[MPlayer-dev-eng] NUT/menus proposal

[Michael Niedermayer]

Hi

On Thursday 16 September 2004 01:02, D Richard Felker III wrote:
> On Wed, Sep 15, 2004 at 08:07:01PM +0200, Michael Niedermayer wrote:
> > Hi
> >
> > On Wednesday 15 September 2004 15:57, D Richard Felker III wrote:
> > [...]
> >
> > > > > 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.
> >
> > metadata should be stored in info packets, thats their propose,
> > originally my
>
> i disagree strongly. there are two types of metadata: stuff that is
> essential in order for the player to be able to present the movie in a
> sane way (playing the director's commentary track by default is not
> sane!) and "extra" stuff that can be useful to the user but that's
> nonessential. putting required data in info packets is very
> misleading, imo.

while i fully agree that playing the directors commentary by default is sick, 
this has no relation to the location where we store the fact that a stream is 
useless commentary, in neither case would it be played by default


>
> > idea was that the all packets except info packets should only contain
> > data which is actually needed for decoding&demuxing
> > maybe the attached patch would change the pre-messup nut spec in an
> > acceptable way?
>
> no, imo it makes it worse.
>
> one thing, can we please all agree to s/ReplayGain/Gain/? 

certainly, just change it, iam not sure why it was called ReplayGain in nut at 
all


[...]

>
> now, more to the issue of the actual spec. lots of the info you talked
> about potentially putting inside a nut file in your last email was
> _good_ stuff to put in, but info packets are the wrong place. i 
> realize this now that i see the spec. for instance, if you want to
> describe the animals in a video with labels for polygon outlines in
> certain frame ranges, you're going to run into a problem. that's a
> huge amount of data all in info packets at the beginning of the file
> (and possibly repeated later as backups?) that the player is going to
> have to load all into memory when it starts (if it wants to use that
> data). otherwise it will be rapidly seeking back and forth, and that
> will be very bad! you also have the issue that info packets will have
> multiple copies for backup...but if the data in info packets is very
> large like this, why is it worth it to make backups of the large
> non-essential info, but not of the video itself?!

why should they be at the beginning?! 

[further flames based upon false assumetation that info packets are all at the 
beginning]

[...]
> anyway, if it would make you happy, here is what i would propose at
> this point in the discussion:
>
> - define in the nut spec a "key/value list" data type.
>
> - put a data structure of this type in the stream header for essential
>   metadata.

please explain why "essential" stream metadata should be handled different 
from other types of metadata, and please define what "essential" stream 
metadata is, in some cases its obvious like marking commentary streams, but 
often its not, for example is the author/fansubber group of a subtitle stream 
essential?
i also have a bad feeling about other people (especially the type liking 
GUI+menus) adding new metadata keys, IMO they will almost certainly have a 
different opinion about essentiality even if its clearly specified ...

>
> - define an info packet as a packet containing two key/value list data
>   structures: the first one specifying what part of the file it
>   applies to (keys like starttime, endtime, streamid, ...) and the
>   second list specifying the information itself (title, description,
>   author, ...).
>
> imo this definition of info packets is similar to what we started out
> with, except there is a proper distinction between what the packet
> applies to, and the data inside the packet. i don't like the change
> you just proposed because there were lots of arbitrary special cases
> for the types of info packets you were considering, and they probably
> won't be sufficient in the future.

hmm, i thought u wanted to limit info packets as much as possible to avoid 
abuse, this was never something i wanted, the suggested change was just 
supposed to be a compromise, but if u just want a cosmetic change of 
splitting the list of key-values into 2, thats fine, it requires an 
additional end marker (useless overhead ...) or would u agree that we 
terminate list1 by the first occurrence of a list2 entry? 


[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();  (violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535)
buf[i]= qp - buf[i-1];    (violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en