MKVToolNix v8.6.1 released

Hey,

Just one day later, another release of MKVToolNix: v8.6.1. I’m therefore including and extending the previous announcement.

The next release of MKVToolNix is available: v8.6.0. Like the previous couple of releases this one focuses on bug fixes primarily. However, it also introduces one interesting new feature with support output mkvmerge’s identification result as JSON for improved scripting.

There’s also an important change breaking backwards compatibility: text files created by the tools (e.g. chapters extracted with mkvextract or redirected output of any of the tools) won’t start with a byte order mark (BOM) anymore, even if they’re encoded in one of the UTF-* encodings. Back in the day people believed that text files would be encoded primarily in UTF in the future and that distinguishing between those formats automatically with a byte order mark seemed sensible.

Reality has shown that things turned out differently: text files are overwhelmingly encoded in UTF-8 if they originate on Linux/Unix/Mac OS and in Windows’ local encoding otherwise. Writing byte order marks isn’t recommended anymore anyway.

This is an experimental change in so far as I’m willing to reverse it if enough people speak out for keeping the BOMs. So if you have legitimate concerns about this then please drop me a line.

An important change for package maintainers is that gcc 4.8.0 or newer/clang 3.4 or newer is now required for compilation due to the (header-only) library used for generating the JSON output. This concerns CentOS 6 and Debian 7 “wheezy” for which I don’t offer binaries anymore as a consequence.

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

You can download the source code or one of the binaries.

Here’s the full ChangeLog since v8.5.2:

  • 2015-11-29 Moritz Bunkus <moritz@bunkus.org>
    • Released v8.6.1.
    • mkvpropedit, GUI’s chapter & header editors bug fix: in certain situations the modified file would not contain a seek head before the first cluster anymore resulting in most players not finding elements such as attachments or the index located at the end of the file anymore. Fixes #1513.
    • mkvmerge: bug fix: the change to do a deeper file analysis if no seek head was found was causing huge increases in file type detection time as popular tools like x264 don’t write seek heads. The way elements at the end are searched has been changed to only scan the last 5 MB of the file instead of iterating over every level 1 element from the beginning of the file.
  • 2015-11-28 Moritz Bunkus <moritz@bunkus.org>
    • Released v8.6.0.
    • all: change: none of the tools will write a byte-order mark (BOM) to text files encoded any of the UTF-* schemes anymore.
  • 2015-11-25 Moritz Bunkus <moritz@bunkus.org>
    • mkvmerge: Matroska reader bug fix: the info about which packetizer is used was output twice for each HEVC track. Fixes #1522.
    • MKVToolNix GUI: bug fix: implemented a workaround for a bug in Qt which caused the GUI not to start anymore due to failing to detect a stale lock file if the GUI had crashed before on a computer with a host name that included non-ASCII characters. See https://bugreports.qt.io/browse/QTBUG-49640
  • 2015-11-22 Moritz Bunkus <moritz@bunkus.org>
    • mkvmerge: bug fix: a track’s number of bits per audio sample wasn’t output in verbose identification mode even if it was present in the file.
    • mkvmerge: enhancement: if no seek head is found before the first cluster when reading Matroska files then mkvmerge will attempt a deeper scan of all elements in the file in order to find track headers, attachments, chapters and tags located at the end of the file. See #1513 for the rationale.
  • 2015-11-21 Moritz Bunkus <moritz@bunkus.org>
    • MKVToolNix GUI: header editor bug fix: the "status" description wasn’t adjusting its height properly resulting in its text being cut off. Fixes #1517.
    • MKVToolNix GUI: bug fix: the program changes its working directory to the user’s profile/home directory on startup allowing the removal of its installation folder even if a program started by the GUI (e.g. a web browser) is still running. Fixes #1518.
    • ebml_validator: bug fix: elements with an unknown size weren’t handled correctly.
    • build system: fixed building and linking against libEBML and libMatroska if they’re installed in a non-standard location.
    • mkvpropedit, MKVToolNix GUI’s chapter and header editors: the tools were unable to update elements in files without a seek head present. Fixes #1516.
  • 2015-11-15 Moritz Bunkus <moritz@bunkus.org>
    • mkvmerge: bug fix: fixed two issues causing mkvmerge to write invalid data when updating track headers caused by the fix for "Re-rendering track headers: data_size != 0 not implemented yet". Fixes #1498.
    • all: MKVToolNix now requires gcc 4.8.0 or later or clang 3.4 or later for compilation.
  • 2015-11-14 Moritz Bunkus <moritz@bunkus.org>
    • MKVToolNix GUI: bug fix: the options for linking to the next/previous segment UID were wrong. Fixes #1511.
  • 2015-11-10 Moritz Bunkus <moritz@bunkus.org>
    • mkvmerge: enhancement: added JSON as an output format for file type identification. It can be activated with "–identification-format json –identify yourfile.ext" (or their short counterparts "-F json -i yourfile.ext").
  • 2015-11-09 Moritz Bunkus <moritz@bunkus.org>
    • mkvmerge: bug fix: the VC-1 handlig code was duplicating the first sequence headers with each mux. Fixes #1503.
  • 2015-11-08 Moritz Bunkus <moritz@bunkus.org>
    • build system: bug fix: configure was checking for and using libintl if –without-gettext was used. Fixes #1501.

Have fun.

10 thoughts on “MKVToolNix v8.6.1 released

  1. Richard

    There is a problem on versions 8.5.2 thru the current 8.6.1, which was not present in 8.5.1 or any earlier version.

    Versions 8.5.2 and later (including the current version) do not work on computers with CPUs that do not support the SSE2 instruction set. The main computer I use does not support SSE2 although it does support the original SSE instruction set. It uses an AMD Sempron processor I got brand new in early 2005. I was unlucky in that I bought a new computer with one of the last non-SSE2 CPUs ever made.

    This problem only occurs with the GUI programs, not with the command-line ones. The command-line ones still work on a computer with no SSE2 support. And the GUI programs worked fine up thru version 8.5.1. The command-line programs still work on my non-SSE2 computer even with the current version, it’s just the GUI programs with this issue. They crash immediately on startup before showing anything, that is very characteristic of using an unsupported CPU instruction set, and I have seen it happen with many other programs.

    Oh right, and this is for your compiled executables for Microsoft Windows, and I am using the 32-bit installers, for all of those different versions. I don’t know what compiler you use (whether it’s GCC, Microsoft, Clang, etc.) but all of those compilers offer different CPU targeting options and I’d suggest targeting the earliest possible CPU target there is so it supports as many computers as possible (e.g. the /arch:IA32 option for Microsoft compilers, or the i386 target for GCC).

    Apparently QT since version 5.3 has assumed SSE2 support without doing any runtime checks to see if those instructions are supported (assuming things without checking first is a bad programming practice but unfortunately one that is all too common in software nowadays), and since your GUI uses QT 5 you should use the -no-sse2 option in QT 5’s config to get around this bug in QT of not even checking for CPU instruction support. There is info about this at the top search results here: https://www.google.com/search?q=no+sse2+qt (search results for “no sse2 qt”).

    So yeah, this breaks ALL 32-bit AMD CPUs ever made (although since some time in 2005 AMD has only been making 64-bit CPUs). It also breaks support for Intel’s Pentium 3 but Intel stopped manufacturing those several years earlier and they never reached the clock speeds of the 32-bit AMD chips that were made prior to AMD64 (AMD64 support was added to AMD chips at the same time as SSE2 support, so as a result all 64-bit chips from Intel OR AMD support SSE2, but none of AMD’s 32-bit chips support it). Since AMD has been the 2nd largest CPU manufacturer for PCs for many years, and AMD didn’t fully transition from 32 to 64-bit until 2005 (with their 32-bit chips not supporting SSE2), there are a lot of computers out there that don’t work with software that requires SSE2. This is not to mention the fact that many of the Athlon XP and Sempron chips made around that transition time are quite fast chips that are faster than typical Intel Atom CPUs being manufactured right now in the current year 2015! Non-SSE2 CPUs are fully supported by all versions of Windows prior to 8.1, everything up to Windows 8.0 (including XP, Vista, 7, 8, and all the pre-XP versions).

    Anyway it would be nice if you could fix this (probably you need to use the right config options with QT 5 to disable SSE2).

    MKVToolNix has never required SSE2 in the past and this appears to be caused by a bug in QT 5.3 and later and not intentional on your part so I am just letting you know about this, and that it was introduced in version 8.5.2 of MKVToolNix and didn’t exist in 8.5.1 or earlier. The changelogs on your blog don’t show any change between those 2 versions that would explain why this happened. I’ve looked at the history of changes on Git and the only one that seems like it could possibly be the cause is this one:

    https://github.com/mbunkus/mkvtoolnix/commit/074347bbc663638d950356880248a058a37761a7

    It’s called “Windows build instructions: remove obsolete configure arguments for Qt”. I think perhaps that one might have caused this bug. I don’t see any other changes in between the 8.5.1 and 8.5.2 releases that relate to Qt. It’s possible maybe you upgraded versions of Qt that you compile with on your own machine as a dependency, too, I guess. That wouldn’t have showed up in the Git commit log but it could just as easily be the reason for the compiled executables for Windows for the GUIs not working on 32-bit AMD CPUs.

    Oh and there’s no danger of this affecting 64-bit builds since all 64-bit CPUs support SSE2 whether made by Intel or AMD. Only 32-bit chips are affected by this. However, it might affect other platforms besides Windows. Luckily, Mac OS X, when it switched to Intel chips, was using chips that supported SSE2 right form the beginning, so this wouldn’t be a problem on Macs. However it’s possible to be a problem on Linux or BSD systems since they work quite well on older CPUs, and apparently Linux users using 32-bit AMD chips have had issues with software that uses Qt 5.3 or later and it isn’t just limited to Windows, from what I have read about this Qt 5 issue on non-SSE2 chips. Then again, looking at the history of Qt releases, it’s more likely that you upgraded from Qt 5.5.0 to Qt 5.5.1 between those 2 releases of MKVToolNix, since Qt 5.5.1 came out on October 15th this year and Qt 5.5.0 dates back to July 8th, several months ago. I can’t really tell the exact cause of SSE2 code being included in the 32-bit Windows executables of the MKVToolNix GUI programs starting in version 8.5.2, but not in 8.5.1 or any prior version. Hopefully you can figure this out.

    Thanks.

    Oh and thanks for the “don’t remove DLLs” commit you did here: https://github.com/mbunkus/mkvtoolnix/commit/183572f2a33840b420e2d626a71bd2229ee6a713 so that it would work with gMKVExtractGUI installed in the same directory on Windows, something I requested in a comment on a previous post. Great job on fixing that so fast, I appreciate it!

    1. mosu Post author

      Yeah… Now that you mention it I do remember this particular issue. I’m using MXE as a cross-compiler for my Windows binaries with a couple of my own patches for various issues. Not too long ago I updated my MXE installation, and in that process I also removed some of my patches – among them the one for compiling Qt with SSE2 disabled as I couldn’t remember what I needed that for at that time. Now I do, so thanks for pointing it out :)

      I’ll re-compile the 32bit Qt and MKVToolNix in the next couple of days with SSE2 disabled. This is purely Qt; MKVToolNix doesn’t require any kind of SSE as you’ve correctly assumed; and I also don’t use compiler switches that enable it explicitely.

  2. vmrsss

    Hi Moritz, any idea why i get the following fatal error when trying to compile? I am on OS X 10.11 using clang 7.0. The latest version i was able to compile was 8.3.0. Thanks for your help.

    CXX src/merge/mkvmerge.cpp
    src/merge/mkvmerge.cpp:405:21: fatal error: no member named ‘make_unique’ in namespace
    ‘std’
    file.ti = std::make_unique();
    ~~~~~^
    1 error generated.

    1. mosu Post author

      I’m sorry, but I don’t I don’t support OS X. Compilation works for me (see the scripts in tools/macos/), and that’s as much time as I want to spend on OS X.

      Basically it has something to do with: compiler support for C++14; configure maybe not detecting the right compiler flags to use…

      1. vmrsss

        thanks mosu. do you mean it works for you on os x using the scripts in tools/macos? if so, i’ll try.

        1. mosu Post author

          The scripts in tools/macos are what I’ve used for compiling the libraries that MKVToolNix uses. They’re also what I use for building the actual DMG that I’m offering for download. Yes, they do work, but they aren’t documented and only tested on the single system I have access to.

          1. vmrsss

            Thank you Mosu. What version of OS X are you building the DMG on? Compilation for me used to work really smooth till Yosemite, but it broke down in El Capitan with this error:

            src/merge/mkvmerge.cpp:405:21: fatal error: no member named ‘make_unique’ in namespace ‘std’

            Are you building on Yosemite or earlier?

            Thanks

  3. Aver

    Keep up the good work Mosu, I know you receive a lot of hate from removing the old GUI, but I can see why you did it. It’s nice to see the new one come along I just don’t like how much screen-space is required to do the same tasks but it is also much easier to do certain things.

Comments are closed.