MKVToolNix v24.0.0 released

[Mosu]

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]

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]

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]

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]

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]

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]

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

[Mosu]

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]

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

Thank you!

[LeMoi]

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

[easy...rider]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[dungpt]

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

[Mosu]

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]

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

[Mosu]

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]

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

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

[Mosu]

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]

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

That as well, yes.

[mindbomb]

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]

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]

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

[cafevn]

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

[Mosu]

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]

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]

Meh... 'course I did.

[sneaker_ger]

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

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]

Nice, thx.

[Betsy25]

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]

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]

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]

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]

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

[LeMoi]

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]

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]

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! :)

[Atak_Snajpera]

mosu what is current progress regarding opus codec?

[Chetwood]

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

[Mosu]

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]

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.