[MPlayer-dev-eng] NUT/menus proposal

[D Richard Felker III]

On Thu, Sep 16, 2004 at 03:43:43AM +0200, Michael Niedermayer wrote:
> > 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?! 

actually at one point we said the spec requires info packets to be
immediately after the stream headers, and repeated whenever the stream
headers are, with the single exception of streaming content where a
new info packet gets sent with every song/show/whatever.

there are also good reasons to require info packets to be at the
beginning. for instance, with chapter divisions, you could put the
chapter info packet right at the start of the chapter, but then it
would be rather hard to use it for seeking to a chapter, no? :)

if you want info packets to be able to be placed at any location, i
think it's even more important to have the essential metadata stored
separately. why? because it needs to be found immediately when the
file is opened, not at a random location while playing the file...

> and please define what "essential" stream 
> metadata is,

i did this. essential data is something without which the player
cannot sanely play the movie. actually there's already a good example
of essential metadata in the stream headers, which you put there:
aspect ratio! sure you can decode and show the frames just fine
without knowing aspect, but any non-broken player needs to know aspect
or the output it shows will be bogus. similarly any nonbroken player
needs to know if a stream is commentary, music-only, or main audio
track, and what language it is, etc., or it will play bogus stuff by
default.

if we want to move stuff to the info headers we could move aspect,
bitrate, colorspace type, and probably many other things there. but
instead we're storing these things in the main header because they're
considered essential. imo the ultimate determination should be this:
you should be able to take any nut file, strip all the info packets
from it, and still have a valid file that will be played correctly.

(if it's confusing what i mean by valid file, on irc we proposed that
any file with more than one stream of a given type must identify the
separate streams with language/disposition.)

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

of course not. that's informative tagging for the user. not meaningful
to a computer at all, and certainly not needed to play the movie.

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

maybe, but i kind of doubt it. the spec should declare any tags not
specified explicitly to be invalid. if you'd be willing, i'd be happy
to throw out the "metadata" key/value pair idea, and just put fields
in the stream header for a few key "essential" things. actually
language code is there already, so it's almost done...

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

i really don't think a couple bytes in a global header matter... my
intent was just to have this be clean and not use lots of different
complicated data structures, but reuse a few more basic ones as much
as we can. either way is ok with me...

anyway michael i feel like this discussion is getting a little bit out
of hand. you put a lot of work into designing something that doesn't
suck (tm^H^Hgm ;), and i don't mean to disrespect what you've done or
your judgement on it. but i also know the current state of video
containers sucks with respect to multi-track and multi-language, and
often it's impossible to get your player to play the track you intend
without randomly trying all the tracks until you find the right one.
nut should be better than that, and i think if we stuff this critical
information away in an info packet that can appear at an arbitrary
location in the file (so it's hard for a player to find, like mplayer
with ogm files now...) then things won't get any better. (i know we
could still require an info packet at the beginning with these things,
but it's more likely that people would ignore it..)

rich