[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