MKVToolNix v6.6.0 released | mosu's Matroska stuff

Hey,

I’ve released MKVToolNix 6.6.0. I’m trying to get back on a release cycle of roughly six weeks between minor versions (minor being the middle part of the version number). So releases may happen more often than over the summer but contain few changes.

This release fixes a couple of bugs and greatly improves the compatibility to the newly released wxWidgets 3.0.0. A new translation into Portuguese has been added, and you can now re-order chapters in the chapter editor with the usual drag & drop operations.

Nothing has changed for package maintainers compared to the previous release, v6.5.0.

You can download the source code or one of the binaries.

Here’s the full ChangeLog since release 6.5.0:

2013-12-01 Moritz Bunkus <moritz@bunkus.org>
- Released v6.6.0.
- mmg: new feature: implemented drag & drop in the chapter editor. Implements #929.
2013-11-24 Moritz Bunkus <moritz@bunkus.org>
- mmg: bug fix: fixed an assertion in wxLogMessage() due to wrong format string/argument data types caused by changes in wxWidgets 3.0.0. See Debian bug #730273.
- mkvmerge: bug fix: improved resilience against MP4 files with obviously wrong entries in the ‘sample size table’ (STSZ) atom.
- mkvmerge: bug fix: improved VC1 frame type detection so that it works even for streams without entry points.
2013-11-14 Moritz Bunkus <moritz@bunkus.org>
- mkvinfo: bug fix: at most the lower 32bits of the track numbers and track UIDs elements were output, even if the element in the file used more bits. Fixes #935.
2013-11-02 Moritz Bunkus <moritz@bunkus.org>
- mkvmerge: bug fix: fixed accessing invalid memory in the memory handling core routines. May be triggered by the code to remove filler NALUs introduced in v6.5.0. Fixes #931.
2013-10-26 Moritz Bunkus <moritz@bunkus.org>
- mmg: bug fix: fixed the tracks list box on the input tab being invisible/0 pixels high with wxWidgets 2.9.x/3.x.
- all: integrated the Portuguese translation. Although the translation files themselves had been added back in 6.3.0 that translation wasn’t available for selection due to forgetfulness on my part.
- mkvmerge: bug fix: The file detection code in the MPEG elementary stream reader had a logic error. Fixes #928. In practice this logic error didn’t have any consequence.

Have fun.

22 thoughts on “MKVToolNix v6.6.0 released”

David December 4, 2013 at 11:01

Testing the new version, Mosu. Thanks for improving the chapter marking capabilities. Hopefully the automatic sorting will come up next!

Lucas December 19, 2013 at 21:54

Great tool, love it :)

But I wonder if the source can be destroyed during re-create with mkvmerge?

mosu Post authorDecember 19, 2013 at 21:59

I don’t quite understand your question.

If you want mkvmerge to remove the source file after muxing has completed successfully: there’s no option for that.

If you want to output to the same file you’re currently reading from: that is technically impossible. mkvmerge contains some code for preventing it by checking source/output file names.
1. Lucas December 19, 2013 at 22:21
  
  For example, when the process was killed – is it possible to corrupt the source file?
  
  Also I’m not sure how to use the CLI version. I tried
  mkvmerge -o new.mkv source.mkv –no-subtiles –audio-tracks 1
  But the output is exactly the same as the input
  1. mosu Post authorDecember 19, 2013 at 22:23
    
    No, it’s not possible, because the source file is never written to.
    
    Track- and file-specific options always apply to the source file name that follows those options. In your example the options don’t apply to anything as there is no source file name after the options.
    
    Read http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.option_order

awe December 21, 2013 at 02:07

where is the download button?

mosu Post authorDecember 21, 2013 at 09:33

http://www.fosshub.com/MKVToolNix.html

George December 22, 2013 at 20:02

Thank you very much!

Bob December 28, 2013 at 14:02

Hey, looks like Trac is down; I get a 502 Bad Gateway.

Anyway, I just downloaded the latest Windows release. I’m trying to get the complete IDs for linked chapters with one command, but I cannot figure out how.
I’ve tried “mkvinfo.exe –ui-language en test.mkv”
This gives me the complete “Segment UID”, but the “ChapterSegmentUID’s” are truncated no matter what I try. Also, even though I used –ui-language, I see for example “ChapterSegmentUID: Länge 16, Inhalt:”.
If I use “mkvextract.exe chapters test.mkv” I do get the complete “ChapterSegmentUID”, but the “Segment UID” is missing.
Also, could mkvinfo export the details as XML, like mkvextract does?

Apart from that, great tool :)

mosu Post authorDecember 28, 2013 at 14:55

Trac’s up and running again.

I don’t know why selecting the interface language doesn’t work for you. It does for me.

A ChapterSegmentUID is a binary element (from the point of view of the specs), and mkvmerge only outputs the first 16 bytes for binary elements because they can become arbitrarily long. For example, CodecPrivate elements can be easily a couple of KB big, and you wouldn’t want to see a hex dump of that each time you run mkvinfo.

The segment UIDs are stored in a different place than the chapter segment UIDs (in the »segment information« element, to be precise). At the moment mkvextract cannot extract the segment info section at all.

So no, it’s not possible and most likely never will be to extract all that stuff in exactly the format you want with a single execution of one of the tools.

mkvinfo cannot output XML and most likely never will be able to. I’ve thought about how that could be accomplished and have therefore a very thorough understanding of the amount of work required to re-write huge portions of mkvino for such a purpose. Way too much work for pretty much no gain to myself.
1. mosu Post authorDecember 28, 2013 at 15:00
  
  And trac’s down again… Don’t know what’s up with it. Will have to investigate.

Bob December 28, 2013 at 20:06

> I don’t know why selecting the interface language doesn’t work for you. It does for me.
Oh, it’s not all the output. Just that line isn’t in english, the rest looks fine. Sorry for not being more clear.

> A ChapterSegmentUID is a binary element (from the point of view of the specs), and mkvmerge
> only outputs the first 16 bytes for binary elements because they can become arbitrarily long.
Hm, from your experience, would it be ok to rely on those 16 bytes only to identify a linked chapter? Not for a player, but only for a informational purpose, like saying “hey, you’re missing a linked chapter file”.
So if the ChapterSegmentUID can be a few kB, the segment UID can be too, right? Because they have to match for a successful linking.

mosu Post authorDecember 28, 2013 at 20:38

Even though segment UIDs are binary elements (which can be arbitrarily long) the specs actually say that they’re exactly 128 bits long. See http://www.matroska.org/technical/specs/index.html 128 bits = 16 bytes.

Now the chapter segment UIDs are supposed to reference existing segment UIDs, so they as well will be 16 bytes long, and therefore the answer to your question is of course »yes«.

As to that one line being displayed in a different language: that I would really like to see. Would you mind sharing a screenshot of mkvinfo’s output showing that particular and its surrounding lines? Please also post the exact command line. Thanks.
1. Bob December 29, 2013 at 13:55
  
  Thanks for the clarifications!
  
  And here’s the screenshot. Turns out there’s another word which won’t change if you use the ui-language switch: http://picpaste.com/gOGIvkQ3.png
  1. mosu Post authorDecember 29, 2013 at 16:57
    
    Thanks for the screenshot. Funny issue. It should be fixed now. A new build with the fix included is available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ Build numbers 556 and higher will have it included. Please give it a try.
    1. Bob December 29, 2013 at 21:30
      
      All translated now, works fine
    2. Bob December 29, 2013 at 23:45
      
      One last thing: a Segment UID is according to the Matroska specs always 128 bit long (as you said above too), so would you consider to display the 16 bytes of the ChapterSegmentUID when using mkvinfo? Currently it truncates the UID after 10 bytes. Then it would be possible to get all UIDs required for finding linked chapter dependencies with a single call.
      That should be quite simple.
    3. mosu Post authorDecember 30, 2013 at 00:14
      
      I’ve just committed a change so that mkvinfo outputs the first 16 bytes for EBML binaries instead of the first 10. Builds 557 and higher will have it included. Upload should be finished in ~5 minutes.
    4. Bob December 30, 2013 at 10:27
      
      Perfect, thanks!

kassandro January 7, 2014 at 10:07

Upgrading from version 6.0 to 6.6 I noticed, that support for transport streams as an input format has been added to mkvmerge. That’s very nice. Usually such transport streams originate from digital tv transmission, whence they easily may contain errors. So far mkvmerge doesn’t seem to spot these errors, which may also cause A/V sync problems. It would be nice, if mkvmerge would recognize such errors and report where they occure.

mosu Post authorJanuary 7, 2014 at 10:09

That’s outside of mkvmerge’s scope. Sorry.
1. kassandro January 18, 2014 at 10:28
  
  I thought, that this is only a matter of checking the checksums of the GOPs, but I don’t know the details.

Comments are closed.