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