MKVToolNix v24.0.0 released

[Mosu]

If you need a small sample of the movie with the problematic area, I'll be glad to upload it somewhere.

Please file a file a bug report (https://trac.bunkus.org/) and upload two sample files to my FTP server: one in which the problem is apparent and one which plays fine (e.g. created with MakeMKV but not yet remuxed with mkvmerge). Both must show the same scene(s) if they should be of any use to me.

Let me know what you think the problem could be.

No idea whatsoever so far.

[Carpo]

Don't know about the others, but the latest version v5.6.0 became very slow. With v5.5.0 it took one minute to mux .mkv with .mp4 audio into 1GB total size file, now it takes up to 10 minutes on my 7 year old AMD. I reinstalled back to v5.5.0 and it works fast as always, about 1 minute for 1GB size and couple of minutes for 3-4GB.

took me about 7 seconds to do a file roughly that size here

[Mosu]

took me about 7 seconds to do a file roughly that size here

That's what I meant with "I cannot reproduce it here" as well. For me muxing is as fast as always. That's why I'm asking for real-life samples -- meaning that someone for whom the problem manifests should upload such a file somewhere.

[djesteban]

Please file a file a bug report (https://trac.bunkus.org/) and upload two sample files to my FTP server: one in which the problem is apparent and one which plays fine (e.g. created with MakeMKV but not yet remuxed with mkvmerge). Both must show the same scene(s) if they should be of any use to me.

I can create a sample with mmg.exe no prob, but I have no idea how to upload a sample for the MakeMKV file, since it seems that there is NO WAY I can create a mkv using a 264 file with this damn tool. I even create a "fake BD" with my sample file and tried to rip it using MakeMKV and it refuses to create a mkv file for some reason... Now the original file is 22Gig so way too big to send.

Any idea how I could split a sample from the MakeMKV file without changing it's properties?

[vmb]

5.6.0 seems to be very slow for me. I try to remux a DVD to mkv or rearrange an mkv and it takes drastically more time and CPU.

Here it is a mediainfo and log on 1.4 Gb mkv — I've only tried to rearrange the order of audio tracks and subs (takes 25 min on 1.8 Gz AMD CPU with 100% load).

There were no such problems with older versions for years...

[Mosu]

5.6.0 seems to be very slow for me. I try to remux a DVD to mkv or rearrange an mkv and it takes drastically more time and CPU.

Please read http://forum.doom9.org/showthread.php?p=1576224#post1576224 and http://forum.doom9.org/showthread.php?p=1576251#post1576251. If you're willing to upload the original file (not the remuxed one) then please also provide either the .mmg file you've used or the corresponding command line.

[vmb]

Mosu
I've sent you a private message with a question.

[vmb]

I've just uploaded the input file to ftp. Command line from mmg.exe:

"C:\Program Files\MKVtoolnix\mkvmerge.exe" -o "J:\\temp\\Nocturna.2007 (1).mkv" "--language" "0:spa" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1019x434" "--compression" "0:none" "--language" "1:rus" "--track-name" "1:MVO" "--default-track" "1:no" "--forced-track" "1:no" "--compression" "1:none" "--language" "2:rus" "--track-name" "2:MVO [Superbit]" "--default-track" "2:yes" "--forced-track" "2:no" "--compression" "2:none" "--language" "3:spa" "--track-name" "3:Original" "--default-track" "3:no" "--forced-track" "3:no" "--compression" "3:none" "--language" "4:rus" "--track-name" "4:[Superbit]" "--default-track" "4:no" "--forced-track" "4:no" "--language" "5:eng" "--default-track" "5:yes" "--forced-track" "5:no" "--language" "6:spa" "--default-track" "6:no" "--forced-track" "6:no" "-a" "1,2,3" "-d" "0" "-s" "4,5,6" "-T" "--no-global-tags" "--no-chapters" "(" "J:\\temp\\Nocturna.2007.mkv" ")" "--track-order" "0:0,0:2,0:1,0:3,0:5,0:4,0:6"

[Mosu]

Those with a slow muxing process should try builds 446 and later from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/.

[vmb]

Mosu
Great fix! Thank you a lot. Now it takes 50 second instead of 25 min.

[Liisachan]

Those with a slow muxing process should try builds 446 and later from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/.

I was just about to report the same problem; 446 fixed it.
Was this a problem of mmg.exe?
mkvmerge v5.6.0 seemed to be working, while I experienced something like a thread deadlock with mmg, on my old, single-core machine and Win XP. I was going to see if I could reproduce the problem on a multicore machine, as I got a vague feeling that one thread was blocking needlessly the other threads. IMHO this is a bad bug. You might want to release a hot-fix 5.6.1 (or 5.7.0) sooner.

Thank you very much again for this great application, anyway :)

[Mosu]

Well. I had re-written the whole thread management in mmg due to problems on Mac OS (really bad lockups with code that worked just fine on both Windows and Linux -- I blame wxWidgets here). Unfortunately the main thread now polls the mkvmerge process continually which results in one CPU being used at full capacity. On single core systems this means that there's not processing power left for mkvmerge, hence the huge slow down for such systems. I don't have a single single core system anymore (including my laptop), which is why I wasn't really able to reproduce the problem before. I also didn't realize people actually meant that mmg was using the CPU. They all just said "muxing is slow", and I tend to test mkvmerge only in such cases.

No, I don't want to release a new release at the moment, I don't want to spend the two hours I always have to work on this. I can point people to the interims release, and Linux users can re-compile the package themselves.

[Selur]

btw. would be nice if mkvextract like mkvmerge would support the "--split parts:" option,..

[Mosu]

btw. would be nice if mkvextract like mkvmerge would support the "--split parts:" option,..

Never say never, but this will in no way happen ;)

[Selur]

Had to ask, it would just be a nice feature to have. :)

[MrVideo]

End users having to do anything in the command line in 2012 bewilders me. Should be totally unnecessary. I know this is a "power user" program (and a great one at that) but still, GUIs are so much easier to use.

GUIs are a PITA when it comes to automating the repetitive process. When the same thing is done over and over and over, scripts are the best way to go. When on a Windoze platform, installing cygwin and writing Zshell scripts, that also have command line options, make the repetitive job a lot easier.

A GUI doesn't exist to take MPEG-2/H.264/AC3 elementary streams, create DGI output, create the necessary AVISynth script and set the x264 encoder options, and lastly run mkvmerge to merge the video and audio streams into the MKV wrapper.

GUIs have their place, but complicated job runs require power user capability.

[MrVideo]

However, this would mean that the default_duration written to the file may be different than the value the user supplied. On the other hand it would make it easier for the user: no matter whether or not the input is 25p or 25i the user only has to enter "25fps". And I could leave mmg's "FPS" field as it is, meaning it wouldn't be renamed to "default duration".

Thoughts?

I know I am little late to this discussion and have more posts in the forum to read after this one, but I have been bitten by the dual meaning of "fps" too often. FPS mean Frames Per Second. As such, the --default-duration should be fps, no matter if the h.264 video is progressive or interlaced. Therfore, when I supply 29.97fps as input, mkvmerge should know to internally change it to 59.95 fields per second when creating the output, when dealing with interlaced input.

My thought.

But, it is basically moot for the latest versions. :D

[LeMoi]

I'm a litle disappointed with the latest split by parts feature. If i want to split a 10s part of a 1 hour movie, it doesn't only mux the 10s part, it muxes the whole file and create the 10s part file only. I mean that instead of taking few seconds to extract that little part, it takes few minutes... It's not really like a splitting feature that may offer other programs for AVI/MP4/etc. files...
Ultimately, it's as long as it was before but it doesn't take the same disk space.

[Mosu]

I'm a litle disappointed with the latest split by parts feature. If i want to split a 10s part of a 1 hour movie, it doesn't only mux the 10s part, it muxes the whole file and create the 10s part file only. I mean that instead of taking few seconds to extract that little part, it takes few minutes... It's not really like a splitting feature that may offer other programs for AVI/MP4/etc. files...
Ultimately, it's as long as it was before but it doesn't take the same disk space.

Yes, and you'll have to live with at least some of that. mkvmerge makes the decision whether or not to split before the current packet after the packet has been processed fully, especially after all the different possible methods of timecode manipulation have been applied (source container timecode calculation, appending from other files, command line options like --sync and timecode files). Therefore all source files have to be processed at least until the last part of the "--split parts:..." option has been fully written. I can make mkvmerge stop after that, though I'll have to test that somehow. That would at least cut the process down somewhat.

mkvmerge works rather differently than a video player. Therefore you cannot expect mkvmerge to simply seek in the input files to where it needs to process the data.

[LeMoi]

Therefore you cannot expect mkvmerge to simply seek in the input files to where it needs to process the data.

That's what i thought it would do, that's why i said i was disappointed :p

I can make mkvmerge stop after that, though I'll have to test that somehow. That would at least cut the process down somewhatGood idea :)

[MWD1001]

For the life of me I can't get any mkv file made with MKVMerge to play on my bluray player. It's a brand new 2012 model Sony BDP-S390 and this player has played every MKV I've thrown at it made from programs like MakeMKV, RipBot264 and TSMuxer. So I know it supports the file format. In fact, the same source content (AVC, not VC-1 which are known to be finicky with Sony players) plays just fine when I mux the file with MakeMKV, but when I mux with MKVMerge I get the infamous "File Not Supported" error message from Sony. I've tried every combination of possible settings in MKVMerge to try to get it to work (compression/no compression, flags on/off, etc.) but my player chokes on every single file and says it's not supported. What's strange is RipBot uses MKVmerge to remux re-encoded files upon completion and those files work just fine. So I know my player will play files muxed with MKVMerge. However, I can't seem to find the right combination of settings when using the GUI. What the hell?

[sneaker_ger]

Are you absolutely sure about the compression/no compression thing? Compared your command line to that of RipBot?

[MWD1001]

Are you absolutely sure about the compression/no compression thing? Compared your command line to that of RipBot?

Yes. I've gone through at least two dozen tests with compression on and off in every possible combination for video, audio, and srt subtitles but nothing is working. However, test mkv files I downloaded that were made with mkvmerge are playing just fine, including the support and playback of UTF-8 based subtitles. I can't seem to make my own mkv file with my own source material using MKVmerge that my player will play. I even remuxed the test file I downloaded and it played. Why can't I get my own backups to work? I'm ready to kill myself!

[sneaker_ger]

Correct compression setting is off for video and audio and on for subtitles. (Can be set globally in the options, "Disable header removal ....")
Also see:
https://www.bunkus.org/answers/?qa=11/improving-playback-players-implement-matroska-specification

[MWD1001]

Correct compression setting is off for video and audio and on for subtitles. (Can be set globally in the options, "Disable header removal ....")
Also see:
https://www.bunkus.org/answers/?qa=11/improving-playback-players-implement-matroska-specification

OK, since you are gracious enough to help me let me try another test, including the settings in the link above and I'll report back to you shortly. Thanks.

Update: Sweet mother of God. I finally found a sequence that worked. Here's what I did:


First made a MKV file with just the source audio and video using MakeMKV. Tested this file and it played flawlessly.
Added that MKV file to MKVMerge along with the srt forced subtitles I needed. Changed subtitle format to UTF-8 for compatibility with my player (Sony BDP-S390).
Made sure compression was off for both audio and video, but on for subtitles.
Added the three global command line settings from the suggestion link provided by sneaker_ger.
Remuxed the file in MKVMerge and prayed.


Somehow that worked. After 48 hours of testing I'm ready to watch this fricking movie with my forced subtitles in all its lossless glory. I have no idea what settings or combination I changed in MKVmerge (I think it might have been compression on the subtitles), but I wrote them down and I'll test another film later tonight/tomorrow to make sure this wasn't just a fluke.

Thanks sneaker_ger for your suggestions and for providing that link to the faq/suggestions written by mosu.

[LeMoi]

Maybe the included decoder is a little old, try to mux with a previous build of mkvtoolnix (v4.x for example ?)

[Chetwood]

Correct compression setting is off for video and audio and on for subtitles. (Can be set globally in the options, "Disable header removal ....")
Header compression is not the same as subtitle compression.

[sneaker_ger]

Header compression is not the same as subtitle compression.

True, but no one said otherwise. :confused:

[sneaker_ger]

Somehow that worked. After 48 hours of testing I'm ready to watch this fricking movie with my forced subtitles in all its lossless glory. I have no idea what settings or combination I changed in MKVmerge (I think it might have been compression on the subtitles), but I wrote them down and I'll test another film later tonight/tomorrow to make sure this wasn't just a fluke.

I'd try the global option only, without touching anything else. Even though I posted the link to the FAQ, these might be unnecessary for a 2012 player.

[MrVideo]

The options I use to package MKV files is:

mkvmerge --clusters-in-meta-seek --default-language eng -o OutputFile.mkv --compression -1:none InputFile.h264 --compression -1:none InputFile.ac3

To fix bad MKV files, it is:

mkvmerge --clusters-in-meta-seek --default-language eng -o OutputFile.mkv --compression -1:none InputFile.mkv

I've not had an issue yet.

[Mosu]

Hey,

I've released v5.7.0. It's purely a bug fix release. The most important bug fixed was the excessive CPU usage during muxing.

Unfortunately the bug fix for the CPU usage brought on a new bug. Due to timing issues between the child process (mkvmerge) ending and the GUI reading its output the very last line(s) of mkvmerge's output might not be shown by mmg. The progress bar might also not be updated to full. However, this is purely a cosmetic issue: the output file has been written completely by that point. See also issue 774 (https://trac.bunkus.org/ticket/774).

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.7.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.7.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.7.0.7z

All of the Linux binaries that I provide have already been built and
are available.

Here's the ChangeLog since v5.6.0:

2012-07-08 Moritz Bunkus <moritz@bunkus.org>
* Released v5.7.0.
* mmg: bug fix: mmg will no longer print false warnings about a chapter UID not being unique. Fixes #760 (https://www.bunkus.org/trac/ticket/760).
* mkvmerge, mkvpropedit, mmg: bug fix: All tools can now deal with 64bit UID values (chapter UIDs, edition UIDs etc).
* mkvmerge: new feature: If "splitting by parts" is active and the last split part has a finite end point then mkvmerge will finish muxing after the last part has been completed. Implements #768 (https://www.bunkus.org/trac/ticket/768).

2012-06-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The DTS and TrueHD packetizers were not flushed correctly. In some rare circumstances this could lead to mkvmerge aborting with an error message about the packet queue not being empty at the end of the muxing process. Fixes #772 (https://www.bunkus.org/trac/ticket/772).

2012-06-17 Moritz Bunkus <moritz@bunkus.org>
* mmg, mkvinfo's GUI, all .exes: enhancement: Added new icons by Ben Humpert based on the ones by Eduard Geier (see AUTHORS).

2012-06-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed handling of tracks in QuickTime/MP4 files with a constant sample size. This fixes the other reason for the "constant sample size and variable duration not supported" error. Fixes issue 764 (https://www.bunkus.org/trac/ticket/764).
* mkvmerge: bug fix: Tracks in QuickTime/MP4 files with empty chunk offset tables (STCO and CO64 atoms) are ignored. This fixes one of the reasons for the "constant sample size and variable duration not supported" error.

2012-06-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed mmg's excessive CPU usage during muxing.

2012-06-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Reading DTS from AVI files often resulted in the error message that DTS headers could not be found in the first frames. This has been fixed. Fixes issue 759 (https://www.bunkus.org/trac/ticket/759).

2012-05-31 Moritz Bunkus <moritz@bunkus.org>
* Documentation: Updated the cross-compilation guide and fixed the "setup_cross_compilation_env.sh" script.

Have fun.

[Keiyakusha]

Hi Mosu, thanks for the new build!
Regarding new "bug", maybe you can just make it draw full progress bar when everything is done? I mean it won't show any real progress since the work is finished, it will just look full. Or maybe just replace the whole thing by something like "DONE" text or whatever. Because right now it looks... well, you know (http://i.imgur.com/Enws3.png) :D

[Mosu]

I know how it looks right now, but people have also already noticed that the last line they usually see ("Writing the cues...") might be missing as well. Therefore simply filling the progress bar might confuse them even more, I'm afraid. I'm also not a big fan of masking bugs instead of fixing them. I will fix the issue, I will most likely do it in time for the next release, but I also have a two-week vacation coming up in which I won't be home. Therefore a timely fix is unlikely.

Also: mmg also says "mkvmerge exited with a return code of 0. Everything went fine." Something like "DONE" would just be... well... redundant.

[Keiyakusha]

Oh, for some reason I though that this is not fixable. No problem then.

[Mosu]

It is definitely fixable, though I have to admin that I'm not sure how exactly I'm going to. Maybe instead of reading directly from the child process I'll have mkvmerge write to a file (with "--redirect-output") that mmg reads at the same time. That way the output will never get lost. However, those are technical details that shouldn't matter to you, the user, as long as it gets fixed ;)

All of this is more or less due to the limited interface that the wxWidgets library provides, unfortunately.

[hello_hello]

Using the GUI, I open an MKV which makes no use of the "File/segment title" field. Naturally it contains no text. I remove the MKV and open a second one which does make use of the "File/segment title" field and it's title is included in the field accordingly. I remove the second MKV and add a third. Regardless of whether the third MKV makes use of the "File/segment title" field, the text in the field remains as the title of the second MKV.
So basically once an MKV which has a title is opened and removed, the "File/segment title" field is no longer updated to reflect the correct title of any subsequently opened MKVs. The only way to ensure the "File/segment title" field is updated correctly seems to be to close and re-open MKVMergeGUI each time rather than simply remove and add MKVs.

I assumed this behavior must be a version 5.7.0 bug as I'd only just upgraded MKVToolNix and this is the first time I'd noticed it, however I downgraded to version 5.6.0 and it behaves the same way, so maybe it's intended, but it seems logical to me if I open a single MKV, the "File/segment title" field should be updated or cleared accordingly.

Cheers.

[Mosu]

Use "File -> new" if you want to start over completely. This is a feature (!) that users actually expect to work: remove all files and the other inputs stay set instead of being cleared.

Adding a file will also only fill in certain input fields if there's no text in them when you add that file. Again, a feature.

[hello_hello]

I sort of figured it may be intended behavior but it seemed a little inconsistent to me, however I'm fairly sure I've never used the File/New menu. Now you've pointed it out, the behavior makes perfect sense.
I guess a dumb, dumb like me would have benefited from a "new" button above the "add" button or something similar, but at least now I know how to reset everything.

Cheers.

[Mosu]

Here's a build that should fix the problem with mmg not reading mkvmerge's output fully: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.7.0-build20120711-453-setup.exe

I'd appreciate some testing.

[hello_hello]

I'd appreciate some testing.

I was experiencing the problem with 5.7.0, but so far not with the build you posted.

[bugmen0t]

where i can find the full list of mkvmerge alias
like
"The Stars were mine"
"Healer"
"The Whirlwind" , etc?

[Mosu]

They're all listed in http://www.bunkus.org/videotools/mkvtoolnix/releases.xml.gz

[bugmen0t]

thanks so much, Mosu http://static.kaskus.co.id/images/smilies/cewek.gif

[mood]

Hi, Mosu...

Version 5.7.0 have a bug on progressbar stay in the middle when muxing is finish.

[sneaker_ger]

Test this:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.7.0-build20120711-453-setup.exe

[Mosu]

Hi, Mosu...

Version 5.7.0 have a bug on progressbar stay in the middle when muxing is finish.

See this post and the following oes as well as issue 774 (https://trac.bunkus.org/ticket/774).

[Liisachan]

Tried 5.7.0, worked fine, including the progress-bar on my Windows XP (single core).
Maybe timing issue doesn't exist on a single-core system?
I'm encoding on a multi-core system, but am still using a single-core machine when muxing for some personal reason.
That bug in the official 5.6.0 is gone anyway. Reconfirmed here :)

[sneaker_ger]

What is the reason for the last timecode of a video track being extracted as a float, while all other timecodes are being extracted as integers? I suppose it's stored differently, as it's not a start time but an end time?
(If you need a sample download this (https://rapidshare.com/files/2377518186/delay_sample.mp4) and remux with 5.7.0 + extract video timecodes)

[Mosu]

In order to be able to calculate the frame durations for N tracks a timecode v2 file has to contain N+1 timecodes as the duration is always the difference between two consecutive timecodes. Therefore mkvextract will write one more timecode during extraction than there are frames in the file. That timecode is calculated as "last frame's timecode + last frame's duration".

Now internally all timecodes are floating point numbers, not integers. They're output with as few places as possible though, hence "40" instead of "40.000000". This is due to most Matroska files using a timecode resolution of 1ms and the timecode files using the very same resolution. However, the N+1st timecode is the sum of the Nth timecode and its duration -- and the duration is taken from the "default duration" header element. And that one is often enough not a rational number (think of 1000 / 23.796).

[sneaker_ger]

Now internally all timecodes are floating point numbers, not integers. They're output with as few places as possible though, hence "40" instead of "40.000000". This is due to most Matroska files using a timecode resolution of 1ms and the timecode files using the very same resolution.

So my real should've been: why did you make mkvmerge ignore the decimals? Does this serve any practical purpose worth the increased jitter?

However, the N+1st timecode is the sum of the Nth timecode and its duration -- and the duration is taken from the "default duration" header element.

What happens if there's no DefaultDuration or BlockDuration element? Duration of N-1?

And that one is often enough not a rational number (think of 1000 / 23.796).

What do rational numbers have to do with this, if timecodes aren't stored/extracted as rationals? :confused: