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: ------
On Mon, Mar 03, 2008 at 02:50:21PM +0100, michael wrote:
--- 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
+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.
I cannot parse the last sentence. Diego
On Mon, Mar 03, 2008 at 05:48:23PM +0100, Diego Biurrun wrote:
On Mon, Mar 03, 2008 at 02:50:21PM +0100, michael wrote:
--- 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
+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.
I cannot parse the last sentence.
Is the s/of/to/ you commited enough or do you think this need further clarification? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I wish the Xiph folks would stop pretending they've got something they do not. Somehow I fear this will remain a wish. -- Måns Rullgård
On Mon, Mar 03, 2008 at 06:16:52PM +0100, Michael Niedermayer wrote:
On Mon, Mar 03, 2008 at 05:48:23PM +0100, Diego Biurrun wrote:
On Mon, Mar 03, 2008 at 02:50:21PM +0100, michael wrote:
--- 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
+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.
I cannot parse the last sentence.
Is the s/of/to/ you commited enough or do you think this need further clarification?
It needs further clarification. "frequently short" is not something I can make much sense of. Diego
Diego Biurrun wrote:
On Mon, Mar 03, 2008 at 06:16:52PM +0100, Michael Niedermayer wrote:
On Mon, Mar 03, 2008 at 05:48:23PM +0100, Diego Biurrun wrote:
On Mon, Mar 03, 2008 at 02:50:21PM +0100, michael wrote:
--- 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
+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.
I cannot parse the last sentence.
Is the s/of/to/ you commited enough or do you think this need further clarification?
It needs further clarification. "frequently short" is not something I can make much sense of.
If I understood the intent correctly, "having frequent, short back pointers" is the correct phrasing. -- Måns Rullgård mans@mansr.com
On Mon, Mar 03, 2008 at 06:21:55PM +0100, Diego Biurrun wrote:
On Mon, Mar 03, 2008 at 06:16:52PM +0100, Michael Niedermayer wrote:
On Mon, Mar 03, 2008 at 05:48:23PM +0100, Diego Biurrun wrote:
On Mon, Mar 03, 2008 at 02:50:21PM +0100, michael wrote:
--- 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
+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.
I cannot parse the last sentence.
Is the s/of/to/ you commited enough or do you think this need further clarification?
It needs further clarification. "frequently short" is not something I can make much sense of.
hmmmm, a back pointer can be long (that is point far back from the point where its stored) or short (that is having a small value and pointing only over a short distance). "frequently short" was supposed to mean that such short back ptrs would be present regularly that is that there would be no long timespans without any short back ptrs. Sadly i cant think of a nice way to say this ATM :( [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin
participants (4)
-
Diego Biurrun -
michael -
Michael Niedermayer -
Måns Rullgård