GNOME Bugzilla – Bug 685709
mpeg4videoparse: AVI file with XVID video doesn't want to preroll: p_length.avi
Last modified: 2012-10-09 13:21:37 UTC
http://people.gnome.org/~hadess/p_length.avi $ gst-launch-1.0 playbin uri=file:///home/data/test-files/movies/p_length.avi Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpeg4VParse:mpeg4vparse0: No valid frames found before end of stream Additional debug info: gstbaseparse.c(1061): gst_base_parse_sink_default (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpeg4VParse:mpeg4vparse0 ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ...
This might have to do with the video/x-xvid => video/mpeg,mpegversion=4 change, in 0.10 mpeg4videoparse doesn't get plugged in this case. It works fine if mpeg4videoparse is not plugged (after 'make clean' in -bad/gst/videoparsers). Moving to mpeg4videoparse for now.
This is indeed due to mpeg4videoparse but also to the video stream in question which does not contain any config data. And mpeg4videoparse by default drops frames until it has valid config data (configurable with drop property), the latter default behaviour stemming all the way back from bug #532723. Given that avdec_mpeg4 still seems to manage without config that may or may not be the best default behaviour (and not consistent across parsers so it seems).
Is it possible that the config data is packed differently into AVI streams in this case (XVID fourcc), perhaps in-stream instead of codec data or vice versa?
Looks like there is enough data to make up config data after all, but that mpeg4videoparse is missing that now due to a regression introduced in patches from bug #683254.
commit 8596e8d5daeb49e438c9e1be838f205bf8f227b7 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Oct 9 13:53:19 2012 +0200 mpeg4videoparse: properly mark config data presence ... which we allow to start at VisualObjectSequence or at VideoObject. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=685709
Works for me, thanks.