MKVToolNix v24.0.0 released

[Mosu]

File a bug report with mplayer. In Matroska the container AR takes precendence over the bitstream AR, and it seems mplayer is not using the container AR at all if there's no bitstream AR. Bug in mplayer.

[magic75]

I get the same behaviour with vlc.

Something has at least changed with mkvmerge:
5.1.0 => Display aspect ratio : 16:9
6.0.0 => Display aspect ratio : 1.667

I am assuming that mkvmerge sets the container AR?
I am pretty much certain that the bitstream AR is 700/420=1.667, as I have not told x264 the actual AR.
I have however told mkvmerge --aspect-ratio 1:16/9 , which seems to be set by 5.1.0, as described above.

[sneaker_ger]

Note that mkvmerge starts counting at "0", so maybe you need to use "--aspect-ratio 0:16/9". Do you see any warnings by mkvmerge? And again: are the source files identical?

[Mosu]

sneaker_ger is most likely spot-on. The way the track IDs are generated has been changed somewhere in the middle of the 5.x.y release series. Read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AMkvextractWrongTrackMkvinfoMkvmergeTrackIDsWrong).

[magic75]

Yes, that did the trick!
I just searched the changelog for something regarding aspect, so I missed this.
Thank you sirs...

Not that it matters much anymore, but no the source files weren't identical, but they were the same resolution (700x420).

[DiNZi]

Hi there, are there any known issues at the moment with MKVToolNix v6.0.0 and VLC? I recently bought an LG BH6220S BluRay Home Cinema and with any MKV files muxed with v6.0.0 I cannot seek or fast forward, it crashes the player and I have to restart the player, with VLC it would take atleast 5 minutes to seek from the first minute to maybe an hour into the movie.

Although, if I take the same MKV files that are muxed with v6.0.0 and open it up in MKVMerge v5.8.0 and just save the file, that works fine the player would allow me to fast-forward/seek and VLC I can jump to any part of the movie without any problems.

I don't think this is a problem with VLC, as my player also doesn't seem to like something here. I don't mind running my MKV files that are already muxed with v6.0 through MKVMerge v5.8 and saving them, but would be nice if in the next build the setting that's causing this issue could be rectified to how it was in v5.8.0.

Cheers!

[sneaker_ger]

It is a bug in VLC:
https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590

[Mosu]

Wow, you obviously spent no time at all search for this. It has been asked multiple times, described just as often, even in this very thread. Fascinating.

Or maybe you did and were just unlucky. In any case, read this fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590).

Congratulations on asking this when I'm really pissed off due to other things. Your prize, unfortunately, is this snarky response.

[DiNZi]

Well, It is not just VLC is it? Things muxed with build v5.9.0/v6.0.0 just cannot use seek in quite a few BluRay players, doesn't work with my LG BluRay player, link below says doesn't work on a Sony BluRay player.

I don't understand how a new build can be released with the same bug as the previous build and nothing done about it.

http://forum.videohelp.com/threads/338925-Muxing-with-mkvmerge?p=2106432&viewfull=1

Thanks for the speedy response Mosu.

[sneaker_ger]

I don't understand how a new build can be released with the same bug as the previous build and nothing done about it.

There is no bug in mkvmerge - stop repeating it. Not all players work with all or the same subset of mkv features and even the VLC devs themselves have acknowledged it is a bug in VLC. In the FAQ you find infos on how to turn off these features to restore compatibility with broken players.

[Mosu]

Because it's not a bug in mkvmerge. It's bad implementations in the hardware devices. mkvmerge writes spec-compliant files. The hardware devices do not support the latest elements (which is understandable), but they also don't support one of the most basic principles of what makes Matroska Matroska: extensibility. One of Matroska's core concepts is "if you don't support that element then just ignore it". Those players don't follow that; they just stop parsing, or crash, or whatever. Basically they don't support Matroska -- even though they claim they do.

The situation with MP4 is similar. It's also a format that can evolve over time and that requires players to skip elements the player doesn't know about. Technically there's not much of a difference between the two situations from the player's point of view. But MP4 support in hardware devices is a lot better as they actually follow that rule ("ignore what you don't know").

Big money is not always right. They're very, very often very lazy though.

So will I do anything about it? No frellin' way. I don't cater to broken hardware implementations most of the time. And this is so fundamentally broken on the player's side that I will not waste my time dumbing a spec-compliant program down to the lowest common denominator.

If you want to know what options such a player vendor has then just read the the possible solutions I've outlined for VLC (https://trac.videolan.org/vlc/ticket/7887). They're not that difficult to implement, but I guess hardware vendors will still drag their heels and only support stuff that's newer than 12 months.

[DiNZi]

Cheers for the reply sir, I fully understand, it isn't the first problem I have come across playing MKV on this new LG BluRay player, I will continue using v5.8.0 as recommended in the bug report that will do fine.

The other was that the player just cannot seem to read chapters in the MKV container, I used to have a £30 Toshiba BluRay player with a USB port that used to read chapters fine but I opted for this LG BluRay Home Cinema that only sees title 1/1 but doesn't read the chapters I doubt there is anyway around this luckily there is a feature where you can jump to a certain timescale.

[Atak_Snajpera]

Well, It is not just VLC is it? Things muxed with build v5.9.0/v6.0.0 just cannot use seek in quite a few BluRay players, doesn't work with my LG BluRay player, link below says doesn't work on a Sony BluRay player.

my cheap Samsung TV UE32EH5000 plays mkvs (v6.0.0) without any problems. So you can only blame Sony or LG for bad firmware.

[DiNZi]

my cheap Samsung TV UE32EH5000 plays mkvs (v6.0.0) without any problems. So you can only blame Sony or LG for bad firmware.

I'm sure if I try it on my cheap Toshiba BluRay player it will also play without any problems, but that's no good to me. I have tried reporting it with LG before but they just say the ticket goes to the feedback centre n they are not sure when I will get a response. Unfortunately there isn't a way you can check these things before you but the product as well, you just have to go on if it supports MKV or not really.

[Atak_Snajpera]

No wonder Samsung sells better than Sony these days ;)

[Emp3r0r]

No wonder Samsung sells better than Sony these days ;)

My LG G2 GoogleTV also has the aspect ratio problem and I'm on a mission to have Google or LG fix it.

Sample file (https://docs.google.com/file/d/0B97a2IRj7gFpWGhuVFN6Rm9ZdjA/edit?usp=sharing)

Google+ Discussion (https://plus.google.com/u/0/113365530033690596670/posts/F2E9gykhcRd)

[smok3]

hint: if you happen to be using some sort of manual nix desktop (like #! openbox), then the answer to the riddle is to type
mmg
to start mkvmerge-gui
(there, just saved you at least 1 blonde minute)

[Avisynth_challenged]

I have a quick question about Mkvmerge.

I notice whenever I append 1080i HD MPEG2 sources together using Mkvmerge that the resulting .mkv file is about 15-20% smaller than the total size of the appended MPEG2 source files.

I don't mind getting smaller filesizes, but I was wondering if Mkvmerge is applying lossy or lossless compression to the source MPEG2 files when it appends them together into the mkv container?

I am very curious. Does anyone here notice the same behavior, or know why the mkvs are smaller (in filesize) than the source files they contain? Thanks in advance for any responses :)

[Guest]

If the source files are M2TS/TS then be aware that the overhead of transport streams is higher than that of MKV containers.

[nevcairiel]

Broadcast MPEG2 streams can also commonly include "padding" data to provide a more constant bitrate, which mkvmerge discards. This data is useless, so throwing it away is still "lossless", no actual image data is lost.

[Mosu]

I've released MKVToolNix 6.1.0. It's one main new feature is support for Blu-ray playlists (MPLS files). You can add them just like any other file and mkvmerge will use the files the playlist references instead. If you add such a playlist in mmg you can let mmg scan the whole directory for other playlists. mmg will then present you with the results (which include each playlist's duration, the referenced files, total file size, the number and types of tracks and the number of chapters) from which you can chose which playlist to actually add. This allows for easy selection of the most appropriate playlist (often the longest, but not always).

There are a few other minor new features and a lot of bug fixes as well. Please look at the ChangeLog below for the details.

For package maintainers nothing has changed. MKVToolNix still requires its bundled versions of libEBML and libMatroska because new versions of them haven't been released yet (just like in 5.9.0).

You can download the source code (http://www.bunkus.org/videotools/mkvtoolnix/source.html) or one of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html).

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 6.0.0:

2013-03-02 Moritz Bunkus <moritz@bunkus.org>
* Released v6.1.0.

2013-02-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed mkvmerge sometimes mistakenly detecting MPEG-1 video in MPEG program streams as AVC/h.264. Fixes #845 (https://www.bunkus.org/trac/ticket/845).
* mmg: new feature: When a playlist file (e.g. MPLS Blu-ray playlist) is added mmg can optionally scan all the other files in the directory that have the same extension and present the user with the results (including them playback time, total size, number of chapters, number and types of tracks). The user can then select the actual playlist file to add. The user can configure the minimum playlist duration in order to filter out too short ones.

2013-02-22 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added an option for disabling making the suggested output file name unique by adding a running number (e.g. ' (1)'). Implements #848 (https://www.bunkus.org/trac/ticket/848).
* mmg: new feature: The output file name can be auto-set to be located in the first input file's parent directory. Implements #849 (https://www.bunkus.org/trac/ticket/849).

2013-02-17 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo, mkvpropedit, mmg's header editor: bug fix: Fixed the description for the DisplayUnit element to include value 3 ("aspect ratio").

2013-02-16 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a Dutch translation of mmg's guide by René Maassen (see AUTHORS).
* mkvmerge: bug fix: Fixed handling chapters when splitting by parts (both parts/timecodes and parts/frames). Fixes #831 (https://www.bunkus.org/trac/ticket/831).
* mkvmerge: bug fix: Fixed reading certain MP4 atoms with invalid length fields.

2013-02-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix in common AAC code: Fixed wrong calculation of AAC packet size for malformed packets resulting in "safemalloc()" failing to allocate memory. Part of a fix for #832 (https://www.bunkus.org/trac/ticket/832).

2013-02-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented support for reading MPLS BluRay playlist files. All M2TS files referenced from an MPLS file are processed. Chapter entries from that MPLS file are used as well. Implements #765 (https://www.bunkus.org/trac/ticket/765).

2013-01-26 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Selecting one of the pre-defined values from the "split by X" argument drop down box (e.g. "700M") was not leaving the selected entry in the drop down box but set it to empty instead.

2013-01-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading VP6 video from FlashVideo files. Fixes #836 (https://www.bunkus.org/trac/ticket/836).

2013-01-20 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed validating the argument for splitting parts by frame/field numbers. Fixes #835 (https://www.bunkus.org/trac/ticket/835).

Have fun.

[sneaker_ger]

What is the pre version for? I don't see any changes on github.

[Mosu]

Ignore it. Just testing a bug fix that's still incomplete.

[noee]

Very cool with the mpls support. Is your intent that the "add" dialog locks Explorer in drag-mode until it's dismissed? Win7 Ult x64.

[robpdotcom]

Thanks Mosu. Bluray to Matroska just got even easier.

[Mosu]

Very cool with the mpls support. Is your intent that the "add" dialog locks Explorer in drag-mode until it's dismissed? Win7 Ult x64.

Nope, definitely not my intent. Wasn't aware of it as I usually don't use D&D :) I'll fix it.

[yonta]

mpls(m2ts) support works just fine except that it can't read LPCM audio track.

small samples;
16bit/2ch/48KHz (http://www.datafilehost.com/download-2b0ee3a7.html)

24bit/2ch/48KHz and 24bit/5.1ch/48KHz (http://www.datafilehost.com/download-73445e62.html)

[Mosu]

mpls(m2ts) support works just fine except that it can't read LPCM audio track.

mkvmerge doesn't support LPCM at all, no matter the container it comes in. And no, I won't add support for it (any time soon), sorry.

[Thunderbolt8]

madshi and mosu, without meaning to be disrespectful to either of you or your tools, and just from a technical point of view:

can it be said now that remuxing via eacto is kind of obsolete if you dont want to perform tasks only eac3to can do (e.g. encoding/changing audio formats etc.)?

or does eac3to process the remuxed (video) files in a different way than mkvmerge does which might or might not be recommendable to use?

[Mosu]

I'm usually not a user of eac3to, but I'm aware of a lot of processing options available in eac3to that I don't see ever being implemented in mkvmerge. For example dealing with dialog normalization, re-coding of audio tracks, applying volume changes, remapping audio channels, downmixing etc, removing pulldown from video. So I would definitely say that eac3to still has and will keep its usefulness.

If your question's scope is only limited to remuxing then I should refrain from commenting as I only know mkvmerge's feature set, and I cannot say whether or not eac3to has remuxing capabilities that mkvmerge doesn't.

[Thunderbolt8]

yes, but thats what I said "if you dont want to perform tasks only eac3to can do".

Im basically talking about situations when you only want to keep the video and original audio without any encoding or something like that. afaik eac3to uses mkvmerge for muxing anyway so there shouldnt be much differences? or does it apply anything differently?

and in such a case you'd also have one step less to do, because you dont need to mux audio and video together afterwards anyway via using mkvmerge.

am I seeing this correctly?

edit: forgot about dialnorm removal. thats indeed a thing Id like to have. so I guess Im sticking to using eac3to as first step then :D

[Mosu]

No, eac3to does not use mkvmerge as far as I know. It either has its own routines for writing Matroska files or it uses some library/DirectShow filter. madshi will hopefully shed light on this.

[sl1pkn07]

eac3to use Haali matroska muxer to mux in mkv

For video muxing you need:
(1) Haali Matroska Muxer

[Thunderbolt8]

right, must have mixed that up because mkvtoolnix is also checked upon when using eac3to -test

[sl1pkn07]

right, must have mixed that up because mkvtoolnix is also checked upon when using eac3to -test

since 3.25 don't use mkvtoolnix

└───╼ eac3to -test
eac3to (v3.27) is up to date
Nero Audio Decoder (Nero 6 or older) doesn't seem to be installed
http://www.nero.com/eng/store-blu-ray.html
CAUTION: You need Nero 7. Nero 8 won't work with eac3to.
ArcSoft DTS Decoder (1.1.0.8) works fine
Sonic Audio Decoder (3.27.0.0) doesn't seem to be installed
Haali Matroska Muxer (2011-09-08) is installed
Nero AAC Encoder (1.5.4.0) is up to date
Surcode DTS Encoder (1.0.29.0) is installed

http://forum.doom9.org/showpost.php?p=1608610&postcount=11977

[Mosu]

Very cool with the mpls support. Is your intent that the "add" dialog locks Explorer in drag-mode until it's dismissed? Win7 Ult x64.

This has been fixed. A new build for Windows is available (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) (build numbers 503 and higher).

[Chumbo]

@Mosu,
Would you please take a look at this post (http://forum.doom9.org/showthread.php?p=1618186#post1618186) regarding setting the DAR when the aspect ratio is provided?

From everything I've read on AR and what Sharc mentions, it seems that mkvmerge, when using --aspect-ratio, should be setting the DAR of a 720x480 4:3 video to 640x480 (the "real" 4x3 size) but instead, it's setting the height, i.e., 720x540. For 16x9, mkvmerge sets the width correctly, so it's just for 4x3 where the height is being adjusted.

Please tell me if you need any other info or if I'm missing something.

[Mosu]

mkvmerge's policy regarding display width/height calculation is to always, always scale upwards. Never downwards. Because... why would you want to deliberately throw resolution away that is present?

Yes, that is intentional. No, I won't change it. If you want different values then provide them directly.

[Chumbo]

mkvmerge's policy regarding display width/height calculation is to always, always scale upwards. Never downwards. Because... why would you want to deliberately throw resolution away that is present?

Yes, that is intentional. No, I won't change it. If you want different values then provide them directly.
To answer your question, I wouldn't and I'd rather have it doing what you're doing. I was just asking in regards to the output being "non standard," for a lack of a better term, NTSC resolution. Won't that cause problems for devices? Anyhow, the 720x540 doesn't seem to create any issues for the devices I have so that's good.

[Mosu]

I don't really care if a device has a problem with a certain resolution. If they do all I do is laugh at the incompetent manufacturers. I'm about writing spec-compliant files. I'm not about writing the most compatible files because that endeavour has shown to be impossible in the past (based on actual products: bad player X doesn't like having clusters listed in meta seek and bad player Y cannot seek without them).

[Chumbo]

I don't understand. From everything I've read in regards to this, if you're writing spec-compliant files, then 720x480 NTSC files should be downsized to 640x480 since 480 must stay 480. Personally I hate that, but it is what it is and I'm trying to understand how 720x480 taken up to 720x540 is spec-compliant? I agree that even the players that do an outstanding job of playing BDs seem to not have it exactly right when playing back SD media files.

[Mosu]

The Matroska specs is what I meant. And they do not make any rules about how display width/height should be calculated for video of size X with pixel aspect ratio Y.

If I'm producing a DVD then I have to follow the DVD specs. Same for Blu-rays. But if I'm creating a Matroska file then I don't care about Blu-ray or DVD specs or NTSC specs.

End of discussion for me.

[Chumbo]

The Matroska specs is what I meant.
...
Gotcha, that makes sense.

[Bigmango]

Forced subtitles are not detected/marked as such when importing an mpls. Is this something that could get fixed in a future release?

Many thanks.

[Mosu]

Where is that piece of information stored?

[sneaker_ger]

I suspect it isn't and is rather DVD style: no marking for tracks but only for lines, with track selection done by the menus.

[Mosu]

Then the answer would be "no".

[tormento]

When I finish a x264 encoding, I put in the same directory v.mkv (the output video), ita.ac3 (my language), eng.ac3 (or any other original language), ita.srt and eng.srt.

With the latest pre version in windows and not with 6.0, whenever I drop v.mkv and then ita.ac3, mmg adds v.mkv again. If, at this point, I delete v.mkv and drop eng.ac3, mmg adds v.mkv twice!

Anyone with my same problem?

[sneaker_ger]

Confirmed.

[Mosu]

Oh yikes I know exactly what the problem is... Thanks for reporting; will be fixed in the next pre-build that's currently compiling.