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

So what about the name? Does it mean something? Sounds Russian....

"matroska" sounds like some weird secret militar operation......
What about MSK for the extension?

"Matroska" sounds good to me, I like the name.
Does that mean we have OGM, MP4, MCF and Matroska as new standards? Also I´m too young to remember the time with VHS, Beta and Video2000, but I know the crappiest won and for the user that many formats weren´t good. But which of them is the crappiest?
I don´t know if it was a good idea to start directly after leaving one project an new one, that will make a lot of confusion.
I know it´s hard to give up all the work/time you spent on it in the last year, but I would have probably done something that helps the users to have only one format: ask Tobias to make his project open-source and ask to help him. I already ask him what´s with making the project open-source, he said that he is going to split the filter in several parts, all the decoding dlls will be open-source, for the rest he don´t know yet.
Will somebody else leave MCF to join Matroska?

matroshka is an old Russian toy, with many puppets contained in each other .. it was Frank's idea, he may give a better background hopefully ...

Well, matryoshka / matreshka are those souvenir nesting dolls, tourists usualy buy in Moscow. So nesting of formats was behind the name, I guess.

Actual matroska makes less sense here IMO. It is sort of warm woollen ahhm... shirt? (long-sleeved t-shirt) with horizontal stripes. Seamans weare those (seaman = matros).

Excellent name for an excellent project! Very clever, Frank.

/ Uosdwis

To finally give us that warm and fuzzy feeling also when it comes to video encoding.


The first thing that came to my mind was actually a female sailor: matros - matroska. Was just a guess but makes about as much sense as the striped t-shirt.

This makes me want to bang my head against the wall repetitively. Does every project which has complications with internal politics have to end up with a fork of the project? In my opinion, kudos to the vorbis guys - I dont see a fork in sight!

But really, this is no good at all, and both formats arent really formats at all as it stands, from a user standpoint.

Ruairi

To make us forget about cold and unfriendly AVI?

Actually sailor's wife . There are no females in the marine.

BTW, John, tell us again about OT posts with large user posted imgs.

Here's Monty's comment about Matroska: http://www.xiph.org/archives/advocacy/0455.html

How about just 'ska'?

Uhm... this is not a good notice (for me).
Sincerly i don't agree with the choise of build more and more containers.
This could make only confusion, and surelly they'll can't be a "standard".

from Ogg Traffic for Sunday, November 24, 2002


I think that if the open source community will focus on a realiable standard we can all benefit from it.

I know that is really difficult to put ideas together to build a cool container, but (in my opinion) is better to work on OGG media container...

Anyway, Open Source means freedom, so this is only a consideration.

Chris, it was my idea to link the name of the toy to the format. And Frank gave us some feedback on the name. Well, it seems that he was wrong in the spelling (is it MATPËWKA is russian ?). But anyway we modified the names he gave us to finish with MATROSKA. So the idea was the toy, it was wrong, but it's not the exact translation anyway.

Well, apparently you never used the unsupported OGM format...

Also, as an answer to another message, we don't start the new project from scratch. We just use what we've been building for the last months in the new project, as the old one rejected it, and most of us consider it's superior. It just makes sense, it's an evolution, not a revolution. Maybe MCF development will continue (as slowly as it always did).

Actually that's our goal. We share the same idea as for MCF (as we evolve from it) : create a portable container that is easy, versatile and can be used on all possible cases. So far it seems to be the case (need to be proven with working code). We are missing a brother to this project : the codec API. We hope the UCI project (Universal Codec Interface) which also aims to be widely portable will become reality too.

and here is my answer :
http://article.gmane.org/gmane.comp.video....o.uci.devel/224
and Monty's one :
http://article.gmane.org/gmane.comp.video....o.uci.devel/225

All streams created with newer versions are completly OGG comaptible. I can anylyse the file with ogginfo, it will tell you that there is one not supported stream (the video) in it and one vorbis stream, but doesn´t report any errors. OGM is not supported by xiph, but it´s not out of the ogg-specs.

Well, I don't know if that goes in the definition of fork or not.

Anyway, Matroska is not compatible with MCF. We have been redesigning the format with a new (modern) approach, but still keep a lot of ideas of MCF. That's why the 2 projects are now split. In most cases, if not all, the overhead produced by Matroska will be smaller that the one of MCF and hopefully of OGG too (even for Vorbis). That's one of the major advantage of Matroska B)

Yes, it looks m0r3 or le55 like that.

BTW when you reach the point, that you'll be about to release something in binary form, hope we'll gonna be the first ones to know it.

Sure, Christian is in charge of that and he knows all the good places
I hope one of the first audio codec (after PCM which is really basic) we'll have in Matroska will be MPC (as Frank Klemm has been helping us a lot, while he was looking for a good container for MPC).

another format


holy crap.......

We already have tons of audio format out here (ACC,MCF,Ogg,WMA,Mp3,mp3 pro,etc)


Why they don't just unite and make a very very best format...instead of split and fight each others

"Why they don't just unite and make a very very best format...instead of split and fight each others"

MCF/new_thing aren't actual audio formats, they're container formats, to store ogg/whatever streams.

I suggest you start a new thread if you want that question answered - it's kinda off topic in this thread.

The question of the splitting can be discussed here.
Most people involved in MCF are now focusing on Matroska because they think it's the very best. MCF has some advantages, but considered minor (fixed sized data at given position).

We all know how bad AVI is for VBR. MPEG-1/2 can only contain their own codec. MPEG4 is complicated. And OGG seem to be missing a lot of things we've designed in Matroska/MCF that I consider essential (like granule position vs timecode). That's what make us think that Matroska is good (easy to upgrade with keeping full backward compatibility). It took a lot of time to reach that point, but it was worth it !

B)

Not at all - Cisco MPEG4IP library has all relevant functions, and you can put anything in the container 3GPP (3G Wireless) and JPEG200 will use the same format.

Well, AFAIK it's based on Quicktime (which is another kind of IFF format like RIFF). I would say that it's AVI with a few additions (for VBR, for example). Matroska is a new kind of IFF format, more scalable (ie will produce less overhead in most cases and can be use for very large data too) and adds a lots of extra feature apart from the muxing. MPEG usually have different levels of encapsulation for that.

That's based on my weak knowledge on the MPEG4 subject.

I don't mean to call your project into question, because I do believe that it will be a good product, nor am I trying to cast doubt on your programming/design skills, but...

Shouldn't you be familiar with the alternative container formats before embarking on your own? At least it might give you more ideas on how to implement specific parts of your project, and at best it would convince you that the already-developed containers do almost everything you want, and that you could simply design some extensions for what's already available.

...Or perhaps you were just being modest

.ogm is not a fomat, it's an extension.

it's an ogg containerformat and xiph.org have said people can use whatever extension they would like.

We did that with those containers that could have been used as a basis for our implementation, like Ogg, but certainly not with MPEG4.

Without having any motivation to starting a flamewar here, i cant really understand the big MPEG enthusiasm some folks seem to be sharing here. Its nice that Menno and Ivan have found a ( hopefully ) well paid job because Ahead wants to support MPEG4 in Nero, but is this really a step into the right direction ?

The MPAA, in the last 2 decades, has been threatening the whole media world with their almost unlimited power, charging stupidly high licensing costs from hardware manufacturers ( and they pass them on to the customer, of course ), software companies and content sellers ... and for what ?? For the pleasure of giving licenses to all the poor believers, suporting their own slavery ?

Of course, everybody is keen on having hardware support for his files, but i can see this coming for Ogg Vorbis also, at least from some manufacturers ( iRiver ), and in not so long time from now. I swear i wont stop until i will be able to play my matroska files in a standalone player, using Vorbis for Audio and Theora/Tarkin for video ..... and dont think we wont come to there, i will prove you wrong.

You may point me to the very nice licensing shemes they are offering currently for MPEG4, as well for the container as for the video compression method. So what ? They can change this any time they like to, its covered and protected by zillions of patents, and they will do so, at leats once the majority of blue laser HDTV DVD standalone units will be shipped based on MPEG4, you may bet !

Now, Ivan said above you can put everything into MP4 ( and he's right, even Vorbis can be put into MP4 meanwhile, thanks to the MPEG4IP people ), but whats the use of that ?

As long as this is not officially implemented and documented, you really think any hardware company would really be looking into this ? Who is MPEG4IP ? A group of people making nice, but unofficial, additions to an industry standard .....

I know whats coming next from the MPEG lovers, as a reply to what i said : '.... So who are you to question the MPEG4IP project, with your 2 and a half developers ... your little container will never become a standard ..' . Well, this is all up to you, the users ... you will decide what container to use for sharing your albums/movies over p2p, you will decide if you buy video editing software with MP4 support or go for Virtualdub with matroska support ( and dont you think the industry doesnt know about Vdubs download numbers .. ) ... and in the end the hardware companies will support a container if they feel they can adress a huge potential target market.

So yes, you are correct to ask who we are compared to the MPAA, and all i can reply is

' ... i have nothing to offer than blood, sweat and tears ..'

Thanks for your interest in what i had to say

Christian

The purpose of MPEG is not to protect some questonable MPAA interests - this is a worldwide standardization body (ISO) with its advantages and disadvantages.

MPEG is not the first and certainly not the last WG inside ISO/JTC - and I would think twice before questioning importance of the worldwide standards.



It is not "Menno and me" situation - it is now 96 industry leaders that support new standard:

http://www.m4if.org/membercompanies.php?PH...def83275829a5bd

After all, Menno and I started work on AAC two years after the standard became available, and two years after professional AAC implementation was working and two years after several hardware implementations became available.

Importance of the standards does not have anything with our salary.

Apart from having "free beer" software there is a LOT of work to be done in order to widespread one standard. Take a look at the growing list of MPEG-4 hardware implementations - on DSP and VLSI devices - because the standard is very well designed for all architectures, UNLIKE some others - but I won't start flaming here because it is not helping any progress.

I have my reasons to believe in MPEG:

1. It is open

2. It is a result of years of research and development

3. It is well designed for all architectures (small memory footprint, possible cheap VLSI, DSP and general-purpose CPU implementations)

4. Has support from many leaders in the multimedia industry



Oh come on, again the conspiracy theory behind codec licensing schemes... did it happen with MPEG-2 - now when we have majority of DVD players in almost all modern PCs? Did it happen with MP3 when it became de-facto music delivery standard? No, it didn't...



At least one code library for reading MP4 would be able to read all tracks, including in codecs that are not MPEG-4 - but that's not my problem anyway And MP4 file format is not MPEG4IP - it is a standard, MPEG4IP is just one free implementation of that standard. By the way, file format is not patented.

MPAA and MPEG don't have anything in common - MPAA does not have a single patent in MPEG standards, nor it does control any of the patent holders. This is all FUD - and I am against any FUD, no matter if it comes from the Thomson Multimedia, or from the OpenSource community - FUD is FUD


Now, this is really getting off topic - if there is a need for new container format, so let it be - but I wonder what will happen again when two of lead developers have different views on the project future? We will have new format... silly, in several years we would have tons of "spin-off" formats.

By the way - I do agree with Monty about that it is easier for someone to write own format instead of checking if existing ones do support some features...

It might turn out that all features you are planning are already supported by some formats (Ogg/Vorbis, MPEG-4 file format, etc..) - and at the end you end with yet-another-file-format. OK, this is cool and nice, maybe some things are easier to do than with other formats, but it just complicates things for developers implementing support for them.

Please do Ivan, please .... i'd be keen if you could point out some flaws in our current specs, so we can resolve them before we freeze specs ....

I perfectly agree !
The question is: why don't you improve OGG instead of build Matrioska ?

When we started to make matroska ( MCF that time ) we looked at this, but abandoned the idea.

The matroska developers might tell you why in more detail than i could do, basically because the container was not very well documented at that time IIRC and because it really has no idea how the packets are put into the pages, leading to major hassle e.g. if you want to seek to keyframes ( for editing/cutting ), generally speaking you always need the codecs help for that.

Meanwhile situation has changed a lot of course, Monty is expanding Ogg for Theora, fine tuning granulepos for key frame seeking, and thanks to Silvia Pfeiffer there is also a very good set of documents available. But please accept that we wont discard all the work we put into matroska, its documentation and developing the specifications, now.

IMHO the Ogg Theora project and matroska dont interfere with each other, at least i never heard Monty has plans to turn Ogg into a general container for

- MPC/musepack audio
- MPEG 1/2 video
- MPEG 1 layer 2/3 audio
- MPEG 2 layer 2/3 audio
- AC3 audio
- MPEG4 video
- Vorbis
- Theora
- Tarkin
- AAC audio
- AC3 audio
- RV9 video
- WMA
- WMV
- all VfW codecs ( in AVI compatibility mode )
- all QT codecs ( in QT compatibility mode )
- all ACM codecs ( in GUID/UUID compatibility mode )
- subtitles
- file attachements ( lyrics, menues )
- menues


Ogg is a specific container, excellent for general audio purposes and streaming use, and will do a perfect job for Theora, i'm sure.


matroska on the other hand shall be the more general approach, specifically for

- movies/anime
- albums ( archive )
- karaoke

I hope Monty will agree that Ogg Theora has a completely different focus here.

I know it's pretentious not to look at OGG while making Matroska (and formerly MCF). I personally didn't (until recently) and believed some comparisons that has been published (noone never questioned the results or really cared). We worked on the format knowing that it would be easier to parse, produce less overhead and contain more informations needed by a general container.

Now I recently had a look at the RFC proposal for OGG. And I was quite shocked by some design choices. It's also very clear that OGG is more a streaming format than a container. Our position in Matroska is that streaming will be handled with a special transport layer : you don't need streaming on a hard drive, CD drive, only on unreliable transports like UDP. And MP4 seem to fall in that category too (where can I get the specs for free ?). We might even consider to use OGG as our streaming container !

Maybe the (supposed) technical superiority won't be enough to be widely used because some companies spent some millions of dollars on a format and are not willing to abandon it (think of how much time it took for MS to abandon DOS). But we'll work hard to make the tools easy, free and cross-platform so that anyone has the choice.

Update :

A first version of libmatroska ( Ver. 0.02 ) is available for developers interested to support the container. The EBML part is finished completely, and some matroska elements are already defined for testing.

Please turn to the mailing lists and read the archives to find out more about it ( links to lists : matroska homepage, contact section.

libmatroska was officially released to developers on the matroska project page on sourceforge today :

http://sf.net/projects/matroska

The library has 'official' status now, as most of the main features are implemented now and it has been tested on various platforms also, including

Windows
Linux
BeOS

All developers wanting to support matroska in their apps are motivated to start doing so, we promise they will get every possible support from the matroska development team.

Currently there is implementation work done for

Virtualdub ( alpha available )
DirectShow parser
Linux muxer ( alpha available )
mplayer playback ( Linux ; alpha available )
Xine playback ( Linux )
Gstreamer encoding/playback ( Linux )

yup...


about the name.. matroska ..

here in norway.. we use to call them
baboska.
i guess that the orign. is matryoshka..
and in finland.. they say matroska..


"funny.. isn`t it...."

And in russian it's "babooshka"

<transcripted>Babuska</transcripted> has the meaning of "grand mother".
<transcripted>Deduska</transcripted> the meaning of grand father.

In the russian language you never have twin vocal except in compound words.

About the grand mother, grand father thing i knew, about twin vocals i didn't , wrote what i heard, corrected i am.

Actually - it should sound like "Babooshka" and it is written like "Babu(s)ka" (there is no Sh letter in general latin alphabet, it exists in cyrilic and some variations of latin - so I can't write it) hmm.. let's try: бабушка

Two vocals usually do not exist in most slavic languages.

Dedooshka is read like.. hmm... Dyedooskha with 'soft' E

Perhaps "Matroska" is a word that perfectly describes the new container format,
but it sounds kinda lame to me...

Find a cooler name!

Reminds me a band called deadywku (sort of pun: you might translate it as 'dead ears')...
May we leave grandmas and grandpas alone. They are perfectly happy with their shellacs and not intrested in any of these digital tricks... B)

I know at least one very very successful firm with a really lame name.
The name is M
NO CARRIER
OK
_

Whatever the name we would have chosen, some people would not like it anyway.
So you'll have to live with this one

I just wanted to add something in the release announcement, that I've stated at the end of my own announcement.

We have been accused many times to be only vaporware. Some people just don't understand than you have to think before proceeding to actual coding and spreading some files. I think it's highly irresponsible to let people use an unfinished format that may completely change in future versions. It may be enough for a small project with a small (religious) user base. But our goal was different. We wanted something that people could use without having to fear future incompatibilities.

So now, the format is officialy not vaporware.