[NUT-devel] Freeze NUT spec?

[Rich Felker]

On Sat, Mar 18, 2006 at 12:06:37PM +0100, Michael Niedermayer wrote:
> > - It's not clear whether limits like max_distance and
> >   max_pts_difference take effect when the difference is > the limit,
> >   or when the difference is >= the limit. This must be specified one
> >   way or the other, and should be consistent between all the limits of
> >   this sort for the sake of simplicity.
> 
> agree

OK. Any preference which way? I can make a patch addressing these
issues if you like but it won't be for a couple days.

> > - 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.
> 
> A.    file_id_string at the begin
> B. no file_id_string at the begin
> 
> B has slightly lower complexity, A will help identifying the file if you are
> an idiot and open it in a text editor
> iam _slightly_ in favor of B

OK, so maybe change this.

> > - version 2 must be incremented for freeze/final.
> 
> agree

OK, adding this to the list of things to change.

> > - reserved_count can only be specified in the framecode, not
> >   explicitly in the frame header.
> 
> wither we:
>     reserved_count -> reserved_count_plus1
>     and
>     if(reserved_count_plus1[frame_code]==0)
>             reserved_count_plus1[frame_code]    v
> or
>     we add a flag
> a flag seems better but inconsistant with how stream_id is coded
> ill post a suggested solution soon

I'm happy with the flags changes that were made, except that maybe
more unlikely flags should be moved to above bit 6.

> > - 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?
> 
> i dont care, a fourcc -> codec_id map is not that hard to add to a player

Hmm, I'm undecided on what's best...

> > - 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.
> 
> hmm, now if i could only remember it ...

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.

Rich