MKVToolNix v24.0.0 released

[Mosu]

I may have spoken too soon. Now chapters are displaying oddly.

Meh :) Should be fixed in the latest pre-builds (https://mkvtoolnix.download/windows/pre/).

[hello_hello]

Meh :) Should be fixed in the latest pre-builds (https://mkvtoolnix.download/windows/pre/).

Yep. All better again.

Thanks.

[hello_hello]

A command line question....

I've been experimenting with muxing with AnotherGUI and mkvmerge.exe. You probably don't need to know anything about the program to understand the following command line preset for AnotherUI and to appreciate that it works:

--aspect-ratio 0:16/9 --default-track 2:no "<FullSourceFileName>" --output "<OutputPath><OutputFileName>.mkv"

But is there a way to apply the aspect ratio change to any video stream I'm missing? Something like this (which I know doesn't work):

--aspect-ratio V:16/9

As long as the video stream is one of the first four streams I know I can change it's aspect ratio with this command line, and for the non-video streams it'll be ignored:

--aspect-ratio 0:16/9 --aspect-ratio 1:16/9 --aspect-ratio 2:16/9 --aspect-ratio 3:16/9 --default-track 2:no "<FullSourceFileName>" --output "<OutputPath><OutputFileName>.mkv"

But that leaves the problem of applying a setting to a particular stream type if it can apply to more than one type of stream, such as language or default status. In order to set the subtitle stream to default = no, I have to know the specific subtitle stream number(s). ie

--default-track 2:no --default-track 3:no

Is there any way to apply an option to a specific stream type rather than a stream number I'm yet to discover?

Thanks.

[Mosu]

No, there isn't. There's only the magic track ID -1 which matches all tracks, regardless of their type.

[ndjamena]

--aspect-ratio -1:16/9

will apply it to every track it can be applied to.

[hello_hello]

Thanks guys.

My main reason for asking was because I had to use this version of ffmpeg (https://forum.doom9.org/showthread.php?t=152419) to change the aspect ratio written to some h264 streams, but it doesn't set the container aspect ratio, so I got carried away with making an AnotherGUI preset for it, which led me to then try to create and mkvmerge preset to finish the job, but in the end it all got too hard.
I discovered ffmpeg would only copy a single audio stream (I couldn't get the mapping function to work) and it was making a mess of srt subtitles, so I gave up trying to do anything with it aside from fix the stream display aspect ratio, which means I have to use MKVToolNix manually to add back the other streams and mux a second time.

Bummer.

[SeeMoreDigital]

My main reason for asking was because I had to use this version of ffmpeg (https://forum.doom9.org/showthread.php?t=152419) to change the aspect ratio written to some h264 streams, but it doesn't set the container aspect ratio...
Out of interest. What are your reasons to for needing (mkv) 'container' aspect ration support?

[hello_hello]

Out of interest. What are your reasons to for needing (mkv) 'container' aspect ration support?

After changing the stream aspect ratio the container aspect ratio wouldn't be the same (it's not set at all) and some players only pay attention to one or the other.

As a quick test I took a 4:3 720x480 MKV and changed the stream aspect ratio to 16:9 with the ffmpeg version I linked to.

I know my Bluray player would play it with a 3:2 aspect ratio.

MPC-HC - 3:2
MPC-BE - 3:2
SMPlayer - 3:2
VLC - 16:9
Potplayer - 16:9

MediaInfo displays:
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Original display aspect ratio : 16:9

You'd imagine given there's no container aspect ratio set at all, players would look at the stream for guidance, but by default they often don't, so it pays to make sure they're both set correctly.

Edit: I tried doing it the other way around... taking a 4:3 MKV and remuxing it as 16:9 with MKVToolNix without changing the video stream, and all the software players displayed it at 16:9. I started to wonder why I'd bother changing the stream aspect ratio, then I remembered the little resizing dance MPC-HC used to do (opening at 4:3 then switching to 16:9). It doesn't seem to do that any more, but I kind of remember a hardware decoding problem.... maybe.... SMPlayer does it very quickly, and I think one of the standalone players gets upset. I'd have to check though.

[nevcairiel]

You'd imagine given there's no container aspect ratio set at all, players would look at the stream for guidance, but by default they often don't, so it pays to make sure they're both set correctly.

Matroska specification says to use the video resolution as aspect ratio (ie. square pixels) when no explicit value is set (ie. DisplayWidth = PixelWidth by default), so any player that obeys the matroska container aspect ratio would be behaving correctly by using 3:2.

In general for containers that can signal an aspect ratio reliably, its usually wise to also use it in a player.

For your last point, MPC-HC probably stopped doing it once it used my decoders. ;)

[Jamaika]

As a quick test I took a 4:3 720x480 MKV and changed the stream aspect ratio to 16:9 with the ffmpeg version I linked to.
So I think that this is an intentional job creators players. If the aspect ratio in the container matroska is treated as a non-standard then why to think about it?

Examples, import&convert file Matorska (pseudo 4K, aspect ratio 16:9) to ASS subtitles editors:
[Script Info]
; Script generated by Aegisub r8898
; http://www.aegisub.org/
ScriptType: v4.00+
PlayResX: 3840
PlayResY: 1600
PlayDepth: 10
WrapStyle: 0
ScaledBorderAndShadow: no
YCbCr Matrix: TV.601

[Aegisub Project Garbage]
Audio File: D:/filmy/Hobbit.Pustkowie.Smauga.(2013).mkv
Video File: D:/filmy/Hobbit.Pustkowie.Smauga.(2013).mkv
Video AR Mode: 4
Video AR Value: 2.400000
Video Zoom Percent: 0.250000
Video Colorspace: TV.2020 NCL
The enormity of mistakes.

For your last point, MPC-HC probably stopped doing it once it used my decoders. ;)
How to define a screenshot? Picture of monitor screen or picture from the original film.;)

How is the transfer of information during the conversion ffmpeg 20161230?
ffmpeg.exe -i 3840x1600.mkv -i subtitle_noinfosize&colorvideo.ass -f matroska -vf scale=3840:1600:out_color_matrix=bt709:out_range=tv,format=yuv420p -aspect 16/9 -c:v libx264 out.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 12.2 MiB
Duration : 19 min 58 s
Overall bit rate mode : Variable
Overall bit rate : 85.5 kb/s
Movie name : Hobbit - Pustkowie Smauga (2013)
Writing application : Lavf57.61.100
Writing library : Lavf57.61.100 / Lavf57.61.100
ErrorDetectionType : Per level 1 ???
...
Color range : Limited
Matrix coefficients : BT.709 <-- No info for file 8bit

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 19 min 58 s
Width : 3 840 pixels
Height : 1 600 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 148 r2744 b97ae06
...
Color range : Limited
Matrix coefficients : BT.709 <-- No info
Default : Yes
Forced : No
DURATION : 00:00:20.983000000

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS <-- No video parameters in the "vsfilter.dll", ie. size video, aspect ratio, color matrix, color range, depth.

[loa-ash]

guys if I append 2 audio files, and I apply a delay onto second file appended, the result file will have the delay that i've choose?

[sneaker_ger]

The delay applied to the second part will be a timecode gap between part 1 and part 2. It will not be at the front of part 1. If you want the delay to apply to the complete track apply it to part 1 only. Leave the delay for the other parts empty.

[loa-ash]

I've add +1000 ms as delay to file appended as testing, but nothing changed...

I've made this:

audio_A = duration 3 sec
audio_B = duration 20 minutes

audio_A(0delay) [APPEND] audio_B(1000delay) = audio_c.mka

If i play audio_c there isn't the 1000ms of delay after 3 sec.

[Mosu]

mkvmerge always shifts timestamps read from a file so that they're 0-based. That's why an existing delay won't be kept.

However, you can apply that delay when you append. On the command line it looks like this:

mkvmerge -o audio_c.mka audio_a.aac + --sync 0:3000 audio_b.aac

In the GUI you select the appended track and enter something in the "delay" field.

[loa-ash]

Ok I understand where I was wrong. After append the two audio, I used mpc-hc for play audio_c.mka just created and didn't see any difference. Instead I had to mux this audio on a video to see the changes. Am I right?

[sneaker_ger]

The gap will be there either way. MPC-HC/LAV might ignore it when playing audio-only linearly. If you seek behind the gap it should be obeyed. I don't know all the logic behind its sync algo.

[Bigmango]

With version 9.7.1 I regularly get a "JSON chain couldn't be analyzed: parse error - unexpected end of input" error when trying to add files to the multiplexer.

It could be caused by FLAC tracks as all my files have FLAC tracks.

And today I could open a file correctly (without FLAC), but when I tried to add 2 FLAC tracks I had just converted with eac3to, the first FLAC gave this JSON error (so I could add it), but the second track was added correctly.

This seems to be happening only to the windows version (windows 10), opening these same files with the linux version seems to work fine.

[Mosu]

Can you upload one such FLAC file to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server), please? Also see this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/JSON-output-could-not-be-parsed).

[Bigmango]

Can you upload one such FLAC file to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server), please? Also see this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/JSON-output-could-not-be-parsed).

Disabling antivirus didn't change anything.

I have sent you the file "1_2_audio.flac".

This file is the result of a DTS-HDMA conversion with eac3to. There were 2 DTS-HDMA tracks converted together. The first track (which I sent you) gives this JSON error on windows (but can be added fine with the linux version), and the second track (which I didn't send) can be added properly as it doesn't give this error.

This is very strange.

Furthermore, I also from time to time (not always) get this error when trying to open mkvs which I have created with this same windows version 9.7.1. (but on linux, same version 9.7.1, I can open these files without any problem).

[nautilus7]

Hi, does mkvmerge support DSD format (the audio format found in SACD)? I have some .dff files and can't mux them into .mka container. Any way to do it? Sample (money.dff) in your ftp.

[Bigmango]

Disabling antivirus didn't change anything.

I have sent you the file "1_2_audio.flac".

This file is the result of a DTS-HDMA conversion with eac3to. There were 2 DTS-HDMA tracks converted together. The first track (which I sent you) gives this JSON error on windows (but can be added fine with the linux version), and the second track (which I didn't send) can be added properly as it doesn't give this error.

This is very strange.

Furthermore, I also from time to time (not always) get this error when trying to open mkvs which I have created with this same windows version 9.7.1. (but on linux, same version 9.7.1, I can open these files without any problem).

Just tested with version 9.7.0. Everything is fine again with this version, so this seems to be a bug with 9.7.1.

Thanks.

[Mosu]

Just tested with version 9.7.0. Everything is fine again with this version, so this seems to be a bug with 9.7.1.

I cannot reproduce your problems here on Windows — neither with 9.7.0, nor with 9.7.1 or the current development snapshot.

It's possible that, for some reason, the GUI's file identification cache contained broken data. Using a different version causes the cached data to be removed, hence why it's working with 9.7.0. It's quite possible that it may work now even if you switch back to 9.7.1.

You should try removing the existing cache directory. If you're using the portable version, it's the "cache" directory next to the MKVToolNix executables. For the installed version look in C:\Users\YourUserName\AppData\Local\bunkus.org\mkvtoolnix-gui.

[Mosu]

Hi, does mkvmerge support DSD format (the audio format found in SACD)? I have some .dff files and can't mux them into .mka container. Any way to do it? Sample (money.dff) in your ftp.

No, mkvmerge doesn't, nor does Matroska in general.

[SeeMoreDigital]

No, mkvmerge doesn't, nor does Matroska in general.That's a real shame.

That said, somebody would then need to create a parser/splitter to support playback of such contained streams ;)

[Bigmango]

You should try removing the existing cache directory. If you're using the portable version, it's the "cache" directory next to the MKVToolNix executables. For the installed version look in C:\Users\YourUserName\AppData\Local\bunkus.org\mkvtoolnix-gui.

Removing this cache directory seems to have fixed the problem.

Thanks.

[Perenista]

I have a video recorded by FRAPS that is using these settings (in terms of Aspect Ratio):
http://i.imgur.com/fX3BhbN.png

If I wanted to use these settings:
http://i.imgur.com/FwJzKds.png

And do not reencode the Matroska, what would I need to do in MKVToolnix? I know there's a setting called "Set aspect ratio", but I don't think that will suffice in this case.

[sneaker_ger]

And do not reencode the Matroska, what would I need to do in MKVToolnix? I know there's a setting called "Set aspect ratio", but I don't think that will suffice in this case.
Why not? Do you want to force black bars on all 4 sides? I think that's indeed not possible. Otherwise just choose AR 1.339 (well, basically 4/3) when muxing using mkvmerge (or add/change the values in exisiting Matroska files using the Header Editor).

[hello_hello]

The MKVToolNix cache folder.....

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

I almost always add the initial file or stream to be muxed via the Explorer right click SendTo menu. ie Right Click/SendTo/mkvtoolnix-gui.exe. but as the number of files in the cache folder increases, so too does the amount of time it takes MKVMergeGUI to "get itself ready". If MKVMergeGUI isn't running when I add a file that way, the GUI still opens in a speedy manner, but all the input fields are initially "greyed out", I assume until MKVMerge has finished loading the cache files.

I haven't timed it exactly, but at the moment the cache folder contains 894 files totalling 3.9MB, which doesn't seem excessive (in respect to size), however the time between the GUI opening and the input fields becoming usable would now be close to ten seconds.

I doesn't happen every time the GUI is opened. If I close it and open it again in a short period of time, it opens normally, but if too much time has passed between closing and re-opening, it goes back to taking a long time to become ready. I assume that must due to the cached data still being in RAM, or not, as the case may be.

I deleted the contents of the cache folder a short while ago, and so far that seems to have fixed the slow opening problem, but I've only used MKVToolNix a couple of times since then, so time will tell.

Thanks.

[Mosu]

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

Obviously, that shouldn't happen.

If MKVMergeGUI isn't running when I add a file that way, the GUI still opens in a speedy manner, but all the input fields are initially "greyed out", I assume until MKVMerge has finished loading the cache files.

Interesting interaction. The GUI has a cleanup process for the cache directory. It is supposed to remove cache files that were created with an older version. It is run in a separate thread as it isn't supposed to affect normal operation of the GUI, and it's started right when the GUI starts.

The problem here is most likely that every access to the cache directory is guarded by a mutex so that only one thread can access it at any given moment. The cleanup process acquires a lock on this mutex when it starts and releases said lock once it finishes. At the same time the file identification tries to acquire a lock on the same mutex which has to wait until the cleanup process is finished.

A fix might be as trivial as to change the cleanup process to release and re-acquire the lock after each file it has processed. That way the file identifier's lock request can be processed, too.

I doesn't happen every time the GUI is opened. If I close it and open it again in a short period of time, it opens normally, but if too much time has passed between closing and re-opening, it goes back to taking a long time to become ready. I assume that must due to the cached data still being in RAM, or not, as the case may be.

Yeah, that's likely due to OS-level caching.

Thanks for describing this so accurately. It's definitely a bug, and I'll definitely fix it.

[hello_hello]

I have another cache question......

In the past I've tended to load video files/streams into MKVMergeGUI for muxing before they're completed, so today I opened an MKV the x264 encoder was in the process of writing as it encoded and checked the cache file info. I closed MKVTookNixGUI and opened the MKV again. The cache file was overwritten but only the two "objectID" values had changed.

Are the "objectID" values important for correct muxing? I ask because there's a very good chance that after having opened the MKV a second time, I'd leave it loaded in MKVToolNixGUI until x264 has finished encoding, then I'd mux it.
If I remove it from the GUI first though, and open it again after the video encoding has finished, I assume the "objectID" values would change again. If I don't do that, they remain the same in the cache file. Does it matter?

Thanks.

[Mosu]

The GUI uses several pieces of inormation to determine whether the cache entry is still valid: the GUI's version, the file's name/size/last modification timestamp. As the latter two properties change with a file that's still written to, the GUI will invalidate the entry the next time the file must be identified.

I don't know which "objectID" values you mean.

[hubblec4]

The "objectID" is very impotant!
MTX-gui needs this for the correct order (display and muxing).
The "objectID" changes every time when you change the input.

[Mosu]

Ah _that_ objectID.

hubblec4 is not entirely correct. The important thing about the objectID is that it is consistent within the same file so that the track order works correctly. However (!), it is totally unimportant that it changes each time such a cache file is created, and even more important, the objectID does NOT depend on the identification output.

So yes, you can continue using the already-loaded file.

[Mosu]

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

This has been fixed in the latest pre-builds (01414 and higher) (https://mkvtoolnix.download/windows/pre/64bit/). The cache cleanup will no longer inhibit the file identification from running, and cache cleanup will only be done once per release of MKVToolNix.

[hello_hello]

This has been fixed in the latest pre-builds (01414 and higher) (https://mkvtoolnix.download/windows/pre/64bit/). The cache cleanup will no longer inhibit the file identification from running, and cache cleanup will only be done once per release of MKVToolNix.

Thanks. I'll give it a spin and report back.

[v0lt]

I have a problem with converting some MPEG-2 files. After packing in MKV files are not played back smoothly in MPC-BE and MPC-HC.
The problem would be solved enabling the option "enable time correction". But it's not the best solution.

What is it? Incorrect operation of mkvtoolnix or the player?

Here are the first 10 timestamps that gives spitter.
Frame: 0, TimeCode: 138
Frame: 1, TimeCode: 58
Frame: 2, TimeCode: 98
Frame: 3, TimeCode: 258
Frame: 4, TimeCode: 178
Frame: 5, TimeCode: 218
Frame: 6, TimeCode: 378
Frame: 7, TimeCode: 298
Frame: 8, TimeCode: 338
Frame: 9, TimeCode: 498
Frame: 10, TimeCode: 418

And here is another file. It played good.
Frame: 0, TimeCode: 680
Frame: 1, TimeCode: 720
Frame: 2, TimeCode: 840
Frame: 3, TimeCode: 760
Frame: 4, TimeCode: 800
Frame: 5, TimeCode: 960
Frame: 6, TimeCode: 880
Frame: 7, TimeCode: 920
Frame: 8, TimeCode: 1080
Frame: 9, TimeCode: 1000
Frame: 10, TimeCode: 1040

[Aleksoid1978]

Player must playback such files normal - upload short sample.

[v0lt]

mpeg2_25i_normal.mkv and mpeg2_25i_unsmooth.mkv (https://cloud.mail.ru/public/Lmye/SZQkqtYeU)

PS: I tried to check these files on my Sony TV, but it does not support MPEG-2 video in MKV files.

Added:
Maybe this problem comes from MPC-BE and LAV decoders. This problem occurs on all system renderer. That is not with Haali and madVR.
If I use Microsoft DTV-DVD Video Decoder, the problem goes away for all renderers except Haali (there is a black screen).

[Aleksoid1978]

mpeg2_25i_normal.mkv and mpeg2_25i_unsmooth.mkv (https://cloud.mail.ru/public/Lmye/SZQkqtYeU)

PS: I tried to check these files on my Sony TV, but it does not support MPEG-2 video in MKV files.

"Bug" in video-decoders, in timestamp handle logic. Both files playback smooth with ffplay.exe and also in MPC-BE with MPEG-2 decoder(libmpeg2).

[SeeMoreDigital]

Hi v0lt,

Both files play okay on my Panasonic when cast via UPnP.

However, when I tried de-muxing and re-muxing the .mkv files they both appeared to be buggy :(

[Mosu]

A nice new release is here, v9.8.0. Couple of enhancements, a couple of bug fixes, especially for the new caching functionality introduced in 9.7.0. I recommend upgrading.

Notes for package maintainers: important changes were made to the build process. Please see the NEWS section below for details (both the "important news" and the "build system changes" sections).

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & Mac OS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and Mac OS binaries have been built already and are available for download. The Linux binaries will be available later today.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since v9.7.1:

# Version 9.8.0 "Kuglblids" 2017-01-22

## Important notes

* build system: the included version of the "drake" build tool has been removed. Since Ruby 2.1 rake has supported parallel builds, too. The MKVToolNix build system has been adjusted to enable parallel builds by default.

## New features and enhancements

* mkvmerge: VobSub in Matroska: mkvmerge will now create and use a default index for VobSub tracks read from Matroska files that are missing their CodecPrivate element (which normally contains said index). Implements #1854 (https://github.com/mbunkus/mkvtoolnix/issues/1854).
* GUI: added checks for several common problems with the installation. These checks will be executed when the GUI starts, and any problems will be reported to the user.
* mkvmerge: added the ISO 639-2 language codes "qaa" and "qad" (both are titled "reserved for local use") as both are used often in France. See #1848 (https://github.com/mbunkus/mkvtoolnix/issues/1848) for more information.
* mkvmerge: the JSON identification result now includes a track's codec delay if set (only for Matroska source files). The JSON schema version has been bumped to 6.
* mkvmerge: MPEG TS: added a workaround for files where the subtitle packets are multiplexed properly, but where their timestamps are way off from the audio and video timestamps. Implements #1841 (https://github.com/mbunkus/mkvtoolnix/issues/1841).
* mkvmerge: added support for Digital Video Broadcasting (DVB) subtitles (CodecID `S_DVBSUB`). They can be read from MPEG transport streams and from Matroska files. Implements #1843 (https://github.com/mbunkus/mkvtoolnix/issues/1843).

## Bug fixes

* mkvmerge: MP4 reader: when an MP4 file contained fewer entries for timestamps than frames (which they never should), mkvmerge would use 0 as the timestamp for all the other frames. This resulted in effects such as the last frame of an output file having a timestamp of 0 and in split files having a much longer duration than they should have. Fixes #1847 (https://github.com/mbunkus/mkvtoolnix/issues/1847).
* GUI: the cache cleanup process that's run automatically when the GUI starts no longer blocks file identification until it is finished. Additionally the process will only be run once per release of MKVToolNix. Fixes #1860 (https://github.com/mbunkus/mkvtoolnix/issues/1860).
* GUI: certain failures during file identification that can be traced to broken installations (e.g. mkvmerge being too old) won't be stored in the cache anymore. Without this fix the GUI would still use the cached failed identification result even though the underlying might have already been fixed.
* mkvmerge: fixed that the error message "not enough space on disk" was shown twice on some operating systems. Fixes #1850 (https://github.com/mbunkus/mkvtoolnix/issues/1850).
* mkvmerge, Matroska: if a codec delay is set for a track in the input file, it is kept. Fixes #1849 (https://github.com/mbunkus/mkvtoolnix/issues/1849).
* GUI: multiplexer: changing default values in the preferences (e.g. the default track language to set) did not affect files whose identification results had already been cached.
* mkvmerge, MP4: fixed detection of MP3 audio when the object type ID in the ESDS signals MP2 and the track headers have invalid values for number of channels or sampling frequency. Fixes #1844 (https://github.com/mbunkus/mkvtoolnix/issues/1844).

## Build system changes

* nlohman json-cpp: configure now looks for a system-wide installed version of the nlohmann json-cpp header-only library. If one is found, it is used; otherwise the included version will be used. Implements #1858 (https://github.com/mbunkus/mkvtoolnix/issues/1858).
* If MKVToolNix is built with rake v10.0.0 or newer, its "multitask" feature will be turned on allowing automatic parallel builds.
* CURL is no longer used by MKVToolNix and is therefore not required for building anymore.

## Other changes

* GUI: the update check now uses Qt's networking classes instead of CURL.
* The command line option "--check-for-updates" has been removed, even though the deprecation warning in release 9.7.0 stated that it would be removed in 2018.

Have fun :)

[videoh]

Thanks, Mosu!

Update thread title?

[jmartinr]

On fosshub the link to the 64bit installer points to an android img file.

[Mosu]

Works fine for me. Clear your browser's cookies, reload the download page, try again. If the problem persists, then please contact the [url=https://www.fosshub.com/contact.htmlFossHub staff[/url]. They're usually pretty quick to fix such issues.

[jmartinr]

It's ok now.

[Q-the-STORM]

I have a feature request:
Can you make it possible inject HDR metadata in x264 video?

only applications I know that can do it are from avtop, SEIedit (250€) and HDRmaster (500€).

I found a modified version of mkvmerge that seems to be able to do it: https://github.com/YouTubeHDR/hdr_metadata
but my TV (LG E6) doesn't detect the metadata.

[Selur]

@Q-the-STORM: https://github.com/SK-Hardwired/nv_hevc_hdr_patcher might be worth a look.

[Mosu]

Can you make it possible inject HDR metadata in x264 video?

I won't add such functionality.

[hello_hello]

Originally Posted by Mosu
This has been fixed in the latest pre-builds (01414 and higher). The cache cleanup will no longer inhibit the file identification from running, and cache cleanup will only be done once per release of MKVToolNix.

Thanks. I'll give it a spin and report back.

Just letting you know there's been no slowdown when opening files since prebuild 01414 and version 9.8.0

Thanks.

[kuchikirukia]

Just had a power outage. When I restarted mkvmerge, it attempted to redo the last 7 muxes. Thankfully it only overwrote a BDMV remux, which I can redo.