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
On Sat, Feb 25, 2006 at 02:29:52PM -0500, Rich Felker wrote:
+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.
Bah, forgot to RTFP. This was already covered.
2. No frame with a different chapter_id (or EOR) may appear between chapter_start and chapter_start+len.
This request still stands. Rich
On Sat, Feb 25, 2006 at 02:29:52PM -0500, Rich Felker wrote:
On Sat, Feb 25, 2006 at 09:03:49PM +0200, Oded Shimon wrote:
+If an info stream contains an info frame for chapter X then it MUST contain +an info frame with pts==chapter_start
1. If chapter_start is coded, then a copy of the info frame must appear at the timestamp coded in chapter_start.
10l to Rich.
2. No frame with a different chapter_id (or EOR) may appear between chapter_start and chapter_start+len.
I'm OK with that. Michael?
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?
chapter_start never implicit, chapter_len zero means implicit. OK. - ods15
Hi On Sat, Feb 25, 2006 at 09:42:22PM +0200, Oded Shimon wrote: [...]
2. No frame with a different chapter_id (or EOR) may appear between chapter_start and chapter_start+len.
I'm OK with that. Michael?
iam ok with: No frame with a different and positive chapter_id (or EOR) may appear between chapter_start and chapter_start+len of a chapter_id>0 chapter [...]
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:41:12 -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.
i would suggest (though i am not strongly against the above): In info streams, chapter_len may be zero for some but not all info frames of a chapter if the length is not known yet this is simpler to remux with filling in length everywhere and its more error robust [...] -- Michael
On Sun, Feb 26, 2006 at 01:28:53AM +0100, Michael Niedermayer wrote:
Hi
On Sat, Feb 25, 2006 at 09:42:22PM +0200, Oded Shimon wrote: [...]
2. No frame with a different chapter_id (or EOR) may appear between chapter_start and chapter_start+len.
I'm OK with that. Michael?
iam ok with: No frame with a different and positive chapter_id (or EOR) may appear between chapter_start and chapter_start+len of a chapter_id>0 chapter
I want it for negative chapter_id too. Otherwise the stream-type semantics are broken. I agree totally that overlapping spans are useful, but they can be done just as well using 2 or more info streams instead of just one. And this gives some meaning to the fact that we consider info as a stream like all others (with possible multiple instances), to make it seem a bit less odd. ;)
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:41:12 -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.
i would suggest (though i am not strongly against the above): In info streams, chapter_len may be zero for some but not all info frames of a chapter if the length is not known yet this is simpler to remux with filling in length everywhere and its more error robust
I discussed the idea of storing length in the final info frame of the span with Oded, but we agreed it was a bad idea because it would mean you would have to mux an extra 'duplicate' right at the end of the span, exactly at the moment where it ceased to be relevant. This seems totally wasteful and counter-intuitive. Also I don't like the idea of the frames not being binary-identical. As long as they're binary-identical, the player can ignore the contents of duplicate frames completely, which simplifies the logic. Rich
On Sat, Feb 25, 2006 at 10:44:02PM -0500, Rich Felker wrote:
On Sun, Feb 26, 2006 at 01:28:53AM +0100, Michael Niedermayer wrote:
Hi
On Sat, Feb 25, 2006 at 09:42:22PM +0200, Oded Shimon wrote: [...]
2. No frame with a different chapter_id (or EOR) may appear between chapter_start and chapter_start+len.
I'm OK with that. Michael?
iam ok with: No frame with a different and positive chapter_id (or EOR) may appear between chapter_start and chapter_start+len of a chapter_id>0 chapter
I want it for negative chapter_id too. Otherwise the stream-type semantics are broken.
I agree totally that overlapping spans are useful, but they can be done just as well using 2 or more info streams instead of just one. And this gives some meaning to the fact that we consider info as a stream like all others (with possible multiple instances), to make it seem a bit less odd. ;)
I agree with Rich...
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:41:12 -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.
i would suggest (though i am not strongly against the above): In info streams, chapter_len may be zero for some but not all info frames of a chapter if the length is not known yet this is simpler to remux with filling in length everywhere and its more error robust
I discussed the idea of storing length in the final info frame of the span with Oded, but we agreed it was a bad idea because it would mean you would have to mux an extra 'duplicate' right at the end of the span, exactly at the moment where it ceased to be relevant. This seems totally wasteful and counter-intuitive.
Also I don't like the idea of the frames not being binary-identical. As long as they're binary-identical, the player can ignore the contents of duplicate frames completely, which simplifies the logic.
Agree here too. - ods15
Hi On Sun, Feb 26, 2006 at 09:19:22AM +0200, Oded Shimon wrote: [...]
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:41:12 -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.
i would suggest (though i am not strongly against the above): In info streams, chapter_len may be zero for some but not all info frames of a chapter if the length is not known yet this is simpler to remux with filling in length everywhere and its more error robust
I discussed the idea of storing length in the final info frame of the span with Oded, but we agreed it was a bad idea because it would mean you would have to mux an extra 'duplicate' right at the end of the span, exactly at the moment where it ceased to be relevant. This seems totally wasteful and counter-intuitive.
Also I don't like the idea of the frames not being binary-identical. As long as they're binary-identical, the player can ignore the contents of duplicate frames completely, which simplifies the logic.
Agree here too.
and what about the timebase? the info stream timbase cannot be every timebase, it cant be their lcm either as that would overflow the max num/den sizes and after you solved that, what about remuxing from info frames to packets everyone except rich will use msec based info streams which will have msec based chapter ends which you probably wont be able to specify in any other stream timebase ... do we need to keep the dummy info streams or just round the timestamps (yeah everyone WILL round them) [...] -- Michael
participants (3)
-
Michael Niedermayer -
Oded Shimon -
Rich Felker