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