[MPlayer-dev-eng] Re: NUT/menus proposal

[Steve Lhomme]

Hi,

It's nice to see menu discussions happening elsewhere, as we (matroska) 
are currently implementing menu support/ripping.

D Richard Felker III a écrit :

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

You forget important parts : interactive buttons and a command language.

> 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

You seem to be starting from the conclusion to explain your point. IMO 
muxing video, audio, subs and all other kind of stuff should fit nicely 
in an A/V container. AFAIK on a DVD you never display video frames or 
audio samples in reverse order. You just play part of the DVD in a 
non-linear way. But the timecode (in MPEG) still highly matters.

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

Maybe that's something that can't be changed in NUT. But it's a drawback 
that has no advantage. In Matroska the timecode is also very important, 
you can't get rid of it. But we also allow playing the file 
non-contiguously. This is done using chapters, with a start/stop 
timecode, that are saved in non-linear order and played in this same 
order. The file can still play linearly with old school players, but it 
will lack an interresting feature. Just because the player doesn't 
support the feature, not because the data shouldn't be there.

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

How about attachments then ?

> 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

How would you play Memento or Irréversible in a non-linear way without 
menus ? (ok in Matroska, you just select another chapter edition)

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

In the other hand you have no idea how many people have been requesting 
the menu feature in Matroska. People want their rips as close to the 
original as possible. And there are interactive DVDs that won't make 
sense without all the menus features. Is it worth designing a completely 
new format that would store video, audio, subs, buttons, commands just 
to allow that ?

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

The current menu system in Matroska is just a rip of the menu features 
in a DVD. And it's put in a "chapter codec". Which means that other 
codec could be used when they appear. The current system we're 
developping is meant to allow easy DVD -> MKV -> DVD without losing any 
key element. And people clearly want a single file for that, because we 
leave in a P2P world... I don't think .zip or .tar would either be valid 
options for anyone...

PS: We have still not decided where the buttons should be put : in 
chapters or in a "Control Track".