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