[NUT-devel] info packets/frames

Michael Niedermayer michaelni at gmx.at
Sat Feb 18 15:14:44 CET 2006


Hi

On Sat, Feb 18, 2006 at 02:19:00PM +0200, Oded Shimon wrote:
> On Sat, Feb 18, 2006 at 01:57:25PM +0200, Oded Shimon wrote:
> > On Sat, Feb 18, 2006 at 12:28:59PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Sat, Feb 18, 2006 at 10:02:48AM +0200, Oded Shimon wrote:
> > > [...]
> > > > I still have one major issue left with info packets - chapters... We need 
> > > > to decide a sane way to do them and say so in the spec... But that's after 
> > > > we all agree on this patch. Does anyone have objections left...
> > > 
> > > i am against it, my oppinion is either store the table in the file or make it
> > > constant, or propose to drop "extendible" from the goals first
> > 
> > :/
> > 
> > Putting the tables in the main header is very very weird. It doesn't belong 

thats my favorite reasoning why something is bad (its weird, philosophical
wrong, not unixish, ...)

btw, you can also put them in an info packet of course if you prefer ...


> > there, it makes it more difficult to mux because even for info streams you 
> > have to know all your fields before hand (or, i guess you always have the 
> > option of using the fields directly in the info packets), it's also tricky 
> > when combining 2 nut files or something...

huh what?! a muxer would probably have a fixed table which it writes ...
_this_ is the equivalent to your suggestion, not designing a optimal
table which isnt needed at all and has negligable gain

the info packets are string name + type + value triplets, the table is
a optimization to reduce the size, i vote for droping the table completely
way before i agree to allowing changing the table without storing it in the
file, the table was never intended to be changable, if you insist on changing
it it must be stored in the file


[...]

> BTW, following your philosophy - the info tables in the main header can 
> triple the size of the main header (or even more), and a single byte of 
> damage in this non essential info would break the entire main header and 
> make the file unplayable...

you do remember that nut files have a minimum of 3 duplicate main headers?


[...]
-- 
Michael




More information about the NUT-devel mailing list