This is my patch... Comments welcome, I hope this patch will please everyone... - ods15
Hi On Tue, Feb 21, 2006 at 01:11:30PM +0200, Oded Shimon wrote:
This is my patch... Comments welcome, I hope this patch will please everyone...
- ods15
Index: DOCS/tech/mpcf.txt =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v retrieving revision 1.108 diff -u -r1.108 mpcf.txt --- DOCS/tech/mpcf.txt 20 Feb 2006 04:49:06 -0000 1.108 +++ DOCS/tech/mpcf.txt 21 Feb 2006 11:10:19 -0000 @@ -262,21 +262,33 @@ checksum u(32)
info_frame: (optional) - for(;;){ - id v - if(id==0) break - name= info_table[id][0] - type= info_table[id][1] - if(type==NULL) + stream_id_plus1 v + chapter_id v + if (chapter_id) { + chapter_start v + if (chapter_id < 0) + chapter_len v
i would prefer of chapter_len is always coded when chapte_start is theres also the question of the length of the last chapter ...
+ } + count v + for(i=0; i<count; i++){ + name vb + value s + if (value==-1){ + type= "UTF-8" + value vb + }else if (value==-2){ type vb - if(name==NULL) - name vb - if(type=="v") - value v - else if(type=="s") - value s - else value vb + }else if (value==-3){ + type= "signed integer" + value s + }else if (value<-3){ + type= "rational" + value.den= -value-2 + value.num s
what advantage is there in the seperate "signed integer"? [...]
+chapter_start + s= chapter_start % stream_count + timestamp= chapter_start / stream_count + timestamp of start of chapter in timebase of stream 's'. + Positive chapter_id's MUST be in sequential order.
IMHO chapter_start should be in the timebase of stream s if the info packet applies just to that stream [...]
image of the (CD, DVD, VHS, ..) cover (preferably PNG or JPEG) "Source" "DVD", "VCD", "CD", "MD", "FM radio", "VHS", "TV", "LD" @@ -640,8 +666,6 @@ (ISO 8601 format, see http://www.cl.cam.ac.uk/~mgk25/iso-time.html) Note: do not forget the timezone "Keywords" - "TotalTime" - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ... [...] -- Michael
On Tue, Feb 21, 2006 at 11:04:36PM +0100, Michael Niedermayer wrote:
info_frame: (optional) - for(;;){ - id v - if(id==0) break - name= info_table[id][0] - type= info_table[id][1] - if(type==NULL) + stream_id_plus1 v + chapter_id v + if (chapter_id) { + chapter_start v + if (chapter_id < 0) + chapter_len v
i would prefer of chapter_len is always coded when chapte_start is theres also the question of the length of the last chapter ...
I'm confused about the intent of the above stuff..
+ }else if (value==-3){ + type= "signed integer" + value s + }else if (value<-3){ + type= "rational" + value.den= -value-2 + value.num s
what advantage is there in the seperate "signed integer"?
I think the idea was that the program would know how to interpret it and display it even if it wasn't aware of the field's contents.
+chapter_start + s= chapter_start % stream_count + timestamp= chapter_start / stream_count + timestamp of start of chapter in timebase of stream 's'. + Positive chapter_id's MUST be in sequential order.
IMHO chapter_start should be in the timebase of stream s if the info packet applies just to that stream
Is there a reasonable justification for chapters that apply to just one stream?
- "TotalTime" - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ...
I thought it was our intent that index would not be "optional". IIRC I suggested defining in the spec a 'NUT stream authored for permenant storage' or something similar, and requiring such a stream to conform to several conditions such as: repeated headers, index present, ... The idea is that a partially written, truncated, streamed, etc. NUT file would not be a a "NUT stream authored for permenant storage" and would not be subject to these requirements, but NUTlint would check these things and indicate to the user that the file is not conformant to the more restrictive requirements. BTW in the case of a truncated file where the index is lost, knowing TotalTime is not useful anyway since it will be wrong. Rich
On Tue, Feb 21, 2006 at 07:26:07PM -0500, Rich Felker wrote:
On Tue, Feb 21, 2006 at 11:04:36PM +0100, Michael Niedermayer wrote:
info_frame: (optional) - for(;;){ - id v - if(id==0) break - name= info_table[id][0] - type= info_table[id][1] - if(type==NULL) + stream_id_plus1 v + chapter_id v + if (chapter_id) { + chapter_start v + if (chapter_id < 0) + chapter_len v
i would prefer of chapter_len is always coded when chapte_start is theres also the question of the length of the last chapter ...
I'm confused about the intent of the above stuff..
Positive chapter_id are real chapters. Negative chapter_id are subregions that have nothing to do with chapters, and the chapter_id is a unique ID for them. And, I wanted chapter_len to be implicit from the start of the next chapter to avoid redundancy and confusing the player... The last chapter is rather obvious - it ends when the file ends. The only disadvantage I see to chapter_len being implicit is that it relies on another info packet, but actually IMO this is better, if you lost one packet, then the chapter before it automatically spans to the next chapter...
+ }else if (value==-3){ + type= "signed integer" + value s + }else if (value<-3){ + type= "rational" + value.den= -value-2 + value.num s
what advantage is there in the seperate "signed integer"?
I think the idea was that the program would know how to interpret it and display it even if it wasn't aware of the field's contents.
Yeah, this adds no space or trouble but is more "clear". A signed integer is different from a fraction...
+chapter_start + s= chapter_start % stream_count + timestamp= chapter_start / stream_count + timestamp of start of chapter in timebase of stream 's'. + Positive chapter_id's MUST be in sequential order.
IMHO chapter_start should be in the timebase of stream s if the info packet applies just to that stream
Is there a reasonable justification for chapters that apply to just one stream?
Yeah I hardly ever relly see a use for this, which is why I wanted to avoid the extra complexity of having it coded differently.
- "TotalTime" - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ...
I thought it was our intent that index would not be "optional". IIRC I suggested defining in the spec a 'NUT stream authored for permenant storage' or something similar, and requiring such a stream to conform to several conditions such as: repeated headers, index present, ...
The idea is that a partially written, truncated, streamed, etc. NUT file would not be a a "NUT stream authored for permenant storage" and would not be subject to these requirements, but NUTlint would check these things and indicate to the user that the file is not conformant to the more restrictive requirements.
BTW in the case of a truncated file where the index is lost, knowing TotalTime is not useful anyway since it will be wrong.
If you want "TotalTime" back I don't object, I personally saw it as obsoleted the moment index got max_pts . I forgot to add a note in the patch - all info packets with the same stream id and chapter id must be binary identical. - ods15
Hi On Tue, Feb 21, 2006 at 07:26:07PM -0500, Rich Felker wrote: [...]
+ }else if (value==-3){ + type= "signed integer" + value s + }else if (value<-3){ + type= "rational" + value.den= -value-2 + value.num s
what advantage is there in the seperate "signed integer"?
I think the idea was that the program would know how to interpret it and display it even if it wasn't aware of the field's contents.
ok
+chapter_start + s= chapter_start % stream_count + timestamp= chapter_start / stream_count + timestamp of start of chapter in timebase of stream 's'. + Positive chapter_id's MUST be in sequential order.
IMHO chapter_start should be in the timebase of stream s if the info packet applies just to that stream
Is there a reasonable justification for chapters that apply to just one stream?
no, probably not "chapters" but chapters are the only way to specifiy start/stop times so if we want to allow describing a start/stop/stream ...
- "TotalTime" - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ...
I thought it was our intent that index would not be "optional". IIRC I suggested defining in the spec a 'NUT stream authored for permenant storage' or something similar, and requiring such a stream to conform to several conditions such as: repeated headers, index present, ...
The idea is that a partially written, truncated, streamed, etc. NUT file would not be a a "NUT stream authored for permenant storage" and would not be subject to these requirements, but NUTlint would check these things and indicate to the user that the file is not conformant to the more restrictive requirements.
BTW in the case of a truncated file where the index is lost, knowing TotalTime is not useful anyway since it will be wrong.
and the chapter lengthes? its a PITA to go and read the index to find the last chapter length [...] -- Michael
On Wed, Feb 22, 2006 at 03:15:24PM +0100, Michael Niedermayer wrote:
On Tue, Feb 21, 2006 at 07:26:07PM -0500, Rich Felker wrote:
- "TotalTime" - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ...
I thought it was our intent that index would not be "optional". IIRC I suggested defining in the spec a 'NUT stream authored for permenant storage' or something similar, and requiring such a stream to conform to several conditions such as: repeated headers, index present, ...
The idea is that a partially written, truncated, streamed, etc. NUT file would not be a a "NUT stream authored for permenant storage" and would not be subject to these requirements, but NUTlint would check these things and indicate to the user that the file is not conformant to the more restrictive requirements.
BTW in the case of a truncated file where the index is lost, knowing TotalTime is not useful anyway since it will be wrong.
and the chapter lengthes? its a PITA to go and read the index to find the last chapter length
I'm ok with bringing back 'totaltime' or having some other solution for having the length for the last chapter... Other than this, can I commit the patch? Are there any comments left? - ods15
On Thu, Feb 23, 2006 at 12:10:13PM +0200, Oded Shimon wrote:
On Wed, Feb 22, 2006 at 03:15:24PM +0100, Michael Niedermayer wrote:
On Tue, Feb 21, 2006 at 07:26:07PM -0500, Rich Felker wrote:
- "TotalTime" - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ...
I thought it was our intent that index would not be "optional". IIRC I suggested defining in the spec a 'NUT stream authored for permenant storage' or something similar, and requiring such a stream to conform to several conditions such as: repeated headers, index present, ...
The idea is that a partially written, truncated, streamed, etc. NUT file would not be a a "NUT stream authored for permenant storage" and would not be subject to these requirements, but NUTlint would check these things and indicate to the user that the file is not conformant to the more restrictive requirements.
BTW in the case of a truncated file where the index is lost, knowing TotalTime is not useful anyway since it will be wrong.
and the chapter lengthes? its a PITA to go and read the index to find the last chapter length
I'm ok with bringing back 'totaltime' or having some other solution for having the length for the last chapter...
Why not just store the length in the info??? This is where they belong. If someone has indexed segments of the file as chapters, they probably want an idea of total time. If not the file should be treated as a pure stream and TotalTime is nonsense. In the trivial case where someone wants TotalTime but no chapter divisions they can just make one big chapter/segment. Rich
On Thu, Feb 23, 2006 at 12:11:25PM -0500, Rich Felker wrote:
On Thu, Feb 23, 2006 at 12:10:13PM +0200, Oded Shimon wrote:
On Wed, Feb 22, 2006 at 03:15:24PM +0100, Michael Niedermayer wrote:
On Tue, Feb 21, 2006 at 07:26:07PM -0500, Rich Felker wrote:
- "TotalTime" - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ...
I thought it was our intent that index would not be "optional". IIRC I suggested defining in the spec a 'NUT stream authored for permenant storage' or something similar, and requiring such a stream to conform to several conditions such as: repeated headers, index present, ...
The idea is that a partially written, truncated, streamed, etc. NUT file would not be a a "NUT stream authored for permenant storage" and would not be subject to these requirements, but NUTlint would check these things and indicate to the user that the file is not conformant to the more restrictive requirements.
BTW in the case of a truncated file where the index is lost, knowing TotalTime is not useful anyway since it will be wrong.
and the chapter lengthes? its a PITA to go and read the index to find the last chapter length
I'm ok with bringing back 'totaltime' or having some other solution for having the length for the last chapter...
Why not just store the length in the info??? This is where they belong. If someone has indexed segments of the file as chapters, they probably want an idea of total time. If not the file should be treated as a pure stream and TotalTime is nonsense. In the trivial case where someone wants TotalTime but no chapter divisions they can just make one big chapter/segment.
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's.. Can I commit this patch? - ods15
On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Is it your intent that negative chapter id's need to be unique? IMO either type of chapter id makes sense in info frames, but storing chapters in info frames rather than packets should be discouraged except for streaming purposes. On the other hand, maybe it's preferable not to call those divisions chapters at all. I'm not sure. I'm just motivated partially by the idea that remuxing a stream to a permenant-storage file could be done without examining or alterring the info frames other than replacing them by info packets, but maybe this is a stupid goal.
Can I commit this patch?
Ask Michael. IMO it's mostly ok. See below.
+chapter_id + Id of chapter this packet applies to. If zero, packet applies to whole + file. Positive chapter_id's are real chapters and MUST NOT overlap. + Negative chapter_id indicate a sub region of file and not a real + chapter. chapter_id MUST be unique to the region it represents. + +chapter_start + s= chapter_start % stream_count + timestamp= chapter_start / stream_count + timestamp of start of chapter in timebase of stream 's'. + +chapter_len + Length of chapter in same timebase of chapter_start.
Maybe this is annoying for players, but I wonder if the timebases don't need to be allowed to differ to allow exact cutting between any two frames of the file.
+ "Cover" (allowed types are "PNG" and "JPEG") image of the (CD, DVD, VHS, ..) cover (preferably PNG or JPEG)
I wouldn't mind removing this and letting people who want it include it as an extension (X-Cover). I'm hesitant to recommend such a bloated practice as storing 'attachments' in a NUT file.
+Info: +----- + +All info packets with the same chapter_id and stream_id are repeated info +packets and MUST be binary identical. + +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.
OK. This answers the question above. Rich
Hi On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
On Thu, Feb 23, 2006 at 12:11:25PM -0500, Rich Felker wrote:
On Thu, Feb 23, 2006 at 12:10:13PM +0200, Oded Shimon wrote:
On Wed, Feb 22, 2006 at 03:15:24PM +0100, Michael Niedermayer wrote:
On Tue, Feb 21, 2006 at 07:26:07PM -0500, Rich Felker wrote:
> - "TotalTime" > - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ...
I thought it was our intent that index would not be "optional". IIRC I suggested defining in the spec a 'NUT stream authored for permenant storage' or something similar, and requiring such a stream to conform to several conditions such as: repeated headers, index present, ...
The idea is that a partially written, truncated, streamed, etc. NUT file would not be a a "NUT stream authored for permenant storage" and would not be subject to these requirements, but NUTlint would check these things and indicate to the user that the file is not conformant to the more restrictive requirements.
BTW in the case of a truncated file where the index is lost, knowing TotalTime is not useful anyway since it will be wrong.
and the chapter lengthes? its a PITA to go and read the index to find the last chapter length
I'm ok with bringing back 'totaltime' or having some other solution for having the length for the last chapter...
Why not just store the length in the info??? This is where they belong. If someone has indexed segments of the file as chapters, they probably want an idea of total time. If not the file should be treated as a pure stream and TotalTime is nonsense. In the trivial case where someone wants TotalTime but no chapter divisions they can just make one big chapter/segment.
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Can I commit this patch?
ok [...] -- Michael
On Fri, Feb 24, 2006 at 01:39:00AM +0100, Michael Niedermayer wrote:
On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Can I commit this patch?
ok
committed, with one additional clause: +Info SHOULD be stored in global packets instead of info streams/frames if +possible, and the amount of data is not large. Taken from Michael's phrasing a while ago... Now, my idea for info frames - exactly the same as info packets. The pts for info frames is completely meaningless, it's only there to be able to comply to MN rule, so there can be repeated info frames, that describe the same "chapter", and you can see that they are the same info frame because they have the same chapter id, which means they must be binary identical. Nothing to modify in spec for this, but should probably be hinted that this is the way to do it... - ods15
On Fri, Feb 24, 2006 at 07:45:36AM +0200, Oded Shimon wrote:
On Fri, Feb 24, 2006 at 01:39:00AM +0100, Michael Niedermayer wrote:
On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Can I commit this patch?
ok
committed, with one additional clause: +Info SHOULD be stored in global packets instead of info streams/frames if +possible, and the amount of data is not large.
Taken from Michael's phrasing a while ago...
Now, my idea for info frames - exactly the same as info packets. The pts for info frames is completely meaningless, it's only there to be able to comply to MN rule, so there can be repeated info frames, that describe the same "chapter", and you can see that they are the same info frame because they have the same chapter id, which means they must be binary identical.
I'm against it, unless you're proposing that we remove info streams entirely.. This completely nullifies the stream-quality of info streams. There's no guarantee that you'll have the frame by the time it becomes relevant, or that it won't appear way before it's relevant, etc. Rather, I would _like_ to do like this: info frames have no chapter_start or chapter_len because these values are implicit in their frame pts and the next frame pts (possibly EOR). However, this creates nasty issues for seeking without index, as back_ptr could be huge. Maybe we should just exclude info from back_ptr..? Certainly chapter=0 (global) should be invalid in info frames. Rich
Hi On Fri, Feb 24, 2006 at 01:45:46AM -0500, Rich Felker wrote:
On Fri, Feb 24, 2006 at 07:45:36AM +0200, Oded Shimon wrote:
On Fri, Feb 24, 2006 at 01:39:00AM +0100, Michael Niedermayer wrote:
On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Can I commit this patch?
ok
committed, with one additional clause: +Info SHOULD be stored in global packets instead of info streams/frames if +possible, and the amount of data is not large.
Taken from Michael's phrasing a while ago...
Now, my idea for info frames - exactly the same as info packets. The pts for info frames is completely meaningless, it's only there to be able to comply to MN rule, so there can be repeated info frames, that describe the same "chapter", and you can see that they are the same info frame because they have the same chapter id, which means they must be binary identical.
I'm against it, unless you're proposing that we remove info streams entirely.. This completely nullifies the stream-quality of info streams. There's no guarantee that you'll have the frame by the time it becomes relevant, or that it won't appear way before it's relevant, etc.
Rather, I would _like_ to do like this: info frames have no chapter_start or chapter_len because these values are implicit in their frame pts and the next frame pts (possibly EOR). However, this
iam against this, info frames and info packets should be identical so we can remux info stream stuff into info packets if we want to or the other way around without looking at the contents furthermore if we start playing in the middle of a chapter we will need some repeated info frames to figure out what we see IMHO the following rules might be ok * the pts of a info frame MUST be >= chapter_start and <= chapter_start + len * if a info stream contains a info frame for chapter X then it MUST contain a info frame with pts==chapter_start
creates nasty issues for seeking without index, as back_ptr could be huge. Maybe we should just exclude info from back_ptr..?
disagree, repeat it or store as a info packet after the headers
Certainly chapter=0 (global) should be invalid in info frames.
agree [...] -- Michael
On Fri, Feb 24, 2006 at 02:31:15PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Feb 24, 2006 at 01:45:46AM -0500, Rich Felker wrote:
On Fri, Feb 24, 2006 at 07:45:36AM +0200, Oded Shimon wrote:
On Fri, Feb 24, 2006 at 01:39:00AM +0100, Michael Niedermayer wrote:
On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Can I commit this patch?
ok
committed, with one additional clause: +Info SHOULD be stored in global packets instead of info streams/frames if +possible, and the amount of data is not large.
Taken from Michael's phrasing a while ago...
Now, my idea for info frames - exactly the same as info packets. The pts for info frames is completely meaningless, it's only there to be able to comply to MN rule, so there can be repeated info frames, that describe the same "chapter", and you can see that they are the same info frame because they have the same chapter id, which means they must be binary identical.
I'm against it, unless you're proposing that we remove info streams entirely.. This completely nullifies the stream-quality of info streams. There's no guarantee that you'll have the frame by the time it becomes relevant, or that it won't appear way before it's relevant, etc.
Rather, I would _like_ to do like this: info frames have no chapter_start or chapter_len because these values are implicit in their frame pts and the next frame pts (possibly EOR). However, this
iam against this, info frames and info packets should be identical so we can remux info stream stuff into info packets if we want to or the other way around without looking at the contents furthermore if we start playing in the middle of a chapter we will need some repeated info frames to figure out what we see
IMHO the following rules might be ok * the pts of a info frame MUST be >= chapter_start and <= chapter_start + len
"compared in a common timebase"
* if a info stream contains a info frame for chapter X then it MUST contain a info frame with pts==chapter_start
Yes I had the exact same idea.
creates nasty issues for seeking without index, as back_ptr could be huge. Maybe we should just exclude info from back_ptr..?
disagree, repeat it or store as a info packet after the headers
Don't forget the restriction I made, you can't make up info packets as you please, if they appear anywhere, they MUST appear at begginning of file as well. We should also mention EOR is allowed in info streams.. And it has no real meaning except keeping back_ptr sane. - ods15
On Fri, Feb 24, 2006 at 02:31:15PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Feb 24, 2006 at 01:45:46AM -0500, Rich Felker wrote:
On Fri, Feb 24, 2006 at 07:45:36AM +0200, Oded Shimon wrote:
On Fri, Feb 24, 2006 at 01:39:00AM +0100, Michael Niedermayer wrote:
On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Can I commit this patch?
ok
committed, with one additional clause: +Info SHOULD be stored in global packets instead of info streams/frames if +possible, and the amount of data is not large.
Taken from Michael's phrasing a while ago...
Now, my idea for info frames - exactly the same as info packets. The pts for info frames is completely meaningless, it's only there to be able to comply to MN rule, so there can be repeated info frames, that describe the same "chapter", and you can see that they are the same info frame because they have the same chapter id, which means they must be binary identical.
I'm against it, unless you're proposing that we remove info streams entirely.. This completely nullifies the stream-quality of info streams. There's no guarantee that you'll have the frame by the time it becomes relevant, or that it won't appear way before it's relevant, etc.
Rather, I would _like_ to do like this: info frames have no chapter_start or chapter_len because these values are implicit in their frame pts and the next frame pts (possibly EOR). However, this
iam against this, info frames and info packets should be identical so we can remux info stream stuff into info packets if we want to or the other way around without looking at the contents furthermore if we start playing in the middle of a chapter we will need some repeated info frames to figure out what we see
If you're against this adamantly then we might as well remove info streams entirely, since your objections ruin the whole stream property of info streams that I wanted them for. The problem is this: if you have a reason to use info streams instead of info packets at the header, it's because chapter length is NOT known at the time the first info frame for the 'chapter' is written. Consider something like a like news show where the info is produced by someone at the studio at the same time it's being transmitted. A simpler more realistic example would be a live net radio show with DJ segments (unknown length) and songs (known length). I have a proposal that works, IMO. It requires some alterrations to convert info frames to info packets, but ONLY in the header (chapter start/length), not any of the contents (key/value pairs). It works like: 1. All info frames with the same chapter id must be binary identical. 2. The first info frame with a given chapter id determines the start time of the chapter from its pts. 3. An info frame with different chapter id (or EOR) marks the end time of the previous chapter. Info frames with same chapter id are just repetition and have no other meaning. This scheme allows full stream-type semantics for info frames, so that they work as intended. Oded had an alternate proposal of just storing 0 as the chapter length if it's unknown. I objected to this because it's lossy, i.e. these chapters, like all chapters, _do_ have a length; it's just not known until further along in the stream. Surely it could be stored in other ways (like key/value pairs), but this precludes easy remuxing chapter information from a live stream into chapter information for a permenant file, since you'd have to parse special keys. One objection you may have to my scheme is that it precludes overlapping chapter spans. I thought this was a problem too and didn't like it at first, but then Oded pointed out that you can use more than one info stream if you need to (the above points 2-3 should be interpreted only within a single given stream). Comments? Rich
Hi On Fri, Feb 24, 2006 at 04:59:58PM -0500, Rich Felker wrote:
On Fri, Feb 24, 2006 at 02:31:15PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Feb 24, 2006 at 01:45:46AM -0500, Rich Felker wrote:
On Fri, Feb 24, 2006 at 07:45:36AM +0200, Oded Shimon wrote:
On Fri, Feb 24, 2006 at 01:39:00AM +0100, Michael Niedermayer wrote:
On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Can I commit this patch?
ok
committed, with one additional clause: +Info SHOULD be stored in global packets instead of info streams/frames if +possible, and the amount of data is not large.
Taken from Michael's phrasing a while ago...
Now, my idea for info frames - exactly the same as info packets. The pts for info frames is completely meaningless, it's only there to be able to comply to MN rule, so there can be repeated info frames, that describe the same "chapter", and you can see that they are the same info frame because they have the same chapter id, which means they must be binary identical.
I'm against it, unless you're proposing that we remove info streams entirely.. This completely nullifies the stream-quality of info streams. There's no guarantee that you'll have the frame by the time it becomes relevant, or that it won't appear way before it's relevant, etc.
Rather, I would _like_ to do like this: info frames have no chapter_start or chapter_len because these values are implicit in their frame pts and the next frame pts (possibly EOR). However, this
iam against this, info frames and info packets should be identical so we can remux info stream stuff into info packets if we want to or the other way around without looking at the contents furthermore if we start playing in the middle of a chapter we will need some repeated info frames to figure out what we see
If you're against this adamantly then we might as well remove info streams entirely, since your objections ruin the whole stream property of info streams that I wanted them for. The problem is this: if you have a reason to use info streams instead of info packets at the header, it's because chapter length is NOT known at the time the first info frame for the 'chapter' is written. Consider something like a like news show where the info is produced by someone at the studio at the same time it's being transmitted. A simpler more realistic example would be a live net radio show with DJ segments (unknown length) and songs (known length).
IMHO the issue is more complex, your argumentation that chapter length isnt known (and i fully agree that there are realistic cases where its not known) can be applied to many other things too with your DJ example, things like genre or artist would be examples maybe simply allowing adding but not removing stuff from info packets would be the solution ...
I have a proposal that works, IMO. It requires some alterrations to convert info frames to info packets, but ONLY in the header (chapter start/length), not any of the contents (key/value pairs). It works like:
1. All info frames with the same chapter id must be binary identical. 2. The first info frame with a given chapter id determines the start time of the chapter from its pts. 3. An info frame with different chapter id (or EOR) marks the end time of the previous chapter. Info frames with same chapter id are just repetition and have no other meaning.
so a single lost info frames will mess up 2 chapters, while with my suggestion all info frames of a chapter need to be lost to loose any information [...]
One objection you may have to my scheme is that it precludes overlapping chapter spans. I thought this was a problem too and didn't like it at first, but then Oded pointed out that you can use more than one info stream if you need to (the above points 2-3 should be interpreted only within a single given stream).
1 stream: actual chapters 2 stream: start/stop of commercial/advertisements single EOR in stream 2 is lost -> whole chapter becomes marked as a commercial [...] -- Michael
On Sat, Feb 25, 2006 at 11:52:42AM +0100, Michael Niedermayer wrote:
IMHO the issue is more complex, your argumentation that chapter length isnt known (and i fully agree that there are realistic cases where its not known) can be applied to many other things too with your DJ example, things like genre or artist would be examples
No, you just use a new 'chapter' span when this information changes..
maybe simply allowing adding but not removing stuff from info packets would be the solution ...
You mean dropping info frames and using info packets for this?
I have a proposal that works, IMO. It requires some alterrations to convert info frames to info packets, but ONLY in the header (chapter start/length), not any of the contents (key/value pairs). It works like:
1. All info frames with the same chapter id must be binary identical. 2. The first info frame with a given chapter id determines the start time of the chapter from its pts. 3. An info frame with different chapter id (or EOR) marks the end time of the previous chapter. Info frames with same chapter id are just repetition and have no other meaning.
so a single lost info frames will mess up 2 chapters, while with my suggestion all info frames of a chapter need to be lost to loose any information
No, a single lost info frame will not cause any nonlocal problems. At worst the previous chapter artificially extends further forward than it should.
One objection you may have to my scheme is that it precludes overlapping chapter spans. I thought this was a problem too and didn't like it at first, but then Oded pointed out that you can use more than one info stream if you need to (the above points 2-3 should be interpreted only within a single given stream).
1 stream: actual chapters 2 stream: start/stop of commercial/advertisements
single EOR in stream 2 is lost -> whole chapter becomes marked as a commercial
For streaming content you will repeat all headers/info often, including EOR since a newly connecting client will need them. Anyway, let me know the second you find someone willing to _flag_ their commercials as commercials so clients can auto-ignore them!! I'll be the first to start listening/watching! ;) Rich
Hi On Sat, Feb 25, 2006 at 06:27:26AM -0500, Rich Felker wrote:
On Sat, Feb 25, 2006 at 11:52:42AM +0100, Michael Niedermayer wrote:
IMHO the issue is more complex, your argumentation that chapter length isnt known (and i fully agree that there are realistic cases where its not known) can be applied to many other things too with your DJ example, things like genre or artist would be examples
No, you just use a new 'chapter' span when this information changes..
maybe simply allowing adding but not removing stuff from info packets would be the solution ...
You mean dropping info frames and using info packets for this?
no, s/packets/frames/ (i meant allow adding fields to info frames) [...] -- Michael
participants (3)
-
Michael Niedermayer -
Oded Shimon -
Rich Felker