Vaapi support testing

[toofar]

Splitting this out from #5378

With Qt 6.6.0 WebEngine supports VA-API for hardware accelerated video decoding. This discussion is to gather resources and test notes to figure out in what situations it works.

Where can I test?

There are videos you can test with here: http://crosvideo.appspot.com/

How can I test?

• While a video is playing open up chrome://media-internals/
• At the top select the relevent video stream (it'll be in state kSuspended or kPlay)
  
• Scroll down and look for kVideoDecoderName. If it's using Vaapi I think the decoder should read VaapiVideoDecoder (this screenshot is showing a configuration without Vaapi). In some cases you can get the slightly older GPU accelerated decoder VDAVideoDecoder to show up too
  
• Scroll further down to see various logs from the media module.
  • If you have Vaapi support built in but it is not enabled (based on configuration or unsupported codec, and maybe more reasons) you'll see an info message "Cannot select VaapiVideoDecoder for video decoding"
    
  • If the VaapiDecoder is enabled but there are errors you may see them here too, eg here is what you'll see on AMD graphics:
    
  • If you don't see VaapiVideoDecoder mentioned in there at all you probably don't have Vaapi support built in

You can also use intel_gpu_top or nvtop to monitor the GPU video decoding state, see https://wiki.archlinux.org/title/Hardware_video_acceleration#Verification

How can I build Vaapi into Qt?

If you have the development files for libgbm and libva installed the Qt build system should autodetect that and enable Vaapi support. You should see a VA-API support entry under Qt WebEngineCore in config.summary.

What situations does Vaapi decoding work in?

• You'll need Qt6.6+
• You probably need Intel graphics, unless you want to patch your chrome sources.
• You may need to pass enable-features=VaapiVideoDecoder in qt.args (I don't think that is necessary though)
  • You might also need ignore-gpu-blocklist, that's mentioned in the chrome docs, which are a bit out of date
• ⚠️ On Linux with desktop OpenGL you need to pass enable-features=VaapiVideoDecodeLinuxGL in qt.args. Although I don't think this is a supported configuration
  • TODO: does this even work on intel graphics? On https://bugreports.qt.io/browse/QTBUG-91677 they said you need to pass QT_XCB_GL_INTEGRATION=xcb_egl, assuming egl is OpenGL ES then that implies that desktop OpenGL doesn't work
  • 💡 Another option when using desktop OpenGL is to pass disable-features=UseChromeOSDirectVideoDecoder in qt.args. This switches away from the Vaapi decoder to the slightly older VDAVideoDecoder which also seems to use hardware acceleration!
• You may be able to set QT_XCB_GL_INTEGRATION=xcb_egl
  • This doesn't seem to affect anything for me? It doesn't auto-enable Vaapi and it doesn't make it work when VaapiVideoDecodeLinuxGL is passed
• You can enable the Vulkan backend with QSG_RHI_BACKEND=vulkan
  • Note that we haven't tested the vulkan backend well, it may have issues
  • ⚠️ If you are not on Intel graphics you'll have to pass in enable-features=VaapiIgnoreDriverChecks. This isn't a supported configuration (but seems to work with a patch)
• TODO: is any of this relevant for Mac and Windows?
• TODO: does this only work for some codecs? In the source I'm seeing delegates for: av1, h264, h265, vp8, vp9
• TODO: isn't this supposed to be better on Wayland? I'm not sure, the platform feature detection seems to be the same. Beyond that I'm not noticing any difference. Maybe Wayland uses GLES natively but because I don't have that compiled in that's why?

The various platform restrictions are in here: https://github.com/qt/qtwebengine-chromium/blob/a71ba6ffc8e34033b93c0727e8d7eb17f7d6a25f/chromium/media/mojo/services/gpu_mojo_media_client_cros.cc#L96
Although I'm not seeing anything about EGL or GLES in there, so I'm not sure where that comes into it.

There is a bug report here about Vaapi support on Linux in general: https://bugs.chromium.org/p/chromium/issues/detail?id=1236697#c102
Comment 102 seems to have a patch way to get it working on non-intel graphics!

The only slightly out of date Chrome docs on Vaapi are here: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/gpu/vaapi.md

There are various switches which may or may not be useful here: https://github.com/qt/qtwebengine-chromium/blob/a71ba6ffc8e34033b93c0727e8d7eb17f7d6a25f/chromium/ui/gl/gl_switches.cc

Long arch thread about Vaapi and Chrome here: https://bbs.archlinux.org/viewtopic.php?id=244031&p=35

What ubuntu is shipping: https://discourse.ubuntu.com/t/an-overview-of-hardware-acceleration-in-chromium/36672

More things to test:

1. Intel graphics:
   1. With a working configuration, which of these qt.args values are needed, if any? ignore-gpu-blocklist, enable-accelerated-video-decode, enable-features=VaapiVideoDecoder, enable-features=VaapiVideoDecodeLinuxGL, enable-features=VaapiIgnoreDriverChecks
   2. Does it work with vulkan graphics? (export QSG_RHI_BACKEND=vulkan)
   3. Does it work with egl? (export QT_XCB_GL_INTEGRATION=xcb_egl)
   4. Does it work under wayland?
   5. Does it work with desktop Open GL? (check GL_VERSION in chrome://gpu)
2. Non-Intel graphics
   1. Do the patches from the chrome bugtracker work?
      1. The gist works for me to enable Vaapi support on Vulkan on AMD (with the VaapiIgnoreDriverChecks feature passed in), I haven't tried to see if the other three fix desktop GL mode
      2. For Qt 6.7 (currently chrome 118 based) that patch for chrome isn't being updated and the [recommendation](https://gist.github.com/thubble/235806c4c64b159653de879173d24d9f?permalin
         k_comment_id=4718214#gistcomment-4718214) is to compile mesa with patches
   2. Even without those patches does adding disable-features=UseChromeOSDirectVideoDecoder into qt.args get you hardware acceleration via the VDAVideoDecoder decoder when not using vulkan?
3. xcb_egl
   1. I don't understand why it's not working for me with this set since the Qt people said it should. Does it only do stuff on intel graphics?
   2. You can tell if this had an effect by looking at GL_VERSION in chrome://gpu. Without it I'm seeing "4.6 ..." and with it I'm seeing "OpenGL ES 3.2 ..."

Recommended config so far:

TODO: turn this into a config.py snippet? Not sure if we can change qt.args in config.py.

If not vulkan:
  # This options enables Vaapi on desktop GL, but it doesn't work with 112
  # based (also requires patching chrome for non-intel)
  #enable-features=VaapiVideoDecodeLinuxGL # currently broken
  # So switch back to the older GPU accelerated decoder (which doesn't work
  # with vulkan). Will probably go away in a later chrome version.
  qt.args += disable-features=UseChromeOSDirectVideoDecoder
If vulkan and not intel:
  # Patch chrome and:
  qt.args += enable-features=VaapiIgnoreDriverChecks

[toofar]

Update on Vulkan support I suppose. I've been re-testing it on my main instances again over the last couple of days and am seeing the same instability on 6.6.0 that I was seeing on 6.5. Lots of renderer process crashes (status 11) and sometimes if I have two windows open sometimes if I open a background tab in window A with some media on it, and there is media playing in an active tab in window B, both windows will freeze up until I switch tabs away from the one with media playing in window B. I feel like I've been getting a way higher rate of super inconvenient errors in the amdgpu driver too.

Ah, seems the renderer crashes are an unrelated issue.

So back to OpenGL for me, nothing to do with Vaapi I don't think, but I'll be testing VDAVideoDecoder instead.

[toofar]

Another update, this one regarding Qt6.7 beta (chrome 118 based).

I can't figure out how to get hardware accelerate video decoding working with an OpenGL backend.
disable-features=UseChromeOSDirectVideoDecoder doesn't work anymore, as expected.
enable-features=VaapiVideoDecodeLinuxGL successfully selects the VaapiVideoDecode but that logs an error about failed Initialize()ing the frame pool (might be an AMD specific issue?)
The arch megathread says you need to use angle too, but I get an error when trying that that which seems to say there are no supported angle backends. So we might be waiting on https://bugreports.qt.io/browse/QTBUG-112281 for that. I haven't tried with the patch for that yet. Or maybe I need to add more flags to let it initialize the frame pool again. This person was having the same issue as me and they said they got it work on 119. So maybe I'll try again then.

I can get it working easy by enabling the Qt vulkan backend (export QSG_RHI_BACKEND=vulkan) ~but in my experience the hardware acceleration from chrome via vulkan (or maybe it's just the Qt vulkan implemenation?) has issues on my AMD 6700 XT: when playing a videos it sometimes uses ~80% of the GPU (not on a fresh instance, not sure what causes that) and some videos have periodic pauses in them (similar to this report). The old OpenGL acceleration didn't have this problem.
Edit: the increased GPU load seems to happen after suspending

For AMD users that patch for chrome isn't being updated anymore and they recommend rebuilding mesa with a patch or two. frontends/va: Only export one handle for contiguous planes (!26165) · Merge requests · Mesa / mesa · GitLab and, if on chrome < 119, Draft: gbm: Allow GBM allocation of YUV surfaces (!23214) · Merge requests · Mesa / mesa · GitLab. With them (on 118 based) vulkan is working fine with no patches to chrome/webengine.

I'll keep running with the vulkan backend for now, not 100% convinced in its robustness yet but no crashes in 3 days at least.

[xaizek]

Thanks for this guide. Just wanted to provide a data point on VAAPI working:

• Slackware current (it's a rolling release, so some older versions of packages also worked)
• qutebrowser v3.1.0
• Qt 6.6.2_20240210_15b7e743
• Mesa 24.0.1
• xorg-server 21.1.11
• Intel iGPU of i5-14600K

The only real configuration was setting QSG_RHI_BACKEND=vulkan to use Vulkan backend. After using this for about two months, I have only noticed a rare glitch which looks like several pixel rows of rendered text are missing (seems to appear only on some sites) which didn't happen with OpenGL backend. However, I also have

c.qt.workarounds.disable_accelerated_2d_canvas = 'never'

but don't know if it's a workaround for this glitch or something else. It's a minor thing anyway.
EDIT: the glitch seems to not be related to the workaround option or Vulkan (could be scaling or something else).
EDIT2: no longer works with Qt6 6.7.1, using Vulkan causes a crash.