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 625470 - mpeg decoding pipeline blocks on preroll
mpeg decoding pipeline blocks on preroll
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: dont know
unspecified
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-07-28 08:18 UTC by Vladimir Eremeev
Modified: 2012-02-18 16:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vladimir Eremeev 2010-07-28 08:18:51 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
Comment 1 Tim-Philipp Müller 2010-08-14 19:27:22 UTC
So, umm, don't specify arbitrary max. queue sizes?

Does this work:

  gst-launch-0.10 playbin2 uri=file:///path/to/file.mpg

?
Comment 2 Vladimir Eremeev 2010-08-16 06:27:20 UTC
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. :)
Comment 3 Jan Schmidt 2010-10-27 11:18:42 UTC
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.
Comment 4 Vladimir Eremeev 2010-10-27 11:47:40 UTC
The point is that the specified queue sizes were not arbitrary, they were taken from playbin2.
Comment 5 Jan Schmidt 2010-10-27 12:19:53 UTC
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.
Comment 6 Tobias Mueller 2011-02-11 12:32:29 UTC
Reopening as the information requested in comment #1 has been provided.
Comment 7 Tim-Philipp Müller 2012-02-18 16:50:48 UTC
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)