[Fwd: Re: Re: [Matroska-devel] Re: Adding matroska support to FFMPEG via libmatroska/libebml, in C++ ?]
christian at matroska.org
Wed Oct 15 04:59:22 CEST 2003
I promised not to reply anymore to ffmpeg-devel AT lists.sf.net after my
last email, but i thought i forward you Felker's last reply, in case
anybody likes to point him to Alex Noe's overhead comparison ;) ....
Michael Niedermayer, the author of the 'nut' specs, certainly knows his
stuff, no doubt. He wasnt interested to help making our specs that time,
but came with his specs after we started making matroska a reality.
There is no working implementation of 'nut' AFAIK, and i really hope it
will stay that way. Low overhead was never our main focus, but future
extendability, and overhead will be even less important when DVD burners
will have replaced CDs completely, so whats the point. I wonder if a nut
file could easily support h.264 NALUs or can be edited without a codec ....
-------- Original Message --------
Subject: Re: Re: [Matroska-devel] Re: Adding matroska support to FFMPEG
via libmatroska/libebml, in C++ ?
Date: Tue, 14 Oct 2003 19:42:47 -0400
From: D Richard Felker III <dalias at aerifal.cx>
Reply-To: ffmpeg-devel at lists.sourceforge.net
References: <20031013103334.C3257 at submarine>
<3F8AFF47.1050805 at matroska.org> <yw1xekxgx32q.fsf at users.sourceforge.net>
<3F8B1D76.8060809 at matroska.org> <yw1x65isx00o.fsf at users.sourceforge.net>
<3F8BB863.0 at free.fr> <yw1xismstcr5.fsf at users.sourceforge.net>
<3F8BC053.3060601 at free.fr> <20031014142122.GZ2856 at brightrain.aerifal.cx>
<3F8C5664.2010604 at matroska.org>
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
> >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.
> 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.
> >>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.
Actually, bitstream parsing performance can be an issue too, but I
doubt the cpu requirements of Matroska are very high.
> 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.
BTW, I find this claim of yours amusing, since Matroska does not allow
packet-resolution seeking in vorbis audio.
> >>>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.
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
More information about the Matroska-devel