Matroska public alpha release date : 1st May 2003

[ChristianHJW]

Hi all,

i apologize for the very long posting out front, if you're not interested in matroska, well, dont read it ;).

The matroska project, with its predecessor/sister project MCF, was started about 2 years ago. Our aim was to build an open standard and open source A/V container project that was flexible and intelligent enough to last for the next 10 years, and to achieve this we did not just hack some code together quickly and release a first alpha into the wild, but instead we were making a lot of considerations about what such a container should be capable of doing, and we also tried to get advice from many different sides, like other opensource multimedia related projects, what they would consider as necessary and what options could convince them to support our container in their OSS projects.

After this long time, and believe me it wasnt always easy to take this route, the core dev team of matroska was happy and proud to be able to release a first alpha of libmatroska, the basic input/output library that can be used to read and write matroska files, beginning of this year. This library was greatly accepted from guys like Julien 'Cyrius/Suiryc' Coloos, the main developer of VirtualdubMod, and Moritz 'mosu' Bunkus, and they started to work instantaneously with it, building a great set of tools for both Windows and Linux for matroska file creation and also playback ( Linux ). As a result we are maybe capable of releasing a first set of tested tools soon, maybe even before the launch date named above.

So you may ask, what is it about the date that was named in the subject line, the 1st of May ?? Well, unfortunately not all sideprojects are coming along that well. We were maybe a bit naive to believe that every OSS developer out there would stop working on his project immediately, and start implementing matroska support into his tools. But, to be honest, the poor feedback we get from the OSS multimedia world out there is pretty demotivating for us, and we cant explain it at all. Its unacceptable to us that at least 20 - 30 developers in the OSS world are still investing their precious time into hacking strange things into AVI ( like SSA subtitles or DTS audio ), while a library exists allowing them to create matroska files with the very wanted content, but in a spec compliant and technically proof way.

Sure, we have some very good feedback also, like Ronald 'BBB' Bultje from the Gstreamer team announcing he might be able to look at making a Gstreamer plugin for matroska, or Mike Melanson offering to look at supporting at least playback from Xine, Francois 'mmu_man' Revol compiling the mplayer patches for OpenBeOS, etc. But besides that there seems to be not much interest from most other projects out there, and we believ to know why this is : When looking at OGM, the closed source container format based on Ogg ( made by Tobias Waldvogel ), its becoming obvious that the OSS developers only started supporting it after people were actually using it. Its interesting to see in this respect that for doing this there was no nice, clean library, instead the developers looking at it had to more or less reverse engineer the complete container, being major hassle for sure. But they did it, as there were users asking them to support it.

As a result of what is said above, we will change our strategy now. Instead of developing matroska to a very stable status on many platforms, and releasing it then to the public, we decided to release whatever we have on 1st of May. This measure is mainly undertaken to help us, the core dev team, to find the motivation again to work hard and even harder on getting matroska used and accepted, and hopefully that way we will also be capable of attracting the interest of other multimedia OSS developers, so they start supporting matroska in their apps, or maybe even contribute code to the main library.

There is one thing that may complicate releasing the matroska tools on 1st of May, and that is the missing DirectShow parser for Windows. Without this parser filter it will be impossible to release matroska to a broad audience. Our friend BlackSun had always predicted that this huge task is too much for only one person, and it seems our core developer Jan 'myFUN' Schlenker is currently extremely busy with real life stuff ( job ), so he cant contribute as much as necessary to develop the filter into a working alpha status until 1st May. We therefore created a task force yesterday to assist him in bringing the parser filter into a workable state until then. This task force will consist of 6 additional developers :

John 'spyder' Cannon
Ludovic 'BlackSun' Vialle ( DShow consultant, TCMP core dev )
Christophe 'Toff' Paris ( DShow consultant, TCMP core dev )
Steve 'robux4' LHomme
Jory 'Jcsston'
angelfire

All of them are looking at the M$ DShow SDKright now, trying to find out what is necessary to resolve the existing bugs in the current filter. Of course this means that they will stop their work on the current projects. Affected are :

spyder : MPV2MKV ; MPEG1/2 video to matroska
robux4 : libmatroska
jcsston : mpv2mkv GUI , mkvmerger GUI

I hope you all understand the necessity of this step and look forward to the 1st of May, together with us. Comments are welcome.

Regards

Christian

[zulu]

congratulations! looking forward to may 1st :D

[Selur]

Cool, thx for the info :)

Cu Selur

[NoLogo]

I wish you all the best.
I've been using OGM (and praid it) for about one year, but I recently decided to give it up, considering the lack of progress with the DShow filter (especially with subtitles and some other things).
And you couldn't imagine (or maybe you could :)) the number of people I know who are not ready to switch to OGM because of some issues (subtitles again).
So my advice is: go ahead, concentrate on DShow. Remember OGM: first, the only tool for a long time was OggCut (by Tobias), then OggMux came later.
One more idea: if Matroska can really handle with .ssa (and do it good), I guess you can have fansubbers behind you, and kick out AVI.

So, once again, all the best.

Regards
NoLogo

[stax76]

a DirectShow parser is one thing, VirtualDub the other, any information about that?

[BlackSun]

we have a fully working VirtualDubMod that support Matroska. Now just expect some basic features to be available, like playback and muxing of simple matroska file atm...

[Palikrovol]

Go on with it guys, hope may 1st were today :D

[HarryM]

Excelent.
I like OGM (mainly for native suporting of the best audio format- Ogg Vorbis), but competition in this category is essential. :cool:

What advantage have Matroska actually against OGM?

[ChristianHJW]

Originally posted by HarryM What advantage have Matroska actually against OGM? ... well, the current status of the parser filter makes it much much worse than OGM, believe me :D .....

[Acaila]

Originally posted by ChristianHJW
... well, the current status of the parser filter makes it much much worse than OGM, believe meI thought you were a salesman? Such a comment is not really conducive to a good business. Better lie and hope no one finds out :D.

Just kidding.

But anyways, great to hear the project is moving along and bearing fruits :).

[spyder]

As you can probably tell from Chris's post, the Matroska team has lost alot of motivation. The best thing this community can do is show suport for us. We do all this work for you also, not just ourselves. I personally won't let this project die until I am the only one left and I cannot proceed any further. :)

So please keep the good comments and feedback coming. And for any of you developers out there, this is an excellent chance to become part of our project. :)

WE WILL TAKE ALL THE HELP WE CAN GET! (As long as it's productive of course).

Spyder

[mikeson]

@ChristianHJW & all matroska devels:

It's GREAT! Please don't give up and keep working. I'm really looking forward to see (and use, of course ;) ) matroska.

Thank you and take care...

[BoNz1]

ChristianHJW, I think it would be difficult to not be disappointed about some developers lack of interest in your container format, and people's crazed obsession to hack all kinds of things into avi when they could help work on a much better format like matroska. I want to encourage you guys though, you have all put a lot of work into the project and I believe you are heading in the right direction. Releasing an alpha is a good idea I think too, it will spark a lot of interest which can only be good for you guys. I think then the support will come. :)

[CaptainCarrot]

Best decision you could have made, imho.
There is no real alternative besides ogm, which is not really developed further (at least at the moment) and was never actually meant to be what it already is. So just make it public, it'll spread since it's superior to anything else. I mean there isn't even anyone trying to compete with you. So just release it (ok, get that ds-parser working first, but then...).
Feels a little bit like christmas is on 1st may this year... :D
And for your motivation... how about
"Go, Matroska, go, get that freakin DirectShow" :D

Just ask for more if you feel demotivated (or did i scare you) :D

[vinouz]

Dont worry, guys, because we are a number eagerly waiting for this nice format to come. And be sure we'll be numbers to use it.

Because a good container is needed, and there you are :).

So, hope for the 1st of may. If there's VdubMod & Dshow filter working, I'm OK for it. I can wait for the rest. As we did for OGM (but too long, in my mind, now, without progress).

See all the post for DSPGuru's depart. That shows how many people read, think, use, and don't need to tell it, often simply not to disturb discussions with such notes. But the silent crowd is there.


Vince

[robUx4]

Thanks for all the kind words. This is really appreaciated !
We'll make our best for 01/05.

:sly:

[BlackSun]

Originally posted by spyder
As you can probably tell from Chris's post, the Matroska team has lost alot of motivation. The best thing this community can do is show suport for us. We do all this work for you also, not just ourselves. I personally won't let this project die until I am the only one left and I cannot proceed any further. :)

So please keep the good comments and feedback coming. And for any of you developers out there, this is an excellent chance to become part of our project. :)

WE WILL TAKE ALL THE HELP WE CAN GET! (As long as it's productive of course).

Spyder

Instead of posting you should be coding :D

[robUx4]

Originally posted by BlackSun
Instead of posting you should be coding :D

That's a coder who say that ???
:D

[jonny]

robux4 : libmatroska

I want to put my dirty hands on this! :)

ChristianHJW and all the developers: keep up! A lot of people is waiting for the first release!

[Atamido]

Originally posted by HarryM
What advantage have Matroska actually against OGM?
The ones that pop to my mind immediately are:

1. Variable frame rate video.
2. An actual set of specs.
3. Active developers.
4. Opensource tools.
5. Defined specs for every informational MP3 ID3 tag, and almost every other tag in other containers including APEv2, Ogg, RIFF, AVI, Extended RIFF, WMP9, CD-Text, and a few others.
6. More extensible for the future. (This is subjective as the future isn't here, but it was a top priority to ensure anything* could be stored in Matroksa for the next 10 years.)

Okay, I thought of 5 and 6 afterwards.


Note that Xiph may be working on OGM, but we have no indication of this. Also, Tobias's DS filters were supposed to become opensource, but who knows what happenned to that.

* 'anything' = timecode organized packetized data as well as various forms of pasta

[Blueseb]

alpha tester ready to go!:D
don't even think your work isn't appreciated by (potential) users
long life to matroska!!!!

[ChristianHJW]

Originally posted by Pamel The ones that pop to my mind immediately are:
1. Variable frame rate video.
2. An actual set of specs.
3. Active developers.
4. Opensource tools.
5. Defined specs for every informational MP3 ID3 tag, and almost every other tag in other containers including APEv2, Ogg, RIFF, AVI, Extended RIFF, WMP9, CD-Text, and a few others.
6. More extensible for the future. (This is subjective as the future isn't here, but it was a top priority to ensure anything* could be stored in Matroksa for the next 10 years.)

7. matroska can hold any number of audio streams, even if different audio codecs and/or sampling rates were used. Also the DShow filter will support this ( hopefully this year still )
8. matroska can deal with any VfW and/or ACM codecs out there, without having to know what codec it actually is ( see WMV9 VCM )
9. matroska has defined 'native' MPEG4 modes, for simple, simple avanced and advanced mode
10. matroska is supporting b-frames natively, without simply taking the VfW hackery with dummy frames and the like. In addition to that 5 more frame types are defined for future use
11. matroska specs do support h.264 with all the advanced features like improved streaming using NALUs ( video packet distribution with a priority ) already
12. matroska files can be stuffed with additional EDC/ECC(FEC) elements in a very flexible way, for enhanced mode2form2 or UDP streaming support

Just a few other advantages from the top of my head .... ;)

[Mgz]

Originally posted by HarryM
Excelent.
I like OGM (mainly for native suporting of the best audio format- Ogg Vorbis), but competition in this category is essential. :cool:

What advantage have Matroska actually against OGM?

I don't thinks Mastroka vs Ogg, becuase IIRC ChristianHJW said that Ogg is good for streaming but Matroska aim to storage :)

[ChristianHJW]

OGM <> OGG

OGM has the same target group of people as matroska, because all video streaming solutions from Xiph will be built on Ogg Theora, not on OGM for sure .... so a comparison between the 2 is valid.

[robUx4]

OGG is designed with streaming in mind, unlike matroska.
For TCP based streaming we are equivalent (I'm being diplomatic here ;)). For UDP based (RTP) OGG is better... Until we have specified our RTP payload format (that we already have roughly in mind).

[BlackSun]

Originally posted by Mgz
I don't thinks Mastroka vs Ogg, becuase IIRC ChristianHJW said that Ogg is good for streaming but Matroska aim to storage :)

Storage, features and editing (and love :D)

[haibane]

That's the greates news I've heard today........
so the long wait is finally over.....
Rock On, Matroska...........

[alexnoe]

and people's crazed obsession to hack all kinds of things into avi Yesterday, I've finished adding SSA support to AVI-Mux GUI :D

[crOOk]

I can't wait for May 1st! I hope you get the DS done by then... I'm glad to hear all the specs of your container. It really sounds awesome!

[BoNz1]

Originally posted by alexnoe
Yesterday, I've finished adding SSA support to AVI-Mux GUI :D

You are a bad bad boy. :)

[spyder]

Our DirectShow task force is spending every free minute debugging this filter. We hope to have a very stable filter by the time we release. :)

[Siku]

I read those advantages what Matroska have over AVI/OGM and I'm really impressed! Can't wait the 1st May :D

[masken]

ChristianHJW, I think it's definetly the right way to go. Get it out so that it gets attention. Unfortunately, most people don't have any kind of patience with "paper products" (meaning no binaries). Unheartly to the developers it may seem, but believe me, when there's some binaries out there, even in early alpha-stages, you'll get the whole community behind you in development.

Good luck, this is a *very* interesting project, and the work that has been done, together with the specs, indeed truthfully aims at the goal it was made for. And a focus oon a working DirectShow filter is of course one of the most essential things :)

[spyder]

Progress Update:

We (The Matroska DirectShow Taskforce) have debugged the filter a bit and gotten demuxing working properly with a few small problems concerning timestamps which cause a slight stuttering in the playback. Our current working code is not in the CVS yet. We hope to soon have the timestamp issues fixed and look into removing some more annoying bugs in the filter that cause crashes. Only then can we move on to seeking. We have developers working on subtitle muxing, tagging(viewing and editing at post mux stages), the DSF, libmatroska, and MatroskaDub.

Matroska will have a very powerful tagging system, initially including all tags defined by ID3(v1.x and 2.x), APE, Vorbis, WMP9, CD-Text, RIFF info, etc.. More types will be able to be added seamlessly later on. Tags will be able to be used for single tracks or per chapter, depending on the author's desire. Also, I think Pamel is pushing for multi-language tagging to be added to support storing tags in different languages for the same file/track/chapter. It's flexible enough to hold your whole MP3 collection in a single file. Pamel is working on a list of tag elements to be defined in the Matroska spec. There will be more than 100 existing tags supported, but the total variations of tags will be several hundred. If you know of a tagging system not mentioned in this post which you think should be supported please post here.

The DSF taskforce has been steadily working on debugging and repairing the filter to work properly. Yesterday we had playback of video+audio files (Xvid+MP3) with only a small stuttering due to incorrect timestamps we believe. We will be adding block buffering which should make variable framerate playback a reality and also clear up some calculation issues. With block buffering we can use timestamps to calculate the duration of a frame based on the presentation time of the next block.

In the coming days we will be working hard to deliver the best product possible. Our aim is to provide an all-purpose container that will suit any user's needs. Whether it be storing an entire collection of videos in a single file or simply combining video and audio in a synchronised container. We will not yet support a few things that will make Matroska stand out from other containers. We do have limited coding resources. For example, menuing will not be supported at the initial release. The initial release will most likely be no more than simply making a combined stream of audio and video and being able to play it back. We look to the community to join in and help with the next phases. After all, this is our container( yeah, including you ;) ).

John Cannon
Matroska Developer

[mikeson]

@all Matroska devels:

It's wonderful to hear that. I can't wait till 1st May. Please don't lose enthusiasm for working. I (and sure not alone) believe in you and Matroska. :)

Best wishes to you.

Date edited.

[CaptainCarrot]

Hi,
will the bit error correction be supported in the 1st may version, or is that one of the "to be added"-features?

[JimiK]

Why is everybody waiting for March 1st? That was a long time ago, or do you mean March 1st 2004? ;) Nevermind, it's just that I saw this date in another thread, strange coincidence.
After I'm also part of the community, I just wanted to say that I'm also anxiously waiting for the initial release. Just a question about Matroska and players: will it be easy to support it in players using shortcuts like Ctrl-A to switch audio. I think this would be an important factor, because the user wants to have it as comfortable as possible. Of course I know that you're programming a container and not a player. Still I want to now: how can we access different streams? Will it work like the OggSplitter menue so that "Language" or another entry shows up where you can select your stream?
Thank you for pushing that hard towards the initial release,
JimiK

[spyder]

Error correction will not likely be supported in the initial release. The only error protection will probably be CRC32. The ECC will have to be added later.

The release date is May 1st, not March 1st. ;)

We will likely support the same interfaces in the filter as the OggDS filter for player configuration.

[Atamido]

Originally posted by JimiK
Just a question about Matroska and players: will it be easy to support it in players using shortcuts.... Of course I know that you're programming a container and not a player. Still I want to now: how can we access different streams? Will it work like the OggSplitter menue so that "Language" or another entry shows up where you can select your stream?
You're right, this is mostly a player feature, however it will be taken into consideration how to have the player interact with the filter to switch streams.

The interface for switching the stream directly through the filter has not yet been decided on yet, but it will likely take use an interface similar to one of those filters.

[int 21h]

No offense Chris, I wish you guys the best with this project, however, the negative response from other developers stems from the amount of hype this project and the project it originally sprang from have always suffered. All of those developers are busy working on fixing their own bugs and adding their own new features, and more than likely if they are typical OSS developers, barely have time for that, let alone, implement the support for an untested, unusable, but technically superior file format.

However, that being said, I believe you guys have finally realized this yourself. Releasing a working implementation will speed integration of your format into other tools.

So to all of you, keep working, your diligence should eventually pay off. Rome wasn't built in a day, and certainly no one moved in as soon as the blueprints were done.

[ChristianHJW]

Originally posted by int 21h No offense Chris, I wish you guys the best with this project, however, the negative response from other developers stems from the amount of hype this project and the project it originally sprang from have always suffered. .. well, like Nic says, its ' .. a helluva project ...' :D :D !!
All of those developers are busy working on fixing their own bugs and adding their own new features, and more than likely if they are typical OSS developers, barely have time for that, let alone, implement the support for an untested, unusable, but technically superior file format I am a motivation driven, over-enthusiastic person and it took me some time to realize that ....
However, that being said, I believe you guys have finally realized this yourself. true
Releasing a working implementation will speed integration of your format into other tools. So to all of you, keep working, your diligence should eventually pay off. Rome wasn't built in a day, and certainly no one moved in as soon as the blueprints were done. .. Suiryc got XviD and Vorbis playback from matroska working yesterday, without stuttering ... but i cant say yet how he did it, its a surprise ;) .... if the filter will come along for the next 14 days as its doing now, then we should have something working pretty cool on May 1st, being fully opensource, open to anybody and we really do hope to be able to raise the interest of other developers by then. Mosu even got allowance that his mplayer playback patch based on the C++ lib will find its way into official mplayer CVS, at least as an interims solution until there is a C lib .... i wished our DShow filter had the same level already as this mplayer patch has, Mosu is really a wizzard :) ... his program 'mkvmerger' was ported to win32 already and can be the basis for a couple of command line matroska muxers on almost all platforms ... so how could i ask for more ....

[unmei]

how the hell could i overlook this thread till now ???
The first time i actually dived into this forum i saw "matroska" and loved the idea. But i learned that even the cracks need some time to get great things working, and it seems like stupid users like me finally can get a glance of it :)

I really don't know whether i will be able to find any sleep until 1st may - i love you guys and will gladly take and rape any snippet of muxer, demuxer, dshow filter etc you release (well for windoze that is...) :D

*big endorphine shock here*

[vinkes]

@ChristianHJW,

I have a short question:
will I be able to mux ogg vorbis (5.1) , subtitles and realvideo 9 movie in to a matroska container? Is realvideo 9 supported?

Regards

[Atamido]

Originally posted by vinkes
will I be able to mux ogg vorbis (5.1) , subtitles and realvideo 9 movie in to a matroska container? Is realvideo 9 supported?
1. It will eventualy, but probably not at release. Edit: The Matroska team (Toff) figured out how to connect the Matroska filter to OggDS, so now Vorbis is playing back. If anyone *cough*Xiph*cough* would make make a general Vorbis DS filter, I'm sure everyone in the community would be eternaly grateful. Regardless, 2ch Vorbis will be working at launch, but getting 5.1 Vorbis up will probably just take longer.

2. Different subtitle formats are well on their way to being placed in MKV.

3. RV9 could be supported if Real openned the API so you could play RV9 from anywhere. I mentioned this to karl_lillevold, and he said that he is already aware and actively trying to get Real to open things up. If they do, then you can, if not, then you can't.

[Atamido]

Two weeks and counting.....

[ChristianHJW]

Guys, the parser filter is working :D :D !!!

Toff, Blacksun and Suiryc made it !!!!! Even Vorbis audio, and no buffer underruns anymore ;) .... these guys are just great :) ...

[BoNz1]

Sweet!!! I got a whole bunch of stuff on my hard drive: avis and vorbis waiting to be muxed into matroska :)

[marnum]

Yeah, thanks for your great work! The quick success of implementing all these features can only be a sign of Matroska's high compatibility!

[stax76]

I'm a little bit confused right now, there is VirtualDub, VirtualDubMod and MatroskaDub. I wonder which plans the developers of each of the 3 different versions have

[spyder]

MatroskaDub is only a test version for development of Matroska. Once we release it will become a part of VirtualDubMod.

[BlackSun]

Originally posted by spyder
MatroskaDub is only a test version for development of Matroska. Once we release it will become a part of VirtualDubMod.

Sometimes it's called MooDub :D Shame on me.

[Atamido]

6 days and counting.

[frodoontop]

I am counting with you....:)

[Atamido]

I just posted the specs for the tags in Matroska. (http://cvs.corecodec.org/cgi-bin/cvsweb.cgi/~checkout~/matroska/doc/website/specs/matroskatags.html?rev=HEAD&content-type=text/html) These are the same type of thing as ID3v2 (http://www.id3.org) tags in MP3's, and in fact the specs make direct reference to many of the ID3 tags for a better understanding of what they contain. There were also tags pulled from RIFF, APE, and WMP9. They contain information about the file such as song name, singer, author, etc. This is an initial version and has many minor mistakes, and a few fields that aren't filled out, but this list is nearly complete and should provide an excellent view of what they will look like finalized. This list is extensive, and there are several tags that will rarely be used, but we wanted to support importing tags from most file types. We have also tried to minimize having lots of never-used tags by using a structuring system.

I would ask the help of the community in looking over these tags to see if there are any missing that you might use. Please also look at the tags and let me know if you have questions regarding any of the descriptions. Avoid commenting on spelling and other minor corrections as those will be fixed soon.

Thank you.

[BlackSun]

nice work pamel ;)

[ChristianHJW]

Pamel, should we think of starting a new thread for that ? I guess many relevant people who could help may no read this thread here ?

[Atamido]

Yes, if you think that is appropriate.

[ChristianHJW]

Originally posted by Pamel
Yes, if you think that is appropriate. .. yes i do ...

[midiguy]

hey.. I don't know much about this container format, but my question is, quite simply, will I be able to stream video from vfw codecs in this container? will this be available on may 1st? what about progressive download and play? is that supported?

sorry about the newb questions..

[ChristianHJW]

Originally posted by midiguy will I be able to stream video from vfw codecs in this container?

Yes, matroska has a VfW compatibility mode, so you can store any VfW video stream in it. Only problem here is that we dont have a streaming server solution yet, but robux4 has some nice plans in this respect, especially to make UDP streaming possible ( HTTP is comparably easy to do ).

will this be available on may 1st? what about progressive download and play? is that supported ?

We wont have a UDP streaming server solution until May 1st, thats for sure, but maybe the Corecodec Team will have HTTP streaming in TCMP until then, we'll see ...

[ChristianHJW]

Announcement :

We decided to have a feature freeze by the end of today ( GMT ) to be able to test all the available stuff until May 1st ... its not certain if the meta seeking in the Dshow filter will be available by then :( ... but rest assured this will very probably be the first update of the filter once its out ;) ...

[empty]

Only a few days.... :)
And then will I have my very own container. :)
I love you all! :)
Let's go for the matroska-dance! ;)

bb empty

[alexnoe]

I've just noticed something about the name: Is the official name матрёшка or matroska? It would have quite some influence on the "correct" pronounciation...(english people often damage words until they can pronounce them...i don't)

[BlackSun]

Originally posted by empty
Let's go for the matroska-dance! ;)


define :D

[ChristianHJW]

Originally posted by alexnoe
I've just noticed something about the name: Is the official name матрёшка or matroska? It would have quite some influence on the "correct" pronounciation...(english people often damage words until they can pronounce them...i don't)

yes, you're right, the original translation of the russian word ( cyrillic letters ) into roman letters was

'matryoshka'

and we felt thats too difficult for the english speaking part of the world, thats why we created the 'artificial' word 'matroska'. Only problem here is we didnt check if this word has a real meaning in Russian again, and it does ( saiilor's wife or shirt ) :D ... LOL !!

[alexnoe]

Does german and english use different transcription rules?

According to the transcription rules I know, if you write an y, then it usually resembles a ы , which is almost funny (a ы is something between i and ü), while an sh is an ж , not a ш .

I hate such transcriptions :( I'm pretty new to the russian language (started to learn it not long ago), but that much I've already learnt: never try to transcript these alphabets into each other; it will automatically be wrong. Sometimes the words turn out wrong, or even 2 completely different words are suddenly the same (e.g. брат <-> брать ) :(

[robUx4]

Originally posted by alexnoe
I hate such transcriptions :( I'm pretty new to the russian language (started to learn it not long ago), but that much I've already learnt: never try to transcript these alphabets into each other; it will automatically be wrong. Sometimes the words turn out wrong, or even 2 completely different words are suddenly the same (e.g. брат <-> брать ) :( [/B]

That's why we made it wrong on purpose :D

[Nic]

Spent a small part of the weekend looking through the matroska code. Its very professional (& very complex ;) ). Although C++ template code can be a pain to read ;)

Good luck, ill get the code out on May 1st and try make something useful with it :)

-Nic

[crusty]

Just a silly question:

What kind of tool will be available to use it with?
Will it be in the form of an avisynth or vdub filter, or will it be like oggmux/oggcut/avimux ?

I just hope the documentation won't be just in russian :D
I only know Da, Njet, Perestrojka, Glasnost, and, off course, Wodka.:)

On a more serious note:
I think after may 1st stability and compatability should be a bigger concern than the adding off more features. Ogm, avi and mp4 are all suffering from compatability problems more than feature problems (in my view). Being a stable container that's fully compatible accross all platforms will surely be a big boost for matroska.
Kudos to the 'sailor's wife or shirt' team.:p

[Atamido]

Before May 1st, stability is the main concern. They are working on a DirectShow filter that can Play, Pause, and Seek. Once they have those all working properly, then they will worry about other stuff. For instance, Chapters are defined, but nothing is being done to implement them until after the top priority items are completed.

[spyder]

The documentation will certainly be in English ;)

I can only read a little Spanish and that's the extent of my language background ;)

We will have support directly in VirtualDubMod to begin with and a few other tools to mux. The rest is up to time and support. Help out if you can and want something.

[alexnoe]

I hope that the docu is not written by the same person who wrote "informations" about 10 times on that one very page...

[BlackSun]

Originally posted by alexnoe
I hope that the docu is not written by the same person who wrote "informations" about 10 times on that one very page...

The goal of matroska is to provide a robust and flexible container, now if you only care about the typo (or that because some of the dev are french and we write 'informations' in french), don't RTFM :)

[int 21h]

Originally posted by BlackSun
define :D

Jump up and down 3 times and sit down at a table. Pour yourself two shots of Vodka (Stolichnaya is preferred), drink the first shot in rememberance of the men of the past and their great deeds, drink the second in hopes that your deeds will join theirs.

Repeat as needed.

And.. as a bonus:

Recipe for Flaming Matroska
Ingredients:
1 oz Vodka
1/5 oz Bacardi 151 proof rum or Everclear
Mixing instructions:
Pour vodka in shot glass, carefully layer rum on top. Ignite rum and serve.

[N_F]

Originally posted by BlackSun
The goal of matroska is to provide a robust and flexible container, now if you only care about the typo (or that because some of the dev are french and we write 'informations' in french), don't RTFM :)
I guess we now know who did the typo... :D

Just kidding...


On a different topic: I just realised that I will be stuck with a modem connection until the 5th may. Will the various tools be in reasonable sizes?

[robUx4]

Originally posted by alexnoe
I hope that the docu is not written by the same person who wrote "informations" about 10 times on that one very page...

:p

[robUx4]

The tools we should have are :

a DirectShow filter (apparently without seeking :( )
a special VirtualDubMod version that can read/write matroska files
command line tools under linux to read/write matroska files
a special build of MPlayer for linux that can play matroska files (seeking working)
a tool to mux an MPEG audio file into a matroska file
a tool to mux a WAV files into a matroska file

[Teegedeck]

I'm really looking forward to that DirectShow filter! :)

How extensive will error recognition/protection information of Matroskadub-produced files be anyway? (As far as I remember there had been plans to have a user-defined amount of that info that could be added to the file or stripped from it with a tool.)

[Atamido]

At the release, there will be none. Someone is needed with some experience in ECC code to help write this code. At the moment the main programmers are just trying to make sure that the files are created properly and can be played back. However, with some help from someone in the know, this feature should not take long to implement.

[midiguy]

one day left!

[Teegedeck]

Originally posted by Pamel
However, with some help from someone in the know, this feature should not take long to implement.

Good to hear that the idea hasn't been dropped; I like it.

So: May 1st I'm gonna burn some matroska-XCDs... :D

[ChristianHJW]

Originally posted by Teegedeck Good to hear that the idea hasn't been dropped; I like it. So: May 1st I'm gonna burn some matroska-XCDs... :D

To save overhead there are currently no ECC or EDC elements in the standard file. However, matroska's underlying EBML structure allows to add them very easily, even by editing an existing file afterwards with a suitable EDC/ECC tool.

The idea to make adding such elements possible has by no means been dropped, in fact it is the backbone of our plans to make matroska streamable via UDP ( RTP payload ) just like with MP4, and not only via HTTP.

As long as you are aiming to use the capacity of your XCD's to the very last byte ( not recommended BTW ) you are not loosing anything with current matroska creation tools, as then you will be aiming for lowest overhead ( and take the highest risk of course ;) ) ....

In future we can see a situation where users will have 780 - 785 MB of effective space for audio and video on a matroska XCD, while about 10 - 15 MB will be spent to add ECC elements for the very important parts of the file ( block headers, track headers, codec private data, etc. ) to ensure the file can be played in any case, plus some EDC elements for not so important parts ( just to see if they are ok or corrupt ) to allow the handling of these data, specific to each codec and its 'sensitivity' to receiving corrupt data ( skip or not ).

In this scenario you'll have the best compromise of space offering compared to safety, but of course you will also have the choice of spending more bytes for safety if you wish to do so .... :) ...

[Teegedeck]

Thanks for the explanation, Christian!

[crusty]

Sounds like some very cool options are going to be in this new file format!

Just two other (possibly silly as well) questions:

-How do you accomplish the type of forward/backward compatibility you are talking about?

-can you explain it to me ....like I'm a six-year old? :D

Looking forward to trying out a fine new container tomorrow...good work!
:)

[spyder]

Well, the bacward compatibility is achieved through our use of EBML. I know it scares some people to think of it as binary XML. It's a way of defining pieces of a file as having a type and a size. This allows us to skip parts of the file we don't know or care about. also, EBML allows minimal overhead by being able to code the sizes of these elements in as small a space as possible. For example the size of 13 bytes is coded in one byte. Larger values take as few bytes as needed. If done right, we can have backward compatibility with older tools when Matroska 2.0 is available :) We hope to never have to change the structures of the files, only add elements. ;)

Spyder

[crusty]

I think I understand it mostly, you basically build a filesystem inside your container with extensions for possible formats, right?
And you'll probably have some sort of header which indicates the presence of certain formats, right? I know nothing of internal avi, mcf or ogm structure but this certainly sounds like a good setup, creating a sort of 'handles' at which any new stream can be 'hooked up' in some way or another.

Just two short questions:

For example the size of 13 bytes is coded in one byte.
I don't quite understand. Are you talking about error correction here or some sort of compression?

And: Is there some sort of support for multi-angle streams, like from multi-angle DVD's, in the specs?

Thanks for the info anyway.

[spyder]

The bit about the 13 bytes was describing how we code sizes in EBML, the size of an element, like a frame. We use as few bytes as possible to code the size, if 4 bytes are needed then we use 4 bytes, otherwise we use less. This may only make sense to programmers.

Yes, the spec will allow multi angle streams in the form of multiple tracks, a track per angle. And no this doesn't mean you will have to have duplicates of the frames in the streams, only those frames which are needed must be placed in the other tracks. The spec allows gaps in streams. :)

Counting down now...

[alexnoe]

As far as I understand, I could simply put some existing files (Buffy 7x01.avi, Buffy 7x02.avi,...) in one matroska file and make a dvd-like menu, right?

Someone should make a nice authoring tool (or is your modded vdub capable of this?)

[spyder]

You could do that yes...

But currently the menuing hasn't been implemented :(

We are very few doing a lot. We need some support to do the rest.

[BlackSun]

it's hot :D

[crusty]

The bit about the 13 bytes was describing how we code sizes in EBML, the size of an element, like a frame. We use as few bytes as possible to code the size, if 4 bytes are needed then we use 4 bytes, otherwise we use less.

So if I get this right, you use the smallest possible unit to account for the frame size.
1 byte size of frame = 1 byte
16 bytes size of frame = 1 byte
256 bytes = 1 byte
512 bytes = 2 bytes (because now you use 9 bits)
Right ?

And about the multi-angle thing:
Does this mean that a multi-angle movie has one track that sort of gives you the option for 3 separate tracks when there is a multi-angle part, and then you switch back to the original track when the multi-angle part is finished...
Or are there multiple full-length tracks with one track containing the non-angled movie and 1 angle and the other tracks simply have a flag set at certain lengths saying 'use track X for this part' ?
I would think the first option would be more economical.

Sorry if this is getting a bit offtopic, but it puzzles me a bit.

[CaptainCarrot]

Ok, it's first of may here...
The next post of any matroska-coder should contain some download-link(s):D
go,go,go,go,go...:D :D :D :D

[spyder]

Originally posted by crusty
[B]So if I get this right, you use the smallest possible unit to account for the frame size.
1 byte size of frame = 1 byte
16 bytes size of frame = 1 byte
256 bytes = 1 byte
512 bytes = 2 bytes (because now you use 9 bits)
Right ?


Something like that yeah. Except you lose a bit per byte due to the flexibility.

Originally posted by crusty
Does this mean that a multi-angle movie has one track that sort of gives you the option for 3 separate tracks when there is a multi-angle part, and then you switch back to the original track when the multi-angle part is finished...
Or are there multiple full-length tracks with one track containing the non-angled movie and 1 angle and the other tracks simply have a flag set at certain lengths saying 'use track X for this part' ?
I would think the first option would be more economical.


Well, you have a main track and a few other tracks that can be overlays to the main one which will give you the option of seeing the different angles. We also have a similar thing for audio tracks which will allow original or "censored" playback of music from a single file.

[spyder]

Oh yeah I forgot.

http://www.matroska.org/announce.html

Spyder

[BlackSun]

it's there :D

[alexnoe]

Oh ! And the name is a simplified version of matryshoka, :p

[Animaniac]

I'm not sure where to post bugs so early... so i'll do it here. This may be a problem with DirectShow seeking, but here it is. In WMP9 with repeat on, the file fails to repeat after the end, and just displays a blank screen and no audio. There seems to be NULL video being passed to the video filter (in my cass ffdshow) since the classic telltale DirectShow "film" is on in the black empty video pane. Furthermore, WMP9 thinks it's still playing the file, but the seek bar remains at t=0. Other than that, awesome work.

[robUx4]

Yes, the main problem right now is the state of the DSF. It's still a bit early. You can't seek and can't stop/play the file. You have to reload it all the time. Now that all this stuff is released I hope we'll find some more time to slightly improve the DSF. That's the priority right now.

Otherwise you can play it in VDubMod :D

[JagPanzer]

@Matroska Team

Thank you!! :)

[crusty]

Yeah !! New toyz !!:D :D

EDIT: Erm....how and where do you install the directshow filter ?
There's just a dll, nothing else.

[ssjkakaroto]

thx a lot for this container m8s :cool: i've been waiting since the days when divx.com forums were hot (Christian even had a guide on how to create a mp3 file using headac3he LOL)
now it can only get better :D
just one thing, will matroska be able to support different subtitle formats like ass, sub or any new format that pops up just like it is supposed to support any new codecs that appear?

[Animaniac]

Originally posted by crusty
Yeah !! New toyz !!:D :D

EDIT: Erm....how and where do you install the directshow filter ?
There's just a dll, nothing else.

Run... -> cmd
regsvr32.exe "C:\location of dll\kaxdemux.dll"

to unregister
regsvr32.exe /u kaxdemux.dll

[midiguy]

hey.. umm. where do I put the DLL?

[Animaniac]

Originally posted by midiguy
hey.. umm. where do I put the DLL?

Anywhere really. Just use the above registering command.

[midiguy]

got ya, thanks.

well, I got it to work. It has some bugs that need working out. In the beginning of playback, the audio starts but it seems the video is fixed on one frame. then it seems to skip a bunch of frames, then speed up a little, until it "catches up", from then on the file will playback okay. really good though for an early public beta! I can't wait for everything to be worked it, and for it to become a usable container format!

[nutshell]

when I muxed an ogm to a mkv there were 2 small problems:
1. when seeking (in mplayer of course :) ) the player wouldn't jump to key-frames
2. the file had the "seek-freeze-frames" (sometimes if you're seeking through an ogm you get to frames where the seeking seems to hang, it just doesn't go on, you have to jump in a bigger step (backwards) or wait for the frame to pass (forewards) to go on)
When I converted the video to avi and the audio to mka before muxing both to a mkv both issues disappeard

(small) feature request:
AFAICSFYS (as far as I could see from your specs) you define the aspect ratio via display-width/height - would it be possible to get an option for setting the two in mkvtools and/or vdubmod. I have a number of files with non-square-pixels and it would be easier to set the correct aspect-ratio once in the file than every time I play them.
/me is lazy :D

Great work!

[ssjkakaroto]

you can't seek with the current filter yet...

[Rasi]

thats why he said mplayer... he is on linux :P

[ChristianHJW]

Originally posted by nutshell
AFAICSFYS (as far as I could see from your specs) you define the aspect ratio via display-width/height - would it be possible to get an option for setting the two in mkvtools and/or vdubmod. I have a number of files with non-square-pixels and it would be easier to set the correct aspect-ratio once in the file than every time I play them.
/me is lazy :D . Great work!

Yes, this feature is planned, but it seems we have to pack a resizing filter into the DirectShow parser, although we are not completely sure about that ... maybe we can do without, we'll have to consult a few experst to find out how the MPEG container is handling this, as it works even with simple players such as WMP 6.4 ... BTW, spyder will link TCMP and matroska fully soon, using the TCMP CDL ;) .... maybe this will give some first AR support ...

[robUx4]

Yes, the AR might require a hack (so either probably every player will have to handle it their own way). It's also impossible to set it now simply because this is the first version of the tools and library. There are many many improvements planned based on the specs.

Things will get better with time, but it's already in usable state :)

[crusty]

I muxed an avi (divx 5.05 EKG modulated) with the corresponding AC3 track into matroska.
But when I tried to play it in wmp the sound is all screwed.
It sounds as if it's trying to decode to spdif, but I use ac filter 0.68b and I've set it to stereo out.
Haven't tried anything else yet, it was late at night and my eyes where begging for some rest.

[mikeson]

@all Matroska devels:

Great work, guys! Keep it coming, but I'm already charmed. :)

[ChristianHJW]

Originally posted by crusty I muxed an avi (divx 5.05 EKG modulated) with the corresponding AC3 track into matroska.
But when I tried to play it in wmp the sound is all screwed.
It sounds as if it's trying to decode to spdif, but I use ac filter 0.68b and I've set it to stereo out.
Haven't tried anything else yet, it was late at night and my eyes where begging for some rest.

@crusty : can you try to play the file in Graphedit and send us a screenshot of the playback graph ? ( email : matroska-devel at freelists.org )

[Animaniac]

mpa2mka-wxgui v0.1.3 (same with mpa2mka which was tagged as "BAD") creates MKA files that stutter when MP3 files with CBR <160Kbps are used. (Stuttering becomes slower as bitrate increases.) 256Kbps CBR works fine. 320Kbps MP3s are rendered unplayable (i.e. silent). VBR MP3s work fine. I didn't know where to post this bug so here it is.

Edit: Files were played back with kaxdemux.dll 0.3.1. kaxdemux.dll 0.3.0 produced the same results.

[spyder]

mpa2mka is broken ATM. We recently changed the way libmatroska handles the timecodes and the code for mpa2mka is outdated a bit. It gives the library the time in milliseconds when it needs nanoseconds. :)

Please be patient until this problem can be resolved...tonight hopefully ;)

Spyder

[Animaniac]

Originally posted by spyder
mpa2mka is broken ATM. We recently changed the way libmatroska handles the timecodes and the code for mpa2mka is outdated a bit. It gives the library the time in milliseconds when it needs nanoseconds. :)

Please be patient until this problem can be resolved...tonight hopefully ;)

Spyder

Ok. Sounds great.

I've made a bunch or Windows XP Registry keys that make .mka and .mkv files behave (with WMP9) like normal audio and video files respectively, (i.e. shell actions, nice icon, recognized in WMP9 open dialog box, etc.). There's also a key for .mkv to generate thumbnails in the thumbnail view in XP. However, the dsfilter doesn't seem to want to work with it as of yet. (In my case ffdshow came up (with the correct video info), hung around for awhile, and didn't produce a thumbnail.) This should work in the future though... I hope. These worked fine on my computer, use at your own risk. >.< Enjoy. (Attachment needs to be approved.)

[robUx4]

Well done Animaniac. We might ask you for these when everything works fine :)
The DSF right now has some deadlock problems. We are working on fixing it. That may be the cause of all known problems so far. (seeking is just a feature not coded yet).

For mpa2mka, it as been renamed as BAD because it produces spec NOT compliant files. So I can't guarantee future playback of files produced with these tools. These tools will be back to normal as soon as it is corrected.

For the 0.3.1 DSF it fixes the jerky start and missing frames at the end. You can also pause a file and play it multiple times, but still not Stop it.

[BlackSun]

ok, file approved. For obscur reasons the mod panel is slooooooooooow :(

[unplugged]

I'm curious :), when hex-viewing a mastroska video file internally I see index-like data (sequences by ~16 bytes) at beginning of file and one huge index at end of file, this last is about 2 Mb long with 1h:40m video file (700 MB).
What does contain the data at end of file?
(I guess that seek data is only for keyframes as VirtualDubMod says, and guess they are placed at beginning...)

I have read (give a look) the specs at matroska.org, but only certain parts was clear for me (at least for me). I loved that "graphical" scheme made previously for MCF, that was very important for global readability.

Thanks.

P.S.: hope that this great format will be locked soon (no further changes), now I feel this as first priority. Good work.

[robUx4]

All the features already implemented are locked. That means all files created now will always meet the specs (as long as they follow the current specs).

The thing you see at the beggining is the Meta Seek header that store the location of Level1 elements (Tracks, Clusters, Tags, Cues, etc). And the big thing at the end is the Cue entry that contains the location and timecode of all keyframes (depending on how you configure the Cue data in VDubMod). That will be used for super fast seeking in the file (supported soon in the DirectShow filter).

[filewalker]

I muxed 1 AVI/ 2 Ogg Audio/ 2 SRT ( ASCII )subtitels into MKV container although it's not really supported by the current DSF v. 0.3.1.

I believe in your hard work and I want to use MKV to store my movies from now, but I have a question:

Will my .mkv file (with these 3 file formats:AVI/Ogg/Srt) be specs compliant in the future and playable with future DSF ?
Or should we wait till USF is supported from both DSF and VDmod (because of possible changes in the specs)?
In other words, can we mux .srt (ASCII) subtitels into MKV without doubt that it's supported in the future?


PS.
The .srt subtitle is now displayed (using DirectVobSub 2.23) but there is a delay to the audio...but I know it's just the second DSF(and I know that it's not mentioned that it works now)...and, as someone said, the next DSF is coming soon!:)

Cu filewalker :)

[ChristianHJW]

SRT subs can be stored in matroska and the current text subs implementation of both mkvmerger ( Linux ) and VdubMod are already specs compliant.

Depending on the fonts the 2 codec IDs

'S_TEXT/ASCII'

or

'S_TEXT/UTF8'

may be used by the muxing application.

[crusty]

@crusty : can you try to play the file in Graphedit and send us a screenshot of the playback graph ?

Sorry, I already deleted the file from which it came. I don't have the hard disk space right now to do some testing, but later on I will certainly take a look at matroska again.

[spyder]

Good, because the filter is actually stabilizing now...no more crashes for me :)

[robUx4]

New Release

We have just released a new much much improved DirectShow filter v0.4.0 that you can find on http://www.matroska.org/announce.html. The new packaged of tools is tagged as the "Iris release".

It's no more in alpha stage, but in beta now. And there is no known problems for the moment.

As it's not using ASync_Reader anymore, it's not possible to use it with XCD. But we plan to use ASync_Reader again later.

[Gaia]

Sorry i am afraid this new dsfilter doesn't seem to work under Win98se. Unistalled and reinstalled it several times but it seems my system can't find it. I just get "corrupt file or missing filters".

Previous version worked fine.

Plus there's some strange uninstalling problems too.

[robUx4]

Originally posted by Gaia
Sorry i am afraid this new dsfilter doesn't seem to work under Win98se. Unistalled and reinstalled it several times but it seems my system can't find it.

Previous version worked fine.

The matroska files has to be named .mka or .mkv to be recognized by DirectShow. And you have to run the install.bat from the location you put the mkxds.dll !... And keep this file at this place.

Otherwise, you can download TCMP which can associate mka and mkv files to the player.

[Gaia]

Originally posted by robUx4
The matroska files has to be named .mka or .mkv to be recognized by DirectShow. And you have to run the install.bat from the location you put the mkxds.dll !... And keep this file at this place.

Otherwise, you can download TCMP which can associate mka and mkv files to the player.

I did ofcourse all that! Just checked my matroska file with VDubMod and everything is fine so the file is not corrupted.

[robUx4]

Maybe it doesn't work with Win98SE, yes. But I really doubt it. I can't test it here. So anyone else could confirm ?

Update: It might be because it's a Unicode DLL which may not be supported under (old) Win98SE.

We might try to make a non-Unicode DLL soon.

[Gaia]

I tried few things and it seems that Win98SE(updated everything) can't register this filter.

[haibane]

I just tried the new version, seek is now possible, but when not hit on a key frame, only the moving parts of the picture will change and the rest of picture will remain intact until reach the next key frame, the picture below is encode with xvid, I haven't tried other codecs yet. I don't know is this an expected problem.

http://skywalker1.mysitespace.com/Snap1.jpg

[robUx4]

This is known & expected. I'm not even sure it needs to be changed.

If you seek at location 10.523s do you expect playback to start at 13s where there is a keyframeor at 10.520s where there is a frame ? I prefer the first one even though it's not a keyframe. After all at 13s I will also have what have the other behaviour... Just take it like a free extra :)

The only real pb is that when you ask to seek at 10.523s you might start at 10.029s because that's where the Cluster starts, and not the closest frame you requested. This needs to be corrected, and it's planed.

[dsmith]

Oh, I'd say it most definitely needs to be changed. Not in where it starts (if I hit 10.523, it should start at the frame closest to that timecode), but it should definitely give me a full, proper frame. As it is, if I pause and then seek to four or five other positions, I get the frame I stopped on, plus the difference coding for each of the other places I stopped, leaving me with a chunk of blocky ugliness only vaguely resembling anything in the original video. Testing on a couple other files seems to indicate that as long as the new seek position is in a new key frame segment it will generate a proper picture, but if it's in the same key frame segment it will just keep layering on changes without regenerating what the frame should actually look like. This is problematic for videos with long keyframe intervals, and for seeking in a small time-frame.

Also of interest: I downloaded the test2.avi from somewhere (don't remember where) along with the accompanying .mkv version. It's the 5 second clip of a French(?) commercial with the ducks and popcorn. (also regenerated the .mkv from scratch myself to be sure) This doesn't seem to want to provide any image for any seek attempt other than the first frame. In addition, if you start it playing and then seek to different points a number of times, it will eventually crash the application (WMP9 and ZoomPlayer3 tested). Pausing and restarting multiple times also seems to crash the player. I wasn't able to get other videos encoded as .mkv's to crash the players.

--
David

[ChristianHJW]

Originally posted by dsmith Oh, I'd say it most definitely needs to be changed.

I guess a user configurable behaviour would be optimal, in the filter properties window ...

[dsmith]

User configurable? Could you please explain why you'd want to keep that behavior? No offense intended, but I honestly cannot think of why you'd want to allow that behavior to remain in place. At best, it gives the impression of a poorly done, unfinished (and potentially more unsavory terms) product.

Edit: Rereading, I see there's potential confusion about what each of us is talking about. Just to be clear, I'm referring to the inability to generate a complete frame if you seek multiple frames inside a single keyframe segment. Whether the final seekpoint is as close to the point you picked as possible or the nearest/next keyframe is less of an issue, and I can see that being configurable.

--
David

[JimiK]

Maybe I'm wrong here, but imho this is the problem that OggDS has. It seeks to the next keyframe and if you want to go back and your step is not large enough, you hang at that keyframe. But that leeds me to the question: how does Avi do that. Is there something wrong with it too? I, for my part, was always perfectly happy the way Avi is seeking (o.k., it's kind of slow).
Best regards,
JimiK

[ssjkakaroto]

hi there i just took a look over http://matroska.sourceforge.net/overhead.html
but i didn't get much how should i calculate the overhead for a matroska stream. does anyone know how to calculate it for xvid(b-frames on)+ogg when using the default settings of vdubmod?

tia

[robUx4]

Originally posted by ssjkakaroto
hi there i just took a look over http://matroska.sourceforge.net/overhead.html
but i didn't get much how should i calculate the overhead for a matroska stream. does anyone know how to calculate it for xvid(b-frames on)+ogg when using the default settings of vdubmod?

tia

This is page may be outdated, because we use even less overhead :)
The formula to calculate the overhead is a bit complicated because all sizes in the format are variable. I might try to make a simple document for that soon.

edit: please add a Tracker request for that on CoreCodec.org (http://corecodec.org/projects/matroska/).

[robUx4]

Originally posted by JimiK
Maybe I'm wrong here, but imho this is the problem that OggDS has. It seeks to the next keyframe and if you want to go back and your step is not large enough, you hang at that keyframe. But that leeds me to the question: how does Avi do that. Is there something wrong with it too? I, for my part, was always perfectly happy the way Avi is seeking (o.k., it's kind of slow).
Best regards,
JimiK

Finally someone get the idea of what I said ;)
In fact AVI may not have this problem because it can send the reference frame to the decoder and then the B or P frame. But that's actually not how DS would work, it would display the keyframe (first in the flushed stream). So being AVI, OGM or matroska we are all equal ! Don't expect something revolutionary because this is DirectShow anyway. So either you'll have a friendly display but not accurate on the location in the file, or the opposite. (that will be the option in the filter).

[GIR]

I'm running Win98se and WMP 6.4 and the new filter does not work for me either :( I registered it manually, that worked fine said it succeeded, however a quick search of the registry finds no references to "mkxds.dll" when attempting to play *.mkv files in WMP 6.4 the following error occurs: "Class not registered (Error=80040154)"

[spyder]

I think the reason that AVI seeking is slow is that when you seek to a specified timecode it jumps to the closest keyframe before the point you seek to and then decodes from there, only presenting the frame requested. This insures that the frame will be correctly displayed. This is what I think the Matroska DSF should try to do also. Sure seeking will be a little slower but the quality of playback will be 10 times better. For example, has anyone tried playing divx 3.11 files with this filter. I remember when the trend was to use 1 keyframe in a file ;) that made for interesting movies with no seeking to be allowed. I wonder if our filter will even play these after seek. Maybe if the frames are decoded anyway seeking actually works in them now...hmmm...i need to go test. :)

[Calculon]

Is there currently a way to get a variable framerate matroska file? I created two matroska files in vdubmod, one 23.976 fps, the other 29.97. The problem is vdubmod won't let me join them because of the difference in framerate. :(

[robUx4]

Originally posted by Calculon
Is there currently a way to get a variable framerate matroska file? I created two matroska files in vdubmod, one 23.976 fps, the other 29.97. The problem is vdubmod won't let me join them because of the difference in framerate. :(

Matroska allow any track to be of any variable rate, but VDubMod may not be able to do that for matroska yet. It should tell you it's impossible when saving (to AVI), not loading.

[spyder]

Currently there is no way to do this...Though it really should become a feature of VDubMod oneday. The filter should have no problem playing this type of file.

[robUx4]

Originally posted by spyder
I think the reason that AVI seeking is slow is that when you seek to a specified timecode it jumps to the closest keyframe before the point you seek to and then decodes from there, only presenting the frame requested. This insures that the frame will be correctly displayed. This is what I think the Matroska DSF should try to do also. Sure seeking will be a little slower but the quality of playback will be 10 times better. For example, has anyone tried playing divx 3.11 files with this filter. I remember when the trend was to use 1 keyframe in a file ;) that made for interesting movies with no seeking to be allowed. I wonder if our filter will even play these after seek. Maybe if the frames are decoded anyway seeking actually works in them now...hmmm...i need to go test. :)

If some files were encoded like that I don't think you'll have playback pb with the current filter. On scene change a P frame is SO different than the previous (P) frame that most of the image will be fully indepedant, and no more display pbs. If we wanted to check the first keyframe that would be too slow.

BTW, a P frame depends on a P frame, so I doubt in AVI it's parsing all the frames until the one you want to display (at the end of the movie).

[Atamido]

It should not be too long before we have a simple tool to append two tracks to each other, despite the content.

[filewalker]

I muxed 3 SRT subtitles in a MKV file. Display is fine...and the chosen subtitle starts without:) moving the video backwards or forwards slightly(like it was with OGM) and cycling through subtitles works with DirectVobsub2.23, too.Thanks!:)
TCMP CDL plugin (v1.0), a plugin to read more data in matroska files when you use The Core Media Player.
What do you mean with "more data"? I'm just curious...;)
Does that mean that the DSF works better or fluently with this plugin(in combination with TCMP),or what?

Cu filewalker :)

[Animaniac]

Originally posted by filewalker
I muxed 3 SRT subtitles in a MKV file. Display is fine...and the chosen subtitle starts without:) moving the video backwards or forwards slightly(like it was with OGM) and cycling through subtitles works with DirectVobsub2.23, too.Thanks!:)

Did you have to create a filter graph with GraphEdit to get DVobSub to load? The Auto-Loading version doesn't load for me.

Also how are some of you getting multiple audio streams to isolate and switch?

Thanks. ^_^

[filewalker]

DVobSub loads without a special filter graph in my case.
But I generally use the Zoomplayer.I registered DVobSub in ZP... and it could be, but I'm not sure, that I increased the MERIT to a high level (to 00800002)some time ago.So DVobSub loads everytime I open any Media File.

AFAIK multiple Audio stream support/switching isn't supported by the current DSF...so, if I'm right :rolleyes:, we have to wait some time till audio switching'll be supported.:)

Cu filewalker

[robUx4]

Originally posted by filewalker
What do you mean with "more data"? I'm just curious...;)
Does that mean that the DSF works better or fluently with this plugin(in combination with TCMP),or what?

For example it can read all the track info in the file and display (not possible with the DSF now). It should also be able to use the Aspect Ratio settings in the matroska file to display a proper video window. But I haven't tested it yet.

You should also be able to edit many kind of tags in the file too (meta infos).

All these little neat features that makes it better to use.

[Belgabor]

Originally posted by robUx4
Matroska allow any track to be of any variable rate, but VDubMod may not be able to do that for matroska yet. It should tell you it's impossible when saving (to AVI), not loading.

VDubMod kinda can write variable frame rate. According to Cyrius dropped frames are not written. (O.K., its limited ;))

[bill_baroud]

so if i understand well =)

if you have a 120fps clip with 24/30fps mixed part, it will be muxed in a mkv w/o the help of dropped frames and with a sort of VFR ?

it's a _really_ good news O_o

[cca]

I don't remember if anyone mentioned it but so far with the limited success I had with .mkv files I was never able to achieve perfectly smooth playback, the plays jerky. I think these basic problems should be solved before the implementation of features such as XCD suppor, audio stream switcher, chaptering etc.

[Atamido]

That depends on how the 120fps video is created. If it is created where the duplicate frames were just saved as dropped frames in AVI, then yes it would be vfr. If the duplicate frames were actually saved by placing a duplicate frame in the video stream, then it would just be saved as 120fps constant frame rate.

I don't really know how they save the video though as I have no experience with those hybrid videos.

@Belgabor: Any idea what happens when you open an MKV that doesn't contain the dropped frames in VirtualDubMod?

[Gaia]

Originally posted by cca
I don't remember if anyone mentioned it but so far with the limited success I had with .mkv files I was never able to achieve perfectly smooth playback, the plays jerky. I think these basic problems should be solved before the implementation of features such as XCD suppor, audio stream switcher, chaptering etc.

Yeah and dshow filter have to work in every OS. Not just XP and W2K.

[Atamido]

Make sure to install the latest filter as it fixes several issues.

One person has mentioned jerkiness at very high bitrates. I have seen none with the new filter.

The Windows 98 compatability issue appears to only be because of the Unicode support in the DS Filter, which the 9x series didn't support. As robUx4 stated earlier, they will try to recompile it without unicode so that it works properly in Windows 9x.

One other thing, if you have jerky playback, or the seekbar isn't working, then you are likely using the old filter. Last I checked, the TCMP installer has the old version of the filter, so if you install this, you will need to re-register the new filter.

[robUx4]

Originally posted by Pamel
One other thing, if you have jerky playback, or the seekbar isn't working, then you are likely using the old filter. Last I checked, the TCMP installer has the old version of the filter, so if you install this, you will need to re-register the new filter.

Good advice !!!

[robUx4]

Originally posted by Gaia
Yeah and dshow filter have to work in every OS. Not just XP and W2K.

Try this : http://www.matroska.org/downloads/mkxds-0.4.0-W98.zip

Don't use it under W2K/XP otherwise it will kill your HD, processor, memory, power supply and might even kill you in the process.

[Suiryc]

Originally posted by bill_baroud
so if i understand well =)

if you have a 120fps clip with 24/30fps mixed part, it will be muxed in a mkv w/o the help of dropped frames and with a sort of VFR ?

it's a _really_ good news O_o
Yes according to the code I wrote :p and what I know about VDub dropped frames won't be written in the output mkv file (no problem here since matroska is based on timecodes). So your 120fps clip which contains dropped frames would become a Variable FrameRate matroska file.

Now for the moment I have to assume constant framerate in VirtualDubMod (since VirtualDub only handle Constant framerate). So when you reopen the file I rely on the (informational only) Framerate indicated in the matroska file (which is 120fps) and this make that VirtualDubMod should reopen your matroska file as your original clip (i.e. a 120fps clip containing dropped frames).

Of course all of this is theory, since I don't have 120fps clips with dropped frames :p

[Gaia]

Originally posted by robUx4
Try this : http://www.matroska.org/downloads/mkxds-0.4.0-W98.zip

Don't use it under W2K/XP otherwise it will kill your HD, processor, memory, power supply and might even kill you in the process.

It works fine:)It acts strange then you seek but i think it's the effect everybody is talking about.

[bond]

which version should be used in winME?

[Ramirez]

Confirming jerky playback problem, XVID 1000kbps/128kbps Vorbis. DShow filter is current/properly registered.

[ssjkakaroto]

not taking in account all the problems people are having with playback and stuff is it ok to start archiving in matroska yet or are these problems are somewhat related to the file itself too?

tia

[haibane]

Originally posted by Suiryc
Yes according to the code I wrote :p and what I know about VDub dropped frames won't be written in the output mkv file (no problem here since matroska is based on timecodes). So your 120fps clip which contains dropped frames would become a Variable FrameRate matroska file.

Now for the moment I have to assume constant framerate in VirtualDubMod (since VirtualDub only handle Constant framerate). So when you reopen the file I rely on the (informational only) Framerate indicated in the matroska file (which is 120fps) and this make that VirtualDubMod should reopen your matroska file as your original clip (i.e. a 120fps clip containing dropped frames).

Of course all of this is theory, since I don't have 120fps clips with dropped frames :p


I mux a 120FPS clip with drop frame into a mkv file, the file itself plays fine. But when I try to reopen the file with VDM(of course the new version), the virtualdubmod crashed, while it didn't happen to my other mkv files. The 120FPS file was encoded with xvid + 1 track of ac3.

[Atamido]

@bond: Use the 98 version.

@ssjkakaroto: Any problems mentioned so far should be the DirectShow filter.

@Matroska Team: Does the jerkiness have anything to do with the Vorbis DS filter not sending quality reports back to the matroska filter?

[Ramirez]

This time is WMV9 950kbps/AC3 audio track, the problem still persist.
AC3Filter used for decoding.

[cca]

My mistake, when I said I have jerky playback I should have mentioned that I do indeed use the latest filter (0.4.0) in WinXP. The problem is not only with Vorbis as I tried with AC3 also. But I want to believe that these are just infancy problems!

[robUx4]

Originally posted by ssjkakaroto
not taking in account all the problems people are having with playback and stuff is it ok to start archiving in matroska yet or are these problems are somewhat related to the file itself too?

tia

Yes, it's safe. As you can see, the new filter can play files done with the same VDubMod version, and also the Linux tools :) The current problems are only playback problems. We will correct them one by one.

[BlackSun]

Originally posted by Pamel

@Matroska Team: Does the jerkiness have anything to do with the Vorbis DS filter not sending quality reports back to the matroska filter?

nope, but instead the buffers of the output pins of the demuxer I think...

[CaptainCarrot]

About the jerkyness: If you play a divx or xvid-file with fddshow, you can have a look at the actual framerate by popping up the info-tab in the fddshow properties. With matroska-files the framerate is rapidly changing in ranges of 15-50 fps (you can hardly make it out since the framerate for every single frame is shown, but sometimes the first digit is a 1, sometimes a 5). When I put the same videostream in an avi-container, the framerate is still not stable, but between 20-25 fps, which is less jerky. I'm using video-only-streams for this tests.
A sidenote: the playback looks less jerky than with the last dshow-filter, but the numbers in fddshow have actually gotten worse: they were from 15-35 with the old (0.3.1) one.

regards

[ChristianHJW]

The jerky playback seems to occur for bitrates > 1000 kbps ( roughly ) ... we look into this, mainly buffer sizes ...

[Blueseb]

today i had a play-time with this brand new toy :p usin' vdubmod 1511a i remuxed a 1-cd xvid video with up to 2 vorbis tracks and up to 3 srt tracks;

highs: overhead!
ogm: 719425 KB - mkv: 714173 KB :D more than 5 MB gained!!!

lows:
multiple audio switching doesn't work (obviously:not yet implemented :p ), but when using player's internal audio switching (mpc&zp) playback freezes after few seconds, seek will unfreeze but still hanging after a bunch of seconds.

dvobsub works fine but won't autoload :confused:, i had to select 'always load' in its preferences.

many thanks to all you guys, your work is kinda delightful to me ;)

[ChristianHJW]

Originally posted by JuanCC
Any fix for jerky plays?
As said on another thread here, its a stupid little bug that was introduced in latest filter, expect a fix beginning of next week, together with some other fixes ...

[ChristianHJW]

We have AAC working in matroska, thanks to Toff :) !

http://forum.doom9.org/showthread.php?s=&postid=314770#post314770

More details later ...

[GIR]

Try this : http://www.matroska.org/downloads/mkxds-0.4.0-W98.zip

Don't use it under W2K/XP otherwise it will kill your HD, processor, memory, power supply and might even kill you in the process.

OMG!!! are you serious??? I installed the filter last week on my Duron 600 running W98 (I know you said W2K/XP) I then created a mkv in vdub from an avi to test, I opened it up in WMP6.4 and tested the seeking, first time worked with a bit of pixelation, second time worked as well except after a few seconds my PC froze, when I reset my PC would not boot :( I assumed it was either the CPU or the memory causing the prob so I took both down to the computer shop and the CPU was toast!! but when I tested a Duron 850 the MB was found to be faulty also!! so now I have an Athlon 2200 and I'm still running W98, but I am bit concerned about using the DSF at this point I don’t want to fry my new CPU also, it could just be a weird coincidence as I've never known any software to cause such a problem, and I had been working my CPU pretty hard leaving it on for 23hrs compressing SouthPark eps two days earlier, though that task will be alot quicker now :) this new CPU is damn fast, cuts through any digital task like a hot knife in butter :)

[Rasi]

hmm strangely something similar happened here :P

my hardware hopefully still is ok... but since i made a test mkv file i cant play any video content anymore... it either needs 100% cpu load or has blocks all over.. (but the file definately is fine, as the rar archive has valid crc) ... seeking isnt possible either...

dunno if it has anything to do with it, it would surprise me really :P

but point of time is perfect

[ChristianHJW]

The DSF can certainly not harm your CPU's guys ... make it like Winnie The Poo : 'Think, Think, Think ...' ;) .... or do you guys believe that M$ DirectShow would allow any elements of it to kill hardware :O ??

[robUx4]

Yes, that was just a joke to say that the preferred DSF under W2K/XP is the original one. There is NO reason why the DSF would kill any hardware.

[vinouz]

BTW, I've compared mkv files made with virtualdub with OGM ones. Ogm always comes with less overhead. How does it happens some have the opposite scenario ? (ex. BlueSeb)

(to obtain these files I simply converted 'old' divx/xvid avi files both in OGM & MKV. They contain 1 audio track (VBR mp3) and 1 video track. It also did the same when converting OGM with vorbis audio to mkv...)

V.

[ChristianHJW]

New filter is out : http://forum.doom9.org/showthread.php?s=&postid=315391#post315391

[duartix]

Boy, talk about cross-posting...
:D :D :D

Anyway, thank you!

[Atamido]

There are a couple of reasons that the files could be larger. First, the longer the file, the more efficient MKV becomes. So, if you make a 10 second test file, then OGM will probably be a little smaller.

After that, the efficiency depends on the number of blocks, how big each frame is, the number of tracks, how big of a cluster you use, if you use lacing, and if you use any of the special features like Tags.

[vinouz]

Tried it both on small clips for ultralow bitrates (these with vorbis sound @q-1) : ogm~=660kb mkv~=750kb (made with vdubmod)
then on 'normal' dvd backups. very small difference (<.1%...) between mkv and ogm, in favor of ogm. it was xvid/mp3(1 track, abr128), previously made with vdub, repacked with vdubmod.
So I can't tell for the inner matroska settings, but that these were the defaults one made by vdub for the big ones, by vdubmod for the small ones (as I reencoded both audio and video then muxed them, with vdubmod).

The fact is that I was waiting for ogm to be winning on ultralow bitrates (~100kbit/s audio+video), but mkv to gain on dvd backups.
Anyways the fact is that I tried this on the first 10% (~70mb) of the dvdrip. Maybe if I had done it completely, I would have started to see mkv taking on ogm).

Will try to repack the full rip. But I was really astonished by the enormous difference between ogm and mkv at ultralow bitrates (>10% by far). Is mkv header that big ! ??

V.

[spyder]

I'm thinking maybe the mp3 frames are not correctly placed in matroska...I could not tell though, Cyrius will know. :)

[robUx4]

For sure matroska is not ace for ultra low bitrates. But for the other bitrate you mention it should have no problem to beat OGM. What is the frame rate you use ?

[Cantide]

Hi,
I converted a few DVD's to .mkv recently (xvid+vorbis) and filesize was lower for matroska compared to ogg.
movie length ~110min
one audio stream ~64kbps
encoded on 1CD
.ogm 699MB
.mkv 696MB

I haven't tested on shorter clips though.

Cheers
Cantide

[vinouz]

OK. Now did the same test with the same video, but took the full film.

Finally mkv is way under ogm, halfway under avi (WAY meaning 4.5mb on 653, so under 1%, but the double as what ogm gained over avi...)

The numbers :
"Les rivières pourpres"
(Divx4.12)
640x272@25fps
152107 frames
+ mp3 track avg 119kbit/s

original AVI : 675402kb
vdubmod ogm : 673695kb (-1.7mb over avi)
vdubmod mkv : 669234kb (-6.1mb over avi)

Thanks Guys !

NB. : still using the second release of the filter. At the end of the dub, vdubmod took 1mn to get back to its normal state. I first thought it had hung.

V.

[Teegedeck]

Just to give some positive feedback: The 0.41-filter works fine for me; B-frames, VBR-MP3, AC3... I buried AVI a in quiet corner of our backyard, now.

[vinouz]

Yep. Works fine. Except the frame rate seems to be quite irregular.
But after 10 mn I had forgotten it (and I ate the entire movie. gotta go working !).

V.

[jcsston]

I have a new release of the TCMP Matroska CDL, with support for... Tag Reading and Writing :D
I've also corrected many bugs from the previous version.
TCMP Matroska CDL v1.1 (http://matroska.sourceforge.net/downloads/MatroskaCDL.v1.1.exe)

Please note that currently if the file doesn't already have a Tags element the tags will not save. (If it takes a long time for the File Infomation to load, the file very likely doesn't have a Tags element) VirtualDubMod does write the Tags element but mkvtoolnix/mkvmerge v0.4.1 does not.

[BlackSun]

Originally posted by jcsston
I have a new release of the TCMP Matroska CDL, with support for... Tag Reading and Writing :D
I've also corrected many bugs from the previous version.
TCMP Matroska CDL v1.1 (http://matroska.sourceforge.net/downloads/MatroskaCDL.v1.1.exe)

Please note that currently if the file doesn't already have a Tags element the tags will not save. (If it takes a long time for the File Infomation to load, the file very likely doesn't have a Tags element) VirtualDubMod does write the Tags element but mkvtoolnix/mkvmerge v0.4.1 does not.

Congrats :D

hmm is that with the new API I'm modifying or the API == 100 ?

[jcsston]

Originally posted by BlackSun
hmm is that with the new API I'm modifying or the API == 100 ? The TCMP RC3 CDL API

[pirata]

Hi everybody.

With the advent of Matroska, you can enhance your DVD backups with additional audio tracks, which can be really useful if you have to learn a language that's not bundled in the DVDs sold in your country.

Until now, I'd probably found an audio track in, say italian (25fps) for my movie (23.976). Since the container was OGM, I'd have to reencode to OGG for the sake of playability -it is so in my system, maybe not in yours-. In the reencoding, I'd convert from 25 to 23.976. It would take time and efforts.

But, I can use the track as is, be it VBR/CBR MP3, AC3, OGG or MPC. I don't have to reencode, so the last remaining problem is the frame rate difference.

My plan is to multiplex the video and the audio tracks without altering them, keeping the original qualities and frame rates (and not bothering with any time-consuming conversion of any type). On mux time you do synching for all audio tracks as needed (i.e. set the video track from 23.976 to 25 and mux with italian audio; experiment with delays until synch is achieved; afterwards mux video at 23.976 and italian track at 25fps with found delay). Then, on playback time, you select the frame rate of the video channel to fit that of the audio track currently being played. Note that the rate at which the audio track is played would is its original rate. The changes on playback time affect only the video track. I hope matroska, with its time stamps, can deal with this.

Here is my question: is there the possibility, either in Windows (be it using some trick with Zoom Player, TCMP or some Directshow filter) or in Linux (mPlayer)


Thanks

[Rasi]

i dont know if its possible, but this is a great idea in fact!

[robUx4]

Originally posted by Rasi
i dont know if its possible, but this is a great idea in fact!

Audio doesn't have an FPS, so it's not really a problem... Anyway, yes you can remux a complete Matroska file without needing to reencode video and audio... VDubMob can do that and mkvmerge too.

[ChristianHJW]

Originally posted by pirata Then, on playback time, you select the frame rate of the video channel to fit that of the audio track currently being played. Note that the rate at which the audio track is played would is its original rate. The changes on playback time affect only the video track. I hope matroska, with its time stamps, can deal with this.
Here is my question: is there the possibility, either in Windows (be it using some trick with Zoom Player, TCMP or some Directshow filter) or in Linux (mPlayer)

Sorry, but i guess that timestamps may even be a problem here instaed of helping, as the duration of a 23.97 fps movie and a 25 fps movie are different in most cases ( thats why you have to change the sound duration in Cooledit or the like to make it match ).

In short, to allow what you are wanting to achieve you had to rewrite every single timestamp of the video stream blocks before playing them, thus accelerating playback speed of the video.

The only thing that may be possible to achieve that was a trick in the parser to search for different video and audio timestamps, putting a lot of stress on the media where you have the movie on, so it wont work with CD for sure. I dont say it cant be done, but its at least very very tricky ;) ....

[Rasi]

yep.. christian is right there.. thats why european movies are always a little shorter than US ones (or was it the other way round?)

means if you have a original ntsc source of a movie and want to mux a pal version-soundtrack to it it will be too short... or too long

[robUx4]

I still don't get it...

How would 100 mins of video at 23.97 fps muxed with 100 mins of video at 25 fps could end up having a different duration ?!!!

[pirata]

@ChristianHJW:

is it so difficult to recreate the time stamps of the video stream blocks in real time for the new fps? How difficult? Could it destroy fluid real time playback? It seems a matter of computing the timestamp of the frames played at X fps, letting the time stamps of each audio stream as they are... I know I am an ignorant user, but it seems easy to do... please, enlightt me, Christian!

[Rasi]

I still don't get it...

How would 100 mins of video at 23.97 fps muxed with 100 mins of video at 25 fps could end up having a different duration ?!!!


cause the pal version of the same movie will not be 100 minutes anymore.. will more be like 102 minutes

[robUx4]

Originally posted by Rasi
cause the pal version of the same movie will not be 100 minutes anymore.. will more be like 102 minutes

Where do the new samples come from ?

[CaptainCarrot]

NTSC-version-movies and PAL-movies have the same number of total FRAMES, the NTSC-ones being played at 23,97fps, the PAL ones at 25 fps. That means that the PAL movie plays ~4% faster, your 100min NTSC would be about 96min PAL.

EDIT: I just read Nic's post, the PAL-clip will be shorter, 25fps ist faster than 23,97 ;).

[Nic]

I assume he means its 100 minutes NTSC 23.97, so 100*60*23.97 frames...when that many frames are played at PAL it will be a longer clip.

-Nic

[Atamido]

When the Matroska file is created, the audio blocks and the video blocks are written in order of timecode. (you could do it otherwise, but it would be super hard to playback out of order blocks) So, the DS filter is handed the blocks in the order that they are read out of the file. Well, you could rewrite the timecode for the video blocks on the fly. But, as time would go forward, you would be feeding the audio pin in the DS filter much more data than the video pin. This is because you would be reading the blocks out of the file in the order they were written, and all of the audio for the 25fps audio would be in the first 94% of the file. (this might be a little confusing, but just trust me that the audio pin would get much more data.)

Well, someone discovered that when of of the pins if fed much more than the other pins, it stops the filter, waiting for the other pin to be fed. But this wouldn't happen because the filter would still be trying to dump off more audio frames before going back to the video.

You could write the audio blocks in the wrong place for the 25fps audio, but I don't want to think of the problems that could cause.

One solution would be to write a complex buffering system that would cache the frames being fed to the pins so that all of the pins were fed data for the same times. But, even with this, you would have to buffer 4+% of the movie. And 5% of 700MB is 35MB, which would be quite a buffer.

@robUx4: please correct any innacuracies you see here.

[pirata]

Please Pamel, this is important to me. I'd like you to get a little bit more technical, so that I see the problem clearly (I am engineer and think I can understand the mathematics/chemistry/physics/metaphysics involved (or sort of :-) )

I really can't believe that the video stream just cannot be recomputed on the fly, when VirtualDubMod is able to create it from scratch (audio included) at hundreds of frames per second (and that on my old PIII 800MHZ!)... Couldn't it be done by a filter of the like of ReClock? Maybe we should talk to its developer.

[Atamido]

As I said above, you could recompute the timecode on the fly. In fact, I would say that would be pretty easy. The problem is that you would end up with a choked DS filter.

If I was going to guess, I would say you would probably be several minutes into the movie before the audio pin had to much data and blocked the filter. Trying to play the movie beyond that point would result in it playing for a second and then stopping.

This is of course all theoretical, and I could be way off base.

[[Toff]]

In the file, an audio block with a timestamps t should be physically closed to a video block with the same timestamps.
This is required cause we need to read the file linearly. You can't start to read a track in the middle of the file and a track at the beginning or you will kill your cdrom player.

One solution would be to tell the muxer to override the audio track length the same way you want it to be change at playing time.
This way the muxer will distribute audio blocks all along the file.

[robUx4]

Originally posted by CaptainCarrot
NTSC-version-movies and PAL-movies have the same number of total FRAMES, the NTSC-ones being played at 23,97fps, the PAL ones at 25 fps. That means that the PAL movie plays ~4% faster, your 100min NTSC would be about 96min PAL.

OK, this is an explanation I like :)

In fact there is NO problem in the case of matroska. It's all in the muxing application that there might be problems depending on what it's taking as input.

Your 100 mins movie have 143,760 frames at 23.96fps. And 100 mins of audio. When put into matroska it should be normally muxed as a 23.96fps video. You can have audio coming from a 23.96fps movie, 25fps or whatever...

Now if your audio is just 96 mins because the video is played faster and the audio has been reencoded accordingly you have 2 choices :

you decode/time-strech/encode the audio to match the video length (100 mins @ 23.96 fps)
adjust the frame duration of each video frame to match the duration of the audio (96 mins)


In the second case you don't need any CPU intensive reencoding... But it is limited to only muxing multiple audio streams with the same length. If you have a 100mins audio track and a 96 mins audio track to mux with 100 mins of video @ 23.96fps, only the first case is possible.

[CaptainCarrot]

adjust the frame duration of each video frame to match the duration of the audio (96 mins)
A thought about this:
let's say you have a movie at 23,97fps, and 2 audio-tracks, one created for 23,97 that has the correct lenght and a shorter one for 25 fps. I understand that you have fixed timestamps for every videoframe in matroska, but what happend if you used a fixed factor (like (audioframerate/videoframerate)) in the dsfilter to recalculate the timestamps on the fly. This factor would have to be set for every audio track (the default being 1), and it would have to be taken into account reversely for the audio during muxing. But then you could have a situation where the video changes framerate (and playback speed) from 23,97 to 25 and vice versa when switching between the audio tracks.

[robUx4]

Originally posted by CaptainCarrot
A thought about this:
let's say you have a movie at 23,97fps, and 2 audio-tracks, one created for 23,97 that has the correct lenght and a shorter one for 25 fps. I understand that you have fixed timestamps for every videoframe in matroska, but what happend if you used a fixed factor (like (audioframerate/videoframerate)) in the dsfilter to recalculate the timestamps on the fly. This factor would have to be set for every audio track (the default being 1), and it would have to be taken into account reversely for the audio during muxing. But then you could have a situation where the video changes framerate (and playback speed) from 23,97 to 25 and vice versa when switching between the audio tracks.

Because we want to save the planet ! It's better to do the big processing once on the encoder side that 10000x on the decoder side... That's just adding a dirty trick where it should not be needed.

In matroska each stream is independent and timecode based. That's one basic principle that I don't want to be changed.

[ChristianHJW]

Originally posted by pirata
is it so difficult to recreate the time stamps of the video stream blocks in real time for the new fps? How difficult? Could it destroy fluid real time playback? It seems a matter of computing the timestamp of the frames played at X fps, letting the time stamps of each audio stream as they are... I know I am an ignorant user, but it seems easy to do... please, enlightt me, Christian!

@captain carrot :

Sorry, our cheif developer thinks you wnat to change the matroska specs, he doesnt get what you wnat to do. Its feasible, but hard to do.

@pirata

the problem is certainly not the computation, but the fact that during playback you are demanding the matroska library to search for audio and video blocks with different time stamps. This is problematic as in every matroska file all blocks with same time/similar timestamps are aligned, to make reading the file easier, just think of CD media.

What you wnat to do is to have a setting in the DShow parser to read the audio blocks with correct timestamps, and search for the video blocks with a different timestamp, being either more in the future of in the past. This will put heavy stress on your HDD and CPU, and require heavy buffering it its feasible at all. But i dont say it cant be done ...

[duartix]

@ChristianHJW:
OT, Christian you are getting dislexic 3 times you misspelled want (wnat). Don't worry :) happens to me quite a lot on a few words ...

[CaptainCarrot]

It's better to do the big processing once on the encoder side that 10000x on the decoder side
Well, that's the point, if you have a audio-track for 23,97fps and want to fit it to 25fps that's qite a task that i've not yet accomplished without wrecking the whole quality. On the other hand it's really simple to change the video framerate from 23,97 to 25 by playing it a little faster. Now you say that each matroska stream is independent and timecode based. That wouldn't be changed, but the timebase would be altered for ALL streams currently playing. But I agree, it really sounds like a nasty hack to accomplish something that usually can't be done with matroska.
Just to get this point clear: Do the specs of matroska allow a stream that has been put in the container as 23,97 fps to be played back at 25 fps or not?

[pirata]

@CaptainCarrot


A thought about this:
let's say you have a movie at 23,97fps, and 2 audio-tracks, one created for 23,97 that has the correct lenght and a shorter one for 25 fps. I understand that you have fixed timestamps for every videoframe in matroska, but what happend if you used a fixed factor (like (audioframerate/videoframerate)) in the dsfilter to recalculate the timestamps on the fly. This factor would have to be set for every audio track (the default being 1), and it would have to be taken into account reversely for the audio during muxing. But then you could have a situation where the video changes framerate (and playback speed) from 23,97 to 25 and vice versa when switching between the audio tracks.


Holy words. That's exactly what I meant.


@ChristianHJW:

I guess the problem is that the DS filter has to prebuffer a bigger amount of data, but prebuffering more doesn't really mean killing the CD reader. You could address it by reading more in the beginning of the playback (yeah, it would make start up slow...), or by distributing the extra readings smoothly (as a full buffer is not needed in the beginning), and reducing them when the buffer is filled. The problem is the amount of RAM needed for the buffer... the longer the video, the bigger the time gap will be, thus the bigger the buffer has to be. That could mean, as Pamel computed before, 35MB, maybe more. That's quite, but nowaday's systems count on hundreds of MB of RAM and I think they could manage this.

The problem is whether it could harm playback speed (maybe managing such big memory chunks is not that easy for all CPUs). Also, you cannot rely on such buffer estimations. Since the bitrate varies on both audio and video tracks, how can you be sure that percentage of 700MB will be enough? By high bitrates (action scenes), you could need a certain video frame you could not reach because the buffer got already full. An there is also the problem when you have a 1400 rip stored on a DVD (for those lucky ones owning that hardware). The buffer size doubles.

So: I guess it should be an option in the decoder. You could tell the decoder to respect the time factor adaptations (or whatever tag informing of the video frame rate associated to a given audio stream, be it MP3 AAC AC3 or whatever), and use a big buffer, or just not to pay any attention to that, and use a small buffer.

One further question: being matroska a timestamp based container, aren't the frame rate control functionalities of the ReClock filter easily implementable in the player (be it mPlayer, TCMP or ZP)?

@ChristianHJW again: I'd like to know if is there any means to mux WMV/asf and MPEG1/2 into matroska. I 've tried mkvmerger but it doesn't work. Will the unseekable WMV/ASF turn seekable with matroska?

[robUx4]

Originally posted by CaptainCarrot
Well, that's the point, if you have a audio-track for 23,97fps and want to fit it to 25fps that's qite a task that i've not yet accomplished without wrecking the whole quality. On the other hand it's really simple to change the video framerate from 23,97 to 25 by playing it a little faster. Now you say that each matroska stream is independent and timecode based. That wouldn't be changed, but the timebase would be altered for ALL streams currently playing. But I agree, it really sounds like a nasty hack to accomplish something that usually can't be done with matroska.
Just to get this point clear: Do the specs of matroska allow a stream that has been put in the container as 23,97 fps to be played back at 25 fps or not?

Nop, we don't have a frame rate in matroska, only the start time of each frame and optionally the duration of this frame. So once it's converted to a frame rate changing the start time of each frame is required.

In the case where you have the video, an audio track from a 25fps version and an audio track from a 23.96fps version, at what speed do you intend it to play ? Either depending on the audio source you play the file at different speed (not supported) or you put everything at a definite speed (hopefully the original one).

Actually I don't think any container will ever allow you to do that other than in a tricky way. In matroska it can be done with a tricky way, which we should not support/endorse... Maybe OGG can do that because each track has an independent timecode base.

[robUx4]

@pirata: The way you described how the DSF should work is exactly how it works already. Regardless of the frame size, we prebuffer a certain number of frames all the time.

[ChristianHJW]

Originally posted by robUx4 In the case where you have the video, an audio track from a 25fps version and an audio track from a 23.96fps version, at what speed do you intend it to play ? Either depending on the audio source you play the file at different speed (not supported) or you put everything at a definite speed (hopefully the original one).

Sorry Steve, i fear you still missed the point. What he wnats to is to

1. mux a 25 fps video including the original sound stream ( with length for 25 fps also ) into matroska - thats very normal

2. add another sound stream to this file that was originally taken from a NTSC DVD ( e.g. downloaded from the internet ), and thus has a different length for a 23.97 fps video

3. on playback, if the normal audio stream ( 25 fps length ) is selected, everything is normal

4. if he selects the 2nd language track, which has a different length ( longer, because originally made for a lower framerate ) he wants our Dshow parser to
- play the 2nd audio with normal time stamps. Thats required, because audio cant be handled differently
- change the playback speed of the video track ( this IS possible ) by searching for blocks with a different timestamps than the ones for the audio track. Example : audio block of timestamp 45:32.16 is played, now as the video has to play slower to match the longer duration he wants the parser to search for the video block at time stamp 43:08.12 ( no precise numbers ), so the actual playback speed of the video track is reduced without touching the timestamps.


Possible solutions :

A. On muxing, if the muxer knows the 2nd audio trakc has another duration, it could mux the blocks into the file willingly such that the timestamps are NOT alligned, as in a normal matroska track. This would reduce stress on the HDD, as the blocks were still close to each other. The parser would always search for audio blocks at t, plus the corresponding video blocks at timestamp t * n ( where 0 < n < 2 , normally 0.86 or 1.13 ), but only if this audio track is selected

B. We could add 2 different timestamps to every video block, one for every single audio track. This would certainly make defining of a new EBML element necessary and increase overheadm but maybe was the best ( cleanest ) solution.

Hope i explained it well :)

[robUx4]

Originally posted by ChristianHJW
A. On muxing, if the muxer knows the 2nd audio trakc has another duration, it could mux the blocks into the file willingly such that the timestamps are NOT alligned, as in a normal matroska track. This would reduce stress on the HDD, as the blocks were still close to each other. The parser would always search for audio blocks at t, plus the corresponding video blocks at timestamp t * n ( where 0 < n < 2 , normally 0.86 or 1.13 ), but only if this audio track is selected

The problem is that matroska should not be limited to play one audio+one video+one sub at a time. It could be (for example) 10 audio tracks played simultaneously, as for a multi track recorder... If you add video to that, that means one of the design can't work with the other. And I prefer the large possibilities... Imagine you have the video @23.96fps with resolution A, the same video @25fps with resolution B, an audio track that comes from the @23.96 video and an audio track that comes from the @25. With the audio track stuck to a particular video, some combinations aren't possible. That's why keeping tracks independent is important to me.

B. We could add 2 different timestamps to every video block, one for every single audio track. This would certainly make defining of a new EBML element necessary and increase overheadm but maybe was the best ( cleanest ) solution.

Not as long as I'm alive ! ;)

[CaptainCarrot]

The problem is that matroska should not be limited to play one audio+one video+one sub at a time. It could be (for example) 10 audio tracks played simultaneously, as for a multi track recorder... If you add video to that, that means one of the design can't work with the other. And I prefer the large possibilities...
10 audio tracks playing simultaniously would only be sensible if the all have the same timebase, so that would not interfere with what we're talking about, if the audio tracks have a diffrent timebase you won't want to play them simultaniously, and if you want to play them simultaiously they will definitely all have the same timebase.

And I prefer the large possibilities... Imagine you have the video @23.96fps with resolution A, the same video @25fps with resolution B, an audio track that comes from the @23.96 video and an audio track that comes from the @25. With the audio track stuck to a particular video, some combinations aren't possible. That's why keeping tracks independent is important to me.
Ok, I think you still haven't understood us correctly. In your example only 2 combinations are possible, both video and audio at 23,97 or both at 25. Every other combination would be out of sync. If each track had a defined timebase, the other combinations would be possible, too, because for 23,97 video and 25 audio the video would be played faster (because of the higher audio timebase) whereas for 25 fps video and 23,97 audio the video would play slower to be in sync. When I think about it, one actually needed master streams (that define a timebase) and slave streams (that adapt to the master timebase). You only had to make sure that all masters playing simultaniously have the same timebase, and thus prevent impossible combinations from being played.

[robUx4]

OK, I finally have found a decent solution that should not break the matroska possibilities and allow what you're asking for.

For each track we can define a TrackTimeCodeScale. The default value would be 1.0...

What does it mean ? It's just a relation between each track (audio, video, subs) to know how timecodes should be handled.

If you have a file with video@23.96, video@25, audio@25, audio@23.96... You would have the following TrackTimeCodeScale in each of these tracks :
1.0, 0.9584, 0.9584, 1.0.

Then on playback, depending on the audio track you chose to play, you have to adjust the Timecode of the video with these number (video scale/audio scale). A limitation would be that you can't play audio streams simultaneously if they don't have the same TrackTimeCodeScale.

That's just adding one tag and not so complicated on the reader part...

Now don't expect tools using this soon ;) (especially on the reader part)

[Atamido]

Well, this does not get around the original problem of one of the directshow pins being fed to much data and locking the filter. As I said before, you have three options"

1. Stretch the audio. (this is the simplest, and will work right now.)

2. Create a good buffering system in the DS filter that can store the blocks until they are needed so that you don't overload the pins.

3. Wrtie the blocks is the order that they will be needed when writing the file.

[robUx4]

That's the 3rd option. That's the job of the muxing app to make blocks around a given timecode as close as possible in the file. It should be handled there and nowhere else... Actually that's the same app that writes the TrackTimecodeScale, so it should not be that hard :D

[pirata]

First of all, I'd like to thank you all for your help. The buys Matroska devs out there, ChristianHJW and robUx4 does what most companies do not: to pay attention to the users, those who can really take a tool to perfection.

I've thought that most of this thread (and many others) we could have spared if we, the common users, have had some insight on Matroska's file structure. I'd like to know if there is a document describing in human-readable, accessible, nice and cool english (or french!) the way Matroska files are built. If there is not such a document, maybe you should think of creating it, as a means to reduce the volume of forum threads like this one. I am thinking of a html based document which would start with a html page describing in simple terms the way Matroska files are built up. In that first explanation, html links would lead to deeper descriptions of Matroska's details as they appear. With such a tool, we could think better our feature requests. You would spare a lot of time, I believe.


Now let's go back to our little problem:

@robUx4: I think Pamel is right. The timetag thing is not important. They can be recomputed on the fly. I'd just add a tag to each audio track saying which frame rate it is synched to.

So, you just mux the video at the frame rate for which the majority of the sound tracks are synched and done. Then, on playback... well that's exactly where the problem is :-)

Yeah. The problem is the buffer. Look, I'd like to thinks this out properly. I have to sleep now. I'll post tomorrow, boyz.

[Atamido]

Originally posted by pirata
I've thought that most of this thread (and many others) we could have spared if we, the common users, have had some insight on Matroska's file structure. I'd like to know if there is a document describing in human-readable, accessible, nice and cool english (or french!) the way Matroska files are built. If there is not such a document, maybe you should think of creating it, as a means to reduce the volume of forum threads like this one. I am thinking of a html based document which would start with a html page describing in simple terms the way Matroska files are built up. In that first explanation, html links would lead to deeper descriptions of Matroska's details as they appear. With such a tool, we could think better our feature requests. You would spare a lot of time, I believe. You might take a look at the diagram. (http://cvs.corecodec.org/cgi-bin/cvsweb.cgi/~checkout~/matroska/doc/website/specs/diagram/index.html) It is much simpler than the specs, and contains links to parts of the actual specs.

There are still many aspects that it doesn't mention, but it does cover the basic structure of Matroska files. And, as a bonus, it is done entirely in HTML.

[robUx4]

Originally posted by pirata
@robUx4: I think Pamel is right. The timetag thing is not important. They can be recomputed on the fly. I'd just add a tag to each audio track saying which frame rate it is synched to.

So, you just mux the video at the frame rate for which the majority of the sound tracks are synched and done. Then, on playback... well that's exactly where the problem is :-)

The "timetag" (TrackTimecodeScale) is used at the muxing stage (to mux data in an efficient order) and at the demuxing stage to generate the right timecodes based on the audio track(s) selected. The problem you might mention is the the way some video data may be too far (in the back or forth) in the file to have an efficient playback. Well this is handled in the muxer and should be transparent to the player (which just have to use the TrackTimecodeScale to generate timecodes).

[CaptainCarrot]

Originally posted by robUx4
OK, I finally have found a decent solution that should not break the matroska possibilities and allow what you're asking for.

For each track we can define a TrackTimeCodeScale. The default value would be 1.0...

What does it mean ? It's just a relation between each track (audio, video, subs) to know how timecodes should be handled.

If you have a file with video@23.96, video@25, audio@25, audio@23.96... You would have the following TrackTimeCodeScale in each of these tracks :
1.0, 0.9584, 0.9584, 1.0.

Then on playback, depending on the audio track you chose to play, you have to adjust the Timecode of the video with these number (video scale/audio scale). A limitation would be that you can't play audio streams simultaneously if they don't have the same TrackTimeCodeScale.

That's just adding one tag and not so complicated on the reader part...

Now don't expect tools using this soon ;) (especially on the reader part)

That's EXACTLY 100% what I was trying to suggest, I guess I just didn't use the right words to explain it. :D

[robUx4]

Originally posted by CaptainCarrot
That's EXACTLY 100% what I was trying to suggest, I guess I just didn't use the right words to explain it. :D

Yes. But in the end, when things are clear it was worth the effort :)

Thanx for your contribution to make matroska even better (with this unique possibility). Now tracks are not fully independent, but that seems to be the only way to support this, which is a legitimate use (because the world is not as perfect as we'd like).

[pirata]

@Pamel:

Sh-it! Seems like the demons down there at Matroska have been reading my mind lately! It's exactly what I was asking for... If I only had seeked a little bit better...

@robUx4:

How can the muxer solve the problem of audio-video frames being too far apart of each other? Is huge buffering avoidable?

You've said:

2If you have a file with video@23.96, video@25, audio@25, audio@23.96... You would have the following TrackTimeCodeScale in each of these tracks : 1.0, 0.9584, 0.9584, 1.0."

Why do you want to change the timings of the audio@25 track? They should remain as they are. It is only the video track timings that change. Also, only the audio tracks should have such tags, shouldn't they?

After all: can we spare the time stamps (and the overhead) of the video frames, if we can recreate them on demand on playback time, depending of the audio track selected?

Now I am at lost... why aren't the tracks anymore independent?
In which sense were they independent before?

[robUx4]

Originally posted by pirata
How can the muxer solve the problem of audio-video frames being too far apart of each other? Is huge buffering avoidable?

By virtually changing the timecode of all tracks to match a "1.0 speed" when muxing the data. So all data are muxed with a correct relation/distance to the other tracks. Of course the timecode saved in the file has to be the original one, not the modified one (that's why it's only virtual).

Originally posted by pirata
2If you have a file with video@23.96, video@25, audio@25, audio@23.96... You would have the following TrackTimeCodeScale in each of these tracks : 1.0, 0.9584, 0.9584, 1.0."

Why do you want to change the timings of the audio@25 track? They should remain as they are. It is only the video track timings that change. Also, only the audio tracks should have such tags, shouldn't they?

Here we suppose the "normal" speed is 23.96fps. So every track's speed (TrackTimecodeScale) is expressed compared to this value. So if you decide to play audio1/audio2 or video1/audio1 you still know the correct time relation between these tracks.

Originally posted by pirata
After all: can we spare the time stamps (and the overhead) of the video frames, if we can recreate them on demand on playback time, depending of the audio track selected?

Nop, all tracks have to have their real timecode. So if you demux all tracks in many files, you don't have anything to modify. And we don't store any fps in matroska so the timecodes can't be recreated !!! (OK we store it, but it's just informational).

Originally posted by pirata
Now I am at lost... why aren't the tracks anymore independent?
In which sense were they independent before?

I hope now it's clearer that they are not independent : their timecode is totally dependent now.

[jcsston]

New release of the Matroska TCMP CDL, this one fixes the problem of Matroska video files not playing with the plugin loaded.
v1.2 (http://matroska.sourceforge.net/downloads/MatroskaCDL.v1.2.exe)

Also here is a new Matroska Shell Ext :D
v1.1 (http://matroska.sourceforge.net/downloads/MatroskaProp.v1.1.zip)

To install it extract it to folder and right-click the .inf file and click 'Install'. Under Win98 you may have to copy the files to C:\windows\system\shellext\ and click 'Skip File' on the dialog when Installing the .inf.

Tag support is for the moment temporarily removed from these while we work out some bugs and improve the tags.

[MarkCoolio]

hm, I now get Matroska files playing with CDL 1.2 (had the bug that you described).

BUT: when CDL is installed, I cannot play Divx5 movies with TCMP. As soon as I uninstall the CDL 1.2, I can play Divx5 again...

What could be the reason?

[pirata]

@robUx4:

hey, when will we see the new feature implemented?
By the way, there something about Matroska I never completely understand: how can we multiplex WMV/WMA and MPEG2 if there are no tools to do that, plus they are "copyrighted" file formats?

[jcsston]

Originally posted by MarkCoolio
hm, I now get Matroska files playing with CDL 1.2 (had the bug that you described).

BUT: when CDL is installed, I cannot play Divx5 movies with TCMP. As soon as I uninstall the CDL 1.2, I can play Divx5 again...

What could be the reason?
:confused: I'm sorry but I cannot reproduce this. What OS and DSF are you using?

[robUx4]

Originally posted by pirata
hey, when will we see the new feature implemented?

I don't know at all. I will add it this week in libmatroska/specs (if I didn't already do). Then it's up to the muxing tools to handle it. So you can ask Cyrius or Mosu, not me :)

Originally posted by pirata
By the way, there something about Matroska I never completely understand: how can we multiplex WMV/WMA and MPEG2 if there are no tools to do that, plus they are "copyrighted" file formats?

Well, the codec may be protected, but as long as we can handle the framing (which may not be protected), we can put it in matroska.

[pirata]

What tools are needed for muxing WMV/MPEG2? (not VDubMod, I am sure)

[robUx4]

As it doesn't exist yet, none.
If it exists it would probably be VDubMod & mkvtoolnix...

[MarkCoolio]

@jcsston:

I have WinXP (without SP) and DivX 5.05 DSF (also tried ffdshow but did not work either).

As soon as I uninstall CDL 1.2 it works, when CDL 1.2 is installed it does not start to play.

A possible hint: if I look into the properties from within TCMP of the not playing file, I can see that TCMP attempts to read matroska info although it is only a divx5 avi.

[pirata]

@robUx4: how can you mux WMV if you don't know exactly its structure (it is copyrighted)? You can maybe look at a WMV file with a HEX editor, and infere part of the standard, but it won't work always.

Anyway, when will it be possible to mux WMV/MPG2? More importantly, is there any roadmap of upcoming new features for Matroska the team is working at right now?

[robUx4]

MPEG2 video support is planned.
But we have no roadmap. We are not a company, we work we find the time to and try to roughly coordinate our efforts...

That's the price you have to pay for a free software.

[pirata]

@robUx4: it's all right babe :-)

Anyway, sure you have a list of priorities (multiaudio tracks, chapters...), haven't you? That's all I wanted to know.

So, WMV it's further down the road. Further than MPEG2, isn't it?

[robUx4]

We have a long list of features planned. We have some "short time" priorities. Then we'll see the next short time priorities...
:D

[Atamido]

Transmuxing WMV is not that big of an issue since WMV is just ASF, and there is already ASF code in VirtualDub. The only question is if WMV9 muxed directly to WMV would play if transmuxed into MKV. They could be storing the data in some strange way.

Transmuxing MPEG-2 is also not that big of a deal. The problem is that noone on the team is familiar enough with the streams to be able to figure out the framing. If someone that was good with MPEG-2 framing *cough*trbarry*cough*Nic*cough*-h*cough* wanted to, they should be able to make an MPEG-2 transmuxer pretty quick. Maybe even Gabest-style quick.

The BIG issue after that is whether any current MPEG-2 DS codec would accept MPEG-2 from an non-MPEG-2 container. Most of them seem to be pretty particular about what they will connect to.

Sorry about the coughing, I have this sore throat that won't heal.

[pirata]

@robUx4: and... what's up on that list? :D

@Pamel: you must be damn right, but... how could I (we) lead them to do such a thing? An offer they couldn't refuse or something? :D

[bond]

Originally posted by pirata
@robUx4: and... what's up on that list? :D look here (http://forum.doom9.org/showthread.php?s=&threadid=52299)!
i take this opportunity to remind the matroska team about the "Enhanced XCD support ( mode2 form2 ) with flexible ECC/EDC" :D

[Atamido]

ECC/EDC is in the same boat as MPEG-2 support. Currently noone on the Matroska team knows how to program ECC/EDC. If someone knew how, it would not be that hard to add another path to libmatroska so that once a cluster was ready to be written, you pass it through some Reed-Solomon code to produce some ECC data. Then that ECC data is added to/after the cluster, and all is good. Then at reading, you read a cluster at a time, pass the cluster through the same code, and if its corrupt, correct it using the Reed-Solomon code. And viola! You have on the fly error correction, and you could set the amount of ECC to create when writing.

Of course, this is all dependant on someone that knows ECC or EDC coding helping out. If noone helps, then they might steal some code from libogg for this. ;)

[bond]

as win98/ME is too dumb to understand unicode is there any win98/ME upgrade available from M$ which enables unicode support?

[robUx4]

Yes, we are currently discussing with Microsoft to help migrate everyone from W98/ME to W2k for free... :D

W98 can under some parts of Unicode. At least we are working on this.