[Matroska-devel] Re: Adding matroska support to FFMPEG via libmatroska/libebml, in C++ ?

ChristianHJW christian at matroska.org
Tue Oct 14 22:02:44 CEST 2003

@ Michael, all : I promise this is my last email about this subject to 
the list, at least for the time being.

D Richard Felker III wrote:
> Hint 1: Matroska has large overhead.

Richard, you always claim that, but i havent seen any proof of those yet 
from your side. Show me another container with a similar flexibility 
that can produce smaller file sizes and is extendable for the next 10 
years. I bet you cant.

> Hint 2: Matroska is so overcomplicated and bloated that the specs
> might as well not be available.

Well, there seem to be a couple of programmers now that dont have any 
problems understanding those 'bloated' specs and make working code based 
on it. It took Gabest 3 days to make his implementation, and he made it 
from scratch, and even wrapped a DirectShow parser and muxer filter 
around it. I would ask you to not judge about things from the view of 
your obviously limited coding capabilities all the time. Just because 
you think they are 'bloated' they dont have to be necessarily like that.

>>opened to any codec, extensible as you wish, all based on an easy 
>>principle (EBML). That's all that comes to my mind for now.
> ROTFL! Perhaps you should learn about this stuff from a performance
> software perspective rather than from a CS-professor perspective. EBML
> is inefficient and totally unnecessary.

LOL ! Sorry, but i cant help laughing here. We had a couple of important 
aspects to respect when making the specs, but for sure 'performance 
perspectives' were not amongst them. Any small Pentium 3 can play 
matroska files without having to invest more than 2% of his CPU power 
for parsing of the file. And when i think about the CPU requirements for 
upcoming compression formats like h.264, this argument just makes me 
smile, sorry.

Richard, you think much to MPEG biased, in a very narrow angle of view. 
We didnt make a container primarily for the existing compression formats 
of today. If we had them in mind, we would have extended the good old 
MPEG container a bit.

>>>In this case, I merely stated that quoting an official promotion site
>>>doesn't really prove the popularity of anything.
>>So what would be decisive for you ? Popularity of a crap format ? Of an 
>>unpopular format that is technically good ? Matroska has a (fast) 
>>growing popularity and is technically good (I won't claim it's the best, 
>>but it's among the best ones). What else do you need ?
> It's technically bad. All it succeeds in doing is being better than
> the horrible avi and ogm containers. Rich

Yes, its much better than AVI already, and the compression formats where 
matroska will be excellent to use with are not even specified yet ;) ....


matroska project admin

More information about the Matroska-devel mailing list