<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Events: seeking (and more)</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79;charset=UTF-8"><LINK
REL="HOME"
TITLE="GStreamer Application Development Manual (0.10.36)"
HREF="index.html"><LINK
REL="UP"
TITLE="Position tracking and seeking"
HREF="chapter-queryevents.html"><LINK
REL="PREVIOUS"
TITLE="Position tracking and seeking"
HREF="chapter-queryevents.html"><LINK
REL="NEXT"
TITLE="Metadata"
HREF="chapter-metadata.html"></HEAD
><BODY
CLASS="sect1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
><SPAN
CLASS="application"
>GStreamer</SPAN
> Application Development Manual (0.10.36)</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="chapter-queryevents.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 11. Position tracking and seeking</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="chapter-metadata.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="section-eventsseek"
>11.2. Events: seeking (and more)</A
></H1
><P
> Events work in a very similar way as queries. Dispatching, for
example, works exactly the same for events (and also has the same
limitations), and they can similarly be sent to the toplevel pipeline
and it will figure out everything for you. Although there are more
ways in which applications and elements can interact using events,
we will only focus on seeking here. This is done using the seek-event.
A seek-event contains a playback rate, a seek offset format (which is
the unit of the offsets to follow, e.g. time, audio samples, video
frames or bytes), optionally a set of seeking-related flags (e.g.
whether internal buffers should be flushed), a seek method (which
indicates relative to what the offset was given), and seek offsets.
The first offset (cur) is the new position to seek to, while
the second offset (stop) is optional and specifies a position where
streaming is supposed to stop. Usually it is fine to just specify
GST_SEEK_TYPE_NONE and -1 as end_method and end offset. The behaviour
of a seek is also wrapped in the <CODE
CLASS="function"
>gst_element_seek ()</CODE
>.
</P
><PRE
CLASS="programlisting"
> static void
seek_to_time (GstElement *pipeline,
gint64 time_nanoseconds)
{
if (!gst_element_seek (pipeline, 1.0, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH,
GST_SEEK_TYPE_SET, time_nanoseconds,
GST_SEEK_TYPE_NONE, GST_CLOCK_TIME_NONE)) {
g_print ("Seek failed!\n");
}
}
</PRE
><P
> Seeks with the GST_SEEK_FLAG_FLUSH should be done when the pipeline is
in PAUSED or PLAYING state. The pipeline will automatically go to preroll
state until the new data after the seek will cause the pipeline to preroll
again. After the pipeline is prerolled, it will go back to the state
(PAUSED or PLAYING) it was in when the seek was executed. You can wait
(blocking) for the seek to complete with
<CODE
CLASS="function"
>gst_element_get_state()</CODE
> or by waiting for the
ASYNC_DONE message to appear on the bus.
</P
><P
> Seeks without the GST_SEEK_FLAG_FLUSH should only be done when the
pipeline is in the PLAYING state. Executing a non-flushing seek in the
PAUSED state might deadlock because the pipeline streaming threads might
be blocked in the sinks.
</P
><P
> It is important to realise that seeks will not happen instantly in the
sense that they are finished when the function
<CODE
CLASS="function"
>gst_element_seek ()</CODE
> returns. Depending on the
specific elements involved, the actual seeking might be done later in
another thread (the streaming thread), and it might take a short time
until buffers from the new seek position will reach downstream elements
such as sinks (if the seek was non-flushing then it might take a bit
longer).
</P
><P
> It is possible to do multiple seeks in short time-intervals, such as
a direct response to slider movement. After a seek, internally, the
pipeline will be paused (if it was playing), the position will be
re-set internally, the demuxers and decoders will decode from the new
position onwards and this will continue until all sinks have data
again. If it was playing originally, it will be set to playing again,
too. Since the new position is immediately available in a video output,
you will see the new frame, even if your pipeline is not in the playing
state.
</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="chapter-queryevents.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="chapter-metadata.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Position tracking and seeking</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="chapter-queryevents.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Metadata</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
