VDPAU: MPEG-4 Video Corruption/Garbling with Radeon hardware decoding

[Adam Hirst]

Relevant Software / Hardware:

• AMD E2-1800 APU (/w Radeon HD 7340)
• Linux 3.12 (Distro: Arch)
• FFmpeg version 2.1
• mesa, mesa-libgl & ati-dri 9.2.3
• mplayer r36498
• mpv 0.2.3 or git (14/11/2013)

Summary of the bug:

With both mplayer and mpv, some video files encoded using "MPEG-4 part 2" render/decode incorrectly using VDPAU hardware decoding on my AMD graphics chipset. For the record, these files render/decode fine using other methods (e.g. XV or OpenGL), and worked fine back when I was using Catalyst and VA-API.

I've attached mpv & mplayer logs to this ticket, and also the output from vdpauinfo and ffprobe.

How to reproduce:

• call mplayer / mpv with the appropriate arguments to enable VDPAU decoding and rendering on an affected file
• observe noticeable garbling and and green-coloured blocking artefacts

[Adam Hirst]

ffprobe output

[Adam Hirst]

verbose log from mplayer

[Adam Hirst]

verbose log from mpv (git build)

[Adam Hirst]

vdpauinfo output

[Carl Eugen Hoyos]

Is this problem also reproducible with current FFmpeg git head?
Did it work with older versions of MPlayer (and FFmpeg)?

[Adam Hirst]

It's been present with versions of mplayer and mpv for at least the last two months, and at least as far back as FFmpeg 2.0.0. I've had it for as long as I've used VDPAU with the free Radeon drivers, but I wanted to wait until I had the chance to use Linux 3.12 before I started chasing anything up.

I'll compile ffmpeg from git now and report back ASAP.

[Carl Eugen Hoyos]

Please also test MPlayer r36415 with FFmpeg b7fc2693 as an "older" version.

[Adam Hirst]

I haven't been able to build & install a full ffmpeg-git package tonight (I must have mucked something up, I'll get back to it), but I can still offer something.

1. The Arch Linux AUR package/script for mpv-build-git builds mpv with a statically-linked ffmpeg-git, which I was able to get working. I cloned and built it at approximately GMT 23:00 14/11/2013, and I think that corresponds to 9244a680, but to be sure here are the internal version numbers it reports (higher than 2.1 stable at the very least):

• libavutil 52.53.100
• libavcodec 55.43.100
• libavformat 55.21.100
• libswscale 2.5.101
• libavfilter 3.91.100
• libavresample 1.1.0

I can confirm that that has exactly the same problematic behaviour as I initially reported.

2. If by stating a specific older version you wanted to know if versions prior to that commit (on 17/08/2013) still present my issue; then I've been able to downgrade to the stable FFmpeg builds from just before then (specifically 2.0.0 and 2.0.1). I of course also downgraded mplayer and mpv to appropriate versions. Suffice to say, the problem is there too.

But yeah, sorry I haven't yet been able to test the specific version you requested; I just hope that what I have currently been able to do still has some relevance.

[Adam Hirst]

I've uploaded an affected file to my Dropbox account: ​https://dl.dropboxusercontent.com/u/3219541/harlock-ep20.mkv

I can upload more / others if it turns out to be useful.

[Carl Eugen Hoyos]

Since I am not sure I understand you and since testing if your problem is a regression or not makes sense in this particular case, could you confirm if the issue you see is reproducible with MPlayer r36415 and FFmpeg b7fc2693 (I just tested that this combination builds fine and does play ASP via VDPAU on Nvidia hardware)?

[Adam Hirst]

To rephrase what I was saying before, since I seem to have not been clear:

• I was having trouble building ffmpeg/mplayer myself
• I was thinking that the reason you gave specific past-versions of ffmpeg/mplayer for me to test is because you wanted me to see if my problem occured at-or-before that commit (i.e. if it was a regression since then)
• I also reckoned you wanted to know if my problem was still present in git
• What I was able to do on that day was:
  1. Download stable versions of ffmpeg/mplayer from my package manager, dated before the subversions you specified
  2. Build mpv (the mplayer fork I primarily use) from git in such a way that it built against its own static instance ffmpeg (also from git)
• My problem was present in all the older ffmpeg/mplayer versions I tested, and (through the git build of mpv I did) also in the latest ffmpeg subversion

Today, however, I was able to build the specific versions of ffmpeg/mplayer you asked for. Unsurprisingly (at least to me) the problem was present in those too, and was exactly how I described in the opening post.

With regards to your having tested it on Nvidia hardware; if I had to suggest anything, I'd say that this is probably a Radeon+VDPAU only issue. Maybe if someone else with an ATI card/chipset with VDPAU support can test it, it would add some weight to my claim?

[Carl Eugen Hoyos]

Do you have any indication that this isn't a driver issue that has nothing to do with FFmpeg?

[Adam Hirst]

I really don't know. It's definitely true that when I started using VDPAU on my Radeon chip, I also (necessarily) started using the Free driver as well.

From where I stand at least, I'd've thought that this is to do with either FFmpeg's handling of this specific kind of file content over to VDPAU, or how the radeon driver gets it from VDPAU to the hardware decoder.

Either way; I know that mplayer/mpv/VLC/etc. can play this content fine with Nvidia+VDPAU, software-decoding and so on; and I know that this specific device has been able to hardware decode it (Catalyst+VAAPI) - so surely the problem has to lie somewhere between the player and the hardware?

I thought I ought to report my issue to FFmpeg first, since I fully expected that the freedesktop guys would just say something like "report to FFmpeg first and work down from there".

What do you think then; should I report this over there as well, link to this report, and see how it goes?

[Carl Eugen Hoyos]

Given that it works fine with Nvidia hardware and drivers, I would suggest so.