From 972cdd8a1c2d6d06d8d968ebb947fb48619fb829 Mon Sep 17 00:00:00 2001
From: Carl Hetherington <cth@carlh.net>
Date: Wed, 27 May 2015 20:48:15 +0100
Subject: Add design doc.

---
 doc/design/decoder_structures.tex | 53 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 doc/design/decoder_structures.tex

(limited to 'doc/design/decoder_structures.tex')

diff --git a/doc/design/decoder_structures.tex b/doc/design/decoder_structures.tex
new file mode 100644
index 000000000..1f7ae0ec4
--- /dev/null
+++ b/doc/design/decoder_structures.tex
@@ -0,0 +1,53 @@
+\documentclass{article}
+\title{Decoder structures}
+\author{}
+\date{}
+\begin{document}
+\maketitle
+
+At the time of writing we have a get-stuff-at-this-time API which
+hides a decode-some-and-see-what-comes-out approach.
+
+\section{Easy and hard extraction of particular pieces of content}
+
+With most decoders it is quick, easy and reliable to get a particular
+piece of content from a particular timecode.  This applies to the DCP,
+DCP subtitle, Sndfile and Image decoders.  With FFmpeg, however, this is not easy.
+
+This suggests that it would make more sense to keep the
+decode-and-see-what-comes-out code within the FFmpeg decoder and not
+use it anywhere else.
+
+However resampling screws this up, as it means all audio requires
+decode-and-see.  I don't think you can't resample in neat blocks as
+there are fractional samples other complications.  You can't postpone
+resampling to the end of the player since different audio may be
+coming in at different rates.
+
+This suggests that decode-and-see is a better match, even if it feels
+a bit ridiculous when most of the decoders have slightly clunky seek
+and pass methods.
+
+\section{Multiple streams}
+
+Another thing unique to FFmpeg is multiple audio streams, possibly at
+different sample rates.
+
+There seem to be two approaches to handling this:
+
+\begin{enumerate}
+\item Every audio decoder has one or more `streams'.  The player loops
+  content and streams within content, and the audio decoder resamples
+  each stream individually.
+\item Every audio decoder just returns audio data, and the FFmpeg
+  decoder returns all its streams' data in one block.
+\end{enumerate}
+
+The second approach has the disadvantage that the FFmpeg decoder must
+resample and merge its audio streams into one block.  This is in
+addition to the resampling that must be done for the other decoders,
+and the merging of all audio content inside the player.
+
+These disadvantages suggest that the first approach is better.
+
+\end{document}
-- 
cgit v1.2.3

