[NUT-devel] Freeze NUT spec?

[Rich Felker]

On Tue, Mar 28, 2006 at 11:05:55AM +0200, Oded Shimon wrote:
> 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).

Umm, just put code that looks for the main startcode in mplayer too...
It's just as simple as the code that looks for the string..

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

Can you just add code to disable nutmerge except for formats that
work?

BTW I suppose the fourcc issue also needs to be resolved before
freeze..

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

>_<
Do you have thoughts on which way we should go with it?

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

I sent an email with a sort of draft wording. Comments on it?

Rich