Matroska public alpha release date : 1st May 2003 [Archive] - Page 5

Atamido

29th May 2003, 00:51

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

29th May 2003, 01:24

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

29th May 2003, 01:45

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]

29th May 2003, 02:19

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

29th May 2003, 10:15

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

29th May 2003, 11:16

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

29th May 2003, 11:26

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

29th May 2003, 12:19

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

29th May 2003, 12:23

@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

29th May 2003, 15:09

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

29th May 2003, 15:19

@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

29th May 2003, 16:24

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

29th May 2003, 16:26

@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

29th May 2003, 19:23

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

29th May 2003, 21:31

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

29th May 2003, 22:45

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

29th May 2003, 23:45

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

30th May 2003, 00:09

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

30th May 2003, 00:13

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

30th May 2003, 02:02

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

30th May 2003, 03:40

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

30th May 2003, 09:19

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

30th May 2003, 09:42

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

30th May 2003, 09:53

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

30th May 2003, 16:29

@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

30th May 2003, 17:31

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

2nd June 2003, 10:10

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

2nd June 2003, 11:05

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

3rd June 2003, 04:12

@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

3rd June 2003, 04:22

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

3rd June 2003, 09:28

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

3rd June 2003, 14:10

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

robUx4

3rd June 2003, 14:23

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

MarkCoolio

3rd June 2003, 14:50

@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

4th June 2003, 03:47

@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

4th June 2003, 08:49

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

4th June 2003, 14:16

@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

4th June 2003, 15:42

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

4th June 2003, 23:59

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

5th June 2003, 00:29

@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

5th June 2003, 15:08

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

5th June 2003, 23:51

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. ;)