MKVToolNix v56.1.0 released

[Mosu]

Got it! Uploading a new build to the Microsoft Store as we speak. All command-line applications will be runnable in the future. Thanks again for the pointer!

[Thunderbolt8]

I encountered a problem when muxing a HEVC HDR & EAC3 video file. basically the process stopped at 35% and said "failed". cant tell if related to the latest version as I only tested it with this one. is there any kind of error log?

btw. I tried to use file splitting here (max. 2 files, but the error occured before the splitting point was reached. I tried not to use splitting thrice, then the error occured at 35%, and 2x at 98%.

[Mosu]

That sounds… interesting. Might be a bug, might be bad hardware. Can you upload the source file(s) in question to my file server, please? And paste the command line of how your mux job was set up? Thans.

[rsotome]

MKVToolNix v56, does the newest build no longer write the language to the chapters?

When muxing an mkv, whether using a .txt or .xml chapter file, I have the setting under output language, set to English (eng), but the info doesn't show up under mediainfo.

Now if I use JMKvpropedit to stip out the chapter info of the muxed video & then add it back in, the language is properly ID'd under the chapters as en:, plus the chapter name.

[rco133]

Originally Posted by rsotome

MKVToolNix v56, does the newest build no longer write the language to the chapters?

When muxing an mkv, whether using a .txt or .xml chapter file, I have the setting under output language, set to English (eng), but the info doesn't show up under mediainfo.

Now if I use JMKvpropedit to stip out the chapter info of the muxed video & then add it back in, the language is properly ID'd under the chapters as en:, plus the chapter name.

Hi.

v56 defenately behaves different than v55 in this matter.

v55 has en:Chapter while v56 just has :Chapter

The changelog mentions this:

* mkvmerge, mkvpropedit, MKVToolNix GUI chapter editor: chapters: the programs
will no longer write chapter elements that are mandatory and set to their
default value (e.g. "chapter language" set to `eng` = English or "Chapter
flag enabled" = 1).

Not sure if thats the reason.

[Mosu]

Well, the chapter language element is a mandatory element with a default value of "eng". What this means is that any reader MUST use the value "eng" if the chapter language element is not present in a "ChapString" parent. If MediaInfo doesn't follow that rule, that's a bug in MediaInfo.

rco133 has correctly identified the news entry relating to this change.

[Thunderbolt8]

Originally Posted by Mosu

That sounds… interesting. Might be a bug, might be bad hardware. Can you upload the source file(s) in question to my file server, please? And paste the command line of how your mux job was set up? Thans.

the source file is 31Gg though. would it still fit? and can the upload be resumed?

[Mosu]

The server has more than enough space, and upload resuming is supported. Thanks.

[Perenista]

Am I wrong when I say that if I do this:

- Split a 89 GB Matroska file (4K resolution) into 15200M or 15300M parts;
- Then append all these parts...

The resulting file will somehow grow a few seconds longer, thus messing with audio sync in the middle?

Because that's exactly what happened here.

And no reports of any error with this job. I will try to create the original Matroska again, and repeat all previous steps.

But I am concerned now that splitting poses a serious risk of damaging the content forever, and if this is the only copy, then I need to identify what has caused this issue.

Because I've been doing exactly this: splitting and appending many different contents, yet I doubt I have seen this happening before.

The only change I did to the original MKV which was more or less 4 seconds shorter was to add a few audio/subtitle tracks. Mosu needs to clarify if splitting and appending sometimes breaks the file the way I described. Or perhaps I did something wrong during my edits...

*****
This is the file I just appended all 6 parts:

https://pastebin.com/dTMTJ70W

This is veeeeery odd. Because when I compare to a smaller one (4 GB, 1080p instead of 4K) the 1080p file has 3 hours, 51 minutes and 38 seconds. While the 4K has 3h51m42s.

For example, if we pause at these moments they will be different:

4K:
00:39:04.431

1080p:
00:39:04.282

******

4K:
02:08:46.470

1080p:
02:08:43.518

******

This can't happen. In the 2nd scene the moments should be the same. Not a 2-3 second difference between them.

I am now thinking this could be it:

4K:
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS

1080p:
Frame rate : 23.976 (24000/1001) FPS

1080p MEDIA INFO: https://pastebin.com/nDB5gZd7

Apparently MKVTOOLNIX inadvertently changed the FPS to something else, which could account for this abnormal result while appending the splitted 4K file.

Or it could be MAKEMKV's fault, while creating the Matroska.

I am going to have to redo this MKV, from the original 4K disc.

What is odd is that this disc shows the following info in the playlist report:

************
PLAYLIST REPORT:

Name: 00040.MPLS
Length: 3:51:36.549 (h:m:s.ms)
Size: 98,182,275,072 bytes
Total Bitrate: 56.52 Mbps

(*) Indicates included stream hidden by this playlist.

VIDEO:

Codec Bitrate Description
----- ------- -----------
MPEG-H HEVC Video 47387 kbps 2160p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 4000nits / HDR10 / BT.2020
* MPEG-H HEVC Video 2101 kbps (4.25%) 1080p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 4000nits / Dolby Vision FEL / BT.2020

************

So what is going on here?

*****
Update: confirmed: recreated MKV from the 4K disc (using MAKEMKV) has now 3h51m36s. I am going to do further tests to see if something changes.

MEDIAINFO:
https://pastebin.com/6pMt4ki9

Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

Next tests:

- Check if using MKVToolnix adds a few more seconds to it, and/or change the FPS.

- I am going to add a few audio/subtitle tracks, and also rename the current ones internally.

MAKEMKV log says nothing wrong: https://pastebin.com/hJu80ZBx (ignore the A/V sync issue, it says this for every disc it tries to rip).

*****
Test result: changing the names of the tracks using MKVToolnix didn't mess with anything:

https://pastebin.com/jpGsrKNj

******
Next verification: add new audio/subtitle tracks.

Then once this is also OK, I'll try splitting and appending.

*******
New test also passed, which was adding new audio and subtitle tracks: https://pastebin.com/ucYccVVe

Again no change. Same fps, same 3h51m36s.

FINAL TEST GOING NEXT: splitting into 15300M parts and then appending. If this final test fails, then it's MKVToolnix's fault.

[Thunderbolt8]

Originally Posted by Mosu

The server has more than enough space, and upload resuming is supported. Thanks.

done.

btw. my TV has trouble playing the file. it can be started, but then playback stops around 4mins.

[Mosu]

Originally Posted by Thunderbolt8

I encountered a problem when muxing a HEVC HDR & EAC3 video file. basically the process stopped at 35% and said "failed".

I haven't looked at your particular file yet, but I've fixed a rather serious bug in the HEVC code yesterday, and the symptoms you describe match what I was seeing in another issue. Can you please give latest continuous build a try? It contains said fix.

[Perenista]

I did everything again and didn't notice anything wrong with the audio sync. Looks like something wrong in the first attempt, or the rip failed somehow. So no bug from MKVToolnix. No problems splitting and then appending all 6 parts.

Yet I noticed something interesting:



This is the file BEFORE I split anything:

https://pastebin.com/NMHFEsE4

Then I asked MKVToolnix to split into 15300M parts.

Part 1: https://pastebin.com/zM91VSkE
Part 2: https://pastebin.com/nzjt9LjE
Part 3: https://pastebin.com/iipEjchr
Part 4: https://pastebin.com/xkjeKAc6
Part 5: https://pastebin.com/fFWUKD2e
Part 6: https://pastebin.com/dx3Gy7Ri

As you can see all of them have the same information:

Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

****
Now look what happens when files 1-2-3-4-5-6 are APPENDED:

https://pastebin.com/n4FfXuVG

Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS

What does that mean?

Also, as the first picture shows, the file when I didn't split was shorter. It had:



Now look what MPC says about the appended file:



And this is also reflected in the 6 splitted files. Because if we add 36+38+38+40+41+36 minutes, plus 161 seconds, that will result in 229 minutes, plus another 2 (120 seconds) = 231, then 41s = 231 minutes and 41 seconds. Or 3h51m41s.

I tried freezing the same frame/scene in all three. These two are both the same:

1080p small file:
01:35:01.167

4K file that had never been splitted.
01:35:01.167

The appended file is different. That same frame/scene is located at:

4K appended
01:35:01.641

Still, the 4K file has no signs of sync issues. So, we can all conclude it is the same content, and the length is different because the fps is different.

But... why is MKVToolnix doing this?

[Mosu]

Hello again,

unfortunately the release I've done only four days ago contains a nasty bug in the HEVC/H.265 code, and people are hitting it in droves. Therefore I'm releasing a fix for that today.

Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code.

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

Version 56.1.0 "My Friend" 2021-04-09
New features and enhancements

• mkvmerge: AAC: added support for LOAS/LATM files with channel configuration indexes 9–21 (e.g. channel count 22.2 for index 13) according to Rec. ITU-R BS.1196-7 & ISO/IEC 23008-3:2019. Fixes #3081.

Bug fixes

• mkvmerge: HEVC/H.265 parser: fixed invalid memory access that could happen when reading certain types of HEVC data (e.g. with changing parameter sets mid-stream) from certain containers (e.g. Matroska). This bug was introduced in release 56.0.0. Fixes #3083.
• mkvextract: AAC: mkvextract will now abort with an useful error message when the user tries to extract a track whose 'audio-specific config' element in "CodecPrivate" signals a number of channels of 7 or greater than 8 as that isn't supported by the ADTS format.

Build system changes

• configure: the "--enable-ubsan" option hasn't actually enabled anything since release 39.0.0.

Have fun