MKVToolNix v99.0 released

[Nico8583]

I have a strange result with some subtitles (chinese).
I extract a subtitle stream from tsMuxeR : file size 28,3MB / 1678 subtitles
Then I mux it to MKV and extract it to sup : file size 55,6MB / 3360 subtitles
If I mux directly from BD to MKV and extract it to sup : file size 28,3MB / 1678 subtitles
Is it a known "issue" ? SUP is OK from BD to tsMuxeR, SUP is OK from BD to MKV but SUP is not OK from BD to tsMuxeR to MKV.
Thank you.

Edit : Last subtitle timecode from 1678 subtitles file : 02:15:50,976
Last subtitle timecode from 3360 subtitles file : 04:31:45,789

Edit 2 : Just tried DGDemux instead of tsMuxeR, it's OK so it seems to be a tsMuxeR issue

[tebasuna51]

It plays fine in sync with MPC-HC, but... Is it realy what it should be...:confused:

Yes, it is fine.

But if you are confused a little more info about MediaInfo options:

For what the two videos have the same duration with a different FPS, and the frames are the same?

Because rounding info data with similar fps.
In the MediaInfo window check Debug-> Advanced mode
Then you can see more exact data like:

...
Duration : 00:01:36.200
Frame rate : 25.000
Frame count : 2405
...
Where Duration = 2405/25

In your two videos it's not possible have the same exact duration and frame count with different fps.
Or have different duration or frame count.
Whit the same frame count one can be 1:44:00 and other 1:44:06, only 6 seconds rounded to 1:44 but enough to unsync the audio.

What is the correct one? I can't know, old film movies are 24 fps, but digital ones can be at 23.976.

In order to play you can't see differences between both.

[jpsdr]

Ok, thanks.

[Boulder]

Does mkvmerge keep the Dolby Vision metadata (from RPU) when joining AV1 or HEVC files? Or is this kind of functionality even supported without messing up the RPU?

[Mosu]

It does, yes. That being said, the same restrictions apply as for appending other H.26x content (where the codec private data must match): the global Dolby Vision data must match as well — though that isn't checked right now, but only the parts of the first file are kept if I remember correctly.

Caveat emptor: I haven't really tested this a lot.

[Boulder]

It does, yes. That being said, the same restrictions apply as for appending other H.26x content (where the codec private data must match): the global Dolby Vision data must match as well — though that isn't checked right now, but only the parts of the first file are kept if I remember correctly.

Caveat emptor: I haven't really tested this a lot.

In this case, the data doesn't match as each file would have its own RPU. My idea was to do parallel chunked encoding by splitting the RPU file accordingly and join the chunks later. Looks like it's not going to work.. HEVC in Matroska can have RPU injected afterwards, but AV1 does not have such tools yet.

[Mosu]

For HEVC appending will likely work even if the global DoVi data doesn't match as nothing's removed from the bitstream. All UNSPEC62 & UNSPEC63 NALUs are kept, and the global data (dvcC, dvvC, dvwC in MP4 speak) is derived solely from those NALUs.

[Boulder]

For HEVC appending will likely work even if the global DoVi data doesn't match as nothing's removed from the bitstream. All UNSPEC62 & UNSPEC63 NALUs are kept, and the global data (dvcC, dvvC, dvwC in MP4 speak) is derived solely from those NALUs.

Looks like it works with AV1 as well, at least DoVi is detected by MediaInfo which is not the case with ffmpeg-joined files. I'll just need to ask quietvoid if he knows whether the approach would affect playback in a negative way.

[quietvoid]

Since mkvmerge doesn't change the bitstream as Mosu said, it should be fine to do whatever.
I've had a script do chunked AV1 encodes with RPU and they played fine.

[von Suppé]

I mux doing the following :
Audio is from Film_23_976 untouched, video is from Film_24_000 with FPS set to 24000/1001 + "Fix bitstream" checked.

Result is :

General
Format : Matroska
Format version : Version 4
Duration : 1 h 44 min
Frame rate : 24.000 FPS
Writing library : libebml v1.4.5 + libmatroska v1.7.1

Video
ID : 1
Format : HEVC
Duration : 1 h 44 min
Frame rate mode : Constant
Frame rate : 24.000 FPS

It plays fine in sync with MPC-HC, but... Is it realy what it should be...:confused:

Timestamps can be written on contaner-level and in-elementary-stream. Which two can differ. Therefore (proper) playback depends on which of the two timestamps are honoured by the player.
Unless things have changed recently, the "Fix bitstream timing info" only works for AVC video. Read here:

https://mkvtoolnix.download/doc/mkvmerge.html#d4e1980 scroll down to "--fix-bitstream-timing-information"

I like to have timestamps in both elementary video and container being the same. To rewrite timestamps for HEVC I use ffmpeg.exe. Two command-lines I often use are:

For 24 fps:
ffmpeg -i input.hevc -c copy -bsf:v hevc_metadata=tick_rate=24:num_ticks_poc_diff_one=1 output.hevc

For "23.976" fps:
ffmpeg -i input.hevc -c copy -bsf:v hevc_metadata=tick_rate=(24000/1001):num_ticks_poc_diff_one=1 output.hevc

[tebasuna51]

https://mkvtoolnix.download/doc/mkvmerge.html#d4e1980 scroll down to "--fix-bitstream-timing-information"

You are right, don't work with HEVC video.
Maybe Mosu can limit or add that Note to the help text.

Then the ffmpeg tool must be used. Also work eac3to:

eac3to input24.mkv 1: output.h265 -changeTo23.976

[von Suppé]

With eac3to I have much used the changeTo... for AVC. Simply didn't know it could do also for HEVC. Thanks for letting this know.

[Mosu]

Heyoooo!

Here's a tiny release with two small new features. Mostly it's so small because we've spent quite a lot of time improving & reworking two underlying libraries libEBML & libMatroska that MKVToolNix uses, among with required adjustments to MKVToolNix's source code as well.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.html) and the source code (https://mkvtoolnix.download/source.html).

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 (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 83.0 "Circle Of Friends" 2024-03-10
New features and enhancements

translations: added a Belarusian translation of the programs & the man pages by prydespar (see "AUTHORS").
mkvmerge, MKVToolNix GUI's chapter editor: added support for reading chapters from ffmpeg metadata files. Implements #3676 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3676).
MKVToolNix GUI: added a new action type for execution after jobs or the queue finishes: quitting MKVToolNix. Implements #3677 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3677).

Build system changes

The bundled "fmt" library was updated to v10.2.1.

Other changes

Tons of changes were made to support the latest development versions of libEBML & libMatroska.


Have fun 😁

[XinHong]

Hello Mosu,

For the 64bit portable 7z version Windows (Windows antivirus) is detecting a virus, do you confirm this file is safe ?
https://mkvtoolnix.download/windows/releases/83.0/mkvtoolnix-64-bit-83.0.7z

[Mosu]

It's fine. A/V mis-detection happens from time to time with newly compiled programs that haven't been around a lot yet, especially after having changed the code signing certificate a couple of months ago (the old one expired). See this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Virus-in-installer) for more information.

[Mosu]

Addendum: I've submitted the file to Microsoft for further analysis, and they agree with me assessment (https://www.microsoft.com/en-us/wdsi/submission/83c0d9e0-4966-4739-9b25-61f52c5e45d6) that the files are harmless. The signature will be removed from detection.

[XinHong]

Yes that's fine now, thanks

[jpsdr]

I gave to a frien an mkv muxed with the 82.0.49 version.
He told me that he cannot fast forwad or advance fast with all his players, except with VLC.
I also gave an mkv muxed with mkvtoolnix, but i made 4 years ago (around) i think.
He had no issue with this one.
According his net research, it's some kind of "indexing issue".

Does this ring a bell to someone ?
Is there some kind of default setting which could have changed in mkvtoolnix during the last (around) 4 year, concering "indexing" ?
If it rings a bell to someone, what's the "fix" (or setting) ?

[Dogway]

I gave to a frien an mkv muxed with the 82.0.49 version.
He told me that he cannot fast forwad or advance fast with all his players, except with VLC.
I also gave an mkv muxed with mkvtoolnix, but i made 4 years ago (around) i think.
He had no issue with this one.
According his net research, it's some kind of "indexing issue".

Does this ring a bell to someone ?
Is there some kind of default setting which could have changed in mkvtoolnix during the last (around) 4 year, concering "indexing" ?
If it rings a bell to someone, what's the "fix" (or setting) ?

Happening to me for the last 6 months or so. It freezes for about 30s or a minute when jumping to a different section of video.
I don't think it's an issue with MKV as remuxing to MP4 doesn't make a difference, and this doesn't happen remuxing to MKV from downloaded MP4.
Maybe it has to do with x264 build (always use Ligh's build). I updated to latest from him and I will check in following encodes.

[jpsdr]

The issue is that it happened on a around 4 years old MKV, i remuxed. The old MKV was "fine", the new not, so... Aside MKVToolnix, i don't see anything else... :(

[blob2500]

The issue is that it happened on a around 4 years old MKV, i remuxed. The old MKV was "fine", the new not, so... Aside MKVToolnix, i don't see anything else... :(
I have always had the same problems, but on hardware players (PVR, BD players etc.).
I always resolve with these settings:

https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Improving-playback-compatibility-with-players

in .ini file of MKVtoolnix, "Defaults" section:

defaultAdditionalMergeOptions=--clusters-in-meta-seek --disable-lacing --disable-track-statistics-tags --disable-language-ietf --engage no_cue_duration --engage no_cue_relative_position --engage no_simpleblocks

[jpsdr]

Ohhhh... :thanks:
Very interesting.
I'll just try for now just to remove the "cue", as it's something new, so it can explain the difference between the at least 4 years mux and the mux now.

[Boulder]

I've had --engage no_cue_duration --engage no_cue_relative_position --disable-track-statistics-tags in Additional options for years, no playback issues with various devices.

[tebasuna51]

I've had --engage no_cue_duration --engage no_cue_relative_position --disable-track-statistics-tags in Additional options for years, no playback issues with various devices.

+, the same.

[jpsdr]

The "cue" was indeed the guilty, i remuxed with the option removing them, and my friend told me that all issues were gone.
Thanks for these informations.

[Perenista]

https://i.postimg.cc/CwfKkY7T/DISA.jpg

Question: how do I make MKVToolnix never assume anything in this field? (FILE TITLE)

I want this to be always blank for 100% files I edit, no matter what was there before (of course if it was already blank, it shouldn't be filled with anything; if wasn't, MKVToolnix should not add anything new).

[WontonNoodle]

Question about remuxing discs: why does directly remuxing with mkvtoolnix via the playlist file result in different audio delays vs demuxing with eac3to then remuxing with mkvtoolnix? And which is correct? This was a seamless branching disc btw.

I demuxed with eac3to which showed a -9ms delay for the dts track. "[a03] Applying DTS delay..." was in the log so I believe it applied the -9ms delay to the dts track.
Directly remuxing with mkvtoolnix reports a +2ms delay for the dts track in the resulting mkv in mediainfo.

I extracted the track and put both into audacity, and it does show a 11 ms difference between the tracks, with the direct remux being 11 ms after the eac3to demux track.
Which is correct and the better way to rip discs?

EDIT: i've also found makemkv to be the worst when it comes to audio sync, it seems like files progressively get out of sync with makemkv.

[hubblec4]

This is a question of duplicated Audio frames which are removed by eac3to/DGDemux.
MTX is not able to remove this frames.

For seamless branching discs you could try my chapterEditor which is special designed for this task.

[WontonNoodle]

This is a question of duplicated Audio frames which are removed by eac3to/DGDemux.
MTX is not able to remove this frames.

For seamless branching discs you could try my chapterEditor which is special designed for this task.

Ah I see. Will try chaptereditor thanks. Btw is the eac3to demux then remux delay correct in any case? Or should I just use chaptereditor for best results?

[hubblec4]

cE uses eac3to in the background, but keep in mind there is a new version of eac3to.
The result with or without cE is equal to use eac3to separate and mux manually with MTX.

But a disc with seamless branching has often more than one Edition of the movie. Only with cE you can create a Multi-Edition-MKV of this disc.

[WontonNoodle]

cE uses eac3to in the background, but keep in mind there is a new version of eac3to.
The result with or without cE is equal to use eac3to separate and mux manually with MTX.

But a disc with seamless branching has often more than one Edition of the movie. Only with cE you can create a Multi-Edition-MKV of this disc.

I tried chaptereditor (i linked mkvtoolnix and eac3to only? not sure if that was correct). It resulted in a mkv with video frames that didnt match up with the bluray disc. The resulting dts track in audacity gave a 329 ms delay near the middle of the movie.

I also tried dgdemux you mentioned and it resulted in a 46 ms delay in the same spot near the middle of the movie. I didnt mux video with this so I didn't check where the frames lined up.

The odd thing is that every track starts at the same ms point so they just progressively get out of sync at different rates. I didn't realize this until now so I have to check the mkvtoolnix track again for sync in the middle of the movie. I'm still not sure which method generates a correctly synced audio track for seamless branching discs.

btw what im trying to do is mux the dts audio from Avatar to my UHD Avatar rip which only has the theatrical cut.

[hubblec4]

I tried chaptereditor (i linked mkvtoolnix and eac3to only? not sure if that was correct).
Maybe you need to set the BDSup2Sub path.


It resulted in a mkv with video frames that didnt match up with the bluray disc. The resulting dts track in audacity gave a 329 ms delay near the middle of the movie.
Sounds like you don't demux the Audio stream. Also in cE you must demux the Audios(it's only a click).


I also tried dgdemux you mentioned and it resulted in a 46 ms delay in the same spot near the middle of the movie. I didnt mux video with this so I didn't check where the frames lined up.
Yes the finial mkv is the important thing. 46ms is more than one Video frame.



The odd thing is that every track starts at the same ms point so they just progressively get out of sync at different rates. I didn't realize this until now so I have to check the mkvtoolnix track again for sync in the middle of the movie. I'm still not sure which method generates a correctly synced audio track for seamless branching discs.

This is a hugh topic and so easy to explain.
You can read this thread (https://www.rationalqm.us/board/viewtopic.php?f=16&t=1298&sid=1798cc6ef152e0134e2bc8ba2ed4fe70).

A movie with several m2ts files, will be problematic. This is a nature of Codec design and Matroska design.


btw what im trying to do is mux the dts audio from Avatar to my UHD Avatar rip which only has the theatrical cut.
Also a big problem. to combine tracks from different discs/sources. Only manually things like Audio re-encoding could be help.

[WontonNoodle]

ok so chaptereditor and mkvtoolnix results in mismatching frames for the video compared to the disc
dgdemux and eac3to result in the same frames as the disc
however dgdemux dts track progressively gets more and more out of sync (starts with 0 difference, then 11 ms delay, then up to 54 ms delay vs the eac3to track as the movie goes on)

so either the dgdemux or eac3to track is correct? any ideas as to which one is the right one.
i also tried on a non branching disc and mkvtoolnix, dgdemux, and eac3to all result in the same audio sync.

EDIT: thanks ill read that thread

[markfilipak]

... dgdemux dts track progressively gets more and more out of sync (starts with 0 difference, then 11 ms delay, then up to 54 ms delay vs the eac3to track as the movie goes on)

What makes you believe that? What indicates DTS to you? "starts with 0 difference" means what to you -- difference between DTS and what?

--Mark.

[WontonNoodle]

What makes you believe that? What indicates DTS to you? "starts with 0 difference" means what to you -- difference between DTS and what?

--Mark.

I loaded all the dts tracks that were demuxed in audacity and shift+z to see the time differences between the tracks at different durations. The tracks are the exact same sonically so it's easy to see where the waves are supposed to match. The delay is with respect to the eac3to demuxed track. The only problem is I dont know which one is correct.

EDIT: I just did some quick frame by frame resuming from the remuxes vs the disc on some gunfire near the end of the movie and the eac3to track is the correct one FYI. the dgdemux audio is delayed by a frame. thanks all

[markfilipak]

I loaded all the dts tracks that were demuxed in audacity and shift+z to see the time differences between the tracks at different durations. The tracks are the exact same sonically so it's easy to see where the waves are supposed to match. The delay is with respect to the eac3to demuxed track. The only problem is I dont know which one is correct.

There is no such thing as a DTS track. Why are you writing "DTS"? I mean no disrespect. I mean to help. But "DTS" doesn't mean what you think it means.

Edit: You probably mean PTS. So you say that frame PTSs get "out of sync". Out of sync with what? With what it started as? Look at the frame rates? Do they differ?

[WontonNoodle]

There is no such thing as a DTS track. Why are you writing "DTS"? I mean no disrespect. I mean to help. But "DTS" doesn't mean what you think it means.

What? When you demux you get a .dts track and you can load all the channels in audacity via ffmpeg

[markfilipak]

What? When you demux you get a .dts track and you can load all the channels in audacity via ffmpeg

Is that a file extension? 'something.dts', like 'something.mp4' or 'something.mkv'?

[rco133]

ok so chaptereditor and mkvtoolnix results in mismatching frames for the video compared to the disc
dgdemux and eac3to result in the same frames as the disc
however dgdemux dts track progressively gets more and more out of sync (starts with 0 difference, then 11 ms delay, then up to 54 ms delay vs the eac3to track as the movie goes on)

so either the dgdemux or eac3to track is correct? any ideas as to which one is the right one.
i also tried on a non branching disc and mkvtoolnix, dgdemux, and eac3to all result in the same audio sync.

EDIT: thanks ill read that thread

Hi.

This may be becoming a bit off topic for MKVToolnix thread.

The author of dgdemux/dgindenv have put a lot of effort into getting seamless branching audio and subs to be in sync, and according to the author I think a maximum of 10-15 ms or so should be the result. If you find that the delay for dgdemux is 54 ms off, I am sure he would like to know.

There are also some other tools that can handle seamless branching discs, but due to technical limitations, you will always end up with some slight delay.

Btw, the "old" eac3to versions below 3.40 all have various issues with seamless branching discs. Especially subs getting way out of sync at the end.

I am sure you can find long threads about it here, and it has also been discussed in lenth on the dgdemux/dgindexnv forum.

rco133

[Mosu]

There is no such thing as a DTS track. Why are you writing "DTS"? I mean no disrespect. I mean to help. But "DTS" doesn't mean what you think it means.

Edit: You probably mean PTS. So you say that frame PTSs get "out of sync". Out of sync with what? With what it started as? Look at the frame rates? Do they differ?

markfilipak: you're talking about timestamps (DTS = decode timestamp, PTS = presentation timestamp), whereas WontonNoodle's talking about the audio codec family called DTS (https://en.wikipedia.org/wiki/DTS_(company)#DTS_technologies). A "DTS track" is therefore an audio track encoded with one of the various DTS codecs.

[hubblec4]

ok so chaptereditor and mkvtoolnix results in mismatching frames for the video compared to the disc
Do you had demuxed the tracks inside cE? I have never issues with the video frames.



dgdemux and eac3to result in the same frames as the disc
however dgdemux dts track progressively gets more and more out of sync (starts with 0 difference, then 11 ms delay, then up to 54 ms delay vs the eac3to track as the movie goes on)

so either the dgdemux or eac3to track is correct? any ideas as to which one is the right one.
i also tried on a non branching disc and mkvtoolnix, dgdemux, and eac3to all result in the same audio sync.



Both tracks, eac3to.dts and dgdemux.dts are fine, but not perfect, and this is also never possible.

The whole issue comes from the different durations of the frames. A video frame has a duration of 24000/1001 ms (round about 41,708 ms). A .DTS frame has a duration of 32ms (hope I'm right)

Let's say our movie has only one video frame:
When we use only one Audio frame there are now more than 9 ms playtime of the video without sound.
For Blu-ray and maybe all other disc formats:
The Audios are always longer than the video.

So we have to use 2 Audio frames for our One-Video-Frame-Movie.
Now is the Audio duration 64ms and plays 22ms longer then the video.

But when the movie uses multiple m2ts files, for each m2ts there is now a bit more Audio as Video.
eac3to and DGDemux drops Audio frames when the desynch reach a certain limit.

There are also more discussion on Reddit (https://www.reddit.com/r/chapterEditor/comments/18i4r6s/small_problem_with_chapters_in_multiedition_mkvs/).
I have written a lot email with this user and he work on a method where no demuxing is necessary.
He means removing Audio data is not good, and he inspired me to look deeper in the BD-specs.
And he is absolute right.
But to keep the entire data and playback then correctly is currently not possible, but maybe in a near future.
I am excited if he can make it to run.
When you preserve all the m2ts files in separate mkv files and use Linked-Ordered-Chapters, this could work.

[Ripman]

GM M. Just posting to let you know that your sw is “top-shelf.” Feature rich, never crashes, sensible layout, man pages, prior versions, cli…. It’s all there. I even see Reddit posts about mkvtoolnix. Really great product.

Thanks for the new version too. Best….

[Mosu]

Thank you very much for your kind words!

[NumberSix]

Hi, all

New to this forum - apologies if this query is in the wrong place.

Have been using mkvtoolnix for a number of years now and it has been a fantastic bit of software - many thanks to the author.

I am just trying to remux rips of my copies of the Top Gun 4K UHD Blu rays and am confused about how to handle the Dolby Vision data.

I am using MakeMKV to copy BDMV folder structures from the discs, and then eac3to to demux to individual streams from the relevant playlists. The demuxing process produces two video streams. My understanding one is the HDR10 "base" layer, and the second (1080p "resolution") stream is the "enhanced" layer track used for DV metadata.

My question is, how should this be processed when remuxing into an MKV using mkvtoolnix? I am simply adding both files to the GUI as separate video tracks - but I have no idea if this is the right process to use?

On v81.0, if it's relevant.

Thanks!

[Mosu]

mkvmerge can read Dolby Vision directly from other Matroska files or from MPEG transport streams (M2TS), but it cannot combine two raw elementary streams. Therefore the "demux the tracks with eac3to" stept is breaking this workflow. Why are you demuxing in the first place?

[NumberSix]

Thanks for the prompt reply!

I am demuxing due to the mixed results I've had when using mkvtoolnix or other tools to read directly from mpls/m2ts. Using eac3to to demux before remuxing in a tool like mkvtoolnix has been the most reliable approach to dealing with titles that use seamless branching on the disc.

Is there any way to combine the streams prior to feeding into mkvtoolnix?

[hubblec4]

Hi NumberSix
For demuxing seamless branching discs with HEVC(+DV) you must use DGDemux for demuxing. And better you use chapterEditor, it is extra designed for such a task.

[Mosu]

Hey y'all.

MKVToolNix v84 is out, with a handful of bug fixes & a handful of enhancements. The usual stuff.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the downloads section (https://mkvtoolnix.download/downloads.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows packages as well as the Linux AppImage are available already. The other Linux packages are still being built and will be available over the course of the next couple of hours.

Please note that due to technical reasons I haven't been able to build the macOS disk image yet. I don't know when I'll be able to fix it.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 84.0 "Sleeper" 2024-04-28
New features and enhancements

mkvmerge: added a new file-specific option "--regenerate-track-uids". When used for Matroska files, "mkvmerge" will generate new random track UIDs instead of keeping existing track UIDs. This is done automatically when a Matroska file was created by MakeMKV.
mkvmerge: MP4 reader: added support for FLAC in MP4. Implements #3692 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3692).
MKVToolNix GUI: multiplexer: the "Attachments" tab's title will now include the total number of attachments (both from source files & to newly attach). Implements #3693 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3693).
translations: added a Norwegian Bokmål translation of the programs by Roger Knutsen (see "AUTHORS").

Bug fixes

configure: when called with "--disable-gui" the build system still ran the check for the GUI libraries & failed if they weren't found. This check is now skipped when the option is given. Fixes #3680 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3680).
mkvmerge: several color-related track header properties were parsed into & stored as a wrong integer type internally. This could result in wrong values being copied when very large values were present in source files, or in error messages when very large values were used as command-line parameters.
MKVToolNix GUI: multiplexer: the keyboard shortcuts from the "modify selected tracks" sub-menu didn't work right after opening a file. They only started working after opening the "multiplexer" menu. Fixes #3681 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3681).

Build system changes

Release v8.0.0 of the "fmt" library is now required. If not found, the bundled copy will be used.
A C++20 compatible compiler is now required for several but certainly not all C++20 features. g++ v10 & clang++ v10 should suffice.


Have fun 😁

[shearerc]

Hi Mosu,

Your latest Windows binaries are signed by the sub-CA "GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1" of the "DigiCert Trusted Root G4" root CA.

Our Windows 10 and 11 machines do not have the sub-CA "GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1", and I can't seem to find this intermediate cert anywhere.
It's strange, because normally a CA will make them available for download like these:
https://www.gogetssl.com/wiki/intermediate-certificates/gogetssl-intermediate-root-certificates/
https://www.digicert.com/kb/digicert-root-certificates.htm

Perhaps you can make it available on your site?

[Mosu]

In general I'm strongly against making CA files available on arbitrary websites that aren't run by the organization operating the CA. It always smells incredibly bad to me. The obvious exceptions are the well-known CA bundles operated by browser vendors. But certainly not on random project websites; that always smells kind of bad to me, to be honest.

To me it looks like GoGetSSL didn't think of adding the intermediates they use for code-signing to the website you've linked to. If anything, you should ask them to add the relevant intermediates to their site.