[NUT-devel] flags, which bit means fixed fps?

Rich Felker dalias at aerifal.cx
Sat Feb 18 18:49:23 CET 2006


On Sat, Feb 18, 2006 at 04:01:07PM +0200, Oded Shimon wrote:
> On Fri, Feb 17, 2006 at 09:06:38PM +0100, Alexander Strasser wrote:
> > Hi,
> > 
> >   there is a minor issue with the spec and
> > current (partial) nut implementations.
> > 
> >   The spec says:
> >     ...
> >     decode_delay                        v
> >     fixed_fps                           u(1)
> >     reserved                            u(7)
> >     codec_specific_data                 vb
> >     ...
> > 
> >   which would mean in the byte of u(1) and u(7)
> > the most significant bit indicates a fixed
> > fps stream. Implementations (ffmpeg muxer and
> > Oded's libnut) do say/set the least significant bit
> > is the fixed fps one.
> > 
> >   It doesn't matter which of the bits we actually
> > use, but we need to make it consistent with the
> > spec.
> > 
> >   So should we just adjust the spec and swap the
> > two entries?
> 
> Is there any real reason why we have this flag? Does it tell anything to 
> the player?.. Just wondering..

It tells the player that pts values are frame numbers, and if a file
is interlaced it must be fixed-fps, and the player probably wants to
know this to initialize its interlaced-refresh sync.

Rich




More information about the NUT-devel mailing list