projects
/
dcpomatic.git
/ blobdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
|
commitdiff
|
tree
raw
|
inline
| side by side
float -> double in a few places.
[dcpomatic.git]
/
doc
/
design
/
decoder_structures.tex
diff --git
a/doc/design/decoder_structures.tex
b/doc/design/decoder_structures.tex
index 1f7ae0ec48dcef5cb9ff6f5a7338e10639c95dde..588b33695ac2a24300d87c074c3f7da0cebe9ff2 100644
(file)
--- 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.
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
\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.
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}
\end{document}