MKVToolnix Windows 7 "The final Countdown"

[jpsdr]

We are now in the Twilight Zone...
I've branched just before the end of QT5, and add some of the fixes. The version displayed will not match anymore, and now there is more risk of broken stuff.
Anyway, the "81.0.33" is on my github.

[filler56789]

I didn't check the code yet, but just saw the name of the last commits from Mosu, it's the end of QT5 support. So i'll try to get only the bug fixes (if possible), but the end is close... :(

Very saddening. That sucks too much, indeed.
Our only hope is, """someone""" will revert the groundless QT dependency for the command-line executables.
IF anyone wants a new GUI, this will have to be written in a dotNET language or in Java.

[jpsdr]

Some new Twilight Zone builds... ;)

[jpsdr]

A new year build :D. And happy new year.

Edit:
Just checked, nice new year gift from autodidact, who succed making a QT6 version with the QT6 modified for Windows 7.

[Video Dude]

Yes, it appears Windows 7 builds will continue.

[manolito]

New version 84.0 is available. :thanks:
Download from here:

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page9#post2733416

Qt5 is still supported...


Cheers
manolito

[jpsdr]

There is still time to time stuff to adjust to keep QT5, but thanks to autodidact help i'm still able to follow.
And for now, the QT6 Windows 7 compatible is still also working.

[manolito]

New version 85.0 is available. :thanks:
Download from here:

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page9#post2738055

Qt5 is still supported...


Cheers
manolito

[filler56789]

Yes, it appears Windows 7 builds will continue.


Yessss :cool: Resistance is futile :devil: :D

[GMJCZP]

For a W7 32 bit user, it is appreciated ;-)

[manolito]

New version 86.0 is available. :thanks:
Download from here:

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page9#post2742950


Cheers
manolito

[filler56789]

NON-OFFICIAL mkvtoolnix v87 is out.

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page15#post2749599

[filler56789]

NON-OFFICIAL mkvtoolnix v88.

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page16#post2754580

[manolito]

Here is mkvtoolnix v89.0 :)

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page11#post2761778

Many thanks to autodidact,

Cheers, and a Happy New Year...
manolito

[shae]

Thanks.

In the official builds, does QT6 bring any improvements?

[filler56789]

Thanks.

In the official builds, does QT6 bring any improvements?

Nope. Apparently the only goal of the endless QT ""updates"" is just annoy the users of the old versions of Windows.

source: https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page11#post2763793

So I did a little more digging in the code changes and found that the default font rendering had changed from GDI to directwrite starting in 6.8.0.
Of course it defaults to the Windows 10/11 version, which results in failure on Windows 7/8.

[filler56789]

NON-OFFICIAL version 90.0 is up and running! 🫡

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page17#post2766653

[tebasuna51]

Thanks, seems it is also needed with old W10 versions (https://forum.doom9.org/showthread.php?p=2014594#post2014594).

One question, if the problem is about the QT versions for what the exe's are also differents not only the GUI.

[filler56789]

.........
One question, if the problem is about the QT versions for what the exe's are also differents not only the GUI.

In the good old days, the command-line executables used the file magic.mgc for detecting the numerous input file contents. But some years ago, Mosu decided that Qt is "better than magic.mgc" at detecting file contents, so from that day on, the mkvtoolnix command-line .EXEs also depend on Qt.😩

[tebasuna51]

Thanks, seems there are other user with that build W7+W10-old

[shae]

Any reason to use the x64 version?

Assuming it's just data shuffling, there's no heavy processing involved, and so no real gains expected.

[nevcairiel]

Any reason to use the x64 version?

Assuming it's just data shuffling, there's no heavy processing involved, and so no real gains expected.

Any reason not to? Should really be the default these days.

[manolito]

Sorry I can't resist to reply... :p

Two clashing philosophies here.

MKVToolnix does not do any REENCODING, it just REPACKS the cource for a different container. Which is very useful. But from many years of using MKVToolnix I do know that the speed difference between the 32bit version and the 64bit version is minimal to non-existent. On a PC with low system memory it can even happen that the 32bit version is faster.

So please stop the religious fight about 32bit against 64bit. In most cases the answer is "It depends".


Just my 2 cents... :D
manolito

[lvqcl]

So please stop the religious fight about 32bit against 64bit.
I thought it was you who just tried to religiously defend 32bit?

[huhn]

Sorry I can't resist to reply... :p

Two clashing philosophies here. As nevcairiel posted recently:


LAV Filters does not do any REENCODING, it just REPACKS the cource for a different container. Which is very useful. But from many years of using LAV Filters I do know that the speed difference between the 32bit version and the 64bit version is minimal to non-existent. On a PC with low system memory it can even happen that the 32bit version is faster.

So please stop the religious fight about 32bit against 64bit. In most cases the answer is "It depends".


Just my 2 cents... :D
manolito
64 bit software decoding is massively faster. what was it 2x for h265 and 15 % for h264.
yes 64 bit software usual addresses more memory compared to the 32 bit version but that's it.

[shae]

Any reason not to? Should really be the default these days.
32-bit is potentially more compatible, and potentially smaller.

[manolito]

Correct... :p

Since MKVToolnix does not do any reencoding of the source files, there is no real acceleration when using the 64bit version. When using the GUI version MKVMergeGUI the GUI could potentially run a little faster in 64bit, but in my tests I did not get any speed increase with the 64bit version. Probably because the GUI uses the (64bit) operating system for all the mem copy and screen writing operations, so even under 32bit MKVToolnix these operations will run in 64bit.

And if you have an older computer with low system memory and a single-threaded CPU then the 32bit version will almost certainly run faster than the 64bit version.


Cheers
manolito

[huhn]

it does compression. and compression algorithm also benefit from 64 bit. you are usually limited by the IO speed anyway.

yes a single thread CPU with not enough memory to run the OS will benefit from a 32 bit version.
or you just get a dongle and use your smartphone instead.

the argument is pretty much the same as 32 bit version run on a 32 bit os the 64 bit doesn't.

[manolito]

it does compression. and compression algorithm also benefit from 64 bit

AFAIK it uses lossless compression only for subs by default. Video and Audio stays as it is. Quote from an older post by Mosu:
https://forum.doom9.org/showthread.php?p=1945234#post1945234

And all this applies only to the final remuxing, the source tracks are never decoded and then reencoded.

Cheers
manolito

[huhn]

yes i said compression but fair to point out.
very useful for LPCM too.

[filler56789]

NON-OFFICIAL version 96 has been released. :cool:

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix?p=2785998&viewfull=1#post2785998

[manolito]

Here is mkvtoolnix v98.0

https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page14#post2795110

Many thanks to autodidact,

Cheers...
manolito