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

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

Hi On Wed, Feb 22, 2006 at 11:04:37AM -0500, Rich Felker wrote:

On Wed, Feb 22, 2006 at 03:07:12PM +0100, Michael Niedermayer wrote:

...

...

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

this is just a matter of syncing to the refresh as the definition of time units, rather than using a pc's rtc or other source. it's a separate issue imo.

if you mean that measured physical units would be used in the file captured from interlaced source, imo this is a very bad idea. rather the timebase should be 1001/30000 (or 1/25) with exactly 1 unit increments per frame, and the audio should be sampled to match the video clock. i expect the audio and video clocks already match for digital devices (dv cams, hardware mpeg encoders, ..)

i was not talking about capturing somethin and storing it on disk and then later playing it but realtime ... you have interlaced video from a vhs recoder/camera/satelite/... if you do not adjust the refresh times of your monitor to the source you will either run out of video frames or need to do unlimited buffering and accept unbound delay this is somewhat off topic i agree but in that case you MUST adjust the refresh times of your display to the true timestamps ... [...] -- Michael