Some notes on timing.

diff --git a/doc/design/timing.tex b/doc/design/timing.tex
index 567ba024fbd7fae77aa2015747e76b71d076682b..45252ea3633db95534a7df53011446d5dc1c194c 100644 (file)
--- a/doc/design/timing.tex
+++ b/doc/design/timing.tex
@@ -38,5 +38,34 @@ as you really need one resampler per source.  So it might make more sense
 to put stuff in the decoder.  But then, what's one map of resamplers between friends?
 
 
 to put stuff in the decoder.  But then, what's one map of resamplers between friends?
 
 

+\section{Options for what \texttt{Time} is a function of}
+
+I've been trying for a while with \texttt{Time} as a wall-clock
+`real-time' unit.  This means that the following is tricky:
+
+\begin{enumerate}
+\item Add content at 29.97 fps
+\item Length of this content is converted to \texttt{Time} using the
+  current DCP frame rate (which will be 29.97).
+\item Add more content at 25 fps.
+\item This causes the DCP frame rate to be changed to 25 fps, and so
+  the first piece of content is now being run slower and so its length
+  changes.
+\end{enumerate}
+
+I think this is the cause of content being overlapped in this case.
+
+It is tempting to solve this by making Time a subdivsion of DCP video
+frame rate.  This makes things nicer in many ways; you get a 1:1
+mapping of content video frames to Time in most cases, but not when
+video frames are skipped to halve the frame rate, say.  In this case
+you could have a piece of content at 50 fps which is some time $T$
+long at at DCP rate of 50 fps, but half as long at a DCP rate of 25 fps.
+
+I'm fairly sure that there is inherently not a nice representation which
+will obviate the need for things to be recalculated when DCP rate changes.
+
+On the plus side, lengths in \texttt{Time} are computed on-demand from
+lengths kept as source frames.

 
 \end{document}
 
 \end{document}