MKVToolNix v24.0.0 released

[Mosu]

Not really. Too long, got other things to do.

[Chetwood]

You know I was talking to Morku, right?

[Mosu]

No, I wasn't. Sorry. When someone says "take a look at..." in this thread they usually mean me. Hence me not reading your post accurately ;)

[Chetwood]

Which also would explain you not realizing you already had answered (http://forum.doom9.org/showthread.php?p=1625351#post1625351) in the thread I was referring to. No biggy ;)

Still, now that I've read it again, I was wondering if there's any chance in hell that the specs might ever be changed in regards to the flagging of tracks? Cause currently we have the choice between ruining playback on most players and being spec-compliant but can't have both.

I mean, what about a BD with one regular subtitle track, that has 10 or so items flagged as forced? Since the MKV container has to flag the entire track (which then will stay on for the entire length of the movie), the only way for me to watch with forced subs only, is to extract those items to a separate track.

Of course you may have had other priorities when doing the specs, I'm just pointing out that the above example is not uncommon.

[Mosu]

Well... if someone caring enough about these issues does the work of writing up a proposal with a rationale, sending it to the matroska-devel mailing list, defending it against criticism etc. then there is a chance, yes. However, if you only wait for "the Matroska team" to do the work on its own then the answer is probably "no".

Keep in mind that supporting new flags in the format is a many-edged blade:


From my experience a lot of players out there react badly to elements they don't know about, even if the Matroska specs say that unknown elements must simply be skipped instead of throwing a tantrum. Mostly hardware devices are at fault here, and it doesn't seem to matter which manufacturer it is: I've received reports from Sony, Panasonic, several less-known ones -- with the notable exception of the Popcorn Hour devices from Cloud Media/Syabas! Software players usually get this right, but even VLC has had its problems until I wrote pretty long and detailed but reports venting my frustration about this.
Adding something to the spec is easy. Support in MKVToolNix will most likely follow shortly, but not always and for all elements, especially if adding involved re-arranging a lot of stuff in mmg. Other than me there's simply no developer working on MKVToolNix, and adding new features requires the work on mkvmerge, on mmg, testing, adding a test case, adding the elements in mkvinfo, updating the translations and adding explanations about this to the documentation. It usually takes a couple of hours of work. So you also have to convince me of doing that work :)
When MKVToolNix has support for a feature it doesn't mean other software creating Matroska files or reading them does as well. Tools like ffmpeg are only using a very limited subset of Matroska's features. Other tools like HandBrake make use of more of them and may adopt such features in time, but someone will have to tell those developers about those new features as well.
Even if you do have all those pieces in place you still need support for them in the players and splitters. Again, those developers have to be told about the new features, and they have to be willing to do the work.


Adding stuff to the specs is easy. Making it all work is a lot of effort that's not undertaken lightly.

[hubblec4]

hi mosu

i found this validator (http://matroska.org/downloads/mkvalidator.html) on the matroskapage.
but when i try to valid a chapter.xml i get this issue message.


***\mkvalidator-win32.v0.4.2>mkvalidator.exe --details chapter.xml
ERR003: EBML head not found! Are you sure it's a matroska/webm file?

the chapter.xml is from your ChapterEditor.

what is the problem of the xml or the validator?

[Mosu]

mkvvalidator can only validate Matroska files.

[Chetwood]

Well... if someone caring enough about these issues does the work of writing up a proposal with a rationale, sending it to the matroska-devel mailing list, defending it against criticism etc. then there is a chance, yes. However, if you only wait for "the Matroska team" to do the work on its own then the answer is probably "no".
Thanks for clearing that up but I'm afraid there's not much rationale other than what I've already given. Since MKVs need an entire track to be flagged as forced rather than seperate items, regular tracks that have only some items flagges as forced must be converted into forced only tracks which may not always be possible due to how the flagging is done on the source Bluray. I guess there's not much to be done about this then.

[Selur]

@Mosu: any news regarding newer Mac OS X builds? (current version is 6.2.0, tried to contact Jonathan a while back but didn't get a reply)

[Mosu]

Neither did I, so no, no news. No new builds until someone else revives Jonathan (metaphorically speaking, I don't know what's up with him) or until someone provides his own builds.

[Mosu]

Hey,

I've released MKVToolNix 6.5.0. One new feature is present: support for the VP9 video codec (reading it from IVF and Matroska/WebM files, extracting it into IVF files). A German translation of the man pages has been added as well. Several minor bugs have been fixed here and there.

For package maintainers nothing has changed compared to 6.4.1.

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.4.1:

2013-10-19 Moritz Bunkus <moritz@bunkus.org>
* Released v6.5.0.
* mkvmerge: enhancement: filler NALUs will now be removed from framed h.264/AVC tracks (such as the ones read from Matroska/MP4 files) just like they have already been when handling unframed tracks.
* mkvextract: new feature: implemented support for extracting VP9 tracks into IVF files.
* mkvmerge: new feature: implemented support for VP9 read from IVF and Matroska/WebM files. Implements #899 (https://www.bunkus.org/trac/ticket/899).
* mkvextract: enhancement: using the same track/attachment ID multiple times in "tracks", "attachments" or "timecodes_v2" mode will result in an error message instead of one empty file. Implements #914 (https://www.bunkus.org/trac/ticket/914).
* mmg: bug fix: With wxWidgets 2.9.x/3.0.x debug message will no longer appear as modal dialogs but only go to the log window.

2013-10-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed a crash when reading empty global tag files. Fixes #921 (https://www.bunkus.org/trac/ticket/921).

2013-10-17 Moritz Bunkus <moritz@bunkus.org>
* build system: bug fix: fix autodetection of Boost's library path if it is installed in the multiarch directories (e.g. /usr/lib/i386-linux-gnu or /usr/lib/x86_64-linux-gnu).

2013-10-04 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: saved window widths were growing by 1 pixel each time mmg was exited.

2013-10-03 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a German translation of the man pages by Chris Leick (see AUTHORS).

2013-10-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Reading OGM files with chapter entries not encoded in the system's local character set has been fixed. During identification the number of chapter entries is still output by removing any non-ASCII characters from the chapter entries. When muxing an additional warning is output if parsing those chapter entries fails, e.g. due to the format being wrong or due to the charset guessed wrongly. Fixes #919 (https://www.bunkus.org/trac/ticket/919).

2013-09-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The "duration" element was calculated wrong if the first element in the file wasn't the one with the smallest timestamp. To be precise, it was too short by the difference between the first timestamp and the smallest one (e.g with video sequences timestamped 80ms, 0ms, 40ms, 120ms... the duration was 80ms too short).

Have fun.

[filler56789]

^ Many :thanks:

[Selur]

Nice!! Any news regarding the support of HEVC?
"support for the VP9 video codec" -> is it now also supported to mux VP9 inside webm?

[Mosu]

Nice!! Any news regarding the support of HEVC?

HEVC is mostly finished (from the specs perspective), and I plan to work on merging the patches written by DivX within the next couple of weeks.

"support for the VP9 video codec" -> is it now also supported to mux VP9 inside webm?

VP9 is indeed supported for WebM, both as input and output.

[Mosu]

PS: There were two reasons why I chose to work on VP9 first:

1. It's dead easy to support (from a container point of view). It's format is so simple that muxing it is trivial. There are no B frames (hence no re-ordering of pictures in order to get the time frames right); the frame type distinction is done with a single bit at a fixed position within the very first byte of each frame; the IVF file format is so simple to parse that it's not even funny. Contrasting this with the sheer amount of work required to get h.264 or h.265 makes we weep with joy (or frustration if I think about the work still ahead of me with those formats).
2. It's a free format. That's always worth prioritizing higher.

[Selur]

Thanks for the info. :)

[sneaker_ger]

Anyone else getting a strange looking GUI?
http://abload.de/img/mkvmerge650_5kp2y.png

[Mosu]

It's built with wxWidgets 2.9.5 now, not 2.8.x anymore. Yes, it looks different, but as wxWidgets 3.0.0 is just around the corner (the release candidate 1 is just a week old) you'll have to get used to it. It's that high because the "global" tab requires that much space.

[DragonQ]

I get the same GUI as sneaker_ger with v6.5.0. There's no track list, so there's no way to edit any of the tracks when you add a file. Reverting to v6.4.1!

[Mosu]

Woah... you're right, of course. Damn.

Edit: needless to say that this does not happen no Linux. I hate this toolkit… anyway, investigating.

[john33]

Actually, if you stretch the window to the height of the screen, you do get the track list, not ideal though. ;)

[Mosu]

I've re-built against the older wxWidgets again. This is the fastest way to get a properly working build out there. I'll fix the issue with the newer wxWidgets for the next release.

The version number remains unchanged, as do the file names. I've updated the check sum lists (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows) for the new builds and uploaded them to FossHub (http://www.fosshub.com/MKVToolNix.html).

[Sparktank]

Thanks for the fix. GUI has been restored.

[filler56789]

I've re-built against the older wxWidgets again.

:thanks: ( again :) )

The version number remains unchanged, as do the file names.

Are you sure of that? :confused:

http://www.fosshub.com/download/mkvtoolnix-unicode-6.5.0-1.7z

[Mosu]

That's the file name, not the version number. I've decided to make the file name different than before in order to make distinction easier. It's also explained here (https://trac.bunkus.org/wiki/KnownIssues).

[tObber166]

Why doesn't Drag n Drop work with the portable version?

Did not work with 6.4.1 version either.

[Mosu]

I don't know. The code is exactly the same for both programs; the only difference is the packaging.

[Thunderbolt8]

2. It's a free format. That's always worth prioritizing higher.isnt H.265 free as well?

[Mosu]

No. Not in the sense that I consider »free«. At most as in »people may use DEcoders for it without charge for the time being«. At least that's what they did with h.264. But that's not what I mean:


specs available free of charge for any use
encoder/decoder reference implementation free of charge for any use (preferably under an OpenSource license)
no royalties for any kind of use, neither now nor ever
as free of third party patents as possible

The last point is debatable for VP9, of course, but h.26x is much, much more patent-encumbered.

[filler56789]

Why doesn't Drag n Drop work with the portable version?

Did not work with 6.4.1 version either.

Drag-and-drop does work as expected with version 6.5.0(-1) over here. Perhaps your system just went b0rked somehow? :confused:

[tObber166]

Drag-and-drop does work as expected with version 6.5.0(-1) over here. Perhaps your system just went b0rked somehow? :confused:

Are you using portable version?

[the_weirdo]

Are you using portable version?

I'm using portable version and I can drag-n-drop just fine.

[tObber166]

Find the solution, sorry for the inconvenience

Had the MKVExtractGUI.exe file in the same folder which caused the issue, lol :D
As soon as i remove it, Drag n Drop works :)


To bad the "MKVExtractGUI-2 2.2.2.8" doesn't work anymore

[Chetwood]

No drag and drop issues with the portable version (.7z) of 6.5.0 on Win 7 64bit with MKVExtractGUI2.exe (2.2.2.8) in the folder.

[tObber166]

Well, dont know what the problem was.
But redownload MKVExtractGUI and now it works :D

/cheers

[filler56789]

Just out of curiosity :)

the next release of MKVtoolnix, will it use the CodecID "V_MPEGH/ISO/HEVC" (from the Rovi people), OR will it use "something else" (for example, V_H265 or V_HEVC)?

[JEEB]

Just out of curiosity :)

the next release of MKVtoolnix, will it use the CodecID "V_MPEGH/ISO/HEVC" (from the Rovi people), OR will it use "something else" (for example, V_H265 or V_HEVC)?
Both sides seem to have agreed on this (http://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html). The CodecID was proposed originally by Rovi/DivX (although you could hardly call it a surprising turn of events as it just follows the same way Haali set the CodecID for AVC/H.264), but the actual request to follow 14496-15 3rd ed extradata came from matroska-devel (and surprisingly Rovi/DivX actually listened).

Rovi/DivX's documentation on the muxing is much less specific (they updated their side just after that e-mail as well), and thus I recommend people depend on that post as well as the newest version of 14496-15 for the details. After Rovi/DivX posted their version, I did a quick review (http://lists.matroska.org/pipermail/matroska-devel/2013-September/004575.html) on possible differences, and later their HEVC muxing patch was adapted (https://github.com/jaya-divx/mkvtoolnix/commit/c8fca4e19722f74259f61bba758a86a8eb4cfc92) accordingly.

I have not generally reviewed their code yet, but it seems like it does create files that seem to more or less confine within the specification.

[filler56789]

^ That's good-news, JEEB :thanks:

Because now, LAV Filters "understand" :) the file
"TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11_AC3_7Subs (1)-003.mkv"
(post #37 in http://dev.mpc-next.ru/index.php/topic,1787.30.html),

even though on 2013/09/07 nevcairiel had written
There is no standard for HEVC in MKV yet, and until there is, LAV will not support it.
And once there is, the DivX MKV files will not be compatible with the standard anyway.

Such a company should not invent their own format, instead coordinate with the Matroska developers. Their old files will in the future most likely not play properly in compliant players.

[Mosu]

Yes, it will be V_MPEGH/ISO/HEVC. JEEB has pointed out all the important pieces of information on how the discussion happened. I'm very glad that the Rovi people worked so well with us, but I strongly dislike them using the final CodecID for experimental versions of the format. Unfortunately there is no official recommendation for this from the Matroska side; I chose to append /EXPERIMENTAL for such cases (e.g. A_OPUS/EXPERIMENTAL). Yes I'm part of that team, but not everything I do becomes official automatically ;)

[nevcairiel]

even though on 2013/09/07 nevcairiel had written

That was before DivX updated their muxing to the official standard. :p

[JEEB]

14496-15 3rd ed and Annex B extradata are both supported with libavcodec, and most matroska demuxers will just throw the extradata and blocks' contents at the decoder. Pretty much same as with AVC/H.264. So yes, the current version of how to mux should be supported.

Because now, LAV Filters "understand" :) the file
"TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11_AC3_7Subs (1)-003.mkv"
(post #37 in http://dev.mpc-next.ru/index.php/topic,1787.30.html),

Meanwhile, this file you linked... Ugh... Open up that matroska file in a hex editor and ctrl+F for 0x63 0xA2 (CodecPrivate structure). One should pop up just after the CodecID. The next byte minus its most significant bit will be the length of this element (as specified per this page (http://matroska.org/technical/specs/index.html), since the most significant bit is set to 1). Now take the CodecPrivate listing I've noted and start going through the data. You should notice that something isn't exactly right quite soon. Although as far as I can see, if you don't really parse the structure and instead just check for the first byte(s) and then jump to the stuff you actually "need" for decoding, it actually ends up looking like nothing is wrong...

configurationVersion is set to 1, which is according to 14496-15 3rd ed (although against the "until 14496-15 3rd ed is released, please set to zero" recommendation), and then if you jump to lengthSizeMinusOne that seems to be 3, which means 4 byte lengths for data in the blocks. This happens to be exactly what DivX's code tended to do at all points.

Then you read the next byte for numOfArrays and you get a zero. Which means that there should be no further data in this structure (you would generally have VPS, SPS and PPS in the extradata). But it's quite obvious there still is data in there, so I'd say this is actually muxed according to the old Rovi/DivX patch, but just happens to work (there are VPS/SPS/PPS in the actual in-band data? Otherwise the stream would actually be impossible to decode). This is an invalid file, unfortunately.

This is what ends up happening when /EXPERIMENTAL isn't used, and different types of muxing not versioned (/EXPERIMENTAL1|2|3 or whatever).

[Boulder]

Wavpack files encoded with the option "--optimize-mono" are not recognized by mkvmerge. The error message is "The file header was not read correctly."

[Mosu]

Wavpack doesn't really have any priority for me. Sorry. See also this issue with Wavpack (https://trac.bunkus.org/ticket/859) that will likely not get fixed.

If you want any chance of me fixing this then please open a new ticket in my bug tracker (https://trac.bunkus.org/) and upload a sample file to my FTP server (see signature). I may get bored and take a look at it some time.

[vmrsss]

Hi Mosu, is mkvtoolnix expected to build with clang? Up to 6.4.1 I was able to build on a mac using a self-complied gcc-4.6.2, now the build of 6.5.0 fails because of linking problems (I suspect due to mismatch with libraries built with clang). Then I gave mkvtoolnix a go with clang Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn), and get the following error, which looks pretty fatal! Any comments? Thanks.

In file included from src/common/command_line.cpp:14:
In file included from src/common/common_pch.h:4:
In file included from src/common/common.h:29:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/vector:1825:21: fatal error:
object of type 'boost::filter_iterator<<lambda at
src/common/command_line.cpp:295:74>,
boost::transform_iterator<boost::range_detail::select_first<std::__1::map<std::__1::basic_string<char>,
std::__1::basic_string<char>, std::__1::less<std::__1::basic_string<char> >,
std::__1::allocator<std::__1::pair<const std::__1::basic_string<char>,
std::__1::basic_string<char> > > > >,
std::__1::__map_const_iterator<std::__1::__tree_const_iterator<std::__1::pair<std::__1::basic_string<char>,
std::__1::basic_string<char> >, const
std::__1::__tree_node<std::__1::pair<std::__1::basic_string<char>,
std::__1::basic_string<char> >, void *> *, long> >, boost::use_default,
boost::use_default> >' cannot be assigned because its copy assignment
operator is implicitly deleted
__m = __first;

[Mosu]

I'm developing solely with clang, so yes, it does work. At least on Linux. I'm also running a continuous-integration server that builds each and every commit with clang, gcc and my mingw cross compilers.

I cannot help you with Mac OS build problems, especially not with libraries compiled with different compilers. Sorry.

[vmrsss]

Thanks Mosu, so have you got no idea on what the cause of the error " __m = __first;" might be? Then, I hope in some Mac user reading this post.

[Thunderbolt8]

does drag & drop not work anymore with windows 8.1? when I try to drag input files from explorer into mkvmerge, I only get this forbidden/not possible symbol.

[Mosu]

Just as possible as before. Just don't start the program with administrative privileges and drag from an application started without admin privileges.

[Thunderbolt8]

well that was it, thanks.

[Sakura-chan]

I just need to ask this thing. Why releases have names? Like "Omega Point" for 6.4.1 and "Isn't she lovely" for 6.5.0. Who comes up with those? Mosu? Any reason and/or logic behind the names? Or just something random that comes to mind when releasing a new version? I've seen names for other things. Ubuntu has adjective + animal, both starting with the same letter going in alphabetical order or something like that. But for mkvtoolnix it seems too random.

Anyway, I like names. Gives each release a bit more love and personality <3. Like installing a new version and discovering what the name is. I know, I'm probably stupid :P