[Matroska-devel] Re: Adding matroska support to FFMPEG via libmatroska/libebml, in C++ ?
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
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