[NUT-devel] Freeze NUT spec?

[Oded Shimon]

On Sat, Mar 25, 2006 at 10:52:20AM -0500, Rich Felker wrote:
> 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.

Yes, but you need to rewind after that, MPlayer sucks for not always 
allowing this (non seekable streams), I'm actually not completely sure 
about all this, but I do know that if you don't do 'stream_seek' after 
probing, you will have lost the initial data you used for probing. Fine 
for native demuxers, trouble for library demuxers (libnut).

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

OK. But I suppose until nutmerge is fixed it should only use 2?

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

OK... Start writing then.

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

Well?

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

Well?

- ods15