[NUT-devel] info packets/frames

[Oded Shimon]

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 
> 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...
> 
> Locking the table is the opposite of extendiblity, it prevents us from ever 
> improoving... Though admittedly there is some non-extendiblity in growing 
> the tables as well, as it "breaks" old demuxers. But IMO no - ALL reserved 
> fields everywhere in NUT "break" old demuxers in that old demuxers do not 
> understand them - the same goes for new info table entries, they only break 
> in that they fail to understand themselves, but still keep everything else 
> intact.

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...

And no, making another packet type just for info tables is a bad idea. :/

- ods15