MKVToolNix v99.0 released

[odino]

Hi Moritz,
I don't know if this is a bug or a setting I missed but often the GUI will attach (1) to a filename, presumably when it has noticed there is an existing filename. Now, I don't mind it per se, but usually I DO want to overwrite a file, but my bigger beef with it is that it sometimes, almost at random, only does this AFTER I have clicked on "start multiplexing", suddenly attaching the "(1)" in a millisecond. This behavior seems unpredicable. Any thoughts? Thanks for your time.

[Mosu]

I'm not sure if this discussion would be better in a draft PR, but the code I did isn't organized properly right now.

Thanks for looking into it! Discussion about code is definitely better done on Gitlab in a MR, even if the code isn't working yet.

[Mosu]

Hi Moritz,
I don't know if this is a bug or a setting I missed but often the GUI will attach (1) to a filename, presumably when it has noticed there is an existing filename. Now, I don't mind it per se, but usually I DO want to overwrite a file, but my bigger beef with it is that it sometimes, almost at random, only does this AFTER I have clicked on "start multiplexing", suddenly attaching the "(1)" in a millisecond. This behavior seems unpredicable. Any thoughts? Thanks for your time.

It's a setting called "Ensure the file name is unique" in the preferences → "Multiplexer" → "Destination file name". What you describe is intended behavior if the option is on as the GUI cannot read your mind (as in "oh, in general I do want it to be unique but _this_ time I don't!").

[odino]

It's a setting called "Ensure the file name is unique" in the preferences → "Multiplexer" → "Destination file name". What you describe is intended behavior if the option is on as the GUI cannot read your mind (as in "oh, in general I do want it to be unique but _this_ time I don't!").

Ok great, thanks, I have switched that off for now. Greetings.

[-QfG-]

There is a bug till v55 (latest Build) and HDR10+DV (Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible) muxes. You have artefacts at the Oppo Player, the Clones and the internal LG Players.
I know that this Players uses the fallback HDR versions from the mkvs. v54 works fine.

[quietvoid]

There is a bug till v55 (latest Build) and HDR10+DV (Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible) muxes. You have artefacts at the Oppo Player, the Clones and the internal LG Players.
I know that this Players uses the fallback HDR versions from the mkvs. v54 works fine.

I think this is the related issue: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3093

I've also noticed both 56 and 56.1 do not trigger Dolby Vision when played back, while 55 does.
I tried the --engage dont_normalize_parameter_sets flag but it made no difference.

[SeeMoreDigital]

Playback of Dolby Vision encoded video placed within .mkv container using an OPPO or LG or Sony player!!! When did this happen?

[quietvoid]

I don't think it has, they mention HDR fallback (which is broken with last MKVToolNix version).
I know I can't play MKVs in Dolby Vision on my 2018 LG (with the internal player).

[VAMET]

Dear Friends

I have created via MakeMKV .mkv with Dolby Vision from my physical disc. There are untouched video and audio tracks and chapters. MakeMKV doesn't allow to remove chapters from .mkv. Are there any possibilities to remove chapters from .mkv without touching/processing video and audio tracks? Is it done via MKVToolNix>Multiplexer>Add file, then untick Chapters and Start Multiplexing or other method (simple command line)?

Thank you in advance for your help and support.

Sincerely

[Mosu]

That should work. You could also just use the GUI's chapter editor's "Remove chapters from existing Matroska file" feature (in the "Chapter editor" menu).

[Perenista]

I am having a new problem with MKVToolnix and subtitles.

https://i.postimg.cc/QtvWbwDS/X1.png

https://i.postimg.cc/brbSFgNP/X2.png

Whenever I add one of these subtitles to any of these Matroskas MKVTOOLNIX disregard my advice to tell all of them are english, and somehow interprets the "de" among the words means it should be german.

https://i.postimg.cc/j2zChjZd/PRO.png

There's just one problem here, the words "de" are part of "cor-de-rosa" which means "pink color" in portuguese.

The mistake MKVToolnix is making would be similar to telling me this:

The Adventures.mkv
The Adventures.srt

Would result in this:

https://i.postimg.cc/T1X3h6f8/PRO2.png

Since this is a primary mistake I need to disable this for good. Whatever language I said the program to assume it is (in this case english) needs to be the one attributed to ALL subtitles. No matter what.

[Mosu]

You can configure the languages the GUI tries to find in the file name in the preferences ("Multiplexer" → "Deriving track languages"). Just remove all languages safe for those you usually use.

If you don't want dashes to be recognized as valid separators for words for the purpose of deriving track languages, you can simply remove the dash from the list of boundary characters there, too.

Or simply deactivate that feature altogether, again at the same place.

[von Suppé]

Hi Mosu,

I noticed you opened https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3113 recently.
For my reassurance, two questions please.

With the "no support for DV two separate files" in your last post there, I assume you mean when importing previously demuxed BL and EL streams?
Secondly, am I right to think that using v55.0.0 is - for now - recommended for (re-)muxing Dolby Vision?

[Mosu]

With the "no support for DV two separate files" in your last post there, I assume you mean when importing previously demuxed BL and EL streams?

I don' t know the verbiage around Dolby Vision, so I cannot really say with certainty that this is what I meant. If I understood things correctly, Dolby Vision on Blu-rays is packaged in a way that means the player has to read the regular HEVC data from one file and the Dolby Vision data from another file, as opposed to having both in a single file. I will most likely not support the former (at least not initially or anytime soon).

Secondly, am I right to think that using v55.0.0 is - for now - recommended for (re-)muxing Dolby Vision?

You can also use 56.1.0. If the resulting file works, great; so far I don't have concrete evidence that all files containing DV created by ≥ 56.1.0 show playback issues.

If it doesn't, try adding "--engage dont_normalize_parameter_sets" which is basically the same behavior as in versions prior to v56.

Even better would be if you could follow issue 3093 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3093) and give the test files I upload there a try & give feedback on whether they play fine or not. That would actually help in fixing the bug whereas going back to v55 doesn't help me at all.

[Mosu]

Addendum: I've just realized that mkvmerge ≥ v56 places the Dolby Vision NALUs in the wrong Matroska block, even if "--engage dont_normalize_parameter_sets" is used. Therefore yes, at this point using v55 for Dolby Vision is the way to go until I've fixed that. You can follow issue 2784 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2784) where this is currently discussed.

[Mosu]

Hello, hello!

fresh of the presses here's MKVToolNix v57.0.0. A lot of work has gone into the HEVC/H.265 code over the last couple days, fixing most issues with Dolby Vision and HDR content, but also fixing a couple of general issues with the HEVC/H.265 code. Everyone using that codec should definitely update.

The state of Dolby Vision & HDR is pretty good right now. The only thing still missing is reading Dolby Vision from Annex B type elementary streams (raw .h265 files or MPEG transport streams), but we're working on that as well.

By the way: a lot of you have decided to support MKVToolNix by buying it from the Microsoft Store (https://www.microsoft.com/store/apps/9NS0Q4ZM8MW2) for which I'm very, very grateful. At the point of writing it has been sold 544 times already. One immediate benefit is that I've invested in Dolby Vision capable hardware in order to be better able to test & improve that part of MKVToolNix. Your support is definitely making a difference.

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

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

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

Version 57.0.0 "Till The End" 2021-05-22
New features and enhancements

mkvmerge: MP4 reader: added support for reading Dolby Vision from MP4 files (FourCCs "dvh1" and "dvhe"; configuration records "dvcC", "dvvC" and "hvcE" will be converted into block addition mappings). Implements #2784 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2784).
mkvmerge: SRT subtitles: mkvmerge now accepts empty text files with the extension ".srt" as SRT subtitle files, enabling the creation of empty SRT tracks. Implements #3089 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3089).
mkvmerge, mkvextract: HEVC/H.265: access unit delimiter NALUs will no longer be discarded, neither during muxing nor during extraction.
MKVToolNix GUI: preferences: switched the order & wording of controls in the "enabling items" panel to make it clearer that certain controls define exceptions. Inspired by 3086.

Bug fixes

mkvmerge: HEVC/H.265 parser: several NALU types, notably the Dolby Vision-specific NALUs ("unspecified 62" and "unspecified 63") and suffix SEI NALUs, are now stored with the frame they belong to instead of with the next frame. Part of fixing & implementing #2784 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2784), #2818 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2818), #3093 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3093) and #3113 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3113).
mkvmerge: HEVC/H.265 packetizer: fixed setting the track's default duration when reading HEVC/H.265 from Matroska files that don't have a default duration set.
mkvmerge: HEVC/H.265 packetizer: fixed the calculation of the duration of frames so that "SimpleBlock" elements can be used again instead of "BlockGroups" with "BlockDuration" elements. Fixes #3114 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3114).
mkvmerge, mkvextract: HEVC/H.265 parser: fixed issues with ordering & duplication of certain NALUs (parameter set & prefix SEI NALUs). Part of fixing & implementing of #2784 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2784), #2818 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2818), #3093 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3093) and #3113 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3113).
MKVToolNix GUI: multiplexer: when dragging & dropping files to the multiplexer, the source directory will be remembered as the "last open directory" again, causing subsequent uses of the "open file" dialog to start in the same directory. Fixes #3110 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3110).
mkvinfo: fixed the position of frames in block groups containing "block duration" elements in summary mode (e.g. for subtitle tracks).

Build system changes

"configure" will now try to detect "libmagic" via "pkg-config" and fall back to including & linking directly if it cannot be found via "pkg-config".


Have fun :)

[filler56789]

fresh of the presses here's MKVToolNix v57.0.0.

Thanks! :thanks:

[quietvoid]

Thank you!

[von Suppé]

Thanks, Mosu.

[Perenista]

I am having a problem with both MKVToolnix and gMKVExtractGUI. This needs clarification because I am always confused about this.

Let's say I have two MKVs from a movie, a Blu-ray released in 2010 and another in 2020. Both are the same in terms of sync/length, just different discs.

Then I create a new audio track to be added to both. A dubbing.

Later I discover I need to introduce a positive delay of 1 second (or 1000 ms) while adding to MKVToolnix. So this works and track #2 is 100% synchronized with video #1.

This is WHAT I AM TRYING TO DO:

a) Remove track #2 from video #1 (from there only, assume I lost my original recording);
b) Add track #2 to video #2.

I always use gMKVExtractGUI for that extraction.

When I open this program I see that track has the 1000 ms information in there. This is also added to the file when we extract, so it's now being called track-2-1000ms.mp3.

My question:

If I simply add track #2 (after extracting from video #1) to video #2 it will be out of sync.

So that means I need to insert the 1000 ms information again?

That would be the logical next step.

Even if the answer is YES, what if I informed a positive (or negative) delay to subtitles? If I did that then I would have no way of knowing what to do next.

This is how gMKVExtractGUI is reading video #1:

https://i.postimg.cc/wTY6VLyp/X1.png

Are there any chances of these positive and negative delays not working with some players/hardware? At least in my PC I never had issues.

Of course if we are talking about SRT subtitles, for example, it would be better to already add the positive delay with a dedicated program:

https://i.postimg.cc/FKY5mHdp/X2.png

In this case Subtitle Workshop, which adds 1 second to the entire file.

That would spare MKVToolnix from doing the same.

But we can't insert a 1 second of silence into a MP3 or any other track without reencoding, which is why when needed I always insert these delays using MKVToolnix.

[von Suppé]

Using MKVToolnix for years, I never tried delays on subtitles so I couln't tell you about player issues for that matter.
I don't know whether MKVToolnix would define srt-delay by header or that it will adjust the timestamps within the srt itself.
I think that, for your own reassurance, it may be a good idea to make a sample mkv where you apply delay on srt (maybe two srt's: one with postive and one with negative value). After that, demux the mkv and compare the "original" srt to the demuxed one(s). Then you can make out how MKVToolnix handles srt delays, my guess.

BTW, a bit off-topic, but beware that negative delays on audio means that MKVToolnix will simply chop off the given time from the beginning of the soundtrack. Thus, that (small) part will be lost in the mux and can't be recovered.

[Atak_Snajpera]

How to correctly convert this command line
"mkvextract.exe" tracks "C:\video.mkv" 1:"C:\Temp\RipBot264temp\job1\audio.opus"

to json file?

I tried that...
[
"tracks",
"C:\\video.mkv",
"1:",
"C:\\Temp\\RipBot264temp\\job1\\audio.opus"
]

...and i got this error
https://i.postimg.cc/9MtmhbYn/Capture.png

[Mosu]

a) Remove track #2 from video #1 (from there only, assume I lost my original recording);
b) Add track #2 to video #2.

I always use gMKVExtractGUI for that extraction.

Why? You should rather simply remux from the original Matroska file. Add the first file. Deactivate muxing of track #2. Add the second file. Deactivate everything but track #2 from the second file. Multiplex.

Extraction is a lossy process as a lot of information (most importantly timestamps, but also track languages, titles etc.) cannot be stored in the elementary streams produced by mkvextract.

When you mux directly from Matroska you don't have to worry about losing existing delays.

Extraction should only be necessary if you need modifications to the content of a track, e.g. re-encode to a different codec or change the wording in subtitle tracks.

As for delays, there's a FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Delay-not-shown-in-the-GUI) about how delays work in Matroska files.

Of course if we are talking about SRT subtitles, for example, it would be better to already add the positive delay with a dedicated program:

Both that external program as well as mkvmerge simply modify the timestamps by adding your delay. It's the same modification.

[Mosu]

How to correctly convert this command line
"mkvextract.exe" tracks "C:\video.mkv" 1:"C:\Temp\RipBot264temp\job1\audio.opus"

to json file?

Command line arguments are split on spaces not enclosed in quotation marks. Your command line has three arguments, not four. Therefore the correct JSON is:

[
"tracks",
"C:\\video.mkv",
"1:C:\\Temp\\RipBot264temp\\job1\\audio.opus"
]

"The file could not be opened or parsed" usually means that the source file's name is wrong. Are you sure your source file is located directly in C:\ ? Another possibility is that the video.mkv is still open in another program that has a exclusive lock on it.

[Atak_Snajpera]

Ok! Thanks mosu. Problem solved.

[Mosu]

With the "no support for DV two separate files" in your last post there, I assume you mean when importing previously demuxed BL and EL streams?

After reading up about Dolby Vision some more[1][2], I'm more confident in my wording. As far as I understood things, Dolby Vision always comes with a Base Layer (BL) and, depending on the profile, might come with a second layer, the Enhancement Layer (EL). There are two different ways to store that Enhancement Layer:

Intermixed with the Base Layer in a single track. The EL NALUs are transported as NALUs of type UNSPECIFIED_63. If the container has global codec initialization data (e.g. MP4 or Matroska), the track headers might store an HEVCDecoderConfigurationRecord for that Enhancement Layer in addition to the HEVCDecoderConfigurationRecord & the DolbyVisionConfigurationRecord for the Base Layer. For MP4 files, the HEVCDecoderConfigurationRecord for the Enhancement Layer is stored in a hvcE atom. Alternatively the data (VPS, SPS & PPS of the EL) can be stored in the bitstream wrapped into UNSPECIFIED_63 NALUs. For containers that do not have global codec initialization data (e.g. MPEG transport streams), the Enhancement Layer initialization data can only be transmitted in the bitstream wrapped as UNSPECIFIED_63 NALUs.
As two separate tracks: the Base Layer and the Enhancement Layer are a track each, the container signals their connection somehow (MP4 & MPEG-TS do this differently). Containers with global codec initialization data (MP4) will only use one regular HEVCDecoderConfigurationRecord (hvcC atom in MP4) for each track and a DolbyVisionConfiguration (dvcC or dvvC for MP4) for… one of them (EL?), but there will be no hvcE atom necessary.

What mkvmerge 57.0.0 already supports is reading single-layer DV from MP4 & Matroska as well as dual-layer-with-both-layers-in-the-same-track from MP4 & Matroska.

What mkvmerge will support soon (see MR 2232 (https://gitlab.com/mbunkus/mkvtoolnix/-/merge_requests/2232)) is reading single-layer DV from raw HEVC elementary streams (ITU-T H.265 Annex B) or from MPEG transport streams.

What mkvmerge will NOT support anytime soon is reading dual-layer DV with the BL & the EL being in different tracks, no matter where they might come from (MP4, MPEG-TS, HEVC elementary streams in different files) for two reasons:

Matroska doesn't have facilities to flag that two tracks belong together in the way required for it.
It is unclear if it would be possible to convert dual-layer-in-two-tracks to dual-layer-in-single-track by simply re-wrapping/converting the regular HEVC NALUs of the EL to the UNSPECIFIED_63 style NALUs intermixed with the BL. Finding information about that is… hard, and the specs are obviously not public.

Does that makes things clearer?

[1] "Dolby Vision Streams Within the ISO Base Media File Format" (https://dolby.my.salesforce.com/sfc/p/#700000009YuG/a/4u000000l6FB/076wHYEmyEfz09m0V1bo85_25hlUJjaiWTbzorNmYY4)
[2] "Dolby Vision in MPEG-TS" (https://professional.dolby.com/siteassets/content-creation/dolby-vision-for-content-creators/dolby-vision-bitstreams-in-mpeg-2-transport-stream-multiplex-v1.2.pdf)

[Perenista]

Why? You should rather simply remux from the original Matroska file. Add the first file. Deactivate muxing of track #2. Add the second file. Deactivate everything but track #2 from the second file. Multiplex.

Extraction is a lossy process as a lot of information (most importantly timestamps, but also track languages, titles etc.) cannot be stored in the elementary streams produced by mkvextract.

When you mux directly from Matroska you don't have to worry about losing existing delays.

Extraction should only be necessary if you need modifications to the content of a track, e.g. re-encode to a different codec or change the wording in subtitle tracks.

As for delays, there's a FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Delay-not-shown-in-the-GUI) about how delays work in Matroska files.

Both that external program as well as mkvmerge simply modify the timestamps by adding your delay. It's the same modification.About my message, this is what I discovered:

- If you add any audio/subtitle track and insert a delay (let's say 1 second or 1000 ms, positive), then that information is stored in your Matroska, but the track itself remains untouched.

So 1000 ms is just an internal information like the language your track reffers to, if it's a forced subtitle, etc. The track itself of course is not modified, because there's no reencode, so the 1000 ms was not permanently inserted into it. This was a confusion I made in the past, because I am always moving these from one source to another.

And since there's no reencode it's true that if it's reading that way:

https://i.postimg.cc/wTY6VLyp/X1.png

Then that "descriptive" track once extracted I'll need to inform MKVToolnix again it has to add a 1820 ms delay, if I put into another video.

With subtitles, no matter what (SRT, VobSub or PGS) this information is not being displayed (see above), but again they are not being modified, so even if you added a 5000 ms positive delay into your MKV the subtitle track is untouched.

What I have been doing here in order to check if two videos are in sync is to skip to a specific scene, say, at 29m32s-500s, and freeze at that moment. If video #2 happens to be at this exact moment with a very small variation, say, 29m32s-450s, then we know they may be from different sources, however are the same (other moments need to be checked because it may be in sync for the first 30 minutes, then gradually change).

Example: Jurassic Park (1993) in UHD/4K and 1080p Blu-ray, no differences there, for the entire movie (note: some movies do have a difference, it may be a small one, say, 200 ms, others more, usually 1 or 2 seconds).

I didn't know it was possible to simply add one specific content/track from one MKV inside another.

I thought you always had to extract anything, otherwise it wouldn't work somehow.

Really, you just have to disable the other tracks that you don't want to add there.

[Mosu]

You're not entirely wrong, but not entirely right either.

When you use a delay in Matroska what happens is that the timestamps are modified but not the frame content.

Whether or not that modification survives a roundtrip through extraction & re-muxing solely depends on the container used during extraction. For example, AC-3 tracks are written to raw AC-3 files, and those do not support timestamps. Therefore modification of Matroska's timestamps don't survive extraction. (Things are slightly different with negative delays as in that case frames are actively dropped during the initial muxing step, and of course those cannot be re-inventeded during the extraction. For example, if you have a delay of -400ms and each frame is 32ms long, then mkvmerge would drop 13 frames (-400ms + 13 * 32ms = 16ms). Of course you don't have to specify -400 again if you extract & remux as that would drop ANOTHER 13 frames. Instead you'd have to specify 16ms now.)

All subtitles formats, on the other hand, always contain timestamps, and therefore modification to Matroska's timestamps do survive an extraction of a subtitle track to a subtitle file.

Really, you just have to disable the other tracks that you don't want to add there.

Exactly. Don't extract. Just… don't.

[von Suppé]

Does that makes things clearer?
Your explanation absolutely does.
Thanks for taking the time to do the reading on Dolby Vision.

[SeeMoreDigital]

What mkvmerge will NOT support anytime soon is reading dual-layer DV with the BL & the EL being in different tracks, no matter where they might come from...

Out of interest what needs to come first... A new dual-layer Dolby Vision compliant .mkv file parser or the muxer?

[Mosu]

Your explanation absolutely does.
Thanks for taking the time to do the reading on Dolby Vision.

I've also created FAQ page (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status) detailing the support status for Dolby Vision.

[Mosu]

Out of interest what needs to come first... A new dual-layer Dolby Vision compliant .mkv file parser or the muxer?

Well, I can certainly finish the muxer part without having a way to play them (for dual-layer with both layers in the same track, mind you! both layers in different tracks would require extending the Matroska specs with a couple of new elements & a hefty amount of changes to MKVToolNix). What needs to be done in MKVToolNix is:

mkvmerge will need to gain support for parsing single-layer DV from Annex B type bitstreams/MPEG transport streams. This basically means finishing the existing merge request (which looks pretty finished at the moment, I just have to test & merge the latest variant).
mkvmerge needs to parse the UNSPEC_63 NALUs for the parameter set NALUs. From those it will be able to create the hvcE configuration. That will not be that hard to do, actually; what I'm primarily lacking is a set of files to test with. I do have dual-layer MP4 files with UNSPEC_63 NALUs, but those do not have the parameter set NALUs in the bitstream; they're only present in the track headers' hvcE atom.
mkvextract must be able to convert the hvcE atom back into UNSPEC_63 parameter set NALUs and insert them at the right place. This is actually much more work than step 1, and I'm unclear about the syntax & semantics of two specific bytes within the UNSPEC_63 NALUs that I would have to recreate somehow.

So yeah, having dual-layer-both-layers-in-same-track sample files would definitely help.

[Mosu]

Heyo,

Summer is here, and so is MKVToolNix v58.0.0. Unlike the previous releases a lot more time has gone into it. The most noticeable change (to end users at least) is how the "default track" flag is handled, bringing it up to how the latest spec says the flag should be handled by players. Another prominent change is which MIME types are used for attached fonts on Windows. See the news below for details on both changes.

There were a couple of changes for packages, though none of them should actually require work on recent distros. Again, see the news below for details.

Last, but not least: get vaccinated if at all possible, y'all!

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

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

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

Version 58.0.0 "Supper's Ready" 2021-06-13
New features and enhancements

mkvmerge, MKVToolNix GUI's multiplexer: the handling of the "default track" flag has been changed to match the recent changes to the Matroska specifications. The new semantics are that if it is set, it is supposed to signal to the player that this track is eligible for being played by default, potentially taking other factors such as user preferences regarding languages into account. This implies that more than one track of each type can have this flag set. For example, a Blu-ray disc with three audio tracks might have the main audio in both English and Japanese, whereas the third audio track contains the director's comments. In such a case the first two tracks should have the "default track" flag set, the third one shouldn't. Earlier "mkvmerge" was enforcing that only one track of each type could have the flag set. This restriction has been removed, both in "mkvmerge" and in the GUI's multiplexer. "mkvpropedit" and the GUI's header editor are unaffected as they've always allowed to set the flag on as many tracks as the user wanted.
mkvmerge: AVC/H.264 & HEVC/H.265 identification: added the stream's pixel dimensions (AVC only; were present for HEVC already) & default duration. Implements #3116 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3116).
mkvmerge, mkvextract: HEVC/H.265: added support for reading single-layer Dolby Vision from Annex B type bitstreams (elementary streams, MPEG transport streams). Patch by quietvoid. Implements #3113 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3113).
mkvinfo: the option "-X"/"--full-hexdump" now affects all binary elements, not just the frame data in "SimpleBlock" and "BlockGroup" elements.
MKVToolNix GUI: multiplexer: the "delay" and "sync" options can now be used for chapters in source files, too. Implements #3129 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3129).
MKVToolNix GUI: when moving list entries up & down with the optional buttons or the keyboard shortcuts (instead of using drag & drop), the GUI ensures that the top-most selected entry remains visible after the move. Implements #3123 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3123).
MKVToolNix GUI: added an option in the preference to use legacy MIME types for font attachments instead of the current standard ones (e.g. 'application/x-truetype-font' instead of 'font/sfnt' and 'font/ttf').

Bug fixes

build system: fixed filtering out optimization options when compiling the file "iso639_language_list.cpp" (before only numeric optimization levels were filtered out and only if it wasn't the last option in the list of flags). See #3105 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3105) for context.
build system: when libmagic was detected via "pkg-config", MKVToolNix was actually compiled without support for libmagic due to a preprocessor symbol not being defined.
mkvmerge: MP4 reader: fixed an issue with timestamps overflowing when the file's or the track's time scale is large. Fixes #3124 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3124).
mkvmerge, mkvextract: fixed key frame handling for "BlockGroup" elements with a forward reference but no backward references. Patches by Tom Yan.
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: the programs will no longer omit writing mandatory elements set to their default value if other elements of the same type are present in the same master. This affects mostly the "chapter language" element which may occur multiple times within the same "chapter display" master. If it does occur multiple times and one of them is set to "English" (which is that element's default value), that element will now be written, too. Part of the fix of #3120 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3120).
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: when parsing chapter files IETF & legacy language elements as well as legacy country elements will now be properly generated depending on which exist already, especially when there's more than one language and/or country element in a "chapter display" element. Part of the fix of #3120 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3120).
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: fixed reading OGM-style chapter files with timestamps that don't have exactly three decimal places. Any number of decimal places between one and nine is now supported for nanosecond precision. Fixes #3121 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3121).
MKVToolNix GUI: chapter editor: added/fixed support for "chapter display" elements with multiple languages or countries. Part of the fix of #3120 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3120).

Build system changes

Qt 6: added support for building with Qt 6. "configure" will look for Qt 6 first and only continue looking for Qt 5 if Qt 6 isn't found or disabled via "--disable-qt6". Qt 6 detection works by first looking for the "qmake6" binary. Its location can be specified with the "--with-qmake6=…" option. All other Qt 6 related facts (such as compiler & linker flags or the position of the other required tools such as "lconvert", "moc", "rcc" and "uic") will be derived from the output generated by "qmake6". Note that at this point Qt 6 is not yet supported for the cross-compilation build to Windows, nor is a static Qt 6 build supported yet. Note that the command line options "--enable-static-qt", "--with-qt-pkg-config-modules" and "--without-qt-pkg-config" only apply to the Qt 5 and have no effect on Qt 6.
Qt 5: the options for specifying the position of the tools ("--with-moc=…", "--with-rcc=…" and "--with-uic=…") have been removed. Their position will now be derived from the output generated by "qmake".
"configure": completely disabling the GUI now requires passing both "--disable-qt6" and "--disable-qt" options.
Boost's multi-precision library is now required.
Boost v1.66 or newer is now required.

Other changes

The Windows build is now using an updated version of the "file"/"magic" library for MIME type detection of attachments. This affects fonts whose MIME types will now be the current standard MIME types (e.g. "font/sfnt" or "font/ttf" for TrueType fonts). As this might pose problematic with older players that only support the legacy MIME type (e.g. "application/x-truetype-font"), a new option was added in the GUI's preferences to use the legacy MIME types instead of the current standard ones. This is off by default. Builds for other operating systems have already been using newer versions of the "file"/"magic" library for a long time.



Have fun 😁

[Klaus1189]

Thanks for new version. Is it intended that v58.0.0 is not digitally signed? I have no problem with it but I recognzed it.

[Mosu]

Huh? Both the installers & the executables after installation are signed; I just re-checked (explorer → right-click on exe → properties → tab "Digital signatures") to make sure. Same for the exes in the 7z archives. So… what exactly are you talking about?

[Mosu]

Ugh, looks like the timestamp signature authority service is… somewhat broken? Dunno. I'll switch to a different one for the next release.

[Liisachan]

In my tests on Windows, GUI recognizes by default:
- .ttf as font/sfnt (technically correct) rather than font/ttf
- .otf as application/vnd.ms-opentype (still legacy?) rather than font/otf (or font/sfnt)
- .ttc as font/ttf (wrong?) rather than font/collection

For the standardized font mime types, one can check https://www.iana.org/assignments/media-types/media-types.xhtml#font

[Mosu]

Yeah, I've upgraded the "file" library used for MIME type detection, and it seems it isn't that good at that. Someone else already opened an issue for it. I plan to replace it by using Qt's MIME type detection which seems to work correctly with my (very) limited set of test files (both OTF & TTF fonts), but that requires quite a bit of work on the code in "configure", which is easily my least place to work in.

As stated in the NEWS file, there is an option in the preferences to use the MIME type that the Windows version of MKVToolNix had used for TrueType fonts (.ttf, not font collections) up until v57, application/x-truetype-font. You can enable that for the time being.

[odino]

Hi Moritz,
sorry to waste your time with this silly question but:
when I select "CTRL+D" (and probably other functions) the default destination file name changes from single slash to double slash. I know both are correct but is there actually a reason for this? I mean, either start the default with double slash or just leave it single all the time, right? lol
I also don't remember this happening before a few versions ago.

Greetings

[Mosu]

@odino I don't follow. For me nothing changes in the destination file name when I press Ctrl+D. Can you please be a bit more specific? What exactly is the destination file name set to before you press Ctrl+D, and what does it change to? And which operating system & which MKVToolNix version are you using?

[asarian]

I would love for compression "determine automatically" to be disabled by default, subsidiarily, an option to keep my choice to disable compression. It's frankly a bit of silly thing to have it enabled, in this day and age of 4K HDR10+ content. Stop marketing your software like any other cheap xvid bot. :)

[Asmodian]

It's frankly a bit of silly thing to have it enabled, in this day and age of 4K HDR10+ content.

I consider it a bit silly to not enable it in this day and age of massive computing power.

It is lossless compression and is basically universally supported. Why wouldn't you want it enabled?

[mood]

@Mosu after install MKVToolNix 58 rev 14

give me this error "share\misc\magic" could not be found in the installation folder.

[Mosu]

@Mosu after install MKVToolNix 58 rev 14

give me this error "share\misc\magic" could not be found in the installation folder.

This is a spurious error you can ignore. I've already fixed that yesterday locally, but I haven't pushed that commit to the repository yet. The program will work fine even with the warning shown as libmagic isn't used for MIME type detection anymore — that installation check is simply something I forgot to remove.

[Mosu]

I would love for compression "determine automatically" to be disabled by default

As said, this is lossless compression supported everywhere. On top of that mkvmerge only uses compression for subtitle tracks by default anyway, not for audio or video tracks.

That being said: Preferences → "Multiplexer" → "Default values" → "Disable additional lossless compression for all track types".

[asarian]

I consider it a bit silly to not enable it in this day and age of massive computing power.

It is lossless compression and is basically universally supported. Why wouldn't you want it enabled?

Because it takes an insane amount of sheer wasted time. The notion that mkvnix can compete with/outdo x265, compression-wise, is frankly, a bit delusional. But if mkvnix can significantly compress a HEVC stream, losslessly, beyond what x265 already could, and all in ca. 30 minutes, then I doff my cap at you. :) But I doubt it.

[asarian]

As said, this is lossless compression supported everywhere. On top of that mkvmerge only uses compression for subtitle tracks by default anyway, not for audio or video tracks.

That being said: Preferences → "Multiplexer" → "Default values" → "Disable additional lossless compression for all track types".


This good info to have. :goodpost:

[SeeMoreDigital]

It is lossless compression and is basically universally supported. Why wouldn't you want it enabled?
Indeed... It's 'hardware' media player friendly!

[nevcairiel]

Because it takes an insane amount of sheer wasted time. The notion that mkvnix can compete with/outdo x265, compression-wise, is frankly, a bit delusional. But if mkvnix can significantly compress a HEVC stream, losslessly, beyond what x265 already could, and all in ca. 30 minutes, then I doff my cap at you. :) But I doubt it.

Except it doesn't do any of that, all it compresses is subtitles. As Mosu already mentioned above your post.

It costs no measurable amount of time.

[asarian]

Except it doesn't do any of that, all it compresses is subtitles. As Mosu already mentioned above your post.

It costs no measurable amount of time.

Okay, thx guys. I see the source of my confusion now.