To maintain sync in pipeline playback (which is the only case where this really matters), GStreamer uses clocks. 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.
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 exactly 1 second according to the system clock, 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.
Whenever some part of the pipeline requires to know the current clock
time, it will be requested from the clock through
gst_clock_get_time (). 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 "base
time", 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
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.