GNOME Bugzilla – Bug 322927
gst_element_seek pauses simple pipeline
Last modified: 2006-03-01 14:18:48 UTC
The pipeline consists of filesrc, mpegdemux, and fakesink for each pad created by mpegdemux. The pipeline is in PLAYING state. When I call gst_element_seek with element = pipeline and flags = GST_SEEK_FLAG_FLUSH, the pipeline stops forever. The function do_pipeline seek changes the state to PAUSED before sending the event and changes the state to PLAYING again. That's OK. But when the fake sinks get the flush event they call gst_element_lost_state which sets pending = current state (= PAUSED) and return value to async. The pipeline sets these values accordingly. Then the pending state is set to PLAYING. But the current state of the pipeline is never set to PLAYING, its state remains in the PAUSED->PLAYING transition.
Created attachment 55477 [details] Test program
I seem to be experiencing this also https://launchpad.net/distros/ubuntu/+source/totem/+bug/3998
I don't think the ubuntu launchpad bug is the same. Totem in ubuntu was still using GStreamer 0.8 back then, whereas this was a 0.10 bug, and seems to work now. mpegdemux has received quite a few fixes since then. Josef, is this still a problem?
not adding queues after the demuxer will cause preroll to fail, which will cause the pipeline to refuse to go to PLAYING. closing.
Yes, it works with queues after demuxer. Thanks for hint!