MKVToolNix v24.0.0 released

[Mosu]

That's reassuring. Thanks for the feedback. Will continue to monitor all my usual communication channels for reports about similar problems, of course.

[Selur]

don't use VLC, but here what I tried:
remuxed avc + dts 5.1 with mkvmerge 6.4.0 -> got sound with MPC-HC
remuxed avc + ac3 5.1 with mkvmerge 6.4.0 -> got sound with MPC-HC
remuxed avc + he-aac 5.1 with mkvmerge 6.4.0 -> got sound with MPC-HC
remuxed avc + aac lc 5.1 with mkvmerge 6.4.0 -> got sound with MPC-HC

-> doesn't seem to be a general problem with mkvmerge

[john33]

Hmmm, strange. I did a clean re-install of 6.4.0 and the problem persists, but I'll try on another system and report back.

[john33]

Well, I've tested on another, but similarly configured, system and 6.4.0 muxes using aac and ac3 all fail to play the audio whereas 6.3.0 muxes all play fine! It's not an issue I've ever had before but it would seem that there is some peculiarity with my systems since others don't appear to have the problem. I'll stick with 6.3.0 for the time being and see if I can ascertain the problem when I have the time (and the inclination! ;) ).

[Mosu]

Might be good if you could upload an example: both source files (audio & video) plus the failing Matroska file created with 6.4.0.

[john33]

I'll have to create clips and check that they fail otherwise I'm looking at about a 10GB upload!

[john33]

Well, at least it's consistent and fails on all files, not just the first one I tried. ;) Another mux just tried, the output using 6.4.0 was 428,074,207 bytes and using 6.3.0 was 428,068,653 bytes. Would you expect a difference in file size from identical inputs?

[Mosu]

Yes -- depending on the track types involved.

BTW: if you want to produce a small file then tell mkvmerge to split by ranges and only include the first 30 seconds or so.

[john33]

OK, uploaded 30secs of an mkv - two versions, one muxed with 6.3.0 which plays normally and the other muxed with 6.4.0 which plays without audio. Which is which is obvious from the file names. Both were created from the same sources. If you need any more from me, just ask. ;)

[Mosu]

Very disturbing. Your 6.4.0 file contains track headers for the AAC track, but not a single data packet. Hence the size difference.

More interesting is that I cannot reproduce the issue so far. Therefore I'll have to ask you for the AAC file in question... If it's a raw .aac file (instead of e.g an .mp4 or .m4a) then you can simply stop uploading after a couple of MBs. With .mp4 or .m4a I'll need the whole file because those files often have important file structure information (headers, indexes...) located at the end. Not always, but sometimes.

[john33]

4mb of raw aac file uploaded. :) The aac file was originally transcoded from ac3 with qaac.

[Mosu]

Thanks. Please also paste the mux settings you've used (e.g. in mmg "Muxing -> Copy command line to clipboard").

[john33]

The 6.4.0 settings:

"C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "I:\\MKVs\\john33 (2).mkv" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:720x404" "--default-duration" "0:24000/1001p" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "I:\\MKVs\\john33.mkv" ")" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "I:\\MKVs\\john33_track2.aac" ")" "--track-order" "0:0,1:0"

The 6.3.0 settings (the same, of course):

"C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "I:\\MKVs\\john33 (3).mkv" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:720x404" "--default-duration" "0:24000/1001p" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "I:\\MKVs\\john33.mkv" ")" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "I:\\MKVs\\john33_track2.aac" ")" "--track-order" "0:0,1:0"

[Mosu]

I can finally reproduce some kind of weird issue that's similar but not identical to your issue. However, I strongly think that both have the same underlying reason. Fixing. Once fixed I will probably have to release 6.4.1.

[john33]

Thanks for looking into this. I was quite happy to remain using 6.3.0 but that clearly isn't progress. ;) If you would like me test test anything prior to release, just let me know.

[Mosu]

I'll ask you to test a pre-build with the fix once I've tracked that bugger down -- before I make the next release. Better safe than sorry. Said pre-build should hopefully be done within an hour.

[john33]

Excellent, thanks. I'll check back at intervals. :)

[Mosu]

Here's the build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-6.4.0-build20130916-521-4e2cd32-setup.exe). Thanks for testing.

[john33]

That works. :)

Edit: Tested on several files and all OK now, thanks very much.

[Mosu]

Thanks for the confirmation. Starting the release process.

[john33]

Just to confirm that the release build works fine, too. Many thanks for this. :)

[Mosu]

Hey,

I've released MKVToolNix 6.4.1 only one day after the release of 6.4.0 due to a nasty regression in 6.4.0 compared to 6.3.0. This release fixes that single bug only. For reference I'll include the previous release message including the new ChangeLog entries. Note that only the source and Windows packages have been uploaded yet; the Linux binaries are still being built.

Not a lot has happened over the summer, but the Opus support has been finalized. A couple of bug fixes here and there as well, especially regarding startup problems on Windows (the mmg window not appearing). However, the next release should feature HEVC support, and I didn't want to hold off the release until that's been finished as it may still take a couple of weeks. So here you go.

For package maintainers: you need libMatroska 1.4.1 due to new elements, a version that hasn't been released yet (libEBML requirements stay at the already-released 1.3.0). MKVToolNix' configure will fall back to the included version and build it statically. I'm sorry for this, and this is not intentional but due to severe lack of time on my side these past weeks. I'll try to release said library within the next two or three week. So feel free to hold off packaging this MKVToolNix version until then.

You can download the source code (http://www.bunkus.org/videotools/mkvtoolnix/source.html) or one of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html).

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 6.3.0:

2013-09-16 Moritz Bunkus <moritz@bunkus.org>
* Released v6.4.1.
* mkvmerge: bug fix: fixed packet ordering regression introduced in 6.4.0 if --default-duration is used for a track.

2013-09-15 Moritz Bunkus <moritz@bunkus.org>
* Released v6.4.0.
* mkvextract: new feature: Implemented extraction of Opus tracks into OggOpus files.

2013-09-14 Monty Montgomery <xiphmont@gmail.com>
* mkvinfo: bug fix: The track information summary enabled with -t/--track-info counted bytes in SimpleBlocks twice.

2013-07-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: CueRelativePosition was wrong for BlockGroups: it pointed to the Block inside the group instead of the BlockGroup itself. CueRelativePosition elements for SimpleBlock elements are not affected. Fixes #903 (https://www.bunkus.org/trac/ticket/903).

2013-07-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented final Opus muxing.

2013-07-04 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The "jobs" folder will be created in the same mmg.exe is located in for the portable version. The installed version will still keep the folder where has already been (%APP_DATA%\mkvtoolnix\jobs).
* mmg: bug fix: Closing mmg's window while it was minimized caused mmg to appear hidden and unmovable when started the next time.

2013-07-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed overly long startup time with wxWidgets 2.9.x (especially on Windows) by using alternative methods for initializing certain controls. Makes startup time on par with wxWidgets 2.8. See #893 (https://www.bunkus.org/trac/ticket/893).

2013-07-02 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: new feature: Added support for the new Matroska elements DiscardPadding, CodecDelay and SeekPreRoll.
* build system: libMatroska 1.4.1 is now required for building.

Have fun.

[Mosu]

Just to confirm that the release build works fine, too. Many thanks for this. :)

Right back at you. Thanks a lot for all the timely feedback.

[Selur]

@Mosu: any plans regarding newer Mac OS X builds? (last version is 6.2.0)

[Mosu]

Those are in the hands of third-party developers. You can try contacting Jon (jonthn.free.fr/MKVtoolnix/CONTACT) when he'll be able to update. Or switch to MacPorts (http://www.macports.org/). While they're still at 6.3.0 they're also pretty quick to update these days.

[DarrellS]

Any timeline on when the next version with hevc support will be released? I'm using the Rovi build from DivX Labs in Virtualdub's external encoder and the settings that I normally use are not working with their build.

I normally use this setting for audio and video...

-o "%(outputname)" --default-duration 0:%(fpsnum)/%(fpsden)fps "%(tempvideofile)" "%(tempaudiofile)"

...but I'm getting an error message that it doesn't know what "--default-duration 0:%(fpsnum)/%(fpsden)fps" means and the only way that I'm able to use the muxer is to use this setting...

-q -o "%(outputname)" "%(tempvideofile)" "%(tempaudiofile)"

...but the finished file is out of sync since it doesn't know what the frame rate is of the hevc file (which is whatever the framerate is of the original file). What can I do to tell mkvmerge what the original file is without manually changing the framerate on every single file that I create?

Not sure why it won't accept "--default-duration 0:%(fpsnum)/%(fpsden)fps" since every other build of mkvmerge.exe will.

[Selur]

I'm using the Rovi build from DivX Labs
sounds like you should contact Rovi/DivX and not Mosu, it's their build,.

[Mosu]

First: what Selur said. I don't support builds by third parties.

Second: we are just in the process of finishing the HEVC-in-Matroska specs. Note that Rovi's build may NOT be using the final method we will agree upon, though they've been eager to adopt their build to match the latest proposal (see and following (http://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html)). I will not release a MKVToolNix build with HEVC support before those specs have been finalized and agreed upon. Therefore my guess (really a guess, not even an estimate) would be "no earlier than in eight weeks".

[DarrellS]

Thanks! I'm in no big hurry, I was just wondering. Maybe by then, someone will have implemented stdin input into the Multicoreware x265 encoder which seems to be a lot faster than the DivX encoder and has more options. The Rovi build does mux the DivX hevc file after it's created and creates an insync file if given the frame rate. It's just a lot easier using your builds to mux with with since they accept "--default-duration 0:%(fpsnum)/%(fpsden)fps" which saves me from either having to create separate encoder sets for each frame rate or muxing after the audio and video files have been created. The other issue is that the DivX files will only play in the DivX player and not in MPC-HC which is my player of choice.

Thanks again

[DarrellS]

sounds like you should contact Rovi/DivX and not Mosu, it's their build,.

I think I'm still a member at DivX Labs so I'll check with them.

I didn't know that your new version of Hybrid uses the DivX HEVC encoder. I'll download it and give it a try.

[Kurtnoise]

Maybe by then, someone will have implemented stdin input into the Multicoreware x265 encoder which seems to be a lot faster than the DivX encoder and has more options. The Rovi build does mux the DivX hevc file after it's created and creates an insync file if given the frame rate. It's just a lot easier using your builds to mux with with since they accept "--default-duration 0:%(fpsnum)/%(fpsden)fps" which saves me from either having to create separate encoder sets for each frame rate or muxing after the audio and video files have been created. The other issue is that the DivX files will only play in the DivX player and not in MPC-HC which is my player of choice.
who cares ? You're off-topic right now...

[hubblec4]

hi mosu

i have a problem with appending files.
i have a movie(h264 untouched), i want cut a short videosequence by timecodes getting from the chapters (chapterfile).

first cut 00:01:30.000
second cut 00:02:50.000

now i have three videoparts. i load the first part in mmg and append the third part. muxing done with 0 error.

the videofile plays fine till the first cut (00:01:30.000), then stuttering the video for 2 or 3 seconds. and only madvr recalibrate the video after this short time. (EVR, vmr, haali renderer sucks).
when i jump back to 00:01:30.000 (in MPC-HC with chapter prev) plays the video fine, no stuttering. but when i go to previous timestamp as 00:01:30.000, the video stuttering agian.

the three video parts play seperatly fine.

[sneaker_ger]

It was originally a complete, single file? Was it encoded with OpenGOP?

[hubblec4]

It was originally a complete, single file? Was it encoded with OpenGOP?

it is a single file, yes. and it came from a bluray.

OpenGOP, i dont know. mediainfo:
Allgemein
UniqueID/String : 142136116527023072389979487536299840814 (0x6AEE6B98C50B77314A39226D8E07152E)
CompleteName : ***video.mkv
Format : Matroska
Format_Version : Version 1
FileSize/String : 5,38 GiB
Duration/String : 42min
OverallBitRate_Mode/String : variabel
OverallBitRate/String : 18,0 Mbps
Encoded_Date : UTC 2013-09-22 16:23:23
Encoded_Application : eac3to
Encoded_Library/String : Haali DirectShow Matroska Muxer 1.13.138.14

Video
ID/String : 1
Format : AVC
Format/Info : Advanced Video Codec
Format_Profile : High@L4.1
Format_Settings_CABAC/String : Ja
Format_Settings_RefFrames/String : 4 frames
MuxingMode : Container profile=Unknown@0.0
CodecID : V_MPEG4/ISO/AVC
Duration/String : 42min
BitRate_Mode/String : variabel
BitRate/String : 17,6 Mbps
BitRate_Maximum/String : 38,0 Mbps
Width/String : 1 920 Pixel
Height/String : 1 080 Pixel
DisplayAspectRatio/String : 16:9
FrameRate_Mode/String : konstant
FrameRate/String : 23,976 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
ScanType/String : progressiv
Bits-(Pixel*Frame) : 0.354
StreamSize/String : 5,27 GiB (98%)
Default/String : Nein
Forced/String : Nein
colour_primaries : BT.709
transfer_characteristics : BT.709
matrix_coefficients : BT.709

[sneaker_ger]

MediaInfo does not offer detection for open gop AFAIK (aside from reading x264 custom sei). Can you upload a short (~1 minute) sample, perhaps your "first cut"?

[hubblec4]

MediaInfo does not offer detection for open gop AFAIK (aside from reading x264 custom sei). Can you upload a short (~1 minute) sample, perhaps your "first cut"?

ok.

video.mkv (http://www.file-upload.net/download-8111016/split-001--1-.mkv.html)

[sneaker_ger]

It seems to indeed be using open gop which cannot be cut reliably using mkvtoolnix.

[hubblec4]

mmh other episodes are work fine.

is this a problem to the entire file? or can i cut on other timecodes?

[sneaker_ger]

You should be able to cut on a few specific timecodes, namely I frames that are directly preceded by a P frame. You will mostly find these on scene changes.
This AviSynth script will show you the type of a given frame:
ffvideosource("split-001--1-.mkv")
ffinfo()

[Chetwood]

@sneaker_ger

I tried to adapt your batch to muxing a folder full of MKVs and Vobsubs but failed. Can you give it another try?

1 idx/sub with 2 languages per MKV:
"D:\Programme\MKVtoolnix\mkvmerge.exe" -o "e:\\ok\\Test 1x05.mkv" "--priority" "lowest" "--language" "0:jpn" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1280x720" "--language" "1:ger" "--track-name" "1:de DTS" "--default-track" "1:yes" "--forced-track" "1:no" "--language" "2:eng" "--track-name" "2:en AC3" "--default-track" "2:no" "--forced-track" "2:no" "-a" "1,2" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05.mkv" ")" "--language" "0:ger" "--track-name" "0:de" "--default-track" "0:no" "--forced-track" "0:no" "--language" "1:eng" "--track-name" "1:en" "--default-track" "1:no" "--forced-track" "1:no" "-s" "0,1" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05.idx" ")" "--track-order" "0:0,0:1,0:2,1:0,1:1" "--engage" "no_cue_duration" "--engage" "no_cue_relative_position"

2 idx/sub with one language each per mkv:
"D:\Programme\MKVtoolnix\mkvmerge.exe" -o "e:\\ok\\Test 1x05.mkv" "--priority" "lowest" "--language" "0:jpn" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1280x720" "--language" "1:ger" "--track-name" "1:de DTS" "--default-track" "1:yes" "--forced-track" "1:no" "--language" "2:eng" "--track-name" "2:en AC3" "--default-track" "2:no" "--forced-track" "2:no" "-a" "1,2" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05.mkv" ")" "--language" "0:ger" "--track-name" "0:de" "--default-track" "0:no" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05-de.idx" ")" "--language" "0:eng" "--track-name" "0:en" "--default-track" "0:no" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05-en.idx" ")" "--track-order" "0:0,0:1,0:2,1:0,2:0" "--engage" "no_cue_duration" "--engage" "no_cue_relative_position"

I'm pretty sure I'm not the only one to benefit from this. Thx.

[sneaker_ger]

I don't really see how you adapted my script (http://forum.doom9.org/showpost.php?p=1642767&postcount=2329). You simply copied the command-line from mkvmerge GUI which is not bad per se but is hard for others to take a look at. It's even harder if you just say "failed" instead of posting the error message.

As I told you in my last PM:
1. all parameters of an input file come directly in front on the input file
2. mkvmerge starts counting at 0. TrackIDs are per input file.
http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html

You are trying to use TrackID 1 with an idx file but unless the idx file has two subtitle tracks (uncommon but possible) you should only be using TrackID 0.

/edit:
corrected idx tracks being able to hold more than 1 subtitle track as per Mosu's correction

[Mosu]

Minor nitpick : VobSub files can contain arbitrary number of tracks. I have plenty of those here. Otherwise you're correct, of course.

[sneaker_ger]

I feared somebody might come and say that. But does mkvmerge read more than one track? I never actually tried.

[Mosu]

Sure it does :-) all of them, unless you tell it not to. Like with all file types it supports.

[Chetwood]

I don't really see how you adapted my script (http://forum.doom9.org/showpost.php?p=1642767&postcount=2329).
I haven't since I failed miserably at adapting it. Thanks for rubbing it in :(

[sneaker_ger]

:D

Maybe we start from the beginning so you can get a clear understanding. I'm using the mkvmerge docs (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html) for reference.

This is the general order of an mkvmerge command-line:
mkvmerge [global options] {-o out} [options1] {file1} [[options2] {file2}] [@optionsfile]

We start off with simply muxing an h264 video to an mkv container:
mkvmerge -o output.mkv input.h264

The next exercise would be to mux one h264 video track and one idx/sub subtitle track:
mkvmerge -o output.mkv video.h264 subtitles.idx
As you can see mkvmerge simply adds all files that don't have a "-o" in front of them into the file.

Now we want to define the video language as "English" and the subtitle language as "Dutch":
mkvmerge -o output.mkv --language 0:eng video.h264 --language 0:dut subtitles.idx
Notice how I've used the TrackID "0" for both input files. Lessons learned:
- the input TrackID's apply for each input file on their own.
- the options of an input file go in front of the input file

Since working with raw files is boring we will now try adding an mkv input file that has 3 tracks, with the first track being English, the second track being Finnish and the third track being Japanese. We will also add an idx/sub subtitle that is supposed to be German:
mkvmerge -o output.mkv --language 0:eng --language 1:fin --language 2:jpn input.mkv --language 0:ger subtitles.idx
As you can see we count from 0 to 2 for the input file with three tracks and still only use 0 for the single track after that.

We can do the same, but now with a second subtitle track which we will also mark as "forced":
mkvmerge -o output.mkv --language 0:eng --language 1:fin --language 2:jpn input.mkv --language 0:ger subtitles.idx --language 0:ger --forced-track 0:yes forced_subtitles.idx

Now let's say we also want to use some global options, for example --engage no_cue_relative_position and --clusters-in-meta-seek. We will simply put them into the front:
mkvmerge --engage no_cue_relative_position --clusters-in-meta-seek -o output.mkv --language 0:eng --language 1:fin --language 2:jpn input.mkv --language 0:ger subtitles.idx --language 0:ger --forced-track 0:yes forced_subtitles.idx


Well, that's pretty much it. We just have to be careful sometimes:
1.) If our file names or other descriptions have spaces in them, we have to use quotes around them. For example if we have "forced subtitles.idx" or we want to name the a track "Director's comment":
mkvmerge --engage no_cue_relative_position --clusters-in-meta-seek -o output.mkv --language 0:eng --language 1:fin --language 2:jpn --track-name 2:"Director's comment" input.mkv --language 0:ger subtitles.idx --language 0:ger --forced-track 0:yes "forced subtitles.idx"
2.) Some special characters have to be escaped (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.escaping)
3.) In some cases (numbered VOBs) mkvmerge tries to automatically load several files without asking. We can stop it from doing so if we add a "=" directly before the filename or if we put it in Parentheses with spaces: "(" filename ")", (see the end of chapter 2.5 in the mkvmerge docs)
mkvmerge --engage no_cue_relative_position --clusters-in-meta-seek -o output.mkv --language 0:eng --language 1:fin --language 2:jpn --track-name 2:"Director's comment" ( input.mkv ) --language 0:ger subtitles.idx --language 0:ger --forced-track 0:yes ="forced subtitles.idx"

[Chetwood]

Thanks for taking the time. I really appreciate it.

[Morku]

I have a little noob question.
Whats the difference between the subttles default flag and forced flag? I know forced subtitles are for parts of the movie with a different language in the scene. When I have the forced and complete subtitles in srt, I set the forced subtitles as default track and it will be shown in the media player. What would be the difference, if I use the forced flag?
Thank you very much.

[Mosu]

Please read this fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3ADefaultAndForcedFlagsAndDefaultYesNoInMMG) about this very topic.

[Chetwood]

@Morku
You might also wanna read this (http://forum.doom9.org/showthread.php?t=167710).