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