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

[Michael Niedermayer]

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?


> 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

[...]

> 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


> 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


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

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();  (violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535)
buf[i]= qp - buf[i-1];    (violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en