MKVToolNix v24.0.0 released

[Mosu]

See this fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AReleaseCodenames) :)

[szabi]

Hi

How can it be set, the video in the mkv is interlaced by top field first order?

bye

[Mosu]

The Matroska format doesn't contain header fields for such properties. Therefore you cannot.

[szabi]

You might know, if a movie was encoded by megui (x264) with setting mkv file for output, where is this information stored?

[Guest]

The field order is specified by the syntax of the AVC elementary stream.

What are you trying to accomplish?

EDIT: I moved your response to a new thread as it is OT for this one:

http://forum.doom9.org/showthread.php?t=169707

Please continue there.

[jkauff]

Created an mkv file with the new version of MakeMKV from a ripped Blu-Ray, using only the main movie stream file. About 10 minutes in, there was a glitch with 200-300 dropped frames. Ran the mkv through mkvmerge, same glitch. Went back to the previous version of MakeMKV, same glitch. Played the Blu-ray folder, no glitch. Ran the stream file through mkvmerge, no glitch.

Mosu, I don't know what you're doing differently from the MakeMKV folks, but nice work handling a problematic source file!

[Atak_Snajpera]

Remuxed vc-1 mkv is unplayable . Latest v6.5 was used.
Sample -> https://mega.co.nz/#!IYNXRZRZ!N3DnCDGftXMwZ6tufjIoSiAe24ks2izHSkh3dFD5cB8

[Selur]

@Atak_Snajpera: Might be a decoding problem.
I tried remuxing your file with mmg which used:
"Y:\Kleinzeug\Videoverarbeitung\mkvtoolnix\mkvmerge.exe" -o "H:\\Output\\mmg.mkv" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1920x1080" "-d" "0" "-A" "-S" "-T" "--no-chapters" "(" "C:\\Users\\Selur\\Desktop\\Last_Man_Standing_VC1_10Min_0.mkv" ")" "--track-order" "0:0"
and i also tried mkvextract followed by mkvmerge with:
mkvextract tracks "C:\Users\Selur\Desktop\Last_Man_Standing_VC1_10Min_0.mkv" 0:"H:\Temp\test_16_19_56_0810_01.vc1"
mkvmerge --ui-language en -o "H:\Output\test.mkv" -d 0 --default-track 0:yes --default-duration 0:24000/1001fps --aspect-ratio-factor 0:1 --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Temp\test_16_19_56_0810_01.vc1"

both output mkv files played fine using mpc-hc (internal lav decoder with cuvid being used)

Cu Selur

[Mosu]

It's not, it's mkvmerge's problem. It marks all but the first frame as being P frames. Looking into it.

[Selur]

Seems like cuvid is more 'flexible' then :)

[nevcairiel]

Seems like cuvid is more 'flexible' then :)

The Microsoft decoder for example is pretty stupid in that regard, if key-frames are not flagged as such, it seriously screws up the decoding.

[Mosu]

You can give this new build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) a try (build number 541 and newer). Upload should be done in a minute or two.

[filler56789]

You can give this new build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) a try (build number 541 and newer).
Just done a quick mux test on a VC1 file generated through Mainconcept Reference, and
according to VirtualDub + the Matroska plugin,
all keyframes were correctly identified and flagged. :thanks:

P.S.: as for the much-expected HEVC support,
will it get out of the oven before next Christmas? :)

[Mosu]

It's not impossible, but unlikely given my current workload :( I would've been happier if it were different.

[Gruko]

Hi,
are you planning a support for h265 video tracks in TS format?

Thanks Mosu for your software.

[Mosu]

The same answer I've posted above your question applies to your question as well.

[sneaker_ger]

What about using the patch from DivX?

[Mosu]

That is what I will do, but from what I've seen from their patch I'm not willing to take it as it is. I will have to spend some time on it in order to whip it into the shape I'd want it to be.

I'm definitely not going to reinvent the wheel. I loath h.264 and how much complexity it causes even on the container level (determining frame types, and more importantly, correct frame DTS and PTS); therefore I'm very grateful for the work they've done already.

[Chetwood]

I have 4 m2ts files of various lengths (but identical video/audo) that I want to to remux into 1 new MKV. Appending them in mmg works but I would like to add 1 chapter when a new clip starts. Can this be done automatically or do I have to get the timings and add the chapters manually? Also, mosu, do you think this (http://forum.doom9.org/showthread.php?p=1655025#post1655025) is correct?

BTW, there's a typo in MMG's "Scan directory for other playlists" window: "The directory it is located it contains..." should read "in contains".

[Mosu]

There are no facilities for creating chapter entries automatically.

Thanks for pointing out the typo.

[Caroliano]

Since I moved to windows 8.1 mmg don't want to start here. No matter how I try to start it, the window never appears. I also tried the version 6.5.0. Any thoughts?

[nevcairiel]

I'm on 8.1 and mmg works fine here, so its not a general failure at least.

[Mosu]

Works fine on my 8.1 as well. Reset mmg's settings (https://trac.bunkus.org/wiki/FAQ%3ASettingsLocation) and try again.

[[ReX]]

I have 4 m2ts files of various lengths (but identical video/audo) that I want to to remux into 1 new MKV. Appending them in mmg works but I would like to add 1 chapter when a new clip starts. Can this be done automatically or do I have to get the timings and add the chapters manually? Also, mosu, do you think this (http://forum.doom9.org/showthread.php?p=1655025#post1655025) is correct?

BTW, there's a typo in MMG's "Scan directory for other playlists" window: "The directory it is located it contains..." should read "in contains".

You can try this (https://github.com/BrunoReX/mkvchap/releases) to at least automate the chapter file creation.

[Caroliano]

Works fine on my 8.1 as well. Reset mmg's settings (https://trac.bunkus.org/wiki/FAQ%3ASettingsLocation) and try again.
I deleted the MkvMergeGui registry key, but nothing changed. I also tried the portable version.

[Mosu]

Hey,

I've released MKVToolNix 6.6.0. I'm trying to get back on a release cycle of roughly six weeks between minor versions (minor being the middle part of the version number). So releases may happen more often than over the summer but contain few changes.

This release fixes a couple of bugs and greatly improves the compatibility to the newly released wxWidgets 3.0.0. A new translation into Portuguese has been added, and you can now re-order chapters in the chapter editor with the usual drag & drop operations.

Nothing has changed for package maintainers compared to the previous release, v6.5.0.

Here are the usual links:

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/source.html

...to the binaries:
http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

Here's the full ChangeLog since release 6.5.0:

2013-12-01 Moritz Bunkus <moritz@bunkus.org>
* Released v6.6.0.
* mmg: new feature: implemented drag & drop in the chapter editor. Implements #929 (https://www.bunkus.org/trac/ticket/929).

2013-11-24 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: fixed an assertion in wxLogMessage() due to wrong format string/argument data types caused by changes in wxWidgets 3.0.0. See Debian bug #730273 (https://www.bunkus.org/trac/ticket/730273).
* mkvmerge: bug fix: improved resilience against MP4 files with obviously wrong entries in the 'sample size table' (STSZ) atom.
* mkvmerge: bug fix: improved VC1 frame type detection so that it works even for streams without entry points.

2013-11-14 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: at most the lower 32bits of the track numbers and track UIDs elements were output, even if the element in the file used more bits. Fixes #935 (https://www.bunkus.org/trac/ticket/935).

2013-11-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed accessing invalid memory in the memory handling core routines. May be triggered by the code to remove filler NALUs introduced in v6.5.0. Fixes #931 (https://www.bunkus.org/trac/ticket/931).

2013-10-26 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: fixed the tracks list box on the input tab being invisible/0 pixels high with wxWidgets 2.9.x/3.x.
* all: integrated the Portuguese translation. Although the translation files themselves had been added back in 6.3.0 that translation wasn't available for selection due to forgetfulness on my part.
* mkvmerge: bug fix: The file detection code in the MPEG elementary stream reader had a logic error. Fixes #928 (https://www.bunkus.org/trac/ticket/928). In practice this logic error didn't have any consequence.

Have fun.

[hubblec4]

hey mosu

i have tested instantly the new chapter editor feature.

i get an error message after few drag and drop of changing the chapter positions.

[Simon88]

Hi Mosu,

I'm wondering if mkclean (v0.8.7) at: http://www.matroska.org/downloads/mkclean.html
is still compatible w/ the latest version of MKVToolNix v6.6.0?

mkclean (v0.8.7) was released quite awhile ago and hasn't been updated in more than a year... just wish to be on the safe side to know if there will be any issues or incompatibilities...

thanx...
-Simon

[73ChargerFan]

Cool - 6.6.0 starts up so quickly now! Thank you!

[Mosu]

I'm wondering if mkclean (v0.8.7) at: http://www.matroska.org/downloads/mkclean.html
is still compatible w/ the latest version of MKVToolNix v6.6.0?

I don't know. I'm not mkclean's author, and I don't use that program on a regular basis.

[sl1pkn07]

this is normal?

http://i.imgur.com/WAhQjfk.png

cut text

build last git with WxGTK/Widgets 3.0 in linux

greetings

[Mosu]

Dunno, looks way better on my Linux with wxWidgets 3.0.0. However, nothing in mmg specifies font sizes manually, and all text labels and buttons use their default height. So I consider this to be a problem of wxWidgets/your setup, not one of mmg.

[sl1pkn07]

only wreid with wxwidgets 2.9.x/3.0, with 2.8 looks fine


EDIT
with wxgtk/widgets 2.8.12 in same theme

http://i.imgur.com/oXx7S80.png

[Mosu]

So this looks like a bug in wxWidgets 3.0.0. You should report it via the proper wxWidgets bug reporting channels.

[hubblec4]

hi mosu

in the attached xml file is a ChapterProcess:

<ChapterProcess>
<ChapterProcessCodecID>0</ChapterProcessCodecID>
<!--Post command: replay this cell-->

<ChapterProcessCommand>
<ChapterProcessTime>2</ChapterProcessTime>
<ChapterProcessData format="ascii">GotoAndPlay(452202188);</ChapterProcessData>
</ChapterProcessCommand>
</ChapterProcess>

when i save this file with your chaptereditor i get another code.

<ChapterProcess>
<ChapterProcessCodecID>0</ChapterProcessCodecID>
<ChapterProcessCommand>
<ChapterProcessTime>2</ChapterProcessTime>
<ChapterProcessData format="hex">476f746f416e64506c617928343532323032313838293b</ChapterProcessData>
</ChapterProcessCommand>
</ChapterProcess>

do you use an algo or a function to transform the "ascii"-value into the "hex"-value?

and are both code-formats correct?

[Mosu]

As the chapter's XML file format is my own invention: yes, the "hex" format is 100% correct. "hex" is simply the hexadecimal representation of the bytes that make up that entry. In C terms:

for (idx = 0; idx < bin_length; idx++)
fprintf(file, "%02x", binary[idx]);

[Mangix]

will support for embedding TAK files come to mkvtoolnix?

[Mosu]

As it's a closed-source lossless audio codec and as MKVToolNix already supports several other lossless audio codecs (FLAC, TTA, ALAC) I doubt I will ever add support for TAK, no.

[Mangix]

Even though it's closed-source, a decoder does exist in FFmpeg. But I can see why adding it would be moot. Still, it does generate smaller files than most stuff.

[Mangix]

I did a few experiments with MPEG2 video and found that if zlib compression is enabled on the video, a smaller mkv file is created(969 vs. 955 MB). Using it on the audio creates a larger file. Maybe enable it by default for MPEG2 video?

Also, any plans to allow xz compression? It's becoming the standard for a lot of linux stuff(the kernel for example). It would also help save another ~18MB on this specific file.

[nevcairiel]

Only zlib is officially supported by recent versions of the MKV Specification. You can't just add new compression formats, because every player in existence would also need to support it.
Previous versions also supported bzip2 and lzo, but support for those was deprecated long ago and shouldn't be used anymore due to lack of player support.

[Mosu]

While the idea to use zlib by default for certain formats that lend themselves to further compression (the text subtitle formats, MPEG-1/2 video, maybe PGS subtitles) I won't do it. I'm still receiving bug reports time and again that there are hardware devices out there that refuse to play files in which zlib compression is used – even though VobSub track have always been zlib compressed. Yes, you can disable that, but my point is that both VobSub support and zlib compression support was introduced at the same time (even in the very same commit (https://github.com/mbunkus/mkvtoolnix/commit/3fcd47d)) – and that's been over ten years ago.

So I foresee a lot more problems popping up here and there if I'd enable zlib compression for any more tracks. True, unfortunately, but as ready as I am to jump onto the »this is spec-compliant, deal with it« bandwaggon I also realize that I don't have to introduce problems for users all the time. I already do that pretty often.

As for implementing new compression algorithms: as nev pointed out this would require additions to the specs, and later players would have to support them. As such tracks wouldn't be playable by players that exist today until they've been updated with the new algorithm it would pose even more problems than simply using zlib compression more. It would leave most hardware devices out in the cold as their manufacturers are notoriously bad in supporting existing devices with new firmware versions (there are a few notable exceptions, including but not limited to Syabas with their Popcorn Hour devices).

Also keep in mind that adding more code for embedded devices often poses great problems. Processing power is one thing to keep in mind, available memory is another. xz (and lzma which xz is based on) compresses better and decompresses faster than bzlib2, but it also requires more memory. zlib is a good compromise as it requires very little CPU and memory during decompression (lzo is even better but compresses worse).

So this is a »no« to both requests. While they do have merits the potential heartaches aren't worth it.

[Mosu]

Hey,

I finally figured out which part of my build system was producing 64bit binaries that could not be run on a 64bit Windows. Turns out it was the manifest files which still contained the wrong processor architecture. After having fixed that I now have nice 64bit builds of all applications – even packaged in an installer. (The installer itself continues to be a 32bit program, and that will not change.)

In order to be able to provide both 32bit and 64bit binaries in the future I'd like some feedback on whether or not there are any problems with said 64bit builds. The first of those is available from the usual location (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/). Look for the ones with »-amd64« in their names. The other ones are still 32bit.

Now to the second part: I decided to finally remove the word »-unicode« from the installer and the 7z archive file names. This is a purely cosmetic change. Back in the days of v2.2.0 I still released non-Unicode enabled builds for Windows 9x. I haven't done that for over five years, and therefore there's no need to point out that this build is Unicode-enabled in the file name. They are. Have been for very long. Will always be so.

Just so you won't be confused and alarmed :)

[Rodger]

Hi Mosu,

instant download for the 64bit version just happened :thanks:

But quickly found out....having it on my hard disk I couldn´t tell which version it is.
There is nothing to divide the 32bit version from the 64bit one.

Please integrate an info into the "-help > about" screen.


/EDIT:
First thing I tried went well.
> Remuxing a m2TS file into mkv with video stream and only one audio kept.
I had hopes that the performance would raise with a native 64bit release.
I made a video of the utilisation of my system please have a look at it. There are several unknown drop downs in performance.
I have a strong feeling that the cache management isn´t optimal.
Seen this behavious in the 32bit versions as well so nothing to be too worried about.

Link following..... http://ul.to/4vndjsfk

Infos on my System:
I3770 @ 4500Mhz
16GB Ram
Win8.1
SSDs involved (A Samsung 840 pro is for Win8.1 ONLY but not involved in this process)
SSD1 READ C300 256GB @ Sata2
SSD2 WRITE M4 512GB @ SATA3

[easyfab]

You can see under the task manager ( processes) if it's 32 or 64bit

If mmg.exe*32 -> 32bit if mmg.exe -> 64bit

[Rodger]

I think we can easily agree that it should not be neccesary to investigate which version is present.

[Mosu]

Knowing which version it is may be important for certain kind of bug reports. But even those are a minority. I'll nevertheless add that information to the about box if I don't forget about it ;)

[Mosu]

As to the performance. There is really no advantage to running mkvmerge in 64bit mode vs 32bit mode. All features are present in the 32bit mode, and performance mostly depends on the machine's I/O sub-system. There are certain codecs for which memory performance trumps I/O performance. Among those is h.264 when it is read from unframed sources (M2TS, AVI, raw h.264 ES – but not if it's read from MP4 or Matroska files).

I don't do anything special for 64bit builds regarding cache coherency, and to be honest I don't plan on investigating any time on optimizations in that area.

[Chumbo]

Knowing which version it is may be important for certain kind of bug reports. But even those are a minority. I'll nevertheless add that information to the about box if I don't forget about it ;)
This is great. Some UIs add "(64bit)" as a suffix to the title bar for the 64bit version. Is this something that's simple enough to do?

[Mosu]

I'll do exactly that, yes. It's trivial to do, yes, the configure checks are all present already.