On Sat, Feb 25, 2006 at 09:03:49PM +0200, Oded Shimon wrote:
Comments...
- ods15
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 25 Feb 2006 19:03:05 -0000 @@ -637,9 +637,15 @@ s= chapter_start % stream_count timestamp= chapter_start / stream_count timestamp of start of chapter in timebase of stream 's'. + In info streams, if chapter_start is zero, chapter_start is the pts of + the first unrepeated info frame.
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. + In info streams, if chapter_start is zero, chapter_len MUST be zero.
type for example: "UTF8" -> string or "JPEG" -> JPEG image @@ -741,6 +747,12 @@
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) + +If an info stream contains an info frame for chapter X then it MUST contain +an info frame with pts==chapter_start + Info SHOULD be stored in global packets instead of info streams/frames if possible, and the amount of data is not large.
I'm ok with this patch, with one additional pair of requirements: 1. If chapter_start is coded, then a copy of the info frame must appear at the timestamp coded in chapter_start. 2. No frame with a different chapter_id (or EOR) may appear between chapter_start and chapter_start+len. With the addition of these constraints, it's always possible to decode with the stream-style behavior, but when chapter_len is known it provides extra information in advance (and may improve error recovery in case a frame is lost). BTW, one more thing: chapter_start==0 is a weird way to omit the field since 0 is also a valid pts. 0 is not a valid value for chapter_start unless pts==0 as well, so this may be ok, but there may be problems if a packet is lost.. What about just always requiring chapter_start to be coded (and equal to the pts of the first copy) and making chapter_len the only optional field? Rich