VA-API video decoding doesn't work for Chromium browser with VA-API support patches. It works perfectly fine with Mesa 17.3.9: https://imgur.com/tMSKtsb But totally broken with Mesa 18.0.3: https://imgur.com/xVGQDhB My system is CentOS 7.5, custom built kernel 4.14.32 (longterm). Video adapter is ASUS Radeon R9 Fury 4GB. Mesa packages is also built by me. libdrm version 2.4.91. LLVM version 6.0.0. libva version 0.40. There isn't any errors reported by Chromium or libva or in dmesg. Also I found in discussion of chromium-vaapi (for Arch) a user with AMD Radeon have very same problem with Mesa 18. Link to discussion: https://aur.archlinux.org/packages/chromium-vaapi-bin/?comments=all User name is digitalone. Link to his screenshot: https://imgur.com/a/vYDJ9 Chromium built with VA-API patches is available in Ubuntu PPA or Arch Linux AUR. If it'll be needed I can upload my build of Chromium with VA-API patches for CentOS 7 somewhere. Chromium flags to enable VA-API acceleration: https://imgur.com/IHkOvlt Ubuntu PPA: https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-dev Arch Linux AUR: https://aur.archlinux.org/packages/chromium-vaapi-bin Ask for any information that You may need.
It looks like it's Chromium or VA-API bug, but not Mesa. Chromium VA-API decoding works with Mesa 18.0 if RGB10 visual configs is disabled.
I'm having a crack at this now and I've got it working using a vdpau-wrapper of sorts, though there has been some scrambling of the colours. I'm still fixing it. What I have seen is that Chrome expects a feature that's not implemented in the gallium state tracker: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-dev/HYz_MOfNtkE "2. While searching for a unit test. I bumped into a bunch of test cases from Autotest suite. I tried to run video_VideoDecodeAccelerator.h264 But the test case failed since one of VA-APIs used by chromium has not been implemented in state_trackers yet (vaQuerySurfaceAttributes) Is there any other unit test available, that I can run to confirm whether decoding is happening properly? Maybe something that decodes and dumps raw data into a file? " Chrome will not work directly with the mesa vaapi interface until this feature is added. I've found a patch for this feature into libva-vdpau-driver that works around it not being there. It's included on the arch linux link above. I could attach a tar the ebuild for gentoo but this user uses fedora. Gentoo and arch Linux have similar patches. Ubuntu and fedora have their own overlay's for the chromium vaapi wrapper. Here's a fedora user's chromium build: https://github.com/biswasab/chromium_vaapi_fed I'm recompiling Chromium with swiftshader disabled to see if I can get around the issues I'm having. https://bugs.chromium.org/p/chromium/issues/detail?id=719213
Created attachment 139679 [details] [review] libva-vdpau-driver 0.7.4 (chromium wrapper) removes deprecated VaProfileH264Baseline Add this patch along with all the others here https://aur.archlinux.org/packages/chromium-vaapi/?comments=all Maybe upstream arch / gentoo should take this too but gentoo's bug tracker is run by fascists. Also it would be nice if someone could add h265 / hecv support to libva-vdpau-driver too as a patch if upstream isn't going to be fixed to implement vaQuerySurfaceAttributes needed by Chromium. This workaround for chromium doesn't support h265 even if your hardware's vdpau does. When testing in mpv I see 4% cpu in VAAPI and ~6% cpu using the VDPAU warpper.
P.S. Leonid everything you are running is too old. I'm using git for libva and all amd drivers, kernel etc - except ffmpeg. Why running the bleeding edge may break some things it fixes others. Until last month I have to use mpv -vo vdpau (or opengl with hwdec=vdpau) - but now mpv -vo opengl (or vaapi) --hwdec=vaapi --opengl-hwdec-interop=vaapi-egl works. Previously I had to use the glx interop with with vaapi that was much slower than vdpau, so I played around with openmax for encoding and vdpau for decode. FYI Chrome uses EGL with vaapi. I suspect if you don't upgrade you too will find that problem. That was one step overcome to make chrome work. Last month there was two issues blocking us.
I have this problem too. A workaround is to set the driconf option "allow_rgb10_configs" to false for chromium-browser. This problem affects radeonsi and r600g, but not i965.
This might be possible duplicate of: https://bugs.freedesktop.org/show_bug.cgi?id=104597 I can reproduce this too on openSUSE with Mesa 18.1. The issue itself is exposed only on Radeon driver not on intel/nouveau. The workaround of course works, but I think there must be some bug in Mesa radeonsi code as the intel/nouveau both manage to play stuff properly using the libva and the conversion to opengl.
This affects not only Chromium but also Totem and Epiphany when using VA-API. MPV does not seem affected, so it seems to me as if anything using gstreamer is affected. https://imgur.com/a/2Fi989D
*** This bug has been marked as a duplicate of bug 109548 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.