[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 03:19:09PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Monday 13 September 2004 14:37, D Richard Felker III wrote:
> > 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... 
> 
> can u give some examples for which this isnt flexible enough?

if i could we could fix it, but alas i think the type of people who
want to make menus and crap will _always_ think of some incredibly
lame thing they want to do that we didn't think of...

> > 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.
> 
> i think u missunderstand my suggestion a little, what iam proposing is to 
> split content from markup, so that the actual content (start/stop times, 
> titles, author, ...) are stored in a standard format (= info packets) while 
> the markup is stored somewhere else, like another stream, later would have a 
> codec like video and audio have and this could contain images, video, scripts 
> or anything else the codec wants to use

ok, so i guess this is the "separate streams with disposition=menu and
high timestamps" approach i described. i suppose it's ok...

> > 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. 
> 
> certainly, i never suggested to append them to the main tracks, this would be 
> very sick

ok, that's how i imagined it would work with the start and stop times,
but now i see i misunderstood...

> > it really sucks for users 
> > not using a stupid gui-menu movieplayer. 
> 
> none of the suggested things need a gui to work, u can very easily display the 
> menu as pure text, and certainly cant if u put black-box data in a menu 
> stream without any standarized info like u suggest

by gui player i mean anything that prompts you for _any_ input after
pressing enter on the commandline.. i suppose the right word would be
"interactive player".

> PS: your/alex`s suggestion remainds me strongly of ogg where even things like 
> samplerate are stored in codec specific ways ...

haha, perhaps... but i don't think menus are as simple/general as you
think. the people who want menus are crazy...

rich