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

[D Richard Felker III]

On Tue, Sep 14, 2004 at 11:19:35AM +0200, Steve Lhomme wrote:
> Hi,
> 
> It's nice to see menu discussions happening elsewhere, as we (matroska) 
> are currently implementing menu support/ripping.

yes and you have very bad ideas about the nature of it, although as
long as those things are separate from nut it doesn't really matter to
me. i just won't download menu files.

seriously, if you want to work together on something like this,
criticizing nut for not repeating the bloat and design mistakes of dvd
and matroska is not going to get you anywhere. it's just going to
convince us that the people who want menus are idiots and that it's
not worth our time trying to please them.

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

umm, these were obvious i thought.

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

no, i'm starting from the design philosophy of nut. perhaps you missed
that.

> IMO 
> muxing video, audio, subs and all other kind of stuff should fit nicely 
> in an A/V container.

muxing, yes. archiving files, no. packaging separate data that is not
muxed (interleaved) is the job of an archive file, not a multimedia
file.

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

huh? i'm really confused about how these three sentences fit into your
point, much less fit with each other...

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

no, it's a huge advantage. it makes it so it's actually possible to
seek correctly, and eliminates all sorts of ambiguities about what a
player should do when it encounters timestamp discontinuities and
other bad things.

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

huh? you mean you store the movie out-of-order and then use editlist
type data to put it back in order? or something else? if my
understanding was right, that's incredibly stupid.

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

yeah, in principle that should be the way it is with dvds, but look
how broken dvds are. the "main" movie is often a random title number
which the user has to painfully search for. once it's found, you also
have to find the right audio and subtitle tracks to use. sometimes
they're tagged right, sometimes not. then, if you want to seek, you're
pretty much out of luck, because timestamps reset to zero all over the
place, and you can't do binary search for seeking. the trouble just
goes on and on.

nut is designed to make it impossible to store such brain damaged
structures that require human intervention to play the movie right,
but putting forth clear rules on what is and isn't valid.

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

nut does not have "attachments" per se because it's a bad idea. you
can store arbitrary data inside info packets, but it's not intended
for large data (like movie clips). further, storing nut files inside
nut files this way is not efficient and will hamper error recovery if
the file is damaged. i see this as a feature, not a limitation, since
it will prevent people from trying to do something so stupid.

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

with chapters, of course. chapters are a very good structure. they
associate with various segments of the movie a name and number,
without imposing any interface on the user. a player can ignore them,
or present them in a pulldown menu, or provide keys which seek to
next/prev chapter, or use the data in any other way it sees fit.

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

you're confusing unrelated data. video, audio, subs are one thing.
buttons and commands are entirely different.

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

while i understand that some people want this, i see it as very
misguided. dvd sucks. dvd ripping is a matter of taking a bad product
and producing a decent transfer out of it. the menus you have to wade
through before getting to the actual movie are one of the biggest
nuisances of dvd, and (with a few exceptions for special content) i
find it stupid to try to reproduce that in a rip.

as for dvd->mkv->dvd, i find the final step of converting back to dvd
also misguided. once you've gone to all the trouble to get the movie
in a good format, why put it back in a bad one? (matroska a good
format? haha i can't believe i said that! :) but compared to dvd...)

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

well the natural choice for that setting would be .rar... ;) i agree
it's stupid to put the movie in a .rar file with all the menu stuff as
a bunch of extra files. the correct way is to make one file for the
movie and another file with the menu stuff. that way people who don't
care for the useless menu crap don't have to download it, and there
are only 2 files total, which is no problem.

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

imo menus/buttons have little to do with chapters, unless you're
abusing chapters as a way to include menu-background clips, in which
case you should rm -rf / and go sit in a corner...

rich