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

Pamel paul at msn.com
Wed Oct 15 14:40:32 CEST 2003

For the benefit of anyone reading the Matroska.Devel list:

> On Tue, Oct 14, 2003 at 10:02:44PM +0200, ChristianHJW wrote:
> > @ 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.
> I'll let you do it for me. Tell me how many bytes per frame in
> overhead you have, and we'll compare it to nut. I have no desire to go
> back and read your spec again (it was bad enough the first time). What
> I can guarantee is that if you tag fields in addition to storing the
> data, you will inherently use a lot more space, and that makes a big
> difference at low bitrate (and even a significant difference at
> moderate bitrates).

I think 10 bytes for I, 13 for P, and 16 for B.  This will also drop
significantly if the new lacing system is used.  It should also be noted that
the referencing system was changed during spec creation from single bit flags
for I,P,B to a system that allows referencing any frame and any number of frames
in a stream.  If the goal was absolute lowest overhead, the bit flags would have
been used.  But since flexibility and future-proofing was the goal, the newer
method was chosen. (AVI is 16 bytes per frame)

> > >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
> Good for him. Did he do it with no aid but the spec document, or did
> he ask you for help, and/or read your source? I find it hard to
> believe anyone could write a demuxer using your specs alone, and have
> it behave fully as you expect.

He did ask for clarification on a few points, and if I'm not mistaken, found
some errors in the specs.  Those errors were fixed.

> > 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.
> I don't think my coding abilities are the topic in question here.

There are several topics here, and that is one of them.  Having a non-coder
declare the greatness of bit-efficiency of one format or another is a bit
dubious.  IE, you are better off hearing the opinions of Mosu, Cyrius, Alexnoe,
RobUx4, or MNiedermayer  rather than ChristianHJW or DRFelker.

> > >>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.
> Then you misunderstood. It has nothing to do with cpu time required to
> decode, but the mindset. The people who designed NUT are competent and
> experienced in writing performance code, and the efficiency-oriented
> mindset that goes along with it. You're designing from a horrible
> XML-inspired undergrad CS dork mindset.

This is such a strange and out of place comment that I have no idea how to
comment on it.  Perhaps just saying that his mommy was a foo-head would be

> Actually, bitstream parsing performance can be an issue too, but I
> doubt the cpu requirements of Matroska are very high.

They aren't.  But if overhead and bit-stream parsing aren't issues, I'm not sure
what is.  As I said before, flexibility and future-proofing were the main
concerns of the Matroska team.  The fact that overhead and bit-stream parsing
aren't issues is just a wonderful coincedence.  ;)

> > 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.
> This is nonsense. NUT can contain any audio and video content,
> regardless of codec, present or future. There are only a few very
> simple requirements to be able to claim this; AVI was just so poorly
> designed that it does not meet them.

Do you allow multiple references to any frame in the stream?

> BTW, I find this claim of yours amusing, since Matroska does not allow
> packet-resolution seeking in vorbis audio.

False.  Not really sure where he got this one, but that was one of the points of
Matroska, to put one frame/block.  If you lace frames, then you will only have 1
timecode for a few frames (100-500ms), so you could certainly seek to any frame,
but you wouldn't know the timecode of it. But you are not required to use
lacing, it just reduces overhead.

> > >>>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 ;) ....
> This is bullshit. If you're going to make such a claim, back it up.
> However, I promise you that you can't.

I hate arguments like this.  What happens is that someone knocks something, and
when someone offers proof that what was said was wrong, they knock something
else.  There will never be an acknowledgement that they were wrong, and it will
never end.  It will just get more and more dumb.  Regardless, I will answer

One codec idea was WARP.  The idea is to use a wavlet transform across a group
of frames (say 32) and store the encoded block for all 32 frames in a single I
frame.  Then you have some way to say, that the other 31 frames have to be
rendered using only data from that block and what their timecodes would be.  In
matroska you would just define a special element to indicate that.  You could
store the data in AVI, and use P-frames as dummy frames, but that would be far
less elegant. The Matroska method would not just work, but would be an excellent
way of doing it.


More information about the Matroska-devel mailing list