[NUT-devel] [RFC] some suggestions for the spec

[Diego Biurrun]

On Sun, May 06, 2007 at 10:52:13AM +0200, Michael Niedermayer wrote:
> 
> On Sat, May 05, 2007 at 02:58:20PM +0200, Diego Biurrun wrote:
> > I had these notes in my local tree from the last time I looked at the
> > spec.  Hopefully this is useful to point out problems and clarify the
> > spec a bit.
> 
> > --- nut.txt	(revision 23236)
> > +++ nut.txt	(working copy)
> > @@ -584,6 +584,7 @@
> >  
> > +FIXME: The frame_code description is convoluted and incomprehensible.
> >  frame_code (f(8))
> >      frame_code is an 8-bit field which exists before every frame, it can
> >      store part of the size of the frame, the stream number, the timestamp
> 
> elaborate ...
> 
> > @@ -602,6 +603,7 @@
> > +FIXME: What does "at the frame header" mean?
> >         5  FLAG_SIZE_MSB    If set, data_size_msb at the frame header,
> >                             otherwise data_size_msb is 0.
> 
> s/at/is (coded) in/
> 
> > @@ -612,7 +614,7 @@
> > -    An EOR set stream is unset by the first content frames.
> > +    An EOR set stream is unset by the first content frame.
> 
> ok
> 
> > @@ -795,7 +797,7 @@
> > -    A negative chapter_id indicates a sub region of the file and not a real
> > +    A negative chapter_id indicates a region of the file and not a real
> >      chapter. chapter_id MUST be unique to the region it represents.
> 
> ok
> 
> > @@ -830,6 +832,7 @@
> > +FIXME: Does this have to be lowercase?
> >      "SourceContainer"
> >          "nut", "mkv", "mov", "avi", "ogg", "rm", "mpeg-ps", "mpeg-ts", "raw"
> 
> the spec does not mandate SourceContainers to be lowercase, all examples are
> lowercase though, maybe we should suggest a more strict format but that
> belongs into a seperate thread
> 
> > @@ -849,6 +852,7 @@
> >          See http://www.loc.gov/standards/iso639-2/
> >          and http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html
> > +FIXME: Does the following line have a meaning here?
> >          the language code
> >          A demuxer MUST ignore unknown language and country codes instead of
> >          treating them as an error.
> 
> i dont think so
> 
> > @@ -884,6 +888,7 @@
> >  Headers may be repeated, but if they are, then they MUST all be repeated
> >  together and repeated headers MUST be identical.
> >  
> > +FIXME: This description is confusing, after 2^x *and* end of file???
> >  Each set of repeated headers not at the beginning or end of the file SHOULD
> >  be stored at the earliest possible position after 2^x where x is an integer
> >  and the end of the file. So the headers may be repeated at 4102 if that is
> 
> remove the "and the end of the file"
> 
> > @@ -923,6 +928,7 @@
> >  demuxer (non-normative):
> >  ------------------------
> >  
> > +FIXME: Where is the syncpoint included?
> >  In the absence of a valid header at the beginning, players SHOULD search for
> >  backup headers starting at offset 2^x; for each x players SHOULD end their
> >  search at a particular offset when any startcode (including a syncpoint) is
> 
> s/including a syncpoint/including the syncpoint startcode/

All committed in several steps.

Diego