GNOME Bugzilla – Bug 625470
mpeg decoding pipeline blocks on preroll
Last modified: 2012-02-18 16:50:48 UTC
filesrc location="any MPEG2-PS file" ! typefind ! mpegpsdemux name=demux multiqueue max-size-bytes=2097152 name=mq demux.audio_c0 ! mq.sink0 mq.src0 ! mp3parse ! flump3dec ! input-selector ! tee ! queue ! audioconvert ! audioresample ! pulsesink demux.video_e0 ! mq.sink1 mq.src1 ! mpegvideoparse ! mpeg2dec ! input-selector ! queue max-size-buffers=3 max-size-bytes=0 max-size-time=0 ! ffmpegcolorspace ! videoscale ! xvimagesink The respective FAQ item doesn't work, as my pipeline has several queues. When this pipeline is loaded in the seek example ($GST_PLUGINS_BASE/tests/examples/seek/seek.c), it begins playing after seeking. When this pipeline is launched in gst-launch, I see only "The pipeline is prerolling" message and nothing happens. Tried this both on windows and linux, with the latest GStreamer-Winbuilds and latest packages from GStreamer-developers PPA. Also tried various audio and video sinks. The images of this pipeline follow: DOT (30kb): http://gstreamer-devel.966125.n4.nabble.com/file/n2297314/player.dot PNG (850kb): http://gstreamer-devel.966125.n4.nabble.com/file/n2297314/player.png
So, umm, don't specify arbitrary max. queue sizes? Does this work: gst-launch-0.10 playbin2 uri=file:///path/to/file.mpg ?
Yes, playbin2 plays the file. I had problems with the reverse playback in some MPEG2 files (bug #619204) and tried to find the source of them. In order to find the element which causes bugs in reverse playback, I tried to mimic playbin2 behavior. First, I've created a simple pipeline then added elements one by one and ended with this gst-launch command. It seems, however, I've missed the buggy element anyway. But have found another problem. :)
I agree with Tim - the most likely reason your pipeline is stalling is that you've made the multiqueue too small, so either the video or audio chain fills the multiqueue before the other chain gets a buffer. It works when you seek because you happen to get some buffers through to both decoders to kick the pipeline off.
The point is that the specified queue sizes were not arbitrary, they were taken from playbin2.
decodebin2 manages the queue size: Until it prerolls the group, it will allow it to grow larger, then it shrinks it again once the pads are exposed.
Reopening as the information requested in comment #1 has been provided.
As I understand it, the actual issue here has to do with the queue limits being too restrictive, so closing as INVALID. Please re-open if this is not the case and I'm missing something. (e.g. if it still doesn't work with all queue limits unset)