MKVToolNix v99.0 released

[Mosu]

mkvmerge muxes everything it understands & supports unless you tell it not to. Options such as "--subtitle-tracks" only ever limit the amount of tracks copied.

The shorted possible command, "mkvmerge -o out.mkv in.ext", copies everything supported from in.ext. No further options needed.

Ideally you'd go the other way around: first, extract subtitles with one of the programs I've mentioned above to either an SRT or to VobSubs (.idx + .sub). Then use mkvmerge to mux the VOBs with those freshly extracted subs, e.g. "mkvmerge -o total.mkv VTS_01_1.VOB extracted_subs.idx"

[markfilipak]

MKVToolNix doesn't support reading subtitles directly from DVDs. You'll have to extract them with other software such as Subrip or Subtitle Edit. Then feed those extracted files to MKVToolNix.

I saw this many months ago but forgot about it:
mkvmerge.html
2.7. Options that can be used for each input file
...Default: copy all subtitle tracks.

'MKVMERGE --output concat.mkv h:\VIDEO_TS\VTS_04_1.VOB' copied zero subtitle tracks.

...because it's a DVD, eh? ...Okay.

[markfilipak]

... e.g. "mkvmerge -o total.mkv VTS_01_1.VOB extracted_subs.idx"
Thanks so much. It's really good to see an entire command instead of bits and pieces of commands.

Will the resulting 'total.mkv' made that way always have the track order: video tracks, then audio tracks, then subtitles? The reason I ask is that such known track order would make my script slightly simpler and faster.

I didn't know I could just list the input files one after another like that. Handly!

Thanks, Mosu.

[Mosu]

I saw this many months ago but forgot about it:
mkvmerge.html
2.7. Options that can be used for each input file
...Default: copy all subtitle tracks.

'MKVMERGE --output concat.mkv h:\VIDEO_TS\VTS_04_1.VOB' copied zero subtitle tracks.

...because it's a DVD, eh? ...Okay.

Because that combination of format & source container simply isn't supported. I don't litter the documentation with caveats ("Only tracks that are actually supported given the combination of track type, codec & source container format and that are valid according to mkvmerge's internal metrics are considered." not once, but everywhere it talks about tracks) everywhere; all it would do is make it tiresome to read & easier to skip over content that's actually important.

Thanks so much. It's really good to see an entire command instead of bits and pieces of commands.

The man page's "Examples" section contains full commands as well.

Will the resulting 'total.mkv' made that way always have the track order: video tracks, then audio tracks, then subtitles?

No. The tracks will be in the order they're found in the file. Which order that is depends on the source container format & the actual content. For example, in AVIs the order is indeed video/audio/subtitles. In MP4, Matroska or MPEG transport streams, on the other hand, the order can be arbitrary. MP4 is among those that often has an audio track before a video track.

The order of the tracks created is the same order they're output in the identification mode (both JSON & plain modes).

The GUI has options for always sorting video/audio/subtitles, but the CLI app doesn't (intentionally so).

I didn't know I could just list the input files one after another like that. Handly!

You can always take a look at the command line the GUI generates for a given set of files & settings via "Multiplexer" → "Show command line". Note that the generated command line isn't guaranteed to be the shorted possible; the GUI sometimes includes redundant stuff (especially around track selection, e.g. adding "--subtitle-tracks 3,4" even if the source file contains exactly two subtitle tracks and therefore "--subtitle-tracks 3,4" could simply be left out and it'd have the same effect on muxing) because implementing a check if that option is actually needed takes more code, and more code requires more time for testing & leads to more chances for bugs.

[markfilipak]

[regarding subtitles from DVDs] Because that combination of format & source container simply isn't supported. I don't litter the documentation ...
That's totally understandable. I didn't mean to imply it wasn't. May I suggest a "Limitations" section in the html docs summarizing all such limitations in one place? I'll help write it if you like.
The man page's "Examples" section contains full commands as well.
Indeed. It's but one thing that makes your work outstanding. ;)
[regarding track order] No. The tracks will be in the order they're found in the file.
How about when there are multiple files? For example: 'MKVMERGE --output AV.mkv AVsource.mkv subs.mkv'. Would the subs always be the higher indexed tracks?
The GUI has options for always sorting video/audio/subtitles, but the CLI app doesn't (intentionally so).
Understood. That makes scripting a bit more complicated, but so be it.
You can always take a look at the command line the GUI generates for a given set of files & settings via "Multiplexer" → "Show command line".
Oh! That's very welcome. I wish every codesmith did that. Thanks!:cool::helpful:

[Mosu]

I'm sorry. I meant the track order when there are multiple files. For example: 'MKVMERGE --output AV.mkv AVsource.mkv subs.mkv'. Would the subs always be the higher indexed tracks?

The tracks are created in the order they are detected by mkvmerge. As files are processed left to right, this means that all tracks from AVsource.mkv would be created before the tracks from subs.mkv. There is no inter-file sorting going on here. Therefore where subtitle tracks end up depends on what the actual tracks in the files are. I'm guessing you're inferring that AVsource.mkv does not contain any subtitle track and subs.mkv contains nothing but subtitle tracks. In that case yes, the subtitle tracks would have the highest indexes.

However, if AVsource.mkv contains two subtitle tracks, a video track, an audio track and another subtitle track in that order, then it really doesn't matter what subs.mkv contains as the tracks in the output file would also be subtitle1, subtitle2, audio, subtitle3 and then whatever is in subs.mkv.

So in general you cannot make any assumption about track order based on track types.

The algorithm is completely deterministic, though. In pseudo code:

all_tracks = []

for file_name in file_names_in_command_line:
all_tracks.append(identify_tracks_in_file(file_name))

for track in all_tracks:
create_track_in_output_file(track)

No sorting, no grouping.

[markfilipak]

...
You are extraordinary.

[darksen]

One question, why with Microsoft Audio Codec Manager MKVToolNix shows it's codec ID 'A_MS/ACM' in the 'Codec' column when for codecs like 'AC-3' or 'DTS-HD MA' it shows the format or commercial name? In MediaInfo I see 'PCM' as the format for 'A_MS/ACM', is MediaInfo wrong here thus why MKVToolNix doesn't show 'PCM'?

Thanks.

[Mosu]

For most codecs there's a native way to store them inside Matroska. For those codec-specific identifiers (= CodecIDs) will be used, e.g. A_OPUS, V_AV1 or S_VOBSUB. All modern codecs (but also a lot of the old ones) have such a native way of storage and hence their own CodecID.

However, there's also a way to store audio or video (but not subtitle) data in Matroska in a way that simply borrows how data is stored in the venerable AVI and WAV containers. For those modes the generic CodecIDs V_MS/VFW/FOURCC (for video) or A_MS/ACM (for audio) are used. In these compatibility modes a certain part of the AVI/WAV container structure is simply stored in Matroska's CodecPrivate structure. Inside that data there is an identifier (for video a so-called FourCC = four characters code = four bytes whose ASCII representation is often times readable, e.g. "MPG2"; for audio a two-byte field with many well-known values) that tells the application what the actual codec is. The most well-known example of a codec that was pretty much only stored in that compatibility mode was MPEG-4 part 2, or as it is better known colloquially: DivX (or sometimes XviD).

This compatibility mode was introduced right at the start of Matroska's lifetime in order to ease adoption, and that kind of worked. Nowadays (as in… pretty much for at least the last ten years or so) there really isn't a good reason to use the compatibility mode. Sure, software developers might just be too lazy to implement native handling of the codecs & just use the compatibility mode.

MKVToolNix supports those compatibility modes and tries to convert them to native mode where possible (if not possible, the tracks will be copied as-is, meaning the output track will also use the compatibility mode).

The GUI itself simply lists a track's CodecID. It doesn't look deeper into that CodedPrivate structure for those other fields.

And the thing with PCM is: there are tons of different types of PCM, unfortunately, with a lot of different two-byte identifier values.

[darksen]

@Mosu Thanks for the detailed reply.

[Nejiro]

Hi everyone, I wanted to ask something about the dolby vision, I have several mkv files in which there are two video tracks, from the information with mediainfo one is HDR10 3840x2160 and the other 1920x1080 Dolby Vision, in this way, however, my player does not detects the dolby vision but only the HDR10, I wanted to know if with MkvToolNix there is the possibility of obtaining a single video track in which there is both the DV and the HDR10 to make my player reproduce the Dolby Vision files.
Thanks

[Mosu]

Hi everyone, I wanted to ask something about the dolby vision, I have several mkv files in which there are two video tracks, from the information with mediainfo one is HDR10 3840x2160 and the other 1920x1080 Dolby Vision, in this way, however, my player does not detects the dolby vision but only the HDR10

Dolby Vision can come in several forms: single-layer, dual-layer in a single track and dual-layer in two separate tracks. What you describe is the last case. At the moment MKVToolNix doesn't support such files. Maybe remuxing them & keeping the two tracks as they are works, I actually don't know — haven't tried it yet.

Support for those files is on my TODO list.

The support status and plans are summarized in this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status). It also links to the corresponding issues in my issue tracker.

As for other tools that might help: at the moment I only know about a pretty new project called dovi tool (https://github.com/quietvoid/dovi_tool), though it doesn't seem to support the dual-layer-in-separate tracks/files case yet. Again, haven't looked into it, but definitely a project worth watching and potentially adding to your Dolby Vision toolbox.

All that being said, other people here have much more experience with & knowledge Dolby Vision & the tooling around it. While I can answer your original question about MKVToolNix in particular, you should wait for others to chime in with solutions outside of MKVToolNix.

[quietvoid]

The simplest way is to use MakeMKV and remux the dual track file.
When doing so, it logs:
Hack: Found secondary video stream with RPU, assuming DV EL
Hack: Attaching DV data from second video track to first one and discarding second video track

And the output file is a single track.

However this doesn't guarantee the file will work on your devices, as only a few Android set top boxes support profile 7 dual layer in the MKV container :)

[SeeMoreDigital]

@Nejiro,

Out of interest... What's the make/model of your playback device?

[Nejiro]

It's a Zidoo Z9X...... https://www.zidoo.tv/Product/index/model/Z9X/target/VEMg6VRC2%2B9KKmVViAFMcQ%3D%3D.html

I am using MakeMKV as it was suggested to me and it works perfectly, the files are read by my player and played in dolby vision, I very much hope that this function is also implemented in MkvToolNix ...
Thank you

[SeeMoreDigital]

It's a Zidoo Z9X...... https://www.zidoo.tv/Product/index/model/Z9X/target/VEMg6VRC2%2B9KKmVViAFMcQ%3D%3D.html
Maybe some other Zidoo Z9X owner/users can help you, over on their dedicated help forums: http://forum.zidoo.tv/index.php

[Mosu]

Hi everyone, I wanted to ask something about the dolby vision, I have several mkv files in which there are two video tracks

While we're on the topic, can you please upload one or two of those files to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server)? I actually don't have sample Matroska files with dual-layer-in-two-tracks to work with for when I get around to implementing support for it.

Thanks!

[SeeMoreDigital]

While we're on the topic, can you please upload one or two of those files to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server)? I actually don't have sample Matroska files with dual-layer-in-two-tracks to work with for when I get around to implementing support for it.

Thanks!I'm sure I uploaded some .m2ts file samples (from Dolby Vision UHD discs) to your server a few weeks ago. Which MKVToolNix can mux just fine...

[Mosu]

I know. That's why I emphasized the "Matroska" part in my answer. I assume those were created by some other piece of software, and I want to be able to test as many potential sources as I can. I'm grateful for having the M2TS files, too, for the same reason.

[SeeMoreDigital]

I assume those were created by some other piece of software, and I want to be able to test as many potential sources as I can...
Good point... I wonder how many Matroska muxing software's are still out there.

Since the release of MakeMKV v1.15.3/4 its Matroska muxer automatically converts 2-track dual-layer Dolby Vision into single-track dual-layer .mkv contained encodes. I don't think they offer an option to keep both tracks now.

Cheers

[Nejiro]

With MakeMKV just load the mkv (which I had done with mkvtoolnix) which contains the two video tracks and automatically recognizes the DV, then I save and create a single video track which is recognized as dolby vision by my zidoo ..... . in case you have a player that is not compatible with dolby vision, it is reproduced as HDR ........
Is there hope that even with MkvToolNix you can do the same, that is create dolby vision compatible mkvs? I much prefer MkvToolNix to MakeMKV ....... I use MkvToolNix on Ubuntu 20.04 LTS
Thanks

[SeeMoreDigital]

Is there hope that even with MkvToolNix you can do the same, that is create dolby vision compatible mkvs? I much prefer MkvToolNix to MakeMKV ....... I use MkvToolNix on Ubuntu 20.04 LTS
ThanksBut surely you're using MakeMKV to create your Matroska 4K UHD back-ups in the first place!

[Mosu]

Is there hope that even with MkvToolNix you can do the same

There definitely is. That's why I asked you to upload (https://forum.doom9.org/showthread.php?p=1950215#post1950215) one or two of those MKVs with DV in two tracks to my file server earlier — so that I have more material to develop & test with.

[quietvoid]

I've uploaded a sample named "spears_and_munsil_drlow_dolby_vision_p7.mkv", which is dual layer profile 7.

Sourced from https://www.avsforum.com/threads/spears-munsil-uhd-hdr-benchmark-disc-discussion.3075780/page-43#post-59634582
Remuxed from mp4 with mkvmerge, then MakeMKV.

[Nejiro]

I don't know how to do it, they are very large files and my line only has 20mb at the output ...

[Nejiro]

Well, I see that someone sent it to you .....

[Mosu]

quietvoid: thanks, but that file only contains a single track. Those are supported just fine. What I need is a file with dual-layer Dolby Vision where each layer is stored in its own track.

Nejiro: I actually linked to the wrong post. Here's the link to the FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server) again. It contains an explanation that includes links to the software to use & screenshots how to configure them. It's really easy. Yes, they're huge, but that is no problem for me: just let the upload run as long as it takes, e.g. overnight. It would really help. Thanks.

[quietvoid]

Oh I thought you wanted dual layer (both single & dual track).
I guess the mp4 from Stacey Spears can just be remuxed to MKV as a source..

[ctl-tx]

I've run into a problem while cutting and joining mkvs with dolby trueHD audio tracks. I wanted to cut a video into 4 parts, then join the second and fourth parts together. But when I put the second part into the muxer, it couldn't see the TrueHD audio tracks, and the output had no audio tracks either. I put the segment (that the muxer couldn't see the audio tracks of) into the header editor, and that one could see the audio tracks just fine.

I thought it may have been because I threw out the AC-3 core of the TrueHD audio, so I went back to the raw video file, muxed it with the AC-3 tracks, then cut it again. This time, only the first of the two TrueHD tracks disappeared in the muxer.

I've got no idea how to get around this, so I'm posting here for help.

This is actually the second time I've encountered this problem. The first a few years ago. I can't remember exactly how I got through that time, only that it involved putting several unrelated mkvs together, and somehow the missing TrueHD track just reappeared. That's not an option this time.

Update: I changed the points in the video where I cut it and the TrueHD audio tracks in the segments now appear in the muxer. While this does solve my immediate problem, I needed to change the cut points anyway, I still hope the issue is looked into, the audio track shouldn't be unrecognized simply because it was cut at a different point.

[Mosu]

TrueHD is one of the very few audio codecs and the only modern one that I know of that uses two different frame types: major sync frames & normal ones. Decoding can only start from major sync frames. This is similar to video frames with key vs. non-key frames (or IDR vs. non-IDR frames).

Due to how mkvmerge works, it can only ever write to one file at the time. Splitting always uses the first video track in the output file to determine where to split. As soon as the split point is found, the current output file is closed & a new one is started.

For TrueHD this often means that splitting will occur before a regular TrueHD frame, not a major sync one, meaning that playing the second part a decoder cannot start decoding audio before the first major sync frame is found.

Splitting with more than one video track where both tracks have key frames in different positions exposes the same fundamental problem.

Handling situations such as these (different tracks with different restrictions where to splitting is allowed) differently, e.g. writing all remaining regular TrueHD frames to the previous output file, would require major rewrites of one of the most intricate parts of the applications. I do not have any plans to spend any time on this issue. It's a known limitation of mkvmerge not being a full-blown video editor.

Sorry.

[ctl-tx]

So, I suppose the only workaround is to change the cut points if this is encountered again. I'll just have to deal with that.

Could the two frame types be responsible for audio drops if you join two TrueHD tracks together? I saw that on my TrueHD joins, but I did those joins for ordered chapters and padded the join points in case of anomalies, such as these. They're just much more significant than I expected.

Edit: Wait, nevermind not being able to split and join due to different frame types. The muxer can't even see there's a track if it doesn't start on a major sync frame? Is it that hard to detect that the track starts with a non-normal frame and still show it on the muxer?

[Mosu]

mkvmerge probes the first few packets of a TrueHD track in order to determine its actual codec properties. If no major sync header is found within those first couple of packets, the track is considered to be bad. The number of packets probed (5) is indeed rather low, given that TrueHD uses a high number of very small frames (in one of my test files there are 120 frames between major sync frames). I'll increase that number considerably which should help with your situation.

[Mosu]

Hmm, at the moment I cannot reproduce the problem with mkvmerge not showing a split TrueHD track. Can you upload such a series of split files to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server), please? Thanks.

[ctl-tx]

Hmm, at the moment I cannot reproduce the problem with mkvmerge not showing a split TrueHD track. Can you upload such a series of split files to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server), please? Thanks.

The files have been uploaded. It's in the folder "from ctl-tx" These are the files I was working on when I posted. You can play the files and verify that they have audio. The audio tracks do not show up when you drop them in the muxer.

What about using what the Header Editor uses to identify tracks? As I said, these audio tracks did appear in it.

[Mosu]

Greetings, gentle fellow humans!

Oh wow, time is moving very strangely for me during this pandemic, sometimes slowing to a crawl, sometimes just going by very quickly. It's been four weeks since the last release already; so let's get the August one out just in time: v61.

This release is on the smaller side. Couple of improvements to the IETF BCP 47 language tag handling, couple other things. Nothing earth shattering, though.

For package maintainers there was a small change. See the NEWS below.

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 61.0.0 "So" 2021-08-30
New features and enhancements

all: IETF BCP 47/RFC 5646 language tags: implemented support for officially registered IANA language tag extensions.
mkvmerge: track selection: when using language tags for selecting which tracks to keep, mkvmerge will now use component-based language tag matching instead of comparing them verbatim. This means that only those components (language, region etc.) the user specified will be required to exist and be equal. For example, if a file contains three subtitle tracks with languages "es" (generic Spanish), "es-MX" (Spanish as spoken in Mexico) and "es-ES" (Spanish as spoken in Spain), the user can use "--stracks es" to match all three tracks or be more specific with e.g. "--stracks es-MX" which would only match one track. Similarly inverting the selection with e.g. "--stracks !es" would get rid of all three tracks, not just the one for the generic Spanish.
MKVToolNix GUI: multiplexer: deriving track languages from file names: the GUI can now detect full BCP 47/RFC 5646 language tags in file names. Part of the implementation of #3173 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3173).
MKVToolNix GUI: multiplexer: deriving track languages from file names: the default list of boundary characters now includes "-". Part of the implementation of #3173 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3173).
MKVToolNix GUI: multiplexer: the GUI now defaults to the "lower" process priority setting for new installations in order to leave more room for other applications, especially interactive ones. Up to and including v59 the default was the "normal" process priority. v60 changed that to "lowest", which turned out to be much slower on Windows for no real gain over "lower". The setting will be auto-corrected by the GUI if the settings file were saved last with a version between v60.0.0.0 & v60.0.0.17 & "lowest" & it is still set to "lowest".
HEVC dumper development tool: the tool has been renamed to "xvc_dump" and extended to be able to dump AVC/H.264 bitstreams, too. It now also detects the type of bitstream framing (ISO 14496-15 vs. ITU-T H.264/H.265 Annex B).

Bug fixes

all: IETF BCP 47/RFC 5646 language tags: fixed a corner case of wrongfully allowing scripts/variants not listed in any of the entries in the prefix list when the prefix list contains prefixes restricting scripts/variants and a prefix solely with the language at the same time (example: the variant "ekavsk" with its prefixes "sr", "sr-Cyrl" and "sr-Latn" where e.g. "sr-ekavsk" and "sr-Cyrl-ekavsk" should be allowed but not "sr-Bali-ekavsk").
mkvmerge: HEVC/H.265: the frame type of B frames was often wrongfully signalled as P frames instead, both with "BlockGroup" (missing second references) and "SimpleBlock" ("discardable" flag not set) elements.
mkvmerge: SSA/ASS packetizer: the frame numbers will now be re-calculated when appending SSA/ASS tracks so that frame numbers of appended tracks are always strictly higher than frame numbers of the track they're appended to.
mkvmerge, MKVToolNix GUI's chapter editor: BCP 47/RFC 5646 language tags: when BCP 47 language tags are used with a language code that isn't part of ISO 639-2, the programs will now write a legacy language element set to "und" ("undetermined") instead of not writing such an element at all or writing one with an invalid code. Fixes #3174 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3174).
mkvmerge, MKVToolNix GUI's chapter editor: BCP 47/RFC 5646 language tags: the programs will ensure that the legacy and IETF language elements written will be unique within the scope of the same "chapter display" element.
mkvinfo, MKVToolNix GUI's info tool: in summary mode the frame type was reported wrong for "BlockGroup" elements in which the "ReferenceBlock" elements were located behind the "Block" element.

Build system changes

all: "std::codecvt_utf8" is now used instead of Boost's "utf8_codecvt_facet". The bundled copy the latter in "lib/boost" has therefore been removed.


Have fun 😁

[VBB]

Thank you!

[Mosu]

The files have been uploaded. It's in the folder "from ctl-tx" These are the files I was working on when I posted.

Thanks. I actually fixed this a couple of days ago but forgot to post about it. You can try the latest continuous builds (https://mkvtoolnix.download/windows/continuous/).

[Selur]

Thanks. :)

[Etroxamin]

Hey, I need to to change video FPS (23.976 to 24), that's not a problem, but I saw a new flag for the "original framerate" appeared in MediaInfo.

I was wondering if that could cause problems for certain players/playback devices and found some posts that it actually can happen and the option "Fix bitstream timing info" can fix that. I read a bit more and saw "Fix bitstream timing info" was described as destructive option.

Now i am confused whats the best way to handle such a video framerate conversation.

The Film has been produced in 24 FPS, so discarding the original framerate information may not be "destructive" at all. However, when i check the "Fix bitstream timing info" MediaInfo still shows me the original framerate.

Is it possible to discard the original framerate information completely?
Are there any drawbacks using "Fix bitstream timing info"?

And maybe my understanding of frame timestamps isn't good enough, thought a framerate eg. 24 or 25 fps would be enough for a player to know how fast frames should be played. So, when I use "Fix bitstream timing info" and change the FPS back to 23.976 as it was originally, and use "Fix bitstream timing info" again, will the timestamps actually change to the orignal (100% accurate) or would these change to a slightly other value?

The video plays fine btw, no matter if i use "Fix bitstream timing info" or not, but before i do something "destructive" or end up with video wrongly interpreted by certain playback devices, it might be good to ask.

[Mosu]

However, when i check the "Fix bitstream timing info" MediaInfo still shows me the original framerate.

That option is only implemented for AVC/H.264, not for any other codec.

Is it possible to discard the original framerate information completely?

Speaking strictly from the AVC/HEVC specs POV: yes, as those sequence parameter set fields are optional. MKVToolNix doesn't contain functionality for that, though: either it leaves the SPS untouched (meaning the info might be present or not), or it forces the information to be present and what the user specified.

Are there any drawbacks using "Fix bitstream timing info"?

If you use wrong values, playback won't work as expected. Otherwise… not really, no.

So, when I use "Fix bitstream timing info" and change the FPS back to 23.976 as it was originally, and use "Fix bitstream timing info" again, will the timestamps actually change to the orignal (100% accurate) or would these change to a slightly other value?

That actually depends. First of all, what's stored in the SPS is not a floating point number but a pair of 32-bit unsigned integers which denominate the "number of frames per ticks" and "number of tickets per second", which, when divided, yields the number of fields-or-frames (depends…) per second. For several well-known & often used frame rates such as 23.976, mkvmerge will store the representation that is commonly used for that frame rate: 24000/1001. No, this isn't exactly 23.976, but that 23.976 number is actually a lie: movies were shot in 24000/1001 FPS, not in exactly 23.976, but us humans use the easy to remember number of 23.976 instead of… well anything, really. 24000/1001 is an irrational number, and you simply cannot express it exactly without reverting to a rational such as 24000/1001. So what MediaInfo reports as 23.976 is most likely stored as 24000/1001, even though that's not the same number.

Sooo… confused yet?

In pretty much all cases 24000/1001 are the numbers video files use when they contain "23.976 FPS" material. That being said, your original file just might contain some other similar but not quite the same value, e.g. 4294944000/179134957, and MediaInfo might round that to that well-known FPS of 23.976, too. Who knows? In this case the value mkvmerge would write would not actually be the value that was present in the file originally. And as we've just learned, that original value wouldn't be exactly 23.976 either.

That's the complex but somewhat accurate answer. The pragmatic answer is a short "sure, that works".

The video plays fine btw, no matter if i use "Fix bitstream timing info" or not

So why try to fix something that doesn't need fixing?

[Etroxamin]

"Fix bitstream timing info"

That option is only implemented for AVC/H.264, not for any other codec.


Ok, the video I use is HEVC, so turning this on doesn't change anything, I guess?


"Is it possible to discard the original framerate information completely?"

Speaking strictly from the AVC/HEVC specs POV: yes, as those sequence parameter set fields are optional. MKVToolNix doesn't contain functionality for that, though: either it leaves the SPS untouched (meaning the info might be present or not), or it forces the information to be present and what the user specified.


Well, is there a chance to see this option working for HEVC in the future, eventually? Btw, if it only works for AVC, it might be an idea to add the information (or else it can be confusing), i just googled a bit more, and someone in another forum had the problem that his muxed videos also had the "original framerate" information, he muxed a PAL DVD to play it at 23.976 frames and it caused problems for a playback device, while it was working on another device, another user suggested to use the "Fix bitstream timing info" but if it only works for AVC, then it makes not much sense of course.

And if MKVToolNix doesn't contain a functionality for removing the original framerate flag, while it can lead to complication with some devices, maybe it would be an idea to be able to force removing this information when FPS change is set. This information seems not of much use for a finished remux... (or not?) but can cause playback errors. It should be optional of course.


"Are there any drawbacks using "Fix bitstream timing info"?"

If you use wrong values, playback won't work as expected. Otherwise… not really, no.


Well, its just a switch to activate (no value to add), so you mean wrong values for the fps bar above? wouldn't a wrong value lead to plaback issues anyway, no matter if i tun the switch on?

Well, maybe the stored "original framerate" could be used to restore something if the original video isn't available anymore.




... so far the double framerate change, i thought something like that. But thanks a lot for that explanation or confirmation. Not that it is really important, I keep the source anyway, so won't ever need to do that, i was just curious :)


"The video plays fine btw, no matter if i use "Fix bitstream timing info" or not"

So why try to fix something that doesn't need fixing?


Well, as said above already, it can have playback issues with certain devices, which will use the "original framerate" instead the one correct one.

It would be great to have the "Fix bitstream timing info" switch for other videos than AVC of course, unless its causing problems of course, but well ...

Anyway, thanks a lot for your answer, at least I know that this switch doesn't work for my current "project". But as said its all fine, at least on PC, still - i'd like to find a way to remove the orignal framerate flag, but guess i then would need to find a way to "Fix bitstream timing info" as well, might be complicated and maybe not the right place to ask for here, but maybe it would be an idea to extend that function to other video types, may improve MKVToolNix and could help in certain situations.

And thanks a lot for MKVToolNix as a whole project btw, great piece of work.

[SeeMoreDigital]

... he muxed a PAL DVD to play it at 23.976 frames and it caused problems for a playback device...
720x576 PAL (and 720x480 NTSC) DVD's are all encoded using MPEG-2 video.

[Etroxamin]

720x576 PAL (and 720x480 NTSC) DVD's are all encoded using MPEG-2 video.

Yes, actually i just put this example on, as mpeg2 wont be effected by the "Fix bitstream timing info" as well. To visualize that without information that this switch is limited to AVC, it can be confusing in such cases.

However someone linked me to an example for ffmpeg:

ffmpeg -i input.mkv -c copy -bsf:v hevc_metadata=tick_rate=25:num_ticks_poc_diff_one=1 output.mkv

well in my case i need to do 24 of course, but seems to work. Even if i find these ffmpeg commands a bit confusing as well, at least for me, cause i never used ffmpeg before...

[von Suppé]

ffmpeg -i input.mkv -c copy -bsf:v hevc_metadata=tick_rate=25:num_ticks_poc_diff_one=1 output.mkv

A batchfile with that code for changing hevc framerate has been in my toolbox since the day I found out about it. Haven't still ran into a GUI with that option.

[markfilipak]

@Mosu, thank you for the update to an outstanding utility. May I cheerfully make some suggestions?

From VirusTotal analysis of mkvtoolnix-64-bit-61.0.0-setup.exe:
Detects "cmd" utilization to self-delete files in some critical Windows destinations.
SOC Prime Threat Detection Marketplace (https://sigma.socprime.com/#!/) - Ariel Millahuel
Context for the matching events
$CommandLine: 'C:\Windows\System32\cmd.exe /c C:\Windows\System32\ipconfig.exe /flushdns >C:\Windows\TEMP\ipconfig.out 2>&1'
$CommandLine: 'C:\Windows\System32\cmd.exe /c C:\Windows\System32\netsh.exe interface ip delete arpcache >C:\Windows\TEMP\ipconfig.out 2>&1'
$CommandLine: 'C:\Windows\system32\cmd.exe /c C:\Windows\system32\powercfg.exe /getactivescheme > C:\Windows\TEMP\PowerPlan.log'
$CommandLine: 'C:\Windows\system32\cmd.exe /c C:\Windows\system32\powercfg.exe /query 381b4222-f694-41f0-9685-ff5bb260df2e > C:\Windows\TEMP\HighPerformancePlan.log'

Regarding lines 1&2: What is mkvtoolnix-64-bit-61.0.0-setup.exe doing with the Internet? Whatever it is, don't do it. In my case, there's a practical reason: Windows is not connected to the Internet. I connect to the Internet solely through a Linux VM.
Regarding lines 3&4: Don't mess with the power scheme. Suggest settings but don't make them.

[Mosu]

MKVToolNix itself does not contain any of those actions it its source code. If you doubt that, get the source code (https://gitlab.com/mbunkus/mkvtoolnix/-/tree/main) and have a look for yourself.

My primary candidates are the NSIS installer & the Qt libraries, though neither the source of NSIS (https://sourceforge.net/projects/nsis/files/NSIS%202/2.46/nsis-2.46-src.tar.bz2/download) nor of Qt (https://github.com/qt/qtbase/tree/5.15.2) contains any mention of "powercfg.exe", "netsh.exe" or "ipconfig.exe".

I don't know where those calls come from. They certainly aren't done intentionally by myself. MKVToolNix only accesses the internet when the GUI's check for updates is run (automatically at most once a day, or if you select "Help" → "Check for updates" manually), and nothing at all is done with power configuration.

As a matter of fact, I decided to check on VirusTotal myself, first downloading mkvtoolnix-64-bit-61.0.0-setup.exe from the official download site, FossHub.com (https://www.fosshub.com/MKVToolNix.html), and then uploading it to VirusTotal. The result (https://www.virustotal.com/gui/file/f2ccd10c67f07369e13d9a75ab3a0b4f693d48f67f99a2224fa7c515186e7d2f) shows none of what you copy-pasted.

Looks like the problem is actually on your end.

You should compare the checksum of the exe with the official ones listed here (https://mkvtoolnix.download/downloads.html#windows).

[von Suppé]

Hi Mosu,

I'm still in the learning process about Dolby Vision. During which' use within both mkv and BD-ISO, I read this: https://github.com/justdan96/tsMuxer/issues/450#

As for remuxing a MakeMKV-created DV with your tool, I'm wondering what the deal is with adding these "Access Unit Delimiters" (which I understand are the first part of a specified form of NAL unit).
If I understand that thread correctly, MakeMKV would simply "forget" this and because of that, DoVi would not be triggered on a TV when remuxed as TS.

My question: Purely for the sake of a proper mkv with DoVi (not TS or BD), could the absence of these "AUDs" in a mkv pose any problem? And - as I'm a noob with this, this may sound stupid - if so, are/can these be (properly) rewritten by mkvtoolnix during a remux?
I hope you don't mind me asking.

[Mosu]

As far as I know access unit delimiters are purely optional, at least when stored in a container format that knows how to keep all NALUs that "belong" to a single frame in the same container-level block structure. Matroska is such a container, MP4 is one as well. In fact, mkvmerge discards AUDs during muxing and has always done so, not just for HEVC, but also for AVC.

MPEG transport streams on the other hand do not have such a notion of a block structure that contains several NALUs and which could therefore signal the start of a sequence of NALUs "belonging" to the same frame.

That being said, I don't understand why AUDs are necessary for DV playback even with MPEG transport streams. The HEVC specs are very clear on the order of NALUs, and from that order you can easily derive which slice NALUs certain DV NALUs belong to: the DV NALUs always follow the slice NALUs.

I'm completely confused by jcdr428 casually stating:

MakeMKV simply forgets to add the Access Unit Delimiters -which yusesope tool does correctly.

as if they were required for playback, especially for playback when inside Matroska or MP4. That doesn't compute.

If the standards do require them somehow somewhere, I'd be really interested in the details, whether I actually have to create them, and if so, under which circumstances.

[videoh]

Small, possibly irrelevant point about AUDs...

When developing DGDecNV I ran into an issue decoding AVC elementary streams:

We are starting to see streams that have successive IDR pictures with the same idr_pic_id (so far always = 0). This has been seen on commercial blurays. It can also be created by accident when concatenating streams, if the first ends with an IDR. As far as I can tell, CUVID silently discards the "extra" IDRs. I realize it's an illegal condition but I am wondering if it can be mitigated in CUVID, i.e., just accept the extra ones and bump the idr_pic_id internally to pretend the stream did it right. Your thoughts on this would be appreciated.

nVidia responded that it was a CUVID parser deficiency that may or may not be fixed and that a workaround is to inject an AUD before the new picture. So that is what DGDecNV does.

#ifdef IDR_PIC_ID_WORKAROUND
if (SystemStream_Flag == ELEMENTARY_STREAM && VideoStream_Flag == AVC)
{
// Workaround for successive IDRs with same idr_pic_id.
if (buf[2] == 1)
offset = 3;
else
offset = 4;

if ((buf[offset] & 0x1f) == 5 && (buf[offset+1] & 0x80))
{
aud[0] = aud[1] = 0;
aud[2] = 1;
aud[3] = 9;
aud[4] = 0xff;
decoder_decode_nalu(aud, 5, false);
}
}
#endif

So there is at least one case where it is beneficial not to strip AUDs. I leave it to you to judge the (ir)relevance of this.

AUDs are required by spec for transport streams.

If you strip the AUDs in MKV, then it will not be possible to later demux the AVC and place it in a transport stream.

Further data on transport streams (note the first bullet item):

Quoted from ISO/IEC 13818-1/2000/FDAM-3 (N5771):
"2.14 Carriage of ITU-T Rec. H.264 | ISO/IEC 14496-10 Video
The ITU-T Rec. H.264 | ISO/IEC 14496-10 coded data shall comply with the byte stream format defined in Annex B of ITU-T Rec. H.264 | ISO/IEC 14496-10, with the following constraints:
* Each AVC access unit shall contain an access_unit_delimiter NAL Unit.
* Each byte stream NAL Unit containing the access unit delimiter contains one zero_byte preceding the start_code_prefix_one_3bytes, as required by ITU-T Rec. H.264 | ISO/IEC 14496-10.
* Sequence and Picture Parameter Sets (SPS and PPS) shall be present within each AVC video stream carried in Transport and Program streams (Note that ITU-T Rec. H.264 | ISO/IEC 14496-10 allows the delivery of SPS and PPS by external means).
* To provide display specific information such as aspect_ratio, it is strongly recommended that the each AVC video stream carries VUI messages with sufficient information to ensure that the decoded AVC video stream can be displayed correctly by receivers."

[Mosu]

Thanks for the info.

I disagree with one thing you said, though:

If you strip the AUDs in MKV, then it will not be possible to later demux the AVC and place it in a transport stream.

Not necessarily. The application extracting from Matroska would be able to re-insert AUDs in such situations. mkvextract doesn't, at the moment.

I could disable the AUD removal, of course (though it isn't a trivial one-line change but rather more involved due to the parameter set normalization mkvmerge does). It would keep improve the situation a bit, for sure, but you can still end up with bad situations when splitting & appending, e.g. situations such as the one in my issue 2990 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2990#note_535215149).

Also, if NVidia's decoder is able to insert AUDs as needed on the fly, any other program should be able to as well?