Search:

Here is release version 85.0.

The Matroska specification changes.
MKVToolNix closely tracks those changes.
Players in TVs and other devices don't always support the full or latest Matroska specification and sometimes have trouble with files multiplexed with the latest MKVToolNix.

The settings suggested by manolito address some of the elements that cause trouble with devices.

Not much information to help troubleshoot the problem other than that you are trying these files on your TV.
Given that scenario I think manolito has made a good suggestion.

As far as I know the official builds now work on Windows 7 when using the latest VxKex.
You should test that if you believe the non-official build is at fault.

Here is release version 84.0.

I am using the main mxe repo modified to use qt 6.6.3.

With changes to the configuration files you must run autogen.sh and reconfigure the build.

@jpsdr
There is some incompatibility with the new C++20 requirements. This breaks qt5 builds but the qt6 build is fine. For qt5 I reverted to the previous ac/c++features.m4 file, before C++20 support was added.

Yes, it looks like you have made all of the necessary corrections to the patches.

I don't think mosu has updated his repo to 6.6.2 yet so you have only updated qt6-qtbase if that is the repo you are using. The main mxe repo has moved to 6.6.2 so you can either use that or bring in their .mk files for the other qt6 packages which will be 6.6.2 based and have the correct SHA.

Hi jpsdr.

The patches are somewhat Windows-centric but the header they added does exist in mingw. They referenced the file with upper and lower case which wouldn't matter on Windows but with a case sensitive filesystem on Linux the all lower case file can't be found. So either all references to that header in the patches has to be changed to all lower case or you have to make a copy of that file in mingw with the name matching the reference.

Another patch that caused problems this time that you may encounter is src/plugins/platforms/windows/qwin10helpers.cpp. I used the patch from 6.6.1 in that case.

Here is release version 83.0.

Thank you Baldrick.

That is interesting. This was an unintentional experiment. Both builds were compiled with the windowsvista style set but version 82.0.39 didn't import the windowsvista style plugin during compilation, whereas 82.0.49 did. So the plugin is overriding or is incompatible with the color palette that Mosu has set for the interface and it presents in the theme style (or lack) you use for Windows. Without the plugin the windowsvista style doesn't look correct with the aero theme.

It seems you would benefit from having the windowsvista style set but not have the plugin imported.

Thanks for the update news. I tested the new VxKex on 32-bit Windows 7 and it indeed works with official MKVToolNix.

I don't post revision builds of the qt5 version but I have shared them via PM requests. The qt6 build in post #177 is currently at revision 82.0.39 and works on older windows.

I made a build of ffmpeg version 4.3.6.

You may realize a performance benefit by using a version of x265 tuned for your cpu. It looks like your cpu has AVX extensions but StaxRip bundles the Mod-by-Patman AVX2 version, which your cpu can't run. If you want to use that mod, there is an AVX version you could try.

https://github.com/Patman86/x265-Mod-by-Patman/releases

You have it correct. That is the core of this simplified method; have mxe build modified qt6. Much better than the method I started with.

Download the qtbase archive from official source.

The patches from https://github.com/crystalidea/qt6windows7 are stored in the correct folder structure used in the qtbase-everywhere-src-6.6.1.tar.xz archive.

So the simplest way would probably be to use a good archiver to open the qtbase archive and drag the patch folder(s) to the correct location in the archive and drop, overwriting the current files. The archive will be updated with the replacement files.

Then you can get the checksum for the new archive with this command:

cksum -a sha256 qtbase-everywhere-src-6.6.1.tar.xz

Yes, that should work. In fact you wouldn't even need to use my modified setup_cross_compilation_env.sh script because you would be updating from a repository with the correct source which wouldn't risk overwriting custom files locally.

The switch is a mistake on my part. Sorry about that.

You will need to check this log:

[log] /home/jpsdr/MKVToolNixQT6/mxe/log/qt6-qtbase_x86_64-pc-linux-gnu

This is an attempt to simplify building mkvtoolnix with a modified qt6. I can't guarantee that it will work in your build environment, but it should.


1. Clone Mosu's mkvtoolnix and mxe repositories per usual.

2. Make the changes to the mkvtoolnix sourcecode such as style, version name, etc.

3. Download the build files from this post and extract them.

4. Place the qtbase-everywhere-src-6.6.1.tar.xz archive file into mxe/pkg. This is the important qtbase package with patches integrated. mxe will download and build all other required qt6 packages.

Hi jpsdr.
I did run into that. It is apparently caused by a recent update to boost, which Mosu pushes ahead of mainline mxe.
The fix is to change mxe/src/assimp.mk line 14 to "ON":

-DASSIMP_ENABLE_BOOST_WORKAROUND=ON \
As you probably know, you will have to disable updating of mxe in the setup script otherwise any changes you make to mxe source will be overwritten next time you run it.

Hi manolito.

I have not tested that scenario so I don't know the precise answer to that question. The support files contain functions from later OS versions that the Qt5 build doesn't require so they are likely ignored, as you suggest.

The only potential Qt5 advantage I am aware of at the moment is that the "windowsvista" style which both builds use, might have better compatiblity with it.

The Qt6 advantage is really about future-proofing the non-official builds.

Hi Ennio.

The archive that you downloaded has no ini file in it so it should never overwrite your settings. If you extracted the archive to a location and executed the program it would generate a generic ini file locally. You would certainly not want to copy this ini file over your current file and it appears you rightly excluded it in the second instance. You don't mention if you excluded it in the first instance.

The archive is also portable by default. For installed locations, the procedure I would recommend is to extract the archive, delete the portable-app file in the data folder, then copy the files to the installed location overwriting the previous files. This should bring you up to date and preserve your settings.

As for running the Qt5 or Qt6 version, while it is possible you should run whatever you are comfortable with. For Windows 7 users the Qt6 version does require additional libraries and this might put some people off from using it.

I don't mind you asking and I hope this helps!

Here is release version 82.0.

Note:
Support for Qt5 has been officially removed but the code base remains compatible for now.
Builds with modified Qt6 are now working on Windows 7/8.1 and are available in post #177.

@jpsdr
It is not currently simple since I setup manually to do a custom Qt6 build. I am thinking of a way to simplify and that may involve using the setup_cross_compilation_env.sh script. If you want to try, the place to start is integrating the patches into an official qtbase source archive (qtbase-everywhere-src-6.6.1.tar.xz) or I can upload one. Then we can go from there. I don't plan to setup a github but I will share and help with what I can and you are welcome to do so.

Thank you for testing and happy new year!

@manolito
Thank you for testing and your valuable feedback. Happy new year!

If that is caused by using the deprecated "windowsvista" style with Qt6, it probably will not get fixed.

Updated Qt6 test builds in post #177.

@ask2018

I have added the Windows 7 support libraries to the original post. Thank you again for testing the builds.

I had to fix a build problem related to using the 'windowsvista' style with Qt6. i have uploaded new test builds in post #177 if you would like to try it out. I also referenced your post on running this build on 64-bit Windows 7.

@ask2018
That is good to know. Thank you for testing!

!!TEST BUILD!!

This was built with Qt6 modified with Windows 7 compatibility patches from here:
https://github.com/crystalidea/qt6windows7

My testing shows this build works fine on Windows 8.1 but does not work on Windows 7*.
Test if you wish.

I think this concludes my Qt6 testing.

I took a look at that project. It is much like others that I have seen that target Windows 7 with QT6 and use a shared QT build. I am reluctant to move to that build type and also fight with QT6 compatibility. What I will do is put some effort into trying to build a static QT6 with the Windows 7 modifications and build mkvtoolnix with that. We'll see how that goes.

@jpsdr
Thank you for sharing the news.

@fits79
Given the new information, future Windows 7 compatible builds are in doubt.

Here is release version 81.0.

Here is release version 80.0.

Hi Manolito.

Are you running from an installed or a portable location? That is usually what causes problems with the mkvtoolnix-gui.ini as there shouldn't be any fundamental difference to the file format between versions. If you can tell me the steps you took to install the new version I can try to reproduce the problem. Under Help -> System Information and under the Paths heading it will say what kind of installation it detects.

I have made an installer if you'd like to try that. It will prompt for elevated permissions to install to the Program Files directory. Of course, keep a backup copy of your ini file.

Here is release version 79.0.

Here is release version 78.0.

Your repo doesn't seem to have the requisite revision information that the build files use to generate the version string. It falls back to the built-in version as you have seen.

For example, this is what I get from my clone of Mosu's repo:

>git describe
release-77.0-19-g51f650418

I guess you could force it by editing the version in the build-config file before compiling.

That is changed at src/common/version.cpp line 29:

constexpr auto VERSIONNAME = "Elemental NON-OFFICIAL";