View Full Version : MKVToolNix v24.0.0 released
Mosu
19th October 2015, 18:05
As long as I can copy from there that would be an improvement.
I've implemented both changes that I've talked about. Here's the corresponding ChangeLog entry:
* MKVToolNix GUI: header editor enhancement: several track
properties like name or language are shown as columns in the tree
for easier distinction between tracks. They're also shown on the
overview page on the right when that track's entry is selected in
the tree. The text in the labels on this overview page can be
selected with the mouse for copying & pasting elsewhere.
Identifying which track to click on and copying & pasting the track name will be easier with these changes, and I hope they can help you with your workflow a bit, too.
A small tip: you can select the whole label for a property by triple-clicking on it, even across spaces and other non-word characters.
I'd appreciate some testing & feedback. You can get new pre-builds from here (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/); build numbers 986 and higher contain the change.
How difficult would providing a dropdown box with a list of custom entries to choose from in the name section be? Too hard?
If you don't need all those columns then remember you can hide them by right-clicking on the column labels (or re-order them via drag & drop). Those changes are remembered across restarts, of course.
ndjamena
20th October 2015, 13:55
I got half way through my current batch before I found the first movie that it turned out to be useful. It does help. I remember even before deleting my batch having to have MediaInfo and the MMG Header Editor open at the same time so I could copy/paste track names at least this is better than that.
Oh, right, one thing I've always noticed was missing in the header editors was the ability to simply remove the header for a track completely like MakeMKV does with empty forced tracks. At the moment I'm just setting the subtitles I don't want to "fre" so that they'll be removed when I remux them but nuking the header completely would be better.
Would that be something you'd be willing to implement or would that be too dangerous? Do players generally care if they come across blocks for tracks they can't identify?
( Sword and the Stone has both normal and SDH forced tracks... I'm currently trying to figure out what the hell to call the SDH one... English Translations SDH - PGS..? Maybe I should have been calling the SDH tracks "English Main SDH - PGS", then I'd already have a protocol in place for when I'm ripping SDH commentary tracks... English (UK) Translations SDH (CC) - PGS )
*sigh*
Mosu
20th October 2015, 14:00
Thanks for the feedback, ndjamena.
Oh, right, one thing I've always noticed was missing in the header editors was the ability to simply remove the header for a track completely like MakeMKV does with empty forced tracks. At the moment I'm just setting the subtitles I don't want to "fre" so that they'll be removed when I remux them but nuking the header completely would be better.
Would that be something you'd be willing to implement or would that be too dangerous? Do players generally care if they come across blocks for tracks they can't identify?
To be honest I don't know of a player that would choke on finding content for a track number for which corresponding track headers exist, but I'd rather not risk it. My past experience with Matroska players (especially with hardware devices) is really bad – the slightest problem (more likely: unanticipated situation) can throw them off. If I provide such a mechanism then I'm more or less condoning the creation of invalid files, or ones whose validity is highly questionable.
Note that mkvmerge will emit a warning for each block group for which no corresponding track header was found as such a situation usually indicates file corruption.
Can't you just set the Enabled flag of those tracks to 0?
ndjamena
20th October 2015, 14:53
That's interesting, MPC-HT actually obeys the enabled flag. Nothing else does.
Really I'm just looking for a way to tell a remuxer NOT to remux the track, my batch used to rename them as "###REMOVE###", but that only works when used alongside my remuxing batch. MediaInfo doesn't read the enabled flag so, that's no good. Interestingly both MKVToolNixGUI AND MakeMKV can remove tracks automatically based on language, it's just that nuking the header would be more efficient and I wouldn't have to look at them. It doesn't help that I feel like I'm insulting any language that I happen to select for the purpose.
It's not important.
SeeMoreDigital
20th October 2015, 18:01
My past experience with Matroska players (especially with hardware devices) is really bad – the slightest problem (more likely: unanticipated situation) can throw them off.Indeed...
There are more hardware playback devices than ever capable of supporting the Matroska container, including televisions. And TV manufacturers are pretty bad at offering updates when third-party software developers decide to change the way their software's function.
It's bad enough getting TV manufacturers to support YouTube app changes :eek:
Mosu
21st October 2015, 13:15
I've released MKVToolNix v8.5.1 only four days after 8.5.0. The reason is that Cisco's Talos Research Group has found several cases of invalid memory access and instances of freeing memory twice in libEBML (TALOS-CAN-0036, TALOS-CAN-0037). The consequences range from heap information disclosure to denial of service.
Those issues have been fixed along with some more cases of invalid memory access discovered while investigating the TALOS-CAN reports. New releases of libEBML (v1.3.3) and libMatroska (v1.4.4) were made yesterday (http://lists.matroska.org/pipermail/matroska-users/2015-October/006985.html). Today's release of MKVToolNix incorporates both updated libraries, and its build system requires at least those versions if you want to use globally-installed copies.
As MKVToolNix and therefore both libEBML and libMatroska are often used to process content from arbitrary sources I highly recommend everyone to upgrade.
Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).
All binaries that I provide have been uploaded already.
Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:
2015-10-21 Moritz Bunkus <moritz@bunkus.org>
* Released v8.5.1.
2015-10-20 Moritz Bunkus <moritz@bunkus.org>
* build system: libEBML v1.3.3 and libMatroska v1.4.4 are now required due to important fixes for invalid memory accesses in those two releases. The copies included in the MKVToolNix source code have been updated to those releases as well.
2015-10-19 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the "save file" dialogs did not have the currently entered file name pre-selected anymore. Fixes #1480 (https://github.com/mbunkus/mkvtoolnix/issues/1480).
* MKVToolNix GUI: header editor enhancement: several track properties like name or language are shown as columns in the tree for easier distinction between tracks. They're also shown on the overview page on the right when that track's entry is selected in the tree. The text in the labels on this overview page can be selected with the mouse for copying & pasting elsewhere.
2015-10-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed a crash when loading corrupted job settings.
* MKVToolNix GUI: header editor bug fix: the tree items weren't re-translated when the GUI language was changed.
* mkvmerge: bug fix: updating the track headers wasn't working in some rare cases (corresponding error message "Re-rendering track headers: data_size != 0 not implemented yet").
2015-10-17 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix (Linux): the function "open folder" was inserting a superfluous leading slash in the directory name. This causes some file managers (in this particular case Dolphin on Linux) to interpret a directory name like "//home/mosu/…" as a share called "mosu" on a Samba/Windows server called "home" and to prepend the whole name with the "smb://" protocol. Fixes #1479 (https://github.com/mbunkus/mkvtoolnix/issues/1479).
Have fun.
Atak_Snajpera
21st October 2015, 16:14
Question: Is there any reason why you don't use ULTRA preset in 7-zip while compressing portable version? Your 7z file is 15,5 MiB but with ULTRA preset you can reduce size even down to 11 MiB.
Mosu
21st October 2015, 16:17
The reason is that I don't care that much about the size. It already takes too long to compress the archives, especially when I build ten or twelve a day.
ndjamena
21st October 2015, 17:01
Can I just voice a minor annoyance.
When MKVToolNixGUI informs me that a new version is out it gives a link to the download page here:
https://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows
That's not the actual link it provides, it would be nice if it would automatically append the #windows bit (or appropriate OS).
But that's not the problem. The problem is that page gives four separate versions to download, and of course each time I get there I sit and take the time to figure out which one I need to click, effort which is ultimately wasted because all four links go to the same page.
http://www.fosshub.com/MKVToolNix.html
And then I have to repeat the process again to begin the download. I feel like a sucker each time...
Since they all go to the same place anyway, would it be too much to ask for one, single, clearly marked download link so I don't have to feel like I'm playing mind games with the website?
Atak_Snajpera
21st October 2015, 17:02
The reason is that I don't care that much about the size. It already takes too long to compress the archives, especially when I build ten or twelve a day.
I do not know what you have there but difference between Normal vs ULTRA on my cpu is only 2 seconds (15s vs 17s). 7-zip most of the time uses only two cores while compressing mkvtoolnix so you do not need expensive i7 cpus at all.
Mosu
21st October 2015, 18:28
Atak_Snajpera: When I said that I don't care about size then I meant that I haven't even tried to measure it. Because I don't care about the size.
Mosu
21st October 2015, 18:30
ndjamena: Well, that was easy to change. Done.
Jamaika
21st October 2015, 18:39
OK. I understand now that "zlib" is an addition to advertising. Indeed, these are trifles finishing, which need a bit more memory when displaying subtitles. I wanted to ask, is it possible to pack text in global-tags.xml?
Mosu
21st October 2015, 18:43
Uhm… what!? I honestly don't understand you're talking about, never mind what you're actually asking, Jamaika.
Jamaika
21st October 2015, 18:48
Uhm… what!? I don't understand you're reading about, Mosu. I thought talking about functions --compression zlib. Good night.
Mosu
21st October 2015, 18:49
If you're asking whether or not you can compress tags: you can't. The Matroska spec only has provisions for compressed track content.
Jamaika
21st October 2015, 18:58
I am surprised, because in the container ASS are additives fonts and images. They can be encoded and aren't track content.
Mosu
21st October 2015, 19:00
Matroska doesn't care about the _content_ of attachments. Its interpretation is up to the application using those attachments. If an applications supports using e.g. attached compressed fonts then that's great, but Matroska doesn't have anything to do with that.
Mosu
21st October 2015, 20:08
Question: Is there any reason why you don't use ULTRA preset in 7-zip while compressing portable version? Your 7z file is 15,5 MiB but with ULTRA preset you can reduce size even down to 11 MiB.
Looks like I was wrong. There obviously was a time when I cared about this enough to devise the following options for compression:
-t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on
I'm pretty sure that this is from back when 7z didn't support lzma2. I'll replace all of those by -mx=9 which means that my current p7zip will default to lzma2 achieving better compression.
Carpo
21st October 2015, 20:17
think you need to add -m0=lzma2 to make it use lzma2, don't think -mx9 on its own selects it, unless the newer 7zip 15.x version has changed it, still using 9.20 myself
Mosu
21st October 2015, 20:39
p7zip 9.38 beta here, and the docs have this to say about -mx=…:
x=[0 | 1 | 3 | 5 | 7 | 9 ]
Sets level of compression
Level Method Dictionary FastBytes MatchFinder Filter Description
0 Copy No compression.
1 LZMA2 64 KB 32 HC4 BCJ Fastest compressing
3 LZMA2 1 MB 32 HC4 BCJ Fast compressing
5 LZMA2 16 MB 32 BT4 BCJ Normal compressing
7 LZMA2 32 MB 64 BT4 BCJ Maximum compressing
9 LZMA2 64 MB 64 BT4 BCJ2 Ultra compressing
Note: "x" works as "x=9".
A short test confirmed that "-mx=9" and "-mx=9 -m0=lzma2" produce identical results.
Carpo
21st October 2015, 20:43
Ah well, as long as it works :)
Mosu
21st October 2015, 20:48
My thoughts exactly :)
magsoud
22nd October 2015, 09:03
Please Add Use Registry to store Settings...
Mosu
22nd October 2015, 09:09
If you use the installed version then the settings will be stored in the registry. That's the main point for a portable version: it doesn't store settings in the registry allowing you to have the full installation on a portable device.
magsoud
22nd October 2015, 10:06
If you use the installed version then the settings will be stored in the registry. That's the main point for a portable version: it doesn't store settings in the registry allowing you to have the full installation on a portable device.
Settings Store to:
"%LocalAppData%\bunkus.org\mkvtoolnix-gui\mkvtoolnix-gui.ini"
Mosu
22nd October 2015, 10:34
Ah you're right. Earlier versions used to store to the registry. I changed that intentionally due to performance reasons. I see no reason to change that back.
foxyshadis
22nd October 2015, 14:20
magsood, what's the use case of changing to registry vs. known file for settings?
Altober
24th October 2015, 22:47
Hi:
Like always... Thanks! For your great software and for your time for answers questions here.
My problem is this:
I have a shared folder in local LAN for can access through Smart TV or any Android device (Smartphone, Notebook, Tablet, etc).
I like so much watch video series from my bed :)
Well, my problem is... All my MKV videos maked for older versions I can watch through my LAN, is NOT necessary the video copy to my portable (Android) device.
But when I try to play my MKV videos maked with new MKVtoolnix versions always I obtain "Is impossible to play this video".
I try with many (the bests) Android Video Players (MX Player, VLC, etc)
First I think in some error in MKV file, then I proceed to copy these videos to my portable Android device, then YES, I can watch this videos.
Is very important to me can access directly to my MKV videos, without copy this videos to my device, but I not understand where is the problem.
I hope you can help me.
Thanks So Much
Edit (New Data):
I have downloaded Supernatural Episode (mkv file, of course) with mkvmerge v8.4.0 ('A better way to fly') 64bit / libebml v1.3.1 + libmatroska v1.4.2
And I CAN watch trough LAN net wihout problems...
But I have previous episode maked with the same mkvmerge version (v8.4.0 ('A better way to fly') 64bit / libebml v1.3.1 + libmatroska v1.4.2)
AND NOT, impossible to watch... The problem are the videos re-processed by me :-(
I can see some "rare here"
Downloaded Video
Lenght: 41 minutes
1.70Gb
NUMBER_OF_FRAMES: 78035
NUMBER_OF_BYTES: 119861760
Re-Processed Video
Lenght: 43 minutes
2.02Gb
NUMBER_OF_FRAMES: 541
NUMBER_OF_BYTES: 16511
O_O "My" video have VERY few frames and very few bytes!!
Really I don't understand. I think this could that be the problem? Really I don't know.
sneaker_ger
24th October 2015, 22:52
Try:
Go to output tab, add additional options (bottom right): --clusters-in-meta-seek --engage no_cue_duration --engage no_cue_relative_position
That way output is more like that of older versions and works in most players.
For further information see https://github.com/mbunkus/mkvtoolnix/wiki/Improving-playback-compatibility-with-players
If that isn't enough compare working and non-working files in MediaInfo and look for differences.
Altober
24th October 2015, 23:44
Thanks sneaker_ger:
No, unfortunately I made a new MKV video from "working MKV" (Of course I save original video in another folder)... and not.
Not work.
I have Mediainfo date, some differences are in "Edit" section of my original message.
If you want (and if is possible) I can upload complete Mediainfo information of "work" and "no-work" videos.
My doubt is because this board not can (or I not found) Spoiler function, and Mediainfo have too much text :confused:
Thanks for your help
Edit
The answer to my problem is very close...
I obtain the same MKVToolmix version that already I have, but in portable version
I proceed to make a "working" MKV and the new MKV work too.
Now I have "one to one" the checked options for found the "problematic" option.
ndjamena
25th October 2015, 04:21
What are you using to look at the Tags?
MediaInfo applies tags to the wrong tracks (or to the file) if UIDs don't match Track Numbers.
FFProbe is the best way of looking at tags I know of.
Jamaika
25th October 2015, 08:34
First, you can examine and separate tracks old movie for the help MKVextract. Followed merge the latest muxer v8.5.1.
If this doesn't help, put mkvmerge and reapply the latest ffmpeg. It should be fine.
NailBomber
25th October 2015, 12:40
Apologies if that's an incorrect thread to ask for help.
I have a recorded stream of youtube that's according to MediaInfo is MPEG-TS container with AVC video inside. The video has a seeking problem and wrong duration. Until this point I fixed such videos by remuxing them through MKVToolNix into a mkv, but this time I got a new problem when viewing resulting mkv - gray block artifacts: http://s013.radikal.ru/i325/1510/af/7d1a62646eac.jpg
Is there options in MKVToolNix I can use to remove such artifacts or is the video unsalvageable?
magsoud
3rd November 2015, 17:02
one suggestion for MKVtoolnix:
When we click on "Start muxing", automatically displayed "job output" page.
Mosu
3rd November 2015, 17:06
Preferences → "GUI" tab → "Jobs and job output" → "Always switch to the job output tool after starting one immediately"
magsoud
3rd November 2015, 17:42
Preferences → "GUI" tab → "Jobs and job output" → "Always switch to the job output tool after starting one immediately"
Thanks Mosuhttp://i47.tinypic.com/2dvsw2p.gif
Mosu
4th November 2015, 23:47
Hey,
Here's another release of MKVToolNix, v8.5.2, a couple of days after 8.5.1. This time a bug in the HEVC/h.265 handling has been fixed that quite a lot of users seem to be hitting.
All binaries that I provide have been uploaded already.
Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:
2015-11-04 Moritz Bunkus <moritz@bunkus.org>
* Released v8.5.2.
2015-11-03 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the file/track columns aren't resized to fit their content when expanding/collapsing tree nodes anymore. Such expansion also happened when moving entries with the "move up/down" buttons. Fixes #1492 (https://github.com/mbunkus/mkvtoolnix/issues/1492).
* mkvmerge: bug fix: fixed the values of the "previous/next segment UID" elements when splitting by parts with segment linking enabled. Fixes #1497 (https://github.com/mbunkus/mkvtoolnix/issues/1497).
* mkvmerge: bug fix: mkvmerge no longer creates a "next segment UID" field in the last file when splitting and segment linking is active.
2015-10-22 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, MKVToolNix GUI header editor: enhancement: added the "codec delay" track header field as an editable property.
* mkvmerge: bug fix: fixed an endless loop when updating track headers caused by the fix for "Re-rendering track headers: data_size != 0 not implemented yet". Fixes #1485 (https://github.com/mbunkus/mkvtoolnix/issues/1485).
Have fun.
mariner
5th November 2015, 11:54
Sorry, but I cannot help you with that. That's tsmuxer's problem.
Thanks for the kind reply, Mosu.
Raw PCM audio is detected by mkvmerge as video. Is it supported?
Mosu
5th November 2015, 12:21
No, it isn't. It must be in a container, e. g. WAV.
mariush
5th November 2015, 21:31
Mosu.. if i may make a small suggestion. Maybe you could add an option or something to show the properties panel in mkvtoolnix gui in two columns instead of a huge single column that often requires scroll. In today's world where people have 16:9 monitors with lots of horizontal width, the gui is stuck at about 950 pixels minimum width.
I'd say probably 80-90% of the people out there have at least 1366x768 displays so you could stretch the minimum width a bit, or make a horizontal scroll bar at the bottom of the properties section.
I know about "use a vertical layout for the input tab" in the options, but if enabled I'd say it's a tradeoff or even a step backwards because now user has to click on each of those 5 tabs to see what he can change, while before he could see everything with a scroll.
Here's a quick mock-up in mspaint of what I mean : http://savedonthe.net/image/2456/example.png
In the picture, the width is 1351 pixels which is a bit much, but if the verticall scrollbar for the properties is removed and the individual columns are just a bit squeezed, it may even fit on 1280x800 lcd displays without resorting to horizontal scrollbar.
The height will also not be a an issue, right now the gui goes down to 650 pixels and the layout in the picture would only need 30-50 pixels more, still safe for 768-800 pixel high monitors.
Mosu
5th November 2015, 22:39
Thanks for the suggestion. That idea isn't half bad. I'll think about it.
73ChargerFan
7th November 2015, 22:08
I LOVE SPLIT BY CHAPTERS! I submitted issue #1500 on GitHub because it split a little bit early and also each file except the last incorrectly included the first chapter name from the following file.
LeMoi
8th November 2015, 11:52
When I open a mtxcfg file directly by double-clicking on it, it opens the MKVtoolnix GUI with 2 tabs, one empty and the other one with the config file. Is it possible to make only the configured tab open, and not an empty one next to it?
Mosu
8th November 2015, 18:46
Possible? Sure, but that's a purely cosmetic issue. Please don't expect a timely fix, and please open an issue on Github for it – otherwise it will likely be forgotten.
LeMoi
9th November 2015, 00:21
I'll do, thanks in advance.
And would it be also possible to make the Ctrl-F4 shortcut close the current tab? I like using shortcut, and i noticed that this one doesn't close the current tab!
Mosu
9th November 2015, 09:02
You can close the current tab with Ctrl+w.
ndjamena
9th November 2015, 09:48
http://forum.videohelp.com/threads/375118-MKVToolNix?p=2418063&viewfull=1#post2418063
:)
LeMoi
9th November 2015, 17:43
You can close the current tab with Ctrl+w.
Thanks for the tip!
ndjamena
10th November 2015, 11:37
Now that MediaInfo should be getting proper tag handling in the next version...
What's the chance of adding a mode in MKVInfo or MKVPropEdit that adds the statistics tags to files that otherwise have none... just for the benefit of those people who chose to remove them or are using mkvs from a different muxer.
It would be nice when people start complaining on forums to be able to give them a method to add the tags that doesn't involve recreating the entire file.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.