X-Git-Url: https://git.carlh.net/gitweb/?p=dcpomatic.git;a=blobdiff_plain;f=doc%2Fdesign%2Fdecoder_structures.tex;h=588b33695ac2a24300d87c074c3f7da0cebe9ff2;hp=1f7ae0ec48dcef5cb9ff6f5a7338e10639c95dde;hb=f3339e76cacae699c18a949e21b615c97d196e35;hpb=972cdd8a1c2d6d06d8d968ebb947fb48619fb829

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}