[NUT-devel] Freeze NUT spec?

[Rich Felker]

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.

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

- version 2 must be incremented for freeze/final.

- reserved_count can only be specified in the framecode, not
  explicitly in the frame header.

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

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

- Michael's guidelines about what a demuxer should do for reading info
  do not seem to have been committed in full.

Otherwise it looks very good!

Rich