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

[Michael Niedermayer]

Hi

On Sat, Feb 18, 2006 at 12:49:23PM -0500, Rich Felker wrote:
> 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

yes


> is interlaced it must be fixed-fps, and the player probably wants to

well, my first thought was "yeah sure", but sadly no
just take a realtime stream the frame times will be
off a little from your ntp/atomic clock, and for cheap vhs cameras/
players they will be off by alot, your player must adjust the
refresh times of the monitor/tv to these timestamps otherwise
it will look less then perfect 

[...]

-- 
Michael