MKVToolNix v24.0.0 released [Archive] - Page 3

Mosu

15th February 2013, 15:13

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

15th February 2013, 15:21

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

15th February 2013, 15:29

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

15th February 2013, 15:32

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

15th February 2013, 16:00

No wonder Samsung sells better than Sony these days ;)

Emp3r0r

22nd February 2013, 06:29

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

27th February 2013, 22:45

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

1st March 2013, 03:17

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

1st March 2013, 03:35

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

nevcairiel

1st March 2013, 08:09

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

2nd March 2013, 18:18

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

2nd March 2013, 23:48

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

Mosu

2nd March 2013, 23:50

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

noee

3rd March 2013, 00:46

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

3rd March 2013, 02:32

Thanks Mosu. Bluray to Matroska just got even easier.

Mosu

3rd March 2013, 09:10

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

3rd March 2013, 14:14

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

3rd March 2013, 16:11

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

3rd March 2013, 16:19

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

3rd March 2013, 16:28

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

3rd March 2013, 16:33

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

3rd March 2013, 16:37

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

3rd March 2013, 16:46

eac3to use Haali matroska muxer to mux in mkv

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

Thunderbolt8

3rd March 2013, 16:48

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

sl1pkn07

3rd March 2013, 16:49

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

3rd March 2013, 17:14

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

3rd March 2013, 20:48

@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

3rd March 2013, 20:51

Chumbo

3rd March 2013, 22:05

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

3rd March 2013, 22:14

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

3rd March 2013, 22:21

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

3rd March 2013, 22:24

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

3rd March 2013, 22:29

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

Bigmango

4th March 2013, 04:19

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

4th March 2013, 08:55

Where is that piece of information stored?

sneaker_ger

4th March 2013, 08:58

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

4th March 2013, 09:00

Then the answer would be "no".

tormento

4th March 2013, 09:05

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

4th March 2013, 09:08

Confirmed.

Mosu

4th March 2013, 09:09

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

Mosu

4th March 2013, 09:56

Build number is 505 (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

tormento

4th March 2013, 11:11

505 seems to have fixed the problem. Thanks.

Bigmango

4th March 2013, 14:49

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.

Forced subtitles selection is done automatically. Nothing to do with the menu.

MakeMKV, DVDfab, and other tools detect forced subtitles properly.

Blu-ray players also detect them an auto-play them properly.

This means, forced subtitles can be detected. Imho, Mkvmerge should auto-flag them as forced subtitle "YES".

Mosu

4th March 2013, 14:51

Let me repeat: where is that information stored? I mean where exactly? "Others can do it" and "mkvmerge should do it" don't help me.

Bigmango

4th March 2013, 14:53

Let me repeat: where is that information stored? I mean where exactly? "Others can do it" and "mkvmerge should do it" don't help me.

I am only giving the information I have. I hope others will contribute with "how it is done".

Many thanks for your great work.

sneaker_ger

4th March 2013, 15:05

MakeMKV, DVDfab, and other tools detect forced subtitles properly.

They may be able to detect forced lines, but this doesn't help with the forced track element of matroska. Forced subs are either incorporated into the full subtitles, with only the forced lines marked as forced, or as a separate track and not marked as forced at all. Either way there is no way for mkvmerge to detect these things. The only thing it could do would be to try some kind of smart auto-guessing or move lines that are marked as forced into a separate track - but that is probably out of scope and would require a full scan of the files before muxing and the guessing would also fail often.

Blu-ray players also detect them an auto-play them properly.

But Blu-Ray players go through the menu system first. These tell the player which (if any) subtitle track it should select and if it should play all or only forced lines.

Bottom line: Blu-Ray and DVD only work with forced lines which may or may not (separate track) be used by the authoring house. Matroska uses forced tracks instead of lines, so that's a different concept, meaning you cannot simply transfer these informations.

nevcairiel

4th March 2013, 15:38

Thats one of the main reasons i demux with eac3to, which notifies me if a stream contains forced lines, and also lets me look into the demuxed PGS streams with BDSup2Sub to identify the other streams, and make a decision which streams i want.
There isn't really a good automated way to solve all the troubles of BD forced subs.

The only think mkvmerge potentially could do is allow splitting forced lines into another track, like most of the other tools support, but imho its not something i would use, because it only solves a small part of the problem.

Bigmango

4th March 2013, 18:36

Where is that piece of information stored?

Thanks to sneaker_ger we now have the answer: the forced lines are marked as forced within the subtitle track.

The only think mkvmerge potentially could do is allow splitting forced lines into another track, like most of the other tools support, but imho its not something i would use, because it only solves a small part of the problem.

This would be great. It solves everything.

If a track contains forced lines and normal lines:

Move the foced lines to a separate track and mark it as forced
Move the normal lines to another track an mark it as unforced.

This would also solve the problem of the 2 different kinds of tracks (the tracks that support both forced and normal lines in the same track, and the separate tracks that contain only forced lines). In both cases, the above procedure would work (i.ex: if a track contains only forced lines and no normal lines, then the track with the normal lines would not be created).

Mosu

4th March 2013, 18:40

Sorry, but that is not going to happen. Mkvmerge would have to know in advance whether or not a track contains forced entries in order to write the file headers correctly. That could only be achieved by implementing two-pass muxing, something that I will most certainly never do. Way too much effort.

sneaker_ger

4th March 2013, 23:02

This would also solve the problem of the 2 different kinds of tracks (the tracks that support both forced and normal lines in the same track, and the separate tracks that contain only forced lines). In both cases, the above procedure would work (i.ex: if a track contains only forced lines and no normal lines, then the track with the normal lines would not be created).

Putting aside that Mosu is not willing to implement this, it wouldn't even work 100%. The problem is that authoring houses that put the forced lines into a separate track usually do not mark those lines as forced. They just tell the player via the menus that it should play that track. Since the track only contains forced lines it's unnecessary to mark them in any way.

mandarinka

5th March 2013, 04:03

I followed http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows and downloaded the binary installer and portable version from downloadbestsoft.com.
Both files had invalid MD5 (I used RapidCRC to check), so the files have probably been tampered with, possibly maliciously. Testing the 7z with 7zip showed no errors. (Redownloading didn't help.)

Maybe this should be investigated, since there is a chance they bundle something into mkvtoolnix :(

P.S. I tried to get the file from your server to check, but I think I didn't fool it and it just redirected me to that accursed host too - the file was identical to teh one from downloadbestsoft.com.

Chetwood

5th March 2013, 07:47

MakeMKV, DVDfab, and other tools detect forced subtitles properly.
No, they don't. There are various threads on both forums dealing with the issue of forced subtitles not being detectd properly.

Thanks to sneaker_ger we now have the answer: the forced lines are marked as forced within the subtitle track.
There are (at least) three methods for forced subs:

a separate stream that only has forced subs
a separate stream that has only forced subs but is not flagged (subs are turned on by navigational commands in the bdmv files)
a regular stream that has several items which are flagged as forced.

Thus the entire stream has to be parsed to determine which items are forced and Mosu already said he's not implementing two-pass muxing.

The only think mkvmerge potentially could do is allow splitting forced lines into another track, like most of the other tools support, but imho its not something i would use, because it only solves a small part of the problem.
It doesn't solve it at all since the detection itself is the problem.

nevcairiel

5th March 2013, 07:56

It doesn't solve it at all since the detection itself is the problem.

It doesn't solve everything, but it could potentially do what MakeMKV does - that is, write two streams for every PGS input stream, one stream gets all PGS lines, and the other one only gets the forced lines. And if no forced line was present, remove the stream from the MKV header again. Not that i think mkvmerge should do this, because it only solves a very small part of the problem, so you still need to do everything else.

Its not a perfect solution, but it does allow splitting out lines marked as forced in one-pass muxing. For everything else, people should demux and inspect the streams before.

What might be nice is an option to *only* take the forced lines out of a PGS input stream, in case you know it contains forced lines, and want to skip the step to split them out manually.

Mosu

5th March 2013, 07:57

I followed http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows and downloaded the binary installer and portable version from downloadbestsoft.com.
Both files had invalid MD5 (I used RapidCRC to check)

The checksums I use are SHA1 and SHA512. Not MD5, not CRC. So please use tools that actually support those checksums and stop spreading unwarranted accusations to the hoster I use. Thanks.

I've just re-checked, just to make sure. Downloaded both files from two different internet connections. They do match the published SHA1 and SHA512 checksums perfectly. No, downloadbestsoft.com is not modifying the files in any way, shape or form.

Mosu

5th March 2013, 07:59

It doesn't solve everything, but it could potentially do what MakeMKV does - that is, write two streams for every PGS input stream, one stream gets all PGS lines, and the other one only gets the forced lines. And if no forced line was present, remove the stream from the MKV header again.

Not possible in every case. Think of splitting. I'd have to re-write all files that have already been output. And what if the user has already moved some of them?

It's nothing I will implement. Period. You can all stop discussing it, or at least move it out of the context of this thread. Thanks.

mandarinka

5th March 2013, 22:18

Sorry, when I was reading the page, I interpreted the SHA1 as MD5. I simply saw that there, God knows why.

smok3

7th March 2013, 10:43

The automagic Bluray playlist selector is working great, thanks!

Reino

10th March 2013, 13:40

Hi there,

I've got about 300 ts-files, each 8 seconds long, that form a 40min documentary. In MKVToolNix I can easily use the append-feature to glue them all together into 1 mkv-file, but I'm facing a minor problem.
MKVToolNix detects the ts-file's video stream (h.264) as ID 1 and its audio stream (aac) as ID 0, which should be the other way around.
It wouldn't be such a fuss if it were only 10 files or so, but it's extremely cumbersome to move 600 streams (1 at a time!) up and down in the "Tracks, chapters and tags"-section to line them up correctly.

With...
ffmpeg.exe -i input.mkv -map 0:1 -map 0:0 -c copy output.mkv...I've found a way to correct this afterwards, but isn't there a way that mkvpropedit can do this for me? Or perhaps an extra option in MKVToolNix to switch the streams upon loading? Or another option of course... being able to move multiple streams up and down at once. That would help a lot too!

Mosu

10th March 2013, 13:56

You can also do that second step with mkvmerge. Load the muxed file again, then you only have one track to move.

On the command line: look at the --track-order option.

No, you won't get that "move multiple tracks at once" from me. Patches are welcome, though.

iSunrise

10th March 2013, 18:36

@Mosu:
Thanks for your great tools, appreciate the continued development on it!

Can you please explain how your new "split before chapters" works? Do you actually cut the files right before the chaptermarks irregardless of a keyframe or does that that take into account keyframes?

I am asking, because I end up with corrupted/invalid files after using that option.

Steps to reproduce:
I am using mkvmergeGUI 6.1.0 and I do a "split before chapters" and using "all" to split everything. While the original full-length MKV plays without problems whatsoever on all my devices and my PC, after the split I end up with several files that when played back, just show a black screen on all of my mobile devices (Android, Apple, etc.). Not even AirVideo (which does transcoding on-the-fly) can play it, says it´s an invalid file.

Right after starting playback I can only hear the audio track, but no video, all I get is a black screen, but the timecode still advances to the end of the file, so the audio is perfectly ok. I even tried to remux the contents (video and audio) to MP4/M4V containers, but it doesn´t help, the h.264 video track seems to be the problem.

For some reason LAV plays the files without any problems. But that doesn´t mean much, because LAV certainly is more "friendly" towards files in general.

Can you explain that? I can upload a sample if needed. Thanks a lot for looking into it.

Mosu

10th March 2013, 18:47

iSunrise

10th March 2013, 19:05

mkvmerge always splits right before key frames. With the "split by chapters" option all it does is take the start timecodes of selected chapters as they were entered in "split by timecodes" mode.

If you've got playback problems then that is your player's problem, not mkvmerge's. mkvmerge writes files that comply with the Matroska specs. That your LAV-based player can play the file just fine is only further proof of that. That's all that counts for me.

See these general troubleshooting information (https://trac.bunkus.org/wiki/Troubleshooting) for help on what you can try. And please, PLEASE, carefully read everything on that page and the ones linked from it. There's a ton of information and a ton of things you can try.
So, going by the info on that page the only thing I can do to avoid that is to use mkvmerge 5.8.0? Why does it behave different in that regard? I obviously would lose splitting by chapters then.

Not to doubt you or anything, but are you 100% sure that mkvmerge works 100% like it is supposed to work like you describe?

I find it very alarming that not even AirVideo that uses libav (avconv) in transcoding mode isn´t able to play the files.

Mosu

10th March 2013, 19:07

You obviously haven't read that page and the ones it links to carefully.

Yes, I'm sure mkvmerge works as I want it to.

iSunrise

10th March 2013, 19:14

You obviously haven't read that page and the ones it links to carefully.

Yes, I'm sure mkvmerge works as I want it to.
I obviously did.

Playback does not work at all or seeking does not work with files created by mkvmerge 5.9.0
The problem

Two symptons:

A player (mostly hardware devices like DVD or BluRay players) cannot play back a file muxed with mkvmerge 5.9.0 and later.
VLC cannot seek properly (or not at all) anymore with files created by mkvmerge 5.9.0 and later.

In both cases muxing with 5.8.0 fixes the issue.

Which is exactly my question. Does 5.8.0 fix my issue?

The only other thing that is mentioned on that page is a FAQ which points to some options to prevent player problems. How should I know what options to use?

Mosu

10th March 2013, 19:19

1. How would I know? I don't have your players with your problems, so how on earth should I know? I suspect it may.
2. No, obviously you didn't.

Quoting you:

So, going by the info on that page the only thing I can do to avoid that is to use mkvmerge 5.8.0?

Quoting my article:

Workaround with mkvmerge until player is fixed

You can prevent mkvmerge from writing these elements in the first place. This will make the file layout identical to the one written by 5.8.0. See the corresponding FAQ entry.

So please just try it. If it doesn't work then try the options listed on the general "what to do with incompatible players" page (https://trac.bunkus.org/wiki/FAQ%3AImprovingPlaybackCompatibilityWithPlayers).

Chumbo

10th March 2013, 19:33

iSunrise

10th March 2013, 19:45

@iSunrise,
After 5.7.0, I had to remux my MKVs using "--engage no_cue_duration --engage no_cue_relative_position" command line options to make sure my player's seeking and time are correctly "seen" and processed. You can set these as a default under Muxing | Add command line options. You can then check "Save as default..." to always mux with these options.
Thanks a lot Chumbo. I am currently in the process of splitting them again, as these options also seem the most likely to me.

Will report back after I´ve tested them and the other options.

Simon88

10th March 2013, 21:25

I was muxing some videos using mkvtoolnix 6.1.0 the other day and it found various errors at various XXXXXX position.... Resyncing at position 1, etc....

I'm wondering if there was a way for mkvtoonix to tell me where approximately (in minutes:second) in the video is that particular XXXXX position located.... so that I can simply cut the offending portion using an editor.... thanx...

Mosu

10th March 2013, 21:33

So far: no. But I may add that information in the near future.

Chumbo

11th March 2013, 03:33

I was muxing some videos using mkvtoolnix 6.1.0 the other day and it found various errors at various XXXXXX position.... Resyncing at position 1, etc....

So far: no. But I may add that information in the near future.
That would be greatly appreciated as I ran into a couple files with the same issue just yesterday.

Simon88

11th March 2013, 03:49

So far: no. But I may add that information in the near future.

Good to hear your considering such an addition....

I also noticed that these errors can cause hardware & software players to lockup, or audio to go silent from there onward. Cutting the offending portion virtually always fixes it.

It would be nice if you also show two values, BOTH the start location where errors are occurring and the location where it becomes OK.

That way, I can skip the editor and just use MKVToolNix to re-mux without bad areas....:)

Thanks....

hello_hello

12th March 2013, 03:52

Is there an option I'm simply missing, which can tell MKVMergeGUI to default to a specific language when adding additional streams to a muxing job?
I'm aware of the setting which places preferred languages at the top of the list, which is very handy, but not one which tells MKVMerge to actually select a particular language by default. If there's not such an option, would it be hard to implement?

Thanks.

Mosu

12th March 2013, 08:39

Wouldn't be hard. But it would pose more problems that it would solve. Therefore I won't implement it.

Here are a couple of examples:

What about files with multiple audio tracks? Do all of them get assigned the default language? Only one of them (if so: which one)?
What about files with both audio and subtitle tracks? Often users have audio in one language, subtitles in a different one.
There's reliable information (e.g. if the language is set on the container level like in MKV, MP4 or CLPI files for Blu-rays). If a default language applied it would be impossible for the user to distinguish between such reliable information and the unreliable information from the defaults. I can guarantee you that you'll forget to change the language for tracks whose actual language differs from the default one.
mkvmerge/mmg is careful not to change the file's semantics by keeping as much (meta) information from the source files as possible. With such a default language those semantics would often be changed in a way that would be pretty intransparent to the user.

etc.

hello_hello

12th March 2013, 10:20

I understand what you're saying, so I guess I'm looking at it from the perspective of an English speaker who usually only works with English streams.

What about a keyboard shortcut to change the language from "undefined" to the specified default etc? Or next to the drop down arrow where you now select the desired language, there could be a little "default" button. You could even have a little default button next to the Default and Forced track flag options. Although to be honest, I think doing away with the drop down menu and having three buttons for the latter two ("default", "yes" and "no") would be a better idea. You could highlight one to show which option is the currently selected one (or show it in a similar manner) and then it'd only take a single mouse click to change the setting for each. Even the language selection could have a few "common language" buttons which could be user defined, and there'd still be plenty of room from a drop down menu if you needed to select something else.

I know in the overall scheme of things it's nothing major, but I do mux quite a lot of files, and sometimes I open one with MKVMergeGUI and a little piece of my soul dies as I change the three dropdown boxes for each stream being added to the output again..... so I was thinking today if maybe there'd be an easier way, or a way to automate it a little.

Anyway.... that's just some thoughts. Everyone else might think it's a waste of time, but thanks for your continued work on MKVToolnix. It's much appreciated. I couldn't imagine life without it!

Mosu

12th March 2013, 10:27

Or next to the drop down arrow where you now select the desired language, there could be a little "default" button.

Why don't you just put "English" at the top of your preferred languages list? That way you can select it almost as easily as with such a button.

Basically you want me to spend a couple of hours on implementation and testing in order to save you a few seconds. Sorry but that's not how I usually work.

If you truly want to automate stuff then I highly suggest you learn a bit about programming. Everything you want to do can be achieved quite easily with a few lines of scripting (e.g. in Perl): parse the output of "mkvmerge --identify-verbose source.ext", assign a few command line options, run the muxing process. You can do anything you want with that approach. Sure, you have to spend some time on it, but here's my stance on bringing automation to mmg: Batch muxing with mmg? (https://trac.bunkus.org/wiki/FAQ%3ABatchMuxingWithMMG) The gist is this quote:

Implementing a powerful and flexible batch remuxer/header editor requires countless hours of work. If I cut down on the hours then either the flexibility or the number of features would be severely reduced and therefore the work would not be worth it because too few people could actually use it in such a state.

hello_hello

12th March 2013, 17:40

Why don't you just put "English" at the top of your preferred languages list? That way you can select it almost as easily as with such a button.

English is at the top of my language list.

Basically you want me to spend a couple of hours on implementation and testing in order to save you a few seconds. Sorry but that's not how I usually work.

Well based on the assumption I'll only ever use MKVMergeGUI once, yes..... but those couple of seconds each time have probably added up to a minute or two already today.... give me another couple of weeks and your couple of hours work would have saved me a couple of hours worth a clicking. ;)

Anyway, it was just a thought.... thanks again.

zeropc

13th March 2013, 17:44

does anyone know why on some mkv files skipping takes very long until playback resumes?
i've seen this behavior on various players, e.g. mpc-hc, vlc, mplayerx.

can i fix this and is there something i need to know to prevent in on future mkv file-creations?

thanks :)

Mosu

13th March 2013, 17:48

Read the fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590) I've written for this and that has been linked to about twenty times now in this very thread.

zeropc

13th March 2013, 18:03

thanks mosu :)

R=G

13th March 2013, 20:57

Can I use this to correct an audio stream of an out of synch MP4 file? Is there a tutorial on how to demux a MP4 file with an out of synch audio file?

DragonQ

16th March 2013, 13:15

If it's out of sync by a constant amount then you can just adjust the offset of the audio track when muxing to MKV. If the sync changes throughout then the frame rate might be wrong, which can also be corrected in MKV Merge.

nautilus7

16th March 2013, 19:20

Mosu, when loading a bluray playlist file into mkvmerge, the chapters it creates are ALL named "Chapter 0". I guess the correct would be "Chapter 1", "Chapter 2", etc.

Simon88

18th March 2013, 18:38

Is there a way to enter a PAR (pixel aspect ratio) value in mkvmerge? or to have it auto calculate an aspect ratio or display resolution from such a value?

It would makes life alot easier as mp4box seems to use PAR values exclusively...

thanx:)

sneaker_ger

18th March 2013, 19:04

Simon88

18th March 2013, 19:30

See mkvmerge doc for "--aspect-ratio-factor", but I would always recommend to already define a PAR when encoding the video to the bitstream (in case of x264 it's --SAR X:Y) - mkvmerge will then automatically read and apply that without any manual interventions.

Is there a way to strip the bitstream aspect ratio that was encoded by x264 before encoding using mkvmerge?

The "--engage remove_bitstream_ar_info" doesn't seem to work the last time I used it....

thanx...

sneaker_ger

18th March 2013, 19:43

I think it only works on H.264 ES, but why would you want to remove it?

SeeMoreDigital

18th March 2013, 19:51

Is there a way to strip the bitstream aspect ratio that was encoded by x264 before encoding using mkvmerge?

The "--engage remove_bitstream_ar_info" doesn't seem to work the last time I used it....

thanx...Hmmm...

That should work. There was a time when MKVmerge would strip the bit-stream aspect ratio signalling by default :scared:

Simon88

18th March 2013, 21:13

I think it only works on H.264 ES, but why would you want to remove it?

Sometimes the bitstream AR is incorrect and a PAR correction must be applied to straighten it for correct display.

This sometimes confuses the media player... of whether to use the container AR or the bitstream AR... though, most players use container AR, nowdays...

Simon88

18th March 2013, 21:17

Hmmm...

That should work. There was a time when MKVmerge would strip the bit-stream aspect ratio signalling by default :scared:

Were you able to get it working on the latest mkvmerge releases? Perhaps my h.264 files are just not compatible for AR stripping..:(

sneaker_ger

18th March 2013, 21:29

How did you verify the stripping did not work?

Some tools (like this one (http://forum.doom9.org/showthread.php?t=152419)) allow SAR changing after encoding, though results may vary.

Simon88

19th March 2013, 01:13

How did you verify the stripping did not work?

Some tools (like this one (http://forum.doom9.org/showthread.php?t=152419)) allow SAR changing after encoding, though results may vary.

I use MediaInfo and it shows TWO values, one "Display aspect ratio" and the other one "Original display aspect ratio"......

Shapierian

19th March 2013, 04:24

Fullmetal Encoder

19th March 2013, 16:31

Mosu,

Thanks a lot for the Blu-ray mpls and chapter functionality! This is tremendously powerful for me since it gives me direct access to Blu-ray extras and chapters which I've never had before.

I also wanted to ask about how time codes are determined for chapter start times when appending files.

If I mux, say, 5 VOBs to 5 separate MKVs and save an empty chapter to each output file with a chapter time of 0 and then append them all together again in the GUI, a single chapter file is attached to the output with adjusted time codes. Obviously this is being calculated from the play time or duration of each video segment being appended but exactly how does mkvmerge GUI get that information and how is the calculation being done? The result in the output file is perfectly precise.

I have searched the forums and looked through the source code but haven't been able to discover it.

sneaker_ger

19th March 2013, 17:31

I use MediaInfo and it shows TWO values, one "Display aspect ratio" and the other one "Original display aspect ratio"......

This does not necessarily mean it is still present. You should see from the value of "Original display aspect ratio" whether that is just coded width / height or the original SAR coded into the bitstream.

Kurtnoise

21st March 2013, 18:28

Hi Mosu,

Subtitles text tracks from mp4 don't seem to be parsed anymore with the current mkvtoolnix package...Here is a sample file (http://kurtnoise.free.fr/samples/Sopranos.mp4) (h264 + aac + tx3g + chapters) to debug.

Overdrive80

24th March 2013, 22:09

Hi Mosu, could be possible a minor implement feature as insert button "up" & "down" in attachment tab?? For example, for creating cover arts (http://matroska.org/technical/cover_art/index.html) is necessary put image files at the top of the attached. Maybe as that:

http://s6.postimg.org/x0idr6wht/Sin_t_tulo_2.png (http://postimage.org/)

hubblec4

1st April 2013, 03:20

Bigmango

3rd April 2013, 00:10

header removal compression has been turned off by default in both mkvmerge and mmg.

How can I enable header removal compression now?

You say the option was turned off.... but I can't seem to find any way to enable it. Is this option now gone?

Is there a way to mux all my files with header removal compression with version 6+, or should I go back to using version 5.8?

Chumbo

3rd April 2013, 02:01

How can I enable header removal compression now?

You say the option was turned off.... but I can't seem to find any way to enable it. Is this option now gone?

Is there a way to mux all my files with header removal compression with version 6+, or should I go back to using version 5.8?
You may be referring to the Compression option on the Extra Options tab.

Bigmango

3rd April 2013, 04:01

You may be referring to the Compression option on the Extra Options tab.

Header removal compression is not in the compression options in the extra options tab in version 6.1...

I may be blind, but the option seems to be gone? :confused:

Furthermore, how can I make mkvmerge behave like prior to version 6 (enabling Header removal compression by default) ? (the option you are referring to is not there anymore in the extra options tab, but even if it was, I would have to select it manually for each ID in each file.... this is too complicated, I want it to be applied by default as it was prior to version 6).

Chetwood

3rd April 2013, 06:16

And why is that? To save a few MB on a GB file?

Mosu

3rd April 2013, 07:46

Mosu, when loading a bluray playlist file into mkvmerge, the chapters it creates are ALL named "Chapter 0". I guess the correct would be "Chapter 1", "Chapter 2", etc.

Please file a bug report (https://trac.bunkus.org/) for this. I'm incredibly busy at the moment and will most likely forget about it otherwise. Thanks.

Mosu

3rd April 2013, 07:49

I'm wondering if there was a way for mkvtoonix to tell me where approximately (in minutes:second) in the video is that particular XXXXX position located.... so that I can simply cut the offending portion using an editor.... thanx...

In case I haven't mentioned it yet: I've added that information (both the last timecode correctly read before such a resync and the first one afterwards) to mkvmerge's output. The latest pre-build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) should contain said code.

Mosu

3rd April 2013, 07:50

Is there a way to strip the bitstream aspect ratio that was encoded by x264 before encoding using mkvmerge?

The "--engage remove_bitstream_ar_info" doesn't seem to work the last time I used it....

Edit: that should work. How do you know it didn't work?

Mosu

3rd April 2013, 07:54

I've noticed that since MKVToolNix 6.0, output no longer seems to playback with the Android 4.2 JellyBean stagefright framework. (e.g. Android Gallery). This seems close to the switch to matroska v4 and libmatroska 1.4.0, but that switch happened with MKVToolNix 5.9, which works fine with Android 4.2. Does anyone have any insights on this? Is it possible to turn off the Matroska v4 features to see if that helps with compatibility?

Why don't you read this fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590) that I've written specifically for this issue and that has been linked about 21 times now in this thread? And please read it carefully and completely as it mentions several solutions.

Mosu

3rd April 2013, 07:56

I also wanted to ask about how time codes are determined for chapter start times when appending files.

When you append two files (let's call them A and B) and B contains chapters then all of their timecodes are adjusted by the total duration of A. The total duration of A is the difference between the highest timecode+duration for a block minus the lowest timecode of any block in the file.

Mosu

3rd April 2013, 07:57

Subtitles text tracks from mp4 don't seem to be parsed anymore with the current mkvtoolnix package...Here is a sample file (http://kurtnoise.free.fr/samples/Sopranos.mp4) (h264 + aac + tx3g + chapters) to debug.

mkvmerge has never supported tx3g subtitles. I have taken a look at that specification in the past and decided not to spend any time on it any time soon either.

Mosu

3rd April 2013, 07:58

Hi Mosu, could be possible a minor implement feature as insert button "up" & "down" in attachment tab?? For example, for creating cover arts (http://matroska.org/technical/cover_art/index.html) is necessary put image files at the top of the attached.

No, sorry, because I refuse to implement workarounds in my software for idiotic implementations of other software. I'm not Mr. Fix-Other-People's-Mistakes.

To elaborate on this. Attachments are supposed to be identified by two different pieces of information:

A unique ID (called "file UID" in mkvinfo's output). mkvmerge automatically assigns that ID when attaching files and keeps it when remuxing them. This could be used from inside the file in order to refer to an attachment unambiguously. Currently that is not really used.
The attachment file name. This is supposed to be used by external applications if they need a specific feature, especially things like front/back covers.

The position inside the attachment list does not factor into it one tiny bit.

Mosu

3rd April 2013, 08:01

How can I enable header removal compression now?

It's more or less gone now (not really gone, but you cannot enable it at the moment). That was a time/effort tradeoff I made when I reversed the decision to enable it by default. If enough people actually want to use that feature then I'll spend the time necessary to make it selectable from the command line (and from mmg) again, but so far you're the only one asking for it.

I also suspect that you're confusing what you want to do. The default prior to v6 was to have header removal compression enabled. The option present in mmg was to disable header removal compression again because having it enabled caused a lot of devices a lot of pain. So if you want your files to be as compatible as possible with regard to this feature v6 and newer already do what you want to achieve.

Simon88

3rd April 2013, 15:47

Edit: that should work. How do you know it didn't work?

I use MediaInfo and it shows TWO values, one "Display aspect ratio" and the other one "Original display aspect ratio"......

as "sneaker_ger" pointed out - "This does not necessarily mean it is still present. You should see from the value of "Original display aspect ratio" whether that is just coded width / height or the original SAR coded into the bitstream."

However, I often use MediaInfo, BOTH the GUI version for a quick check and the CLI version for batch processing. I usually go by the container AR, but in the past my batch scripts were getting confused when there were two values.

Even some STB MediaPlayers gets "confused" and use the "Original display aspect ratio" rather than the container AR, requiring manually adjusting the AR using the remote during playback?

Can you make it so that "--engage remove_bitstream_ar_info" will ALSO remove the "Original display aspect ratio" info/value more completely so that programs like MediaInfo cannot detect it or make the value mirror that of the "Display aspect ratio"?

Mosu

3rd April 2013, 15:53

Simon88

3rd April 2013, 18:29

That is exactly what the option is supposed to do in the first place. You should ask the MediaInfo author whether or not that piece of information is always reported for AVC/h.264 -- even if the ar_info_present flag in the SPS is not present.

One thing you can do is let mkvmerge output some debugging information:

mkvmerge --redirect-output output.txt --debug avc_sps -o dummy.mkv your_file_that_was_created_with_remove_bitstream_ar_info.mkv

Then paste the resulting messages e.g. on pastebin.com or upload the output.txt somewhere.

What this is doing is simply remuxing the file you've created with "--engage remove_bitstream_ar_info" while dumping the parsed AVC SPS structures mkvmerge handles.

I couldn't find a file w/ bad AR. So, I issued the following two commands on a known good video file that is 960x540p (which has a 1:1 PAR / 16:9)... I want to make it 4:3, so I issued the following two commands:

"mkvmerge.exe" -o "your_file_that_was_created_with_remove_bitstream_ar_info.mkv" "--default-track" "0:yes" "--forced-track" "0:no" "--aspect-ratio" "0:4/3" "--default-track" "1:yes" "--forced-track" "1:no" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "dummy.mkv" ")" "--track-order" "0:0,0:1" "--engage" "remove_bitstream_ar_info"

"mkvmerge.exe" --redirect-output output.txt --debug avc_sps -o dummy.mkv your_file_that_was_created_with_remove_bitstream_ar_info.mkv

The output of "output.txt" is:
mkvmerge v6.1.0 ('Old Devil') built on Mar 2 2013 14:32:37
'your_file_that_was_created_with_remove_bitstream_ar_info.mkv': Using the demultiplexer for the format 'Matroska'.
'your_file_that_was_created_with_remove_bitstream_ar_info.mkv' track 0: Using the output module for the format 'AVC/h.264'.
'your_file_that_was_created_with_remove_bitstream_ar_info.mkv' track 1: Using the output module for the format 'AC3'.
The file 'dummy.mkv' has been opened for writing.
Progress: 0%
Progress: 8%
Progress: 26%
Progress: 44%
Progress: 59%
Progress: 71%
Progress: 91%
Progress: 100%

The cue entries (the index) are being written...
Muxing took 3 seconds.

MediaInfo shows:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 40mn 53s
Bit rate : 1 068 Kbps
Width : 960 pixels
Height : 540 pixels
Display aspect ratio : 4:3
Original display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.082
Stream size : 306 MiB (87%)
Writing library : x264 core 114 r1924 08d04a4
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1068 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
In the resulting file, MediaInfo still shows the "Original display aspect ratio".... It appears MediaInfo gets he value from the track header.... I searched the web and found this info:

http://sourceforge.net/p/mediainfo/discussion/297610/thread/5c5de6d2

Can you also reset or mirror (w/ the container AR) the video track header info associated w/ the AR when the "--engage remove_bitstream_ar_info is used?

thanx...

Mosu

3rd April 2013, 18:38

Simon88

3rd April 2013, 19:44

sneaker_ger

3rd April 2013, 21:21

Ah I know what's happening. In case of remuxing from Matroska to Matroska the code path that actually adjusts or removes the AR info (depending on whether or not "--engage remove_bitstream_ar_info" is in effect) is never called. The same is true when remuxing from MP4 to Matroska. In all other cases (from raw h.264, from MPEG-PS or TS, from AVIs...) it is called.

I might get around to changing that some day. But don't ask me for an ETA.

Yes, I think we already talked about that in this thread some months/years ago.

Anyway, MediaInfo might still display "Original Display Aspect Ratio" even if the bitstream info has been completely removed by mkvmerge, so that's nothing that can be further improved from the mkvmerge side (aside from it also working with non-ES input). MediaInfo showing that info does not necessarily mean the info is still present.

Btw, I think the mkvmerge doc on compression might need some update.

nautilus7

3rd April 2013, 23:55

Please file a bug report (https://trac.bunkus.org/) for this. I'm incredibly busy at the moment and will most likely forget about it otherwise. Thanks.

Done!

Fullmetal Encoder

4th April 2013, 02:22

When you append two files (let's call them A and B) and B contains chapters then all of their timecodes are adjusted by the total duration of A. The total duration of A is the difference between the highest timecode+duration for a block minus the lowest timecode of any block in the file.

You're obviously quite busy so thanks for responding.

With regards to the timecode and duration in the files being appended, where does that information come from? Was it read from the VOBs by the MPEG program stream reader when the VOBs were muxed into MKVs? What elements are being pulled from the stream to get those infos? When muxing, are VOBs treated any differently in this regard than any other MPEG stream?

If I examine the fist VOB with MediaInfo it exactly reports the same duration given by mkvmerge GUI to the first chapter when it's muxed and appended with the second MKV. However, if I use MediaInfo to get the duration of each VOB separately and then add those durations I get a number that's different from that of the single appended MKV. From the testing I've done, what mkvmerge is doing is perfectly correct vis a vis the chapter seek points and file segment durations. This is why it seemed that mkvmerge was doing something different than just adding the separate file durations.

I am asking about this because a while back I'd expressed interest in mkvmerge being able to "see" the "chapters" in DVD files like it can currently with Blu-ray mpls. I believe I can code a solution for this. Other tools like MakeMKV are not placing the chapter points correctly and if I'm going to try to solve this I want to do it properly.

Mosu

4th April 2013, 08:00

With regards to the timecode and duration in the files being appended, where does that information come from? Was it read from the VOBs by the MPEG program stream reader when the VOBs were muxed into MKVs?

Not as such. The timecode adjustment code (which also applies to the timecodes of appended tracks, not just of appended chapters) is located in mkvmerge's output chain. It simply knows which blocks were read from the previous file and tracks the lowest timecode and highest timecode+duration, and that is independent of the source file format. So it's not some... header value or something like that read from a source file, it's really the maximum difference between the block timecodes in an input file.

However, if I use MediaInfo to get the duration of each VOB separately and then add those durations I get a number that's different from that of the single appended MKV.

I'm pretty sure that MediaInfo does not take care of a) frame reordering due to B frames and b) maybe not of frame durations. For example, if you have a (pretty short) MPEG-2 video sequence of the usual IPBB with timecodes 0, 120, 40, 80 then the duration of that short sequence would be 160 (lowest timecode is obviously 0; duration of each is 40, so highest timecode+duration would be 120+40; 120+40 - 0 = 160 total duration). I'm simply not sure how MediaInfo calculates the duration, but it might just use the 80 (as it's the very last frame), or it might even be more intelligent and add the frame's duration of 40 ending up with 120 -- which would still be wrong.

I also don't know how MediaInfo handles streams of different lengths. What if there's an audio track in addition to the video track and the audio track still has packets for timecode 150 with a duration of 32ms?

You should ask MediaInfo's author for further information if you really want to know the answers.

I am asking about this because a while back I'd expressed interest in mkvmerge being able to "see" the "chapters" in DVD files like it can currently with Blu-ray mpls. I believe I can code a solution for this. Other tools like MakeMKV are not placing the chapter points correctly and if I'm going to try to solve this I want to do it properly.

If I'm not mistaken then the chapter information is stored in one of the IFO files. So far mkvmerge doesn't have an IFO parser on board, though it would be nice to have one -- similar to how the MPEG transport stream reader is looking for CHPL files and parsing them in addition to the M2TS or MPLS files you've asked mkvmerge to process.

SeeMoreDigital

4th April 2013, 15:46

Hi Mosu,

I'm currently performing some tests with .dff and .dsf (DSD) (http://en.wikipedia.org/wiki/Direct_Stream_Digital) audio streams. Is there official Matroska container support for these types of files?

Mosu

4th April 2013, 15:47

Never heard of them, so: no.

Fullmetal Encoder

5th April 2013, 20:12

For example, if you have a (pretty short) MPEG-2 video sequence of the usual IPBB with timecodes 0, 120, 40, 80 then the duration of that short sequence would be 160 (lowest timecode is obviously 0; duration of each is 40, so highest timecode+duration would be 120+40; 120+40 - 0 = 160 total duration).

Ok, that's very interesting. So the duration is something that the code just calculates from seeing the difference between the timecodes. And the timecodes are pulled from the stream by the MPEG-PS reader? I'm interested in where in the MPEG data and code it's pulling this.

You should ask MediaInfo's author for further information if you really want to know the answers.

It's ok, it's no longer relevant. There were just two possibilities. Either there was some generally accepted method of getting the play length of an MPEG clip and mkvmerge (along with MediaInfo, Windows OS, etc.) was implementing that, in which case I wouldn't probably need to delve into the mkvmerge code, or mkvmerge is doing it's own thing entirely. The latter appears to be the case.

The big thing that mkvmerge does differently is that it's setting the chapter points by the actual video segment duration via the timecodes. I think aside from maybe some DVD authoring tools mkvmerge is the only program that does this. As far as I know, the video segment can only begin with an I-frame (without corruption). Mkvmerge has no knowledge of IFOs and there's nothing else to go by to tell it how to adjust chapter start times when appending so it looks directly at the real video duration (which would make sense anyway). So when our two hypothetical mkvs are appended the output file has chapter start times that land directly on the I-frames that were at the beginning of the individual segments. I think other tools that attempt to pull chapter "points" from DVDs are only looking at the IFOs.

If I'm not mistaken then the chapter information is stored in one of the IFO files.

Well, yes and no. When human beings think of chapters they think of them as 'parts of a show' they can jump to that are at certain time points in the playback of the video. The problem is that the DVD structures and files have no such concept of a chapter. The "chapters" in an IFO are really just tables of pointers to byte offsets within the VOBs. Of course, it's up to the user which of those video segments have enough meaning to be considered chapters in the file they want to mux to mkv. If a user wants to create chapters in some generic video file they have to manually decide where each chapter point should land. However, in a DVD all the chapter "points" are already chosen for us but to get them properly you have combine the information in the IFOs with the video frame data. I don't think there are any non-professional tools that do this, which doesn't surprise me. While the above method may be perfectly correct it's also a PITA to implement.

So far mkvmerge doesn't have an IFO parser on board, though it would be nice to have one --

Yes, I am almost completely finished with this as far as video title sets are concerned. Although I do have the idea to go beyond that. I still need to do a little more work to include the parts of title table pointers but mostly everything regarding the program chains and cell byte offsets is complete and that's the main meat of it.

I have also completed code for pulling subtitles from DVDs. It can scan through VOBs and pull together all of the sub-picture PES streams just as VobSub would for a .sub file as well as look into the IFO for a video title set to get the original DVD color palette and convert to RGB as VobSub would. As far as I can tell the subpic PES streams and the DVD palette infos should be all your vobsub packetizer needs from a DVD source. Most of the content of a VobSub .idx file is to allow the user to customize different attributes of the subtitles which is irrelevant to us since we're only concerned with extracting the subtitles as they are in the DVD source. Let me know if any other information may be needed.

Honestly though I have not been able to integrate any of this into the mkvtoolnix code as it's just too complex and over my head for me to do that at this point. Especially the memory management. What I am doing is creating stand alone programs that show that the code does what it's supposed to do. Would you be willing to check out the code when it's all finished to see how easily or how difficult it may be to integrate? I am trying to make everything as modular as I can and to keep it simple in case any redesigning needs to be done to make it more compatible/portable.

Atak_Snajpera

7th April 2013, 21:30

mosu any breakthrough regarding opus stream in matroska?

SeeMoreDigital

7th April 2013, 21:41

mosu any breakthrough regarding opus stream in matroska?Experimental support was added to MKVToolNix v6.0.0... It seems to work okay ;)

Mosu

8th April 2013, 09:29

Well, Opus is bitchy to implement properly. No, no major breakthrough so far. Read the recent discussion (http://article.gmane.org/gmane.comp.multimedia.matroska.devel/4617) for more details.

sneaker_ger

8th April 2013, 10:02

While we're at new formats: is H.265 support in the works?

Mosu

8th April 2013, 10:14

No, not really. I'd love to have support for it, obviously I'd be the one doing the implementation, but I don't have access to specs, nor do I have a lot of time on my hand right now. So unless someone else steps forward and provides some needed knowledge... For example, someone mentioned something about needing to distinguish between BLA/CRA, and I have no clue whatsoever what he referred to.

superhil

10th April 2013, 09:03

Dear Mosu,
I have 6.1 AAC file that I want to mux with the video.
When I add it (using mmg.exe v6.1.0) it doesn't appear in the menu.

But, if I downconvert it to 5.1 AAC, everything is fine

Do you know what's the problem?

------------------------
edit:
I just tried also with 7.1 AAC
I face the same problem

Mosu

10th April 2013, 09:07

No, I don't know what the problem is.

superhil

10th April 2013, 09:08

have you tried muxing 6.1/7.1 AAC audio?
I don't know whether it's bug or not

thank you for your fast reply

Mosu

10th April 2013, 09:18

I don't know how many channels my AAC files have. I only mux them, I don't listen to them.

superhil

10th April 2013, 09:24

may I give you sample file?
thank you :-)

Mosu

10th April 2013, 09:27

Sure, but I don't have much time at the moment. Don't expect an answer for a week or two (might be sooner, but I simply cannot plan ahead when I'll have time and motivation to work on MKVToolNix at the moment). Upload to my FTP server, please (see signature).

superhil

10th April 2013, 10:10

Mosu

10th April 2013, 12:27

The audio track in your file contains an invalid number of channels inside the AAC configuration data. To be more specific:

An MP4/M4A file with AAC contains an ESDS atom. That atom's content is usually 2 or 5 bytes long and tells the AAC decoder about the most important properties: the profile, the sampling frequency, the number of channels, the output sampling frequency in case of SBR/HE. In your case the ESDS contains 14 bytes (why so many? no clue, to be hones), but the first two are 0x11 0x80. The number of channels is stored in the second bytes in the lower seven bits, which is... 0. mkvmerge then discards the track because 0 channels would be invalid in Matroska.

However, the MP4 container itself does also contain a "number of channels" header element. That one is set correctly. I'll change mkvmerge to use the channel number indicated by MP4 for AAC in such a case.

ffmpeg compiled with debugging options agrees that the container value is fine but the ESDS data says "0 channels".

Not sure if this is solely an issue in mkvmerge. Meaning... I'd be interested to know why there are 14 bytes instead of 2 or 5. I'd also be interested to know if those extra 12 bytes are actually something official that does contain the channel number in some way.

nevcairiel

10th April 2013, 12:47

channel_config == 0 is valid in the aac header, it usually means that a GA ("General Audio") block and PCE (program configuration element) is following the data which contains the channel configuration.
If you have the AAC spec at hand, its tables 1.13 for the generic setup data, and tables 4.1 for the "General Audio" info (following the setup data), and 4.2 for the PCE

Mosu

10th April 2013, 12:53

Ah, that sheds some light on it, thanks. Looks like this blog post (http://spectralhole.blogspot.com/2010/08/aac-bistream-flaws-part-1-channel-model.html) explains the situation quite well.

Mosu

10th April 2013, 13:01

Hmm, is there ANY documentation about AOTSpecificConfig anywhere apart from ISO 14496-3 (which I don't have)?

Guest

10th April 2013, 13:54

@Mosu

Check your PM.

superhil

10th April 2013, 13:58

Honestly,,I don't understand about the detail.. :-D
But thank you very much for your explanation..

Finally, i decided to convert it to 5.1 audio, since my speaker is only 5.1.

superhil

10th April 2013, 14:03

Does it mean that the problem is with Nero AAC Encoder?
The original file is 7 channels (6.1) .wav audio and then i converted it to AAC (.m4a)

BTW, I have MediaInfo installed in my PC, it tells correctly about the total number of channels from that .m4a file.

Mosu

10th April 2013, 15:21

Does it mean that the problem is with Nero AAC Encoder?

Nope, it's mkvmerge's problem. "Channels = 0" is valid in such a situation and mkvmerge will have to be changed in order to support it.

easy...rider

12th April 2013, 10:09

Hello,

I would like to ask your help with timecodes. I would like to use multiple time delays on a audio track. Is it possible?
I read the MkvMerge documentations, but I found no solution. I think I need Format V3 but this is how far I get.

I need these delays threw the video:
-358 00:00.000 - 13:15.000
+54 13:15.000 - 1:18:53.390
-1048 1:18:53.390 - end

I need to use the stretch too, 25.000/23.976

I hope you can help me, and thank you in advance!

dungpt

14th April 2013, 16:32

mkvinfo can see the attachments just fine. However, mkvpropedit moves to the attachments to the end of the file, and that's why you don't see them in mkvinfo's output with default settings. Why? Easy. mkvinfo parses the file from front to back, so seeking involved whatsoever (that's its purpose). In order not to overwhelm the user with information mkvinfo stops when it finds the first cluster by default. If the attachments are located behind the cluster then mkvinfo will not print them by default.

Adding one or more "-v" (or "--verbose") will cause mkvinfo to parse the whole file. That way you'll see the attachments near the end.

There is no problem with mkvinfo!

When I attach a file less than about 1.6mb, it will be located in the begining. However if I add more file and the total size is more than 1.6mb, all attachements are moved to the end of file. It makes me difficult to find the data in attachment. Do you have any way to keep the first attachment always locating in the begining (of course file size is less than 1mb)?

Mosu

14th April 2013, 17:50

Nope, there isn't. And I don't really understand that "makes it hard to find them" business. From my point of view there are only two scenarios, and in both of them locating the attachments is easy if implemented properly:

1. The more difficult scenario: you're writing a Matroska parser. In that situation you have to implement reading all the meta seek elements (even the meta seek elements pointed to from other meta seek elements). But you have to do that anyway, because you want to find the cues, too, right? And they're always located at the end of the file. Track headers and chapters might be too, btw.

2. You're just querying some tool in order to find out whether or not a file contains attachments, e.g. in order to extract them or... well I don't know why. In this case mkvinfo is the wrong tool to use: use mkvmerge's identification mode ("mkvmerge --identify yourfile.mkv"). mkvmerge implements 1. properly and has therefore no problems at all finding attachments, no matter where they're actually located.

dungpt

15th April 2013, 17:15

Thank Mosu for fast reply. I am going to put some text file in mkv. It's very fast to search the text in some first kb and we do not care the structure of mkv file. As you mention the meta seek element can pointed to from other meta seek element so we can store attachments in 2 possition.
It's easy if we know which kind of file is located (header or footer). Moreover it's waste of storage if we do not store any thing in 1.6mb header.
If the attachment is located at the end, I have to read metaseek element and go to the end. If the file size is big, it would take a time.
Are there anyway to alway store 1 small file in header as attachment?

Mosu

15th April 2013, 17:41

mkvmerge does not (!) leave 1.x MB of space at the start of the file. It simply doesn't. Neither is the header itself ever that big. mkvmerge always puts attachments at the beginning, right behind the track headers. I've even documented mkvmerge's file layout (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.file_layout).

mkvpropedit, on the other hand, puts attachments whereever it can fit them: by overwriting existing attachments (if it is asked to remove them), by overwriting "void" elements, and if all else fails, it puts them at the end. That is perfectly valid, and mkvpropedit tries really hard not to put them at the end -- but it may not have a choice in the matter.

I still don't see the point of having one program being able to force anything in this regard. You still have to account for all the other Matroska muxers out there. What exactly are you trying to do? You still seem to be parsing mkvinfo's output. Have you actually looked at mkvmerge's output for mkvmerge --identify-verbose that-file-with-attachments.mkv? If so, what is missing in that output for your purposes!?

superhil

17th April 2013, 11:27

https://trac.bunkus.org/ticket/872
thank you @Mosu.
It has been fixed ;-)

Mosu

17th April 2013, 12:53

Yeah. Forgot to mention that here, sorry.

Just FYI: the next release is not far off. I only want to fix one remaining issue (https://trac.bunkus.org/ticket/868), but even if I don't find the time to do that this week I might release on Sunday.

Edit: I meant Sunday next week, not this week, sorry. Sunday, April 28th.

easy...rider

18th April 2013, 13:08

Could someone help me with this?
http://forum.doom9.org/showpost.php?p=1623818&postcount=2152

Thank you!

LeMoi

18th April 2013, 17:17

You should split the video at these timings and append them again using the delay you want

easy...rider

18th April 2013, 22:05

Tank you.
I think I will search for a AC3 splitter without reencode. Splitting in MKV merge is not too precise. (as I experienced. I might be wrong about it)

LeMoi

18th April 2013, 22:20

Oh, that's just my point of view, maybe others will have other ideas ^^ splitting in MKV is bound to keyframes, maybe your delays apply at keyframes?

Sparktank

19th April 2013, 09:05

Story:
I took a 3D DCP trailer (unencrpypted), found a way to unwrap everything, encode the left-eye into a single video file (with audio) and encode the right-eye into a single video (without audio) and now need to put both together so I can sit back with my ridiculous anaglyph glasses and giggle like a child.
(first chapter of the story here (http://forum.doom9.org/showthread.php?p=1616435#post1616435))

2 separate video encodes (left+right) from a DCP trailer (.mxf container).
I want to store them inside a Mastroska container to be played back via Stereoscopic Player or other.
The two separate files were encoded as simply h264 (via ffmpeg;libx264). Both appear as monoscopic and can be viewed separately.
Right-eye image data not encoded as MVC; but as monoscopic (ie, same treatment as the left-eye image data).

Question:
How would I mux these two together in a Matroska container?
Is this an instance where leaving the stereo mode as empty be beneficial (to let the player intelligently decide playback)?
Since it wasn't encoded as MVC or anything else fancy, setting something like frame-packed, sbs, ou, etc would cause... ?

I played it back in Bino 3D player it seemed to have liked it.

I just want to make sure I'm muxing them correctly. Documentation said most cases are find with left blank.

sneaker_ger

19th April 2013, 16:14

Two separate tracks are to be combined by TrackOperation:
http://matroska.org/technical/specs/notes.html#TrackOperation
http://matroska.org/technical/specs/index.html#TrackCombinePlanes

But I'm not sure if it can already be done with mkvtoolnix. The other thing is that probably no player can read them yet. Most people just encode into a single H.264 or MVC track.

Mosu

19th April 2013, 16:27

Not yet, no. See bug 594 (https://trac.bunkus.org/ticket/594) (not that there's any information yet, but it's still on the list of features that should be implemented one of these days).

Sparktank

19th April 2013, 23:53

Interesting. That looks like a fun venture in the future when it picks up.
I imagine after it's implemented into Matroska, much longer for hardware player support.

In the meantime, I think I'll leave the stereo mode empty and let the players decide.
I don't have a 3DTV or PS3 so I can't test the undefined stereo mode in hardware playback.
Thanks for the info.

mindbomb

20th April 2013, 00:44

I know you get asked this a lot, but...
default track flag and forced track flag, with regard to subtitles in an mkv container-
Some people are using the default track flag like other use the forced track flag and vice versa.

I was under the impression that you use forced track flag for movies like Argo, where there are a handful of scenes in another language, but the majority of the movie is in english.
However, people have told me that they would use the default track flag in this case, and players like VLC seem to always play the default track flag.

who is doing it right?

Chetwood

20th April 2013, 06:04

I think VLC is doing it wrong, it should play the track also when only forced is set. You can read up on flags earlier in this thread (http://forum.doom9.org/showthread.php?p=1529805#post1529805).

Mosu

20th April 2013, 07:55

That mostly explains how mkvmerge decides (but is a good read in its own right, to be sure). I've also documented the meaning of those flags from the player's point of view (https://trac.bunkus.org/wiki/FAQ%3ADefaultAndForcedFlagsAndDefaultYesNoInMMG) (which is also the spec's point of view, of course).

mindbomb

20th April 2013, 13:36

dungpt

20th April 2013, 16:46

Thank Mosu very much. I only work with mkvpropedit. I will study mkvmerge and ask you later.

Mosu

20th April 2013, 17:24

I have read that faq, and I am still not completely clear on a few things.
You say "As a lot of users don't want subtitles shown by default they tell mkvmerge not to set the "default track" flag for any subtitle track."
But if that is true, I don't understand why the Lord of the Rings' english for Elvish track is an example of forced, if default would have made it show by default.

The "default" flag tells the player which track to show by default if the user has chosen to have tracks of this kind to be played by default. So if the user doesn't want subtitles by default then the player should not show a subtitle track even if it has the "default" flag set to "yes".

"Forced = yes" on the other hand means that the player must play this track even if another track of the same kind is shown as well.

So for subtitles that only contain translations of a few sentences (Elvish) you use "forced" because you always want that shown, even if you have other subtitles active as well. However, if the "other subtitles" all contain the translations as well then there's no need for "forced". So it all depends on the content, of course.

A lot of players handle "default" wrong and "forced" not at all, unfortunately.

sneaker_ger

20th April 2013, 17:26

Yes, I know nobody that uses the forced flag in the way it seems to be intended by the specs.

Mosu

20th April 2013, 17:26

Like I said: there's no way to tell mkvpropedit where to put stuff. mkvpropedit will always try hard to keep stuff at the front, but if it is not possible then it is not possible. Note that mkvpropedit will also not write multiple "attachments" master elements even if you do have multiple attachments (a strategy might be to keep one attachment at the front and write the others at the end, but mkvpropedit does not work that way and most likely never will).

LeMoi

20th April 2013, 17:49

"Forced = yes" on the other hand means that the player must play this track even if another track of the same kind is shown as well
Do you mean that the player should show, in this case, BOTH subtitles, an active one, chosen by the viewer, AND the one marked as forced, at the same time ?

Chetwood

21st April 2013, 06:00

The player definitely should show a forced sub even if it's set to show no subs by default.

Mosu

21st April 2013, 18:44

Do you mean that the player should show, in this case, BOTH subtitles, an active one, chosen by the viewer, AND the one marked as forced, at the same time ?

Yes, and the specification is pretty clear on that:

Set if that track MUST be active during playback. There can be many forced track for a kind (audio, video or subs), the player should select the one which language matches the user preference or the default + forced track. Overlay MAY happen between a forced and non-forced track of the same kind.

Mosu

21st April 2013, 18:53

The player definitely should show a forced sub even if it's set to show no subs by default.

That as well, yes.

mindbomb

21st April 2013, 21:09

so, in other words, from the muxer's perspective for subtitles, you basically never use the forced flag and rarely use the default flag.
Most of the time, there should be no flag, but when subtitles are necessary you use the default flag.

Mosu

21st April 2013, 21:44

That's mostly correct, though you could argue about the meaning of "necessary" in this context.

But again, it all depends on both the content and the intended audience. I know a lot of people that prefer to watch movies in the original language even if they don't speak it -- simply because they think a lot of the intended expression is lost in translation and synchronization. Those people usually turn on subtitles in their native language. Those people might always flag a subtitle track with "default".

Chetwood

23rd April 2013, 16:09

Mosu, care to chime in on this (http://forum.doom9.org/showthread.php?p=1625307#post1625307)?

cafevn

25th April 2013, 16:38

hi, do i need apply audio delay to append stream?

Mosu

28th April 2013, 13:35

I've released MKVToolNix 6.2.0. It's mostly a bug fix release with only small new features but one big enhancement: memory usage has been reduced severely. This is especially more noticeable the more video and subtitle tracks you're muxing, e.g. with Blu-ray discs.

For package maintainers: as libEBML 1.3.0 and libMatroska 1.4.0 have been released in March this release of MKVToolNix can be compiled with external versions of both libraries again. The source package still contains both libraries, but they're only used as fallbacks.

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.1.0:

2013-04-28 Moritz Bunkus <moritz@bunkus.org>
* Released v6.2.0.

2013-04-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The option "--engage remove_bitstream_ar_info" will now work on AVC/h.264 tracks read from Matroska/MP4 files as well. Fixes #868 (https://www.bunkus.org/trac/ticket/868).

2013-04-16 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: mmg will now handle all file names given on the command line instead of only the first one. This allows things like opening several selected files with mmg in Windows, and mmg will add all of them. Fixes #867 (https://www.bunkus.org/trac/ticket/867).
* mkvmerge: bug fix: The amount of memory required to store the cues during muxing has been reduced drastically. This is more noticeable the more video and subtitle tracks are muxed. Fixes #871 (https://www.bunkus.org/trac/ticket/871).

2013-04-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If splitting had been active then the elements "cue duration" and "cue relative position" were only written to the first output file.

2013-04-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The "CTS offset" field of FLV files with AVC/h.264 video tracks is now read as a signed-integer field in accordance with the FLV specifications.

2013-04-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: DTS parsing: no more warnings about incompatible encoder revision numbers will be printed. Fixes #866 (https://www.bunkus.org/trac/ticket/866).
* mkvextract: enhancement: track extraction mode: If mkvextract encounters a broken file structure it will output the last timecode successfully read before resyncing. After the resync the first cluster timecode will be reported as well.
* installer: The installation directory will no longer be added to the PATH environment variable.
* mkvmerge: bug fix: The parsing of the AAC AudioSpecificConfig structure (the bytes contained in Matroska's CodecPrivate and in MP4's "ESDS" atom) was fixed to support parsing the GASpecificConfig and the ProgramConfigElement if the channel configuration is 0. Fixes #872 (https://www.bunkus.org/trac/ticket/872).

2013-04-09 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Loading chapters from Matroska files will open the file in read-only mode allowing to read from write-protected files.

2013-04-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: All entries in chapters imported from MPLS playlists were named "Chapter 0". The numbering has been fixed. Fixes #870 (https://www.bunkus.org/trac/ticket/870).

2013-04-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Selecting the lowest process priority with "--priority lowest" will cause mkvmerge to also select an idle/background I/O priority. Implements #863 (https://www.bunkus.org/trac/ticket/863).

2013-03-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading AVI files with audio chunks of size 0. Fixes #843 (https://www.bunkus.org/trac/ticket/843).

2013-03-29 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Add control for new option "--fix-bitstream-timing-information".

2013-03-20 Giuseppe De Robertis <giuseppe.derobertis@ba.infn.it>
* mkvmerge: new feature: Add option for fixing the timing information in video track bitstreams (--fix-bitstream-timing-information).

2013-03-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Matroska reader: If mkvmerge encounters a broken file structure it will output the last timecode successfully read before resyncing. After the resync the first cluster timecode will be reported as well.

2013-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG program stream reader: tracks with invalid video properties (e.g. width or height = 0) are ignored properly.
* mkvmerge: bug fix: The progress percentage was sometimes using the wrong input file as the reference if multiple files are read with the "additional parts" mechanism (on the command line: the syntax "( VTS_01_1.VOB VTS_1_2.VOB VTS_1_3.VOB )".
* mkvmerge: bug fix: Fixed one situation that could lead to mkvmerge aborting with the error message "Re-rendering track headers: data_size != 0 not implemented yet".

2013-03-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: removal: Support for BZ2 (bzlib) and LZO (lzo1x) compression has been removed.
* mmg: bug fix: Using drag & drop to add playlists will no longer lock the dragging application (e.g. Windows Explorer) in D&D mode for the duration of the scan for other playlists.
* mmg: bug fix: The validation for the argument to "split by chapters" was wrongfully rejecting certain valid inputs (chapter number lists in which the second or any later chapter number was higher than 9).
* all: enhancement on Windows: all programs now determine the interface language to use from the user's selected interface language (C function "GetUserDefaultUILanguage()"), not from the locale setting. Implements #852 (https://www.bunkus.org/trac/ticket/852).

Have fun.

SeeMoreDigital

28th April 2013, 14:51

I've released MKVToolNix 6.1.0. It's mostly a bug fix release with only small new features but...
I think you mean MKVToolNix 6.2.0 ;)

Mosu

28th April 2013, 16:05

Meh... 'course I did.

sneaker_ger

28th April 2013, 22:22

--fix-bitstream-timing-information could come in handy, especially since that ffmpeg mod seems to be stalled. Does it also set fps mode to CFR when specifying a constant fps in mmg?

Mosu

28th April 2013, 22:28

If you're referring to the fixed_frame_rate flag in the VUI structure in the sequence parameter sets: yes, it does set that to 1 if this option is enabled.

sneaker_ger

28th April 2013, 22:46

Nice, thx.

Betsy25

2nd May 2013, 21:56

Feature Request:

Is it possible to have the window size being remembered for the "Status and Progress" window please ? The default size always has to linebreak over multiple lines by default with fairly simple filenamed items.

The reason why I would really like this to be a bit bigger is that WARNINGS (such as when there are errors in the source AVC are added in the "Output" list instead of the "Warning" list, and so they easily get overlooked, resulting in a broken output file.

Mosu

2nd May 2013, 21:57

Sure. Would you mind opening a ticket for that in my bug tracker (https://trac.bunkus.org)? I will likely forget about it otherwise.

Betsy25

2nd May 2013, 22:04

Sure. Would you mind opening a ticket for that in my bug tracker (https://trac.bunkus.org)? I will likely forget about it otherwise.

Thanks, Done. (https://trac.bunkus.org/ticket/878#ticket)

Fullmetal Encoder

5th May 2013, 15:26

Dear Mosu,

If/when you are interested/have time I would like to make available what code I have for parsing DVD IFOs and reading the subtitle PES packs from VOBs.

I apologize for not integrating everything into MKVToolNix code in a finished product but working by myself that would take a lot more time and I feel like it's taken way too long as it is. Plus, as for the IFO parsing part using that code would require building new capabilities into your GUI and I'm sure you have your own ideas about how to proceed there.

For the subtitle support the code I have for producing .sub data works on the assumption that it can access the bytes of a complete 2048 byte PES subpicture pack as a buffered array. I am uncertain as to how to proceed in integrating it into your code so I was hoping you could advise me about that upon seeing what I've done. Of particular interest to me is this chunk of your r_mpeg_ps.cpp:

...
if ((packet.m_id.sub_id & 0xe0) == 0x20)
// Subtitles, not supported yet.
return packet;
...

The method used by my PES code I don't think is compatible with yours but the meat of it is relatively simple and I can redesign it if needed.

The IFO code I have primarily makes available information about the cells and other structures of the DVD being examined as well as the original DVD color lookup table palette used by the subtitles. If it would be beneficial to MKVToolNix to know anything else about the DVD from the IFO files please let me know and I'd be happy to expand it's capabilities.

In my own usage/testing everything has been compiled with Visual C++ 2012 with Boost installed but as far as I can tell there isn't anything too platform specific about my code. Especially in the parts that actually do the work.

In the case that any of my code is useful to you I have released it all under GPL. I have placed everything in a 7-zip file of about 11k. What is the best way to get it to you? Can I just email it or would you prefer I try to use your FTP server?

Mosu

5th May 2013, 15:29

Thanks for the work. E-mail is just fine.

LeMoi

23rd May 2013, 23:33

I have 2 files, one video track, a 140 MB file, 24min, and one audio track, a 20 MB file, 30 min. That's an example, I don't exactly remember the proper sizes and durations. Anyway, I only want to mux them in one 24 min mkv file, which shoud be, for example, 140 + 15 = 155 MB instead of 140 + 20 = 160 MB.
To be sure to have the right duration, i choose the split option, I type "00:00:00.000-00:24:00.000" to split the file correctly, but when i mux the final MKV file is 160 MB instead of 155 !
Is this a bug, or am i doing it wrong ?

The solution I found is to first split the audio track, in one .mka file, using the split option ("00:00:00.000-00:24:00.000") to have a 15 MB file which duration is 24 min. Then I mux this .mka with the video track, and the final file is 155 MB. But that's one step more, I thought I would be able to do it with the first described method...

Mosu

24th May 2013, 08:14

That's not a bug, no. mkvmerge can only split right before a key frame. On top of that mkvmerge has to decide which track to use for that distinction. If the whole muxing process contains a video track than that video track is used, otherwise the first audio track. Your case contains a video track -- but you want to split after the video track ends. That will simply not work, sorry.

gonwk

24th May 2013, 22:04

Atak_Snajpera

24th May 2013, 22:37

mosu what is current progress regarding opus codec?

Chetwood

25th May 2013, 05:59

Q1: How is that Possible?
It's not.

Mosu

25th May 2013, 08:31

mosu what is current progress regarding opus codec?

Still an ongoing (and currently active) discussion. See the Matroska devel mailing list (http://lists.matroska.org/pipermail/matroska-devel/2013-May/004448.html).

Simon88

25th May 2013, 23:43

Hi Mosu,

Thanks for the GREAT Tool ... MKVToolnix.

I have a dumb Q or observation ... when I have an MKV file and I want to Add or Remove Subtitles from the MKV container ... eventhough I do NOT Change or Touch the Video or Audio ... the resultant New MKV file when I play it using VLC ... the Video look a bit different ... People's face look a Tad Chubbier ... eventhough the Aspect Ratio remains the same the new MKV file, the Video part just does not look the same. The difference is extremely minimal ... I have to really, really focus and zero on it ...

Q1: How is that Possible?

Q2: How to prevent this from happening?

Thanks,

G! :)
Use a different player/settings. Some video players re-size the screen by squishing the image by about 32-40 pixels and displaying the Subs below the video, try overlaying the Subs on-top of video and re-calculate the container aspect ratio. Also, resetting the preferences in latest VLC should fix this issue.

gonwk

26th May 2013, 03:07

Use a different player/settings. Some video players re-size the screen by squishing the image by about 32-40 pixels and displaying the Subs below the video, try overlaying the Subs on-top of video and re-calculate the container aspect ratio. Also, resetting the preferences in latest VLC should fix this issue.

Hi Simon88,

Thanks for taking the time and answering.

Simon, when I am comparing the 2 MKV files, I am not even enabling the playback of the Subtitles in VLC so it would not distract my viewing of the Video and comparing the pictures.

Simon, are you saying that if I use MPC-HC the pictures of the Original MKV vs my new re-muxed one might look identical!?!?

Appreciate the help again.

G!:)

gonwk

26th May 2013, 03:19

Hi Mosu,

I download and use your "Portable" version of MKVToolNix.

I don't believe the Tool is "really" Portable ... and why do I say this, because I have versions 5.8.0 and 6.2.0 on my laptop in their Separate folders and have made separate shortcuts to both of their mmg's BUT when I click on 6.2.0 MKVToolNix shortcut ... the program tells me that is pointing to the MKVMerge in my 5.8.0 folder.

Q1: If the program is in fact Portable and Self-contained in it's own folder ... how is it that it tells me there is another version floating on my PC?

Q2: How can I have 2 different versions of your program, portable ones, on my PC that I can switch back & forth on demand? Without going thru redirecting the Pathway each and every time?

Thanks,

G! :thanks:

Simon88

26th May 2013, 06:25

Hi Simon88,

Thanks for taking the time and answering.

Simon, when I am comparing the 2 MKV files, I am not even enabling the playback of the Subtitles in VLC so it would not distract my viewing of the Video and comparing the pictures.

Simon, are you saying that if I use MPC-HC the pictures of the Original MKV vs my new re-muxed one might look identical!?!?

Appreciate the help again.

G!:)
I'm assuming the Subs are SoftSubs and NOT hard coded. Using MKVToolNix v6.2.0, the Default track flag & Forced track flag should allow your video player to properly read the container settings properly of whether to display or not display Subs by default. Set a correction value for the MKV aspect value, taking to account the extra pixels used by borders/subtitles, etc. Use the following formula: SAR*PAR=DAR to set proper aspect ratio.

For new users playing MKVs, K-Lite Mega Pack is quite good... it is bundled w/ latest MPC-HC...

Simon88

26th May 2013, 06:45

Mosu

26th May 2013, 09:24

I don't believe the Tool is "really" Portable...

True, as they still store their settings in the registry. Patches to fix this are welcome, but I will most likely not spend time on this myself.

Q2: How can I have 2 different versions of your program, portable ones, on my PC that I can switch back & forth on demand? Without going thru redirecting the Pathway each and every time?

Remove all MKVToolNix settings from the registry and don't set the path to mkvmerge.exe yourself. That way mmg.exe will look for mkvmerge.exe in the same folder the currently running mmg.exe is located in.

gonwk

26th May 2013, 16:28

Hi Mosu & Simon88,

Appreciate your replies and feedback.

@ Mosu, Thanks for your GREAT Program.

Mosu, between Your suggestion Not to set the Path manually & Simon's suggestion to create the Shortcut within the portable folder ... the Solution worked like a Charm, problem Solved.

So, no need for Reg Clean Up, and since the program was never installed ... I don't know if something like "Revo Uninstaller" would work. Goooogling said may be CCleaner would do it ... but some recommended against messing with the Registry.

@ Simon88, dude YOU are Smarter than Average Bear ... your Solution worked like a Charm. Thanks my man!

Thanks again guys!

G! :thanks:

Keiyakusha

27th May 2013, 04:49

Hi Mosu. I want to clarify something...
Let's say I created mkv with 2 editions. 1st edition just plays the whole file. Second - replaces some part in the middle of the file with external segment. Splitter that supports ordered chapters/linked segments/editions plays it fine.
Now if I'll take these 2 mkv files and binary-append them, virtual timeline will work as before. Splitter without ordered chapters support just ignores appended segment.
Question: is this a right thing to do? If not, is there a proper way of creating multi-segment mkv? If I'll simply append streams within one mkv, splitter that does not supports ordered chapters will be outputting main file + additional segment. I want this extra segment to be ignored.

Mosu

27th May 2013, 17:38

I cannot really help you with such question as I've never played with ordered XYZ myself.

Keiyakusha

27th May 2013, 18:11

I cannot really help you with such question as I've never played with ordered XYZ myself.

Well, ok. How about this.
If I binary append 2 mkv files, resulting file is a valid file from a perspective of the mkv spec, or hack that only by chance works the way I want it to?

mediainfo seems to be aware of such thing. it displays something like
Format : Matroska / Matroska
Format version : Version 4 / Version 2 / Version 4 / Version 2

Mosu

27th May 2013, 18:13

More or less a hack because the EBML header is repeated in the middle. However, I'm not sure whether or not we really allow this intentionally. Sorry. You should ask on matroska-users, maybe Steve Lhomme has some more insight.

Keiyakusha

3rd June 2013, 00:27

Hi Mosu. I have another question about Chapter editor in mkvtoolnix.
It allows to create chapters without specifying end time, but isn't end time is mandatory? At least ordered chapters/linked segments don't work correctly without it...

Also lets say I have 2 chapters:
First [00:00.000; und]
Second [19:06.545; und] <- starts at I-frame, lets say... #61299
In this situation what time should I specify for end of the 1st chapter? is it also time of the frame #61299 (19:06.545)? Or it should be time of the frame #61298 (19:06.529)?
What abut end of the 2nd chapter? Should it be timecode of the last frame or last+1 frame?

sneaker_ger

3rd June 2013, 06:36

but isn't end time is mandatory?

It is not.

At least ordered chapters/linked segments don't work correctly without it...

Maybe since it may be ambiguous as you can leave out parts in ordered chapters? I don't know if this is a quirk of the splitters or something the spec demands, though.

Also lets say I have 2 chapters:
First [00:00.000; und]
Second [19:06.545; und] <- starts at I-frame, lets say... #61299
In this situation what time should I specify for end of the 1st chapter? is it also time of the frame #61299 (19:06.545)?

Yes.

What abut end of the 2nd chapter? Should it be timecode of the last frame or last+1 frame?

I guess so, but last frame + 1 timecode is a topic on its own concerning mkv. Maybe Mosu can say more.

Mosu

3rd June 2013, 07:15

Hi Mosu. I have another question about Chapter editor in mkvtoolnix.
It allows to create chapters without specifying end time, but isn't end time is mandatory?

No, in general it isn't. If there is no end time then the implicit end time is the start time of the next chapter on the same nesting layer. If the chapter in quesiton is the last one on that layer then the implicit end time is the end time of the layer above it (which could be more chapters or the segment iself).

Why ordered chapters don't work without an explicit end time I cannot say.

hubblec4

3rd June 2013, 17:14

Why ordered chapters don't work without an explicit end time I cannot say.

the explicit end time is necessary to generate the new virtual timeline exactly.

Selur

5th June 2013, 12:50

Got a problem remuxing a stream, first I extract the streams using:
mkvextract tracks "H:\Output\avc_1440x1080i.mkv" 1:"H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
and
mkvextract tracks "H:\Output\avc_1440x1080i.mkv" 0:"H:\Output\13_19_13_3010_40.264"
then I remux the stream using:
mkvmerge --ui-language en -o "H:\Output\test50i.mkv" -d 0 --default-track 0:yes --default-duration 0:5000000/100000i --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
since I was unsure wheter I should use 50i or 25i for muxing I also tried:
mkvmerge --ui-language en -o "H:\Output\test25i.mkv" -d 0 --default-track 0:yes --default-duration 0:5000000/100000i --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
Problem is: both remuxes are async.

-> Does anyone know where the problem is?
(Uploaded the the avc_1440x1080i, test50i, the test25i clip and the extracted raw files to: http://www.embedupload.com/?d=8UU3UQQYYN)

Is this me missing something obvious, me doing something wrong, a bug during playback or a bug in mkvmerge?

Mosu

5th June 2013, 13:47

You're demuxing from a container that has timecodes (Matroska) to two containers that don't (AC3 and raw h.264 elementary streams). That is bound to cause trouble. Don't. Just re-mux directly from Matroska to Matroska.

Selur

6th June 2013, 14:07

I assumed I would only need the time codes if they indicate vfr.
since:
mkvextract timecodes_v2 "H:\Output\avc_1440x1080i.mkv" 0:"H:\Output\timeCode_14_58_15_554.txt"
produces an output file which has a constant difference of 20 (<> matching 50fps), I assumed the time codes weren't necessary,...
(uploaded the time codes to: http://pastebin.com/DcgbsRyy)

Also extracting the time codes and adding them to the video stream, fixes the problem, question is:

Why do I need them? (shouldn't either '--default-duration 0:5000000/100000i' or '--default-duration 0:2500000/100000i' tell mkvmerge to create exactly the same time codes?

Cu Selur

Mosu

6th June 2013, 14:12

Maybe it's a bug, maybe not. Not sure, don't have time to investigate for the time being.

Selur

6th June 2013, 14:13

okay, no problem will test a bit more :)
-> using "--default-duration 0:2500000/100000p" fixes the issue, so seems like there's something wrong with the interpretation of the '--default-duration' values

Mosu

6th June 2013, 22:15

--default duration 0:25p and --default-duration 0:50i end up being the same internally. There's no distinction. The provided value (25) is multiplied by 2 if it's p and 1 if it's i, so in both cases the reciprocal comes out as 1s/50 = 20ms per field.

I'm pretty sure you changed something else, too.

Selur

7th June 2013, 12:48

I'm pretty sure I didn't,...

I checked:
1. downloaded and extracted http://www.embedupload.com/?d=8UU3UQQYYN (to make sure I really use the same files)
2. deleted test50i.mkv and test25i.mkv
3. called:
mkvmerge --ui-language en -o "H:\Output\test50i.mkv" -d 0 --default-track 0:yes --default-duration 0:5000000/100000i --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
then
mkvmerge --ui-language en -o "H:\Output\test25i.mkv" -d 0 --default-track 0:yes --default-duration 0:2500000/100000i --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
then
mkvmerge --ui-language en -o "H:\Output\test25p.mkv" -d 0 --default-track 0:yes --default-duration 0:2500000/100000p --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"

-> only the test25p file plays properly.
As a side note: notice that the content is not mbaff, but paff interlaced.

Cu Selur

Mosu

7th June 2013, 13:05

Your very first case has one 0 too few. 0:5000000/100000i = 0:5/1i = 5 fields per second? :)

Selur

7th June 2013, 13:08

Sorry (well spotted!), but still there is something wrong, since the last three calls are all fine and still the only file that plays properly is the 25p one.

Mosu

7th June 2013, 14:47

I don't know how paff interlacing differs from mbaff. But from what you're sayin it seems thon the frame /field flag.

at one Matroska block contains one full frame. In such a case a duration of 40ms per Matroska block is appropriate. Remember : you're setting the default duration for a single Matroska block. You're not setting a frame rate. Mkvmerge does not think in frames. It thinks in single blocks. The h264 code (as well as other similar places) calculate a block's duration by multiplying the default duration by either 1 or
2 dependingThat’s why the nomenclature "50i" or "25p" doesn't always make sense.

However, that's how mkvmerge works internally. Changing that to work on a frame basis amounts to rewriting the whole application. Not something I'm willing to consider.

Selur

7th June 2013, 14:51

Remember : you're setting the default duration for a single Matroska block. You're not setting a frame rate.
I always forget that. :)

However, that's how mkvmerge works internally. Changing that to work on a frame basis amounts to rewriting the whole application. Not something I'm willing to consider.
No, real problem now that I know how to set the flags for paff content I can remux my files. :)

Atak_Snajpera

14th June 2013, 14:01

I'm trying to combine 4 flacs (the same frequency , bitdepth , channels ) using append feature

http://s23.postimg.org/i2f8yt2mz/Untitled_2.png

http://s1.postimg.org/rjuz8m8pb/Untitled_3.png

Everything seems to be ok after remuxing. Duration is correct and plays ok in media player.

General
Complete name : E:\combined_flacs.mka
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.35 GiB
Duration : 2h 41mn
Overall bit rate mode : Variable
Overall bit rate : 1 192 Kbps
Encoded date : UTC 2013-06-14 12:53:02
Writing application : mkvmerge v6.2.0 ('Promised Land') built on Apr 28 2013 12:22:01
Writing library : libebml v1.3.0 + libmatroska v1.4.0

Audio
ID : 1
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 2h 41mn
Bit rate mode : Variable
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Writing library : libFLAC 1.3.0 (UTC 2013-05-26)
Default : Yes
Forced : No

However after demuxing with mkvextract new flac file has incorrect duration despite correct file size. All media players see only first 40 min (duration of first chunk)

General
Complete name : C:\temp\0_audio_Undetermined.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 1.34 GiB
Duration : 40mn 25s
Overall bit rate mode : Variable
Overall bit rate : 4 760 Kbps

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 40mn 25s
Bit rate mode : Variable
Bit rate : 4 706 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 1.33 GiB (99%)
Writing library : libFLAC 1.3.0 (UTC 2013-05-26)

I've even tried demuxing .mka with ffmpeg and still no luck.
ffmpeg throws out bunch of errors and final file again has correct size but duration is wrong (see above mediainfo report)

http://s23.postimg.org/5khje24nv/Untitled_1.png

Mosu

14th June 2013, 14:29

I'm trying to combine 4 flacs (the same frequency , bitdepth , channels ) using append feature

Yeah that won't work correctly as you noticed. FLAC streams start with a metadata block (http://flac.sourceforge.net/format.html#metadata_block_streaminfo). This block is required for playback, that's why mkvmerge keeps them.

The problem is twofold: 1. all of the four files contain metadata blocks and 2. each metadata block contains the number of samples in this stream. mkvmerge keeps all metadata blocks (which is not really correct), and it doesn't update the very first one (which isn't correct either).

So when you extract the single track back into a FLAC file it starts with the original metadata block of the first of the four original files. It still contains the number of samples appropriate for that first file, not the sum of all samples of all the files. Hence MediaInfo reporting the duration it is reporting.

I will most likely never fix that. You're free to open a bug report (https://trac.bunkus.org) for it, of course; that way there's at least a chance I might get around to it one day.

Atak_Snajpera

14th June 2013, 14:38

S**T! I was hoping to find a workaround for joining flacs without re-encoding process. It turns out that after all those years there is no tool which could merge flacs without lengthy re-encoding. You can split/join lossy OGG Vorbis losslessly but you can not do the same with plain lossless format! :(

Mosu

14th June 2013, 14:45

As far as I know there's nothing really preventing appending two FLAC files if their basic parameters match (sample rate, number of channels). Of course a tool that can do that will have to adjust the metadata (at least the STREAMINFO and SEEKTABLE blocks, but it should also deal gracefully with VORBIS_COMMENTS and PICTURE blocks). However, I've never done that myself and cannot give you pointers to tools that manage to do it.

SeeMoreDigital

14th June 2013, 20:11

Hi Atak,

I actually tried doing the same as you a few months ago, with no success...

In the end I had to re-encode using CUETools 2.1.4 which performed the task very quickly. So quickly in fact that I'm not sure if it did actually re-encode them. :scared:

Skylinestar

16th June 2013, 07:34

My CPU processor is Intel Core2Duo. Will I get significant improvement (less time) in demuxing and muxing MKV files if I were to upgrade to Intel Core i5 cpu?
I don't encode/convert video files. I just add on srt subs and remux the mkv.

nevcairiel

16th June 2013, 07:35

Muxing is mostly limited to IO speed, i don't think a faster CPU is going to help you much.

Mosu

16th June 2013, 07:44

What nevcairiel said. mkvmerge is I/O bound in almost all cases. Where it isn't limited by hard drive I/O speed it is limited by memory I/O speed.

smok3

16th June 2013, 14:41

Chetwood

17th June 2013, 06:14

mkvmerge is I/O bound in almost all cases.
Mmh, recently it felt like an old bug returned you had fixed some while ago cause muxing took 10+ min longer than simlpy copying over the file.

Snowknight26

17th June 2013, 13:27

VC-1 muxing takes considerably longer than other formats.

Atak_Snajpera

17th June 2013, 13:33

How is recoding flac lengthy in 2013 (just wondering), it should be a matter of seconds?

When I encode 2h - 3h 6 channel movie soundtrack encoding process using plain FLAC encoder on my Q6600@3Ghz can take even 10 minutes. Simple remuxing would take less than 30 seconds.
FLAC CL is obviously faster but it does not support wave64 and multiple input files (joining on fly).

Mosu

28th June 2013, 09:51

Hey,

I've released MKVToolNix 6.3.0. It fixes a couple of minor issues and contains only two small enhancements: saving the window positions and mmg being truly portable now (if it's not installed via the installer).

For package maintainers: nothing's changed compared to MKVToolNix 6.2.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.2.0:

2013-06-27 Moritz Bunkus <moritz@bunkus.org>
* Released v6.3.0.
* mkvmerge: bug fix: When appending unframed AVC/h.264 tracks and setting the default duration the second and all following source parts will use the same default duration as set for the first part. Fixes #889 (https://www.bunkus.org/trac/ticket/889).
* all: enhancement (Windows only): mmg will store its settings in a file "mkvtoolnix.ini" in the same folder mmg.exe is located in if MKVToolNix hasn't been installed via its installer. If it has been installed then the settings are stored in the Windows registry. This way MKVToolNix is truly portable.
* mmg: new feature: mmg's windows and dialogs will remember and restore their positions and sizes. Implements #878 (https://www.bunkus.org/trac/ticket/878).

2013-06-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: AVC/h.264 output module: fixed writing the wrong values if --fix-bitstream-timing-information is used. Fixes #888 (https://www.bunkus.org/trac/ticket/888).

2013-06-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: FLV reader: Implemented deriving the video dimensions for FLV1 type tracks from the frame content if they're not given within a script tag. Fixes #880 (https://www.bunkus.org/trac/ticket/880).
* mkvmerge: bug fix: Fixed handling MPEG transport streams with broken PES packet streams. Fixes #879 (https://www.bunkus.org/trac/ticket/879) and #887 (https://www.bunkus.org/trac/ticket/887).
* mkvextract: bug fix: mkvextract writes the correct value for the "block alignment" value in the header of WAV files (mostly affects mono PCM audio tracks). Fixes #883 (https://www.bunkus.org/trac/ticket/883).

2013-05-26 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a Portuguese translation of the programs by Ricardo Perdigão (see AUTHORS).

Have fun.

Selur

28th June 2013, 09:56

Thanks!! :)

filler56789

28th June 2013, 13:40

* all: enhancement (Windows only): mmg will store its settings in a file "mkvtoolnix.ini" in the same folder mmg.exe is located in if MKVToolNix hasn't been installed via its installer. If it has been installed then the settings are stored in the Windows registry. This way MKVToolNix is truly portable.

:goodpost:

:thanks: :thanks: :thanks:

Keiyakusha

28th June 2013, 18:21

Hi Mosu. I have a problem with windows installer.
For some reason after starting mmg it only appears after 10-15 seconds and it appears behind the active window...
Also fonts in some parts of the gui changed to something ugly...
Edit: basically all text that is "gray", inactive now uses bigger and uglier font (no cleartype support?)
Edit2: also I am talking about English version of the gui and I'm on Japanese locale. Japanese translation never was really beautiful to begin with.
File->Options takes ages to appear too. But some other dialogs, like header editor, are fine.

Mosu

28th June 2013, 18:34

I build against a new version of wxWidgets (the current series, 2.9.x). Unfortunately it's a lot slower than the old one, but that's something you'll have to live with for the time being, I'm afraid. The current series is going to be the new stable series 3.0.x soon enough, and I'm not willing to stay on an old series (2.8.x) indefinitely.

Mosu

28th June 2013, 18:39

Note that the current 6.3.0 Windows builds were done against a slightly out-of-date version of wxWidgets 2.9.x. It also contains a bug that manifests when you drag & drop a file to the "attachments" tab causing mmg to show an error message and quit/crash. I've re-built against the latest 2.9.4 which works regarding the drag & drop issue, but I haven't uploaded it yet. Instead I will try to build another version against the latest from the 2.8 series, 2.8.12, and see if that works better.

In any way expect new Windows builds soon. They'll be identical to the 6.3.0 release but built against a different wxWidgets library version as said above -- meaning they'll also use 6.3.0 and their version number, likely postfixed with "-1" in the installer/portable archive file, but not in the programs themselves.

Mosu

28th June 2013, 19:36

The new build against wxWidgets 2.8.12 is available now (http://www.downloadbestsoft.com/MKVToolNix.html) as v6.3.0-1. Drag & drop works well with it as far as I can tell. I'll keep using that version for the time being.

Keiyakusha

28th June 2013, 23:10

Thanks Mosu, this solved the issues for me.

hubblec4

29th June 2013, 20:00

hi mosu

why is the childelement "<ChapProcess>" not supported?

Error: The XML chapter file 'c:\test.xml' contains an error: <ChapProcess> is not a valid child element of <ChapterAtom> at position 590.

Mosu

29th June 2013, 20:49

Overdrive80

29th June 2013, 23:28

Hi Mosu, when you refer to "unframed" that meaning it. Excuse my ignorance. T_T

Mosu

30th June 2013, 07:27

AVC/h.264 video bit streams consist of NALUs. Those NALUs can either be separated by certain start codes or they can be prefixed with the NALU's length. Which it is depends on what container they're stored in (see e.g. this description (http://msdn.microsoft.com/en-us/library/windows/desktop/dd757808(v=vs.85).aspx)); e.g. raw AVC/h.264 elementary bit streams use start codes while length fields are used when they're stored inside MP4 or Matroska.

mkvmerge has different output modules for those two. "Framed" refers to the output module that accepts tracks that already contain those length fields. For these each memory slice that's handed over to the output module contains a full field or frame (depending on interlacing, of course), meaning those memory slices don't have to be post-processed anymore. The "unframed" output module accepts bits treams that use start codes. For those each memory slice can contain pretty much anything: less than a single frame, exactly one frame or even multiple frames at once. mkvmerge has to find those start codes itself and determine the length fields to add instead.

hubblec4

30th June 2013, 11:31

That element is called <ChapterProcess> in mmg's XML dialect. Here's the DTD (https://github.com/mbunkus/mkvtoolnix/blob/master/examples/matroskachapters.dtd) for the XML files listing all know element names.

thx,
but 4 childelements of the segmentinfo are missing.

ChapterTranslate 2 [69][24] - * - - m * * * * A tuple of corresponding ID used by chapter codecs to represent this segment.
ChapterTranslateEditionUID 3 [69][FC] - * - - u * * * * Specify an edition UID on which this correspondance applies. When not specified, it means for all editions found in the segment.
ChapterTranslateCodec 3 [69][BF] * - - - u * * * * The chapter codec using this ID (0: Matroska Script, 1: DVD-menu).
ChapterTranslateID 3 [69][A5] * - - - b * * * * The binary value used to represent this segment in the chapter codec data. The format depends on the ChapProcessCodecID used.

could you add this elements?

Mosu

30th June 2013, 11:46

For segment info files there's a separate DTD (https://github.com/mbunkus/mkvtoolnix/blob/master/examples/matroskasegmentinfo.dtd) (also for tags (https://github.com/mbunkus/mkvtoolnix/blob/master/examples/matroskatags.dtd)).

hubblec4

30th June 2013, 12:42

Overdrive80

30th June 2013, 15:34

Mosu

30th June 2013, 15:44

You cannot split where there are no key frames, no matter what codec/output module.

Chumbo

30th June 2013, 16:16

Ok thanks. If I dont undertand bad, would "unframed" output module let split properly changes scene in stream when not exists keyframe?
If you need to do frame-accurate editing, then take a look at VideoReDo h.264 edition, however, it's not free.

smok3

1st July 2013, 11:39

Thanks, 'You can't stop me!' is working fine on wheezy.

mkvmerge GUI question: Is it possible to disable automagical append, when opening a vob ? (I solved it by modifying the generated cli)

Mosu

1st July 2013, 11:42

No, it isn't.

Mosu

1st July 2013, 13:45

To elaborate. When you add a file to mmg the additionally processed files will always be added as well. If you don't want to process them you don't have to resort to the command line, though: select the file you've just added and hit the "additional parts" button. There you can remove the parts you don't want processed.

If you're OK with the command line then by all means, chose that route :) I just wanted to point out an alternative.

smok3

1st July 2013, 13:56

Thanks for elaboration, it is working exactly as you described.

hubblec4

3rd July 2013, 00:30

hi mosu

when you have time for watching this files (http://forum.gleitz.info/showthread.php?34646-Men%FC-und-mkv&p=438051&viewfull=1#post438051) would be nice.

this are files from dvdmenuxtractor.
in the *info.xml (segmentinfo) are elements of <chapterTranslate>
but they will not shown in the mmg's Header Editor.
mmg mux this file without issues.

the *menu.xml (chapters) has a complex structure(DVD-structure) but mmg mux this file without issues.

We may now assume that generates mkv has a dvd-strucure inside.

but the videos dont play well. i have tested Haali, LAV, AV Splitter and MPC- internal splitter.

im sure the problem are the splitters. but maybe mkvmerge is the problem.

i hope you can say that with mkvmerge is all right.

( and then i hope LAV or void(AV Splitter) will add this feature to her splitter^^)

in one of the zips you will find a *.btn file.

can you explain me what it is?
mmg mux it well too.

hubble

Mosu

3rd July 2013, 07:23

when you have time for watching this files (http://forum.gleitz.info/showthread.php?34646-Men%FC-und-mkv&p=438051&viewfull=1#post438051) would be nice.

I will answer concrete questions, but not a general "am I doing it right?" -- a bit limited on time at the moment.

in the *info.xml (segmentinfo) are elements of <chapterTranslate> but they will not shown in the mmg's Header Editor.

mmg's header editor does not list all possible elements -- neither for the segment info nor for the tracks. Only those that users usually have an interest editing in. The ChapterTranslate elements are definitely not displayed. You can check whether or not they're present with mkvinfo.

but the videos dont play well. i have tested Haali, LAV, AV Splitter and MPC- internal splitter.

As far as I know no splitter has ever implemented full support for DVD-style menus in Matroska. This information may be outdated.

in one of the zips you will find a *.btn file.

Those are button definitions: areas in which the menu in which the user can click so that things happen (e.g. language selection, chapter selection etc.).

hubblec4

3rd July 2013, 12:30

thanks mosu.

the menu.xml and info.xml are correct? and muxing with mmg are correct too?

so its a problem of the splitters?

mkvinfo show the elements of the segmentinfo, thx.

when i want mux the "extra"-files like *.btn and *.tmc, where must i selected in mmg? attachments?

Mosu

3rd July 2013, 12:34

the menu.xml and info.xml are correct? and muxing with mmg are correct too?

If mkvmerge acceps menu.xml and info.xml without complaints then they're syntactically correct. I cannot tell you if they're semantically correct because I've never looked at those menu features myself. dvdmenuextractor is also not my program; I haven't written it.

when i want mux the "extra"-files like *.btn and *.tmc, where must i selected in mmg? attachments?

*.btn can be added like any other input file.

I guess that *.tmc are timecode files. You'll have to select them as the "external timecodes" for each track that they belong to. Which they belong to I cannot tell you; maybe the file names give you a clue.

hubblec4

3rd July 2013, 12:36

mmg's header editor does not list all possible elements -- neither for the segment info nor for the tracks. Only those that users usually have an interest editing in. The ChapterTranslate elements are definitely not displayed.

yeah thats the problem.
nobody use it, cause its no exist this feature.

but i'm very sure if the menu-feature avalible a lot of people will use it.

hubblec4

3rd July 2013, 12:40

If mkvmerge acceps menu.xml and info.xml without complaints then they're syntactically correct. I cannot tell you if they're semantically correct because I've never looked at those menu features myself. dvdmenuextractor is also not my program; I haven't written it.

ok sounds good. ( I know your progg is mkvmerge^^)
but i think you have great plan of such things.

*.btn can be added like any other input file.

I guess that *.tmc are timecode files. You'll have to select them as the "external timecodes" for each track that they belong to. Which they belong to I cannot tell you; maybe the file names give you a clue.

thx for explanation.

hubblec4

3rd July 2013, 12:50

another issue:

i start mmg its shown in the taskbar but i dont see the progg on the screen.

a right-click on the taskbar-icon dont show me "move" (verschieben), so that i can see the progg agian.
if there a ini-file where i can change something.

Mosu

3rd July 2013, 12:52

hubblec4

3rd July 2013, 13:53

New in 6.3.0 is that mmg remembers the window position when you exit a window (not only for the main window but for most other windows like the header editor as well -- exceptions are the file dialogs). Try moving it to where you want it, closing and then re-starting it.

thats the problem i cant move it. there is no option by rightclick on the taskbar-icon of mmg.

and i dont see the window of mmg, so we i can move the mmgwindow?

Mosu

3rd July 2013, 14:02

I'm quite curious how you managed that. mmg contains code to move the window into the visible space even if the stored values are bogus. And how did you run mmg before... I mean you've obviously played around with the header editor etc?

Anyway: hold down shift while right-clicking on the taskbar icon. That should bring up the system menu. There you can select "move" etc.

hubblec4

3rd July 2013, 14:07

I'm quite curious how you managed that. mmg contains code to move the window into the visible space even if the stored values are bogus. And how did you run mmg before... I mean you've obviously played around with the header editor etc?
yesterday all fine, but today i start mmg and i dont see it on the sreen.
whats wrong: i have no idea.

Anyway: hold down shift while right-clicking on the taskbar icon. That should bring up the system menu. There you can select "move" etc.
first right-click: "move" is grey, i push restore
second right-click: "move" is avalible and i can move the mmgwindow.
thx that helps. now work it fine and i see the window of mmg agian.

cyberbeing

4th July 2013, 04:45

This same issue which hubblec4 described with the mmg window opening completely hidden & off-screen happened to me earlier today. Win7 SP1 x64.

Chetwood

4th July 2013, 06:51

but i'm very sure if the menu-feature avalible a lot of people will use it.
I'm very sure they won't cause they don't offer any real benefit. Given the puny amount of requests for menus, I'd say a lot of people see it this way.

Mosu

4th July 2013, 07:23

This same issue which hubblec4 described with the mmg window opening completely hidden & off-screen happened to me earlier today. Win7 SP1 x64.

When that happens the next time you start mmg please do the following:

do not close mmg right away or move it, but:
send me the registry settings written by mkvmerge (if you've isnstalled it; otherwise the mkvtoolnix.ini file from the same folder mmg.exe is located in)

The registry key to export is HKEY_CURRENT_USER\Software\mkvmergeGUI. Thanks.

cyberbeing

4th July 2013, 10:09

[HKEY_CURRENT_USER\Software\mkvmergeGUI\GUI\geometry\mmg_dialog]
"x"=dword:ffff8300
"y"=dword:ffff8300
"width"=dword:000000a0
"height"=dword:0000001b

I seem to have figured out how to reproduce it. If you close mmg by right-clicking from the taskbar when minimized, this issue occurs 100% of the time.

Mosu

4th July 2013, 10:12

Thanks, that makes it easy enough to fix.

Mosu

4th July 2013, 10:54

Fixed in the latest pre-build (www.bunkus.org/videotools/mkvtoolnix/win32/pre/) (518).

cyberbeing

4th July 2013, 18:48

Confirmed. Thanks, Mosu.

Selur

9th July 2013, 08:31

I'm using:
mkvmerge --ui-language en -o "H:\Output\test.mkv" -d 0 --default-track 0:yes --default-duration 0:50i --aspect-ratio-factor 0:1.422 --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Temp\audio.m2v" --default-track 0:yes --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Temp\video.ac3"
to multiplex a video and an audio stream into a mkv file, but end up with:
Error: The file 'H:\Temp\video.m2v' has unknown type. Please have a look at the supported file types (Error: The file 'H:\Temp\video.m2v' has unknown type. Please have a look at the supported file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <moritz@bunkus.org> if your file type is supported but not recognized properly.) and contact the author Moritz Bunkus <moritz@bunkus.org> if your file type is supported but not recognized properly..
I then rechecked 'mkvmerge --list-types' and it does list "MPEG video elementary streams [m1v m2v mpv]"
not sure where the problem is, uploaded the raw streams to: http://www.embedupload.com/?d=8EZYDECSL2
The video was extracted using mplayer, audio was extracted using mencoder; source was a vob file (http://www.embedupload.com/?d=0EH4VEOYF5).

Mosu

9th July 2013, 08:40

You're most likely running into a known problem with mkvmerge's MPEG-1/2 reader. That module was contributed by someone else a long time ago, and it turns out that there are files for which the module simply cannot find any frame at all due to several assumptions and errors. Unfortunately fixing this is neither trivial nor fast. I've started a complete re-write of that code a couple of weeks ago but quickly lost interest, both due to the amount of work and the sense that MPEG-1/2 simply is not that much of a priority for me. So no ETA on that.

I also don't have a workaround. Sorry.

Selur

9th July 2013, 08:41

Thanks for the info, not much of a problem, just wanted to report the issue. :)

Selur

9th July 2013, 09:10

Just as a side note, if you ever find the motivation to look more at it. If I use:
mencoder -nosound -ovc copy -o "H:\Temp\video.m2v" "H:\TESTCL~1\_AAA_M~1.VOB"
the extracted video is handled fine by mkvmerge, if I use:
mplayer -nosound -dumpvideo -dumpfile "H:\Temp\video.m2v" "H:\TESTCL~1\_AAA_M~1.VOB"
instead, mkvmerge fails.
-> So for me the solution is to simply use mencoder and if you look into it comparing the output of these two methods might help get a clue whats going wrong.

Mosu

9th July 2013, 16:59

Thanks, I'll keep that in mind. If it is indeed the aforementioned problem then I already know what's wrong -- the problem is that a fix requires such a huge change that a whole re-write is not much more work :(

pie

10th July 2013, 11:43

I'm using:
I then rechecked 'mkvmerge --list-types' and it does list "MPEG video elementary streams [m1v m2v mpv]"
not sure where the problem is, uploaded the raw streams to: http://www.embedupload.com/?d=8EZYDECSL2
The video was extracted using mplayer, audio was extracted using mencoder; source was a vob file (http://www.embedupload.com/?d=0EH4VEOYF5).

One other workaround: It muxes fine if you pass the m2v through ProjectX first.

Snowknight26

13th July 2013, 01:35

Mosu, I think mkvmerge has an issue splitting video.

Using this (http://stfcc.org/misc/mkvmerge%20split%20source.mp4) as the input file, muxing (as well as splitting) this file results in ffmpeg failing to decode the H.264 stream.

mkvmerge -o "mkvmerge split source.mkv" "--language" "0:eng" "--forced-track" "0:no" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "mkvmerge split source.mp4" ")" "--track-order" "0:0" "--split" "duration:30s"

Part 1 (http://stfcc.org/misc/mkvmerge%20split%20result.mkv) of the muxed MKV results in
[matroska,webm @ 00000000026dc680] decoding for stream 0 failed
Input #0, matroska,webm, from 'Z:\mkvmerge split result.mkv':
Metadata:
creation_time : 2013-07-13 00:24:33
Duration: 00:00:30.00, start: 0.000000, bitrate: 14872 kb/s
Stream #0:0(eng): Video: h264 (High), yuv420p, 1280x720 [SAR 1:1 DAR 16:9],
60 fps, 60 tbr, 1k tbn, 120 tbc (default)
from ffmpeg, rendering the stream unusable (unless I add -flags2 showall). More info is available on ffmpeg's trac (https://ffmpeg.org/trac/ffmpeg/ticket/2777).

Mosu

13th July 2013, 15:48

So... the reference decoder already has a problem with that MP4, and that MP4 is an already-remuxed thingy and not the original? Sorry, won't look into it.

zerowalker

13th July 2013, 16:08

Is it possible to Add VP9 Support?
As it´s currently supported as Webm when encoding, and i can see it in Mkvtoolnix when i open the Webm, but i can´t mux it into Webm itself, just mkv.

Thanks

Mosu

13th July 2013, 16:22

Yeah. Should be able to do that for the next version (no ETA for it, though). I've created a bug report for that in my tracker so I won't forget about it.

zerowalker

13th July 2013, 16:25

Great!

Appreciated:)

sneaker_ger

22nd July 2013, 08:19

Concerning bug #903:
Can files written with 5.9.0 - 6.3.0 be considered broken? Does this exclusively affect files muxed with "--engage no_simpleblocks"? Will remuxing with the next mkvmerge version/current pre fix those files?

Mosu

24th July 2013, 13:01

Concerning bug #903:
Can files written with 5.9.0 - 6.3.0 be considered broken?

Technically yes, because the values mkvmerge writes for that one element are pointing to the wrong element. From a practical point of view you will not ever notice this unless you're seeking inside such a file with a player that already uses this element. I don't know of any player that does.

Does this exclusively affect files muxed with "--engage no_simpleblocks"?

No, it affects all files if they contain normal BlockGroups for which a cue point has been created. That should mostly be those with subtitles, but it might also be a video key frame with a non-default duration.

Will remuxing with the next mkvmerge version/current pre fix those files?

Sure. mkvmerge does not read the cues when it re-muxes a Matroska file and is therefore not affected by the bug. Even if it had been I could easily have added a version-number dependent coping mechanism as I've done in the past already.

sneaker_ger

24th July 2013, 13:09

Thank you for the clarification.

AMED

2nd August 2013, 21:52

Hi Mosu,

Would there be any possibility of supporting extraction of A_MS/ACM audio with mkvextract?

Currently i receive the error below (from MeGUI) when i try to extract the 5.1 PCM audio from a mkv that is created by makeMKV.

Error: Extraction of track ID 1 with the CodecID 'A_MS/ACM' is not supported.

I have uploaded a small sample that causes the problem

http://www.mediafire.com/download/ha24ey6l24j6p0o/The_Hunter_t00_(2)-001.rar

EAC3to seems to handle this audio format fine.

Mosu

3rd August 2013, 09:26

That does not have any priority for me, sorry, especially as you seem to have a workaround in eac3to.

AMED

3rd August 2013, 10:19

No problems Mosu. Never hurts to ask the question :)

jq963152

4th August 2013, 13:22

@ Mosu:

Hello,

files created using MKVToolNix show the following in MediaInfo:

Writing application: mkvmerge v6.3.0 ('You can't stop me!') built on Jun 28 2013 20:09:41
Writing library: libebml v1.3.0 + libmatroska v1.4.0

Is there any way to make it show what GUI (like mmg or MeGUI for example) was used?

And if yes: how?

And if not: could you please implement it?

Mosu

4th August 2013, 15:25

It's currently not possible. I could add an option for that to mkvmerge and make mmg use it; MeGUI would have to be adjusted separately. However, I don't see much use for something like that -- as the muxing result only depends on the options used by the GUI, not which particular GUI created said options. I do agree that it might make tracking bugs in the GUIs concerning some automatic calculations done by the GUIs or whatever somewhat easier.

But then again I also am not particularly keen on spending an hour or two implementing this (yes, it does take that long for writing the code in mkvmerge, adding a regression test, writing documentation and translating said documentation and the help strings) until I've heard some convincing arguments why you need this particular feature in the first place. So please tell me what you're really trying to achieve by having that piece of information.

jq963152

5th August 2013, 00:18

Thanks for your reply.

It's currently not possible. I could add an option for that to mkvmerge and make mmg use it; MeGUI would have to be adjusted separately.

Well, i already asked the MeGUI devs to make it so that MediaInfo would show that MeGUI was used to create the video files (regardless of container type).

Then they answered the following:

iirc, we cannot do that using mkvmerge, the tool used to create MKV. So, it's a no-go...

;)

So please tell me what you're really trying to achieve by having that piece of information.

Well, you already named one reason, which would be:

I do agree that it might make tracking bugs in the GUIs concerning some automatic calculations done by the GUIs or whatever somewhat easier.

;)

It also simply would be nice to be able to keep track of what tool (and what version of that tool) was used to create the video file.

To me, personally, it would be at least as important to know what version of MeGUI (for example) was used to create the video file.

But at the moment, the MeGUI devs can not do that because MKVToolNix currently does not allow to do it.

reyflores

6th August 2013, 21:20

Chapter Editor, loading chapter text files gives ERROR PARSING THE FILE: this file does not contain valid chapters. I get this error way too often. I use the following format:

CHAPTER01=00:00:03.000
CHAPTER01NAME=Deleted Scene 1

I create up to fifty chapters and although there is "user error" involved I triple check each and every line and I can NOT decipher where the error is occurring? I use Windows 7x64 and the default Windows notepad for creating the chapter text files. I often have to go line by line and it can get very tedious. I only want to use the text format. Is there a tool that will verify or check what/where the error is occurring?

Thank you for your consideration.

hubblec4

6th August 2013, 23:46

reyflores

7th August 2013, 01:09

Thank you for the suggestion. I believe that may help in the future. In this case I painstakingly found the errors after searching 100 lines of text. Yes, it was "user" error. I forgot to add "NAME" to a couple of the lines.

SamKook

7th August 2013, 14:36

maybe i can help you.

i got the same issue one time by self creating the chapter.txt-file.

with the lines is allready fine, but you need at the end of the file an empty line.

jump to the last position of the text and hit ENTER, then safe the file.

I don't think that's right. The way I work, I never leave an empty line at the end and all my chapters work fine when I mux them with mkvmerge.
I don't actually use it's chapter editor though so maybe that's a contraint only for it.
I also usually do it via command line but I think I've done it a few times with the GUI, just not 100% sure about it.

Boulder

9th August 2013, 17:17

I'm having problems with appending linked mkv files and then extracting the FLAC audio track (using MKVExtractGUI-2) out of the resulting large mkv file. The reason why I'm doing this is that one of my HDs broke down and I need to recreate a part of my collection from backups which consist of linked mkv files (due to getting files to fit optimally on DVDs).

The troublesome file is in three parts. The whole file plays normally when the parts are in the same folder, but after appending the parts, the audio track is ruined. The playback length is incorrect and if I extract the FLAC track out of each part, the second and third parts are just static or complete silence.

I've also noticed that the merged file has incorrect chapters at least on the PC when using Media Player Classic (tried two different splitters), didn't test on my media player yet. MKVExtractGUI-2 shows the correct amount of chapters but it doesn't match with what MPC shows in the playback bar.

sneaker_ger

9th August 2013, 20:21

It could be because of the private data where Matroska stores the FLAC headers. If you have three different encodes they all have their own private data fields, but if you merge them into a single track/file only the first private data field is kept (more than one private data field is not possible in Matroska). It basically means that there can't be any fix from mkvmerge. What you can do however: reencode the three parts to a single new encode. Fortunately, since you are using a lossless codec, this only costs time.

/edit:
Tried reading up on it a bit and it seems that each FLAC frame should have its own header that make decoding it possible, so you probably shouldn't get static/silence, even if the duration is shown incorrectly. Maybe wait for Mosu to answer since I don't know if these individual frame headers are removed.

Boulder

10th August 2013, 10:54

The issue with the FLAC file seems to occur in this one only so there must be something specific in the linked files themselves. I tested another clip which was also in three segments but it worked just fine.

The chapter issue affects every file that has multiple segments. I can post screenshots if Mosu wants to see what MPC shows.

sneaker_ger

12th August 2013, 08:28

I've also noticed that the merged file has incorrect chapters at least on the PC when using Media Player Classic (tried two different splitters), didn't test on my media player yet. MKVExtractGUI-2 shows the correct amount of chapters but it doesn't match with what MPC shows in the playback bar.

The chapter issue affects every file that has multiple segments. I can post screenshots if Mosu wants to see what MPC shows.

So these are ordered chapters with segment linking of external files and the chapters don't work correctly on the merged file?
That would be expected as the segment UIDs those chapters link to do not exist anymore after the merge. You would have to manually edit the chapters since mkvmerge does not offer any "un-order" feature AFAIK.

Boulder

12th August 2013, 08:38

I kind of expected the append feature to automagically create correct chapters, but maybe it's not that simple. Though it shouldn't be complex since all the timecode information is there to use.

sneaker_ger

12th August 2013, 08:49

There was some kind of chapter magic for appending added not long ago, but I think it only works on "simple" chapters where each file had its own chapters to begin with. Ordered chapters use a single chapter info that describes the complete virtual timeline spanning over all files. As you say it probably is pretty simple to manually edit them since the times don't change and all you have to do is delete all the ordered chapter elements.

rhaz

15th August 2013, 11:39

Mosu

15th August 2013, 11:45

I kind of expected the append feature to automagically create correct chapters, but maybe it's not that simple. Though it shouldn't be complex since all the timecode information is there to use.

mkvmerge does indeed not contain such auto-un-linking-correction for chapters.

Mosu

15th August 2013, 11:47

Hi. Using latest mkvmerge GUI on Win8x64, when using .mkv file and selecting Open with mmg the progam launch but it stays minimized to taskbar and clicking it it won't open. It just stays forced in the taskbar.

This has been discussed (http://forum.doom9.org/showthread.php?p=1635328#post1635328) before and solved (http://forum.doom9.org/showthread.php?p=1635436#post1635436) in the meantime.

Boulder

15th August 2013, 16:07

mkvmerge does indeed not contain such auto-un-linking-correction for chapters.

Is there anything that could be done about the FLAC problem which I reported in my first post? I.e. the file was split into three linked segments but it is not possible to append them again or extract the audio track from the last two segments. If I play the individual segments in MPC-HC, there are no problems with the audio.

Mosu

15th August 2013, 16:09

Not really, no. Or maybe there could, but I'm definitely not willing to invest the time for it. Sorry.

Boulder

15th August 2013, 16:14

OK :( Is this behaviour encountered only with FLAC files or does it affect other ones too? I'd like to know which format I should use - FLAC consumes less disk space than the original DTS-HD MA or TrueHD.

Mosu

15th August 2013, 16:26

This particular problem applies to FLAC tracks, but not to any other (as far as I know).

Selur

16th August 2013, 08:14

Small question is there some sort of short cut when trying to append multiple files.
I have around 100 1min chunks named: chunks_1.mkv to chunks_100.mkv now I want do append them using mkvmerge.
writing: chunks_1.mkv + chunks_2.mkv + ... + chunks_100.mkv is kind of annoying :)

Cu Selur

Ps.: If this is not supported atm. would be nice if this could be added.

Mosu

16th August 2013, 09:03

In mmg you can select multiple files to append in the file dialog.

On the command line there's nothing trivial to achieve this, but it's not that difficult to script, e.g. with zsh (or equivalent bash syntax):

typeset -a args
for file (chunk*.mkv) {
if [[ ${#args} > 0 ]] args=($args +)
args=($args $file)
}
mkvmerge -o out.mkv $args

Selur

16th August 2013, 09:04

On the command line there's nothing trivial to achieve this,...
Okay, thanks. Just wanted to make sure I didn't miss something. :)

Cu Selur

sneaker_ger

18th August 2013, 23:38

Yes:
https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvpropedit.html

Mosu

19th August 2013, 20:15

In case anyone's wondering what sneaker_ger's referring to: there had been a post (deleted since) asking if it's possible to add/remove attachments without remuxing.

mirek190

29th August 2013, 08:53

Hi Mosu

I can say really nice piece of work !

But I have one problem with mkvtoolnix ( mkvextract exactly ).

If I add opus audios into mkv I cannot extract them later from mkv file with the help mkvextract.

It happens just with opus audio.

Could you repair it?

Thanks for your work again !

Mosu

29th August 2013, 08:57

Opus extraction is not supported in mkvextract. I cannot tell you when it will be (that's more of a "when" than an "if").

hubblec4

29th August 2013, 16:05

hi Mosu

a question about the chaptereditor. for chapternaming it is possible more then one name to set. why? and what effect have it for the chapters?

in the chapter.xml i found more "nodes" "<chapterstring>" as one, but only the first "chapterstring-node" will be shown during playback. LAV and AVSplitter and Haali.

for what need more then one chapterstring-node?

Mosu

29th August 2013, 16:18

You can provide different names in different languages. The idea is that a player can show other languages based on the player's own interface language. Think of the strings more like elaborate descriptions than simple names. In Matroska not only can you number your chapters ("1", "2", ... "12") but you can provide descriptions if you want ("Chapter 03: Introduction of the thief character").

Now displaying such a description is of course a problem if it's written in a language the user doesn't understand. Therefore we decided to provide the option in the specs for providing the translations at the same time. For the prior example you could flag that description as the English one and provide another <chapterstring> entry flagged as German: "Kapitel 03: Einführung des Diebescharakters". If the OS's language (or the player's interface language) is set to German the player can show the German string. Otherwise it can show the English string (which is supposed to be the default/fallback). Both entries apply to the same chapter, of course.

I don't know if there's actually a player out there that makes use of this feature.

hubblec4

29th August 2013, 19:13

ok, i think i understand a little bit :-)

i'm sure there is no player (splitter) that can handle this feature.

thanks for the explanation.

atm: when i want two or more "language-chapters" i create two or more editons. so you can change the language of all chapters with two clicks in the player.
but its sound nice if the player can this by himself.

hubblec4

29th August 2013, 19:47

next question's :-)

chapter/edition -UID: your chaptereditor set 19 digits, i have used other proggs and there are 10 digits or 12 and so on.
with 20 digits works it to (i used your "verify-option")

what is the right number of digits?

segment UID: i.e.: is it ok when i use 32 digits of number 9? (99999999999999999999999999999999)
the format is hex. can i use chars like A or B (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)?

Mosu

30th August 2013, 17:08

The Matroska specs (http://www.matroska.org/technical/specs/index.html) tell you that both UIDs are Matroska unsigned integer: up to 64bits. mkvmerge choses one randomly. They have to be unique with the logical segment. When you merge (or append) two Matroska files then entries with the same UID are considered to belong to the same entry and will be merged, too, of course.

Chetwood

4th September 2013, 15:49

I thought that mmg would be capable of applying a command-line to an entire directory of files but Mosu pointed me at this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3ABatchMuxingWithMMG) so I was wondering if anyone here can turn this commandline

"D:\Programme\MKVtoolnix\mkvmerge.exe" -o "e:\\remux ok\\Test S02E05.mkv" "--priority" "lower" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1280x720" "--language" "1:ger" "--default-track" "1:yes" "--forced-track" "1:no" "--language" "2:eng" "--default-track" "2:no" "--forced-track" "2:no" "-a" "1,2" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "M:\\remux\\Test S02E05.mkv" ")" "--language" "0:ger" "--default-track" "0:yes" "--forced-track" "0:yes" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "M:\\remux\\Test S02E05-de-forced.idx" ")" "--language" "0:ger" "--default-track" "0:no" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "M:\\remux\\Test S02E05-de.idx" ")" "--language" "0:eng" "--default-track" "0:no" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "M:\\remux\\Test S02E05-en.idx" ")" "--track-order" "0:0,0:1,0:2,1:0,2:0,3:0" "--engage" "no_cue_duration" "--engage" "no_cue_relative_position"

into a batch that runs on Windows? It's muxing each mkv of one directory with its corresponding subs (de forced, de, en or sometimes de and en only).

Boulder

4th September 2013, 15:57

I used this for my Star Trek TNG stuff.

for %f in (star*.h264) do "C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "M:\\Series\\Star Trek The Next Generation\\Season 3\\%~nf.mkv" "--priority" "higher" "--forced-track" "0:no" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "J:\\%~nf.h264" ")" "--language" "0:eng" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "J:\\%~nf.m4a" ")" "--language" "0:eng" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "J:\\%~nf.srt" ")" "--track-order" "0:0,1:0,2:0" "--chapters" "J:\\%~nf.xml"

Basically it's looking for files named star*.h264 in the current directory, picks up the full filename and then uses it (without the extension, hence the %~nf) to fill the fields mkvmerge needs.

I don't know how to adjust it for situations where the muxing process is not exactly the same in every case but maybe this will help you a bit.

sneaker_ger

4th September 2013, 16:25

@echo off
if exist *.mkv mkdir remux
for %%a in (*.mkv) do (
if exist "%%~na-de-forced.idx" mkvmerge --engage no_cue_duration --engage no_cue_relative_position -o "remux\%%a" --language 1:ger --language 2:eng ="%%a" --default-track 0:yes --forced-track 0:yes --language 0:ger ="%%~na-de-forced.idx" --language 0:ger ="%%~na-de.idx" --language 0:eng ="%%~na-en.idx"
if not exist "%%~na-de-forced.idx" mkvmerge --engage no_cue_duration --engage no_cue_relative_position -o "remux\%%a" --language 1:ger --language 2:eng ="%%a" --default-track 0:no --language 0:ger ="%%~na-de.idx" --default-track 0:no --language 0:eng ="%%~na-en.idx"
)

hello_hello

4th September 2013, 21:52

Is there a change MKVMergeGUI might one day have a "New" button above the "Add" button? Or somewhere in the vicinity? Maybe it's just me but I'm so used to clicking on "Add" or "Append" or "Remove" etc I sometimes catch myself moving the cursor towards the same area for "New" too.... before I remember it's all the way over the other side hidden under the File menu. :)

Thanks for your continued work on MKVMerge. I couldn't imagine life without it.

Mosu

4th September 2013, 21:56

Reino

4th September 2013, 22:35

@ Boulder, sneaker_ger:
Can't you people hit enter a couple more times? Not all of us have ultra-wide-screen monitors!

O.t.o.h, (as on the Hydrogenaudio Forums for instance) would be really handy for lots of code or situations like above.

Mosu

4th September 2013, 22:45

And "nice example!" or "good work!" or "thanks!" wouldn't have hurt to say either. Just saying.

Selur

6th September 2013, 12:39

trying to multiplex a m2v raw video stream and a flac audio stream using:
mkvmerge --ui-language en -o "H:\Output\mplayer_detects_noAudio.mkv" --global-tags "H:\Output\mplayer_detects_noAudio_13_29_11_5210__04.xml" -d 0 --default-track 0:yes --track-name 0:"0" --default-duration 0:59.94i --aspect-ratio-factor 0:0.889 --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_29_11_5210_03.m2v" --default-track 0:yes --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_3_aid_128_13_29_11_5210_02.flac"

I got:
mkvmerge v6.3.0 ('You can't stop me!') built on Jun 27 2013 22:06:07

'H:\Output\13_29_11_5210_03.m2v': Using the demultiplexer for the format 'AVC/h.264'.

'H:\Output\iId_3_aid_128_13_29_11_5210_02.flac': Using the demultiplexer for the format 'FLAC'.

+-> Parsing the FLAC file. This can take a LONG time.

+-> Pre-parsing FLAC file: 2%
+-> Pre-parsing FLAC file: 7%
+-> Pre-parsing FLAC file: 12%
+-> Pre-parsing FLAC file: 17%
+-> Pre-parsing FLAC file: 22%
+-> Pre-parsing FLAC file: 28%
+-> Pre-parsing FLAC file: 33%
+-> Pre-parsing FLAC file: 38%
+-> Pre-parsing FLAC file: 43%
+-> Pre-parsing FLAC file: 48%
+-> Pre-parsing FLAC file: 53%
+-> Pre-parsing FLAC file: 58%
+-> Pre-parsing FLAC file: 63%
+-> Pre-parsing FLAC file: 68%
+-> Pre-parsing FLAC file: 73%
+-> Pre-parsing FLAC file: 79%
+-> Pre-parsing FLAC file: 84%
+-> Pre-parsing FLAC file: 89%
+-> Pre-parsing FLAC file: 94%
+-> Pre-parsing FLAC file: 99%
+-> Pre-parsing FLAC file: 100%

'H:\Output\13_29_11_5210_03.m2v' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.

'H:\Output\iId_3_aid_128_13_29_11_5210_02.flac' track 0: Using the output module for the format 'FLAC'.

The file 'H:\Output\mplayer_detects_noAudio.mkv' has been opened for writing.

Error: 'H:\Output\13_29_11_5210_03.m2v' track 0: mkvmerge encountered broken or unparsable data in this AVC/h.264 video track. Either your file is damaged (which mkvmerge cannot cope with yet) or this is a bug in mkvmerge itself. The error message was:

No error
and an mkv file which is only 14kByte.
-> uploaded the raw stream, the mkv and the xml file I used: http://www.embedupload.com/?d=1XQGVKIQB1

Not sure if the m2v is broken (plays fine in MPC-HC) in one or the other way or if it really is a bug in mkvmerge.

-> Thanks for looking into it. :)

Cu Selur

Ps.: "" -> yes, a horizontal and vertical scrolling codebox wouldn't be such a bad idea. *gig* (personally I don't really care, since I normally copy&paste command line I need into an editor anyways.)

Mosu

6th September 2013, 12:56

Sorry, I won't spend time on investigating MPEG-1/2 related parser issues. The MPEG-1/2 code is known to have a lot of problems that I've already spent hours trying to improve them, and I've tried re-writing it from scratch. Simply too much effort, as it turned out, especially for legacy video formats.

Chetwood

7th September 2013, 07:36

@Boulder, sneaker_ger
Thanks!

hello_hello

7th September 2013, 08:06

No, definitely not. That area is already crowded enough, and it wouldn't fit topically into what a "new" function does (especially "File -> new"). What "new" really does is clear ALL inputs in ALL of the tabs (except for the chapters). The "add", "append" and "remove..." buttons on the other hand only work on the file/track list and are therefore located close to it.

Yep, after thinking about it I agree with what you're saying, however....
If you put it at the top right, level with the tabs and menu, it'd be obvious it's not just for working with the file/track list, even more so due to it's it's continued presence when switching tabs.
The "Start muxing", "Copy to Clipboard" and "Add job to queue" buttons are all similarly "global", only down the bottom. Alternatively could they share some of the spare real estate with a "Clear everything" button?

From this users perspective, as if I had to estimate my ratio of File/New menu selecting to "Copy to Clipboard" button clicking, it'd probably be somewhere in the vicinity of five thousand to zero, a "Reset MKVMerge" button would be more convenient than File/New..... which based on the behaviour of other Windows programs, originally had me thinking it would open a new instance of MKVMergeGUI rather than perform a reset.

Selur

7th September 2013, 08:29

Sorry, I won't spend time on investigating MPEG-1/2 related parser issues.
No, problem. Just wanted to let you know of the issue and thought I provide a sample.

Mosu

7th September 2013, 09:19

If you put it at the top right, level with the tabs and menu,

That would require serious wrestling with the (not so much beloved) GUI toolkit I'm unfortunately using. Still a "no".

The "Start muxing", "Copy to Clipboard" and "Add job to queue" buttons are all similarly "global"

I'll think about replacing "Copy to clipboard" with "New", re-adjusting the layout of those three buttons at the bottom to make it clear which belong together: first "Start muxing" and "Add to job queue" close together, some space, then the "new" one. I don't like "Clear everything" as it would do the same as "File -> New" just with a different name, and giving the same function different names is a sure way to confuse the heck out of users.

mastrboy

7th September 2013, 11:38

What...? Don't remove "Copy to Clipboard" please, I use that functionality when i create batch script for mkvmerge.

Mosu

7th September 2013, 11:52

Only the button at the bottom. The menu entry ("Muxing -> Copy to clipboard") will remain, of course. However, I too think that more users actually use "File -> New" than "Muxing -> Copy to clipboard"); therefore the proposed change to the buttons at the bottom.

mastrboy

7th September 2013, 14:56

Oh, good.
I thought you meant to remove the entire "copy to clipboard" functionality...

Mosu

7th September 2013, 23:00

I rarely (if ever) actually remove functionality. One exception is the infamous header removal compression which cannot be turned on anymore at the moment (thought the code is still there, the user interface for it is simply not present/working). Copy to clipboard is definitely here to stay :)

Atak_Snajpera

13th September 2013, 12:00

what is happening with opus in matroska? any breakthrough or we are still in woods?

Kurtnoise

13th September 2013, 13:52

Seems to be useable in mkvtoolnix since July (https://github.com/mbunkus/mkvtoolnix/commits/master) according to the last commits...Matroska specs have been also updated accordingly.

Atak_Snajpera

13th September 2013, 17:53

Thanks Kurtnoise. I will have to take a look at the latest mkvtoolnix then.

Mosu

16th September 2013, 08:57

Hey,

I've released MKVToolNix 6.4.0. Not a lot has happened over the summer, but the Opus support has been finalized. A couple of bug fixes here and there as well, especially regarding startup problems on Windows (the mmg window not appearing). However, the next release should feature HEVC support, and I didn't want to hold off the release until that's been finished as it may still take a couple of weeks. So here you go.

For package maintainers: you need libMatroska 1.4.1 due to new elements, a version that hasn't been released yet (libEBML requirements stay at the already-released 1.3.0). MKVToolNix' configure will fall back to the included version and build it statically. I'm sorry for this, and this is not intentional but due to severe lack of time on my side these past weeks. I'll try to release said library within the next two or three week. So feel free to hold off packaging this MKVToolNix version until then.

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.3.0:

2013-09-15 Moritz Bunkus <moritz@bunkus.org>
* Released v6.4.0.
* mkvextract: new feature: Implemented extraction of Opus tracks into OggOpus files.

2013-09-14 Monty Montgomery <xiphmont@gmail.com>
* mkvinfo: bug fix: The track information summary enabled with -t/--track-info counted bytes in SimpleBlocks twice.

2013-07-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: CueRelativePosition was wrong for BlockGroups: it pointed to the Block inside the group instead of the BlockGroup itself. CueRelativePosition elements for SimpleBlock elements are not affected. Fixes #903 (https://www.bunkus.org/trac/ticket/903).

2013-07-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented final Opus muxing.

2013-07-04 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The "jobs" folder will be created in the same mmg.exe is located in for the portable version. The installed version will still keep the folder where has already been (%APP_DATA%\mkvtoolnix\jobs).
* mmg: bug fix: Closing mmg's window while it was minimized caused mmg to appear hidden and unmovable when started the next time.

2013-07-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed overly long startup time with wxWidgets 2.9.x (especially on Windows) by using alternative methods for initializing certain controls. Makes startup time on par with wxWidgets 2.8. See #893 (https://www.bunkus.org/trac/ticket/893).

2013-07-02 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: new feature: Added support for the new Matroska elements DiscardPadding, CodecDelay and SeekPreRoll.
* build system: libMatroska 1.4.1 is now required for building.

Have fun.

john33

16th September 2013, 09:25

Thanks for the new build, but I've had to revert to 6.3.0 as the first movie I muxed, 720p X264 and 6 channel aac audio, plays back with no audio in VLC and MPC-HC, but plays as expected when muxed with 6.3.0. I'm on Windows 7 Pro x64.

Mosu

16th September 2013, 09:32

I'm currently at work and can therefore not test/verify this. Does anybody else see such a severe problem? If so I may have to pull this release...

sneaker_ger

16th September 2013, 09:56

Can't reproduce here. Muxed x264 H.264 + 6ch AAC and plays fine using VLC 2.0.8 and LAV/MPC-HC.

Mosu

16th September 2013, 09:59

That's reassuring. Thanks for the feedback. Will continue to monitor all my usual communication channels for reports about similar problems, of course.

Selur

16th September 2013, 10:05

don't use VLC, but here what I tried:
remuxed avc + dts 5.1 with mkvmerge 6.4.0 -> got sound with MPC-HC
remuxed avc + ac3 5.1 with mkvmerge 6.4.0 -> got sound with MPC-HC
remuxed avc + he-aac 5.1 with mkvmerge 6.4.0 -> got sound with MPC-HC
remuxed avc + aac lc 5.1 with mkvmerge 6.4.0 -> got sound with MPC-HC

-> doesn't seem to be a general problem with mkvmerge

john33

16th September 2013, 10:17

Hmmm, strange. I did a clean re-install of 6.4.0 and the problem persists, but I'll try on another system and report back.

john33

16th September 2013, 11:10

Well, I've tested on another, but similarly configured, system and 6.4.0 muxes using aac and ac3 all fail to play the audio whereas 6.3.0 muxes all play fine! It's not an issue I've ever had before but it would seem that there is some peculiarity with my systems since others don't appear to have the problem. I'll stick with 6.3.0 for the time being and see if I can ascertain the problem when I have the time (and the inclination! ;) ).

Mosu

16th September 2013, 11:17

Might be good if you could upload an example: both source files (audio & video) plus the failing Matroska file created with 6.4.0.

john33

16th September 2013, 11:25

I'll have to create clips and check that they fail otherwise I'm looking at about a 10GB upload!

john33

16th September 2013, 11:49

Well, at least it's consistent and fails on all files, not just the first one I tried. ;) Another mux just tried, the output using 6.4.0 was 428,074,207 bytes and using 6.3.0 was 428,068,653 bytes. Would you expect a difference in file size from identical inputs?

Mosu

16th September 2013, 12:21

Yes -- depending on the track types involved.

BTW: if you want to produce a small file then tell mkvmerge to split by ranges and only include the first 30 seconds or so.

john33

16th September 2013, 15:03

OK, uploaded 30secs of an mkv - two versions, one muxed with 6.3.0 which plays normally and the other muxed with 6.4.0 which plays without audio. Which is which is obvious from the file names. Both were created from the same sources. If you need any more from me, just ask. ;)

Mosu

16th September 2013, 15:43

Very disturbing. Your 6.4.0 file contains track headers for the AAC track, but not a single data packet. Hence the size difference.

More interesting is that I cannot reproduce the issue so far. Therefore I'll have to ask you for the AAC file in question... If it's a raw .aac file (instead of e.g an .mp4 or .m4a) then you can simply stop uploading after a couple of MBs. With .mp4 or .m4a I'll need the whole file because those files often have important file structure information (headers, indexes...) located at the end. Not always, but sometimes.

john33

16th September 2013, 16:08

4mb of raw aac file uploaded. :) The aac file was originally transcoded from ac3 with qaac.

Mosu

16th September 2013, 16:14

Thanks. Please also paste the mux settings you've used (e.g. in mmg "Muxing -> Copy command line to clipboard").

john33

16th September 2013, 16:52

The 6.4.0 settings:

"C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "I:\\MKVs\\john33 (2).mkv" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:720x404" "--default-duration" "0:24000/1001p" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "I:\\MKVs\\john33.mkv" ")" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "I:\\MKVs\\john33_track2.aac" ")" "--track-order" "0:0,1:0"

The 6.3.0 settings (the same, of course):

"C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "I:\\MKVs\\john33 (3).mkv" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:720x404" "--default-duration" "0:24000/1001p" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "I:\\MKVs\\john33.mkv" ")" "--language" "0:eng" "--default-track" "0:yes" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "I:\\MKVs\\john33_track2.aac" ")" "--track-order" "0:0,1:0"

Mosu

16th September 2013, 19:23

I can finally reproduce some kind of weird issue that's similar but not identical to your issue. However, I strongly think that both have the same underlying reason. Fixing. Once fixed I will probably have to release 6.4.1.

john33

16th September 2013, 19:28

Thanks for looking into this. I was quite happy to remain using 6.3.0 but that clearly isn't progress. ;) If you would like me test test anything prior to release, just let me know.

Mosu

16th September 2013, 19:31

I'll ask you to test a pre-build with the fix once I've tracked that bugger down -- before I make the next release. Better safe than sorry. Said pre-build should hopefully be done within an hour.

john33

16th September 2013, 19:37

Excellent, thanks. I'll check back at intervals. :)

Mosu

16th September 2013, 20:36

Here's the build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-6.4.0-build20130916-521-4e2cd32-setup.exe). Thanks for testing.

john33

16th September 2013, 20:56

That works. :)

Edit: Tested on several files and all OK now, thanks very much.

Mosu

16th September 2013, 20:58

Thanks for the confirmation. Starting the release process.

john33

16th September 2013, 21:39

Just to confirm that the release build works fine, too. Many thanks for this. :)

Mosu

16th September 2013, 21:42

Hey,

I've released MKVToolNix 6.4.1 only one day after the release of 6.4.0 due to a nasty regression in 6.4.0 compared to 6.3.0. This release fixes that single bug only. For reference I'll include the previous release message including the new ChangeLog entries. Note that only the source and Windows packages have been uploaded yet; the Linux binaries are still being built.

Not a lot has happened over the summer, but the Opus support has been finalized. A couple of bug fixes here and there as well, especially regarding startup problems on Windows (the mmg window not appearing). However, the next release should feature HEVC support, and I didn't want to hold off the release until that's been finished as it may still take a couple of weeks. So here you go.

For package maintainers: you need libMatroska 1.4.1 due to new elements, a version that hasn't been released yet (libEBML requirements stay at the already-released 1.3.0). MKVToolNix' configure will fall back to the included version and build it statically. I'm sorry for this, and this is not intentional but due to severe lack of time on my side these past weeks. I'll try to release said library within the next two or three week. So feel free to hold off packaging this MKVToolNix version until then.

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.3.0:

2013-09-16 Moritz Bunkus <moritz@bunkus.org>
* Released v6.4.1.
* mkvmerge: bug fix: fixed packet ordering regression introduced in 6.4.0 if --default-duration is used for a track.

2013-09-15 Moritz Bunkus <moritz@bunkus.org>
* Released v6.4.0.
* mkvextract: new feature: Implemented extraction of Opus tracks into OggOpus files.

2013-09-14 Monty Montgomery <xiphmont@gmail.com>
* mkvinfo: bug fix: The track information summary enabled with -t/--track-info counted bytes in SimpleBlocks twice.

2013-07-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: CueRelativePosition was wrong for BlockGroups: it pointed to the Block inside the group instead of the BlockGroup itself. CueRelativePosition elements for SimpleBlock elements are not affected. Fixes #903 (https://www.bunkus.org/trac/ticket/903).

2013-07-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented final Opus muxing.

2013-07-04 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The "jobs" folder will be created in the same mmg.exe is located in for the portable version. The installed version will still keep the folder where has already been (%APP_DATA%\mkvtoolnix\jobs).
* mmg: bug fix: Closing mmg's window while it was minimized caused mmg to appear hidden and unmovable when started the next time.

2013-07-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed overly long startup time with wxWidgets 2.9.x (especially on Windows) by using alternative methods for initializing certain controls. Makes startup time on par with wxWidgets 2.8. See #893 (https://www.bunkus.org/trac/ticket/893).

2013-07-02 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: new feature: Added support for the new Matroska elements DiscardPadding, CodecDelay and SeekPreRoll.
* build system: libMatroska 1.4.1 is now required for building.

Have fun.

Mosu

16th September 2013, 21:42

Just to confirm that the release build works fine, too. Many thanks for this. :)

Right back at you. Thanks a lot for all the timely feedback.

Selur

17th September 2013, 18:37

@Mosu: any plans regarding newer Mac OS X builds? (last version is 6.2.0)

Mosu

17th September 2013, 18:41

Those are in the hands of third-party developers. You can try contacting Jon (jonthn.free.fr/MKVtoolnix/CONTACT) when he'll be able to update. Or switch to MacPorts (http://www.macports.org/). While they're still at 6.3.0 they're also pretty quick to update these days.

DarrellS

17th September 2013, 23:10

Any timeline on when the next version with hevc support will be released? I'm using the Rovi build from DivX Labs in Virtualdub's external encoder and the settings that I normally use are not working with their build.

I normally use this setting for audio and video...

-o "%(outputname)" --default-duration 0:%(fpsnum)/%(fpsden)fps "%(tempvideofile)" "%(tempaudiofile)"

...but I'm getting an error message that it doesn't know what "--default-duration 0:%(fpsnum)/%(fpsden)fps" means and the only way that I'm able to use the muxer is to use this setting...

-q -o "%(outputname)" "%(tempvideofile)" "%(tempaudiofile)"

...but the finished file is out of sync since it doesn't know what the frame rate is of the hevc file (which is whatever the framerate is of the original file). What can I do to tell mkvmerge what the original file is without manually changing the framerate on every single file that I create?

Not sure why it won't accept "--default-duration 0:%(fpsnum)/%(fpsden)fps" since every other build of mkvmerge.exe will.

Selur

18th September 2013, 07:26

I'm using the Rovi build from DivX Labs
sounds like you should contact Rovi/DivX and not Mosu, it's their build,.

Mosu

18th September 2013, 07:46

First: what Selur said. I don't support builds by third parties.

Second: we are just in the process of finishing the HEVC-in-Matroska specs. Note that Rovi's build may NOT be using the final method we will agree upon, though they've been eager to adopt their build to match the latest proposal (see and following (http://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html)). I will not release a MKVToolNix build with HEVC support before those specs have been finalized and agreed upon. Therefore my guess (really a guess, not even an estimate) would be "no earlier than in eight weeks".

DarrellS

19th September 2013, 13:04

Thanks! I'm in no big hurry, I was just wondering. Maybe by then, someone will have implemented stdin input into the Multicoreware x265 encoder which seems to be a lot faster than the DivX encoder and has more options. The Rovi build does mux the DivX hevc file after it's created and creates an insync file if given the frame rate. It's just a lot easier using your builds to mux with with since they accept "--default-duration 0:%(fpsnum)/%(fpsden)fps" which saves me from either having to create separate encoder sets for each frame rate or muxing after the audio and video files have been created. The other issue is that the DivX files will only play in the DivX player and not in MPC-HC which is my player of choice.

Thanks again

DarrellS

19th September 2013, 13:07

sounds like you should contact Rovi/DivX and not Mosu, it's their build,.

I think I'm still a member at DivX Labs so I'll check with them.

I didn't know that your new version of Hybrid uses the DivX HEVC encoder. I'll download it and give it a try.

Kurtnoise

19th September 2013, 13:19

Maybe by then, someone will have implemented stdin input into the Multicoreware x265 encoder which seems to be a lot faster than the DivX encoder and has more options. The Rovi build does mux the DivX hevc file after it's created and creates an insync file if given the frame rate. It's just a lot easier using your builds to mux with with since they accept "--default-duration 0:%(fpsnum)/%(fpsden)fps" which saves me from either having to create separate encoder sets for each frame rate or muxing after the audio and video files have been created. The other issue is that the DivX files will only play in the DivX player and not in MPC-HC which is my player of choice.
who cares ? You're off-topic right now...

hubblec4

24th September 2013, 14:50

hi mosu

i have a problem with appending files.
i have a movie(h264 untouched), i want cut a short videosequence by timecodes getting from the chapters (chapterfile).

first cut 00:01:30.000
second cut 00:02:50.000

now i have three videoparts. i load the first part in mmg and append the third part. muxing done with 0 error.

the videofile plays fine till the first cut (00:01:30.000), then stuttering the video for 2 or 3 seconds. and only madvr recalibrate the video after this short time. (EVR, vmr, haali renderer sucks).
when i jump back to 00:01:30.000 (in MPC-HC with chapter prev) plays the video fine, no stuttering. but when i go to previous timestamp as 00:01:30.000, the video stuttering agian.

the three video parts play seperatly fine.

sneaker_ger

24th September 2013, 15:12

It was originally a complete, single file? Was it encoded with OpenGOP?

hubblec4

24th September 2013, 15:20

It was originally a complete, single file? Was it encoded with OpenGOP?

it is a single file, yes. and it came from a bluray.

OpenGOP, i dont know. mediainfo:
Allgemein
UniqueID/String : 142136116527023072389979487536299840814 (0x6AEE6B98C50B77314A39226D8E07152E)
CompleteName : ***video.mkv
Format : Matroska
Format_Version : Version 1
FileSize/String : 5,38 GiB
Duration/String : 42min
OverallBitRate_Mode/String : variabel
OverallBitRate/String : 18,0 Mbps
Encoded_Date : UTC 2013-09-22 16:23:23
Encoded_Application : eac3to
Encoded_Library/String : Haali DirectShow Matroska Muxer 1.13.138.14

Video
ID/String : 1
Format : AVC
Format/Info : Advanced Video Codec
Format_Profile : High@L4.1
Format_Settings_CABAC/String : Ja
Format_Settings_RefFrames/String : 4 frames
MuxingMode : Container profile=Unknown@0.0
CodecID : V_MPEG4/ISO/AVC
Duration/String : 42min
BitRate_Mode/String : variabel
BitRate/String : 17,6 Mbps
BitRate_Maximum/String : 38,0 Mbps
Width/String : 1 920 Pixel
Height/String : 1 080 Pixel
DisplayAspectRatio/String : 16:9
FrameRate_Mode/String : konstant
FrameRate/String : 23,976 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
ScanType/String : progressiv
Bits-(Pixel*Frame) : 0.354
StreamSize/String : 5,27 GiB (98%)
Default/String : Nein
Forced/String : Nein
colour_primaries : BT.709
transfer_characteristics : BT.709
matrix_coefficients : BT.709

sneaker_ger

24th September 2013, 16:14

MediaInfo does not offer detection for open gop AFAIK (aside from reading x264 custom sei). Can you upload a short (~1 minute) sample, perhaps your "first cut"?

hubblec4

24th September 2013, 16:32

MediaInfo does not offer detection for open gop AFAIK (aside from reading x264 custom sei). Can you upload a short (~1 minute) sample, perhaps your "first cut"?

ok.

video.mkv (http://www.file-upload.net/download-8111016/split-001--1-.mkv.html)

sneaker_ger

24th September 2013, 17:14

It seems to indeed be using open gop which cannot be cut reliably using mkvtoolnix.

hubblec4

24th September 2013, 17:26

mmh other episodes are work fine.

is this a problem to the entire file? or can i cut on other timecodes?

sneaker_ger

24th September 2013, 18:08

You should be able to cut on a few specific timecodes, namely I frames that are directly preceded by a P frame. You will mostly find these on scene changes.
This AviSynth script will show you the type of a given frame:
ffvideosource("split-001--1-.mkv")
ffinfo()

Chetwood

26th September 2013, 11:24

@sneaker_ger

I tried to adapt your batch to muxing a folder full of MKVs and Vobsubs but failed. Can you give it another try?

1 idx/sub with 2 languages per MKV:
"D:\Programme\MKVtoolnix\mkvmerge.exe" -o "e:\\ok\\Test 1x05.mkv" "--priority" "lowest" "--language" "0:jpn" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1280x720" "--language" "1:ger" "--track-name" "1:de DTS" "--default-track" "1:yes" "--forced-track" "1:no" "--language" "2:eng" "--track-name" "2:en AC3" "--default-track" "2:no" "--forced-track" "2:no" "-a" "1,2" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05.mkv" ")" "--language" "0:ger" "--track-name" "0:de" "--default-track" "0:no" "--forced-track" "0:no" "--language" "1:eng" "--track-name" "1:en" "--default-track" "1:no" "--forced-track" "1:no" "-s" "0,1" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05.idx" ")" "--track-order" "0:0,0:1,0:2,1:0,1:1" "--engage" "no_cue_duration" "--engage" "no_cue_relative_position"

2 idx/sub with one language each per mkv:
"D:\Programme\MKVtoolnix\mkvmerge.exe" -o "e:\\ok\\Test 1x05.mkv" "--priority" "lowest" "--language" "0:jpn" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1280x720" "--language" "1:ger" "--track-name" "1:de DTS" "--default-track" "1:yes" "--forced-track" "1:no" "--language" "2:eng" "--track-name" "2:en AC3" "--default-track" "2:no" "--forced-track" "2:no" "-a" "1,2" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05.mkv" ")" "--language" "0:ger" "--track-name" "0:de" "--default-track" "0:no" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05-de.idx" ")" "--language" "0:eng" "--track-name" "0:en" "--default-track" "0:no" "--forced-track" "0:no" "-s" "0" "-D" "-A" "-T" "--no-global-tags" "--no-chapters" "(" "D:\\remux\\Test 1x05-en.idx" ")" "--track-order" "0:0,0:1,0:2,1:0,2:0" "--engage" "no_cue_duration" "--engage" "no_cue_relative_position"

I'm pretty sure I'm not the only one to benefit from this. Thx.

sneaker_ger

26th September 2013, 17:23

I don't really see how you adapted my script (http://forum.doom9.org/showpost.php?p=1642767&postcount=2329). You simply copied the command-line from mkvmerge GUI which is not bad per se but is hard for others to take a look at. It's even harder if you just say "failed" instead of posting the error message.

As I told you in my last PM:
1. all parameters of an input file come directly in front on the input file
2. mkvmerge starts counting at 0. TrackIDs are per input file.
http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html

You are trying to use TrackID 1 with an idx file but unless the idx file has two subtitle tracks (uncommon but possible) you should only be using TrackID 0.

/edit:
corrected idx tracks being able to hold more than 1 subtitle track as per Mosu's correction

Mosu

26th September 2013, 21:28

Minor nitpick : VobSub files can contain arbitrary number of tracks. I have plenty of those here. Otherwise you're correct, of course.

sneaker_ger

26th September 2013, 21:30

I feared somebody might come and say that. But does mkvmerge read more than one track? I never actually tried.

Mosu

26th September 2013, 21:31

Sure it does :-) all of them, unless you tell it not to. Like with all file types it supports.

Chetwood

27th September 2013, 08:25

I don't really see how you adapted my script (http://forum.doom9.org/showpost.php?p=1642767&postcount=2329).
I haven't since I failed miserably at adapting it. Thanks for rubbing it in :(

sneaker_ger

27th September 2013, 11:35

:D

Maybe we start from the beginning so you can get a clear understanding. I'm using the mkvmerge docs (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html) for reference.

This is the general order of an mkvmerge command-line:
mkvmerge [global options] {-o out} [options1] {file1} [[options2] {file2}] [@optionsfile]

We start off with simply muxing an h264 video to an mkv container:
mkvmerge -o output.mkv input.h264

The next exercise would be to mux one h264 video track and one idx/sub subtitle track:
mkvmerge -o output.mkv video.h264 subtitles.idx
As you can see mkvmerge simply adds all files that don't have a "-o" in front of them into the file.

Now we want to define the video language as "English" and the subtitle language as "Dutch":
mkvmerge -o output.mkv --language 0:eng video.h264 --language 0:dut subtitles.idx
Notice how I've used the TrackID "0" for both input files. Lessons learned:
- the input TrackID's apply for each input file on their own.
- the options of an input file go in front of the input file

Since working with raw files is boring we will now try adding an mkv input file that has 3 tracks, with the first track being English, the second track being Finnish and the third track being Japanese. We will also add an idx/sub subtitle that is supposed to be German:
mkvmerge -o output.mkv --language 0:eng --language 1:fin --language 2:jpn input.mkv --language 0:ger subtitles.idx
As you can see we count from 0 to 2 for the input file with three tracks and still only use 0 for the single track after that.

We can do the same, but now with a second subtitle track which we will also mark as "forced":
mkvmerge -o output.mkv --language 0:eng --language 1:fin --language 2:jpn input.mkv --language 0:ger subtitles.idx --language 0:ger --forced-track 0:yes forced_subtitles.idx

Now let's say we also want to use some global options, for example --engage no_cue_relative_position and --clusters-in-meta-seek. We will simply put them into the front:
mkvmerge --engage no_cue_relative_position --clusters-in-meta-seek -o output.mkv --language 0:eng --language 1:fin --language 2:jpn input.mkv --language 0:ger subtitles.idx --language 0:ger --forced-track 0:yes forced_subtitles.idx

Well, that's pretty much it. We just have to be careful sometimes:
1.) If our file names or other descriptions have spaces in them, we have to use quotes around them. For example if we have "forced subtitles.idx" or we want to name the a track "Director's comment":
mkvmerge --engage no_cue_relative_position --clusters-in-meta-seek -o output.mkv --language 0:eng --language 1:fin --language 2:jpn --track-name 2:"Director's comment" input.mkv --language 0:ger subtitles.idx --language 0:ger --forced-track 0:yes "forced subtitles.idx"
2.) Some special characters have to be escaped (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.escaping)
3.) In some cases (numbered VOBs) mkvmerge tries to automatically load several files without asking. We can stop it from doing so if we add a "=" directly before the filename or if we put it in Parentheses with spaces: "(" filename ")", (see the end of chapter 2.5 in the mkvmerge docs)
mkvmerge --engage no_cue_relative_position --clusters-in-meta-seek -o output.mkv --language 0:eng --language 1:fin --language 2:jpn --track-name 2:"Director's comment" ( input.mkv ) --language 0:ger subtitles.idx --language 0:ger --forced-track 0:yes ="forced subtitles.idx"

Chetwood

28th September 2013, 05:55

Thanks for taking the time. I really appreciate it.

Morku

2nd October 2013, 13:18

I have a little noob question.
Whats the difference between the subttles default flag and forced flag? I know forced subtitles are for parts of the movie with a different language in the scene. When I have the forced and complete subtitles in srt, I set the forced subtitles as default track and it will be shown in the media player. What would be the difference, if I use the forced flag?
Thank you very much.

Mosu

2nd October 2013, 13:50

Please read this fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3ADefaultAndForcedFlagsAndDefaultYesNoInMMG) about this very topic.

Chetwood

3rd October 2013, 07:05

@Morku
You might also wanna read this (http://forum.doom9.org/showthread.php?t=167710).

Mosu

3rd October 2013, 07:10

Not really. Too long, got other things to do.

Chetwood

4th October 2013, 05:59

You know I was talking to Morku, right?

Mosu

4th October 2013, 09:21

No, I wasn't. Sorry. When someone says "take a look at..." in this thread they usually mean me. Hence me not reading your post accurately ;)

Chetwood

5th October 2013, 07:05

Which also would explain you not realizing you already had answered (http://forum.doom9.org/showthread.php?p=1625351#post1625351) in the thread I was referring to. No biggy ;)

Still, now that I've read it again, I was wondering if there's any chance in hell that the specs might ever be changed in regards to the flagging of tracks? Cause currently we have the choice between ruining playback on most players and being spec-compliant but can't have both.

I mean, what about a BD with one regular subtitle track, that has 10 or so items flagged as forced? Since the MKV container has to flag the entire track (which then will stay on for the entire length of the movie), the only way for me to watch with forced subs only, is to extract those items to a separate track.

Of course you may have had other priorities when doing the specs, I'm just pointing out that the above example is not uncommon.

Mosu

5th October 2013, 10:08

Well... if someone caring enough about these issues does the work of writing up a proposal with a rationale, sending it to the matroska-devel mailing list, defending it against criticism etc. then there is a chance, yes. However, if you only wait for "the Matroska team" to do the work on its own then the answer is probably "no".

Keep in mind that supporting new flags in the format is a many-edged blade:

From my experience a lot of players out there react badly to elements they don't know about, even if the Matroska specs say that unknown elements must simply be skipped instead of throwing a tantrum. Mostly hardware devices are at fault here, and it doesn't seem to matter which manufacturer it is: I've received reports from Sony, Panasonic, several less-known ones -- with the notable exception of the Popcorn Hour devices from Cloud Media/Syabas! Software players usually get this right, but even VLC has had its problems until I wrote pretty long and detailed but reports venting my frustration about this.
Adding something to the spec is easy. Support in MKVToolNix will most likely follow shortly, but not always and for all elements, especially if adding involved re-arranging a lot of stuff in mmg. Other than me there's simply no developer working on MKVToolNix, and adding new features requires the work on mkvmerge, on mmg, testing, adding a test case, adding the elements in mkvinfo, updating the translations and adding explanations about this to the documentation. It usually takes a couple of hours of work. So you also have to convince me of doing that work :)
When MKVToolNix has support for a feature it doesn't mean other software creating Matroska files or reading them does as well. Tools like ffmpeg are only using a very limited subset of Matroska's features. Other tools like HandBrake make use of more of them and may adopt such features in time, but someone will have to tell those developers about those new features as well.
Even if you do have all those pieces in place you still need support for them in the players and splitters. Again, those developers have to be told about the new features, and they have to be willing to do the work.

Adding stuff to the specs is easy. Making it all work is a lot of effort that's not undertaken lightly.

hubblec4

7th October 2013, 08:21

hi mosu

i found this validator (http://matroska.org/downloads/mkvalidator.html) on the matroskapage.
but when i try to valid a chapter.xml i get this issue message.

***\mkvalidator-win32.v0.4.2>mkvalidator.exe --details chapter.xml
ERR003: EBML head not found! Are you sure it's a matroska/webm file?

the chapter.xml is from your ChapterEditor.

what is the problem of the xml or the validator?

Mosu

7th October 2013, 08:23

mkvvalidator can only validate Matroska files.

Chetwood

9th October 2013, 07:25

Selur

16th October 2013, 09:38

@Mosu: any news regarding newer Mac OS X builds? (current version is 6.2.0, tried to contact Jonathan a while back but didn't get a reply)

Mosu

16th October 2013, 09:39

Neither did I, so no, no news. No new builds until someone else revives Jonathan (metaphorically speaking, I don't know what's up with him) or until someone provides his own builds.

Mosu

20th October 2013, 10:21

Hey,

I've released MKVToolNix 6.5.0. One new feature is present: support for the VP9 video codec (reading it from IVF and Matroska/WebM files, extracting it into IVF files). A German translation of the man pages has been added as well. Several minor bugs have been fixed here and there.

For package maintainers nothing has changed compared to 6.4.1.

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.4.1:

2013-10-19 Moritz Bunkus <moritz@bunkus.org>
* Released v6.5.0.
* mkvmerge: enhancement: filler NALUs will now be removed from framed h.264/AVC tracks (such as the ones read from Matroska/MP4 files) just like they have already been when handling unframed tracks.
* mkvextract: new feature: implemented support for extracting VP9 tracks into IVF files.
* mkvmerge: new feature: implemented support for VP9 read from IVF and Matroska/WebM files. Implements #899 (https://www.bunkus.org/trac/ticket/899).
* mkvextract: enhancement: using the same track/attachment ID multiple times in "tracks", "attachments" or "timecodes_v2" mode will result in an error message instead of one empty file. Implements #914 (https://www.bunkus.org/trac/ticket/914).
* mmg: bug fix: With wxWidgets 2.9.x/3.0.x debug message will no longer appear as modal dialogs but only go to the log window.

2013-10-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed a crash when reading empty global tag files. Fixes #921 (https://www.bunkus.org/trac/ticket/921).

2013-10-17 Moritz Bunkus <moritz@bunkus.org>
* build system: bug fix: fix autodetection of Boost's library path if it is installed in the multiarch directories (e.g. /usr/lib/i386-linux-gnu or /usr/lib/x86_64-linux-gnu).

2013-10-04 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: saved window widths were growing by 1 pixel each time mmg was exited.

2013-10-03 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a German translation of the man pages by Chris Leick (see AUTHORS).

2013-10-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Reading OGM files with chapter entries not encoded in the system's local character set has been fixed. During identification the number of chapter entries is still output by removing any non-ASCII characters from the chapter entries. When muxing an additional warning is output if parsing those chapter entries fails, e.g. due to the format being wrong or due to the charset guessed wrongly. Fixes #919 (https://www.bunkus.org/trac/ticket/919).

2013-09-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The "duration" element was calculated wrong if the first element in the file wasn't the one with the smallest timestamp. To be precise, it was too short by the difference between the first timestamp and the smallest one (e.g with video sequences timestamped 80ms, 0ms, 40ms, 120ms... the duration was 80ms too short).

Have fun.

filler56789

20th October 2013, 10:30

^ Many :thanks:

Selur

20th October 2013, 10:30

Nice!! Any news regarding the support of HEVC?
"support for the VP9 video codec" -> is it now also supported to mux VP9 inside webm?

Mosu

20th October 2013, 10:38

Nice!! Any news regarding the support of HEVC?

HEVC is mostly finished (from the specs perspective), and I plan to work on merging the patches written by DivX within the next couple of weeks.

"support for the VP9 video codec" -> is it now also supported to mux VP9 inside webm?

VP9 is indeed supported for WebM, both as input and output.

Mosu

20th October 2013, 10:43

PS: There were two reasons why I chose to work on VP9 first:

1. It's dead easy to support (from a container point of view). It's format is so simple that muxing it is trivial. There are no B frames (hence no re-ordering of pictures in order to get the time frames right); the frame type distinction is done with a single bit at a fixed position within the very first byte of each frame; the IVF file format is so simple to parse that it's not even funny. Contrasting this with the sheer amount of work required to get h.264 or h.265 makes we weep with joy (or frustration if I think about the work still ahead of me with those formats).
2. It's a free format. That's always worth prioritizing higher.

Selur

20th October 2013, 10:45

Thanks for the info. :)

sneaker_ger

20th October 2013, 10:56

Anyone else getting a strange looking GUI?
http://abload.de/img/mkvmerge650_5kp2y.png

Mosu

20th October 2013, 10:59

It's built with wxWidgets 2.9.5 now, not 2.8.x anymore. Yes, it looks different, but as wxWidgets 3.0.0 is just around the corner (the release candidate 1 is just a week old) you'll have to get used to it. It's that high because the "global" tab requires that much space.

DragonQ

20th October 2013, 11:18

I get the same GUI as sneaker_ger with v6.5.0. There's no track list, so there's no way to edit any of the tracks when you add a file. Reverting to v6.4.1!

Mosu

20th October 2013, 11:21

Woah... you're right, of course. Damn.

Edit: needless to say that this does not happen no Linux. I hate this toolkit… anyway, investigating.

john33

20th October 2013, 12:03

Actually, if you stretch the window to the height of the screen, you do get the track list, not ideal though. ;)

Mosu

20th October 2013, 12:29

I've re-built against the older wxWidgets again. This is the fastest way to get a properly working build out there. I'll fix the issue with the newer wxWidgets for the next release.

The version number remains unchanged, as do the file names. I've updated the check sum lists (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows) for the new builds and uploaded them to FossHub (http://www.fosshub.com/MKVToolNix.html).

Sparktank

20th October 2013, 13:33

Thanks for the fix. GUI has been restored.

filler56789

20th October 2013, 14:22

I've re-built against the older wxWidgets again.

:thanks: ( again :) )

The version number remains unchanged, as do the file names.

Are you sure of that? :confused:

http://www.fosshub.com/download/mkvtoolnix-unicode-6.5.0-1.7z

Mosu

20th October 2013, 14:23

That's the file name, not the version number. I've decided to make the file name different than before in order to make distinction easier. It's also explained here (https://trac.bunkus.org/wiki/KnownIssues).

tObber166

20th October 2013, 15:13

Why doesn't Drag n Drop work with the portable version?

Did not work with 6.4.1 version either.

Mosu

20th October 2013, 15:18

I don't know. The code is exactly the same for both programs; the only difference is the packaging.

Thunderbolt8

21st October 2013, 11:51

2. It's a free format. That's always worth prioritizing higher.isnt H.265 free as well?

Mosu

21st October 2013, 11:56

No. Not in the sense that I consider »free«. At most as in »people may use DEcoders for it without charge for the time being«. At least that's what they did with h.264. But that's not what I mean:

specs available free of charge for any use
encoder/decoder reference implementation free of charge for any use (preferably under an OpenSource license)
no royalties for any kind of use, neither now nor ever
as free of third party patents as possible

The last point is debatable for VP9, of course, but h.26x is much, much more patent-encumbered.

filler56789

21st October 2013, 12:29

Why doesn't Drag n Drop work with the portable version?

Did not work with 6.4.1 version either.

Drag-and-drop does work as expected with version 6.5.0(-1) over here. Perhaps your system just went b0rked somehow? :confused:

tObber166

21st October 2013, 14:02

Drag-and-drop does work as expected with version 6.5.0(-1) over here. Perhaps your system just went b0rked somehow? :confused:

Are you using portable version?

the_weirdo

21st October 2013, 14:11

Are you using portable version?

I'm using portable version and I can drag-n-drop just fine.

tObber166

21st October 2013, 23:27

Find the solution, sorry for the inconvenience

Had the MKVExtractGUI.exe file in the same folder which caused the issue, lol :D
As soon as i remove it, Drag n Drop works :)

To bad the "MKVExtractGUI-2 2.2.2.8" doesn't work anymore

Chetwood

22nd October 2013, 05:53

No drag and drop issues with the portable version (.7z) of 6.5.0 on Win 7 64bit with MKVExtractGUI2.exe (2.2.2.8) in the folder.

tObber166

22nd October 2013, 19:06

Well, dont know what the problem was.
But redownload MKVExtractGUI and now it works :D

/cheers

filler56789

23rd October 2013, 00:12

Just out of curiosity :)

the next release of MKVtoolnix, will it use the CodecID "V_MPEGH/ISO/HEVC" (from the Rovi people), OR will it use "something else" (for example, V_H265 or V_HEVC)?

JEEB

23rd October 2013, 06:56

Just out of curiosity :)

the next release of MKVtoolnix, will it use the CodecID "V_MPEGH/ISO/HEVC" (from the Rovi people), OR will it use "something else" (for example, V_H265 or V_HEVC)?
Both sides seem to have agreed on this (http://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html). The CodecID was proposed originally by Rovi/DivX (although you could hardly call it a surprising turn of events as it just follows the same way Haali set the CodecID for AVC/H.264), but the actual request to follow 14496-15 3rd ed extradata came from matroska-devel (and surprisingly Rovi/DivX actually listened).

Rovi/DivX's documentation on the muxing is much less specific (they updated their side just after that e-mail as well), and thus I recommend people depend on that post as well as the newest version of 14496-15 for the details. After Rovi/DivX posted their version, I did a quick review (http://lists.matroska.org/pipermail/matroska-devel/2013-September/004575.html) on possible differences, and later their HEVC muxing patch was adapted (https://github.com/jaya-divx/mkvtoolnix/commit/c8fca4e19722f74259f61bba758a86a8eb4cfc92) accordingly.

I have not generally reviewed their code yet, but it seems like it does create files that seem to more or less confine within the specification.

filler56789

23rd October 2013, 07:28

^ That's good-news, JEEB :thanks:

Because now, LAV Filters "understand" :) the file
"TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11_AC3_7Subs (1)-003.mkv"
(post #37 in http://dev.mpc-next.ru/index.php/topic,1787.30.html),

even though on 2013/09/07 nevcairiel had written
There is no standard for HEVC in MKV yet, and until there is, LAV will not support it.
And once there is, the DivX MKV files will not be compatible with the standard anyway.

Such a company should not invent their own format, instead coordinate with the Matroska developers. Their old files will in the future most likely not play properly in compliant players.

Mosu

23rd October 2013, 07:46

Yes, it will be V_MPEGH/ISO/HEVC. JEEB has pointed out all the important pieces of information on how the discussion happened. I'm very glad that the Rovi people worked so well with us, but I strongly dislike them using the final CodecID for experimental versions of the format. Unfortunately there is no official recommendation for this from the Matroska side; I chose to append /EXPERIMENTAL for such cases (e.g. A_OPUS/EXPERIMENTAL). Yes I'm part of that team, but not everything I do becomes official automatically ;)

nevcairiel

23rd October 2013, 07:55

even though on 2013/09/07 nevcairiel had written

That was before DivX updated their muxing to the official standard. :p

JEEB

23rd October 2013, 08:35

14496-15 3rd ed and Annex B extradata are both supported with libavcodec, and most matroska demuxers will just throw the extradata and blocks' contents at the decoder. Pretty much same as with AVC/H.264. So yes, the current version of how to mux should be supported.

Because now, LAV Filters "understand" :) the file
"TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11_AC3_7Subs (1)-003.mkv"
(post #37 in http://dev.mpc-next.ru/index.php/topic,1787.30.html),

Meanwhile, this file you linked... Ugh... Open up that matroska file in a hex editor and ctrl+F for 0x63 0xA2 (CodecPrivate structure). One should pop up just after the CodecID. The next byte minus its most significant bit will be the length of this element (as specified per this page (http://matroska.org/technical/specs/index.html), since the most significant bit is set to 1). Now take the CodecPrivate listing I've noted and start going through the data. You should notice that something isn't exactly right quite soon. Although as far as I can see, if you don't really parse the structure and instead just check for the first byte(s) and then jump to the stuff you actually "need" for decoding, it actually ends up looking like nothing is wrong...

configurationVersion is set to 1, which is according to 14496-15 3rd ed (although against the "until 14496-15 3rd ed is released, please set to zero" recommendation), and then if you jump to lengthSizeMinusOne that seems to be 3, which means 4 byte lengths for data in the blocks. This happens to be exactly what DivX's code tended to do at all points.

Then you read the next byte for numOfArrays and you get a zero. Which means that there should be no further data in this structure (you would generally have VPS, SPS and PPS in the extradata). But it's quite obvious there still is data in there, so I'd say this is actually muxed according to the old Rovi/DivX patch, but just happens to work (there are VPS/SPS/PPS in the actual in-band data? Otherwise the stream would actually be impossible to decode). This is an invalid file, unfortunately.

This is what ends up happening when /EXPERIMENTAL isn't used, and different types of muxing not versioned (/EXPERIMENTAL1|2|3 or whatever).

Boulder

23rd October 2013, 18:17

Wavpack files encoded with the option "--optimize-mono" are not recognized by mkvmerge. The error message is "The file header was not read correctly."

Mosu

23rd October 2013, 18:21

Wavpack doesn't really have any priority for me. Sorry. See also this issue with Wavpack (https://trac.bunkus.org/ticket/859) that will likely not get fixed.

If you want any chance of me fixing this then please open a new ticket in my bug tracker (https://trac.bunkus.org/) and upload a sample file to my FTP server (see signature). I may get bored and take a look at it some time.

vmrsss

24th October 2013, 09:47

Hi Mosu, is mkvtoolnix expected to build with clang? Up to 6.4.1 I was able to build on a mac using a self-complied gcc-4.6.2, now the build of 6.5.0 fails because of linking problems (I suspect due to mismatch with libraries built with clang). Then I gave mkvtoolnix a go with clang Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn), and get the following error, which looks pretty fatal! Any comments? Thanks.

In file included from src/common/command_line.cpp:14:
In file included from src/common/common_pch.h:4:
In file included from src/common/common.h:29:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/vector:1825:21: fatal error:
object of type 'boost::filter_iterator<<lambda at
src/common/command_line.cpp:295:74>,
boost::transform_iterator<boost::range_detail::select_first<std::__1::map<std::__1::basic_string<char>,
std::__1::basic_string<char>, std::__1::less<std::__1::basic_string<char> >,
std::__1::allocator<std::__1::pair<const std::__1::basic_string<char>,
std::__1::basic_string<char> > > > >,
std::__1::__map_const_iterator<std::__1::__tree_const_iterator<std::__1::pair<std::__1::basic_string<char>,
std::__1::basic_string<char> >, const
std::__1::__tree_node<std::__1::pair<std::__1::basic_string<char>,
std::__1::basic_string<char> >, void *> *, long> >, boost::use_default,
boost::use_default> >' cannot be assigned because its copy assignment
operator is implicitly deleted
__m = __first;

Mosu

24th October 2013, 10:25

I'm developing solely with clang, so yes, it does work. At least on Linux. I'm also running a continuous-integration server that builds each and every commit with clang, gcc and my mingw cross compilers.

I cannot help you with Mac OS build problems, especially not with libraries compiled with different compilers. Sorry.

vmrsss

24th October 2013, 18:24

Thanks Mosu, so have you got no idea on what the cause of the error " __m = __first;" might be? Then, I hope in some Mac user reading this post.

Thunderbolt8

27th October 2013, 17:14

does drag & drop not work anymore with windows 8.1? when I try to drag input files from explorer into mkvmerge, I only get this forbidden/not possible symbol.

Mosu

27th October 2013, 17:17

Just as possible as before. Just don't start the program with administrative privileges and drag from an application started without admin privileges.

Thunderbolt8

27th October 2013, 23:57

well that was it, thanks.

Sakura-chan

28th October 2013, 06:21

I just need to ask this thing. Why releases have names? Like "Omega Point" for 6.4.1 and "Isn't she lovely" for 6.5.0. Who comes up with those? Mosu? Any reason and/or logic behind the names? Or just something random that comes to mind when releasing a new version? I've seen names for other things. Ubuntu has adjective + animal, both starting with the same letter going in alphabetical order or something like that. But for mkvtoolnix it seems too random.

Anyway, I like names. Gives each release a bit more love and personality <3. Like installing a new version and discovering what the name is. I know, I'm probably stupid :P

Mosu

28th October 2013, 09:08

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

szabi

8th November 2013, 15:18

Hi

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

bye

Mosu

8th November 2013, 15:51

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

szabi

8th November 2013, 15:58

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

Guest

8th November 2013, 16:18

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

12th November 2013, 09:46

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

15th November 2013, 15:49

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

Selur

15th November 2013, 16:28

@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

15th November 2013, 16:30

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

Selur

15th November 2013, 16:32

Seems like cuvid is more 'flexible' then :)

nevcairiel

15th November 2013, 16:35

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

24th November 2013, 21:27

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

26th November 2013, 16:44

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

26th November 2013, 18:40

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

Gruko

27th November 2013, 15:04

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

Thanks Mosu for your software.

Mosu

27th November 2013, 19:04

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

sneaker_ger

27th November 2013, 20:28

What about using the patch from DivX?

Mosu

27th November 2013, 20:36

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

28th November 2013, 10:58

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

28th November 2013, 14:46

There are no facilities for creating chapter entries automatically.

Thanks for pointing out the typo.

Caroliano

30th November 2013, 04:17

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

30th November 2013, 11:13

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

Mosu

30th November 2013, 12:01

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

[ReX]

30th November 2013, 13:38

Caroliano

30th November 2013, 20:07

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

1st December 2013, 20:41

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

2nd December 2013, 01:38

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

3rd December 2013, 04:51

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

3rd December 2013, 04:54

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

Mosu

3rd December 2013, 08:37

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

3rd December 2013, 16:19

this is normal?

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

cut text

build last git with WxGTK/Widgets 3.0 in linux

greetings

Mosu

3rd December 2013, 16:21

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

3rd December 2013, 16:24

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

3rd December 2013, 18:48

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

hubblec4

3rd December 2013, 20:17

hi mosu

in the attached xml file is a ChapterProcess:

<ChapterProcess>
<ChapterProcessCodecID>0</ChapterProcessCodecID>


<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

3rd December 2013, 20:28

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

14th December 2013, 23:52

will support for embedding TAK files come to mkvtoolnix?

Mosu

15th December 2013, 09:55

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

16th December 2013, 03:08

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

31st December 2013, 03:07

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

31st December 2013, 08:11

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

31st December 2013, 10:42

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

2nd January 2014, 22:27

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

3rd January 2014, 15:10

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

3rd January 2014, 16:44

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

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

Rodger

4th January 2014, 12:53

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

Mosu

5th January 2014, 13:29

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

5th January 2014, 13:32

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

5th January 2014, 16:26

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

5th January 2014, 16:56

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

Mosu

8th January 2014, 22:34

Hey,

I've release v6.7.0 of MKVToolNix. It contains tons of bug fixes all over the place, but also a couple of enhancements. The most important bug fix is probably the change to how MPLS files are handled (see below).

This is the first release for which I'm providing 64bit binaries for Windows as well. They offer the same functionality as the 32bit binaries. Versions can be distinguished in their version number output as well as mmg's »about« dialog.

Please note that the Windows installer and portable archive do not contain the word »Unicode« anymore. That's not because they don't support Unicode; they do. It's just that the last release without Unicode support was v2.something quite a lot of years ago, and there's simply no reason to point out the Unicode-awareness anymore.

There's one change for package maintainers: Ruby 1.9.x is now required for building. I don't support 1.8.x anymore. This should not be a problem for current distributions anyway.

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.6.0:

2014-01-08 Moritz Bunkus <moritz@bunkus.org>
* Released v6.7.0.
* build system: Ruby 1.9.x is now required.

2014-01-05 Moritz Bunkus <moritz@bunkus.org>
* all: enhancement: The architecture (32bit/64bit) is mentioned in the version information of all programs.

2014-01-02 Moritz Bunkus <moritz@bunkus.org>
* build system: bug fix for 64bit builds on Windows (x86_64-w64-mingw32): use the correct processor architecture via separate Windows manifest files. Fixes mmg and mkvinfo not starting due to »error 0x0000007b«.
* mkvmerge: bug fix: Fixed a potential endless loop due to an integer overflow in the code removing AVC/h.264 filler NALUs.

2014-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading uncompressed PCM audio tracks from QuickTime/MP4 files in certain situations. Fixes #950 (https://www.bunkus.org/trac/ticket/950).
* mmg: enhancement: Made the »scanned files« list box sortable by all columns. Fixes #954 (https://www.bunkus.org/trac/ticket/954).

2013-12-31 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The »additional parts« dialog will now show the files that make up an MPLS playlist. This is for informational purposes only and doesn't allow changing the playlist itself.
* mkvmerge: bug fix: Reading from an MPLS playlist file is now done as if the second and following files referenced in that playlist had been appended to the first file from that playlist. Before they were treated as if they were additional parts. Fixes #934 (https://www.bunkus.org/trac/ticket/934).
* mmg: enhancement: a couple of fixes to tooltips: 1. Content correction for »splitting by chapters«; 2. no ugly re-formatting with wxWidgets 3.0.0 on Windows.

2013-12-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Improved the AAC, AC3 and MP3 header decoding error handling so that the corresponding parsing routines won't get stuck in endless loops when encountering certain garbage data patterns.

2013-12-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: unified codec names output by mkvmerge's identification mode for all file format readers.
* mkvinfo: bug fix: when setting the language with --ui-language a few strings were still translated using the system's default language.
* mkvextract: bug fix: if the track headers were located at the end of the file (e.g. after modification with mkvpropedit or mmg's header editor) then mkvextract was writing files with a length 0 bytes.
* mmg: bug fix: the »playlist items« list box in the »select playlist file to add« dialog was showing the items in reversed order. Fixes #952 (https://www.bunkus.org/trac/ticket/952).

2013-12-28 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: the »select playlist file to add« dialog can now be resized, minimized and maximized. It also remembers its position and size during runs. Fixes #951 (https://www.bunkus.org/trac/ticket/951).

2013-12-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The user can select the default subtitle character set to use for newly added subtitle tracks in the preferences dialog as requested in bug #948 (https://www.bunkus.org/trac/ticket/948).

2013-12-24 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: fixed the tooltip for the subtitle character set drop-down box to match mkvmerge's actual behavior. Fixes #948 (https://www.bunkus.org/trac/ticket/948).

2013-12-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: implemented reading DTS audio tracks from MP4 files (with ESDS object type ID == 0xA9 (decimal 169) or FourCC == 'DTS ' or 'dtsc').

2013-12-18 Ralph Giles <giles@mozilla.com>
* mkvmerge: enhancement: allowed muxing Opus to WebM files.
* mkvmerge: bug fix: Fixed the mapping of the Opus element »seek pre-roll« and »pre-skip« to the Matroska elements »track seek pre-roll« and »codec delay«. Remuxing Matroska files without Opus created with earlier versions of MKVToolNix is enough to fix such a file.

2013-12-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixing the bitstream timing information of h.264/AVC writes clean values for 25000/1001 frames per second video (e.g. de-telecined PAL @ 29.97).

2013-12-07 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: fixed a crash in during drag & drop operations in mmg's chapter editor.

Have fun.

sneaker_ger

8th January 2014, 23:01

Remuxing Matroska files without Opus created with earlier versions of MKVToolNix is enough to fix such a file.
Without or with?

Mosu

8th January 2014, 23:27

»With«, of course.

nautilus7

9th January 2014, 00:39

Hi, thanks for the update.

Shouldn't the 64bit version install to "Program Files" folder instead of "Program Files (x86)" by default?

Chumbo

9th January 2014, 04:23

Thanks Mosu.

Overdrive80

9th January 2014, 04:46

Hi, thanks for the update.

Shouldn't the 64bit version install to "Program Files" folder instead of "Program Files (x86)" by default?

Yes, I think the same.

Mosu

9th January 2014, 08:56

Hi, thanks for the update.

Shouldn't the 64bit version install to "Program Files" folder instead of "Program Files (x86)" by default?

Yes. That will be fixed for the next release.

fryk

9th January 2014, 19:36

I use mkvtoolnix 6.7.0 64bit in Win 8.0 x64

All works fine but I cannot start mmg. Error message is:

http://img716.imageshack.us/img716/2299/0c0v.png

Mosu

9th January 2014, 19:37

Does the 32bit version work for you? How soon does this message occur (do you ever see the GUI pop up or not)?

fryk

9th January 2014, 20:14

The 32bit version works. And no, I can't see the GUI window, the error msg box comes immediately.

PS: Issue is solved. I use the portable version and have to add myself to the mkvtoolnix program folders permissions. Even if I "installed" the program files (made the folder and copied the files). This wasn't necessary ever before, sorry.

Mosu

9th January 2014, 20:56

Please do the following:

Download and install this build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-amd64-6.7.0-build20140109-571-4768784-setup.exe) with debugging options
Start mmg. It will likely fail in the same way.
Navigate to the folder C:\Users\YourUserName\AppData\Local\Temp
Locate the file mkvtoolnix-debug.log and send it to me to moritz@bunkus.org; we'll do the rest by email

Snowknight26

9th January 2014, 21:34

Is having zlib compression enabled for PGS streams supposed to remove the forced flag on individual subtitles?

Mosu

9th January 2014, 21:35

zlib is lossless compression algorithm. It doesn't modify the PGS stream at all.

Snowknight26

9th January 2014, 21:48

zlib is lossless compression algorithm. It doesn't modify the PGS stream at all.

Figured as much. Had to rule mkvmerge out as both eac3to and LAV Splitter have issues with this particular PGS stream.

Selur

9th January 2014, 23:25

Thanks for the update, any news regarding H.265 support?

Chumbo

10th January 2014, 01:57

I use mkvtoolnix 6.7.0 64bit in Win 8.0 x64

All works fine but I cannot start mmg. Error message is:

http://img716.imageshack.us/img716/2299/0c0v.png
Does the 32bit version work for you? How soon does this message occur (do you ever see the GUI pop up or not)?
I'm running Windows 8.1 Pro 64bit and have no problems with the 64bit version. I do install to a custom location, i.e., outside of the standard Program Files, but I uninstalled it and reinstalled to default location and it also worked fine. If the log doesn't shed any light, try [fryk] using SysInternals' Process Monitor to see what gets flagged when mmg is loading.

[EDIT] @fryk, you can also check the application log in the event viewer which may provide Mosu with some helpful info.

Mosu

10th January 2014, 08:54

fryk told me in an email that he had some permission problem on his end resulting in said error. The 64bit version is working just fine for him now, too.

Mosu

10th January 2014, 08:56

Thanks for the update, any news regarding H.265 support?

I've actually started work on that before the 6.7.0 release. The commits by DivX/Rovi have been merged and updated to compile with the latest code. The next steps are actually testing that it (still) works, creating tests, documentation and source code cleanups. My current plan is to have this in for the next minor release, 6.8.0.

smok3

10th January 2014, 09:35

Thanks, small request;
"options/mmg/Check online for the latest release"
should be disabled by default (at least in Debian edition) for two reasons;
a. The way repos work makes it unnecessary
b. Software calling home would/could be considered unsafe/buggy (imho)

Mosu

10th January 2014, 09:50

I disagree.

Debian's (and Ubuntu's) official releases are always notoriously out of date. So it does make sens, even for repository-based installations. If you're using my own repo then that is mitigated, but I still don't care enough to actually invest any work into it.

Second, I would consider »calling home« to be something to be concerned about if there was actually any transfer of information from your computer to my server. As it is implemented the application only does a simple HTTP GET request for a single XML file without any additional parameters/HTTP headers/customization[1] (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/version.cpp). The URL is always http://mkvtoolnix-releases.bunkus.org/latest-release.xml[2] (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/version.h).

If you feel strongly about these points then you have several options:

Compile your own package and disable the curl support completely (add »--without-curl« to configure). That way none of the programs does have any internet access. It's easy (http://www.bunkus.org/videotools/mkvtoolnix/source.html#debian_ubuntu_package).
Disable that setting in mmg's preferences. mmg is the only one that does this check on its own. All other applications require a parameter to be passed to them before they'll execute said check.
File a bug report at Debian. There's one already for Ubuntu (https://bugs.launchpad.net/ubuntu/+source/mkvtoolnix/+bug/1014229) already, but it doesn't seem like they care that much either.
Don't use mmg at all.

smok3

10th January 2014, 09:59

Thank you for your consideration & no I don't feel strongly about that, just a suggestion.

[ReX]

11th January 2014, 02:08

Mosu, is the translated "File" string meant to be shown with "mkvmerge --identify-verbose"?
For me, it shows "Ficheiro" (pt-PT) in Windows (pt-BR).

Edit: it also shows "contentor" instead of "container".

Edit 2: Also, did you forget about "A_REAL/*" in codec.cpp?

Edit 99999: VP9 is duplicated in codec.cpp.

Mosu

11th January 2014, 09:26

The output of »--identify-verbose« is supposed to be translated, yes. You have two options:

Use the undocumented option »--identify-for-mmg« instead of »--identify-verbose« which results in untranslated identification output but translated error messages
Use the documented option »--ui-language en« along with »--identify-verbose«

I did indeed forget about A_REAL/* – as in »I thought about them, put them on hold while I still had other issues to sort out with codec_c, and promptly forgot about them again« :)

Thanks for pointing it out (the VP9 duplication, too).

Stereodude

11th January 2014, 15:39

What's the main difference between "append" and "additional parts" when I have multiple sequential .264 files (encoded with --stitchable) that I want to put into a mkv container as if they were one continuous file. The mkv seems to play fine when I try it either way, but which method is the right one to use?

Mosu

11th January 2014, 15:47

For raw .264 both methods should be equivalent. Same for most other raw formats that can only contain a single track, that don't have global file headers and that do not have timestamps (raw AAC, AC3, MP3, MPEG-1/2 ES).

For formats in which each has their own headers (AVI, MP4, Matroska, FLAC, TTA, Ogg, IVF…) or in which multiple tracks can occur (MPEG TS…) appending is the appropriate choice.

The only place where »additional parts« is the appropriate choice and »append« would be wrong is where a file has been cut into multiple files at an arbitrary position. This is the case for VOBs on DVDs. Think of having one giant 4 GB VOB file that's been treated with WinSplit (or the Linux equivalent »split«).

However, if you want to append VOBs from multiple sources (from two different DVDs) then »append« may be the appropriate choice. So you cannot say »always use additional parts for VOBs« either.

The worst part is that you cannot really autodetect it reliably (not even close). For DVD-like named files mmg/mkvmerge does it, but that's about the only place. Heck, I even got it wrong for Blu-rays and just fixed it in 6.7.0 (see the change regarding how MPLS files are treated).

Summary: If in doubt use »append«.

Stereodude

11th January 2014, 18:50

Thanks for the quick and detailed explanation.

Snowknight26

11th January 2014, 18:52

Just out of curiosity, any reason you're using strange angle quotation marks?

Mosu

11th January 2014, 19:01

They're called Guillemets (http://en.wikipedia.org/wiki/Guillemet), and I'm German.

[ReX]

12th January 2014, 01:20

Use the undocumented option »--identify-for-mmg« instead of »--identify-verbose« which results in untranslated identification output but translated error messages

I knew there was a switch that wasn't supposed to be translated, but I was mistakenly remembering it as "--identify-verbose".
Thanks for the answer. You probably answered this same silly question several times, sorry about that.

Brother John

12th January 2014, 11:23

The next steps are actually testing that it [HEVC] (still) works, creating tests, documentation and source code cleanups. My current plan is to have this in for the next minor release, 6.8.0.
Is there a way already to experiment with HEVC muxing? The 583-559b275 Windows pre build doesn’t recognise an x265 HEVC elementary stream as a valid file type and I couldn’t find any HEVC/H.265 references in the Github commit messages. (I might be completely blind though, it’s happened before. ;))

mikeyakame

12th January 2014, 11:26

I just noticed today that I was getting the following output from mkvmerge 6.7.0 (x64 windows build)

mtx ex: Unknown error (type: N3mtx5mm_io13end_of_file_xE)

and

mtx ex: No error (type: N3mtx5mm_io13end_of_file_xE)

These warnings/output seem to be harmless as the exit value is 0 and the resulting mux seems to be fine.
It only appears to output this when remuxing matroska files.

Should I be concerned about them at all?

Mosu

12th January 2014, 11:28

Is there a way already to experiment with HEVC muxing? The 583-559b275 Windows pre build doesn’t recognise an x265 HEVC elementary stream as a valid file type and I couldn’t find any HEVC/H.265 references in the Github commit messages. (I might be completely blind though, it’s happened before. ;))

Not with my mkvmerge. The development's happening in a different branch from which the releases aren't built.

Mosu

12th January 2014, 11:30

I just noticed today that I was getting the following output from mkvmerge 6.7.0 (x64 windows build)

mtx ex: Unknown error (type: N3mtx5mm_io13end_of_file_xE)

Known issue due to a compiler bug. See https://trac.bunkus.org/wiki/Troubleshooting for details.

Anakunda

13th January 2014, 14:39

HI!!
I'd have some question about occasional spontaneous applying of positive delay for audio tracks. I noticed that (only sometimes) media info reports effective audio delay present on audio track even if I use none user value for muxing (empty delay field). Regardless if I use GUI or console. Reported as
Delay relative to video : 24ms
or similar. For this I'd be thankful to know when and why is mkvmerge using implicit delay and from what the value which looks to me like completely random it's derived (P.S. the respective audio tracks filenames contain no time or delay expression).

sneaker_ger

13th January 2014, 14:43

This can happen if the source container signals a delay. Because mkvmerge deletes frames before zero both negative and positive delays in the source container can result in a positive delay (i.e. first time code >0) in the output mkv file. Are your source files by chance mp4 containers with aac audio? Common aac encoders signal their encoding delay by writing certain tags and mkvmerge reads and applies them automatically.

Mosu

13th January 2014, 14:47

First off read https://trac.bunkus.org/wiki/FAQ%3ADelayNotShownInMmg. It touches on this subject and is rather important to understand.

Now. mkvmerge does not apply arbitrary delays. It does, however, try to keep the timestamps of all packets. MP4 files, for example, can have the audio start later than the video (or the other way around), and mkvmerge simply these relative offsets but shifts them down to 0.

Let's take a notional MP4 file with three tracks: one video, two audio. Let's assume that you only copy audio track 2, not audio track 1. Let's further assume that the smallest timestamp of the video packets is 12ms, the smallest timestamp in audio track 1 is 0ms and the smallest timestamp in audio track 2 is 40ms. When you mux this into a Matroska file then mkvmerge will take the minimum of all the timestamps read from the tracks of this file (this would be either 12ms from the video track or 40ms from audio track 2 – audio track 1 is not muxed and therefore disregarded; ergo the minimum is 12ms) and subtract it from all timestamps in that source file (this is the shift to 0).

So in the output file the smallest video timestamp will be 12ms - 12ms, and the smallest audio timestamp will be 40ms - 12ms = 28ms.

And that's what MediaInfo will show you: audio starts 28ms after the video starts.

Edit: sneaker_ger's right. In addition to the normal timestamps in an MP4 file mkvmerge also applies the encoder delay stored in the MP4 file headers to those timestamps.

Anakunda

13th January 2014, 14:47

Just that no because the used tracks are always either AAC (in m4a) or AC3. But it's susrprising that the AAC file can signal any delay if it's converted with no delay flags (--no-delay)

edit: okay Mosu's reply seems to clear things up

jkauff

13th January 2014, 20:16

I'm having a problem with 6.7.0 64-bit on Windows 8.1 64-bit. Files load OK, but muxing immediately produces a return code of 3. Same files work perfectly on 6.6.0.

Anyone else experiencing this?

Mosu

13th January 2014, 20:16

See https://trac.bunkus.org/wiki/Troubleshooting; it's a known & fixed problem.

Caroliano

15th January 2014, 03:53

I finally discovered the source of the problem I was having since I moved to windows 8.1: http://forum.doom9.org/showthread.php?p=1655957#post1655957

How to reproduce:
- Create a new windows user named "Cloé".
- Try running mmg from that user (you may download a portable version to make it easier)
- Nothing happens.
- Now create a new user named "Mike" and log in with him, mmg will work.

Even if you use the "rename user" option for "Cloé", mmg will refuse to work, probably because the "C:\Users\" folder will still be named "Cloé", and there is no safe way to change it. So, please fix this bug. This is the only program where I had this kind of problem (thankfully!).

Mosu

15th January 2014, 14:18

Cannot reproduce:

http://www.bunkus.org/misc/mmg-670-win81-chlo%C3%A9.png

Edit: changed IMG tag to normal URL as the screenshot is rather large.

Caroliano

15th January 2014, 22:40

Strange. I can consistently reproduce the working/non-working of mmg just by switching between the two new fresh windows users I created (one accentuated and one non-accentuated name being the only thing differing between them).

By the way, in version 6.7.0 it now gives this error screen on both 64 bit and 32bit portable versions, and the debug version that you posted two pages ago. (http://forum.doom9.org/showthread.php?p=1661325#post1661325) I will use the same image link as the previous user that got this window:
http://img716.imageshack.us/img716/2299/0c0v.png

Here the contents of the mkvtoolnix-debug.log:
2014-01-15 19:34:24 +0ms Current file & line: src/mmg/mmg.cpp:331
2014-01-15 19:34:24 +1ms Current file & line: src/mmg/mmg.cpp:333
2014-01-15 19:34:24 +2ms Current file & line: src/mmg/mmg.cpp:335
2014-01-15 19:34:24 +5ms Current file & line: src/mmg/mmg.cpp:205
2014-01-15 19:34:24 +12ms Current file & line: src/mmg/mmg.cpp:210
2014-01-15 19:34:24 +13ms Current file & line: src/mmg/mmg.cpp:217
2014-01-15 19:34:25 +1244ms Current file & line: src/mmg/mmg.cpp:337

Mosu

15th January 2014, 22:52

Already fixed. Read https://trac.bunkus.org/wiki/Troubleshooting.

About the issue with mmg not starting: no idea what's wrong, and without being able to reproduce it I don't stand a chance of debugging it - not to mention fixing it.

Caroliano

15th January 2014, 23:17

I tried the builds linked at that troubleshooting link and still get the same "***Caught unhandled unknown exception; terminating" error on both 32 and 64bit, portable and installer. There is no new debuging build that can see where it hangs on my computer, because I can reproduce here.

Mosu

16th January 2014, 09:23

I somewhat doubt that you're really executing the correct mkvmerge.exe executable and not some older version. I cannot reproduce the exceptions with either of the four builds linked in the troubleshooting article on my Windows 8.1. With the release builds I was able to reproduce them quickly and deterministically.

Anyway. Things I cannot reproduce remain impossible to diagnose, so I'm sorry but I cannot help you at the moment.

shinchiro

16th January 2014, 15:20

I tried remove some font attachment using with mkvpropedit. The fonts had been removed but the size still no reduced. Is it normal? I need remux the file again to see the size decrease..

Mosu

16th January 2014, 15:24

Yes, that is normal. Attachments don't have to be stored at the very end of the file. Instead they can be stored anywhere within it. mkvmerge stored them after the track headers before the first cluster. mkvpropedit will only overwrite them with an EbmlVoid element if they're not located at the end.

shinchiro

16th January 2014, 17:04

I see. Thanks for the clarification

DragonQ

17th January 2014, 20:19

I've finally gotten around to archiving some TV recordings (1080i/25 AVC) from the past couple of months after being lax about it. However, every single MKV file that I've made so far has dodgy timestamps and thus doesn't play back correctly in many places (MadVR shows frame drops, EVR shows graph oddities). I've tried changing everything I can think of to find where the problem lies:

- Happens with both MadVR and EVR in MPC-HC
- Happens with both MPC-HC and MediaPortal
- Happens with LAV Filters 0.60.1 and 0.58.2
- Happens using DXVA2 Native and ffmpeg decoding
- Happens using both MKVToolNix 6.0.0 and MKVToolNix 6.7.0
- Happens when muxing the original TS file as well as the cut TS file created by TS-Doctor

The original TS files play back perfectly whether cut or not. Can anyone identify what the problem might be? I can't imagine the broadcast stream format has changed over the last couple of months since that'd probably break lots of hardware out there.

Here's a sample: TS file (http://www.aotplaza.com/Files/HTPC/Samples/MKV%20Dodgy%20Timestamps%20Sample.ts) | Dodgy MKV file (http://www.aotplaza.com/Files/HTPC/Samples/MKV%20Dodgy%20Timestamps%20Sample.mkv)

Simon88

17th January 2014, 22:54

DragonQ

17th January 2014, 23:52

@DragonQ: You might try VLC 2.1.2 or K-Lite Mega those two has worked great for me on problematic streams. For cutting of *.ts stream, Avidemux 2.6.7 works great for me as the MKV produced by it is fine, BUT I re-mux again using latest MKVTools, "just in case"..
Thanks for the suggestions but VLC does not play the MKV files correctly either (same issue: timestamps incorrect in places). TS-Doctor is surely not the problem as the issue happens with uncut files too. In any case, AVIDemux insta-crashes when I install it on Windows 8.1 x64.

Simon88

18th January 2014, 01:15

Thanks for the suggestions but VLC does not play the MKV files correctly either (same issue: timestamps incorrect in places). TS-Doctor is surely not the problem as the issue happens with uncut files too. In any case, AVIDemux insta-crashes when I install it on Windows 8.1 x64.

I'm using Win7 x64 and tested it on your file and it worked fine. Did you update to latest Avidemux v2.67?...

You can also process the files via commandline using latest ffmpeg or libav...

DragonQ

18th January 2014, 01:56

I'm using Win7 x64 and tested it on your file and it worked fine. Did you update to latest Avidemux v2.67?...

You can also process the files via commandline using latest ffmpeg or libav...
Never used AVIDemux before so yes I installed the latest v2.67. What do you mean "process the files"? All I want to do is mux them to MKV.

EDIT: If I use the following command on the sample TS file:

ffmpeg -i test.ts -c copy -map 0 test.mkv

I get these errors:

http://www.aotplaza.com/Files/HTPC/Samples/MKV%20Dodgy%20Timestamps%20ffmpeg.png

Simon88

18th January 2014, 02:26

@DragonQ: I usually just use Avidemux and snip the ends and then sometimes simply extract the main video and audio streams using ffmpeg, the reason is *.ts files can contain alot of "junk/filler" streams that just waste space. When all else fails I use VideoRedo TV Suite which has an excellent stream fixer and GOP slicer that I used in the old MPEG-1/2 days... but it is a commercial program and can fix many uncooperative files, including newer H.264/AAC/AC-3 files. You may give it a try, they have a trial version, but I recommend testing all new software in a virtual machine, as I use to always have to restore my system from an image backup when I start testing ALOT of trialware and some will screw everything up... I usually use/love ffmpeg as I can batch process a hundred files in a few hours without user intervention....

73ChargerFan

19th January 2014, 01:32

I've finally gotten around to archiving some TV recordings (1080i/25 AVC) from the past couple of months after being lax about it.
Had you done this months ago with an older version of mkvtoolnix? Do you think your problems because you updated it? Or is this the first time you've tried this?

If you think it might be the muxing, you might try the mkv muxer by Haali. I prefer mmg, but when I run into weird streams I try another muxer to see if it's the software or the video.

73ChargerFan

19th January 2014, 02:14

My C drive has only 20gb free. I just installed mkvtoolnix 6.7.0 64bit and it now muxes to my system drive instead of the target drive.

How can I disable this? v6.6.0 didn't do that. Took my half an hour to fix my computer after it completely filled my drive. I don't see anything in Options. It stored the file in:
C:\Program Files (x86)\MKVToolNix\j

Mosu

19th January 2014, 08:37

mkvmerge writes to where you tell it to write; in mmg you set this via the output file name. That output file name is suggested automatically by mmg based on the settings of the default output directory in the preferences.

I've just re-tested with 6.7.0 64bit and it writes exactly where I tell it to, be it a second hard drive, a USB flash drive or a connected network share.

DragonQ

19th January 2014, 13:37

Had you done this months ago with an older version of mkvtoolnix? Do you think your problems because you updated it? Or is this the first time you've tried this?
I updated when it said there was an update. As I said above this happens with v6.0.0 too so if a change broke things it must've happened a while back.

If you think it might be the muxing, you might try the mkv muxer by Haali. I prefer mmg, but when I run into weird streams I try another muxer to see if it's the software or the video.
Thanks for the tip, I just tried muxing it with Haali's MKV Muxer (dsmux.x64.exe) and the resulting MKV plays perfectly! It must be a bug with how MKVToolnix handles these TS files then. Can you look into this please Mosu using the sample I provided above?

Mosu

19th January 2014, 13:39

Not in the next two or three weeks; I currently have other priorities, sorry.

73ChargerFan

19th January 2014, 19:13

My bad. I tried to target the j:\ drive but missed the colon, so instead it targeted a subdirectory j in the program directory. The cascade of computer errors and the fact that I had just installed the new version led me to think it was a temporary location. Sorry.

shinchiro

23rd January 2014, 10:09

How could I make mkvmerge show attachment's name in japanese or chinese when using -i option?

Mosu

23rd January 2014, 10:15

My guess is that you're referring to the fact that the output of Unicode characters on Windows' cmd.exe is buggy. That's handled (and fixed) in ticket 971 (https://trac.bunkus.org/ticket/971). You have two options:

Download and use the new build mentioned in that ticket.
Redirect mkvmerge's output to a text file with the following two options: --redirect-output output.txt --output-charset UTF-8

Option 2 has the advantage of working with versions going back years.

cihub

23rd January 2014, 11:09

I'm not sure whether this question have been asked previously, but how do you leave info about "Bits/(Pixel*Frame)" in Matroska after remuxing (MKVToolNix 6.5.0, 6.7.0)? When I mux H.264 from x264 and add AAC-HE, it gets stripped, but when I mux only video, or AC3, it stays there.

Mosu

23rd January 2014, 11:14

You cannot. There's no header information for this.

What you see is MediaInfo estimating the bitrate based on the track size. However, MediaInfo can only do that if there's only a single track inside that file because in Matroska there's no header info about the track size either.

Therefore: Only one track -> MediaInfo uses the file size as an approximation for the track size -> MediaInfo calculates estimated bitrate based on the file's duration and the file's size.

cihub

23rd January 2014, 12:51

Thank you for explanation, Mosu.

shinchiro

23rd January 2014, 19:09

Sakura-chan

24th January 2014, 07:12

Hi

Is there some sort of compression in Matroska for MPEG2 streams?

I've seen this happen with certain discs. The story goes like this. I have a DVD, 6.37 GB in size. I use MakeMKV on the main feature, the resulting MKV is 5.18 GB. It has an MPEG2 and an AC3 track. Then, because I want to add English subs, I remux that MKV and the subs with mkvtoolnix v6.6.0. But now the resulting MKV is only 3.93 GB.

What is going on? The bitrate of the movie is decreased, but everything is there. mkvmerge doesn't re-encode anything. I guess there must be some compression going on. But how can it be so strong to cut 1.25 GB of the MPEG2 track? Is there some kind of "garbage" or useless data in the frames of the MPEG2 stream?

Why MakeMKV's resulting file has a "logical" filesize given the source and mkvmerge remux is a lot smaller?

Extracting the MPEG2 tracks from both big and small MKVs results in .mpg files with sizes according to the original MKVs. So the stream doesn't go back to the original size. mkvmerge simple discards something in the mux.

This doesn't happen always. Or probably I haven't noticed before because I didn't stop to check the sizes of the MKVs. For now I've seen this with 3 PAL DVDs (French editions of Hideo Gosha's films). I made MKVs of other DVDs and didn't observe this drastic size reduction, just a little as always when making MKVs from DVDs.

Here's the info of the video tracks of both MKVs.

Original:

Video #1
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : No
Format settings, Matrix : Custom
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 1h 32mn
Bit rate mode : Variable
Bit rate : 7 703 Kbps
Maximum bit rate : 8 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.743
Time code of first frame : 10:00:00:00
Time code source : Group of pictures header
Stream size : 4.96 GiB (96%)
Language : English
Default : No
Forced : No

Remuxed:

Video #1
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : No
Format settings, Matrix : Custom
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 1h 32mn
Bit rate mode : Variable
Bit rate : 5 808 Kbps
Maximum bit rate : 8 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.560
Time code of first frame : 10:00:00:00
Time code source : Group of pictures header
Stream size : 3.74 GiB (95%)
Default : Yes
Forced : No

All in all, another great reason to store/backup movies in MKV, that's a nice (and lossless) file size cut :P

Mangix

24th January 2014, 08:46

I believe avi files are broken with mmg 64-bit under windows. I switched to the 32-bit version and could remux an avi file without running into error code 3.

Mosu

24th January 2014, 09:16

Thanks, Mosu. That's great. Tried with option 1 but it look like the japanese character turn to '???' so I used option 2 and it worked :p

Then your Windows version lacks support for Asian languages, or your cmd.exe uses a font that lacks those characters.

Mosu

24th January 2014, 11:15

I believe avi files are broken with mmg 64-bit under windows. I switched to the 32-bit version and could remux an avi file without running into error code 3.

Known and fixed. See https://trac.bunkus.org/wiki/Troubleshooting.

Mosu

24th January 2014, 11:39

Hi

Is there some sort of compression in Matroska for MPEG2 streams?

No. What you're most likely seeing is mkvmerge removing filler data. Various MPEG-based formats require certain storage (on a DVD) to have a minimum bitrate. Filler data is therefore inserted in order to achieve that minimum. This filler data is not required for decoding, it is complete garbage from the point of view of the decoding process. A decoder skips that data.

mkvmerge simply removes it. A Matroska file does not have a minimum bitrate.

Note that the actual video bitrate is unaffected by this removal. The video bitrate is the number of bits the actual encoded pictures use. That filler data only affects the whole stream's bitrate, which is highly misleading. If you have a video stream at 2Mbit/s then the quality will not be improved one iota by packaging it as a stream with a stream bitrate of 4Mbit/s.

hello_hello

2nd February 2014, 05:40

I'm not sure when it happened.... I think I skipped a version or two and went from 6.4 to 6.7..... but I just wanted to say thanks. MKVMergeGUI no longer opens at a snail's pace running on my quad core PC. It used to take at least twice as long to open as it did running on my dual core. Now it opens nice and quickly regardless of the CPU. Sometimes, it's the little things.....

Thanks! (32 bit version, XP)

Nexin

6th February 2014, 22:33

Mosu using MKVmerge recently for splitting and audio image with added cue sheet.

MKVmerge
drop audio file - Mux to mka file - Remove audio file
Drop new muxed mka file - add cue file to it - close MKVmerge (To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.)
Open MKVmerge - drop newer mka file and select Global then Splitting Mode

This is where I become stuck what to add for Split Parts By Timecodes which I guess will be the most exact way to split perfectly on INDEX 00:03:54 (now chapters). I have tried many ways yet unable to get it to split.

I have a suggestion wouldit be possible for MKVmerge to parse an mka file on load so automatically knows each chapter (from the now embedded cue file in mka). So when using Splitting and other MKVmerge features we see instead a list and able to select what chapters we like to be split and output.

I did get MKVmerge to work but it fails for what I needed as I though it would from the splitting name. I used the following..
Split Before Chapters
All
# [# of tracks to split]

As can guess the track splits weren't perfectly correct and erased those split files.

If you can see a way to make MKVmerge better to automatically parse each file or highlighted file on Input screen (after you implement this do tell if we need to highlight file in the upper or lower panel on Input for file to auto chapter parse)

Also the MKVmerge gui doesn't keep its screen position on restart. This is even with GUI maximise window set. With each new MKVmerge start the GUI has moved nearly all off the monitor screen
(1 gfx screen and 1 hardware monitor setup using xp3)

hello_hello

7th February 2014, 00:10

MKVmerge
drop audio file - Mux to mka file - Remove audio file
Drop new muxed mka file - add cue file to it - close MKVmerge (To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.)
Open MKVmerge - drop newer mka file and select Global then Splitting Mode

The File/New menu doesn't open a new file or a new instance of MKVMergeGUI as I'd originally assumed it would. It clears everything.
At one stage I requested a "New" button be added to the bottom of the window. Maybe replacing the "copy to clipboard" button, which I suspect would be a likely winner if ever entered into a "least often used GUI button" competition. ;) Or maybe that's just me. A "manage jobs" button next to "add jobs" button might be handy too.

I did get MKVmerge to work but it fails for what I needed as I though it would from the splitting name. I used the following..
Split Before Chapters
All
# [# of tracks to split]

As can guess the track splits weren't perfectly correct and erased those split files.

I've not split files by chapters before so after reading your post I gave it a spin after muxing a multitrack flac file into an MKA, then again using multitrack MP3. Each time I included the corresponding cue file.
After muxing, opening the muxed file and splitting before chapter (all), the output files all contained a single chapter with a timecode of 00:00:00.000, so for me MKVMergeGUI split exactly at each chapter.
I'm using version 6.7.0 and XP.

hello_hello

7th February 2014, 00:45

MKVMergeGUI has an option to automatically use any audio delay included in the file's name if the delay amount follows the word "delay". For those who aren't aware it can do so, an example file name would be (as extracted by DGIndex):
"Audio T81 2_0ch 224Kbps DELAY 32ms"

Feature request:
When audio is extracted from an MKV using MKVCleaver, it looks something like this (it doesn't write the delay value):
Audio_Track01(EN).mp3
MKVExtractGUI does it like this (no audio delay written either)
Audio_track2_eng.mp3
MeGUI extracts the audio this way:
audio - [0] English 16ms
Although after requesting it be changed, Zather informed me the next MeGUI version would write the file names in a more MKVMergeGUI friendly manner.
audio - [0] English Delay 16ms

Given most programs write the language name (or two letter code) to the extracted audio, would it be possible for a future version of MKVMergeGUI to automatically apply the specified language when adding tracks? The same way it automatically applies the correct delay? MeGUI's muxers understand the format MeGUI uses for languages in file names and automatically applies them, so I'd assume it's not impossible. MKVMergeGUI already does so when opening MKVs if the streams within have a specified language and/or delay.

If the developers of the above software (and MKVMergeGUI) would care to get together one day, have a few drinks, tell a few jokes at the expense of other software developers, then settle down to the task of deciding on a common naming format each program will use when extracting, I'll buy the first couple of rounds. ;)

Mosu

7th February 2014, 08:54

Mosu

7th February 2014, 08:56

Given most programs write the language name (or two letter code) to the extracted audio…

No, and not for the reason that I'm currently re-writing the GUI. Read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3ADetectingTrackLanguageFromFilename) I've written about this very topic.

hello_hello

7th February 2014, 11:11

No, and not for the reason that I'm currently re-writing the GUI. Read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3ADetectingTrackLanguageFromFilename) I've written about this very topic.

That's disappointing..... and to be honest I'm not sure any of the reasons listed would necessarily be show stoppers. If I may....

If I wanted to detect full language names (e.g. "English") then how should Johnny English.srt or, even worse, The French Connection.srt be handled?
If I wanted to detect full language names it would be restricted to their English representations. But what if the file name contains a localized language name? In the following example the language would be "English" again, but the whole file name is in French: Le fabuleux destin d'Amélie Poulain (Anglais).srt
So we're back to short ISO-689 codes. Even if I only try to detect them at word boundaries there's a huge problem as some of those three-letter codes are actual words in certain languages. Let's take Le juge est une femme.srt Here est is the language code for Estonian.

MeGUI's muxers have used the language written to extracted streams for as long as I can remember. I tested it by changing the file name to a language like this:

Audio - [0] English 16ms
French - [0] English 16ms

Disappointingly it used English the first time and French the second, so it's not particularly clever. I'd be willing to bet the number of complaints regarding this behaviour in the MeGUI threads would be somewhere in the vicinity of none. Having said that.....

The word "Delay" preceding the delay value in the file name has been the secret handshake for applying a delay for as long as I can remember, yet file names can also contain numbers. Surely a similar secret handshake could be used for applying language names? A two/three letter code following, or surrounded by, characters which aren't likely to be otherwise combined in the same way?

Audio -[[En]]- Delay 16ms

I'd imagine you'd need set the standard.... be the one who decides on on the appropriate secret handshakes for MKVMerge, while the developers of encoder GUIs and extraction utilities etc would need to make their programs MKVMergeGUI friendly. If there's ever going to be a standard for this sort of thing, it's got to start somewhere. :)

Another problem occurs with files that can contain multiple tracks. Let's take Life of Brian (FRE).mkv as an example. What if there's one audio track and one subtitle track in that file? Which of those would FRE refer to?

Neither. Mostly, it's after extracting streams from their original containers it'd be handy to have languages and audio delays written to file names and automatically applied. Doing the same at the container level doesn't seem as important to me.
While I hadn't envisaged it, if a container contains more than one track, any language written to the file name would probably be best ignored. It's ignored currently so nothing would change there. If a container contains more than one stream, I'd expect the language specified for the streams to be applied as it currently is.
Maybe if a container only contains a single stream the language in the file name could be applied, but if the stream itself has a set language I'd probably expect it to take precedence. Or maybe in such a situation they could both be ignored... Whatever happens, the user would get used to the way it works.

The next problem is that detecting the language code is one thing. Making the user aware that mmg has tried to detect such a code is another matter entirely. If the language drop-down box is simply set accordingly then the user will only realize this if he clicks on all added tracks in turn. But he has to do that because it's such a frail mechanism that he has to verify the results.

When streams or files are opened by MKVMergeGUI for muxing, each stream is listed in the tracks section. Changing the text color of a stream which has been subjected to an automatic application of settings.... as long as the user is given some sort of "hey, something happened and you might want to check it warning".....
Mind you when currently opening an existing MKV I'd imagine most people know the individual tracks need to be checked unless they're confident they were set correctly in the first place.... sometimes you just need to check.
Even if the "general track options" area contained a single "default" button which for the selected track would automatically apply a particular language, default and forced track setting according to the users preference, it would probably reduce the need for clicking, scrolling and selecting by a considerable amount.

Anyway.... thanks for all the hard work on MKVToolNix. It's appreciated!

Mosu

7th February 2014, 12:17

Nexin

8th February 2014, 02:17

Mosu using MKVmerge recently for splitting and audio image with added cue sheet.
This works as intended, just like hello_hello has written. Keep in mind that mkvmerge can only split before I frames, not at arbitrary positions (even though you can enter arbitrary timestamps). See the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split).
Working with audio only with MKVmerge ATM.
No I frames unless audio also has I frames ?

Can MKVmerge split exact on cue sheet (chapter) Index marks or not ? If not will the new GUI be able to do so ?

Currently MKVmerge GUI Splitting feature has many options. I thought the 'Split by parts based on Timecodes' would be an exact precise split of the cue file Index points (chapters). Use of MKVmerge is for demux only with no audio file conversion. To demux and split precisely only at exact Index points using the embedded cue index (chapters).

To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.
Use »File« -> »New«, that's what the function is there for: to start over as if you had re-started mmg. The »Remove all« button is intentionally different and keeps the content of a lot of controls in order to facilitate muxing several sets of files, e.g. several episodes of a series where you keep certain central things, one after each other.
Thanks the File-New option works as needed, I was looking for a GUI button to do the same.

I have a suggestion…
I'm in the middle of re-writing the GUI with a different toolkit (Qt instead of wxWidgets). Therefore the old GUI has reached its end of life; I won't spend any more time on it. I also don't accept feature requests for the new GUI yet.
Good news I didn't know you were working on a new GUI.

Will also the new GUI allow drag and drop for cue files. Current MKVmerge complains with 'File Identification Failed' when try to.

Looking forward to the new MKVmerge GUI features and options :)

Mosu

8th February 2014, 08:37

Working with audio only with MKVmerge ATM.
No I frames unless audio also has I frames ?

Most audio formats are I frame only, but the old RealAudio do indeed have I and P frames – meaning you cannot start decoding at arbitrary frames but only from specific ones, same as for video in general. But for modern audio codecs it's true that all of their frames are decodable without any prior frame, and therefore mkvmerge can split before any of them.

Can MKVmerge split exact on cue sheet (chapter) Index marks or not ?

No. It can only split directly before a frame. For audio those frames are usually somewhere up to 40ms long (depending on the format and sampling parameters in question).

If not will the new GUI be able to do so ?

This has nothing to do with the GUIs. It's how mkvmerge works.

Will also the new GUI allow drag and drop for cue files. Current MKVmerge complains with 'File Identification Failed' when try to.

No, it won't. Again, this has nothing to do with the GUI but with mkvmerge. mkvmerge does not accept chapter files as input files; you have to pass them with "--chapters filename". Therefore the GUIs won't accept them when you drag such a file as an input file either.

Nexin

8th February 2014, 18:05

Thanks for your exact explanation Mosu, I will look elsewhere for what I need. Use your present and new GUI when need to contain some videos to use in other softwares'.

update:

It transpires that DVDV-A and DVD-A does not use cue sheet indexes but instead chapters. So splitting just before is ok as 40ms is small. Will try again and adjust where needed so correct.
It can only split directly before a frame. For audio those frames are usually somewhere up to 40ms long (depending on the format and sampling parameters in question).

Thankfully I can edit easily using cue sheets and have each audio track file name included. two files image and cue sheet a lot easier to store than many files.

Maybe also in time MKV itself updates so can parse chapters make life easier to use other options when needed. :)

pepelugil

11th February 2014, 21:50

Hi,

My standalone player doesn't correctly handle mkv generated with v5.9.0 and above: If I try to fast-forward, the mkv will stop playing. With v5.8.0 muxed mkv's there isn't this problem, and the only diference I've noticed is that while with v5.8.0 MediaInfo is this:

Format : Matroska
Format version : Version 2

With newer versions is this one:

Format : Matroska
Format version : Version 4 / Version 2

Is there any option or parameter in newer versions in order to force Version 2 only?

Thanks

sneaker_ger

11th February 2014, 22:14

Chetwood

12th February 2014, 06:47

What brand is that standalone?

Mosu

12th February 2014, 08:51

As sneakger_ger said; also read https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590 which boils down to the same options but gives more explanation.

pepelugil

12th February 2014, 19:49

See https://trac.bunkus.org/wiki/FAQ%3AImprovingPlaybackCompatibilityWithPlayers#Notusingcertainnewelementsinthecueswith--engageno_cue_durationand--engageno_cue_relative_position, the part about --engage no_cue_duration and --engage no_cue_relative_position in particular.

As sneakger_ger said; also read https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590 which boils down to the same options but gives more explanation.

Thanks that was it, adding --engage no_cue_duration and --engage no_cue_relative_position did the trick :):):)

What brand is that standalone?

It's a Cambridge Audio azur 651BD with the lastest firmware available from May 2012.

Chetwood

13th February 2014, 07:04

I was afraid something like this might happen so I immediately added this parameters to my encodes to make sure they run on my WDTV. Never even tried it without ;)

hello_hello

13th February 2014, 08:00

You may, but you won't change my mind, and I can live perfectly fine with your disappointment. I'm also pretty sure that the amount of time such a feature would have saved you doesn't even equal the time you've spent writing this post.

Oh well.... although I'm fairly sure I'll survive knowing how incorrect your assumption is.

I did play around with GDSMuxer and discovered it automatically defaults to English (or the default OS language, I assume) after adding individual streams without the world ending as a result, but it's not MKVMergeGUI.

A bit of messing around with command lines seemed to allow me to set the defaults I want for each track by adding the following to the "user defined options" for each one, allowing me to bypass the General Track Options tab most of the time (hopefully). Unless I need to change something, it's much faster than playing with drop down boxes to change each setting for each track individually.

--language <TID>:eng --track-name <TID>: --default-track <TID>:yes --forced-track <TID>:no

Currently I've added it to my clipboard manager for easy copying and pasting, but when I get a chance I'll have a play with the macro program. With any luck I might be able to automate the process a bit more.

Any way to coax MKVMergeGUI into opening with the "Extra options" tab selected rather than defaulting to the "General track options" tab?

Mosu

13th February 2014, 08:50

Any way to coax MKVMergeGUI into opening with the "Extra options" tab selected rather than defaulting to the "General track options" tab?

No, there isn't. At least none that I know of. Maybe you could try to use something like AutoIt or other similar macro processing tools for emulating a click at the proper coordinates.

Chetwood

14th February 2014, 07:40

Mosu

14th February 2014, 08:55

keyboard shortcuts still missing from mmg like CTRL-A to Add to job queue.

There is such a shortcut, Alt+A. It works just fine on Linux and I haven't figured out why it refuses to work on Windows. That's only one of the reasons why I'm re-writing the GUI with a different toolkit…

We've talked about this: having mmg play a sound

Which I consider one of the worst features a program can have. I usually listen to music, my music player is at a volume I'm comfortable with, and then all of a sudden program XYZ blares out some arbitrary sound file at full volume? No thank you. The first thing after unpacking act3to, for example, is to delete all the .wav files in its directory in order to prevent this.

I realize different users have different needs, and that there are those like you that rather like such a feature. But I'm also not in the business of implementing each and every one of user's wishes. I wouldn't get anywhere if I were, and me doing this program must always be balanced around me having fun, too, because as soon as it drifts over into the realm of »it's all work that I don't like« then this will be detrimental to my long-term commitment to MKVToolNix.

However, as I've said above I'm currently re-writing the GUI with a different toolkit (Qt instead of wxWidgets). There's a multitude of reasons for that decision, and I will write a probably rather lengthy blog or wiki post about the why, how and when of that transition. The point is that on my TODO list (or at least on my »ideas for the new GUI« list) there is an item called »user-configurable job actions«. The long-term vision for this feature is to leverage Qt's own QtScript language (which is pretty much JavaScript) and allowing the user to write his/her own snippets in that language that will be executed on different events: before a job is started, after it has been completed, after all jobs have been completed etc. The short-term goal would be to simply allow this code to execute external applications. The long-term goal would be to have a tighter integration allowing the manipulation of the job files from within that script before the job is executed.

This kind of interface would definitely allow you to play sounds (via external programs), shut down the computer, send emails upon completion (again via external programs – I don't plan an implementing SMTP clients into the GUI) etc. Yes, it would be more work for you than simply ticking a checkbox in the preferences, but it would also be so much more flexible than such a checkbox would be. And it would save you from me saying »no I don't want that feature« :)

Yes, it's far off, but me re-writing the GUI is also the reason for my next sentence: I'm sorry, but there won't any more work on mmg safe for critical bug fixes. Definitely not new features, and highly unlikely bug fixes for cosmetic/unimportant/very hard to reproduce bugs.

And if it's not feasible somehow due to MKVToolnix being multi OS

My refusal for playing sounds is mostly based upon the reason stated above. Being multi OS with a crappy toolkit (wxWidgets) plays its part, too, but that wouldn't be a concern for Qt as Qt comes with a nice multi-platform multimedia framework (Phonon). Anyway, with the QtScript-based actions outlined above those concerns would be moot. This feature would be available on all platforms, and it would simply be up the user to select the external mechanisms suitable for him/her.

Ideas? Use dbus for desktop notifications on Linux. Use "shutdown /t now" on Windows. Send and email with "mail done | joe@user.org'' on Linux. Use Mac OS desktop notifications via growl.

nautilus7

14th February 2014, 14:41

Mosu, mkvmerge has some issues when reading mpls files.

I 've come across several Blu-ray discs (bbc's documentaries especially) that mkvmerge can't detect correctly all the tracks (video, audio, subs) because the playlist contains 2 or more m2ts files with different kinds of tracks. Look at the sample (bbc blu-ray.rar) which I have already uploaded to your ftp server.

LAV filters can playback such mpls files correctly, if that helps.

Mosu

14th February 2014, 14:47

MPLS referring to M2TS files with different tracks are not supported and most likely never will be. Those M2TS files have to be handled the same way as appending files has to be, which means that all track types and track parameters (codec, sampling frequency etc) will have to be the same.

Now for appending files normally mmg (and by extension mkvmerge) allow you to tell them which tracks should be appended to which other tracks – meaning you can fix that manually. I know that this is currently not possible for MPLS files. I've thought about this when I re-designed the MPLS support (changed from treating the M2TS as »additional parts« to »appended files«), but I figured that it would be a staggering amount of work to implement this properly both in mkvmerge and the GUI.

That's the reason it's currently simply unsupported and will most likely stay that way at least for a long time (if not forever).

nautilus7

14th February 2014, 14:56

I see. Thanks.

EDIT: so, I decided to load just the main m2ts file that is referenced in such mpls, but audio is not detected. Is that because it's pcm audio?

hello_hello

14th February 2014, 18:45

Using coordinates is a tedious approach due to people's varying screen resolutions and MMG window sizes. Far better is simulating keypresses which would however require keyboard shortcuts still missing from mmg like CTRL-A to Add to job queue. IMHO, AutoIt is a clumsy workaround for features that MKVToolnix should have. We've talked about this: having mmg play a sound when it's done or shutting down the machine (especially after working through a long job queue) should be standard these days. And if it's not feasible somehow due to MKVToolnix being multi OS, calling up an autoexec.bat in the MKVToolnix folder after each encode/finished queue would let people create their own actions.

I must admit, I'm not a fan of software which goes "ding" myself, but if it can be enabled/disabled..... each to their own.
TSMuxer.... why can't it remember the "play sound" choice from the last time it ran?

I didn't bother with anything too clever in the end. I have AutoHotKey set to type a commandline for me. I only use two variations 99.999% of the time. English/Default Yes/Forced No, or the same with default=no instead.

Now it's a two handed operation.....
Click on a track, click on the user options area, tap a couple of keys with the other hand to activate adding the commandline line, select the next track.....

I could probably automate the process a little more, but I'll see how that goes first.

Chetwood

15th February 2014, 10:34

Which I consider one of the worst features a program can have. I usually listen to music, my music player is at a volume I'm comfortable with, and then all of a sudden program XYZ blares out some arbitrary sound file at full volume?
Wow?! Not everyone listens to music during work (or is sitting at the computer/in the same room the job queue is running on/in), the file selected isn't abitrary and as such could be recorded to lower volume but most importanty: it's an OPTION! And unlike header compression back then it would not be set to on by default.

I realize different users have different needs, and that there are those like you that rather like such a feature. But I'm also not in the business of implementing each and every one of user's wishes.
We know, you've made that abundantly clear on several occasions, just recently towards hello_hello.

»user-configurable job actions«. The long-term vision for this feature is to leverage Qt's own QtScript language (which is pretty much JavaScript) and allowing the user to write his/her own snippets in that language that will be executed on different events: before a job is started, after it has been completed, after all jobs have been completed etc.
While overkill for my needs (and probably everyone else's who's not too fond of getting into scripting) it sounds quite flexible and promising (but given your preferences unfortunately also way, way off in the future).

Use "shutdown /t now" on Windows.
Sure but how to do this right now? Currently I have to run AutoIt to periodically poll for MKVToolnix's "mkvmerge has finished" window in the background which does not work properly and is a crutch anyway. That's why I suggested for you to make the current version of mmg execute the file "autoexec.bat" (or whatever) from the MKVToolnix folder. Upon installation it's an empty file and nothing happens on execution (or missing file) but the user can put "shutdown /t now" (or somthing similar for Linux/Mac) or whatever into this.

I totally get that you don't want to lose your fun of working on MKVToolnix but I also think that adding this simple function to the current code would be worth the effort, if only to get people pestering you about the release date of the new GUI off your back ;)

Mosu

15th February 2014, 10:58

Wow?! Not everyone listens to music during work

And I did acknowledge other people's different uses and preferences, so what's your point?

We know, you've made that abundantly clear on several occasions, just recently towards hello_hello.

You know, it cuts both ways. As the sole developer of MKVToolNix I get receive a neverending stream of feature requests. On the other hand I rarely receive a patch by someone implementing a certain feature or fixing a bug. And users such as yourself come across as being somewhat entitled to feature XYZ and that I must be the one implementing it. I'm definitely not saying that's your intention or motivation! Just that I perceive your wording to inflect it. »It's just an option; not a lot of work; just do this and that and that will be enough«. To be honest, it's quite discouraging, because it makes me feel that how many features I ever implement, no matter how much time and effort I put into this piece of free software, it will never be enough, because there's always some feedback à la »this is not enough; I don't understand why you don't implement this and that; I need it NOW or not at all«.

Again, I'm not clairvoyant; I don't know your thoughts and I'm not making any judgement on your character. This is just how it comes across to me.

Several solutions you propose may be enough for you and your unique situation, but I have to think about all users whenever I implement a feature. I also have to keep in mind any previous feature request that might be affected by such a feature. Let's take your autoexec.bat example.

You proposed:

That's why I suggested for you to make the current version of mmg execute the file "autoexec.bat" (or whatever) from the MKVToolnix folder. Upon installation it's an empty file and nothing happens on execution (or missing file) but the user can put "shutdown /t now" (or somthing similar for Linux/Mac) or whatever into this.

Now when would I execute this file? For the shutdown case it would have to be either at the end of the job queue (when running the job queue) or at the end of the currently running muxing job (when not running the job queue). However, I've had feature requests for doing stuff at the end of the job queue but not when you're muxing the current settings. So we'd need two different files for that already.

Another feature request I've received in the past is being able to do stuff to the output file after it's been muxed, e.g. move it to a different drive/folder. This would require running such an autoexec.bat after each job has finished, no matter if its the current job or one from the job queue. However, that would make such a file unusable for the shutdown case because maybe you want the whole job queue processed and shutdown afterwards, not after the first file. And moving the file to a different output folder may depend on the exit status: if there were warnings then move to a folder requiring user intervention later; if there were no warnings then simply move it to the archive. So we'd need some kind of parameter passing. That would have to be flexible enough to be extensible in the future (because I may want to expand on the capabilities without braking compatibility). Even more stuff to think about and more time to spend.

but I also think that adding this simple function to the current code would be worth the effort, if only to get people pestering you about the release date of the new GUI off your back ;)

You're quite wrong. It would get you off my back, but not the other users asking for features. There will never be a point where I can safely say »now all wishes have been fulfilled and I can go work on the new GUI«. It's simply unrealistic. As my time is limited I've elected to stop working on mmg completely; anything else is untenable for me. It wouldn't benefit you much either. For example, if I decided to implement features X, Y and Z from users A, B and C which aren't you then that would move the new GUI into the future even more delaying the features I've laid out in my previous post even more. So implementing your feature request delays work for everyone else.

It's simply not a clear case of »why don't you implement XYZ, nothing depends on it«.

Chetwood

16th February 2014, 09:36

And I did acknowledge other people's different uses and preferences, so what's your point?
That's what I was wondering. Why raise points (that could easily be countered) when you acknowledge other people's preferences which renders those points moot anyway? Moving on.

This is just how it comes across to me.
Well, then I have to say I'm sorry cause that wasn't my intention. I must admit though that your brisk way of dealing with requests and criticism (again, header compression) seems to provoke a different tone sometimes :sly:

Now when would I execute this file?
After the job queue is done is what I had in mind. This would keep it simple and therefore live up to my naive idea of being a "1-liner" job with no ramifications for your workload or other/requested features (I'm no coder though). Initially I thought about suggesting jobdone.bat and queuedone.bat (to be executed only after a return code of 0) but I realized that would probably strike you as a programmer less than elegant.

So we'd need some kind of parameter passing. That would have to be flexible enough to be extensible in the future (because I may want to expand on the capabilities without braking compatibility).
I get that. Implementing these feature requests requires careful planning (you don't have time for ATM) but I think you'll get this covered eventually with the scripting approach you mentioned. And of course, any negative side effects of people's inability to properly use that function would be their sole responsibility: "use at your own risk!". Still, while you're working on the new GUI, you might wanna add some extra space for future checkboxes ("shutdown after queue") next to "abort current job" in the mkvmerge is running queue window.

So implementing your feature request delays work for everyone else.
Obviously, and of course it's your decision what to implement next, whether it's the latest "tweak" to the MKV standard like no_cue_duration or the handling of new codecs. I, however, always found MKVToolnix to be lacking in the notification department (play sound or do whatever when done) we've come to expect from software over the years and I just thought that fixing this might benefit users more than an MKV feature that we've done fine without so far and that most likely will take standalone manufacturers forever to implement. But that's just me.

Still, I appreciate you taking time to explain this rather than shrugging it off. Thanks.

Selur

20th February 2014, 16:58

@Mosu: got an mp4 file here which was captured with VLC and where MediaInfo reports:
General
Complete name : f:\asynch after remux_vlcCapture.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 105 MiB
Duration : 13mn 30s
Overall bit rate mode : Variable
Overall bit rate : 1 092 Kbps
Encoded date : UTC 2012-12-18 20:00:04
Tagged date : UTC 2012-12-18 20:00:04
Writing application : vlc 2.0.4 stream output
Comment : QuickTime 6.0 or greater

Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 13mn 28s
Source duration : 13mn 28s
Bit rate : 1 024 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate mode : Variable
Frame rate : 25.000 fps
Minimum frame rate : 8.342 fps
Maximum frame rate : 25.025 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.099
Stream size : 98.7 MiB (94%)
Source stream size : 98.7 MiB (94%)
Language : English
Encoded date : UTC 2012-12-18 20:00:04
Tagged date : UTC 2012-12-18 20:00:04
mdhd_Duration : 808599

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : 40
Duration : 13mn 30s
Source duration : 13mn 30s
Bit rate mode : Variable
Bit rate : 64.0 Kbps
Maximum bit rate : 99.7 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz / 22.05 KHz
Compression mode : Lossy
Stream size : 6.18 MiB (6%)
Source stream size : 6.18 MiB (6%)
Language : English
Encoded date : UTC 2012-12-18 20:00:04
Tagged date : UTC 2012-12-18 20:00:04
mdhd_Duration : 810422
Playback of the original file works fine, but if I remux it to mkv using mkvmerge the file is totally async.
Issue isn't that important to me, just thought you might want to know about potentially problematic mp4 files.
-> if you want I can upload the file to your ftp.

Cu Selur

Mosu

20th February 2014, 20:33

I'd appreciate the upload, though I will probably not be able to look at it soon. Thanks.

Nico8583

21st February 2014, 23:50

Hi :)
I would like to know if it's possible to add some informations to an MKV file, like synopsis, stars, released year, cover (but it seems to be in Attachments), title, genre, countries...
Is it possible by creating a XML file and use it in Global tags ? Or another way ? And how to format XML file to be accepted by MKVmerge ?
Thanks !

the_weirdo

22nd February 2014, 05:49

Is it possible by creating a XML file and use it in Global tags ?
Yes.

And how to format XML file to be accepted by MKVmerge ?

This (http://matroska.org/technical/specs/tagging/index.html) may help you. (You can find XML examples there, too).

Nico8583

22nd February 2014, 10:15

Thank you, it is what i searched :)
Do you know players who can read these informations ? XBMC ? MPC-HC ?

the_weirdo

22nd February 2014, 12:08

Thank you, it is what i searched :)
Do you know players who can read these informations ? XBMC ? MPC-HC ?

Don't know about XBMC but MPC-HC/BE doesn't seem to read those informations. However, VLC and mpv can do that.

Nico8583

22nd February 2014, 12:26

Don't know about XBMC but MPC-HC/BE doesn't seem to read those informations. However, VLC and mpv can do that.
Thanks, I'll try XBMC and MediaPortal.

leeperry

27th February 2014, 12:27

Thanks for this great app, BTW is there any simple way to extract a sequence in the middle of a MKV file? I always have to split several times to get the sequence I want, is there any way to get it right away?

Mosu

27th February 2014, 12:29

Use splitting by parts and read the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split) for it.

Mosu

3rd March 2014, 18:29

Hey,

I've released MKVToolNix 6.8.0. There were tons of bug fixes for the Windows builds, especially for the 64bit builds.

The one new feature that is present is support for h.265/HEVC video: but only for reading it from elementary streams or from other Matroska files. My initial plan was to have reading it from MPEG transport streams work as well, but alas, free time is in short supply, and this release is a week overdue already.

The HEVC support has been implemented by Rovi Corp (DivX). I've merged their changes, updated them to the current code base and cleaned them up somewhat. Their work is much appreciated.

For package maintainers nothing has changed compared to 6.7.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.7.0:

2014-03-02 Moritz Bunkus <moritz@bunkus.org>
* Released v6.8.0.

2014-02-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: new feature: added support for h.265/HEVC by merging the patches from DivX/Rovi Corp. So far HEVC is only supported as elementary streams and read from other Matroska files.

2014-02-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The deprecated ISO 639-1 code "iw" is now recognized for Hebrew.

2014-02-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The AC3 packetizer will re-derive the sampling frequency and the number of channels from the bitstream. This way obviously invalid information from the source container like a sampling frequency of 0 Hz will be fixed.

2014-02-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancements: AVI reader: audio chunks with obvious wrong size information (bigger than 10 MB) will be skipped.

2014-02-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: When reading M2TS files belonging to an MPLS playlist mkvmerge will now only copy packets whose timestamps lie between the »in time« and »out time« restrictions from the playlist's entry corresponding to that M2TS file. Fixes #985 (https://www.bunkus.org/trac/ticket/985).

2014-01-22 Moritz Bunkus <moritz@bunkus.org>
* all: Windows 64bit: fixed return value checks for opening files. Fixes #972 (https://www.bunkus.org/trac/ticket/972).

2014-01-21 Moritz Bunkus <moritz@bunkus.org>
* all: Windows: when redirecting the program's output with cmd.exe (e.g. »mkvinfo file.mkv > info.txt«) the programs will no longer write two line feed characters (\r) per carriage return character (\n). Fixes #970 (https://www.bunkus.org/trac/ticket/970).
* all: Windows: the default charset for the files created with»--redirect-output« has been changed from the system's local charset to UTF-8. Just like before it can be changed with»--output-charset«. See #970 (https://www.bunkus.org/trac/ticket/970).
* all: bug fix: Windows: messages written to the console (cmd.exe) are not re-encoded to the local charset and back to UTF-16 before they're handed over to ConsoleWriteW(). This fixes outputting Unicode characters to the console that are not part of the local charset. Fixes #971 (https://www.bunkus.org/trac/ticket/971).

2014-01-18 Moritz Bunkus <moritz@bunkus.org>
* extract: bug fix: using names of non-existing files in»attachments«, »chapters«, »cuesheet« or »tags« mode caused mkvextract to crash instead of emitting a proper error message. Fixes #964 (https://www.bunkus.org/trac/ticket/964).

2014-01-17 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: fixed the check for WebM-compatible track types for Opus.

2014-01-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed muxing Sorenson v3 (SVQ3) video from QuickTime files.

2014-01-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract, mkvpropedit: enhancement: attachments in Matroska files with a missing FileUID element are not ignored anymore even though they violate the specs. mkvmerge generates a new FileUID instead.

2014-01-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: re-built with the 64bit build for Windows with a newer compiler version in order to fix #957 (https://www.bunkus.org/trac/ticket/957). It was due to a bug in gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
* mmg: bug fix: mkvmerge's file identification is written to a temporary file with --redirect-output and from there into mmg instead of directly from mkvmerge. This prevents from character re-coding done by wxWidgets 3.0.0 on Windows. Fixes #959 (https://www.bunkus.org/trac/ticket/959).

2014-01-09 Moritz Bunkus <moritz@bunkus.org>
* installer: enhancement: the architecture (32bit vs 64bit) is mentioned in the interface.
* installer: bug fix: the installation directory for 64bit builds will default to the proper directory (»C:\Program Files« instead of »C:\Program Files (x86)«). Fixes #956 (https://www.bunkus.org/trac/ticket/956).

Have fun.

filler56789

3rd March 2014, 19:30

DragonQ

3rd March 2014, 22:54

Mosu, did you have a chance to look at that issue with muxing BBC HD broadcasts causing dodgy timestamps I posted a few weeks back? (Works fine with Haali MKV Muxer.)

Mosu

4th March 2014, 09:55

DragonQ: No, I've totally overlooked that one due to the answers you were already receiving, sorry. I don't have time to look into this over the next two weeks or so either. There's already a similar-sounding bug report (https://trac.bunkus.org/ticket/918) (though the source material is somewhat different) which may have the same underlying cause. However, I haven't been able to figure that problem out. There's simply no other code out there that I can take a look at in order to compare to my code, so it's reaaaaaally difficult guessing where my code is doing something wrong… Haali not being Open Source doesn't help matters either, of course.

So don't get your hopes up.

cyberbeing

4th March 2014, 10:33

Haali not being Open Source doesn't help matters either, of course.

Haali shared his entire source code for splitter & muxer with JEEB awhile back, and even allowed release of binaries built from patched source code. So while Haali may not be Open Source (yet?), it's not as closed as it used to be. Haali's muxer uses DirectShow input though, so things like dodgy timestamps could potentially be cleaned up during decoding, before it even reaches the actual muxer.

pie

4th March 2014, 15:31

I've been searching, but I can't seem to find the answer, so sorry if this has been asked before:

Was there any reason why the type identifier for subtitles, e.g S_TEXT/ASS has been changed to SubStationAlpha?

Mosu

4th March 2014, 15:40

I've unified mkvmerge's output of codec types over the various input/output modules. As both SSA and ASS are handled the very same way they're now named identically.

If you really need to know the type of the codec used then mkvmerge is not the right tool for that particular job.

Mosu

4th March 2014, 19:22

Mosu, did you have a chance to look at that issue with muxing BBC HD broadcasts causing dodgy timestamps I posted a few weeks back? (Works fine with Haali MKV Muxer.)

I've looked into this for a couple of hours and seem to have figured out the reason. I have a new build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) which includes a change that makes playback of the sample you've uploaded smooth. Please try it with some of your other files as well. Thanks.

DragonQ

4th March 2014, 20:13

Just tried a file recorded the other day and it looks like everything's working now, thanks. Out of curiosity, what was the problem? Do they use some rare codec setting that MKVToolnix didn't handle correctly? The BBC tend to be the first to push codec improvements in the broadcasting arena so it wouldn't surprise me.

Mosu

4th March 2014, 20:25

Thanks for testing and getting back to me.

It wasn't a codec setting per se. In an h.264 elementary stream there are several conditions under which the next frame/field can be considered a key frame (in the lose sense of the word – a point from which decoding can start without needing knowledge of any prior/following frames, e.g. a point you can start from after seeking, a »key frame« in Matroska terms): either the NALU is of type »IDR slice« and the slice itself is of one of the types »I, I2, SI or SI2« (that's basically how I named my constants for the various numeric values), or the frame/field follows a »recovery point SEI« NALU.

mkvmerge usually has to buffer all frames/fields for h.264 up to the following key frame. Only when such a key frame is found can the timestamps be applied to the buffered frames properly (sort by display order, assign timestamps, sort back to decoding order).

Now this stream makes heavy use of »recovery point SEI« NALUs. This is OK in general. However, here we have key frames consisting of two fields, and there was a »recovery point SEI« NALU in front of each of the two fields.

The result is:

The first key frame field is found and all prior buffered frames/fields are flushed (flushing = assign timecodes, write to output file, clear list of buffered frames).
The first key frame field is buffered (and now the only frame/field buffered at that point).
The second key frame field is found; again all prior frames/fields are flushed (which is only the first key frame field).
Processing continues up to the next key frame. Here all buffered frames/fields are flushed starting with the second key frame field.

Point 2 is where things went wrong. If the first field of that key frame is flushed so soon then that's too soon as it is required for proper calculation/assignment during step 3.

So what I did was change the algorithm not to flush frames before the second field. I haven't looked into the specs, though, in order to see whether or not what I've done is actually the right thing to do.

hello_hello

10th March 2014, 00:33

Is there a reason why, when muxing a single chapter into an MKV, the chapter in question is ignored? I have a feeling the behaviour isn't new (I can't remember exactly) but is there a way to stop that from happening? Also the behaviour isn't consistent, in that if I remux an MKV (or MP4) which already contains a single chapter, the existing chapter is muxed into the output file. MKVMergeGUI's chapter creator will also mux a single chapter into an MKV. If I create the chapter myself using a text file though, adding it under the Global tab has no effect when muxing. The reason I ask.....

Several times I've wanted to append MKVs while adding chapters corresponding to the point where one MKV "part" ends and the new one begins. I thought it'd be nice and easy to create a chapter located at time code zero, mux it into each MKV, and then when appending the MKVs I'd have a single file with chapters in all the right places. The second part of the idea works a treat, but muxing a single chapter into each before appending is a little harder.

At one stage I appended four MKVs, each containing a single chapter, but the output MKV didn't contain four chapters as I expected. It only contained the chapters from the first two appended MKVs. Is there a reason why the following two chapters might have been ignored? It only happened when appending one particular group of MKVs.

I've also discovered what appears to be a bug in MKVMergeGUI 6.8.0. I don't know if it's new, but if I load the following chapter into MKVMergeGUI's Chapter Creator, it causes the GUI to stop running.

CHAPTER01=00:00:00.000
CHAPTER01NAME=00:00:00.000

Thanks.

the_weirdo

10th March 2014, 05:46

I've also discovered what appears to be a bug in MKVMergeGUI 6.8.0. I don't know if it's new, but if I load the following chapter into MKVMergeGUI's Chapter Creator, it causes the GUI to stop running.

CHAPTER01=00:00:00.000
CHAPTER01NAME=00:00:00.000

Maybe this is indeed a bug and should be fixed, but in the mean time, you can work around it by adding an empty line at the end of chapter files. Your problem of "when muxing a single chapter into an MKV, the chapter in question is ignored" may also be caused by this.

hello_hello

10th March 2014, 05:56

Your problem of "when muxing a single chapter into an MKV, the chapter in question is ignored" may also be caused by this.

It seems it was. Add an empty third line and a single chapter can now be muxed, while loading said chapter file doesn't cause the GUI to run away.

I guess the "can't mux a single chapter" thing is a bug. You never can tell. Handbrake refuses to mux single chapters into it's output files (although the log file informs you of it) so I thought maybe not being able to mux a single chapter might be considered normal. I'm glad it appears not to be.

Thanks.

Mosu

10th March 2014, 10:18

As I'm in the process of re-writing the GUI I won't fix minor issues such as this in the old one, especially as you have a usable workaround for the time being.

delacroixp

10th March 2014, 15:41

* mkvmerge, mkvextract: new feature: added support for h.265/HEVC by merging the patches from DivX/Rovi Corp. So far HEVC is only supported as elementary streams and read from other Matroska files..
Finally \o/ :D

:goodpost: and MANY :thanks:

Ditto ... a welcome addition to the H265 roadmap.
Wasn't sure if you were gonna get to it since you're a "one man band".

Awesome ... tx

It's all good
:):devil::D
Pascal

DragonQ

10th March 2014, 16:10

Wish there was some real-world HEVC content to try. Maybe UHD trials will start on satellite soon.

sl1pkn07

10th March 2014, 16:12

@Mosu

I'm in the middle of a complete re-write of the GUI with a different toolkit library. I will therefore not fix minor issues in mmg anymore.

what is the new GUI toolkit?

Mosu

10th March 2014, 16:22

Qt instead of wxWidgets.

sl1pkn07

10th March 2014, 16:27

GREAT!!!

thanks Mosu for you work!!

greetings

Snowknight26

13th March 2014, 16:12

The Windows installer for the 64-bit version of 6.8.0 seems to have a black background for the copyright line or something like that.

Mosu

13th March 2014, 16:14

Known, already fixed. As it's a completely cosmetic issue I won't create new installers for 6.8.0.

fancyclown

14th March 2014, 01:49

Hi, thanks for the great updates!

Right now I'm using 6.8.0 with wine on OS X because I can't figure out how to build a new version with a gui.

The mac app version hasn't been updated since 6.2.0 so it would be great if anyone could give pointers how to build the new version.

:thanks:

Chetwood

14th March 2014, 07:12

BTW, this thread's headline still suggests 6.7.0 being the latest version.

Mosu

14th March 2014, 09:35

@Chetwood: goot point, thanks. Fixed.

DarrellS

14th March 2014, 18:14

Thanks for the update. Good to see HEVC support. It was worth the wait.

shinchiro

15th March 2014, 02:46

Does chapter extraction broken somewhere in 6.8? as I unable to parse the xml doc in c# library. Plus the byte of sizes it produce is slightly bigger than previous mkvtoolnix version 6.6,6.5 etc produce so it make me wonder it it is the reason it broke. I use --redirect-output option instead '>' when extracting the chapter

Mosu

15th March 2014, 09:17

That's a known issue that I've already fixed in the latest pre-build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/). The issue was that the BOM was written twice when using --redirect-output. The redirection via '… > filename.xml' did not suffer from this issue, though I cannot say whether or not this works nicely with non-ASCII characters on Windows' cmd.exe (it does work fine on Linux shells, of course).

Korgnex

17th March 2014, 12:51

Since version 6.7.0 the head data editor has an annoying bug:
(this also still applies to version 6.8.0)

if you load a file (*mkv) with the head data editor or place it via drag and drop there, the head data editor becomes unresponsive for about 6-8 seconds. The same happens when you save the changes.
In version 6.6.0 the loading and saving worked flawless.

platform tested: Windows 7 SP1 / Windows 8.1 (both x64)

Could you please reproduce this bug and fix it?

Mosu

17th March 2014, 12:53

No, sorry. I won't spend any more time on the old GUI as I'm in the process of re-writing it – even though that will still take some time until it'll be finished.

Simon88

21st March 2014, 17:19

When I open MKVs under mmg 6.8.0 64-bit and trying to edit the "Global options | File/segment title:", subsequent edits of different files shows "blank/nothing" in the "File/segment title:" fied. I know for a fact it contains a File/segment title... so when I exit and re-run it and then load up the mkv, it shows the correct File/segment title.

For the new Input files:, I simply click "remove all" and then add... Am I doing something wrong, or am I suppose to exit the entire program before loading up a new MKV file? I remember in the past it seem to work as I had expected... but this newer version somehow behaves differently....

Mosu

21st March 2014, 17:21

Use »File -> New«. Using »Remove all« is supposed to keep certain fields the way they are, and that includes their internal state regarding whether or not the field has been manually changed.

MeridiusUK

25th March 2014, 22:23

Use »File -> New«. Using »Remove all« is supposed to keep certain fields the way they are, and that includes their internal state regarding whether or not the field has been manually changed.

Hi there

I have also been using the remove all button to create more mkvs but did not know that the Global File/Segment title did not change with every new files droped into the window.

is there a way to change this field in the mkv without remuxing a few mkvs or will i have to start all over to change that field.

also what other fileds odes the remove button keep when inputing a new project apart from the file/segment title ? is there anything i should be worried about.

thanks

Mosu

26th March 2014, 08:01

If you need a GUI: mmg's header editor. If you need something scriptable: mkvpropedit.

MeridiusUK

26th March 2014, 20:31

Thanks fro that but i can not seem to finr the mmg header editor ? is it in mkvtoolnix or other as i can not find it

thanks

Mosu

26th March 2014, 20:38

Start mmg, File -> Header editor.

hubblec4

27th March 2014, 11:52

Hi Mosu

during i update my chapterEditor i found a small issue in mmg at the mpls parser.

here is an eac3to log which you can see that the mpls file is used for 2 separate editions.

eac3to v3.27
command line: eac3to.exe "h:" -log=log.txt
------------------------------------------------------------------------------
1) 00001.mpls (angle 1), 1:51:51
[6+1+3+4].m2ts
- Chapters, 12 chapters
- h264/AVC, 1080p24 (16:9)
- DTS Master Audio, German, multi-channel, 48kHz
- DTS Master Audio, English, multi-channel, 48kHz

2) 00001.mpls (angle 2), 1:51:51
[6+2+3+5].m2ts
- Chapters, 12 chapters
- h264/AVC, 1080p24 (16:9)
- DTS Master Audio, German, multi-channel, 48kHz
- DTS Master Audio, English, multi-channel, 48kHz

when i load this mpls in mmg i get only a chapter entry, but no tracks.

this is a mpls from the "SNITCH" Bluray.

MeridiusUK

28th March 2014, 17:43

Start mmg, File -> Header editor.

thanks alot for that

can it cause any damage in the mkv by doing this at all ?

Mosu

28th March 2014, 17:46

Read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AAllTracksVanishedAfterMkvpropeditOrHeaderEditor) for what may happen with players that don't support the Matroska file format properly.

AYColumbia

5th April 2014, 15:10

@Mosu,
After updating to 6.8.0, it looks like chapter adding/updating is broken with mkvpropedit. I sometimes have to tweak some chapters so I use mkvextract to get the chapter in XML, update it and then re-insert it with mkvpropedit. I've been doing this for a long time now with no issues, until after updating to 6.8.0.

I even tried extracting the chapter, not modifying it and then re-insert it and it still failed. Here's the error mkvpropedit is reporting:Commandline: mkvpropedit "test.mkv" -c "test_chapters.xml"
Error: Unknown chapter file format in 'E:\Media\work\test_chapters.xml'. It does not contain a supported chapter format.
Process terminated with code: 2
Execution took 0 seconds(s).
Here's the chapter file contents that are untouched, i.e., extracted from MKV file and not modified:<?xml version="1.0"?>

<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionUID>6990704301007864204</EditionUID>
<ChapterAtom>
<ChapterUID>17754048247072012851</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:01:17.710966666</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 01</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>4344430792985646390</ChapterUID>
<ChapterTimeStart>00:01:17.710966666</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:11:49.241866666</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 02</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>5565392499311670039</ChapterUID>
<ChapterTimeStart>00:11:49.241866666</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:21:31.823866666</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 03</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>7804300074959422330</ChapterUID>
<ChapterTimeStart>00:21:31.823866666</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:22:30.048700000</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 04</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>1890640418935528493</ChapterUID>
<ChapterTimeStart>00:22:30.048700000</ChapterTimeStart>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterTimeEnd>00:22:31.550200000</ChapterTimeEnd>
<ChapterDisplay>
<ChapterString>Chapter 05</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>
I also tried to load the chapter files into the UI's chapter editor and got the same error, so I'm not sure what has changed. Tell me if you need any other info please. Thank you.

Mosu

5th April 2014, 15:15

The extraction with mkvextract was broken, yes. Known issue, fixed already. Get the latest build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

AYColumbia

5th April 2014, 15:23

The extraction with mkvextract was broken, yes. Known issue, fixed already. Get the latest build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).
Great, thank you. I'll grab the latest and give it a try. I just ran into one other issue with mkvpropedit though. I wanted to try to remove the current chapter file and according to the help, I can leave the -c argument blank, i.e., no file specified which would remove the current chapters. I tried it with -c only and -c followed by "" and both gave the following error:Commandline: mkvpropedit "test.mkv" -c
Error: Missing argument to '-c'.
Process terminated with code: 2
Execution took 0 seconds(s).

Commandline: mkvpropedit "test.mkv" -c
Error: Missing argument to '-c'.
Process terminated with code: 2
Execution took 0 seconds(s).
After each one, the chapters were still in the MKV file.

I'll post back on the other issue in a bit.

Mosu

5th April 2014, 15:27

Hmm… please open a ticket in my bug tracker (https://trac.bunkus.org/) about that issue; otherwise I'll most likely forget about it (more than busy at the moment).

AYColumbia

5th April 2014, 15:38

Hmm… please open a ticket in my bug tracker (https://trac.bunkus.org/) about that issue; otherwise I'll most likely forget about it (more than busy at the moment).
I'll put it in the bug tracker now. Thanks.

Okay, I had to grab the 7z file to update to the latest build and it worked great. However, the executable would not launch. I saw, for a split second, the dialog frame and then it would go away. This is happened on both my Windows 8.1 Pro and 7 Ultimate OSes. Both running 64 bit.

Mosu

5th April 2014, 15:52

AYColumbia

5th April 2014, 16:03

Which executable? mkvextract, mkvpropedit and mkvmerge are pure CLI applications; they don't have a GUI, so it's perfectly normal that there's only a new cmd.exe window that disappearsa gain afterwards.
Oh, no, I was talking about the install file, i.e., mkvtoolnix-amd64-6.8.0-build20140310-598-441cded-setup.exe. However, this is not an issue any longer. Seems to be working now. Not sure what in the world happened there.

BTW, defect ticket 1005 created.

Mosu

5th April 2014, 16:06

I've seen it; thanks.

hubblec4

9th April 2014, 15:46

Hi Mosu

I have a question for the mux with mmg at a Bluray with multi editions inside.

My T2 BD will mux every fine but with another BD(multi editions) the mkv has "hiccup's" during the playing.

What could be the problem? or is any other information for mux with mmg neccessary? maybe a timecodes-file?

Mosu

9th April 2014, 19:35

I'm not sure how multi-edition BluRays differ from other ones, but I haven't done anything about those things, so I guess they're simply not really supported.

hubblec4

10th April 2014, 09:18

that confuses me. m2ts file appending works very well. with or without the mpls file.

manually appending work too, but not in every case.

can you explain me how i can use the timecode file? or is it the wrong way? i found not really much infos.

bxyhxyh

13th April 2014, 18:14

Please tell me Traditional Chinese flag. I've searching it for hours from dropdown list.

Mosu

13th April 2014, 18:21

Please read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AChineseNotSelectableAsLanguage) which explains why you cannot do that.

Simon88

14th April 2014, 20:17

Does anyone have the equation necessary to calculate the "Stretch by:" value for a particular video? I have an old video that is 44 minutes and 58 seconds in length. However the audio gradually loses sync. In the beginning it is in sync, and near the end it is off by about 3.5 seconds... Can someone show me how the fraction (ratio) is calculated to obtain the "Stretch by:" value for such a video?

Thanks!!

sneaker_ger

14th April 2014, 20:29

(44*60+58)/(44*60+58+3.5) or (44*60+58+3.5)/(44*60+58)?

Simon88

14th April 2014, 21:02

(44*60+58)/(44*60+58+3.5) or (44*60+58+3.5)/(44*60+58)?
:thanks:

Simon88

16th April 2014, 00:48

I have a Matroska file that has an Aspect Ratio of 16/9. However, it has a VobSub subtitle that looks stretched. So I force the display of the Matroska video with a 4:3 Aspect Ratio and the subtitle looks OK, but the video of course does not.

I realize there is an IDX file for each SUP where I can alter the scale, but the Matroska file container must have a switch somewhere where I can set the Aspect Ratio in the IDX during the importing of the IDX/SUB bitmaps, like the same way we can override the video Aspect Ratio. I'm hoping I don't have to do it manually... :-)

Thanks...

LeMoi

16th April 2014, 06:26

You can manually edit the .idx file and change the "# Original frame size" item or the "# Image scaling (hor,ver), origin is at the upper-left corner or at the alignment coord (x, y)" item

hubblec4

16th April 2014, 09:17

@ Simon you could use BDSUP2Sub.

Simon88

16th April 2014, 16:34

@hubblec4: I'll definitely look at this neat program you mentioned...

@LeMoi: Do you know of generic changes to the IDX that will work for ALL cases of 4:3 --> 16:9 subtitle conversion?

I'm thinking of creating a simple batch file where I can mkvextract the IDX/SUB, then use SED to modify the IDX, and then re-integrate the new one into a new file in a separate directory, whenever I find one in my collection.

Thanks..

Ars92

16th April 2014, 17:35

Don't know why I didn't use this tool from the start. So much more reliable than mediacoder. Effortlessly muxes my drm less iTunes file with subs in less than 10 seconds!

Sent from my SM-N9005 using Tapatalk

Mosu

18th April 2014, 15:19

Hey,

I've released MKVToolNix 6.9.0. There the usual bug fixes all over the place but nothing major, but it was time for a new release.

For package maintainers nothing has changed compared to 6.8.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.8.0:

2014-04-18 Moritz Bunkus <moritz@bunkus.org>
* Released v6.9.0.
* all: new feature: added a Brazilian Portuguese translation of the programs by Thiago Kühn (see AUTHORS).
* mkvpropedit, mmg's header editor: bug fix: fixed a failed assertion in libEBML when writing the same changes twice to certain files (those for which a seek head with a single entry pointing to the elements modified by mkvpropedit/mmg's header editor; e.g. x264 creates such files). Fixes #1007 (https://www.bunkus.org/trac/ticket/1007).

2014-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: reading fonts embedded in SSA/ASS files was sometimes truncating the attachments created from them. Fixes #1003 (https://www.bunkus.org/trac/ticket/1003).
* mkvmerge: bug fix: fixed display of very large IDs during attachment extraction.
* mkvmerge: enhancement: improved file type detection speed for text subtitle formats.

2014-03-10 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: during the extraction of chapters, tags or segment info XML files with the --redirect-output parameter the BOM (byte order mark) was written twice.

2014-03-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG TS: timestamp outliers are ignored if they differ at least five minutes from the last valid timestamp. Fixes #998 (https://www.bunkus.org/trac/ticket/998).
* mkvmerge: enhancements: trailing zero bytes will be removed from AVC/h.264 NALUs. Implements #997 (https://www.bunkus.org/trac/ticket/997).

2014-03-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed timestamp assignment for AVC/h.264 videos in which recovery point SEIs occur in front of the second field of two interlaced fields.

Have fun.

schorman

18th April 2014, 16:32

Just installed the newest version, 6.9.0, for 64 bit Windows. When I add tracks it uses up to 10Gb of memory and basically stalls the system. I think there is some kind of memory leak.

I would advise not installing this version yet.

Mosu

18th April 2014, 16:40

What kind of file have you added? What kind of tracks are in it?

Mosu

18th April 2014, 16:44

Oh wait, I can reproduce this easily. I'll fix it and prepare a new release for that.

schorman

18th April 2014, 17:04

Wow, that was fast. Thanks. Just for good measure, it stalled while adding an h264 video track.

Mosu

18th April 2014, 17:04

Fixed. I'm now preparing release v6.9.1 which will take the usual two to three hours (building all binaries, posting in the usual places etc). Stick to 6.8.0 until then, please.

Mosu

18th April 2014, 17:09

The file type actually doesn't really matter. One of the file type detection modules (called »readers« in mkvmerge terms) was accidentally reading the whole file into memory.

Back with 6.8.0 that reader (a subtitle reader) was probed almost last. Therefore that issue pretty much never came to light. For 6.9.0 I've moved all subtitle readers up to the top because normally they're way, way faster than a lot of other readers (especially the h.264/h.265 ones). That exposed the bug.

As I usually test with small files due to muxing large files taking a lot of time I haven't noticed it before…

Shit happens and stuff :)

Boulder

18th April 2014, 17:16

Mosu,

is it generally "safe" to join two mkv files by appending them? The video, audio and subtitle tracks have the same characteristics. I have a few blu-rays which have a documentary part and a concert part which I'd like to join for viewing and then archive that version instead of archiving two clips.

What I've noticed is that the chapter points do not work correctly with joint files, I guess I need to create a new file manually.

Mosu

18th April 2014, 17:18

Chapters usually work just fine with appending. And yes, appending is generally safe.

Mosu

18th April 2014, 19:02

Hey,

I've released MKVToolNix 6.9.1 mere hours after the release of 6.9.0 due to a severe bug that wasn't present in 6.8.0. Here's the combined announcement for both releases.

There were the usual bug fixes all over the place. No major new features, but it was time for a new release.

For package maintainers nothing has changed compared to 6.8.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.8.0:

2014-04-18 Moritz Bunkus <moritz@bunkus.org>
* Released v6.9.1.
* mkvmerge: bug fix: fixed huge memory usage when probing files (it was reading the whole file into memory for that).
* Released v6.9.0.
* all: new feature: added a Brazilian Portuguese translation of the programs by Thiago Kühn (see AUTHORS).
* mkvpropedit, mmg's header editor: bug fix: fixed a failed assertion in libEBML when writing the same changes twice to certain files (those for which a seek head with a single entry pointing to the elements modified by mkvpropedit/mmg's header editor; e.g. x264 creates such files). Fixes #1007 (https://www.bunkus.org/trac/ticket/1007).

2014-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: reading fonts embedded in SSA/ASS files was sometimes truncating the attachments created from them. Fixes #1003 (https://www.bunkus.org/trac/ticket/1003).
* mkvmerge: bug fix: fixed display of very large IDs during attachment extraction.
* mkvmerge: enhancement: improved file type detection speed for text subtitle formats.

2014-03-10 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: during the extraction of chapters, tags or segment info XML files with the --redirect-output parameter the BOM (byte order mark) was written twice.

2014-03-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG TS: timestamp outliers are ignored if they differ at least five minutes from the last valid timestamp. Fixes #998 (https://www.bunkus.org/trac/ticket/998).
* mkvmerge: enhancements: trailing zero bytes will be removed from AVC/h.264 NALUs. Implements #997 (https://www.bunkus.org/trac/ticket/997).

2014-03-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed timestamp assignment for AVC/h.264 videos in which recovery point SEIs occur in front of the second field of two interlaced fields.

Have fun.

microchip8

18th April 2014, 19:18

I see no package for openSUSE 13.1. Still building/packaging?

Mosu

18th April 2014, 19:23

Yes, packages for certain distros/versions are still being built. I simply didn't want to hold off too long as more and more bug reports were coming in.

schorman

19th April 2014, 02:03

Thanks again for the fix and thank you for your wonderful work on mkvmerge. Great program and truly invaluable.

netmask

19th April 2014, 07:52

I'm using Firefox with the Foxbleed add-on. When I went to the author's page I was presented with a HeartBleed warning. Not sure if it is a false positive, so far I have only detected it on 2 other web sites.

Mosu

19th April 2014, 09:25

The SSL libraries are up to date on my server (I did that on the day Heartbleed was revealed to the public), but I haven't revoked and re-issued the certificate. It is highly debatable whether or not one insignificant site such as mine warrants panic over non-re-issued certificates, though.

PS: Please no discussion about this here, it's highly offtopic.

Selur

22nd April 2014, 09:14

to the Mac users: http://jonthn.free.fr/MKVtoolnix/ has a new mkvtoolnix build for Mac OS X!

Mosu

22nd April 2014, 09:24

Indeed, and it's already been added to my download section. I've also been working with a kind German Mac user who has spent quite a lot of hours trying to compile everything, and yesterday he has succeeded (including the GUIs; statically linked; for 10.8 and newer). So we may hopefully expect more up-to-date DMGs in the future – independent of Jon's erratic update schedule.

Selur

23rd April 2014, 13:03

Jonathans builds are 10.7+ compatible, so personally I would prefer them over the 10.8+ versions. (I would even more prefer a 10.6+ compatible version ;))

Mosu

23rd April 2014, 13:05

You may use whichever you wish, of course. But Jon's track record for updates hasn't been stellar for a year. So you may have to switch some day. Or maybe he'll update regularly again now. We'll see.

szabi

9th May 2014, 09:27

Hi

Is that possible by mkvtoolnix (http://www.bunkus.org/videotools/mkvtoolnix/) after a given time, automatically switch from one audio stream to an other?

bye
szabi

Mosu

9th May 2014, 10:50

No, that is not possible (even though I don't really understand what you want I can still answer »no« because none of the possible interpretations that I have for your question can be fullfilled with Matroska in general or MKVToolNix in particular).

Simon88

9th May 2014, 15:25

Hi

Is that possible by mkvtoolnix (http://www.bunkus.org/videotools/mkvtoolnix/) after a given time, automatically switch from one audio stream to an other?

bye
szabi

It is the player's job to do the audio track switching, so a script/batch file to "force" the switching from one audio to the other can be done.

Another workaround, is just use the "Append" button in mmg. It will not require any scripting by the media player. File size will of course be doubled... Good luck...

Simon88

12th May 2014, 00:08

I have some MKVs w/ parts of it broken. I find MKVtoolnix will skip and re-mux OK if it's the end or somewhere in the middle is broken, with the missing parts eliminated after a re-mux and most of the video recovered and plays fine without freezing the media player.

However, how would I make mkvtools read an MKV file that is broken or missing the beginning of the file? Is there a switch I can use to force the scanning & re-muxing of valid MKVs that is broken in the beginning? Or can you offer a "generic" chunk of binary data I can simply append or hexeditor copy to the beginning of the file to force mkvtools to scan, read, and fix the good portions of the file and create a viewable file? Thanks..

Mosu

12th May 2014, 08:12

If the track headers have been damaged: not really, no. First you'd have to know exactly which codecs were used for which track, which track had which track number etc. Then you'd also have to know the exact format of CodecPrivate for a lot of video codecs (which you don't, with almost absolute certainty). From a purely technical standpoint it is possible in some cases, of course, but it would take even someone with in-depth knowledge of Matroska an exorbitant amount of time (think several days for a single file).

If all the files use the very same tracks and the very same codecs with the very same codec settings then it may be possible to copy segment and track headers from another file to your damaged one. However, there's no tool that could automate this kind of work. It would look roughly like this:

Determine the start position and the length of the EBML head, segment info and the track headers elements in the working file and extract them to separate files
Determine the position of the first readable cluster (basically the first cluster ID followed by a length information after which another cluster ID can be found) in the bad file, remember that position
Copy the EBML head, segment info and track headers from step 1 into the new output file
Copy everything from the bad file starting at the position found in step 2 to the new output file
Edit the new output file and modify the segment element's length field to match the new file length (or set it to undefined)
Try to re-mux with mkvmerge or to watch the movie

All of those steps involve heavy work with hex editors, deep knowledge of EBML and Matroska structures, a lot of time and a lot of patience.

Simon88

12th May 2014, 15:00

Thanks for detailed explanation... I guess it'll be easier for me to just re-encode and/or re-capture them from the tape source...

btw, if the info for the header is so important and if bytes usage is insignificant, would you consider storing another copy of it at the end, or some other convenient place in a MKV file or provide an option to do so, if feasible, in a future specification update in order for increased robustness?

Mosu

12th May 2014, 15:15

Well it's only allowed for the track headers. Storing the EBML head or the segment head twice would pretty much bork the whole file.

Other media formats aren't any better. If you overwrite the first few KB in an AVI or an MP4 file then those files are just as unusable. Again other formats (especially MPEG transport streams) are more resilient by sending the required headers multiple times. They do it because they were explicitly designed for streaming in which you need to be able to join the stream at almost any moment. Matroska wasn't designed for this, and I highly doubt we'll ever adjust it in such a way. Resilience always has a cost: in terms of wasted space, but also in complexity for all software components that need to read such files. How are players supposed to act if they find two differing copies of track headers? What about editing track properties: if the second copy is somewhere in the middle and you enter a very, very long track name so that the track header copy won't fit there anymore; where do I store it now?

On top of all that you have to keep compatibility with existing players in mind.

So the answer is »most likely no«. Sorry.

If you need general resilience then I suggest using something like PAR files and storing them somewhere else (on different hard drives, at least).

Carpo

17th May 2014, 12:55

Is it possible to add movie information into the MKV container, like you can with MetaX and MP4 - apologies if this has already been asked

Simon88

17th May 2014, 22:15

Is it possible to add movie information into the MKV container, like you can with MetaX and MP4 - apologies if this has already been asked

"File/segment title" and "Attachments"... However, attachments must be crafted in way your front-end or viewer expects them...

Carpo

19th May 2014, 10:58

Simon88

19th May 2014, 16:49

The players in question would be MPC-HC, MPC-BE, J River and Playstation 3, I am guessing the PS3 wouldn't see any of it and to be honest I am not that concerned, as I may just stream directly from the PC to the TV anyway, guess I need to read MKVTool's documentation

If it's cover art, I believe it is explained at:
http://www.matroska.org/technical/cover_art/index.html

And some players use: Movie.nfo within the mkv to display misc. info.

Carpo

19th May 2014, 16:53

I know it can do cover art, I was hoping to add such things as, year, director, cast, summary, that sort of thing.

I have looked at the documentation and it seems like I should be able to add most of the above in an .xml file, but I haven't seen anything about adding a plot summary

sneaker_ger

19th May 2014, 17:02

http://matroska.org/technical/specs/tagging/index.html
"SUMMARY" might be what you're looking for.

You mentioned "MetaX". The website says it already has support for mkv tagging built-in.

Carpo

19th May 2014, 17:20

Thanks, will take a peek :)

Nico8583

22nd May 2014, 12:29

Hi,
I have a little question : I'm using MKVMerge 6.8.0 to merge MKV files with video h264, audio DTS or AC3 and subtitle sup files. Then I want to try to extract tracks from MKV to separated files so I use MKVExtract.
I have made a MD5 hash from source files (before mux) and extracted files (after demux) and there are differents (except for DTS track, MD5 are identical). Is it possible to extract tracks and obtain the same MD5 hash ?
Thanks !

sneaker_ger

22nd May 2014, 12:55

For H.264 this happens because mkvmerge does not remove the headers. When mkvextract extracts the stream it writes the header from the private field back into the bitstream without checking whether it already exists there. So with each H.264 ES -> mkvmerge -> mkvextract -> H.264 ES generation you will have the headers an additional time i.e. the checksums won't match. (Don't know about AC3 and sup.)

Nico8583

22nd May 2014, 13:31

Thanks for your explanation :)

Mosu

22nd May 2014, 14:00

That's not the only thing changed with h.264 bitstreams. Filler NALUs are removed as well.

For MP3 files ID3 tags are removed during muxing (both v1 and v2, both at the beginning and the end of the file). Same applies to AC3, AAC, TrueHD, TTA files. Generally all data that cannot be identified as a valid MP3 packet is dropped as well (similar for AC3; this applies mostly to audio read from AVI files where garbage is used for syncing audio tracks to the video track).

Nico8583

22nd May 2014, 14:14

sneaker_ger

22nd May 2014, 14:34

Thanks for this complement :)
So if I want to extract all tracks and remux a new MKV, is there a difference between original remuxed mkv and new remuxed mkv ?
Or if I want to add a new track on existing MKV, is it better to use mmg.exe and nothing will be lost (tracks, attachments, covers, mkv properties, chapters...) ?

On extract some information can be lost (e.g. timecodes) so usually you just load the original mkv directly into mmg if you want to add a track. It's also easier and requires less time and space. You do not get 100% the same mkv if you mux the raw streams again because some info in mkv must be randomized i.e. it will differ even if the raw source streams were identical.

Mah

5th June 2014, 21:36

Is it possible to change the position of subtitles in mkvmerge, so that I can move subtitles little higher, bottom of screen and than mux it with mkvmerge into mkv file?

Thanks for help.

Simon88

5th June 2014, 23:31

Is it possible to change the position of subtitles in mkvmerge, so that I can move subtitles little higher, bottom of screen and than mux it with mkvmerge into mkv file?

Thanks for help.

mkv files are simply a container, it is the job of the media player which controls how subs are positioned or displayed. Some subtitle formats such as SRT relies entirely on the player while ASS files has MUCH more advanced control of how subs are interpreted/displayed that is built into the format itself, although some players allows for the overriding of how subs are displayed, eg vobsubs... the mkv cropping option may offer some limited control though...

Mah

6th June 2014, 06:05

Simon88

6th June 2014, 15:58

Thanks for the answer... I edited SSA subtitles to my taste, but still on blu-ray player via USB it didn't help, because when merged via mkvmerge it didn't play SSA subtitles, but it played SSA subititles externally, but the position was the same as before (on the bottom), it didn't work... although on computer (on any software player), it worked.

Many hardware players have limited cpu & ram and strips most advanced subtitle features. An MKV is treated like any other container, only 1st video & 1st audio track is read. I believe many only interpret the timing & text of subs only. An external SRT or ASS/SSA are treated the same.

Your ONLY consistently reliable option is to hard code the subs onto the video stream.:(

Mosu

9th June 2014, 18:26

Hey,

I've released mkvtoolnix v7.0.0. It's a release that includes a couple of minor enhancements to mmg and mkvmerge and the usual bug fixes (nothing major – though some more cases of overly long file detection times have been fixed).

The most prominent change is that mkvmkerge will now write certain track-specific statistics (such as bit rate) as tags. See the ChangeLog for more details. Accompanying this change is that mkvmerge's verbose identification mode will now include the track's tags as well in order to make retrieving that information easier for other programs.

For packagers: this build requires Boost's Date/Time library.

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.9.1:

2014-06-09 Moritz Bunkus <moritz@bunkus.org>
* Released v7.0.0.

2014-05-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: In addition to the track statistics tags»BPS«, »DURATION«, »NUMBER_OF_BYTES« and »NUMBER_OF_FRAMES«mkvmerge will write two more tags identifying which application wrote the statistics (»_STATISTICS_WRITING_APP«) and when the file in question was written: »_STATISTICS_WRITING_DATE_UTC«.»_STATISTICS_WRITING_APP« will always contain the same string contained in the segment info header element »WritingApp«.»_STATISTICS_WRITING_DATE_UTC« will contain the same timestamp as in the segment info header element »Date«, though»_STATISTICS_WRITING_DATE_UTC« is actually a string representation instead of an integer value. Additionally a tag named »_STATISTICS_TAGS« is written containing the names of the tags that mkvmerge has set automatically. It equals the following currently: »BPS DURATION NUMBER_OF_BYTES NUMBER_OF_FRAMES«.
* build system: Boost's "date/time" library is now required.

2014-05-25 John Peebles <johnpeeb@gmail.com>
* mkvmerge: bug fix: If a single subtitle track contains two or more entries at the same timecode then the cue duration and cue relative position elements written were wrong.

2014-05-24 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: fixed wrong progress percentage shown during saving the information to text files. Fixes #1016 (https://www.bunkus.org/trac/ticket/1016).
* mkvmerge: new feature: Added a global option for disabling writing the tags with statistics for each track: --disable-track-specific-tags.

2014-05-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: When identifying a Matroska file in verbose identification mode track-specific tags will be output as well. The format is »tag_<tag name in lower case>:<tag value>», e.g. for a tag named »BPS« with the value »224000« the output would be »tag_bps:224000«. Enhancement for #1021 (https://www.bunkus.org/trac/ticket/1021).
* mkvmerge: new feature: mkvmerge will write track-specific tags with statistics (»BPS« for the average number of bits per second,»DURATION« for the duration, »NUMBER_OF_BYTES« and»NUMBER_OF_FRAMES« for the track's size in bytes and its number of frames/packets). Implements #1021 (https://www.bunkus.org/trac/ticket/1021).

2014-05-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Changed the file type detection order again. The text subtitle formats are now probed after those binary formats that can be detected quickly and unambiguously. This avoids some mis-detection if e.g. Matroska files as ASS text subtitles if they do contain such a track.
* mmg: enhancement: The chapter editor will only use fast-mode parsing when loading chapters from Matroska files.

2014-05-14 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: fixed invalid memory access in the cleanup procedures which only occurred if the output was redirected with the »--redirect-output« command line parameter.

2014-05-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The last chapter entry read from MPLS files is removed if it is at most five seconds long. Patch by Andrew Dvorak (see AUTHORS).
* mkvmerge: enhancement: added the attachment UID to the verbose identification output of Matroska files.

2014-04-21 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Selecting a subtitle track correctly sets the»character set« drop-down box if no character set was set for this track. Fixes #1008 (https://www.bunkus.org/trac/ticket/1008).
* mmg: enhancement: the subtitle character set cannot be set anymore for subtitle tracks read from Matroska files as mkvmerge ignores that setting for said container anyway (text subs are always encoded in UTF-8 in Matroska).

2014-04-20 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: mmg will look for the »mkvmerge« executable in the same directory as the »mmg« executable is located it if the location hasn't been set by the user on all operating systems (before: only on Windows). Improves detection if »mkvmerge« is not in the $PATH.

Have fun.

SeeMoreDigital

9th June 2014, 20:21

Nice one. Thanks Mosu :)

microchip8

9th June 2014, 21:30

Works fine on openSUSE 13.1. Thanks ;)

AYColumbia

10th June 2014, 03:06

Congrats on another major version and thank you. :)

mariner

15th June 2014, 18:06

Greetings.

Is there a way to combine splitting and appending (on multiple files) into one single operation?

Many thanks and best regards.

Simon88

16th June 2014, 00:45

Greetings.

Is there a way to combine splitting and appending (on multiple files) into one single operation?

Many thanks and best regards.

A batch loop using the FOR, IN, DO commands can do it easily, assuming using Windows...

Chetwood

16th June 2014, 15:38

Anyone else muxed 1 srt file with 7.0 but got 2 instead?

hubblec4

16th June 2014, 16:13

hi mosu

I'm not sure if this is the right topic.

I have made some tests with my chapterEditor and i found a small "issue" after muxing the parts of a movie with mmg.

I have used the splitting option with timecodes. first cut is 00:00:05.000, second cut 00:00:21.000, third cut 00:00:41.000. (you get 4 parts)
there is a forced subtitle track inside and one subtitle is shown from 00:00:20.000 to 00:00:23.000. after the cutting and muxing (appending) part 2 and part 4

the subtitle is shown after the 00:00:20.000 timecode but it is still shown till the end of the movie. when i jump to the "new" timecode 00:00:24.000 the subtitle is not shown anymore.

i guess the subtitle starttime 00:00:20.000 starts the subtitle correctly but there is no end-time for the sub after remuxing.

sneaker_ger

16th June 2014, 16:58

Anyone else muxed 1 srt file with 7.0 but got 2 instead?

No. Sample?
(Note that 7.0.0 writes tags with statistics as default. Maybe your application shows them as tracks?)

Mosu

16th June 2014, 18:40

I have made some tests with my chapterEditor and i found a small "issue" after muxing the parts of a movie with mmg.

I haven't noticed anything like that before. Can you please upload some sample files (preferably the one before splitting) to my FTP server so that I can take a look?

mariner

17th June 2014, 07:22

A batch loop using the FOR, IN, DO commands can do it easily, assuming using Windows...

No GUI?

Mosu

17th June 2014, 07:42

mariner

17th June 2014, 15:05

If you want to split first and append some of those files created by splitting afterwards then I strongly recommend the »split by parts« mode which can replace those two steps with a single one. See the documentation (https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split).

If you want to append first and split afterwards then those two things can be done in a single operation, too, of course. Just »add« your first file, »append« your second and following files, and activate splitting.

All of that can be done with mmg.

Thanks for the kind reply, Mosu.

I can't figure out how to apply the split timecode range to each individual file to be appended. For example, I'd like to append segment A from file 1 to segment B from file 2. How does one indicate which timecode range applies to which file?

Many thanks and best regards.

Mosu

17th June 2014, 15:19

Ah, now I understand what you want to do. That's not possible in a single step.

Mosu

17th June 2014, 15:24

Well, it is possible, but in a roundabout way. Add and append all files. Then use --split parts:, like I've said above. The tricky part is calculating the timecodes. For example, let's assume you have two files. The first one is 2 minutes long, the second one is 3 minutes long. You want 0:30 – 1:30 from the first file and 1:15–2:15 from the second file.

If you don't use splitting then the resulting file will be 5 minutes long. Now we can calculate which timestamps in the full output file correspond to the desired ranged in the source files.

Range 1: source file 1 0:30 – 1:30 is the same in the output file, of course.
Range 2: source file 2's own 0:00 corresponds to the duration of source file 1's last timecode, 2:00. So range 2 = 1:15 – 2:15 corresponds to the range 2:00 + 1:15–2:15 in the output file.

The resulting argument for --split parts: should be something like 00:30–01:30,03:15–04:15.

Simon88

17th June 2014, 16:31

No GUI?

One of the BEST feature of MKVToolNix is the show the command line... If I need to do something to a large group of files, whether using to MKVToolNix or any other tool, once you "see" the command line, it can be slightly modified w/ variables and it'll do it automatically in MULTIPLE steps, if needed. Most GUI's are just front ends to the command line, not very useful when complex tasks are needed.

Simon88

20th June 2014, 23:47

Hi Mosu,

I'm currently using the latest Hauppauge WinTV 7 CDv3.5 app to capture some over-the-air TV and latest MKVToolNix v7.00... The transport stream container can & often do contains an extra junk stream or two that I can easily remove & re-mux back to a TS file. However, I really like the flexibility of the MKV container & your excellent tool, MKVToolNix, that goes with it. I found that it has trouble detecting the MPEG-2 video portion and only found the audio, but I found a workaround by re-muxing w/ ffmpeg first. I also wanted to preserve the TWO closed captioning EIA-608 and EIA-708 streams... VLC plays the captioning perfectly as a TS file... In the mean time, I had to extract captions and convert them to an SRT file before re-muxing them into MKVs. It wold be great if I can also store the unmodified binary captioning info together w/ the SRT file I had extracted, so I can simply delete the TS file... That way, in the future, if I ever need to re-constitute the TS file, I can simply re-mux it and have the captioning streams intact... because closed captioning encoding gear are VERY expensive....

I know you aren't interested in doing any more MPEG-2 work, but I'm wondering if you will offer a way of storing closed captioning? As I understand it, future H.264/265 video standards will still use the same closed captioning formats. I only know that North America uses EIA-608/708 & Europe uses Teletext...

If you need short samples, I'll be happy to provide them to you for examination/testing (just tell me how many minutes to capture, where to upload it, and file-name to use...)...

Here's a short MediaInfo of a two minute capture...
General
ID : 1 (0x1)
Complete name : C:\Conversion\10.1_20140620_1525.ts
Format : MPEG-TS
File size : 310 MiB
Duration : 2mn 50s
Overall bit rate mode : Variable
Overall bit rate : 15.2 Mbps
Law rating : TV-PG

Video
ID : 256 (0x100)
Menu ID : 1 (0x1)
Format : MPEG Video
Commercial name : HDV 720p
Format version : Version 2
Format profile : Main@High
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=30
Codec ID : 2
Duration : 2mn 50s
Bit rate : 14.1 Mbps
Maximum bit rate : 15.6 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Active Format Description : Full frame 16:9 image
Frame rate : 59.940 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.255
Time code of first frame : 19:23:22:30
Time code source : Group of pictures header
Stream size : 287 MiB (93%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 257 (0x101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 129
Duration : 2mn 50s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -247ms
Stream size : 7.82 MiB (3%)
Language : English

Text #1
ID : 256 (0x100)-CC1
Menu ID : 1 (0x1)
Format : EIA-608
Muxing mode : A/53 / DTVCC Transport
Muxing mode, more info : Muxed in Video #1
Duration : 2mn 50s
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)

Text #2
ID : 256 (0x100)-1
Menu ID : 1 (0x1)
Format : EIA-708
Muxing mode : A/53 / DTVCC Transport
Muxing mode, more info : Muxed in Video #1
Duration : 2mn 50s
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)

Menu
ID : 4096 (0x1000)
Menu ID : 1 (0x1)
Duration : 2mn 50s
List : 256 (0x100) (MPEG Video) / 257 (0x101) (AC-3, English)
Language : / English
Service name : Service01
Service provider : FFmpeg
Service type : digital television
Law rating : TV-PG

Mosu

21st June 2014, 12:01

It wold be great if I can also store the unmodified binary captioning info together w/ the SRT file I had extracted, so I can simply delete the TS file...

I'm willing to work on reading CCs from M2TS files and converting them to SRT on the fly. What I will not do, though, is simply to store the binary data alongside with it. If you need something like that then you'll have to extract the CC sub-streams and attach them to the Matroska file manually.

Having a sample file or two would be nice, especially of both the EIA formats. I'd like to take you up on your offer. See the information in my signature for where to upload. Please name the file(s) something like closed-captions-….ts. Thanks.

I know you aren't interested in doing any more MPEG-2 work

Well… more or less, yes. I will take a look at the file and why mkvmerge doesn't recognize the track (as it generally does support MPEG-2 video read from M2TS files), but if it turns out to be too much effort to fix then I may possibly not do it.

, but I'm wondering if you will offer a way of storing closed captioning? As I understand it, future H.264/265 video standards will still use the same closed captioning formats. only know that North America uses EIA-608/708 & Europe uses Teletext...

Having a sample with Teletext would be nice, too, though as you're in America I don't expect you to fly to Europe just to capture one ;)

Thanks.

Simon88

23rd June 2014, 01:03

Hello Mosu,

I couldn't just upload one or two file but decided to send you a more representative sample. I had some trouble using FireFTP and had to install FileZilla instead. They are just two minutes long each. Their resolutions, framerates, and several important aspects all varies a bit between stations, so I deleted some of the ones that had blank closed captions, and a few has a SAP track, to display a second audio track for DVS, descriptive video service (for visually-impaired people), and some sticks a Spanish "subtitles" track in the English Audio programming.

CCextractor can process the CCs without issue, but certain aspects of the raw closed captioning are lost after conversion to SRT. eg, musical notes & symbols, extended unicode characters, screen positioning, and Chinese/Japanese/Korean characters are lost. RAW CC data appears to use VERY little space after zlib compression. VLC plays the RAW CC data without issue or the need for conversion as does a few others. I used VLC to play & verify the presence of the CCs in the TS files. These files I uploaded are RAW files, captures straight from the air with latest WinTV app, unaltered or "ts-doctored" in any way whatsoever for you to examine.

If you need longer samples, please let me know...:)

Nico8583

26th June 2014, 17:48

Hi,
I've made about 150 Blu ray with the same method but with 2 movies there is a problem.
I have encoded original H264 stream (from my original Blu ray) with DGMVCSource (for 3D version of Dragon Gate 3D) or DGIMDecode (for 2D version of Dragon Gate 3D) + AviSynth 2.5.8 + x264 and mux it with MKVToolnix 6.8.1 (but same issue with 7.0.0). For both movies, normal duration time is about 2 hours but when there are muxed in MKV, any player show a duration about 3 hours ! If I mux the same stream movie in M2TS with tsMuxer, duration is correct so I think there is a problem with MKVToolnix. Movies are "Dragon Gate 3D" and "Riddick" (French versions).
Could you help me ?
Thanks !

Mosu

27th June 2014, 09:35

I couldn't just upload one or two file but decided to send you a more representative sample.

Quite an impressive selection. Thank you very much!

Mosu

27th June 2014, 09:37

HFor both movies, normal duration time is about 2 hours but when there are muxed in MKV, any player show a duration about 3 hours !

I have no idea what the issue might be, especially if the very same method leads to correct results in so many more cases. Without access to the files in question (meaning the Blu-rays, unfortunately) I cannot really comment further on this.

Nico8583

27th June 2014, 12:37

I'll try to encode again but I think it will be the same issue :(

Frozen Fractals

4th July 2014, 02:48

Quick question. Why does 7.0.0 add extra tags (viewed using MediaInfo Lite) and how to get rid of them?

DURATION : 01:18:26.285000000
NUMBER_OF_FRAMES : 112836
NUMBER_OF_BYTES : 7824617775
_STATISTICS_WRITING_APP : mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 9 2014 15:16:27
_STATISTICS_WRITING_DATE_UTC : 2014-07-04 04:35:51
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Before it was like this:

General
Unique ID : 232382587752882843431441932852508950773 (0xAED342288477565E80B727CC5C9B00F5)
Complete name : E:\Pirates of the Caribbean_ Dead Man's Chest (1080p HD) (1).mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 7.29 GiB
Duration : 1h 18mn
Overall bit rate : 13.3 Mbps
Encoded date : UTC 2014-07-04 04:35:51
Writing application : mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 9 2014 15:16:27
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 18mn
Bit rate : 12.9 Mbps
Width : 1 920 pixels
Height : 802 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.350
Stream size : 7.14 GiB (98%)
Writing library : x264 core 133 r2334 a3ac64b
Encoding settings : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=12 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=90 / rc=2pass / mbtree=1 / bitrate=12918 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No

Thanks :)

Sparktank

4th July 2014, 03:17

Quick question. Why does 7.0.0 add extra tags (viewed using MediaInfo Lite) and how to get rid of them?

IIRC, those new tags are only added when invoked with "-v" (verbose) command.

Have you added "-v" to your command line (or batch scripts)?
Or to the mmg preferences?
"Add command line options"
-> "-v"
-> "Save as default for new jobs"

They don't take up much space and shouldn't affect playback on any software/hardware. Not that I've noticed.

If you read the changelog for v7.0.0, you'd find out more information on the new tags.

Chetwood

4th July 2014, 04:33

Why does 7.0.0 add extra tags ?

Why not read the changlog before updating?

I've released mkvtoolnix v7.0.0. It's a release that includes a couple of minor enhancements to mmg and mkvmerge and the usual bug fixes (nothing major – though some more cases of overly long file detection times have been fixed).

The most prominent change is that mkvmkerge will now write certain track-specific statistics (such as bit rate) as tags. See the ChangeLog for more details. Accompanying this change is that mkvmerge's verbose identification mode will now include the track's tags as well in order to make retrieving that information easier for other programs.

Frozen Fractals

4th July 2014, 05:59

IIRC, those new tags are only added when invoked with "-v" (verbose) command.

Have you added "-v" to your command line (or batch scripts)?
Or to the mmg preferences?
"Add command line options"
-> "-v"
-> "Save as default for new jobs"

They don't take up much space and shouldn't affect playback on any software/hardware. Not that I've noticed.

If you read the changelog for v7.0.0, you'd find out more information on the new tags.
No, I don't think I have. It's a vanilla install of mkvtoolnix. I am using the GUI and currently using "--disable-track-statistics-tags" to get rid of them, but it seems to be a stopgap solution. Unfortunately, it also rids of the information about the writing library and encoder settings. I mean...I don't mind the extra tags being there, it's just my OCD is getting to me with it having all the uppercase letters and underscores. :scared:
Why not read the changlog before updating?
I did...that's why I am asking about how to get rid of them.

Sparktank

4th July 2014, 06:15

Just did a test remux without invoking "-v" anywhere in the GUI.
It does the tags, regardless.

it's just my OCD

:rolleyes:

Mosu

4th July 2014, 07:23

Those tags have nothing to do with any verbosity (-v) setting.

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

Mosu

4th July 2014, 07:27

No, I don't think I have. It's a vanilla install of mkvtoolnix. I am using the GUI and currently using "--disable-track-statistics-tags" to get rid of them, but it seems to be a stopgap solution. Unfortunately, it also rids of the information about the writing library and encoder settings.

This is wrong. Either you're not looking in the right place or the application you're using has fucked up the »no statistics tags« case.

Regardless of any command line option used mkvmerge always writes the »writing app« and »muxing app« header elements (»header elements« being the important bit here).

Since 7.0.0 mkvmerge will also write those new tags, and one of those tags contains the information which application created those statistics tags (»_STATISTICS_WRITING_APP«). mkvmerge sets this to the same value that it writes into the header element »writing app«. But, again, even with »--disable-track-statistics-tags« the header elements will still be set to the usual values which you can verify easily with mkvinfo.

Sparktank

4th July 2014, 10:01

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

Bookmarked. I don't read through that site as often as I should.

Mosu

4th July 2014, 10:05

To be fair that particular FAQ entry is only a couple of days old.

gendalv

4th July 2014, 16:30

i'm using mkvtoolnix 5.8.0 gui.
10 queued simple tasks (adding srt subtitles into mkv containers)

there isn't enough space on my disk to complete all of the tasks, but there is on another disk, so in File->settings I change it from saving to the same folder - to exact folder on another disk

but it still saves into the same folder, is there a way to change which folder previously queued tasks output files?

Mosu

4th July 2014, 20:45

The »default folder« setting is only relevant when you add the very first file to a new muxing job (to be more precise: the output file name will only be set automatically when you add a file if the output file name is empty in that moment). Therefore changing this setting doesn't affect existing jobs.

You can, though, simply edit the job files; they're only text files, after all. They're stored in C:\Users\YourUserName\AppData\Roaming\mkvtoolnix\jobs.

Frozen Fractals

5th July 2014, 00:29

This is wrong. Either you're not looking in the right place or the application you're using has fucked up the »no statistics tags« case.

Regardless of any command line option used mkvmerge always writes the »writing app« and »muxing app« header elements (»header elements« being the important bit here).

Since 7.0.0 mkvmerge will also write those new tags, and one of those tags contains the information which application created those statistics tags (»_STATISTICS_WRITING_APP«). mkvmerge sets this to the same value that it writes into the header element »writing app«. But, again, even with »--disable-track-statistics-tags« the header elements will still be set to the usual values which you can verify easily with mkvinfo.
Ah, yes..I meant to go back and edit my post. It DOES NOT rid of the encoder information like I stated above. Indeed it does keep it and I was lead to believe it was removed because the particular file I tested it on did not have the tags to begin with in the first place. "--disable-track-statistics-tags" in fact only rids of the new "tags" found in v7. Thanks for the info.

SeeMoreDigital

5th July 2014, 11:04

Could a 'check box' be added to more quickly enable/disable these new meta-data lines?

Mosu

5th July 2014, 12:07

I won't do that, sorry.

nautilus7

5th July 2014, 12:42

Hi, I have some satellite broadcasts (World Cup EBU feeds) that mkvmerge can't properly detect and remux the 3rd audio track. LAV filters can't decode that track properly so maybe there's something with the track. Here's a sample (https://www.sendspace.com/file/gulxjy) of such broadcast. Can you have a look, please?

SeeMoreDigital

5th July 2014, 13:02

According to MediaInfo, there are 5No audio streams in your sample ;)

filler56789

5th July 2014, 13:03

^ According to MediaInfo, that sample file contains a "Dolby E" audio stream. TSmuxer doesn't like it, and eac3to detects it as "RAW/PCM".

nautilus7

5th July 2014, 14:10

Yes, it should be "Dolby E" (it says so at the bottom of the video stream). What is Dolby E?

filler56789

5th July 2014, 14:23

It's something to bring more complication to our lives :)

http://wiki.multimedia.cx/index.php?title=Dolby_E

nautilus7

5th July 2014, 14:55

I see thanks.

Chetwood

6th July 2014, 06:26

Could a 'check box' be added to more quickly enable/disable these new meta-data lines?
I always add it to the command-line options and save as default for new jobs. Currently I'm using

--engage no_cue_duration --engage no_cue_relative_position --disable-track-statistics-tags

to be on the safe side when it comes to hardware players.

SeeMoreDigital

6th July 2014, 09:53

Currently I'm using

--engage no_cue_duration --engage no_cue_relative_position --disable-track-statistics-tags

to be on the safe side when it comes to hardware players.

Good idea, many thanks Chetwood :)

Mosu

6th July 2014, 11:34

Dolby E is currently not supported by mkvmerge. At the moment I have no plans for adding support, though I most certainly don't rule it out.

SeeMoreDigital

6th July 2014, 12:18

Dolby E is currently not supported by mkvmerge. At the moment I have no plans for adding support, though I most certainly don't rule it out.As far as I'm aware, Dolby E has been designed for commercial distribution purposes. So even if you did include support for it someone would need to design a suitable splitter and decoder for it too... Unless one already exists!

nautilus7

6th July 2014, 12:48

ffmpeg/lav doesn't support it?

Simon88

6th July 2014, 19:19

Hi Mosu,

I was playing with some ATSC TS files the other day, and after muxing them into a MKV file, the user data area is no longer available for VLC to decode/display the closed captioning. Perhaps it is the job of the media player to detect the closed captioning, I thought. So,I also tried verifying this by mkvextracting the mpg from the mkv file and the file also no longer have the closed captioning information. Has mkvtoolsnix inadvertently stripped the user data away or was it labeled incorrectly during extraction that they no longer are understood by media players which supports closed captioning?

Mosu

6th July 2014, 19:43

Closed captions are currently not supported by mkvmerge, and as they're separate streams inside the TS they won't be copied into the Matroska file.

Korgnex

10th July 2014, 10:55

Since version 7.0.0 something strange is happening when you mux a file:

When you remove an audio or subtitle track (eg removing any additional audio or subtitle language that you don't want to keep), after the file has been (re-)muxed successfully and you put it again into mkvmerge GUI to take a look at it, it will show ADDITIONAL tag tracks for EVERY remaining track - which you can't get rid of (because if you mux it again, they will just pop up AGAIN).

Eg if your file now consists of 1 video and 1 audio track, the mkvmerge GUI will show TWO additional tag tracks:
tags for track-ID 01
tags for track-ID 02

BUT there are no actual tags anywhere in the video or audio tracks, so why are these showing up since version 7.0.0??

Mosu

10th July 2014, 11:07

Pro tip: always read the ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog). Additionally it's helpful to read some of the recent posts (http://forum.doom9.org/showthread.php?p=1685722#post1685722) in this very thread.

If those don't answer your question then I also recommend reading the fine FAQ entry I've written about this very topic (https://trac.bunkus.org/wiki/FAQ%3AAutomaticTagGeneration). If all else fails you could still search for it (http://bit.ly/1raAXay).

Of course you're also free to register in this forum and ask this question without doing any of the above. Don't be surprised if the answers might be somewhat snarky, though.

sneaker_ger

10th July 2014, 15:33

mkvmerge 7.0.0 writes some tags even for webm output:
DURATION : 00:01:00.080000000
NUMBER_OF_FRAMES : 3004
NUMBER_OF_BYTES : 698325
_STATISTICS_WRITING_APP : mkvmerge v7.0.0 ('Where We Going') 32bit built on Jun 9 2014 15:08:34
_STATISTICS_WRITING_DATE_UTC : 2014-07-10 14:27:08
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

I cannot play those files in Chrome (or Chromium based Opera) and suspect this might be the cause.
From mkvmerge doc:
-w, --webm
Create a WebM compliant file. This is also turned on if the output file name's extension is "webm". This mode enforces several restrictions. The only allowed codecs are VP8 video and Vorbis audio tracks. Neither chapters nor tags are allowed. The DocType header item is changed to "webm".
(Doc should also be updated for VP9 and Opus?)

Mosu

10th July 2014, 15:37

Meh, that is indeed a bug. Thanks for reporting it; I will fix it for the next release.

sneaker_ger

10th July 2014, 16:07

After checking out 6.9.1 again: It's not the cause of Chrome's/Opera's failure to open such files. Any ideas?

About the tags:
It seems people are getting confused as these tags appear like tracks in mmg. UI clearness suffers as I see it. Instead of people turning them off (and losing debug info in turn) maybe mmg should simply not list them by default?

Mosu

10th July 2014, 16:20

I have to admit that I haven't thought of how mmg presents those tags. I will have to think about how to handle this. I will probably change mkvmerge to not list statistics tags as being track tags at all.

sneaker_ger

10th July 2014, 23:37

I only looked at the mkvmerge doc at first but looking at the WebM page tagging seems to be supported now after all. I'm not sure if only "official" WebM tags or all tags. The specs are kinda vague. Enabling them in their current form (with TrackUID != 0) would at least be against their recommendation, though, so turning them off looks like a good decision for the time being.

http://www.webmproject.org/docs/container/#tagging
http://wiki.webmproject.org/webm-metadata/global-metadata#TOC-Official-Tags

vid.user

26th July 2014, 02:44

I noticed a slight language parsing output anomaly I hope you can take a look at. Using mkvmerge GUI v7.0.0 (x64) on Windows 8.1 (x64), if I leave (or set) any of the track (video|audio|subtitle) languages to English (eng) then that language information is not displayed within the output of MKVINFO. If I set it to any other language then yes, I get the language when displaying the file information using MKVINFO.

I looked at the 'Muxing|Show the command line' option which seemed to be correct, displaying:
"--language" "1:eng" if I set to English or
"--language" "1:rus" if I set to Russian.

MKVINFO output would show:
| + Language: rus
but would never display:
| + Language: eng

Thanks for your time.

bobp

26th July 2014, 03:49

vid.user

26th July 2014, 04:14

@bobp:
Interesting.... and a big thanks.

Mosu

27th July 2014, 17:03

Hey,

I've released mkvtoolnix v7.1.0. It fixes a few minor issues. Probably the most important fix is that the new statistics tags introduced with v7.0.0 aren't written to WebM files anymore as the WebM specs currently don't allow tags.

For packagers: nothing has changed since v7.0.0.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-7.1.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

All of the Linux binaries that I provide have already been built and
are available.

Here's the full ChangeLog since release 7.0.0:

2014-07-27 Moritz Bunkus <moritz@bunkus.org>
* Released v7.1.0.
* all: bug fix: Fixed file seeking code for »seek relative to end of file« case. Fixes #1035 (https://www.bunkus.org/trac/ticket/1035).
* mmg: bug fix: Selecting the root of the chapter editor tree will disable the language/country inputs properly as changing those fields doesn't make sense for the root.

2014-07-26 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: if MKVToolNix on Windows is residing in a directory containing non-ASCII characters then translations weren't found. This has only been fixed for cases where those non-ASCII characters are part of the system's active code page.

2014-07-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: track statistics tags are not written for WebM files anymore as the WebM specification doesn't allow tags.

2014-07-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed wrong default duration for PCM audio tracks if the source file provides timecodes for that track. Fixes #1001 (https://www.bunkus.org/trac/ticket/1001) and #1033 (https://www.bunkus.org/trac/ticket/1033).

2014-06-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: SSA/ASS: in addition to semicolons comments can now start with exclamation marks, too.

2014-06-11 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Fixed a crash when opening damaged/invalid Matroska files in all extraction modes. Fixes #1027 (https://www.bunkus.org/trac/ticket/1027).

Have fun.

filler56789

27th July 2014, 17:11

Thanks a lot :thanks:

Gravitator

28th July 2014, 16:21

Привет!
Why mkvmerge does not accept prores.mov files?
> sample (http://files.videohelp.com/u/227452/prores%20(sample).mov)

SeeMoreDigital

28th July 2014, 17:02

Привет!
Why mkvmerge does not accept prores.mov files?
> sample (http://files.videohelp.com/u/227452/prores%20(sample).mov)
Yes... I've been meaning to mention this too...

As a work-around I've been re-muxing ProRes.mov to ProRes.avi (using MPEG StreamClip 1.2). Then ProRes.avi to ProRes.mkv using MKVmerge GUI.

Simon88

28th July 2014, 17:03

Привет!
Why mkvmerge does not accept prores.mov files?
> sample (http://files.videohelp.com/u/227452/prores%20(sample).mov)
Proprietary & lossy for post-production use:
http://en.wikipedia.org/wiki/Apple_ProRes

Simon88

31st July 2014, 22:52

I was looking at some files w/ MediaInfo and what happens bitstream AR is removed, etc...

I was wondering if there is a corresponding command-line option for "--engage remove_bitstream_ar_info"

for example.. "--engage insert_bitstream_ar_info"

sneaker_ger

1st August 2014, 07:22

Simon88

1st August 2014, 15:14

H.264 bitstream AR is not removed by default so there is no need for such an option. Maybe you're misinterpreting MedieInfo's output. Or are you looking for a feature to actually write/change the H.264 stream to match the AR option chosen in mkvmerge? That does not exist indeed.

When I did the "--engage remove_bitstream_ar_info", it causes the Original AR to be calculated from "square" pixels. eg. 352x288p = ~1.222:1 rather than the original intended non-square AR of 4:3 or even the really stretched pixel AR of 16:9. These probably should've been encoded to 640x360p

These were definitely "improper" encodes, but I just wished I could re-insert the proper AR into BOTH the bitstream & the mkv container on many of my older encodes w/o the need for re-encoding. Apps that use such info wouldn't be confused.

A command that can mirror the mkv container AR into the bitstream AR would fix this issue which I sometimes run into.

Boulder

1st August 2014, 15:52

I'm not sure if I follow what you are looking for, but I've sometimes had to use H.264 Aspect Ratio Modifier to correct some streams if I've made a mistake while encoding.

Simon88

1st August 2014, 16:14

I'm not sure if I follow what you are looking for, but I've sometimes had to use H.264 Aspect Ratio Modifier to correct some streams if I've made a mistake while encoding.

Thanks for the info Boulder... I did a search and it appears to work with AVI files mostly... but the other day I did some tests using Ffmpeg and it appears to offer this capability... Having it within MKVTools's "Add command line options" would make it a whole lot easier and I could just set it in my batch file and forget about it, without the need to peek into the file first when re-muxing. I still MUCH prefer the MKVTools MKV creater to that of FFmpeg's.

Boulder

1st August 2014, 16:33

It needs an elementary h.264 stream so if you happen to use it, you need to extract that from the container.

You could create a batch file to mux with ffmpeg and remux with mkvmerge if you like ;)

Simon88

1st August 2014, 16:49

It needs an elementary h.264 stream so if you happen to use it, you need to extract that from the container.

You could create a batch file to mux with ffmpeg and remux with mkvmerge if you like ;)

Yeah, that was my thinking as well... I just didn't want to double the time and double the wear & tear on my HDD if a single command in MKVTools can re-write the AR for BOTH bitstream & container at the same time while muxing, whether needed or not, without the need for Ffmpeg :(...

AYColumbia

2nd August 2014, 00:23

Yes... I've been meaning to mention this too...

As a work-around I've been re-muxing ProRes.mov to ProRes.avi (using MPEG StreamClip 1.2). Then ProRes.avi to ProRes.mkv using MKVmerge GUI.
Another option; my camera creates MOV files and I use tsmuxer to demux and then remux to MKV. But yeah, it would be sweet if mkvmerge supported the MOV container. So +1 for that feature. :)

Mosu

2nd August 2014, 12:07

MOV in general is supported, though not all of the codecs that can be stored in there. I have no plans for adding ProRes support at the moment.

SeeMoreDigital

4th August 2014, 15:33

Another option; my camera creates MOV files and I use tsmuxer to demux and then remux to MKV. As far as I'm aware... TSmuxer is capable of accepting MPEG-1, MPEG-2 and MPEG-4 Part-10 video placed within the .MOV container, but not ProRes video placed within the .MOV container.

AYColumbia

4th August 2014, 23:48

As far as I'm aware... TSmuxer is capable of accepting MPEG-1, MPEG-2 and MPEG-4 Part-10 video placed within the .MOV container, but not ProRes video placed within the .MOV container.
Yeah, that was my bad as I glazed over ProRes. Sorry about that.

hello_hello

5th August 2014, 07:54

I believe the answer is available here: https://trac.bunkus.org/wiki/FAQ%3AElementsNotShowingUpInOutputFile

Basically since 'eng' is the default track language, mkvmerge won't write it to the file.

I'd kind of forgotten about that myself, but.....

If you set the language for a track to "English" when muxing, and MKVMerge doesn't write the language element, how does MediaInfo distinguish between a track which was muxed using "English" and a track which was muxed with the language element as "undefined"? Or is MKVMerge removing an existing "undefined" language element when you set the language to "English"?

sneaker_ger

5th August 2014, 09:10

Or is MKVMerge removing an existing "undefined" language element when you set the language to "English"?
Yes.
Basically you can have the following possibilies:
no language element -> means "English"
"eng" language element -> means "English"
"und" language element -> means "undefined"

cyberbeing

7th August 2014, 09:24

Mosu, is there a reason why mkvtoolnix must refuse to accept and process sources missing a TrackUID? Having a warning is fine, but this seems like one of those things which would be trivial to just ignore by default, assign a temporary TrackUID when parsing/demuxing, and just repair automatically when muxing. The current workaround is just to manually add a TrackUI with mkvpropedit/header-editor, but that seems like an unnecessary extra step.

The muxer in question which generates these single-track Video-only files missing a TrackUID, is that Whammy Javascript-based WebM encoder. A quick google search seems to suggest this issue has existed for a couple years now, and was never fixed upstream. Not a big issue to me personally, but still a bit of an annoyance from an end-user perspective when I run across websites or userscripts making use of this Whammy muxer.

Mosu

7th August 2014, 12:56

I think the reason is simply that I haven't run across such a file before. Back in the days of implementing Matroska for the first time I was using the track number element for track selection in the command line options (you know, the »123« in »--language 123:eng«). However, it turned out that too many programs were writing broken files and were assigned track numbers multiple times within the same file, hence making them impossible to use for track identification.

Can you please open a ticket in my bug tracker (https://trac.bunkus.org)? This is definitely something I will want to fix, but I will be going on vacation soon and might forget about it otherwise.

cyberbeing

9th August 2014, 05:43

Can you please open a ticket in my bug tracker (https://trac.bunkus.org)? This is definitely something I will want to fix, but I will be going on vacation soon and might forget about it otherwise.
You seem to have a permission problem with newly created Trac accounts which prevents creation of tickets. Upon registering and verifying email for a new account, there is no visible link for ticket creation, and going directly to https://trac.bunkus.org/newticket result in a forbidden error while logged in: TICKET_CREATE privileges are required to perform this operation. You don't have the required permissions.

hello_hello

9th August 2014, 08:10

Yes.
Basically you can have the following possibilies:
no language element -> means "English"
"eng" language element -> means "English"
"und" language element -> means "undefined"

If you add a single elementary stream to MKVMergeGUI (raw avc for example) and simply mux it, there's nothing I can see in respect to the language in the command line ("Muxing/Show the commandline" menu), but if you click on the drop down list and select "undefined", which is the default anyway, the following is added:
"--language" "0:und"
With or without it though, an undefined language element is written.

Does the above mean MKVMergeGUI doesn't follow the Matroska specification exactly? Logically, if I open an MKV containing a bunch of tracks without a language element, MKVMergeGUI should default to displaying English for each. The Header Editor does just that, but MKVMergeGUI defaults to "undetermined" and forces you to manually specify English. Maybe if it didn't, it appear to be defaulting to English so it's a kind of workaround for the Matroska spec. For people who'd generally use another language I could see that being inconvenient, so instead MKVMergeGUI defaults to "undetermined", making it equally inconvenient for everyone. ;)

I still think letting the user select a language for MKVMergeGUI to default to if there's no language element present would be a better idea, and/or maybe a default language for when the element is "undetermined", although I know Mosu disagrees.

Mosu

9th August 2014, 08:53

You seem to have a permission problem with newly created Trac accounts which prevents creation of tickets. Upon registering and verifying email for a new account, there is no visible link for ticket creation, and going directly to https://trac.bunkus.org/newticket result in a forbidden error while logged in: TICKET_CREATE privileges are required to perform this operation. You don't have the required permissions.

Yeah, I'm having intermittent problems with spammers. I therefore turn on the need for manual administrator approval of each newly registered account. Unfortunately I had forgotten I did that and in turn didn't authorize accounts… I've approved your account just now and turned manual authorization off for the time being.

Mosu

9th August 2014, 09:01

If you add a single elementary stream to MKVMergeGUI (raw avc for example) and simply mux it, there's nothing I can see in respect to the language in the command line ("Muxing/Show the commandline" menu), but if you click on the drop down list and select "undefined", which is the default anyway, the following is added:
"--language" "0:und"
With or without it though, an undefined language element is written.

Not exactly true. If you don't specify a language then mkvmerge will try to keep the source's language intact if there is one (e.g. if you read the track from another Matroska file or from a VobSub file).

If the source doesn't provide a language then mkvmerge defaults to »undefined«.

Does the above mean MKVMergeGUI doesn't follow the Matroska specification exactly? Logically, if I open an MKV containing a bunch of tracks without a language element, MKVMergeGUI should default to displaying English for each. The Header Editor does just that, but MKVMergeGUI defaults to "undetermined" and forces you to manually specify English.

This is not true. If a source Matroska file doesn't contain a »language« element then both mkvmerge and mmg assume it is set to »English«. You can try to re-create this easily:

Create a Matroska file with a single track from something and set the language manually to »English«
Restart mmg
Add the file you've just created and observe how mmg sets the language selection for that track

In step 1 you've created a Matroska file whose single track doesn't contain a language element. But mmg will still set that track to »English« when you add the file because that's what the track's language is logically set to according to the specs.

However, if the source file does not provide a language (e.g. if you add an SRT or AC3 file) then mmg defaults to »undefined«. This has nothing to do with the Matroska specs as the specs do NOT say that all tracks must default to »English«! They only say that the language element defaults to »English« if it is missing from the file. That's all.

hello_hello

10th August 2014, 14:09

If the source doesn't provide a language then mkvmerge defaults to »undefined«.

That's what I said, I think. :)

This is not true. If a source Matroska file doesn't contain a »language« element then both mkvmerge and mmg assume it is set to »English«. You can try to re-create this easily:

You're correct and I was 100%, totally and completely wrong. I don't know what I was thinking......
Maybe I opened the wrong MKV with MKVMergeGUI and it was the one containing the undefined elements instead of no elements at all. Sorry.

Thunderbolt8

10th August 2014, 17:34

I want to transfer jobs I created for the job queue with mkvmerge from one computer to another. how can I do that?

I tried copying the .mmg files from the user/appdata/roaming/mkvtoolnix folder from the first PC into the same folder on the 2nd. But those files werent added to the manage jobs window in mkvmerge on the other PC.

Mosu

10th August 2014, 17:52

mmg also stores information about the jobs in the registry (for the installed version; for portable it's in the .ini file). It's the »jobs« sub-tree of HKCU\Software\mkvmergeGUI. That sub-tree (respectively all the sections from the .ini whose names start with »jobs« for the portable version) has to be copied as well.

rhaz

11th August 2014, 17:25

Hi. How do I limit mmg.exe mux speed, it is killing my 5400RPM HDD. Impossible to use computer while muxing 10GB files. Cheers.

Simon88

11th August 2014, 17:46

Hi. How do I limit mmg.exe mux speed, it is killing my 5400RPM HDD. Impossible to use computer while muxing 10GB files. Cheers.

Some Win apps such as archivers & gui-encoders, when minimized will lower priority into a low priority background app. or use fewer cpu cores. For mmg.exe, you'll have to set the priority in the OS task manager.

Also many motherboard chipsets are crippled in a way that consumes the cpu 90%+ when HDD is busy. Only way around it is buying a high performance RAID HDD controller which has its own memory and controller chips that offloads most tasks away from the cpu.

cyberbeing

11th August 2014, 17:56

For mmg.exe, you'll have to set the priority in the OS task manager.

mmg.exe actually has a 'Process priority' setting for mkvmerge under File>Options>mkvmerge for controlling this. According to the tool-tip if you set that option to 'Lowest', mmg to also set low I/O priority, which is what rhaz likely requires to reduce HDD impact.

Simon88

11th August 2014, 18:01

mmg.exe actually has a 'Process priority' setting for mkvmerge under File>Options>mkvmerge for controlling this. According to the tool-tip if you set that option to 'Lowest', mmg to also set low I/O priority, which is what rhaz likely requires to reduce HDD impact.

Your right, I rarely every use the GUI, only to grab the "command line". But, I just checked my system just now and mmg.exe uses very little cpu. He may need try using an SSD drive.

Boulder

11th August 2014, 18:04

Setting any priorities will help very little. The program will happily use whatever resources are available unless some other program requests for the same resource but has a higher priority. Sounds to me that some kind of I/O throttling is requested but I'd say it's very hard if not impossible to implement such a thing inside a program. Sounds more like a job for the OS.

Mosu

11th August 2014, 22:21

As others have pointed out you can set the process priority to "lowest" which will also set a lower I/O priority. The advantage is that other programs you use simultaneously will receive more I/O bandwidth which may alleviate your problem somewhat.

mkvmerge doesn't have a real throttling mechanism for adjusting the maximum I/O bandwidth.

Also : the mmg process itself should never use much CPU. It's just the frontend that controls mkvmerge. mkvmerge is the processdoing all rthe heavy lifting requiring CPU and I/O power.

delacroixp

12th August 2014, 10:05

Hi. How do I limit mmg.exe mux speed, it is killing my 5400RPM HDD. Impossible to use computer while muxing 10GB files. Cheers.
Also many motherboard chipsets are crippled in a way that consumes the cpu 90%+ when HDD is busy. Only way around it is buying a high performance RAID HDD controller which has its own memory and controller chips that offloads most tasks away from the cpu.
Muxing a 10GB file on an old PC is a major challenge.
Green 5400rpm HDD's (vs 7200rpm) are faced with a similar challenge.

That said ... installing a 2nd HDD (even an old 75GB model) will act like RAID if you mux over the 2 HDD's.
WRITE is more intense than READ ... so mux from C: to D:
A 3rd drive will marginally improve your situation still further since windows and other programs utilise the C: drive.
Once done, you can even move the 'paging file' to the new drive ... for a nice performance improvement overall.

Muxing, is a low CPU but a high HDD usage operation.
(It's little more than a copy operation in most cases)

It's all good
:):devil::D
Pascal

Simon88

12th August 2014, 20:27

Muxing a 10GB file on an old PC is a major challenge.
Green 5400rpm HDD's (vs 7200rpm) are faced with a similar challenge.

That said ... installing a 2nd HDD (even an old 75GB model) will act like RAID if you mux over the 2 HDD's.
WRITE is more intense than READ ... so mux from C: to D:
A 3rd drive will marginally improve your situation still further since windows and other programs utilise the C: drive.
Once done, you can even move the 'paging file' to the new drive ... for a nice performance improvement overall.

Muxing, is a low CPU but a high HDD usage operation.
(It's little more than a copy operation in most cases)

It's all good
:):devil::D
Pascal

I've noticed many low CPU, but HDD intensive operations can literally freeze some computer, but not others. Such as database manupulation or re-muxing. Sometimes an updated chipset+sata controller driver "may" fix it, but on other times it's just the way the controller/driver operates for that particular motherboard. Most newer well reviewed motherboards shouldn't do this. I've seen this behavior on some HP/Compaq or other pre-configured home computer systems. In the past HP and others almost always uses an OEM/crippled versions a budget ASUS motherboard. However buying a $100+ or so RAID controller will almost always fix this for me. Hence, it is often cheaper just to replace the motherboard. Of course, using two separate HDD will lessen the HDD bottleneck, as well.

foxyshadis

13th August 2014, 02:32

These days you can get 3TB for $100 (or 2 1TB for $100) or you can get a network-attached NAS for only a bit more, so it's hardly worth it. Each version of Windows also significantly improves default I/O priority, with 8.1 you can hardly tell anything's happening. I'll recommend everyone buy an SSD these days, too, they're becoming dirt cheap (though getting one into a laptop without sacrificing capacity is tricky, unless you settle for external storage).

rhaz

16th August 2014, 11:37

Lol, you guys still arguing about it. I got another question. How do you add an audio alert when muxing is complete? E.g. when eac2to command line finish the process it makes sound alert, really useful when away from keyboard.

Mosu

16th August 2014, 12:50

There's currently nothing in mmg for such a purpose. You could always run mkvmerge and some audio player from a batch file, of course.

Chetwood

17th August 2014, 06:44

How do you add an audio alert when muxing is complete?
We've been over this (http://forum.doom9.org/showthread.php?p=1668297#post1668297) and it doesn't look pretty :(

Simon88

26th August 2014, 02:44

Hi Mosu,

I was wondering if it would be possible to add another way of inputing aspect ratio in mkvtools? You currently have two ways in the GUI -- "Display width/height" and "DAR"...

Since (PAR) = (DAR)/(SAR), I'm wondering if it is possible to use PAR as an input method?

It is very easy to remember, and square pixels are always 1:1... It is especially useful and easy to calculate when dealing with subtitles that occupy its own area of the screen.

Thanks...

Sparktank

26th August 2014, 04:31

For playing simple WAV files from command-line (if media players cause a hassle), you can always use "sounder.exe" to play a WAV from the command line.
http://www.elifulkerson.com/projects/commandline-wav-player.php

[code]mmg ...batch commands...
sounder "C:\Bin\SFX\Star Trek\Romulan Hail Screen.wav"
[code]

It works great for batch processes.

MMG also has an option at the top of the menu bar where you can copy the command operation to clipboard, file, etc.
So there's plenty of options.

MeridiusUK

31st August 2014, 08:15

Hi all, just wanted to report a bug that I noticed with MKVToolNix 7.1.0 64bit on windows 7 intel chip.

It does not support multi monitors like older versions did what I mean is if I movie MKVToolNix to anything other than the primary monitor (centre) it does not stay there it tries to put itself back to the centre primary monitor. it will not save its position unless I use the centre monitor and it saves its positions all the time but soon as I move it to another monitor and reload it it goes back to the centre monitor. the older versions did not have this problem as I upgraded from 6.3.

just hope it can be fixed in the new versions

thanks

Mosu

31st August 2014, 08:41

I don't work on the old GUI anymore as I'm re-writing it with a different toolkit. I'm pretty sure that remembering the correct position in a multi-monitor setup won't work with that new version either at first, but once the most important things have been implemented I may get around to implementing multi-monitor positioning correctly. You'll have to live with for the time being, though.

MeridiusUK

31st August 2014, 12:56

no problem thanks for getting back to me

Simon88

4th September 2014, 16:07

I don't work on the old GUI anymore as I'm re-writing it with a different toolkit.

Where can we find betas/alphas of your new GUI version?

Mosu

4th September 2014, 18:22

There are no such builds yet. The next release should feature a first preview, but it'll really only be a preview, not an alpha, and most definitely not a beta.

Carpo

10th September 2014, 08:41

Mosu would it be possible in this new GUI to add the option to make and add tags to mkv files during muxing? I know at the moment we have to make the xml file ourselves and add it, just be nice to have it all in one so to speak :)

Mosu

10th September 2014, 08:46

A tag editor is something I might be working on one day, but that day is still far off in the future.

Mosu

13th September 2014, 18:29

Hey,

I've released mkvtoolnix v7.2.0. It fixes a couple of small bugs. Furthermore it fixes compilation with the just-released Boost v1.56.0 which is source-incompatible to earlier releases in certain ways.

Behind the scenes a lot of work has gone into the re-write of mmg called MKVToolNix GUI. This release is the first one to feature a preview of that new GUI, but only in the Windows binaries (users of other operating systems will have to compile the package themselves if they want to run the new GUI). More details are available at https://trac.bunkus.org/wiki/MkvToolNixGuiStatus

For packagers: note that the REAMDE file has been converted to Markdown format. Therefore it has been renamed to README.md.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-7.1.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

All of the Linux binaries that I provide have already been built and are available.

Here's the full ChangeLog since release 7.1.0:

2014-09-13 Moritz Bunkus <moritz@bunkus.org>
* Released v7.2.0.
* MKVToolNix GUI: included a first preview version in the Windows installer and portable releases.

2014-09-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed calculating AC3 delay from garbage data when reading AC3 from AVIs. This stopped working in release 5.4.0 due to commit 97cc2121.

2014-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: SSA/ASS files with sections after "[Events]" in their CodecPrivate are now handled correctly. Fixes #1057 (https://www.bunkus.org/trac/ticket/1057).

2014-09-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed handling certain edit list types in MP4 files that are used for positive track delays. Fixes #1059 (https://www.bunkus.org/trac/ticket/1059).

2014-08-09 Moritz Bunkus <moritz@bunkus.org>
* source: Fixed compilation with Boost 1.56.0 which changed the»indexed« range adaptor in an incompatible way.
* mkvpropedit, mmg's header editor: bug fix: when editing files with missing track UID elements such an element will be generated automatically instead of crashing and leaving the file in an unplayable state. Part of a fix for #1050 (https://www.bunkus.org/trac/ticket/1050).
* mkvmerge: bug fix: Reading Matroska files with missing track UID elements will no longer cause mkvmerge to abort with an error. A warning is printed and a new unique track ID generated instead. Part of a fix for #1050 (https://www.bunkus.org/trac/ticket/1050).

Have fun.

sl1pkn07

13th September 2014, 19:11

UO!!!!

thanks!!

show like this in my linux (build from sources)

http://wstaw.org/m/2014/09/13/plasma-desktopuf2662.png

is as expected?

greetings

EDIT: is a Qt5, fail build with Qt4 (configure say too old)

wanezhiling

13th September 2014, 19:13

The new desktop shortcut "MKVToolNix GUI preview" can not be automatically deleted after uninstalling the program.

Mosu

13th September 2014, 19:25

Only Qt5 is supported. Your screenshot looks a lot like it looks on my machine, albeit with a different theme (I'm not using Ubuntu, nor any of their UI stuff like Unity or those themes). So I'd say that yes, it should look this way. Anything in particular that you find strange about it?

Mosu

13th September 2014, 19:25

The new desktop shortcut "MKVToolNix GUI preview" can not be automatically deleted after uninstalling the program.

Will be fixed in the next released.

sl1pkn07

13th September 2014, 21:06

Anything in particular that you find strange about it?

at the moment, the white frame

greetings

Mosu

13th September 2014, 21:14

I've added an explicit frame around that panel because it was hard to distinguish on a traditional theme (meaning a lighter theme, e.g. Windows' default colors or something with light gray backgrounds). But that's just optics; I'm not really set on such things, just experimenting here and there.

filler56789

13th September 2014, 21:29

LOL, it seems some anti-viruses don't like the latest MKVtoolnix :)

http://www.videohelp.com/tools/MKVtoolnix#11697

Mosu

13th September 2014, 21:40

That happens regularly. It will happen again. I've even written a FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AVirusInInstaller) about it.

It happens so often (especially with ridiculous files like eicar.mod – EICAR is not a virus, it's an anti-virus test file! (http://en.wikipedia.org/wiki/EICAR_test_file)) that I've given up reporting the false positives to anti-virus companies. It literally took hours for each release finding out where to send those reports to and then actually sending them.

DragonQ

14th September 2014, 00:04

Carpo

14th September 2014, 00:14

More than likely because it is just a preview and a rough example of what Mosu is thinking about, as more people see it and give feed back, then he can change things

sl1pkn07

14th September 2014, 00:43

Qt5 is relative new, need time to get look&feel like Qt4

magsoud

14th September 2014, 06:14

Please Add "--disable-track-statistics-tags" to New Version!

Chetwood

14th September 2014, 06:47

why not do it yourself and set it as default?

Mosu

14th September 2014, 07:49

I have a question about the new GUI preview. Why does it use the old Windows 2000 style Winforms elements? Why not use "visual styles"? I dunno about C++ but with .NET programs this literally is just ticking a box in Visual Studio.

I haven't fiddled with the platform-specific knobs yet at all. The goal, of course, is to have the application look as native as possible – which Qt5 can definitely do.

It's also quite possible that this has something to do with the fact that I'm linking statically and not dynamically at the moment; I seem to remember that having some influence at least on Linux regarding how an application looks in KDE and GNOME. Maybe it applies to Windows as well.

But like I said: this is a preview. I'd expect at least the beta to have this fixed, if not the alpha.

Mosu

14th September 2014, 07:52

Please Add "--disable-track-statistics-tags" to New Version!

If you're referring to the new GUI: I don't take feature requests yet. That being said, I've also stated (https://trac.bunkus.org/wiki/MkvToolNixGuiStatus) that achieving feature parity with the old GUI is definitely a goal. So the ability to set that option will come back in one form or another.

If you mean the old GUI: that's already possible: »Muxing« → »Add command line options« → select the desired option and press »Add«. If you want it set for all of your muxing jobs (which I suspect you do) then simply check »Set as default for new jobs«.

DragonQ

14th September 2014, 08:41

I haven't fiddled with the platform-specific knobs yet at all. The goal, of course, is to have the application look as native as possible – which Qt5 can definitely do.

It's also quite possible that this has something to do with the fact that I'm linking statically and not dynamically at the moment; I seem to remember that having some influence at least on Linux regarding how an application looks in KDE and GNOME. Maybe it applies to Windows as well.

But like I said: this is a preview. I'd expect at least the beta to have this fixed, if not the alpha.
Cool, I was just wondering if it was a deliberate choice or just something for a future build. Thanks.

huhn

16th September 2014, 12:49

should MXF with jpeg2000 work with mkvmerge?

Mosu

16th September 2014, 13:16

Neither MXF nor JPEG 2000 are supported, and there are no plans whatsoever for it either.

huhn

16th September 2014, 15:10

Neither MXF nor JPEG 2000 are supported, and there are no plans whatsoever for it either.

thx for the answer.

Atak_Snajpera

17th September 2014, 10:52

Any plans for MP4 (HEVC) support in mkvmerge?

Mosu

17th September 2014, 11:05

Sure, but not short-term (more like medium-term); same for MPEG TS. See #995 (https://trac.bunkus.org/ticket/995) and #996 (https://trac.bunkus.org/ticket/996).

Atak_Snajpera

17th September 2014, 11:32

Sure, but not short-term (more like medium-term); same for MPEG TS. See #995 (https://trac.bunkus.org/ticket/995) and #996 (https://trac.bunkus.org/ticket/996).

oki doki :)

Mangix

18th September 2014, 22:28

having issues with the latest version. using a command line like "mkvextract tracks 1.mkv 1:1.wv" results in:

Error: Track 1 with the CodecID 'A_WAVPACK4' is missing the "codec private" element and cannot be extracted.

Mosu

20th September 2014, 13:10

Matroska and therefore mkvextract requires certain data to be present in CodecPrivate for WavPack. If it isn't then mkvextract cannot re-create it from thin air. Hence the error message.

73ChargerFan

30th September 2014, 04:46

Feature request: Assume a file is PCM audio if the extension is .pcm

Not sure if that'll work; initially mmg said it was "MPEG-4p10/AVC/h.265" . Mediainfo was able to determine stream 2 in m2ts file was PCM audio from a blu-ray, though it took a while. Maybe it was analyzing it.

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : PCM
Format settings, Endianness : Big
Format settings, Sign : Signed
Muxing mode : Blu-ray
Codec ID : 128
Duration : 1h 26mn
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 950 MiB (6%)

As a work around I re-extracted using eac3to to a .wav file and mmg accepted that. The .wav file was 68 bytes larger than the .pcm file. Header info?

eac3to v3.27
command line: eac3to 1) 3: "00003 - 3 - PCM, Undetermined, 2.0 channels, 16 bits, 48kHz.wav"
------------------------------------------------------------------------------
M2TS, 1 video track, 1 audio track, 1:26:28, 24p /1.001
1: Chapters, 9 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, Undetermined, 2.0 channels, 16 bits, 48kHz
[a03] Extracting audio track number 3...
[a03] Reading RAW/PCM...
[a03] Swapping endian...
[a03] Writing WAV...
[a03] Creating file "00003 - 3 - PCM, Undetermined, 2.0 channels, 16 bits, 48kHz.wav"...
[a03] The original audio track has a constant bit depth of 16 bits.
Video track 2 contains 124388 frames.
eac3to processing took 2 minutes, 40 seconds.
Done.

sneaker_ger

30th September 2014, 08:03

You can't really auto-detect raw PCM files because infos like sampling rate are missing and can't be trivially detected. You need the wav header or other container.

Reading PCM from transport streams is not yet supported in the 7.2.0 stable build but you can get a preview build that has support for it:
https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (64 bit only)

If it's still misdetected file a bug report on the tracker and supply a sample.

Mosu

1st October 2014, 09:36

Feature request: Assume a file is PCM audio if the extension is .pcm

Nope, sorry. Raw PCM doesn't come with headers that contain the information necessary for further processing (number of channels, sampling frequency, sample size in bits, byte order, quantization type lik linear/a-law/µ-law…). I'd have to add additional command line switches, too, and users would have to set those. There are tons of tools out there that can do just that and convert a raw PCM file to WAV files. There's simply not enough need for mkvmerge to be able to do that, too.

Mosu

1st October 2014, 09:38

Reading PCM from transport streams is not yet supported in the 7.2.0 stable build but you can get a preview build that has support for it:
https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (64 bit only)

If it's still misdetected file a bug report on the tracker and supply a sample.

Exactly this. The next release will contain that feature, too, of course. If you have files for which even the new builds don't detect your PCM tracks then please provide a sample and post about it in the original LPCM-in-TS ticket (https://trac.bunkus.org/ticket/763). Thanks.

yonta

1st October 2014, 14:53

mmg detects a raw pcm file as a mpeg4 part10/avc stream and even muxes it into .mkv file, which of course is not playable.
sample (https://drive.google.com/file/d/0B1mCVSSmbT2LRTZaTl9HOWp6UTQ/edit?usp=sharing)

Mosu

1st October 2014, 15:27

And as others have said: detecting raw PCM is pretty much impossible because it has no recognizable structure at all. I know that the h.264 code often leads to false positives regarding its detection, but that's simply because raw h.264 (pretty much every MPEG elementary stream) has crappy structure, too.

No, I won't change anything regarding this, sorry.

Edit: What I meant about reporting mis-detection issues was PCM-in-MPEG-TS/MPEG-PS, not raw PCM files.

Simon88

10th October 2014, 00:07

It would be great if you add GUI-based splitting for mkv using "common codecs" in your revised GUI? I find using avidemux rather un-reliable, and going back and forth to MKVToolNix after I record split locations to do the splitting.

Mosu

10th October 2014, 07:48

If you mean something like a visual preview of the video allowing jumping from key frame to key frame (in addition to normal seeking) and selecting a key frame for use as a split point: that will most likely never be implemented, or at least not before everything else on my GUI TODO list has been done. It would require a LOT of work: a) link against and use ffmpeg, b) write the interface for it, c) find a deterministic mapping from ffmpeg's track numbers to mkvmerge's track IDs, d) find a deterministic mapping from ffmpeg's timecodes to mkvmerge's for all the codecs supported.

Especially c) and d) are the points that would require hours of work. So no, not soon, likely not ever.

Nico8583

13th October 2014, 09:44

Hi,
I have a little question : I'm using mmg.exe to modify attachments, but I would like to know if there is a possibility to change attachment order when adding a new attachment ? I only see "enable all", "disable all" but none button. If it is possible with a cmdline, I'm also interested.
Thanks !

Mosu

13th October 2014, 10:21

Changing the order of attachments already present in a file is currently not supported.

The order of newly added attachments cannot be changed in mmg.exe, but it can be changed on the command line; simply move all the --attachment-… settings around as you see fit.

Nico8583

13th October 2014, 10:44

Boulder

13th October 2014, 10:46

Would it be possible to skip parsing the FLAC file if it exists in the list but is not used in muxing? I often do two muxes, one with AAC audio for my media player and one with FLAC audio to archive. I add all the necessary files at the same time and use the checkboxes to determine which files to use in the result.

Mosu

13th October 2014, 10:50

Thanks, is it possible to keep existing attachment already present in a file and add new attachment before these attachments ? Or new attachments will be added automaticaly after existing attachments ?

New attachments will always be added after the ones already present in the source files.

Mosu

13th October 2014, 10:51

Nico8583

13th October 2014, 10:57

New attachments will always be added after the ones already present in the source files.
Ok thanks, so I keep my actual solution : extract all attachments already presents in a file and attach them as new attachments with the order I want :)

Carpo

18th October 2014, 11:02

Is this the correct way to do a tag xml file for muxing into an mkv? - Every player I have tried this in never seems to pick any of the information up, although this could just be the player lacking MKV tag support, I just want to check I am doing it right first.

<?xml version="1.0" encoding="utf-16"?>
<Tags>
<Tag>
<Targets>
<TargetTypeValue>50</TargetTypeValue>
</Targets>
<Simple>
<Name>IMDB</Name>
<String>tt0347246</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>DATE_RELEASED</Name>
<String>2004-10-28</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>SUMMARY</Name>
<String>In the year 2032, Batô, a cyborg detective for the anti-terrorist unit Public Security Section 9, investigates the case of a female robot--one created solely for sexual pleasure--who slaughtered her owner.</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>SUBTITLE</Name>
<String>Sore wa inotchi innosensu ('Innocence is Life')</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>LAW_RATING</Name>
<String>PG-13</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>GENRE</Name>
<String>Animation</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>GENRE</Name>
<String>Drama</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>GENRE</Name>
<String>Sci-Fi</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>ACTOR</Name>
<String>Richard Epcar</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>ACTOR</Name>
<String>Crispin Freeman</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>ACTOR</Name>
<String>Michael McCarty</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>ACTOR</Name>
<String>Mary Elizabeth McGlynn</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>DIRECTOR</Name>
<String>Mamoru Oshii</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>WRITTEN_BY</Name>
<String> Masamune Shirow</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>WRITTEN_BY</Name>
<String>Mamoru Oshii</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
</Tag>
<Tag>
<Targets>
<TargetTypeValue>70</TargetTypeValue>
</Targets>
<Simple>
<Name>TITLE</Name>
<String>Ghost in the Shell 2: Innocence</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>KEYWORDS</Name>
<String>cyborg, section 9, anime, AI, cult film</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
</Tag>
</Tags>

Overdrive80

18th October 2014, 12:01

I think that this entries <TagLanguage>und</TagLanguage> <DefaultLanguage>1</DefaultLanguage> arent need for each section.

http://matroska.org/technical/specs/tagging/example-video.html

Example:

<?xml version="1.0" encoding="windows-1252"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">
<Tags>

<Tag>
<Targets>
<TargetTypeValue>50</TargetTypeValue>
</Targets>
<Simple>
<Name>TITLE</Name>
<String>Dune</String>
</Simple>
<Simple>
<Name>DIRECTOR</Name>
<String>David Lynch</String>
</Simple>
<Simple>
<Name>DATE_RELEASED</Name>
<String>1984</String>
</Simple>
<Simple>
<Name>COMMENT</Name>
<String>Great sci-fi movie</String>
</Simple>
</Tag>
</Tags>

Too, create two instances of same element isnt good idea.

<Name>GENRE</Name>
<String>Drama</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>GENRE</Name>
<String>Sci-Fi</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>

Carpo

18th October 2014, 20:01

I took the Genre bits from IMDB, do you now if you can have them separated by comma's in the one section or should I just go with my gut?

I guess with Riddick you could just have Sci-Fi

I'll read the matroska site again.

But other than the bits you picked, does the rest look okay?

Bet Mosu can see why I asked for a tag editor in mkvtools, and I can now see why he said no :p

upyzl

19th October 2014, 06:59

wish to improve support HEVC like ffmpeg mux

I mean, currently mkvtoolnix remux HEVC must be: a raw HEVC stream. and it strip some header info (such as x265 SEI) by using the way of H.265 hack

but latest ffmpeg remux HEVC could from a .mp4 besides .hevc raw, and after remux it still reserved the info (such as x265 SEI)

for fullinfo:
General
Unique ID : 241369618266815033885817361646294187142 (0xB59618F8F0E2848E395DD26EB2B8BC86)
Complete name : D:\enc\test_ffmpeg.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.04 MiB
Duration : 4s 254ms
Overall bit rate : 2 060 Kbps
Writing application : Lavf56.9.100
Writing library : Lavf56.9.100

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.0
Codec ID : V_MPEGH/ISO/HEVC
Duration : 4s 254ms
Bit rate : 2 019 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.041
Stream size : 1.02 MiB (98%)
Writing library : x265 1.3+608-426a279be2b8:[Windows][MSVC 1800][64 bit] 16bpp
Encoding settings : wpp / ctu=64 / tu-intra-depth=2 / tu-inter-depth=2 / me=1 / subme=3 / merange=57 / no-rect / no-amp / max-merge=3 /
no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra /
open-gop / interlace=0 / keyint=360 / min-keyint=1 / scenecut=40 / rc-lookahead=25 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / weightp / weightb /
aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree /
rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Default : Yes
Forced : No
Encoded date : UTC 2014-10-19 05:43:15
HANDLER_NAME : L-SMASH Video Handler
General
Unique ID : 248387222181975135494247133887195962691 (0xBADDA38EF90F2D07A66761D5269EDD43)
Complete name : D:\enc\test_mmg.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.05 MiB
Duration : 4s 171ms
Overall bit rate : 2 109 Kbps
Encoded date : UTC 2014-10-19 05:45:13
Writing application : mkvmerge v7.2.0 ('On Every Street') 64bit built on Sep 13 2014 15:52:10
Writing library : libebml v1.3.0 + libmatroska v1.4.1
DURATION : 00:00:04.171000000
NUMBER_OF_FRAMES : 100
NUMBER_OF_BYTES : 1093111
_STATISTICS_WRITING_APP : mkvmerge v7.2.0 ('On Every Street') 64bit built on Sep 13 2014 15:52:10
_STATISTICS_WRITING_DATE_UTC : 2014-10-19 05:45:13
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 4s 171ms
Bit rate : 2 067 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Bits/(Pixel*Frame) : 0.042
Stream size : 1.03 MiB (98%)
Default : Yes
Forced : No

samples download: https://mega.co.nz/#!AhEAWL5K!7UtRSorYF0MR3uxpBxhQvxWaTate4BMVa7K2qXP4yEQ

Mosu

19th October 2014, 08:54

That is on my TODO list (https://trac.bunkus.org/ticket/996), but I cannot give you an ETA.

upyzl

19th October 2014, 09:07

That is on my TODO list (https://trac.bunkus.org/ticket/996), but I cannot give you an ETA.

got it:cool:, np

Simon88

19th October 2014, 21:19

Hi Mosu,

I remember you were considering such a capability as to extract Closed Captioning during muxing of TS, MPG, and MP4...into one of the text format files which are supported by CCExtractor... such as ttext, srt, etc.... CCExtractor is pretty much a mature program now, with very little development and open sourced. The reason that it is important to me is because any processing done to a captured TS, MPG, or MP4 will destroy the captioning info... and having it stored in the MKV in a separate stream, and easily extractable, or cut, is very convenient... :)

Mosu

19th October 2014, 21:21

The next release will feature importing teletext subtitles from MPEG transport streams. I will most likely not work on closed captioning in the near future.

alexVS

21st October 2014, 19:52

Hi!
I'm trying to cut 6min part from 3,5 hour MKV video file (avc 1080i 15Mb/s, mpa sound)
Is possible just cut, I mean receive only 1 small file (for example 01:00:00 from to 01:06:00)?
I receive 3 parts (the whole file processed, splitted). Middle part is mine. But its very slow and I'm almost out of disk space.

Mosu

21st October 2014, 20:11

The »split by parts« mode is the one you need. See the documentation (https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split) for further explanations.

Mosu

22nd October 2014, 21:30

Hey,

I've released mkvtoolnix v7.3.0. It implements support for PCM in MPEG program (.vob – DVDs) and transport streams (.ts, .m2ts – Blu-rays, television broadcasts) as well as for teletext subtitles in MPEG tranport streams. Apart from that a lot of work has gone into the new GUI.

For packagers: nothing has changed since the previous release.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-7.3.0.tar.xz

...to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

Here's the full ChangeLog since the previous release:

2014-10-22 Moritz Bunkus <moritz@bunkus.org>
* Released v7.3.0.

2014-10-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: implemented support for reading teletext subtitles from MPEG transport streams. They're converted to SRT-style subtitles (CodecID S_TEXT/UTF8). Implements #773 (https://www.bunkus.org/trac/ticket/773).

2014-10-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: probing MPEG transport streams with certain types of broken MPEG-2 inside caused mkvmerge to exit with an error message. Such tracks are now ignored instead.

2014-09-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg's chapter editor: fixed the default value for the»language« element if it isn't present in a chapter XML file.

2014-09-28 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: implemented drag & drop in the files pane.

2014-09-26 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo (Qt version on Windows): bug fix: the console window is closed if the GUI is launched.

2014-09-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Reading tracks from MPEG transport streams resulted in the track being cut off at points with a five minute gap in between frames. It is due to timecode wrap detection introduced in v6.9.0. As it affects subtitles the most the wrap detection has been relaxed for them.

2014-09-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: implemented drag & drop in the track pane.

2014-09-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: added support for PCM in MPEG program streams (.vob – DVDs) and transport streams (.ts, .m2ts – Blu-rays). Implements #763 (https://www.bunkus.org/trac/ticket/763).

2014-09-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: fixed missing command line switch for audio sync/stretch.

2014-09-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: implemented drag & drop in the job queue.

2014-09-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: implemented storing the job queue when the application exits and retrieving it when it starts again.
* Installer: bug fix: the shortcut for the GUI preview on the desktop is removed upon uninstallation. If the user opts not to have shortcuts on the desktop then no shortcut is created for the GUI preview either.
* MKVToolNix GUI: fixed clearing the file/track/attachment lists when starting a new config or when loading an existing one.
* MKVToolNix GUI: implemented setting the output file name automatically in four different modes (don't set at all; place in previous output directory; place in fixed output directory; place in parent directory of first source file) with an option to make them unique by appending a running number.
* MKVToolNix GUI: implemented setting the file title automatically from added files that already have a title.

Have fun.

Sparktank

22nd October 2014, 22:19

support for PCM...

Have fun.

:thanks:

Oh, fun will be had. Thanks for your continual support. :)

Mosu

23rd October 2014, 08:14

You're welcome.

Funny (or not so funny) anecdote: that »Have fun.« is a message that was printed by my very first Linux distribution (S.u.S.E. Linux back in 1994 or so) upon logging in. Somehow it stuck :)

Sparktank

23rd October 2014, 12:37

That's actually really cool tidbit information.

Stuff like that really adds to the whole "mythos" of software development.
I mean, we've already learned the inspiration behind the product code.

Just when you think you've lurked Doom9 enough, anothing pops up!

Boulder

23rd October 2014, 14:16

Is there any way around the infamous "missing the codec private element and cannot be extracted" error with mkvextract?

I'm getting it for some Wavpack audio tracks in some Matroska files that have been split while muxing w/ linked files, and then later the parts were merged with the append option. The resulting file plays normally.

(EDIT: noticed the post on the top of this page, but this seems like an mkvmerge bug as it is the one that has broken the audio track when splitting)

DragonQ

23rd October 2014, 16:21

Dunno if this has been reported already but the "Download" button on the window that appears when a new version is available is broken. It tries to go to:

https://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-7.3.0-setup.exe

When instead it needs to point to either:

https://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-7.3.0-setup.exe
or
https://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-amd64-7.3.0-setup.exe

Mosu

23rd October 2014, 16:36

Ah right. I'll fix that for the next release to point to the general download page – always pointing to the installer would be wrong if you're running the portable version.

Thanks for reporting it.

Simon88

23rd October 2014, 21:25

Will you also be implementing ATSC CEA-708 Closed Captioning support in a later version?

Currently CCextractor works well, but having MKVToolNix doing it would be alot better.

Currently I have to "fix" the TS streams using VideoRedo after ATSC DTV capture before MKVtoolsNix will find the video track (only the Audio tracks are seen without fixing), then use MediaInfo to take a peek at the # of CC tracks, then extract them to separate SRT files, and finally load them all into MKVToolsNix for final muxing. The capture cards are dual tuner ATSC Hauppauge PCIe cards.

Mosu

24th October 2014, 08:39

It is on my TODO list, but not for the near or mid-term future.

Carpo

26th October 2014, 11:33

What is the optimal way to add actors tag in the tag file? If I do them all separately mediainfo only picks up the last one I put, should they all be on one line, would the same go for writers?

Boulder

26th October 2014, 17:47

Recovering stuff from my archives, I have some Matroska files that warn "Invalid EBML data" when I have extracted the FLAC-encoded audio track and try to decode it. Is this an indication of a corrupted file perhaps? I have HD Sentinel monitoring the HDs all the time and according to that, there have been no problems registered by the hard drive.

cfsmp3

12th November 2014, 23:18

CCExtractor is pretty much a mature program now,

Yes...

with very little development

Quite the opposite. It was accepted into Google's Summer of Code in 2014 and a lot of things were done over the summer, and now the 3 students that worked on it are pretty much permanent team members (even though they do stuff as time allows).

Simon88

13th November 2014, 01:40

Quite the opposite. It was accepted into Google's Summer of Code in 2014 and a lot of things were done over the summer, and now the 3 students that worked on it are pretty much permanent team members (even though they do stuff as time allows).

According to:
http://ccextractor.sourceforge.net/roadmap.html

Carlos states:

CCExtractor already does all I need it to do, and a lot more. This means that all future development needs to be sponsored or it's unlikely to happen.

I'm happy to continue working on CCExtractor, but it just is not going to happen on my personal time.

In short: If your company needs anything done on CCExtractor, and you want me to do it, you will need to hire me.

Though near the end it mentions Google will be paying 3 people to do some stuff over the summer that probably Google themselves need or want.... :)

microchip8

15th November 2014, 13:13

Hi, Mosu :)

Can you please build openSUSE 13.2 RPMs?

thanks

Mosu

15th November 2014, 13:15

I will, all in due time. Haven't even installed 13.2 yet.

Mosu

16th November 2014, 18:55

Binaries for openSUSE 13.2 are now available (https://www.bunkus.org/videotools/mkvtoolnix/downloads.html#suse).

Simon88

18th November 2014, 16:33

I'm wondering if their is a proper command to scanning a large MKV file for errors without generating any media files, eg. pipe it to a NUL device?

Or is there a special command to do it. I'll probably just put it in a batch loop and do it in the background.

Thanks...

Mosu

18th November 2014, 16:37

On proper OS you can just output to /dev/null, but Windows simply isn't a proper OS ;)

Boulder

18th November 2014, 17:05

Is it not possible to use -o NUL ?

Mosu

18th November 2014, 17:24

Yeah it should. mkvmerge simply uses the CreateFileW() function with the output file name.

Simon88

18th November 2014, 18:26

On proper OS you can just output to /dev/null, but Windows simply isn't a proper OS ;)

I just thought there must be a "better", "easier", or "faster" way of scanning thru a set of file just to verify it... Oh well... So, does a simple command like this look OK:

""%mkvmerge_exe%" -o "NUL" "%%~B"

Any "options" I should use to make it better?:)

Mosu

18th November 2014, 19:01

mkvmerge is not a file format verification tool. Yes, it does have some capabilities for ignoring certain kinds of errors (and will output warnings and errors depending on whether or not mkvmerge thinks it can carry on), but that also means that there are no special options and you have to use something like -o NUL on Windows or -o /dev/null anywhere else.

I cannot tell you anything about shell variable/wildcard expansion on Windows' shells, though, so if %%~B works for you, great, if not then someone else will have to tell you why.

Simon88

18th November 2014, 20:18

Thanks Mosu,

Everything works great... Btw, I really like the new Matroska GUI, looks promising... :)

RDF

20th November 2014, 21:28

Hi Mosu,

I have been following this thread for a long time and I am very thankful for you and your team to create the mkv container. It's truly an amazing container that I hope it becomes the container standard with the support of MKV in Windows 10. Anyway, I have a question about the MKVToolNix and I hope this doesn't bother you. Is there a way to add custom hot-keys for some of the menu in the MKVToolNix (http://puu.sh/cYNBn/a5bfe2ab22.png)?

Mosu

20th November 2014, 21:37

Thanks for the praise. No, such customization is not implemented.

RDF

20th November 2014, 21:42

Thanks for the praise. No, such customization is not implemented.

are there any plans to make this a feature? I will understand if you don't plan to add such feature.

Mosu

20th November 2014, 22:19

No, I don't have any plans in that direction. I have many other things to implement and fix that I consider of higher priority and bigger concern to a broad number of users. Sorry.

Simon88

23rd November 2014, 16:33

Hi Mosu,

I was using MP4Box to add a plain text English SRT file to a short MP4 video capture. I simply used the -add track command, nothing fancy.

ID : 6
Format : Timed Text
Codec ID : tx3g
Duration : 43mn 31s
Bit rate mode : Variable
Bit rate : 37 bps
Stream size : 11.8 KiB (0%)
Language : English
Encoded date : UTC 2014-11-23 15:29:33
Tagged date : UTC 2014-11-23 15:29:35

Mkvtoolsnix does not seem to see it when I tried to put it into an MKV container.

Mosu

23rd November 2014, 19:09

The timed text format is not supported by mkvmerge. I have no plans for adding support for it in the near future.

Nexin

27th November 2014, 17:10

Adding Chapters doesn't need to be complex simple chapters can be easy. I Tried to add some simple chapters using mkvmerge v7.3.0 it wouldn't do work. So I tried an example from mkvmerge own help guide which still didn't work !

MKVMerge help guide..

4.2 Examples
Intro (from 00:00:00, language English)
Act 1 (from 00:01:00, language English)
Act 2 (from 00:05:30, language English)
Credits (from 00:12:20 until 00;12:55, language English)

MKVMerge Error..
This file does not contain valid chapters. Error message from the Parser: Unknown chapter file format in G:\chapters.txt it does not contain valid chapter information

Other examples are more complex than I need. Simple and easy is better for projects easier to remember and do each time.

Mosu

27th November 2014, 18:35

sneaker_ger

27th November 2014, 20:22

The mkvmerge cli doc has examples:
https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.chapters

Mosu

27th November 2014, 20:25

Oh right, I totally forgot about that. Thanks.

Nexin

28th November 2014, 11:24

That example is meant to be recreated with the GUI and not copy paste into a text file. If you need example files for the text format then look in the installation folder, there should be examples (unless I don't package them for Windows... I don't remember at the moment).
Thanks for the info will have to try next simple chapter format with txt files which would be easier.

Having made a simple .txt file for subtitles now extension .srt with a .txt working backup copy. Subtitles are extra comments for the video. Soon realise what I needed was chapters to do this. I didn't check to see if mp4 supported chapters or any software to add .srt or sub-idx to mp4 container but knew mkv could do that and still not sub video hard-copy which is preferred.

Made the chapters using video player to see where each comment subtitle needed to be . Does mkvtoolnix mkmerge have or integrate with a video player we can use to set chapters that is internally sent to mkvmerge for use ?

Your guide that sneaker-ger linked isn't the same as the one in v.7.3.0 package but the same info is there.

Mosu

12th December 2014, 17:36

Hey,

I've released mkvtoolnix v7.4.0. It's mostly a bug-fix release, though
kind of important if you mux HEVC or teletext subtitles.

For packagers: nothing has changed since the previous release.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-7.4.0.tar.xz

...to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

All of the Linux binaries that I provide have already been built and
are available.

Here's the full ChangeLog since the previous release:

2014-12-12 Moritz Bunkus <moritz@bunkus.org>
* Released v7.4.0.

2014-12-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge was sometimes dropping lines from teletext subtitles read from MPEG transport streams. See #773 (https://www.bunkus.org/trac/ticket/773).

2014-12-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The PCM packetizer was producing wrong track statistics by disregarding the last packet's duration when reading PCM data from packaged sources (Matroska, MP4 files). Fixes #1075 (https://www.bunkus.org/trac/ticket/1075).
* build system: enhancement: configure will look for a system version of the pugixml library and use that instead of the bundled version if it is found. Fixes #1090 (https://www.bunkus.org/trac/ticket/1090).
* mkvextract: bug fix for chapter & tag extraction: If locale is set to a non-UTF locale (including C or POSIX) then no XML data was output at all even if the XML data contained ASCII characters only. Fixes #1086 (https://www.bunkus.org/trac/ticket/1086). This also fixes mkvextract writing two BOMs when extracting tags with the »--redirect-output« option on Windows.

2014-11-19 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: summary mode: reported frame types in block groups are now derived from the number of references found and not by the references' values.

2014-11-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed muxing open GOPs after I frames in MPEG-1/2 video (patch by Stefan Pöschel). Fixes #1084 (https://www.bunkus.org/trac/ticket/1084).

2014-11-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: VP9 video tracks are accepted in WebM mode.

2014-11-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Cherry-picked several commits from DivX' mkvmerge fork for improved HEVC handling. Fixes #1076 (https://www.bunkus.org/trac/ticket/1076).
* all: new feature: added a Catalan translation of the programs by Antoni Bella Pérez (see AUTHORS).

2014-11-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the handling of Big Endian PCM tracks read from MP4 files. Fixes #1078 (https://www.bunkus.org/trac/ticket/1078).

Have fun.

Boulder

12th December 2014, 17:41

Thanks again for a new version!

hubblec4

13th December 2014, 03:23

This also fixes mkvextract writing two BOMs when extracting tags with the »--redirect-output« option on Windows.

Yes it works. Thanks a lot.

AYColumbia

13th December 2014, 16:24

Thank you Mosu. Don't forget to change thread title. ;)

73ChargerFan

14th December 2014, 03:40

End of year - time for everyone to donate!

Gravitator

3rd January 2015, 10:39

Happy New Year!!!
Check the file > NX1_UHD_30p.mp4 (http://forum.videohelp.com/attachments/28897-1417273258/NX1_UHD_30p.mp4) (does not see a video stream HEVC).

Mosu

3rd January 2015, 11:48

Thanks. In my current development version reading h.265/HEVC from MP4 has already been implemented. Still, mkvmerge didn't recognize the video track out of the box, but I only had to add »hev1« as yet another FourCC for h.265/HEVC video and it started working.

Mosu

4th January 2015, 21:38

Hey,

I've released MKVToolNix v7.5.0. It contains a lot of new features dealing with h.265/HEVC video & AAC audio, some minor assorted enhancements and quite a number of bug fixes – especially some which prevent invalid memory access.

MKVToolNix' own configure script has therefore been changed to look for the libraries via their respective pkg-config files. This means that the configure options »--with-extra-includes« and »--with-extra-libs« don't affect the detection of libEBML/libMatroska anymore. Instead you can set the environment variable »PKG_CONFIG_PATH« to where the pkg-config scripts of libEBML and libMatroska are located.

MKVToolNix' own configure script has therefore been changed to look for the libraries via their respective pkg-config files. This means that the configure options »--with-ebml-headers«, »--with-ebml-libs«, »--with-matroska-headers« and »--with-matroska-libs« are not supported anymore. Instead you can set the environment variable »PKG_CONFIG_PATH« to where the pkg-config scripts of libEBML and libMatroska are located.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-7.5.0.tar.xz

...to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

All of the Linux binaries that I provide have already been built and
are available.

Here's the full ChangeLog since the previous release:

2015-01-04 Moritz Bunkus <moritz@bunkus.org>
* Released v7.5.0.
* mkvmerge: bug fix: If the target drive is full then a nicer error message is output instead of simply crashing due to an uncaught exception.
* mkvmerge: bug fix: Fixed reading MPEG transport streams in which all PATs and/or PMTs have CRC errors. Fixes #1100 (https://www.bunkus.org/trac/ticket/1100).

2015-01-03 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: Re-wrote the whole checksum calculation code. This lead to a fix for the Adler32 checksum algorithm that was triggered under certain circumstances. Adler32 is used in mkvinfo's output (e.g. in summary mode or if checksums are activated), in the h.265/HEVC bitstream and TrueAudio (TTA) file headers.

2015-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed handling of HE-AACv2 with object type »parametric stereo«.
* mkvmerge: new feature: implemented support for MP4 DASH files. Implements #1038 (https://www.bunkus.org/trac/ticket/1038).

2014-12-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: implemented reading MPEG-H p2/HEVC video tracks from MP4 files. Implements #996 (https://www.bunkus.org/trac/ticket/996).

2014-12-30 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: track statistics: the duration (and therefore the estimated bitrate) was wrong for files in which the frame with the maximum timecode wasn't the last frame in the file. Fixes #1092 (https://www.bunkus.org/trac/ticket/1092).
* mkvmerge: new feature: implemented support for AAC in LOAS/LATM multiplex if read from MPEG transport streams or raw LOAS/LATM AAC files. Implements #877 (https://www.bunkus.org/trac/ticket/877) and fixes the underlying issue in #832 (https://www.bunkus.org/trac/ticket/832).

2014-12-21 Moritz Bunkus <moritz@bunkus.org>
* build system: libEBML and libMatroska have been changed to provide pkg-config configuration files. Therefore MKVToolNix' build system has been switched to look for both libraries via pkg-config.

2014-12-20 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: several fixes have gone into libEBML and libMatroska that prevent illegal memory access (both reading from and writing to unallocated addresses). The bugs #1089 (https://www.bunkus.org/trac/ticket/1089) and #1096 (https://www.bunkus.org/trac/ticket/1096) have thus been fixed.

2014-12-19 Moritz Bunkus <moritz@bunkus.org>
* build system: libMatroska v1.4.2 is now required as part of a fix for #1096 (https://www.bunkus.org/trac/ticket/1096).

2014-12-18 Moritz Bunkus <moritz@bunkus.org>
* build system: libEBML v1.3.1 is now required as a part of a fix for #1089 (https://www.bunkus.org/trac/ticket/1089).
* mkvinfo: bug fix: mkvinfo will abort with a proper error message if the first element found is not an EBML head element. See #1089 (https://www.bunkus.org/trac/ticket/1089).
* all: enhancement: improved exception messages that can occur when reading damaged Matroska files to make it clearer for the user what's happening. See #1089 (https://www.bunkus.org/trac/ticket/1089).

2014-12-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading h.265/HEVC video tracks from MPEG transport streams. Implements #995 (https://www.bunkus.org/trac/ticket/995).
* mkvinfo: bug fix: Timecodes output with ms resolution are now rounded to ms instead of simply cut off. Fixes #1093 (https://www.bunkus.org/trac/ticket/1093).

Have fun.

filler56789

5th January 2015, 01:21

Thanks a lot for the fixes and improvements :thanks:

BUT the title of this thread was not updated accordingly ;) :)

DarkSpace

5th January 2015, 11:48

* mkvinfo: bug fix: Timecodes output with ms resolution are now rounded to ms instead of simply cut off. Fixes #1093 (https://www.bunkus.org/trac/ticket/1093).
Speaking of timecodes, how do you calculate video timecodes? I tried looking at the source, but from what I recognized*, it seems like you're doing simple rounding when calculating timecodes, and that does not match up with the results I'm getting from mkvmerge with e.g. 24000/1001 fps.
Now what's most interesting about that is, in my opinion, that the results I'm getting are sometimes neither rounded nor truncated (and the standard deviation is lower than with simple rounding, with a different mean) results of the calculation
framenumber / fps = framenumber * fps_denominator / fps_numerator

* I looked at timecode_factory (.h (https://github.com/mbunkus/mkvtoolnix/blob/master/src/merge/timecode_factory.h) and .cpp (https://github.com/mbunkus/mkvtoolnix/blob/master/src/merge/timecode_factory.cpp)), timecodes_v2.cpp (https://github.com/mbunkus/mkvtoolnix/blob/master/src/extract/timecodes_v2.cpp), samples_timecode_conv.h (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/samples_timecode_conv.h), and timecode.h (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/timecode.h). I may have missed something, of course.

Mosu

5th January 2015, 12:45

Well, »it depends« ;) For the simplest case in which the source file doesn't provide its own set of timestamps the following happens (see src/output/p_video.cpp):

The timecode in nanoseconds is calculated as 1000000000.0 * number_of_frames_output / frames_per_second.
This value is immediately truncated to an integer (meaning the sub-ns precision is lost).
The packet is handed over to the core muxing code.
When the core muxing code (src/merge/cluster_helper.cpp) writes a packet into the file it has to scale the timecode to the file's timecode scale value whose default is 1000000 (resulting in nanosecond precision). This is done in src/merge/packet.cpp, function normalize_timecodes(), which uses the preprocessor macro RND_TIMECODE_SCALE. The calculation is: timecode_in_scale_units = integer-round(timecode_in_ns / timecode_scale)
That integer-round() function in turn is pretty much only cast-to-double, add 0.5, cast-to-integer.

Timecode factories only come into play in certain situations. If the source container provides timecodes (Matroska, MP4, MPEG TS mostly, MPEG PS mostly…) then those timecodes are used instead.

And then there are situations in which the source container provides timecodes for some but not all packets. MPEG TS and MPEG PS are notable candidates for such behavior, especially for the audio tracks. In such situations the audio packetizers remember the timecode that was provided by the container last and calculate new timecodes from there on (instead of from 0) based on the number of samples.

Of course options like --sync and --timecodes (this is what the factories are for) also apply somewhere.

The initial calculation doesn't have to use floating-point numbers either. Several packetizers only use integer calculation. For example the h.264/AVC parser code does; it simply adds the number of nanoseconds per frame/field to the last known provided timecode.

Internally mkvmerge calculates all timecodes in nanosecond precision. It only scales to the file's precision (timecode_scale) right before it writes out a packet. Yes, such calculations (e.g. adding the number of nanoseconds per frame/field) is prone to rounding errors, but you'd need over a million video frames before this makes any difference to the default millisecond timecodes of a Matroska file.

manolito

5th January 2015, 23:32

Are out of range chapters legal in an MKV file?

Sorry if this has been treated before, but I could not find any information about it...

I often need to add chapters at a fixed interval to MKV files. There is a software called MKV Chapterizer which should do exactly what I want, but unfortunately it does not work on my computer.

So I normally use a template chapter file in the OGG format which has chapters up to 4 hours. I manually edit this file to remove out of range chapters before muxing the chapter file into the MKV using MKVMergeGUI.

Just the other day I simply forgot to edit the chapter file so I ended up with an MKV where the movie was under 2 hours, but had chapters for 4 hours. MediaInfo reported all the chapters, they had not been truncated at the end of the movie. And the MKV played flawlessly on all my players.

Is such a file legal by the MKV specs, or am I pushing my luck?

Cheers
manolito

qyot27

6th January 2015, 00:25

DarkSpace

6th January 2015, 01:46

Well, »it depends« ;) For the simplest case in which the source file doesn't provide its own set of timestamps the following happens (see src/output/p_video.cpp)
Thanks for the quick answer! I'll think about it sometime when I'm more awake, and I'll ask again if I have any questions left.

hubblec4

6th January 2015, 02:19

[B]...I often need to add chapters at a fixed interval to MKV files. There is a software called MKV Chapterizer which should do exactly what I want, but unfortunately it does not work on my computer.

Hi manolito

You can try my chapterEditor (windows only).

It is based on the chapter editor in the mmg, with a lot of more functions.

Mosu

6th January 2015, 10:23

Are out of range chapters legal in an MKV file?

There are no limitations on the chapter timecodes with respect to the whole file's timecodes.

Mosu

6th January 2015, 10:31

Which Qt modules do mkvinfo and mkvtoolnix-gui rely on?

I ask, because the Windows builds of mkvinfo and mkvtoolnix-gui crash on startup on pre-SSE2 CPUs (because of Qt5.3+ automatically assuming SSE2 now unless it's disabled during configure), and have since 7.2.0. I was thinking of recompiling everything myself, but I'd rather not build Qt modules I won't need.

It's more of a problem for mkvinfo, since it stops the CLI from being used too.

Some clarification on which GUI toolkits are used by which program: mmg doesn't use Qt at all but wxWidgets. mkvinfo has two GUI implementations, one based on wxWidgets and one based on Qt; the Windows build currently uses Qt 5.3.1. The new mkvtoolnix-gui is based on Qt, again built with 5.3.1.

So with the current Windows builds you get: mmg built with wxWidgets 3.0.0; mkvinfo & mkvtoolnix-gui built with Qt 5.3.1.

I wasn't aware of the SSE2 requirement. Do you know which option to pass to Qt's configure? I can certainly do without such a strict requirement; it's not as if I'm using Qt for anything performance-sensitive.

If you're building from source then you can build mkvinfo with wxWidgets, of course, completely circumventing the problem for the time being. If you're building with Qt then you do need Qt 5.x, though I'm currently uncertain of the minimum version required – probably 5.2.x. As for the Qt modules: both GUIs are compiled with and linked against the following pkg-config elements: Qt5Core Qt5Gui Qt5Widgets Qt5PlatformSupport (just the basics here – no SQL, no QtQuick, no HTML so far, but that may change once help support has been implemented).

Edit: Also note that I'm cross-compiling from Linux for Windows with the MXE project (http://mxe.cc/). I've never built directly on Windows (e.g. with Cygwin or mingw or even Visual C++), and that's not something that I support in any shape or form. Build instructions are available (https://github.com/mbunkus/mkvtoolnix/blob/master/README.Windows.txt), though they're slightly outdated and somewhat incomplete (e.g. no mention of how to build a 64bit version).

sl1pkn07

6th January 2015, 10:38

try to add "-no-sse2" in your Qt5 build options (no need in 64bits environment. only if build lib32 libs)

https://bugreports.qt-project.org/browse/QTBUG-35430

Mosu

6th January 2015, 12:00

I've re-built Qt 5.3.1 with -no-sse2 as well as MKVToolNix with that newly built Qt. You can get the build here (build number 642) (https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

qyot27

7th January 2015, 00:47

Thanks.

Some clarification on which GUI toolkits are used by which program: mmg doesn't use Qt at all but wxWidgets. mkvinfo has two GUI implementations, one based on wxWidgets and one based on Qt; the Windows build currently uses Qt 5.3.1. The new mkvtoolnix-gui is based on Qt, again built with 5.3.1.

So with the current Windows builds you get: mmg built with wxWidgets 3.0.0; mkvinfo & mkvtoolnix-gui built with Qt 5.3.1.
If you're building from source then you can build mkvinfo with wxWidgets, of course, completely circumventing the problem for the time being. If you're building with Qt then you do need Qt 5.x, though I'm currently uncertain of the minimum version required – probably 5.2.x. As for the Qt modules: both GUIs are compiled with and linked against the following pkg-config elements: Qt5Core Qt5Gui Qt5Widgets Qt5PlatformSupport (just the basics here – no SQL, no QtQuick, no HTML so far, but that may change once help support has been implemented).
Ok, I wasn't sure if the wxWidgets GUI for mkvinfo had been removed, since the recent Changelog entries only mention the Qt one. I wasn't having issues with mmg, that's why I didn't mention wxWidgets (and I'd worked out how to cross-compile wxWidgets for another project some time ago).

Edit: Also note that I'm cross-compiling from Linux for Windows with the MXE project (http://mxe.cc/). I've never built directly on Windows (e.g. with Cygwin or mingw or even Visual C++), and that's not something that I support in any shape or form. Build instructions are available (https://github.com/mbunkus/mkvtoolnix/blob/master/README.Windows.txt), though they're slightly outdated and somewhat incomplete (e.g. no mention of how to build a 64bit version).
Likewise, I usually only ever cross-compile, albeit from a manually-built toolchain. Aside from Qt, the only dependencies mentioned in the README that I hadn't already worked out instructions for with other projects were gettext (not for lack of trying, though), file, and lzo.

Mosu

7th January 2015, 09:51

The relationship goes something like this:

mkvinfo's GUI is the wxWidgets version by default unless you tell configure »--enable-qt«. If you do mkvinfo's Qt GUI is built instead.

If you »--enable-qt« then you can also tell configure »--with-mkvtoolnix-gui« which will build the mkvtoolnix-gui (the preview of the mmg rewrite with Qt).

If you're generally cross-compiling then I strongly suggest that you take a look at MXE. I've used a self-built chain myself in the past, but keeping it up to date regarding the mingw version, the required patches (and build instructions) for the various libraries etc. proved to be a lot of work. With MXE you get a 32bit compiler, a 64bit compiler, a static build and shared build (still work in progress) – and all of that is pretty darn easy to set up and use afterwards.

You can still read my build instructions for Windows (https://github.com/mbunkus/mkvtoolnix/blob/d50315e0fd5e890516079b80ec0d5bdcfd7ade1f/README.Windows.txt) before the change to MXE. Maybe it'll help you somewhat if you don't want to give MXE a try.

Simon88

7th January 2015, 19:11

Hi Mosu,

I was going to upgrade to mkvtoolnix is v7.5.0 today and notice FOSSUB has changed their D/L procedures and now forces one to download their small *.EXE stub first (Free_Download.exe or Free_Download_Setup.exe). I don't know if it is malware, spyware, or whatnot, but I've seen a few other sites are doing this as well.

I just went to your old bunkus site and D/L it instead... You might consider changing to sourceforge, sites.google, or some other place.

Edit: after I hit cancel a few times, and try to D/L again, it no longer tried to force feed their *.EXE stub. Appears they wrote something to my cookie file indicating, I'm smart enough not to download their stub file and the correct *.EXE now downloads.

Mosu

7th January 2015, 19:36

The correct place to download is http://www.fosshub.com/MKVToolNix.html (intentionally not linked). I can download from there just fine without going through a different exe, especially not anything with free in the name.

Did you click on the link on my site? Did you Google for it? Type the URL from memory?

Note that the FossHub.com admin staff is very forward with their projects regarding any changes in their infrastructure and procedures, and I haven't heard anything about any forced setup.exe. It also goes against pretty much everything they're working on.

Therefore I think you've simply visited the wrong site.

Simon88

7th January 2015, 20:11

Mosu

7th January 2015, 20:19

I'm pretty certain that they're not doing it on purpose but that such a popup is the result of one of the advertisements. I'll contact the FossHub.com stuff about it.

foxyshadis

7th January 2015, 20:19

I think I got it now, some sort of pop-up windows overlaps EXACTLY over my present window and it re-directs me to: http://www.soft-disc.com/lp/free-download/552/ with a D/L button immediately next to it.

Very tricky of FossHub... a bit un-ethical perhaps.. But I guess they must pay the bills... I had to switch windows to get back at the link. Thanks Mosu...

That's the ad broker's fault, not Fosshub. Contact them with a screenshot and they'll immediately remove the offending ad (and possibly the whole broker). Ads pay the bills, but some go rogue and have to be removed.

Mosu

7th January 2015, 21:11

It was indeed due to an ad. Sam, the admin from FossHub.com, has taken a look and disabled the offending ad. Here's what Sam said/wrote:

Hello,

Mr. Moritz Bunkus, thank you for reporting this!

NO! Under no circumstances we would be doing this. I assume it is a bad advertiser that somehow has managed to bypass our ads. I am manually reviewing all the ads 1-2 times a day and didn't noticed anything like that. Obviously if you can ask that user to show a screenshot we will be blocking that advertiser and its crappy ads immediately!

I will look ASAP based on the info the user has posted and look-up for any similar ads matching his words.

I repeat, we are not associated or promoting anything like that - that single ad Google Adsense ad is our only source of revenue and as I said we are blocking ads.

Regards, Sam - FossHub

Later:

Hello,

Mr. Moritz Bunkus, another update, I just search by "soft" word and indeed there was an advertiser named "soft-disc.com". The reason for not seeing that ad was because of an internal error from Google that was not showing me the entire ad correctly - please take a look at the screenshots.

If I would've noticed that ad - the entire ad it would've been blocked.

I apologize for this, I will try to post on the forum and explain what happened.

Regards, Sam - FossHub

He had difficulties registering an account, therefore I'm posting this in his stead.

Anyway, I hope this eases your worries.

Simon88

7th January 2015, 21:13

Thanks Mosu & foxyshadis,

I just went to http://www.fosshub.com/MKVToolNix.html again and the offending ad is no longer there. Now it's just a simple "non-rogue" banner ad from some other company...

Good to see FossHub was so proactive in disabling the offending ad... :)

LeMoi

7th January 2015, 22:46

Even though the Windows shortcut of mkvmergeGUI is set to open the program in a maximized window, it doesn't. It used to with previous versions (but I don't know in which version it started to behave like that...).

Mosu

7th January 2015, 23:03

Sorry, but I don't fix such issues with the old GUI anymore.

LeMoi

8th January 2015, 23:38

OK, I hope the new GUI is coming soon... Even if the window is maximized, when the muxing process begins, the progression windows is not in a maximized window

DarkSpace

9th January 2015, 00:33

For the simplest case in which the source file doesn't provide its own set of timestamps the following happens (see src/output/p_video.cpp):

The timecode in nanoseconds is calculated as 1000000000.0 * number_of_frames_output / frames_per_second.
This value is immediately truncated to an integer (meaning the sub-ns precision is lost).
The packet is handed over to the core muxing code.
When the core muxing code (src/merge/cluster_helper.cpp) writes a packet into the file it has to scale the timecode to the file's timecode scale value whose default is 1000000 (resulting in nanosecond precision). This is done in src/merge/packet.cpp, function normalize_timecodes(), which uses the preprocessor macro RND_TIMECODE_SCALE. The calculation is: timecode_in_scale_units = integer-round(timecode_in_ns / timecode_scale)
That integer-round() function in turn is pretty much only cast-to-double, add 0.5, cast-to-integer.
I tried building something like what you described here, but it doesn't quite work yet. I also looked at the source code you mentioned, but I couldn't find anything where I might have misunderstood your description, so I'm somewhat puzzled right now, and hope that you can provide further answers.
Nitpick: "scale the timecode to the file's timecode scale value whose default is 1000000 (resulting in nanosecond precision)" in list item #4 - I think you meant "millisecond precision" there.

The initial calculation doesn't have to use floating-point numbers either. Several packetizers only use integer calculation. For example the h.264/AVC parser code does; it simply adds the number of nanoseconds per frame/field to the last known provided timecode.
For what it's worth, I tried both frame-based timecode calculation and timecode incremention, but neither quite worked.

For easier testing, I tried emulating the timecode generation mechanism in Python 3, using the following code:
import decimal
import fractions

def _tcns(frame, rate=fractions.Fraction(24000, 1001), shift_ns=0):
"""
Returns a decimal.Decimal that represents the timecode at frame, truncated to
nanoseconds.
"""
return decimal.Decimal(10**9 * frame // rate) + int(shift_ns)

def _tcscale(tcns, scale=10**6):
"""
Scales the decimal.Decimal timecode, plus shift scaled to ns, in nanosecond
precision to the specified timecode scale, and returns the result as int.
"""
raw = tcns / scale
time = raw.quantize(decimal.Decimal('1'), rounding=decimal.ROUND_HALF_DOWN)
return int(time)

def tc(frame, rate=fractions.Fraction(24000, 1001), scale=10**6, shift_ns=0):
"""
Calculates the timecode at the specified frame number at the given frame rate
plus the specified shift using direct calculation.
"""
tcns = _tcns(frame=frame, rate=rate, shift_ns=shift_ns)
return _tcscale(tcns, scale=scale)

def inc(frame, rate=fractions.Fraction(24000, 1001), scale=10**6, shift_ns=0):
"""
Calculates the timecode at the specified frame number at the given frame rate
plus the specified shift by incrementing the timecode at frame 1.
"""
tcns = frame*_tcns(frame=1, rate=rate, shift_ns=0) + int(shift_ns)
return _tcscale(tcns, scale=scale)
For my tests, I created an h264 video of 480,000 frames length at 24000/1001 fps, which I muxed into mkv using mkvmerge --output out.mkv --default-track 0:True --forced-track 0:False --default-duration 0:24000/1001p in.264 and extracted the video stream's timecodes into a file using mkvextract timecodes_v2 out.mkv 0:timecodes.txt (is it possible to output the timecodes to stdout using some special switch?), which I then compared my functions' results with.

My tests showed that for the end result, it is irrelevant whether I calculate using a fraction or a 64-bit floating point value (I went with a fraction because it seems cleaner to me), and that in order to be consistent with your integer-round(), I would have to round down half values.
Even so, however, I get 143748 mismatches between my function's (tc) results and the timecodes that mkvmerge produced, of which a subset of 114998 mismatches still exists when using the incremental timecode generation (inc).
Usually, I'd expect that I need to re-check my calculations, because when my results are wrong, they're always one ms too large (the difference between the reference timecode from the mkv file and my calculated timecodes (before rounding) is always between -0.458334 and 1.125).
I already did that, however, trying all kinds of permutations of using fractional or floating point values, and the mismatches remain. This leads me to believe that
my calculations are incorrect,
my interpretation is incorrect,
there is a weird floating point behavior in C++ which is different in Python3,
you calculate the full timecodes at special frames (I-frames?) rather than just incrementing them and then continue incrementing from there,
the fps information from the raw h264 file (which also says 24000/1001 fps) somehow influences the timecode generation even though I specified the --default-duration*,
or a combination of the above.
If it helps, I can supply the video (it's just a blank screen at max. qp, the filesize is ~7.5 MB), the timecodes, or any other requirements for reproducing my issues.

* If I specified a default duration and provided some timecode (v2) files, would the default duration take care of the remaining frames if the timecode file is incomplete? If the timecode file is complete, will the value still be written to the header (e.g. if I want to write a default duration of 120p for a VFR file of mixed 24, 30, and 60 fps)?

Mosu

9th January 2015, 09:25

DarkSpace

9th January 2015, 14:21

I'm sorry, but I'm not really interested in debugging your Python code. Note that mkvmerge doesn't use fractions internally, it uses 64bit integers with nanosecond precision. Meaning that your default duration of 24000/1001fps is parsed as as 41708333 (https://github.com/mbunkus/mkvtoolnix/blob/master/src/merge/mkvmerge.cpp#L414), and that is given to the h.264 packetizer code.
Thank you. I checked, and I got the same value for my code, so I know that this part was correct.

The h.264 packetizer code in turn uses half of that value (https://github.com/mbunkus/mkvtoolnix/blob/master/src/output/p_avc.cpp#L68), 20854166, (because it deals in fields and not in full frames) and passes that to the h.264 parser code. The h.264 parser in turn uses that forced value as its internal value for the duration of a single field (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/mpeg4_p10.cpp#L1500).
And that's where my error was, thank you. I calculated the frame's timecode, rather taking the integer half of that timecode and multiplying it by two.
Now I'm down to exactly one error (at 480000), but I'm going to check my maths first.
Thanks again for the quick response!

DarkSpace

10th January 2015, 03:46

Now I'm down to exactly one error (at 480000), but I'm going to check my maths first.
So I re-checked my calculation steps, but I found no error.
According to my insights (read: your information) so far, at 24,000/1,001 fps (h264), the timecode for frame #480,000 should be 20,019,999.36 ms (rounded to 20,019,999), yet the timecode file says that mkvmerge calculated 20,020,000 ms there.
I reached the 20,019,999.36 value the following way:
## ** denotes the power operator; // denotes integer division
duration = 10**9 // (24,000/1,001) # equivalent to int(10**9 / (24,000/1,001)) ### 41,708,333
duration_per_frame = duration - (duration % 2) # I'm dealing with progressive content here ### 41,708,332
timecode_ms = 480,000*duration_per_frame / 10**6 # the nanosecond value, scaled to ms, in floating point ### 20,019,999.36
timecode = round_half_up(timecode_ms) # I was wrong, I have to round up for half values, after all ### 20,019,999
Do you know anything about how mkvmerge reaches 20,020,000 as a result, even though it (presumably) also increments the field-duration?

Mosu

10th January 2015, 08:35

No, I don't. Sorry.

DarkSpace

10th January 2015, 11:04

Thanks anyway. In the meantime, I found out that this affects only the last frame, if it happens (it happened with a length of 480,000 and 1,200,000, but not with 1,200,001), so I guess I'll ignore it.

73ChargerFan

11th January 2015, 10:42

Ah, edge cases...

hubblec4

13th January 2015, 14:26

Hi Mosu

Is it possible to change the duration info for a Matroska file with nanosecond precision in the output of mkvinfo.exe?

|+ Segment information size 160
| + Timecode scale: 1000000 size 7
| + Muxing application: libebml v1.3.1 + libmatroska v1.4.2 size 38
| + Writing application: mkvmerge v7.5.0 ('Glass Culture') 32bit built on Jan 4 2015 16:37:25 size 72
| + Duration: 1.024s (00:00:01.024) size 7
| + Date: Sun Jan 11 19:34:03 2015 UTC size 11
| + Segment UID: 0x8d 0x9e 0xca 0x68 0xc3 0x5e 0x44 0xb0 0xb8 0x4c 0x77 0x47 0xd8 0x59 0x21 0xdf size 19

Optionally you could output the frames and the fps.

Mosu

13th January 2015, 14:39

Technically it would be possible, of course, but I cannot simply change the output. There are way too many tools out there that parse mkvinfo's output somehow, and modifying the numbers presented would provide ample opportunity for breakage.

One option would be to add a switch that enables outputting all timecode values in ns. However, this would require a couple of hours of work and is not something I'm about to do any time soon.

Korgnex

15th January 2015, 20:53

Anyone else having strange issues with splitting a mkv file (encoded with H.264, default settings with mkvmerge GUI (7.5.0)?

I want to split a file into 2 at certain time stamps. However it always ignores those and makes the split about 5 seconds later. When I try it a different way by creating chapters and saving them into the mkv, then load it again and tell it to split by chapters, it still ignores that and makes EXACTLY the same unwanted split as before, 5 seconds from where I told it to split.

The file isn't corrupt either, nothing strange at the beginning of the file, so playback of video and audio is without any flaws from first second to last one.

This is almost like Handbrake used to behave before its recent update. I have a feeling mkvmerge GUI is buggy and currently can't do a simple split job.

HeadlessCow

15th January 2015, 21:19

Mosu

15th January 2015, 21:27

mkvmerge is not a video encoder and can therefore split at key frames. Due to technical reasons mkvmerge splits right before the first key frame after the split point. This is not a bug but conscious design.

Korgnex

15th January 2015, 23:04

There is about 7 seconds blank screen before a new scene starts. Is that a key frame??
I tried to cut within that segment at any possible moment. Yet whatever I enter into "Global ==> Splitting ==> split after duration", it simply cuts too late - already INTO the new scene - as if the just mentioned method the GUI provides doesn't work.

Or does splitting not work the way I assumed it to do? How else would I split it then?

hubblec4

16th January 2015, 00:33

Or does splitting not work the way I assumed it to do? How else would I split it then?

mkvmerge can split a video only at keyframes. it seems you have not a key frame in your video that correspond to your cut time stamp.

the next following key frame will be used for cutting.

you have to check your video with DGIndexNV or AVIDemux to get information about the key frames.

when you encode a video then allways create a key frame for cutting for this specified time stamp.

Korgnex

16th January 2015, 00:57

Thanks, I think this essential limitation should make it into the tool tip because right now the GUI makes it look like you could split at any desired time stamp.

Asmodian

16th January 2015, 01:21

This is one of those "of course it works like that" limitations for those experienced with video but it does make sense to let novice users know. It is slightly more complicated due to the behavior being dependent on the video format. A small mention in the help file could be nice, if the tool tip is too full. :)

foxyshadis

16th January 2015, 03:45

I was going to say "Use AviDemux", but it turns out its smart copy function is only for MPEG-4 ASP. The only ones out there for AVC are SolveigMM Video Splitter (http://www.videohelp.com/tools/SolveigMM-Video-Splitter) and VideoReDo (http://www.videohelp.com/tools/VideoReDo), both with a right hefty price tag.

To do it manually, you have to find the right times, split it into the video before the split, the video after, and the segment itself, re-encode each half of the segment, and then merge them back together. That's what a smart copy editor is supposed to do for you. It's some really annoying manual labor, I've done it a few times, and if you really want to try I can go into more detail.

Sparktank

16th January 2015, 06:51

if you really want to try I can go into more detail.

+1 on seeing a guide on this. I'd archive it for future references.

stax76

16th January 2015, 17:01

Technically it would be possible, of course, but I cannot simply change the output. There are way too many tools out there that parse mkvinfo's output somehow, and modifying the numbers presented would provide ample opportunity for breakage.

In my case I started to parse mkvinfo and mp4box output with regex and this was how it worked many years. Just recently started over from scratch using MediaInfo exclusively with great success.

stax76

16th January 2015, 19:11

@Mosu

I wonder if I could automate mkvmerge to cut various audio formats, it would be no problem creating a video stream with very little data using avisynth's blankclip and virtualdub, I'm in particularly interested in aac and dts.

sneaker_ger

16th January 2015, 19:16

It cuts audio just fine. Any specific problems you ran into?

stax76

16th January 2015, 19:55

I thought I rather ask about potential problems before I write 2-3 hours code.

edit: I created a "fake" avi file with avisynth blankclip and ffmpeg, first try with DTS-MA worked which is awesome, mkvmerge rocks!

Dogway

28th January 2015, 19:57

Since version 6.7.0 or so it is specially slow, almost double slow... I waited for a fix since 7.1.0 was the version I was testing, downloaded 7.5.0 and it's still slow as hell.

stax76

30th January 2015, 17:30

@mosu

After many tests with many different formats and no issues found I changed StaxRip to use mkvmerge as default audio cutter for all audio formats, it's great mkvmerge has such features and everything works reliable.

TS DVB muxing caused a sync issue in my last test, Haali's muxer didn't cause the issue. What I did is first remux ts to mkv and then use StaxRip's cut feature (that now cuts with mkvmerge by default) to encode a short dialog. What also helped is to fix the ts file with TS-Doctor prior mkvmerge muxing. I'll run some more test shortly, maybe it's a known problem.

hello_hello

30th January 2015, 23:36

I'm a bit late to the party but.....

Thanks, I think this essential limitation should make it into the tool tip because right now the GUI makes it look like you could split at any desired time stamp.

If you open a video with MPC-HC and use the Shift key in combination with the left and right arrows on your keyboard, it'll jump between keyframes. The Navigate/GoTo menu will tell you exact frame numbers if you need it.

To do it manually, you have to find the right times, split it into the video before the split, the video after, and the segment itself, re-encode each half of the segment, and then merge them back together. That's what a smart copy editor is supposed to do for you. It's some really annoying manual labor, I've done it a few times, and if you really want to try I can go into more detail.

Pretty please!
I can do the splitting and re-encoding myself, but finding matching encoder settings to avoid the "codec private data doesn't match" errors, that's the part I'd be keen to understand.

Every so often I would like to re-encode just a section of a movie to hardcode some subtitles I didn't know were needed, or I forgot, or to fix some banding I didn't notice etc, and almost every time I end up re-encoding the whole thing because I can't get the bits to join. I know there's --stitchable and it works when I split encodes, but if it wasn't used when the video was originally encoded or if those encoder settings aren't known there must be some serious black magic required. :)

Thunderbolt8

31st January 2015, 17:04

Im curious how splitting files works. I try to split a part of a movie (23.976fps, mkv blu-ray remux, video stream only) from I-frame to I-frame, but I cannot get the end split point right. tried with with split after duration and split based on frame numbers. the end point is always a few frames off, like some frames short or too many. why is that?

e.g. I want to have a piece of 26 frames, the first and last frame are an I-frame. it begins correctly with the first I frame, but then either is 10 frames too long with the exact frame number after 26 frames, or 3 frames too short when I try to have it end 1 frame before that next I-frame.

how can I find out which are the key frames or the key frame positions in my movie?

edit: it seems like the cut always has to begin at an I-frame. thats fine, the problem is just that it always ends with a P-frame 2 frames before the next I-frame and the B-frame in between then gets skipped or rather said its causing image corruption when appending the cuts together (the next B-frame after the I-frame is also corrupted for some reason)

edit: just to clarify, I get this problem when trying to combine cuts from two differnt BDs of the same movie. the frame types at and around the syncing points are the same in both versions though, so I dont know whats causing that problem.

foxyshadis

3rd February 2015, 02:47

You're not losing B-frames, thanks to open GOP they might be referencing the now-missing future I-frame. Those first few corrupted frames after the I-frame are also referencing frames before the I-frame, which is perfectly legal in H.264. That's the difference between an I and IDR frame.

Ex0rcist

7th February 2015, 00:47

Today I was looking through .mkv Header values and I noticed something which I dont understand, why does all audio headers have the same default duration (21333333 = 21.3ms ) value no matter which FPS video has?

nevcairiel

7th February 2015, 01:09

The FPS of the video is entirely unrelated to any audio things. Audio doesn't work that way, the default duration for audio only depends on the codec used, and on the sample rate, but not the video.

Ex0rcist

7th February 2015, 01:33

Ok.. but what does that value actually tell me? How do I know it is actually correct, because sometimes I remux from different containers and I'd like to be sure everything is as it should be. Is it possible to use some kind of formula just to check if it's valid?

cyberbeing

7th February 2015, 03:08

At least in terms of mkvtoolnix, a single audio frame should match the default duration if set correctly. You can check this by opening your mkv with mkvinfo and checking the timecode and number of frames in each simpleblock containing the audio track. For example, if you have a simpleblock with 8 audio frames, and an audio track default duration of 21.333333ms, the duration of each simpleblock containing the audio track should be 170.666664ms. So you would end up with timecodes like 0ms, 170.666664ms, 341.333328ms, 511.999992ms, and so on for your audio simpleblocks within the mkv.

mariner

7th February 2015, 10:05

Question on delay

Greetings Mosu.

Have a question on how MKVToolNix deals with delays present in source when split & join operation is performed.

It seems the delay is preserved the new mkv container if the source is a ts container, but not when the source is mkv container. Is there a reason for the discrepancy?

Many thanks and best regards.

Mosu

7th February 2015, 10:17

Delays are always preserved. So I'll need much more detailed information on what you're doing and what you're observing if I am to comment further.

mariner

7th February 2015, 10:31

Delays are always preserved. So I'll need much more detailed information on what you're doing and what you're observing if I am to comment further.

Which was what I thought. Here's what I did:

1. Original ts has 200ms delay in video.
2. If original ts remuxed to mkv, delay preserved.
3. If original ts remuxed to mkv with split/join, delay preserved.
4. If the mkv from (2) is used for remuxing with split/join, delay no longer preserved.

Shouldn't (3) and (4) produce identical results?

Thanks for your kind reply.

Mosu

7th February 2015, 10:37

Yes, it should, and in a quick test here it does. So I still need more information.

Here's my evidence:

[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s v.mkv|head -n 5
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: Main @L5.1), mkvmerge/mkvextract track ID: 0, language: und, pixel width: 640, pixel height: 352, display width: 640, display height: 352, default duration: 41.708ms (23.976 frames/fields per second for a video track)
Track 2: audio, codec ID: A_AAC, mkvmerge/mkvextract track ID: 1, default duration: 21.333ms (46.875 frames/fields per second for a video track), language: und, sampling freq: 48000, channels: 2
I frame, track 1, timecode 200 (00:00:00.200), size 12973, adler 0xc59f1503
I frame, track 2, timecode 200 (00:00:00.200), size 502, adler 0x379d04bd
I frame, track 2, timecode 200 (00:00:00.200), size 450, adler 0x2ebbd8e2
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o remuxed.mkv v.mkv --split 30s --split-max-files 2 > /dev/null
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s remuxed-001.mkv|head -n 5
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: Main @L5.1), mkvmerge/mkvextract track ID: 0, default duration: 41.708ms (23.976 frames/fields per second for a video track), language: und, pixel width: 640, pixel height: 352, display width: 640, display height: 352
Track 2: audio, codec ID: A_AAC, mkvmerge/mkvextract track ID: 1, default duration: 21.333ms (46.875 frames/fields per second for a video track), language: und, sampling freq: 48000, channels: 2
I frame, track 1, timecode 200 (00:00:00.200), size 12973, adler 0xc59f1503
I frame, track 2, timecode 200 (00:00:00.200), size 502, adler 0x379d04bd
I frame, track 2, timecode 200 (00:00:00.200), size 450, adler 0x2ebbd8e2
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o joined.mkv remuxed-001.mkv + remuxed-002.mkv > /dev/null
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s joined.mkv|head -n 5
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: Main @L5.1), mkvmerge/mkvextract track ID: 0, default duration: 41.708ms (23.976 frames/fields per second for a video track), language: und, pixel width: 640, pixel height: 352, display width: 640, display height: 352
Track 2: audio, codec ID: A_AAC, mkvmerge/mkvextract track ID: 1, default duration: 21.333ms (46.875 frames/fields per second for a video track), language: und, sampling freq: 48000, channels: 2
I frame, track 1, timecode 200 (00:00:00.200), size 12973, adler 0xc59f1503
I frame, track 2, timecode 200 (00:00:00.200), size 502, adler 0x379d04bd
I frame, track 2, timecode 200 (00:00:00.200), size 450, adler 0x2ebbd8e2

Edit: added an example with actual splitting & joining.

mariner

7th February 2015, 11:27

Thanks for your reply, Mosu.

I lack the sophisticated tools needed for detail analysis, so had to rely on mediainfo and eac3to, as well as visual inspection for change in video/audio delay. Here's a ts sample and would appreciate if you could kindly take a look.

https://www.sendspace.com/file/k3ex0j

I've used the following for "split by parts based on timecodes", and also ticked "fix bitstream timing information".
00:00:00.000-00:01:27.158,+00:01:41.163-00:08:29.161

Many thanks and best regards.

Ex0rcist

7th February 2015, 12:02

Mosu

7th February 2015, 14:27

Here's a ts sample and would appreciate if you could kindly take a look.

I still cannot reproduce it, even with your file. Please post the exact command lines you've used in order to create the fourth file – meaning both the command line used for creating 2 from 1 and the one creating 4 from 2.

mariner

7th February 2015, 14:39

Here you go. I have the tags removed.

Step (2)
"C:\Program Files\MKVToolNix\mkvmerge.exe" -o "F:\\mkv\\50_.mkv" "--forced-track" "0:no" "--default-duration" "0:25p" "--aac-is-sbr" "1:1" "--forced-track" "1:no" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "F:\\50\\50_.ts" ")" "--track-order" "0:0,0:1"

Step (4)
"C:\Program Files\MKVToolNix\mkvmerge.exe" -o "F:\\mkv\\cutmkv_.mkv" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1280x720" "--default-duration" "0:25p" "--fix-bitstream-timing-information" "0:1" "--aac-is-sbr" "1:1" "--default-track" "1:yes" "--forced-track" "1:no" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "F:\\50\\50_.mkv" ")" "--track-order" "0:0,0:1" "--split" "parts:00:00:00.000-00:01:27.158,+00:01:41.163-00:08:29.161"

Mosu

7th February 2015, 15:03

Using --default-duration doesn't just set some header files. It also causes mkvmerge to re-calculate all timecodes based on the supplied value, 25fps. This causes the timecodes to start at 0. The --default-duration option, just like the similar --timecodes option, tells mkvmerge »I know better than you how to timecode!« and mkvmerge will simply get out of the way in that case.

So unless you actually need --default-duration don't use it.

mariner

7th February 2015, 15:38

1. I've selected 25fps because if left out, the mkv created is in VFR frame rate mode instead of the fixed 25fps. This seems to confuse eac3to in to reporting the frame rate as 25.381 and giving a warning that the video bitstream framerate field doesn't match the container framerate. Is this the intended behavior? And what's the proper way to create a fixed fps?

2. The 25fps --default-duration option was used in all the three steps. Delay was preserved in steps 2 & 3 (using ts as source), but not in step 4, when the source is mkv. Why the discrepancy?

Many thanks and best regards.

Mosu

7th February 2015, 15:45

1. If you use mkvmerge's append function the the file is inherently VFR. Nothing you can do about that. Ignore eac3to's warning.

2. They use different code paths for packetizing the video.

mariner

7th February 2015, 15:55

Thanks for your kind explanations, Mosu.

Just to reconfirm, if --default-duration is selected when using mkvmerge's append function, delay would be preserved for ts input, but not for mkv input.

Many thanks and best regards.

Mosu

7th February 2015, 16:12

More or less, though the deciding factor isn't the input format but the output module used. For h.264 and h.265 there are two output modules each, depending on whether the track is already in NALU format or not. Inside MPEG TS h.26x isn't in NALU format, inside Matroska it is, therefore the different output code paths.

I may change the behavior of the h.264-as-NALU code to match the behavior of other code path so that such delays will be preserved even if --default-duration is used, but it depends on how invasive that change will turn out to be – if it turns out to require too many changes then I will not do it soon.

mariner

7th February 2015, 16:35

It may not be obvious from the short uploaded sample, but the video is lagging the audio, most likely due to the 158ms delay. Many other hls recordings suffer from the same problem.

So the current behavior actually solves this problem without having to manually compensate for the delay. I wanted to makes sure that my eyes were not fooling me.

Mosu

8th February 2015, 17:25

Hey,

I've released MKVToolNix v7.6.0. It's mainly a bug fix release. Nothing major had to be fixed, though.

Nothing has changed for package maintainers.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

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

...to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

All of the Linux binaries that I provide have already been built and
are available.

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

2015-02-08 Moritz Bunkus <moritz@bunkus.org>
* Released v7.6.0.

2015-02-03 Moritz Bunkus <moritz@bunkus.org>
* all programs: bug fix: Since release 7.0.0 the wrong exit code was used when warnings were finished (0 instead of 1). Fixes #1101 (https://github.com/mbunkus/mkvtoolnix/issues/1101).

2015-02-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Appending chapters with the same chapter UID was dropping all sub-chapters from the one of the two merged chapters. Now the sub-chapters are merged recursively as well.
* mkvmerge: bug fix: The wrong Codec ID was written when reading PCM tracks from Matroska files in Big Endian byte order. Fixes #1113 (https://github.com/mbunkus/mkvtoolnix/issues/1113).

2015-01-23 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a Serbian (Latin) translation of the programs by Danko (see AUTHORS).

2015-01-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If splitting was active and AC3 tracks read from Matroska files were shorter than a split point then the following output file would contain an AC3 packet with the timecode of 00:00:00 somewhere in the middle. Fixes #1104 (https://github.com/mbunkus/mkvtoolnix/issues/1104).

2015-01-14 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: If a chapter track from a Matroska file is selected then the »language« drop-down box is disabled. Fixes #1105 (https://github.com/mbunkus/mkvtoolnix/issues/1105).

2015-01-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: On Windows the end-of-file-reached status wasn't tracked correctly for certain file operations. This could manifest in e.g. mkvmerge not finding tracks in MPEG transport streams when probing MPLS playlist files. Fixes #1100 (https://github.com/mbunkus/mkvtoolnix/issues/1100).
* mmg: bug fix: When scanning for play lists the window presenting the results listed some properties in an unescaped way (e.g. »\s« instead of spaces).
* mmg: bug fix: When adding MPLS files mmg was only offering to scan for more playlists if there were at least two additional MPLS files present. This has been fixed to one MPLS file (in addition to the one just added).

Have fun.

Ex0rcist

9th February 2015, 14:04

Hi,

What could be causing synchronization problem when extracting streams from .flv or .mp4 container and then remuxing them again to .mkv, but when directly remuxing the file audio is perfectly synchronized.

Thanks.

Mosu

9th February 2015, 14:20

When you extract tracks from containers into their elementary streams then a lot of information is lot on the way, among them their timecodes. Therefore: don't do it. Re-mux directly from the source files if at all possible.

One notable exception are subtitle files as they already carry timecode information in their native/elementary formats.

Boulder

9th February 2015, 14:35

So does mkvmerge use existing timecodes for video tracks if VFR Matroska files are used as a source? That does not show up in the GUI and I've sometimes wondered which is the correct way to remux if I just want to re-encode audio into some lossy format.

Ex0rcist

9th February 2015, 14:46

Mosu

9th February 2015, 14:53

Mosu

9th February 2015, 14:54

Is it possible to somehow get timecodes from .mp4 files and use them later when remuxing?

No idea how to extract timecodes from MP4 files. On mkvmerge's end you can use the --timecode option.

foxyshadis

11th February 2015, 03:08

Is it possible to somehow get timecodes from .mp4 files and use them later when remuxing?

mp4fpsmod (https://sites.google.com/site/qaacpage/junk) ~ download (https://sites.google.com/site/qaacpage/cabinet/mp4fpsmod_0.24.zip?attredirects=0&d=1)

hello_hello

16th February 2015, 13:38

Hi Mosu (or anyone else who can help).
I thought I'd ask this question here because while I don't think it's an MKVMerge problem as such (I can duplicate it with GDSMux) I don't know where else to ask. I can duplicate this problem time and time again, at least at this frame rate. The problem is one that arose when discussing a MeGUI related issue here (http://forum.videohelp.com/threads/369714-QTGMC-Script-in-meGUI?p=2374638&viewfull=1#post2374638).

Anyway, the MKV I've linked to is written by the x264 encoder. MediaInfo sees the frame rate as 59.940fps, which is exactly as it should be. After remuxing though, it appears to be 59.880fps. If I remux while specifying a 59.940 frame rate ("--default-duration" "0:60000/1001p"), MediaInfo sees it as being 60fps (MediaInfo actually shows two frame rates, one being "original frame rate"). VLC shows the remuxed MKVs as being 59.94157

I've never seen this sort of oddness when remuxing at other frame rates, so I'm just trying to work out if something odd is happening, or whether the programs are lying and I should just ignore it all.

Thanks.

http://ge.tt/5ApLhZA2/v/0 (7.7MB)

ndjamena

16th February 2015, 17:36

Really, you're posting VideoHelp links here?

I'll raise you one:

http://forum.videohelp.com/threads/368819-MKV-Merge-Makes-29-97-file-into-30

And give you some Sourceforge to boot:

https://sourceforge.net/p/mediainfo/bugs/882/

MKVMerge uses a time base of 1000000ns, which amounts to an accuracy of 1ms. X264 and quite a few other programs use a time base of 50000ns, which gives a far more accurate representation of display time. Apparently 1ms isn't accurate enough for whatever frame rate heuristic MediaInfo uses to detect the frame rate at 60/1.001 fps. Since each frame at that frame rate has a shorter duration than in most other standard frame rates small inaccuracies in the time codes have a greater effect.

Mosu

16th February 2015, 17:53

Also related: this fine FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed) about frame rates and Matroska.

ndjamena

16th February 2015, 19:42

The information is simply not there – simply because it is not needed for playback which can work just fine without that information.

I don't completely agree with that statement. My WDTV Live SMP actually sets the frame rate being passed to my TV through HDMI to 23.976fps when I'm playing a blu ray rip. I know it shouldn't and I know it shouldn't be getting frame rate info from the stream headers but the alternative is to simply up the frame rate as far as possible and hope for the best. Since the HDMI link is limited to 60 or 50 frames per second and TVs can come at 120fps now days it's probably better to transfer the actual frame rate through the link for the TV to display as it will rather than relying on it auto establishing some kind of film mode.

hello_hello

16th February 2015, 22:18

Really, you're posting VideoHelp links here?

Yeah. I post doom9 links at VideoHelp too. Is there a rule or something?

Anyway, thanks guys. I assume the difference in reported frame rate is nothing to worry about.

foxyshadis

17th February 2015, 02:25

MKVMerge uses a time base of 1000000ns, which amounts to an accuracy of 1ms.

Anything more is a waste for playback, since most renderers have a jitter well above 1ms anyway. You can always set your own with --timecode-scale, if MediaInfo's accuracy is absolutely necessary, but this is really more of a MediaInfo missing feature: if it scanned 30 seconds in, it'd see the duration overrides, but MediaInfo doesn't ever do deep scans of files if there's a way not to, and no option to override to get better data. For the same reason it can't detect VFR. Just take anything it says with a grain of salt.

In fact, because MediaInfo simply reports DefaultDuration, a badly broken muxer could set the value to anything and then override it with the real frame time on every frame. Only mkvinfo's debug report will be truly accurate. Fortunately, pathological behavior is rare.

Yeah. I post doom9 links at VideoHelp too. Is there a rule or something?

Not at all, nothing wrong with VideoHelp and others like AVSForum.

ndjamena

17th February 2015, 05:06

I was just a little taken aback that you had to ask it over here. I guess I was absent then. (Plus, you obviously hadn't read the thread that dealt with that topic already, or the report on the MKVToolNix bug tracker that mentioned it, or the MediaInfo thread... Maybe I'm thinking of someone else.)

Zenitram

17th February 2015, 09:07

Anything more is a waste for playback, since most renderers have a jitter well above 1ms anyway.

If you consider MKV only as a "lossy" container format, right, but some people would like to not lose some piece of information.
Example: some people (here, I don't say they are right, I say what they want) want to see the difference between the following frame rates:
29.970000000 fps (which is not the exact US typical frame rate, see the number below), frame duration is 0.033366700 second
30000/1001 fps [~29.970029970 fps), frame duration is 0.033366667 second
30.000000000 fps, frame duration is 0.033333333 second

and Matroska does not permit easily, as far as I know, to differentiate these frame rates, even if the complete file is parsed.
In some other containers (e.g. MP4), timescale has a numerator and denominator, so timescale can be e.g. 1000/2997, 1001/30000, 1/30.
In some other containers (e.g. MPEG-TS), time is at 90 kHz (so easy to catch the US frame rate)

This is true it is useless for playback.
But it may be useful if you want to know the exact frame rate (and yes, it matters for some people).

if MediaInfo's accuracy is absolutely necessary, but this is really more of a MediaInfo missing feature: if it scanned 30 seconds in, it'd see the duration overrides, but MediaInfo doesn't ever do deep scans of files if there's a way not to, and no option to override to get better data. For the same reason it can't detect VFR. Just take anything it says with a grain of salt.

MediaInfo is definitely buggy on this side, the algo is crappy and I did not take the time to find a better one.
FYI, it is possible to override MediaInfo default behavior in order to scan the complete file but it has not been tested for Matroska (maybe something else in the code will prevent MediaInfo to compute right information) because there is currently no sponsorship for Matroska (it may change in the near future (https://mediaarea.net/en/PreForma_MediaInfo_Phase1)).

Keep in mind that default MediaInfo behavior has a goal of quickly (=without parsing the whole file) being able to report information, it has not the goal of detecting uncommon and difficult to detect cases (e.g. fixed frame rate during 1 hour, then 10 seconds of VFR), specific implementation of MediaInfo (with some constraints e.g. parsing time) may be coded for that.

But Mosu has added few months ago some statistical metadata, and it may help to resolve the issue with new files.

DR;TL: for the moment, the biggest issue is in MediaInfo, for sure.

Jérôme, developer of MediaInfo.