Project Announcement : New Media Container Format

[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)