MKVToolNix v83.0 released

[Mosu]

Sounds like… well… something, maybe bad compiler optimizations? I don't know… Please give the latest continuous build a try. They're built with newer compiler versions.

Not that I think that'll really do anything, mind you…

As I don't have access to a single Ryzen system, I don't think there's really anything I can do at the moment, especially given that older Ryzen seems to have run the binaries just fine according to you.

[Mosu]

Originally Posted by hubblec4

The old "codec name" track property (now codec_name) was "codec" only?

No. "codec" wasn't changed at all. The property "codec_name" was added containing the value of the "CodecName" track header attribute if present.

[nogames]

Originally Posted by Mosu

Sounds like… well… something, maybe bad compiler optimizations? I don't know… Please give the latest continuous build a try. They're built with newer compiler versions.

Downloaded the 64-bit version of the continuous build. And no errors. It runs. I'll report back again when this version goes final.

[DragonQ]

Originally Posted by nogames

MKVToolNix GUI v35.0.0/64bit keeps crashing when adding a file to GUI. It does not matter if it is via drag-drop or Add file option.

I just upgraded my system to Ryzen 7 3700X. It's a fresh install of Windows 10 Pro 64-bit (version 1903). I came from a Ryzen 7 1800X (but not version 1903 but the previous version) which did not have this problem.

The 32bit version of MKVToolNix GUI v35.0.0 works! I have tried all 64 bit versions from v30.0.0 and on and they all crash when I add a file.

Note: No difference in behaviour between Installed and Portable versions

I have a similar issue. I also have a Ryzen 7 3700X, a fresh install of Windows 10 1903, and the 64-bit version of MKVToolnix GUI. I can add files and make changes, but as soon as I hit "Start multiplexing", the app crashes and disappears. I then cannot restart the app at all (it presumably insta-crashes since I never see the window). The only way to get the app to relaunch is to empty the "AppData\Local\bunkus.org\mkvtoolnix-gui\jobQueue" directory.

The only workaround I've found is to import files, choose my settings, then do "Show command line" and run it manually in the command line.

[Snowknight26]

Yep, just noticed the same thing, Ryzen 5 3600. Start multiplexing crashed the program and it won't start again. It was working fine up until I chose the destination file using the button instead of typing the name in manually.

[Mosu]

The new Ryzens are known to contain several bugs, e.g. with their RDRAND instruction. This is not a bug in MKVToolNix, and AMD has released new BIOSes that're supposed to fix some of those bugs to for the motherboard manufacturers. Another user who reported the issue over on Gitlab also reported that their motherboard manufacturer's just released a BIOS update. After having applied the update MKVToolNix started to work fine for them.

[chros]

Originally Posted by Mosu

The new Ryzens are known to contain several bugs, e.g. with their RDRAND instruction.

That's interesting, thanks. Did AMD become the new Intel?!

[DragonQ]

Originally Posted by Mosu

The new Ryzens are known to contain several bugs, e.g. with their RDRAND instruction. This is not a bug in MKVToolNix, and AMD has released new BIOSes that're supposed to fix some of those bugs to for the motherboard manufacturers. Another user who reported the issue over on Gitlab also reported that their motherboard manufacturer's just released a BIOS update. After having applied the update MKVToolNix started to work fine for them.

Which bugs are "known" other than the RDRAND bug? Does MKVToolnix actually use RDRAND?

Either way, I tried the latest dev release and it seems to work now. Not sure if it's because of the new version or a new BIOS but at least it works now.

[huhn]

there are quit some issues they even pulled bios versions thanks to bugs in the AGESA. boards are shipped with alpha version bios this is as rushed as possible...

if you want a stable system zen 2 shouldn't be an option for now.

[MrVideo]

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

[lvqcl]

Originally Posted by MrVideo

and a search here

There is also an old thread: http://forum.doom9.org/showthread.php?t=155732

Originally Posted by MrVideo

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

You mean officially? I suspect that the answer is here - https://gitlab.com/mbunkus/mkvtoolni...s-and-versions

Supported are all client versions of Windows (meaning Intel architecture) that Microsoft supports. This means Windows 7 or newer, 32-bit and 64-bit architectures. On the server side Windows Server 2012 and newer are supported.

(emphasis mine)

At least, version 11 was the first that dropped support for WinXP.

PS: http://forum.doom9.org/showthread.ph...81#post1806381

[sneaker_ger]

Yeah, officially. The sounds made the GUI not work on XP for good. CLI may still work. As should Vista.

# Version 11.0.0 "Alive" 2017-04-22

## New features and enhancements

* 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)

## Build system changes

* Qt's multimedia component is required for compilation of the GUIs since
version 11.0.0.

https://mkvtoolnix.download/doc/NEWS.md

[MrVideo]

Originally Posted by lvqcl

You mean officially? I suspect that the answer is here - https://gitlab.com/mbunkus/mkvtoolni...s-and-versions

I saw that. It doesn't say when.

At least, version 11 was the first that dropped support for WinXP.

I've got V24 32bit running on an XP system. I've never used the GUI. I do all my mkvmerge stuff via the CLI within Zshell scripts under cygwin. That said, I do not use that system for recoding and merging of the video and audio streams anymore. But, I do use mkvmerge a lot. I guess I'll just keep upgrading until I find a version whereby it no longer works and go back to the previous version.

I had to rebuild another XP system that I was using for compiling and loaded XP-64 on it. I ran either 31 or 33 on it. Hardware issues required a new mobo so I upgraded it to Win7 as well. I had already built another Win7 box for compiling and have basically turned off the other Win7 box. At least I haven't turned it back on after AC power issues.

PS: http://forum.doom9.org/showthread.ph...81#post1806381

Personally I do not like the "ding"ing that goes on when programs finish, or if there are errors. I find it annoying. The error dialog popups are good enough for me.

Thanks for the responses. It has been helpful.

[manolito]

The last CLI version which works under WinXP is v.29. If you need the GUI you have to replace some components of the package with older versions.

FWIW here is a package which does this...
https://files.videohelp.com/u/172211/ToolNix_XP.zip


/EDIT/
The archive was updated to also include the last Win7 compatible version (32-bit only)

[MrVideo]

Originally Posted by manolito

The last CLI version which works under WinXP is v.29.

Thanks for the info. That'll save me a lot of trial and error.

If you need the GUI you have to replace some components of the package with older versions.

Thanks. But like I wrote, I do not use the GUI and have never used the GUI.

[Mosu]

Here's another small summery bug fix release for MKVToolNix, v36.0.0. Nothing major's changed; just a couple of fixes here & there.

There've been no changes regarding packaging since the previous release.

Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code.

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 since the previous release:

Version 36.0.0 "Is That Jazz?" 2019-08-10
New features and enhancements

• mkvmerge: mkvmerge now allows appending AV1, VP8, VP9, H.264/AVC and H.265/HEVC tracks whose pixel dimensions differ. Implements #2582.

Bug fixes

• source code: fixed building with Boost 1.71.0. Fixes #2599.
• all: fixed the spelling of the H.264 & H.265 codec names.
• mkvmerge: Blu-ray MPLS handling: mkvmerge will now find corresponding M2TS files even if the "clip_codec_identifier" playlist item field is not set to "M2TS" in the MPLS file. Fixes #2601.
• mkvmerge: fixed handling of text files that use both DOS-style and Unix-style line endings resulting in problems such as text subtitle files not being parsed correctly. Fixes #2594.

Have fun

[Mosu]

Originally Posted by DragonQ

Which bugs are "known" other than the RDRAND bug? Does MKVToolnix actually use RDRAND?

MKVToolNix itself does not contain any assembly instructions, nor does it contain any CPU-specific or CPU-vendor-specific code. It is, of course, more than possible that at least some of the libraries used by MKVToolNix do use those instructions, especially given that MKVToolNix does communicate via HTTPS, meaning there are a lot of security-related code paths.

I don't know specifics about buggy instructions other than RDRAND, but there are tons of reports out there of bugs such as software crashing (see e.g. Destiny 2 crashing), Windows blue-screening during boots and several board vendors releasing BIOS updates several times a week. All of that paints a picture of a rather immature hardware platform. Not really surprising, really, as AMD's hardware seems to include much more radical changes & new features than the glacial enhancements Intel seems to produce these days. I'd simply give the hardware platform some more time to mature, or be aware of the usual risks for early adopters.

[Mosu]

Originally Posted by MrVideo

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

While we're on the topic: yes, my official policy is that I only support those Windows versions that Microsoft supports for the general population (= unpaid support). So yes, this means that Windows 7 itself will soon not match this criteria anymore as its unpaid, extended support will end on January 14, 2020.

This doesn't mean that MKVToolNix will stop running on Windows 7 on that day, nor does it mean that I'll go out of my way to make MKVToolNix require newer Windows versions to run. In fact, it's quite possible MKVToolNix will continue running on Windows 7 for much longer than it used to run on XP after its end of support. But I do reserve the right to refuse to debug issues occurring on Windows 7 unless the user can show the problem happens on other supported platforms, too.

Queue the outrage in 3… 2… 1…

[Mosu]

Originally Posted by MrVideo

I saw that. It doesn't say when.

That's because I don't implement intentionally that cause MKVToolNix not to run on older versions anymore. "Not supported" doesn't necessarily mean "doesn't run anymore". I just don't pay attention to unsupported OS anymore regarding my choice of things such as library versions, features used, compiler flags used etc. I often don't even realize there's a problem running on older OS until users complain.

[MrVideo]

Originally Posted by Mosu

That's because I don't implement intentionally that cause MKVToolNix not to run on older versions anymore.

I don't mean to imply that you do anything intentionally to not make it work.