View Full Version : MKVToolNix v24.0.0 released
Note: The latest release is v25.0.0 (http://forum.doom9.org/showthread.php?p=1846426#post1846426). Yes, that's in a new thread.
Hey,
I've released mkvtoolnix v4.0.0. This release features full support for the WebM variant of the Matroska container format, VP8 video tracks, the IVF container format. It also contains a new translation into Dutch.
There are two changes for package maintainers: 1. the new translation I've mentioned and 2. mkvtoolnix requires the new releases libebml v1.0.0 and libmatroska v1.0.0 available at http://dl.matroska.org Both libraries are not binary-compatible with earlier releases, but they're source-compatible. These libraries are only needed if you want to compile your own package. You do not need them if you're using one of the binary ones.
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-4.0.0.tar.bz2
...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.0.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.0.0.7z
All binaries that I provide myself have already been uploaded.
Here's the full ChangeLog since release 3.4.0:
------------------------------------------------------------
2010-06-05 Moritz Bunkus <moritz@bunkus.org>
* Released v4.0.0.
* build: Building mkvtoolnix now requires libebml v1.0.0 and libmatroska v1.0.0 or later.
2010-06-04 Moritz Bunkus <moritz@bunkus.org>
* all command line tools: bug fix: Fixed the output of eastern languages like Japanese or Chinese under cmd.exe on Windows.
2010-06-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added the estimated remaining time to the mux and job dialogs.
2010-05-31 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation of the programs into Dutch by Ren?? Maassen (see AUTHORS).
2010-05-28 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: feature removal: Removed support for extracting FLAC tracks into Ogg FLAC files. Instead they're always written into raw FLAC files. The option "--no-ogg" has been removed as well.
* mkvmerge: feature removal: Removed support for the FLAC library older than v1.1.1.
* mkvmerge: bug fix: Fixed support for reading FLAC tracks from Ogg files following the FLAC-in-Ogg-mapping established with FLAC v1.1.1. Fix for bug 488.
2010-05-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The "mkvmerge executable" input in the preferences dialog is not read-only anymore. Final part of a fix for bug 490.
* mmg: bug fix: mmg will output a warning if it is used with a mkvmerge executable whose version differs from mmg's version. Part of a fix for bug 490.
* mmg: bug fix: If adding a file fails mkvmerge's error message will be shown in a scrollable dialog instead of a normal message box. Part of a fix for bug 490.
* mmg: Added 'IVF' files to the list of known input file types.
* mkvmerge: Added support for reading IVF files with VP8 video tracks.
* mkvextract: Added support for extracting VP8 video tracks into IVF files.
2010-05-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvinfo, mkvextract: bug fix: Fixed handling of clusters missing a cluster timecode element.
* mkvinfo GUI: bug fix: Frames for simple blocks were shown at the wrong place in the element tree.
2010-05-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: Fixed handling of clusters with an unknown size.
2010-05-22 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Fixed handling clusters with an unknown size.
* mkvinfo: new feature: Added an option ("-z" / "--size") for displaying each element's size property. Elements with an unknown/infinite size are shown as "size is unknown".
2010-05-21 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added a checkbox for enabling "WebM" mode. This will also enable the same limitations that mkvmerge enables: Only VP8 and Vorbis tracks, no chapters, no tags. The output file name extension will be changed to ".webm" upon enabling the mode.
2010-05-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: change: mkvmerge will not write track header elements whose actual value equals their default value anymore.
2010-05-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Neither chapters nor tags will be written to WebM compliant files. Warnings are issued if chapters or tags are found and not disabled.
* mkvmerge: bug fix: Matroska files without clusters are accepted as valid input files again.
* mmg: enhancement: Added "WebM" with the extension "webm" to the list of known file types.
* mkvmerge: new feature: Added support for muxing VP8 video tracks.
* mkvmerge: enhancement: mkvmerge will no longer put all clusters into a meta seek element resulting in smaller file size. The parameter "--no-clusters-in-meta-seek" has been renamed to "--clusters-in-meta-seek" and its meaning reverted.
* mkvmerge: enhancement: WebM compatibility mode will be turned on automatically if the output file name's extension is '.webm', '.webma' or '.webmv'.
* mkvinfo GUI: enhancement: Added "webm" to the list of known file name extensions for WebM files both for the "Open file" dialog and the drag & drop support.
2010-05-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added options "--webm"/"--web-media" that enable the WebM compatibility mode. In this mode only Vorbis audio tracks and VP8 video tracks are allowed. Neither chapters nor tracks are allowed. The DocType element is set to "webm".
* mkvinfo GUI: bug fix: Opening more than one file without restarting mkvinfo GUI could result in wrong timecodes due to variables not being reinitialized.
2010-05-16 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Binary elements shorter than 10 bytes were not output correctly.
2010-05-15 Moritz Bunkus <moritz@bunkus.org>
* Build system: bug fix: The man page installation process only installed the English originals instead of the Japanese and Chinese translations.
------------------------------------------------------------
Have fun.
Keiyakusha
5th June 2010, 20:33
mkvextract: feature removal: Removed support for extracting FLAC tracks into Ogg FLAC files. Instead they're always written into raw FLAC files
Ohh finaly! I hate that oggflac so much!
Anyway, thanks for the new version. Congratulations with yet another major release!
Thanks mosu.
Does it give thd+ac3 support?
If you mean that it keeps the AC3 core then no. And don't hold your breath; I won't implement such a feature.
If you mean that it keeps the AC3 core then no. And don't hold your breath; I won't implement such a feature.
Thx for the quick response but why not?
Because in Matroska you have one codec per track, not two. If you need something like that you'll have to use MPEG TS or some other muxer that allows this. mkvmerge won't.
So this feature request must be made to Haali or whatever?
73ChargerFan
6th June 2010, 05:00
Thanks for the new version!
Because in Matroska you have one codec per track, not two. If you need something like that you'll have to use MPEG TS or some other muxer that allows this. mkvmerge won't.
A DTS-MA track ripped from a blu-ray disk works fine, and has a dts core. :confused:
DTS-HD master audio is different from TrueHD+AC3. With DTS-HD the "master audio" part is actually only the difference between the lossy core and the lossless original. Therefore a decoder needs both the core and the HD part in order to decode losslessly.
With TrueHD+AC3 this is not the case. The TrueHD is completely decodable on its own without the AC3 part.
b66pak
6th June 2010, 16:21
thanks a lot...
_
D.A.S.
7th June 2010, 14:54
Peoples, this is just I have a problem with the flags in version 4.0?
Returned 3.4.
mkvmerge 4.0.0 does NOT write default values in the headers anymore. Default values are a feature that the Matroska specifications have had since the beginning (2002). For example, the default value for the track language is "eng" (English). Therefore this value will not be written to the headers if its actual value is "eng".
Any player still having problems dealing with this should be fixed. Those are bugs in the reading application (player), not the in the writing application (mkvmerge).
D.A.S.
7th June 2010, 16:32
Hmm...
For example, have the video stream and audio stream, and 2 versions of the subtitles, "eng" and "rus", I point "rus" subtitles to be - default.
Then after muxing and adding created file to Mkvmegre GUI displays all streams in default track flag - no.
This is normal right? >_<
Abradoks
7th June 2010, 16:35
mkvmerge 4.0.0 does NOT write default values in the headers anymore. Default values are a feature that the Matroska specifications have had since the beginning (2002). For example, the default value for the track language is "eng" (English). Therefore this value will not be written to the headers if its actual value is "eng".
While you are technically right, IMO not setting "eng" code is wrong.
1) Such meta information should be set explicitly. Defaulting to "eng" in standard is very arguable.
2) It's not default value in mkvmerge. When user explicitly sets this parameter he obviously wants it to be in the file. As I understand, now there is no way to write language value as "eng".
3) You are breaking compliance without reason.
So please revert this change. When user specifies some parameter it should be written to the file. Or am I missing something?
I'm not reverting the change. The specifications state explicitely that in case of an absent element its default value must be used instead. I'm not breaking compliance, I'm forcing others to fix their bugs.
For example, have the video stream and audio stream, and 2 versions of the subtitles, "eng" and "rus", I point "rus" subtitles to be - default.
Then after muxing and adding to Mkvmegre GUI displays all streams in default track flag - no.
That's indeed a bug in mkvmerge's handling of the files. I'll fix it.
D.A.S.
7th June 2010, 16:54
Also, in a small confusion regarding the present editing the header using the header editor.
Abradoks
7th June 2010, 18:05
I'm not reverting the change. The specifications state explicitely that in case of an absent element its default value must be used instead. I'm not breaking compliance, I'm forcing others to fix their bugs.
You are not breaking spec compliance, you are breaking compliance with some players. Of course those players should be fixed. But old behavior of mkvtoolnix was spec compliant too and it wasn't causing any problems.
Also, current behavior is unexpected and limiting. Specs don't say you shouldn't write "eng" value. Those defaults are for playback applications, not for muxers. It can be changed to "und" at any time (and that would be reasonable).
If I change back then app developers will have no reason to fix their broken implementations -- again. I'm sorry, I won't change it back.
Abradoks
7th June 2010, 18:39
If I change back then app developers will have no reason to fix their broken implementations -- again.
Why do you care? There are many more important bugs and missing features in current implementations. This one doesn't make any sense. It was artificially raised by you.
Its even more logical to display "Not specified" instead of "English" when language tag isn't presented (but it's spec issue).
Nevertheless, you could just add something like "--language 0" meaning "don't write this tag". And if you want so much to break other apps you could specify it as default for "--default-language". That will be logical and won't remove functionality.
I'm not discussing this any more. Sorry.
BTW: A few years ago there has already been exactly the same situation. mkvmerge switched to not writing the default values, users complained, I switched back. Obviously nothing changed on the playback side, so I'm upping the pressure on the others a bit now. I don't believe in "compatibility above everything else". With other specs people are very quick to blame the readers if they don't comply, while with Matroska everyone expects the muxers to circumvent bugs in the players. I want that to change.
DeathWolf
7th June 2010, 20:15
It's a bit sad to see devs. going on a crusade against the world. But alas it is of course your final choice. I would rather be able to force explicitly language for all tracks even if it's the default value, should it be for the idea that everything is *marked* and there isn't random things unmarked because their value is default. I can very well go along the idea of having the default behavior not mark defaults, but if I want to mark them I should be able to...
Kurtnoise
7th June 2010, 20:25
It's a bit sad to see devs. going on a crusade against the world. But alas it is of course your final choice. I would rather be able to force explicitly language for all tracks even if it's the default value, should it be for the idea that everything is *marked* and there isn't random things unmarked because their value is default. I can very well go along the idea of having the default behavior not mark defaults, but if I want to mark them I should be able to...
if you don't like it, fork it...plain & simple.
Thanks Mosu for your unbelievable work on these tools. Keep it the great work.
DeathWolf
7th June 2010, 21:54
if you don't like it, fork it...plain & simple.
Thanks Mosu for your unbelievable work on these tools. Keep it the great work.
Interesting reaction there. I was just expressing the way I feel. And while forking is something that seems "easy" to the eye, fragmentation is never good. It seems to me you your reaction was fairly... how to say... non constructive and inflammatory.
I was just hoping a non-default option would allow to force default tags, that's all.
sneaker_ger
7th June 2010, 22:23
/edit: nevermind...
Atak_Snajpera
7th June 2010, 23:49
While you are technically right, IMO not setting "eng" code is wrong.
1) Such meta information should be set explicitly. Defaulting to "eng" in standard is very arguable.
I agree! Since when english is the most important language on Earth??? It's very useful but it does not mean that it is above the rest. I as a Pole would like to see Polish language as default. People in Southern America would like to have spanish or portuguese as default and so on. Default language should not exists because there is no default language for all people. It is funny that you mosu as a german don't understand us. Please explain me why every movie in german is dubbed !?!? Why Brad Pit does not speak in english :) What you did does not make sense at all. If language is not specified it should be automatically marked as 'und' . If language is english then it must be 'eng' and so on! No exceptions!
LeMoi
7th June 2010, 23:55
Mosu said he's not discussing any more because some years ago he had same conversation with other people and made the changes he made. That's why he just doesn't want to change this feature any more, people won't stop changing their mind :)
Atak_Snajpera
7th June 2010, 23:59
He should use common sense. If I was doing everything what users want ripbot264 will probably end up as another bloated MeGui!
sneaker_ger
8th June 2010, 01:19
If language is not specified it should be automatically marked as 'und' . If language is english then it must be 'eng' and so on! No exceptions!
If you don't specify any language mkvmerge will still use "und" as the default flag. Only if you explicitly tell it to flag as "eng" no tag will be written.
But I agree that no tag equaling "eng" may not be a wise decision, but changing it now would only increase confusion and break backward compatibility. (Although that's no reason not to write the "eng" tag as before, but it seems that we can't do aynthing about it...)
I made a short test and both Haali's and Gabest's splitters and VLC interpreted the files correctly.
I agree! Since when english is the most important language on Earth??? It's very useful but it does not mean that it is above the rest. I as a Pole would like to see Polish language as default. People in Southern America would like to have spanish or portuguese as default and so on. Default language should not exists because there is no default language for all people. It is funny that you mosu as a german don't understand us. Please explain me why every movie in german is dubbed !?!? Why Brad Pit does not speak in english :) What you did does not make sense at all. If language is not specified it should be automatically marked as 'und' . If language is english then it must be 'eng' and so on! No exceptions!
Please read sneaker_ger's answer. mmg is still defaulting to using "und" when you add a track from a container that does not contain language tags, e.g. AVI files or raw h264 files.
"eng" being the "default value" only applies to the container level. If the "language" element is not present in the file then a reading application has to use "eng" instead. This is indeed not the best value ("und" would have been better), but that's what the speficiations say since 2002. You cannot simply change that now and break every spec compliant program out there.
Like sneaker_ger said: mmg will select "und" by default. If you select "eng" on purpose only then will the "language" element not be written into the file. This is not "us" wanting to dominate the world (hey, I'm German and don't like the US's attitude of them being the center of the Universe either). It's rather a minor technicality.
Some more reasons why I'm not changing this back. Back in 2002 when Matroska was created I was there. I started the first program actually being able to create Matroska files. I wrote the very first patch for the very first player being able to play Matroska files (mplayer). I've been pushing it ever since. Now if I stopped pushing all of it and only concentrated on a common sub-set supported by every player out there then that would mean Matroska will never move forward again. Things like linked files would never happened. You'd never have totally uncommon stuff like FLAC, Kate, Dirac in Matroska. Hell, you'd never have had Matroska in the first place! Never mind the WebM project which would either not have happened at all or with something completely different -- maybe MP4, maybe not even that but Ogg.
Without pushes, without applications using more than just the most basic features no further development will be made. With unchartered territory there's always someone who's first to chart it, and that process is not always an easy one. In this case I'm not even the first. Like sneaker_ger said Haali, VLC support this properly, maybe even some or most hardware players (I only have one to test against, but it doesn't show the track's language anyway).
GodofaGap
8th June 2010, 07:52
I don't quite understand the consternation yet. I just muxed a file and set the language of both audio and video to eng, and both Haali, MPC-HC and VLC reported the track languages as English.
Which players do not support this? It doesn't seem like a particularly hard thing to implement anyway...
Atak_Snajpera
8th June 2010, 17:31
"eng" being the "default value" only applies to the container level. If the "language" element is not present in the file then a reading application has to use "eng" instead. This is indeed not the best value ("und" would have been better), but that's what the speficiations say since 2002. You cannot simply change that now and break every spec compliant program out there.
Can you at least modify mkvinfo.exe to show language?
+ A track
| + Track number: 2
| + Track UID: 253140655
| + Track type: audio
| + Enabled: 1
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 1
| + MinCache: 0
| + Timecode scale: 1
| + Max BlockAddition ID: 0
| + Codec ID: A_VORBIS
| + Codec decode all: 1
| + CodecPrivate, length 4330
| + Language: eng
| + Name: 2.0 Vorbis
| + Audio track
| + Sampling frequency: 48000
| + Channels: 2
| + A track
Can you at least modify mkvinfo.exe to show language?
No. mkvinfo is designed to show the elements that are actually present. If you want to know things like basic flags, track type and language you can use "mkvmerge --identify-verbose yourfile.mkv". That's what mmg does when you add a file.
EricJ2190
8th June 2010, 18:25
I like the idea of not writing default flags and I don't think you should revert that behavior, but how about a command-line option to write default flags if we want that behavior?
If you aren't willing, I'll try and make a modified version for my own use, but I'd like to see that as an option in the official mkvmerge.
I certainly won't add such an option myself, but I might consider applying patches if anyone wrote them. Such an option would have to be off by default, it won't show up in mmg (mmg is way too crowded as it is already), and it must be documented in the man page (DocBook XML).
73ChargerFan
8th June 2010, 20:29
DTS-HD master audio is different from TrueHD+AC3. With DTS-HD the "master audio" part is actually only the difference between the lossy core and the lossless original. Therefore a decoder needs both the core and the HD part in order to decode losslessly.
With TrueHD+AC3 this is not the case. The TrueHD is completely decodable on its own without the AC3 part.
Thanks for clarifying this.
guillome
9th June 2010, 16:14
Hi Mosu,
It seems that starting yesterday Avira AV started to see the mmg.exe located in the mkvtoolnix program folder as a trojan (TR/Dldr.Agent.dsqn' [trojan])
Looking on google, it seems kaspersky went for it too: http://forum.kaspersky.com/index.php?showtopic=172738
That was with v3.4.0 that i had been using since its release.
Gonna install v4.0.0 and report if it happens again. :devil:
sneaker_ger
9th June 2010, 16:46
mmg 4.0.0 : 1/41 scanners say it's infected (http://www.virustotal.com/de/analisis/50b9ae0fcc3ed9f1c3e0fae5f7de5663344a5a4c7dac81fa074e21195af62899-1276097920)
mmg 3.4.0 : 3/41 scanners say it's infected (http://www.virustotal.com/de/analisis/34d773441c8a8711206c5261adf3ea01eefd8d4e8ea1c8d6211c8e8ef2d18ee7-1276098129)
(hope the links work)
Please report those findings to the AV makers. I cannot do anything about it but report them there as well. Again.
sneaker_ger
9th June 2010, 21:17
small addition to my previous post:
MPC-HC's splitter is NOT working fine without the language tag, but only subtitles are affected. ( error description (http://forum.doom9.org/showpost.php?p=1405881&postcount=13140) ) Use Haali's splitter (for now).
Mosu
10th June 2010, 22:27
Is there any support for H264 streams with open-gop planned? There are some problems with seeking which is probably caused by a missing support for open-gop in mkv. The problem and its possible cause are explained here: http://forum.doom9.org/showpost.php?p=1401348&postcount=178.
I just created an open GOP file with a patched x264 v1564. mkvmerge v4.0.0 can handle the file just fine without any further modification. Like I said mkvmerge already treats the first non IDR slice after a SEI NALU as a key frame from the container's point of view. So I guess this just works.
sneaker_ger
11th June 2010, 02:47
What will happen if we want to split such files? Will we see corruptions (as to missing I-frames) at the end of a file?
foxyshadis
11th June 2010, 03:27
What will happen if we want to split such files? Will we see corruptions (as to missing I-frames) at the end of a file?
Only in the very last frames of the open gop, if any reference the I. Going forward, nothing should because the x264 open-gop patch clears the ref list at each gop, so no corruption is possible. (However, you've always been able to set the gop to infinity and use i-frames only for scenecuts, where later frames can reference pre-I frames.) mkvmerge won't enforce an IDR (closed GOP) split.
Mosu: Concerning the discussion above, I appreciate anything enforcing higher efficiency, even if it's only a few bytes!
Mosu
11th June 2010, 07:32
mkvmerge won't enforce an IDR (closed GOP) split.
That's correct. mkvmerge doesn't distinguish between IDR-type key frames and non IDR-type keyframes outside of the MPEG4 p10 handling code. And the splitting code is a layer or two above that code.
Modifying this to pass extra information up to that layer (e.g. "splitting possible before this frame?") would not be that hard, but I won't spend more time on this until it's been officially accepted into x264. Other things to do as well :)
Hello Mosu,
in your most recent build, i.e. 265, there's quite a strange error.
I cannot add AC3s to the project in mkvmerge GUI cause mkvmerge crashes :)
http://imgur.com/qpnom.png
mkvmerge.exe itself crashes @ 001e4a8e but I guess that is not much useful :)
Mosu
13th June 2010, 08:16
Can you please upload the first 20mb of the file to my FTP server?
Can you please upload the first 20mb of the file to my FTP server?
That has been done. Not all files have this problem however I reckon a specific type of them does. I.e. I have found several files with such problem and uploaded the smallest of them. I think 448kbps 2_0 are broken (maybe some other types as well)
Mosu
13th June 2010, 21:54
That has been done. Not all files have this problem however I reckon a specific type of them does. I.e. I have found several files with such problem and uploaded the smallest of them. I think 448kbps 2_0 are broken (maybe some other types as well)
Thanks. I'm not at home for a couple of days and will not be able to take a look at it before next weekend though.
Update: didn't test extensively but I was able to replicate it even with 264 build mkvmerge.exe
I finally got rid of the problem by only replacing the exe file with the one from 3.4.0.0. So the problem is limited with mkvmerge.exe file.
Worse news -- it is a generic error it seems, so any track can potentially crash it, I was able to get a crash on h264 stream, for instance.
Mosu
15th June 2010, 16:28
The problem is not a generic problem. mkvmerge v4.0.0 just received a lot of updates in almost every part of its code, and that's why you may see such issues in multiple cases.
I've fixed the issue for the AC3 detection code in build 269 (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.0.0-build20100615-269-setup.exe). I haven't been able to reproduce the issue with h264 tracks though. Could you please upload the first 40 MB of that h264 that causes your crash?
I haven't been able to reproduce the issue with h264 tracks though. Could you please upload the first 40 MB of that h264 that causes your crash?
No problem, uploading 50mb segment. It crashes 265 build mkvmerge in the same way as AC3 did (obviously the whole file crashes it as well)
However it seems to be fixed in 269 build, both AC3 and h264 now seem to work.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.