GStreamer uses a global clock to synchronize the plugins in a pipeline.
Different clock implementations are possible by implementing this abstract
base class or, more conveniently, by subclassing #GstSystemClock.
The #GstClock returns a monotonically increasing time with the method
gst.clock.Clock.getTime. Its accuracy and base time depend on the specific
clock implementation but time is always expressed in nanoseconds. Since the
baseline of the clock is undefined, the clock time returned is not
meaningful in itself, what matters are the deltas between two clock times.
The time returned by a clock is called the absolute time.
The pipeline uses the clock to calculate the running time. Usually all
renderers synchronize to the global clock using the buffer timestamps, the
#GST_EVENT_SEGMENT events and the element's base time, see #GstPipeline.
A clock implementation can support periodic and single shot clock
notifications both synchronous and asynchronous.
To perform a blocking wait for the specific time of the #GstClockID use
gst.clock.Clock.idWait. To receive a callback when the specific time is reached
in the clock use gst.clock.Clock.idWaitAsync. Both these calls can be
interrupted with the gst.clock.Clock.idUnschedule call. If the blocking wait is
unscheduled a return value of #GST_CLOCK_UNSCHEDULED is returned.
Periodic callbacks scheduled async will be repeatedly called automatically
until they are unscheduled. To schedule a sync periodic callback,
gst.clock.Clock.idWait should be called repeatedly.
The async callbacks can happen from any thread, either provided by the core
or from a streaming thread. The application should be prepared for this.
A #GstClockID that has been unscheduled cannot be used again for any wait
operation, a new #GstClockID should be created and the old unscheduled one
should be destroyed with gst.clock.Clock.idUnref.
It is possible to perform a blocking wait on the same #GstClockID from
multiple threads. However, registering the same #GstClockID for multiple
async notifications is not possible, the callback will only be called for
the thread registering the entry last.
None of the wait operations unref the #GstClockID, the owner is responsible
for unreffing the ids itself. This holds for both periodic and single shot
notifications. The reason being that the owner of the #GstClockID has to
keep a handle to the #GstClockID to unblock the wait on FLUSHING events or
state changes and if the entry would be unreffed automatically, the handle
might become invalid without any notification.
These clock operations do not operate on the running time, so the callbacks
will also occur when not in PLAYING state as if the clock just keeps on
running. Some clocks however do not progress when the element that provided
the clock is not PLAYING.
When a clock has the #GST_CLOCK_FLAG_CAN_SET_MASTER flag set, it can be
slaved to another #GstClock with gst.clock.Clock.setMaster. The clock will
then automatically be synchronized to this master clock by repeatedly
sampling the master clock and the slave clock and recalibrating the slave
clock with gst.clock.Clock.setCalibration. This feature is mostly useful for
plugins that have an internal clock but must operate with another clock
selected by the #GstPipeline. They can track the offset and rate difference
of their internal clock relative to the master clock by using the
gst.clock.Clock.getCalibration function.
The master/slave synchronisation can be tuned with the #GstClock:timeout,
#GstClock:window-size and #GstClock:window-threshold properties.
The #GstClock:timeout property defines the interval to sample the master
clock and run the calibration functions. #GstClock:window-size defines the
number of samples to use when calibrating and #GstClock:window-threshold
defines the minimum number of samples before the calibration is performed.
GStreamer uses a global clock to synchronize the plugins in a pipeline. Different clock implementations are possible by implementing this abstract base class or, more conveniently, by subclassing #GstSystemClock.
The #GstClock returns a monotonically increasing time with the method gst.clock.Clock.getTime. Its accuracy and base time depend on the specific clock implementation but time is always expressed in nanoseconds. Since the baseline of the clock is undefined, the clock time returned is not meaningful in itself, what matters are the deltas between two clock times. The time returned by a clock is called the absolute time.
The pipeline uses the clock to calculate the running time. Usually all renderers synchronize to the global clock using the buffer timestamps, the #GST_EVENT_SEGMENT events and the element's base time, see #GstPipeline.
A clock implementation can support periodic and single shot clock notifications both synchronous and asynchronous.
One first needs to create a #GstClockID for the periodic or single shot notification using gst.clock.Clock.newSingleShotId or gst.clock.Clock.newPeriodicId.
To perform a blocking wait for the specific time of the #GstClockID use gst.clock.Clock.idWait. To receive a callback when the specific time is reached in the clock use gst.clock.Clock.idWaitAsync. Both these calls can be interrupted with the gst.clock.Clock.idUnschedule call. If the blocking wait is unscheduled a return value of #GST_CLOCK_UNSCHEDULED is returned.
Periodic callbacks scheduled async will be repeatedly called automatically until they are unscheduled. To schedule a sync periodic callback, gst.clock.Clock.idWait should be called repeatedly.
The async callbacks can happen from any thread, either provided by the core or from a streaming thread. The application should be prepared for this.
A #GstClockID that has been unscheduled cannot be used again for any wait operation, a new #GstClockID should be created and the old unscheduled one should be destroyed with gst.clock.Clock.idUnref.
It is possible to perform a blocking wait on the same #GstClockID from multiple threads. However, registering the same #GstClockID for multiple async notifications is not possible, the callback will only be called for the thread registering the entry last.
None of the wait operations unref the #GstClockID, the owner is responsible for unreffing the ids itself. This holds for both periodic and single shot notifications. The reason being that the owner of the #GstClockID has to keep a handle to the #GstClockID to unblock the wait on FLUSHING events or state changes and if the entry would be unreffed automatically, the handle might become invalid without any notification.
These clock operations do not operate on the running time, so the callbacks will also occur when not in PLAYING state as if the clock just keeps on running. Some clocks however do not progress when the element that provided the clock is not PLAYING.
When a clock has the #GST_CLOCK_FLAG_CAN_SET_MASTER flag set, it can be slaved to another #GstClock with gst.clock.Clock.setMaster. The clock will then automatically be synchronized to this master clock by repeatedly sampling the master clock and the slave clock and recalibrating the slave clock with gst.clock.Clock.setCalibration. This feature is mostly useful for plugins that have an internal clock but must operate with another clock selected by the #GstPipeline. They can track the offset and rate difference of their internal clock relative to the master clock by using the gst.clock.Clock.getCalibration function.
The master/slave synchronisation can be tuned with the #GstClock:timeout, #GstClock:window-size and #GstClock:window-threshold properties. The #GstClock:timeout property defines the interval to sample the master clock and run the calibration functions. #GstClock:window-size defines the number of samples to use when calibrating and #GstClock:window-threshold defines the minimum number of samples before the calibration is performed.