MKVToolNix v24.0.0 released

[Mosu]

Right! But the TrackNumber (like EBML variable-sized integer) can't be zero, because Tracknumbers start at 1, right?

That's correct, at least from the point of view of the specification. It states that the track number must not be 0. However, from a purely technical point of view, there's nothing preventing someone from creating a file with a track number of 0. That would still require one byte in the Block/SimpleBlock structures, though (value 0x80).

@mkver
Would you do this? I think your English is better.

I've just filed this issue (https://github.com/Matroska-Org/matroska-specification/issues/213).

[mkver]

TrackNumber can't be zero because the spec don't allow zero as a TrackNumber ("But the TrackNumber [..] can't be zero, because Tracknumbers start at 1" is circular reasoning); the size encoded in an EBML variable-sized integer can be zero (although the coded EBML variable sized integer can't be). You can even encode a size of zero in an EBML integer with 8 octets.

[psychoboust]

Hello,
a question about TrueHD and AC3 Core.

Do you think we will get one day the availabilty to have a truehd and ac3 core in the same track (like m2ts) or this feature will never be added to the mkv spec ?

Thks a lot for your work

[nevcairiel]

Do you think we will get one day the availabilty to have a truehd and ac3 core in the same track (like m2ts) or this feature will never be added to the mkv spec ?

This "feature" is not useful for MKV.

If you want it to be able to re-create a m2ts with a combined track later, it still wouldn't help you, since you need a m2ts muxer that can write the additional metadata required to clearly split these two tracks - and if it can do that, it would also be able to just take a truehd and ac3 track separately and combine them.

[Mosu]

Do you think we will get one day the availabilty to have a truehd and ac3 core in the same track (like m2ts) or this feature will never be added to the mkv spec ?

No. The only reason for having both in the same track is so that existing players that support the older AC-3 but not the newer TrueHD can still play the track by only using the AC-3 and skipping over everything else. It's a hack for a hacky format.

This is not a concern for Matroska. If the player does support Matroska, then it's highly likely that it'll be able to do somewhat smart track selection already based on the CodecIDs it supports.

[psychoboust]

This "feature" is not useful for MKV.

If you want it to be able to re-create a m2ts with a combined track later, it still wouldn't help you, since you need a m2ts muxer that can write the additional metadata required to clearly split these two tracks - and if it can do that, it would also be able to just take a truehd and ac3 track separately and combine them.

There won't be space gain ?
1 TrueHD track + 1 AC3 track = 1 TrueHD + Core Track ?

Because for DTS HD
1 DTSHD track + 1 DTS track is different from only one DTSHD+Core track (because it always include the core)[maybe I already have my answer : does TrueHD track can exist without core unlike DTS HD ?]

My question is really about the size of the final mkv file (not player support ;-))

Thks !

[Mosu]

TrueHD+AC-3 is not comparable to DTSHD+its core. Two completely different things. Why? Because you can decode TrueHD without AC-3 and AC-3 without TrueHD. However, you cannot decode the DTS HD extension without its core (!). Therefore both TrueHD and AC-3 form their own logical track, they can be used without each other just fine, you don't have to keep them together. With DTS you can separate the core from the HD extension, but then you can only decode the core part, but not the HD-only part.

[psychoboust]

ok, if understand :
a TrueHD + AC3 in the same track from a m2ts should have the same size comparing to a mkv with (the same) 2 tracks (1 TrueHd and 1 Ac3) because Truehd doesn't share information with AC3.

True ?

So we should not call AC3 as Core in TrueHD when in the same track in m2ts file ?

If so, I understand why there is no interest supporting this "feature"

[Mosu]

One could say that the AC-3 part is a lossy representation of the same content that the TrueHD part is a lossless representation of, and that both parts are independent of each other. Of course that's quite a mouthful to say; hence people usually just calling it something else. But yes, calling the AC-3 part a "core" is a misnomer in my opinion.

[psychoboust]

Thanks for your feedback.

I made a simple test with EAC3TO

eac3to.exe "dolby_ATMOS_amaze_lossless-DWEU_.track_4352.thd" acore.ac3 -core
TrueHD/AC3 (Atmos), 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
Extracting AC3 stream...
Creating file "acore.ac3"...

eac3to334>eac3to.exe hd_dts_animated_logo_lossless-DWEU.track_4352.dtshd acore.dts -core
DTS Master Audio, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
Extracting DTS core...
Creating file "acore.dts"...

Even this software tell that AC3 is "embedded" and a different "stream" unlike the DTS which is called "Core"

And to answer my question, if you convert a m2ts to a mkv, TrueHD+AC3 track will have the same size than 1 TrueHD track + 1 AC3 Track. Which is not the case for DTSHD (which can't be separated from its core)

So I Agree, This "feature" is not useful for MKV.

Thks again for your time.

[hubblec4]

Hi Mosu

I have a question about: Split parts by timestamps

The split-times must be ordered? Or can I use something like this:

0s-100s,+600s-700s,+200s-300s

Is MTX so smart to connect different periods of time that are not ordered.

[Mosu]

They have to be sorted as mkvmerge doesn't sort them itself.

[hubblec4]

They have to be sorted as mkvmerge doesn't sort them itself.

It is important NOT to ordered the parts.
The new mkv should be created by this order of the parts.

[Mosu]

Edit: I'm clearly too tired to think clearly about this and not write total rubbish.

mkvmerge processing input once, from start to finish. It cannot jump backwards in time. Therefore the split points you've written will result in an error message during parsing the command line parameters.

[hubblec4]

:-) I saw your first answer, it confused me.

I thought me that this ends up in an error message.
But is it a big work that such split-codes working?

[Mosu]

Yes, huuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuge amount of work. It would involve pretty much rewriting all input, all output modules of mkvmerge as well as the muxer core logic. I can safely say that'll never happen.

[hubblec4]

OK, no hurry next week is good for me :-)

[Arm3nian]

I don't understand how to use a basic function. I add 4 different files, each 25s long, and get a single file which is 25s long. The file has 4 video and 4 audio streams in it. How do I get them to play one after another?

Is it possible to do what I'm trying, or do I have to encode the 4 files into 1.

[hubblec4]

What kind of files, mkv's?

When you like to join files then use "Append to an existing source" option when you load the second file...

[Arm3nian]

That worked, thanks. I was adding all 4 files at the same time.

[Mosu]

Well, hello everyone!

The holidays are always a nice time for coding as the world seems to turn just a tad slower than usual and people are that tiny bit more relaxed. I took the opportunity to work on my backlog and fix quite a number of bugs in mkvmerge. I've also removed those options and features that I had deprecated a year ago.

Another huge change was the near complete rewrite of mkvinfo's internals. The goal is to include its GUI into MKVToolNix GUI in the next release. It won't be a 1:1 copy; instead, the new GUI will have more features. A result is that the output generated by the command-line utility has changed in several ways. See the corresponding NEWS entry below for more details.

An important change for package maintainers is the new requirement for the "cmark" library. Fedora/CentOS/openSUSE already contain the necessary package ("cmark-devel"), whereas Debian/Ubuntu don't just yet (there's the "cmark" package, but that only contains the binary, whereas MKVToolNix needs the library & header files).

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

The Windows and macOS binaries are available already. The Linux binaries are still being built and will be available of the course of the next couple of hours.

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

# Version 20.0.0 "I Am The Sun" 2018-01-15

## Important notes

Feature removal: several deprecated features have been removed:
mkvmerge: the deprecated options `--identify-verbose` (and its counterpart `-I`), `--identify-for-gui`, `--identify-for-mmg` and `--identification-format verbose-text`
all command line tools: support for the deprecated, old, proprietary format used for option files
all command line tools: support for passing command line options via the deprecated environment variables `MKVTOOLNIX_OPTIONS`, `MKVEXTRACT_OPTIONS`, `MKVINFO_OPTIONS`, `MKVMERGE_OPTIONS` and `MKVPROPEDIT_OPTIONS`

mkvinfo: most of its code was re-written in order to lay the groundwork for including its functionality in MKVToolNix GUI but with more features than the existing mkvinfo GUI. The result is that a lot of its output has been changed slightly while keeping the basic layout. Changes include but aren't limited to:
Several element names are a bit clearer (e.g. `Maximum cache` instead of `MaxCache`).
All timestamps and durations are now output as nanoseconds in formatted form (e.g. `01:23:45.67890123`). All additional formats (e.g. floating point numbers output in seconds or milliseconds) were removed.
Element names for chapters and tags are now translated if a translation is available.
Elements located in wrong positions within the Matroska document are handled better.

While mkvinfo's output is mostly kept very stable, it is not designed to be parsed by other utilities. Even though I've tried hard to cram all changes and cleanups into this version, additional changes may be made in the next couple of releases depending on user feedback and bug reports.

## New features and enhancements

mkvmerge: AVC/h.264 packetizer (framed): access unit delimiter NALUs will now be removed. Implements #2173 (https://github.com/mbunkus/mkvtoolnix/issues/2173).

## Bug fixes


mkvmerge: AVC/h.264 parser: when fixing the bitstream timing information mkvmerge will now use exact representations of the desired field duration if possible. For example, when indicating 50 fields/second `num_units_in_tick` is set to 1 and `time_scale` to 50 instead of 5368709 and 268435456. Part of the fix for #1673 (https://github.com/mbunkus/mkvtoolnix/issues/1673).
mkvmerge: AVC/h.264 parser: mkvmerge no longer assumes that encountering sequence parameter set or picture parameter set NALUs signal the start of a new frame. Fixes #2179 (https://github.com/mbunkus/mkvtoolnix/issues/2179).
mkvmerge: AVC/h.264 packetizer (framed): when mkvmerge is told to fix the bitstream timing information, it will now update all SPS NALUs, not just the ones in the AVCC. Part of the fix for #1673 (https://github.com/mbunkus/mkvtoolnix/issues/1673).
mkvmerge: MPEG TS reader: TS packet payloads will only be treated as PES packets if the payload actually starts with a PES start code. The prior behavior led to wrong timestamps and potentially broken frame data. Fixes #2193 (https://github.com/mbunkus/mkvtoolnix/issues/2193).
mkvmerge: MPEG TS reader: mkvmerge will now drop incomplete PES packets as soon as an error is detected in the transport stream instead of passing the incomplete frame to the packetizer. An error is assumed either if the `transport_error_indicator` flag is set or if the value of the `continuity_counter` header field doesn't match the expected value. Fixes #2181 (https://github.com/mbunkus/mkvtoolnix/issues/2181).
mkvmerge: Opus: when re-muxing Opus from Matroska mkvmerge will now write "block duration" elements for all block groups where a "discard padding" is set, too. Fixes #2188 (https://github.com/mbunkus/mkvtoolnix/issues/2188).
mkvmerge: SRT reader: mkvmerge can now handle SRT files with timestamps without decimal places (e.g. `00:01:15` instead of `00:01:15.000`).
mkvmerge: read buffer I/O class: the class could get out of sync regarding the file position of the underlying file I/O class causing wrong data to be returned on subsequent read operations. One result was that trying to identifying MPLS files that refer to very short M2TS files caused mkvmerge to segfault.
mkvmerge: multiplexer core: if there's a gap in audio timestamps, a new block group/lace will be started for the first frame after each gap. Before the fix the frame after the gap was often stored in the previous block group causing the gap to be in the wrong place: at the end of that block group. Fixes #1700 (https://github.com/mbunkus/mkvtoolnix/issues/1700).
mkvextract: AVC/h.264: if two consecutive IDR frames with the same `idr_pic_id` parameter and no access unit delimiters are found between them, mkvextract will insert an access unit delimiter in order to signal the start of a new access unit. Fixes #1704 (https://github.com/mbunkus/mkvtoolnix/issues/1704).
MKVToolNix GUI: update check dialog: Markdown links will now be converted to clickable links. Fixes #2176 (https://github.com/mbunkus/mkvtoolnix/issues/2176).
build system: fixed a race condition when creating new directories if `rake` is run with `-jN` in newer versions of Ruby/`rake`. Fixes #2194 (https://github.com/mbunkus/mkvtoolnix/issues/2194).

## Build system changes


cmark (https://github.com/commonmark/cmark), the CommonMark parsing and rendering library in C, is now required when building the GUIs.


Have fun :)

mosu

[Selur]

Thanks for the new version and all the work to put into it!
(btw. the title of this thread still neeeds updating, still mentions v19.0)

Cu Selur

[hubblec4]

Many thanks for this new version.

All timestamps and durations are now output as nanoseconds in formatted form (e.g. `01:23:45.67890123`).

You changed the output format only? Or are the values now real nanoseconds?

For example DefaultDuration for a normal Bluray with FPS 24000/1001

old time string: 00:00:00.042
new time string: 00:00:00.042000000
real time string: 00:00:00.041708333

[Mosu]

You changed the output format only? Or are the values now real nanoseconds?

The timestamps are not rounded anymore (before they were often rounded to the nearest millisecond, depending on the format used). In the case of the DefaultDuration header element: that one is stored with ns precision in the file, and therefore it is now output with full precision.

The storage in the files hasn't changed.

[hubblec4]

The timestamps are not rounded anymore (before they were often rounded to the nearest millisecond, depending on the format used). In the case of the DefaultDuration header element: that one is stored with ns precision in the file, and therefore it is now output with full precision.

Very nice to read. But all timestamps which stored with Matroska TimestampScale are still Millisec and filled with "0" up to ns?


The storage in the files hasn't changed.
Ok, logic.

[Mosu]

Very nice to read. But all timestamps which stored with Matroska TimestampScale are still Millisec and filled with "0" up to ns?

Yes. All timestamps are output as ns, no matter which precision was used in the file.

[Snowknight26]

Minor issue with v20:

After muxing something and removing all source files, the destination file is unset. When no destination is specified and there are no source files attached, closing the window shows the following prompt:
https://www.stfcc.org/pics/i/9bf16b8315b0d16ca7c1e96de3467df2.png

[hubblec4]

Hi Mosu

When an mkv has no Statistics Tags, could mkvmerge quickly restore/set new one? Or is it necessary to remux the mkv?

[sneaker_ger]

You want mkvpropedit with --add-track-statistics-tags parameter.


Slightly related:
Does ffmpeg calculate on bytes on compressed or uncompressed bitstream? If it behaves like mkvmerge did until recently maybe uncompressed should get a new tag and the spec gets changed to have the current tag use compressed instead of uncompressed size.

/edit2:
On the other hand, sane people basically only use it for subtitles which are small to begin with. Doesn't really matter. Second tag not important.

[hubblec4]

You want mkvpropedit with --add-track-statistics-tags parameter.

Ah, so simple is that, thanks.

[hubblec4]

Another question.

In the output of the identify JSON there is a field: "minimum_timestamp":0, for some tracks.
Is this a start time of the track, and is this a nanosec value?

[sneaker_ger]

Yes and yes.

[hubblec4]

Yes and yes.

Splendid.

And now:
Mosu, is it possible to get a new field: "maximum_timestamp"?

[Mosu]

No, because that would require parsing the whole file just for identification. I want identification to be fast.

[Mosu]

Minor issue with v20:

Most likely some other setting in one of the controls anywhere in the multiplex job is still set, e.g. the title. Therefore the GUI will ask you that question. You can turn such questions off in the preferences.

[Snowknight26]

Most likely some other setting in one of the controls anywhere in the multiplex job is still set, e.g. the title. Therefore the GUI will ask you that question. You can turn such questions off in the preferences.

If it makes any difference, since it is a regression from v19, here are the reproduction steps:

- Open MKVToolNix
- Click 'Add source files'
- Choose a file to add (I was using a Blu-ray's index.bdmv, selecting a random playlist)
- Click to select the file in the 'Source files' panel
- Press the delete key
- Close MKVToolNix

[hubblec4]

No, because that would require parsing the whole file just for identification. I want identification to be fast.

Ok. I understand.

But when you add Statistics-Tags with mkvpropedit is there a parsing required?
A duration for the video track will be set. Is this duration not an end timestamp?

[Atak_Snajpera]

How to get full info about tracks like in v19
mkvmerge.exe" --identify-verbose "video.mkv"
https://pastebin.com/yUCMqpRC

instead of this
mkvmerge.exe" -i -v "video.mkv"
https://pastebin.com/2XssD1xs

[Mosu]

If it makes any difference, since it is a regression from v19, here are the reproduction steps:

- Open MKVToolNix
- Click 'Add source files'
- Choose a file to add (I was using a Blu-ray's index.bdmv, selecting a random playlist)
- Click to select the file in the 'Source files' panel
- Press the delete key
- Close MKVToolNix

Does this happen with v20 but not v19 for the same file?

[Mosu]

Ok. I understand.

But when you add Statistics-Tags with mkvpropedit is there a parsing required?

Yes. mkvpropedit parses the whole file in that case.

A duration for the video track will be set. Is this duration not an end timestamp?

No, it's the difference between the highest timestamp+its duration and the lowest timestamp.

[Mosu]

How to get full info about tracks like in v19
mkvmerge.exe" --identify-verbose "video.mkv"
https://pastebin.com/yUCMqpRC

Use the JSON identification format:

mkvmerge --identification-format json --identify yourfile.mkv

Also read the announcement again (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/NEWS.md#L905), please.

[Snowknight26]

Does this happen with v20 but not v19 for the same file?

Ah boo, it sure does. So not a regression but not the behavior I expected. Oh well. :P

[hubblec4]

Hi Mosu

Here is a short sample (https://forum.videohelp.com/attachments/44395-1515937462/DefaultDuration20ms_BlockDuration40ms.7z): DVD 25FPS MPEG2

The mkv says for DefautDuration 20ms. All BlockDurations are 40ms.
Is this a bug or why set mkvmerge DefaultDuration to 20ms?

[Mosu]

Possibly a bug, though I'm not sure. I don't want to spend any time on MPEG-2, though.

[mkver]

I actually have already reported such behaviour in my very first bug report (https://github.com/mbunkus/mkvtoolnix/issues/1658). Tl;dr: It is an unintended sideeffect of a fix introduced in MKVToolNix 3.3.

[Inviska]

Mkvinfo v20 now outputs '\n' as the newline character on Windows, while in previous versions it was "\r\n".

Is that an intentional change that's going to stay, or is it a mistake?

[Mosu]

That's not an intentional change. Please file an issue over at Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/); otherwise chances are I'll forget about it again. Thanks.

[Mosu]

I've fixed mkvinfo's behavior. The next release will use \r\n again on Windows.

[Inviska]

I've fixed mkvinfo's behavior. The next release will use \r\n again on Windows.

Thanks for fixing that. One other question; I have an MKVExtract GUI and I'm updating it for the changes in version 17. As far as I can see there's no way to determine from MKVInfo whether a file contains tags or cuesheets. To determine if tags and cuesheets were present I ran mkvextract tags and mkvxtract cuesheets and processed the output.

As of version 17, tags and cuesheets now output to a file, so this won't work. The only way I can see to detect if tags and cuesheets are present would be to output them to a file, read the file and then delete it, which would be a bit messy.

Is there a better way of detecting tags and cuesheets?

[Mosu]

Of course there is: don't use mkvinfo in the first place but "mkvmerge --identification-format json --identify yourfile.mkv" As I've said numerous times. Using mkvinfo for that is the wrong tool.