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

[D Richard Felker III]

On Sat, Sep 11, 2004 at 01:06:41PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Saturday 11 September 2004 11:18, Alex Beregszaszi wrote:
> > CVS change done by Alex Beregszaszi
> >
> > Update of /cvsroot/mplayer/main/DOCS/tech
> > In directory mail:/var2/tmp/cvs-serv5108
> >
> > Modified Files:
> >  mpcf.txt
> > Log Message:
> > 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.

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.

3. info data is user-oriented and is associated with the whole file,
   not any particular stream. several old containers require you to
   associate it to a stream, so it often gets attached to the
   (primary) video stream, but this is silly. allowing separate info
   packets per-stream encourages users to do idiotic things like
   storing sequential data (e.g. different songs from an album)
   interleaved in one file.

4. further, info data may change over time, e.g. for a network stream
   with multiple songs. it makes sense to allow info packets to appear
   anywhere in the file, and apply until they're replaced by a new
   info packet later. on the other hand, metadata should never change
   midstream, and it's needed at _startup_ time so the player can let
   the user make an informed choice (or automatic choice) about which
   tracks to play. thus, metadata must immediately follow the main
   headers and be repeated whenever the headers are repeated.

actually i don't really like the implementation alex outlined (we only
taked about the principles above, not how to change the spec), but
that's not important. imho a better way would be to put the metadata
as a tag/value list inside the stream header itself, rather than as a
separate type of packet, and then to reserve "info" packets
exclusively for "user data".

comments?

rich