Created attachment 142707 [details] 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.
Created attachment 142708 [details] The problematic video, downloaded from YouTube Attaching the correct video, so it doesn't necessitate installing the right Chromium or h264ify extension.
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
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.
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.
*** This bug has been marked as a duplicate of bug 104597 ***
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.
(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?
(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.
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.