MKVToolNix v24.0.0 released

[GuilhermeAraujo]

Interesting. I didn't know about this compression stuff.
However, I had a 3.81 GB file, then compressed every stream, and got a 3.82 GB!

And I found a bug:
I dragged a file which contain a Title (Segment information > Title, on Header Editor). Then I removed that file, leaving the list empty. Then added more files and muxed.
The title was kept. I believe it was supposed to be removed along with the first file, right?

[Mosu]

Interesting. I didn't know about this compression stuff.
However, I had a 3.81 GB file, then compressed every stream, and got a 3.82 GB!

Don't. Compressing an already compressed stream only makes it worse. There are exceptions, but they are few (e.g. you can usually gain a few bytes compressing MP3 files with RAR). Just let mkvmerge chose what it thinks is best.

I dragged a file which contain a Title (Segment information > Title, on Header Editor). Then I removed that file, leaving the list empty. Then added more files and muxed.
The title was kept. I believe it was supposed to be removed along with the first file, right?

That's not a bug but intentional. What you may want is "File -> New". Removing all input files is NOT supposed to clear everything else.

[GuilhermeAraujo]

Oh. I didn't know that file was already compressed. That makes sense now.
That's not a bug but intentional. What you may want is "File -> New". Removing all input files is NOT supposed to clear everything else.
I see.

[Adub]

It's already compressed if it uses a codec, like X264 or Xvid. Which is the case for about 99.999% of video files.

[soneca]

Today I used the version 4.1.0 and the result was a mkv with audio mute.
Again tested with versions 4.0.0 and .3.2.0 and audio came back...

mkvmerge v4.1.0 ('Boiling Point') built on Jul 1 2010 14:37:28
'D:\RECEM_CHEGADA_DEMUX\RECEM_CHEGADA_Track1.h264': Using the AVC/h.264 ES demultiplexer.
'D:\BLU_RAY\AUDIO_DD_DTS\RECEM_CHEGADA_PT.ac3': Using the AC3 demultiplexer.
'D:\RECEM_CHEGADA_DEMUX\RECEM_CHEGADA_Track1.h264' track 0: Using the MPEG-4 part 10 ES video output module.
'D:\BLU_RAY\AUDIO_DD_DTS\RECEM_CHEGADA_PT.ac3' track 0: Using the AC3 output module.
The file 'E:\VIDEOS MKV\RECEM_CHEGADA_TESTE.mkv' has been opened for writing.
'D:\RECEM_CHEGADA_DEMUX\RECEM_CHEGADA_Track1.h264' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1280/720.
Progress: 0%Progress: 1%Progress: 2%Progress: 3%Progress: 4%Progress: 5%Progress: 6%Progress: 7%Progress: 8%Progress: 9%Progress: 10%Progress: 11%Progress: 12%Progress: 13%Progress: 14%Progress: 15%Progress: 16%Progress: 17%Progress: 18%Progress: 19%Progress: 20%Progress: 21%Progress: 22%Progress: 23%Progress: 24%Progress: 25%Progress: 26%Progress: 27%Progress: 28%Progress: 29%Progress: 30%Progress: 31%Progress: 32%Progress: 33%Progress: 34%Progress: 35%Progress: 36%Progress: 37%Progress: 38%Progress: 39%Progress: 40%Progress: 41%Progress: 42%Progress: 43%Progress: 44%Progress: 45%Progress: 46%Progress: 47%Progress: 48%Progress: 49%Progress: 50%Progress: 51%Progress: 52%Progress: 53%Progress: 54%Progress: 55%Progress: 56%Progress: 57%Progress: 58%Progress: 59%Progress: 60%Progress: 61%Progress: 62%Progress: 63%Progress: 64%Progress: 65%Progress: 66%Progress: 67%Progress: 68%Progress: 69%Progress: 70%Progress: 71%Progress: 72%Progress: 73%Progress: 74%Progress: 75%Progress: 76%Progress: 77%Progress: 78%Progress: 79%Progress: 80%Progress: 81%Progress: 82%Progress: 83%Progress: 84%Progress: 85%Progress: 86%Progress: 87%Progress: 88%Progress: 89%Progress: 90%Progress: 91%Progress: 92%Progress: 93%Progress: 94%Progress: 95%Progress: 96%Progress: 97%Progress: 98%Progress: 99%Progress: 100%Progress: 100%
The cue entries (the index) are being written...
Muxing took 67 seconds.

[LeXXuz]

Recently updated from 3.2 to 4.0.

Have there been any changes to the vobsub muxer lately? With 4.0 my media players do not display vobsubs in 1080p anymore. Tracks get recognized, but no subpictures shown.
PC playback still works as usual.

However, same files muxed with 3.2 and everything works fine.

Same Problem with 4.1 now. Any ideas?

[SamuriHL]

I just remuxed some stuff with 4.1 and I'm not seeing an audio mute problem. Everything seems fine for me. I'm simply adding PGS subs from a file back into my MKV's so it's taking an existing one, adding PGS subs to it, and writing it back out. No problems.

[Mosu]

Today I used the version 4.1.0 and the result was a mkv with audio mute.
Again tested with versions 4.0.0 and .3.2.0 and audio came back...

Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression for an explanation and file a bug report with the vendor(s) of the software/hardware you use for playback (and the demuxer if its separate from the player).

[soneca]

Mosu,

You are right, it was a failure KMPlayer but already been resolved by changing the settings.:)


Thanks!

[steelista]

Hi,

I've installed an Ubuntu package from http://www.bunkus.org/ubuntu/lucid/binary/i386/ and I can't change the GUI's language. It's always English no matter what i select.

[Mosu]

I've installed an Ubuntu package from http://www.bunkus.org/ubuntu/lucid/binary/i386/ and I can't change the GUI's language. It's always English no matter what i select.

Probably because you don't have the locales compiled for the language you're trying to use. Please paste/tell me:

1. the output of the "locale" command,

2. which language you're trying to use,

3. the output of "cat /var/lib/locales/supported.d/*"

[hubblec4]

hi mosu

thanks for this great upgrade

""...
2010-06-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading PGS subtitles from PGS/SUP files.
..."

this new feature helps me to keep the original bluray.sup's.

I demux a bluray ever with eac3to and i get the sup files with the name of the language like this:
"00019 - 15 - Subtitle (PGS), German, 1685 captions.sup"

when i insert the file to the gui i must select the language manually. It would be nice that the language set automaticly.

hubble

[GuilhermeAraujo]

Reading info from file name? Yes, would be very interesting. Language and delay.

[LeMoi]

AFAIK delay is already read from filename (at least for audio files), see options.

[Mosu]

Hey,

I've released mkvtoolnix v4.1.1 just two days after v4.1.0 due to a serious bug introduced in v4.1.0. If causes mkvmerge to crash with default option in various circumstances, especially when handling MPEG-4 part 2 video tracks.

There are no changes for package maintainers in this release.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-4.1.1.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.1.1-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.1.1.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.1.0:

------------------------------------------------------------
2010-07-03 Moritz Bunkus <moritz@bunkus.org>
* Released v4.1.1.
* mkvmerge: bug fix: Fixed invalid memory access in the header removal compressor. Fix for bug 508.
* mmg: bug fix: mmg will no longer add .mmg files opened by the job runner to the file menu's list of recently opened files. Fix for bug 509.
------------------------------------------------------------

Have fun.

[GuilhermeAraujo]

AFAIK delay is already read from filename (at least for audio files), see options.
Cool. I'm gonna make some tests :P

[johnsonlam]

I got this message frequently, and MMG stopped, how to solve the problem?

"Compression failed: Header removal compression not possible because the buffer contained 1 bytes which is less than the size of the headers that should be removed, 3."

Thanks.

[Mosu]

I got this message frequently, and MMG stopped, how to solve the problem?

"Compression failed: Header removal compression not possible because the buffer contained 1 bytes which is less than the size of the headers that should be removed, 3."

Force compression to 'none' for the problematic track. Also I'd like to know how what files and tracks you were muxing. If possible could you upload them to my FTP server? This should not happen, and I'd like to know the reason for it and to fix it.

The lenght, 3, lets me guess that it's a MPEG-4 part 2 video track that's causing the problem.

[woah!]

i dont know why/how but since 4.1.0 or 4.1.1 any mkv i make doesnt play sound on my wd hd live media player. remuxing exact same mkv made with 4.1.0,but using 4.0.0 and plays correctly on the media player?

just a heads up if people ever have an issue like this...

[sneaker_ger]

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

[woah!]

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

ok so a bug report to wd is needed thx :)

i will use 4.0.0 until enough people report to them, for them to fix it maybe...

[Mosu]

You can also use 4.1.1 but you have to disable extra compression for the audio tracks if you intend to play the file with such a player.

[soneca]

I also have the WDTV Live and confirm this "problem".
I doubt that this is corrected quickly by WD.:(

[cge]

Hi,
This is probably a very basic things bug I'd like to clarify it in my mind.
I thought that the default and forced flags are booleen values but there are 3 choices in the drop/down box in the mkvmerge dialog (YES|NO|DEFAULT) ?
Note: from the header editor dialog it's only possible to set them to Yes|No
Regards
Christophe

[Mosu]

mmg has a lot of booleans that contain 'yes', 'no' and either 'default' or an empty value. 'yes' means 'definitely set this value to "yes"'. 'no' means 'definitely set this value to "no"'. 'default' or an empty value means 'please mkvmerge, decide yourself'.

For the 'forced display' flag this means that mkvmerge will keep the value from the source container -- e.g. if you're remuxing from a Matroska file to another Matroska file.

For the 'default track' flag this means that mkvmerge will decide on the information from the source containers and the values of the 'default track' flags of all the other tracks whether or not to set this value.

In all cases mkvmerge will either set the value to 'yes' or to 'no'. That's why the header editor also only lets you chose between 'yes' and 'no'.

[sialivi]

Any plans to support .flv input files?

[Mosu]

No support for Flash video files is planned.

[cge]

Hi,
I'd like to know if there is an easy way to change the track order without remuxing ?
I tried to change the track ID using the header editor with no luck !
Thanks
Christophe

[Mosu]

Not really, no. There's nothing in the specs telling a player how to sort the tracks, so most players simply use the order in which they appear in the track headers. Neither mmg's editor nor mkvpropedit allow the track headers to be re-ordered, and such a feature is not planned at the moment.

[^*^]

I have recently bought new Samsung LED TV which is unable to play MKV files with new audio compression. I have to specify "none" each time I add an audio stream. This is easy, but also easy to forget about it. Muxing of 30 GB file to external HDD takes about 40 minutes. And sometimes this time is wasted due to wrong compression setting. It is very unlikely that Samsung will correct its firmwares, and therefore I would be very grateful that You add in program options a checkbox, which will make "audio compression - none" as default.

[Atak_Snajpera]

@Mosu
I think that you should disable audio compression by default. It only causes more confusion. You've added that feature too late ;)

[Mosu]

and therefore I would be very grateful that You add in program options a checkbox, which will make "audio compression - none" as default.

Sorry, but I won't.

[Mosu]

@Mosu
I think that you should disable audio compression by default. It only causes more confusion. You've added that feature too late ;)

Sorry, but I won't. Users have several options (some better suited than others for different kinds of users): keep using an earlier version; force compression off; use the command line which makes forcing easier; get the player vendors to support this feature that's been part of the specifications for eight years now.

[Guest]

Sorry, but I won't. Why is it so important for you that the default be enabled? Don't you care at all about the grief this causes users? Isn't it a trivial matter to enable the option if you want it? Doesn't backward compatibility mean anything to you?

Please don't get mad at me. I'm just inquiring as a concerned user.

[Mosu]

I'm concerned about backwards compatibility, but at the specs level. The specs haven't changed in this regard, this feature just has never seen very wide use until now. Haali's muxer has always supported header compression (muxer, not only the demuxer!), but it hasn't been enabled by default.

What I'm trying to do at this very moment is to get companies to update their software to support a wider range of the specs. Now is a good time for such a move due to an already existing major change in mkvtoolnix 4.0.0 (default values aren't written anymore) and due to the changes necessary for WebM playback. That's why I'm pushing for it now.

The Matroska project has always been about pushing into unchartered territory. If we were satisfied with the status quo then we'd still all be using AVIs or MP4 and neither OGM nor Matroska would have seen the light of day. Yes, this process is often painful, but you don't get (technical) advancement for free.

[Guest]

What I'm trying to do at this very moment is to get companies to update their software to support a wider range of the specs. Now is a good time for such a move due to an already existing major change in mkvtoolnix 4.0.0 (default values aren't written anymore) and due to the changes necessary for WebM playback. That's why I'm pushing for it now.
Seems to me that if you were serious about that you would have removed the option to disable it. :)

[Mosu]

I'm not about forcing everyone to push my agenda for them. I like to give the users a choice. The choices themselves are often not what the user would prefer though (e.g. use older versions of the software).

There's a technical reason why I don't let users chose in the 'default values' case: the libraries mkvtoolnix uses makes it very hard to not write default values and still create valid WebM files. I don't have that much time to fix this properly.

The 'compression' case is different. It's technically trivial to let the user chose in this case. Even the modifications in mmg were trivial because the 'compression' selection box was already present, it just couldn't be used for non-subtitle tracks.

[nurbs]

I second the request for an option in mmg to turn off audio compression by default. I compared a file (1*AVC/3*AAC/1*SUB/IDX) muxed with 3.4.0 and 4.1.1 and the latter is 0,002% smaller (45kB out of 2.12 GB) and didn't work on any of my hardware. There is zero gain and lots of trouble with that feature.

[Mosu]

There's no header removal compression with AVC and AAC tracks. VobSub tracks have always been compressed with zlib.

And no, I won't add such an option. Sorry.

[Guest]

Source is available. We can make our own branch. :)

[Mosu]

Sure, you can do that. But please don't call it mkvtoolnix then and change the program names (e.g. in the "about" dialogs and the help texts) to make it obvious that those are modified versions.

[nurbs]

There's no header removal compression with AVC and AAC tracks.
Which raises the question why the file doesn't work. I'll have to investigate.

[Mosu]

Here's a list of track types and their default compression methods:

VobSub, PGS/SUP, text subtitles (SRT/ASS/SSA), VobButtons: ZLIB

AC3, DTS, MP3, MPEG-4 part 2 (aka DivX aka Xvid), Dirac: header removal

Everything else: no additional compression

[Guest]

Sure, you can do that. But please don't call it mkvtoolnix then and change the program names (e.g. in the "about" dialogs and the help texts) to make it obvious that those are modified versions. Of course. I'm talking for personal use only. :)

[Mosu]

Ah ok. No need to change anything for personal use, just don't distribute it under the original name. Thanks.

[johnsonlam]

Force compression to 'none' for the problematic track. Also I'd like to know how what files and tracks you were muxing. If possible could you upload them to my FTP server? This should not happen, and I'd like to know the reason for it and to fix it.

The lenght, 3, lets me guess that it's a MPEG-4 part 2 video track that's causing the problem.

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

I've uploaded the video in 7z format (4 parts) with subtitle, I just want to add subtitle to the file, and I do as you say force "none" works!

I think it's a bit annoying to display this message without suggestion, people usually not able to determine what kind of files can be compressed, and for this kind of file MMG failed to decide.

I've tested subtitle can be compressed but sound and video already compressed (anyone will use WAV or uncompressed AIFF for sound track?), they should be automatically set to "none".

Thanks for your MKVTOOLNIX, it's the "savior" of MKV, also thanks for your work!

[SeeMoreDigital]

Sorry, but I won't.I seem to remember you having similar reservations about not letting MKVmerge automatically remove the aspect ratio signalling embedded within MPEG-4 video streams... But eventually you changed your mind ;)

[Mosu]

I seem to remember you having similar reservations about not letting MKVmerge automatically remove the aspect ratio signalling embedded within MPEG-4 video streams... But eventually you changed your mind ;)

True. But the case of aspect-ratio information is not as clear-cut as this one. The Matroska specifications don't say anything about where aspect ratio information must be stored. In fact it doesn't say anything about aspect-ratio information at all -- it only contains two elements that tell the player the preferred size of the video when it is played back.

Header removal compression is defined in the specs, as are default values.

[Mosu]

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

I've uploaded the video in 7z format (4 parts) with subtitle, I just want to add subtitle to the file, and I do as you say force "none" works!

Thanks, I'll take a look. DX50 is also MPEG-4 part 2 (DX50 is, if I'm not mistaken, the FourCC of DivX v5.0 or something like that). My guess is that frames of length 1 simply mean 'repeat previous frame'. So I have two options: disable header removal compression or drop those frames and calculate timecodes/duration accordingly. The latter is already done when muxing from AVI into Matroska, so it wouldn't be anything new.

I think it's a bit annoying to display this message without suggestion, people usually not able to determine what kind of files can be compressed, and for this kind of file MMG failed to decide.

I agree. I want to have a solution that succeeds in 99.99% of all cases ( = muxing succeeds in 99.99% of all cases; playback is a totally different matter). So if I cannot find a proper solution for such files as yours I'll disable header removal for MPEG-4 part 2 tracks by default.

[LeXXuz]

Here's a list of track types and their default compression methods:

VobSub, PGS/SUP, text subtitles (SRT/ASS/SSA), VobButtons: ZLIB


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?