Created attachment 91790 [details] mpv verbose log, when video decodes successfully This is somewhat difficult to explain. * AMD PALM E2-1800 APU * Arch Linux x86_64 * Kernel 3.12.6-ck (also with vanilla 3.12.6) * mesa 10.0.1, xf86-video-ati 7.2.0 One of the following three situations occurs, seemingly at random, when opening an mpeg4 video file using any player which supports vdpau hardware-decoding (e.g. mplayer r36498, VLC 2.1.2, mpv 0.3.2) 1. The video decodes and plays just fine 2. The video decodes incorrectly, with bright-green garbling, and general smearing 3. The video decodes and plays fine, BUT with a couple of small artefacts either in the player window, or anywhere on the screen (the artefacts are little black squares, inside which are a few fluorescent-coloured pixels flickering) The interesting point is that, on the same file, you can close and re-open the video player and receive a different random outcome each time. I'm in the habit of trying a few times to open my .avi videos until it "just works". This is not the same as the mpeg4 ASP garbling issue which I reported a month or so ago, which was 100% consistent on the affected files. For this bug, the files which display *this* problem are 'normal' mpeg4 videos, and whether or not decoding succeeds appears to be completely random. Frustratingly, neither the video player's verbose logs, nor the DPM messages in dmesg, indicate anything *at all* different between successful and unsuccessful attempts. I'll upload to this report a couple of log files, including the outputs of ffmpeg -i on a selection of affected files. I'll also upload some video samples, bear with me.
Created attachment 91791 [details] mpv verbose log, when output is garbled
Created attachment 91792 [details] example of garbled output
Created attachment 91793 [details] example of garbled output Whoops, forgot to set it as a jpeg first time
Created attachment 91794 [details] `ffmpeg -i` output on one affected file
Here are two trimmed file segments which behave in the curious way I've described. https://dl.dropboxusercontent.com/u/3219541/ppgz.avi https://dl.dropboxusercontent.com/u/3219541/zillion.avi Sometimes you have to be persistent; repeated attempts can be met with failure, and then the next time just *works*, so I'm pretty sure this isn't the fault of the files. Having another video playing using vdpau at the same time as trying to open an mpeg4 file doesn't seem to affect whether the issue occurs. It also occurs whether I'm on the laptop's LVDS screen, or over HDMI. Also, a clarification about the mpv logs. The logs were generated using vo_opengl, and hardware-decoding using vdpau uses the vdpau/opengl interop. However, the same behaviour does occur when using plain vo_vdpau, with a similar complete lack of difference between verbose logs generated.
Please attach your dmesg output and xorg log. If you have dpm enabled, does disabling it help?
Created attachment 91795 [details] dmesg output This is a whole swathe of dmesg output, to do with the power-level changes when using UVD. I know for a fact that *some* of these correspond to correct rendering cases. When checking dmesg immediately after a successful run, the most recent set of power messages was identical to the previous. I'll disable dpm and test further.
Created attachment 91796 [details] dmesg output (UVD lockup with dpm off) I can confirm that with dpm disabled, the problem persists. One interesting thing that occurred with dpm off, which didn't happen with it on, is that while repeatedly closing and opening a file for testing, at one point UVD appears to have totally locked up, seemingly requiring a reboot. The lockup persisted when closing and restarting X. Attached is the output in dmesg from when that happened.
Created attachment 91797 [details] xorg log (dpm off) Here's an X.org log, in this case with dpm off. Since it doesn't seem to contain any information related to actual attempts at video playback, do I particularly need to attach another log from a boot with dpm re-enabled?
(In reply to comment #9) > Here's an X.org log, in this case with dpm off. Since it doesn't seem to > contain any information related to actual attempts at video playback, do I > particularly need to attach another log from a boot with dpm re-enabled? No need for a separate xorg log for that case.
Created attachment 91798 [details] dmesg from bootup (dpm on) I realise I neglected to include any dmesg output from the first few seconds of bootup. In case you need that info as well, here it is.
*** This bug has been marked as a duplicate of bug 71812 ***
Sorry that was the wrong bug.
Hi! I observe the same problem too. The jpeg file of the garbled output is very similar to what I see. 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. It looks like there may be a cache warmness effect at play, because it seems to me that --even if the problem occurs mainly in a random way-- it can more easily be triggered after a fresh boot, than after a couple of retries on the same file. Also another feeling is that the bug is more easily triggered with gstreamer-vaapi + vdpau, than with mplayer or vlc, maybe because gst can burst a bunch of hw decoding operations on different surfaces before switching to the rendering thread ? vlc and mplayer invoke vdpau in a more *ordered* way. I also confirm point 3 of the initial reporter : the corruption may extend to artifacts appearing *outside* the player window.
Increasing the dpb_size value in src/gallium/drivers/radeon/radeon_uvd.c seems to be a workaround. I tested with dpb_size = dpb_size * 2, since a couple of hours, and I cannot reproduce the problem. max_references is set to 2 in my case, this is the default value of the vaapi-vdpau-driver for mpeg4 : defined in function get_num_ref_frames().
I can reproduce this very easily. I not sure when it actually started happening. Play a mpeg4/h264 file on VLC, the video most of the times starts correctly, a few times is just black, but when you try to seek the video there's always a the chance the video will start either displaying green artefacts or the video will glitching and jumping frames back and forth. You can just keep seeking until it resumes normally. Sometimes it also triggered by heavy disk/cpu activity, and you will get green artefacts this happens. Strangely enough, it doesn't happen with XBMC (though there are other bugs there). Tends to happen less often with recent updates, but the issue is still there. Ati HD4770 Arch Linux 3.15.5 Mesa 10.2.4 xf86-video-ati 7.4.0 VLC 2.1.5 XBMC 13.1
-- 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/481.
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.