[MPlayer-dev-eng] Re: [Mplayer-cvslog] CVS: main/DOCS/tech mpcf.txt, 1.64, 1.65

[D Richard Felker III]

On Mon, Sep 13, 2004 at 01:36:03PM +0200, Michael Niedermayer wrote:
> > > > 1. the old info packet contained a list of tags describing two
> > > >    different (and unrelated things): itself, and some portion of the
> > > >    file. for example, some tags like streamid and start/end time told
> > > >    what the packet applies to, while others like author, title, etc.
> > > >    described the object the packet applies to. imo this was
> > > >    unnecessarily confusing.
> > >
> > > well, i wanted to use info packets for edit lists and menus, so alex`s
> > > removing of start/stop time makes this impossible
> >
> > hmmm...can you explain a bit more of how this would work?
> >
> > > it also destroys chapters support, as its no longer possible to describe
> > > a specific part
> >
> > again i'd like to hear more about what you have in mind for chapters.
> 
> a chapter would simply be described by a info packet containing the following
> ------
> StartTimestamp ...
> EndTimestamp ...
> Titel=<chapter name>
> Description=<chapter description>
> ...
> ------

maybe this works for very basic stuff like chapters, but i'm strongly
against it for editlists and menus. it won't be nearly flexible
enough, so everyone will make their own incompatible extensions to
it... my inclination (although i'm open to arguments to the contrary)
is that menus and editlists should _not_ be specified in the container
format any more than codecs should. instead the container should just
specify packet types to hold "navigation" data, with user-defined data
inside. then, rather than being limited to what the container gives
them, people can design their own menu formats...some very basic,
others really advanced, etc.

from a slightly different perspective, we (alex and i) had the idea
that menu data should not be inside the nut file to begin with. i tend
to agree with this, especially if menu data involves editlists. that
sort of nasty hack is something that belongs in a bad format like
quicktime, not nut. why? a player shouldn't be expected to be able to
deal with that crap to play a movie. as far as i can tell, with your
system if the player didn't support menus it would just play all the
menu animations in sequence before or after the movie, which would be
pretty dumb.

instead, alex proposed having something more like a dvd filesystem
(but less complicated) where you have an accompanying spec for
additional navigation files that can be used with nut (and possibly
other containers too?). in my mind this has two big advantages:

1. nav data doesn't pollute the main movie file.
2. users who don't want nav crap don't have to download it.

it also has several things that are arguably a disadvantages:

1. nav data can get lost/separated from the main movie file.
2. if the nut file(s) are renamed, will the nav file still work?

if we do decide to put the menu stuff directly in the nut file, i
_don't_ think it's at all proper to append (or prepend) the menu
animations onto the main audio/video tracks. it really sucks for users
not using a stupid gui-menu movieplayer. there's a possibility of
using high timestamps after the end of the movie, _with_ separate
stream id's as well, but this is sort of a hack...what do you think?
imo any menu animations need to be segregated somehow from the movie.
this way it could be done with a stream with disposition=nav.

really, in my opinion, menus are a whole lot more trouble than they're
worth...

> additionally we could add some image(s)/video(s)/simple script language to 
> show a nice GUI for the menu ...

imo it's very wrong to specify a script language in the container...

rich