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

[D Richard Felker III]

On Sat, Sep 11, 2004 at 10:18:55PM +0200, Michael Niedermayer wrote:
> > > > info packet is now file global, while meta pakcet is stream specific,
> > > > as discussed with Rich
> > >
> > > where was this disscussed?
> > > i strongly dissagree with this change, info packets where much more
> > > flexible, generic and simple then this
> >
> > michael, i agree the whole thing scould use a little more work
> > (info/meta stuff), but alex and i agreed strongly that the old system
> > was bad. a couple key points we talked about (perhaps with a few new
> > ideas added by me):
> >
> > 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.

> allthough, i certainly agree that the description /what is described mix is  
> not good, but limiting what is described to exactly one stream or the whole 
> file is neither good

hmm...i see more merit for info packets that apply to a time segment
of the file. but packets that apply to just one stream don't seem very
useful and could be inviting abuse.

> > 2. metadata is strongly associated with a stream, and tells properties
> >    of that stream that the player app should be able to know for its
> >    purposes, such as: language, disposition (main audio, music only,
> >    commentary track, subtitle, karaoke, commentary text, ...), gain
> >    (let's use the simple word gain rather than the silly ReplayGain
> >    named after a dumb windows app). it should never be associated with
> >    just a segment of the stream for obvious sanity reasons.
> well, some things like disposition or gain certainly should not change, but 
> language is a bit tricky, while we may disslike it, its very possible to have 
> a video with parts in different languages
> so there really are 2 things here
> 1. primary language (maybe we should allow 'multilingual') this is per stream
> 2. language which is per stream+start/stop time, this will probably be rarely 
> set

actually we talked about this a little bit. i think allowing a special
code for 'multilingual' is the correct solution. if a movie is mostly
in one language but with small parts in another (like many american
movies with small bits of spanish or other languages, or "la vita e
bella" which is mostly in italian but also has small parts in german)
i think it's appropriate to just tag the main language. but if it's
truely a mix (i seem to recall a major hollywood film in the past
couple years being half-english and half-spanish) then a multilingual
tag is most appropriate. it's simply ridiculous to have the language
tag switch back and forth every time someone says a line in a
different language! :) and even if you felt like encoding such a
nonsensical thing, it would be useless to the user/player for
selecting which audio track they want to hear.

imo, it should also be allowed to _omit_ language & disposition, but
_only_ for one audio track. so if there's more than one track, it's
required to specify which is which. alex and i were discussing (on
irc) a "nut validator" program which users could run on their files to
make sure they comply to spec, and it could check such things.

i'll write some proposals on -dev-eng soon (which would be a better
place to discuss this -- can we move the thread?)

rich