MKVToolNix v24.0.0 released

[loekf]

Yes it is. That's why many and more and more people don't understand why it's enabled by default.
There are actually more cons than pros for this useless and annoying feature.

+1

I only found out about this after I got some movies, which resulted in no audio on my mediaplayer.

I have no problems making the implementation of a standard feature complete, but make it an option, switch if off by default.

[Mosu]

It has been switched off for the past four years. Still a lot of players/demuxers did not implement support for it. No, I'm not willing to reconsider or argue about it.

[Zenitram]

if i specificially instruct mkvmerge to set a track language to "eng", i kinda expect it to do so

...and mkvmerge does what you want: it sets the track language to "eng", ie it removes the track language from the file, because the specification says "no track language = eng".

while i have no problem with mkvmerge using "und" when no language is specified for a track, i do not understand its current behaviour...

It is conform to specs: eng is the default value if there is no track language. mkvmerge is conform to specifications.
I don't like this default value (default value should be "und"! why English?), but this is not mkvmerge fault, this is Matroska fault, you should blame Matroska for this. And you should blame other developpers not conforming to specifications.

It has been switched off for the past four years. Still a lot of players/demuxers did not implement support for it. No, I'm not willing to reconsider or argue about it.

And I am happy with this! This is a good demo for showing the flaw of my coding vs specifications! We were a lot not reading enough specifications (mainly the default values), this is a good motivation to change this.

[Daemon404]

Sorry if this has been posted/asked already, but I noticed mkvinfo no longer outputs attachment info from files created by newer versions mkvmerge (how new im not sure). Older files (I tested one created 2.9.8) display them file in mkvinfo.

[Mosu]

See http://forum.doom9.org/showthread.php?p=1425081#post1425081

Also note that mkvinfo's normal mode (without any "-v" or "--verbose") stops parsing when it encounters the first cluster. From your question I guess that what you really need is "mkvmerge --identify-verbose yourfile.mkv" instead of mkvinfo.

[Daemon404]

See http://forum.doom9.org/showthread.php?p=1425081#post1425081

Also note that mkvinfo's normal mode (without any "-v" or "--verbose") stops parsing when it encounters the first cluster. From your question I guess that what you really need is "mkvmerge --identify-verbose yourfile.mkv" instead of mkvinfo.

I've been using mvkmerge to do that for ages, but I just wondered why mkvinfo stopped displaying 'em.

[jasonwc]

It's a bug in the DivX thumbnailer creator thats installed with the DivX codecs. I checked through the registry to see what ShellEx were being used for MKV files in explorer and found it, i uninstalled the DivX package and the problem is gone, of course i dont get thumbnails but i wasnt bothered about them either.

Im sorry to have wasted your time :(

I reported this issue to Divx on their support page and a ticket has been opened. Let's see if a fix is forthcoming. Unfortunately, DivX is the only provider of a Mediafoundation filter for Windows 7. Without their filter, there is no way to get thumbnail support and other basic media attributes (e.g. duration, bitrate) to display in Windows Explorer.

[SamuriHL]

I reported this issue to Divx on their support page and a ticket has been opened. Let's see if a fix is forthcoming. Unfortunately, DivX is the only provider of a Mediafoundation filter for Windows 7. Without their filter, there is no way to get thumbnail support and other basic media attributes (e.g. duration, bitrate) to display in Windows Explorer.

Good luck with that. It's been an issue for years and they've never seen fit to fix it.

[jasonwc]

Good luck with that. It's been an issue for years and they've never seen fit to fix it.

Years? The problem appears to be the thumbnail generator breaking due to AVC header compression which wasn't used until MKVMerge 4.2.0. Even if it was in the spec, they had no reason to implement it before.

[SamuriHL]

Years? The problem appears to be the thumbnail generator breaking due to AVC header compression which wasn't used until MKVMerge 4.2.0. Even if it was in the spec, they had no reason to implement it before.

Not that specific problem, no. But Divx has had thumbnail problems going back a LONG LONG time. There are numerous threads all over the Net about explorer crashing when divx is installed and you look at a folder of avi's or (now) mkv's with thumbnails turned on. They've never fixed it. A few months ago in the MakeMKV forum we were discussing it and the ways to get around it. Someone reported it to them and got an awesome response back from them about it. Complete silence. :)

[stax76]

I reported this issue to Divx on their support page and a ticket has been opened. Let's see if a fix is forthcoming. Unfortunately, DivX is the only provider of a Mediafoundation filter for Windows 7. Without their filter, there is no way to get thumbnail support and other basic media attributes (e.g. duration, bitrate) to display in Windows Explorer.

As far as I know the MS thumbnail component is DirectShow based and can be enabled for every file type, IIRC user CLSID posted about this long time ago.

[AzraelNewtype]

There's a bug in v4.2.0 that results in tracks from SSA/ASS files not being copied into the output file if you use mmg. This has been fixed in the following build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.2.0-build20100729-293-setup.exe


Would it be possible to release a new minor version bump (4.2.1?) for this build? My primary OS isn't Windows, and while I could circumvent my package manager and build from git by hand, it seems a little silly to do so in order to use an official bugfix rather than third party patch. I've had to downgrade all the way back to 3.4.0 to attach subtitles, as 4.1.1 (the only version in the middle still available in the manager) had a different bug that neither 4.2.0 nor 3.4.0 was exhibiting. Even on Windows it would probably cut down on the number of people coming in to ask about this already fixed bug anyway.

[Mosu]

As each release requires roughly six hours to compile everything with two hours of continuous work I don't release too often. mkvtoolnix is already on a rather active release schedule (four to six weeks between releases). That being said -- I was planning on releasing this or weekend or the weekend after anyway.

[Mosu]

Btw, compiling from Git into a package installable with your package manager is pretty easy, at least for Debian, Ubuntu, OpenSuSE and Fedora as I provide the build files for those distributions in the source tarball/Git repo.

[AzraelNewtype]

Oh, okay then. I'm perfectly comfortable compiling from source actually, it's just that when you manually inject files like that, portage (gentoo user) freaks out next time you attempt to install from the official sources again due to finding files it isn't expecting. The feature exists to keep your system sane/stable, but can drive you crazy if you try dancing around it.

I'll try actually doing the right thing then in that case in the interim and modify the official ebuild to grab git instead of the tarball.

Thanks.

[jasonwc]

Not that specific problem, no. But Divx has had thumbnail problems going back a LONG LONG time. There are numerous threads all over the Net about explorer crashing when divx is installed and you look at a folder of avi's or (now) mkv's with thumbnails turned on. They've never fixed it. A few months ago in the MakeMKV forum we were discussing it and the ways to get around it. Someone reported it to them and got an awesome response back from them about it. Complete silence. :)

There actually is a "fix" for the earlier AVI issues. The response I got from DivX told me to install it. It appears to disable thumbnail generation for AVI, so it doesn't fix the MKV crashes.

See http://support.divx.com/faq/view/supportFAQen001/The-DivX-All-In-One-Fix-V181

Explorer Crash When Opening a Folder

When opening a folder containing DivX or XviD .Avi files under some specific configurations, the thumbnail generation crash Windows Explorer. This option Disable the Thumbnail generation.

[jasonwc]

I reported this issue to Divx on their support page and a ticket has been opened. Let's see if a fix is forthcoming. Unfortunately, DivX is the only provider of a Mediafoundation filter for Windows 7. Without their filter, there is no way to get thumbnail support and other basic media attributes (e.g. duration, bitrate) to display in Windows Explorer.

There is actually a really easy "fix" for the Explorer crashing. It disables thumbnail generation for MKVs but all the other metadata works, which is why I installed the Media Foundation filter.

Go to the the folder:
C:\Program Files\DivX\DivX Plus Media Foundation Components

You need to rename one DLL:

DivXThumbnailProvider.dll

After that, MKV thumbnail generation will no longer work, but explorer won't crash either. :P

[SamuriHL]

There actually is a "fix" for the earlier AVI issues. The response I got from DivX told me to install it. It appears to disable thumbnail generation for AVI, so it doesn't fix the MKV crashes.

See http://support.divx.com/faq/view/supportFAQen001/The-DivX-All-In-One-Fix-V181

Explorer Crash When Opening a Folder

When opening a folder containing DivX or XviD .Avi files under some specific configurations, the thumbnail generation crash Windows Explorer. This option Disable the Thumbnail generation.

Fascinating. They should do the same for MKV's. Thanks for the info!

[SamuriHL]

There is actually a really easy "fix" for the Explorer crashing. It disables thumbnail generation for MKVs but all the other metadata works, which is why I installed the Media Foundation filter.

Go to the the folder:
C:\Program Files\DivX\DivX Plus Media Foundation Components

You need to rename one DLL:

DivXThumbnailProvider.dll

After that, MKV thumbnail generation will no longer work, but explorer won't crash either. :P

Right, that's the work around I saw on MakeMKV forum. I've still not had a chance to try it myself yet.

[jasonwc]

Right, that's the work around I saw on MakeMKV forum. I've still not had a chance to try it myself yet.

The MakeMKV forum also said to disable "DivXPropertyHandler.dll" which is responsible for providing all metadata for MKV files. However, the problem seems solely related to the DLL responsible for thumbnail creation. This way, I'm still able to get duration, bitrate and other metadata within Explorer, without the crashes.

I contacted Divx support and told them that disabling "DivXThumbnailProvider.dll" fixed the issue. Perhaps they'll add that to the compilation of fixes, or you know, fix the underlying problem.

[AzraelNewtype]

On the off chance anybody here is using Gentoo and wants to cleanly update to the git version while we wait on an official new tarball, I edited up an ebuild for it here: http://pastebin.com/FKHU9JsD. I suggest deactivating the qt4 USE flag, since I know at least it wasn't building for me. Could be an isolated thing.

Mosu, I may have missed this, but are you sticking with rake for future versions, or will that just be the build system you're using for git trunk builds for the time being? I ask because moving from make to rake was by far the biggest cause for change in the ebuild, and if the next release is using it, the maintainers will have to make the same changes for the official ebuilds that I did, in which case trying to get this one into the main repo will be much more important.

[Mosu]

rake is the new build system. The README & ChangeLog make that very clear. The 'biggest change' you mentioned is rather small (I speak from the experience of adjusting the Debian, OpenSuSE and Fedora Core build files): add Ruby (you don't even have to add Rake itself 'cause mkvtoolnix includes its own version) to the dependencies and call './drake' instead of 'make'. Maybe adjust the name of one or two targets if the installation step is split into multiple calls instead of a simple './drake install'.

I don't really support Qt4 at the moment. I will fix build issues eventually, but it doesn't have a high priority for me.

[MeridiusUK]

hi i was just wanting some help is there anything to get tsmuxer to work with the new compressed file headers as at teh min i have to run it using mkvtoolnix 4.2.0 and turn it off and then use tsmuxer to get it into m2ts format. wanted to avoid doing this twice.

any help on that if poss

oh another question in mkvtoolnix 4.2.0 I know you nee to just turn off the compression on the audio and video but do you also need to do this on the subtitles to ? as chapters has it grayd out.



thanks

[Mosu]

oh another question in mkvtoolnix 4.2.0 I know you nee to just turn off the compression on the audio and video but do you also need to do this on the subtitles to ?

No. Subtitles have always been compressed with ZLIB in Matroska. Either a player supports subtitles with compression, or it doesn't support subtitles at all (neither with nor without compression).

as chapters has it grayd out.

Chapters and tags cannot be compressed at all. Therefore it's grayed out.

[MeridiusUK]

No. Subtitles have always been compressed with ZLIB in Matroska. Either a player supports subtitles with compression, or it doesn't support subtitles at all (neither with nor without compression).



Chapters and tags cannot be compressed at all. Therefore it's grayed out.

so is it best just to leave the subtitles option blank or do i need to select zlib as in your program its option is blank or does the blank mean it defaults to zlib ? and just select compresion none for audio and video when i remux the files ?

cheers

[AzraelNewtype]

The 'biggest change' you mentioned is rather small (I speak from the experience of adjusting the Debian, OpenSuSE and Fedora Core build files): add Ruby (you don't even have to add Rake itself 'cause mkvtoolnix includes its own version) to the dependencies and call './drake' instead of 'make'.

That isn't how ebuilds tend to work, as they tend to abstract out direct calls to make entirely, but nobody has ever bothered to set up a similar system for using rake, and certainly not for the builder being in the working directory. Don't get me wrong, it's not particularly hard considering at their base ebuilds are essentially gussied up bash scripts, it's just not conforming to the usual style at all. That said, I should actually edit my dependency list and call the local version accordingly in that case, since it's there.

I don't really support Qt4 at the moment. I will fix build issues eventually, but it doesn't have a high priority for me.

Yeah, that's fine. I prefer it since wx is GTK widget backed on linux and I run KDE, but this is honestly so trivial that I wouldn't even mind you yanking the whole damn thing instead of bothering to fix it.

[Mosu]

You know that only mkvinfo has a Qt GUI, right? mmg is wxWidgets only.

[AzraelNewtype]

Actually, I didn't. I care even less about the feature then, so it really deserves to be super low priority.

[MeridiusUK]

hi i was just wanting some help is there anything to get tsmuxer to work with the new compressed file headers as at teh min i have to run it using mkvtoolnix 4.2.0 and turn it off and then use tsmuxer to get it into m2ts format. wanted to avoid doing this twice.

any help on that if poss

oh another question in mkvtoolnix 4.2.0 I know you nee to just turn off the compression on the audio and video but do you also need to do this on the subtitles to ? as chapters has it grayd out.



thanks

any help on this last post ?

[sneaker_ger]

tsmuxer does not support it and there is no trick to make it work. Seems to be as simple as that.

[MeridiusUK]

Cheers.

so is it best just to leave the subtitles option blank or do i need to select zlib as in your program its option is blank or does the blank mean it defaults to zlib ? and just select compresion none for audio and video when i remux the files ?

[sneaker_ger]

You can leave it blank for subtitles because the default is and always has been compression = on for subtitles.

[onlym3]

Is there a way to set the header compression to "none" by default? I have a player with Realtek chipset and currently they don't work with header compressed video and who knows how long it takes them to fix it, if ever, so for every file i mux i have to set it to none. Would make my life a lot easier if i could set it to none by default.

Thanks

[SamuriHL]

Search this thread. Mosu has said he will not change that many times now. You will have to remember to set it manually each time. He's against setting it by default because he wants players to follow the FULL MKV standard. Whether you agree or disagree, if you search, you'll see Mosu believes this very strongly and absolutely won't change his mind. :)

[onlym3]

Search this thread. Mosu has said he will not change that many times now. You will have to remember to set it manually each time. He's against setting it by default because he wants players to follow the FULL MKV standard. Whether you agree or disagree, if you search, you'll see Mosu believes this very strongly and absolutely won't change his mind. :)Yeah well, and in the mean time there are a lot of players that don't play files because one man is trying to force an industry his way. The reality is that it's not worth it, on a 4 GB file you save less than 150 KB with the header compression, that is really peanuts compared to all the problems it causes so a little flexibility instead of a fight against windmills would help a lot.

[SamuriHL]

Yeah well, and in the mean time there are a lot of players that don't play files because one man is trying to force an industry his way. The reality is that it's not worth it, on a 4 GB file you save less than 150 KB with the header compression, that is really peanuts compared to all the problems it causes so a little flexibility instead of a fight against windmills would help a lot.

I wasn't making a judgement on the decision either way...simply an observation that this argument has been tried before and was unable to persuade Mosu to change his stance. I do get the frustration, but, at the end of the day, remember who's project it is. :) We may or may not like the decision he made, but, it's without a doubt his decision to make as the developer.

[Superb]

@onlym3: "his way"? header compression is in the mkv specification. I'm glad Mosu set it as default. It forces hardware manufactures to find bugs in their implementation and release a firmware updates.

[onlym3]

@onlym3: "his way"? header compression is in the mkv specification. I'm glad Mosu set it as default. It forces hardware manufactures to find bugs in their implementation and release a firmware updates.And it frustrates a lot of people who can't watch mkvs anymore without having to remux. It doesn't matter that hardware manufacturers didn't implement properly, the fact is, at the moment the easiest solution would be to at least allow people to disable compression by default. And let's not forget what kind of compression saving we are taking about, there isn't any significant saving, on GB sized files you save KB. 100 KB saving is worth so much trouble?

[Brazil2]

"his way"? header compression is in the mkv specification.
The specs don't say that this feature MUST be enabled but that it MAY be enabled. It's the user's choice. See the difference ?
So yes, Mosu has decided by his own to force us to use this useless feature by default and there is actually no way to save the default settings we want to use with mkvmerge/mmg so we have to do dozens of clicks each time we want to make an MKV without this feature.

It forces hardware manufactures to find bugs in their implementation and release a firmware updates.
Really ? I'm still waiting for an update for WD TV that is supporting this feature. And I have the feeling it's gonna take a long time and you know why ? Because this feature is USELESS, it brings almost no gain, last time I checked I think I got a file size reduction of about 800 kB from a 25 GB file IIRC. Yes, 800 kB for 25 GB !
That's why big companies are not in a hurry to support something that gives no real advantage to anyone and that's also why this feature shouldn't be enabled by default.

[prOnorama]

Setting header compression on by default is fine by me, however not letting the end user decide to change the default on a permanent basis is not very user friendly IMO.

I forgot to switch it off last time and the mkv didn't play on my brother's WD TV (there goes the movie night, my brother lives in another city :( ) Yes my fault, but had it been just a one time setting change I would not have made this mistake.

[Brazil2]

I forgot to switch it off last time and the mkv didn't play on my brother's WD TV
Exactly and it's so annoying and frustrating -to say it in a polite way- to realize that you have forgotten ONE click for ONE track after the mux is done, which took 20-30-40 minutes depending on the movie/tracks you want to mux. And you have to do it again........

[Underground78]

Hi Mosu,

About the FAQ entry for "header removal", it is written that "Freebox (One user got a response from the manufacturer stating that one of the next firmware upgrades would add support for this feature.)", the firmware has been changed now and it does work correctly.

[Mosu]

About the FAQ entry for "header removal", it is written that "Freebox (One user got a response from the manufacturer stating that one of the next firmware upgrades would add support for this feature.)", the firmware has been changed now and it does work correctly.

Thanks, I've changed the entry accordingly.

[sneaker_ger]

Should have removed MPC and PS3 while you've been at it. Also, NMT has fixed the C-200. Fixes for the other models are probably to follow.

[Superb]

The specs don't say that this feature MUST be enabled but that it MAY be enabled. It's the user's choice. See the difference ?
So yes, Mosu has decided by his own to force us to use this useless feature by default and there is actually no way to save the default settings we want to use with mkvmerge/mmg so we have to do dozens of clicks each time we want to make an MKV without this feature.If the mkv spec says a feature MAY be enabled, then the software/hardware player MUST support it. That's the correct logic. Useless or not, that's not even relevant. The spec should be fully implemented. Any other way is a player's BUG.

Really ? I'm still waiting for an update for WD TV that is supporting this feature. And I have the feeling it's gonna take a long time and you know why ? Because this feature is USELESS, it brings almost no gain, last time I checked I think I got a file size reduction of about 800 kB from a 25 GB file IIRC. Yes, 800 kB for 25 GB !
That's why big companies are not in a hurry to support something that gives no real advantage to anyone and that's also why this feature shouldn't be enabled by default.Big companies are definitely in a hurry to support this feature. Why? Cuz not supporting it renders their player useless w/ anything encoded online (e.g. illegal downloads) using the new mkvtoolnix. They will have no choice but to fix their implementation (as more and more releases are muxed w/ this new feature). I give it a month for >75% of them to release firmware updates.

[7ekno]

Why not just mux as you have always done, then at the end of your muxing run, double click a BAT file to fix it all up (fixMKV.BAT, posted here somewhere) ;)

No chance of forgetting a click, no chance of leaving without running the BAT, takes a few extra seconds to click the BAT while you go have a coffee :P

7ek

[onlym3]

Why not just mux as you have always done, then at the end of your muxing run, double click a BAT file to fix it all up (fixMKV.BAT, posted here somewhere) ;)

No chance of forgetting a click, no chance of leaving without running the BAT, takes a few extra seconds to click the BAT while you go have a coffee :P

7ekWell there is an easier solution if you only make your own mkvs. Revert to 4.1.0, that's what i have done and if enough people ignore any version above 4.1.0 until the situation is resolved, maybe the developer realises that a little flexibility never hurt anyone.

[Pulstar]

I'm trying to mux raw VFR streams using MKVMerge to no avail. It seems when I append the video track there's no option to import the assorted timecodes.txt generated by previous app (ex. FLVExtract). Could someone kindly write me a short example MP4Box batch to mux several H.264 streams into a single MP4 with the timecodes in mind? (Yamb doesn't have this feature, it just creates multiple tracks)

[Mosu]

I'm trying to mux raw VFR streams using MKVMerge to no avail. It seems when I append the video track there's no option to import the assorted timecodes.txt generated by previous app (ex. FLVExtract).

I don't have a solution for MP4Box for you, but you could first import the raw h264 streams into one Matroska file each and then append those Matroska files. Another way (though more complicated) would be to create one huge timecode file containing all the timecodes of the segments you want to append. That timecode file can be used in mmg on the first track, and mkvmerge will use the timecodes for the appended tracks as well.

If you want to talk more about that I suggest we do that over in the mkvtoolnix support thread (http://forum.doom9.org/showthread.php?t=155732).

[73ChargerFan]

Huh? Mosu, you pointed back to this thread.