mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-09-08 13:18:52 +00:00
Original commit message from CVS: * docs/manual/advanced-clocks.xml: * docs/manual/advanced-interfaces.xml: * docs/manual/advanced-metadata.xml: * docs/manual/advanced-position.xml: * docs/manual/advanced-schedulers.xml: * docs/manual/advanced-threads.xml: * docs/manual/appendix-porting.xml: * docs/manual/basics-bins.xml: * docs/manual/basics-bus.xml: * docs/manual/basics-elements.xml: * docs/manual/basics-helloworld.xml: * docs/manual/basics-pads.xml: * docs/manual/highlevel-components.xml: * docs/manual/manual.xml: * docs/manual/thread.fig: Update (until threads/scheduling) Application Development Manual; remove GstThread, add GstBus, add simple porting checklist, add documentation for tag writing, clocks, make all examples until this part compile and run. * examples/manual/Makefile.am: Update from changes to Application Development Manual; add bus example, remove thread example.
63 lines
3 KiB
XML
63 lines
3 KiB
XML
<chapter id="chapter-clocks">
|
|
<title>Clocks in GStreamer</title>
|
|
|
|
<para>
|
|
To maintain sync in pipeline playback (which is the only case where this
|
|
really matters), &GStreamer; uses <emphasis>clocks</emphasis>. Clocks
|
|
are exposed by some elements, whereas other elements are merely clock
|
|
slaves. The primary task of a clock is to represent the time progress
|
|
according to the element exposing the clock, based on its own playback
|
|
rate. If no clock provider is available in a pipeline, the system clock
|
|
is used instead.
|
|
</para>
|
|
|
|
<sect1 id="section-clocks-providers">
|
|
<title>Clock providers</title>
|
|
|
|
<para>
|
|
Clock providers exist because they play back media at some rate, and
|
|
this rate is not necessarily the same as the system clock rate. For
|
|
example, a soundcard may playback at 44,1 kHz, but that doesn't mean
|
|
that after <emphasis>exactly</emphasis> 1 second <emphasis>according
|
|
to the system clock</emphasis>, the soundcard has played back 44.100
|
|
samples. This is only true by approximation. Therefore, generally,
|
|
pipelines with an audio output use the audiosink as clock provider.
|
|
This ensures that one second of video will be played back at the same
|
|
rate as that the soundcard plays back 1 second of audio.
|
|
</para>
|
|
<para>
|
|
Whenever some part of the pipeline requires to know the current clock
|
|
time, it will be requested from the clock through
|
|
<function>gst_clock_get_time ()</function>. The clock-time does not
|
|
need to start at 0. The pipeline, which contains the global clock that
|
|
all elements in the pipeline will use, in addition has a <quote>base
|
|
time</quote>, which is the clock time at the the point where media time
|
|
is starting from zero. This timestamp is subctracted from the clock
|
|
time, and that value is returned by <function>_get_time ()</function>.
|
|
</para>
|
|
<para>
|
|
The clock provider is responsible for making sure that the clock time
|
|
always represents the current media time as closely as possible; it
|
|
has to take care of things such as playback latencies, buffering in
|
|
audio-kernel modules, and so on, since all those could affect a/v sync
|
|
and thus decrease the user experience.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="section-clocks-slaves">
|
|
<title>Clock slaves</title>
|
|
<para>
|
|
Clock slaves get assigned a clock by their containing pipeline. Their
|
|
task is to make sure that media playback follows the time progress as
|
|
represented by this clock as closely as possible. For most elements,
|
|
that will simply mean to wait until a certain time is reached before
|
|
playing back their current sample; this can be done with the function
|
|
<function>gst_clock_id_wait ()</function>. Some elements may need to
|
|
support dropping samples too, however.
|
|
</para>
|
|
<para>
|
|
For more information on how to write elements that conform to this
|
|
required behaviour, see the Plugin Writer's Guide.
|
|
</para>
|
|
</sect1>
|
|
</chapter>
|