[NUT-devel] Freeze NUT spec?

[Oded Shimon]

On Tue, Mar 28, 2006 at 11:55:31AM -0500, Rich Felker wrote:
> 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..

I think you misunderstand..

step 1: mplayer probe - read N bytes, check if it matches startcode/id.
step 2: call libnut and start demuxing

The problem is, mplayer's probe sucks, and it _discards_ the N bytes you 
just read. you will either have to seek back to begginning of stream 
(I'm not 100% if this requires a seekable stream) or use your own caching 
hacks for them (or just ignore them and start at byte position after the 
probe). I know currently demux_lavf does: probe, seek back, demux.

Starting after a probe of 'file_id' is fine, because libnut doesn't need 
it, but if you "eat up" the main startcode from begginning of file, 
libnut will choke looking for it.

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

I might as well reject everything, I'm working on a decent framer api for 
nutmerge, we'll see how that goes.

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

Yeah, hence me asking you to start doing it...

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

Uhh.... No idea.
More or less same as current formats, not be a pain in the ass. As in, I 
wouldn't mind using MP4S if players actually support it. If not, I say 
just use XVID... (Though it would be weird for a spec strictly saying to 
use something like "XVID")

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

You mean this?

-
My version said something to the effect that decode_delay is not a
derived property of the pts sequence but a property defined by the
compression specification or a relevant supplement (if we acknowledge
that some ill-specified formats like Xiph codecs might require
supplemental specs for storage in non-incestuous containers), and that
the value of decode_delay in the NUT file MUST match the codec's idea
of delay.
-


No objections...

- ods15