[Bug 689113] New: No application-level method of flushing pipeline

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=689113
  GStreamer | gstreamer (core) | 0.10.36

           Summary: No application-level method of flushing pipeline
    Classification: Platform
           Product: GStreamer
           Version: 0.10.36
        OS/Version: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: 4ernov at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.