MKVToolNix v24.0.0 released

[sneaker_ger]

Tested it on a TV capture with lots of packet loss: frames are dropped correctly, A/V sync is kept. This is already looking very good for a test version.

[Mosu]

Muxing this sample will result in an mp3 track in addition to the ac3 track:

Here's an updated build that ignores such tracks: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110917-362-setup.exe

I actually have another such a file like yours now works well now with the new build; with the old one I still have to exclude that track manually.

Thanks for the subtitle sample. Will work on it on over the weekend.

I'm off to bed now. Have fun testing everyone ;)

[Mosu]

Aaah don't use that build. It will skip valid tracks as well, e.g. VC1 and TrueHD ones. Will fix it properly tomorrow. I've removed the 362 build.

[nevcairiel]

How will it deal with TrueHD/AC3 interleaved tracks from Blu-ray m2ts files?
I kinda hope it will remove the interleaved AC3 frames, or split it into two tracks.

[Mosu]

As this questions comes up from time to time I decided to write a FAQ entry (http://www.bunkus.org/videotools/mkvtoolnix/faq.html#truehd_with_ac3) for it (just now, so don't think you've overlooked something if you had looked at the FAQ earlier).

[Mosu]

Muxing this sample will result in an mp3 track in addition to the ac3 track:

Here's a build that will only report (via "--identify") or mux tracks that it can actually find data for in the file (well, within the probing limit). Unlike the previously pulled build this one doesn't discard VC1 and TrueHD tracks by mistake.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110918-363-setup.exe

Off to bed now; upload is still running though. Should be done in a minute or two.

[Mosu]

Yet another build, this time with support for HDMV PGS subtitles, DTS HD master audio and a couple of bug fixes: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110918-364-setup.exe

Thanks for the samples.

[lovelove]

'D:\title08_track2.flac': Using the FLAC demultiplexer.
+-> Parsing the FLAC file. This can take a LONG time.
+-> Pre-parsing FLAC file: 0%
+-> Pre-parsing FLAC file: 5%

Why do FLAC files have to be pre-parsed contrary to ALL other input formats?

[Mosu]

Back when I implemented FLAC support I didn't want to write all the file code parsing myself. So I relied on libFLAC to do the file parsing for me. Unfortunately libFLAC uses a callback-based system that's fundamentally incompatible with how mkvmerge's main muxing process works. Therefore all the processing with libFLAC is done before muxing starts, the required information recorded and then re-used during muxing without any calls to libFLAC.

I never bothered to re-write that code to not relying on libFLAC 'cause I don't think it's that important (with "important" being determined by the number of people annoyed by it (unknown, probably low) times the actual impediment (very low, it simply takes a bit longer)).

[nautilus7]

Maybe people weren't annoyed because they didn't know why it was hapening. Now that I know that it can be bypassed / replaced by a better or faster algorithm, I am annoyed. :P

[robpdotcom]

I'd be annoyed if it really did take a long time. But since it actually happens very quickly, I have no problem with it.

[Mosu]

Well, I'm always open to patches ;)

[Thunderbolt8]

Yet another build, this time with support for HDMV PGS subtitles, DTS HD master audio and a couple of bug fixes: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110918-364-setup.exein what cases are the changes to dtsma audio relevant?
do I have to redo all my .mkv remuxes?

[SamuriHL]

@Mosu

Stupid question. Is there any chance that you'll add support for adding an MPLS file so that for seamless branching titles you can join all the separate m2ts files into a single MKV? Of course, I'm also assuming it doesn't do that before I even try it, but, I haven't seen any mention of this functionality hence why I ask. Thanks!

[Mosu]

in what cases are the changes to dtsma audio relevant?
do I have to redo all my .mkv remuxes?

Check your audio tracks. If they are considerably shorter than the video track (my problematic file resulted in the audio track being half as long as the video track -- but only regarding the timecodes; all the actual content was there) then you have to re-mux.

It also only concerns DTS-HD MA read from TS streams. As both the support for DTS-HD MA and the corresponding fix to the timecode handling were both introduced between builds 363 and 364 I highly doubt that you'd be affected.

[Mosu]

@Mosu

Stupid question. Is there any chance that you'll add support for adding an MPLS file so that for seamless branching titles you can join all the separate m2ts files into a single MKV? Of course, I'm also assuming it doesn't do that before I even try it, but, I haven't seen any mention of this functionality hence why I ask. Thanks!

It's not supported yet, true, but that would indeed be a nice feature to have. Any way I can get my hands on sample files or create them myself (e.g. split a m2ts I have into multiple ones and create such a file)? I don't know a lot about MPLS in the first place, so any hint would be appreciated.

[SamuriHL]

It's not supported yet, true, but that would indeed be a nice feature to have. Any way I can get my hands on sample files or create them myself (e.g. split a m2ts I have into multiple ones and create such a file)? I don't know a lot about MPLS in the first place, so any hint would be appreciated.

No, I don't know of any way to create them. Any seamless branching title will have them though. Sony's been using a java protection that relies on seamless branching so titles like Source Code would be a good one to experiment on. Nev or madshi might have some insight on how to read and parse those files. I think Nev uses the libbluray library. I'm not sure how madshi does it.

[mbcd]

How will it deal with TrueHD/AC3 interleaved tracks from Blu-ray m2ts files?
I kinda hope it will remove the interleaved AC3 frames, or split it into two tracks.
Stupid Question of mine:

What is with DTS? It has also a "core" inside.
Its likely the same as with THD/AC3.

Those are two different formats (DTS/DTS-HD) or am I wrong ?

[nevcairiel]

DTS is different. The DTS core is a vital part of the DTS stream. Both the DTS core and the DTS-HD extensions are required to decode the audio properly.
For TrueHD/AC3, the AC3 frames are only there for backwards compatible reasons, iow. useless. :p

[b66pak]

@mbcd

see the answer on wiki (http://en.wikipedia.org/wiki/DTS-HD_Master_Audio)...

[Video Dude]

Yes, mkvmerge removes the sequence headers and stores the first ones that it finds in the CodecPrivate. Yes, I know that this a problem with changing sequence headers in the middle of the stream, and yes, I plan to change that someday. That being said, I don't spend any time coding mkvtoolnix at the moment, so your guess is as good as mine when mkvmerge will handle such streams correctly.
Mosu, I was taking a look at the source code, would you know which source file(s) refers to this?

[Mosu]

Does that quote refer to MPEG-1/2 video? If so then this problem has long been solved by keeping the sequence headers in the bitstream as well.

[nevcairiel]

I believe it refers to H264.

[Mosu]

Hmm, I don't want to rule that out but I usually don't talk about "sequence headers" when talking about h264; instead I talk about SPS and PPS NALUs. But still... mkvmerge also keeps SPS and PPS NALUs in the bitstream for h264 tracks.

[nevcairiel]

The quote is from 2007, so things might have changed as well. ;)
Looking at the original quote, it did indeed refer to H264, in context of importing raw avc streams.
This was right around the time you disabled the removal of sequence headers for MPEG-1/2

[Mosu]

mkvmerge has been keeping SPS & PPS NALUs in the bistream for over four years now:

commit e88bb1aee5ebdf3cda3dc59817588a6ad8eecb8f
Author: Moritz Bunkus <moritz@bunkus.org>
Date: Wed Aug 15 17:59:22 2007 +0000

Don't remove SPS and PPS NALUs from AVC/h.264 streams.

[nautilus7]

Request about .m2ts re-muxing: When loading xxxxx.m2ts file from blu-ray read track languages from xxxxx.clpi.

[Mosu]

Maybe, not for the next release (time constraints).

What are clpi files (I see that they're stored in the CLIPINF sub-directory)? Where can I get a description about their format or see code that reads them?

[Mosu]

Ah, libbluray has code for parsing them. I'll take a look.

[nautilus7]

Thanks, mosu!

[Mosu]

Alright, that looks mighty easy to parse. I hope I can squeeze it in before the weekend (that's when I plan to release the next version).

[SamuriHL]

Absolutely great work, Mosu. Thank you for your efforts in this area!!

[Mosu]

Here's a build that parses a .clpi file with the same base name as the transport stream file extracting the track languages from it. It will look for this file a) in the same directory, b) in "path\to\source\file\..\CLIPINF" and c) in "path\to\source\file\..\clipinf" (for file systems that don't do case folding).

I only have one test file here (the .m2ts does not contain track language attributes of its own, the .clpi one provides them for all audio tracks), and it Works For Me(tm). Please test & report back. Thanks.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110920-365-setup.exe (upload should be done in a minute or two)

[lovelove]

Back when I implemented FLAC support I didn't want to write all the file code parsing myself. So I relied on libFLAC [...]

many thanks for the explanation, Mosu!

Maybe people weren't annoyed because they didn't know why it was hapening. Now that I know that it can be bypassed / replaced by a better or faster algorithm, I am annoyed. :P

big fat LOL :D

[Kurtnoise]

Thanks Mosu,

Here's a build that parses a .clpi file with the same base name as the transport stream file extracting the track languages from it. It will look for this file a) in the same directory, b) in "path\to\source\file\..\CLIPINF" and c) in "path\to\source\file\..\clipinf" (for file systems that don't do case folding).
what about m2ts file in \BDMV\STREAM\ folder and clpi in \BDMV\CLIPINF\ ?

the BD structure looks like this : http://www.videohelp.com/hd

[nevcairiel]

what about m2ts file in \BDMV\STREAM\ folder and clpi in \BDMV\CLIPINF\ ?

Didn't he explain that? :p

It'll look in "..\CLIPINF", so if the m2ts is in BDMV\STREAM, it'll look in "BDMV\STREAM\..\CLIPINF", which is just "BDMV\CLIPINF" - fully supporting BD structures. ;)

[Kurtnoise]

well...languages tracks detection doesn't work here then.

[Mosu]

well...languages tracks detection doesn't work here then.

Can you upload sample files, please? I need the clpi file (shouldn't be too big) and roughly 30 MB of the m2ts file. It would be extra cool if you could upload a ZIP file with the same folder structure as the one your files are in. Thanks.

[sneaker_ger]

A few random things:

1.) Currently the writing app info written to the file is localized, I think it should always be English.
2.) mkvinfo always seems to complain that "there is more than one track with the id x". Isn't this a false alarm?
3.) It seems that you've already implemented (more) SPS/PPS reading. Would it be possible to use the timing info from H.264 ES instead of defaulting to 25 fps/displaying a warning in mmg? (or is that (https://github.com/mbunkus/mkvtoolnix/commit/78a27c7ee0825b6d6bf686d458e89b0e925c9d59) for writing?)
That warning still pop ups in mmg, even if you load a timecode file, btw.

[Mosu]

A few random things:

1.) Currently the writing app info written to the file is localized, I think it should always be English.

Hmm, indeed. I'll fix that.

2.) mkvinfo always seems to complain that "there is more than one track with the id x". Isn't this a false alarm?

According to the Matroska specs this is an error. Oh wait, this could also happen if the same track headers are written more than once. Hmm... I'll think about it.

3.) It seems that you've already implemented (more) SPS/PPS reading. Would it be possible to use the timing info from H.264 ES instead of defaulting to 25 fps/displaying a warning in mmg? (or is that (https://github.com/mbunkus/mkvtoolnix/commit/78a27c7ee0825b6d6bf686d458e89b0e925c9d59) for writing?)
That warning still pop ups in mmg, even if you load a timecode file, btw.

That is planned, yes.

[sneaker_ger]

According to the Matroska specs this is an error. Oh wait, this could also happen if the same track headers are written more than once. Hmm... I'll think about it.

I don't really understand, just wondered, as it would be displayed for all tracks if mkvmerge or ffmpeg were used. Haali-muxed files don't display the warning.

/edit:
oh, sorry. I think it may be my error, it doesn't depend on the muxer, but me opening the files in mkvinfo one after another without closing. mkvinfo seems to somehow remember the old file. Is this expected?

/edit2:
I don't find anything about this in the mkvinfo docs, so I assume it's a bug? To reproduce just drag&drop a file on the mkvinfo window and then drag&drop the same file again on to it.

[Mosu]

I don't get that warning for files created with mkvmerge. Anyway, I've removed them.

[Mosu]

/edit:
oh, sorry. I think it may be my error, it doesn't depend on the muxer, but me opening the files in mkvinfo one after another without closing. mkvinfo seems to somehow remember the old file. Is this expected?

Ah, good point. Will have to fix that as well; mkvinfo doesn't clean up nicely when it opens a second file (I almost never use its GUI, therefore I seldom catch such issues).

[sneaker_ger]

So, that basically means that this change (https://github.com/mbunkus/mkvtoolnix/commit/52fafe5c08da9f537d38bd1788b9333c9ea16239) was unnecessary, right? Sorry 'bout that, I hope it wasn't too much work.

[svcdprayer]

hello! im wondering does mkvmerge supports smi?

thanks!

[Mosu]

So, that basically means that this change (https://github.com/mbunkus/mkvtoolnix/commit/52fafe5c08da9f537d38bd1788b9333c9ea16239) was unnecessary, right? Sorry 'bout that, I hope it wasn't too much work.

No. That warning could also have been output if a second copy of the track headers was found (e.g. AVIMux GUI writes such files, Haali can, too, if I'm not mistaken). That is legal and should not issue warnings.

[Mosu]

hello! im wondering does mkvmerge supports smi?

No, it does not.

[nautilus7]

Language detection doesn't work here either no matter where the clpi file is located. Sample on your ftp.

[Mosu]

Alright, found the issue & fixed it in build 367 (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110921-367-setup.exe).

[nautilus7]

Working now. Thanks!