2.17 brakes hardware video decoding in Chromium

[gladykov]

libva 2.17 breaks hw video decode with or without vulkan on Chromium

See https://bbs.archlinux.org/viewtopic.php?pid=2080054#p2080054

Accoring to author this commit broke it: ef1df02

[shtirlic]

Also here https://bugs.chromium.org/p/chromium/issues/detail?id=1407223#c10

[mtak-misc]

There will be a difference in the output of vainfo in my environment.

If ef1df02 is enabled, "libva error: /usr/lib/dri/iHD_drv_video.so init failed" will be displayed in the following way.

Trying display: wayland
Trying display: x11
libva error: /usr/lib/dri/iHD_drv_video.so init failed
vainfo: VA-API version: 1.17 (libva 2.17.1)
vainfo: Driver version: Intel i965 driver for Intel(R) Sandybridge Mobile - 2.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

If ef1df02 is disabled, "libva error: /usr/lib/dri/iHD_drv_video.so init failed" will not be displayed in the following way.
Even when using libva 2.16.0, this message will not be displayed.

Trying display: wayland
Trying display: x11
vainfo: VA-API version: 1.17 (libva 2.17.1)
vainfo: Driver version: Intel i965 driver for Intel(R) Sandybridge Mobile - 2.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

[chromer030]

Same issue on ArchLinux , tested with Chromium and Google Chrome.

[guiodic]

I can confirm the issue on Arch Linux with TGL Intel iGPU. Reverting the commit all works fine in Chrome/chromium (anyway vainfo has no errors with or without the commit)

[rkolbaskin]

Vivaldi outputs these error messages whenever I try to play any video.

[2273:2273:0122/130638.210519:ERROR:vaapi_wrapper.cc(2684)] vaPutSurface failed, VA error: invalid parameter
[2273:2273:0122/130638.210775:ERROR:vaapi_video_decode_accelerator.cc(286)] Failed putting surface into pixmap

These errors don't show up if I recompile libva with changes to va/x11/va_x11.c made in aforementioned commit undone.

[adi8900]

For me on Endeavour OS(based on arch anyway) same happens, building package without mentioned commit makes hw video decode working again with chromium based browsers(tested chrome)
But i didn't have any errors in vainfo with that commit or without

[evgeniy-harchenko]

Same for Manjaro, tested on Google Chrome, Yandex Browser and Chromium.

[mtak-misc]

Alpine Linux v3.17.1 also has the same problem in Chromium, but not in Firefox. So the problem may not be Linux distribution specific, but web browser specific.

[shtirlic]

Also might be related https://bugs.chromium.org/p/chromium/issues/detail?id=1399897
(Issue 1399897: Vaapi On GL (don't rely on vulkan))

[evelikov]

Wonder why I don't his this issue with neither Firefox nor Chromium on my Arch box. Both --use-gl=egl and --use-gl=desktop work for me... never really tried Vulkan.

Does chromium work without any flags (be that command line or chromium-flags.conf)? Does disabling the sandbox help? I would be unlikely but worth a shot.

[evelikov]

@mtak-misc if you can do some tracing what exactly causes the iHD driver to fail, that would be greatly appreciated. You might need to either a) start a debugger or b) add some printf() in the driver code-base to find you way around.

My gut feeling is that the driver isn't gracefully falling back to DRI2... Considering the iHD complexity, I'll be better if @dvrogozh @XinfengZhang or anyone in the Intel team fix that.

Will also test the old i965 driver tomorrow + open a PR if needed - bear in mind that getting MRs to land in there is like pulling teeth 😅

[evelikov]

Based on a quick look - this seems to be a bug in iHD, since it doesn't handle DRI3. It could be fixed by reworking the DeviceName handling although that's quite a lot of work - should have a PR by the end of the week.

[tmn505]

This bug doesn't affect only Chromium and iHD driver. I tested Xine player on CherryView (i965) and it also fails to decode when launched with -V vaapi. Reverting the mentioned commit fixes the issue. When tested with mpv everything is ok with or without revert, even when running with --hwdec=vaapi.

[evelikov]

@tmn505 off the top of my head - does Xine use vaPutSurface by any chance?

Edit: Should have looked at the linked bug I guess - yes it does. Xine should probably migrate to using vlVaExportSurfaceHandle instead. Either that or one needs to add support for iHD and i965 - Mesa had a code path for 3+ years.