MKVToolNix v24.0.0 released

[sneaker_ger]

What will happen if we want to split such files? Will we see corruptions (as to missing I-frames) at the end of a file?

[foxyshadis]

Originally Posted by sneaker_ger

What will happen if we want to split such files? Will we see corruptions (as to missing I-frames) at the end of a file?

Only in the very last frames of the open gop, if any reference the I. Going forward, nothing should because the x264 open-gop patch clears the ref list at each gop, so no corruption is possible. (However, you've always been able to set the gop to infinity and use i-frames only for scenecuts, where later frames can reference pre-I frames.) mkvmerge won't enforce an IDR (closed GOP) split.

Mosu: Concerning the discussion above, I appreciate anything enforcing higher efficiency, even if it's only a few bytes!

[Mosu]

Originally Posted by foxyshadis

mkvmerge won't enforce an IDR (closed GOP) split.

That's correct. mkvmerge doesn't distinguish between IDR-type key frames and non IDR-type keyframes outside of the MPEG4 p10 handling code. And the splitting code is a layer or two above that code.

Modifying this to pass extra information up to that layer (e.g. "splitting possible before this frame?") would not be that hard, but I won't spend more time on this until it's been officially accepted into x264. Other things to do as well

[Egh]

Hello Mosu,

in your most recent build, i.e. 265, there's quite a strange error.

I cannot add AC3s to the project in mkvmerge GUI cause mkvmerge crashes

http://imgur.com/qpnom.png

mkvmerge.exe itself crashes @ 001e4a8e but I guess that is not much useful

[Mosu]

Can you please upload the first 20mb of the file to my FTP server?

[Egh]

Originally Posted by Mosu

Can you please upload the first 20mb of the file to my FTP server?

That has been done. Not all files have this problem however I reckon a specific type of them does. I.e. I have found several files with such problem and uploaded the smallest of them. I think 448kbps 2_0 are broken (maybe some other types as well)

[Mosu]

Originally Posted by Egh

That has been done. Not all files have this problem however I reckon a specific type of them does. I.e. I have found several files with such problem and uploaded the smallest of them. I think 448kbps 2_0 are broken (maybe some other types as well)

Thanks. I'm not at home for a couple of days and will not be able to take a look at it before next weekend though.

[Egh]

Update: didn't test extensively but I was able to replicate it even with 264 build mkvmerge.exe

I finally got rid of the problem by only replacing the exe file with the one from 3.4.0.0. So the problem is limited with mkvmerge.exe file.

Worse news -- it is a generic error it seems, so any track can potentially crash it, I was able to get a crash on h264 stream, for instance.

[Mosu]

The problem is not a generic problem. mkvmerge v4.0.0 just received a lot of updates in almost every part of its code, and that's why you may see such issues in multiple cases.

I've fixed the issue for the AC3 detection code in build 269. I haven't been able to reproduce the issue with h264 tracks though. Could you please upload the first 40 MB of that h264 that causes your crash?

[Egh]

Originally Posted by Mosu

I haven't been able to reproduce the issue with h264 tracks though. Could you please upload the first 40 MB of that h264 that causes your crash?

No problem, uploading 50mb segment. It crashes 265 build mkvmerge in the same way as AC3 did (obviously the whole file crashes it as well)

However it seems to be fixed in 269 build, both AC3 and h264 now seem to work.

[Mosu]

Originally Posted by Egh

No problem, uploading 50mb segment. It crashes 265 build mkvmerge in the same way as AC3 did (obviously the whole file crashes it as well)

However it seems to be fixed in 269 build, both AC3 and h264 now seem to work.

That makes sense. The bug was in the AC3 detection code, and the AC3 detection is run before the h264 detection. So thanks for the upload, and I'll test it myself, but I don't think that there's another bug in the h264 code.

[moviefan]

Originally Posted by Mosu

I just created an open GOP file with a patched x264 v1564. mkvmerge v4.0.0 can handle the file just fine without any further modification. Like I said mkvmerge already treats the first non IDR slice after a SEI NALU as a key frame from the container's point of view. So I guess this just works.

Indeed you're right. I seem to have patched with a corrupt open-gop patch which caused the issue. Now it works. Thanks for checking the open-gop support, too.

[jasonwc]

I found a minor regression after switching from Mkvmerge 3.4 to 4.0. With 3.4, a subtitle's description and language showed correctly in MPC-HC using the internal Matroska splitter. With 4.0, subtitles display as Unknown (English) even though there is a description. I also noticed a difference in Mediainfo output:

Mkvmerge 3.4:

Text
ID : 5
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : English
Language : English

Mkvmerge 4.0:

Text
ID : 5
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : English

I used identical settings to mux both. The former shows up as English (English) and the latter Unknown (English) in recent SVN builds of MPC-HC. I can post a sample file if necessary, but this issue is easily reproduced.

EDIT: Sorry, I went back a few pages and saw that this is not in fact a bug of Mkvmerge. I'll move my request to the MPC-HC thread.

[Mosu]

Here's a build that can read PGS/SUP files directly (mkvmerge could already handle PGS subs in Matroska files): http://www.bunkus.org/videotools/mkv...-270-setup.exe

[dbone1026]

Originally Posted by Mosu

Here's a build that can read PGS/SUP files directly (mkvmerge could already handle PGS subs in Matroska files): http://www.bunkus.org/videotools/mkv...-270-setup.exe

Thanks Mosu, I have just confirmed that PGS subtitles worked perfectly with the new build

[SamuriHL]

Originally Posted by dbone1026

thanks mosu, i have just confirmed that pgs subtitles worked perfectly with the new build

sweet!!!!!!

[SamuriHL]

Hey quick question. So I have a bunch of MKV's I've done with MKVMerge already and I had the subs in another folder. I used the original MKV as the source for MKVMerge and added the subs, but, I lost the embedded chapters. Am I doing something wrong?

[Mosu]

Not enough details. Usually mkvmerge copies the chapters unless you tell it not to (e.g. by disabling chapters in mmg or with command line options).

[SeeMoreDigital]

With reference to this post...

I've generated a couple of "PGS" test muxes with the new build and although VLC player v1.1.0 RC is able to detect the PGS subtitle stream (as before), it can't display it (unlike before).


Cheers

[SamuriHL]

Originally Posted by Mosu

Not enough details. Usually mkvmerge copies the chapters unless you tell it not to (e.g. by disabling chapters in mmg or with command line options).

When I created my original MKV with mkvmerge 4.0.0, I added my video and DTS-HD MA tracks, and then went to the global tab and loaded a chapter file. The streams I used were all extracted using EAC3to. If I look at the original with media info, I see the chapter info at the bottom of the page. I now load that MKV into the mkvmerge GUI as the source. It sees the video and audio tracks, but, I don't see the chapters anywhere. When I output it, the chapters are lost in the output. I guess I can extract the chapter.txt file from the original and add it to the global tab, but, I was just wondering if I was missing something. You said it should copy the chapters, but, in this case it doesn't seem to be doing so. Didn't know if I did something wrong.