[MPlayer-dev-eng] NUT/menus proposal

[D Richard Felker III]

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.

> 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/? ReplayGain
is a proper noun, the name of a (proprietary?) piece of windows
software, and does not belong in the nut spec or any official spec.
the word Gain accomplishes the exact same meaning without having
"intellectual property" issues associated with it. imo it's the same
issue as using the term "Photocopy" versus "Xerox". the latter may be
popular slang for the generic term, but it's also someone's trademark
and bound to get you in trouble...

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

for this type of application, i think the solution is very obvious.
you don't have static info packets at the head of the file. instead
you have a special type of stream, interleaved with audio and video
and subs. this way the data is available right when you need it; you
don't have to preload it all at once. and, timestamps are exact (i
doubt info packet timestamps will be very exact) so you know for sure
which polygon outline goes with which frame, rather than having to
guess.

imo putting a huge list of time ranges and polygon vertices at the
beginning of a movie file is just as bad as putting a complete .ssa
file at the beginning of the movie. you don't do it. instead you
interleave the subs, and likewise you should interleave this sort of
data. also, i'm not so strongly decided on the following, but my
inclination would be _not_ to specify the format of such data in nut,
and instead support separate "codecs" for it. but there are merits to
both ways and i'd be interested in hearing both sides.



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.

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


rich