[radeon] Totem with gstreamer1.0-vaapi and Xorg: wrong color on H264 videos

i attach a screenshot that shows the problem

I am also affected by this bug on Ubuntu 18.04

Status changed to 'Confirmed' because the bug affects multiple users.

Could you include the output of the command "dpkg -l | grep gstreamer"?

Do you get the issue on any h264 video? Do you use an xorg or wayland session and what is your video driver?

Please also try this as a workaround:

sudo apt remove mesa-va-drivers

I've opensource amdgpu driver "xserver-xorg-video-amdgpu/bionic,now 18.0.1-1 amd64 [installato]"
The problem occurs both on xorg and wayland, but on wayland i've a total black screen, i can hear only audio.
every h264 video that i've tried has this problem.
if i remove "mesa-va-drivers" package, the problem disappear

i attach the output of "dpkg -l | grep gstreamer"

you should file it upstream at

https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa

drivers/gallium/radeonsi

I would have done that already, but have not verified if the problem really is in mesa-va-drivers.

It's hard to tell when mpv doesn't work either (for different reasons). So we haven't yet excluded the possibility that the bug is in gstreamer1.0-vaapi.

i understand.
so i must report upstream on https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
or not??

It's reasonably likely the bug is in mesa, so yes worth reporting still.

I have tested on my Radeon RX480, also AMDGPU drivers, git snapshot from 20180829 from Padoka PPA, and this bug occurs with Totem as well.

It should also be noted that the bug does not occur with mpv, either with vdpau or vaapi.

For future reference, please don't mention PPAs in bug reports, or report bugs against packages installed from PPAs. Because we are unable to support them.

But yes, comment #13 looks like this bug.

I only thought to mention the PPA to indicate that the bug still occurs even in fairly bleeding edge Mesa code. I also still think it's either something wrong with gstreamer-vaapi, or something that gstreamer-vaapi is doing different from what mpv does for the same exact video. It should probably be reported to upstream Mesa, just in case it really is their bug.

Adding a comment to indicate that this is a problem with the 10bpc support which is enabled in Radeon graphics. I am unsure if it is enabled in Intel's drivers, so that would explain why it does not occur there. Either VA-API is outputting wrong, the client library is outputting wrong, or all the player applications are wrong. Something appears to be matching the buffers to each other without a conversion, simply because both RGBA32 and RGBA10-10-10-2 have the same number of bytes per pixel, but clearly completely different structure.

A workaround is to add the following to the //driconf/device section of /etc/drirc:

<application name="Default">
    <option name="allow_rgb10_configs" value="false"/>
</application>

Clearly, this workaround should not be the only way, since someone in the processing chain clearly wants 10bpc support, and some applications can benefit from it, somehow.

I'm experiencing this issue as well. I have an RX550 video card, using Ubuntu's drivers.

Has anyone reported this to mesa, and if so where? If someone can share the right location/component for ME to log a bug, I will do so.

It seems that AMD GPUs are quite useless today, a million things are broken and I'm strongly considering throwing out this $140 brand new video card to get a NVidia card that hopefully works 50% better.

10bpc is already disabled by default for every gallium driver, so it's surprising to hear that you'd need to flip the default manually in drirc

unless you use 3rd party mesa, in which case all bets are off

After testing from a well modified system, the issue appears after I install the amdgpu driver from AMD.

THAT SAID, this issue is noticeable on videos that I have viewed on this system since initial install in January. I constantly view many videos in Videos (every day) - so I suspect that something changed, that I cannot undo.

Which specific package should I be verifying?

example of broken video properties

example of good video properties

I'm also affected by this bug. I've tried many different things that I described in another bug report:
https://bugs.launchpad.net/ubuntu/+source/gstreamer1.0/+bug/1818382

For me it's not the case with the amd drivers. The same bug is there on a clean install of Ubuntu too.

Please use the workaround at the top of this bug.

removing gstreamer1.0-vaapi did the trick but I don't think a user should be expected to do that on every new installation.

Maybe it shouldn't be included in 19.04 until it's fixed?

As already stated above, the correct workaround, for now, is to configure a drirc (probably in a conf.d directory, so it doesn't clash with other settings files) so as to disable 10 bit per channel support for Totem. The same had to be done with Chromium-vaapi, as it also happens with that solution.

Which DRI driver are you using? 10bpc is disabled for every gallium driver (like radeonsi) and intel, so I don't understand how changing the drirc would affect at all.

This bug can only occur if 10bpc is enabled. There is no other possibility. It is clearly a colorspace mismatch between VAAPI and the decode target surface. If disabling 10bpc happens in Ubuntu Mesa packages, then it is clearly someone using unofficial package builds of Mesa which have 10bpc enabled on supporting hardware.

Or as one user posted, the official AMDGPU Pro package, which also enables 10bpc.

I thought I had reproduced this bug in the past when doing radeon testing. And my radeon testing does not involve AMDGPU or PPAs. Just vanilla Ubuntu on radeon was enough to reproduce it.

I, too, had this bug manifested on clean Ubuntu without PPAs and without AMDGPU.

disabling 10bpc solved the problem, thanks

Verified on bionic (fresh install and fully updated) that the bug is still present, and that the workaround in comment #16 works. It just took me a while to remember you need to:
  1. Install ubuntu-restricted-addons; and
  2. Use Xorg (because if you're in a Wayland session you hit bug 1720820 instead).

---

OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon R6 Graphics (CARRIZO, DRM 3.23.0, 4.15.0-46-generic, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

---

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wani [Radeon R5/R6/R7 Graphics] (rev c6)
        Subsystem: Hewlett-Packard Company Carrizo
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu

---

libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Mesa Gallium driver 18.2.2 for AMD Radeon R6 Graphics (CARRIZO, DRM 3.23.0, 4.15.0-46-generic, LLVM 7.0.0)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple : VAEntrypointVLD
      VAProfileMPEG2Main : VAEntrypointVLD
      VAProfileVC1Simple : VAEntrypointVLD
      VAProfileVC1Main : VAEntrypointVLD
      VAProfileVC1Advanced : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main : VAEntrypointVLD
      VAProfileH264Main : VAEntrypointEncSlice
      VAProfileH264High : VAEntrypointVLD
      VAProfileH264High : VAEntrypointEncSlice
      VAProfileHEVCMain : VAEntrypointVLD
      VAProfileJPEGBaseline : VAEntrypointVLD
      VAProfileNone : VAEntrypointVideoProc

Also verified mpv works, but mpv isn't using VAAPI at all. It's using software decoding because "VO does not support requested hardware decoder".

I hit this bug on Fedora 28 when using a third-party mesa build. Here's the ~/.drirc I used to fix this:

<driconf>
  <device driver="radeonsi">
    <application name="totem" executable="totem">
      <option name="allow_rgb10_configs" value="false" />
    </application>
  </device>
</driconf>

This also fixed the timecode in Totem showing strange, rainbow colors, caused by the same thing. Repeat the application section as required for each program affected.

Sounds like we have a semi-permanent workaround now:

gstreamer-vaapi (1.16.0-3ubuntu2) eoan; urgency=medium

  * debian/patches/git_no_amd.patch:
    - backport an upstream change to disable vaapi with the amd drivers,
      the current experience is buggy and it's better to just not enable it
      see the discussions on this mailing list and the referenced bug
      https://mail.gnome.org/archives/distributor-list/2019-September

 -- Sebastien Bacher <email address hidden> Mon, 09 Sep 2019 17:09:08 +0200