Here’s release v11.0.0 of MKVToolNix. There have been several important bug fixes to the HEVC/h.265 and AVC/h.264 parsers. Among the fixed bugs are some that will silently produce invalid files. I therefore recommend everyone to update.
This release includes a couple of smaller enhancements to the GUI as well. Noteworthy is the implementation of features that have been requested several in the past: playing a sound or shutting down the computer after the current job’s been completed. The implementation is very flexible and not limited to those two actions, though.
There have been several changes the package maintainers should be aware of, see the section “build system changes” below.
You can download the source code or one of the binaries. The Windows and macOS binaries have been built already and are available for download. The Linux binaries will be available later today.
Here’s the NEWS since the previous release:
New features and enhancements
- mkvmerge: FLAC reader: added support for handling embedded pictures as attachments. Implements #1942.
- mkvmerge: MP4 reader: merged pull request #1804 adding support for parsing the "COLR" atom and including its values as track headers.
- MKVToolNix GUI: watch jobs: the user can now have the GUI execute an action once as soon as the current job or the whole queue finishes. The actions are the same ones that can be configured to be run automatically after job or queue completion.
- MKVToolNix GUI: implemented several built-in actions that can be executed either on special events or once via the "watch jobs" tool. These are: playing an audio file (implemented for all operating systems); hibernating, sleeping and shutting down the computer (only implemented for Windows and for Linux systems using systemd).
- MKVToolNix GUI: multiplex tool: added a new option for what to do after starting to multiplex/adding to the job queue: "close current settings" will close the current multiplex settings without opening new ones.
Bug fixes
- mkvmerge: AAC parser: fixed mis-detection of certain data as valid ADTS AAC headers resulting in memory allocation failures. Fixes #1941.
- mkvmerge: AVC/h.264 parser: mkvmerge will now ignore bogus timing information in the sequence parameter sets (values indicating more than 100000 progressive frames per second). Fixes #1946.
- mkvmerge: AVC/h.264 & HEVC/h.265 parsers: all trailing zero bytes will now be removed from NALUs. Fixes #1952.
- mkvmerge: HEVC/h.265 parser: fixed copying the `bitstream_restriction_flag` and all dependent fields in the VUI parameters of the sequence parameter sets. Fixes #1924.
- mkvmerge: HEVC/h.265 parser: fixed the calculation of the number of parameter set arrays in the HEVCC data structure stored in CodecPrivate. Fixes the video-related part of #1938.
- mkvmerge: HEVC/h.265 parser: fixed writing superfluous and uninitialized bytes at the end of the HEVCC data structure stored in CodecPrivate. Another fix for the video-related part of #1938.
- mkvmerge: HEVC/h.265 parser: fixed the assumption that the HEVCC data structure always includes arrays for all parameter set types (VPS, SPS, PPS and SEI), and that the order is always VPS → SPS → PPS → SEI. Instead now only the arrays actually present are parsed, and they can be in any order. This fixes mkvinfo’s output for Matroska files created from files such as the one from #1938.
- mkvmerge: AVC/h.264 packetizer: when reading a framed track (e.g. from Matroska or MP4 files), specifying a default duration as fields (e.g. `50i`) would result in double the actual duration for each frame and the track’s default duration header field. Fixes #1916.
- mkvmerge: Matroska reader: invalid track language elements are now treated as if they were set to `und` = "undetermined". See #1929 for context.
- mkvmerge: MPEG TS reader, AAC: mkvmerge will now require five consecutive AAC headers with identical parameters before track type determination is considered valid. This avoids false positives and consequently wrong track parameters. Fixes the audio-related part of #1938.
- mkvmerge: fixed an endless loop in certain circumstances when splitting by `parts` or `parts-frames` and the start of the file is discarded. Fixes #1944.
- MKVToolNix GUI: multiplexer tool: the "show command line" dialog will no longer include the mkvmerge executable’s location as the first argument for the two "MKVToolNix option files" escape modes. Fixes #1949.
- MKVToolNix GUI, header editor: empty track language elements are now treated the same as those set to invalid ISO 639-2 codes: as if they were set to `und` = "undetermined". See #1929 for context.
Build system changes
- bug fix: configure now looks for the `strings` binary by using the `AC_CHECK_TOOL()` autoconf macro. That way it will be found in multiarch setups, too. Fixes #1923.
- bug fix: the environment variable USER_CXXFLAGS was accidentally removed from the compiler flags in release 9.8.0. It’s been re-added. Fixes #1925.
- The `.desktop` files have been renamed to `org.bunkus.mkvtoolnix-gui.desktop` and `org.bunkus.mkvinfo.desktop`. This allows Wayland compositors to associate the correct icons with running applications for e.g. task switchers. Fixes #1948.
- Qt’s multimedia component is required for compilation of the GUIs since version 11.0.0.
Have fun :)
As the new version is v11 instead of v11.0.0: Does this mean a change in the versioning scheme?
The current release is v11.0.0, not v11. I’ve fixed the blog post.
That being said: It was indeed my intention to switch to a dot-less version numbering scheme. Unfortunately I the existing version number parser code requires at least three components in a version number. I only found that out after having built almost all binaries for v11-without-any-dots and doing some final tests. Otherwise the new release would have been ready 8 hours ago.
I’ve fixed the version number parser to accept an arbitrary number of dot-separated components. However, existing installations in the wild won’t include that fix, obviously.
My revised plan is to switch to only increasing the major component of the version number from now on but keeping three components for the time being. Hence the current version number v11.0.0, instead of v10.1.0. After a year or so I will probably switch to using only a single component (that’ll probably be in the range of v19 – v22).
There has never been much of a great scheme behind the way MKVToolNix’ version numbers have been chosen. It does definitely not follow the semantic versioning scheme[1]. I tended to increase the second component for regular releases and the third for emergency releases, and the first one was simply incremented whenever the second one reached 10. So why not ditch that altogether? It doesn’t really convey that much information anwyay.
[1] http://semver.org/
Thanks for the explanation.
I agree that all three components are too much for the needs of MKVToolNix. Nevertheless in my opinion it still makes sense to be able to distinguish (by the third component) between normal releases and emergency ones. This way just by reading the versions number in the message subject of the RSS feed, one is able to either say “OK, I will check sometime later” or “Oh, I should check now if I have to update”. So I would regret the use of just a dot-less versioning scheme.
Perhaps it is an option for you to continue using a three component versioning scheme, but only increasing the major version (or the minor version) on new releases, and still use the third component for urgent fixes.
That I’d consider the worst possible option, to be honest. What good does the second component do if it’s never used?
You do have a point, though. Maybe I’ll switch to a two-component numbering scheme (11.0) with normal releases increasing the major component (11.0 → 12.0) and emergency releases increasing the minor component (11.0 → 11.1). For me the primary driver of this change is the meaningless distinction between major and minor component that existed in the old scheme, and going to a two-component scheme would fix that while keeping the emergency notification heads-up.
The second component does not make sense, but at least it keeps the component count at three.
Hmm, using two components seems to be the best way to handle this (“Königsweg”).
Thanks for a great program :)
I just have a question about the setting for output directory.
All my untouched files is in F:\New\*Folder Name With Date* and the processed files is stored on Y:\*Folder Name With Date*. Is it possible to make this happen without having to set the output directory manually for every file?
I’ve messed around with the ‘Directory relative to first input’s directory’ setting and using ../ and stuff but either it’s not meant to happen or I’m doing it wrong :D
If it’s the first reason would it be possible to add it in an upcoming version?
Cheers!
/Pontpet
Including variable parts such as the current date in the output file name is not support at the moment, and I don’t have plans for implementing something like that. Implementing variables always means a lot of work because users want them to be flexible (just think about all the different date formats out there, writing out month names instead of numbers etc.). On top of that a lot of documentation needs to be written. In short, it’s way more work than I’m willing to invest. Sorry.
Think you misunderstood me or I explained it badly.
I don’t want mkvtoolnix to figure out the current date to name the folder, that is already done by the program that creates the files that’s in the folder. I just want it to be able to preserve the folder structure (somewhat) but on another drive.
For example today I have files in five folders with different names (20170427, 20170428, 20170429, 20170430, 20170501) located under F:\New\ and I want them to end up in Y:\20170427, Y:\20170428 and so on.
So more or less I just want mkvtoolnix to exchange F:\New\ with Y:\ in the ‘Output file’-setting so that the file will end up in a folder with the same name as its original without having to change this manually for every file.
Hope that explains it better.
I see. That’s not possible at the moment, and I don’t have plans to implement something like that. Sorry.
However, you should be able to whip up a batch script that moves the files after multiplexing has finished. Then configure the GUI to run that script after each job. Such specific and custom workflows are the reason I’ve implemented that “run a program” feature in the fist place.
Didn’t think it would be such of a big task to fix it but OK, to bad.
Scripting stuff like that is out of my league so I’ll be stuck at doing it manually or find another program.
Hello there
Why is there no bulk multiplexing (conversion)? I’m doing video + subtitles and constantly re-open the window again this is too bad. It is best to have a series of 10 to 15 chapters all at once, with subtitles in one, and then converting or multiplying them all in one shot. There is such a program ” XviD4PSP ” very well they are doing this job. We’re waiting for you to do it. You are actually late. And now you have to go through a modern interface. 2017 is still using the WXP interface. A Metro interface is more useful
See https://github.com/mbunkus/mkvtoolnix/wiki/Batch-muxing-with-the-GUI for the answer why there’s no batch muxing.
> A Metro interface is more useful
I disagree.