After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 685709 - mpeg4videoparse: AVI file with XVID video doesn't want to preroll: p_length.avi
mpeg4videoparse: AVI file with XVID video doesn't want to preroll: p_length.avi
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.0.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-10-08 10:33 UTC by Bastien Nocera
Modified: 2012-10-09 13:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Bastien Nocera 2012-10-08 10:33:34 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 ...
Comment 1 Tim-Philipp Müller 2012-10-08 10:44:26 UTC 
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.
Comment 2 Mark Nauwelaerts 2012-10-09 10:18:59 UTC 
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).
Comment 3 Tim-Philipp Müller 2012-10-09 10:30:20 UTC 
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?
Comment 4 Mark Nauwelaerts 2012-10-09 11:24:22 UTC 
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.
Comment 5 Mark Nauwelaerts 2012-10-09 12:29:16 UTC 
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
Comment 6 Bastien Nocera 2012-10-09 13:21:37 UTC 
Works for me, thanks.