Bug 108937 - [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify
Summary: [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium...
Status: RESOLVED DUPLICATE of bug 104597
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-04 09:25 UTC by Christopher Snowhill
Modified: 2018-12-05 08:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screen shot of YouTube video in Chromium, artifacts (405.56 KB, image/png)
2018-12-04 09:25 UTC, Christopher Snowhill
Details
The problematic video, downloaded from YouTube (5.54 MB, video/mp4)
2018-12-04 09:27 UTC, Christopher Snowhill
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Snowhill 2018-12-04 09:25:13 UTC
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.
Comment 1 Christopher Snowhill 2018-12-04 09:27:07 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.
Comment 2 Christoph Haag 2018-12-04 20:53:30 UTC
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
Comment 3 Christopher Snowhill 2018-12-05 00:26:35 UTC
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.
Comment 4 Christian König 2018-12-05 07:38:28 UTC
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.
Comment 5 Christian König 2018-12-05 07:39:43 UTC

*** This bug has been marked as a duplicate of bug 104597 ***
Comment 6 Christopher Snowhill 2018-12-05 07:41:48 UTC
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.
Comment 7 network723 2018-12-05 08:45:51 UTC
(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?
Comment 8 Christian König 2018-12-05 08:52:57 UTC
(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.