X-Git-Url: https://git.carlh.net/gitweb/?a=blobdiff_plain;f=doc%2Fdesign%2Ftiming.tex;h=6cd1ca6891c8dcd7126fd9a642e30b1c067014a0;hb=b0463c6c22d51f6297eea313b429348c3bec3971;hp=d71b48f23e231890f96d86214326ed248d7ad63b;hpb=8cad55c5de6ef3b9692800517040bd32e844f46d;p=dcpomatic.git

diff --git a/doc/design/timing.tex b/doc/design/timing.tex
index d71b48f23..6cd1ca689 100644
--- 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
-(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.
@@ -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.
 
-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
@@ -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.
 
+
+\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}