GNOME Bugzilla – Bug 591919
mpeg2dec doesn't handle pixel-aspect-ratio change
Last modified: 2011-08-18 14:08:21 UTC
Created attachment 140851 [details] cropped log showing steps leading up to error I have a couple of DVDs that seem to change the pixel-aspect-ratio (as reported by mpeg2dec) whilst playing. It changes the pixel-aspect-ratio from 256/135 to 64/45 and always produces a not-negotiated error. What seems to happen is that the new caps are set on the src pad and a buffer is allocated with the new caps. But the buffer that is actually pushed to the pad (in function handle_slice()) still has the original pixel-aspect-ratio for some reason!? The pad picks up the discrepancy between the caps it has been set and the caps of the buffer and attempts to set the caps on the pad to match the buffer... which fails (because the pad has fixed caps?). Setting the src pad as non-fixed seems to hack around it and allow the playback to continue normally, but I'm sure there is some root cause that must be fixed instead. Partial log from the following pipeline is attached: gst-launch-0.10 dvdreadsrc device=DONNIE_DARKO.iso title=2 ! dvddemux name=dvd dvd.current_video ! queue ! mpeg2dec ! progressreport update-freq=1 ! fakesink --gst-debug=GST_CAPS:4,GST_PADS:4,mpeg2dec:4
Which versions of gstreamer, gst-plugins-base and gst-plugins-ugly do you use? Also, could you provide a short sample file that shows this behaviour, for example the seconds around the PAR-switch on this DVD. From looking at the code there seems to be nothing obvious that is wrong.
Sorry, should have included that in the original report: gstreamer-0.10.24 gst-plugins-base-0.10.24 gst-plugins-ugly-0.10.12 libmpeg2-0.5.1 You prompted me to actually check the 0.10.10 and 0.10.11 versions of the mpeg2dec plugin for similar behaviour: 0.10.10 - doesn't crash, but picture is very blocky at the point it usually crashes 0.10.11 - crashes with same not-negotiated error So, it seems this may be a regression. Incidentally, applying the hack I mentioned (removing gst_pad_use_fixed_caps() for the mpeg2dec srcpad) plays the same section smoothly without blocky-ness! Sample file incoming (if bugzilla lets me attach a 6.6M file).
File was too large for bugzilla so I had to upload it elsewhere, hopefully this link works: http://www.mediafire.com/?vndvi5nq2jp
Works fine with latest GIT of gst-plugins-ugly but I also see the PAR change. Can you confirm? The _use_fixed_caps() call is still there but it works for me, and gst_pad_use_fixed_caps() shouldn't break this anyway ;)
Hmm, no luck with latest Git, I built gstreamer, gst-plugins-base and -ugly but still see the same behaviour. Which version of libmpeg2 are you using? I ask because I did try downgrading libmpeg2 to 0.4.1 (from 0.5.1) and hey presto, the problem has completely resolved itself! So, it seems to be some issue with using v0.5.x of libmpeg2. The notes on http://libmpeg2.sourceforge.net do indicate that the way libmpeg2 deals with aspect ratio changes has changed in v0.5.
Created attachment 151032 [details] Little helper app, that prints out buffer caps for monitoring the aspect ratio
I got a similar problem while playing recorded DVB-T streams from VDR. The aspect ratio gets changed when advertisement gets faded in within the video stream. But gstreamer based applications do not react to the aspect ratio changes. This issue occured while developing a custom application using gstreamer and it could be reproduced playing the same stream with Totem. This is my testing environemnt: totem 2.28.2-0ubuntu3 gstreamer0.10-x 0.10.25-2ubuntu1.2 Since this is an MPEG stream, i see the following options for decoding the video: gstreamer0.10-plugins-ugly_0.10.12-1 with libmpeg2-4_0.4.1-3 or gstreamer0.10-ffmpeg_0.10.9-1 The problem occured with both options, while the aspect ratio switched correctly when playing the video with mplayer. The attached file prints out the buffer caps including the pixel aspect ratio. The aspect ratio has always the same value, depending on which aspect ratio occured first.
Reopening as I think the requested information has been provided
I just tested the current state of my original problem and it seems that things no longer crash when using mpeg2dec compiled against libmpeg-0.5.1, but checking the logs shows that no actual aspect ratio change is reported (as Manuel stated above). There is a sample on the MPlayer website that I believe should have an aspect-ratio change but, again, none is reported when playing with GStreamer: http://samples.mplayerhq.hu/MPEG2/res_change_ffmpeg_aspect.ts Could this be an issue with mpegvideoparse rather than mpeg2dec, both elements seem to be used by the playbin when constructing the pipeline?
So does everything work fine now?
Thomas, manuel.weichselbaumer, Can you please confirm the bug against latest stable release of Gstreamer ? If things work fine, the bug can be closed.
The res_change_ffmpeg_aspect.ts file properly switches PAR.... ... but for some reason the first PAR seems excessively wrong (45/11). Not sure if we should consider this as the same problem initially reported or as a new one.
I read the comments as if this particular issue is OBSOLETE by now. Please open new bugs for new issues.