MKVToolNix v99.0 released

[Mosu]

Windows < 10 hasn't been supported for years now. It isn't news.

[lvqcl]

Although the download page says about support for Windows 10 and newer (https://mkvtoolnix.download/downloads.html#windows)

The download page has a link to https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Officially-supported-operating-systems-and-versions:
Supported are all client versions of Windows (meaning Intel architecture) that Microsoft offers general support for.
This means that MKVToolNix stopped supporting Windows 7 a long time ago.

[filler56789]

69.0.0 - installs but does not run on Windows 7.
OUCH! *woman facepalming emoji*

Yeah, the installer shouldn't even run IF "Windows.version < 10".
But that's ""an irrelevant :rolleyes: detail"" for the ""geniuses"" who devilop the QT GUI. ;)

[FranceBB]

Thanks for the update, it works just fine on Fedora 36 x64.
I'm glad you had a swift recovery from COVID, it's never nice when you get it. I caught it in the middle of December 2021 even though I had 2 doses of Oxford Astra Zeneca + the Pfizer Booster, so... I know. :(

Anyway I'm glad you're feeling better and thanks for the new release! :)

[v0lt]

Windows < 10 hasn't been supported for years now. It isn't news.
It is possible that support was discontinued earlier (which did not prevent mkvtoolnix-gui.exe from working on these systems). But in which version this happened cannot be found in NEWS.txt and other text documents.

OUCH! *woman facepalming emoji*
...
I don't understand why you are so confused by the results of my test installs and application runs. This is just information for other users.

[Mosu]

I never mention in NEWS when I drop support for an operating system. 'cause that's not actually news about the code itself. It's just an operational decision.

Furthermore, I don't actually test whether a change breaks the programs from running on unsupported operating systems. That's part of the "unsupported" package — not receiving this kind of verification.

[tormento]

Furthermore
What happened to mkvtoolnix.download/windows/continuous/64-bit/69.0.0? I see it empty.

[Mosu]

A delete command gone awry. Will be populated with future builds, of course.

[tormento]

A delete command gone awry. Will be populated with future builds, of course.
Thanks :)

[filler56789]

I don't understand why you are so confused by the results of my test installs and application runs. This is just information for other users.

I was a programmer ""some time between 1973 and 1985"" :) ,
therefore it's difficult for me NOT to be annoyed by the post-modern programming "features" ;)

[tormento]

@Mosu

Since last version, I see many

--max-luminance 3:0 --min-luminance 3:0 --projection-pose-yaw 3:0 --projection-pose-pitch 3:0 --projection-pose-roll 3:0

in CLI command generated by GUI.

As I use it as reference to create batch files, could you please make them optional when of no use?

[Mosu]

That can definitely be improved, yeah. I'll look into it.

[Mosu]

Aaaand it's fixed.

[Selur]

How to properly signal 30000/1001 fps interlaced with mkvmerge v69.0.0 ('Day And Age') 64-bit?
Using '--default-duration "0:29.97i"':
mkvmerge --ui-language en -o "E:\Output\2022-07-17@08_45_40_5310__03.mkv" --global-tags "E:\Output\mkvtags_2022-07-17@08_45_40_5310__03.xml" -d 0 --default-track 0:yes --language 0:en --default-duration "0:29.97i" --aspect-ratio-factor 0:0.889 --chapter-charset UTF-8 --chapters "E:\Output\2022-07-17@08_45_40_5310__04.chp" --compression -1:none --forced-track 0:yes --field-order 0:6 --no-audio --no-subtitles "E:\Output\clip1_2022-07-17@08_45_40_5310_02.m2v" --track-name 0:"Japonês" --language 0:ja --default-track 0:yes --sync 0:6 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "E:\Output\iId_1_aid_0_lang_ja_DELAY_6ms_2022-07-17@08_45_40_5310_01.ac3"
and using '--default-duration "0:30000/1001i"':
mkvmerge --ui-language en -o "E:\Output\2022-07-17@08_45_40_5310__03.mkv" --global-tags "E:\Output\mkvtags_2022-07-17@08_45_40_5310__03.xml" -d 0 --default-track 0:yes --language 0:en --default-duration "0:30000/1001i" --aspect-ratio-factor 0:0.889 --chapter-charset UTF-8 --chapters "E:\Output\2022-07-17@08_45_40_5310__04.chp" --compression -1:none --forced-track 0:yes --field-order 0:6 --no-audio --no-subtitles "E:\Output\clip1_2022-07-17@08_45_40_5310_02.m2v" --track-name 0:"Japonês" --language 0:ja --default-track 0:yes --sync 0:6 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "E:\Output\iId_1_aid_0_lang_ja_DELAY_6ms_2022-07-17@08_45_40_5310_01.ac3"
both result in

Frame rate : 29.970 (29970/1000) FPS <- container
Original frame rate : 29.970 (30000/1001) FPS <- stream


Cu Selur

[Selur]

Okay, "0:30000/1001i", does seem to work as intended unless I use m2v video.
(For AVC content I need to use "0:60000/1001i" to get 29.970 (30000/1001) fps.)

[jpsdr]

@Mosu

There might be one more option. There seems to be modified QT6 version for Win7 here:
https://forum.qt.io/topic/133002/qt-creator-6-0-1-and-qt-6-2-2-running-on-windows-7
I've been already able to run another QT6 based software using that (Calibre 6.1 - https://calibre-ebook.com/download).
There you need to use as well VxKex to run it - https://github.com/vxiiduu/VxKex
But MKVToolnix seems to have QT embedded in main exe, so it is not possible just easily replace those binary files like for Calibre.

Do you think you can take a look at this ?

[Mosu]

Why would I? I don't support Windows 7.

[manolito]

--EDIT--
Issue solver. Please see here
https://forum.doom9.org/showthread.php?p=1973494#post1973494

Please bear with me, after my stroke last year I am quite ignornt with my computer. But I try to come back a little one step after the other...

My current problem is with some clips in the .TS format from the internet (I cannot post them here since they are quite explicit). The clips are VFR, and they play well in my players. I want to repack them to MKV or MP4 to be able to add chapters (also my XTreamer box is not too happy with .TS files), but after the conversion with MKVToolNix or MkvToMP4 audio will be out of sync.

I do not want to reencode the clips, I just want to repack them to a different container plus adding chapters. This must be possible because after fooling around a little bit using different software, I found that the very old YAMB 2.0 can do this without any problems.

It would be nice if I could somehow convince MKVToolNix to do the same, but so far I failed to find a way to do this.

Maybe I should mention that only a few .TS files exhibit these problems, and these sources do have a lot of (very bad) edits. But somehow YAMB is able to do it, and it does it without reencoding.


Cheers
manolito

[jpsdr]

Question about building mkvtoolnix target windows.
I've successfully build a 32 bits version.
Then, i wanted to build a 64 bits version, so i changed ARCHITECTURE to 64 in setup_cross_compilation_env.sh and re-run it. It took a LOOOOONG time, meaning that all the dependencies were build for 64 bits.
Unfortunately, it failled during the link, saying that a lot of lib/module are not compatible.
My guess: files from previous build where not cleaned and not overwritten, compiler probably thought it wasn't needed to rebuild them, resulting in linker trying to link 32 bits build with 64 bits build.
Do i need to do some cleanup between the both run of setup_cross_compilation_env.sh/rake ? In that case, what is the command for doing the clean up ?
Thanks.

[Mosu]

I cannot really help you with general problems compiling the MXE project. It's not my project; I only use it.

What I can tell you:

you can easily clean up the folder simply by deleting the whole "usr" sub-folder. It's where all the built stuff is installed.
you can have both 32 and 64-bit packages in a single MXE installation by setting "MXE_TARGETS" to "x86_64-w64-mingw32.static i686-w64-mingw32.static" in the "$MXE/settings.mk" file. It's just my setup_cross_compilation_env.sh script that doesn't support it. That script is targeted at users who want to do a one-time build, or who only need one architecture on a regular basis.

Clean up for a MKVToolNix source-tree is simply running "drake clean" followed by a new call to "configure".

[jpsdr]

In my setup, "drake" is not know, but i run "rake clean", and re-rerun setup_cross_compilation_env.sh, and as the libraries mxe where allready built, it was very fast, i then re-run "rake", and it finished ok.
:thanks:

[Mosu]

The MKVToolNix source tree comes with drake bundled. drake is much better at handling concurrent builds, making much better use of multi-core systems. You can run it from the MKVToolNix source tree root with "./drake" if you don't have it installed globally.

That being said, drake is definitely not a requirement. rake will do just fine, albeit slower.

setup_cross_compilation_env.sh is designed to be run multiple times without removing anything between runs, so yeah, you can certainly re-run it after changing ARCHITECTURE. One thing to note, though, is the script will always fetch the latest variant of my customized MXE repository. If that happens, it's quite possible you'll have to completely remove the $MXE/usr sub-directory and recompile both the 32 & the 64 bit toolchains.

[manolito]

--EDIT--
Issue solver. Please see here
https://forum.doom9.org/showthread.php?p=1973494#post1973494


Short follow-up to this post:
https://forum.doom9.org/showthread.php?p=1972539#post1972539

To show the issue I cut out a short section of one of the affected .TS sources which is only mildly erotic. You can download it here:
https://files.videohelp.com/u/172211/Test.zip

I included the MediaInfo results for the files. Maybe someone has an idea why only the old YAMB can handle such sources...

Cheers
manolito

[jpsdr]

@Mosu
Just out of curiosity, because size don't realy matter, any idea why my .exe files are at almost twice bigger than yours ?

[Mosu]

You probably didn't strip them.

[filler56789]

@Mosu
Just out of curiosity, because size don't realy matter, any idea why my .exe files are at almost twice bigger than yours ?

But size DOES matter. Keep in mind that not everybody has tons of RAM and tons of disk space to waste only because most programmers of today are careless noob-like 🤬s.
:D

P.S.: besides stripping the executables, you might also apply UPX onto them. However I don't know if the Qt stuff of MKVtoolnix will like that... FWIW, the ORIGINAL ancient .exe(s) of tsMuxeR were upx-ed, but after being un-upx-ed, it /they doesn't /don't work anymore. :confused:

[jpsdr]

You probably didn't strip them.
....
How do you do that ? Is it something to add in the setup_cross_compilation_env.sh script ?
Or is it a parameter to add when doing the rake command ?

[mastrboy]

But size DOES matter. Keep in mind that not everybody has tons of RAM and tons of disk space to waste only because most programmers of today are careless noob-like 🤬s.
:D

P.S.: besides stripping the executables, you might also apply UPX onto them. However I don't know if the Qt stuff of MKVtoolnix will like that... FWIW, the ORIGINAL ancient .exe(s) of tsMuxeR were upx-ed, but after being un-upx-ed, it /they doesn't /don't work anymore. :confused:

You are more likely to get flagged by antivirus software when using tools like UPX and mpress though, likely as a lot of malicious software use the same tools unfortunately.
Thankfully Microsoft is pretty fast at fixing false-positives for Defender after submitting files to them, usually within a few days. (https://www.microsoft.com/en-us/wdsi/filesubmission)

[jpsdr]

There is commits in MKVToolnix for MSYS2 issues.
It means it's probably possible to build MKVToolnix using MSYS2...:eek:

But i'm unable to find tutorial about it.

[Mosu]

It's not supported officially, and I don't know how to do it. Another person did the work of getting it to compile & provided merge requests that I merged. That's all.

[von Suppé]

Hi Mosu,

At the Dolby Vision support status page, I wonder why there is no "Supported check" under mkvextract for single track dual layer. Extracting hevc from STDL seems ok.

[Mosu]

Mostly because it doesn't do anything with the data stored in the various "addition" blocks (the stuff that corresponds to the CodecPrivate of the base laye, the dvcC/dvvC atoms). For regular, non-DV HEVC it's quite common that the parameter set NALUs are only stored once at the start, and mkvextract tries its best to normalize them so they're present before each and every key frame.

It could do something similar with the Dolby Vision NALUs, but it doesn't yet (as that is simply not implemented).

So yeah, for well-formed tracks you only take out and remux somewhere else as-is, the current code should work fine. The edge cases probably won't, though.

[Mosu]

Heyo!

A new small release is ready, mostly fixing two annoying bugs in the GUI's handling of color parameters that unfortunately slipped in in v69.

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 70.0.0 "Caught A Lite Sneeze" 2022-08-14
New features and enhancements

MKVToolNix GUI: the user can now control where the job queue files & the preferences INI file are stored via environment variables. If set, the variable "MKVTOOLNIX_GUI_STATE_DIR" can point to a directory where the GUI stores both the job queue sub-directory and the preferences INI file. If you only want to relocate the preferences INI file, you can store the desired file name for the INI file in "MKVTOOLNIX_GUI_CONFIG_FILE". Implements #3382 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3382).
MKVToolNix GUI: when adding directories via drag & drop/copy & paste the GUI will now offer the user the option to create one multiplex settings tab per directory & adding all files from that directory to the corresponding, newly created tab. Implements #3371 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3371).

Bug fixes

mkvmerge: AV1 OBU parser: fixed identifying files that only contain single frame. Fixes #3380 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3380).
MKVToolNix GUI: multiplexer: when reading color parameters from identified files that are floating point numbers (minimum/maximum luminance, projection pitch/roll/yaw) the numbers will be formatted in floating-point notation instead of scientific notation as mkvmerge only supports the former. Fixes #3368 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3368).
MKVToolNix GUI: multiplexer: color parameters that are floating point numbers (minimum/maximum luminance, projection pitch/roll/yaw) will only be set to a value during identification if the identification actually contains the property, and not to 0 anymore if it doesn't.

Build system changes

Several merge requests where accepted that improve compilation on MSYS2 on Windows. Note that this build type isn't supported.


Have fun 😁

[Kuler087]

thank you !

[lvqcl]

I wonder why A/V detection is 3/15 on Windows portable and 0/15 on Windows installer. Also some antiviruses don't like hevcc_dump.exe.

[Mosu]

New EXEs that have never been seen in the wild are often the target of false positives.

I create both the 7z and the installer from the same set of compiled EXEs. I compile on Linux. There's no Windows involved in the build process at all.

So… yeah.

[jpsdr]

A build question.
When you're building for Linux (we will forget targeting Windows for now).
Will --enable-static-qt build QT (or something similar) ? If not, what will it do ?
Is --enable-static-qt mandatory for --enable-static ?
Or for --enable-static you just need to have installed the proper allready build QT package ?

[Mosu]

If you want to use a statically-linked Qt, you'll have to use "--enable-static-qt".

"--enable-static" compiles all programs as static binaries, requiring all libraries to exist as static libraries. This isn't supported. The option is only present because one user provided a merge request for it. I don't use it, I don't test it, I don't support it.

[jpsdr]

Ok, thanks.
When you're building for Linux, what are the required QT packages for --enable-static-qt ?

[Mosu]

I only use static Qt libraries for the Windows builds, via the MXE project.

[jpsdr]

I'm not talking about the Windows build via MXE.
As i've specified, when you build for Linux, what are the required QT package for --enable-static-qt ?

[Mosu]

I'm not building with static Qt libraries on Linux. That's what I meant above. I only build with static Qt libraries when I build for Windows. For that I only use MXE.

[jpsdr]

Ah... Ok...
Sorry, i didn't understood, thanks for these informations.

[manolito]

https://forum.doom9.org/showthread.php?p=1972708#post1972708

Sorry for bringing this up again, but I think I found the issue now...

It turned out that the source files are borked, but playing the original .TS files in any player did not reveal the problem. Only after converting the source to .MKV usind MKVToolNix the audio sync was broken.

dmMediaConverter to the rescue. It reported THIS in its log:

[mpegts @ 076b04c0] Non-monotonous DTS in output stream 0:1; previous: 16190735, current: 16189009; changing to 16190736. This may result in incorrect timestamps in the output file.

The solution was to just repack the source with dmMediaConverter (everything in DirectStreamCopy mode) to another .TS file and then use this repacked source file as the input for MKVToolNix. All audio sync errors are gone...


Cheers
manolito

[jpsdr]

@Mosu
Assuming i want to build a Linux release, the same way you do, but from a clean fresh mkvtoolnix repo cloning.

My guess is that i have to do the following, am i correct ?


./autogen.sh (is there parameters here ?)
./configure (what parameters are you using ?)
rake (is there parameters here ?)

[Mosu]

Highly depends on which distro I build for, if I build for development, if I try to test certain features.

For releases I build from source tarballs, not git repo checkouts, meaning that you don't have to run "autogen.sh" (that builds the "configure" script, but the source tarball already includes "configure"). "autogen.sh" doesn't need parameters.

In general I only add those parameters to "configure" that are required for it to find the required libraries if they're stored in locations "configure" doesn't search in. Ideally I don't add any parameter to "configure".

"rake" doesn't need any parameters either.

[jpsdr]

Ok, thanks.

[Perenista]

I used MKVToolnix to put a subtitle (SRT) inside a m2ts file, and noticed that as MKV the filesize decreased from 65.1 to 61.9 GB.

By comparing both MediaINFO details from them, can this reduction be explained?

m2ts (original file):

https://pastebin.com/VuBWVUn8

MKV:

https://pastebin.com/r1VSWpXu

Is the MKV still "lossless" after I used MKVtoolnix? I only added the SRT.

EDIT: I just found this explanation (https://forum.videohelp.com/threads/359137-MKVToolNix-Complete-m2ts-to-mkv-reduces-file-size-why):

Is that it?

The CONTAINER OVERHEAD of a transport stream is much greater than the container overhead of other formats (MPG, AVI, MKV, MP4). In this way, when you remux from (m2)ts to Matroska, you will ALWAYS get a very-noticeable filesize reduction.

[Mosu]

Yes. The MPEG (2) transport stream container has one of the highest overhead of all the usual containers. It's really noticeable.

Another possible part of the explanation are filler NALUs. Video streams might contain so-called "filler NALUs" that don't contain any data and are only present to keep the effective bitrate above a certain threshold. As those NALUs are completely superfluous wrt. decoding, they're dropped by MKVToolNix.

[hubblec4]

Hi Mosu

Short question. mkvmerge writes always 8 bytes for the Segment DataSizeLength?