doc/design/timing.tex

   1 \documentclass{article}
   2 \begin{document}
   3
   4 We are trying to implement full-ish playlist based content specification.  The timing is awkward.
   5
   6 \section{Reference timing}
   7
   8 Frame rates of things can vary a lot; content can be in pretty much
   9 anything, and DCP video and audio frame rates may change on a whim
  10 depending on what is best for a given set of content.  This suggests
  11 (albeit without strong justification) the need for a
  12 frame-rate-independent unit of time.
  13
  14 So far we've been using a time type called \texttt{Time} expressed in
  15 $\mathtt{TIME\_HZ}^{-1}$; e.g. \texttt{TIME\_HZ} units is 1 second.
  16 \texttt{TIME\_HZ} is chosen to be divisible by lots of frame and
  17 sample rates.
  18
  19 We express content start time as a \texttt{Time}.
  20
  21
  22 \section{Timing at different stages of the chain}
  23
  24 Let's try this: decoders produce sequences of (perhaps) video frames
  25 and (perhaps) audio frames.  There are no gaps.  They are at the
  26 content's native frame rates and are synchronised (meaning that if
  27 they are played together, at the content's frame rates, they will be
  28 in sync).  The decoders give timestamps for each piece of their
  29 output, which are \emph{simple indices} (\texttt{ContentVideoFrame}
  30 and \texttt{ContentAudioFrame}).  Decoders know nothing of \texttt{Time}.
  31
  32
  33 \section{Split of stuff between decoders and player}
  34
  35 In some ways it seems nice to have decoders which produce the rawest
  36 possible data and make the player sort it out (e.g.\ cropping and
  37 scaling video, resampling audio).  The resampling is awkward, though,
  38 as you really need one resampler per source.  So it might make more sense
  39 to put stuff in the decoder.  But then, what's one map of resamplers between friends?
  40
  41 On the other hand, having the resampler in the player is confusing.  Audio comes in
  42 at a frame `position', but then it gets resampled and not all of it may emerge from
  43 the resampler.  This means that the position is meaningless, and we want a count
  44 of samples out from the resampler (which can be done more elegantly by the decoder's
  45 \texttt{\_audio\_position}.
  46
  47
  48 \section{Options for what \texttt{Time} is a function of}
  49
  50 I've been trying for a while with \texttt{Time} as a wall-clock
  51 `real-time' unit.  This means that the following is tricky:
  52
  53 \begin{enumerate}
  54 \item Add content at 29.97 fps
  55 \item Length of this content is converted to \texttt{Time} using the
  56   current DCP frame rate (which will be 29.97).
  57 \item Add more content at 25 fps.
  58 \item This causes the DCP frame rate to be changed to 25 fps, and so
  59   the first piece of content is now being run slower and so its length
  60   changes.
  61 \end{enumerate}
  62
  63 I think this is the cause of content being overlapped in this case.
  64
  65 It is tempting to solve this by making Time a subdivision of DCP video
  66 frame rate.  This makes things nicer in many ways; you get a 1:1
  67 mapping of content video frames to Time in most cases, but not when
  68 video frames are skipped to halve the frame rate, say.  In this case
  69 you could have a piece of content at 50 fps which is some time $T$
  70 long at at DCP rate of 50 fps, but half as long at a DCP rate of 25 fps.
  71
  72 I'm fairly sure that there is inherently not a nice representation which
  73 will obviate the need for things to be recalculated when DCP rate changes.
  74
  75 On the plus side, lengths in \texttt{Time} are computed on-demand from
  76 lengths kept as source frames.
  77
  78
  79 \section{More musings}
  80
  81 In version 2 things we changed, and a problem appeared.  We have / had
  82 \texttt{ContentTime} which is a metric time type, and it is used to
  83 describe video content length (amongst other things).  However if we
  84 load a set of TIFFs and then change the frame rate we don't have the
  85 length in frames i order to work out the new rate.
  86
  87 This suggests that the content lengths, at least, should be described
  88 in frames.  Then to get metric lengths you would need to specify a
  89 timecode.
  90
  91 I will probably have to try a frame-based ContentTime and see what
  92 problems arise.
  93
  94 \end{document}