MKVToolNix v24.0.0 released

[hubblec4]

Hi Mosu
and many thanks for this new version.

In the ChapterEditor tool, is a button "Open Matroska, WebM- or Chapter files".
But WebM files doesn't contain chapters (says the specs).

[sneaker_ger]

# Version 14.0.0 "Flow" 2017-07-23

## New features and enhancements

* mkvmerge, mkvpropedit, MKVToolNix GUI (chapter editor): added support for
chapters in WebM files that is spec-compliant by removing all tag elements
not supported by the WebM spec. Implements #2002 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2002).

[Mosu]

But WebM files doesn't contain chapters (says the specs).

Chapters in WebM are spec-compliant (https://www.webmproject.org/docs/container/). The valid elements are a subset of all the chapter elements Matroska supports.

[Mosu]

When flagging H.264 frames from mp4 as discardable is mkvmerge using mp4 container info (is there such info?) or is it parsing the H.264 bitstream?

For normal h.264 bitstreams: container information. In the case of MP4 this information is incomplete as the container level doesn't really provide it

In the case of Annex B bitstreams inside MP4: the bitstream information.

[hubblec4]

Chapters in WebM are spec-compliant (https://www.webmproject.org/docs/container/). The valid elements are a subset of all the chapter elements Matroska supports.

Ok, thanks for this link.

[mkver]

For normal h.264 bitstreams: container information. In the case of MP4 this information is incomplete as the container level doesn't really provide it

In the case of Annex B bitstreams inside MP4: the bitstream information.
This is how I proposed it in #2047. But now that I think about it again I think my proposal was based on a misconception: That parsing framed input would be slow. In fact, for an eternity you have already looked at the first byte of every NAL unit in order to discard filler bytes and now AUDs as well. What do you think?

[Mosu]

Not interested. Due to how Matroska works, mkvmerge has to calculate all reference timestamps properly, which basically means treating any h.264 stream the way an Annex B stream is treated (safe for finding the unit boundaries, of course): calculating the frame order etc. The flags in the "simple block" structure such as "key" and "discardable" are only derived from those reference timestamps. And for situations such as simple blocks being disabled the reference timestamps will actually have to be written to the output file (in the block groups).

So no, it's not just looking at the slice type.

[manolito]

Just stumbled upon a weird interaction between TSDoctor and MKVMerge.

The source is a downloaded TS file from the ARTE Mediathek. I used the SD version, but the HD version has the same problem.

The downloaded TS file has a frame rate of 25 fps, it plays without issues. After running it through TSDoctor it still shows 25 fps and plays nicely. But after repacking this TSDoctor fixed TS using MKVMerge GUI the properties change to VFR, and playback shows heavy artifacts.

If I feed MKVMerge with the original downloaded TS without using TSDoctor then the resulting MKV has 25 fps CFR and plays without problems.

I uploaded my results here:
http://www83.zippyshare.com/v/cndrA2sS/file.html


Any idea what is happening here? I tend to believe that MKVMerge is to blame, because when I use FFmpeg to repack the TSDoctor fixed TS file then the resulting MKV does not show any issues.


Cheers
manolito

[Selur]

Looks to me like TSDoctor is not properly adjusting the headers, mkvmerge keeps the messed up headers and delivers vfr, ffmpeg ignores the headers partially and returns cfr. So I would blame TSDoctor and not mkvtoolnix.

[sneaker_ger]

Mkvmerge drops some frames. E.g. frame #16 display/#13 coded, P frame.

[mkver]

Beginning with mkvmerge 20.0 mkvmerge nows uses the information from the continuity counter that the transport stream provides to decide whether a PES packet in the input is corrupted; corrupted PES packets are dropped. ProjectX says that there are some discontinuities in the continuity counter, so this is what's happening here. It also complains a lot about bit errors in packets.
Why do you use tsdoctor at all? What can it do that mkvmerge can't (apart from outputting a transport stream what mkvmerge obviously won't)?
[Edit]: It's actually slightly different to what I said above: There are some packets in your file that look like this:

47 01 00 39 B7 00 FF FF ... FF FF

(... = 178 more 0xFF)
According to the TS header this packet has an adaption field followed by a payload. The B7 (=183) says that the whole rest of the ts packet belongs to said adaption field, i.e. contrary to what has been signalled the packet doesn't even contain a payload. Now the thing is that the continuity counter is only supposed to increase for packets with payload. If one ignores this restriction, then there is no discontinuity in the continuity counter; but if one expects the continuity counter not to increase with such packets, then one has a discontinuity in the continuity counter which leads to the rejection of the entire PES packet.
Now I have to admit that I don't know whether the continuity counter should increment if the header signals the presence of a payload despite there being none (or does a 0 B payload count?) or if it should only increment when there is an actual payload. Anyway, this faulty header information leads to ProjectY's reports of bit errors in the packet; therefore it drops said packets and reports a discontinuity in the continuity counter afterwards. mkvmerge is likely to do something similar.
PS: I'd really liked to know what TSDoctor is supposed to achieve.

[manolito]

I have been using TSDoctor for a long time for video broadcasts in TS containers mainly to repair broadcast glitches and remove padding data. You are probably correct to question its usefulness for non-broadcast streams like downloaded files or ripped files from a BD.

You cannot really compare TSDoctor to ProjectX. ProjectX converts MPEG2 transport streams to program streams, it repairs broadcast glitches and takes care of keeping A/V sync. TSDoctor keeps the transport stream format when repairing the source, and when there was a glitch in the transmission TSDoctor will issue a warning, but it will not repair the stream. The resulting "fixed" stream will still exhibit A/V sync problems (which ProjectX would have repaired).

Still my question remains valid. Why does the TSDoctor fixed TS file work perfectly, but after repacking it to MKV with mkvmerge the resulting MKV is broken? And doing the repacking of the same file to MKV with FFmpeg does not introduce any problems?


Cheers
manolito

[mkver]

1. mkvmerge does also remove padding data by default. And has done this for a very long time. So I don't see a point in using TSDoctor for broadcast streams, too. You yourself said that mkvmerge when fed with the original ts file produces a flawless file.
2. I did not compare ProjectX to TSDoctor; I just said that I used ProjectX to analyze your sample.
3. I don't see that TSDoctor fixed your TS file; the file it created is corrupted as I have explained. And since when does a mediathek use filler data at all? That would be news to me. So why do they exist in the version produced by TSDoctor? Really strange.
4. ffmpeg ignores the continuity counter, therefore it doesn't care about discontinuities in the continuity counter.

[Mosu]

Now I have to admit that I don't know whether the continuity counter should increment if the header signals the presence of a payload despite there being none (or does a 0 B payload count?) or if it should only increment when there is an actual payload. Anyway, this faulty header information leads to ProjectY's reports of bit errors in the packet; therefore it drops said packets and reports a discontinuity in the continuity counter afterwards. mkvmerge is likely to do something similar.
PS: I'd really liked to know what TSDoctor is supposed to achieve.

ISO/IEC 13818-1 (the standard document describing MPEG program and transport streams) has this to say about the continuity_counter:

continuity_counter – The continuity_counter is a 4-bit field incrementing with each Transport Stream packet with the
same PID. The continuity_counter wraps around to 0 after its maximum value. The continuity_counter shall not be
incremented when the adaptation_field_control of the packet equals '00' or '10'.

The lower bit of the two is what signals the presence of data payload, the higher one the presence of the adaptation field. The standard doesn't say anything about the actual number of payload bytes having anything to do with the decision whether or not the continuity_counter should be incremented; and indeed, mkvmerge doesn't base its decision on it either (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/input/r_mpeg_ts.cpp#L2025).

That 0xb7 = 0b10110111 indicates: 0b10 = transport_scrambling_control; 11 = adaptation_field_control ( = adaption field present, payload present), 01111 = current continuity_counter. The "payload present" flag is set, therefore the condition mentioned above is not met, meaning the continuity_counter must be increased.

If TSDoctor is writing such header fields but isn't increasing the continuity_counter, then it produces broken files and should not be used until that issue's been fixed.

Still my question remains valid. Why does the TSDoctor fixed TS file work perfectly, but after repacking it to MKV with mkvmerge the resulting MKV is broken?

We've just explained this to you.

And doing the repacking of the same file to MKV with FFmpeg does not introduce any problems?

Just guessing: maybe ffmpeg can recognize such situations and fixes them silently.

[nevcairiel]

FFmpeg reads the continuity counter, and it warns if it mis-matches, but it doesn't automatically drop data.

PS:
Your analyzes is one byte off Mosu, the important header starts at 39, but the conclusion remains the same.

[mkver]

That 0xb7 = 0b10110111 indicates: 0b10 = transport_scrambling_control; 11 = adaptation_field_control ( = adaption field present, payload present), 01111 = current continuity_counter. The "payload present" flag is set, therefore the condition mentioned above is not met, meaning the continuity_counter must be increased.

You are off by 1 B: 0x39 is the header byte containing the information concerning TSC, adaption field, payload and continuity counter. It says that both an adaption field and a payload is there (and no scrambling is used); the 0xb7 is the size of the rest of the adaption field (following 0xb7) and it says that 183 B are this rest. Together with the length field and the 4 bytes of header this is the complete packet.

If TSDoctor is writing such header fields but isn't increasing the continuity_counter, then it produces broken files and should not be used until that issue's been fixed.

TSDoctor is writing packets that contain payload according to the header, but in reality don't contain any payload. For these packets it is incrementing the continuity counter which is in line with the spec and the code you cited. I thought that mkvmerge checks whether a ts packet has any real payload, but if it just checks the header then I actually don't understand why this frame is dropped; because then there is no discontinuity in the continuity counter. Version 19.0 doesn't have any problems with it, so it must be the recent changes to the ts input module.
@Nevcairiel: I have seen ffmpeg outputting error messages that PES packet are incomplete, but I never got an error message (or a warning) informing me of discontinuities in the continuity counter.

[Mosu]

Yes, I was off one byte (oops!), but as Nev said, it doesn't actually change the analysis: the adaptation_field is still 0b11, and therefore the continuity_counter must be incremented.

Version 19.0 doesn't have any problems with it, so it must be the recent changes to the ts input module.

Well, that may very well be, but I'm not really interested in spending time on this. There are three methods described in this thread that don't pose a problem (not using TSDoctor in the first place, using ffmpeg on the file produced by TSDoctor, using an older mkvmerge). If anyone wants to debug mkvmege and propose a fix, I'll gladly apply it, of course.

[Mosu]

Well, I did look into my source code. And yes, this is a bug in mkvmerge. From what I can tell, mkvmerge doesn't update its expectation about what the next continuity_counter is supposed to be if a TS packet doesn't contain payload bytes. The line I've linked to above handles that case correctly, it simply isn't called in that case (and that's likely the issue here). I'll see if I can get it fixed.

[Mosu]

Should be fixed in the latest pre-builds (https://mkvtoolnix.download/windows/pre/).

[mkver]

It is. Except for the tags the output is the same as the one from 19.0.

[manolito]

Thanks Mosu for the quick fix. Works nicely here... :thanks:

And a few words in defense of TSDoctor:

Just for fun I installed a more than 5 year old version (1.2.xxx) of the Doctor and repeated the test. Result was exactly the same. So if you insist that TSDoctor creates broken files then it has been doing this for a very very long time. And so far I am not aware that anyone has ever complained about such broken files.

@mkver
I did not compare ProjectX to TSDoctor; I just said that I used ProjectX to analyze your sample.

I was just a little surprised that you tried using ProjectX at all on this sample. ProjectX does not deal with AVC video and AAC audio.

And if you do not know why anyone uses TSDoctor at all, just download the trial version and throw some corrupted broadcast captures at it. From the first page of the manual:

Cypheros TS-Doctor was designed to scan digital Transport Streams for errors and
correct them in a way that the resulting file(s) will play back without surges, dropouts
or diverging sound and picture on Hardware- or Software-Media players.
Unlike some other tools, TS-Doctor tries to keep the original stream as untouched as
possible during error correction, thus avoiding the creation of additional incompatibilities.


Cheers
manolito

[Mosu]

I didn't say TSDoctor is buggy, I said that if it didn't increase the continuity counter in this case, then it would be buggy. It does increase it, though, and therefore isn't buggy. What it is doing is simply curious: creating TS packets without any payload in it. Such packets could simply be skipped, making the file smaller.

[manolito]

I didn't say TSDoctor is buggy...

No, you didn't, but mkver sure did... ;)

Anyway, this faulty header information...
and
I don't see that TSDoctor fixed your TS file; the file it created is corrupted as I have explained.


Cheers
manolito

[mkver]

It seems that the specs agree with TSDoctor about this after all; but given that the existence of packets falsely claiming to contain payload is very strange to say the least and given that the release mkvmerge version worked with the original file I presume that these packets were created by TSDoctor (maybe because it thinks that some players don't like variable bitrate?). And even if one wants constant bitrate (which is incompatible with the goal of removing filler data) one could do so by inserting packets that not even claim to have a payload.
And yes, I know that ProjectX doesn't really support H.264. But I used it just to check the continuity counters and other things at the transport stream layer and it can do this even with unsupported tracks.
But let's not derail this thread any more. If you want to continue to talk about this, let's do it via PM.

[tormento]

@Mosu

Why doesn't delay work with subs (I am trying with srts). Is it a choice or a limit?

[sneaker_ger]

It should work. Try again. If you can't get it to work provide samples and command-line.

[Mosu]

Why doesn't delay work with subs (I am trying with srts). Is it a choice or a limit?

It works just fine. If you have problems, then please post the actual command line used, like sneaker_ger has said.

[tormento]

It works just fine. If you have problems, then please post the actual command line used, like sneaker_ger has said.

Is there a way to get command line from GUI? I insert streams and delays there.

[ChaosKing]

Yes, look at the menu: Multiplexer -> Show command line (Visualizza linea di comando)

[tormento]

It works just fine. If you have problems, then please post the actual command line used, like sneaker_ger has said.
Tried again. It indeed works. I was mislead from gMKVExtractGUI that doesn't show delay as it does for audio. Is there any way to find srt (sub) delay from muxed mkv?

[nevcairiel]

Subtitles are a sparse stream, which means there really is no inherent "delay". Audio and Video typically always start right at time 0, and any difference here can be considered a "delay".
Subtitles only start when there is actual text to be shown, so any information of how much you delayed it during muxing is essentially lost - because it just gets baked into the timstamps of the subtitles.

[tormento]

Subtitles are a sparse stream, which means there really is no inherent "delay". Audio and Video typically always start right at time 0, and any difference here can be considered a "delay".
Subtitles only start when there is actual text to be shown, so any information of how much you delayed it during muxing is essentially lost - because it just gets baked into the timstamps of the subtitles.

:thanks:

[hubblec4]

Hi Mosu

For long time I don't use an .mtxcfg file, but now I realized I can't open the MTX with the mtxcfg (double-click).
What has changed and what can I do to restore this behavior?

[cherishjoo]

It's a great program!

[Mosu]

@hubble4 Nothing has changed. The installer doesn't set a file association for.mtxcfg. You'll have to do that yourself.

[hubblec4]

I have nothing changed on my system. I remember me to set a "system-path" for the mtxcfg. I override the old files from the new versions zip file.
From version 19 on, my mtxcfg's don't start the MTX.

I will check my system, thanks for your reply.

EDIT: All OK now, it was a path issue.

[hubblec4]

Hi Mosu

After nevcairiel's answer in this thread (https://forum.doom9.org/showthread.php?t=175328) I have one question.
Can MTX cut HEVC material on IDR frames only or also on CRA/BLA frames?

[mkver]

mkvmerge cuts at what it considers to be keyframes (e.g. if you manipulate the keyframe flag of a Matroska SimpleBlock or void the reference fields of a BlockGroup, it thinks that this is a keyframe and allows you to cut the stream at this position). If the source file of the HEVC track is "framed" (Matroska or mp4), then things like the keyframe flags will be reused; if not, mkvmerge will analyze the bitstream and a quick search found this place in the code (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/common/hevc_es_parser.cpp#L258) that indicates that a BLA frame without a recovery_point SEI message won't be considered a keyframe.

[hubblec4]

Hi Mosu

I have some questions about mtxcfg file and JSON identify.

In an mtxcfg file exists more then one "type"-object. A "type"-object("type": 22 (for m2ts)) is used for a file and it is the same value like in JSON identify "container_type"
"container": {
"properties": {
"container_type": 22,
"is_providing_timestamps": true
},
"recognized": true,
"supported": true,
"type": "MPEG transport stream"
},
On the other hand, the "type"-object(MPEG transport stream) from this JSON identify sample is not used in mtxcfg, right?

In mtxcfg exists for each track also a "type"-object ("type": 0 for DTS-HD Master Audio) but in JSON identify the "type"-object is a string (video,audio etc).
{
"codec": "DTS-HD Master Audio",
"id": 1,
"properties": {
"audio_channels": 6,
"audio_sampling_frequency": 48000,
"language": "eng",
"number": 4352,
"program_number": 1,
"stream_id": 4352
},
"type": "audio"
},

Is this an issue?
How can I determine the right value for an mtxfcg track "type"-object with info from JSON identify?
Could you add this info?
I know, then are two "type"-objects present. Why exists so many same named objects with different usage?

Best regards hubble

[Perenista]

I tried to add a .sub subtitles to a MKV and MKVTOOLNIX said MicroDVD is not supported. I easily converted into SRT, and then was able to add. Why is this unsupported? Are all .SUB s affected?

[sneaker_ger]

Reason:
https://gitlab.com/mbunkus/mkvtoolnix/issues/77

Often people use .sub/.idx files, those are different from MicroDVD. Then you can just add the .idx file.

[Mosu]

I have some questions about mtxcfg file and JSON identify.

Those two formats don't correlate. The mtxcfg format predates the JSON identification format. The JSON identification format is an official API of MKVToolNix, the mtxcfg format isn't — therefore its values reflect more closely how the GUI's built internally.

On the other hand, the "type"-object(MPEG transport stream) from this JSON identify sample is not used in mtxcfg, right?

That's correct. The GUI uses its internal knowledge for mapping the numerical container type to the string displayed in the "container" column in the multiplexer's "source files" list.

How can I determine the right value for an mtxfcg track "type"-object with info from JSON identify?

The "type" in the mtxcfg for tracks is important as it determines what kind of a track it is: audio, video, subtitles, chapters, tags… The GUI decides which controls to enable/disable based on this value. The values are the ones from "enum Type" in "class Track" (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/mkvtoolnix-gui/merge/track.h#L21). Again, this numerical value reflects internal knowledge of the GUI the user shouldn't need to be aware of — and as mtxcfg is considered not to be part of an external API, the GUI uses those internal values there.

I know, then are two "type"-objects present. Why exists so many same named objects with different usage?

Because there are many different kinds of objects that need their type information. External APIs (the JSON identification format) use human-readable strings; internal APIs (the mtxcfg format) often use internal, numerical values as they don't require conversion.

[hubblec4]

Many thanks for this explanation.

I know that mtxcfg is not for normal users but I want support it again in my new cE. The old code still works with version 21/22 but it is too old and missing new MTX functions.

I'm very familiar with the structure of mtxcfg and with JSON identify it is now more easier to build such mtxcfg files.
All the extended functions of cE can then be used in the MTX.


In a JSON identify for an mp4 file there is no chapter track. When I load an mp4 to MTX and save the mtxcfg there is a second chapter track.
Could you add this info to JSON identify?

hubble

[Mosu]

In a JSON identify for an mp4 file there is no chapter track. When I load an mp4 to MTX and save the mtxcfg there is a second chapter track.

Chapters are handled differently in the GUI and in the identification output. In the ID output, there's a separate key called "chapters" on the same level as "tracks", "container" etc. In the GUI that's turned into an entry in the track listing even though it's not a track. Tags are handled the same way.

[hubblec4]

Ah yes, I see the entry for chapters(identify output), but there is only the "num_entries" object. Thats not very helpful.
But mp4-chapter-track has not much mtxcfg-objects and not all are necessary.

[Mosu]

The GUI doesn't use anything more anyway for chapters. What mkvmerge delivers is enough.

[hubblec4]

OK, nice to know. Same for Tags I guess?

[Mosu]

Yes, both types are treated almost identically.

[Mosu]

Hey everyone.

I thought today would be a good day for a new release of MKVToolNix: v22.0.0 is here. Celebrating the official announcement of AV1, this is the first release that contains support for that format as well (still some things to do, though). Other than that the info tool in the GUI has been improved quite a bit.

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 since the previous release:

# Version 22.0.0 "At The End Of The World" 2018-04-01

## New features and enhancements

* mkvmerge, MKVToolNix GUI multiplexer: AC-3, DTS, TrueHD: added an option for removing/minimizing the dialog normalization gain for all supported types of the mentioned codecs. Implements #1981 (https://gitlab.com/mbunkus/mkvtoolnix/issues/1981).
* mkvmerge: AV1: added support for reading AV1 video from IVF, WebM and Matroska files.
* mkvmerge: FLAC: mkvmerge can now ignore ID3 tags in FLAC files which would otherwise prevent mkvmerge from detecting the file type. Implements #2243 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2243).
* mkvinfo: the size and positions of frames within "SimpleBlock" and "BlockGroup" elements are now shown the same way they're shown for other elements (by adding the `-v -v` and `-z` options).
* MKVToolNix GUI: multiplexer: added options for deriving the track languages from the file name by searching for ISO 639-1/639-2 language codes or language names enclosed in non-word, non-space characters (e.g. "…[ger]…" for German or "…+en+…" for English). Implements #1808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/1808).
* MKVToolNix GUI: info tool: implemented reading all elements in the file after the first cluster. Only top-level elements are shown; child elements are only loaded on demand. Implements the rest of #2104 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2104).
* MKVToolNix GUI: info tool: added a context menu with the option to show a hex dump of the element with the bytes making up the EBML ID and the size portion highlighted in different colors. In-depth highlighting is done for the data in `SimpleBlock` and `Block` elements.
* MKVToolNix GUI: chapter editor: added an option to remove all end timestamps to the "additional modifications" dialog. Implements #2231 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2231).

## Bug fixes

* mkvmerge: MP4 reader: fixed reading the ESDS audio header atom if it is located inside a "wave" atom inside the "stsd" atom.
* mkvmerge: MP4 reader: AAC audio tracks signalling eight channels in the track headers but only seven in the codec-specific configuration will be treated as having eight channels.
* mkvmerge: MPEG TS reader: fixed wrong handling of the continuity counter for TS packets that signal that TS payload is present but where the adaptation field spans the whole TS packet.
* mkvmerge: the 'document type version' and 'document type read version' header fields are now set depending on which elements are actually written, not on which features are active (e.g. if a `SimpleBlock` is never written, then the 'read version' won't be set to 2 anymore). Part of the fix for #2240 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2240).
* mkvmerge: the 'document type version' header field is now set to 4 correctly if any of the version 4 Matroska elements is written. Part of the fix for #2240 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2240).
* mkvinfo: summary mode: the file positions reported for frames in `BlockGroup` elements did not take the bytes used for information such as timestamp, track number flags or lace sizes into account. They were therefore too low.
* mkvpropedit, MKVToolNix GUI header editor: the 'document type version' and 'document type read version' header fields are now updated if elements written by the changes require higher version numbers. Part of the fix for #2240 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2240).
* mkvpropedit, MKVToolNix GUI header editor: mandatory elements can now be deleted if there's a default value for them in the specifications. Fixes #2241 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2241).
* source code: fixed a compilation error on FreeBSD with clang++ 5.0. Fixes #2255 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2255).

## Build system changes

* A compilation database (in the form of a file `compile_commands.json`) can be built automatically if the variable `BUILD_COMPILATION_DATABASE` is set to `yes` (e.g. as `rake BUILD_COMPILATION_DATABASE=yes`).

Have fun :)

[sneaker_ger]

Thx. Some nice new features (mkvinfo hex, language from file name).


* mkvmerge: MP4 reader: AAC audio tracks signalling eight channels in the track headers but only seven in the codec-specific configuration will be treated as having eight channels.
What is the reasoning behind this?



P.S.: You linked to github issue tracker, not gitlab.