[NUT-devel] info packets/frames

[Michael Niedermayer]

Hi

On Sat, Feb 18, 2006 at 04:34:35PM +0200, Oded Shimon wrote:
[...]
> > > > 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
> 
> Many containers have ID-to-metadata mappings, and they are fairly static. 
> If we have found a way to do this while still being able to, in the far 
> future, add new fields, then why not...
> 
> I think the only gripe I have with writing the table in some header, is, 
> besides the complexity, the fact that we don't have a pre-made table with 
> common fields and prepared with "UTF-8" and etc. Id's are more consistent 
> than names (some muxer might goof up and use Titel instead of Title, and 
> then demuxers won't understand it...).

right, now if only they made the C standard use random ids instead of english
words the world would be a better place ...
and please keep in mind C is written by people who make mistakes, nut files
are written by muxers which are less likely to mess up, and such messup is
detectable
and last thing, why exactly should title vs. titel be a more likely messup
then 5 vs. 6 ?! not to mention later is not detectable while a unknown name
with no X- infront is detectable


> 
> > > 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?
> 
> I'm downloading the file with bittorrent, I only have one copy of the main 
> headers, and because of its size it just ended up being on a block 
> boundry..

in that case i suspect your solution will put one stream header at 
that block bouandary


> I'm surprised, you were very high strong about all other packets '1 byte 
> should cause minimal data loss, even in essential repeated headers', which 
> is why we still have stream_id in stream headers..

index packets are 100kb while the mainheader is <1kb, the mainheader must be
there at least 3 times the index in most cases will be in the file just once

[...]
-- 
Michael