MKVToolNix v24.0.0 released

[manolito]

not any. I'm using a DVB-T2 receiver with PVR feature. it is the Comag SL30T2.

Only few folks here in Germany use USB tuners to capture DVB-T2 directly to the computer. Due to the HEVC format in 1080p @ 50fps this requires a very powerful machine.

For receivers with PVR the users are entirely at the mercy of the manufacturer (or the chipset manufacturer). My XORO HRT 720 seems to have the same chipset as your Comag. The latest firmware update was from June 2017, and it does not look like there will be any more updates in the future. But so far I never had such ugly glitches as you had in my captured files, not even on days when the air is full of low flying choppers (when some foreign high security politician is visiting Angie...)


Cheers
manolito

[Mosu]

Hey.

time for MKVToolNix v24.0.0, a release that's on the smaller side regarding the number of changes: nothing major, a number of smaller bugs squashed, a couple of enhancements.

AV1 support hasn't changed as the bitstream format still hasn't been finalized.

To my users on Debian and Ubuntu: just a friendly reminder that the layout of my APT repositories was changed in April. If you haven't done so, you'll have to update your `sources.list` entry accordingly. Read more about that in this blog post (https://www.bunkus.org/blog/2018/04/debian-ubuntu-apt-repository-changes/).

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 24.0.0 "Beyond The Pale" 2018-06-10

## New features and enhancements

* mkvmerge: MP4 reader: improved the detection of edit lists consisting of two identical entries, each spanning the file's duration as given in the movie header atom. The second entry is ignored in such cases. See #2306 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2306).
* mkvmerge: JSON identification: the "display unit" video track property is now reported as `display_unit`. The JSON schema has been bumped to v11 for this change.
* mkvmerge, mkvextract: AVC/h.264: empty NALUs will now be removed.
* mkvextract: VobSub extraction: empty SPU packets will now be dropped during extraction as other tools such as MP4Box cannot handle them correctly. Implements #2293 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2293).

## Bug fixes

* mkvmerge: E-AC-3 parser: fixed determining the number of channels for streams that contain an AC-3 core with dependent E-AC-3 frames. Fixes #2283 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2283).
* mkvmerge: Matroska reader: fixed mkvmerge buffering the whole file if a video track is multiplexed that consists of only one or a few frames. Fixes #2304 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2304).
* mkvmerge: the "display unit" video track property will now be kept if it is set in the source file. Fixes #2317 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2317).
* MKVToolNix GUI: multiplexer: when scanning playlists, all playlists were offered for selection regardless of the value of the "minimum playlist duration" setting. Fixes #2299 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2299).
* MKVToolNix GUI: multiplexer: deriving track languages from file names: the regular sub-expressions for ISO 639-1 codes could match on empty strings, too, causing matches in wrong places and hence no language being recognized in certain situations. Fixes #2298 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2298).
* MKVToolNix GUI: header editor: fixed a crash when saving the file fails (e.g. because it isn't writable). Fixes #2319 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2319).
* MKVToolNix GUI: header editor: the editor was wrongfully claiming that mandatory elements with default values cannot be removed in the "status" text. Fixes #2320 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2320).
* MKVToolNix GUI: preferences: on macOS & Linux the setting "enable copying tracks by their type" wasn't restored on program start. Fixes #2297 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2297).

## Other changes

* Niels Lohmann's JSON library: the bundled version has been updated from v1.1.0 (git revision 54d3cab) to v3.1.1 (git revision g183390c1).
* pugixml library: the bundled version has been updated from v1.8 to v1.9 (git revision e584ea3).

Have fun :)

[hubblec4]

Many thanks for this upgrade and your work.

[Midzuki]

Regression report:

recent versions of MKVtoolnix are unable to mux MLP files correctly.
Version 5.8.0 of MKVmerge did the job well and produced a 28.3 MB .mka from a 26.8 .MLP, whereas MKVmerge 24.0.0 generates a 22.4 MB .mka from the same source.

Sample files: http://www.mediafire.com/file/dpwrgu1z1mtkr1k/MLP-at-44100Hz-Sample.7z/file

[mkver]

In Midzuki's case 7.6 was the last version that worked; the behaviour changed in 7.7.

[SeeMoreDigital]

Regression report:

recent versions of MKVtoolnix are unable to mux MLP files correctly.
Version 5.8.0 of MKVmerge did the job well and produced a 28.3 MB .mka from a 26.8 .MLP, whereas MKVmerge 24.0.0 generates a 22.4 MB .mka from the same source.

Sample files: http://www.mediafire.com/file/dpwrgu1z1mtkr1k/MLP-at-44100Hz-Sample.7z/fileOut of interest... Why don't you re-encode your .mlp contained files to flac?

[Mosu]

recent versions of MKVtoolnix are unable to mux MLP files correctly.

Thanks for the report. But please open an issue on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/). Otherwise chances are I'll forget about it again.

[Midzuki]

Thanks for the report. But please open an issue on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/). Otherwise chances are I'll forget about it again.

Done. And many thanks for answering :thanks:

[v0lt]

@Mosu
In old versions of "mkvinfo.exe" the "--gui" key worked. Now it does not work :(, can I return it?

[Mosu]

mkvinfo's GUI has been removed and replaced by the "info" tool in MKVToolNix GUI. You can start that directly via "mkvtoolnix-gui --info yourfile.mkv".

mkvinfo's GUI won't be coming back.

[arrgh]

Yes, for the sake of completeness — but if I'm entirely honest, then that feature probably has the lowest priority of all the things that I still want to implement. Mostly because I have zero interest in 3D myself.

Hi Mosu
did this feature to mux MVC-mkv move up in the priority list somewhat...?

Thanks

[mike23]

How can I find out with mkvtoolnix what the average video bitrate of a *.mkv video is?

Sometimes tools like MediaInfo do not show this info.
See as sample snapshot here:
http://easycaptures.com/2581037801

But I could imagine that this is possible with mkvtooolnix

[mkver]

Some muxers like mkvmerge (or MakeMKV) add statistcs tags by default that enable MediaInfo to show the average bitrate of the tracks in the file to the user. If these tracks aren't there, MediaInfo simply doesn't know the numbers.
You can use mkvpropedit (a part of MKVToolNix) to add the track statistics tags to your file: mkvpropedit --add-track-statistics-tags <file>

[mike23]

You can use mkvpropedit (a part of MKVToolNix) to add the track statistics tags to your file: mkvpropedit --add-track-statistics-tags <file>

Thank you for the suggestion.

I executed the command (on an existing *.mkv file) just as above and yes the output looks good:

The file is being analyzed.
The file is read in order to create track statistics.
Progress: 100%
The changes are written to the file.
Done.

But when I drag the *.mkv file afterwards onto MediaInfo again then the average bitrate is still NOT shown.

Whats wrong?

BTW: Can I somehow execute the --add-track-statistics-tags operation in the GUI version of mkvpropedit as well?
I found no corresponding checkbox or menu

And finally I wonder if there is a GUI which let me do this without changing the *.mkv file. In other words which analyze the mkv and show me all infos about the used codecs. Unfortunately
mkvtoolnix-gui.exe does not offer this function

[mkver]

You are right. My version of MediaInfo (18.03.1) shows it only in the following way:


Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, RefFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 4 s 160 ms
Bit rate : 8 409 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 50.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.182
Stream size : 4.17 MiB (95%)
Default : Yes
Forced : No
Statistics Tags Issue : mkvpropedit v24.0.0 ('Beyond The Pale') 64-bit 2018-06-16 09:28:36 / Lavf58.13.100
FromStats_BitRate : 11464630
FromStats_Duration : 00:00:03.120000000
FromStats_FrameCount : 150
FromStats_StreamSize : 4471206

Audio
ID : 2
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : A_MPEG/L2
Codec ID/Hint : MP2
Duration : 4 s 166 ms
Bit rate mode : Constant
Bit rate : 256 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Delay relative to video : -1 s 46 ms
Stream size : 130 KiB (3%)
Language : German
Default : Yes
Forced : No
Statistics Tags Issue : mkvpropedit v24.0.0 ('Beyond The Pale') 64-bit 2018-06-16 09:28:36 / Lavf58.13.100
FromStats_BitRate : 257542
FromStats_Duration : 00:00:03.984000000
FromStats_FrameCount : 167
FromStats_StreamSize : 128256

It seems that MediaInfo doesn't display the track statistics tags in the usual way if the tags don't seem to have been created during muxing. This even applies to the case when there is a "date" element in the header so that one can check whether the tags are up to date (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Automatic-tag-generation#determining-if-the-tags-are-up-to-date) (ffmpeg/Lavf doesn't write the date element). I'll report this to the MediaInfo developers.

[Mosu]

did this feature to mux MVC-mkv move up in the priority list somewhat...?

No, it didn't.

[v0lt]

mkvinfo's GUI has been removed and replaced by the "info" tool in MKVToolNix GUI. You can start that directly via "mkvtoolnix-gui --info yourfile.mkv".

mkvinfo's GUI won't be coming back.
It's a pity.
Can I run mkvtoolnix-gui.exe with English translation? I need something like the "--ui-language en" key, which was in mkvinfo.exe.

[Mosu]

Can I run mkvtoolnix-gui.exe with English translation? I need something like the "--ui-language en" key, which was in mkvinfo.exe.

That doesn't work at the moment, though I'm not sure why. It certainly was my intention to have that working. I'll look into it.

[Midzuki]

Not a bug report at all, just a *request-for-comments*.

mpv was unable to deal with Matroska files that contain MLP streams. I reported the flaw, and today that flaw has been fixed. I downloaded the latest Windows build of mpv from SourceForge and put it to the test. Now mpv.exe shows the following warning message:

=> mpv PaBailar-580.mka
Playing: PaBailar-580.mka
(+) Audio --aid=1 --alang=spa (*) (mlp 2ch 44100Hz)
[mkv] This is a broken file! Packets with incorrect keyframe flag found. Enabling workaround.
AO: [wasapi] 48000Hz 5.1 6ch float

So my question is: ¿does that warning make any sense? :confused:

[Mosu]

Does that happen with TrueHD files produced by MKVToolNix as well?

[Midzuki]

Does that happen with TrueHD files produced by MKVToolNix as well?

I don't have any sample files with TrueHD audio, so I don't know.

Given that MPlayer (a.k.a. «the real thing») just plays that .MKA file without a complaint, I assume the mpv developers don't know very-well what they're doing :(

[Mosu]

I'm asking about TrueHD as TrueHD and MLP are very similar. Both are two of the few audio codecs (RealAudio being another one) where you cannot start decoding from any packet. Therefore mkvmerge flags only those frames decoding can start from as key frames. Maybe mpv expects that all audio frames are marked as key frames — but that's just conjecture, of course, I don't know mpv's source code.

[SeeMoreDigital]

Unlike Dolby TrueHD audio streams on Blu-ray discs, DVD-Audio discs are essentially PCM streams packed into the .mlp container.

Personally I don't see any benefit of keeping a PCM audio stream within the .mlp container and containing it again within the .mka container. Which is why I've backed up all my DVD-A's to flac.

Sufficed to say, flac can be muxed into the .mka container and the files are smaller than the original .mlp contained files...

[Midzuki]

^ Okay, I found and tested a TrueHD MKA file. Just for the notes, MediaInfo says

Track name : Final Fantasy Advent Children Complete (2009)
Encoded date : UTC 2011-07-05 20:41:36
Writing application : mkvmerge v4.6.0 ('Still Crazy After All These Years') built on Apr 1 2011 21:01:49
Writing library : libebml v1.2.0 + libmatroska v1.1.0

This time mpv didn't display any stupid /misleading message:

=> mpv TrueHD-Sample.mka
Playing: TrueHD-Sample.mka
(+) Audio --aid=1 (*) (truehd 6ch 48000Hz)
File tags:
Title: Final Fantasy Advent Children Complete (2009)
AO: [wasapi] 48000Hz 5.1(side) 6ch s32

So the problem really is in mpv itself, not in MKVmerge (or in FFmpeg). Before I reported that issue, mpv already dealed with containerless .MLP streams, it simply didn't know what to do with MLP audio in a Matroska container.

I was going to tell the mpv people to take a look at our latest comments in this thread, but the admin of mpv's Github locked the issue I filed because it became "too hot" :rolleyes:

[Midzuki]

Unlike Dolby TrueHD audio streams on Blu-ray discs, DVD-Audio discs are essentially PCM streams packed into the .mlp container.

Personally I don't see any benefit of keeping a PCM audio stream within the .mlp container and containing it again within the .mka container. Which is why I've backed up all my DVD-A's to flac.

Sufficed to say, flac can be muxed into the .mka container and the files are smaller than the original .mlp contained files...

You missed the whole point. I should send you to my IgnoreList (again), but I won't. Not yet, at least =)

P.S.: MLP is not a container for uncompressed audio. PCM is not the same as PPCM.

[SeeMoreDigital]

I just don't see the benefit of placing mlp compressed PCM streams within the .mka container!

[mkver]

So the problem really is in mpv itself, not in MKVmerge (or in FFmpeg).
Strange. In my experience ffmpeg wants all audio packets to be flagged as keyframes. When I play a Matroska file created by mkvmerge with video and TrueHD audio and seek in the input file (e.g. ffmpeg -ss 10 -i <mkv file created by mkvmerge> ...) I usually get a "File is broken, keyframes not correctly marked!" error. Given that the index is for the video, the first audio packet received after the seek is probably a non-keyframe. Strangely this doesn't happen without a video track although mkvmerge does not take the keyframe flag into account for creating the cues for files without video track. (Btw: It also doesn't take the clustering into account in this case.)

[Mosu]

"File is broken, keyframes not correctly marked!"

This looks like a bug in ffmpeg to me. libavformat/matroskadec. (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskadec.c#L3358) seems to assume that the first non-subtitle ( = audio or video) block after a seek-to-keyframe operation must be a key frame. The situation with MLP & TrueHD is, though, that ffmpeg might try to seek to a video key frame and find an audio block first — and that audio block isn't a key frame because it doesn't contain an MLP/TrueHD sync frame.

[foxyshadis]

I just don't see the benefit of placing mlp compressed PCM streams within the .mka container!

Why would you put anything in an mka container? Seeking, standardized tags, chaptering... there are a lot of potential reasons.

MLP is virtually identical to FLAC from a high-level technical standpoint, although it's obviously implemented to suit the constraints of fixed rotational speeds and buffer sizes, as well as often being fixed-bitrate (meaning just stripping padding and re-packetizing it would win you a lot, as well as changing every frame to a keyframe). Plus MLP has no standardized tags or seek tables, so why wouldn't you place it in a container that does?

[SeeMoreDigital]

In today's world (ppcm) mlp is pointless, in or out the .mka container!

Flac offers tagging and image art and far greater software and hardware playback device support.

Sadly I'm yet to find a hardware playback device that supports .mka chapter navigation. Which is why I'm still creating .cue files...

[LeMoi]

I think title of the topic should be changed to meet latest version

[hubblec4]

I think title of the topic should be changed to meet latest version

please read here
https://forum.doom9.org/showthread.php?t=175541

[LeMoi]

Thanks for the info, didn't notice, hope mods can do something :)

[foxyshadis]

Excellent point, done. I'd normally suggest reporting posts when mod action is needed, except avih hasn't been around in a while and Koepi hasn't been around since Longcat was a fresh meme. I should petition to get myself added as a mod on more of the abandoned fora.

[SeeMoreDigital]

Excellent point, done. I'd normally suggest reporting posts when mod action is needed, except avih hasn't been around in a while and Koepi hasn't been around since Longcat was a fresh meme. I should petition to get myself added as a mod on more of the abandoned fora.
Sadly, quite a few moderators are MIA :(

[Masutin]

An issue with splitting. To cut the same duration, counting from the end, at the end of files of different lengths, is there a way to specify a duration (not a timestamp) FROM the end of a file? If not for mkvmerge, for FFmpeg if appropriate.

[Mosu]

Not for mkvmerge, as the file's duration is generally only only after it has been fully muxed.

[Perenista]

Is there a way to turn a video 90 degrees clockwise with MKVToolnix? Or I need to use another software like Sony Vegas and reencode?

[Mosu]

Is there a way to turn a video 90 degrees clockwise with MKVToolnix? Or I need to use another software like Sony Vegas and reencode?

MKVToolNix cannot do this. It's not a video editor/encoder. Additionally there are no provisions for filters/modifications/projections upon display in Matroska either.

[Perenista]

MKVToolNix cannot do this. It's not a video editor/encoder. Additionally there are no provisions for filters/modifications/projections upon display in Matroska either.Hum, what do you mean?

For example, if I wanted to change the display aspect ratio in MKVToolnix I could do that easily. Some videos have a wrong AR, and I usually adjust them by configuring the AR to 4:3, or even 16:9, depending on the case.

Sometimes I use MakeMKV and the extra features are in 3:2 for some odd reason (it only happens with certain discs). Then I use that option to correct the MKV files.

I assumed that since this sort of modification is possible (while mantaining the contents in lossless) I could easily turn the video 90 degrees clockwise without any unnecessary reencode.

The issue with my video is that I recorded using an iPAD Pro 10.5 while not using landscape/portrait properly. So the video looks like this now:

https://imgur.com/a/SkBt9ZZ

Another reason for me to not want to resort to reencode is that I have multiple videos from the iPAD, and once ONE is reencoded you have to do the same for all others, since it's not possible to combine them by using MKVToolnix anymore *.

* At least I don't think this can be done, I remember seeing "the streams don't match" warnings in the past.

I assumed "90 degrees clockwise" was just another random command given to the Matroska just like "change the AR to 4:3, 16:9 or 1.85:1), and the player would only interpret it to adjust accordingly.

Do you guys follow my line of reasoning...?

[Mosu]

Changing the display aspect ratio is basically the only such operation that you can do in Matroska without reencoding the video.

[gpower2]

Hey guys! I have a question for the experts:
A friend of mine was hit by a ransomware and lost a lot of his files. He is interested in a particular mkv file which seems to only have its first bytes encrypted, meaning the mkv header is totally corrupted, yet the track data remain intact.
Is there a way to extract the tracks of that damaged mkv, or recreate the mkv header?

Thanks! :)

[Mosu]

If they know the codec type and order of tracks, they could create a second file with the same track types and track order. Then use a hex editor and combine the track headers (everything before the first cluster) from the second file with the clusters from the encrypted file.

One problem will be CodecPrivate content. This won't be 100% identical in the second file you've created. However, you might get away with additional steps:

Extract the video track from the combined file with "--raw"
Remux that extracted data with mkvmerge

This might work if it's h.264 or h.265 and the SPS/PPS are part of the bitstream as mkvmerge will then be able to re-create the CodecPrivate from the bitstream.

Things get somewhat more complicated with AAC and CodecPrivate. In that case I'd try hard to simply get an audio track to mux with the same stream parameters (number of channels, sample rate, profile) and use the resulting track headers.

After all, they should start making regular backups — the best insurance against data loss of any kind, including crypto ransomware.

[MrVideo]

I assumed that since this sort of modification is possible (while mantaining the contents in lossless) I could easily turn the video 90 degrees clockwise without any unnecessary reencode.
I get the feeling that you do not understand how video works. The video image that is encoded into MPEG-2, H.264 and H.265 (the common codecs that consumers basically use), "scan" from top to bottom, left to right. The aspect ratio is only a "tag" that tells the displaying device how the "pixels" are to be displayed. The decoding of the video is done top to bottom, left to right. Think of the old analog video displays. Same concept, just done with pixels.

The iPad, or any video recording device, does top to bottom, left to right, as if you were holding the recording device landscape. Hence, when you play back your portrait mode video, it looks like you shot it while laying on your side. The only way to "fix" it is to recode it and adding pillar bars on the sides. The vertical resolution is also reduced because the 1920 pixels have to be reduced to 1080 pixels. The horizontal resolution has to be reduced to 607 pixels in order to keep the 9:16 aspect ratio. That is why all these idiots (IMHO) who shoot video with their cell phones result in there being pillar bars of some sort on the left and right. Things are fine if you only view the video on your cell phone, but contribute the video to a TV station and it looks like crap (IMHO). I even harp on my daughter when she sends me vertically shot video.

Sorry, but your video is frack'd.

[mkver]

The only way to "fix" it is to recode it and adding pillar bars on the sides.
There is another way:
1. If your video is H.264, you can add a "Display Orientation SEI message" into the bitstream that contains the information that this video should be turned by 90° when viewed.
2. You can use a container that allows you to rotate the video. mp4 does so (you have to set the right "matrix"), Matroska unfortunately not.
Both these approaches have a downside: They only work on players that take this side-data into account. The second approach seems to work with ffmpeg-based players; the first seems not to do so. (I haven't seen a player that actually honours these SEI values.)

[SeeMoreDigital]

Provide an AVC encoded sample and I'll make it play back at any aspect ratio you like?!

[Mosu]

MKVToolNix v25 has been released. There's a new thread for that (http://forum.doom9.org/showthread.php?p=1846426#post1846426) as I cannot change the title (http://forum.doom9.org/showthread.php?t=175541) of this one anymore — this thread is simply too old. Please head over to the new thread. This one will be closed soonish. Thanks!