mkvtoolnix 1.0 is out :)

[kurt]

Shinobu, it works with the version you posted (01/01/05)! playback is fine now with ffdshow ...

[Mosu]

Which ffdshow version are you guys using? (the exact version/date, please, not just "the latest one")

[JasonFly]

Tested with the 17/01/2005 from celtic druid

I am going to try with a more recent build. I thougth I had installed one but I didn't... More info in a few minutes

EDIT: With the 22/01/2005 build, file is choppy too.

[kurt]

Originally posted by JasonFly
EDIT: With the 22/01/2005 build, file is choppy too.
jep, i'm using this version too ...

[Shinobu]

tried different ffdshow, its all the same bug.
but one thing is sure, with the mmg 01/01/2005 it's not choppy, with newer it's choppy, seems that for kurt it's the same...

++

[JasonFly]

The effect is also present in small clip of 5 Mb.

I must also add that subs are flickering/blinking, i don't know what word best describe the phenomenon.

I must admit that one some scenes, this "choppiness" is very subtle but when you watch the original and the choppy ckip, the difference is clear.

[Mosu]

Originally posted by thana
i have found one more bug in the mmg chapter editor (version mkvtoolnix-head-20050125-1):
when you save a chapter-file over an already existing file, the existing file doesn't get cleared but only overwritten,

I've fixed this...

- it is possible to save chapter files that can't be loaded afterwards anymore in both the latest official and latest beta version of mmg, by setting an empty (first entry in the dropdown) language and/or country value for a chapter entry.

...and hopefully this as well. I've tested it, and it works fine here on both Windows & Linux (meaning I haven't been able to create chapter entries with an empty language). Before you could also select one of the "separator" entries ("---common---"). This is checked in verify as well.

Could you please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD//mkvtoolnix-head-20050130-1.rar and give it a try?

Thanks.

"verify" doesn't seem to find problems before saving.

Just for your information: That verify function is called automatically before each call to "save", "save as" or "save to Matroska file". That there's an extra menu option for it is meant mainly as a tool for myself. But users might want to check the validity of their entries as well (e.g. having forgotten to enter a start time).
the resulting xml contains an empty tag, f.e. "<ChapterLanguage></ChapterLanguage>", and mmg refuses to load it again.

[Mosu]

Originally posted by Shinobu
tried different ffdshow, its all the same bug.
but one thing is sure, with the mmg 01/01/2005 it's not choppy, with newer it's choppy, seems that for kurt it's the same...

++

Thanks for the uploads, but I'm really confused at the moment. You've uploaded two files, "ok.mkv" and "chopy.mkv". Looking at the file headers tells me that "ok.mkv" was muxed with a build from "Jan 1 2005 20:52:36" while "chopy.mkv" was muxed with a build from "Dec 21 2004 19:30:47". Perhaps you mixed something up here? Because apart from these headers the two files are actually byte-identical.

Please retry at least with http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/mkvtoolnix-head-20050125-1.rar (this version writes "Jan 22 2005 17:00:16" as the build date) or, even better, with today's build http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/mkvtoolnix-head-20050130-1.rar (this version writes "Jan 30 2005 20:21:51" as the build date).

Thanks.

[JasonFly]

I 've upload asample.

Some more info:
While playing the choppy clip with ffdshow OSD on, fps is fluctuating:
62.50
0.00
12.50
12.82
66.67
15.87

I hope that'll help

EDIT:
Seems that I misundertood the concept behind "decoding FPS" in ffdshow. I didn't notice that it wasn't related to FPS(24,25,23.996...usually) but to the decoding speed. Sorry for this.

[Koti]

originaly posted by Shinobu
could you try the build i post (01/01/2005) and tell me if it's produice no-choppy mkv for you too.

It worked for me as well - perfect playback with ffdshow

Every other nero avc I ever muxed to mkv (various versions of ffdshow , halli's mkv splitter , mmg ) has been choppy with flashing subs and 0-62 fps decoding.

edit - also tried todays build of mmg (20050130-1.rar). choppy file :(

[Mosu]

If you all want a technical explanation of what's going on:

MP4 files can contain an atom named CTTS. Especially for AVC/h.264 video tracks. This atom maps the timecodes usually found in a MP4 file to display timecodes. Normally, the timecodes are 0ms, 40ms, 80ms, 120ms... etc. for a 25 FPS file. With a CTTS atom these can become e.g. 0ms, 120ms, 40ms, 80ms... This is also the case for B frames in "normal" MPEG-4.

Up until early this year (I don't know the exact date, but let's say January 10th or so) mkvmerge did not evaluate the CTTS atom at all. So the build from 20050101 simply uses the ordered timecodes. ffdshow seems to be happy with those.

Unfortunately, Nero's decoder is NOT happy with those timestamps. It sees ordered timecodes, but it derives from the frame data itself that those are wrong and falls back to a fixed FPS mode. This is not what we want.

Therefore the Matroska team (more like Haali and me) decided to do it the "right" way and to store display timecodes. This is "right" because Matroska does indeed store display timecodes. This is also true for what I call "native MPEG-4 storage" or "native B frames".

Unfortunately ffdshow does not seem to be happy with those timecodes. We're not sure what we will do about that, but it seems that it is an issue on the decoder side and not one on mkvmerge's side. I guess Haali will try to contact Milan (the ffdshow developper). But judging from the past he may not be the quickest to respond.

[Koti]

Thanks for the explanation and for looking into this. :)

[kurt]

so in the meantime we shouldn't use mkvtoolnix from 01/01/05 (cause of unstable playback with nerodecoder) and wait for newer ffdshow-versions?

[Mosu]

Originally posted by kurt
so in the meantime we shouldn't use mkvtoolnix from 01/01/05 (cause of unstable playback with nerodecoder) and wait for newer ffdshow-versions?

Pretty much, yes. You can safely assume that the 20050101 way of storing AVC in Matroska will not be the final way, and that it won't be playable in the mid to far future.

[kurt]

with todays ffdshow build playback of avc in mkv (and haali-splitter) is fine now :)

http://www.aziendeassociate.it/cd.asp?dir=/ffdshow

[Mosu]

Originally posted by kurt
with todays ffdshow build playback of avc in mkv (and haali-splitter) is fine now :)

Really!? That's great! Just to make sure: playback of AVC in Matroska created with mkvtoolnix >= 20050125 works with that version?

Mosu

[kurt]

jep, but i used mkvtoolnix from 30.1.05 and it plays well with AVC in it!!

[Shinobu]

the mkv i muxer with 01/01/2005 version of mmg are ok too ^^
cooooool ! thanks for your works

++

[Mosu]

Originally posted by Shinobu
the mkv i muxer with 01/01/2005 version of mmg are ok too ^^

Don't keep those around, though. Like I said, that's not the official way to store AVC.

[JasonFly]

Yes, the 01/02/2005 ffdshow solve this choppy playback problem for me.
Mosu, thank you for this beautiful "Cornflake girl" build of mkvtoolnix.

[Mosu]

Hey,

I have a new release of mkvtoolnix -- 1.0.2. This is not the long-awaited release with the tons of new features like support for AVC, MPEG-1/-2 etc. Neither does it contain all the bug fixes that the current development version contains. It is merely a release that works with today's releases of libebml and libmatroska. Nevertheless a few bug fixes are present as well.

For those who want to build it (like the packages): please be aware that you need libebml 0.7.3 and libmatroska 0.7.5 which were released not an hour ago. You can grab their sources at http://dl.matroska.org/downloads/

The usual links to...
...the homepage:
http://www.bunkus.org/videotools/mkvtoolnix/
...the sources:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-1.0.2.tar.bz2
...the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-1.0.2-setup.exe

Binary packages for other systems/distributions are available from the home page.

Here's the ChangeLog since 1.0.1:
----------------------------------------------------------
2005-02-06 Moritz Bunkus <moritz@bunkus.org>
* Released v1.0.2.
* all: bug fix: Fixed compilation with the upcoming new versions of libebml and libmatroska.

2005-01-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge did not accept XML chapter files created with older mkvtoolnix versions due to deprecated chapter elements. Such elements are now skipped.

2004-12-18 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Again the window handling. Hopefully this is better than the other attempts.

2004-12-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: One was able to crash mmg by pressing 'ok' in the muxing dialog right after muxing finished, especially if the 'abort' button was hit before. This mostly happened on Linux.
* mkvmerge: bug fix: Fixed negative audio displacement for a couple of formats.
----------------------------------------------------------

Have fun :)

[Yong]

Many thanks, Mosu:)

[ermannob]

:thanks:

[bond]

Originally posted by Mosu
If you all want a technical explanation of what's going on:

MP4 files can contain an atom named CTTS. Especially for AVC/h.264 video tracks. This atom maps the timecodes usually found in a MP4 file to display timecodes. Normally, the timecodes are 0ms, 40ms, 80ms, 120ms... etc. for a 25 FPS file. With a CTTS atom these can become e.g. 0ms, 120ms, 40ms, 80ms... This is also the case for B frames in "normal" MPEG-4.
...
Therefore the Matroska team (more like Haali and me) decided to do it the "right" way and to store display timecodes. This is "right" because Matroska does indeed store display timecodes. This is also true for what I call "native MPEG-4 storage" or "native B frames"beaware that ctts is also needed without b-frames, when the encoder does some frame reordering (eg p-frames), which is possible in avc and already done in mainconcept (have a look here (http://forum.doom9.org/showthread.php?s=&threadid=80952&perpage=20&pagenumber=2)) via the "reordering delay" option (isnt enabled if b-vops are enabled no matter what is set in the gui)

[Mosu]

Originally posted by bond
beaware that ctts is also needed without b-frames, when the encoder does some frame reordering (eg p-frames), which is possible in avc and already done in mainconcept

I know, and mkvmerge will always print the following warning if no CTTS atom is found:

The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

Unfortunately I have two MP4 files without CTTS atoms that are perfectly fine. In such cases this warning will be a "false positive".

[bond]

Originally posted by Mosu
Unfortunately I have two MP4 files without CTTS atoms that are perfectly fine. In such cases this warning will be a "false positive"with avc? propably muxed with an old version of mp4creator (it should set the ctts right now for avc with b-frames)

note that mp4creator (and therefore mp4ui too) with asp will not set a ctts when you mux from .avi to .mp4 (what most people will do), if you mux from raw to .mp4 they do it

yeah, thats mpeg4ip... :rolleyes:

[Mosu]

Originally posted by bond
with avc? propably muxed with an old version of mp4creator

Dunno. Someone provided those samples, I just downloaded them ;) But playback is fine for those. At least on Linux with mplayer and ffmpeg. But I guess that ffmpeg is not as bitchy about the timecodes on Linux as Nero's decoder is, so those files might not play on Windows. Anyway, having the warning is a good thing, especially in light of...

note that mp4creator (and therefore mp4ui too) with asp will not set a ctts when you mux from .avi to .mp4 (what most people will do), if you mux from raw to .mp4 they do it

:( mkvmerge will have the same problem. Muxing from AVI will be a bitch. I'll have to parse the bitstream in order to find out frame types/references. That's so much work...

[bond]

Originally posted by Mosu
Dunno. Someone provided those samples, I just downloaded them ;)lol, well if you run mp4info from mpeg4ip you will see the used streams (or open it in mp4ui, if they say "invalid" as description, its avc :D )
but beaware to only open a copy of your files in mp4ui, as mp4ui has the "nice" feature to optimize (aka rewrite) the files whenever you open them automatically, i dont trust it

But playback is fine for those. At least on Linux with mplayer and ffmpeg. But I guess that ffmpeg is not as bitchy about the timecodes on Linux as Nero's decoder is, so those files might not play on Windows.yep might be, still what counts are the avc specs, not what players do, cause i think that the players surely do some assumptions about what the ctts says and so ignore it, a method that might not work on all streams :(

mkvmerge will have the same problem. Muxing from AVI will be a bitch. I'll have to parse the bitstream in order to find out frame types/references. That's so much work...:(

[filewalker]

A little cosmetic bug...

During muxing the progress bar doesn't show the "green bar" anymore(mkvmerge GUI v.1.0.2).

Cu filewalker

[Dick Buttkiss]

I'm using mkvtoolnix 1.0.2 and I'm having a problem with chapters not showing up at all.


I load a chapter file in a *.txt format. mkvtoolnix opens and parses the chapters correctly, but when I mux everything together mediaplayer classic 6.4.8.2 (latest ver) doesn't see any chapters in my *.mkv file.

When I mux chapters in VDub-mod everything works fine. However, I like your chapter editor more. I didn't seem to see anything in the last few pages that helped me.

[thana]

the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally. or you can first mux your file without chapters, and then add the chapters in the chaptereditor with "save to matroska file".

[Dick Buttkiss]

Originally posted by thana
the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally. or you can first mux your file without chapters, and then add the chapters in the chaptereditor with "save to matroska file".

That was it, thanks man.

[Dreassica]

Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

[rawr]

Bump for the speex support request a while back. Though you're obviously busy with other bits at the moment, I have a definate usage for this atm (director's comments track... not worth bloating a file over, but reasonable quality very low bitrate would make it worth backing up), and can see other usage (audio books -> mka etc).

rawr.

[Mosu]

Originally posted by Dreassica
Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

Probably. I haven't forgotten about this, but I haven't looked at it yet either. It should be easy enough to fix. I'll get to it this weekend.

[Mosu]

Originally posted by rawr
Bump for the speex support request a while back.

Ok, I've talked a bit to a guy on IRC (illi) about Speex. I think I can get it working although there are no specs for Speex :( (at least not about what I need to know -- the bitstream format. There are specs about the algorithms/methods used, but those don't help me ;)) But I won't work on it before the next release (due hopefully end of next week).

[Mosu]

Originally posted by thana
the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally.

Very true, and often a source for confusion. I think I'll have to add a warning if there are chapters loaded when muxing is about to start although no chapter file has been selected on the "global" tab (and only then. No need for too many warnings). The chapter editor should have been in its own dialog and not yet another tab, but it's always easy to say that with hindsight.

[Mosu]

Originally posted by Dreassica
Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

I've tested mkvtoolnix 1.0.2 and current SVN, and neither one drops such a comma. Please have a look at your file in a hex editor (or use mkvextract to extract that SSA track again and look at the resulting file) and make sure that the comma is really not present in the file. If it is then it's a problem with some part of the playback software (VSfilter?).

[karl_lillevold]

I just tried the latest Guliverkli Matroska Splitter and discovered a little problem playing back my trans-muxed RealVideo files. They all have the framerate set to 30.00 fps (RM is inherently VFR, and this might be the max FPS as read by mkvmerge in the RM header I presume).

However, the actual framerate is 23.976. With the previous version of Matroska Splitter, reclock does not detect the framerate and I can manually set it to 23.976. The "problem" with the newer splitter is that now Reclock gets 30.00 as the framerate, and it is not possible to change it back to 23.976 fps. The only solution I have found is to go back to the older splitter version.

Could it perhaps be possible to allow changing the framerate in the MKV file with something like Matroska Properties, in the same way it can now change the display size...? Is it possible to "brute force" hex edit the MKV files?

Alternatively, there does not seem to be an option in mkvmerge to set the framerate, if I were to re-mux all the files and set the framerate correctly..

[b166er]

MKV being VFR I doubt it would work. Maybe the pb is in MatroskaSplitter ? Have you tried Haali's splitter ?

[karl_lillevold]

I know Matroska is VFR, just like RM, but there seems to be a default time for each frame. From mkvinfo:
+ Writing application: mkvmerge v0.8.8
+ Default duration: 33.333ms (30.000 fps for a video track)
Even though this is a 23.976 fps clip.

On another video it's OK though:
+ Writing application: mkvmerge v1.0.1 ('October Road')
+ Default duration: 41.708ms (23.976 fps for a video track)
where I seem to have used a newer mkvmerge. So I tried to re-mkvmerge one of the problem files, with the very latest mkvmerge, but this did not make any difference. I am not sure if mkvmerge version makes a difference though. Whether files end up as 23.976 or 30.000 seem relatively random, even with the same mkvmerge version (0.9.6).

I wish there was a way to correct the files with problems.

Haali's Matroska Splitter does not work well for me at all, and crashes both MPC and Zoomplayer with many of my Matroska files. However, it does play one of the problem files, and it results in the same reclock problem.

[Prettz]

Originally posted by karl_lillevold

Alternatively, there does not seem to be an option in mkvmerge to set the framerate, if I were to re-mux all the files and set the framerate correctly..
Actually, I could probably make use of a feature like that too, especially if I'm eventually forced to stop using VDM. An option like VD and VDM have, where you can either manually enter the video framerate or set framerate to match the audio duration, would be nice.

[b166er]

Originally posted by karl_lillevold
I know Matroska is VFR, just like RM, but there seems to be a default time for each frame. From mkvinfo:
+ Writing application: mkvmerge v0.8.8
+ Default duration: 33.333ms (30.000 fps for a video track)
Even though this is a 23.976 fps clip.

On another video it's OK though:
+ Writing application: mkvmerge v1.0.1 ('October Road')
+ Default duration: 41.708ms (23.976 fps for a video track)
where I seem to have used a newer mkvmerge. So I tried to re-mkvmerge one of the problem files, with the very latest mkvmerge, but this did not make any difference. I am not sure if mkvmerge version makes a difference though. Whether files end up as 23.976 or 30.000 seem relatively random, even with the same mkvmerge version (0.9.6).

I wish there was a way to correct the files with problems.

I assume when remuxing mkvmerge is using the default duration from the mkv file... So remuxing shouldn't fix that. Maybe you could try to save it to AVI or rm and then back to matroska ? Of course there is still the hex editor hack...

[Mosu]

(RM is inherently VFR, and this might be the max FPS as read by mkvmerge in the RM header I presume).

.rm --> .mkv: The Real Media File Format contains a header field called 'fps'. mkvmerge uses its contents for the 'default duration' element and as the duration for each video frame. Are you saying that this header field contains the maximum FPS encountered in the whole file? That would practically make it worthless IMHO.

.mkv --> .mkv: mkvmerge uses the 'default duration' element if one was present. If not, the output file will not have a 'default duration' for that track. The duration of each frame is copied 1:1 into the output file.

So. If a MKV says that it's 30fps then that's because the original .rm said it's 30fps as well. Adding a parameter for setting the default duration ( = 1/fps) could solve your problem partially, but how should it set the duration of each frame? In the .rm --> .mkv case this is easy -- the duration of each frame is 1/(forced new FPS). But for .mkv --> .mkv I can't simply do that (well I can, but the user can easily shoot himself in the foot with that).

[karl_lillevold]

Mosu: thanks for clarifying.

Originally posted by Mosu
.rm --> .mkv: The Real Media File Format contains a header field called 'fps'. mkvmerge uses its contents for the 'default duration' element and as the duration for each video frame. Are you saying that this header field contains the maximum FPS encountered in the whole file? That would practically make it worthless IMHO.
It's even worse :( It contains the MaxFrameRate parameter used for Producer, which has no relation to the actual framerate in the RM file, except if producer encounters a /higher/ framerate, it will skip frames. Tools like AutoRV10 just sets MaxFrameRate to 30, even though the actual /fixed/ framerate of the video is 23.976, 25.00 fps, or 29.97 fps. All my audience templates likewise, since (until now) there really was no reason to modify this. In fact, to avoid users shooting themselves in the foot, by setting MaxFrameRate to a lower number than the actual framerate, thus causing Producer to skip frames, I have suggested always using 30 fps. One common mistake seen was settting MaxFrameRate to 24, input sequence is 29.97, frames are skipped and Producer's inverse telecine would fail.

What I have not yet figured out is how some of the MKV files came out correctly... :confused: I would have thought every sample I have has MaxFrameRate set to 30. Unfortunately I no longer have the RMVB original for those MKVs that are correct, but I will keep it in mind and check when I happen to transmux next time..

I am sure if they had re-designed RMFF today, it would have been different.. Right now it is quite useless, as you say, and a 'default duration' like Matroska has, would have been better.

.mkv --> .mkv: mkvmerge uses the 'default duration' element if one was present. If not, the output file will not have a 'default duration' for that track. The duration of each frame is copied 1:1 into the output file.
This sounds like the only possible solution.

So. If a MKV says that it's 30fps then that's because the original .rm said it's 30fps as well. Adding a parameter for setting the default duration ( = 1/fps) could solve your problem partially, but how should it set the duration of each frame? In the .rm --> .mkv case this is easy -- the duration of each frame is 1/(forced new FPS). But for .mkv --> .mkv I can't simply do that (well I can, but the user can easily shoot himself in the foot with that).
I am not sure what would work best, but right now there is a slight mismatch in the RMFF -> MKV process in that one parameter is translated into a different one. In most cases it does not matter. Only when a filter (like Reclock) tries to find the framerate, and Matroska Splitter provides this wrong number, there is a problem.

I will suggest to D-C that AutoRV10 uses the actual source fixed framerate as the MaxFrameRate. This could solve the problem for one specific usage scenario, but is not very general.

[Mosu]

Thanks for the explanation, Karl. Looks like I'll have to change mkvmerge to ignore the FPS header field completely. I'll also add a --default-duration parameter (or sth similar) that will override whatever mkvmerge usually thinks is the default duration. I don't think I'll add that to the GUI, though. It contains too many options already :/ Maybe it's time to introduce a separate dialog for seldom-used track specific options (e.g. the "fourcc" field could safely be moved there as some others. This might even free up some space that I could give to the two list boxes -- they're pretty small at the moment).

[Mosu]

Haali just reminded me that I've already added such an option in the development version available at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/ :

--default-duration <TID:Xms|us|ns> Force the default duration of a track to X.

Maybe you could give it a try.

[Bluedan]

Mosu, what's the current state of the head section aka pre1.2.0?

Once in the past I knew where to look for a change log. :rolleyes:
How far are you away from <higher aims> (i.e.DVD menue transitions??).
Is AVC implementation considered as _quite_ ready?

The last news (http://www.bunkus.org/videotools/mkvtoolnix/avc-status.html) written here are nearly 2 weeks old and there has been a new build nearly every day....

[karl_lillevold]

Originally posted by Mosu
Maybe you could give it a try.
I did and it works -- Thanks! After using mmg to construct command line and then adding --default-duration 0:41708us in front of the RMVB filename argument, I ended up with (almost) 23.976 fps as default framerate. I remuxed with 41708375ns and got exactly 23.976 ;) Hope you can find a way to add it to the GUI.

[pest]

Hi Mosu,
first let me thank you for mkvtoolnix...it's quite stable
since the first days of my use

but i wonder if it's possible to mux rared idx/subs?
mmg is crashing if i try 1.0.1 or mkvhead-05.02.20

would be nice, because the subs compress about 1:7