[Matroska-devel] Re: NUT/menus proposal
steve.lhomme at free.fr
Tue Sep 14 11:19:35 CEST 2004
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".
More information about the Matroska-devel