[MPlayer-dev-eng] NUT/menus proposal

[D Richard Felker III]

ok in light of the discussion i've been having here with michael and
on irc with alex and ivan and others, i'd like to make a proposal for
what to do with nut and menus.

in our discussion on irc, i started with the observation that menus
consist of a bunch of resources, which at present are likely to be
still pictures, movies, subpictures, sounds, and who knows what else.
in principle there are only two possible places to store these
resources: inside your movie (.nut) file, or outside.

first let's suppose we choose inside. by design a single nut file is
intended to represent only _one_ continuous unit of media. this is
very important, to avoid brain damage like dvd where we have resetting
timestamps and other nonsense. already we see that there's not a
logical place for menu resources to be muxed. in fact, if we mux the
menu resources starting at timestamp 0, they'll be _interleaved_ with
the main movie (remember correct interleaving rule). this is clearly
not what we want since it will hurt performance and makes no sense. so
instead we make up a really high starting timestamp, in order to allow
ourselves to mux the menu resources after the movie. this is
technically legal as far as i can tell, but it's still ridiculous
since it violates the design principle that a nut file should be a
single continuous unit of media.

if we want to avoid the brain damage, the only alternatives are
sacrificing some of the clean design of nut (definitely _not_ worth it
for menus!) or storing the menu resources _outside_ of the nut file.
more on that later.

so, here comes the proposal. it's based on some comments by ivan:

<@iive> actually menus are used for 2 things
<@iive> visually choose playing streams
<@iive> and choosing playing file
<@iive> as nut contains only one file (content) the menu is not so needed
<@iive> about choosing stream, this info is already present
<@iive> actually, one of the biggest drawbacks of DVD menus, is that
they are different for every film
<@iive> you have no idea how many people cannot manage to turn on
bulgarian subtitles with stock DVD's

i think what he's saying makes a lot of sense. not only does the
design philosophy of nut make it illogical to try to store menu data
inside the nut file. it also makes it illogical to even _have_ a menu
for a single nut file. thus, my proposal is to remove anything about
menus from the nut spec, and to make it clear that this stuff doesn't
belong in nut.

now, lots of you may know me as a menu-hater, but i'm not saying get
rid of menus entirely. so here's the second part of my proposal:

as a supplement to nut (but also independent), i think we should work
out a flexible menu file format. the menu file would have certain
control headers at the beginning, but then would essentially be an
_archive_ file containing all the resources for the menu as separate
subfiles. it would also need to be able to reference external files,
so if you had movie.nut, extra1.nut, and extra2.nut, it could
duplicate the dvd menus that lead you to the movie or the extras. in
principle any file formats could be used for the external files and
subfiles, but we'd probably want to design a standard profile intended
to be supported by hardware players.

basically, the principle of this design is that putting menus inside a
nut file is backwards. menus aren't an element of a single movie
(resource), but instead an umbrella structure that covers many
resources. and as such, the menu structure should be the "outer"
object and the resources should be the "inner" objects.

the nice bonus is that this format could be used with any container,
not just nut. so we might get help from people who are more interested
in menus (like the matroska crowd) so we don't have to waste our time
and dirty our hands with that stuff.

rich