[XviD-devel] Re: [Flac-dev] Re: [advocacy] Project Announcement : New Media Container Format 'matroska'

[Steve Lhomme]

Monty wrote:

> On Sat, Dec 07, 2002 at 10:29:29PM +0100, ChristianHJW wrote:
>
> >Please allow me to announce the creation of a new open source Media
> >Container Format, named 'matroska'
> >
> >Project page is here http://sf.net/projects/matroska ; homepage is
> >http://matroska.sourceforge.net , HTML should be online soon.
>
> Another redundant project?

Well, if you think anything new with just a few variations is redundant, 
then it surely is. As OGG and Vorbis are too and a thousand other 
projects I won't name here (vi vs pico vs emacs, etc).

> "ten BSD programmers are sealed in a computer lab for a month.  At the
> end of the month, the door is opened.  Investigators discover,
> bloodied and dead, all ten programmers--- and thirteen new flavors of
> BSD."

Yeah, it's sad but true (that this could exist).

> >I am personally not happy about the fact that we had to found a new 
> project,
> >but it seems that it was the only alternative now. Of course we are well
> >aware of the fact that both projects will become weaker this way, but we
> >hope to be able to release the container including creation tools and
> >playback filters until January/February 2003, and then the users will 
> decide
> >what format they prefer.
>
>
> This announcement is not about 'letting the users decide'.  You

It wasn't sent to users, but developpers. Users will decide later. But 
as some people heard of MCF, the same one would probably like to know 
about matroska. In a perfect world I would expect technical person to 
get a minimum interrest and if they find it interresting, dig more in 
the specs. But since it hardly happened with MCF, I doubt it will with 
matroska. Apparently people prefer to code, comment the code and later 
analyse what they did. We tried and keep on trying the reverse way :)

BTW, for the record, Matroska is a simplified version of matrioshka (or 
MATPËWKA in russian), the original name of the russian dolls. The idea 
comes from me and Frank Klemm gave us the name in russian. It just 
symbolises the fact that, like IFF formats, Matroska contains other 
Matroska elements.

> haven't released or produced anything yet. This is the grown-up
> equivalent of declaring 'I didn't get to do it my way, so I'm taking
> my toys home with me' and watching to see which kids in the crowd are
> going to follow you home.  We're on the way to having every dissident
> hacker pushing his own incompatable container format, most based on
> someone else's container format.  OK, sure, whatever.

Well, this is not exactly what is happening. Tronic gave me full control 
of the MCF specs and that's exactly what I did. I tried to take the 
specs and add what we thought would be needed/good/possible features. 
And I ended up with Matroska which borrows a lot from MCF, but is very 
different in the "syntax". So basically it was meant to become MCF v1 
very soon, as the format is passing Round 1 soon (see spec for more 
details). But now Tronic is back and don't want MCF to become that 
format I worked on. And since I consider it fills all past missing gaps 
in the specs and is far superior in expandability, I don't want that 
format to die.

There is also a libmcf library already existing that I coded 90% a while 
back. And since MCF and Matroska are twins this code will be used for 
libmatroska, and I think we'll be able to parse/create Matroska files 
quite fast (we're only missing UCI then).

> "Step one: Achieve something. Step two: toot horn"

I strongly agree with this. But Christian's announcement wasn't to 
announce that the format is final and the code is existing (AFAIK 
neither OGG nor Vrobis are final), just that it has been created. He 
didn't even tell the most important : it is already far closer to be 
final and a working code is not far neither. So this is no vaporware (as 
MCF tended to be perceived like).

> If you were really interested only in doing something different or
> trying out something new, you'd just have gone off and done it, and
> let the world know if it did/didn't work out. We already went through
> all this a year or two ago when you all declared the beginning of MCF
> and sent mail to the Ogg lists that it would be better than our
> project in every way and we should abandon Ogg and use MCF.  It was
> quite the initial introduction and left a lasting impression.  So,
> I'll repeat a previous flame that the original MCF folks never really
> rebutted (just seemed to ignore).

Yes, I know it sounded like vaporware. But in the mean time a lot of 
work has been done, lots of people contacted, only few reactions, even 
fewer help. And the result of all this (unknown) work from the 2 most 
active person in the MCF team is now turning into a new project.

> Quite a few MCF proponents keep touting things that Ogg can't
> do... except they're wrong.  For example, somone told with great
> confidence on HA that he was going with MCF because there was no way
> to figure out what codecs Ogg used and that each mixed stream type was
> hardwired.  That would really suck if it were true.  It isn't.

I don't want to start a long falme war (we all have better things to 
do), so I won't reply here. If you want my point of view, just email me 
in private.

> Looking at it from a high level, Ogg (the software) is full of feature
> hooks for which no one has written the code yet.  But it's apparently
> easier to start from scratch (again), effectively abandoning a half
> completed system that's already running, solid, and deployed
> worldwide, and then use my own lists to pull people out of the project
> that works and has forward momentum.  A second time.  It's in poor
> taste all over again.

We never said OGG should be abandoned. We just hope MCF-now-Matroska 
will fill all the needed use for a multimedia container, so that 
probably (hopefully) covers all that OGG can do. It might sound 
pretentious but all this year I've been working hard (not alone and I've 
learned a lot from other people) on just a container. Something 
versatile and build to last long (even though we can't predict the future).

> Personally, my position is that XML (binary or no) belongs in a stream
> or at a higher non-linear level-- not defining the lowest level
> transport attributes.  The correct way to build a large system is not
> to smash every conceivable feature into a single monolithic API layer.
> Build small pieces that work together. 

Well, yes that's a difference in our point of view. I don't know OGG 
very well, but it seems that you went a level too low in the format 
(AFAIK all is based on small packets of data). This is actually only 
usefull on a limited number of transport layers like streaming (I've had 
a look at the draft RFC for OGG in RTP). For most of the time it's 
overkill. So we avoid that part. For streaming, we have already thought 
about it (to make sure the format could fit in) with Frank Klemm. And 
he's actually been working a lot lately on the way it should be 
technically done and what ECC would be needed for reliable transport 
(even over UDP). So even this possibility is not left out of what we 
want to do/cover.

>
> We here at Xiph started with:
>
> 1) a nice, robust linear transport layer that's optimized specifically
> and only for linear transport, ie, 'does one thing very well and can
> be used to build larger things'
>
> 2) filters, aka OggFile, the first 'larger thing', now in progress
> along with resource usage optimizations (eg, zero-copy).
>
> We're going to get that right before building a huge feature-rich
> system on a foundation that's unproven / doesn't exist.

Well, that's one way of doing. We try to think in advance, from very low 
level, coding to high level and interfacing with the rest of the 
world/OSes. And then code. Sadly we don't have the coding resources or 
support Xiph has (been building) so our solution seem to be appropriate 
to what we do. We can't afford to code 10 different non working 
versions, but we already coded 2 minimal parsers for MCF and it's 
working well.

> In summary, I'd prefer you let the people here who have demonstrated
> they're capable of working together without forking continue to do so
> without this ongoing pseudotechnical distraction.

I didn't see anything in Christian's message that would let you think we 
want to distract people. And nothing against OGG (which I assume you're 
talking about). So I would be glad if you would not try to discourage 
anyone to get interrest in our project as much as we don't force anyone 
to leave OGG. I just hope you don't consider OGG as the one and only 
format. (this is the polite version)

> (And if you want to do something productive with XML, how about
> contribute to the metaheader or XML page stream type in Ogg?  Hmmm?)

Because so far, all the contacts I had with you and other people of the 
OGG/Vorbis was never friendly (this message is just one more example). 
This is a major reason for me. For example we leave the MCF project in 
good terms and I will still be a (small) part of it. Working "against" 
people is something I want to avoid.