MKVToolNix v24.0.0 released

[b66pak]

@Mosu one request: can you add the audio delay in a .mkv (if any) to the report obtained with:

mkvmerge -i anyfile.mkv
_

[jasonwc]

I noticed that when MKVMerge is used to mux a FLAC track into an MKV, it strips out the bitrate metadata, and thus cannot show the bitrate or size of the FLAC track within a MKV container. A FLAC track produced with eac3to, for example, contains bitrate information, but after being muxed into an MKV container, merely displays as "Variable" within Mediainfo.

In addition, no percentage information is given for VC-1 or AVC streams from most Blu-Ray sources. I assume this is because no metadata is included within the m2ts, however, MKVMerge should be able to figure out the bitrate of the video stream by calculating the filesize - overhead.

One more question - how much space is saved by the use of header compression for AC3 and DTS streams, on average?

[LeMoi]

Calculating video bitrate is not very reliable. You should use MPEG File Bitrate Viewer.

[Mosu]

I noticed that when MKVMerge is used to mux a FLAC track into an MKV, it strips out the bitrate metadata

That's incorrect. mkvmerge keeps all FLAC blocks including FLAC's metadata blocks.

but after being muxed into an MKV container, merely displays as "Variable" within Mediainfo.

That's due to a combination of the Matroska container not having a bitrate header field and Mediainfo not looking into the FLAC stream inside the Matroska container.

[Mosu]

@Mosu one request: can you add the audio delay in a .mkv (if any) to the report obtained with:

mkvmerge -i anyfile.mkv
_

No, sorry. mkvmerge does not scan the input files further than the header fields for the output of "-i", and it would have to in order to be able to display that piece of information. You can calculate that value from the output of mkvinfo.

[jasonwc]

Mosu,

I think I have discovered an odd bug, and I can't tell if the problem is with MKVMerge or Haali's Matroska splitter. I have been able to reproduce the issue with MKVMerge 4.0, 4.1.0, and 4.1.1.

Issue: When an MKV contains an AVC and FLAC 1.0 track, it always stalls when played back when using the Haali Matroska splitter. It simply sits at the first frame and shows 1 frame drawn with a framerate of 0.0. The same MKV will playback using MPC-HC's internal matroska splitter.

To reproduce: Create an MKV with a AVC and FLAC 1.0 track.

Note: If I remove the FLAC 1.0 track, the video plays fine. I also haven't had any issues with FLAC 5.1 or 7.1 tracks. I think it's an issue with mono FLAC audio. I have also tested with and without the AC3 commentary tracks and PGS subs. The only factor that matters is the inclusion of a FLAC 1.0 track.

I have provided two samples which exhibit the issue, one from Everlasting Moments (2008) and another from Close-Up (1990). Both are small samples from a Blu-Ray remux. The original BD contained LPCM 1.0 tracks which were dithered to 16 bit, and encoded in FLAC.

The problem doesn't seem to affect all AVC + FLAC 1.0 MKVs. "M" (1931) fits this pattern yet doesn't have the problem. I used identical eac3to settings to demux, and verified that it still works when I create the MKV with MKVMerge 4.1.1. What's really odd is that all three films were produced by Criterion.

I have therefore provided a sample from M, which does work in Haali. Perhaps this will allow you to figure out why the others don't work:

Everlasting Moments Sample (Doesn't Work): http://www.mediafire.com/?htglad3iozbdt2d

Close-Up Sample (Doesn't Work): http://www.mediafire.com/?goulfu8ylc6ycds

'M' (1931) Sample (Does Work): http://www.mediafire.com/?1b2owc9f19mxsz5

Tested with MPC-HC SVN rev. 2099, Haali Splitter 05/20/2010, Mediaportal RC6 (uses Haali). Same behavior in each.

EDIT: Just realized that Everlasting Moments actually has a 5.1 track, yet it has the same behavior. I'm not sure what's going on as I have remuxed dozens of BDs and these are the only problematic ones.

FIXED: The problem was with the ffdshow FLAC decoder. Works with MPC-HC's internal FLAC decoder as well as madFLAC. Sorry for the inconvenience.

[Rodger]

Hy guys.

I don´t know what it is...but since updating to the current version the created mkv-files somehow are screwed up.

I found out because my Samsung TV suddenly didn´t play any audio in the newly created mkvs. Just to let you know....the video stream is played correctly. Older ones do play perfect as before.

I tried out some settings but I can´t get to work.
PLUS i just found out, that it´s not only my TV having problems with the files, but tsmuxer too!!!
"Some tracks not recognized....." comes with no recognized audio streams.

Anybody with a solution for this problem?

[SamuriHL]

Yes, if you'd have read this thread it has been discussed to death. You need to turn compression to NO on the extended tab for your audio track. And no, Mosu won't make that the default or give you a way to set that as default. :)

[Rodger]

Yes, if you'd have read this thread it has been discussed to death. You need to turn compression to NO on the extended tab for your audio track. And no, Mosu won't make that the default or give you a way to set that as default. :)

Sorry Mate. 0 Points for that answer. Doesn´t work.
And by the way...I found that tip before you posted it.

EDIT: I do have to correct. Playback on my SamsungTV does work now again, but tsmuxer still does not recognize the audio stream. THAT is still a HUGE disadvantage to me.

[SamuriHL]

Sorry Mate. 0 Points for that answer. Doesn´t work.
And by the way...I found that tip before you posted it.

EDIT: I do have to correct. Playback on my SamsungTV does work now again, but tsmuxer still does not recognize the audio stream. THAT is still a HUGE disadvantage to me.

And....you documented that in your original post that you set that? :rolleyes: Right, I know, we're all supposed to be mind readers as to what you've done and haven't done to fix the problem. Enough guessing games from me then.

[jasonwc]

Sorry Mate. 0 Points for that answer. Doesn´t work.
And by the way...I found that tip before you posted it.

EDIT: I do have to correct. Playback on my SamsungTV does work now again, but tsmuxer still does not recognize the audio stream. THAT is still a HUGE disadvantage to me.

I just tested one of the remuxes I made with MKVMerge 4.1.1. It added an AC3 stream to tsMuxer without issue, despite the fact that header compression was used. It was able to mux to TS as well. No errors.

When did your problem start and what was the last working version?

[Rodger]

I can pinpoint it to a certain Date. It was the 3rd of july.
I did´t update for quite a while before that. I think I do recall I updated from Version 3.4.

I do confirm, that I just have testet positively with a file, which wasn recognized fully by tsmuxer before.
Demuxed and remuxed it WITH setting to no compression.
NOW tsmuxer does find the fullHD AVC and the DTS-HD Stream inside.

That cuts my problem to my DVBS2-Recordings from a Vantage 7100s (SkyHD).
This is where I recognized the problem at first.

I currently have no such recordings at hand so I can´t test it right now. But surely will as soon as possible.

Thank you very much for your help so far.

[Sebastiii]

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)

Hi,
Aleksoid has reply on ticket and doesn't reproduce this issue, so it's seems all is ok :)

Could you post sample and or describe how you produce this issue ?

Thanks,
Sebastiii.

[sneaker_ger]

The problem only appears on subtitle tracks that are set to "eng" using mkvmerge >= 4.0.0 (thus do not have a track language element). All other combinations work fine.

[Brazil2]

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.
mkvtoolnix is not (only) about user requests, it's also (or even more so) about pushing Matroska features.
In every car I had since I got my driving license several decades ago, there was an electric cigarette lighter receptacle. It's a built-in feature, a part of the specs of the car.
But I'm a non smoker. So here comes the question: should I start to smoke because this lighter is available so I MUST use it ? Or is it useless ?

Header compression is a part of the Matroska specs, you want to support it, perfect, no problem.
But why do you want to FORCE people to use it by default since it's a pretty useless feature that saves only few bytes. If it was about MB I could understand, but bytes !?
And if we could at least save the default configuration we want to use for this option, but no we can't and we have to go through menus to set if off on every mux.

[SeeMoreDigital]

Given the radical changes with these new MKVmerge releases, how about closing this 3 and a half year old thread and creating a new "mkvtoolnix 4.x.x" thread from post 1611 onwards?

[Mosu]

Given the radical changes with these new MKVmerge releases, how about closing this 3 and a half year old thread and creating a new "mkvtoolnix 4.x.x" thread from post 1611 onwards?

Not a bad idea. I've asked Foxyshadis to do it.

[SeeMoreDigital]

Not a bad idea. I've asked Foxyshadis to do it.I do have them... from time to time ;)

EDIT: And for all those interested. The old thread can be found here: http://forum.doom9.org/showthread.php?t=120648

[LeXXuz]

I think there might be a bug with keeping the <eng> language ID of tracks when importing older matroska files.

I remuxed a couple of older matroska files with 4.1.1 and noticed that the <english> language ID always gets stripped from the outcoming file. Even if it is set correctly in mmg. This occurs for all kinds of tracks (subs, audio, video). However, the <german> language ID of any track is been taken over to the final file, as it should. At the moment I have to reopen those files with the Header Editor and replace the "undetermined" values of the language IDs manually.

Pardon me, if this has been reported before. :)

EDIT: Header Editor also hangs up after editing 2 or 3 files. The open file dialogue box does not appear anymore and the right window is empty even if a file is still opened:
http://img3.imagebanana.com/img/nbl8712q/thumb/headereditor.png (http://www.imagebanana.com/view/nbl8712q/headereditor.png)

[Mosu]

I think there might be a bug with keeping the <eng> language ID of tracks when importing older matroska files.

Yes, this has been discussed a lot after the release of v4.0.0. Please read this FAQ entry for an explanation: http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values

EDIT: Header Editor also hangs up after editing 2 or 3 files. The open file dialogue box does not appear anymore and the right window is empty even if a file is still opened:
http://img3.imagebanana.com/img/nbl8712q/thumb/headereditor.png (http://www.imagebanana.com/view/nbl8712q/headereditor.png)

This seems to a bug. I'll take a look when I find the time (meaning hopefully in the next couple of weeks).

[Selur]

got a question (just to be sure): 2010-07-12 Moritz Bunkus <moritz@bunkus.org>
....
* mkvmerge: bug fix: Header removal compression has been deactivated for MPEG-4 part 2 (aka DivX/Xvid) video tracks due to incompatibility with packed bitstreams.
Does this mean Header removal compression will be automatically deactivated when feeding mkvmerge with a MPEG-4 part 2 with packed bitstreams?

[Mosu]

No, it's completely turned off for MPEG-4 part 2, no matter whether the bitstream is packed or not.

[Underground78]

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.

And it does work ... I took the time to report the problem with "header removal compression" for the set-top box provided by the French FAI Free (http://en.wikipedia.org/wiki/Freebox) and the support of this feature will be added in next firmware !

[Keiyakusha]

I understtand the goal of making someone support wider range of the mkv specs by making changes to mkvmerge, but then I don't understand why we have webm support in mmg. More logical would be not allow creating VP8 videos in webm-compliant way.

[Mosu]

??? I want both Matroska and WebM to succeed. WebM is not a competitor to Matroska as it has a totally different focus.

[Keiyakusha]

Well, the focus is different, for now. But it will sneak in everywhere it can. From the perspective of a some manufacturer, why they should implement full matroska support if only webm is fine and most importantly its not bounded by patents? Currently webm is only lacking some subtitles support, but subs is a work in progress and webm will be expanded to support subs when they done. Also currently I'm doing backups with x264/apple aac but I'm gladely switch to VP8/vorbis and there will be no need for me in whole matroska. I'm sure the same valid for some other people.

[Mosu]

Sure, some people will switch, but h264+AAC in Matroska has gained way too much ground for companies to ignore. I simply don't think what you've described will happen, and not supporting WebM would be the worse for Matroska+WebM than the imaginary gain for Matroska by not supporting WebM.

[Snowknight26]

Shouldn't compression be turned on for A_PCM?

[Stephen R. Savage]

Possibly ZLIB compression or something similar, but I can't imagine header removal helping, since PCM has no headers.

[Selur]

btw. does webm support chapters?

[Snowknight26]

Possibly ZLIB compression or something similar, but I can't imagine header removal helping, since PCM has no headers.

Remuxed file was 85% of the original with compression turned on. And it wasn't PCM but WAV as mkvmerge doesn't support PCM (but says PCM as the codec when WAV is used).

[GodofaGap]

Remuxed file was 85% of the original with compression turned on. And it wasn't PCM but WAV as mkvmerge doesn't support PCM (but says PCM as the codec when WAV is used).
That doesn't make too much sense. WAV is a container and PCM is a way of representing uncompressed audio data in a digital way. Obviously MKVmerge supports PCM in WAV. :)

Perhaps the PCM data itself is compressed?

Sure, some people will switch, but h264+AAC in Matroska has gained way too much ground for companies to ignore.
Not only that. H264 and AAC have already found their way in lots of different hardware devices. They are not suddenly going to disappear. Also, you don't make a format open and then expect people to not use and build on it. :)

[AlistRain]

how to create a tag (eg "SourceFrom: string")
I could not do this with help and example-tags.xml

translated by google (translate.google.ru)

[mrbass]

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.


Truly sad state of affairs. I hope donations pick up eventually.

[Mosu]

Truly sad state of affairs. I hope donations pick up eventually.

Well... I don't do it for the money, and I don't ask for donations (I don't even have a "donate via paypal" button on my home page or something similar). So I'm perfectly OK with it. This was an argument that no decisions were ever based on the wishes of a company.

[DigitAl56K]

Mosu,

I see there have been many requests on the matter of header compression already so please do not take offense that I add mine also. I'm only contributing for what I feel is good for .mkv :)

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.

Firmware upgrades are something you and I and those we converse with here can all perform. They are not something 99% of people understand or are willing to do without being prompted with an easy-to-use "Update available, update now?" wizard popping up on their screen.

We're talking moms & pops, kids, grandparents, people who buy devices to watch movies, not to tinker with them. My mother would be too afraid to go through what's typically a poorly documented firmware upgrade process buried on a support website that's hard to find - if she could even download and extract the file to a suitable medium and follow the special startup procedure. My younger brother would manage it no problem - but he's a developer. My sisters? Again, no way. Lots of devices are sold rebranded under the names of big stores and have custom SKUs/model codes, complicating things even further.

*insert for yourself obvious blurb here about cost of regression tests, risk of bricking devices, etc. etc.*

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.

That's very idealistic, but far from reality. Consumers might choose a device because it plays some format or it doesn't. And when it comes to internet delivery formats vs formats you see on store shelves, like DVD and Blu-Ray even that is a subset of the overall segment. A consumer could read every line of text on a product package and all the in-store material and have no idea whether or not header compression was supported by a device. What percentage of Doom9ers knew what it was before you explained it, even though it's been in the specs for a long time? :)

You're also working against your own statement here: Consumers will buy a new device because their old one isn't working well whether manufacturers provide an update or not. (unless the update is conspicuously presented and simple to perform, not the case on the majority of device types)

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.

This is the key thing I wanted to put forth to you. What you are trading here is a few KB in data relative to a file that's likely to be GBs large against the masses having a positive experience around .mkv files. What happens when the average Joe tries to play an .mkv file and doesn't get any sound? Then he maybe tries another and it works. Then he tries another and it doesn't work again. He's not going to know that this is because header compression isn't supported. He probably doesn't even know where to find out and troubleshooting the issue probably hasn't crossed his mind. If you are lucky maybe he wastes his time and money trying a different device and perhaps it's no better. All he knows is that .mkv is unreliable compared to other formats. Average Joe is the vast, vast majority of people.

You can push a feature by having an option that people can set and even making it prominent, but let it be in a compatible mode by default. Pushing features is okay, but please give further thought to how this particular change might affect the perception of .mkv overall, which is much more vital to its success than these few KBs in data savings. If popular mkv writers will bluntly sacrifice interoperability over such issues stable, proprietary platforms will take away ground. Changing something fundamental like this in mkvmerge is pretty big and seems like an odd decision after so much effort has been spent trying to convince manufacturers to support .mkv. I don't think it helps the cause to willfully risk breaking devices only for the sake of pressing a very minor feature later. I've also had to make calls over interoperability many times and I know it is not easy, but I hope you will reconsider.

Those are my personal thoughts.

- Al

[Atak_Snajpera]

Average Joe will probably use RipBot264 for encoding. Don't worry I won't update mkvtoolnix to anything above 4.0.0

[Mosu]

That's very idealistic, but far from reality.

If I hadn't been idealistic I would never have started with Matroska in the first place. Again, sorry, but I won't change it.

[Mosu]

Average Joe will probably use RipBot264 for encoding. Don't worry I won't update mkvtoolnix to anything above 4.0.0

As an author of a frontend you can safely upgrade to > 4.0.0 if you're already using 4.0.0. Just add "--compression -1:none" to all non-subtitle files.

[LeMoi]

Average Joe will probably use RipBot264 for encoding. Don't worry I won't update mkvtoolnix to anything above 4.0.0

Average Joe doesn't rip, he downloads ! :D

[Atak_Snajpera]

As an author of a frontend you can safely upgrade to > 4.0.0 if you're already using 4.0.0. Just add "--compression -1:none" to all non-subtitle files.
How can i verify that track has not been compressed?

[Mosu]

Use mkvinfo. If that track does not have a 'content encoding' element listed then it is not compressed.

E.g. a compressed track (VobSub compressed with zlib in this case) looks like this:

| + A track
| + Track number: 2
| + Track UID: 2086699828
| + Track type: subtitles
| + Default flag: 0
| + Lacing flag: 0
| + Codec ID: S_VOBSUB
| + CodecPrivate, length 348
| + Language: dan
| + Content encodings
| + Content encoding
| + Content compression

Header removal compression looks like this (non-essential parts omitted):

| + Content encodings
| + Content encoding
| + Content compression
| + Algorithm: 3 (header removal)
| + Settings: length 1, data: 0xff

[Atak_Snajpera]

Thanks mosu!

[Audionut]

New VLC media player is fixed.

[7ekno]

Thanks for MKVToolnix and all the ongoing support ;)

Good idea to split the thread cause it took me a little while to find the relevant posts!

7ek

[shh]

Hello mosu,
I'm using your actual beta release from here: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/
version build20100719-289

Issue: Merging of files with compression on/off -> crash
I want to merge 2 MKVs containing MPEG4p10, AC3 and SRT.
1st (16.nocomp.mkv): not using header removal compression
2nd (17.comp.mkv): using header removal compression (=standard)
Now, when I activate "none" for compression of the video-track and try to mux the program crashes.
I've uploaded the files as:
16.nocomp.mkv
17.comp.mkv

[Mosu]

I can reproduce the issue here. I'll try to fix it this week.

[nautilus7]

I think that splitting a file after a given size functionality is broken in latest version.

[Mosu]

I don't think so:

[0 mosu@tionne (rake)# ~/prog/video/mkvtoolnix/data] ls -lL v.avi
-rw-r--r-- 1 mosu vj 13232128 2003-11-10 17:54 v.avi
[0 mosu@tionne (rake)# ~/prog/video/mkvtoolnix/data] mkvmerge -o v.mkv v.avi --split 5m
mkvmerge v4.1.1 ('Bouncin' Back') built on Jul 26 2010 23:49:13
'v.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'v.avi' track 0: Using the video output module.
'v.avi' track 1: Using the MPEG audio output module.
The file 'v-001.mkv' has been opened for writing.
Progress: 0%
The cue entries (the index) are being written...
The file 'v-002.mkv' has been opened for writing.

The cue entries (the index) are being written...
The file 'v-003.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 0 seconds.
[0 mosu@tionne (rake)# ~/prog/video/mkvtoolnix/data] ls -l v-00*.mkv
-rw-r--r-- 1 mosu vj 6094174 2010-07-27 09:06 v-001.mkv
-rw-r--r-- 1 mosu vj 5802909 2010-07-27 09:06 v-002.mkv
-rw-r--r-- 1 mosu vj 1245659 2010-07-27 09:06 v-003.mkv

What makes you say that?

[nautilus7]

Well, if i load a file and then select split after 50M, the files writen are very small (~5MB or so). Tried with different files and split sizes. Split after given duration works fine though.