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

[D Richard Felker III]

On Sun, Feb 09, 2003 at 02:40:19PM +0100, Fabien Tassin wrote:
> 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 :)

Well said.

Rich