[MPlayer-dev-eng] MPCF Draft/Discussion (MPlayer Container Format)

[Michael Niedermayer]

Hi

On Friday 07 February 2003 05:02, Fabien Tassin wrote:
> According to Alex Beregszaszi:
> > Please move the thread here.
[...]
> > MPCF Draft/Discussion (MPlayer Container Format)
>
> - choose a better name. Something sexy or funny but not tied to any
agree

> particular OS or SW. What about EGG ? it will give you a 3 letters
> extention and isn't an egg the better container ever ? You could also see
> it as Extended OGG. In any cases, it should be pronounceable and/or easy to
> remember.
egg sounds nice, ...
other options:
IVA (AVI backward)
AME (Advanced media egg)
COLA
10L

btw, we allso should be carefull not to violate and lame trademarks ...

>
> - try to avoid the brain damaged encoding of some formats that pack bits
> for some fields and use 'long' or even 'long long' for booleans.
yes, we dont do that

>
> - in addition to the optionnnal-but-recommanded index (which, like Arpi,
> I think it is better to have it at the end), try to allow optionnal
> chaptering with stop points flags. A player ignoring those chapters will
hmm, i dont like that, IMHO chapter info should be in optional packets, so 
simple players dont have to know anything about it

> play the file from the beginning to the end. Another supporting them will
> stop, allowing some extra/bonus/alternate sequences to be tied to the video
> and read on-demand. Even better, if it is possible to tie a still picture
> and some sort of script, you could build a real menu with a single file
> (easier to transport). I see chapters different from index as index uses
> fixed size cells and chapter cells, because of titles, could have variable
> lengths.
scripts: very bad idea IMHO, (complex, security, useless)
menus:   can be done with info packets, just specify with info packets that
some part of the file is an alternative, if the player supports it than it 
could let the user select between them ... 

[...]
> - in the header, it would be nice to specify the size (in bytes) and length
> (in seconds or ms) of the media when known (like with AVI/ASF). It could
its there

> be tied to a flag known/evaluated/unknown for each two.
thats just increases complexity, the fields can be 0 if unknown

[...]
>
> - alignment: permit stuffing bytes (like in MPEG or AVI's JUNK chunk).
> Could be useful for in-place edition (to fill holes) and for
> CDROM 2k alignment (at the end).
ok

>
> - version: should not be necessary but who knows the future ? Take
> the example of MPEG, in some cases, it is tricky to figure out what
> version of MPEG video is stored in an MPEG2-PS. MPEG audio is easy because
> it specifies its version.
version is there, its called version, just grep

[...]

Michael