[NUT-devel] [nut]: r619 - docs/nut.txt

[Rich Felker]

On Wed, Feb 13, 2008 at 08:02:30PM +0100, Michael Niedermayer wrote:
> On Wed, Feb 13, 2008 at 12:55:59PM -0500, Rich Felker wrote:
> > On Wed, Feb 13, 2008 at 01:20:31PM +0100, michael wrote:
> > > Author: michael
> > > Date: Wed Feb 13 13:20:28 2008
> > > New Revision: 619
> > > 
> > > Log:
> > > Ensure that match_time_delta[frame_code] fits in 16bit.
> > > 
> > > 
> > > Modified:
> > >    docs/nut.txt
> > > 
> > > Modified: docs/nut.txt
> > > ==============================================================================
> > > --- docs/nut.txt	(original)
> > > +++ docs/nut.txt	Wed Feb 13 13:20:28 2008
> > > @@ -678,7 +678,7 @@ coded_pts (v)
> > >      delta = last_pts - mask / 2
> > >      pts   = ( (pts_lsb - delta) & mask ) + delta
> > >  
> > > -match_time_delta
> > > +match_time_delta (s)
> > >      This is the time difference in stream timebase units from the pts at which
> > >      the output from the decoder has converged independent from the availability
> > >      of previous frames (that is the frames are virtually identical no matter
> > > @@ -688,6 +688,11 @@ match_time_delta
> > >      A muxer MUST only set it to 1-(1<<62) if it does not know the correct
> > >      value. That is, it is not allowed to randomly discard known values.
> > >  
> > > +match_time_delta[frame_code] (s)
> > > +    If FLAG_MATCH_TIME is not set then this value shall be used for
> > > +    match_time_delta, otherwise this value is ignored.
> > > +    MUST be <32786 and >-32768 or =1-(1<<62)
> > > +
> > 
> > Why?? If the timebase is 1/(1<<30) this is nonsense..
> 
> Because the framecode table before match_time_delta fitted in ~2kb
> and 64bit match_time_delta would need 2kb extra.
> 
> Also the same applies to pts_delta in the framecode table, and even
> with more strict limits. I dont see why match_time_delta should be
> an exception. Or why we suddenly should endorse the use of 1/(1<<30)
> as timebase.
> If someone wants to use 1/(1<<30) he will have to code all pts_delta
> and match_time_delta in the actual frame headers.

Oh, I see... If it's explicitly coded rather than being in the
framecode, there's no limit still. That's fine then. Sorry, I was just
confused.

Rich