[MPlayer-dev-eng] NUT/menus proposal

[D Richard Felker III]

On Wed, Sep 15, 2004 at 12:45:40PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Wednesday 15 September 2004 08:31, D Richard Felker III wrote:
> > On Tue, Sep 14, 2004 at 12:42:47PM +0200, Michael Niedermayer wrote:
> > > iam not against placing menus outside nut, what iam against is the last
> > > change to info packets
> >
> > ok, that clarifies it a bit... but, if not for storing menus and such
> > in nut, can you explain to me what your requirements for info packets
> > are? i think this whole misunderstanding arose from us not
> > understanding what you want to accomplish with info packets.
> 
> info packets could be used for many things
> 1. chapters
> 2. scene description, like storing all the start/stop times where gandalf 
> appears or the start/stop time of commercials, that would be quite nice for 
> seeking
> 3. storing other data, like gps coordnates (that way u know where the spot 
> from the documentary is exactly, so u could easily visit it for example)
> 4. storing the (x,y) coordinates of an unimportant rectangle for subtitles for 
> the current scene
> 5. storing interlaced/pogressive/telecine flags
> 6. storing object descriptions, like the names+info+coordinates of vissible 
> plants, animals and the like for educational material
> 
> but the the most important thing is what we dont know yet, if nut really 
> spreads and is used by alot of people, nut will be used for alot of things we 
> didnt predict, and alot of what u call braindamaged now will turn out to be 
> the only possible solution to some problems

ok, thanks for some interesting examples! 
from what i can tell, none of your examples are stream-specific, but i
won't object to having a good way to info packets to be
stream-specific...

> > i'd be willing to add more flexibility back to info packets, but i
> > still think we should make metadata separate (and store it in the
> > stream headers) since it plays a very very different from generic
> > info. 
> 
> ok, (language, disposition, audio-gain in the stream header)

but not just those three things... i meant an extensible system in
case people come up with new metadata in the future.

> > and i'm against making info packets more flexible unless there 
> > seem to be good reasons for it, since they invite abuse...
> 
> and iam very strongly against putting limits in a format because we fail to 
> find a good example where its usefull
> as long as something doesnt add any comlexity and adds possibilities it should 
> be supported, possible abuse or braindamaged are IMHO weak arguments, 
> everything can be abused and everything is braindamaged from someones point 
> of view

ok. i don't mind leaving things open because we see a potential need.
what i do mind is adding a feature specifically for a misguided
purpose.

rich