summaryrefslogtreecommitdiff
path: root/doc/design
diff options
context:
space:
mode:
authorCarl Hetherington <cth@carlh.net>2015-05-27 20:55:51 +0100
committerCarl Hetherington <cth@carlh.net>2015-06-02 13:38:21 +0100
commit0a93237cb5e4642d3b698ff9b7d0cfae5401478c (patch)
treeb0d5255ae2b90d1c9ef489e78239c2f081ea0a9e /doc/design
parent608c146eb09fac2a8fc60e1a72591f6bb8364e1f (diff)
Handle multiple audio streams in a single piece of content
in a similar way to the V1 patch.
Diffstat (limited to 'doc/design')
-rw-r--r--doc/design/decoder_structures.tex5
1 files changed, 5 insertions, 0 deletions
diff --git a/doc/design/decoder_structures.tex b/doc/design/decoder_structures.tex
index 1f7ae0ec4..588b33695 100644
--- a/doc/design/decoder_structures.tex
+++ b/doc/design/decoder_structures.tex
@@ -28,6 +28,7 @@ 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
@@ -50,4 +51,8 @@ and the merging of all audio content inside the player.
These disadvantages suggest that the first approach is better.
+One might think that the logical conclusion is to take streams all the
+way back to the player and resample them there, but the resampling
+must occur on the other side of the get-stuff-at-time API.
+
\end{document}