|
List Info
Thread: : r648 - docs/nut.txt
|
|
| : r648 - docs/nut.txt |
|
2008-03-03 07:50:21 |
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:
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
K
+Subtitle:
..K............................................K.....K......
.
+shortest back ptrs:<--o
+
<-----------------------------------------o
+
<-o
+
<---o
+Bad example:
+Video:
.....K...........................................K..........
.
+Audio:
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
K
+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:
------
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
|
| Re: : r648 - docs/nut.txt |
|
2008-03-03 10:48:23 |
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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
|
| Re: : r648 - docs/nut.txt |
|
2008-03-03 11:16:52 |
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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
|
| Re: : r648 - docs/nut.txt |
|
2008-03-03 11:21:55 |
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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
|
| Re: : r648 - docs/nut.txt |
|
2008-03-03 11:42:03 |
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
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel |
|
| Re: : r648 - docs/nut.txt |
|
2008-03-03 11:44:33 |
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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
|
[1-6]
|
|