[NUT-devel] info packets/frames

Michael Niedermayer michaelni at gmx.at
Thu Feb 16 16:28:44 CET 2006


Hi

On Thu, Feb 16, 2006 at 08:01:38AM +0200, Oded Shimon wrote:
[...]
> > > > > > just store the f* table in the main header :)
> > > > > 
> > > > > Bleh. :) It's a nice solution, but it's somewhat bad in that it adds info 
> > > > > stuff in essential, small, main header (slightly defeating the purpose). 
> > > > > Also it makes it harder for us to enforce our premade headers... (utf-8, 
> > > > > etc.)
> > > > 
> > > > we cant enforce that anyway, just becaue it has utf-8 as type doensnt mean
> > > > it is utf8, if someone decides to ignore a rule in the spec which says only
> > > > utf-8 allowed, then he will care little about the type being enforced to utf-8
> > > > actually later is worse as its undetectable, so IMHO better give "them" an
> > > > option to specify that they violate the rules instead of making it impossible
> > > > to specify the type while obviously not preventing them from storing things
> > > > in their native encoding ...
> > > 
> > > That's somewhat a good point, but still not excuse enough IMO to put the 
> > > info types in the main header, it literally defeats the purpose - info 
> > > stuff goes in info packets, not in main headers...
> > 
> > then my vote is to simply not allow extending the table, its not needed
> > anyway to add new fields to info packets
> > 
> > you either have a fixed table or you store the table in the file
> 
> Is the problem old programs not understanding new fields? It's not a big 
> issue IMO...

if the id->string table is in the mainheader, every demuxer new and old
will support it, if its not in the main header and we dont force muxers to
use litteral strings as id then the values are not useable by old demuxers and
there simply is no need to be able to parse them, just skip the rest of the
info packet and require muxers to order fields by "age"
also note that such unknown metadata would be not transcodeable to other
containers, and even nut->nut might be hard over some (de)muxer APIs

also keep in mind not everone will update their sw every month to support the
new info types

[...]

-- 
Michael




More information about the NUT-devel mailing list