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".
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.
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.
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 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 '+').
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.
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 '' will be replaced by the chapter number. The string '' will be replaced by the chapter's start timestamp.
The strings '' and '' 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.
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.
This option changes the order in which the tracks for an input file are created. The argument is a comma separated list of pairs IDs. 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.
Normally mkvmerge(1) will use a value of 1000000 which means that timestamps and durations will have a precision of 1ms. For files that will not contain a video track but at least one audio track mkvmerge(1) will automatically chose a timestamp scale factor so that all timestamps and durations have a precision of one audio sample. This causes bigger overhead but allows precise seeking and extraction.
Tells mkvmerge(1) not to create and write the cue data which can be compared to an index in an AVI. Matroska(tm) files can be played back without the cue data, but seeking will probably be imprecise and slower. Use this only if you're really desperate for space or for testing purposes. See also option --cues which can be specified for each input file.
Normally mkvmerge(1) will write certain tags with statistics for each track. If such tags are already present then they will be overwritten. The tags are BPS, DURATION, NUMBER_OF_BYTES and NUMBER_OF_FRAMES.
Normally mkvmerge(1) will write the new IETF BCP 47 language elements in addition to the legacy language elements in track headers, chapters and tags. If this option is used, only the legacy elements are written.
Enables normalizing all IETF BCP 47 language tags to either their canonical form with mode 'canonical', 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.
For the extended language subtags form the canonical form is built first. Afterwards all primary languages for which an extended language subtag exists are replaced by that extended language subtag and its prefix. This converts e.g. 'yue-jyutping' back to 'zh-yue-jyutping' but has no effect on 'fr-FR' as 'fr' is not an extended language subtag.
Splits the output file after a given size or a given time. Please note that tracks can only be split right before a key frame. Therefore the split point may be a bit off from what the user has specified.
The parameter d may end with 'k', 'm' or 'g' to indicate that the size is in KB, MB or GB respectively. Otherwise a size in bytes is assumed. After the current output file has reached this size limit a new one will be started.
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. After the duration of the contents in the current output has reached this limit a new output file will be started.
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. After 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 parts mode tells mkvmerge(1) to keep certain ranges of timestamps while discarding others. The ranges to keep have to be listed after the parts: keyword and be 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).
Normally each range will be 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(1) 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 3 mkvmerge(1) 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 that mkvmerge(1) 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(1) will continue outputting the frames up to but excluding the following key frame.
The parts-frames mode tells mkvmerge(1) 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 be separated by commas. A range itself consists of a start and an end frame/field number. Numbering starts at 1.
Normally each range will be 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(1) 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.
Note that mkvmerge(1) 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 frame/field number is between two key frames mkvmerge(1) will continue outputting the frames up to but excluding the following key frame.
In example 1 mkvmerge(1) will create two files. The first will contain 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 will contain the content starting from 548 until 1211.
In example 3 mkvmerge(1) will create two files. The first will contain the content from the start of the source files until 430. The second file will contain the content starting from 2512 until the end of the source files.
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.
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.
7fc3f7cf58