MKVToolNix v83.0 released

[filler56789]

Originally Posted by hello_hello

PS. I'm using x264 core 155 r2901 7d0ff22 (with 32 bit MeGUI), as last time I tried to upgrade it, the newer x264 wouldn't run on XP. Is that still the case with the latest version?

When you try to run x264.exe on its own, i.e., "outside of" MeGUI,
what is the error message(s) that Windows XP returns?

[robena]

Originally Posted by mkver

The easiest way to measure this is by using the Taskmanager: Make it show the CPU Time of your processes and take a look at the value of this counter right before the process ends.
(This is not a perfect benchmark: If a process takes (say) 10 % of a core's CPU time, then after 10s the CPU time will be 1s higher -- regardless of whether your CPU is currently running at its maximum/default frequency or not.)

I used something more precise, the command:

typeperf "\Process(mkvmerge)\% Processor Time" -si 10 -o mkvmerge.txt

For the command line, directly cut pasted form the GUI, I got a file that looks like:

"(PDH-CSV 4.0) (Romance Standard Time)(-60)","\\NT\Process(mkvmerge)\% Processor Time"
"03/30/2019 19:58:15.817"," "
"03/30/2019 19:58:25.822","96.552356850679971"    
"03/30/2019 19:58:35.824","96.859476872593547"
"03/30/2019 19:58:45.826","98.107263033370458"
"03/30/2019 19:58:55.828","97.327396077620293"
.....
"03/30/2019 20:28:15.975","97.483370443431511"
"03/30/2019 20:28:25.977","98.107263033370458"
"03/30/2019 20:28:35.978","98.112168754568174"
"03/30/2019 20:28:45.981"," "
"03/30/2019 20:28:55.983"," "

The sum of all not NULL times was: 16144.6679175611
Elapsed time was 19:58:25 -> 20:28:45, 32m20s

Then, I ran the GUI, after a "sync" command and got:

"(PDH-CSV 4.0) (Romance Standard Time)(-60)","\\NT\Process(mkvmerge)\% Processor Time"
"03/30/2019 20:51:55.756"," "
"03/30/2019 20:52:05.760","35.717906573357453"
"03/30/2019 20:52:15.762","31.818571794606637"
"03/30/2019 20:52:25.774","28.514617588198405"
.....
"03/30/2019 20:57:25.883","34.470119444157191"
"03/30/2019 20:57:35.885","37.121667093707742"
"03/30/2019 20:57:45.888"," "

Total CPU time was: 1017.40205400394
Elapsed time was 20:52:05 -> 20:57:45, 5m40s

As you can see, both the elapsed time and the CPU usage are way lower from the GUI.

[hello_hello]

Originally Posted by manolito

The behavior I was talking about happened with LigH's latest build r2969 under Win7-64. My XP computer does not really handle HD sources. The latest x264 version which runs under XP and does not need SSE2 is 0.148.2579.0 from 2015.

I never used the --stitchable parameter in x264 because at the time when I created this "Silence" clip I used the same x264 build which was used for the movie conversion. The warning started to appear after I updated x264 to a newer build. For the movie conversion the parameters were absolutely identical. So I believe that every new build probably creates different "private data" even when identical parameters are used.

I assume the timeline went something like this:

1: x264 doesn't optimize global stream headers
2: x264 does optimise global stream headers
3: Users complain about not being able to append encoded video
4: --stitchable added to prevent x264 from optimising global stream headers
5: Fewer users complain about not being able to append encoded video

--stitchable became a thing in 2013, so if you created the original silence clip before then, it'd make sense. If not, I don't know.........

I've definitely had problems appending encoded video in the past, even when the same x264 build was used and the same settings. Although --stitchable has always prevented the warning when appending constant frame rate encodes. For variable frame rate encodes it's still a little hit and miss. That could be because x264 is writing directly to MKV (for reasons I don't understand) as if MKVToolNix has warned about the codec's private data when appending VFR video in MKVs, extracting the raw streams and appending those instead has always worked.

An SSE2 requirement isn't an issue for me, but if x264 could find that missing entry point in kernel32.dl and obsess over bcrypt.dll a little less, I wouldn't complain. That started sometime after build 2091.

Cheers.

[sneaker_ger]

You already asked about fps in the past. It changed headers.
https://forum.doom9.org/showthread.php?p=1822942

[filler56789]

Originally Posted by hello_hello

An SSE2 requirement isn't an issue for me, but if x264 could find that missing entry point in kernel32.dll and obsess over bcrypt.dll a little less, I wouldn't complain. That started sometime after build 2091.

Just my wild guess... the problem is not the recent revisions of x264, it's whether the .EXE uses win32thread or not. If you compile x264 without win32thread, then it should run normally on Windows XP
(or at least I think so).
I don't have a XP machine anymore, so I cannot test my hypothesis...

[hello_hello]

Sorry filler56789,
I missed your earlier post.

I can't remember if Windows offered an error message as such, but the first hurdle was x264 not being able to find bcrypt.dll. I downloaded it just to see what'd happen, then the next hurdle was a procedure entry point in kernel32.dll, so I gave up. That's much the same as the latest ffmpeg compiled without XP support (and MKVToolNixGUI after version 10), and while I don't know what win32thread is just yet, I suspect you're on the right track.

Cheers.

[hello_hello]

Originally Posted by sneaker_ger

You already asked about fps in the past. It changed headers.
https://forum.doom9.org/showthread.php?p=1822942

I completely forgot about that.

Thanks.

[lvqcl]

Originally Posted by hello_hello

I can't remember if Windows offered an error message as such, but the first hurdle was x264 not being able to find bcrypt.dll. I downloaded it just to see what'd happen, then the next hurdle was a procedure entry point in kernel32.dll, so I gave up. That's much the same as the latest ffmpeg compiled without XP support (and MKVToolNixGUI after version 10), and while I don't know what win32thread is just yet, I suspect you're on the right track.

From x264 configure file:

External library support:
  --disable-avs            disable avisynth support
  --disable-swscale        disable swscale support
  --disable-lavf           disable libavformat support
  --disable-ffms           disable ffmpegsource support
  --disable-gpac           disable gpac support
  --disable-lsmash         disable lsmash support

So, it looks like x264 is linked with some ffmpeg libraries by default. r2901 contains string "FFmpeg version git-2018-01-18-81c09ce34d", while r2935 contains "FFmpeg version git-2018-09-23-77c673920b".
Apparently, newer x264 -> newer ffmpeg -> no WinXP support.

(sorry for offtopic)

[Mosu]

Hey,

another month, time for another release of MKVToolNix: v33.0.0. This is still a rather quiet time for MKVToolNix; hence this is another small bug fix release.

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 33.0.0 "A Little Bit of Madness" 2019-04-12

## Bug fixes

* mkvinfo: when using the `--size` option, mkvinfo will now report the correctly if an element has an unknown size. Part of the fix of #2530.
* MKVToolNix GUI: info tool: clusters with an unknown size will now be read and displayed correctly. Part of the fix of #2530.
* MKVToolNix GUI: multiplexer: Windows: trying to open Blu-ray index or playlist files failed when the path to the files contained symbolic links (e.g. when mounting a drive in a sub-folder via Windows' disk management utility). Fixes #2522.
* MKVToolNix GUI: multiplexer: if a destination file names ends with a number in parenthesis (e.g. a year such as "(2017)"), that number will not be stripped anymore during the process of ensuring the destination file name is unique. Only those suffixes added automatically in prior attempts to make the file name unique will be removed. Fixes #2521.
* MKVToolNix GUI: multiplexer: Windows: the GUI will let the user change the drive letter part of the destination file name freely again and only verify its validity right before starting to mux/adding to the job queue. Before it tried to force that into something valid, often resulting in unintentional paths (such as "C:\users\…\DC\files\…"). Fixes #2527.

Have fun

[stax76]

Thanks for the release. Minor cosmetic request for you or anybody else that posts markdown: BB code instead of MD code would be easier to read. It could be converted with a script that reads MD from the clipboard and copies BB back and for convenience the script could be started with a launcher like Alfred or Wox or via command line.

before: https://forum.doom9.org/showpost.php...1&postcount=88

after: https://forum.doom9.org/showpost.php...5&postcount=90

node script: https://pastebin.com/ru5xe4EE

[Mosu]

Hey,

well, I buggered up the handling of UNC paths on Windows in release 33.0.0. So… sorry? Here's a fix for that. As this is just an emergency hot fix release I'll include the news for v33.0.0, too.

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 33.1.0 "Primrose" 2019-04-15
Bug fixes

• MKVToolNix GUI: multiplexer: Windows: using UNC paths (e.g. "\\server\Videos") when the option "automatically set the destination file name" was set in the preferences, the GUI would create a destination file name with forward slashes (e.g. "//server/Videos/outputfile.mkv"), a syntax not supported by "mkvmerge". Fixes #2533 & #2534.
• build system: the programs were accidentally built without stack protection ("-fstack-protector-strong") on recent versions of gcc and clang.

Version 33.0.0 "A Little Bit of Madness" 2019-04-12
Bug fixes

• mkvinfo: when using the "--size" option, mkvinfo will now report the correctly if an element has an unknown size. Part of the fix of #2530.
• MKVToolNix GUI: info tool: clusters with an unknown size will now be read and displayed correctly. Part of the fix of #2530.
• MKVToolNix GUI: multiplexer: Windows: trying to open Blu-ray index or playlist files failed when the path to the files contained symbolic links (e.g. when mounting a drive in a sub-folder via Windows' disk management utility). Fixes #2522.
• MKVToolNix GUI: multiplexer: if a destination file names ends with a number in parenthesis (e.g. a year such as "(2017)"), that number will not be stripped anymore during the process of ensuring the destination file name is unique. Only those suffixes added automatically in prior attempts to make the file name unique will be removed. Fixes #2521.
• MKVToolNix GUI: multiplexer: Windows: the GUI will let the user change the drive letter part of the destination file name freely again and only verify its validity right before starting to mux/adding to the job queue. Before it tried to force that into something valid, often resulting in unintentional paths (such as "C:\users\…\DC\files\…"). Fixes #2527.

Have fun

[Mosu]

Originally Posted by stax76

Thanks for the release. Minor cosmetic request…

Well, the script as-is didn't work too well for me, but with a couple of changes (handle more headline tags, revert HTML escaping of " and &, removal of code tags, manually joining lines in order to avoid line breaks) it works well enough, I guess.

[chros]

Originally Posted by algorithm_colon

There's been some noise recently about this tool from Dolby which can create Dolby Vision mp4 files. I was able to create a profile 7 file from a UHD disc backup which played succesfully with DV on an LG TV.
I was wondering if there's anything in the code that might provide some clues for getting Dolby Vision into mkv - after remuxing the mp4 with mkvtoolnix all of the dolby vision information is lost.

@Mosu, is there any plan for this? I'm just interested, thanks!

[raymondjpg]

I am trying, unsuccessfully, to standardise order of tracks in output files generated by MKVToolNix so video comes first, then audio, then subtitles.

When I add --track-order 0:0,0:1 (by my understanding video first, then audio) as Default additional command line options in Multiplexer default values preferences, I get an error when muxing '--track-order' may only be given once.

I can find only one instance of --track-order in mkvtoolnix-gui.ini, and nowhere else in MKVToolNix preferences to set track order, so I am at a loss to know how to achieve standardisation of track order in output files.

Can anyone set me on the right path?

[sneaker_ger]

Originally Posted by raymondjpg

When I add --track-order 0:0,0:1 (by my understanding video first, then audio)

That's not what it means. It means track 0:0 (track with TrackID 0 of first input file) is used first, then track 0:1 (track with TrackID 1 of first input file) second. --track-order doesn't have any arguments to differentiate between video/audio/subtitles.

Originally Posted by raymondjpg

I can find only one instance of --track-order in mkvtoolnix-gui.ini, and nowhere else in MKVToolNix preferences to set track order, so I am at a loss to know how to achieve standardisation of track order in output files.

Can anyone set me on the right path?

It's not possible to automatically make the GUI set 1. video 2. audio 3. subtitles. The GUI will always insert its own --track-order which cannot be disabled.

[raymondjpg]

Originally Posted by sneaker_ger

That's not what it means. It means track 0:0 (track with TrackID 0 of first input file) is used first, then track 0:1 (track with TrackID 1 of first input file) second. --track-order doesn't have any arguments to differentiate between video/audio/subtitles.


It's not possible to automatically make the GUI set 1. video 2. audio 3. subtitles. The GUI will always insert its own --track-order which cannot be disabled.

Thanks for the clarification. I was curious as to why the version of mkvmerge.exe bundled with MeGUI always managed to generate an mkv with the 'correct' track order of Video Audio and then Subtitles, whereas the current version of MKVToolNix GUI 33.1.0 is generating mkvs with track order of Audio Video then Subtitles.

I know track order in output files can be changed around manually.

[sneaker_ger]

You can set the track order manually. It's just that MeGUI and MKVToolNixGUI use mkvmerge in different ways. The way MKVToolNixGUI works it's not possible to automate what you want.

[Klaus1189]

Is it possible to cut out a scene from a a videofile (key frame accurate is enough for that), but the two other parts (before and after the cut) should be one file again, without the need of more than one step.
I could cut on two points and then merge the two other parts together, but is there a one step possibility for that?

[mkver]

If you do not want to keep the middle part, then it is possible: If you use a + in front of a range, then this range will be appended to the preceding range that was outputted.

[hubblec4]

You have to use split option "By parts based on timestamps".