mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-26 03:31:05 +00:00
Code Issues 1 Projects Releases Wiki Activity

docs/random/company/time: Add some docs about clocking and time

Browse source 
Original commit message from CVS:
2004-01-28  Benjamin Otte  <in7y118@public.uni-hamburg.de>

* docs/random/company/time:
Add some docs about clocking and time
This commit is contained in:
Benjamin Otte 2004-01-28 22:02:22 +00:00
parent 5263fa9402
commit 0d25cd2aa4
2 changed files with 44 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
ChangeLog
View file

@ -1,3 +1,8 @@
2004-01-28 Benjamin Otte <in7y118@public.uni-hamburg.de>
* docs/random/company/time:
Add some docs about clocking and time
2004-01-28 Julien MOUTTE <julien@moutte.net>
* docs/pwg/advanced-interfaces.xml: Adding XOverlay documentation.

39
docs/random/company/time Normal file
View file

@ -0,0 +1,39 @@
Time in Gstreamer
When talking about time in streams (or "clocking"), people often confuse 3
different things that need to be treated seperately. Older designs in GStreamer
confused those and this made it difficult to design solutions for time
management.
1) clock time
There are many clock providers in GStreamer. In normal circumstances there is
only one clock, commonly referred to as the system clock. But in the GStreamer
case there are others - like a sound card. If a sound card claims to output
44100 samples/sec, one second in the sound cards clock has elapsed when 44100
samples have been processed. If a webcam claims to deliver 25 pictures/sec a
second has elapsed after processing 25 pictures. This concept is useful in
starvation cases - when you use the clock of the sound card and due to high
load (or the hard disc of your laptop needing to start spinning again to read
in an mp3) no samples are processed, the clock does not advance. A system clock
would merrily go on ticking and make your song jump.
2) element time
Some elements need to know when to output a buffer. Therefore buffers have
timestamps. But there needs to be a way those timestamps to the time reported by
clocks. This is were element time comes in. GStreamer takes transparently care
of this by remembering at what clock time you set your element to PLAYING and
computes the time that has passed since then automatically. It takes care of the
PAUSE state, too. There is even a way to adjust the time in the case of a
discontinuity event (which most likely happens after seeking).
3) synchronization
It is a common case (especially in video playback) that people want to
synchronize two elements (audio and video output), so that they report the same
time. This is an unsolved problem in GStreamer and is only handled implicitly.
To aid in this, clocks have "clock events". An event happens when an element
does something, for example changing states. Because people want to set the
states of multiple elements at once, but computers serialize everything, the
actual state setting on the elements is serialized, too. If however such events
happen shortly after each other, GStreamer assumes they were meant to happen at
the same time and handles this as such.