[MPlayer-dev-eng] NUT/menus proposal

[Michael Niedermayer]

Hi

On Monday 13 September 2004 17:37, D Richard Felker III wrote:
> 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.

iam not against placing menus outside nut, what iam against is the last change 
to info packets

[...]

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