MKVToolNix v83.0 released

[Mosu]

Originally Posted by von Suppé

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

I've also created FAQ page detailing the support status for Dolby Vision.

[Mosu]

Originally Posted by SeeMoreDigital

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:

1. 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).
2. 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.
3. 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, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code.

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 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.
• 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.
• 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.
• 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.
• 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 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.
• 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.
• 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.
• 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.
• MKVToolNix GUI: chapter editor: added/fixed support for "chapter display" elements with multiple languages or countries. Part of the fix of #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/med...pes.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]

Originally Posted by asarian

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]

Originally Posted by mood

@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]

Originally Posted by asarian

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]

Originally Posted by Asmodian

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]

Originally Posted by Mosu

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.

[SeeMoreDigital]

Originally Posted by Asmodian

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

Indeed... It's 'hardware' media player friendly!

[nevcairiel]

Originally Posted by asarian

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]

Originally Posted by nevcairiel

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.