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

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

diff --git a/ChangeLog b/ChangeLog
index 63a0821..f8b3c86 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -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.

diff --git a/docs/random/company/time b/docs/random/company/time
new file mode 100644 (file)
index 0000000..0fe9cff
--- /dev/null
+++ b/docs/random/company/time
@@ -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.
+