Fill test disk partitions with random noise to expose more bugs.

[dcpomatic.git] / doc / design / timing.tex

diff --git a/doc/design/timing.tex b/doc/design/timing.tex
index d71b48f23e231890f96d86214326ed248d7ad63b..6cd1ca6891c8dcd7126fd9a642e30b1c067014a0 100644 (file)
--- a/doc/design/timing.tex
+++ b/doc/design/timing.tex
@@ -8,7 +8,8 @@ We are trying to implement full-ish playlist based content specification.  The t
 Frame rates of things can vary a lot; content can be in pretty much
 anything, and DCP video and audio frame rates may change on a whim
 depending on what is best for a given set of content.  This suggests
 Frame rates of things can vary a lot; content can be in pretty much
 anything, and DCP video and audio frame rates may change on a whim
 depending on what is best for a given set of content.  This suggests

-(albeit without strong justification) the need for a frame-rate-independent unit of time.
+(albeit without strong justification) the need for a
+frame-rate-independent unit of time.

 
 So far we've been using a time type called \texttt{Time} expressed in
 $\mathtt{TIME\_HZ}^{-1}$; e.g. \texttt{TIME\_HZ} units is 1 second.
 
 So far we've been using a time type called \texttt{Time} expressed in
 $\mathtt{TIME\_HZ}^{-1}$; e.g. \texttt{TIME\_HZ} units is 1 second.


@@ -61,7 +62,7 @@ I've been trying for a while with \texttt{Time} as a wall-clock
 
 I think this is the cause of content being overlapped in this case.
 
 
 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
+It is tempting to solve this by making Time a subdivision 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
 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


@@ -74,4 +75,20 @@ 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.
 
 On the plus side, lengths in \texttt{Time} are computed on-demand from
 lengths kept as source frames.
 

+
+\section{More musings}
+
+In version 2 things we changed, and a problem appeared.  We have / had
+\texttt{ContentTime} which is a metric time type, and it is used to
+describe video content length (amongst other things).  However if we
+load a set of TIFFs and then change the frame rate we don't have the
+length in frames i order to work out the new rate.
+
+This suggests that the content lengths, at least, should be described
+in frames.  Then to get metric lengths you would need to specify a
+timecode.
+
+I will probably have to try a frame-based ContentTime and see what
+problems arise.
+

 \end{document}
 \end{document}