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? :confused:

[ChristianHJW]

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

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. (http://filext.com/index.htm)

[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... :D ' insane in the membrane'

[DSPguru]

Originally posted by KAMiKAZOW
Why don't you work with Xiph.org on improving the OGG container? :confused: 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.

[spyder]

JohnMK:

The problem here is that the creator of MCF, Tronic, does not like the ideas behind Matroska. That makes it very difficult for the two sides to work together. I like MCF's structure. Hell I spent hours on hours coding for it. But it does not easily support streaming or linear writes. Also, small changes to the structure easily break compatibility. These are the reasons I like Matroska. I am not saying MCF is bad, it's just not suited for some uses. Tronic has made it clear that he does not want the complexity of Matroska. Matroska would lose all of it's flexibility if you took away the EBML. That's what makes it Matroska. I will code an MCF parser for Java one day if Tronic wants me too. But right now I am furthering the development of what I see as a great format. robUx4 and I work well together and we both listen to each other. I am not knocking Tronic for standing up for what he wants out of MCF. We just believe this format has too great of potential to abandon. I would love to rejoin the projects as I have worked for nearly a year with ALL of these people. But I just don't see this as being possible. At least not with Tronic's current goals.

Spyder

[robUx4]

Originally posted by 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.

Actually Matroska is basically MCF. Tronic gave me full rights to change what was needed in the format to finish the spec. And I came up with Matroska. But just before we go to Round 2 of the process (start coding, initial freezing of the format) he comes back and say it's not MCF and will only be considered if the "old one" can't fit.

I think my work and all contributions made in the mean time deserve more than this, and I already came to the conclusion that MCF is bad when I changed it to something new/better.

MCF has a few advantages over Matroska and some major drawbacks. So if Tronic finally decides that the old one can't be used, Matroska=MCF. Otherwise Matroska=MCF++.

[JohnMK]

Well I hope he reads this forum . . . I would really like to see people leave pride and vanity somewhere else, and work together. I still think it can be done if you're careful not to let passions interfere.

[ChristianHJW]

JohnMK,

yes, there is a very small chance of the 2 projects reunifying, but its a very hypothetical thing to happen IMHO and maybe only possible if one of the 2 projects would come to a halt somehow and the remaining developers decided to join the other team.

Our first priorities are now to

- get the specs completely finished and documented ( DocBook ), so we can publish and spread them ( 95% done ; ETA : December 2002 )

- Update Steve's C++ code from libmcf so that we have a working libmatroska ( 5% done ; ETA : January 2003 )

- test first files, created with spyder's matroska implementation on Java ( 60% done ; ETA : January 2003 )

- motivate Suiryc to adapt VirtualdubMod_MCF to statically or dynamically link to libmatroska ( 80% done, API is basically the same for both ; ETA : January 2003 )

- find somebody to help myFUN/kromyx to get the DShow filter working for video, and for more than one stream/track to allow switching ( ETA : ? ; until then only spyder's 'javatroska' ( ;)) could be used to watch the movies )

- x-check files created with spyder's Java implementation with VirtualdubMod, and vice versa


As for me, contributing to matroska will look completely different than what i did for MCF, now that we have a fully motivated team and a clear timeline. Its becoming obvious that people are starting to get annoyed by the constant announcements without the chance to get their hands onto something working.

I promise now that this post here is my last post about matroska until we can start public alpha testing, unless somebody will flame the project here and i feel i have to defend it, that is. I guess nobody will mind me doing so ;) ...

BTW : mailing lists will be up tomorrow, namely

matroska-devel@freelists.org
matroska-general@freelists.org

( subscribe here : http://www.freelists.org/signup.html )

matroska-cvs@lists.sf.net

( subscribe here : http://sourceforge.net/mail/?group_id=68739 )

Gmane NNTP interface will be

news://news.gmane.org

gmane.comp.multimedia.matroska.devel
gmane.comp.multimedia.matroska.general
gmane.comp.multimedia.matroska.cvs ( read only )

[temporance]

IMHO you've made am excellent decision opting for an extensible format. Fixed field sizes and fixed field offsets were features of file formats of the 1980's, and we're now in 2002!

However, why don't you build upon the ISO / mp4 file format? This is now a family of file formats and is extensible with UUID atoms. It will be supported by hardware DivX players. IANAL, and AFAIK, there are no patents covering the mp4 file format. And the specs are online somewhere.

The only problem with mp4 are that:
* When capturing to an mp4 file, the already-captured part of the file is not playable until the file is closed (and MovieAtom written). [there could be ways around this]

Btw, what is EBML? I can't find a spec anywhere.

Cheers.

[BlackSun]

EBML is the binary version of XML

[robUx4]

Originally posted by temporance
The only problem with mp4 are that:
* When capturing to an mp4 file, the already-captured part of the file is not playable until the file is closed (and MovieAtom written). [there could be ways around this

At least we don't have such problems. Also we support some kind of UUID but with varying sizes. If the specs are readable somewhere (and easy to read for a human being) I will. It's good to know if we are better/worse and what we could borrow to make Matroska even better :)

[robUx4]

Originally posted by BlackSun
EBML is the binary version of XML

Yes, but it's not something official, like XML. We just invented it because we borrow some ideas of XML :

tag information, so that we can skip unknown informations
variable size of all elements
differentiate the data syntax and the semantic (known by the code, not the file), like an XML file and the related DTD/Schema


Eveywhere where XML is used, it could be turned into EBML. And the opposite is true too. So in the future you might be able to write all the informations about a Matroska file in XML and then use an XSLT processor and transform it into a "mastered" Matroska file ! All this without a single line of code (only a "standard" XLST stylesheet).

[rjamorim]

Originally posted by temporance
IANAL, and AFAIK, there are no patents covering the mp4 file format.


http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,134,243.WKU.&OS=PN/6,134,243&RS=PN/6,134,243

Apple already stated that they are not interested in charging license fees from the usage of technologies included in that patent.

Of course, it's up to you to believe them or not.

And the specs are online somewhere.

http://developer.apple.com/techpubs/quicktime/qtdevdocs/QTFF/qtff-1.html

IIRC, MP4 specs are slightly different, but qtff is good start to understand how it works and what are it's capabilities.

Regards;

Roberto.

[robUx4]

Thanx for all these info.

I've had a look at the patent, and clearly the format is made to be mapped to a C structure. This is not the case in Matroska/EBML because there is no order of elements and the size of the same element can vary from 1 byte to an infinite number of bytes (theoretically). And we use the same variable size for all "Atom IDs" (to use the Quicktime terminology) too.

Hey, we're in 2002 ! ;)

[robUx4]

...Which leads me to another reflection. If any company want to make smething similar to EBML, it won't be "patentable" ! Because there is a prior art : Matroska :)

I just hope noone already did something similar. But I doubt there would be patents on the EBML, because it's similar to UTF-8 coding which AFAIK has no patent (at least it's free to use it).

[Latexxx]

I hope that you won't keep matroshka as the final name for the format. Imagine when h4x0rs start to use it: ThE_rEaLly_CoOl_mOVie-xvid-570-320-no-shit-non-cam-version.2002.matroshka Matroshka is a great name, but it is too long. I would suggest that you would select something like .mc2 to the end of the file name. Mc2 come from something like mcf^2 because matroshka is based on mcf and it is better version. Mc2 also refers to Einstein famous e=mc^2 thing(don't know what to call it in english).

[robUx4]

Matroska is the name human beings should use to refer to the format. For the file extension you're talking about, we have (nearly) decided to use .kas for matroska files containing Sound only, and .kav containing at least Video. Later extensions will be created when required.

[bond]

uhh that sounds too russian...

Why dont you use mc2 or omp, omf or omc...

kas is a slang word in german for cheese -> if something is shit you can say that it is "a kas"! :D

[Atamido]

MC2..... I like it. And the whole E=MC2, thats pure genius. Also, the reference to MCF version 2 is nice. Except it could be the Matroska Container Format version 2. Nobody ever wants to go with the version 1.0 of something, so we could start off with the 2.0 version. ;)

The only issue is that it doesn't differenciate between audio and video in the extension. Unless of course you did MC2 and MC3.

I can think of some pretty cool banners containing something along the lines of "E=mc2, A=mc3, V=mc4... Matroska, it just makes sense"

Does that sound cool to anyone else? (the A is for audio, and the V is for video. Kinda plays off of the mp3 and mp4 phenomenon too.)

[robUx4]

Yeah, that will just lead to confusion with MCF (no competition, please) and the MPEG files. Also for the version number, I hope there will never be a need for Matroska version 2 ! That's why it's designed with all possibilities in mind.

[Atamido]

Originally posted by robUx4
Also for the version number, I hope there will never be a need for Matroska version 2 ! That's why it's designed with all possibilities in mind. I know, I just really liked the e=mc2 bit.

[Latexxx]

Choose what ever name you want as long it is easy to remember.

BTW. What does kas / kav refer to?

[robUx4]

Hopefully nothing, but most people will know how to pronounce it :)
It can be taken as matrosKA Sound or matrosKA Video... But it doesn't really matter.

[Ookami]

I think the most appropriate name would be "Mmmm, let's wonder how long this will last before some politics ruin it".

Or "M" or "Most valuabled container format" or "Most advertised container format" or...

Even here we have a thread http://www.hydrogenaudio.org/index.php?act=ST&f=2&t=4746 .

Anyone who keeps track of all "whatever the new name and project is" threads? ;)

Cheers,

Mijo.

[robUx4]

He he.
Hopefully we don't just talk. We work too.
And apparently the most advertised format is not getting more help anyway... :sly:

[ChristianHJW]

Originally posted by Ookami Anyone who keeps track of all "whatever the new name and project is" threads? ;)

me .. :P

Hey Ookami, a bit more enthusiasm about the future of video encoding please.

The split was not planned, believe me. But i swear it was the best thing we could do actually. Please, be a little bit more patient and we wont disappoint you mate, i promise.

Christian

[Ookami]

Hello Christian...

I am enthusiastic. Remember, I inserted the link to TMF in my programmers corner before you or anyone else from the scene was in it...

Because I believe we need a new container format...

I'm just disappointed with the current events.

I wish you all the luck and fun. You and your team have my moral support (I know it's not much worth, but still...)!

Cheers,

Mijo.

[robUx4]

He he. Thanx for the support.

And don't worry, the wait for a new container has been long. But it won't be long now until people can use it. And I hope (think) that it was worth the wait.

As a side not, there is also a need for a codec architecture (UCI is supposed to fill that gap) and a Menu system (that should be integrated in other containers too), AFAIK there is no menu system existing. I mean something like advanced stuff like on DVD menu (hotspots, variable settings, etc).

[ChristianHJW]

Originally posted by Ookami
[B]Hello Christian...
I am enthusiastic. Remember, I inserted the link to TMF in my programmers corner before you or anyone else from the scene was in it...
Because I believe we need a new container format...

Really, i had no idea ! It as Ingo Ralf Blum pointing us to TMF, i wouldnt know you found it before he did. A good proff you know whats going on ;) ...


I'm just disappointed with the current events.

So are we :( ... really, if anybody believes it was easy for me to abandon my beloved child, you are wrong. But sometimes its better to make a clear cut.

'Lieber ein Ende mit Schrecken als Schrecken ohne Ende ...'

( 'Better and end with terror than never ending terror..' )

I guess this German saying hits the point here.

I wish you all the luck and fun. You and your team have my moral support (I know it's not much worth, but still...)!

You're wrong, it is precious for us. Many believers in MCF are disapointed now and turn their back on us. Hopefully we will be able to convince them that only the name has changed, not the team behind it and by no means the mission ...

[OUTPinged_]

We dont turn our backs on you. Never. We do need alternative container format, and ogm seems not enough.

Good luck on 'matroska' container.

(Btw, 'matroska' is giving me laughs as to a person with russian lang. as primary. I will send you a photo of actual thing (a sailor tshirt, not some silly wooden toy) to use it as a banner, will be fun. As soon as i will find it hehe.)

[robUx4]

We know that the russian name is MAPTËWKA, which is pronounced Matrioshka, and we decided to simplify it for the lazy (USAns) people. You'll see that on our webpages we use the russian name too.

[^^-+I4004+-^^]

is this new container XCD,or MCF,or,or?
(yes,yes XCD is cd container...but still...)

i don't care much for the name of it ( matroška? some kind of
cookie , outpinged? hehe ) but if you keep splitting
( XCD from MCF,you guys from MCF....then poor MCF(?))
where does it lead to?
seems like no one agrees there and it's enogh for two people to disagree to found their own project....
i wonder if it's good idea.....

anyhow, anyone that comes up with something better than .avi will be
appreciated so don't mind me bitchin a bit on the splitting thing
and try to give us some tools for creating and watching "matroška's"
(it's š or sh in my lang.) soon

cheers_

ps. ohh and btw. "MAPTEWKA" can't be pronounced as "Matrioshka" as
"P" is "R" in cyrillic alphabet.....
but "Marteshka"......."Mapt" is "Mart" is "May"
( as "month" )
you made a typo there....

[ChristianHJW]

Originally posted by ^^-+I4004+-^^ and try to give us some tools for creating and watching "matroška's" (it's š or sh in my lang.) soon

Alpha testing has just started, but it seems our tools are still so buggy that we probably cant even call it 'alpha' but better 'pre-pre-alpha' ... lol .. :D

Actual Status :

- MP3 and MP2 audio alone works fine, when created with old mpa2mcf.exe ( originally made for MCF project )

- DivX3/4/5 video works ok, but picture is still flickering

- XviD doesnt work at all ( oh my, DivX decoder is trying to decode it in the playback graph, and we have no f..ing clue why )

- MP3 sound inserted by VdubMod together with video doesnt play in the Dshow parser, seems some blocks get incorrect time stamps

- no Vorbis still ( needs to be hardcoded in VdubMod and parser first )

- no MPEG2 video still ( Suiryc doesnt understand pulco-citrons MPEG2 parser code :P )

- no AC3 audio AFAIK

Sounds we still have a lot to do guys :D :D .. but we dont give up !!

[^^-+I4004+-^^]

>Sounds we still have a lot to do guys .. but we dont give up !!

piece of cake,i'm sure.....

btw.i took a look at draft for standard,and i wonder why
am i not seeing any real support for interlaced
stuff
(like the support for proper playback,field order->which field comes first,etc.)
but perhaps it's still to early to discuss it(?)

though you have some interlaced flag
so obviously you have it in mind.......

[robUx4]

Yes, there is a bit to indicate that a video Track contains interlaced data or not. Is there a finer way to do it (I'm a bit video agnostic) ?

[^^-+I4004+-^^]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directshow_sp1/htm/videoinfoheader2structure.asp


this concerns the plb of video
(in my context captured .avi)
if in plb fields are mixed( in time...the fields can be mixed in space too....that is so called "swap-fields" problem-but the latter is of no concern to you,as it's the way the capture device works etc.),plb is jerked in back-forth
manner..(as timeline is not exact ie. what (field that) came first is now
second etc.)
if you're going to put mpeg2 in that container.........
or interlaced divx (little is known of this divx feature,but it works)
(or mpeg2 stream inside the container could arrange this
in proper way?probably a matter of parser etc.)

cheers_

[robUx4]

OK, the valuable part of the document seem to be this one :
dwInterlaceFlags

Bit-wise combination of zero or more of the following flags. The flags in Group 1 are mutually exclusive and so are the flags in Group 2. (The flags in Group 2 are not recommended.) The flags in Group 3 may be combined with each other and with one flag from Group 1 and/or Group 2. See the table at the bottom of this page for more information about flag combinations.
Flag Description
Group 1
AMINTERLACE_IsInterlaced The stream is interlaced. If this flag is absent, the other bits are irrelevant.
AMINTERLACE_1FieldPerSample One field per media sample. If this flag is absent, there are two fields per media sample.
AMINTERLACE_Field1First Field 1 is first. If this flag is absent, Field 2 is first. (Top field in PAL is field 1, top field in NTSC is field 2.)
Group 2
AMINTERLACE_FieldPatField1Only Stream never contains a Field 2.
AMINTERLACE_FieldPatField2Only Stream never contains a Field 1.
AMINTERLACE_FieldPatBothRegular One Field 2 for every Field 1.
AMINTERLACE_FieldPatBothIrregular Random pattern of Field 1 and Field 2.
Group 3
AMINTERLACE_DisplayModeBobOnly Bob display mode only.
AMINTERLACE_DisplayModeWeaveOnly Weave display mode only.
AMINTERLACE_DisplayModeBobOrWeave Either bob or weave mode.

Is there anything missing or not needed in these ?
I personally don't like the Group 1 excludes Group 2... It's a real hole for bugs !

[robUx4]

Also Group 3 can resume to 2 bits only and Group 2 in 3 bits (strange Microsoft guys).

[^^-+I4004+-^^]

>Is there anything missing or not needed in these

well if you copy-pasted everything that contains"aminterlaced"
i think it should be ok (heheh)



btw. i don't see any importance in group2....
and if needed i'll do all the tests needed to establish
if that shi*t serves anything :

->for example:"AMINTERLACE_FieldPatField1Only Stream never contains a Field 2"
this is nonsense and can't ever occur in proper interlaced stream,as this means stream only has field1 and then it's no more interlaced but progressive stream.and i don't see use for it......
->i'm not sure if FieldPatBoth(Ir)regular serves anything
(anyhow,irregular random pattern sounds silly for it to be used on playback )
also:
"(The flags in Group 2 are not recommended.) "

so if anything has to go, throw away group2.....

i can't tell you much on dirx programing,but i can surely tell you what's wrong
with interlaced stream when i see one....

[robUx4]

OK, that makes 5 bits
3 for Group1 and 2 for Group3. It shouldn't be a problem to had them to the current Matroska specs :)
Thanx for the informations.

[Rash]

I have a very bad idea. Why don't we use DVD's vob container? Supports anything you want (mutiple angles, mutiple audio tracks and mutiple subtitles). :P

I want a better container too. Today we have great encoders and old containers. :(

[ChristianHJW]

Originally posted by Rash I have a very bad idea. Why don't we use DVD's vob container? Supports anything you want (mutiple angles, mutiple audio tracks and mutiple subtitles). :P
yes, but only MPEG2 video ...
I want a better container too. Today we have great encoders and old containers. :(
Thanks for the motivating words .. you seem to have a very good understanding of what we are trying to do and why ..... if you ever feel like you wanted to support our project drop me a mail to christianhjw at users dot sf dot net ....

[Rash]

Sorry Christian but I don't really have that programming knowledge to help you develop a container. :(

[ChristianHJW]

Originally posted by Rash Sorry Christian but I don't really have that programming knowledge to help you develop a container. :(

I said that many times, you dont need to be a developer to be able to support an open source project. Registering to the mailing list ( http://matroska.org ) and giving input to the developers asking questions to potential users is one possibility, helping with design, logos, website creation etc. another way. Of course, to give valid input to the devs you shouldnt be a complete n00b on video compression ;) ...


Please allow me to wish you all a happy new year and thank you for the patience and all the mental support we got. Big parts of libmatroska source code, at least most of the EBML stuff of it, is lying on robux4's HDD already, but we could not have a working version of it finalized by the end of the year as i was hoping.

Spyder482 has all the EBML part of his Javatroska finalized and debugged ( he had a stupid bug in his code that tok him days to find ) now, so i have high hopes on him that we will be able to produce valid matroska files with his JMF based tools in the course of January.

See you all next year, hopefully all well and ready to meet with the future of open source audio and video encoding :D :D .....

ChristianHJW

[Atamido]

Originally posted by ChristianHJW
I said that many times, you dont need to be a developer to be able to support an open source project. Registering to the mailing list ( http://matroska.org ) and giving input to the developers asking questions to potential users is one possibility, helping with design, logos, website creation etc. another way. Of course, to give valid input to the devs you shouldnt be a complete n00b on video compression ;) ...
This is true. I don't know a thing about anything, but I still enjoy participating in the discussions. Saying that I actually contribute might be going a bit far. But, I think it helps the real developers to hear ideas from the average Joe. Like if you ask if the format could do some particular task, but they never realized that anyone would want to use it for that. Or occaisionaly you have the old "can't see the forest for all the trees" scenario where you get so focused on some small feature that you forget about the whole purpose. So, I think that comments from regular people, and the occaisional comment from the village idiot do help, even if sometimes in only a round about way.

[ChristianHJW]

Originally posted by Pamel This is true. I don't know a thing about anything, but I still enjoy participating in the discussions. Saying that I actually contribute might be going a bit far....
No its not ! You're contributing a lot Paul, especially your background in subtitles is extremely helpful for us. I will recommend to Blacksun and [Toff] to add you to the dev list on usf.corecodec.org once Cyt0plas gets the server going again ...
But, I think it helps the real developers to hear ideas from the average Joe. Like if you ask if the format could do some particular task, but they never realized that anyone would want to use it for that. Or occaisionaly you have the old "can't see the forest for all the trees" scenario where you get so focused on some small feature that you forget about the whole purpose. So, I think that comments from regular people, and the occaisional comment from the village idiot do help, even if sometimes in only a round about way.
All true, and there is also another very very important factor : Motivation !! There is nothing more demotivating than a dead mailing list ! Feedback from potential users is what drives developers to import their spare free time into writing boring documentations about specifications and write and debug code ....

[bond]

sitting on my toilet there just came the perfect file-extension-name for matroska to my mind:

mp5 (as mp4 is already used :( )

m for matroska
p for packet, power, project...
and 5 for ... uh i guess you will find something in matroska that has to do with 5 :D

and because of this file-extension-name the masses (yeah the masses) will love matroska, just because it sounds like mp3 (and gaining popularity is half the work)

i know this is a little bit sassy but... :D

[ChristianHJW]

Hehehe ... actually i am starting to like the idea ... what about .4pm .. lol :D !!

[stargazer]

Hehehe ... actually i am starting to like the idea ... what about .4pm .. lol :D !!
Why not .pms (PMS - Project Matroska System, The ultimate container in those days of the month)? ;) :)

[Rash]

What do you have against .pm ? :) Plain and simple.

Certaily I'll join the discussion.

[BlackSun]

what about .blacksun ? :D

[ChristianHJW]

I guess we should make a poll soon about it ... there has been one on corecodec.com, but Steve didnt give the user much choice .. LOL

[TetarZ]

It's been a long time since I last of him. But if my memories are good (geeze one does get old quickly trying to keep track of all of these projects) he also branched out of wtf was the old standard name (TMF MCF or I' dont know what) to found his own. U might wanna see if he can rally with you.
P.S.: Please don't branch anymore or my brains are gonna blow out. Anyways You can only branch 36*36*36 times before running out of three characters extensions:sly:

[DeXT]

Uh? I branched? Perhaps you are talking about the old MCF-CD/XCD discussion, which are different projects than Mode2CDMaker, and neither has nothing to do with MCF and Matroska projects. So we are talking about 5 projects here: two extended CD formats, a generic CD creator, and two containers.

Since MCF-CD is mostly dead, I use XCD name because it's shorter and it's basically the same thing (it just lacks the error protection to be a "real" XCD). Remember XCD was designed by avih with Mode2CDMaker in mind. But I did not branch from anywhere since I started developing this alone, before knowing about MCF-CD (and of course XCD). On the mean time Mode2CDMaker will probably become "XCD Maker" once we integrate the error correction into either the tool or the GUI, since I'm currently the only one at charge of the XCD stuff.

So in the end we will have a single Form2 CD format from my side, and a single multimedia container from the matroska (ex-mcf) team, so there is no branching here, but integration ;)

[ChristianHJW]

Originally posted by DeXT So in the end we will have a single Form2 CD format from my side, and a single multimedia container from the matroska (ex-mcf) team, so there is no branching here, but integration ;)

Cant say it better. While Tronic had plans to make his own mode2 form2 burning extension to MCF, robux4 and me were always voting to use XCD. Now with matroska there can be no doubt XCD will be the mode2 extension for us.

As avih cant really contribute to the project for the time being ( i know he will come back !! ) i was offering help to DeXT about developing the XCD Dshow filter to support the new general backup structure for OGM and MP4, but unfortunately our main DShow developer, Jan 'kromyx' Schlenker, cant work a lot on our parser and hardly has any free time to work on that.

I will personally try my best to make both projects a success ..

[TetarZ]

That would rock. Gee I can't wait.
The Riff-cdxa filter never worked on my 'puter and it did get me quite frustrated. But huh here is good news.
P.S. sorry for having all mixed up.

[bond]

so many great ideas but only few resources :(

[ChristianHJW]

Originally posted by bond so many great ideas but only few resources :(

Sorry, missed that reply of yours. Dont worry, comes time, come more resources.

Yes it hurts to see how much effort and coding time from various good people is being put into overcoming the limitations of AVI/VfW, instead of helping us to build something new, better for the future. Please note that i am not talking about matroska alone. Many of the work we do could be used for other containers also ( Ogg Theora, OGM, etc. ).

Its like everywhere, as soon as its out and people can get their hands on it, interest may rise. Before nobody cares and makes his own thing.


BTW : libmatroska 0.02 is out since yesterday. EBML part is completey finished and some important matroska elements are defined. One more week and we may be able to start alpha testing with Virtualdub_matroska and matroskaparser.dll ;). Thanks to the work done with old libmcf before we may have XviD/MP3 and XviD/Vorbis in matroska before February is ending .....

[midiguy]

any ideas for when the first usable version of matroska will be released? by "usable", I mean that you can actually put audio/video into the container, and play the file back in a player. thanks!

[robUx4]

We have an approximate schedule for the end of february. No precise date yet. Hopefully it will already be in VdubMod when it's available and with a DirectShow filter.

[midiguy]

hey, just wondering, should we expect a stable, usable, release? or will it be a public test release (or an alpha, or RC release?) thanks!

[Atamido]

It will be a beta, but it should be a functional beta. Essentialy it will work well as a container, but none of the advanced features will be implemented yet.

[ChristianHJW]

libmatroska has reached a usable status for encoding/muxing yesterday, it was uploaded to CVS and Suiryc was informed that he can start implementing it into VdubMod. robux4 will finalize the decoding part now during the next days and matroskaparser.dll will be updated.

Plans are to

- release the libmatroska library publically, in compiled versions for all supported OS ( Windows, Linux, MacOS ), after decoding part was added. This has only value for developers wanting to look at it, not for the potential user

- test matroskadub and the matroskaparser in a small alpha testing group, at least until we can say its more or less bugfree

- release matroskadub and parser as Beta then. By that time you will be able to use matroska as a real container format, as the basic specs shouldnt change than anymore

- merge matroskadub with standard VirtualdubMod

- motivate more developers ( Gabest, DexT, avih, Zenitram, DarkCracker, Koepi, EmP3R0R, to name only a few ) to support matroska in their tools, so it can get widespread use

- implement all the missing, but specified features such as
* chapters
* menues
* tool to add flexible EDC/ECC for perfect mode2 form 2 support
* MPC support ( Http://corecodec.org/projects/mpc )
* Block reordering/file optimization tools
* USF support ( http://corecodec.org/projects/usf )
* add UCI interface to all important codecs
* add MPEG2 video muxing/storing support ( strip MPEG container )
* create a generic UCI wrapper for VfW and ACM codecs
* implement UCI interface into matroskadub/VdubMod
* add UCI calling capability to matroskaparser
etc.


Still a long way to go, and it will certainly take little a while until we can offer the same functionalities as OGM does currently, but the basic file support could be here until end of february, as robux4 was pointing out above ...

[Lefungus]

I've been watching over mcf/matroska since a year now and i'm impatient as ever to use it. Keep up the good work guys ! Your efforts are fully appreciated. It's the best time for you when finally results are coming

[bb]

I'd like to switch from OGM to a better supported format as soon as possible, so keep going! I'm curious to test what you've got till the end of this month.

bb

[robUx4]

A quick note about the state of the beta release.

The file format basis (EBML) is very stable and tested (at least for read/write). All matroska revolves around this format and is scalable from this point. That means that the files created with the beta library/tools will always be playable by future parsers. Know elements of the format will be used, unknown will be discarded.

[ChristianHJW]

Short update :

Cyrius created a first version od matroskadub, based on VirtualdubMod. It can create and read valid, specs compliant matroska files and is currently tested by the matroska alpha test team.

Also Moritz Bunkus is close to finish work on his matroska muxer for Linux, called 'mkvtoolnix' ( ;) ). He also can create files already, at least with XviD and MP3. Same time he started to write a patch allowing matroska playback on mplayer, but this patch will not make its way into mplayer CVS as it will be based on our C++ library, and mplayer people dont like that. To overcome this problem there are currently 3 ( ! ) developers working on porting the C++ lib to C, so that mplayer people can use it for an official patch.

I also tried to motivate Ronald 'BBB' Bultje to make a gstreamer playback plugin for matroska, but it seems he cant work on that right now as he has other priorities ( matroska support for sure is no priority for gstreamer people now :D ).

The biggest problem we currently have is that our DShow parser developer, Jan 'myFUN' Schlenker, seems to be on vacation or missing in action, so we dont have a working parser filter yet, and the only way to play the created matroska files now is either matroskadub's preview function ( no audio ) or mosu's inofficial mplayer patch, once he has finished it :-( ....

But, as you can see : We will maybe even be able to keep the forecasted beta release date for first matroska files, being end of february :) !!

Christian

P.S. Anybody knows if mplayer will work on Cygwin ? ... LOL

[deXtoRious]

That's great news, I can't wait to test matroska! :D

[Liisachan]

Let me share the results I've just gotten...

[ INPUT ]
XviD Video: 2,079,942 Bytes
LAME Joint Stereo: 311,754 Bytes
Ogg Vorbis Stereo: 311,890 Bytes

[ OUTPUT ]
xvid+mp3cbr.avi 2,352KB (2,408,448 Bytes)
xvid+vorbis.ogm 2,340KB (2,396,092 Bytes)
xvid+mp3cbr.mkv 2,327KB (2,382,707 Bytes)
xvid+vorbis.mkv 2,320KB (2,375,511 Bytes)

Matroska seems cool, at least in its space efficiency :)

[Sigmatador]

and no audio sync problem i hope ? :D

[robUx4]

Originally posted by Sigmatador
and no audio sync problem i hope ? :D

Nop, every data block has a timecode :) (unlike in AVI)

[Liisachan]

Originally posted by Sigmatador
and no audio sync problem i hope ? :D

Er... "No." I mean, I can't test that atm, because there are no players that can replay MKVs yet.
I don't think MKV will have audio/sub synch problems in itself,
but it s possible that replaying MKV will be so cpu-intensive that you have some problems especially with an older PC.
(e.g. Karaoke in soft-subs)

Anyway, to make an MKV file is much easier than expected, literally as easy as clicking. A screen shot:
http://matroska.tripod.co.jp/matroska_rx13.png

ps. i m not an "official" tester nor a matroska developper.

[robUx4]

Nice matryoshka picture (russian doll) you have on the back !
:D

[BlackSun]

Originally posted by Liisachan
Er... "No." I mean, I can't test that atm, because there are no players that can replay MKVs yet.
I don't think MKV will have audio/sub synch problems in itself,
but it s possible that replaying MKV will be so cpu-intensive that you have some problems especially with an older PC.
(e.g. Karaoke in soft-subs)

Anyway, to make an MKV file is much easier than expected, literally as easy as clicking. A screen shot:
http://matroska.tripod.co.jp/matroska_rx13.png

ps. i m not an "official" tester nor a matroska developper.

Just curious, do you use Unicode filename for audio/video files ?

[ChristianHJW]

Originally posted by Liisachan Anyway, to make an MKV file is much easier than expected, literally as easy as clicking. A screen shot:
http://matroska.tripod.co.jp/matroska_rx13.png
ps. i m not an "official" tester nor a matroska developper.

Ehem ... would you mind telling me where you 'found' matroskadub, so we can fix this hole ?

Dont misunderstand me, i dont have problems with that if you are 'testing' matroskadub ( in fact, half of the old alpha test team seems to have lost interest :( ) as i consider you being an experienced memeber, but i would have a problem if any uninfomred people got their hands on this version and were spreading files out to the wild to be 'cool' !! It wouldnt be a big desaster, as the files we create now ARE already specs compliant ( or so we honestly believe :D ), but we would prefer to wait a bit longer before releasing any tools.

Thanks for telling me mate ... i promise i'll add you to the 'official' alpha test team, just drop me a PM here with your email addy, so i can give you further instructions.

ChristianHJW

[Liisachan]

Originally posted by ChristianHJW
Ehem ... would you mind telling me where you 'found' matroskadub, so we can fix this hole ?

well, er, you are the very person who "leaked" that link to a public mailing list :confused:
You gave the link for alpha2 even after Steve Lhomme asked "Chris, are you aware you sent this link to a public mailing list ?" so I thought this was supposed to be a kind of public test. Sorry if it was not like that. But that link was also copied in a forum in Japan (not by me); we are so much interested in MKV seriously, partly because we are not happy with sub support in today's OGM here in japan.

Originally posted by BlackSun
Just curious, do you use Unicode filename for audio/video files ?
No, usually not.
My file system is NTFS, so technically all filenames are internally Unicode (UCS-2) iirc, and I can have, say, Korean filenames and Japanese filenames in the same directory. I do that sometimes, but not usually, because many pieces of software (DivX Player 2.0, mIRC...etc, etc) don't work fine if the path or filename contains so-called multibyte characters.
Plus, if the audio file contains mb characters, you'll have to use IME(something you ll need to type in Eastern languages) just to type "lame --alt-preset filename" or "oggenc filename"; it's too much of a bother...

[ChristianHJW]

Originally posted by Liisachan
[B]well, er, you are the very person who "leaked" that link to a public mailing list :confused:
You gave the link for alpha2 even after Steve Lhomme asked "Chris, are you aware you sent this link to a public mailing list ?" so I thought this was supposed to be a kind of public test.

Uhmmm ! Does that mean there are actually other people than us reading our mailing lists ?? :D :D ... lol .... what a success !! :)

Sorry if it was not like that. But that link was also copied in a forum in Japan (not by me); we are so much interested in MKV seriously, partly because we are not happy with sub support in today's OGM here in japan.

Dont worry, as i said above the files created with it are pretty much specs compliant already, so its no big deal. I was literally too lazy to sned a private email copied to the 25+ team members we have now, so i took the easy road and sent it to the ML.

Anyway, this link is for the old version with huge memory leaks in the library, so nobody could ever create a real movie with it, unless he has got 1.5 GB or RAM .... welcome in the alpha test team, email is on the way to you ...

[Defiler]

Originally posted by BlackSun
Just curious, do you use Unicode filename for audio/video files ? If so, VirtualDubMod would have to be modified to support Unicode filenames. I'm running the latest version, and it can't handle nasty UTF-8 filenames like this one:
http://hellninjacommando.com/temp/zplayer01.png

[ChristianHJW]

Originally posted by Defiler If so, VirtualDubMod would have to be modified to support Unicode filenames.

http://sourceforge.net.jp/projects/virtualdubmod

;)

We hope to be able to merge the 2 versions soon, stream is now an official part of the VirtualdubMod Team and working on a general translation structure for VirtualdubMod, so it can be switched to different languages. Of course, handling Unicode filenames is top priority then ...

[Defiler]

This looks awesome. I had to read your reply twice before I noticed that you weren't linking me to the regular SF page. Heh.
From the version numbers, it looks like the JP version is in the same state of completion as the main branch? That's cool.
Is Unicode support really all that difficult? I'd always heard it was simply a matter of using a different Win32 API call, but Blight says that he'd basically have to rewrite Zoom Player to get Unicode support.

[Atamido]

Originally posted by Liisachan
Let me share the results I've just gotten...


I feel that it is important to note that these files do not have a seek index as that part of the code has not been finished yet. While it will be possible to seek in *.mkv files without a seek index, you will not likely see files like this because of the difference in seek speed.

And, although the file will be larger with a seek index, and it will depend on how big of a seek index you want, the size required should be minimal. For instance, I will likely only care to have seek points (shown as "CuePoint" in the specs) for every keyframe, but others may want a seek point for at least ever second. Either way, it should not add more than a few bytes for each seek point. (I was trying to add up exactly how many for each CuePoint, but then one of the project leaders posted a list. My numbers were a little different, but he has a better handle on the specs so I will list his.)

Keyframe = 19 bytes
P Frame = 34 bytes
B Frame = 48 bytes

Plus, there would be an additional 10 bytes for the 'header' on the seek portion of the file, and the number should become a bit more efficient with additional tracks. But, ignoring this, if you only marked keyframes (makes the most sense) and the keyframes occured, on average, once per second on a 24fps movie, that lasted 2 hours, and took up 1.4GB (2xCD), then lets see how much that would take up. 1 x 60sec x 60min x 2hr x 19bytes = 136,800bytes. Or, less than .09%. Lets figure in two audio tracks, no lacing, put on some overhead, and you still have around 500KB for a 1.4GB movie. Not a big difference.

[Belgabor]

Originally posted by ChristianHJW
We hope to be able to merge the 2 versions soon, stream is now an official part of the VirtualdubMod Team and working on a general translation structure for VirtualdubMod, so it can be switched to different languages. Of course, handling Unicode filenames is top priority then ... [/B]

Well, they kinda were already merged for 1.4.x, but now we started on updating to 1.5.x (which already has some Unicode support), the update of the internationalisation & unicode stuff is still pending.

[Liisachan]

Tentative Correction

Originally posted by Pamel
I feel that it is important to note that these files do not have a seek index as that part of the code has not been finished yet.

Keyframe = 19 bytes
P Frame = 34 bytes
B Frame = 48 bytes

Plus, there would be an additional 10 bytes for the 'header' on the seek portion of the file

The test clip was 468f, w 3 keyframes (I), 23.976fps, 19.52sec.
So if I unterstand your memo correctly...

(1) to compare with OGM, which can seek by following I-frames,
it would be fair to add 13*3 + 10 = 49 Bytes.
[ Observed Value ]
xvid+mp3cbr.avi 2,352KB (2,408,448 Bytes)
xvid+vorbis.ogm 2,340KB (2,396,092 Bytes)
xvid+mp3cbr.mkv 2,327KB (2,382,707 Bytes)
xvid+vorbis.mkv 2,320KB (2,375,511 Bytes)
[ Corrected (theoretical) ]
xvid+mp3cbr.avi 2,352KB (2,408,448 Bytes)
xvid+vorbis.ogm 2,340KB (2,396,092 Bytes)
xvid+mp3cbr.mkv 2,327KB (2,382,756 Bytes)
xvid+vorbis.mkv 2,320KB (2,375,560 Bytes)

Conclusion: No changes in KB unit

(2) if I can add more "CuePoints" in this smart manner:
- CuePoints must be inserted so that there s alywas at least one CuePoint in each 0.5 sec. (This will enable you to seek freely from any scene to any scene, better than older containers)
- If possible, a CuePoint is inserted on an I-frame, or else it will be on a P-frame.

Since the clip was 19.52 sec, there would be some 40 CuePoints;
3 of which would be inserted on I, 37 on P:
19*3 + 34*37 + 10 = 1325 Bytes ... Correction Value

[ Corrected II ]
xvid+mp3cbr.avi 2,352KB (2,408,448 Bytes)
xvid+vorbis.ogm 2,340KB (2,396,092 Bytes)
xvid+mp3cbr.mkv 2,328KB (2,384,032 Bytes)
xvid+vorbis.mkv 2,321KB (2,376,836 Bytes)

Conclusion: No big changes :)
Correct me if i m wrong.

NOTE: We dont know yet what will happen when we mux more than 2 files as an MKV.

OGM is excellent in this point: the overhead will be about the same even if you mux 8 streams (like 1 video + 1 audio + 6 subs)
I hope the same is true for MKV too.

the keyframes occured, on average, once per second on a 24fps movie

I don't think keyframes are this many, generally.
That's why you cannot set a "Chapter" as you like in OGM file.
(in OGM, when you try to jump to the chapter at mm:ss.nnn,
you will jump to the first keyframe after mm:ss.nnn,
not exactly on mm:ss.nnn. If you don't insert I-frames on purpose for chapters, probably chapters won't work fine: that is how it is in OGM)

[Defiler]

Originally posted by Liisachan
If you don't insert I-frames on purpose for chapters, probably chapters won't work fine: that is how it is in OGMSince, unlike OggMux, VirtualDubMod is aware of both the keyframes and the chapters.. is this a feature that is being looked into?
Edit: I meant for all formats that support chapters, (i.e. Matroska as well as OGM)

[Liisachan]

Originally posted by Defiler
Since, unlike OggMux, VirtualDubMod is aware of both the keyframes and the chapters.. is this a feature that is being looked into?
Edit: I meant for all formats that support chapters, (i.e. Matroska as well as OGM)

maybe VirtualDubMod will work fine for making chapters,
by inserting I-frames properly when compressing.
I m using OggMux and normal VDub to make OGM, and i'll need KeyframeForcer for this purpose (editing .stats file)
http://pat2k2.bei.t-online.de/

sorry to be getting off-topic. i just wanted to say there were not so many keyframes generally......

[ChristianHJW]

Please note that matroska will not necessarily need a keyframe to be able to seek to a specific point in the movie, as matroska's seektable will contain ( in most cases, as per choice of the user ) not only a specific frame that is being played at a certain time, but also the frame(s) its depending from, so its relatively easy and fast to seek even to non-keyframes.
Of course, having a keyframe at a chapter start is always recommended, to allow editing/cutting on chapters, and because seeking will of course be faster when pointing to a keyframe, so the existing tools to set a keyframe on a chapter starting point by modifying the stats file will do a good service also for matroska ....

[robUx4]

I've reduced the size of elements in a Cue to (worst case) :

K 1+1+1+1+3+1+1+1+1+1+1+1+4 = 19 bytes
P 19+1+1+1+1+3+1+1+4 = 32 bytes
B 32+1+1+3+1+1+4 = 43 bytes

This size may vary (reduced) depending on the length of your movie.

Originally posted by Liisachan [/B]

The test clip was 468f, w 3 keyframes (I), 23.976fps, 19.52sec.
So if I unterstand your memo correctly...

In this case, The size is :
K 17 bytes
P 28 bytes
B 37 bytes

(2) if I can add more "CuePoints" in this smart manner:
- CuePoints must be inserted so that there s alywas at least one CuePoint in each 0.5 sec. (This will enable you to seek freely from any scene to any scene, better than older containers)
- If possible, a CuePoint is inserted on an I-frame, or else it will be on a P-frame.

Since the clip was 19.52 sec, there would be some 40 CuePoints;
3 of which would be inserted on I, 37 on P:
17*3 + 28*37 + 10 = 1325 Bytes ... Correction Value

[ Corrected II ]
xvid+mp3cbr.avi 2,352KB (2,408,448 Bytes)
xvid+vorbis.ogm 2,340KB (2,396,092 Bytes)
xvid+mp3cbr.mkv 2,328KB (2,383,804 Bytes)
xvid+vorbis.mkv 2,321KB (2,376,608 Bytes)

Conclusion: No big changes :)

NOTE: We dont know yet what will happen when we mux more than 2 files as an MKV.

OGM is excellent in this point: the overhead will be about the same even if you mux 8 streams (like 1 video + 1 audio + 6 subs)
I hope the same is true for MKV too.

In MKV it's linear (the more tracks you add, the more overhead).

[Suiryc]

Originally posted by Liisachan
NOTE: We dont know yet what will happen when we mux more than 2 files as an MKV.

OGM is excellent in this point: the overhead will be about the same even if you mux 8 streams (like 1 video + 1 audio + 6 subs)
I hope the same is true for MKV too.

:) taking such an exemple is not good ;)
Subtitle tracks generally don't take that much space (text files), and so don't represent a noticeable overhead.
The funny thing is that when you look at it carefully the relative overhead on a subtitle track is far bigger (can easily reach up to 50% of overhead) than on other (video / audio) tracks.

But I believe that if you add another audio track you will also add the overhead generated by this track (and this overhead shouldn't change because there are already other tracks in your OGM file).
In this respect OGM and Matroska work the same way : the overhead is cumulative.

[ChristianHJW]

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 )

[Teegedeck]

Congratulations to the team!

You've done it, thanks a lot! Now, I'm looking forward to a directshow filter + matroskadub...

[ChristianHJW]

Originally posted by Teegedeck Congratulations to the team!

Thanks mate ! Its really incredible, after a pretty long time of starvation and pain its running pretty well now. The team is growing constantly, in an average by one member every 2 weeks, just because more and more people feel matroska is worth contributing. Yesterday i was in the situation that a new team member asked me what to do next and i couldnt give him an immediate reply really .... thats a completely new situation ... LOL :D !

You've done it, thanks a lot! Now, I'm looking forward to a directshow filter + matroskadub...

Mate, we know each other for a pretty long time .. just drop me an email and you're in the alpha test team. With respect to the DirectShow parser/splitter : MyFUN is back from vacation and already working hard to get a first alpha out of the door, while Mosu could play XviD and Vorbis already in his mplayer patch end of last week ;) ...

[Teegedeck]

Hehe, I'm planning on a little CPU-upgrade for this week or next; after that I'll be good alpha-tester material, again. (Or average at least, unlike now...)

[frodoontop]

First I'd like to say this sure looks like a great project. What I would like to know, is there any date or whatsoever which enables the average guy here around to use it?
Are there for windows XP already players available or when will they be? And I tried searching for it, but I couldn't find matroskadub. Maybe it's just not public yet. But when will this be?
Just a few questions, hope you don't mind...

[ChristianHJW]

The existing code of matroska's DShow filter was now uploaded to CVS, but the filter isnt working yet unfortunately :( .... we hope myFUN will find the error soon.

If the filter is working we plan to make a 2 weeks alpha testing phase with our alpha test team, and will then release all we have as public beta material.

So, in best case we talk about 2 weeks, in very worst case 6 weeks from now ....

[Defiler]

Could you release VirtualDub 2.0 while you're at it? :D

[Atamido]

Originally posted by frodoontop
Are there for windows XP already players available or when will they be? And I tried searching for it, but I couldn't find matroskadub. Maybe it's just not public yet.
Matroskadub is not yet public, but it isn't ready yet anyway. It can mux video and audio into an .MKV file, but it cannot play the audio when previewing it. This version is also, unfortunately, built off of VirtualDubMod 1.4.13.1, and is integrated using a hack in the OGM hack. While it certainly works and produces good files, this is less than optimal. Siuryc has said that Matroska will be fully integrated in the 1.5 tree of VDMod using ((snip). I'm not sure if I'm supposed to talk about that, so I won't)

But yes, when the public beta is announced, it will be with MatroskaDub, a DShow filter, an MPEG-Audio to MKA muxer, Linux mplayer with Matroska support, and a Linux MKV muxer, with everything fully opensource. (I think thats everything?)

The Matroska team is also trying to enlist help with an AVISynth Matroska filter, C libmatroska, MPEG1/2 to Matroska tool, and various other tools to help the transition move as quickly as possible.

[spyder]

I am already working on the MPEG 1/2 muxer for video only. If anyone is experienced enough or interested enough, you can make a full program stream transmuxer. My problem with doing that is motivation. It seems to be an extremely long task which I don't have time for. The code I am working on now takes only elementary streams as input, thus making only simple MKV files with one stream. I may integrate the code into Mosu's mkvmerge so you can mux M1V, Vorbis, MP3, etc... in any combination. :D

[multicone]

bump .... a historic thread !

[sillKotscha]

bump .... a historic thread !

and for what reason the bummer??

the project is dead/ replaced by matroska...

[joseph5]

the project is dead/ replaced by matroska...The project IS Matroska.

[multicone]

and for what reason the bummer??

the project is dead/ replaced by matroska...


Sorry, just seen the replies. Guess i have to visit Doom9 more often :D !

Yes, this was the official project announcement of matroska project those days.

I wonder what the founders (robux4, ChristianHJW) are doing today ? It seems only mosu is still active, improving mkvtoolnix ??