MKVToolNix v83.0 released

[Mosu]

Hey y'all,

this is more or less a small bugfix release of MKVToolNix. One rather important new feature is support for the new Matroska elements introduced for storing additional codec-initialization data needed for techniques such as MVC (3D video) or Dolby Vision metadata. mkvmerge cannot produce them itself yet, but it will keep the data that's present, e.g. when reading files created by MakeMKV.

Important news for package managers is that libMatroska v1.6.1 is now required (that one was released earlier today). As usual MKVToolNix bundles that version as a fallback.

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 49.0.0 "Sick Of Losing Soulmates" 2020-08-02
New features and enhancements

• mkvmerge: added support for copying the new track header elements "BlockAddIDName", "BlockAddIDType", "BlockAddIDValue" and "BlockAddIDExtraData" from Matroska files if they exist. Part of the implementation of #2887.
• mkvinfo: added support for the new track header elements "BlockAdditionMapping", "BlockAddIDName", "BlockAddIDType", "BlockAddIDValue" and "BlockAddIDExtraData". Part of the implementation of #2887.
• MKVToolNix GUI: multiplexer: the list of recent directories can now be edited in the preferences → "Multiplexer" → "Destination file name". Implements #2861.
• MKVToolNix GUI: preferences: the values in the various "predefined values" lists can now be re-ordered freely by dragging & dropping.

Bug fixes

• mkvmerge: Matroska reader: when reading tracks (e.g. a subtitle track) from Matroska files with their "default track" flag set to "yes", and when overwriting those via the command line to "no", "mkvmerge" would not promote additional tracks of the same type from other files (e.g. another subtitle track from an SRT file). Fixes #2863.
• mkvmerge: SRT reader: empty lines inside entries were doubled. Fixes #2888.
• mkvmerge: subtitles: when calculating the rounded duration of each entry the error from rounding the corresponding timestamp will be taken into account. Fixes #2890.
• mkvextract: SSA/ASS extraction: mkvextract is no longer inserting empty lines before the "Dialogue:" lines. Fixes #2876.
• mkvextract: USF subtitles: start & end timestamps were too high by a factor of 1.000.000. Fixes #2875.
• MKVToolNix: info tool: when saving to a text file the checkbox "Save as default for saving output to text files" did nothing. Fixes #2869.
• MKVToolNix: info tool: when saving to a text file in "all elements in a tree-like structure" mode, the GUI always stopped at the first cluster regardless of the setting of the "verbosity" option.
• MKVToolNix GUI: preferences: when tooltips were disabled the dialogs for adding new entries to the various "predefined values" lists were missing their texts.
• Windows installer: the images are shown again. Fixes #2868.
• configure: fixed detection of QtDBus. Fixes #2886.

Build system changes

• libMatroska v1.6.1 is now required. The bundled version has been updated to that version.

Have fun

[quietvoid]

Originally Posted by Mosu

One rather important new feature is support for the new Matroska elements introduced for storing additional codec-initialization data needed for techniques such as MVC (3D video) or Dolby Vision metadata. mkvmerge cannot produce them itself yet, but it will keep the data that's present, e.g. when reading files created by MakeMKV.

Thanks for the new release

I was playing with test samples and the headers seem to be kept just fine (mkvinfo says so at least).

I was wondering if there were plans to be able to edit these (block addition mapping, and all) with mkvpropedit (or the GUI), as they don't seem to be in the current list.
It's possible that is what you refer to for

mkvmerge cannot produce them itself yet,

[Mosu]

No plans for making those fields editable with mkvpropedit/the header editor. The reason is that they're codec-specific data. I don't make CodecPrivate available for editing either.

[quietvoid]

Okay, thanks for the info.

[ssjkakaroto]

Hey Mosu, can you tell me exactly what changed between v47.0.0 and v48.0.0/v49.0.0 regarding to Qt so I can try to open a bug report about the dual-monitor issue over the Qt bug tracker?

[Mosu]

Originally Posted by ssjkakaroto

Hey Mosu, can you tell me exactly what changed between v47.0.0 and v48.0.0/v49.0.0 regarding to Qt so I can try to open a bug report about the dual-monitor issue over the Qt bug tracker?

v47 was built with Qt 5.14.2, v48 with Qt 5.15.0. Apart from that no changes wrt. to monitor or menu or display handling were made on my end.

[Selur]

Small question about chroma sub sampling signaling.
From https://mkvtoolnix.download/doc/mkvmerge.html I gathered that for:

• 4:2:0 one should use 1,1
• 4:2:1 one should use 1,0

-> What should be used for '4:4:4' and 4:2:2' ?

[nevcairiel]

The wording of that option sure is bizarre, but either way, for 4:4:4 its clearly 0,0 since nothing is being removed. And 4:2:2 has full vertical resolution, so it should be 1,0.

I have never seen a MKV that uses that information though, when raw video is contained in MKV its usually with a FourCC to identify it or similar means, and encoded video carries that information in its bitstream.

[Mosu]

I actually don't know. Those options & the accompanying documentation was contributed by someone else.

[ssjkakaroto]

Originally Posted by Mosu

v47 was built with Qt 5.14.2, v48 with Qt 5.15.0. Apart from that no changes wrt. to monitor or menu or display handling were made on my end.

Hi Mosu, the bug with the popup menu will be fixed in Qt 5.15.1

[Mosu]

That's great, thanks! I usually update my build environment once a month and should pick up 5.15.1 quickly after its release.

[chros]

Originally Posted by Mosu

No plans for making those fields editable with mkvpropedit/the header editor. The reason is that they're codec-specific data. I don't make CodecPrivate available for editing either.

Hi Mosu! Thanks for your continous work on mkvtoolnix.
Do you know any util to do this? I'm asking because of this. (Although I don't even know whether it's possible without reencoding.)

[Mosu]

I strongly doubt that you can convert HDR formats without re-encoding.

[SeeMoreDigital]

Originally Posted by chros

Hi Mosu! Thanks for your continous work on mkvtoolnix.
Do you know any util to do this? I'm asking because of this. (Although I don't even know whether it's possible without reencoding.)

There's no need to convert HDR10+ to HDR10... As HDR10+ (and Dolby Vision) HEVC encodes already include mandatory HDR10 meta-data as a fall-back!

https://en.wikipedia.org/wiki/HDR10%2B

[chros]

Thanks, but for whatever reason the Oppo deal with HDR10+ in a different way. @butterw2 just wrote how to flag these differently using ffmpeg. That's what I need for experimenting. I'll continue with this in this thread.

[Mosu]

Hello everyhone,

another month, another MKVToolNix release. This one includes quite a high number of commits under the hood due to the prominent new feature I've implemented: support for the new IETF BCP 47 language elements. Finally you can express things such as "Portuguese as spoken in Brazil" or "Serbian in Cyrillic script as spoken in Serbia".

Apart from that there are the usual enhancements & bug fixes.

Important news for package managers is that the PCRE2 library is now required (only its UTF-8 variant).

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 50.0.0 "Awakenings" 2020-09-06
New feature: IETF BCP 47 language tags

• I've written up a nice FAQ entry about the switch to using IETF BCP 47 language tags, how they interact with legacy language elements, how the programs actually behave and how to disable their use if necessary.
• mkvmerge: IETF BCP 47/RFC 5646 language tags: mkvmerge will now accept full BCP 47 language tags for all options taking a language. mkvmerge will always write "LanguageIETF" track header elements. If the language tag contains a valid ISO 639-2 language code it will also set the legacy "Language" track header element to the included ISO 639-2 code. Part of the implementation of #2419.
• mkvmerge: IETF BCP 47/RFC 5646 language tags: if present the "LanguageIETF" track header element will be reported as the "language_ietf" property in JSON identification mode. Part of the implementation of #2419.
• mkvmerge: IETF BCP 47/RFC 5646 language tags in chapters: mkvmerge will now write "ChapLanguageIETF" elements when creating chapter atoms, either when reading the simple chapter format or when generating chapters due to the "--generate-chapters" command line option. Part of the implementation of #2419.
• mkvmerge: IETF BCP 47/RFC 5646 language tags in tags: mkvmerge will now write "TagLanguageIETF" elements when creating "simple tag" elements, either when reading tag XML files or when generating them. Part of the implementation of #2419.
• mkvmerge: IETF BCP 47/RFC 5646 language tags: added an option "--disable-language-ietf" that causes mkvmerge to only write the legacy language elements.
• mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: IETF BCP 47/RFC 5646 language tags in chapters: when reading XML chapter files the programs will now add "ChapLanguageIETF" elements for atoms that don't contain them. The values are derived from existing "ChapterLanguage" elements. Part of the implementation of #2419.
• mkvpropedit: IETF BCP 47/RFC 5646 language tags: setting/deleting the track language now acts on both the old language element as well as the "LanguageIETF" track header element. Part of the implementation of #2419.
• mkvpropedit: IETF BCP 47/RFC 5646 language tags: added an option "--disable-language-ietf" that causes mkvpropedit to apply changes to the "language" track header property only to the legacy language track header element.
• mkvinfo: IETF BCP 47/RFC 5646 language tags: added support for the "LanguageIETF" track header element. Part of the implementation of #2419.
• MKVToolNix GUI: multiplexer: added full support for IETF BCP 47/RFC 5646 language tags for both track and chapter languages. Part of the implementation of #2419.
• MKVToolNix GUI: chapter: added full support for IETF BCP 47/RFC 5646 language tags for chapter languages. Part of the implementation of #2419.
• MKVToolNix GUI: header editor: added full support for IETF BCP 47/RFC 5646 language tags for track header languages. The header editor allows editing of the legacy language elements and the IETF BCP 47 language elements independent of each other. Part of the implementation of #2419.

Other new features and enhancements

• mkvmerge: the chapter generation mode "when-appending" now also works with the splitting modes "parts:" & "parts-frames:" when using the "…,+…" syntax for appending other sections of the source file to the same destination file. Implements #2898.
• MKVToolNix GUI: multiplexer: the file selection dialogs now include the extension ".dtsma" for DTS files. Implements #2901.
• mkvmerge: MP4 reader: sped up parsing MP4 DASH files with a lot of segments ("trun" atoms) quite a bit. Part of the fix of #2900.
• The PCRE2 regular expression library is now used instead of "std::regex" for big performance improvements in all places where regular expressions are used for parsing big chunks of text, e.g. in the subtitle parsers. Part of the fix of #2899.
• all programs: Windows: all programs now support long file names on Windows 10 release 1604 if they're turned on in the registry. Implements #2916.

Bug fixes

• MKVToolNix GUI: preferences: under certain conditions changing the selected entry in the page tree on the left did not cause the page shown on the right to be updated. Fixes #2895.
• mkvmerge: splitting text by a fixed string (e.g. ",") is now done by using "std::string.find()" instead of using a regular-expression-based text splitting function, greatly improving its performance. Part of the fix of #2899.
• mkvmerge: mkvmerge will now read-buffer file I/O when probing text file formats which increases its speed significantly on Windows. Part of the fix of #2899.
• mkvmerge: MP4 reader: fixed handling of "tkhd" atoms of version 1. Fixes #2900.

Build system changes

• The PCRE2 library (the 8-bit variant) is now required.

[AYColumbia]

Thank you Mosu.

[Masutin]

1) Can the progress percentage appear in the CLI window title?
2) While lists of MKV files, as contents of storage media, appear in televisions, players, file managers or other interfaces, will attached images show as covers? They didn't in my case but I didn't try newer systems. Is the tag "Cover:Yes" required?

[Mosu]

Originally Posted by Masutin

1) Can the progress percentage appear in the CLI window title?

No, and I have no intention of implementing something like that.

Originally Posted by Masutin

2) While lists of MKV files, as contents of storage media, appear in televisions, players, file managers or other interfaces, will attached images show as covers? They didn't in my case but I didn't try newer systems. Is the tag "Cover:Yes" required?

From Matroska's side there is no official mechanism to mark attached pictures as cover images. Convention is to name them "cover.[ext]". If and how they're used is up to the software reading the files.

[Snowknight26]

Just from a usability standpoint, it's no longer possible to select a track in the multiplexer input panel, click language, then quickly type 'eng' (or whatever you choose) for to select the language you want. Instead, you have to click the very small edit button which has a much smaller click area than the input field that used to show in there instead.

What's more interesting is, if you double click on the label next to the edit button, the "Extended subtags" dropdown receives focus and opens, making it even more inconvenient to try to change the language component (you have to close the dropdown, Shift+Tab to go to language, type in the letters, then press enter).

These changes add unnecessary user actions.

Instead, might I suggest keeping the language dropdown visible on the main multiplexer panel (while still having the edit button), allowing one to quickly change languages while still having the option of defining a more specific language tags through the edit button?