MKVToolNix v99.0 released

[Mosu]

@Mosu

I owe you an apology. Opening 'Job queue' (not 'Job output', as you said)…

Actually I did say that you can right-click on a job in the "job queue" tool & then view its output in the "job output" tool; see this post (https://forum.doom9.org/showthread.php?p=1903626#post1903626). But that's fine, often enough I don't read instructions carefully enough myself. So… apology accepted, of course.

May I ask a question? A chap on the ffmpeg-user list said he uses the MKVToolNix "generate timestamps" option. Is that an undocumented feature? Or was the chap in error?

I'm actually not quite sure which particular feature that person is talking about. Normally mkvmerge will re-use existing timestamps for the container a track is read from.

A couple of possibilities:

The "--default-duration" option is the most likely candidate in my opinion. You specify how long each frame or field (depending on how the video was encoded: interlaced or progressive) should be displayed, and mkvmerge will calculate the timestamps from it. mkvmerge will also set the track's "default duration" header field accordingly. With this option mkvmerge does indeed "generate timestamps" from your specification.
With the "--timestamps" option you can specify a file which contains the timestamps for all the frames of a track. mkvmerge will use those timestamps instead of the ones from the source container. There are several file formats for that particular "timestamps file". The option is meant to be used by other tools, not really by humans. With this option mkvmerge does not "generate timestamps" itself, it just uses timestamps someone or something else has generated for mkvmerge.
Maybe the person wasn't talking about timestamps after all but about chapters? mkvmerge can generate chapters based on timestamps, e.g. one chapte every X seconds.

[markfilipak]

Actually I did say that you can right-click on a job in the "job queue" tool & then view its output in the "job output" tool; see this post (https://forum.doom9.org/showthread.php?p=1903626#post1903626). But that's fine, often enough I don't read instructions carefully enough myself. So… apology accepted, of course.
May I suggest?
"Current Job Output" ...after a job runs
"Current Job Queue" ...before a job runs
"Job History" ...previous job outputs

I like your style, Mosu.

[markfilipak]

I'm actually not quite sure which particular feature that person is talking about. Normally mkvmerge will re-use existing timestamps for the container a track is read from.

A couple of possibilities:

The "--default-duration" option is the most likely candidate in my opinion. You specify how long each frame or field (depending on how the video was encoded: interlaced or progressive) should be displayed, and mkvmerge will calculate the timestamps from it. mkvmerge will also set the track's "default duration" header field accordingly. With this option mkvmerge does indeed "generate timestamps" from your specification.
With the "--timestamps" option you can specify a file which contains the timestamps for all the frames of a track. mkvmerge will use those timestamps instead of the ones from the source container. There are several file formats for that particular "timestamps file". The option is meant to be used by other tools, not really by humans. With this option mkvmerge does not "generate timestamps" itself, it just uses timestamps someone or something else has generated for mkvmerge.
Maybe the person wasn't talking about timestamps after all but about chapters? mkvmerge can generate chapters based on timestamps, e.g. one chapte every X seconds.
Thank you. Yes, I was familiar with all these options. Below is the mailing list thread for your information and perspective. As you see from my query (at the end of the thread), I thought that MKVToolNix might provide a clue regarding the 4400ms audio lead. The early-audio was present only for PGCs 9 & 10 and the only thing I can think of was that the PTS was wrong.

On 03/15/2020 09:41 AM, Mark Filipak wrote:
> On 03/15/2020 09:02 AM, Crazy Red Elephant via ffmpeg-user wrote:
>>> Are they actually disruptive, or could you just keep the original
>>> stream as is, knowing 1 out of 120 frames or something will be
>>> dropped when playing back?
>>
>> To me, yes. I know some other users also reported something about
>> playback issues numerous times but the stream provider doesn't seem to
>> care.
>>
>> I think I mentioned before that remuxing the video with MKVToolNix and
>> the "generate timestamps" option checked...
>
> Can you help me find the "generate timestamps" option? I can't find it.
> I'd like to see what it does with a VOB that has 8 PGCs that are okay,
> but the 9th & 10th PGCs have audio in advance of video by about 4400ms.
>
> Regards,
> Mark.

[markfilipak]

I discovered (the hard way) that MKVToolNix doesn't handle things well if the input and output are the same file name.
It would be nice if overwriting were possible.

[Mosu]

I discovered (the hard way) that MKVToolNix doesn't handle things well if the input and output are the same file name.
It would be nice if overwriting were possible.

Overwriting a file you're reading from is definitely not supported and never will be. mkvmerge should abort with an error message if this is attempted.

The are several reasons, e.g. there's a distinct possibility that data to be written is generated faster than data is read from the source file; in that case data that hasn't been read yet would be overwritten by the output data. Not a good idea.

[Liisachan]

Hi, I'd like to report a possible issue of the GUI.

The default destination file name, auto-generated by GUI, may cause errors or unexpected behaviors, at least on my Windows machine, in some situations related to a slash (possibly also a colon?) in the --title.

Example 1
You have "La Rose - Partie 2.264" and want to make "La Rose - Partie 2.mkv". You want to give it a title "La Rose / Partie 2". A command line like this will work fine:
mkvmerge -o "La Rose - Partie 2.mkv" "La Rose - Partie 2.264" "La Rose - Partie 2.ogg" --title "La Rose / Partie 2"
On GUI, when you select source files like above, "La Rose - Partie 2.mkv" is automatically set as the destination, which seems fine. You can type "La Rose / Partie 2" in the "File title" editbox, which seems fine too. But then, when you're happy with the default destination shown and click "Start multiplexing", you got an error like this:
Errors emitted by job 'Multiplexing to file " Partie 2.mkv" in directory "X:\path\La Rose "' started on 2020-03-18 18:26:13 ---
The file 'X:\path\La Rose \ Partie 2.mkv' could not be opened for writing: open file error.

The problem seems to have two aspects:
1) GUI design: Before and when you click Start, the "Destination file" editbox is saying "X:\path\La Rose - Partie 2.mkv". GUI suddenly changes its mind after you click Start, even though you do want to create "X:\path\La Rose - Partie 2.mkv". If the default destination changes, the editbox showing it should be updated accordingly before the user clicks "Start multiplexing" (e.g. when the "File title" editbox is updated and loses the focus).
2) Technically it's possible to create a file "X:\path\La Rose \ Partie 2.mkv" on Windows (though this is probably not what the user wants to do), but the tools fail to do that: it seems that they can't handle a folder name with a trailing space in this case.

Example 2
Suppose the --title should be "Take a 50/50 Chance!" GUI works fine with this title, but if the destination file name is auto-generated, then a sub-folder "Take a 50" is created, in which a file "50 Chance!.mkv" is written. Obviously this is not what the user wants. Like Example 1, the user doesn't know this will happen until after they click the "Start multiplexing" button.

[Mosu]

Nice catch, thanks. I'll have to replace all characters Windows doesn't allow in file names before copying the title to the file name.

[markfilipak]

Nice catch, thanks. I'll have to replace all characters Windows doesn't allow in file names before copying the title to the file name.
As an alternative, you could %-hex the offending characters. For example, "Take a 50/50 Chance!" would become "Take a 50%2F50 Chance!". Or you could simply replace any offending characters with hyphen of course.

[Mosu]

Replacing consecutive invalid characters with a single hyphen is what I was thinking about. I don't like % encoding for normal folks as they don't really understand what's happening and what that's supposed to mean.

[tormento]

For example (this is with bash on Linux, but other OS will surely have similar tools available)
Ask me anything about hardware but I am a noob about programming software.
Alternatively create a tag file with the tags you want to use.
Months ago I asked you to set language from filename convention and at the beginning you were reluctant. After some silent months, you coded it and it's really useful.

I think it would be useful for a lot of people to have the stream file date and time saved in the mkv container, so being resilient to cuts and other manipulations.

[Mosu]

Ask me anything about hardware but I am a noob about programming software.

I'm sure you weren't born with your knowledge about hardware. So how did you acquire it? You invested time to learn about it.

Same with automating/scripting stuff. If you want to be efficient, use automation; if you don't know how, invest the time & learn.

If you aren't willing to invest the time, then I can only understand that to mean that the topic isn't that important to you.

[tormento]

I'm sure you weren't born with your knowledge about hardware. So how did you acquire it? You invested time to learn about it.
I appreciate your wise reply. I can read you are proud of the lines you crossed.

In this spirit, I gave you a comment to improve your great product: my hint was about a feature many could find useful.

[Liisachan]

Nice catch, thanks. I'll have to replace all characters Windows doesn't allow in file names before copying the title to the file name.

The problem may not be just that some characters are illegal in the Windows file system. In my tests, GUI doesn't allow you to create foo.mkv from foo.264 at all, when the File title is non-empty and not "foo", even if you explicitly type "foo.mkv" in the File destination editbox. In other words, on GUI, when --title is specified, you can't select a Destination that happens to be identical to the initial default Destination.

Example:
- When you create a new job on GUI and add a source file "D:\CD Image.flac", the Destination file "D:\CD Image.mka" is auto-selected. Type something in the File title editbox; the Destination file remains the same. In this state, you'd think "CD Image.mka" will be created when "Start multiplexing" is clicked...
http://faireal.net/image/2020/cd_image_mka.png

- What will actually happen is different (already reported).

- Not only that, even if you manually type or select the Destination "D:\CD Image.mka" (suppose you do want to use that file name) after you type something in File title, GUI ignores it and still tries to create a Matroska file named after the File title. This behavior seems case-sensitive: GUI allows you to write e.g. "D:\CD Image.Mka" (capital M) from "D:\CD Image.flac" with an arbitrary --title.

[Mosu]

The GUI tries to determine whether the user has changed the destination file name manually and remembers the name it set automatically. If the current name is different than the automatically determined one, the GUI will stop auto-generating the file name. Sure, there might still be bugs in that process (because it's a shitty guesswork).

Nevertheless, the title issues should be fixed. The latest continuous builds (https://mkvtoolnix.download/windows/continuous/) contain the fixes.

[Liisachan]

Thanks! Tested 44.0.0.14 and it's working fine :)

As for the second problem, I've found an easy workaround for Windows. If you want to do e.g. mkvmerge -o "D:\path to\foo.mkv" "D:\path to\foo.264" --title bar using GUI and doesn't want to get bar.mkv, you can just change one character - lowercase the drive letter - in the Destination editbox: "d:\path to\foo.mkv" instead of "D:\path to\foo.mkv".

Of course, one can also use Multiplexer | Show command line, and just paste it to cmd.exe or make a batch file (which is most convenient for me).

One cosmetic observation: the command line generated by GUI for cmd.exe uses forward slashes to write a path to the folder where mkvmerge.exe exists. E.g. if you have mkvmerge.exe & mkvtoolnix-gui.exe in
D:\folder\mkvtoolnix
then, a command line generated by GUI looks like:
D:/folder/mkvtoolnix\mkvmerge.exe --ui-language en --output ...
This seems harmless, though, as cmd.exe now accepts a forward slash as if it were a backslash.

[Mosu]

Thanks! Tested 44.0.0.14 and it's working fine :)

Great! Thanks for the confirmation.

As for the second problem, I've found an easy workaround for Windows. If you want to do e.g. mkvmerge -o "D:\path to\foo.mkv" "D:\path to\foo.264" --title bar using GUI and doesn't want to get bar.mkv, you can just change one character - lowercase the drive letter - in the Destination editbox: "d:\path to\foo.mkv" instead of "D:\path to\foo.mkv".

Yeah, that's definitely a useful workaround.

One cosmetic observation: the command line generated by GUI for cmd.exe uses forward slashes to write a path to the folder where mkvmerge.exe exists.

Nice, you found one last place where I forgot to use the "show platform-dependent slashes" function. I'll fix that. Yes, it is completely cosmetic as Windows supports both backward and forward slashes as path separators (both in cmd.exe and all of its "open a file" functions).

[tormento]

I am encoding lot of material with local dialects and I can't find them in ISO 639-2. I saw they are present in ISO 639-3, could you please add it as optional in the next nightly or major release?

[nevcairiel]

I am encoding lot of material with local dialects and I can't find them in ISO 639-2. I saw they are present in ISO 639-3, could you please add it as optional in the next nightly or major release?

Strictly speaking, the Matroska specification says that codes should be ISO 639-2, if you use others you are likely to confuse reading applications

https://www.matroska.org/technical/specs/index.html#languages

[tormento]

Strictly speaking, the Matroska specification says that codes should be ISO 639-2, if you use others you are likely to confuse reading applications
Uh, I see.

Anyway, I don't remember where, I saw that current revision of specification is v3 and v4 is work in progress. Perhaps it refers to something else.

[Mosu]

The current Matroska specs contain new elements (https://github.com/cellar-wg/matroska-specification/blob/master/ebml_matroska.xml#L348) for specifying languages following the IETF BCP 47 specification (see here (https://tools.ietf.org/html/bcp47) for the full spec and here (https://en.wikipedia.org/wiki/IETF_language_tag) for Wikipedia's summary). That spec is pretty much complete and can express any type of language/territory relationship.

Unfortunately no tool supports those elements yet, and yes, that includes MKVToolNix — because handling those specs is rather complex. Just like real life.

So no, I will never add support for ISO 639-3 as I cannot simply use arbitrary values that aren't part of the spec — and the spec already includes a superior mechanism in IETF BCP 47 language elements. I plan on supporting them one day, but please don't ask me for an ETA.

[Liisachan]

Nice, you found one last place where I forgot to use the "show platform-dependent slashes" function. I'll fix that. Yes, it is completely cosmetic as Windows supports both backward and forward slashes as path separators (both in cmd.exe and all of its "open a file" functions).

Still, it's Windows after all; backslashes are safer. For example, if you have mkvmerge in a folder "cd" something like this could happen.
R:\>cd\mkvmerge.exe --version
mkvmerge v44.0.0 ('Domino') 32-bit

R:\>cd/mkvmerge.exe --version
The system cannot find the path specified.

Also, though irrelevant to the current version of mkvmerge, XP is less tolerant of foward slashes.
C:\>mkvtoolnix\mkvmerge.exe --version
mkvmerge v20.0.0 ('I Am The Sun') 32-bit

C:\>mkvtoolnix/mkvmerge.exe --version
'mkvtoolnix' is not recognized as an internal or external command,
operable program or batch file.


I am encoding lot of material with local dialects and I can't find them in ISO 639-2. I saw they are present in ISO 639-3, could you please add it as optional in the next nightly or major release?

If the language name is uncoded in ISO 639-2, perhaps something like this is the best one could do currently:
mkvmerge -o foo.mkv foo.264 --language 0:mis --track-name 0:"Venetian [vec]" foo.ogg

mis = “Uncoded languages” is not supported by GUI, not in the Available list, but mkvmerge does accept it. MPC shows whatever you type as track-name e.g. "Venetian".

It would be ideal if not only ISO 639-3 but the language subtag registry were supported so that e.g. simplified Chinese vs. traditional Chinese subs, or Mandarin vs. Cantonese dubs could be consistently tagged and auto-selected by players. Although the Matroska specs says one can (at least) use suffixes like -cn, -tw, -hk, they are not supported in reality; even if supported, they are not necessarily convenient (e.g. when talking about writing systems, not about countries).

Note: even if the language code is not in the GUI listbox by default, mkvmerge accepts any language codes in mkvmerge --list-languages > lang.txt.
*Example 1:
mkvmerge -o foo.mkv foo.264 --language 0:nap foo.ogg
MPC-HC & MPC-BE both show "Napolitan" for this track.

*Example2:
mkvmerge -o foo.mkv foo.264 --language 0:nap foo.ogg --language 0:mul --track-name 0:"Japanese karaoke with English translation" foo.ass
For this subtitle track, MPC-BE shows "Multilingual, Japanese karaoke with English translation".

[tormento]

The current Matroska specs contain new elements

Well, thanks! You were really wise. Any ETA will be welcome, when any.

[Mosu]

mis = “Uncoded languages” is not supported by GUI, not in the Available list, but mkvmerge does accept it.

This is incorrect. "Uncoded languages" is very much available in the GUI.

In fact both the GUI and mkvmerge use the same list of languages for displaying/checking their validity. All entries that mkvmerge accepts are available in the GUI (preferences → "GUI" → "Often used selections" → "Languages").

[Liisachan]

@Mosu: you're right. Sorry, was looking for "mis" under M, not U. That's why I couldn't find it.

[stax76]

@Mosu

Re-muxing a video that has a FLAC audio track and using split mode by parts don't seem to work, maybe you can take a look or maybe somebody else can verify it.



G: Matroska, 28.9 MiB, 2 min 49 s, 1 430 kb/s

V: HEVC, Main 10@L3.1@Main, 1280x720, 23.976 FPS, 2 088 kb/s

A: German, FLAC, 1 291 kb/s, 2ch, 44.1 kHz


General

CompleteName : C:\Users\frank\Desktop\aaa.mkv
Format/String : Matroska
Format_Version : Version 4
FileSize/String : 28.9 MiB
Duration/String : 2 min 49 s
OverallBitRate_Mode/String : Variable
OverallBitRate/String : 1 430 kb/s
Encoded_Date : UTC 2020-03-29 18:20:06
Encoded_Application/String : mkvmerge v44.0.0 ('Domino') 64-bit
Encoded_Library/String : libebml v1.3.10 + libmatroska v1.5.2

Video

ID/String : 1
Format/String : HEVC
Format/Info : High Efficiency Video Coding
Format_Profile : Main 10@L3.1@Main
CodecID : V_MPEGH/ISO/HEVC
Duration/String : 11 s 220 ms
BitRate/String : 2 088 kb/s
Width/String : 1 280 pixels
Height/String : 720 pixels
DisplayAspectRatio/String : 16:9
FrameRate_Mode/String : Constant
FrameRate/String : 23.976 (23976/1000) FPS
FrameRate_Original/String : 23.976 (24000/1001) FPS
ColorSpace : YUV
ChromaSubsampling/String : 4:2:0
BitDepth/String : 10 bits
Bits-(Pixel*Frame) : 0.095
StreamSize/String : 2.79 MiB (10%)
Encoded_Library/String : x265 3.3+10-g08d895bb6:[Windows][GCC 9.3.0][64 bit] 10bit
Encoded_Library_Settings : removed, was too long
Default/String : Yes
Forced/String : No
colour_range : Limited
colour_primaries : BT.709
transfer_characteristics : BT.709
matrix_coefficients : BT.709

Audio

ID/String : 2
Format/String : FLAC
Format/Info : Free Lossless Audio Codec
CodecID : A_FLAC
Duration/String : 2 min 49 s
BitRate_Mode/String : Variable
BitRate/String : 1 291 kb/s
Channel(s)/String : 2 channels
ChannelLayout : L R
SamplingRate/String : 44.1 kHz
FrameRate/String : 9.571 FPS (4608 SPF)
BitDepth/String : 24 bits
Compression_Mode/String : Lossless
StreamSize/String : 26.1 MiB (90%)
Encoded_Library/String : Lavf58.38.101
Language/String : German
Default/String : No
Forced/String : No


FLAC file was created with ffmpeg:

D:\Projekte\VB\staxrip\bin\Apps\Encoders\ffmpeg\ffmpeg.exe -i "D:\Samples\aaa_temp\aaa ID1.m4a" -af volume=1.7dB -y -hide_banner -ac 2 "D:\Samples\aaa_temp\aaa ID1.flac"

edit:

Happens also with FLAC created with eac3to.

[sneaker_ger]

I cannot reproduce. Does splitting work as expected if you disable the video track?

[stax76]

Thanks for testing, and if you demux the result with mkvextract, has the flac file the correct length in mpv?

I cannot reproduce. Does splitting work as expected if you disable the video track?

Yes

[Mosu]

Splitting & appending FLAC isn't supported by mkvmerge due to the very unfortunate way FLAC is stored in Matroska. And yes, I was the one who invented how it is stored. I obviously didn't grasp that what I was doing was problematic.

[stax76]

Thanks, next staxrip build has a verification and a suggestion which settings can be used instead.

[sneaker_ger]

Thanks for testing, and if you demux the result with mkvextract, has the flac file the correct length in mpv?
No. (Of course) Mosu is right and while it seemingly works if I play the FLAC file with mpv or MPC-HC the displayed duration is the one from before the splitting (even though the actual data from the cut-out parts is missing). :o He wrote some more info about it some time ago: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/953

So re-encoding is the proper way to deal with this.

[Chris]

I guessed the problem is Qt after updating another software which uses Qt, it now shows similar problems, however the difference is that it doesn't appear to be hanging like MKVToolnix but seems to open menus slowly. Mind you it uses Qt 5.14, don't remember what MKVToolnix v43 used. Should I report that to Qt devs or they are already aware of the problem?

I can confirm this bug with Qt 5.14.1. The same problem have Qbittorrent 4.2.2 with identical qt version.



You can check which Qt version MKVToolNix was built with via the "Help" → "System information" menu entry. For MKVToolNix v43 on Windows this was Qt 5.14.1.



I wasn't able to find anything in their bug tracker with a quick search.

Note that this particular problem doesn't happen on all Windows installations (it doesn't on my Windows 10, my Windows Server 2016 and Server 2019 installations). Neither did anyone open a bug report for it.

If it only happens on Windows 7, you might have to prepare for the problem not to be fixed anymore.

My OS is Windows 10 1909 64bit. Thanks for this great software Mosu! :)

Qbittorrent post:
https://github.com/qbittorrent/qBittorrent/issues/12316

[Mosu]

I've just modified mkvmerge to abort with appropriate error messages if the user attempts to append or split FLAC audio tracks. Additionally I've converted the text from issue 953 sneaker_ger has linked to into an official entry in my FAQ.

[stax76]

Thanks Mosu

[Stereodude]

Is there a way to make a MVC (3D Blu-ray) mux with MKVToolNix directly from the mounted .ISO of the decrypted Blu-ray? I know for regular 2D blu-rays you can just drag in the .pls. Doing that on a 3D blu-ray gives you a 2D mux.

[arrgh]

... a way to make a MVC (3D Blu-ray) mux with MKVToolNix directly...

I second this request.:thanks:

[Mosu]

Is there a way to make a MVC (3D Blu-ray) mux with MKVToolNix directly from the mounted .ISO of the decrypted Blu-ray? I know for regular 2D blu-rays you can just drag in the .pls. Doing that on a 3D blu-ray gives you a 2D mux.

It might happen one day, but I've never really been motivated to work on that functionality.

[Stereodude]

It might happen one day, but I've never really been motivated to work on that functionality.
So the MKV container can handle MVC video (from a 3D blu-ray), and MKVToolNix can correctly handle/process/manipulate/export a MKV that already contains a MVC video stream (from a 3D blu-ray), but it has no ability to mux it from the demuxed streams or a blu-ray source? What's different about having it already in a .mkv vs. demuxed elementary streams? :confused:

[Mosu]

Data already present in Matroska can simply be kept as-is. Data read from other container formats has to be parsed and converted into structures suitable for storage in Matroska.

[Ripman]

Hi all. Long time. Still very excellent sw. I pay attention, just haven't needed to ask anything - even with the option changes and such.

Thanks again for mkvtoolnix.

[Mosu]

Hello dear people,

I sincerely hope you're all healthy or at least on the way there. I'm fine, and having some more time on my hands I was able to get more done wrt. MKVToolNix. So this release is a bit bigger than the previous ones.

Nothing's changed for package managers.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.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 45.0.0 "Heaven in Pennies" 2020-04-04
New features and enhancements

mkvmerge: mkvmerge has never supported appending & splitting FLAC audio tracks. mkvmerge will now emit error messages when the user attempts either instead of continuing and creating invalid FLAC tracks.
MKVToolNix GUI: added an option in the preferences to turn on eliding text on tab headers. If enabled, tab names will be shortened so that all tab headers fit into the window's width. Implements #2768 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2768).
MKVToolNix GUI: added an option in the preferences to disable all tooltips.
MKVToolNix GUI: Windows: debug output sent via Qt's to Windows' debugging facility will use a more verbose message format including the application name, making it easier to filter for in SysInternal's "Debug View" utility.
MKVToolNix GUI: multiplexer: if the file identification fails due to a JSON parser error, the output generated by "mkvmerge" will be output via Qt's debugging facility (viewable with SysInternal's "Debug View" utility on Windows; on other systems it's output on "STDERR") allowing insight into what's gone wrong.
MKVToolNix GUI: multiplexer: if an error occurs during file identification, the name of the processed file will be mentioned in the error message.
MKVToolNix GUI: multiplexer: if an error occurs during identification of multiple files, the GUI will ask the user whether to continue or abort the identification process. Implements #2778 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2778).
MKVToolNix GUI: job queue: added an option in the preferences for removing completed jobs when exiting the program depending on their status. Implements #2769 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2769).

Bug fixes

mkvmerge: H.265/HEVC packetizer: fixed changing the NALU size length, it was using the wrong offset into the "hevcC" structure.
mkvmerge: MP4 reader: fixed calculating the duration of video tracks that only contain a single frame. Fixes #2747 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2747).
mkvmerge: MP4 reader: if there's no frame offset table ("ctts" atom) present for H.265/HEVC video tracks, mkvmerge will determine the timestamp order itself instead of relying on the timestamps in the MP4 being in the presentation order required by Matroska. Fixes #2777 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2777).
mkvpropedit: Windows: mkvpropedit wasn't caching when reading the file to modify, slowing down operations such as adding track statistics tags considerably. Fixes #2761 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2761).
MKVToolNix GUI: multiplexer: when using the title as part of the destination file name (both automatically as well as using the "copy title to destination file name" function) all characters that aren't valid in a file name are replaced by hyphens.
MKVToolNix GUI: multiplexer: the "copy title to destination file name" function was broken when the "make file name unique" option in the preferences was disabled. In that case the file base name was removed regardless of what the title was set to at the time.
MKVToolNix GUI: multiplexer: when using the "show command line" menu option on Windows the path to the "mkvmerge" executable was shown with forward slashes instead of backslashes. This is a purely cosmetic fix as Windows supports both forward and backward slashes.
MKVToolNix GUI: multiplexer: when adding Blu-ray playlists the GUI used to only look for the English version of the disc library information (title & cover images). Now the GUI will present all disc library entries in the "select playlist to add" dialog & let the user chose which one to use (if any). Fixes #2765 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2765).
MKVToolNix GUI: multiplexer, info tool: fixed the "warn before overwriting" check wrt. jobs creating the same file. Fixes #2758 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2758).


So try to have some fun, especially in these trying times.

[filler56789]

^ Thanks :thanks:

[ryrynz]

Solid release. Good one.

[zn]

Is it possible to log actual start and finish timecodes for all parts from "--split parts:" output?

as a temporarily solution I am using "--split timecodes:" instead of "--split parts:", this way I can calculate times manually

[Selur]

Small question:
I noticed that mkv has rotaion options:

--projection-type TID:method
Sets the video projection method used. Valid values are 0 (rectangular projection), 1 (equirectangular projection), 2 (cubemap projection) and 3 (mesh projection).
--projection-private TID:data
Sets private data that only applies to a specific projection. Data must be given as hex numbers with or without the "0x" prefix, with or without spaces.
--projection-pose-yaw TID:float
Specifies a yaw rotation to the projection.
--projection-pose-pitch TID:float
Specifies a pitch rotation to the projection.
--projection-pose-roll TID:float
Specifies a roll rotation to the projection.

see: https://mkvtoolnix.download/doc/mkvmerge.html

-> Do VLC, MPC-HC and other players support these? (they would be useful when reencoding mp4 files which were recorded by a mobile with a mp4 rotation flag)


Cu Selur

Ps.: Okay, did a small test using:
mkvmerge --ui-language en -o "E:\Output\source with rotation flag.mkv" --global-tags "E:\Temp\source with rotation flag_08_56_54_1010__06.xml" -d 0 --default-track 0:yes --projection-type 0:0 --projection-pose-roll 0:90 --track-name 0:"VideoHandle" --language 0:en --default-duration 0:2984100/100000fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles --timecodes 0:"E:\Temp\timecodeV2_08_56_54_1010.tc" "E:\Temp\08_56_54_1010_03.264" and the output at least with MPC-HC wasn't rotated.

[leon]

@Mosu

https://bugreports.qt.io/browse/QTBUG-82701

What's the current version of Qt used in the latest version of MKVToolNix?

[Mosu]

You can check the Qt version your particular copy was built against via "Help" → "System information".

[Mosu]

Is it possible to log actual start and finish timecodes for all parts from "--split parts:" output?

There's no functionality that outputs those timestamps.

[leon]

You can check the Qt version your particular copy was built against via "Help" → "System information".

I know that, but I'm not using the "latest version" because of the bug.

[Mosu]

v45 is built with Qt 5.14.2, which is the latest release available.

[ryrynz]

I know that, but I'm not using the "latest version" because of the bug.If you look at the link you posted you can see the issue was closed with the release of 5.14.2. If you're going to reference something at least understand it...