[NUT-devel] Freeze NUT spec?

[Rich Felker]

On Tue, Mar 28, 2006 at 07:09:02PM +0200, Oded Shimon wrote:
> 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 

No, mplayer's stream layer handles this. Otherwise all probing for all
formats would be broken.

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

If libnut doesn't need it then libnut is not compliant to the spec. :)

> > > > > > - 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")

Using XVID for everything is absolutely wrong. There's no need to
maintain compatibility with the expectations of stupid hardware
players since they don't even support NUT yet. IMO the options are:

1. Use the same mess as AVI & friends with 10-20 fourcc's for each
   codec.
2. Require a single fourcc per codec, using an existing common name
   for the standard (like MP4S or H264) if available and never using
   vendor-specific names.
3. Require a single fourcc (or more generally, codec id) per codec,
   using our own nomenclature. One past proposal I made was to use the
   official name of the document that specifies the compression
   format, and in the case of reverse-engineered proprietary formats
   this would be the name of the DLL file. :) Of course I'm open to
   other options too.

IMO 3 is the cleanest and most format, while 2 is probably more
pradmatic. In some senses 1 is probably the most pragmatic but also
disgusting, and it certainly isn't appropriate for audio..

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

OK, I'll try to write up a version for inclusion in the spec..

Rich