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

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}