[MPlayer-dev-eng] Re: MPCF Draft/Discussion (MPlayer ContainerFormat)

[Fabien Tassin]

According to Steve Lhomme:
> 
> Fabien Tassin wrote:
> >>Not recommended reading/inspiration:
> >>(overly complicated, implementation based instead of solution based
> >>design and general brain damage)
> >
> >
> >It is worth the read just to understand what is wrong and why.
> 
> Any chance of sharing ?

this was not a direct criticism. Just a "don't take that
crap argument for granted, read and decide by yourself".

> I'm (very) surprised so many people read the matroska specs and we got 0 
> comments. Even some saying it's pure crap...

not me for sure. I browsed your doc in the past and lost track of it
until this discussion. I just re-read it.

My main problem with Matroska is the EBML dependancy. The idea may be
nice but I think it is not worth it. The reason invoqued is "extensability
for future use". I don't see why it is necessary or even whished to use
that thing to reach that goal. You even admit that it is very similar
to VLC/TLV.

Whatever format emerges, many projects will add support for it quickly
but I bet that most will use their own (de)muxer (by coding it or
stealing it). If I ever have to include support for matroska in my apps,
I will not add EBML dep, but code the minimal subset of EBML required.
Why ? just because I think it is quite easy and I prefer that than bloat
my app with another lib. It may be different for a more complex feature.

The various types supported are also funny for a container.
IMHO, unsigned integers (1, 2, 4, 8 bytes) and ASCII/UTF8 strings
are enough. And in most cases, there's no need to specify the types of
each piece of information in the files, the specs are enough.

The "EBML was originally created for the matroska project" sentence
disturbs me for all the given reason.

Except that, I have nothing to say against matroska at the moment
as I never tried to code around this format. Perhaps I will, if it ever
gets popular :)

/Fabien