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

[Michael Niedermayer]

Hi

On Mon, Nov 13, 2006 at 12:56:56PM -0000, Måns Rullgård wrote:
> 
> Michael Niedermayer said:
> > 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)
> 
> Not that my word counts for much around here, but that is not a good definition.
> The PTS must be defined as the presentation time of the first frame/sample that
> is completed by that coded frame.  With your suggested definition, a coded IPBB
> sequence (displayed IBBP) the PTS of the P and B frames would all be 1.  This
> is clearly not a good situation.

thanks for the suggested improvement, ive added your pts definition

[...]
-- 
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