MKVToolNix -- Cross-platform tools for Matroska

Frequently asked & answered questions

Muxing

Common errors

Features

Distribution

Muxing

Is it possible to create byte-identical files if the source files and the mux settings are identical?

Technically, it is possible, but mkvmerge does not allow this in an easy way. There are several elements in a Matroska file that differ with each muxing, even if everything else is the same between different mux runs. These include but are not limited to the muxing date (DateUTC) and all unique IDs (track UIDs, attachment UIDs, segment UIDs, chapter UIDs etc etc).

If you use different builds of MKVToolNix then you'll also have the WritingApp differ as it contains mkvmerge's version number and build timestamp. This may be the case e.g. if you want to mux on two different machines.

mkvmerge knows a switch that will use fixed values for all of the elements listed above. However, files created this way have serious issues: they violate the Matroska specifications, may cause problems during playback (especially with advanced features like segment linking, ordered chapters etc) and are not future-proof. The only reason this switch exists in the first place is that it is used for regression testing during mkvmerge's development. For this reason I will not name the switch here.

There is a solution if you're willing to run other software directly after the muxing process. What most people do if they want to have byte-identical files is mux the two files with identical settings and then use a file synchronization tool for copying only the differences between the two files. This is a pretty fast process as the amount of bytes the two resulting files differ by is very small.

There are several OpenSource programs that are suited perfectly for this job. On Linux/Unix/Mac people usually use rsync. On Windows people usually use a native port of rsync called DeltaCopy. Another alternative is Unison.

Can the tools use FIFOs, pipes or standard output/standard input for reading/writing?

No. All of the tools in the MKVToolNix package rely on their input and output files being fully seekable. FIFOs, pipes and standard input/output are not. Therefore they cannot be used.

At the moment there are no proper error messages if you try to use a FIFO as an input or output file. However, the resulting files are most likely cut off or incorrect.

Why does the language "eng" (English) not show up in the output file even though I've selected it in the GUI?

The Matroska specifications know a feature called "default values". These default values have been in place since the beginning in 2002. The meaning of the default value is that any application reading a Matroska file must use the default value if the element itself is not present in the file. For example, if the track headers for a track do not contain a "language" element then this means that the value "eng" must be used by the reading application.

Starting with version 4.0.0 mkvmerge does not write elements to output files whose value equals their default value. This mostly applies to the "language" and "default track flag" elements. If an application does not show "eng" as the track's language even though you've selected it in the GUI then please file a bug report for that application.

Why does audio or video not play anymore since v4.1.0 (e.g. MP3, AC3, DTS audio tracks, h264 video tracks)? Why does Windows Explorer crash when displaying Matroska files with v4.1.0 and newer?

The Matroska specifications know a feature called "header removal compression". This allows a muxer to keep a certain number of bytes that are identical for each frame in the track headers removing them from the individual frames. This reduces the size of the tracks significantly without altering the content as a demuxer can add the bytes found in the track headers to each frame during demuxing.

Starting with v4.1.0 mkvmerge uses header removal compression for a couple of track types by default. These include AC3, DTS and MP3 audio tracks as well as Dirac video tracks. Other versions add other track types (e.g. h.264/AVC since 4.2.0) to this list. The user muxing a file may disable it by explicitely selecting 'none' as the compression scheme for such a track.

If your player has difficulties playing such files then it is a bug in that player or in the demuxer but not in mkvmerge. This feature has been part of the Matroska specification since more than six years, and there's no excuse for refusing to add support for it.

The proper solution is to ask the vendor of your player to support this feature. A temporary solution is to re-mux such files turning off extra compression for all tracks.

The reason for crashes in Windows Explorer is the DivX thumbnail component which does not support this feature. Uninstalling it will fix the issue. There are reports that DivX Plus 8 seems to have fixed the crashes, but the thumbnails are still completely black.

Here's a list of hardware and software players that do not implement this part of the specification. This list is most likely outdated as updates are released by the authors and manufacturers.

Several players have had issues with this feature in the past but have been fixed in the meantime. For hardware devices this usually means that a firmware upgrade is required. Again this list is probably outdated and incomplete.

What is the difference between the "default track" flag and the "forced" flags? And what about the settings "default", "yes" and "no" in mmg?

Leaving a flag (no matter which flag) on the "default" settings means the decision whether or not it should be set is up to mkvmerge. mkvmerge usually takes the information provided by the source container into account. For some flag types (especially the "default track" flag) there are other considerations as well.

Setting a flag to "no" will force mkvmerge not to set that flag, no matter what those other considerations would have done and no matter what the source container provided for that flag.

For the "default track" flag: The special consideration is that mkvmerge will automatically set this flag to "yes" for exactly one track of each track type (audio, video, subtitles). You can only prevent this by explicitly setting the "default track" flag to "no" manually for all tracks of a kind (e.g. for all subtitle tracks).

The "default track" flag tells the player that this track should be played unless the user overrides that decision somehow. You usually mark the original audio track with "default track" and leave it off for the rest of them, e.g. for the director's commentary or some translations you don't want (e.g. Lord of the Rings, mark "English" as "default track" but not "German" and "Director's comments (English)").

As a lot of users don't want subtitles shown by default they tell mkvmerge not to set the "default track" flag for any subtitle track.

Now on to the "forced display" flag, in short "forced". If this is set to "on" then this track must be played/shown no matter what the user selected for his preferences or what the player would normally chose to show/play. This is used seldom, e.g. only for a subtitle track that only contains the English translation whenever Legolas is talking Elbish.

"Forced" has nothing to do with "default track". If "forced" is set the player must play that track no matter what "default track" is set to. In fact normally a track that has "forced" set does not have "default track" set, though it is neither invalid nor undefined behavior.

Options for improving playback on players that don't implement the full Matroska specification

There are several options that can improve playback on certain players (both hardware and software based ones) that don't implement certain Matroska features. These are:

--compression

--compression: This option is already mentiond in the FAQ entry about header removal compression. With this option that compression can be turned off.

Possible effects of your player not supporting this feature are no video playback, no audio playback, distorted audio or (less likely) distorted video. Some players may even crash when accessing files with this feature.

As header removal compression isn't the only compression scheme available in Matroska you don't need to turn off compression for subtitle tracks.

Compression is a track-based option meaning you have to enable it for each and every problematic track. In mmg this option is found in the "Compression" drop down box on the "Extra options" sub-tab of the "Input" tab.

--clusters-in-meta-seek

There two kinds of indexes in Matroska files: the "cues" and the "meta seek elements". The former is used for telling a player where the key frames are in a file. The latter are used for telling a player where certain important Matroska elements are in a file.

In Matroska a cluster is a unit that contains a number of frames of all track types. A file is often made up of hundreds if not thousands of clusters. Normally the "cues" provide enough information for a player in order to find the cluster that contains a certain key frame a player wants to seek to. Some players also need the clusters themselves to be referenced in the "meta seek elements".

Symptoms include seeking in your player doesn't work properly or takes a lot of time. This also applies to skipping/selecting chapters to go to as that is a seeking operation as well.

This is a global option. Therefore you only have to use it once on the command line, and its position does not matter. You can enable it in mmg by selecting the option "Add command line options" from the "Muxing" menu, selecting the option "--clusters-in-meta-seek" from the drop down box and pressing the "Add" button.

--disable-lacing

Lacing is a technique for putting several frames of a track (up to 8) into a single Matroska element called 'BlockGroup' or 'SimpleBlock'. This reduces file size overhead. Some players don't support each and every kind of lacing method that Matroska files can use.

Symptoms of a player not supporting some lacing methods or lacing in general include not playing certain tracks at all or only in certain parts of a file or only for very short periods of time.

This is a global option. Therefore you only have to use it once on the command line, and its position does not matter. You can enable it in mmg by selecting the option "Add command line options" from the "Muxing" menu, selecting the option "--disable-lacing" from the drop down box and pressing the "Add" button.

--engage no_simpleblocks

In Matroska there are two element types that contain the actual frames: the older 'BlockGroup' structure and the newer (introduced roughly around 2004) 'SimpleBlock' structure. The former is more flexible, the latter has less overhead. Muxers usually use both in the same file: 'BlockGroup' if they need certain features for a frame (e.g. a special duration) and the 'SimpleBlock' element otherwise (in order to reduce file size overhead).

Symptoms of a player not supporting 'SimpleBlock' elements include include not playing certain tracks at all or only in certain parts of a file or only for very short periods of time.

This is a global option. Therefore you only have to use it once on the command line, and its position does not matter. You can enable it in mmg by selecting the option "Add command line options" from the "Muxing" menu, selecting the option "--engage no_simpleblock" from the drop down box and pressing the "Add" button.

Players don't use embedded fonts for subtitle playack

Some people have noticed that their players (both hardware and software ones) might not use TrueType fonts attached to Matroska for subtitle playback while they used to do it earlier. Here's why.

Matroska files can contain attachments. Each attachment is identified by both a name and a UID. Its type, however, is specified via a MIME type.

Each time the user adds an attachment to mmg the MIME type will be detected automatically. While the user can override this choice easily most don't bother.

The system used for automatic MIME type recognition is the well-known libmagic library which is part of the file utility. It is the standard library for MIME type detection on non-Unix systems and is also used in a wide variety of Windows programs.

A couple of versions ago libmagic returned a different MIME type than it does today. Earlier it was application/x-truetype-font, today it is application/x-font-ttf. Most Linux users noticed this change some time ago while Windows users didn't. This is due to me not updating the libmagic library I was using for creating the Windows build of MKVToolNix.

See this mailing list post for the rationale behind the change.

Starting with v5.1.0 I did finally update said library for the Windows builds as well. If a player doesn't recognize application/x-font-ttf as a MIME type for TrueType fonts then it will most likely not use the attached font for playback.

As this causes major headaches for a lot of people I have added a manual mapping in release v5.2.0 so that the older MIME tpe application/x-truetype-font is used even if libmagic returns application/x-font-ttf.

mkvextract extracts the wrong track! And mkvinfo's track IDs do not match mkvextract's or mkvmerge's!

First of all, there's a misconception about three different terms: track numbers, track UIDs (track unique IDs) and track IDs. The former two, track numbers and track UIDs, are fields stored in the track headers of a Matroska file. The corresponding elements are called "TrackNumber" and "TrackUID" in the Matroska specs.

The latter ones, track IDs, are IDs assigned by mkvmerge and mkvextract upon program invocation. Those IDs are not actually present in the file, and they're only valid within the same version of the MKVToolNix tool family. The order and numbering scheme of these IDs is also subject to change.

Earlier versions of mkvmerge used to assign track IDs that usually equaled the track's "TrackNumber" element. Therefore users were using those numbers in order to correlate the output of mkvinfo (or even third party tools like MediaInfo) with the input of mkvextract -- which is wrong. In order to find out the track IDs that mkvmerge and mkvextract use one is suposed to execute mkvmerge in identification mode:

mkvmerge --identify yourfile.mkv or, for more information, mkvmerge --identify-verbose yourfile.mkv

The only guarantee that I make is that the same version of mkvmerge and mkvextract will use the same track IDs. Unfortunately there were a few releases that contained changes and bugs that caused confusion:

In order to simplify correlating mkvmerge's track IDs and mkvinfo's output mkvmerge will output the track's UID in verbose identification mode along with a few other new header fields starting with release v5.3.0.

Common errors

mkvmerge outputs an error: "Error: cstrutf8_to_UTFstring: Invalid UTF-8 sequence encountered"

Users of certain application (Popcorn MKV AudioConverter) have often complained that mkvmerge exits with the error message shown above. My analysis shows that this is not a bug in mkvmerge.

Popcorn MKV AudioConverter seems to be a frontend for various tools that are executed in the background in order to convert and encode from one format to another one. One of the programs that is run prior to mkvmerge produces a Matroska file that is then used as an input file for mkvmerge. This Matroska file contains Unicode strings with invalid characters. mkvmerge chokes on these invalid strings.

Therefore this error message is not really a bug in mkvmerge. The proper solution would be to fix the creation of the invalid encoding by that other tool (I don't know which tool that is, nor do I care).

However, I do recognize that this may be rather difficult depending on who that tool's author is. Therefore newer mkvmerge versions (starting with v4.5.0) will simply discard such strings with invalid encodings. You can update mkvtoolnix, and it should work with those invalid files.

mkvmerge hangs during muxing on RedHat Enterprise Linux / CentOS / Scientific Linux

This is due to a bug in the GNU C compiler (gcc) used on RedHat Enterprise Linux / CentOS / Scientific Linux 5.x. A workaround is to disable optimizations by passing the option --disable-optimizations to configure.

The spec file provided in the source tarball contrib/centos.spec contains that option and can be used without modification.

Features

Will there be a batch muxing feature in mmg? Or a something similar for the header editor/mkvpropedit?

Sorry, but such a feature will never be implemented. There are excellent shells out there that can do this easily. For example, with the bash or zsh shells you could convert all .avi files into Matroska with these commands: 

    find -type f -name '*.avi' | {
      while read filename ; do
        mkvmerge -o /path/to/output/dir/"`basename "$filename" .avi`.mkv" "$filename"
      done
    }

Batch processing of header editing is just as easy. For example, if you want to set the title field for a couple of files to the base file name then you can do the following with bash/zsh: 

     for file in *.mkv ; do
       mkvpropedit "$file" --set title="${file%.mkv}"
     done

I do realize that using shells is not everyone's thing. However, implementing a powerful and flexible batch remuxer/header editor requires countless hours of work. If I cut down on the hours then either the flexibility or the number of features would be severely reduced and therefore the work would not be worth it because too few people could actually use it in such a state.

The short version is that it's way too much work and that I don't have that amount of free time. So the answer is "no". Sorry.

When will mkvmerge/mmg support MPEG transport streams (.ts or .m2ts files)?

The upcoming release, v5.0.0, will feature support for MPEG transport streams.

How does mkvmerge handle TrueHD tracks with embedded AC3 data?

If a TrueHD track contains AC3 data then both data sets are completely decodable independently from another. The AC3 part is present so that if that track is output to a hardware decoder that doesn't know about TrueHD then that hardware decoder can still decode the AC3 part. The only difference between the two is that TrueHD is a lossless codec while AC3 isn't -- but they've both been done from the same source material.

The Matroska specs state that one track must only contain data for one codec. Therefore mkvmerge cannot keep the AC3 interleaved with the TrueHD part in a single track.

At the moment mkvmerge's only solution is to discard the AC3 part silently. This applies to TrueHD tracks read from any source file, be it from e.g. a raw TrueHD file, from a Matroska file or a MPEG transport stream. In future I may change that behaviour so that mkvmerge will present the interleaved AC3 part as a track of its own so that the user can chose wether to mux the AC3 part into its own track or to discard it (e.g. because the source material contains another track that only contains the AC3 part as is often the case).

Distribution

Is MKVToolNix compatible with Windows 7?

Yes. Starting with v3.0.0 it even displays the muxing progress in Windows 7's taskbar, but earlier versions were working just fine as well.

Is MKVToolNix compatible with 64bit versions of Windows?

Yes. The Windows builds I distribute are 32bit, but they're fully compatible with 64bit Windows installations. There are several reasons why there are no special 64bit builds, but the most important of them is that MKVToolNix does not gain anything from being compiled with 64bit. Its 32bit version fully supports files of any size, arbitrary time codes, and needs a lot less memory than the maximum that a 32bit operating system provides.

Is there a virus in your installer for Windows?

Short answer: no, and there never has been one.

Longer answer: no, and here's why.

Note: This has happened with v2.4.1 for the first time, but it has happend again since. However, the result of my investigation has always been the same. Therefore this section applies to current versions just as well.

Several times in the past users have reported that their virus scanner detected a virus in the installer for Windows available on my site. I could verify that some virus scanners did indeed detect something, but most others did not. There are several reasons why I'm 100% certain that this was a false positive:

  1. The build process for the installer runs exclusively on Linux. MKVToolNix itself is built on Linux with a mingw cross compiler, and the installer itself is built with a Linux version of the NSIS compiler. Afterwards the installer is uploaded to my Linux-based webserver by the Linux program Unison.
  2. Even on my Linux machine I run an anti virus software which has never detected a virus.
  3. The installer software I use (NSIS -- the Nullsoft Scriptable Installation System) has been the victim of being falsely detected as being virus infected in the past. Those cases have all been false positives.
  4. When this problem occured the first time I sent the installer to Kaspersky for verification. Kaspersky replied quickly and confirmed that it was indeed a false positive.

When can MKVToolNix be built against external versions of libEBML and libMatroska again?

It should be possible again with release v5.0.0.

Earlier I wrote:

I don't know; maybe never. I moved away from it because all recent releases of libEBML/libMatroska were binary incompatible with each other due to interface changes in the classes. I fully expect the next releases to share the same fate. This always requires package maintainers to release completely separate packages and not just new releases (e.g. there are now "libebml0" and "libebml3" in Debian at the same time, and there were "libebml1" and "libebml2" as well).

Also including them in MKVToolNix allows me to bug fix faster there. I simply lack the time to provide proper releases for libEBML/libMatroska after each change. This is simple pragmatism.

© 2002 - 2011 Moritz Bunkus   |   Imprint/Impressum