gstreamer/docs/design/part-seeking.txt

Seeking
-------

Seeking in GStreamer means configuring the pipeline for playback of the
media between a certain start and stop time, called the playback segment.
By default a pipeline will play from position 0 to the total duration of the
media at a rate of 1.0.

A seek is performed by sending a seek event to the sink elements of a
pipeline. Sending the seek event to a bin will by default forward
the event to all sinks in the bin.

When performing a seek, the start and stop values of the segment can be
specified as absolute positions or relative to the currently configured
playback segment. Note that it is not possible to seek relative to the current
playback position. To seek relative to the current playback position, one must
query the position first and then perform an absolute seek to the desired
position.

Feedback of the seek operation can be immediately using the GST_SEEK_FLAG_FLUSH
flag. With this flag, all pending data in the pipeline is discarded and playback
starts from the new position immediately.

When the FLUSH flag is not set, the seek will be queued and executed as
soon as possible, which might be after all queues are emptied.

Seeking can be performed in different formats such as time, frames
or samples.

The seeking can be performed to a nearby key unit or to the exact
(estimated) unit in the media (GST_SEEK_FLAG_KEY_UNIT). 

The seeking can be performed by using an estimated target position or in an
accurate way (GST_SEEK_FLAG_ACCURATE). For some formats this can result in
having to scan the complete file in order to accurately find the target unit.

Non segment seeking will make the pipeline emit EOS when the configured 
segment has been played.

Segment seeking (using the GST_SEEK_FLAG_SEGMENT) will not emit an EOS at
the end of the playback segment but will post a SEGMENT_DONE message on the
bus. This message is posted by the element driving the playback in the
pipeline, typically a demuxer.  After receiving the message, the application
can reconnect the pipeline or issue other seek events in the pipeline.
Since the message is posted as early as possible in the pipeline, the
application has some time to issue a new seek to make the transition seamless.
Typically the allowed delay is defined by the buffer sizes of the sinks as well
as the size of any queues in the pipeline.

The seek can also change the playback speed of the configured segment.
A speed of 1.0 is normal speed, 2.0 is double speed. Negative values
mean backward playback.

When performing a seek with a playback rate different from 1.0, the
GST_SEEK_FLAG_SKIP flag can be used to instruct decoders and demuxers that they
are allowed to skip decoding. This can be useful when resource consumption is
more important than accurately producing all frames.


Seeking in push based elements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






Generating seeking events
~~~~~~~~~~~~~~~~~~~~~~~~~

A seek event is created with gst_event_new_seek ().



Seeking variants
~~~~~~~~~~~~~~~~

The different kinds of seeking methods and their internal workings are
described below.


FLUSH seeking
^^^^^^^^^^^^^

This is the most common way of performing a seek in a playback application.
The application issues a seek on the pipeline and the new media is immediately
played after the seek call returns.


seeking without FLUSH
^^^^^^^^^^^^^^^^^^^^^

This seek type is typically performed after issuing segment seeks to finish
the playback of the pipeline.

Performing a non-flushing seek in a PAUSED pipeline blocks until the pipeline
is set to playing again since all data passing is blocked in the prerolled
sinks.


segment seeking with FLUSH
^^^^^^^^^^^^^^^^^^^^^^^^^^

This seek is typically performed when starting seamless looping.


segment seeking without FLUSH
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This seek is typically performed when continuing seamless looping.