MKVToolNix v24.0.0 released

[^*^]

Then let's change these specifications! Your application has become de facto the standard for creation of Matroska files. Millions (or probably billions) of devices compatible with previous versions of mkvtoolnix are made. Now they are incompatible. OK, we still can make files suitable for our old devices. But other 95% (or even more) of consumers haven't knowledge to do this. They will attempt to play new films without success and then they will be starting to think about to purchase of new equipment. The old sooner or later will go to trash. Please, think "green", unless some corporations have paid You to make these changes and they could sell more "new and compatible" devices. Frequent change of standards are their bread.

[Mosu]

I dont understand very much of this topic, but I guess this is the reason why my players don't display any vobsubs with the 4.x builds? Am I right?

You may be right, but I doubt it. VobSub compression with ZLIB has been used since the day VobSub support was introduced itself. Meaning since Sep 11 2003:

commit 3fcd47dc6a9e5a9a22a0ad985f2fab2f761f5e86
Author: Moritz Bunkus <moritz@bunkus.org>
Date: Thu Sep 11 19:43:32 2003 +0000

Implemented the VobSub reader and packetizer. Implemented three compression algos which are selectable via the (undocumented) command line option --compression.


What's new in v4.1.0 (not in 4.0.0!) is that certain audio and video tracks use header removal compression by default.

What's new in v4.0.0 is that default values are not written anymore. This does concern ZLIB compression, and this is what most likely breaks your player: it does not support default values properly. Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values for an explanation.

Note that blaming mkvmerge is not really solving your problem. With the rise of WebM there are tons of new muxers popping up left and right, and some of them don't write default values either. So the only sensible long-term solution is to fix playback devices to support the specs properly.

[Mosu]

Then let's change these specifications! Your application has become de facto the standard for creation of Matroska files.

Not possible. Even if mkvtoolnix is the de facto standard in a limited number of situations it is by far not the only program using the existing specs. Changing the specs in backwards incompatible ways now that there are tons of muxers and demuxers already out there is out of the question.

Please, think "green", unless some corporations have paid You to make these changes and they could sell more "new and compatible" devices.

Since I've started working on mkvtoolnix in 2002 I've received all of 200 EUR in donations. No corporation has ever contacted me and asked me to change mkvtoolnix in any way.

Also it's a lie if a corp tells you that they cannot fix bugs in older hardware. This is not about implementing a whole new video codec for which the hardware might not be capable enough. These are minor software updates which would only require a new firmware, certainly not a new hardware device. I know corps like to sell new devices instead of support old ones. But changing their corporate mind is the responsibility of each and every consumer by making the choice which devices to buy and which not to buy.

So please don't start a discussion about corporate ethics, the impact of my decisions on the environment. This is a mkvtoolnix support thread, not a political discussion board.

[LeXXuz]

You may be right, but I doubt it. VobSub compression with ZLIB has been used since the day VobSub support was introduced itself. Meaning since Sep 11 2003:

Since it works with 3.2, you're right ofcourse!



What's new in v4.1.0 (not in 4.0.0!) is that certain audio and video tracks use header removal compression by default.

What's new in v4.0.0 is that default values are not written anymore. This does concern ZLIB compression, and this is what most likely breaks your player: it does not support default values properly. Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values for an explanation.

Note that blaming mkvmerge is not really solving your problem. With the rise of WebM there are tons of new muxers popping up left and right, and some of them don't write default values either. So the only sensible long-term solution is to fix playback devices to support the specs properly.

I get your point, thanks for your answer. I'm not blaming mkvmerge for anything. Just trying to figure out what I have to do temporarily to get subtitles to work. Now that I know what changed I can contact the vendor and ask them to make changes to their FW. As usual they wont do anything until customers start to complain, so this might take some time...

[asc28]

I recently remuxed H.264/flac to mkv with mkvmerge 4.1.0, no errors, but it came out damaged (file would skip in the middle). I did it again, same version, same inputs, same settings and it came out fine. Checksums of the files were different and there is an "NAL too big error" when extracting the damaged one. Filesizes are identical.

command-line: mkvmerge -o out.mkv --default-duration 0:24000/1001fps in.h264 in.flac

So, I did a surface scan of all the drives involved (including my pagefile drive) and did 5 passes of Memtest86+ with no errors found. Could this have something to do with that particular version of mkvmerge or should I be worried that something else is wrong with my system?

[edit] Just realized checksums will be different anyway because of encoding date metadata, but everything else applies

[stax76]

Such compatibility issues won't happen with a HTPC. :)

[Mosu]

True about the checksums. Hard to tell in general. The AVC code has received a couple of changes in the last few releases. But I haven't seen anything random happening for other users.

It could also have been a one-time hardware error, e.g. system getting very hot; intermittent memory fault. Such things happen, even if subsequent tests don't show anything wrong with the hardware.

What I'm trying to say is that there's no known issue with raw h264 files in v4.1.1.

[LeXXuz]

You were right Mosu. Setting vobsub compression manually in mmg and vobsubs work again on my players. Thanks for your help, would have never figured that out by myself. :thanks:

[tiny55]

I'm having a problem with the merge function(MMG) of MKVtoolNix.
The same problem as mentioned by Foofaraw.. (reference posts 1476 to 1480 page74)

Using MKVMERGE, I can take a BluRay rip made with MakeMKV with just a Video and audio track that works fine on my computer software players and Seagate Fat+ or WD media players, run it thru the MKVMerge program without changing anything and the resulting file now takes 10-20 seconds to load in all my players. The origional rip would load in 1-2 seconds.

Except for the Fat+ all the other players wait for the file to load and the movie will play without incident.The computer players take a little longer to load but not that much longer. The Fat+ however, will not wait. It just locks since it can't load the file immediately. However, with H264, I usually do not not have that problem. MMg asks for the frame rate and remuxes perfectly and the file will load in 1 to 2 seconds. Also with Mpeg and VC1 files less than an hour long they will usually load within the time frame allowed by the Seagate player and they will load and play as well.

Further, I can take the movie that MKVMERGE generated that takes too long to load run it thru tsMuxer, convert it to a Bluray folder without adding or removing anything and run it once again thru Makemkv. The resulting movie once again plays as before and loads in 1-2 seconds.

I've gone as far asdemuxing a VC1 file and adding only the video and chapters back into it. No audio or anything else and it still takes too long to load.

I've used the header editor as well as the verify selection and nothing was out of place as far as I could tell.

So after reading the above mentioned posts(1476-1480) and the explanation as why this happens, I was wondering if I could just get some advice on how to shorten the re-load time.


Thank you
Tony

[MeridiusUK]

a hugh bug in mkvtoolnix 4.1.1 please read this post and link

http://forum.doom9.org/showthread.php?p=1416294#post1416294

I rip a dvd to mkv using makemkv then i will use mkvtoolnix 4.1.1 to disable the subs so that they dont auto play well on the pc side anyway as i hate to keep turning them off then i remux the file all works fine on the pc but when i play it on the ps3 the sound just plays like a old spectrum loader game in the old days.

now if i do the same rip the dvd to kv with makemkv but do not use mkvtoolnix 4.1.1 it works so it looks like mkvtoolnix is damaging the file in some way.

I have not tried to remux the file without changing anything so i am going to do this first to see if it stil damages the file if it does not it must be when i change the subs from default to no but i will have to try this out.

its just a shame makemkv does not give you an option to stop the subs comming on stright away

at least i now know mkvtoolnix sems to be the problem i am going to try verion 4.0.0 to to see what happens

but the mkv file that i made with makemkv is now working as long as i dont use mkvtoolnix to disable the subs but i will do more testing

oh bugger i dont have 4.0.0 can anyone tell me where to get it to test it out as version 4.1.1 is totaly unusable for me now i know its for the ps3 but to be honest it should not be damaging the file in this way it might even cause problems for pc in the future or now.

hope this helps as i love this tool

[Mosu]

a hugh bug in mkvtoolnix 4.1.1 please read this post and link

http://forum.doom9.org/showthread.php?p=1416294#post1416294

I rip a dvd to mkv using makemkv then i will use mkvtoolnix 4.1.1 to disable the subs so that they dont auto play well on the pc side anyway as i hate to keep turning them off then i remux the file all works fine on the pc but when i play it on the ps3 the sound just plays like a old spectrum loader game in the old days.

Not a bug in mkvtoolnix but in the playback software. Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression for an explanation.

oh bugger i dont have 4.0.0 can anyone tell me where to get it

All versions ever released are available from http://www.bunkus.org/videotools/mkvtoolnix/win32/

[MeridiusUK]

Thanks for that so if I select none on the audio track it will
not remove the headers from the track and should make it more compatable with the ps3 so I don't need to go back to version 4.0.0 but in doing so will make the final mkv slighty bigger than the normal file. Is this correct ?

Also the files that I have already done can I reload them back in and select none on the audio track and will it fix it or will I need to rerio the DVDs again ? Cheers

so this feature is to make the mkv files smaller ?

Is there anything ealse I should watch out for just in case

Thanks for the help

[LeMoi]

The difference won't be huge, just a few bytes...

[Mosu]

Thanks for that so if I select none on the audio track it will
not remove the headers from the track and should make it more compatable with the ps3 so I don't need to go back to version 4.0.0 but in doing so will make the final mkv slighty bigger than the normal file. Is this correct ?

Yes.

Also the files that I have already done can I reload them back in and select none on the audio track and will it fix it

Definitely, yes. This type of "compression" is lossless. Technically it works like this: Each frame of a track starts with the very same bytes. Header removal compression takes these bytes and stores them once in the track headers and removes them from the start of each frame. A player (or a demuxer like mkvmerge's input module) must add the bytes from the track header to every frame in the file upon playback. This is a trivial process; a couple of lines of code at most.

[MeridiusUK]

Thanks for that will try it out later, so if its only saves a few bytes why use it ? If when not using it makes it a littile more compatable. I know the files worked on a pc with no problems butthe ps3 must. Be a littile more fussy.

I am happy that I don't need to re rip all my moves as u say I can just load them back into mkvtoolnix and change the audio to none and it will add all the headers back into each track to make it more comptable.

Is it normal for mkvtoolnix to have the settin all set to blank ?

Could u also let me know if there is anything ealse I should watch out for when using mkvtoolnix 4.1.1 as I upgraded from 4.0.0 and don't know if there anything ealse that has changed.

It's that I use makemkv for my DVDs but for some reason when u have select subtitles it will auto default them to on when playback wise it would not do that but I use mkvtoolnix to change it from yes to no to stop them from comming on automaticly is this the right option to select no to turn them off or default ?

[MeridiusUK]

hi there just got back in, what do i select none for just the audio track ? as there is an option for the video track and vobsub track do i just leave these blank ?

so is it

audio = none
rest of the settings leave alone or blank

or

audio = none
video = none

rest of the settings leave alone

or

audio = none
video = none
subtitles = none

?

not to sure what to use

version 4.0.0 did the file in 92sec

version 4.1.1 did it in
audio = none
video = none
93sec

version 4.1.1 did it in
audio = none
video = blank
104sec

so is it right that having the video and audio set to none as only doing the audio takes 10sec longer to do meaning it must be doing somthing extra over 4.0.0.

cheers

[MeridiusUK]

anyone ?

[SeeMoreDigital]

anyone ?This is a community forum, not a private "help-desk". Indeed, please refer to the forum rules (http://forum.doom9.org/forum-rules.htm). Particularly rule: 12

[steelista]

Probably because you don't have the locales compiled for the language you're trying to use.

Sorry for a late answer.

Missing locales was the problem. Thank you for the help.

[Mosu]

Thanks, you're right about the video track have problem, but it's a "DX50" (H263) video.

The next release will have header removal compression turned off for MPEG-4 part 2 video tracks again. It simply is incompatible with packed bitstreams which are the (vast?) majority of all MPEG-4 part 2 tracks out there.

[SeeMoreDigital]

The next release will have header removal compression turned off for MPEG-4 part 2 video tracks again. It simply is incompatible with packed bitstreams which are the (vast?) majority of all MPEG-4 part 2 tracks out there.Have you considered "removing" the packed bit-stream from the MPEG-4 ASP video stream during muxing to the .MKV container?

Given the processing power of todays software and hardware players, the use of packed bit-stream is completely un-necessary now. It's just another awful hack to place b-frames within the .AVI container. Indeed, it's a hack that is not required for use with the .MP4 container and therefore should not be required for use with the .MKV container either!


Cheers

[Mosu]

Yes, mkvmerge contains very complicated code for it. It can be activated with "--engage native_mpeg4". However, it still contains a couple of bugs, and I've already spent way too much time on it compared to an actual gain.

[SeeMoreDigital]

Yes, mkvmerge contains very complicated code for it. It can be activated with "--engage native_mpeg4". However, it still contains a couple of bugs, and I've already spent way too much time on it compared to an actual gain.Is there no way of implementing/modifying Moitah's MPEG4 Modifier code?

[Mosu]

I've already got all the code in place, but the problems are the remaining bugs. You can read about it here: https://www.bunkus.org/bugzilla/show_bug.cgi?id=289

Also why bother? It's not like MPEG-4 part 2 is the future of video encoding...

[zn]

Error: The demultiplexer for the file '1024.vc1' failed to initialize
vc1_es_reader: Could not open the source file.

muxing more then 1024 files didn't work using mkvmerge -o out.mkv a.vc1 +b.vc1 +c.vc1

tested on 2.7

[Mosu]

You probably hit a limit imposed by the operating system. mkvmerge does not have any artificial limit on the number of open files. Technically mkvmerge could close the files after reading the headers and re-open them when its their turn, but I will definitely not spend any time on something like that.

BTW: v2.7 is ancient. You should upgrade. Though that won't solve this particular problem.

[SamuriHL]

Holy snikes! 1024 files?!?!?! :D

[zn]

You probably hit a limit imposed by the operating system.

i can confirm this! I have similar error in both 64 bit linux ext3 and 32 bit xp sp3 ntfs
in linux it was possible to avoid this problem by increasing open files limit to (ulimit -n 2048)

Holy snikes! 1024 files?!?!?! :D
in total it was 1231 files :D

[SamuriHL]

in total it was 1231 files :D

Good Lord that's a lot of files to merge! :)

[SeeMoreDigital]

I've already got all the code in place, but the problems are the remaining bugs. You can read about it here: https://www.bunkus.org/bugzilla/show_bug.cgi?id=289

Also why bother? It's not like MPEG-4 part 2 is the future of video encoding...In that case...

How about issuing a "pop up notice" reminding people about the possible conflicts regarding muxing MPEG-4 ASP video streams... In much the same way you provide a notice to remind people to set the video streams FPS speed?

[Mosu]

The current way of muxing MPEG-4 ASP ("VfW compatibility mode") works nicely for playback on all devices, so such a warning would be bogus.

The FPS issue is completely different and definitely warrants a warning. The difference is that in the ASP case people don't have to do anything and it "just works". In the AVC case not specifying the FPS will usually result in wrong frame rate and therefore it doesn't "just work".

[Ramon4eg]

How can I fix the english subtitle trouble? In MPC-Homecinema they are named "Unknown", when I choose english language. Other languages are normal. Before mkvtoolnix 4.0.0 they're was "English".

[SamuriHL]

Try giving them a title. I always put "English" or "English - Forced"as a description in the title field.

[Snowknight26]

MPC-HC bug, take it up with the devs.

[Ramon4eg]

In older versions all be allright.

[sneaker_ger]

This has been discussed here and in the mpc-hc section already, it is a bug in mpc-hc's matroska splitter which doesn't correctly lable subtitle tracks without the "language" tag as "English" as defined by the matroska spec.
Solutions:
1.) Use Haali's splitter instead of the internal or
2.) switch to an older mkvmerge version or
3.) manually add the language tag with the header editor or
4.) get the mpc-hc devs to fix the problem

[Midzuki]

Solutions:

1.) Use Haali's splitter instead of the internal or
2.) switch to an older mkvmerge version or
3.) manually add the language tag with the header editor or
4.) get the mpc-hc devs to fix the problem

Only #4 would deserve to be called "solution". :)

[foxyshadis]

I created a patch to fix the problem, but it hasn't been applied yet. MPC Ticket 536 (https://sourceforge.net/apps/trac/mpc-hc/ticket/536)

[Ramon4eg]

OK, I'll wait app.

[Thunderbolt8]

is the option to turn off that header compression thing for ac3 tracks that one under 'extra options' -> compression = none?

[SamuriHL]

Yup, that's the setting.

[LeMoi]

Is there a way to add a setting in the options dialog "set audio/video compression to default/none/zlib" for all tracks, if not specified?

[sneaker_ger]

.....
I second the request for an option in mmg to turn off audio compression by default.
And no, I won't add such an option. Sorry.

[LeMoi]

No, it's not about turning off by default, it's just about letting the choice to the user, not the same thing

[Mosu]

You do have the choice. I'm not preventing you to turn it off in mmg. You can use the command line and use the wildcard track ID -1 which matches all tracks in a given file. You can use older releases.

[sneaker_ger]

No, it's not about turning off by default, it's just about letting the choice to the user, not the same thing

Nurbs asked for "an option in mmg to turn off audio compression by default". Which is pretty much what you were asking for.

[LeMoi]

It's like the 'und' option for language tracks, in first releases, every track added had its language set to English, and then Mosu decided to set the default language as Undetermined -even if Matroska specs say that default language is English, which may cause problems now (with latest releases) for some old splitters and players unlike Haali's one.
Again, I'm just saying that it would be nice to be able to set this option once for all in the GUI, not having to set it every time for every audio/video track. That means for example that if compression field is empty, it's set to what would be set in the options, which may be "default" (=yes), "none" and "zlib". It's just a matter of saving time, not changing or antagonizing Matroska specs.

And please, stop saying "use older version", you know that new versions fix other bugs or add new features, we (I) wouldn't change mkvtoolnix version just because of that.

I'll just add that I'm not concerned by the problem, I play all my MKV files on my PC, using MPC-HC and Haali Splitter, I don't have any hardware player or other buggy stuff. It's just about having the choice to turn on/off this option once for all ^^

[Mosu]

It's like the 'und' option for language tracks, in first releases, every track added had its language set to English, and then Mosu decided to set the default language as Undetermined -even if Matroska specs say that default language is English, which may cause problems now (with latest releases) for some old splitters and players unlike Haali's one.

You're confusing issues here. There are two different issues: 1. the language that mkvmerge assumes if the user hasn't specified anything specific and if the source container doesn't provide that information either (think of SRT subtitles) and 2. the value that a reader must use if the element is not present in the file. These are two completely different issues, and only the second one actually concerns players/readers.

What I changed was the 1. issue. In early releases mkvmerge assumed "English", and people (rightfully) complained that the world does not revolve around English, and I switched mkvmerge to use "undefined" instead. This has nothing (!) to do with specs.

The 2. issue has only been changed with v4.0.0, and that's only a matter of properly following the specs.

And please, stop saying "use older version", you know that new versions fix other bugs or add new features, we (I) wouldn't change mkvtoolnix version just because of that.

I'm giving you options. These options may not be what you want, but that's another issue. This is open source software. You're not forced to use the "latest and greatest". You could create such a build yourself, or lacking the programming skills you (or anyone else wishing for specific features that I won't implement) could ask other developers to do it for you.

Anyway. I'm not discussing this any further. I will not implement such an option.

[LeMoi]

OK, never mind. It's just a shame to implement an option nobody asked for and only few people use, while lot of users complain about it. And you know that even if your program is open source, you're the only one to compile public versions of it (I never saw other builds than yours, but maybe I didn't search for it...).
But you're right, if you really don't want to re-implement this feature, 'end of discussion' and sorry for bothering :)

[Mosu]

mkvtoolnix is not (only) about user requests, it's also (or even more so) about pushing Matroska features. I'm perfectly aware that "Matroska features" and "user requests" don't always overlap very well.