Project Announcement : New Media Container Format

[ChristianHJW]

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.

Steve 'robux4' LHomme and myself have left the MCF project because of incompatibilities of our work with the project goals defined by the founder of MCF ( TMF ), Lasse 'Tronic' Karkainen, especially with respect to the latest specs Steve had been writing and documenting here http://matroska.sourceforge.net/specs/ ( replace libmcf with libmatroska, will be updated soon ) .

Tronic himself could not be actively participating on the project lately, due to the fact that his courses at university didnt leave him much time to do so. Steve and myself have been developing the project further, and now we find ourselves in the situation that the result of this work does not comply with the goals the original project leader was defining for it. As a consequence we decided to leave MCF and found our own project.

matroska will of course be based on MCF, but the EBML based specs that were developed together with Frank Klemm ( main MPC developer ) make the format very extensible on the one hand, but harder to parse on the other hand. Steve and myself do believe that easiness of parsing is a minor thing today, with respect to the fast development of modern CPUs, but extensability has proven to be a steady issue for container formats, as nobody can predict what future requirements may be.

EBML, being a kind of binary equivalent to XML, can be supported on all platforms easily and we hope that by using it we can differentiate our project from other known containers significantly.

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.

About the project name : we needed one quickly and amongst the numerous trials to find a 'friendly name' for MCF matroska seemd to be the best one. As it was Frank's idea and we knew he wouldnt mind we went for it, but please be aware we will listen closely to your considerations in this respect, as nothing has to be made in concrete yet.

Thanks for your interest


ChristianHJW
matroska project administrator

[spyder]

I am switching projects as well.

I need a new avatar I guess......

[Acaila]

Chris,

I don't get it...

For a long time it's been "MCF this", "MCF that" and now all of a sudden you're leaving the project? I know it's probably not all of a sudden, but it does seem like that from my perspective. Of course I understand that people don't like having their work gone to waste, but MCF was going to be THE new format and you've all put a lot of work into it already.

Ogg doesn't seem to be moving forward a lot lately (at least I haven't heard of anything new in a long time), and so I (and I'm sure a lot of others as well) were really looking forward to seeing MCF becoming a reality. But now, as I understand it, some of the best people on the project are leaving for greener pastures.

Although I'm sorry to hear you leaving MCF, I still wish all of you good luck on the new project.

Ps.
What does 'matroska' mean and what language is it?

[spyder]

Matroska is Russian. It's a name for a toy doll that has another inside and another inside of that one and so on...

It has been deceloping for a while now. Steve had bigger plans for MCF than Tronic but when Tronic left the project, Steve was in charge. We developed the new specs and changed a few things in the format that should be changed to make the format more flexible. As a result of this, we adopted the EBML form of coding element IDs and sizes. Tronic strongly disagrees with this choice. He came back from his time away and refused to accept the EBML specs as the new spec but never voiced that until recently. He just put it aside in his mind as a side project. Steve didn't want to argue about it and refused to give up all of this great work he did on the new format. So Matroska was formed. The main benefits of Matroska over MCF are:

-Highly flexible structure
-Easily extendable
-Broadcast and file modes merged
-Unlimited frame sizes
-Infinite number of element styles
-Easily backwards compatible with new specs
-reduced overhead for smaller frame sizes(7,14,21,28-56 bit or higher sizes may be used)

The disadvantages as Tronic sees them:

-No fixed positions of elements
-File must be completely rewritten for small changes in the headers
-Complex to parse

Both formats have their advantages. But Tronic's is limited while Matroska is not. I will code an MCF parser one day when the spec is ready. I have joined Matroska as an active member however as I believe it has great capability and needs input on the structure. I have agreed to advise on MCF specs if Tronic needs help. Tronic wants his format the way he wants it though so I will not be an active member because of that. He doesn't accept the work Steve put into making the format great.

[KAMiKAZOW]

IIRC, the MCF project started because the OGG container is not specified/good enough. Correct me if I'm wrong.

Why don't you work with Xiph.org on improving the OGG container?

[ChristianHJW]

Originally posted by KAMiKAZOW
Why don't you work with Xiph.org on improving the OGG container?

Because Ogg container is fixed as is, the only thing you can do to improve it is to decide HOW EXACTLY to put your data in it, thats it. You cant have anthing changed on the container itself, without breaking compatibility with existing Ogg ( audio ) parsers ....

[JohnMK]

Best of luck.

[Teegedeck]

Good luck - and: sorry to hear that at the same time.

[KAMiKAZOW]

Originally posted by ChristianHJW
Because Ogg container is fixed as is, the only thing you can do to improve it is to decide HOW EXACTLY to put your data in it, thats it. You cant have anthing changed on the container itself, without breaking compatibility with existing Ogg ( audio ) parsers ....

Ah, OK.

Another question: Which license(s) will you use?
Will you use the combo of 'Specification license' and License for the libraries as MCF (LGPL). I ask, because the SF project page says " License: GNU General Public License (GPL), Qt Public License (QPL)".

[Lazy_Ranma]

Originally posted by spyder
Matroska is Russian. It's a name for a toy doll that has another inside and another inside of that one and so on...

"Matreshka" is the right word. "Matroska" means "sailor's jacket".

[sillKotscha]

Originally posted by Lazy_Ranma
"Matreshka" is the right word.

isn't it "Matryoshka"

and about the nMCF... I think Acaila used to say the right words

'sorry' for you Chris or even good luck with your new project!!

[Atamido]

Originally posted by Lazy_Ranma
"Matreshka" is the right word. "Matroska" means "sailor's jacket".

"Matroshka" is the Germanized version of the Russian word. "Matroska" is the simplified, Germanized, version of the Russian name.

It really is a bad name. The whole reason they are using it is that they wanted to come up with a user friendly way to say "MCF". And because of this it had to start with an "M". There honestly weren't any good suggestions.

But, since they are branching to a different project, they need to come up with a user friendly name, and then create a a three letter acronym for it. If anyone has any ideas for a good name, please suggest them. Also, look to see if an appropriate file extension is available here.

[MfA]

Originally posted by ChristianHJW
Because Ogg container is fixed as is, the only thing you can do to improve it is to decide HOW EXACTLY to put your data in it, thats it.

What is wrong with that?

There is no reason to insist the container format should allow you to put new datafields in the page header ... put that stuff in a seperate stream. Ogg's "inflexibility" presents no problems which cant be solved in an efficient manner, as long as you are not too inflexible in the ways you choose to solve them.

For instance, you can use a meta data stream for an application specific translation of whatever indexing/time-keeping method you want to use to granulepos+packetno in the data stream. Use skip pointers in the meta data for faster seeking if you want. Etc etc.

[sillKotscha]

Originally posted by Pamel
If anyone has any ideas for a good name, please suggest them.

I don't know if it's any good but what about

- *.omp = OpenMediaPack
- *.omf = OpenMediaFormat
- *.omc = OpenMediaContainer

or

- *.ocb = OpenContainerBackbone

and of course OCB as another container for another content... ' insane in the membrane'

[DSPguru]

Originally posted by KAMiKAZOW
Why don't you work with Xiph.org on improving the OGG container?

http://www.xiph.org/archives/advocacy/0455.html

[MfA]

He might be abrasive but that doesnt mean he isnt right.

It was poor form to send it to the Ogg lists anyway. They are in the process of standardizing storage of I/P/B-framed and timestamped video in Ogg ... sending it to theora-dev (where that is happening at the moment) was a questionable decision, sending it to the ogg advocacy list of all places was wrong.

[ChristianHJW]

Originally posted by MfA He might be abrasive but that doesnt mean he isnt right.

You obviously forgot to paste the URL of Steve's reply to Monty, and his reply back, so i do it for you :

http://article.gmane.org/gmane.comp.video.uci.devel/224
http://article.gmane.org/gmane.comp.video.uci.devel/225

It was poor form to send it to the Ogg lists anyway. They are in the process of standardizing storage of I/P/B-framed and timestamped video in Ogg ... sending it to theora-dev (where that is happening at the moment) was a questionable decision, sending it to the ogg advocacy list of all places was wrong.

MfA, i respect you very much as a person and a valuable contributor to XviD, but you're making a very big mistake here IMHO. Your proposing something thats simply not existing, that is a form of 'competition' between Ogg Theora and MCF/matroska.
It is maybe worthwhile mentioning in this respect that on the very same day when Steve and me decided to leave the MCF team i had a very friendly conversation with Emmett Plant, the CEO of xiph.org, on IRC about the whole situation. Emmett offered to help us, and i know he ment that when he said it.

Both, matroska and MCF, have a completely different focus than Ogg Theora ( of course, this is not valid for OGM, which is not supported by xiph.org ). Ogg Theora is focussed on Vorbis and Theora, and unless i am completely wrong here the Xiph people will never aim to put MP3, XviD or AC3 into Ogg. They want to be able to offer a framework around their codes, being based onOgg, thats it. On the other side, Vorbis and its outstanding quality was the main reason for the founding of MCF, as we couldnt use it in AVI without introducing big hacks, so its also responsible for the existence of matroska that way.

Both codecs, Vorbis and Theora, will be very important for matroska, so we would be fools to piss xiph.org people. Please, dont see problems here that are not existing.

[robUx4]

Originally posted by Pamel
"Matroshka" is the Germanized version of the Russian word. "Matroska" is the simplified, Germanized, version of the Russian name.

It really is a bad name. The whole reason they are using it is that they wanted to come up with a user friendly way to say "MCF". And because of this it had to start with an "M". There honestly weren't any good suggestions.

Well, that's not how we got to this name. Given the way Matroska is architecture I thought the russian dolls would be a good symbol for the format. And so I asked around for the name in russian. And it ended up like MATPËWKA (that's what Frank Klemm said) and the german name is Matrioschka or something like that. Since some people thought that the russian name and the german name would be too hard for Joe Average, we came up with a more simple one. Which actually is our creation, like the format

[MfA]

I didnt posted the original link, and he took back nothing of what he said so from my point of view hist last reply was irrelevant.

With only one small exception, streaming, Ogg's purpose is an exact subset of MCF/Matroska. The overhead introduced by it supporting streaming is negligible, since there is a large overlap in the requirements for multiplexing.

As a whole you arent competing with Ogg, but Ogg was competing to be part of your standard ... and it lost out. Personally I find focus a poor reason for that, I never believed focus was the reason why there are so many BSDs either. Their focus presents no problem for Ogm, Ogm doesn't need Xiph's support ... it only needed Ogg.

[JohnMK]

Is there any hope for compromise, a soothing of passions, and eventual re-joining of MCF & Matroska? It really would be grand if both sides could do this. We'd all benefit naturally.