doc/design/who_fills_the_gaps.tex

   1 \documentclass{article}
   2 \begin{document}
   3
   4 There is a lot of dancing about to handle potential gaps and sync
   5 problems in the FFmpeg decoder.  It might be nicer if
   6 \texttt{FFmpegDecoder} could just spit out video and audio with
   7 timestamps and let the player sort it out, since the player must
   8 already handle insertion of black and silence.
   9
  10 The first question would be what time unit the decoder should use to
  11 stamp its output.  Initially we have the PTS, in some time base, and
  12 we can convert that to seconds at the content's frame rate; this is
  13 basically a \texttt{Time}.  So we could emit video and audio content
  14 with \texttt{Time} stamps.
  15
  16 Then the player receives video frames, and can fill in gaps.
  17
  18 The FFmpeg decoder would still have to account for non-zero initial
  19 PTS, as it is expected that such `dead time' is trimmed from the
  20 source implicitly.
  21
  22 The snag with this is that hitherto \texttt{Time} has meant DCP time,
  23 not time at a content's rates (before the content is potentially sped
  24 up).  As it stands, seek takes a \texttt{Time} in the DCP and the
  25 content class converts it to content frames.  This is then (rather
  26 grottily) converted back to time again via the content frame rate.
  27 All a bit grim.  Everything should probably work in time rather than
  28 frame rates.
  29
  30 \end{document}