[NUT-devel] Patch for info packets

[Oded Shimon]

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