[NUT-devel] Freeze NUT spec?

[Rich Felker]

On Sat, Mar 25, 2006 at 03:45:43PM +0200, Oded Shimon wrote:
> > - 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...)

Umm, reading main header startcode will work just as well for probing.

> > - version 2 must be incremented for freeze/final.
> 
> IMO 2 for freeze, 3 for final. By the time spec is finalized should be 

IMO 3 for freeze. 2 has been all the constantly-changing versions for
the past year and we need a way to distinguish them and reject the old
files during the freeze while people are testing.

Also if there are no changes (no unfreeze) then we can keep 3 after
final too!

> 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?

After final, nut will ALWAYS be compatible, forever. This is why
freeze/final is so important! New version numbers will just indicate
new additional semantics, etc. Maybe they're not even needed at all..

> > - 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...

No it's not.

> > - 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?

OK..

> 
> > - 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.

OK I'll check..

Rich