VA-API Video Acceleration On The Linux Desktop Is Nearly Ready For Chrome

[aufkrawall]

Ha, interesting if true. But isn't OGL compositing still off in Firefox and you have to force-enable it?

Unfortunately, yes. It really doesn't seem wise to me that they don't enable it by default nowadays.
I never had a problem with it with both Nvidia and Intel on Linux.

Just discovered that Chromium website rendering on Linux (tested with Nvidia) is also much faster than on Windows. You just have to enable GPU rasterization and it mostly runs smooth as silk on Linux, while on Windows scrolling still shows severe stuttering with heavy content.
It's enabled by default on Android.

Aren't there settings in the Nvidia control panel to affect that? It's been a long time since I've been in Windows and/or used a Nvidia card, but I recall some kind of performance vs. quality video settings somewhere.

I haven't looked at these settings for a while, but I think Nvidia doesn't touch video color by default. The blur seems to be mostly a technical limitation of the API from what I have read at the doom9 forums. At least it's very prone to it.

But yeah, dxva2 sucks in terms of how much control an application has over the video, you're at the mercy of the GPU driver vendor. d3d11va is much better in this regard. I'll have to check what Firefox is actually using, whether it's just dxva2 or if there's d3d11va support too.

I don't know that for sure, but I guess they use d3d11va to make it easier (or even just possible?) to present the frame to their DX11 renderer.
According to LAV Filters developer nevcariel, d3d11va isn't very programmer friendly. At also doesn't work really great in mpv, native requires ANGLE (well, you've already pointed out its greatness) and the copy mode is slower than DXVA2-copy.
VAAPI seems to be the holy grail in comparison, at least from my experience with it.

[Gusar]

I haven't looked at these settings for a while, but I think Nvidia doesn't touch video color by default. The blur seems to be mostly a technical limitation of the API from what I have read at the doom9 forums. At least it's very prone to it.

Hmm, don't see how the API would enter into it. The application calls StretchRect, and what happens there depends on the GPU driver. I just checked my Baytrail netbook (came with Win8.1 pre-installed), dxva2 has slightly different colors (same as --vo=direct3d --vo-direct3d-prefer-stretchrect), but otherwise the picture isn't any blurrier. So if you see a blurrier result, it's your driver screwing up with whatever it's doing in StretchRect.

I don't know that for sure, but I guess they use d3d11va to make it easier (or even just possible?) to present the frame to their DX11 renderer.

I checked the Firefox source, dom/media/platforms/wmf/DXVA2Manager.cpp contains D3D9DXVA2Manager and D3D11DXVA2Manager, so both are supported.

At also doesn't work really great in mpv, native requires ANGLE

That's not been my experience, d3d11va/angle works well here on Intel (the aforementioned Baytrail netbook, also my brother's Haswell laptop). Though it would be nice to see how a d3d11-interop that doesn't use ANGLE would perform. It could depend on the GPU - Nvidia has good OpenGL drivers, Intel on Windows not so much.

and the copy mode is slower than DXVA2-copy.

Also not my experience, though I don't know why one would care about the -copy stuff in the first place.

VAAPI seems to be the holy grail in comparison, at least from my experience with it.

Yep, VAAPI works extremely well, the native output (--vo=vaapi) is very efficient and the EGL interop is perfect to work with all the fancy opengl filters mpv has.

[aufkrawall]

Hmm, don't see how the API would enter into it. The application calls StretchRect, and what happens there depends on the GPU driver. I just checked my Baytrail netbook (came with Win8.1 pre-installed), dxva2 has slightly different colors (same as --vo=direct3d --vo-direct3d-prefer-stretchrect), but otherwise the picture isn't any blurrier. So if you see a blurrier result, it's your driver screwing up with whatever it's doing in StretchRect.

Well possible, you apparently know way better what's going on than me. afair it isn't blurry with AMD driver.
Does DXVA2 not offer a higher processing precision than of 8 bit, independent of the GPU driver?

I checked the Firefox source, dom/media/platforms/wmf/DXVA2Manager.cpp contains D3D9DXVA2Manager and D3D11DXVA2Manager, so both are supported.

Question is if DXVA2 is limited to the legacy DX9 renderer and d3d11va to DX11.

That's not been my experience, d3d11va/angle works well here on Intel (the aforementioned Baytrail netbook, also my brother's Haswell laptop).

I think it's inevitable that ANGLE abstraction comes with some additional overhead compared to native OGL.
GPU usage and power consumption are a bit higher with it on Nvidia compared to WGL/dxinterop.

Though it would be nice to see how a d3d11-interop that doesn't use ANGLE would perform. It could depend on the GPU - Nvidia has good OpenGL drivers, Intel on Windows not so much.

I have just recently opened a feature request for this at Github.

Also not my experience, though I don't know why one would care about the -copy stuff in the first place.

Higher GPU usage with copy compared to native.
It can have advantages like being able to use VapourSynth or DXVA2 on Nvidia without quality drawbacks.

Yep, VAAPI works extremely well, the native output (--vo=vaapi) is very efficient and the EGL interop is perfect to work with all the fancy opengl filters mpv has.

This is also my experience, can achieve stutter-free video and decent quality with my IGP and VAAPI decoding at the same time.

[mulenmar]

Isn't 10-bit support useless if the video wasn't recorded and encoded in 10-bit color anyway? It's not like playback typically requires editing the video, where having the extra color representation is a really nice thing.

Not a lot of material (afaik) out there to bother spending developers' unpaid time on supporting it.

[aufkrawall]

Isn't 10-bit support useless if the video wasn't recorded and encoded in 10-bit color anyway? It's not like playback typically requires editing the video, where having the extra color representation is a really nice thing.

Not a lot of material (afaik) out there to bother spending developers' unpaid time on supporting it.

DXVA2 on Nvidia (and probably also AMD/Intel) limits the renderer to 8 bit internal processing precision. This also increases banding for 8 bit content.

[Gusar]

Isn't 10-bit support useless if the video wasn't recorded and encoded in 10-bit color anyway?

It helps to encode in 10bit even if your material is 8bit. The higher internal precision helps to reduce residuals, which results in better compression (though I hear this is less of an advantage in hevc compared to h264), also results in less banding.

Not a lot of material (afaik) out there to bother spending developers' unpaid time on supporting it.

10bit h264 is basically limited to a few anime encoding groups, no commercial h264 video is 10bit, and there's no 10bit h264 hardware decoders. However, hevc is an entirely different animal, 10bit hevc will be a lot more mainstream due to UHD Blu-ray and HDR video (hevc broadcasts are also 10bit I think). Google is also experimenting with 10bit VP9 on Youtube. Also current hardware already has 10bit hevc and VP9 decoders.

[Gusar]

I think it's inevitable that ANGLE abstraction comes with some additional overhead compared to native OGL.

Compilation time, sure. But runtime performance not necessarily, if the GPU vendor has good Direct3D but less good OGL drivers.

GPU usage and power consumption are a bit higher with it on Nvidia compared to WGL/dxinterop.

Very likely Nvidia is hit differently from Intel here.

I have just recently opened a feature request for this at Github.

I saw that. Though now I'm wondering if it's even possible. Currently, EGL_ANGLE_stream_producer_d3d_texture_nv12 is used to import d3d11va surfaces into OGL, but that's obviously an ANGLE extension. I don't know how one would do it without ANGLE. May not be possible to import the surfaces directly, may be needed to convert the video to RGB with the d3d11 video processor and then import that, which is less than ideal.

[heliosh]

"Nearly ready" ... What happened to this?

[bwat47]

"Nearly ready" ... What happened to this?

The activity dropped off for quite a while, but the patch submitter just submitted an updated patchset on the 9th so there's still activity: https://chromium-review.googlesource...m/src/+/532294

hopefully it lands soon. it's 2018 and still no decent browser with hardware decoding is just absurd :/