MKVToolNix v24.0.0 released

[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, the Windows installer/portable version & macOS DMG and the source code.

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 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.

## 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• MKVToolNix GUI: update check dialog: Markdown links will now be converted to clickable links. Fixes #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.

## Build system changes

• 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]

Originally Posted by hubblec4

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]

Originally Posted by Mosu

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?

Originally Posted by Mosu

The storage in the files hasn't changed.

Ok, logic.

[Mosu]

Originally Posted by hubblec4

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/9bf16b8...6de3467df2.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]

Originally Posted by sneaker_ger

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]

Originally Posted by sneaker_ger

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]

Originally Posted by Snowknight26

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]

Originally Posted by Mosu

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]

Originally Posted by Mosu

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]

Originally Posted by Snowknight26

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]

Originally Posted by hubblec4

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.