MKVToolNix v24.0.0 released

[Mosu]

I'd appreciate the upload, though I will probably not be able to look at it soon. Thanks.

[Nico8583]

Hi :)
I would like to know if it's possible to add some informations to an MKV file, like synopsis, stars, released year, cover (but it seems to be in Attachments), title, genre, countries...
Is it possible by creating a XML file and use it in Global tags ? Or another way ? And how to format XML file to be accepted by MKVmerge ?
Thanks !

[the_weirdo]

Is it possible by creating a XML file and use it in Global tags ?
Yes.


And how to format XML file to be accepted by MKVmerge ?

This (http://matroska.org/technical/specs/tagging/index.html) may help you. (You can find XML examples there, too).

[Nico8583]

Thank you, it is what i searched :)
Do you know players who can read these informations ? XBMC ? MPC-HC ?

[the_weirdo]

Thank you, it is what i searched :)
Do you know players who can read these informations ? XBMC ? MPC-HC ?

Don't know about XBMC but MPC-HC/BE doesn't seem to read those informations. However, VLC and mpv can do that.

[Nico8583]

Don't know about XBMC but MPC-HC/BE doesn't seem to read those informations. However, VLC and mpv can do that.
Thanks, I'll try XBMC and MediaPortal.

[leeperry]

Thanks for this great app, BTW is there any simple way to extract a sequence in the middle of a MKV file? I always have to split several times to get the sequence I want, is there any way to get it right away?

[Mosu]

Use splitting by parts and read the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split) for it.

[Mosu]

Hey,

I've released MKVToolNix 6.8.0. There were tons of bug fixes for the Windows builds, especially for the 64bit builds.

The one new feature that is present is support for h.265/HEVC video: but only for reading it from elementary streams or from other Matroska files. My initial plan was to have reading it from MPEG transport streams work as well, but alas, free time is in short supply, and this release is a week overdue already.

The HEVC support has been implemented by Rovi Corp (DivX). I've merged their changes, updated them to the current code base and cleaned them up somewhat. Their work is much appreciated.

For package maintainers nothing has changed compared to 6.7.0.

Here are the usual links:

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/source.html

...to the binaries:
http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

Here's the full ChangeLog since release 6.7.0:

2014-03-02 Moritz Bunkus <moritz@bunkus.org>
* Released v6.8.0.

2014-02-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: new feature: added support for h.265/HEVC by merging the patches from DivX/Rovi Corp. So far HEVC is only supported as elementary streams and read from other Matroska files.

2014-02-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The deprecated ISO 639-1 code "iw" is now recognized for Hebrew.

2014-02-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The AC3 packetizer will re-derive the sampling frequency and the number of channels from the bitstream. This way obviously invalid information from the source container like a sampling frequency of 0 Hz will be fixed.

2014-02-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancements: AVI reader: audio chunks with obvious wrong size information (bigger than 10 MB) will be skipped.

2014-02-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: When reading M2TS files belonging to an MPLS playlist mkvmerge will now only copy packets whose timestamps lie between the »in time« and »out time« restrictions from the playlist's entry corresponding to that M2TS file. Fixes #985 (https://www.bunkus.org/trac/ticket/985).

2014-01-22 Moritz Bunkus <moritz@bunkus.org>
* all: Windows 64bit: fixed return value checks for opening files. Fixes #972 (https://www.bunkus.org/trac/ticket/972).

2014-01-21 Moritz Bunkus <moritz@bunkus.org>
* all: Windows: when redirecting the program's output with cmd.exe (e.g. »mkvinfo file.mkv > info.txt«) the programs will no longer write two line feed characters (\r) per carriage return character (\n). Fixes #970 (https://www.bunkus.org/trac/ticket/970).
* all: Windows: the default charset for the files created with»--redirect-output« has been changed from the system's local charset to UTF-8. Just like before it can be changed with»--output-charset«. See #970 (https://www.bunkus.org/trac/ticket/970).
* all: bug fix: Windows: messages written to the console (cmd.exe) are not re-encoded to the local charset and back to UTF-16 before they're handed over to ConsoleWriteW(). This fixes outputting Unicode characters to the console that are not part of the local charset. Fixes #971 (https://www.bunkus.org/trac/ticket/971).

2014-01-18 Moritz Bunkus <moritz@bunkus.org>
* extract: bug fix: using names of non-existing files in»attachments«, »chapters«, »cuesheet« or »tags« mode caused mkvextract to crash instead of emitting a proper error message. Fixes #964 (https://www.bunkus.org/trac/ticket/964).

2014-01-17 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: fixed the check for WebM-compatible track types for Opus.

2014-01-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed muxing Sorenson v3 (SVQ3) video from QuickTime files.

2014-01-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract, mkvpropedit: enhancement: attachments in Matroska files with a missing FileUID element are not ignored anymore even though they violate the specs. mkvmerge generates a new FileUID instead.

2014-01-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: re-built with the 64bit build for Windows with a newer compiler version in order to fix #957 (https://www.bunkus.org/trac/ticket/957). It was due to a bug in gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
* mmg: bug fix: mkvmerge's file identification is written to a temporary file with --redirect-output and from there into mmg instead of directly from mkvmerge. This prevents from character re-coding done by wxWidgets 3.0.0 on Windows. Fixes #959 (https://www.bunkus.org/trac/ticket/959).

2014-01-09 Moritz Bunkus <moritz@bunkus.org>
* installer: enhancement: the architecture (32bit vs 64bit) is mentioned in the interface.
* installer: bug fix: the installation directory for 64bit builds will default to the proper directory (»C:\Program Files« instead of »C:\Program Files (x86)«). Fixes #956 (https://www.bunkus.org/trac/ticket/956).

Have fun.

[filler56789]

* mkvmerge, mkvextract: new feature: added support for h.265/HEVC by merging the patches from DivX/Rovi Corp. So far HEVC is only supported as elementary streams and read from other Matroska files.

Finally \o/ :D

:goodpost: and MANY :thanks:

[DragonQ]

Mosu, did you have a chance to look at that issue with muxing BBC HD broadcasts causing dodgy timestamps I posted a few weeks back? (Works fine with Haali MKV Muxer.)

[Mosu]

DragonQ: No, I've totally overlooked that one due to the answers you were already receiving, sorry. I don't have time to look into this over the next two weeks or so either. There's already a similar-sounding bug report (https://trac.bunkus.org/ticket/918) (though the source material is somewhat different) which may have the same underlying cause. However, I haven't been able to figure that problem out. There's simply no other code out there that I can take a look at in order to compare to my code, so it's reaaaaaally difficult guessing where my code is doing something wrong… Haali not being Open Source doesn't help matters either, of course.

So don't get your hopes up.

[cyberbeing]

Haali not being Open Source doesn't help matters either, of course.

Haali shared his entire source code for splitter & muxer with JEEB awhile back, and even allowed release of binaries built from patched source code. So while Haali may not be Open Source (yet?), it's not as closed as it used to be. Haali's muxer uses DirectShow input though, so things like dodgy timestamps could potentially be cleaned up during decoding, before it even reaches the actual muxer.

[pie]

I've been searching, but I can't seem to find the answer, so sorry if this has been asked before:

Was there any reason why the type identifier for subtitles, e.g S_TEXT/ASS has been changed to SubStationAlpha?

[Mosu]

I've unified mkvmerge's output of codec types over the various input/output modules. As both SSA and ASS are handled the very same way they're now named identically.

If you really need to know the type of the codec used then mkvmerge is not the right tool for that particular job.

[Mosu]

Mosu, did you have a chance to look at that issue with muxing BBC HD broadcasts causing dodgy timestamps I posted a few weeks back? (Works fine with Haali MKV Muxer.)

I've looked into this for a couple of hours and seem to have figured out the reason. I have a new build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) which includes a change that makes playback of the sample you've uploaded smooth. Please try it with some of your other files as well. Thanks.

[DragonQ]

Just tried a file recorded the other day and it looks like everything's working now, thanks. Out of curiosity, what was the problem? Do they use some rare codec setting that MKVToolnix didn't handle correctly? The BBC tend to be the first to push codec improvements in the broadcasting arena so it wouldn't surprise me.

[Mosu]

Thanks for testing and getting back to me.

It wasn't a codec setting per se. In an h.264 elementary stream there are several conditions under which the next frame/field can be considered a key frame (in the lose sense of the word – a point from which decoding can start without needing knowledge of any prior/following frames, e.g. a point you can start from after seeking, a »key frame« in Matroska terms): either the NALU is of type »IDR slice« and the slice itself is of one of the types »I, I2, SI or SI2« (that's basically how I named my constants for the various numeric values), or the frame/field follows a »recovery point SEI« NALU.

mkvmerge usually has to buffer all frames/fields for h.264 up to the following key frame. Only when such a key frame is found can the timestamps be applied to the buffered frames properly (sort by display order, assign timestamps, sort back to decoding order).

Now this stream makes heavy use of »recovery point SEI« NALUs. This is OK in general. However, here we have key frames consisting of two fields, and there was a »recovery point SEI« NALU in front of each of the two fields.

The result is:

The first key frame field is found and all prior buffered frames/fields are flushed (flushing = assign timecodes, write to output file, clear list of buffered frames).
The first key frame field is buffered (and now the only frame/field buffered at that point).
The second key frame field is found; again all prior frames/fields are flushed (which is only the first key frame field).
Processing continues up to the next key frame. Here all buffered frames/fields are flushed starting with the second key frame field.

Point 2 is where things went wrong. If the first field of that key frame is flushed so soon then that's too soon as it is required for proper calculation/assignment during step 3.

So what I did was change the algorithm not to flush frames before the second field. I haven't looked into the specs, though, in order to see whether or not what I've done is actually the right thing to do.

[hello_hello]

Is there a reason why, when muxing a single chapter into an MKV, the chapter in question is ignored? I have a feeling the behaviour isn't new (I can't remember exactly) but is there a way to stop that from happening? Also the behaviour isn't consistent, in that if I remux an MKV (or MP4) which already contains a single chapter, the existing chapter is muxed into the output file. MKVMergeGUI's chapter creator will also mux a single chapter into an MKV. If I create the chapter myself using a text file though, adding it under the Global tab has no effect when muxing. The reason I ask.....

Several times I've wanted to append MKVs while adding chapters corresponding to the point where one MKV "part" ends and the new one begins. I thought it'd be nice and easy to create a chapter located at time code zero, mux it into each MKV, and then when appending the MKVs I'd have a single file with chapters in all the right places. The second part of the idea works a treat, but muxing a single chapter into each before appending is a little harder.

At one stage I appended four MKVs, each containing a single chapter, but the output MKV didn't contain four chapters as I expected. It only contained the chapters from the first two appended MKVs. Is there a reason why the following two chapters might have been ignored? It only happened when appending one particular group of MKVs.

I've also discovered what appears to be a bug in MKVMergeGUI 6.8.0. I don't know if it's new, but if I load the following chapter into MKVMergeGUI's Chapter Creator, it causes the GUI to stop running.

CHAPTER01=00:00:00.000
CHAPTER01NAME=00:00:00.000

Thanks.

[the_weirdo]

I've also discovered what appears to be a bug in MKVMergeGUI 6.8.0. I don't know if it's new, but if I load the following chapter into MKVMergeGUI's Chapter Creator, it causes the GUI to stop running.

CHAPTER01=00:00:00.000
CHAPTER01NAME=00:00:00.000


Maybe this is indeed a bug and should be fixed, but in the mean time, you can work around it by adding an empty line at the end of chapter files. Your problem of "when muxing a single chapter into an MKV, the chapter in question is ignored" may also be caused by this.

[hello_hello]

Your problem of "when muxing a single chapter into an MKV, the chapter in question is ignored" may also be caused by this.

It seems it was. Add an empty third line and a single chapter can now be muxed, while loading said chapter file doesn't cause the GUI to run away.

I guess the "can't mux a single chapter" thing is a bug. You never can tell. Handbrake refuses to mux single chapters into it's output files (although the log file informs you of it) so I thought maybe not being able to mux a single chapter might be considered normal. I'm glad it appears not to be.

Thanks.

[Mosu]

As I'm in the process of re-writing the GUI I won't fix minor issues such as this in the old one, especially as you have a usable workaround for the time being.

[delacroixp]

* mkvmerge, mkvextract: new feature: added support for h.265/HEVC by merging the patches from DivX/Rovi Corp. So far HEVC is only supported as elementary streams and read from other Matroska files..
Finally \o/ :D

:goodpost: and MANY :thanks:

Ditto ... a welcome addition to the H265 roadmap.
Wasn't sure if you were gonna get to it since you're a "one man band".

Awesome ... tx


It's all good
:):devil::D
Pascal

[DragonQ]

Wish there was some real-world HEVC content to try. Maybe UHD trials will start on satellite soon.

[sl1pkn07]

@Mosu


I'm in the middle of a complete re-write of the GUI with a different toolkit library. I will therefore not fix minor issues in mmg anymore.


what is the new GUI toolkit?

[Mosu]

Qt instead of wxWidgets.

[sl1pkn07]

GREAT!!!

thanks Mosu for you work!!

greetings

[Snowknight26]

The Windows installer for the 64-bit version of 6.8.0 seems to have a black background for the copyright line or something like that.

[Mosu]

Known, already fixed. As it's a completely cosmetic issue I won't create new installers for 6.8.0.

[fancyclown]

Hi, thanks for the great updates!

Right now I'm using 6.8.0 with wine on OS X because I can't figure out how to build a new version with a gui.

The mac app version hasn't been updated since 6.2.0 so it would be great if anyone could give pointers how to build the new version.

:thanks:

[Chetwood]

BTW, this thread's headline still suggests 6.7.0 being the latest version.

[Mosu]

@Chetwood: goot point, thanks. Fixed.

[DarrellS]

Thanks for the update. Good to see HEVC support. It was worth the wait.

[shinchiro]

Does chapter extraction broken somewhere in 6.8? as I unable to parse the xml doc in c# library. Plus the byte of sizes it produce is slightly bigger than previous mkvtoolnix version 6.6,6.5 etc produce so it make me wonder it it is the reason it broke. I use --redirect-output option instead '>' when extracting the chapter

[Mosu]

That's a known issue that I've already fixed in the latest pre-build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/). The issue was that the BOM was written twice when using --redirect-output. The redirection via '… > filename.xml' did not suffer from this issue, though I cannot say whether or not this works nicely with non-ASCII characters on Windows' cmd.exe (it does work fine on Linux shells, of course).

[Korgnex]

Since version 6.7.0 the head data editor has an annoying bug:
(this also still applies to version 6.8.0)

if you load a file (*mkv) with the head data editor or place it via drag and drop there, the head data editor becomes unresponsive for about 6-8 seconds. The same happens when you save the changes.
In version 6.6.0 the loading and saving worked flawless.

platform tested: Windows 7 SP1 / Windows 8.1 (both x64)

Could you please reproduce this bug and fix it?

[Mosu]

No, sorry. I won't spend any more time on the old GUI as I'm in the process of re-writing it – even though that will still take some time until it'll be finished.

[Simon88]

When I open MKVs under mmg 6.8.0 64-bit and trying to edit the "Global options | File/segment title:", subsequent edits of different files shows "blank/nothing" in the "File/segment title:" fied. I know for a fact it contains a File/segment title... so when I exit and re-run it and then load up the mkv, it shows the correct File/segment title.

For the new Input files:, I simply click "remove all" and then add... Am I doing something wrong, or am I suppose to exit the entire program before loading up a new MKV file? I remember in the past it seem to work as I had expected... but this newer version somehow behaves differently....

[Mosu]

Use »File -> New«. Using »Remove all« is supposed to keep certain fields the way they are, and that includes their internal state regarding whether or not the field has been manually changed.

[MeridiusUK]

Use »File -> New«. Using »Remove all« is supposed to keep certain fields the way they are, and that includes their internal state regarding whether or not the field has been manually changed.

Hi there

I have also been using the remove all button to create more mkvs but did not know that the Global File/Segment title did not change with every new files droped into the window.

is there a way to change this field in the mkv without remuxing a few mkvs or will i have to start all over to change that field.

also what other fileds odes the remove button keep when inputing a new project apart from the file/segment title ? is there anything i should be worried about.

thanks

[Mosu]

If you need a GUI: mmg's header editor. If you need something scriptable: mkvpropedit.

[MeridiusUK]

Thanks fro that but i can not seem to finr the mmg header editor ? is it in mkvtoolnix or other as i can not find it

thanks

[Mosu]

Start mmg, File -> Header editor.

[hubblec4]

Hi Mosu

during i update my chapterEditor i found a small issue in mmg at the mpls parser.

here is an eac3to log which you can see that the mpls file is used for 2 separate editions.

eac3to v3.27
command line: eac3to.exe "h:" -log=log.txt
------------------------------------------------------------------------------
1) 00001.mpls (angle 1), 1:51:51
[6+1+3+4].m2ts
- Chapters, 12 chapters
- h264/AVC, 1080p24 (16:9)
- DTS Master Audio, German, multi-channel, 48kHz
- DTS Master Audio, English, multi-channel, 48kHz

2) 00001.mpls (angle 2), 1:51:51
[6+2+3+5].m2ts
- Chapters, 12 chapters
- h264/AVC, 1080p24 (16:9)
- DTS Master Audio, German, multi-channel, 48kHz
- DTS Master Audio, English, multi-channel, 48kHz

when i load this mpls in mmg i get only a chapter entry, but no tracks.

this is a mpls from the "SNITCH" Bluray.

[MeridiusUK]

Start mmg, File -> Header editor.

thanks alot for that

can it cause any damage in the mkv by doing this at all ?

[Mosu]

Read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AAllTracksVanishedAfterMkvpropeditOrHeaderEditor) for what may happen with players that don't support the Matroska file format properly.

[AYColumbia]

@Mosu,
After updating to 6.8.0, it looks like chapter adding/updating is broken with mkvpropedit. I sometimes have to tweak some chapters so I use mkvextract to get the chapter in XML, update it and then re-insert it with mkvpropedit. I've been doing this for a long time now with no issues, until after updating to 6.8.0.

I even tried extracting the chapter, not modifying it and then re-insert it and it still failed. Here's the error mkvpropedit is reporting:Commandline: mkvpropedit "test.mkv" -c "test_chapters.xml"
Error: Unknown chapter file format in 'E:\Media\work\test_chapters.xml'. It does not contain a supported chapter format.
Process terminated with code: 2
Execution took 0 seconds(s).
Here's the chapter file contents that are untouched, i.e., extracted from MKV file and not modified:<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionUID>6990704301007864204</EditionUID>
<ChapterAtom>
<ChapterUID>17754048247072012851</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:01:17.710966666</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 01</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>4344430792985646390</ChapterUID>
<ChapterTimeStart>00:01:17.710966666</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:11:49.241866666</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 02</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>5565392499311670039</ChapterUID>
<ChapterTimeStart>00:11:49.241866666</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:21:31.823866666</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 03</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>7804300074959422330</ChapterUID>
<ChapterTimeStart>00:21:31.823866666</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:22:30.048700000</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 04</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>1890640418935528493</ChapterUID>
<ChapterTimeStart>00:22:30.048700000</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:22:31.550200000</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 05</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>
I also tried to load the chapter files into the UI's chapter editor and got the same error, so I'm not sure what has changed. Tell me if you need any other info please. Thank you.

[Mosu]

The extraction with mkvextract was broken, yes. Known issue, fixed already. Get the latest build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

[AYColumbia]

The extraction with mkvextract was broken, yes. Known issue, fixed already. Get the latest build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).
Great, thank you. I'll grab the latest and give it a try. I just ran into one other issue with mkvpropedit though. I wanted to try to remove the current chapter file and according to the help, I can leave the -c argument blank, i.e., no file specified which would remove the current chapters. I tried it with -c only and -c followed by "" and both gave the following error:Commandline: mkvpropedit "test.mkv" -c
Error: Missing argument to '-c'.
Process terminated with code: 2
Execution took 0 seconds(s).

Commandline: mkvpropedit "test.mkv" -c
Error: Missing argument to '-c'.
Process terminated with code: 2
Execution took 0 seconds(s).
After each one, the chapters were still in the MKV file.

I'll post back on the other issue in a bit.

[Mosu]

Hmm… please open a ticket in my bug tracker (https://trac.bunkus.org/) about that issue; otherwise I'll most likely forget about it (more than busy at the moment).