doc/design/decoder_structures.tex

   1 \documentclass{article}
   2 \title{Decoder structures}
   3 \author{}
   4 \date{}
   5 \begin{document}
   6 \maketitle
   7
   8 At the time of writing we have a get-stuff-at-this-time API which
   9 hides a decode-some-and-see-what-comes-out approach.
  10
  11 \section{Easy and hard extraction of particular pieces of content}
  12
  13 With most decoders it is quick, easy and reliable to get a particular
  14 piece of content from a particular timecode.  This applies to the DCP,
  15 DCP subtitle, Sndfile and Image decoders.  With FFmpeg, however, this is not easy.
  16
  17 This suggests that it would make more sense to keep the
  18 decode-and-see-what-comes-out code within the FFmpeg decoder and not
  19 use it anywhere else.
  20
  21 However resampling screws this up, as it means all audio requires
  22 decode-and-see.  I don't think you can't resample in neat blocks as
  23 there are fractional samples other complications.  You can't postpone
  24 resampling to the end of the player since different audio may be
  25 coming in at different rates.
  26
  27 This suggests that decode-and-see is a better match, even if it feels
  28 a bit ridiculous when most of the decoders have slightly clunky seek
  29 and pass methods.
  30
  31
  32 \section{Multiple streams}
  33
  34 Another thing unique to FFmpeg is multiple audio streams, possibly at
  35 different sample rates.
  36
  37 There seem to be two approaches to handling this:
  38
  39 \begin{enumerate}
  40 \item Every audio decoder has one or more `streams'.  The player loops
  41   content and streams within content, and the audio decoder resamples
  42   each stream individually.
  43 \item Every audio decoder just returns audio data, and the FFmpeg
  44   decoder returns all its streams' data in one block.
  45 \end{enumerate}
  46
  47 The second approach has the disadvantage that the FFmpeg decoder must
  48 resample and merge its audio streams into one block.  This is in
  49 addition to the resampling that must be done for the other decoders,
  50 and the merging of all audio content inside the player.
  51
  52 These disadvantages suggest that the first approach is better.
  53
  54 One might think that the logical conclusion is to take streams all the
  55 way back to the player and resample them there, but the resampling
  56 must occur on the other side of the get-stuff-at-time API.
  57
  58 \end{document}