[NUT-devel] info packets/frames

Oded Shimon ods15 at ods15.dyndns.org
Wed Feb 15 16:14:25 CET 2006


On Wed, Feb 15, 2006 at 03:23:30PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Feb 15, 2006 at 12:59:50PM +0200, Oded Shimon wrote:
> > On Wed, Feb 15, 2006 at 11:25:13AM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Wed, Feb 15, 2006 at 10:34:04AM +0200, Oded Shimon wrote:
> > > > TotalTime is unecessary thanks to max_pts in index
> > > 
> > > ok
> > > 
> > > 
> > > > no more null termination of info packets
> > > 
> > > ok
> > > 
> > > 
> > > > stream_id coded sperately
> > > 
> > > ok if multiple stream_ids per info packet are possible
> > 
> > Hmm, no such possilbity, it's all or one... What's the usefulness?
> 
> just a factor of 10 reduction of overhead
> for example take a movie with a few audio and subtitle streams, then
> lets assume it does contain some info packets which apply to all the streams
> like the movie name, and various other metadata ...
> now add another audio stream of your favorite music as background music,
> none of the "global" info applies so you must duplicate all the info packets
> for every stream
> or add a fansubbed sutitle stream, many things like studio, producer, director
> and so on wont apply to it while they apply to all other streams

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?

> > > > seperate to 4 basic types for extendibility, now we can add new fields 
> > > > without breaking old demuxers
> > > 
> > > please elaborate
> > 
> > If someone makes up a new header, and we decide we like it and add it to 
> > info table, using the old method, old demuxers not knowing the new info 
> > entry would crap out on the entire info packet because of the v/vb stuff. 
> > With the type stuff, it can be done in backwards compatible way, lacking 
> > the demuxer just understand the new header...
> 
> 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.)

- ods15




More information about the NUT-devel mailing list