Summary: | VC-1 VDPAU decoding on radeon causes occasional garbage | ||
---|---|---|---|
Product: | Mesa | Reporter: | Fluendo dev team <fluendo-tech> |
Component: | Mesa core | Assignee: | 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
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. 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. Please test with mesa master as well. I've just tried it on a Richland and there it also seems to work perfectly fine. (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 :-) Created attachment 122108 [details]
script to decode and md5sum
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? (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. -- 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.