[NUT-devel] [nut]: r648 - docs/nut.txt
michael
subversion at mplayerhq.hu
Mon Mar 3 14:50:21 CET 2008
Author: michael
Date: Mon Mar 3 14:50:19 2008
New Revision: 648
Log:
Random Access (seeking) considerations
Modified:
docs/nut.txt
Modified: docs/nut.txt
==============================================================================
--- docs/nut.txt (original)
+++ docs/nut.txt Mon Mar 3 14:50:19 2008
@@ -1017,6 +1017,39 @@ The muxer SHOULD repeat non-mandatory he
the overhead is not excessive.
+Random Access (seeking) considerations:
+---------------------------------------
+Decoding can only start at a keyframe. Thus if efficient seeking with at
+least a granularity of N seconds is wanted, then it is neccessary to have
+at least 1 keyframe every N seconds in every stream.
+
+Furthermore to start correct "presentation" (after seeking) it is neccessary
+to have a decoded frame from every stream at approximately the same time.
+Thus it is important to have closely placed keyframes in all streams at least
+once every N seconds. This is equivalent of having back pointers frequently
+short.
+Good example:
+Video: .....K...........................................K...........
+Audio: KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
+Subtitle: ..K............................................K.....K.......
+shortest back ptrs:<--o
+ <-----------------------------------------o
+ <-o
+ <---o
+Bad example:
+Video: .....K...........................................K...........
+Audio: KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
+Subtitle: ..........................K..................................
+shortest back ptrs: <--------------------o
+ <----------------------o
+
+In the bad example a player would have to demux and decode half of the video
+between the 2 keyrames to start correct playback if it favors the shortest
+back ptr.
+
+The above 2 considerations are not specific to NUT.
+
+
Index:
------
More information about the NUT-devel
mailing list