[NUT-devel] Patch for info packets

Michael Niedermayer michaelni at gmx.at
Wed Feb 22 15:15:24 CET 2006


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




More information about the NUT-devel mailing list