[NUT-devel] info packets/frames

[Michael Niedermayer]

Hi

On Wed, Feb 15, 2006 at 08:05:19PM +0200, Oded Shimon wrote:
> On Wed, Feb 15, 2006 at 05:46:37PM +0100, Michael Niedermayer wrote:
> > On Wed, Feb 15, 2006 at 05:14:25PM +0200, Oded Shimon wrote:
> > > This may be a question of opinion, but IMO "producor/author/title" etc. 
> > > still apply to all streams/entire file, and then maybe you have a packet
> > > applied to the subtitle stream. Infact, "director" makes no sense to apply 
> > > to any stream, it's not a video thing or audio thing, it's a movie (as in, 
> > > entire file) thing. But I do see your point, do you have a suggestion for 
> > > how to code it? (in stream, using vlc's. not in C code :)
> > > Maybe a bitmask? 0 meaning all streams?
> > 
> > hmmmmmm, what about 
> > 
> > decompress_element(a, i, count)
> >     type                   v
> >     x= type>>1;
> >     if(type&1){
> >         x>>=1
> >         while(x--)
> >             a[i++] = !!(type&2)
> >         a[i++] = !(type&2);
> >     }else{
> >         while(x != 1){
> >             a[i++] = x&1;
> >             x>>=1;
> >         }
> >     }
> >     return i
> 
> Warning: `count' unused parameter. :) Maybe you meant to put the loop here?
> 
> > and then use this for both the index (we aleady do ...) and info packets
> > 
> > info_packet
> >     for(i=0; i<stream_count; )
> >         i= decompress_element(streams, i, stream_count)
> 
> I dislike it. For this purpose, a pure bitmask with special case 0 is good 
> enough... It's not quite a complication but it is simply not worth it...
> (bitmask has the slight disadvantage of overflowing, but seriously, 64 
> streams... Worst pathological scenario I can think of is 30 streams, 20 
> subtitles and 10 audio tracks)

a limitation to 30-60 streams is not acceptable


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

[...]
-- 
Michael