Bug 94381

Summary: VC-1 VDPAU decoding on radeon causes occasional garbage
Product: Mesa Reporter: Fluendo dev team <fluendo-tech>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED MOVED QA Contact: mesa-dev
Severity: normal    
Priority: medium    
Version: 11.0   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Example of the garbage with the video "Test_1440x576_WVC1_6Mbps.wmv"
script to decode and md5sum

Description Fluendo dev team 2016-03-03 09:35:13 UTC
Created attachment 122093 [details]
Example of the garbage with the video "Test_1440x576_WVC1_6Mbps.wmv"

Playing WVC1 encoded videos with VDPAU hardware acceleration in a Radeon platform causes the playback to show a lot of garbage.
This happens occasionally: sometimes it works perfectly and sometimes it shows the garbage.
It happens with videos encoded in either simple, main or advanced.

This thread in the mailing list talks about the same behaviour, but we couldn't find a bug reported about this, and this happens to advanced profile too: https://lists.freedesktop.org/archives/mesa-dev/2015-September/095144.html

Testing with the same videos in the thread:
http://samples.ffmpeg.org/V-codecs/WVC1/Test_1440x576_WVC1_6Mbps.wmv
http://samples.ffmpeg.org/asf-wmv/asf_with_chapters.wmv

We reproduce this with the command found in the mailing list:
mpv --hwdec=vdpau --vo=vdpau
And with a gstreamer pipeline using the Fluendo video acceleration codec:
gst-launch-0.10 playbin2 uri=file://[...]

Both ways reproduce the same garbage, when it happens.
Comment 1 Andy Furniss 2016-03-03 13:17:52 UTC
Maybe post what hardware/mesa/kernel you test with.

Repeatedly decoding to ram via script the first file has so far got me the same md5sum > 200 times at time of writing.

I am using amdgpu/tonga which is UVD 5.0 (IIRC).

Powerplay is experimental on this h/w and until recently I could eventually get uvd to go wrong by repeatedly decoding h264 using a mix of vaapi/omx/vdpau.

If you try hard enough can you get h264 to err?

The second file - asf is interesting in that it has artifacts for me decoding with ffmpeg software which aren't present with vdpau h/w dec.
Comment 2 Fluendo dev team 2016-03-03 17:33:02 UTC
The hardware is a Kabini [Radeon HD 8400E], which I think is UVD 4.
Mesa version is 11.0.9
Kernel version is 4.4.0

The OS is based on Ubuntu Trusty 14.04.3 64bit.

Can you share the script you used to decode to ram?

Testing with a h264 video, it worked perfectly every time.

The "asf_with_chapters.wmv" video works fine for me with software, but shows garbage with hardware.
Comment 3 Christian König 2016-03-03 18:38:34 UTC
Please test with mesa master as well. I've just tried it on a Richland and there it also seems to work perfectly fine.
Comment 4 Andy Furniss 2016-03-04 00:54:55 UTC
(In reply to Fluendo dev team from comment #2)
> The hardware is a Kabini [Radeon HD 8400E], which I think is UVD 4.
> Mesa version is 11.0.9
> Kernel version is 4.4.0
> 
> The OS is based on Ubuntu Trusty 14.04.3 64bit.
> 
> Can you share the script you used to decode to ram?

Well it's a bit of a hack on top of a script I used to test h264 and as I use ffmpeg git via bash alias (ffm) I further modified a bit so it should work for you, assuming you have a working ffmpeg. IME ffmpeg may silently fall back to s/w, so you need to check cpu usage. The threads 1 may not be needed.

Normally with x264 md5sum matches s/w decode (with caveats which is why there are different workarounds in parts of the script that won't run as it is).

vc1 it seems mostly doesn't sum the same as s/w dec so the script just compares to the first run.

I use LFS and have 8 gig ram I made /mnt/ramdisk and then do -

mount -t tmpfs -o size=6200m tmpfs /mnt/ramdisk

of course tmpfs can get swapped out and you'll need to size for your mem/needs and adjust the paths/filename in the script as required. 

> 
> Testing with a h264 video, it worked perfectly every time.
> 
> The "asf_with_chapters.wmv" video works fine for me with software, but shows
> garbage with hardware.

OK, so my ffmpeg has regressed, another bisect to do :-)
Comment 5 Andy Furniss 2016-03-04 00:55:49 UTC
Created attachment 122108 [details]
script to decode and md5sum
Comment 6 Fluendo dev team 2016-03-10 11:23:38 UTC
I've tried to test with mesa master. I've compiled it, but when I replace the dri drivers (radeon_dri.so, radeonsi_dri.so, ...) my Xorg server crashes, and I can't make it work until I put back the original drivers.

Do I need to compile any other driver for the X server or anything like that? Am I missing something here?
Comment 7 Christian König 2016-03-10 12:13:42 UTC
(In reply to Fluendo dev team from comment #6)
> I've tried to test with mesa master. I've compiled it, but when I replace
> the dri drivers (radeon_dri.so, radeonsi_dri.so, ...) my Xorg server
> crashes, and I can't make it work until I put back the original drivers.
> 
> Do I need to compile any other driver for the X server or anything like
> that? Am I missing something here?

Mhm, maybe the configure options used to compile mesa doesn't match the one used on your distribution.

But you don't need to replace radeonsi_dri.so or radeon_dri.so (BTW: that one is for decade old hardware, so you don't need it anyway).

All you need is libvdpau_radeonsi.so or libvdpau_r600.so.
Comment 8 GitLab Migration User 2019-09-18 20:25:17 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1002.

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.