MKVMERGE(1)

๐Ÿ’– MKVMERGE(1) ๐Ÿ’–

okay bestie, we're in the User Commands part of the manual and the whole thing is about mkvmerge. yes, that mkvmerge. she's iconic, she's booked, she merges things. ๐Ÿ’…โœจ

โœจ NAME โœจ

mkvmerge โ€” Merge multimedia streams into a Matroska(TM) file ๐ŸŒˆ


๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

mkvmerge [global options] {-o out} [options1] {file1}
         [[options2] {file2}] [@options-file.json]

๐Ÿ‘‘ DESCRIPTION ๐Ÿ‘‘

okay so the whole concept: this program takes the input from several media files and joins their streams (all of them or just a selection) into a Matroska(TM) file; see the Matroska(TM) website[1]. that's it, that's the girlboss behavior ๐ŸŽ€

Important ๐Ÿšจ The order of command line options is important. Please read the section "Option order" if you're new to the program. not me begging you to actually read that section, bestie, the order MATTERS. ๐Ÿ˜ญ

๐Ÿ’ซ Global options

  • -v, --verbose โ€” Increase verbosity. she's talking more now, she has things to say ๐Ÿ’ฌ
  • -q, --quiet โ€” Suppress status output. no thoughts, no updates, just silence ๐Ÿซถ
  • -o, --output file-name โ€” Write to the file file-name. If splitting is used then this parameter is treated a bit differently. See the explanation for the --split option for details. ๐Ÿ‘€
  • -w, --webm โ€” Create a WebM compliant file. This is also turned on if the output file name's extension is "webm". This mode enforces several restrictions. The only allowed codecs are VP8, VP9 video and Opus, Vorbis audio tracks. The DocType header item is changed to "webm". ๐ŸŽฌ

For chapters and tags only a subset of elements are allowed. mkvmerge(1) will automatically remove all elements not allowed by the specification. she's cleaning house, no clutter allowed ๐Ÿงน

  • --title title โ€” Sets the general title for the output file, e.g. the movie name. give her a name, she deserves one ๐Ÿ‘‘
  • --default-language language-code โ€” Sets the default language code that will be used for tracks for which no language is set with the --language option and for which the source container doesn't provide a language.

The default language code is 'und' for 'undetermined'. (like, we genuinely don't know, don't ask her ๐Ÿซ )


๐Ÿ”ฎ Segment info handling (global options)

  • --segmentinfo filename.xml โ€” Read segment information from an XML file. This file can contain the segment family UID, segment UID, previous and next segment UID elements. An example file and a DTD are included in the MKVToolNix distribution. ๐Ÿ“„

See the section about segment info XML files below for details.

  • --segment-uid SID1,SID2,... โ€” Sets the segment UIDs to use. This is a comma-separated list of 128-bit segment UIDs in the usual UID form: hex numbers with or without the "0x" prefix, with or without spaces, exactly 32 digits. ๐Ÿ”ข

If SID starts with = then its rest is interpreted as the name of a Matroska file whose segment UID is read and used.

Each file created contains one segment, and each segment has one segment UID. If more segment UIDs are specified than segments are created then the surplus UIDs are ignored. If fewer UIDs are specified than segments are created then random UIDs will be created for them. so either you tell her, or she improvises ๐Ÿ’…


๐ŸŒธ Chapter and tag handling (global options)

  • --chapter-language language-code โ€” Sets the ISO 639-2 language code that is written for each chapter entry. Defaults to 'eng'. See the section about chapters below for details.

This option can be used both for simple chapter files and for source files that contain chapters but no information about the chapters' language, e.g. MP4 and OGM files.

The language set with this option is also used when chapters are generated with the --generate-chapters option.

  • --chapter-charset character-set โ€” Sets the character set that is used for the conversion to UTF-8 for simple chapter files. See the section about text files and character sets for an explanation how mkvmerge(1) converts between character sets. ๐Ÿ”ค

This switch does also apply to chapters that are copied from certain container types, e.g. Ogg/OGM and MP4 files. See the section about chapters below for details.

  • --chapter-sync d[,o[/p]] โ€” Adjust the timestamps of the chapters in the following source file by d ms. Alternatively you can use the --sync option with the special track ID -2 (see section special track IDs). โฑ๏ธ

o/p: adjust the timestamps by o/p to fix linear drifts. p defaults to 1 if omitted. Both o and p can be floating point numbers.

Defaults: no manual sync correction (which is the same as d = 0 and o/p = 1.0).

This option can be used multiple times for an input file applying to several tracks by selecting different track IDs each time.

  • --generate-chapters mode โ€” mkvmerge(1) can create chapters automatically. The following two modes are currently supported: ๐Ÿค–
    • 'when-appending' โ€“ This mode creates one chapter at the start and one chapter whenever a file is appended.

This mode also works with split modes 'parts:' and 'parts-frames:'. For these modes one chapter will be generated for each appended timestamp range (those whose start timestamps are prefixed with '+').

Note ๐Ÿ“ mkvmerge(1) requires a video or an audio track to be present in order to be able to determine when a new file is appended. If one or more video tracks are muxed the first one is used. Otherwise the first audio track is used. she needs something to look at, okay? ๐Ÿ‘€
  • 'interval:time-spec' โ€“ This mode creates one chapter at fixed intervals given by time-spec. The format is either the form HH:MM:SS.nnnnnnnnn or a number followed by one of the units 's', 'ms' or 'us'.

Example: --generate-chapters interval:45s

The names for the new chapters are controlled by the option --generate-chapters-name-template. The language is set with --chapter-language which must occur before --generate-chapters. order matters bestie, we said this ๐Ÿ˜ค

  • --generate-chapters-name-template template โ€” This sets the name template for chapter names generated by the option --generate-chapters. If the option is not used then default 'Chapter <NUM:2>' will be used. ๐Ÿท๏ธ

There are several variables that can be used in the template that are replaced by their actual values when a chapter is generated. The string '<NUM>' will be replaced by the chapter number. The string '<START>' will be replaced by the chapter's start timestamp.

The strings '<FILE_NAME>' and '<FILE_NAME_WITH_EXT>' are only filled when generating chapters for appended files. They will be replaced by the appended file's name without respectively with its extension. Note that only the file's base name and extension are inserted, not its directory or drive components. no paths, no drama ๐Ÿšซ

You can specify a minimum number of places for the chapter number with '<NUM:places>', e.g. '<NUM:3>'. The resulting number will be padded with leading zeroes if the number of places is less than specified.

You can control the format used by the start timestamp with <START:format>. The format defaults to '%H:%M:%S' if none is given. Valid format codes are:

  • %h โ€“ hours
  • %H โ€“ hours zero-padded to two places
  • %m โ€“ minutes
  • %M โ€“ minutes zero-padded to two places
  • %s โ€“ seconds
  • %S โ€“ seconds zero-padded to two places
  • %n โ€“ nanoseconds with nine places
  • %<1-9>n โ€“ nanoseconds with up to nine places (e.g. three places with %3n)

The string '<TITLE>' is only filled when generating chapters for appended files. It'll be replaced by the appended file's title if one is present.

  • --cue-chapter-name-format format โ€” mkvmerge(1) supports reading CUE sheets for audio files as the input for chapters. CUE sheets usually contain the entries PERFORMER and TITLE for each index entry. mkvmerge(1) uses these two strings in order to construct the chapter name. With this option the format used for this name can be set. ๐ŸŽต

If this option is not given then mkvmerge(1) defaults to the format '%p - %t' (the performer, followed by a space, a dash, another space and the title).

If the format is given then everything except the following meta characters is copied as-is, and the meta characters are replaced like this:

  • %p is replaced by the current entry's PERFORMER string,
  • %t is replaced by the current entry's TITLE string,
  • %n is replaced by the current track number and
  • %N is replaced by the current track number padded with a leading zero if it is < 10.
  • --chapters file-name โ€” Read chapter information from the file file-name. See the section about chapters below for details. ๐Ÿ“–
  • --global-tags file-name โ€” Read global tags from the file file-name. See the section about tags below for details. ๐Ÿท๏ธ

๐Ÿ’Ž General output control (advanced global options)

  • --track-order FID1:TID1,FID2:TID2,... โ€” This option changes the order in which the tracks for an input file are created. The argument is a comma-separated list of ID pairs. Each pair contains first the file ID (FID1) which is simply the number of the file on the command line starting at 0. The second is a track ID (TID1) from that file. If some track IDs are omitted then those tracks are created after the ones given with this option have been created. ๐Ÿ”€

If this option isn't given, tracks will be sorted by their type first & the order of their source file second. Video tracks come first followed by audio & subtitle tracks. Other rarely used track types come last. video girlies first, as always ๐Ÿ’…

  • --cluster-length spec โ€” Limit the number of data blocks or the duration of data in each cluster. The spec parameter can either be a number n without a unit or a number d postfixed with 'ms'. ๐Ÿ“ฆ

If no unit is used then mkvmerge(1) will put at most n data blocks into each cluster. The maximum number of blocks is 65535.

If the number d is postfixed with 'ms' then mkvmerge(1) puts at most d milliseconds of data into each cluster. The minimum for d is '100ms', and the maximum is '32000ms'.

mkvmerge(1) defaults to putting at most 65535 data blocks and 5000ms of data into a cluster.

Programs trying to find a certain frame can only seek directly to a cluster and have to read the whole cluster afterwards. Therefore creating larger clusters may lead to imprecise or slow seeking. โš ๏ธ big clusters = slow seeking, no cap, that's just how it is

  • --clusters-in-meta-seek โ€” Tells mkvmerge(1) to create a meta seek element at the end of the file containing all clusters. See also the section about the Matroska(TM) file layout. ๐Ÿ—‚๏ธ
  • --timestamp-scale factor โ€” Forces the timestamp scale factor to factor. Valid values are in the range 1000..10000000 or the special value -1. ๐Ÿ•ฐ๏ธ

okay so normally mkvmerge uses a value of 1000000, which means timestamps and durations get a precision of 1ms. But here's the tea: for files that won't contain a video track but do have at least one audio track, mkvmerge automatically picks a timestamp scale factor so that all timestamps and durations have a precision of one audio sample. Yeah it's bigger overhead, but bestie it buys you precise seeking and extraction. โœจ

And if you pass the special value -1? Then mkvmerge will use sample precision even if a video track is present. no cap. ๐Ÿ’…

  • --enable-durations โ€” writes durations for all the blocks. It makes the file bigger and, lowkey, doesn't give players any extra value right now. ๐Ÿ™ˆ
  • --no-cues โ€” tells mkvmerge not to create and write the cue data (think of it like an index in an AVI). Matroskaโ„ข files can totally play back without cue data, but seeking will probably be imprecise and slower. Only use this if you're really desperate for space, or you're just testing. See also the --cues option, which you can specify per input file. ๐ŸŽ€
  • --no-date โ€” by default mkvmerge sets the "date" segment information field to the time & date when multiplexing started. With this option that field just... isn't written at all. bye. ๐Ÿ‘‹
  • --date timestamp โ€” sets the DateUTC field written to the segment information. The timestamp has to be ISO 8601-like: YYYY-mm-ddTHH:MM:SSZ for UTC, or with an offset ยฑHH:MM (a space instead of T is also accepted), e.g. 2017-03-28T17:28:00Z or 2017-03-28 17:28:00+02:00. โฐ If you use it together with --no-date, then --no-date takes precedence and no date will be written. periodt.
  • --disable-lacing โ€” disables lacing for all tracks. This makes the file's size go up, especially if there are a lot of audio tracks. โš ๏ธ This option is not intended for everyday use, bestie.
  • --disable-track-statistics-tags โ€” normally mkvmerge writes certain tags with statistics for each track. If those tags are already there, they get overwritten. The tags are BPS, DURATION, NUMBER_OF_BYTES and NUMBER_OF_FRAMES.

Enabling this option stops mkvmerge from writing those tags, and also stops it from touching any existing tags with the same names. ๐Ÿซถ

  • --disable-language-ietf โ€” normally mkvmerge writes the new IETF BCP 47 language elements in addition to the legacy language elements in track headers, chapters and tags. If you use this option, only the legacy elements get written. ๐ŸŒธ
  • --normalize-language-ietf mode โ€” turns on normalizing all IETF BCP 47 language tags to either their canonical form with mode 'canonical', or to their extended language subtags form with mode 'extlang', or turns it off with mode 'off'. By default, normalization to the canonical form is applied.

In the canonical form, all subtags that have preferred values get replaced by those preferred values. So this converts e.g. 'zh-yue-jyutping' to 'yue-jyutping', or 'fr-FX' to 'fr-FR'. ๐Ÿ”„

For the extended language subtags form, the canonical form gets built first. After that, all primary languages that have an extended language subtag get replaced by that extended language subtag and its prefix. So this converts e.g. 'yue-jyutping' back to 'zh-yue-jyutping', but it has no effect on 'fr-FR' since 'fr' isn't an extended language subtag. iykyk ๐Ÿ’…

  • --stop-after-video-ends โ€” stops processing once the primary video track ends, discarding any remaining packets of other tracks. ๐Ÿ›‘

๐ŸŽฌ File splitting, linking, appending and concatenation (more global options) ๐ŸŽฌ

  • --split specification โ€” splits the output file after a given size or a given time. Quick heads-up bestie: tracks can only be split right before a key frame, so the split point might be a lil off from whatever you specified. that's just how it is. ๐Ÿ’€

At the moment mkvmerge supports the following modes:

  1. Splitting by size.

Syntax: --split [size:]d[k|m|g]

Examples: --split size:700m or --split 150000000

The parameter d may end with 'k', 'm' or 'g' to say the size is in KB, MB or GB respectively. Otherwise a size in bytes is assumed. Once the current output file has reached this size limit, a new one gets started. ๐Ÿ“ฆ

The 'size:' prefix may be omitted for compatibility reasons.

  1. Splitting after a duration.

Syntax: --split [duration:]HH:MM:SS.nnnnnnnnn|ds

Examples: --split duration:00:60:00.000 or --split 3600s

The parameter must either have the form HH:MM:SS.nnnnnnnnn for specifying the duration in up to nano-second precision, or be a number d followed by the letter 's' for the duration in seconds. HH is the number of hours, MM the number of minutes, SS the number of seconds and nnnnnnnnn the number of nanoseconds. Both the number of hours and the number of nanoseconds can be omitted. There can be up to nine digits after the decimal point. โณ Once the duration of the contents in the current output has reached this limit, a new output file gets started.

The 'duration:' prefix may be omitted for compatibility reasons.

  1. Splitting after specific timestamps.

Syntax: --split timestamps:A[,B[,C...]]

Example: --split timestamps:00:45:00.000,01:20:00.250,6300s

The parameters A, B, C etc must all have the same format as the ones used for the duration (see above). The list of timestamps is separated by commas. Once the input stream has reached the current split point's timestamp, a new file is created. Then the next split point given in this list is used. ๐ŸŽฏ

The 'timestamps:' prefix must not be omitted.

  1. Keeping specific parts by specifying timestamp ranges while discarding others.

Syntax: --split parts:start1-end1[,[+]start2-end2[,[+]start3-end3...]]

Examples:

  1. --split parts:00:01:20-00:02:45,00:05:50-00:10:30
  2. --split parts:00:01:20-00:02:45,+00:05:50-00:10:30
  3. --split parts:-00:02:45,00:05:50-

The parts mode tells mkvmerge to keep certain ranges of timestamps while discarding others. The ranges to keep have to be listed after the parts: keyword and separated by commas. A range itself consists of a start and an end timestamp in the same format the other variations of --split accept (e.g. both 00:01:20 and 80s refer to the same timestamp). ๐Ÿ•

If a start timestamp is left out, then it defaults to the previous range's end timestamp. If there was no previous range, then it defaults to the start of the file (see example 3).

If an end timestamp is left out, then it defaults to the end of the source files, which basically tells mkvmerge to keep the rest (see example 3). โœจ

Normally each range gets written to a new file. This can be changed so that consecutive ranges are written to the same file. For that, the user has to prefix the start timestamp with a +. This tells mkvmerge not to create a new file and instead append the range to the same file the previous range was written to. Timestamps will be adjusted so that there will be no gap in the output file even if there was a gap in the two ranges in the input file. ๐Ÿซถ

In example 1, mkvmerge will create two files. The first will contain the content starting from 00:01:20 until 00:02:45. The second file will contain the content starting from 00:05:50 until 00:10:30.

In example 2, mkvmerge will create only one file. This file will contain both the content starting from 00:01:20 until 00:02:45 and the content starting from 00:05:50 until 00:10:30.

In example 3, mkvmerge will create two files. The first will contain the content from the start of the source files until 00:02:45. The second file will contain the content starting from 00:05:50 until the end of the source files.

Note ๐Ÿ‘‘ Note that mkvmerge only makes decisions about splitting at key frame positions. This applies to both the start and the end of each range. So even if an end timestamp is between two key frames, mkvmerge will continue outputting the frames up to but excluding the following key frame. (yes really, it's giving "close enough" energy ๐Ÿ˜ญ)
  1. Keeping specific parts by specifying frame/field number ranges while discarding others.

Syntax: --split parts-frames:start1-end1[,[+]start2-end2[,[+]start3-end3...]]

Examples:

  1. --split parts-frames:137-258,548-1211
  2. --split parts-frames:733-912,+1592-2730
  3. --split parts-frames:-430,2512-

The parts-frames mode tells mkvmerge to keep certain ranges of frame/field numbers while discarding others. The ranges to keep have to be listed after the parts-frames: keyword and separated by commas. A range itself consists of a start and an end frame/field number. Numbering starts at 1. ๐Ÿ”ข

If a start number is left out, then it defaults to the previous range's end number. If there was no previous range, then it defaults to the start of the file (see example 3).

If an end number is left out, then it defaults to the end of the source files, which basically tells mkvmerge to keep the rest (see example 3). โœจ

Normally each range gets written to a new file. This can be changed so that consecutive ranges are written to the same file. For that, the user has to prefix the start number with a +. This tells mkvmerge not to create a new file and instead append the range to the same file the previous range was written to. Timestamps will be adjusted so that there will be no gap in the output file even if there was a gap in the two ranges in the input file. ๐Ÿซถ

Okay so the big thing about all these timestamp-based splits, bestie: mkvmerge(1) only makes its decisions at key frame positions. That goes for both the start and the end of every range. So even if your end frame/field number is chilling somewhere between two key frames, mkvmerge(1) will just keep outputting frames up to but excluding the following key frame. No cap. ๐Ÿ’…

In example 1 mkvmerge(1) will create two files. The first one gets the content starting from the first key frame at or after 137 up to but excluding the first key frame at or after 258. The second file gets the content starting from 548 until 1211. โœจ

In example 2 mkvmerge(1) will create only one file. That file contains both the content starting from 733 until 912 and the content starting from 1592 until 2730. The way it just merges those two ranges into one file? Obsessed. ๐ŸŽ€

In example 3 mkvmerge(1) will create two files. The first one gets the content from the start of the source files until 430. The second file gets the content starting from 2512 until the end of the source files.

This mode considers only the first video track that is output. If no video track is output, no splitting will occur. Periodt.

Note, bestie: the numbers you give with this argument are interpreted based on the number of Matroska(TM) blocks that are output. A single Matroska(TM) block contains either a full frame (for progressive content) or a single field (for interlaced content). mkvmerge does not distinguish between those two โ€” it just counts the number of blocks. For example: if you wanted to split after the 25th full frame with interlaced content, you'd have to use 50 (two fields per full frame) as the split point. ๐Ÿ‘‘

  1. Splitting after specific frames/fields.

Syntax:

--split frames:A[,B[,C...]]

Example:

--split frames:120,237,891

The parameters A, B, C etc must all be positive integers. Numbering starts at 1. The list of frame/field numbers is separated by commas. After the input stream has reached the current split point's frame/field number, a new file is created. Then the next split point given in this list is used. Slay, sequential.

The frames: prefix must not be omitted. fr fr, do not forget it.

This mode considers only the first video track that is output. If no video track is output, no splitting will occur.

Note, bestie: the numbers given with this argument are interpreted based on the number of Matroska(TM) blocks that are output. A single Matroska(TM) block contains either a full frame (for progressive content) or a single field (for interlaced content). mkvmerge does not distinguish between those two and simply counts the number of blocks. For example: if one wanted to split after the 25th full frame with interlaced content, one would have to use 50 (two fields per full frame) as the split point. ๐Ÿซถ
  1. Splitting before specific chapters.

Syntax:

--split chapters:all or --split chapters:A[,B[,C...]]

Example:

--split chapters:5,8

The parameters A, B, C etc must all be positive integers. Numbering starts at 1. The list of chapter numbers is separated by commas. Splitting will occur right before the first key frame whose timestamp is equal to or bigger than the start timestamp for the chapters whose numbers are listed. A chapter starting at 0s is never considered for splitting and is discarded silently. (Rude, but that's the rule. ๐Ÿ’€)

The keyword all can be used instead of listing all chapter numbers manually. Iconic shortcut energy.

The chapters: prefix must not be omitted.

Note, bestie: the Matroska(TM) file format supports arbitrary deeply nested chapter structures called 'edition entries' and 'chapter atoms'. However, this mode only considers the top-most level of chapters across all edition entries. We stay on the surface level here, no digging. ๐Ÿ™ˆ

For this splitting mode the output filename is treated differently than for the normal operation. It may contain a printf like expression '%d' including an optional field width, e.g. '%02d'. If it does, then the current file number will be formatted appropriately and inserted at that point in the filename. If there is no such pattern, then a pattern of '-%03d' is assumed right before the file's extension: '-o output.mkv' would result in 'output-001.mkv' and so on. If there's no extension, then '-%03d' will be appended to the name. ๐Ÿฆ‹

Another possible pattern is '%c' which will be replaced by the name of the first chapter in the file. Note that when '%c' is present, the pattern '-%03d' will not be added automatically. It's giving main character, it doesn't need a co-star.

  • --link โ€” Link files to one another when splitting the output file. See the section on file linking below for details. ๐Ÿ”—
  • --link-to-previous segment-UID โ€” Links the first output file to the segment with the segment UID given by the segment-UID parameter. See the section on file linking below for details.
    • If SID starts with = then its rest is interpreted as the name of a Matroska file whose segment UID is read and used. ๐ŸŽ€
  • --link-to-next segment-UID โ€” Links the last output file to the segment with the segment UID given by the segment-UID parameter. See the section on file linking below for details.
    • If SID starts with = then its rest is interpreted as the name of a Matroska file whose segment UID is read and used. ๐ŸŽ€
  • --append-mode mode โ€” Determines how timestamps are calculated when appending files. The parameter mode can have two values: 'file', which is also the default, and 'track'.

When mkvmerge appends a track (called 'track2_1' from now on) from a second file (called 'file2') to a track (called 'track1_1') from the first file (called 'file1'), then it has to offset all timestamps for 'track2_1' by an amount. For 'file' mode this amount is the highest timestamp encountered in 'file1' โ€” even if that timestamp was from a different track than 'track1_1'. In 'track' mode the offset is the highest timestamp of 'track1_1'.

Unfortunately mkvmerge cannot detect which mode to use reliably. Therefore it defaults to 'file' mode. 'file' mode usually works better for files that have been created independently of each other, e.g. when appending AVI or MP4 files. 'track' mode may work better for sources that are essentially just parts of one big file, e.g. for VOB and EVO files.

Subtitle tracks are always treated as if 'file' mode were active, even if 'track' mode actually is. Subtitle tracks said "I don't do that" and honestly, respect. ๐Ÿ’…

  • --append-to SFID1:STID1:DFID1:DTID1[,...] โ€” This option controls to which track another track is appended. Each spec contains four IDs: a file ID, a track ID, a second file ID and a second track ID. The first pair, "source file ID" and "source track ID", identifies the track that is to be appended. The second pair, "destination file ID" and "destination track ID", identifies the track the first one is appended to.

If this option has been omitted, then a standard mapping is used. This standard mapping appends each track from the current file to a track from the previous file with the same track ID. This allows for easy appending if a movie has been split into two parts and both files have the same number of tracks and track IDs with the command:

mkvmerge -o output.mkv part1.mkv +part2.mkv
  • + โ€” A single '+' causes the next file to be appended instead of added. The '+' can also be put in front of the next file name. Therefore the following two commands are equivalent:
$ mkvmerge -o full.mkv file1.mkv + file2.mkv
$ mkvmerge -o full.mkv file1.mkv +file2.mkv
  • [ file1 file2 ] โ€” If multiple file names are contained in a pair of square brackets, then the second and all following files will be appended to the first file named within the brackets.

This is an alternative syntax to using '+' between the file names. Therefore the following two commands are equivalent:

$ mkvmerge -o full.mkv file1.mkv + file2.mkv
$ mkvmerge -o full.mkv '[' file1.mkv file2.mkv ']'
  • = โ€” For certain file types (MPEG program streams = VOBs) mkvmerge(1) normally looks for files in the same directory as an input file that have the same base name and only differ in their running number (e.g. 'VTS_01_1.VOB', 'VTS_01_2.VOB', 'VTS_01_3.VOB' etc) and treats all of those files as if they were concatenated into a single big file. This option, a single '=', causes mkvmerge not to look for those additional files.

The '=' can also be put in front of the next file name. Therefore the following two commands are equivalent:

$ mkvmerge -o full.mkv = file1.vob
$ mkvmerge -o full.mkv =file1.vob
  • ( file1 file2 ) โ€” If multiple file names are contained in a pair of parenthesis, then those files will be treated as if they were concatenated into a single big file consisting of the content of each of the files one after the other.

This can be used for e.g. VOB files coming from a DVD or MPEG transport streams. It cannot be used if each file contains its own set of headers, which is usually the case with stand-alone files like AVI or MP4. Soz. ๐Ÿ˜ญ

Putting a file name into parenthesis also prevents mkvmerge(1) from looking for additional files with the same base name as described in option =. Therefore these two command lines are equivalent:

$ mkvmerge -o out.mkv = file.mkv
$ mkvmerge -o out.mkv '(' file.mkv ')'

Several things should be noted:

  1. There must be spaces both after the opening and before the closing parenthesis. Not me forgetting the space and breaking everything. ๐Ÿ™ˆ
  2. Every parameter between parenthesis is interpreted as a file name. Therefore all options applying to this logical file must be listed before the opening parenthesis.
  3. Some shells treat parenthesis as special characters. Hence you must escape or quote them as shown in the example above.

๐ŸŽ€ Attachment support (more global options) ๐ŸŽ€

  • --attachment-description description โ€” Plain text description of the following attachment. Applies to the next --attach-file or --attach-file-once option. ๐Ÿซถ
  • --attachment-mime-type MIME type โ€” this is the MIME type of the attachment that comes right after it. It applies to the next --attach-file or --attach-file-once option, so like, order matters bestie ๐Ÿ’…. A list of officially recognized MIME types lives at the IANA homepage[2]. The MIME type is mandatory for an attachment.

If you don't give a MIME type for an attachment, its type gets detected automatically. Slay, it'll figure it out โœจ

  • --attachment-name name โ€” sets the name that gets stored in the output file for this attachment. If you don't pass this option, the name gets derived from the file name of the attachment, exactly as you gave it with the --attach-file or the --attach-file-once option. No extra naming needed, it just vibes off your filename ๐ŸŽ€
  • --attach-file file-name, --attach-file-once file-name โ€” creates a file attachment inside the Matroska(TM) file. The tea on the difference between the two forms: during splitting, files attached with --attach-file get attached to all output files, while the ones attached with --attach-file-once only go into the first file created. If splitting isn't being used, both of them do the exact same thing. Periodt.

mkvextract(1) can be used to extract attached files from a Matroska(TM) file, so you're never stuck ๐Ÿซถ

  • --enable-legacy-font-mime-types โ€” turns on the use of legacy MIME types for certain types of font attachments. For example, 'application/x-truetype-font' will be used for TrueType fonts instead of 'fonts/ttf'. It's giving retro โœจ

This affects both new attachments if their MIME type gets detected automatically and existing attachments whose stored MIME types will be remapped to the legacy ones.

The affected MIME types are 'font/sfnt', 'font/ttf' and 'font/collection', which are all mapped to 'application/x-truetype-fonts', and 'font/otf', which is mapped to 'application/vnd.ms-opentype'. Lowkey a whole glow-up chart, but make it MIME types ๐Ÿ’…


๐ŸŒˆ Options that can be used for each input file ๐ŸŒˆ

  • -a, --audio-tracks [!]n,m,... โ€” copy the audio tracks n, m, etc. The numbers are track IDs, which you can get with the --identify switch. They're not simply the track numbers (see section track IDs), okay bestie, don't get it twisted ๐Ÿ˜ญ. Default: copy all audio tracks.

Instead of track IDs you can also provide ISO 639-2 language codes. This will only work for source files that provide language tags for their tracks.

Default: copy all tracks of this kind.

If the IDs are prefixed with ! then the meaning is reversed: copy all tracks of this kind but the ones listed after the !. Iconic little plot twist ๐Ÿฆ‹

  • -d, --video-tracks [!]n,m,... โ€” copy the video tracks n, m, etc. The numbers are track IDs which can be obtained with the --identify switch. They're not simply the track numbers (see section track IDs). Default: copy all video tracks.

Instead of track IDs you can also provide ISO 639-2 language codes. This will only work for source files that provide language tags for their tracks.

If the IDs are prefixed with ! then the meaning is reversed: copy all tracks of this kind but the ones listed after the !.

  • -s, --subtitle-tracks [!]n,m,... โ€” copy the subtitle tracks n, m, etc. The numbers are track IDs which can be obtained with the --identify switch. They're not simply the track numbers (see section track IDs). Default: copy all subtitle tracks.

Instead of track IDs you can also provide ISO 639-2 language codes. This will only work for source files that provide language tags for their tracks.

If the IDs are prefixed with ! then the meaning is reversed: copy all tracks of this kind but the ones listed after the !.

  • -b, --button-tracks [!]n,m,... โ€” copy the button tracks n, m, etc. The numbers are track IDs which can be obtained with the --identify switch. They're not simply the track numbers (see section track IDs). Default: copy all button tracks.

Instead of track IDs you can also provide ISO 639-2 language codes. This will only work for source files that provide language tags for their tracks.

If the IDs are prefixed with ! then the meaning is reversed: copy all tracks of this kind but the ones listed after the !.

  • --track-tags [!]n,m,... โ€” copy the tags for tracks n, m, etc. The numbers are track IDs which can be obtained with the --identify switch (see section track IDs). They're not simply the track numbers. Default: copy tags for all tracks.

If the IDs are prefixed with ! then the meaning is reversed: copy everything but the IDs listed after the !.

  • -m, --attachments [!]n[:all|first],m[:all|first],... โ€” copy the attachments with the IDs n, m, etc to all or only the first output file. Each ID can be followed by either ':all' (which is the default if neither is entered) or ':first'. If splitting is active, then those attachments whose IDs are specified with ':all' get copied to all of the resulting output files, while the others are only copied into the first output file. If splitting isn't active, then both variants have the same effect โ€” no drama ๐Ÿ’…

The default is to copy all attachments to all output files.

If the IDs are prefixed with ! then the meaning is reversed: copy everything but the IDs listed after the !.

  • -A, --no-audio โ€” don't copy any audio track from this file. Silence, bestie ๐Ÿ”‡
  • -D, --no-video โ€” don't copy any video track from this file.
  • -S, --no-subtitles โ€” don't copy any subtitle track from this file.
  • -B, --no-buttons โ€” don't copy any button track from this file.
  • -T, --no-track-tags โ€” don't copy any track specific tags from this file.
  • --no-chapters โ€” don't copy chapters from this file.
  • -M, --no-attachments โ€” don't copy attachments from this file.
  • --no-global-tags โ€” don't copy global tags from this file.
  • --regenerate-track-uids โ€” when this option is used for a Matroska source file, mkvmerge(1) will create new random unique track IDs instead of keeping the existing ones in the file. Existing track UIDs in chapters & tags read from the same file will be remapped to the newly generated values. Fresh identity, who dis ๐Ÿ’…

This behavior is enabled automatically for Matroska files created by the MakeMKV software. The reason is that MakeMKV uses consecutive numbers (1, 2, 3...) as UIDs instead of generating random ones. Not it being predictable ๐Ÿ™ˆ

  • -y, --sync TID:d[,o[/p]] โ€” adjust the timestamps of the track with the id TID by d ms. The track IDs are the same as the ones given with --identify (see section track IDs).

o/p: adjust the timestamps by o/p to fix linear drifts. p defaults to 1 if omitted. Both o and p can be floating point numbers.

Defaults: no manual sync correction (which is the same as d = 0 and o/p = 1.0).

This option can be used multiple times for an input file, applying to several tracks by selecting different track IDs each time. Sync them all, bestie ๐ŸŽ€

  • --cues TID:none|iframes|all โ€” controls for which blocks cue (index) entries are created for the given track (see section track IDs). 'none' inhibits the creation of cue entries. For 'iframes' only blocks with no backward or forward references ( = I frames in video tracks) are put into the cue sheet. 'all' causes mkvmerge(1) to create cue entries for all blocks, which will make the file very big ๐Ÿ˜ญ

The default is 'iframes' for video and subtitle tracks and 'none' for audio tracks. See also option --no-cues, which inhibits the creation of cue entries regardless of the --cues options used.

This option can be used multiple times for an input file, applying to several tracks by selecting different track IDs each time.

  • --default-track-flag TID[:bool] โ€” sets the "default track" flag for the given track (see section track IDs) if the optional argument bool is set to 1 or if it isn't present. The flag will be set if the source container doesn't provide that information and the user doesn't specify it via this option.

If the user does not explicitly select a track during playback, the player should select one of the tracks that has its "default track" flag set, taking user preferences such as their preferred language into account. Main character track energy ๐Ÿ‘‘

This option can be used multiple times for an input file, applying to several tracks by selecting different track IDs each time.

  • --track-enabled-flag TID[:bool] โ€” sets the "track enabled" flag for the given track (see section track IDs) to the given value bool (0 or 1; defaults to 1 if not specified). Tracks are enabled by default if no option is specified for them and the source container doesn't provide this information either.

Only tracks whose "track enabled" flag is set should be considered for playback.

This option can be used multiple times for an input file, applying to several tracks by selecting different track IDs each time.

  • --forced-display-flag TID[:bool] โ€” sets the "forced display" flag for the given track (see section track IDs) if the optional argument bool is set to 1 or if it isn't present. Use this for tracks containing onscreen text or foreign-language dialogue ๐ŸŒธ

This option can be used multiple times for an input file, applying to several tracks by selecting different track IDs each time.

  • --hearing-impaired-flag TID[:bool] โ€” sets the "hearing impaired" flag for the given track (see section track IDs) if the optional argument bool is set to 1 or if it isn't present. This flag can be set if the track is suitable for users with hearing impairments ๐Ÿ’–

This option can be used multiple times for an input file, applying to several tracks by selecting different track IDs each time.

  • --visual-impaired-flag TID[:bool] โ€” sets the "visual impaired" flag for the given track (see section track IDs) if the optional argument bool is set to 1 or if it isn't present. This flag can be set if the track is suitable for users with visual impairments ๐Ÿ’œ

This option can be used multiple times for an input file, applying to several tracks by selecting different track IDs each time.

  • --text-descriptions-flag TID[:bool] โ€” sets the "text descriptions" flag for the given track (see section track IDs) if the optional argument bool is set to 1 or if it isn't present. This flag can be set if the track contains textual descriptions of video content suitable for playback via a text-to-speech system for a visually-impaired user โœจ

This option can be used multiple times for an input file, applying to several tracks by selecting different track IDs each time.

  • --original-flag TID[:bool] โ€” bestie, this one slaps the "original language" flag onto the track you point at (check the track IDs section for how to name it). It only gets set if the optional bool is 1, or if you justโ€ฆ don't bother giving a bool at all (then it's assumed ๐Ÿ’…). When is it appropriate? When the track is genuinely in the content's original language โ€” not a translation, okay?

You can drop this option multiple times for one input file if you're flagging several different tracks โ€” just pick a different track ID each time. ๐ŸŽฏ

  • --commentary-flag TID[:bool] โ€” same energy as above but for the "commentary" flag. Set on the track (see track IDs) when bool is 1 or when bool isn't there at all. Use it when the track literally contains commentary, because that's what it says on the tin. ๐ŸŽ™๏ธ

Repeatable! Multiple times, multiple track IDs, one input file. No cap.

  • --track-name TID:name โ€” names the track. You give it the track (see track IDs) and the name, and boom, it's named. โœจ
  • --language TID:language โ€” sets the language for the track you picked (see track IDs). Both ISO 639-2 language codes and ISO 639-1 country codes are allowed โ€” the country codes get auto-converted into language codes, so don't stress about it. ๐ŸŒ

Wanna see every language with its ISO 639-2 code? That's what --list-languages is for.

Repeatable, same deal: multiple uses, multiple track IDs, several tracks in one input file.

  • -t, --tags TID:file-name โ€” reads tags for the track numbered TID out of the file file-name. The tags section below has all the tea. ๐Ÿท๏ธ
  • --aac-is-sbr TID[:0|1] โ€” okay so this tells mkvmerge(1) that the track with ID TID is SBR AAC (aka HE-AAC or AAC+). You need this when a) the source is an AAC file (not a Matroska(TM) file) and b) that AAC file has SBR AAC data in it.

Why does this switch even exist? Because it is technically impossible to automatically tell normal AAC data apart from SBR AAC data without decoding a whole AAC frame ๐Ÿ˜ญ, and since there are several patent issues with AAC decoders, mkvmerge(1) will never contain that decoding stage. Periodt. So for SBR AAC files this switch is mandatory โ€” skip it and the resulting file might not play back correctly, or honestly might not play at all. ๐Ÿ’€

If the source is a Matroska(TM) file, the CodecID should be enough to detect SBR AAC. But if the CodecID is wrong, you can use this switch to fix it.

And if mkvmerge wrongfully decides an AAC file is SBR? Just slap ':0' onto the track ID. ๐Ÿฉน

  • --audio-emphasis TID:n|symbolic-name โ€” sets the emphasis for the audio track with track ID TID. The mode is either a number n (certain values between 0 and 16) or a symbolic name. Every valid number & symbolic name is listable with --list-audio-emphasis. ๐Ÿ”Š
  • --reduce-to-core TID โ€” some audio codecs have a lossy core plus optional extensions that do the lossless decoding thing. This option tells mkvmerge(1) to copy only the core and skip the extensions. Default behaviour? Both core and extensions get copied. ๐Ÿคท

Right now only DTS tracks are affected by this. TrueHD tracks with an embedded AC-3 core are instead presented as two separate tracks, and the user picks which one to copy. For DTS that scheme wouldn't work, because the HD extensions can't be decoded by themselves โ€” unlike the TrueHD data. Make it make sense ๐Ÿง 

  • --remove-dialog-normalization-gain TID โ€” some audio codecs carry header fields telling the decoder or player to apply a (usually negative) gain for dialog normalization. This tells mkvmerge(1) to remove or minimize that gain by rewriting the corresponding header fields. โœ‚๏ธ

Currently only AC-3, DTS and TrueHD tracks are affected by this option.

  • --timestamps TID:file-name โ€” reads the timestamps for that specific track ID out of file-name. Heads up: these forcefully override the timestamps mkvmerge(1) would normally calculate. Go read the section about external timestamp files. โฑ๏ธ
  • --default-duration TID:x โ€” forces the default duration of a given track to the value you specify. It also modifies that track's timestamps to match the default duration. The argument x has to be postfixed with one of these:
    • 's' โ€” seconds
    • 'ms' โ€” milliseconds
    • 'us' โ€” microseconds
    • 'ns' โ€” nanoseconds
    • 'fps' โ€” frames per second
    • 'p' โ€” progressive frames per second
    • 'i' โ€” interlaced frames per second

And x itself can be a floating point number or a fraction. โœจ

If the default duration isn't forced, mkvmerge tries to derive the track's default duration from the container and/or the encoded bitstream for certain track types โ€” e.g. AVC/H.264 or MPEG-2.

Bonus: you can also use this to change the FPS of video tracks without needing an external timestamp file. Iconic behaviour honestly.

  • --fix-bitstream-timing-information TID[:0|1] โ€” normally mkvmerge(1) does not touch the timing information (frame/field rate) stored in the video bitstream. With this option that info gets adjusted to match the container timing information instead. Where does container timing info come from? Various places: the command line (see option --default-duration), the source container, or derived from the bitstream. ๐ŸŽ›๏ธ
Note โ€” so far this has only been implemented for AVC/H.264 video tracks. Don't come for me, it is what it is. ๐Ÿ™ˆ
  • --compression TID:n โ€” picks the compression method used for the track. Important vibe check: the player also has to support this method. Valid values are 'none', 'zlib' and 'mpeg4_p2'/'mpeg4p2'.

The 'mpeg4_p2'/'mpeg4p2' method is a special compression method called 'header removal', and it's only available for MPEG4 part 2 video tracks.

For some subtitle types the default is 'zlib' compression. That's also the method that most, if not all, playback applications support. Support for any compression method other than 'none' is not assured. ๐Ÿ˜ฌ


โœจ Options that only apply to video tracks โœจ

  • -f, --fourcc TID:FourCC โ€” forces the FourCC to the value you give. Works only for video tracks in the 'MS compatibility mode'. ๐ŸŽฌ
  • --display-dimensions TID:widthxheight โ€” Matroska(TM) files carry two values that set the display properties a player should scale the image to on playback: display width and display height. Set them with this option, like '1:640x480'. ๐Ÿ“

Another way to set these values is the --aspect-ratio or the --aspect-ratio-factor option (see below). These options are mutually exclusive โ€” pick one, bestie, not both.

  • --aspect-ratio TID:ratio|width/height โ€” same two values as above (display width + display height, the stuff a player scales to on playback), except here mkvmerge(1) calculates the display width and height for you, based on the image's original width and height plus the aspect ratio you give. The ratio can be a floating point number ratio or a fraction 'width/height', e.g. '16/9'. ๐ŸŒˆ

Another way to set these values is the --aspect-ratio-factor or --display-dimensions options (see above and below). Mutually exclusive, bestie. ๐Ÿ’…

  • --aspect-ratio-factor TID:factor|n/d โ€” yet another way to set the aspect ratio: specify a factor. The original aspect ratio gets multiplied by this factor first, and that result becomes the target aspect ratio afterwards. โž—

Another way to set these values is the --aspect-ratio or --display-dimensions options (see above). Mutually exclusive, obviously. ๐Ÿ™ƒ

  • --cropping TID:left,top,right,bottom โ€” sets the pixel cropping parameters of a video track to the given values. Snip snip. โœ‚๏ธ
  • --color-matrix-coefficients TID:n โ€” sets the matrix coefficients of the video, which are what you use to derive luma and chroma values from red, green and blue color primaries. The parameter n is an integer ranging from 0 and 10. ๐ŸŽจ

Valid values and their meaning:

  • 0 โ€” GBR
  • 1 โ€” BT709
  • 2 โ€” unspecified
  • 3 โ€” reserved
  • 4 โ€” FCC
  • 5 โ€” BT470BG
  • 6 โ€” SMPTE 170M
  • 7 โ€” SMPTE 240M
  • 8 โ€” YCOCG
  • 9 โ€” BT2020 non-constant luminance
  • 10 โ€” BT2020 constant luminance
  • --color-bits-per-channel TID:n โ€” sets the number of coded bits for a color channel. A value of 0 means the number of bits is unspecified. ๐Ÿ”ข
  • --chroma-subsample TID:hori,vert โ€” how many pixels to remove in the Cr and Cb channels for every pixel not removed horizontally/vertically.

Example: for video with 4:2:0 chroma subsampling, set the parameter to TID:1,1. ๐Ÿงช

  • --cb-subsample TID:hori,vert โ€” how many pixels to remove in the Cb channel for every pixel not removed horizontally/vertically. This one is additive with --chroma-subsample. โž•

Example: for video with 4:2:1 chroma subsampling, --chroma-subsample should be set to TID:1,0 and Cb-subsample should be set to TID:1,0.

  • --chroma-siting TID:hori,vert โ€” sets how chroma is sited horizontally/vertically: 0 = unspecified, 1 = top collocated, 2 = half. ๐Ÿ“
  • --color-range TID:n โ€” sets the clipping of the color ranges: 0 = unspecified, 1 = broadcast range, 2 = full range (no clipping), 3 = defined by MatrixCoefficients/TransferCharacteristics. โœ‚๏ธ
  • --color-transfer-characteristics TID:n โ€” the transfer characteristics of the video. ๐ŸŽž๏ธ

Valid values and their meaning:

  • 0 โ€” reserved
  • 1 โ€” ITU-R BT.709
  • 2 โ€” unspecified
  • 3 โ€” reserved
  • 4 โ€” gamma 2.2 curve
  • 5 โ€” gamma 2.8 curve
  • 6 โ€” SMPTE 170M
  • 7 โ€” SMPTE 240M
  • 8 โ€” linear
  • 9 โ€” log
  • 10 โ€” log sqrt
  • 11 โ€” IEC 61966-2-4
  • 12 โ€” ITU-R BT.1361 extended color gamut
  • 13 โ€” IEC 61966-2-1
  • 14 โ€” ITU-R BT.2020 10 bit
  • 15 โ€” ITU-R BT.2020 12 bit
  • 16 โ€” SMPTE ST 2084
  • 17 โ€” SMPTE ST 428-1
  • 18 โ€” ARIB STD-B67 (HLG)
  • --color-primaries TID:n โ€” sets the color primaries of the video. ๐ŸŒˆ

Valid values and their meaning:

  • 0 โ€” reserved
  • 1 โ€” ITU-R BT.709
  • 2 โ€” unspecified
  • 3 โ€” reserved
  • 4 โ€” ITU-R BT.470M
  • 5 โ€” ITU-R BT.470BG
  • 6 โ€” SMPTE 170M
  • 7 โ€” SMPTE 240M
  • 8 โ€” FILM
  • 9 โ€” ITU-R BT.2020
  • 10 โ€” SMPTE ST 428-1
  • 22 โ€” JEDEC P22 phosphors
  • --max-content-light TID:n โ€” sets the maximum brightness of a single pixel (Maximum Content Light Level) in candelas per square meter (cd/mยฒ). The value of n should be a non-negative integer. โ˜€๏ธ
  • --max-frame-light TID:n โ€” sets the maximum brightness of a single full frame (Maximum Frame-Average Light Level) in candelas per square meter (cd/mยฒ). The value of n should be a non-negative integer. ๐Ÿ”†
  • --chromaticity-coordinates TID:red-x,red-y,green-x,green-y,blue-x,blue-y โ€” sets the red/green/blue chromaticity coordinates, exactly like CIE 1931 defines them. ๐Ÿ’…
  • --white-color-coordinates TID:x,y โ€” sets the white color chromaticity coordinates, also as defined by CIE 1931. โœจ
  • --max-luminance TID:float โ€” sets the maximum luminance in candelas per square meter (cd/mยฒ). Heads up bestie: the value has to be less than 9999.99. ๐Ÿ“
  • --min-luminance TID:float โ€” sets the minimum luminance in candelas per square meter (cd/mยฒ). And this one has to be less than 999.9999. ๐ŸŒธ
  • --projection-type TID:method โ€” picks the video projection method. The valid values are literally:
    • 0 โ€” rectangular projection
    • 1 โ€” equirectangular projection
    • 2 โ€” cubemap projection
    • 3 โ€” mesh projection
  • --projection-private TID:data โ€” sets private data that only applies to one specific projection. The data has to be given as hex numbers, with or without the 0x prefix, and with or without spaces. ๐Ÿฆ‹
  • --projection-pose-yaw TID:float โ€” specifies a yaw rotation for the projection.
  • --projection-pose-pitch TID:float โ€” specifies a pitch rotation for the projection.
  • --projection-pose-roll TID:float โ€” specifies a roll rotation for the projection.
  • --field-order TID:n โ€” sets the field order for the video track with the track ID TID. The order has to be one of these numbers, no cap:
    • 0 โ€” progressive
    • 1 โ€” interlaced with top field displayed first and top field stored first
    • 2 โ€” undetermined field order
    • 6 โ€” interlaced with bottom field displayed first and bottom field stored first
    • 9 โ€” interlaced with bottom field displayed first and top field stored first
    • 14 โ€” interlaced with top field displayed first and bottom field stored first
  • --stereo-mode TID:n|symbolic-name โ€” sets the stereo mode for the video track with the track ID TID. The mode can be either a number n between 0 and 14, or a symbolic name. You can list every valid number & name with the --list-stereo-modes option. ๐Ÿ‘‘

โœจ Options that only apply to text subtitle tracks โœจ

  • --sub-charset TID:character-set โ€” sets the character set used for converting to UTF-8 for UTF-8 subtitles, for the track ID you give it. If you don't specify it, the charset gets derived from your current locale settings. Note that a charset isn't even needed for subtitles read from Matroska(TM) files or from Kate streams, because those are always stored in UTF-8. There's a whole section about text files and character sets that explains how mkvmerge(1) converts between character sets, so go read that if you're curious. ๐Ÿ“–

You can use this option multiple times for one input file, applying to several tracks, by selecting a different track ID each time.

๐ŸŒˆ Other options ๐ŸŒˆ

  • -i, --identify file-name โ€” makes mkvmerge(1) probe that single file and report its type, the tracks inside it, and their track IDs. If you use this option, the only other option allowed is the filename. Periodt.

You can change the output format with the --identification-format option.

  • -J file-name โ€” this is just a convenient alias for --identification-format json --identify file-name. โœจ
  • -F, --identification-format format โ€” decides the output format that the --identify option uses. These are the supported formats: text (the default when you don't use this option) and json.
    1. The text format is short and human-readable. It's one line per item found (container, tracks, attachments etc.).

This format is not meant to be parsed. The output gets translated into whatever language mkvmerge(1) is using (see also --ui-language).

  1. The json format outputs a machine-readable JSON representation. This format follows the JSON schema described in this file:

mkvmerge-identification-output-schema-v20.json[3]

All versions of the JSON schema are available both online and in the released source code archives.

  • --probe-range-percentage percentage โ€” file types like MPEG program and transport streams (.vob, .m2ts) need to parse a certain amount of data before they can detect all the tracks inside the file. That amount is 0.3% of the source file's size or 10 MB, whichever is higher.

If you know tracks are in there but they're not being found, you can change the percentage to probe with this option. The minimum of 10 MB is built-in and cannot be changed. ๐Ÿ™ˆ

  • --list-audio-emphasis โ€” lists every valid number & its matching symbolic name for the --audio-emphasis option.
  • --list-languages โ€” lists all languages and their ISO 639-2 code, which you can use with the --language option.
  • --list-stereo-modes โ€” lists every valid number & its matching symbolic name for the --stereo-mode option.
  • -l, --list-types โ€” lists the supported input file types. ๐Ÿ’œ
  • --priority priority โ€” sets the process priority that mkvmerge(1) runs with. Valid values are 'lowest', 'lower', 'normal', 'higher' and 'highest'. If you give nothing, 'normal' is used. On Unix-like systems mkvmerge(1) will use the nice(2) function โ€” which means only the super user can use 'higher' and 'highest'. On Windows, all values are usable for every user, no gatekeeping. ๐Ÿซถ

Selecting 'lowest' also makes mkvmerge(1) select idle I/O priority on top of the lowest possible process priority.

  • --command-line-charset character-set โ€” sets the character set used to convert strings given on the command line from. It defaults to the character set given by your system's current locale. This setting applies to the arguments of these options: --title, --track-name and --attachment-description.
  • --output-charset character-set โ€” sets the character set that strings are converted to when they're output. It defaults to the character set given by your system's current locale.
  • -r, --redirect-output file-name โ€” writes all messages to the file file-name instead of to the console. Yes, you could just do output redirection, but there are cases where this option is genuinely needed: when the terminal reinterprets the output before writing it to a file. The character set set with --output-charset is honored. ๐Ÿ’–
  • --no-bom โ€” normally, text files that are created & encoded in one of the UTF variants start with a byte order marker (BOM). This option disables writing that byte order marker. Bye BOM. ๐Ÿ‘‹
  • --flush-on-close โ€” tells the program to flush all data cached in memory to storage when closing files opened for writing. This can be used to prevent data loss on power outages, or to get around certain problems in the operating system or drivers. The downside is that multiplexing will take longer, because mkvmerge will wait until all data has been written to storage before exiting. Check out issues #2469 and #2480 on the MKVToolNix bug tracker if you want the in-depth discussion on the pros and cons. ๐Ÿ”ฅ
  • --ui-language code โ€” forces the translations for the language code to be used (so like 'de_DE' for the German translations). Entering 'list' as the code makes the program output a list of available translations.
  • --abort-on-warnings โ€” tells the program to abort after the very first warning is emitted. The program's exit code will be 1. ๐Ÿ’€
  • --deterministic seed โ€” enables the creation of byte-identical files, as long as you use the same version of mkvmerge(1) with the same source files, the same set of options and the same seed. Note that the "date" segment information field is not written in this mode.

The seed can be an arbitrary string and doesn't have to be a number.

The byte-identical result is only guaranteed under these conditions:

  1. The same version of mkvmerge(1) built with the same versions of libEBML and libMatroska is used.
  2. The source files used are byte-identical.
  3. The same command line options are used in the same order (with the notable exception of --output ...).

Using other versions of mkvmerge(1) or other command-line options may result in the same byte-identical file, but it's not guaranteed to do so.

  • --debug topic โ€” turns on debugging for a specific feature. This option is only useful for developers. ๐Ÿงš
  • --engage feature โ€” turns on experimental features. You can request a list of available features with mkvmerge --engage list. These features are not meant to be used in normal situations.
  • --gui-mode โ€” turns on GUI mode. In this mode, specially-formatted lines may be output that can tell a controlling GUI what's happening. These messages follow the format '#GUI#message'. The message may be followed by key/value pairs like '#GUI#message#key1=value1#key2=value2...'. Neither the messages nor the keys are ever translated, and they're always output in English. ๐ŸŒŸ
  • @options-file.json โ€” reads additional command line arguments from the file options-file. See the section about option files for more info.

If you want to use the @ sign as the first character in the argument to an option like '--title', you have to escape it with a second @ sign. Example:

$ mkvmerge -o midnight-s01e01.mkv --title @@midnight midnight-s01e01.mp4
  • --capabilities โ€” lists information about optional features that have been compiled in, then exits. The first line of output will be the version information. Every following line contains exactly one word, and if that word is present it means the feature has been compiled in. These features are:
    • 'FLAC' โ€” reading raw FLAC files and handling FLAC tracks in other containers, e.g. Ogg(TM) or Matroska(TM).
  • -h, --help โ€” show usage information and exit.
  • -V, --version โ€” show version information and exit.

๐Ÿ‘‘ USAGE ๐Ÿ‘‘

For each file, you the user get to select which tracks mkvmerge(1) should take. All of them get put into the file you specify with -o. And you can get a list of known (and supported) source formats with the -l option. Easy.

Important The order of command line options is important. Please read the section "Option order" if you're new to the program. ๐ŸŽ€

๐Ÿ’… OPTION ORDER ๐Ÿ’…

okay bestie so the order you type your options in? genuinely matters for some of them. not all, but some. here's the tea โ˜•

Options fall into two categories:

  1. Options that affect the whole program and are not tied to any input file. These include but are not limited to --command-line-charset, --output or --title. These can appear anywhere on the command line. no rules, main character energy โœจ
  2. Options that affect a single input file or a single track in an input file. These options all apply to the following input file on the command line. All options applying to the same input (or to tracks from the same input file) can be written in any order as long as they all appear before that input file's name. Examples for options applying to an input file are --no-chapters or --chapter-charset. Examples for options applying to a single track are --default-duration or --language.

The options are processed from left to right. If an option appears multiple times within the same scope then the last occurrence will be used. Therefore the title will be set to "Something else" in the following example:

$ mkvmerge -o output.mkv --title 'This and that' input.avi --title 'Something else'

The following example shows that using the --language option twice is OK because they're used in different scopes. Even though they apply to the same track ID they apply to different input files and therefore have different scopes:

$ mkvmerge -o output.mkv --language 0:fre franรงais.ogg --language 0:deu deutsch.ogg

๐ŸŒˆ EXAMPLES ๐ŸŒˆ

Let's assume you have a file called MyMovie.avi and the audio track in a separate file, e.g. 'MyMovie.wav'. First you want to encode the audio to OggVorbis(TM):

$ oggenc -q4 -oMyMovie.ogg MyMovie.wav

After a couple of minutes you can join video and audio:

$ mkvmerge -o MyMovie-with-sound.mkv MyMovie.avi MyMovie.ogg

If your AVI already contains an audio track then it will be copied as well (if mkvmerge(1) supports the audio format). To avoid that simply do

$ mkvmerge -o MyMovie-with-sound.mkv -A MyMovie.avi MyMovie.ogg

After some minutes of consideration you rip another audio track, e.g. the director's comments or another language to 'MyMovie-add-audio.wav'. Encode it again and join it up with the other file:

$ oggenc -q4 -oMyMovie-add-audio.ogg MyMovie-add-audio.wav
$ mkvmerge -o MM-complete.mkv MyMovie-with-sound.mkv MyMovie-add-audio.ogg

The same result can be achieved with

$ mkvmerge -o MM-complete.mkv -A MyMovie.avi MyMovie.ogg MyMovie-add-audio.ogg

Now fire up mplayer(TM) and enjoy ๐ŸŽฌโœจ If you have multiple audio tracks (or even video tracks) then you can tell mplayer(TM) which track to play with the -vid and -aid options. These are 0-based and do not distinguish between video and audio. iykyk ๐Ÿ‘‘

If you need an audio track synchronized you can do that easily. First find out which track ID the Vorbis track has with

$ mkvmerge --identify outofsync.ogg

Now you can use that ID in the following command line:

$ mkvmerge -o goodsync.mkv -A source.avi -y 12345:200 outofsync.ogg

This would add 200ms of silence at the beginning of the audio track with the ID 12345 taken from 'outofsync.ogg'.

Some movies start synced correctly but slowly drift out of sync. For these kind of movies you can specify a delay factor that is applied to all timestamps โ€” no data is added or removed. So if you make that factor too big or too small you'll get bad results ๐Ÿ˜ญ An example is that an episode I transcoded was 0.2 seconds out of sync at the end of the movie which was 77340 frames long. At 29.97fps 0.2 seconds correspond to approx. 6 frames. So I did

$ mkvmerge -o goodsync.mkv -y 23456:0,77346/77340 outofsync.mkv

The result was fine. ๐Ÿ’…

The sync options can also be used for subtitles in the same manner.

For text subtitles you can either use some Windows software (like SubRipper(TM)) or the subrip(TM) package found in transcode(1)'s sources in the 'contrib/subrip' directory. The general process is:

  1. extract a raw subtitle stream from the source:
$ tccat -i /path/to/copied/dvd/ -T 1 -L | tcextract -x ps1 -t vob -a 0x20 | subtitle2pgm -o mymovie
  1. convert the resulting PGM images to text with gocr:
$ pgm2txt mymovie
  1. spell-check the resulting text files:
$ ispell -d american *txt
  1. convert the text files to a SRT file:
$ srttool -s -w -i mymovie.srtx -o mymovie.srt

The resulting file can be used as another input file for mkvmerge(1):

$ mkvmerge -o mymovie.mkv mymovie.avi mymovie.srt

If you want to specify the language for a given track then this is easily done. First find out the ISO 639-2 code for your language. mkvmerge(1) can list all of those codes for you:

$ mkvmerge --list-languages

Search the list for the languages you need ๐Ÿ” Let's assume you have put two audio tracks into a Matroska(TM) file and want to set their language codes and that their track IDs are 2 and 3. This can be done with

$ mkvmerge -o with-lang-codes.mkv --language 2:ger --language 3:dut without-lang-codes.mkv

As you can see you can use the --language switch multiple times. slay โœจ

Maybe you'd also like to have the player use the Dutch language as the default language. You also have extra subtitles, e.g. in English and French, and want to have the player display the French ones by default. This can be done with

$ mkvmerge -o with-lang-codes.mkv --language 2:ger --language 3:dut --default-track-flag 3 without-lang-codes.mkv --language 0:eng english.srt --default-track-flag 0 --language 0:fre french.srt

If you do not see the language or default track flags that you've specified in mkvinfo(1)'s output then please read the section about default values. ๐Ÿซถ

Turn off the compression for an input file.

$ mkvmerge -o no-compression.mkv --compression -1:none MyMovie.avi --compression -1:none mymovie.srt

๐Ÿ‘‘ TRACK IDS ๐Ÿ‘‘

โœจ Regular track IDs โœจ

Some of the options for mkvmerge(1) need a track ID to specify which track they should be applied to. Those track IDs are printed by the readers when demuxing the current input file, or if mkvmerge(1) is called with the --identify option. An example for such output:

$ mkvmerge -i v.mkv
File 'v.mkv': container: Matroska(TM)
Track ID 0: video (V_MS/VFW/FOURCC, DIV3)
Track ID 1: audio (A_MPEG/L3)
Do not confuse the track IDs that are assigned to the tracks that are placed in the output MKV file with the track IDs of the input files. Only the input file track IDs are used for options needing these values. ๐Ÿ’€

Also note that each input file has its own set of track IDs. Therefore the track IDs for file 'file1.ext' as reported by 'mkvmerge --identify' do not change no matter how many other input files are there or in which position 'file1.ext' is used.

Track IDs are assigned like this:

  • AVI files: The video track has the ID 0. The audio tracks get IDs in ascending order starting at 1.
  • AAC, AC-3, MP3, SRT and WAV files: The one 'track' in that file gets the ID 0.
  • Most other files: The track IDs are assigned in order the tracks are found in the file starting at 0.

The options that use the track IDs are the ones whose description contains 'TID'. The following options use track IDs as well: --audio-tracks, --video-tracks, --subtitle-tracks, --button-tracks and --track-tags.

๐Ÿฆ‹ Special track IDs ๐Ÿฆ‹

There are several IDs that have special meaning and do not occur in the identification output. sneaky ones ๐Ÿ™ˆ

The special track ID -1 is a wild card and applies the given switch to all tracks that are read from an input file.

The special track ID -2 refers to the chapters in a source file. Currently only the --sync option uses this special ID. As an alternative to --sync -2:... the option --chapter-sync ... can be used.


๐Ÿ’– LANGUAGE HANDLING ๐Ÿ’–

Matroska(TM) has support for two different types of language elements: the old, deprecated "Language" element containing ISO 639-2 alpha 3 codes and the new "LanguageIETF" tags containing IETF BCP 47 language tags. All of mkvmerge(1)'s options that accept a language accept a BCP 47 language tag. mkvmerge(1) will derive the value for the deprecated "Language" element from the BCP 47 language tags wherever possible.

When identifying a file in JSON mode, existing "LanguageIETF" track header elements will be output as the language_ietf track property.

When writing a file mkvmerge(1) will always write the "LanguageIETF", "ChapLanguageIETF" and "TagLanguageIETF" elements (the latter two only if chapters or tags are written respectively). In addition to those elements the corresponding old elements will be written; they'll be set to the ISO 639-2 code portion of the BCP 47 language tag. For example, when the track language is set to sr-Cyrl-RS "LanguageIETF" will be set to sr-Cyrl-RS and the old "Language" element will be set to srp. no cap, that's the mapping ๐Ÿ’…

When reading existing files (Matroska files, XML chapter or tag files etc.) that already contain "...LanguageIETF" elements the existing elements will be kept. Otherwise "...LanguageIETF" elements will be added based on command-line options and other existing deprecated "...Language" elements.

The creation of the new elements can be disabled completely with the command-line option --disable-language-ietf which operates on all three new elements.

You can chose the normalization method applied to extended language sub-tags with the parameter --normalize-language-ietf. ๐ŸŒธ

โœจ TEXT FILES AND CHARACTER SET CONVERSIONS โœจ

okay bestie listen UP because this is one of those notes that actually matters: everything in this section applies to all programs in MKVToolNix, even when it's only shouting out mkvmerge(1) by name. iykyk ๐Ÿ’…

๐ŸŒธ Introduction

So here's the tea: every single bit of text inside a Matroska(TM) file is encoded in UTF-8. Which means mkvmerge(1) has to convert every text file it reads โ€” plus every text string you throw at it on the command line โ€” from whatever character set it's in, into UTF-8. and then, because life is a cycle, mkvmerge(1)'s output has to get converted right back from UTF-8 into that character set. that's the case when you're using a non-English translation with --ui-language, or for text that originally came out of a Matroska(TM) file. ๐Ÿฆ‹

and it does all of this automatically, no cap โ€” based on whether there's a byte order marker (BOM for short) hanging out at the front, or based on the system's current locale. now, how the character set gets inferred from the locale? that depends entirely on which operating system you're running mkvmerge(1) on. different vibes, different rules. ๐ŸŽ€


๐Ÿ’– Byte order markers (BOM)

if a text file starts with a BOM, it's already encoded in one representation of UTF. mkvmerge(1) supports these five modes, periodt:

  • UTF-8
  • UTF-16 Little Endian
  • UTF-16 Big Endian
  • UTF-32 Little Endian
  • UTF-32 Big Endian

text files that have a BOM get converted to UTF-8 automatically, no questions asked. and any parameter that would otherwise set the character set for that file โ€” like --sub-charset, for example โ€” gets silently ignored. literally just not even acknowledged. ๐Ÿ™ˆ


๐Ÿงš Linux and Unix-like systems including macOS

on Unix-like systems, mkvmerge(1) calls the setlocale(3) system call, which in turn reads the environment variables LANG, LC_ALL and LC_CTYPE. the resulting character set is usually something in the UTF-8 or ISO-8859-* family, and it gets used for all text file operations, for encoding strings on the command line, and for output to the console. one charset to rule them all. โœจ


๐ŸŽ€ Windows

on Windows, the default character set used for converting text files comes from a call to the GetACP() system call. that's the vibe check right there.

reading the command line happens via the GetCommandLineW() function, which already hands back a Unicode string. so because of that, the option --command-line-charset is ignored on Windows. nothing you can do about it, bestie.

output to the console is a whole three-scenario situation:

  1. if the output gets redirected with the option --redirect-output, then the default charset is UTF-8. you can change it with --output-charset. ๐Ÿ’œ
  2. if the output gets redirected by cmd.exe itself โ€” like mkvinfo file.mkv > info.txt โ€” then the charset is always UTF-8 and there is no changing it. periodt.
  3. otherwise (meaning you're writing straight to the console), the Windows function WriteConsoleW() is used, and the option --output-charset is ignored. the console should be able to output every Unicode character that has its corresponding language support installed. like, Chinese characters might not show up on English Windows versions. that's a them problem. ๐Ÿ˜ญ

๐Ÿ‘‘ Command line options

here are the options that let you specify character sets, all together, all slaying:

  • --sub-charset โ€” for text subtitle files, and for text subtitle tracks stored inside container formats where the character set can't be determined unambiguously (Ogg files, for instance).
  • --chapter-charset โ€” for chapter text files, and for chapters plus file titles stored in container formats where the character set can't be determined unambiguously. that means Ogg files for chapter information, track titles, file titles, etc; and MP4 files for chapter information.
  • --command-line-charset โ€” for all the strings on the command line.
  • --output-charset โ€” for all strings written to the console, or to a file if the output has been redirected with the --redirect-output option. on non-Windows systems the default for the output charset is the system's current charset. on Windows it defaults to UTF-8 both for redirecting with --redirect-output and for redirecting with cmd.exe itself โ€” like mkvinfo file.mkv > info.txt.

๐Ÿ“ OPTION FILES ๐Ÿ“

an option file is a file that mkvmerge(1) can read extra command line arguments out of. why would you want that? to dodge certain limitations of the shell or the operating system when it runs external programs โ€” like a command line that's only allowed to be a certain length. the option file is your escape hatch. ๐Ÿ’…

an option file holds JSON-formatted data. its content has to be a valid JSON array made up solely of JSON strings. the file's encoding must be UTF-8. the file shouldn't start with a byte order marker (BOM), but if one is there anyway, it gets skipped. no drama.

the rules for escaping special characters inside JSON are the ones from the official JSON specification, RFC 7159[4].

and the option file's name itself has to be given as a command line argument with a @ character slapped on the front.

so this command line:

mkvmerge -o "my file.mkv" -A "a movie.avi" sound.ogg

could be converted into this JSON option file, called something like options.json:

[
  "-o",
  "c:\\Matroska\\my file.mkv",
  "--title",
  "#65",
  "-A",
  "a movie.avi",
  "sound.ogg"
]

and the corresponding command would then just be:

mkvmerge @options.json

obsessed with the efficiency honestly. ๐Ÿซถ


๐Ÿ’€ FILE LINKING ๐Ÿ’€

Matroska(TM) supports file linking, which basically just says that one specific file is the predecessor or the successor of the current file. but to be precise โ€” and bestie, we ARE being precise โ€” it's not actually the files being linked, it's the Matroska(TM) segments. and since most files will probably only ever contain one Matroska(TM) segment, the following explanation keeps saying "file linking" even though "segment linking" would technically be the more correct term. we're keeping it casual. ๐Ÿงš

every segment is identified by a unique 128 bit wide segment UID. this UID gets generated automatically by mkvmerge(1). the linking happens primarily by putting the segment UIDs (SID for short) of the previous/next file into the segment header information. mkvinfo(1) prints these SIDs if it finds them. ๐Ÿ”ฅ

if a file gets split into several smaller ones and linking is used, then the timestamps won't start at 0 again โ€” they'll keep going from where the last file left off. this keeps the absolute time intact even if the previous files aren't available (like when you're streaming). if no linking is used, then the timestamps should start at 0 for each file. and by default, mkvmerge(1) does not use file linking. want it? turn it on with the --link option. heads up though: this option is only useful if splitting is activated too.

regardless of whether splitting is active or not, you can tell mkvmerge(1) to link the produced files to specific SIDs. that's what --link-to-previous and --link-to-next are for. these options accept a segment SID in the exact format that mkvinfo(1) outputs: 16 hexadecimal numbers between 0x00 and 0xff, each prefixed with 0x, like this:

0x41 0xda 0x73 0x66 0xd9 0xcf 0xb2 0x1e 0xae 0x78 0xeb 0xb4 0x5e 0xca 0xb3 0x93

alternatively you can use the shorter form: 16 hexadecimal numbers between 0x00 and 0xff with no 0x prefixes and no spaces, like this:

41da7366d9cfb21eae78ebb45ecab393

if splitting is used, then the first file gets linked to the SID given with --link-to-previous, and the last file gets linked to the SID given with --link-to-next. if splitting is not used, then the one single output file gets linked to both of those two SIDs. lucky file. ๐Ÿ‘‘


๐ŸŒˆ DEFAULT VALUES ๐ŸŒˆ

the Matroska(TM) specification says that some elements have a default value. and usually, an element doesn't get written to the file at all if its value equals its default value โ€” because why waste space, right? slay. โœจ

the elements you might notice going missing from mkvinfo(1)'s output are the language element and the default track flag element. the default value for the language is English (eng), and the default value for the default track flag is true.

so if you used --language 0:eng for a track, it just... won't show up in mkvinfo(1)'s output. it's not broken, bestie, it's just the default. ๐Ÿ˜ญ


๐Ÿ’– ATTACHMENTS ๐Ÿ’–

maybe you want to keep some photos alongside your Matroska(TM) file. or maybe you're using SSA subtitles and you need a special TrueType(TM) font that is genuinely, unbelievably rare. in those cases, you can attach those files to the Matroska(TM) file. and no, they don't just get appended to the file โ€” they get embedded in it. a player can then show those files (the 'photos' case) or use them to render the subtitles (the 'TrueType(TM) fonts' case). main character energy for your fonts. ๐Ÿ’…

here's an example of how to attach a photo and a TrueType(TM) font to the output file:

$ mkvmerge -o output.mkv -A video.avi sound.ogg \
  --attachment-description "Me and the band behind the stage in a small get-together" \
  --attachment-mime-type image/jpeg \
  --attach-file me_and_the_band.jpg \
  --attachment-description "The real rare and unbelievably good looking font" \
  --attachment-mime-type application/octet-stream \
  --attach-file really_cool_font.ttf

if a Matroska(TM) file containing attachments is used as an input file, then mkvmerge(1) will copy the attachments into the new file. and if you want to change which attachments get copied and which ones don't? that's what the options --attachments and --no-attachments are for. ๐Ÿฆ‹

โœจ CHAPTERS โœจ

okay bestie, buckle UP, because the Matroska(TM) chapter system is so much more powerful than that crusty old system OGM files used ๐Ÿ’…. The full specs live at the Matroska(TM) website[1] if you wanna go read the whole thing.

mkvmerge(1) accepts two kinds of chapter files as input:

  • the first one is called the 'simple chapter format', and it's literally the same format the OGM tools expect ๐Ÿฅฐ
  • the second one is an XML based chapter format that supports all of Matroska(TM)'s chapter functionality โœจ

And like, apart from dedicated chapter files, mkvmerge(1) can also pull chapters straight out of other file formats (e.g. MP4, Ogg, Blu-rays or DVDs). versatile queen ๐Ÿ‘‘


๐ŸŽ€ The simple chapter format

this format is just pairs of lines that start with 'CHAPTERxx=' and 'CHAPTERxxNAME=' respectively. The first line of the pair holds the start timestamp, the second one holds the title. Here's the vibe:

CHAPTER01=00:00:00.000
CHAPTER01NAME=Intro
CHAPTER02=00:02:30.000
CHAPTER02NAME=Baby prepares to rock
CHAPTER03=00:02:42.300
CHAPTER03NAME=Baby rocks the house

mkvmerge(1) turns every pair of lines into one Matroska(TM) ChapterAtom. It does not set any ChapterTrackNumber, which means all chapters apply to all tracks in the file. everyone's included, no gatekeeping ๐Ÿซถ

Since this is a text file, character set conversion may need to happen. See the section about text files and character sets for the whole explanation of how mkvmerge(1) converts between character sets.

๐ŸŒˆ The XML based chapter format

the XML based chapter format looks like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Chapters SYSTEM "matroskachapters.dtd">
<Chapters>
  <EditionEntry>
    <ChapterAtom>
      <ChapterTimeStart>00:00:30.000</ChapterTimeStart>
      <ChapterTimeEnd>00:01:20.000</ChapterTimeEnd>
      <ChapterDisplay>
        <ChapterString>A short chapter</ChapterString>
        <ChapterLanguage>eng</ChapterLanguage>
      </ChapterDisplay>
      <ChapterAtom>
        <ChapterTimeStart>00:00:46.000</ChapterTimeStart>
        <ChapterTimeEnd>00:01:10.000</ChapterTimeEnd>
        <ChapterDisplay>
          <ChapterString>A part of that short chapter</ChapterString>
          <ChapterLanguage>eng</ChapterLanguage>
        </ChapterDisplay>
      </ChapterAtom>
    </ChapterAtom>
  </EditionEntry>
</Chapters>

With this format, three things are possible that the simple chapter format simply cannot do, no cap:

  1. The timestamp for the end of the chapter can be set.
  2. Chapters can be nested. ๐Ÿช†
  3. The language and country can be set.

The mkvtoolnix distribution contains some sample files in the doc subdirectory which you can use as a basis. free starter pack, we love to see it ๐Ÿ’–

The following lists the supported XML tags, their data types and, where appropriate, the valid range for their values:

Chapters (master)
  EditionEntry (master)
    EditionUID (unsigned integer, valid range: 1 <= value)
    EditionFlagHidden (unsigned integer, valid range: 0 <= value <= 1)
    EditionFlagDefault (unsigned integer, valid range: 0 <= value <= 1)
    EditionFlagOrdered (unsigned integer, valid range: 0 <= value <= 1)
    ChapterAtom (master)
      ChapterAtom (master)
      ChapterUID (unsigned integer, valid range: 1 <= value)
      ChapterTimeStart (unsigned integer)
      ChapterTimeEnd (unsigned integer)
      ChapterFlagHidden (unsigned integer, valid range: 0 <= value <= 1)
      ChapterFlagEnabled (unsigned integer, valid range: 0 <= value <= 1)
      ChapterSegmentUID (binary, valid range: 1 <= length in bytes)
      ChapterSegmentEditionUID (unsigned integer, valid range: 1 <= value)
      ChapterPhysicalEquiv (unsigned integer)
      ChapterTrack (master)
        ChapterTrackNumber (unsigned integer, valid range: 1 <= value)
      ChapterDisplay (master)
        ChapterString (UTF-8 string)
        ChapterLanguage (UTF-8 string)
        ChapterCountry (UTF-8 string)
      ChapterProcess (master)
        ChapterProcessCodecID (unsigned integer)
        ChapterProcessPrivate (binary)
        ChapterProcessCommand (master)
          ChapterProcessTime (unsigned integer)
          ChapterProcessData (binary)

๐Ÿ’™ Reading chapters from Blu-rays

mkvmerge(1) can read chapters from unencrypted Blu-rays ๐Ÿ‘€. For that you just hand it the path to one of the MPLS play lists using the --chapters parameter.

Example: --chapters /srv/blurays/BigBuckBunny/BDMV/PLAYLIST/00001.mpls

๐Ÿ’œ Reading chapters from DVDs

When MKVToolNix is compiled with the libdvdread(TM) library, mkvmerge(1) can read chapters from DVDs too. For that you use the path to one of the folders or files on the DVD with the --chapters parameter. Now, DVDs can contain more than one title, and each title has its own set of chapters, so you can append a colon and the title number you want to the end of the file name argument. The title number defaults to 1.

Example: --chapters /srv/dvds/BigBuckBunny/VIDEO_TS:2

๐ŸŒธ General notes

When splitting files, mkvmerge(1) will correctly adjust the chapters as well ๐Ÿซก. What that means: each file only includes the chapter entries that apply to it, and the timestamps get offset to match the new timestamps of each output file.

mkvmerge(1) is able to copy chapters from Matroska(TM) source files unless this is explicitly disabled with the --no-chapters option. The chapters from all sources (Matroska(TM) files, Ogg files, MP4 files, chapter text files) are usually not merged but end up in separate ChapterEditions. Only if chapters are read from several Matroska(TM) or XML files that share the same edition UIDs will chapters be merged into a single ChapterEdition. And if you want that kind of merge in other situations too, then you have to extract the chapters from all sources with mkvextract(1) first, merge the XML files manually, and mux them afterwards. DIY era ๐Ÿ˜ญ


๐Ÿท๏ธ TAGS โœจ

Introduction

Matroska(TM)'s tag system is similar to that of other containers: a set of KEY=VALUE pairs. BUT (and this is the twist) in Matroska(TM) these tags can also be nested, and both the KEY and the VALUE are elements of their own. The example file example-tags-2.xml shows how to use this whole system. it's giving structure, it's giving hierarchy ๐Ÿ’…

Scope of the tags

Matroska(TM) tags do not automatically apply to the complete file. They can do that, sure, but they may also apply to different parts of the file: to one or more tracks, to one or more chapters, or even to a combination of both. The Matroska(TM) specification[5] gives more details about this fact.

One important fact bestie: tags are linked to tracks or chapters with the Targets Matroska(TM) tag element, and the UIDs used for this linking are not the track IDs mkvmerge(1) uses everywhere. Instead the numbers used are the UIDs which mkvmerge(1) calculates automatically (if the track is taken from a file format other than Matroska(TM)) or which are copied from the source file if the track's source file is a Matroska(TM) file. So yeah, it's genuinely difficult to know which UIDs to use in the tag file before the file is handed over to mkvmerge(1). annoying? yes. iconic? also yes ๐Ÿ™ˆ

mkvmerge(1) knows two options with which you can add tags to Matroska(TM) files: the --global-tags and the --tags options. The difference is that the former option, --global-tags, will make the tags apply to the complete file by removing any of those Targets elements mentioned above. The latter option, --tags, automatically inserts the UID that mkvmerge(1) generates for the tag specified with the TID part of the --tags option.

Example

Let's say that you want to add tags to a video track read from an AVI. mkvmerge --identify file.avi tells you that the video track's ID (do not mix this ID with the UID!) is 0. So you create your tag file, leave out all Targets elements, and call mkvmerge(1):

$ mkvmerge -o file.mkv --tags 0:tags.xml file.avi

๐Ÿ“„ Tag file format

mkvmerge(1) supports a XML based tag file format. The format is very closely modeled after the Matroska(TM) specification[5]. Both the binary and the source distributions of MKVToolNix come with a sample file called example-tags-2.xml which simply lists all known tags and which you can use as a basis for your real life tag files. starter template, slay ๐ŸŽ€

The basics are:

  • The outermost element must be <Tags>.
  • One logical tag is contained inside one pair of <Tag> XML tags.
  • White spaces directly before and after tag contents are ignored.

๐Ÿงฌ Data types

The new Matroska(TM) tagging system only knows two data types: a UTF-8 string and a binary type. The first one is used for the tag's name and the <String> element, while the binary type is used for the <Binary> element.

Now, binary data itself would not fit into a XML file, so mkvmerge(1) supports two other methods of storing binary data:

  • If the contents of a XML tag starts with '@' then the following text is treated as a file name. The corresponding file's content is copied into the Matroska(TM) element. ๐Ÿ“Ž
  • Otherwise the data is expected to be Base64 encoded. This is an encoding that transforms binary data into a limited set of ASCII characters and is used e.g. in email programs. mkvextract(1) will output Base64 encoded data for binary elements.
the deprecated tagging system knows some more data types, which can be found in the official Matroska(TM) tag specs. But mkvmerge(1) does not support this system anymore, so those types aren't described here. rip to the old ways ๐Ÿ’€

๐Ÿ‘‘ Known tags for the XML file format

The following lists the supported XML tags, their data types and, where appropriate, the valid range for their values:

Tags (master)
  Tag (master)
    Targets (master)
      TargetTypeValue (unsigned integer)
      TargetType (UTF-8 string)
      TrackUID (unsigned integer)
      EditionUID (unsigned integer)
      ChapterUID (unsigned integer)
      AttachmentUID (unsigned integer)
    Simple (master)
      Simple (master)
      Name (UTF-8 string)
      TagLanguage (UTF-8 string)
      DefaultLanguage (unsigned integer)
      String (UTF-8 string)
      Binary (binary)

๐ŸŽฌ SEGMENT INFORMATION ๐ŸŽฌ

okay so if you hand mkvmerge a segment info XML file, you can set some very specific values in the "segment information" header field of a Matroska(TM) file ๐Ÿ’… and literally none of these can be set any other way. No flags, no nothing. XML only, bestie.

Now โ€” some other "segment information" header fields can be set from the command line, but not from the XML file. Like --title and --timestamp-scale, for example. So it's giving "two separate doors, neither one opens everything" ๐Ÿ˜ญ

And then there's a third category of elements that can be set neither via command line options nor via the XML files. Those are:

  • DateUTC (also known as the "muxing date")
  • MuxingApp
  • WritingApp
  • Duration

These four are always set by mkvmerge(1) itself, no input from you, periodt. โœจ

Here's the full list of supported XML tags, their data types, and โ€” where it matters โ€” the valid range for their values:

Info (master)
  SegmentUID (binary, valid range: length in bytes == 16)
  SegmentFilename (UTF-8 string)
  PreviousSegmentUID (binary, valid range: length in bytes == 16)
  PreviousSegmentFilename (UTF-8 string)
  NextSegmentUID (binary, valid range: length in bytes == 16)
  NextSegmentFilename (UTF-8 string)
  SegmentFamily (binary, valid range: length in bytes == 16)
  ChapterTranslate (master)
    ChapterTranslateEditionUID (unsigned integer)
    ChapterTranslateCodec (unsigned integer)
    ChapterTranslateID (binary)

๐ŸŒˆ MATROSKA(TM) FILE LAYOUT ๐ŸŒˆ

The Matroska(TM) file layout is super flexible, but mkvmerge(1) is gonna render your file in one predefined way. The resulting file looks like this:

[EBML head] [segment {meta seek #1} [segment information] [track
information] {attachments} {chapters} [cluster 1] {cluster 2} ...
{cluster n} {cues} {meta seek #2} {tags}]

The stuff in curly braces? That's optional, and whether it shows up depends on the contents and the options you used ๐Ÿซถ

A couple of notes, because there's lore here:

  • meta seek #1 includes only a small number of level 1 elements, and only if they actually exist: attachments, chapters, cues, tags, meta seek #2. Older versions of mkvmerge(1) used to put the clusters into this meta seek element as well. So some imprecise guessing was necessary to reserve enough space. It often failed. ๐Ÿ’€ Now only the clusters are stored in meta seek #2, and meta seek #1 refers to the meta seek element #2.
  • Attachment, chapter and tag elements are only present if they were added. No add, no element, simple as that.

The shortest possible Matroska(TM) file would look like this:

[EBML head] [segment [segment information] [track information] [cluster
1]]

Which might be the case for audio-only files ๐Ÿ‘‘ cute, minimal, iconic.


โฑ๏ธ EXTERNAL TIMESTAMP FILES โฑ๏ธ

mkvmerge(1) lets you, yes you, choose the timestamps for a specific track yourself. This is how you make files with variable frame rate video, or sneak gaps into audio ๐Ÿฆ‹

A frame in this context is the unit that mkvmerge(1) creates separately per Matroska(TM) block. For video that's exactly one frame. For audio it's one packet of that specific audio type โ€” e.g. for AC-3 this would be a packet containing 1536 samples.

Timestamp files used when tracks are appended to each other must only be specified for the first part in a chain of tracks. So if you append two files, v1.avi and v2.avi, and you want to use timestamps, your command line must look something like this:

$ mkvmerge ... --timestamps 0:my_timestamps.txt v1.avi +v2.avi

There are four formats mkvmerge(1) recognizes. The first line always contains the version number. Empty lines, lines containing only whitespace, and lines beginning with # are ignored ๐Ÿ™ˆ

๐Ÿ“ผ Timestamp file format v1

This format starts with the version line. The second line declares the default number of frames per second. All following lines contain three numbers separated by commas: the start frame (0 is the first frame), the end frame and the number of frames in this range. The FPS is a floating point number with the dot . as the decimal point. The ranges can contain gaps for which the default FPS is used. An example:

# timestamp format v1
assume 27.930
800,1000,25
1500,1700,30

๐Ÿ“ผ Timestamp file format v2

In this format each line contains a timestamp for the corresponding frame. This timestamp must be given in millisecond precision. It can be a floating point number, but it doesn't have to be. You have to give at least as many timestamp lines as there are frames in the track. The timestamps in this file must be sorted. Example for 25fps:

# timestamp format v2
0
40
80

๐Ÿ“ผ Timestamp file format v3

In this format each line contains a duration in seconds followed by an optional number of frames per second. Both can be floating point numbers. If the number of frames per second is not present the default one is used. For audio you should let the codec calculate the frame timestamps itself โ€” for that you should be using 0.0 as the number of frames per second. You can also create gaps in the stream by using the 'gap' keyword followed by the duration of the gap. Example for an audio file:

# timestamp format v3
assume 0.0
25.325
7.530,38.236
gap, 10.050
2.000,38.236

๐Ÿ“ผ Timestamp file format v4

This format is identical to the v2 format. The only difference is that the timestamps do not have to be sorted. This format should almost never be used ๐Ÿšฉ like genuinely, why would you.


๐Ÿšช EXIT CODES ๐Ÿšช

mkvmerge(1) exits with one of three exit codes:

  1. 0 โ€” This exit code means that muxing has completed successfully. ๐ŸŽ‰ slay.
  2. 1 โ€” In this case mkvmerge(1) has output at least one warning, but muxing did continue. A warning is prefixed with the text 'Warning:'. Depending on the issues involved the resulting file might be ok or not. The user is urged to check both the warning and the resulting file. ๐Ÿ‘€
  3. 2 โ€” This exit code is used after an error occurred. mkvmerge(1) aborts right after outputting the error message. Error messages range from wrong command line arguments over read/write errors to broken files. ๐Ÿ˜ญ

๐ŸŒ ENVIRONMENT VARIABLES ๐ŸŒ

mkvmerge(1) uses the default variables that determine the system's locale (e.g. LANG and the LC_* family). Plus these extra ones:

  • MKVMERGE_DEBUG, MKVTOOLNIX_DEBUG and its short form MTX_DEBUG โ€” The content is treated as if it had been passed via the --debug option.
  • MKVMERGE_ENGAGE, MKVTOOLNIX_ENGAGE and its short form MTX_ENGAGE โ€” The content is treated as if it had been passed via the --engage option.

๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

mkvinfo(1), mkvextract(1), mkvpropedit(1), mkvtoolnix-gui(1)


๐ŸŒ WWW ๐ŸŒ

The latest version can always be found at the MKVToolNix homepage ๐Ÿ’–


๐Ÿ‘‘ AUTHOR ๐Ÿ‘‘

Moritz Bunkus <moritz@bunkus.org>

  • Developer

๐Ÿ“ NOTES ๐Ÿ“

  1. the Matroska(TM) website https://www.matroska.org/
  2. the IANA homepage https://www.iana.org/assignments/media-types/
  3. mkvmerge-identification-output-schema-v20.json https://mkvtoolnix.download/doc/mkvmerge-identification-output-schema-v20.json
  4. RFC 7159 https://tools.ietf.org/html/rfc7159
  5. Matroska(TM) specification https://www.matroska.org/technical/specs/index.html
  6. the MKVToolNix homepage https://mkvtoolnix.download/

and that's a wrap on the whole page, bestie ๐ŸŽ€ this version is MKVToolNix 102.0, dated 2026-09-14 โ€” go forth and mux responsibly ๐Ÿ’…โœจ

๐Ÿ“ฆ where this page comes from