[NUT-devel] Re: FINALIZE NUT SPEC!!

[Oded Shimon]

On Tue, Feb 28, 2006 at 02:10:11AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Feb 27, 2006 at 02:30:23PM -0500, Rich Felker wrote:
> > Moving to nut-devel list...
> > 
> > On Mon, Feb 27, 2006 at 08:08:55PM +0100, Michael Niedermayer wrote:
> > > yes, but that realtime data could very well become available afterwards
> > > lets say some realtime news of a earthquake, its magnitude, number of
> > > casualties and so on wont be known immedeatly
> > > furthermore estimates will change, and if you dont like that example, take
> > > any other realtime stream (some DJ with music videos whatever) where info
> > > is added in realtime some mistakes will creep in and it should be possible
> > > to correct them, in such a way that automatic remuxing updates all info
> > > thats not hard but with our strict rules its impossible. so with these
> > > restrictions i see no sense in info streams
> > 
> > OK, how about this: drop the requirement that they be
> > binary-identical, and instead the last packet with the given
> > chapter_id is the one that's valid. Keep the rest of the semantics for
> > what range it applies to. This allows updating/correcting info in a
> > live stream and will give the correct results if you convert it to an
> > info packet for permenant storage (using the latest/most correct
> > data). Also this allows you to specify length if it becomes known.
> 
> ok

- ods15
-------------- next part --------------
Index: DOCS/tech/mpcf.txt
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v
retrieving revision 1.113
diff -u -r1.113 mpcf.txt
--- DOCS/tech/mpcf.txt	25 Feb 2006 18:51:46 -0000	1.113
+++ DOCS/tech/mpcf.txt	28 Feb 2006 04:16:51 -0000
@@ -640,6 +640,9 @@
 
 chapter_len
     Length of chapter in same timebase of chapter_start.
+    In info streams, if chapter_len is zero, chapter_len is the pts of
+    the first EOR or info frame with a different chapter_id in the same
+    info stream, minus chapter_start.
 
 type
     for example: "UTF8" -> string or "JPEG" -> JPEG image
@@ -734,13 +737,30 @@
 -----
 
 All info packets with the same chapter_id and stream_id are repeated info
-packets and MUST be binary identical.
+packets and MUST be binary identical. This does not apply to info streams.
 
 All info packets MUST appear after main headers at begginning of file, and
 SHOULD be repeated after all main headers unless they are very large.
 
 Info frames can be used to describe the file or some part of it (chapters)
 
+The pts of an info frame MUST be >=chapter_start and <=chapter_start+len
+(Compared using compare_ts)
+
+Info frames with a different chapter_id (or EOR) MUST NOT appear between
+chapter_start and chapter_start+len. For overlapping chapters several info
+streams can be used.
+
+If an info stream contains an info frame for chapter X then it MUST contain
+an info frame with pts==chapter_start. Due to this restriction, the only
+legal timebase for chapter_start (and chapter_len) is the info stream
+timebase.
+
+Info frames with the same chapter_id and stream_id MUST have the same
+chapter_start and chapter_len if it is non zero. The last info frame with
+the same chapter_id and stream_id is the most correct one, and SHOULD have
+chapter_len filled.
+
 Info SHOULD be stored in global packets instead of info streams/frames if
 possible, and the amount of data is not large.