[NUT-devel] info packets/frames

[Oded Shimon]

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)

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

And, well, let's hope no-one breaks the utf-8 rule.. :)

Actually, it's better - they can still violate with our "enforcing", but it 
will be expensive (overhead). So they will do it at their own expenses...

- ods15