MKVToolNix v24.0.0 released

[Mosu]

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]

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/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.0.0-build20100618-270-setup.exe

[dbone1026]

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/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.0.0-build20100618-270-setup.exe

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

[SamuriHL]

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 (http://forum.doom9.org/showthread.php?p=1409364#post1409364)...

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]

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.

[Mosu]

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).

Try to disable compression for the subtitle track. Maybe your copy of VLC has problems with default values. For example:

mkvmerge -o out.mkv --compression -1:none in.mkv

Or use mmg and disable compression for all PGS tracks.

[Mosu]

You said it should copy the chapters, but, in this case it doesn't seem to be doing so.

Try to run "mkvmerge --identify-verbose in.mkv" on one of your original file (the one for which you do see the chapters). Post the result here.

Please also run "mkvinfo -v -v -z in.mkv --redirect-output in.txt" and upload the in.txt file to my FTP server (compressing it first with 7zip/RAR/ZIP/LZMA is fine).

[SeeMoreDigital]

Try to disable compression for the subtitle track. Maybe your copy of VLC has problems with default values. For example:

mkvmerge -o out.mkv --compression -1:none in.mkv

Or use mmg and disable compression for all PGS tracks.Okay...will do.

I think this is what Sami is referring too: -

Old build
http://img138.imageshack.us/img138/6609/previousbuild.png

New build
http://img3.imageshack.us/img3/5778/newbuild.png

Cheers

[SamuriHL]

Try to run "mkvmerge --identify-verbose in.mkv" on one of your original file (the one for which you do see the chapters). Post the result here.

Please also run "mkvinfo -v -v -z in.mkv --redirect-output in.txt" and upload the in.txt file to my FTP server (compressing it first with 7zip/RAR/ZIP/LZMA is fine).

Sure thing. Give me a few minutes as I'm in the middle of another encode but I will get to you asap. Thanks!!

[SamuriHL]

Yes, that's right. That's exactly what I'm saying. I was able to extract them using MKVCleaver and re-added them. Just curious as to why it wasn't detected. That's all.

[Mosu]

Definitely a bug that I haven't been able to reproduce yet. How big is such a file? Could one of you upload such a file to my FTP server? I don't have any disc to make my own file with MakeMKV.

[SeeMoreDigital]

Try to disable compression for the subtitle track. Maybe your copy of VLC has problems with default values. For example:

mkvmerge -o out.mkv --compression -1:none in.mkv

Or use mmg and disable compression for all PGS tracks.Nice one...

With "Compression" set to "None", the PGS subtitles are now displayed okay in VLC player v1.1.0 RC

Thanks Mosu

[SeeMoreDigital]

Definitely a bug that I haven't been able to reproduce yet. How big is such a file? Could one of you upload such a file to my FTP server? I don't have any disc to make my own file with MakeMKV.The "MakeMKV" sample can be found here: http://forum.doom9.org/showpost.php?p=1409335&postcount=1908

[Mosu]

With "Compression" set to "None", the PGS subtitles are now displayed okay in VLC player v1.1.0 RC

Please complain to the VLC developers that they should fix their handling of default values. In this particular case the default value they don't seem to use is the value '0' for the ContentCompAlgo element -- see http://www.matroska.org/technical/specs/index.html for details.

[SamuriHL]

Yea, my "samples" are in the neighborhood of 25 gigs so... :D

P.S. Mine happened with a mkvmerge created MKV just as an FYI.

[SeeMoreDigital]

Okay, will do. Thanks Mosu ;)

[SamuriHL]

Mosu, do you still need me to upload anything? I would think that now that you have a sample you could repro the issue? If not, I can still upload what you requested.

[SamuriHL]

Um, hmm. I just noticed something. I'm working on a TrueHD track right now. It says that it's using pass through for that. When I do DTS-HD MA tracks, it says it's doing DTS output module. Is it possible this DTS output module is causing problems with the DTS-HD MA track? Is there a way to just do "pass through" on DTS-HD MA tracks? The reason I ask is that TrueHD tracks output with mkvmerge work fine with Haali. DTS-HD MA tracks don't. I know you don't have time to look into that problem and feel it's a Haali issue...while I agree, I'm just wondering what the DTS output module does.

[Mosu]

Thanks for noticing. The chapter problem has been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.0.0-build20100618-272-setup.exe

[Mosu]

Is it possible this DTS output module is causing problems with the DTS-HD MA track?

No.

Is there a way to just do "pass through" on DTS-HD MA tracks?

No.

The reason I ask is that TrueHD tracks output with mkvmerge work fine with Haali. DTS-HD MA tracks don't.

Bug Haali with it.

I'm just wondering what the DTS output module does.

The same all the other output modules do: they analyze the bitstream, throw out non-spec compliant stuff, assign timecodes etc.

[SamuriHL]

That fixed the chapter issue. Thanks for the quick turnaround on that!!

[SamuriHL]

No.



No.



Bug Haali with it.



The same all the other output modules do: they analyze the bitstream, throw out non-spec compliant stuff, assign timecodes etc.

Ok. Thanks!

[bwhinnen]

Hi Guys,

I'm trying to track down an issue I have with DTS-MA in mkv files created by mkvmerge. If I use a tool such as MakeMKV to create my original (uncompressed version) of the BD movie into an MKV they play fine. If I then use some compression method to compress the video down from the original size to something a little smaller and use mkvmerge to create a new mkv from the original DTS-MA audio, subtitles and the newly compressed video I get playback issues.

The issues only seem to be when actually using HD bitstream passthrough to my AVR. Audio plays fine, but the video lags. Where as the original mkv from MakeMKV will play the file fine.

I'm using Haali to split the mkv, MS codecs to play the video side, and FFDShow x64 to play the audio and send directly to via HDMI to the AVR.

Windows 7 x64 Ultimate (all current patches)
Intel H55 chipset (GA-H55M-S2H) with current BIOS
Intel i530 CPU
All latest drivers
Shark-007 codec pack for both Win 7 and x64 components (2.53 and 2.57 respectively).
AVR is a Onkyo TX SR-706
Connection is a HDMI

This works fine with mkv's from MakeMKV which just copies the streams out, and a output from RipBot, where the audio is converted to AC-3 into mkv also works fine, but when using mkvmerge (from versions 3.2 to 4.0 on Windows) and using the original DTS-MA track from MakeMKV and the new Video track from RipBot I get the issue in playback. Opening Haali and watching the bitrate I can see Audio just steaming through, but Video is pretty much non-existent. Dolby True-HD done in the same manner works perfectly.

Thanks for any pointers, it is really frustrating me as I'd like to be able to shrink my BD collection down a bit to conserve a bit of space, specially Avatar which is 37GB for the raw mkv compared to 15GB for a shrunk one with DTS-MA.

Thanks,

Brett

[SamuriHL]

Yes, Mosu says it's a problem with Haali. I've reported it in the Haali thread. For now you can play them back in MPC-HC using the MPC internal splitter.

[rica]

Yes, Mosu says it's a problem with Haali. I've reported it in the Haali thread. For now you can play them back in MPC-HC using the MPC internal splitter.

And/or with Solveig...

[SledgeHammer_999]

Can I put two feature requests here?

1. Make mkvinfo output xml instead of the current format (add it as an command line option)
2. Make mkvinfo put an "Attachment number" to attachments like it does for tracks("Track number:").

The first one will make it easier to parse the output and grab certain values(using a good xml library).
The second one can be used in combination with the first one and later used with mkvextract. I know that I should use mkvmerge --identify, but I want to make decisions(my program) based on some additional info.
Also with xml output, I think more applications will be able to easier intergrate mkvtoolnix.
I hope it isn't much trouble. Thanks.

[Mosu]

I might implement the first option.

I won't implement the second one though because mkvmerge can already get you that information if you run "mkvmerge --identify-verbose yourfile.mkv" -- just like you said. The track/attachment numbers are the same that mkvextract expects. mkvinfo's "Track number" output is actually NOT the track number that mkvextract expects. It's just the EBML/Matroska element "TrackNumber". mkvextract and mkvmerge assign "track IDs" in a different way.

What exactly do you mean with "integrating mkvtoolnix"? If you want the applications to make decisions how to run mkvmerge/mkvextract based on the content of a Matroska file you're most likely out of luck due to the discrepency in track numbers/track IDs that I described above. Also note that mkvmerge's "--identify-verbose" outputs more information than a simple "--identify". "--identify-verbose" is what mmg uses when you add a file (actually it's "--identify-for-mmg", but the only difference to "--identify-verbose" is that the output of "--identify-for-mmg" is always in English safe for error/warning messages and the output of "--identify-verbose" is fully localized). It gets you information about the container (e.g. type), tracks (e.g. language, codec type, track type, default track flag...), attachments (name, MIME type, size), chapters and tags.

[SledgeHammer_999]

Yes, --identify-verbose and --identify-for-mmg is what I am looking for. (maybe xml those too?). You should include those into the man pages.

[Mosu]

Yes, --identify-verbose and --identify-for-mmg is what I am looking for. (maybe xml those too?).

No. They're dead easy to parse as they are. One line per item. Normal information first. Extended information between [ and ]. Extended information consists of space-separated key:value pairs. Special characters are escape: '\' maps to '\\', '"' to '\2', ' ' to '\s' and ':' to '\c'.

You should include those into the man pages.

Patches are welcome. Meaning I rather spend my time on other things.

[chipzoller]

I've got a strange problem that I don't believe is mkvtoolnix's fault; it is probably something wrong with my system but I don't know where to start. For whatever reason, when I encode mkvs at the correct resized resolution for my needs, then add them to be muxed in with audio, subs, etc., it always incorrectly detects the video stream's display width/height as 144 x 79--regardless of what the actual resolution I feed it. It could be 640 x 480 or 872 x 368--it still detects this as 144 x 79. I've un/reinstalled 4.0 a couple times and checked a few others including video drivers. I don't know what has caused this, but this never used to happen until fairly recently. What could be a possible explanation for this? How does mkvtoolnix derive the display resolution integers?

[Mosu]

mkvmerge calculates the display resolution either from the source container (e.g. if you're adding a Matroska file) or directly from the bitstream (e.g. if you're adding raw h.264 files). Raw h264 files contain the pixel width/height and the pixel aspect ratio in its headers. From those values mkvmerge calculates the display width/display height. Those values should not be 144x79 at all -- they're normally larger than the pixel resolution.

Can you give me more information about the video files you're adding to mmg/mkvmerge?

[chipzoller]

Generally, these are mkv video streams (x264) produced with MeGUI and are all SD resolutions. There is nothing special in the scripts producing them; only crop, resize, and occasional denoising. I verified that the encoded frame size set in the script is correct in the resulting file, but regardless of that resolution when dropping into mkvmerge it always sets these display values. Also, whenever I use the automated muxer in MeGUI (mkv), it also outputs a file with incorrect display settings.

[LeMoi]

mkvtoolnix actually displays the aspect ratio, not the display resolution.
If your video is 640x480, mkvtoolnix will show 4x3 instead of 640x480. Don't worry, your file will be played without any problem

[chipzoller]

Yes, I understand that, but as I mentioned, it doesn't matter what the resolution of the input file is, it will always set 144 x 79. The only way I can fix this is to put the display size the same as the frame size.

[LeMoi]

What is your initial output extension in MeGUI? MP4, AVI, MKV?

[chipzoller]

MKV always

[Mosu]

LeMoi: That's incorrect. mkvmerge will display the "display resolution". The values it display MAY come from a Matroska file whose "display width/height" values are set to "4/3" or similar small values, but if mkvmerge calculates the dimensions itself (e.g. for raw h264 files) then it will calculate the display resolution and not just the aspect ratio.

chipzoller: Look at the file MeGui created with mkvinfo's GUI and look for the "display width" and "display height" paramters of the video track. What do they contain?

[chipzoller]

In 3 cases it does show 144 x 79 but the pixel values are correct. Wonder what has happened to cause this in MeGui? The scripts are simple and encoder settings are basic crf and tune film.

[Mosu]

I've never used MeGui and have no clue as to what the problem might be. You should ask in a MeGui thread.

[Selur]

little feature request:
Would be cool if one could 'extract' a part of a mkv by defining start- and endtimecode (or start-position in seconds and end-position in seconds).
something like:
-extract TID:timecodes:00:30:00.000:00:39:09.000

I know one could abuse the '--split timecodes:A[,B[,C...]] ' option to do something similar, but if I understand it right this would always create three parts (part before the section, the section and the part behind the section), which is kind of a bummer when handling larger files and only wanting a few minutes,...

Cu Selur

Ps.: I also know I could use mencoder or ffmpeg to do this, but it would be nice to be able to do it with mkvmerge.

[LeMoi]

Afaik atm it's only possible to specify on which timecodes a new files should be created, which would result in three output files instead of one when trying to extract a stream from timecode X to timecode Y;
-> Is there already a way to call mkvmerge just create one file and extract just a portion of a stream?
if not: Would be nice if this could be added as a feature in an upcoming version.

No, it's not possible. I know it would be a nice feature to have, but I won't spend any time on that at the moment or in the near future. Patches are always welcome -- I'm not against such a feature, it just won't be me who'll implement it any time soon.
I think you just asked him some days ago, and he answered immediately ;)

[Selur]

LOL, wasn't sure if I asked and couldn't find it. ;)

[LeXXuz]

Recently updated from 3.2 to 4.0.

Have there been any changes to the vobsub muxer lately? With 4.0 my media players do not display vobsubs in 1080p anymore. Tracks get recognized, but no subpictures shown.
PC playback still works as usual.

However, same files muxed with 3.2 and everything works fine.

[Snowknight26]

Any chance of having the muxing status form start in the center of its parent instead of the center of the screen?

[Mosu]

Hey,

I've released mkvtoolnix v4.1.0. This release features a couple of bug fixes and enhancements especially in combination with WebM and full support for PGS/SUP subtitles. There's a new translation of the programs into Spanish and of the manual pages into Dutch. The Russian translation has received a huge update.

There are a couple of changes for package maintainers:

1. the new translations I've mentioned,

2. new .desktop and .xml files for menu and MIME type integration (installed into $datadir/applications and $datadir/mime/packages respectively; they're only installed if the GUIs are activated)

3. icons for the GUI applications (installed into $datadir/icons/hicolor/<size>; they're only installed if the GUIs are activated)

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-4.1.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.1.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.1.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.0.0:

------------------------------------------------------------
2010-07-01 Moritz Bunkus <moritz@bunkus.org>
* Released v4.1.0.

2010-06-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading AVC/h.264 tracks from AVI files if they're stored in NALUs inside the AVI.

2010-06-26 Moritz Bunkus <moritz@bunkus.org>
* Build system: enhancement: Improved the error reporting if certain Boost libraries are not found.

2010-06-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge will report if it finds data errors in a Matroska file (e.g. due to storage failure or bad downloads). The position is reported as well as a periodic update as long as mkvmerge re-syncs to the next Matroska element.
* mmg: enhancement: The "compression" drop down box is enabled for all track types. That way "no compression" can be forced for those tracks mkvmerge uses "header removal" compression for.

2010-06-23 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Matroska files read from/written to by the header and chapter editors will no longer be kept opened and locked. Fix for bug 498.
* mmg: bug fix: If mmg was called with "--edit-headers filename.mkv" then it crashed when the header editor was closed.

2010-06-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge will start a new cluster before a key frame of the first video track. Fix for bug 500/
* mkvmerge: enhancement: The default cluster length has been increased to five seconds (up from two seconds).

2010-06-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge will no longer report nonsensical progress reports (e.g. -17239182%) when reading Matroska files with all the flags "--no-audio --no-video --no-subtitles" enabled. Fix for bug 505.
* mmg: bug fix: Fixed a crash in the job runner when the total time was very big due to a division by zero.
* mkvmerge: enhancement: Implemented write caching resulting in faster muxes especially on Windows writing to network shares.

2010-06-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading PGS subtitles from PGS/SUP files.
* mkvmerge: bug fix: Specifying an FPS with "--default-duration" for AVC/h264 tracks in AVI files did not work. Fix for bug 492.

2010-06-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an invalid memory access possibly causing a crash in the AC3 detection code.

2010-06-14 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Changing mmg's interface language did not change the entries in the "command line options" dialog if that dialog had been opened prior to the language change.

2010-06-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge uses header removal compression by default for AC3, DTS, MP3, Dirac and MPEG-4 part 2 tracks.
* all: Added desktop files for mmg/mkvinfo, a MIME type file for .mmg files and icons to the installation procedure on Linux. Most files were contributed by Cristian Morales Vega (see AUTHORS).
* all: Added a translation of the programs into Spanish by Isra Lucas (see AUTHORS).

2010-06-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed access to uninitialized memory when reading DTS tracks from AVI and Matroska files.

2010-06-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The Matroska reader will use the MPEG audio packetizer for MP2 tracks instead of the passthrough packetizer.
* mkvmerge: bug fix: The Matroska reader did not handle compressed tracks correctly if the passthrough packetizer was used.

2010-06-08 Moritz Bunkus <moritz@bunkus.org>
* docs: Added a Dutch translation for the man pages by René Maassen (see AUTHORS).

2010-06-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The handling of Matroska files in which the 'default track flag' is not present has been fixed.
------------------------------------------------------------

Have fun.