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.

[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%3AP...eekMkvmerge590

[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.

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]

Originally Posted by DiNZi

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. 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]

Originally Posted by Atak_Snajpera

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]

Originally Posted by Atak_Snajpera

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

Google+ Discussion

[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.