Bug 106490 - VA-API video deconding broken for Chromium on Mesa 18.0.3
Summary: VA-API video deconding broken for Chromium on Mesa 18.0.3
Status: RESOLVED DUPLICATE of bug 109548
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: 18.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
Depends on:
Reported: 2018-05-12 16:31 UTC by Leonid Maksymchuk
Modified: 2019-04-01 10:11 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

libva-vdpau-driver 0.7.4 (chromium wrapper) removes deprecated VaProfileH264Baseline (1.05 KB, patch)
2018-05-22 10:47 UTC, Luke McKee
Details | Splinter Review

Description Leonid Maksymchuk 2018-05-12 16:31:08 UTC
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.
Comment 1 Leonid Maksymchuk 2018-05-14 10:31:56 UTC
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.
Comment 2 Luke McKee 2018-05-22 10:40:40 UTC
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:


"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:

I'm recompiling Chromium with swiftshader disabled to see if I can get around the issues I'm having.

Comment 3 Luke McKee 2018-05-22 10:47:56 UTC
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

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.
Comment 4 Luke McKee 2018-05-22 11:11:34 UTC
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.
Comment 5 MWATTT 2018-06-23 01:18:41 UTC
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.
Comment 6 Tomáš Chvátal 2018-10-18 14:04:00 UTC
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.
Comment 7 Kristoffer 2018-12-15 12:03:01 UTC
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.

Comment 8 Michel Dänzer 2019-04-01 10:11:59 UTC

*** 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.