[Bug 108937] [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify
https://bugs.freedesktop.org/show_bug.cgi?id=108937
Bug ID: 108937 Summary: [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: kode54@gmail.com QA Contact: dri-devel@lists.freedesktop.org
Created attachment 142707 --> https://bugs.freedesktop.org/attachment.cgi?id=142707&action=edit Screen shot of YouTube video in Chromium, artifacts
I am attempting to play H.264 video in Chromium, using a fork of the current beta (v71) that has a VAAPI patch applied. When playing the following video:
https://www.youtube.com/watch?v=oiSn2JuDQSc
I get the resulting video output, attached.
Using:
Description: Ubuntu 18.10 Release: 18.10
chromium-browser 71.0.3578.62-0ubuntu1~ppa1~18.10.1
mesa-va-drivers 19.0~git1812040730.bacf84~oibaf~c
It should be possible to follow those to the patches used, but I don't think that the Chromium patch is responsible for "misusing" VA-API, so much as the radeonsi VA-API driver being broken in some way.
The artifact simply goes away if I disable h264ify, since it switches to VP9, and thus software decoding.
https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #1 from Christopher Snowhill kode54@gmail.com --- Created attachment 142708 --> https://bugs.freedesktop.org/attachment.cgi?id=142708&action=edit The problematic video, downloaded from YouTube
Attaching the correct video, so it doesn't necessitate installing the right Chromium or h264ify extension.
https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #2 from Christoph Haag haagch@frickel.club --- Try setting allow_rgb10_configs to false for chromium in drirc or starting chromium with the env var
allow_rgb10_configs=false chromium
see also bug #104597
https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #3 from Christopher Snowhill kode54@gmail.com --- Yes, that dodges the issue. Should I be enabling this setting system-wide, possibly for other applications? I recall Totem having the same issue with H.264 hardware decoding.
https://bugs.freedesktop.org/show_bug.cgi?id=108937
Christian König ckoenig.leichtzumerken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEW |RESOLVED
--- Comment #4 from Christian König ckoenig.leichtzumerken@gmail.com --- Alternatively update the applications.
The problem is that the driver exposes 10bit RGB and the applications selects that for some reason but actually can't handle it correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=108937
Christian König ckoenig.leichtzumerken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|NOTOURBUG |DUPLICATE
--- Comment #5 from Christian König ckoenig.leichtzumerken@gmail.com ---
*** This bug has been marked as a duplicate of bug 104597 ***
https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #6 from Christopher Snowhill kode54@gmail.com --- I don't control the application, and it's already the latest version currently available. It's already a feature implemented by a patch that hasn't been accepted by upstream since it was submitted over a year ago. I've already emailed the maintainer of the PPA that I'm installing the Chromium beta from, and hoping they can point me where I should report it for inclusion in the patch set.
https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #7 from network723@rkmail.ru --- (In reply to Christian König from comment #4)
Alternatively update the applications.
The problem is that the driver exposes 10bit RGB and the applications selects that for some reason but actually can't handle it correctly.
Could you please confirm that it is a bug of application and not Mesa? I had an argument with my favorite distro's maintainers on this, and their point is that other drivers (intel and nouveau) don't have this problem. Do these drivers even expose 10bit color configs?
https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #8 from Christian König ckoenig.leichtzumerken@gmail.com --- (In reply to network723 from comment #7)
(In reply to Christian König from comment #4)
Alternatively update the applications.
The problem is that the driver exposes 10bit RGB and the applications selects that for some reason but actually can't handle it correctly.
Could you please confirm that it is a bug of application and not Mesa?
Please see the other bug report. This is actually not a problem related to the driver or Mesa in any way. The xserver just exposes 10bit color config on AMD now and some applications doesn't seem to correctly handle those.
I had an argument with my favorite distro's maintainers on this, and their point is that other drivers (intel and nouveau) don't have this problem. Do these drivers even expose 10bit color configs?
Not sure, but that can indeed be the reason they don't show those problems.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org