Summary: | [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify | ||
---|---|---|---|
Product: | Mesa | Reporter: | Christopher Snowhill <kode54> |
Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED DUPLICATE | QA Contact: | Default DRI bug account <dri-devel> |
Severity: | normal | ||
Priority: | medium | CC: | network723 |
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Screen shot of YouTube video in Chromium, artifacts
The problematic video, downloaded from YouTube |
Description
Christopher Snowhill
2018-12-04 09:25:13 UTC
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.