Artifacts on MKV containers with mpeg4 video

[spam@…]

When trying to playback MKV videos containing mpeg4 video data MPlayer plays the video with a lot of artifacts since my package manager updated to the latest version.

$ mplayer
MPlayer SVN-r36285-4.8.0 (C) 2000-2013 MPlayer Team
205 audio & 424 video codecs
Usage: mplayer [options] [url|path/]filename

Attached is a test video (a few seconds from a DVBT source processed with Avidemux and rendered with mpeg4 as video codec, Vorbis as audio codec and MKV as container format according to Avidemux settings).

Videos with identical settings do not cause any problems in the previous version of MPlayer. It is not a problem of the video. I checked with older videos, too. The all seem to have the same problems but worked before.

Here’s the output of mplayer -identify for said test video:

$ mplayer -identify test.mkv
MPlayer SVN-r36285-4.8.0 (C) 2000-2013 MPlayer Team
205 audio & 424 video codecs

Playing test.mkv.
libavformat version 55.7.100 (internal)
libavformat file format detected.
ID_VIDEO_ID=0
[lavf] stream 0: video (mpeg4), -vid 0
ID_AUDIO_ID=0
[lavf] stream 1: audio (vorbis), -aid 0
VIDEO: [MP4V] 1024x576 0bpp 25.000 fps 0.0 kbps ( 0.0 kbyte/s)
Clip info:

title: Avidemux

ID_CLIP_INFO_NAME0=title
ID_CLIP_INFO_VALUE0=Avidemux

AUTHOR: Avidemux

ID_CLIP_INFO_NAME1=AUTHOR
ID_CLIP_INFO_VALUE1=Avidemux

ENCODER: Lavf53.24.0

ID_CLIP_INFO_NAME2=ENCODER
ID_CLIP_INFO_VALUE2=Lavf53.24.0
ID_CLIP_INFO_N=3
Load subtitles in ./
ID_FILENAME=test.mkv
ID_DEMUXER=lavfpref
ID_VIDEO_FORMAT=MP4V
ID_VIDEO_BITRATE=0
ID_VIDEO_WIDTH=1024
ID_VIDEO_HEIGHT=576
ID_VIDEO_FPS=25.000
ID_VIDEO_ASPECT=1.7778
ID_AUDIO_FORMAT=22127
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=48000
ID_AUDIO_NCH=2
ID_START_TIME=0.00
ID_LENGTH=13.92
ID_SEEKABLE=1
ID_CHAPTERS=0
Opening video filter: [screenshot]
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 55.12.100 (internal)
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
ID_VIDEO_CODEC=ffodivx
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, floatle, 0.0 kbit/0.00% (ratio: 0->384000)
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=48000
ID_AUDIO_NCH=2
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis)
==========================================================================
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
ID_AUDIO_CODEC=ffvorbis
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
ID_VIDEO_ASPECT=1.7778
[swscaler @ 0x7f8bf14ffa00]using unscaled yuv420p -> rgb24 special converter
VO: [vdpau] 1024x576 => 1024x576 Planar YV12
A: 0.1 V: 0.1 A-V: -0.001 ct: -0.000 0/ 0 ??% ??% ??,?% 0 0
[VD_FFMPEG] DRI failure.
A: 0.4 V: 0.4 A-V: -0.000 ct: -0.000 0/ 0 ??% ??% ??,?% 0 0

Exiting... (Quit)
ID_EXIT=QUIT

[spam@…]

Testing video that causes artifacts when played

[spam@…]

screen shot of said artifacts (converted to jpg because webserver reports 413 Request entity too large if i try to attach the original png)

[spam@…]

Further research: Downgrading to SVN-r35920-4.8.0 instantly fixes the problem. The test video and all other videos I tried are played without any problems. UIpgrading again to SVN-r35920-4.8.0 and bam: videos are played with artifacts again.

So it must have to do with the changes between SVN-r36285-4.8.0 and SVN-r35920-4.8.0.

[spam@…]

Still happens with SVN-r36285-4.8.1

switched to mplayer2, because obviously no-one cares about this bug.

[reimar]

Sorry that this was frustrating, I am afraid the mailing lists often result in a more prompt reply.
However, the main problem and why I ended up forgetting about it is that it is not reproducible for me.
The only thing suspicious is:

[swscaler @ 0x7f8bf14ffa00]using unscaled yuv420p -> rgb24 special converter
VO: [vdpau] 1024x576 => 1024x576 Planar YV12

Does it also happen when using e.g. gl instead of VDPAU?
Does "-noconfig all" change anything?
The artefacts don't look like anything typical, so that's not much help either.

[reimar]

Also, some people reported they needed "-noslices" now, but I think this was an FFmpeg issue that is fixed by now.

[spam@…]

I did som further testing and was able to track it down to vf=screenshot that is present in my config for reasons. vo=gl doesn’t have the problems either (but it’s not usable because it does not allow me to use geometry settings.

Because I want to keep vf=screenshot I stick with mplayer2.

[reimar]

Unfortunately
mplayer -noconfig all test.mkv -vf screenshot
Still works perfectly for me.
The first configuration that causes issues is:
mplayer -noconfig all test.mkv -slices -lavdopts threads=4 -vo gl
But that is expected and not a supported setup (unfortunately, and due to FFmpeg changes).
And what do you mean by:

but it’s not usable because it does not allow me to use geometry settings

VDPAU and gl use exactly the same code to handle -geometry, so they _should_ give exactly the same behaviour.

[spam@…]

VDPAU and gl use exactly the same code to handle -geometry,
so they _should_ give exactly the same behaviour.

Yes, they should. When using gl the video always is in the top left corner of the screen, without it’s centered as configured.

[reimar]

I could reproduce the issue with -vo vdpau. What is suspicious is that it indeed only happens with the combination vdpau+screenshot, xv, gl, ... are fine, and the usual options like -noslice do not help. So this is strange.
However in the mean time I think I fixed/hacked around the -geometry issue for -vo gl. I couldn't reproduce it (it should be specific to the window manager used) but I still expect r36403 to completely avoid the issue.

[reimar]

Surprisingly the issue was in the screenshot filter, it showed up with VDPAU only because that one lacked a specific feature the screenshot filter silently assumed to be available.
Issue is fixed for me in SVN r36403.

[reimar]

Sorry, I meant r36405 in that last comment.