mkvtoolnix 4.1.1 released

[KoD]

Ah, I was not aware there was a File->New menu option !

In this case there's no need indeed for clearing those fields when remove is pressed.

[Mosu]

Here's a new build with a couple of bug fixes in the VC1 code. Especially EVOBs with multiple VC1 video tracks are read correctly now.

http://www.bunkus.org/videotools/mkv...20080925-1.rar

[STaRGaZeR]

A request Mosu, can you add a 60000/1001 option?

[yonta]

Mosu, can you take a look at this sample?
It's from a HDTV cap and 1080i@60 MPEG2 ES.
I try to load it in mmg and mmg gives that message I get when I load a AVC ES?

You're adding an AVC/h.264 elementary stream.......

I'm using 20080925-1 build.

[Mosu]

Please download this build: http://www.bunkus.org/videotools/mkv...20081004-2.rar It fixes file type detection for your file.

[madshi]

@Mosu, would it be easy for you to add a version resource to the win32 mkvmerge.exe and mmg.exe files? Or at least to the mmg.exe file? The reason I'm asking is that my "eac3to" tool contains an "is there a new mkvtoolnix beta build available?" online check. Currently I'm using "mkvmerge --version" to do this check. But it seems that sometimes mmg.exe has a later date in a new beta build compared to mkvmerge.exe (e.g. in latest beta build mkvmerge reports Oct 4, while mmg.exe seems to be Oct 5), and since I can't programatically read out the mmg.exe version number and compile date, my version check sometimes fails to work properly.

[Mosu]

Starting with http://www.bunkus.org/videotools/mkv...0081006-12.rar all EXEs have VERSIONINFO resources. Here's such a resource for mkvmerge for a release version:

1 VERSIONINFO
 FILEVERSION 2, 3, 0, 0
 PRODUCTVERSION 2, 3, 0, 0
 FILEFLAGSMASK 0x3f
 FILEOS 0x4
BEGIN
  BLOCK "StringFileInfo"
  BEGIN
    BLOCK "040904B0"
    BEGIN
      VALUE "CompanyName", "Moritz Bunkus"
      VALUE "FileDescription", "mkvmerge"
      VALUE "FileVersion", "2.3.0"
      VALUE "InternalName", "mkvmerge"
      VALUE "LegalCopyright", "Released under the GNU Pulic License http://www.gnu.org/licenses/gpl-2.0.html"
      VALUE "OriginalFilename", "mkvmerge"
      VALUE "ProductName", "MKVToolNix"
      VALUE "ProductVersion", "2.3.0"
    END
  END
END

Builds between releases have their build date and number coded into "File Version" and "Product Version", e.g.

...
      VALUE "FileVersion", "2.3.0-build20081006-12"
...

[madshi]

That's *very* nice - thank you!

Just a quick question: Is there a specific exe you're always updating in a new beta build? Or should I simply loop through all exes to make sure I find the newest one to be able to show the proper version information?

[Mosu]

I've modified my build and upload scripts to always put the same version information into all EXEs and to re-build all EXEs for a beta build. Each build has its own unique version/build number. Therefore you should not have to loop through all EXEs anymore.

PS: The information shown in mmg's "About" window and in "mkvmerge --version" might not correspond to the version information in the resource. Use the data from the resource. That's more reliable for the Windows port. (The reason is simple: time. Building mkvmerge so that its --version output is up to date takes about 5 minutes with my crappy build computer while simply relinking with newer resources is done in 15 seconds or so.)

[madshi]

Great, will update my version check accordingly. Thanks again!

[madshi]

P.S: You could change the "mkvmerge --version" code in such a way that it reads its own EXE version resource and then outputs that. As a result you'd never have to waste those 5 minutes, anymore. At least that's how eac3to's version display works...

[Mosu]

True, but that's no cure because there's no such thing as resources on non-Windows operating systems

[swaaye]

I've noticed that mkvmerge is very slow when muxing to a network drive. On my gigabit LAN, it can only pull about 5 MB/s even when it is only writing to the network (reading sources from local system drive.) I can dump DVDs to network drives at 20-30 MB/s, on the other hand.

Is this due to small-sized write accesses causing tons of overhead perhaps? It's a curious thing.

[Mosu]

Yes, most likely. mkvmerge is not multi-threaded and does not use advanced read-ahead or caching mechanisms. Sorry, I don't have time to do everything.

[swaaye]

Originally Posted by Mosu

Yes, most likely. mkvmerge is not multi-threaded and does not use advanced read-ahead or caching mechanisms. Sorry, I don't have time to do everything.

No no. I'm not asking for anything, just mentioning what I've run into. Your app is great! I'm not exactly using it in a typical way and it's not a critical thing at all .

[zeropc]

mosu, is it possible to add full support of .m2ts container import?

this would save some big time demuxing

[Mosu]

Maybe, maybe not.

[madshi]

There are 2 big problems with adding m2ts support to mkvtoolnix:

(1) Some audio tracks might need transcoding to make sense. E.g. there's no current standard to store TrueHD in MKV. So TrueHD would have to be transcoded to something else. Or alternatively the Matroska "official forces" would have to be asked to add an official method to mux TrueHD into MKV. But even if that happens, mkvtoolnix would still have to be able to strip the AC3 frames from the TrueHD stream. That's possible to do, but can't be developed in 5 minutes.

(2) Some Blu-Ray movies consist of multiple m2ts parts. Simply demuxing video/audio and remuxing them into MKV would result in audio slowly drifting out of sync throughout the whole movie because audio overlaps in these m2ts parts while video (usually) does not.

As a result I'm not sure if it's worth it for Mosu to add m2ts support. However, @Mosu, if you want to add ts/m2ts support, when you have any technical questions, feel free to contact me.

[Mosu]

Originally Posted by madshi

(2) Some Blu-Ray movies consist of multiple m2ts parts. Simply demuxing video/audio and remuxing them into MKV would result in audio slowly drifting out of sync throughout the whole movie because audio overlaps in these m2ts parts while video (usually) does not.

Oh my frellin' god. Which idiot came up with that scheme!?

Anyway, adding MPEG TS support is one of the bigger projects left. I might tackle this one day, but that's more an "if I find the time and motivation" than a "when I find the time and motivation".

[madshi]

Originally Posted by Mosu

Oh my frellin' god. Which idiot came up with that scheme!?

Well, if you think about it, it does make some sense. Each of the m2ts parts must play on its own (this logic is mainly used for seamless branching titles). So at the beginning of each m2ts part video and audio are perfectly in sync. But since e.g. an AC3 audio frame is 32ms long and video frames are usually 41.7ms long there's a runtime mismatch between audio and video. So it's clear that either audio or video have to overlap a bit. That's ok for a Blu-Ray player, but of course a bit problematic for a demuxing/transcoding tool.