GNOME Bugzilla – Bug 328487
mpegdemux loops infinitely with corrupt MPEG file
Last modified: 2009-03-06 09:18:56 UTC
Steps to reproduce: 1. type "touch zero.mpg" in order to have a zero-length file 2. launch the pipeline "gst-launch-0.10 filesrc location=zero.mpg ! mpegdemux .video_00 ! ffdec_mpeg2video ! xvimagesink" 3. all the threads get stuck Stack trace: Other information: I discovered this bug because I have some .mpg files whose first 4 bytes are 00 00 01 B3, and not 00 00 01 BA as real MPEG PS files should be. GStreamer does not play those, and this could be right (although FFmpeg and Windows Media Player do play them, so making GStreamer's MPEG demuxer more tolerant could be an option). However, what is unacceptable is that GStreamer never exits. Apparently, gst_packetize_read tries unsuccessfully to find the sequence 00 00 01 BA, at the end of the file it returns GST_FLOW_RESEND, and gst_mpeg_parse_chain returns GST_FLOW_OK. This happens for all non-MPEG files fed to the MPEG demuxer, not only with MPEG files starting with 00 00 01 B3: even with empty files or files made of all zeros
This could be related to bug #320084.
related to bug #320084. In this case an element was added to the pipeline (videosink) that will never preroll since nothing is connected to it. the proper way of creating a pipeline is to only add elements that are needed. We could post an error message in the source if the file has a length of 0. did not test the 000001ba cases yet.
> However, what is unacceptable is that GStreamer never exits. > Apparently, gst_packetize_read tries unsuccessfully to find > the sequence 00 00 01 BA, at the end of the file it returns > GST_FLOW_RESEND, and gst_mpeg_parse_chain returns GST_FLOW_OK. > This happens for all non-MPEG files fed to the MPEG demuxer, > not only with MPEG files starting with 00 00 01 B3: even with > empty files or files made of all zeros Any suggestions on what the best way to fix this is? Maybe the packetizer should count the number of bytes dropped since the last sync when trying to sync, and throw an error if it hasn't been able to find a sync for N bytes (and on receiving EOS if it hasn't found a single sync yet)? Maybe it should throw an error if the file doesn't start with a clean sync (or is that too much of an assumption to make?)?
In EOS, check if some stream was found, if not, post en error. This would handle the empty file and the no-sync cases. Not sure what the max sync-byte distance is in mpeg, should not be more than a few 100K
moved to normal, this applies to all demuxers.
Whether with hand-crafted launch lines (like in the initial report) or with playbin/playbin2 everything exits normally now with empty files. Closing bug.