| Bug ID | 108937 |
|---|---|
| Summary | [radeonsi, RX480] VAAPI H.264 decoder produces garbage on You= Tube 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 [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.youtu= be.com/watch?v=3DoiSn2JuDQSc 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 VP= 9, and thus software decoding.
Created attachment 142708 [detail=
s]
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=3Dfalse 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.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | NOTOURBUG |
| Status | NEW | RESOLVED |
Alternatively update the applications. The problem is that the driver exposes 10bit RGB and the applications selec= ts that for some reason but actually can't handle it correctly.
| What | Removed | Added |
|---|---|---|
| Resolution | NOTOURBUG | DUPLICATE |
*** This bug has been marked as a duplicate of bug 104597 ***
I don't control the application, and it's already the latest v= ersion 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 fro= m, and hoping they can point me where I should report it for inclusion in the patch set.
(In reply to Christian K=C3=B6nig from comment #4) > Alternatively update the applications. >=20 > 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 ha= d 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=C3=B6nig from comment #4) > > Alternatively update the applications. > >=20 > > The problem is that the driver exposes 10bit RGB and the applicat= ions > > selects that for some reason but actually can't handle it correct= ly. >=20 > 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 A= MD now and some applications doesn't seem to correctly handle those. > I had an argument with my favorite distro's main= tainers 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.=