Created attachment 89489 [details] Playback log from mpv-player I initially reported this over at the FFmpeg Trac, so just in case I accidentally omit to mention something I've already considered (or just for reference), that's over at https://ffmpeg.org/trac/ffmpeg/ticket/3138 == Relevant Software / Hardware: == * AMD E2-1800 APU (/w Radeon HD 7340), i.e. PALM * Linux 3.12 (Distro: Arch) * FFmpeg 2.1 * mesa, mesa-libgl & ati-dri 9.2.3 * mplayer r36498, mpv 0.2.3 & VLC 2.1.1 == Summary: == Some files encoded into "MPEG-4 part 2" (seemingly, those using GMC, if zgreg's hunch on #radeon is anything to go by) render/decode incorrectly using VDPAU hardware-decoding on my AMD chipset. The files work fine using software decoding, and worked fine back when using Catalyst & VA-API (which should mean that the files and the hardware are fine). By "incorrectly", I don't mean complete garbage. About half of the image renders fine, it's just that between reference frames it progressively garbles into a bright-green mess in heavily-updated areas. I'll try to catch a decent screenshot demonstrating this when I can. In the meantime, I've put a sample affected file up on my Dropbox account: https://dl.dropboxusercontent.com/u/3219541/harlock-ep20.mkv I'll re-attach here some mplayer/mpv logs, and some output from vdpauinfo and ffprobe; and I'll also attach output from glxinfo. If there's anything extra I ought to provide, please say so :)
Created attachment 89490 [details] Playback log from mplayer
Created attachment 89491 [details] Output from ffprobe
Created attachment 89492 [details] Output from vdpauinfo
Created attachment 89493 [details] Output from glxinfo
Also; was I right to have posted this in Drivers/Gallium/r600 as opposed to Drivers/DRI/R600 ?
(In reply to comment #5) > Also; was I right to have posted this in Drivers/Gallium/r600 as opposed to > Drivers/DRI/R600 ? Yes. Gallium/R600 is correct.
That's a known problem, but so far we didn't had any bugreport for it. Thanks for filling one in.
*** Bug 73457 has been marked as a duplicate of this bug. ***
*** Bug 77676 has been marked as a duplicate of this bug. ***
Hi! I also see the same behaviour. I tested it with mplayer -vo vdpau -vc ffodivxvdpau, using both vdpau decoder render and vdpau presentation functions. I tested it with vlc --avcodec-hw=vdpau, using decoder render and video surface get bits functions, and finally with gstreamer vaapidecode and vaapisink/ximagesink. (using radeonsi/uvd). All these cases have in common the use of the vdpau decoder render functions. Tested with upstream mesa/xorg, in a fedora 20 x86_64, [AMD/ATI] Cape Verde PRO [Radeon HD 7750 / R7 250E]. I made some traces at the libvdpau level (VDPAU_TRACE env vars), that I can provide if needed. They don't seem to present major differences between situations with and without corruption. I tried to serialize the vdpau calls with a mutex without more success, I played with the number of surfaces too, no difference. libefence didn't help. I have the feeling that some uninitialized stuff is passed to the hardware decoder, because I would say the problem probalistically happens more frequently after a fresh boot. The initial frame is _sometimes_ garbled with some bad colors (chroma planes ?), and this corruption progates to consecutive frames, due to the way mpeg compression works. I also have the feeling that this bug occurs more frequently with gstreamer-vaapi/vdpau-driver than vlc and mplayer, because of the multithreaded nature of gst, where decoding operation and rendering operations are less regularily scheduled : in gst, a burst of 4 or 5 vdpau decode render operations can happen on different surfaces, before the generated data is consumed by the vdpau presentation mode. Another way this problem occurs is by corrupting other parts of the display, not limited to the X11 window area where the rendering should happen, like small black rectangles appearing randomly on the screen. In another case, I noticed that part of my gnome-terminal transparent background looses some small rectangular areas that become "more" transparent than they should be.
Hi Fabrice! Back several months ago I submitted two bugs to this tracker. One was this one, in which I mention that MPEG-4 files which use ASP garble *every single playback* with VDPAU. The other was https://bugs.freedesktop.org/show_bug.cgi?id=73457, in which I mention that *all* MPEG-4 files have a *chance* of garbling with VDPAU. From the fact that you mention probabilities, and video corruption affecting the screen outside the video itself, it kind of sounds like you're describing the latter of those, and not the former (i.e. this bug). I don't want these two similar-but-separate issues to end up getting confused in the minds of the developers or testers. I've re-uploaded an affected ASP file to my Dropbox: https://dl.dropboxusercontent.com/u/3219541/samples/harlockep20-fine.mkv And note the minor garbling which occurs on 100% of playback attempts in a consistent manner, unlike the other bug for 'normal' MPEG-4 files in which the garbling is random and may not occur at all. (If anyone asks, I will upload a longer sample of the same file to the same Dropbox URL, to better demonstrate the issue) ~ Adam
(In reply to comment #11) > > From the fact that you mention probabilities, and video corruption affecting > the screen outside the video itself, it kind of sounds like you're > describing the latter of those, and not the former (i.e. this bug). I don't > want these two similar-but-separate issues to end up getting confused in the > minds of the developers or testers. Yes, you're completely right, what I observe exactly matches the other bug https://bugs.freedesktop.org/show_bug.cgi?id=73457 The jpeg screenshot is very clear about the problem. Thanks for the sample file BTW.
About this specific bug this time :) I see a deterministic corruption in your sample too, that seems related to the presence of sprite frames in the stream, and the result looks like these S frames are just ignored by the hardware decoder (they are correctly passed to the mesa level). For example, an effect of the corruption is the "C" of Captain, that is warped into something that looks like the euro symbol (€), around 22.5s. Is it similar to what you observe ? I can provide screenshot if needed. I tried with VDPAU on radeonsi/uvd, with nouveau, and also with the proprietary nvidia VDPAU implementation. _All_ implementations have this problem. The radeon and the nvidia driver just silently drop S frames, and the following non-S frames are corrupted. The nouveau driver replaces S frame by something that looks like the rendering of an unintialized vmem buffer. Also, I can reproduce the _same_ corruption with the ffmpeg software mpeg4 decoder, just by disabling the S-frames handling with this patch: diff -uNrp ffmpeg-2.1.5.orig/libavcodec/mpeg4videodec.c ffmpeg-2.1.5/libavcodec/mpeg4videodec.c --- ffmpeg-2.1.5.orig/libavcodec/mpeg4videodec.c 2014-07-21 20:43:58.550548835 +0200 +++ ffmpeg-2.1.5/libavcodec/mpeg4videodec.c 2014-07-21 20:43:11.632103072 +0200 @@ -2105,6 +2105,8 @@ static int decode_vop_header(MpegEncCont } if(s->pict_type == AV_PICTURE_TYPE_S && (s->vol_sprite_usage==STATIC_SPRITE || s->vol_sprite_usage==GMC_SPRITE)){ + printf("S frame\n"); + return AVERROR_INVALIDDATA; if (mpeg4_decode_sprite_trajectory(s, gb) < 0) return AVERROR_INVALIDDATA; if(s->sprite_brightness_change) av_log(s->avctx, AV_LOG_ERROR, "sprite_brightness_change not supported\n"); Are sprite frames supposed to be decoded by the hardware ? The radeon driver has a sprite-related section in its ruvd_mpeg4 struct definition in mesa/src/gallium/drivers/radeon/radeon_uvd.h.
Created attachment 103214 [details] Corrpution of C into € at 22.5s For the sake of completion, I can confirm the same corruption of a C into something like an € at around 22.5s, when playing the file with hardware decoding (`mpv --vo=opengl --hwdec=vdpau --hwdec-codecs=all`) on my AMD PALM unit with VDPAU. Current versions: mesa 10.2.3 xf86-video-ati 7.4.0 linux-ck 3.15.6 xorg-server 1.15.2
-- 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/470.
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.