[NUT-devel] r20862 - trunk/DOCS/tech/nut.txt

[Michael Niedermayer]

Hi

On Sun, Nov 12, 2006 at 09:42:17PM -0500, Rich Felker wrote:
> On Sun, Nov 12, 2006 at 01:24:57PM +0100, michael wrote:
> > Author: michael
> > Date: Sun Nov 12 13:24:57 2006
> > New Revision: 20862
> > 
> > Modified:
> >    trunk/DOCS/tech/nut.txt
> > 
> > Log:
> > least restrictive dts ordering rule which ensures frames are in decoding order
> > 
> > 
> > Modified: trunk/DOCS/tech/nut.txt
> > ==============================================================================
> > --- trunk/DOCS/tech/nut.txt	(original)
> > +++ trunk/DOCS/tech/nut.txt	Sun Nov 12 13:24:57 2006
> > @@ -670,6 +670,8 @@
> >      Pts of all frames in all streams MUST be bigger or equal to dts of all
> >      previous frames in all streams, compared in common timebase. (EOR
> >      frames are NOT exempt from this rule)
> > +    Dts of all frames MUST be bigger or equal to dts of all previous frames
> > +    in the same stream
> 
> This is guaranteed by the definition of DTS and the above condition on
> PTS, isn't it?

i dont know but just looking at the definition of decode_delay gives me 
doubt
"decode_delay
    maximum time between input and output for a codec, used to generate
    dts from pts
    is set to 0 for streams without B-frames, and set to 1 for streams with
    B-frames, may be larger for future codecs
    decode_delay MUST NOT be set higher than necessary for a codec."


what is the "maximum time between input and output for a codec" ?
its not the time between a frame input and output IPBBB ->IBBBP (=3)
its neither the smallest number so that dts are monotone (IPPPP)
and codec is decoder + encoder that too makes no sense

i dont know what i was thinking when i wrote that :(


its rather
dts of a frame is the time when it is input into the decoder
pts is the time of presentation of the first corresponding decoded sample
and decode_delay is then the size of the timestamp sorting buffer that
the above has a solution for

note, the above is a little fuzzy i know but if we define pts like
pts is the time of presentation of the first sample affected by the frame
then IPBBB would have I.pts=0 P.pts=1 as the b frame is affected by P

comments, objections?
(if there are no objections then ill change that in the spec)


and what about audio?
with a MDCT a frame which feeded into the decoder affects
samples 2t..2t+4 it combines that with the previous frame like:

                __
Frame 0:       /  \
                  __
Frame 1:         /  \
                    __
Frame 2:           /  \
out 1:           **
out 2:             **

that gives the expected decode_delay=0

another thing i was thinking about was if we maybe should add a field
to indicate how many initial inexact (or not outputed) samples there are
after seeking?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is