MKVToolNix v24.0.0 released

[Mosu]

What is the reasoning behind this?

There's shit out there, and ffmpeg does the same in that situation (or at least with that file).

P.S.: You linked to github issue tracker, not gitlab.

Doh! Thanks, fixed, and fixed my NEWS-to-bbcode script, too.

[hubblec4]

Hi Mosu,

While I coding mtxcfg support in cE, I found a strange behavior in MTX. First I thought I do something wrong, but after manually reproducing it occurs also.
I feed MTX with a video stream (m2v) two or three audios (ac3) and subtitles(idx) and for all this files exists "appended files".
When I disable an audio or subtitle stream (all appended streams are disabled and grayed out. OK) and start muxing, MTX shows for all disabled streams an info

No append mapping was given for the file no. 13 ('E:\DVD-mtxcfg\I2_T1\2\AudioFile_82.ac3').
A default mapping of will be used instead.
Please keep that in mind if mkvmerge aborts with an error message regarding invalid '--append-to' options.

Is this info superfluous because the main file/stream and all appended files/streams are not used in the final mkv?

EDIT:
I use this MTX version:
mkvtoolnix-64-bit-22.0.0-build20180401-01724-421bea2a3

[fadedfedor]

Hello, I've been trying to make an mkv with a VP9 video track, Opus audio track, and an srt subtitle. A clicking sound is heard in both channels of the audio track after remuxing. I also tried to forego the srt and make it a webm, and it has the same clicking sound added.

I made a 30 second clip of the Opus track from the remuxed mkv to post as an example, it sounds fine, no clicking. Why would the Opus track sound fine before muxing, and extracted as a clip after muxing, but have an added clicked sound in the mkv or webm container?

[sneaker_ger]

Try:
Open mkv/webm in the Header Editor. Go Audio track -> default duration. Add element: "20000000". Save. Try again in your player (what player are you using?).

[mkver]

What player are you using? And can you upload a sample of the audio track before it was muxed at all?
FYI: There have been multiple (https://trac.ffmpeg.org/ticket/4178) reports (https://gitlab.com/mbunkus/mkvtoolnix/issues/2099) about a strange glitch with regard to opus, but it could never be tracked down, because all those who have complained had already deleted the file that the encoder produced. (And usually they also hadn't had the source files any more to check whether this is a reproducible bug in the opus encoder.) The bug has something to do with the DiscardPadding element that is used to signal the correct, sample accurate length of an opus packet: The packets of lots of codecs usually only have a few possible values for the number of samples they contain; if I am not mistaken then the length of every opus packet is always a multiple of 120 samples/2.5ms so if you want the encoded file to have th esame number of samples you have to trim something at the end and in Matroska this is designed to be signalled by the DiscardPadding element. It is usually only used in the very last packet, but in the samples we are talking about they are all over the place. If you play such a Matroska file with e.g. MPC-HC, the audio is severly distorted (just listen to the Star Trek sample from ffmpeg's bug tracker). Now here are to things you should know: The ogg container (the "native" container for opus) also has a way to signal what the DiscardPadding element signals. And if you extract the opus track from the Matroska file with mkvextract, the ogg muxer built into mkvextract uses this method so that the resulting files still contain this information. But if you play this ogg/opus file with e.g. MPC-HC the audio will sound normal although opusinfo (a file analyzer from the developers of the opus format) complains about the file being invalid. If you extract the file with ffmpeg (ffmpeg -i <Matroska file> -vn -sn -c:a copy output.opus -- this might be adapted if there are several audio tracks), it doesn't signal the information given by the DiscardPadding elements at all (at least not for the packets in the middle of a stream; I don't know about the very last packet where it is completely normal to have a DiscardPadding element). Consequently opusinfo doesn't complain about the extracted file at all any more and they seem to be fine. And maybe extraction with ffmpeg even repaired the file. But notice that ffmpeg's behaviour is actually not spec compliant.
As has been said: We don't really know if mkvmerge messes it up in the first place or if the files output by the opus encoder are garbage or whatnot.
So to cut a long story short: Please upload the samples. And if you know which tool produced them, then please tell which tool it was (including the version number). If you created the files yourself and if you still have the source files, then please try to reproduce the behaviour.

[fadedfedor]

Try:
Open mkv/webm in the Header Editor. Go Audio track -> default duration. Add element: "20000000". Save. Try again in your player (what player are you using?).
Thanks for the reply. I tried this and it did not make a noticeable change, I still hear the clicking / artifacts. I've tried playing it with mpv, MPC-HC and VLC.

What player are you using? And can you upload a sample of the audio track before it was muxed at all?...And if you know which tool produced them, then please tell which tool it was (including the version number). If you created the files yourself and if you still have the source files, then please try to reproduce the behaviour.
Thank you for your reply as well. I wish I understood more of the information that's in your post and the links you provided, and I am trying to. I first encoded it with foobar2000, but it sounded muffled. Then I encoded it with XMedia Recode 3.4.3.0 (latest) and was happy with the result. I still have the audio track, here's a sample of it: https://a.safe.moe/wNs6w3z.opus

[mkver]

opusinfo doesn't complain about the file you uploaded, it sounds right; and it still does when I remux the file with mkvmerge. In other words: I don't see/hear any bug here. Is this really the file that when remuxed with mkvmerge produced these distortions? Or was that the file produced by foobar2000? Or is did you use ffmpeg to extract only a part of the file that when remuxed with mkvmerge triggered the bug? That's not good, because remuxing with ffmpeg may change even the part of the file that is kept.

[fadedfedor]

Yes, that's really from the Opus track that made the distortions when muxed. I deleted the one produced by foobar2000 immediately, maybe I didn't even need to mention it. I made the clip that I uploaded with XMedia Recode from the Opus track not from a remuxed file.

[mkver]

I just took a look at the file you sent me via PM (for others who want to take a look themselves: link (https://a.safe.moe/6Nwew9a.mkv)):
1. The audio frames in both files coincide; it's just that the opus file has a few more of them. (I used ffmpeg's framehash muxer.)
2. The Matroska file (produced be a pretty recent version of libavformat) has DiscardPadding elements in it; more exactly, it has these elements in fixed intervals: at 980ms, 1980ms, 2980ms... The DiscardPadding is equal to 6.5ms -- equal to the CodecDelay. If one would have to join different opus files (each with a CodecDelay of 6.5ms) together, the resulting file would need to have DiscardPadding elements of 6.5ms in the middle. But because of the DiscardPadding elements the actual blocks with DiscardPadding would only have a length of 13.5 ms. In our case: The block after the block at 980ms would have to start at 993.5ms (which would need to be rounded depending on TimestampScale), but it starts at 1s (so there is a gap in the file).
3. Could you upload the exact source files (video and subtitle file) that you used as input in XMedia Recode (besides the opus file you already uploaded)? And can you give the exact settings that you used? (Because of 1. I already know that you did not reencode the opus track again, but I'd like to know the other settings as well.)
4. If I see this correctly, then you didn't really use mkvmerge in the process of creating the defective mkv at all. Is that true? This is further evidence that mkvmerge isn't to blame for this bug.

[fadedfedor]

Thanks for your analysis. I think you misunderstood me somewhere. I did use mkvmerge (MKVToolNix) to make the defective mkv. I only used XMedia Recode to encode the Opus track and to make a small clip of it to upload as a sample. I put a -2200ms delay on the subtitles when muxing, no other settings were changed.
https://a.safe.moe/G4Y6erB.srt
https://a.safe.moe/v7Ag3o1.webm

[mkver]

Ok, so let me rephrase: If I use mkvmerge to mux the webm file, the srt subs and the opus file that you uploaded I am supposed to get a file that has a defect audio track? Because I just did exactly that and the file I got was not defective.

[fadedfedor]

Ok, so let me rephrase: If I use mkvmerge to mux the webm file, the srt subs and the opus file that you uploaded I am supposed to get a file that has a defect audio track? Because I just did exactly that and the file I got was not defective.
You're right, I just did the same thing and the audio sounds fine. I noticed when I load the short clips there are two tags in the webm with the VP9 video. When I load the full VP9 and Opus tracks that those clips were cut from, there are no tags included. Could that have something to do with it?

[mkver]

Can you upload the full opus file? Or at the least the first few megabyte of it (it's important that you don't remux the file, but simply extract the first few MB (with a hex editor, not with a tool like ffmpeg); yes, you will probably have a defect packet at the end, but if there is enough material before it one can nevertheless use it to analyze it).
I'd be very surprised if the tags had anything to do with it. And the approval of attachments is very slow on this forum. If you ever want to upload something, then don't do it as an attachment. Not that I need a screenshot to show me that there are tags. I know it, because ffmpeg adds some tags by default.

[fadedfedor]

You meant the file before it's muxed into mkv that had the added clicking noises, right? Stupid question probably.
I split the file with a hex editor, is the first 3MB split okay? I don't mind uploading the full Opus file either, it's only 33MB.

https://a.safe.moe/0iTR2WZ.opus

[sneaker_ger]

I can hear the popping with the mkv remuxed from that sample.

[mkver]

If you have no problem uploading the whole sample, then please do so. Thanks.
For ease of reading: A = the opus file you just uploaded, B = file A remuxed with mkvmerge, C = file A remuxed with ffmpeg to opus
1. I can confirm that in B the packets at 980ms, 1980ms etc. have a DiscardPadding element. A uses page durations of 1s and the DiscardPadding elements in B are attached to the last frame out of A's pages (if I am not mistaken).
2. opusinfo has two complaints about B: WARNING: Samples with negative granpos in stream 1
WARNING: EOS not set on stream 1 (normal for live streams)
The second warning is an obvious result of the fact that the file is truncated; I don't think the first warning is, but to be sure I'd like to check the whole 33MB file.
What is remarkable is that there are no "WARNING: Sample count ahead of granule (49920>49608) in stream 1" and no "ERROR: stream 1 has interior holes or more than one page of end trimming" messages. (These are the errors that opusinfo outputs if one extracts the track from B to ogg/opus and analyzes the output with opusinfo.)
3. When A is decoded with the reference decoder, it also has this popping in it, but only once at about 970-980ms; B has it more often, because it has DiscardPadding elements every second. Consequently the decoded output of A and B diverge gradually; the difference in length is 138216 = 443*312 samples. 443s = 7m23s, the length of the file is about 7m24s.
If A is decoded with ffmpeg's native decoder then it is quite ok (the native decoder doesn't strip the CodecDelay away, so that the output file is actually 624 samples longer than the output of the reference decoder).
The differing behaviour of the reference decoder and mkvmerge might be due to a bug in the latter.
4. Unfortunately I don't know an analyzer that does for ogg/opus what mkvinfo does for Matroska.
5. Given that A is likely buggy I'd like to know exactly how you created it. In particular I'd like to know if you can reproducibily produce files like A.

[fadedfedor]

33.9MB Opus (https://we4load.com/1L4G)

http://i.cubeupload.com/p8Yh4b.png

I used these settings to create it with XMedia Recode 3.4.3.0. I deleted the source I used shortly after encoding because I listened to some of it and was happy with the result until I muxed it. I just checked and the source is no longer available online either. Almost forgot to mention that the source was 5.1 and I didn't use a downmix matrix.

[mkver]

If your defective opus file is all you've got, then the best thing to do would be to remux said file with ffmpeg: ffmpeg -i RObV6XA0h1k.opus -c copy output.opus. As has been said, this seems to repair it.
If the video is no longer available and you still want to help, you can try a few similar videos from the same website. They presumably use one set of tools for all their videos so that this behaviour may also be triggered by other videos.

[fadedfedor]

Thanks once again. That did seem to repair it and it sounds fine when muxed into an mkv now. That was my first time using ffmpeg. I'm sure I've used a couple programs that utilize it. I really appreciate your detailed analysis. I'll definitely try more videos from that same site.

[mkver]

You have definitely already used ffmpeg: XMedia Recode uses it; in fact, RObV6XA0h1k.opus was created by ffmpeg: Lavc58.17.100 libopus encoded RObV6XA0h1k.opus. Lavc stands for libavcodec, the library ffmpeg provides for de- and encoding. And the first opus file you uploaded (wNs6w3z.opus) was created using libavformat, ffmpeg's muxer and demuxer library.
But anyway, I can now produce such files myself: As has already been mentioned, ffmpeg's native opus decoder doesn't strip the Preskip/CodecDelay away; instead it adapts the timestamps: The first pcm sample has a timestamp of -312 (if the preskip was 312 samples, the default for libopus) on an 48 kHz timescale (or -6.5ms if you prefer) so that the actually valid samples start at zero. Unfortunately the invalid samples with negative timestamps aren't stripped away later either: If you output it to wave, the wave muxer includes the invalid samples in the output file; and if you reencode an opus file again (using ffmpeg's native decoder and the libopus encoder) the output file causes opusinfo to raise a "Samples with negative granpos in stream 1" warning and mkvmerge includes these DiscardPadding elements in the whole file.
So you don't need to try other files from the site again. I'm currently reading the opus in ogg specs to find out which tool is buggy (and whether files like RObV6XA0h1k.opus are actually against the spec (there might be a reason that opusinfo only shows a warning for such files)) and inform the relevant people. I'm already pretty sure that mkvmerge has a bug: If I don't use an opus input, but offset the timestamps manually with -itsoffset -0.05, I get a file where the DiscardPadding is more than the duration of the block without DiscardPadding:

| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:00.940002336
| + Frame with size 3
| + Discard padding: 10000000
| + Block duration: 00:00:00.009999360
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:00.960001056
| + Frame with size 3
| + Discard padding: 30000000
| + Block duration: 00:00:00.000000000
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:00.979999776
| + Frame with size 3
| + Discard padding: 50000000
| + Block duration: 00:00:00.000000000
...
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:01.940000832
| + Frame with size 163
| + Discard padding: 10000000
| + Block duration: 00:00:00.009999360
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:01.959999552
| + Frame with size 173
| + Discard padding: 30000000
| + Block duration: 00:00:00.000000000
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:01.979998272
| + Frame with size 166
| + Discard padding: 50000000
| + Block duration: 00:00:00.000000000
...

One more thing: The offset in RObV6XA0h1k.opus (equal to 312 samples, the Preskip of the reference opus encoder) lets me believe that this file has been reencoded from an source that was already opus. Is that so?

[fadedfedor]

One more thing: The offset in RObV6XA0h1k.opus (equal to 312 samples, the Preskip of the reference opus encoder) lets me believe that this file has been reencoded from an source that was already opus. Is that so?
Yes, the source was Opus. It was an odd 5.1 channel file that I've never seen on that site before.

[kuchikirukia]

I've uploaded a transport stream to your ftp that won't mux. The uncut one is 14GB and when mkvtoolnix tries to mux it it will sit there and read it, slowly filling 14GB of RAM, and then output a 120MB mkv that doesn't work.

If you split it with tsmuxer every piece is broken.
mkvtoolnix doesn't report any errors.

[mkver]

This sounds like a file that doesn't contain a single frame that mkvmerge detects as keyframe. Try the "--engage all_i_slices_are_key_frames" option. If this doesn't solve your problem: Can the transport stream actually be played? And does it contain other tracks than the video stream (can the 120 MB come from an audio stream?)?

[Mosu]

That sample is strange. I've only looked into it for a minute, but ffmpeg isn't happy with it either. Running "ffmpeg -i kuchikirukia\ -\ won\'t\ mux.ts -an -c:v copy ffmpeg.h264" produces an empty file; the similar "ffmpeg -i kuchikirukia\ -\ won\'t\ mux.ts -an -c:v copy ffmpeg.mkv" produces a Matroska file with track headers & tags but without any frame.

As to mkvmerge: the option is called ""--engage all_i_slices_are_key_frames" (additional "_" after "key"), BTW. You can mux the file that way. There are I slices every 500ms which will all be marked as key frames.

If I use mkvmerge with "all_i_slices…", extract the h.264 from that and import into an MP4 with MP4Box, then none of the frames are marked as key frames in the MP4 file (the "stss" atom contains an empty table).

If anyone else wants to take a look: I'll leave the file up here (https://mkvtoolnix.download/misc/kuchikirukia%20-%20won%27t%20mux.ts) for a while.

[mkver]

The file has 27 I frames, 27 SPS/PPS combinations (in the same access units as the keyframes), but no IDR frame and no recovery_point SEI messages. In other words: This is exactly the type of file for which said engage option has been introduced.
ffmpeg by default strips everything in front of the very first keyframe away. This behaviour can be overriden with -copyinkf[:stream_specifier]. Btw: It seems that ffmpeg ignores the Matroska keyframe flags: If I copy the file muxed with mkvmerge with the engage option, then the output file doesn't contain any frames flagged as keyframes (and no cues either, of course).

[manolito]

Also played a little bit with this sample, it is definitely quite broken IMO...

TSDoctor has no problems with it, no errors and no warnings. Demuxing or Remuxing always ends up without any video, no matter if you use MKVMerge or FFmpeg.

//EDIT//
Sorry I have to correct myself...
I just found out that Avidemux can remux this clip to MKV just fine (without any reencoding). I was using the ancient version 2.6.8 which still works under Win XP. As far as I can tell the resulting MKV seems to be in sync. Not too bad...
//End Edit//

But...
This clip can very well get transcoded, either to the same format or to a different format. FFmpeg does it, and it is also possible using AviSynth. As the AVS source filter only DSS2Mod worked for me, the three different versions of ffms2 I tried all failed.

Too bad that this clip really makes it impossible to judge audio sync, but I guess this could be repaired one way or another.


Cheers
manolito

[mkver]

Both mkvmerge (with the engage option already mentioned) and ffmpeg (with the copyinkf option; although you won't get an index in this case and the I frames won't have the keyframe flag set) can mux this file with video.
Do you have any reasons to believe there could be audio sync problems? (The sound doesn't consist in dialogue or noises that are caused by things we see onscreen, so we can't detect audio sync with it.)
If you want to repair this clip, you should add recovery_point SEI messages to the I frames: 0606018480 in hex without the start code (00000005 in Matroska, 000001 in an elementary stream/transport stream; but keep in mind that you can't simply add something in Matroska or a transport stream without breaking the container). Maybe mkvmerge could offer an option to include said recovery_points so that one can reprocess further with other tools who want to derive the keyframe condition on their own and don't use the Matroska flag?

[kuchikirukia]

I'm using a version of FFMS2 I pulled from somewhere (i needed the 10 bit hack) and it works to encode it from the start, it just can't seek. Trying to open it with MeGUI's preview just makes it churn endlessly since it tries to open from the middle.
MPC-HC plays it just fine. Audio's in sync and it has no problems seeking anywhere.

[Mosu]

MKVToolNix v23.0.0 is out containing a moderate number of enhancements and bug fixes.

About AV1 support: even though the previous release was the first to support AV1, keep in mind that neither the bitstream format nor the method of storage in MP4, WebM and Matroska has been finalized yet. I've therefore decided to disable AV1 support by default. You have to enable it manually by passing `--engage enable_av1` to mkvmerge. mkvmerge can still identify AV1 without that option, but it'll refuse to multiplex it.

Note further that only supported bitstream format is the one that was active on 2018-05-02.

To my users on Debian and Ubuntu: the layout of my APT repositories was changed in April. You'll have to update your `sources.list` entry accordingly. Read more about that in this blog post (https://www.bunkus.org/blog/2018/04/debian-ubuntu-apt-repository-changes/).

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries are available already. The Linux binaries are still being built and will be available of the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 23.0.0 "The Bride Said No" 2018-05-02

## New features and enhancements

* mkvmerge: input: format detection uses file-extension to improve performance and to give preference when several formats match.
* mkvmerge: AV1: added support for reading AV1 video from Open Bitstream Unit files.
* mkvmerge: AV1: adjusted the code for the AV1 bitstream format changes made up to 2018-05-02 (git revision d14e878).
* mkvmerge: MP4 reader: if a track has an edit list with two identical entries, each spanning the file's duration as given in the movie header atom, then the second entry will now be ignored. Improves the handling of files with bogus data; see #2196 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2196) and #2270 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2270).
* MKVToolNix GUI: multiplexer: added options to only enable tracks of certain types by default. Implements #2271 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2271).
* MKVToolNix GUI: multiplexer: added an option to enable dialog normalization gain removal by default for all audio tracks for which the operation is supported. Implements #2272 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2272).
* MKVToolNix GUI: multiplexer: when deriving track languages from the file names is active and the file name contains the usual season/episode pattern (e.g. "S02E14"), then only the part after the season/episode pattern will be used for detecting the language. Part of the improvements for #2267 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2267).
* MKVToolNix GUI: multiplexer: the regular expression used for deriving track languages from the file names can now be customized in the preferences. Part of the improvements for #2267 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2267).
* MKVToolNix GUI: multiplexer: the user can now customize the list of track languages the GUI recognizes in file names. This list defaults to a handful of common languages instead of the full list of supported languages. Part of the improvements for #2267 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2267).

## Bug fixes

* mkvmerge: MP3 packetizer: removed a memory leak growing linearly with the track's size.
* mkvmerge: VobSub packetizer: whenever a VobSub packet doesn't contain a duration on the container level, mkvmerge will now set it from the duration in the SPU packets. Before it was accidentally setting the SPU-level duration to 0 instead. Fixes #2260 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2260).
* mkvmerge: track statistics tags: if writing the `Date` element is deactivated via `--no-date`, the `_STATISTICS_WRITING_DATE_UTC` isn't written either anymore. Fixes #2286 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2286).
* mkvmerge, mkvextract, mkvpropedit: removed several small, constant-size memory leaks.
* mkvextract: fixed a crash when mkvextract with a non-Matroska file as the source file. Fixes #2281 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2281).
* MKVToolNix GUI: the central area is now scrollable, allowing the GUI to be resized to almost arbitrary sizes. Fixes #2265 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2265).
* MKVToolNix GUI: multiplexer: the "copy file title to destination file name" functionality will now replace everything in the destination file name up to the last period instead of only up to the first period. Fixes #2276 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2276).

## Build system changes

* build system: MKVToolNix now requires a compiler that supports the following features of the C++14 standard: "user-defined literals for `std::string`". For the GNU Compiler Collection (gcc) this means v5.x or newer; for clang it means v3.4 or newer.
* Windows: linking against and installing shared version of the libraries with MXE is now supported by setting `configure`'s `host` triplet accordingly, e.g. `--host=x86_64-w64-mingw32.shared`.

## Other changes

* mkvmerge: AV1: support for AV1 must be activated manually by adding `--engage enable_av1` as the AV1 bitstream specification hasn't been finalized yet.

Have fun :)

[LeMoi]

Thanks, many new features are quite useful and were missing :)

[Snowknight26]

Tiny bug in at least v23:

When adding source files and selecting index.bdmv of a Blu-ray, the "Select file to add" window generally pops up, listing all the scanned playlists. If you select the first scanned file, then 2nd, then first, and so on, the tracks panel's width grows indefinitely, shrinking the scrollbar.

https://www.stfcc.org/pics/i/99bf261a747beca7ee049e5095b9756a_th.png (https://www.stfcc.org/pics/i/99bf261a747beca7ee049e5095b9756a.png)

[zeropc]

is there a way to start a movie from a certain chapter? if not, can this be added?
this would be very neat to skip those millions of logos at the beginning.

[sneaker_ger]

Ordered chapters (http://mod16.org/hurfdurf/?p=8) can virtually "remove" parts you don't want, but only some players support it (e.g. MPC-HC and VLC).

You can also split on chapter marks ("Output" tab) in the GUI to completely get rid of the stuff you don't want. Of course the usual splitting limitations (keyframes, subtitle lines) still apply.
https://mkvtoolnix.download/doc/mkvmerge.html#d4e768

[hubblec4]

@zeropc

If you need more info and help... here is the right place (https://forum.doom9.org/showthread.php?t=169984) for this.

[hubblec4]

Hi Mosu

Can I mux chapters and tags with mkvpropedit in one go to an existing mkv?

[Mosu]

Sure:

mkvpropedit yourfile.mkv --chapters funny-chapters.xml --tags global:serious-tags.xml

[hubblec4]

Wonderful, thanks for this info.

[zeropc]

thanks hubble & sneaker_ger :)

[Sp00kyFox]

I have a problem here with some DVB-T2 captures (mts, HEVC). I usually cut and remux them afterwards with MKVToolnix. but when there are some hiccups during the recording the audio in the resulting MKV gets out of sync. I guess I can't expect that the tool handles corrupt files correctly, but I was wondering if there is any command or option to prevent MKVToolnix from closing the gap. since when playing the original mts file there is still the hiccup but it keeps in sync. here is a sample with said issue:

https://mega.nz/#!Gc4xgBAC!-yRi2YvR31JiZEgdBZu8OhlzwURbOjdH7EROMldPupw

the hiccup occurs around 0:0:14. remux it with MKVToolNix and the result gets desynced. I'd appreciate any help, thanks!

[manolito]

Wow, this is a real bad hickup...

First of all do not spend any money on TSDoctor, it cannot repair the audio sync. Just the opposite with this file, after letting TSDoctor fix it it will not play in sync any longer.

I found 2 methods to keep the remuxed MKV in sync:

The easiest one is AviDemux. Use COPY for audio and video, use MKV as the muxer. In the settings under "Output" there is an option to create more even timestamps in Copy mode. If you tick it then you will get a couple of warnings about skipped frames, but the result also stays in sync.

The other option is FFmpeg, but only if audio is decoded to WAV. You can later reencode it to AAC or AC3. I also had to disable all extra streams including the subs stream. My FFmpeg version is fairly recent, but it could not detect the subs format. This is the FFmpeg command line I used:
ffmpeg.exe -fflags +genpts -y -i "I:\sample.mts" -map 0:0 -c:v:0 copy -aspect:v:0 16:9 -map 0:1 -c:a:0 pcm_s16le -metadata:s:a:0 "language=deu" -map 0:2 -c:a:1 pcm_s16le -metadata:s:a:1 "language=deu" -shortest "I:\sample.mkv"


Good luck
manolito

[mkver]

That sample is weird: Here is a selection of the timestamps that MKVToolNix produces for the video stream:

B frame, track 1, timestamp 00:00:14.683000000, size 5905, adler 0x77fe5115
P frame, track 1, timestamp 00:00:14.723000000, size 7492, adler 0xc9d3a8b1
P frame, track 1, timestamp 00:00:14.823000000, size 39269, adler 0xf81166f8
B frame, track 1, timestamp 00:00:14.783000000, size 17800, adler 0x77f5c510
B frame, track 1, timestamp 00:00:14.763000000, size 7068, adler 0xf5bcdafa
P frame, track 1, timestamp 00:00:14.803000000, size 7392, adler 0xcc7c6691
P frame, track 1, timestamp 00:00:14.903000000, size 41811, adler 0xef1522c7
B frame, track 1, timestamp 00:00:14.863000000, size 17522, adler 0x2947169a
B frame, track 1, timestamp 00:00:14.843000000, size 7354, adler 0x0ca36690
P frame, track 1, timestamp 00:00:14.883000000, size 6775, adler 0xf0114eff
P frame, track 1, timestamp 00:00:14.983000000, duration 00:00:00.080000000, size 40562, adler 0x43f9aea7
B frame, track 1, timestamp 00:00:14.943000000, size 17214, adler 0x4990347a
B frame, track 1, timestamp 00:00:14.923000000, size 6127, adler 0x030cff37
P frame, track 1, timestamp 00:00:14.963000000, size 6162, adler 0x39c8e3f5
P frame, track 1, timestamp 00:00:15.063000000, duration 00:00:02.500000000, size 54072, adler 0x7da33895
P frame, track 1, timestamp 00:00:17.583000000, size 9334, adler 0x88830309
B frame, track 1, timestamp 00:00:17.563000000, size 5986, adler 0xa78fa29b
P frame, track 1, timestamp 00:00:17.603000000, duration 00:00:00.040000000, size 6204, adler 0x05e501b3
P frame, track 1, timestamp 00:00:17.703000000, size 28974, adler 0x589c0d84
B frame, track 1, timestamp 00:00:17.663000000, size 9435, adler 0xd1413b81
B frame, track 1, timestamp 00:00:17.643000000, size 5678, adler 0x9569018e
P frame, track 1, timestamp 00:00:17.683000000, size 5745, adler 0xa2983a9c
P frame, track 1, timestamp 00:00:17.783000000, size 32748, adler 0xaa58c28e
B frame, track 1, timestamp 00:00:17.743000000, size 9003, adler 0x3bfb6ac0
B frame, track 1, timestamp 00:00:17.723000000, size 5656, adler 0x76b9019c
P frame, track 1, timestamp 00:00:17.763000000, size 5459, adler 0x49a19fa5
P frame, track 1, timestamp 00:00:17.863000000, size 32155, adler 0x599cab02
B frame, track 1, timestamp 00:00:17.823000000, size 8498, adler 0xac1282b0
B frame, track 1, timestamp 00:00:17.803000000, size 4970, adler 0x3e389ce3
P frame, track 1, timestamp 00:00:17.843000000, size 5419, adler 0x48907c49
P frame, track 1, timestamp 00:00:17.943000000, size 30719, adler 0xedeeb630
B frame, track 1, timestamp 00:00:17.903000000, size 8410, adler 0xf8d2594f
B frame, track 1, timestamp 00:00:17.883000000, size 5525, adler 0xec7dd765
P frame, track 1, timestamp 00:00:17.923000000, size 5672, adler 0xcee0f180
I frame, track 1, timestamp 00:00:18.023000000, size 52082, adler 0x254477d4
B frame, track 1, timestamp 00:00:17.983000000, size 7646, adler 0x226ebbc3
B frame, track 1, timestamp 00:00:17.963000000, size 5603, adler 0xbd84cf41
P frame, track 1, timestamp 00:00:18.003000000, size 5627, adler 0xf3ec2549
P frame, track 1, timestamp 00:00:18.103000000, duration 00:00:00.040000000, size 34160, adler 0x850647c8
B frame, track 1, timestamp 00:00:18.063000000, size 7740, adler 0x91eaef29
B frame, track 1, timestamp 00:00:18.043000000, size 4781, adler 0xd48d6b83
P frame, track 1, timestamp 00:00:18.083000000, size 4870, adler 0x87604e98
P frame, track 1, timestamp 00:00:18.183000000, size 30475, adler 0x763c5976
P frame, track 1, timestamp 00:00:18.143000000, duration 00:00:00.040000000, size 9822, adler 0xdb050357
B frame, track 1, timestamp 00:00:15.503000000, size 9059, adler 0x148db74b
B frame, track 1, timestamp 00:00:15.483000000, size 4751, adler 0xf4273b64
P frame, track 1, timestamp 00:00:15.523000000, duration 00:00:00.040000000, size 5091, adler 0xff93096a
P frame, track 1, timestamp 00:00:15.623000000, size 32602, adler 0x009a8195
B frame, track 1, timestamp 00:00:15.583000000, size 12851, adler 0xd40500a2
B frame, track 1, timestamp 00:00:15.563000000, size 7913, adler 0xb7f2854e
P frame, track 1, timestamp 00:00:15.603000000, size 8057, adler 0x4a5fd8ed
...
B frame, track 1, timestamp 00:00:17.183000000, size 9020, adler 0x9f776665
B frame, track 1, timestamp 00:00:17.163000000, size 5280, adler 0x1aa6424b
P frame, track 1, timestamp 00:00:17.203000000, size 6087, adler 0x56b9ef41
P frame, track 1, timestamp 00:00:17.303000000, size 32706, adler 0xc4c9c5d4
B frame, track 1, timestamp 00:00:17.263000000, size 8916, adler 0x63451274
B frame, track 1, timestamp 00:00:17.243000000, size 5775, adler 0x53614f69
P frame, track 1, timestamp 00:00:17.283000000, size 5830, adler 0x3bbc415c
P frame, track 1, timestamp 00:00:17.383000000, size 33581, adler 0xe81607af
B frame, track 1, timestamp 00:00:17.343000000, size 9170, adler 0xff80ce50
B frame, track 1, timestamp 00:00:17.323000000, size 5401, adler 0xb95b8c57
P frame, track 1, timestamp 00:00:17.363000000, size 5737, adler 0xd0bb4d6b
P frame, track 1, timestamp 00:00:17.463000000, size 29957, adler 0x8fc5a400
B frame, track 1, timestamp 00:00:17.423000000, size 9846, adler 0xa9862ab8
B frame, track 1, timestamp 00:00:17.403000000, size 6106, adler 0x13f0d4c9
P frame, track 1, timestamp 00:00:17.443000000, size 6747, adler 0xaa1a4085
P frame, track 1, timestamp 00:00:17.543000000, size 28533, adler 0x889598f0
B frame, track 1, timestamp 00:00:17.503000000, size 9428, adler 0x1b643ff4
B frame, track 1, timestamp 00:00:17.483000000, size 6461, adler 0x97dab14f
P frame, track 1, timestamp 00:00:17.523000000, size 6278, adler 0xe8d2403e
P frame, track 1, timestamp 00:00:17.623000000, size 29976, adler 0xa9ac3da5
B frame, track 1, timestamp 00:00:17.583000000, size 9334, adler 0x88830309
B frame, track 1, timestamp 00:00:17.563000000, size 5986, adler 0xa78fa29b
P frame, track 1, timestamp 00:00:17.603000000, size 6204, adler 0x05e501b3
P frame, track 1, timestamp 00:00:17.703000000, size 28974, adler 0x589c0d84
B frame, track 1, timestamp 00:00:17.663000000, size 9435, adler 0xd1413b81
B frame, track 1, timestamp 00:00:17.643000000, size 5678, adler 0x9569018e
P frame, track 1, timestamp 00:00:17.683000000, size 5745, adler 0xa2983a9c
P frame, track 1, timestamp 00:00:17.783000000, size 32748, adler 0xaa58c28e
B frame, track 1, timestamp 00:00:17.743000000, size 9003, adler 0x3bfb6ac0
B frame, track 1, timestamp 00:00:17.723000000, size 5656, adler 0x76b9019c
P frame, track 1, timestamp 00:00:17.763000000, size 5459, adler 0x49a19fa5
P frame, track 1, timestamp 00:00:17.863000000, size 32155, adler 0x599cab02
B frame, track 1, timestamp 00:00:17.823000000, size 8498, adler 0xac1282b0
B frame, track 1, timestamp 00:00:17.803000000, size 4970, adler 0x3e389ce3
P frame, track 1, timestamp 00:00:17.843000000, size 5419, adler 0x48907c49
P frame, track 1, timestamp 00:00:17.943000000, size 30719, adler 0xedeeb630
B frame, track 1, timestamp 00:00:17.903000000, size 8410, adler 0xf8d2594f
B frame, track 1, timestamp 00:00:17.883000000, size 5525, adler 0xec7dd765
P frame, track 1, timestamp 00:00:17.923000000, size 5672, adler 0xcee0f180
I frame, track 1, timestamp 00:00:18.023000000, size 52082, adler 0x254477d4
B frame, track 1, timestamp 00:00:17.983000000, size 7646, adler 0x226ebbc3
B frame, track 1, timestamp 00:00:17.963000000, size 5603, adler 0xbd84cf41
P frame, track 1, timestamp 00:00:18.003000000, size 5627, adler 0xf3ec2549
P frame, track 1, timestamp 00:00:18.103000000, size 34160, adler 0x850647c8
B frame, track 1, timestamp 00:00:18.063000000, size 7740, adler 0x91eaef29
B frame, track 1, timestamp 00:00:18.043000000, size 4781, adler 0xd48d6b83
P frame, track 1, timestamp 00:00:18.083000000, size 4870, adler 0x87604e98
P frame, track 1, timestamp 00:00:18.183000000, size 30475, adler 0x763c5976
B frame, track 1, timestamp 00:00:18.143000000, size 9822, adler 0xdb050357
B frame, track 1, timestamp 00:00:18.123000000, size 4600, adler 0x99a7eafd
P frame, track 1, timestamp 00:00:18.163000000, size 4082, adler 0x55c71256
P frame, track 1, timestamp 00:00:18.263000000, size 31747, adler 0xcf232b6e
B frame, track 1, timestamp 00:00:18.223000000, size 10340, adler 0xfee421db
B frame, track 1, timestamp 00:00:18.203000000, size 4685, adler 0x60391107
P frame, track 1, timestamp 00:00:18.243000000, size 4958, adler 0xdbadafec
P frame, track 1, timestamp 00:00:18.343000000, size 31606, adler 0xb7f4f75d
B frame, track 1, timestamp 00:00:18.303000000, size 10588, adler 0x1a50895d
B frame, track 1, timestamp 00:00:18.283000000, size 5079, adler 0xd794eec5
P frame, track 1, timestamp 00:00:18.323000000, size 4937, adler 0x49596eb3
P frame, track 1, timestamp 00:00:18.423000000, size 31821, adler 0x8064d43e
B frame, track 1, timestamp 00:00:18.383000000, size 9972, adler 0x4cd6611c
B frame, track 1, timestamp 00:00:18.363000000, size 4410, adler 0x4b54aa42
P frame, track 1, timestamp 00:00:18.403000000, size 4407, adler 0xd0ee7f79
P frame, track 1, timestamp 00:00:18.503000000, size 32125, adler 0xfd1484b1
B frame, track 1, timestamp 00:00:18.463000000, size 9686, adler 0xf6e8b772
B frame, track 1, timestamp 00:00:18.443000000, size 4400, adler 0xca9d7802
P frame, track 1, timestamp 00:00:18.483000000, size 4192, adler 0xf00e2d6a
P frame, track 1, timestamp 00:00:18.583000000, size 32390, adler 0x76b8e4d7
B frame, track 1, timestamp 00:00:18.543000000, size 8114, adler 0xf66be2b8
B frame, track 1, timestamp 00:00:18.523000000, size 4325, adler 0xb76fa0c5
P frame, track 1, timestamp 00:00:18.563000000, size 5358, adler 0xb6fc5e37
P frame, track 1, timestamp 00:00:18.663000000, size 31926, adler 0x754efed5
B frame, track 1, timestamp 00:00:18.623000000, size 8209, adler 0xd145cb14
B frame, track 1, timestamp 00:00:18.603000000, size 5177, adler 0x169e1b7d
P frame, track 1, timestamp 00:00:18.643000000, size 5181, adler 0x9929062c
P frame, track 1, timestamp 00:00:18.743000000, size 31480, adler 0x4350e50e
B frame, track 1, timestamp 00:00:18.703000000, size 8789, adler 0x2166ef9d
B frame, track 1, timestamp 00:00:18.683000000, size 5172, adler 0xecd20fca
P frame, track 1, timestamp 00:00:18.723000000, size 5632, adler 0x595dbecf
P frame, track 1, timestamp 00:00:18.823000000, size 30210, adler 0x13a2c4b3
B frame, track 1, timestamp 00:00:18.783000000, size 9503, adler 0x97036215
B frame, track 1, timestamp 00:00:18.763000000, size 6270, adler 0x34992280
P frame, track 1, timestamp 00:00:18.803000000, size 6563, adler 0x61ecc81b
P frame, track 1, timestamp 00:00:18.903000000, size 30006, adler 0xb3e1f7f1
B frame, track 1, timestamp 00:00:18.863000000, size 9644, adler 0xf2369b6b
B frame, track 1, timestamp 00:00:18.843000000, size 6438, adler 0x21dd73b1
P frame, track 1, timestamp 00:00:18.883000000, size 6615, adler 0xa171d824

There are two things of note in there: First, the timestamp of the packet immediately after 15.063 is 17.583, then there are some packets until 18.143 and then we have a packet with timestamp 15.503 diretctly after that. The second jump can't be explained by frame reordering at all. And secondly, after the second jump we have normal video once again -- including packts with the same timestamps and checksums (the adler stuff). Therefore your m2ts file is not only missing some packets (as is normal for a bad transmission), it also has something twice. Analysing the file yields that the blocks 12341248-12842816 and 14700544-15202112 coincide. These 501568 bytes correspond to 2612 1/3 packets. Looking at the above timestamps (or also at the timestamps contained in the first four bytes before the actual 188 bytes transport stream packet) one sees that the first of these blocks should be deleted; but because that would leave an incomplete packet at 12341248 I have only deleted 12341312-12842816. If I feed this to mkvmerge, the A/V sync is good and the hiccup is not so bad any more.
Btw: Using ffmpeg produced a file where the aac tracks used an uncommon format (the A_MS/ACM CodecId and LATM at the bitstream level) and that also had a second error at about 17s. But the snc was fine.

[Sp00kyFox]

yeah, I stumbled upon TS Doctor but I thought I better ask here first. usually there are some free solutions available from the video community. thanks for the heads-up. I only have this problem with some stations. since it is a terrestrial broadcasting I suppose there is a problem with the signal strength and it introduces the occasional packet loss. maybe I should get me a bigger antenna. anyways. many thanks for the help manolito and mkver. I tried Avidemux on the full recording and it worked just fine, awesome.

[VoodooFX]

I remuxed one mp4 video to mkv with mkvtoolnix v23 and noticed that mkv video stutters (skips frames), when mp4 plays properly, there where no warnings or errors in "job output".
Then I tried to remux with Avidemux and got this message:
https://i.imgur.com/l0xHGV3.png

Would be nice to get warning that something wrong with PTS in mkvtoolnix too, or even option to reconstruct PTS.

[Mosu]

mkvmerge used to contain a similar warning if the CTTS atom wasn't present, but it didn't actually check whether or not there were B frames present. This meant that the warning was often shown in error, meaning the CTTS atom not being present was OK as there were no B frames.

Due to how mkvmerge works internally, the container-reading code doesn't have a lot of (if any) knowledge about the bitstreams of the various codecs the container can carry. Therefore analyzing whether or not B frames are present in the MP4 reader would amount to a lot of work and/or a noticeable slowdown in processing speed, neither of which I want.

I therefore decided to remove the warning altogether a couple of releases ago. It won't come back.

[VoodooFX]

That "Question" popup in Avidemux I got almost instantly after opening mp4, so its implementation not so slow. Real slowdown would be need to double check remuxed mkvs for this error.
I hope you reconsider implementing it in future. Thank you.

[Mosu]

In case of a positive hit (CTTS not present but B frames present), the slowdown would indeed be unnoticeable as a B frame is almost certainly encountered right away. The place where the slowdown does hurt and does occur, though, is if the file is valid (CTTS not present and B frames not present either), because in that case mkvmerge would have to parse the whole bitstream in the demuxer to no avail.

No, I won't reconsider. I have a lot of things I actually want to work on that are much more relevant. Your file is something that happens very, very rarely, after all.

[foxyshadis]

I have a problem here with some DVB-T2 captures (mts, HEVC). I usually cut and remux them afterwards with MKVToolnix. but when there are some hiccups during the recording the audio in the resulting MKV gets out of sync. I guess I can't expect that the tool handles corrupt files correctly, but I was wondering if there is any command or option to prevent MKVToolnix from closing the gap. since when playing the original mts file there is still the hiccup but it keeps in sync. here is a sample with said issue:

https://mega.nz/#!Gc4xgBAC!-yRi2YvR31JiZEgdBZu8OhlzwURbOjdH7EROMldPupw

the hiccup occurs around 0:0:14. remux it with MKVToolNix and the result gets desynced. I'd appreciate any help, thanks!

Just curious, but what capture software is this? They're supposed to filter out repeated PTS.

[FishPencil]

Can mkvmerge handle PGS subtitles with some of the subtitles having the forced flag set?

I believe that some studios bundle the forced and nonforced subtitles into one PGS stream and a flag is set for each image to denote its type.

If I multiplex an m2ts with these subtitles included, will the resulting mkv work with the forced ones?

If not, how should this be handled?

[Sp00kyFox]

Just curious, but what capture software is this? They're supposed to filter out repeated PTS.
not any. I'm using a DVB-T2 receiver with PVR feature. it is the Comag SL30T2.

[Mosu]

Can mkvmerge handle PGS subtitles with some of the subtitles having the forced flag set?

mkvmerge doesn't do anything regarding that flag. It simply copies the whole PGS stream as-is.