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

[Fabien Tassin]

According to Alex Beregszaszi:
> 
> Please move the thread here.

[ well, I wrote this before even reading mpcf.txt but I did now and most
still applies. Take this as a list of wishes and recommandations based
upon my own experience with media formats ]
 
> MPCF Draft/Discussion (MPlayer Container Format)

- choose a better name. Something sexy or funny but not tied to any
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.

- 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.

- 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 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.

- TLV: the notion of typed objects of ASF is nice. It allows everybody to
easily extend the format based on the principal that it will cause no harm as
an unknown type must be ignored. A low level demuxer could just pass
the object untouched to the upper layer.

- 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
be tied to a flag known/evaluated/unknown for each two.

- authoring: someone spoke about ID3v1 limitation and ID3v2 complexity.
I agree. We do not need to care about MPEG syncword (fortunately) but
VL fields are nice. Remember OMDL extentions to AVI. MPEG-PS definitely
lacks such feature (see MPEG 7). RM 'CONT' chunk is VL but could not be
extended.

- 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).

- 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.

/Fabien