[NUT-devel] Freeze NUT spec?

[Oded Shimon]

On Sat, Mar 18, 2006 at 12:19:33AM -0500, Rich Felker wrote:
> Reviewing now. A couple issues:
> 
> - It's not clear whether limits like max_distance and
>   max_pts_difference take effect when the difference is > the limit,
>   or when the difference is >= the limit. This must be specified one
>   way or the other, and should be consistent between all the limits of
>   this sort for the sake of simplicity.

fixed

> - Is file_id_string desirable? There was a question about this at one
>   point and I don't know if it was resolved. I don't really care one
>   way or the other.

I'm leaning both ways. It's slightly more complex, but it allows for ex. 
mplayer to probe without having to seek back after probing (mplayer is very 
dumb about this...)

> - version 2 must be incremented for freeze/final.

IMO 2 for freeze, 3 for final. By the time spec is finalized should be 
about same time nutmerge can give 100% compliant nut files.  Also, is there 
any rule about if a certaion version number means it is non backwards 
compatible? Like, if version is 4 then the demuxer should not even bother 
trying demuxing the file?

> - reserved_count can only be specified in the framecode, not
>   explicitly in the frame header.

fixed

> - We need a spec for what goes in the fourcc field, especially for
>   audio, but it may also be an issue for video. Are XVID, DIVX, DX50,
>   etc. valid or is MP4S the only valid MPEG4-ASP fourcc?

seperate from freeze/finalizing...

> - The correct spec for decode_delay is still missing. It just says
>   "decode_delay MUST NOT be set higher than necessary for a codec."
>   which is ambiguous and actually incorrect in the case of an mpeg4
>   stream without low_delay but with no B frames actually present. I've
>   drafted possible wordings for a correct requirement on IRC before
>   and I think Michael has written a corrected version too.

send a patch?

> - Michael's guidelines about what a demuxer should do for reading info
>   do not seem to have been committed in full.

I didn't quite follow that whole discussion so not sure whats missing.

- ods15