GNOME Bugzilla – Bug 689113
No application-level method of flushing pipeline
Last modified: 2014-05-28 12:36:29 UTC
It's nearly impossible to flush the pipeline using higher-level method. There're several workarounds to do that mentioned in gst-mailing-list: http://gstreamer-devel.966125.n4.nabble.com/how-to-flush-a-gstreamer-pipeline-td2553146.html http://gstreamer-devel.966125.n4.nabble.com/Flush-RTSP-pipeline-td4655706.html But there's no single public 'pure' method for this functionality. Still it's obviously quite necessary action, especially when using dynamic pipelines or appsrc/appsink-based pipelines. Here's what absence of such functionality implies: - it's virtually impossible to clear data from internal queues in certain complex elements as appsrc or decodebin(2), which additionaly cannot be fully reduced (queue size of 0 usually means automatic control of queue size and not a zero size) - it's virtually impossible to flush data from non-seekable pipeline as the 'flushing-seek' workaround can't be used in this case - it's too hard to flush the whole pipeline and consequently to keep the timestamping logic intact as it's too hard to send the necessary events from the very upstream (i.e. some source elements). Here's some steps one should take to make a proper flush in her pipeline: 1. Send FLUSH_START and FLUSH_STOP events possibly from the very upstream element. 2. Create and send proper new-segment event as FLUSH_STOP event resets running-time of the pipeline. 3. Serialize (1) and (2) above with data flow so that fresh buffers won't go ahead of these events. 4. Look after the message bus. Probably that's not all of them. If something above is done wrong the pipeline usually get stalled or stops with error. Other than it's not that really application-level routines, another problem that arises is that some elements don't send events received with gst_element_send_event() downstream, so you should use (sink) pads which are absent in 'src' elements etc. etc. So I think it would be natural to make a high-level and well-tested method in, e.g. GstPipeline interface, to make the pipeline properly flushed to receive fresh data and present it in a seamless way.
I'm inclined to close this bug now. In 1.0 you can do a non-time-reset flush. You can push these events to the pipeline and most sources should forward them correctly.
Let's do that then. Alexey, please re-open with more information if there are still open issues with the 1.0 API.
Wim, Tim-Philipp, thank you very much for attention and answers. Yes, it needs to work some more with 1.0 API as I wrote concerning mainly 0.10 branch. Is it right to use gst_element_send_event to push such events to sources to have them sent downstream?
> Is it right to use gst_element_send_event to push such events to sources to > have them sent downstream? Yes. GstBins / the pipeline will send downstream events further down the bin hierarchy on the source side, while upstream events will get passed down the bin hierarchy on the sink side, until a real source or sink is found, which will then inject the event into the pipeline.
Hmm, is it true for 0.10 branch and flush events (as the only both up- and downstream ones)? I thought it's processed some different manner as I experimented with it lately and didn't manage to pick flush-start or flush-stop events sent to the pipeline on src pad of a queue inside it while events sent to some upstream pad were delivered.
I don't remember what happens for events that are both up and downstream, and especially not in 0.10, you'd have to check the code.
Yeah, I'll try to know it better. Thank you for detailed information!
For the record, because it came back on the mailing list and in case it wasn't clear, a pipeline can be flushed by operating a flushing seek. In 1.0, we can skip specifying start/stop and it should just flush. In 0.10, one would need to query the position. This bugs was obsolete from 0.10 point of view, and invalid for 1.0 and so on.
Yes, I agree. There were several reports on this issue, so this one I forgot about completely, sorry. Another solution is sending FLUSH_START and FLUSH_STOP to the pipeline, it works since 1.2 IIRC. I think I posted the code snippet some time before in the list.
Nicolas, sending flush start/stop to the pipeline should work just as well really (depending on the context), and it's been fixed up for cases where that makes sense.
Ok, sorry for the noise. I've just re-read that code, and it indeed changed a lot since last time (there was a warning there).