[NUT-devel] Freeze NUT spec?

[Michael Niedermayer]

Hi

On Sat, Mar 18, 2006 at 12:19:33AM -0500, Rich Felker wrote:
> On Thu, Mar 16, 2006 at 11:03:15AM -0500, Rich Felker wrote:
> > On Thu, Mar 16, 2006 at 12:20:58PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Wed, Mar 15, 2006 at 06:47:31PM +0200, Oded Shimon wrote:
> > > > On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
> > > > > Hi
> > > > > 
> > > > > On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
> > > > > > $subj
> > > > > 
> > > > > oded, rich, please each of you read through the spec and see if you notice
> > > > > any issues, if no and we have agreed on something for the remaining ones
> > > > > i have no objections to a freeze
> > > > > * cosmetic changes are ok
> > > > > * minor fixes like changed thresholds or added info packet names are ok
> > > > > * everything else needs unfreezing or so
> > > > 
> > > > Commit?
> > > 
> > > iam ok with it
> > 
> > Give me a chance to read through the spec as it is again, but I think
> > I'll be ok with it.
> 
> Reviewing now. A couple issues:
> 
> - 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


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


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

agree


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


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


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


[...]
-- 
Michael