MKVToolNix v24.0.0 released

[Mosu]

Note: The latest release is v25.0.0 (http://forum.doom9.org/showthread.php?p=1846426#post1846426). Yes, that's in a new thread.

Hey,

I've released mkvtoolnix v4.0.0. This release features full support for the WebM variant of the Matroska container format, VP8 video tracks, the IVF container format. It also contains a new translation into Dutch.

There are two changes for package maintainers: 1. the new translation I've mentioned and 2. mkvtoolnix requires the new releases libebml v1.0.0 and libmatroska v1.0.0 available at http://dl.matroska.org Both libraries are not binary-compatible with earlier releases, but they're source-compatible. These libraries are only needed if you want to compile your own package. You do not need them if you're using one of the binary ones.

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-4.0.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.0.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.0.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 3.4.0:

------------------------------------------------------------
2010-06-05 Moritz Bunkus <moritz@bunkus.org>
* Released v4.0.0.
* build: Building mkvtoolnix now requires libebml v1.0.0 and libmatroska v1.0.0 or later.

2010-06-04 Moritz Bunkus <moritz@bunkus.org>
* all command line tools: bug fix: Fixed the output of eastern languages like Japanese or Chinese under cmd.exe on Windows.

2010-06-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added the estimated remaining time to the mux and job dialogs.

2010-05-31 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation of the programs into Dutch by Ren?? Maassen (see AUTHORS).

2010-05-28 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: feature removal: Removed support for extracting FLAC tracks into Ogg FLAC files. Instead they're always written into raw FLAC files. The option "--no-ogg" has been removed as well.
* mkvmerge: feature removal: Removed support for the FLAC library older than v1.1.1.
* mkvmerge: bug fix: Fixed support for reading FLAC tracks from Ogg files following the FLAC-in-Ogg-mapping established with FLAC v1.1.1. Fix for bug 488.

2010-05-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The "mkvmerge executable" input in the preferences dialog is not read-only anymore. Final part of a fix for bug 490.
* mmg: bug fix: mmg will output a warning if it is used with a mkvmerge executable whose version differs from mmg's version. Part of a fix for bug 490.
* mmg: bug fix: If adding a file fails mkvmerge's error message will be shown in a scrollable dialog instead of a normal message box. Part of a fix for bug 490.
* mmg: Added 'IVF' files to the list of known input file types.
* mkvmerge: Added support for reading IVF files with VP8 video tracks.
* mkvextract: Added support for extracting VP8 video tracks into IVF files.

2010-05-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvinfo, mkvextract: bug fix: Fixed handling of clusters missing a cluster timecode element.
* mkvinfo GUI: bug fix: Frames for simple blocks were shown at the wrong place in the element tree.

2010-05-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: Fixed handling of clusters with an unknown size.

2010-05-22 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Fixed handling clusters with an unknown size.
* mkvinfo: new feature: Added an option ("-z" / "--size") for displaying each element's size property. Elements with an unknown/infinite size are shown as "size is unknown".

2010-05-21 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added a checkbox for enabling "WebM" mode. This will also enable the same limitations that mkvmerge enables: Only VP8 and Vorbis tracks, no chapters, no tags. The output file name extension will be changed to ".webm" upon enabling the mode.

2010-05-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: change: mkvmerge will not write track header elements whose actual value equals their default value anymore.

2010-05-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Neither chapters nor tags will be written to WebM compliant files. Warnings are issued if chapters or tags are found and not disabled.
* mkvmerge: bug fix: Matroska files without clusters are accepted as valid input files again.
* mmg: enhancement: Added "WebM" with the extension "webm" to the list of known file types.
* mkvmerge: new feature: Added support for muxing VP8 video tracks.
* mkvmerge: enhancement: mkvmerge will no longer put all clusters into a meta seek element resulting in smaller file size. The parameter "--no-clusters-in-meta-seek" has been renamed to "--clusters-in-meta-seek" and its meaning reverted.
* mkvmerge: enhancement: WebM compatibility mode will be turned on automatically if the output file name's extension is '.webm', '.webma' or '.webmv'.
* mkvinfo GUI: enhancement: Added "webm" to the list of known file name extensions for WebM files both for the "Open file" dialog and the drag & drop support.

2010-05-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added options "--webm"/"--web-media" that enable the WebM compatibility mode. In this mode only Vorbis audio tracks and VP8 video tracks are allowed. Neither chapters nor tracks are allowed. The DocType element is set to "webm".
* mkvinfo GUI: bug fix: Opening more than one file without restarting mkvinfo GUI could result in wrong timecodes due to variables not being reinitialized.

2010-05-16 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Binary elements shorter than 10 bytes were not output correctly.

2010-05-15 Moritz Bunkus <moritz@bunkus.org>
* Build system: bug fix: The man page installation process only installed the English originals instead of the Japanese and Chinese translations.
------------------------------------------------------------

Have fun.

[Keiyakusha]

mkvextract: feature removal: Removed support for extracting FLAC tracks into Ogg FLAC files. Instead they're always written into raw FLAC files
Ohh finaly! I hate that oggflac so much!

Anyway, thanks for the new version. Congratulations with yet another major release!

[rica]

Thanks mosu.

Does it give thd+ac3 support?

[Mosu]

If you mean that it keeps the AC3 core then no. And don't hold your breath; I won't implement such a feature.

[rica]

If you mean that it keeps the AC3 core then no. And don't hold your breath; I won't implement such a feature.

Thx for the quick response but why not?

[Mosu]

Because in Matroska you have one codec per track, not two. If you need something like that you'll have to use MPEG TS or some other muxer that allows this. mkvmerge won't.

[rica]

So this feature request must be made to Haali or whatever?

[73ChargerFan]

Thanks for the new version!

Because in Matroska you have one codec per track, not two. If you need something like that you'll have to use MPEG TS or some other muxer that allows this. mkvmerge won't.
A DTS-MA track ripped from a blu-ray disk works fine, and has a dts core. :confused:

[Mosu]

DTS-HD master audio is different from TrueHD+AC3. With DTS-HD the "master audio" part is actually only the difference between the lossy core and the lossless original. Therefore a decoder needs both the core and the HD part in order to decode losslessly.

With TrueHD+AC3 this is not the case. The TrueHD is completely decodable on its own without the AC3 part.

[b66pak]

thanks a lot...
_

[D.A.S.]

Peoples, this is just I have a problem with the flags in version 4.0?
Returned 3.4.

[Mosu]

mkvmerge 4.0.0 does NOT write default values in the headers anymore. Default values are a feature that the Matroska specifications have had since the beginning (2002). For example, the default value for the track language is "eng" (English). Therefore this value will not be written to the headers if its actual value is "eng".

Any player still having problems dealing with this should be fixed. Those are bugs in the reading application (player), not the in the writing application (mkvmerge).

[D.A.S.]

Hmm...

For example, have the video stream and audio stream, and 2 versions of the subtitles, "eng" and "rus", I point "rus" subtitles to be - default.
Then after muxing and adding created file to Mkvmegre GUI displays all streams in default track flag - no.
This is normal right? >_<

[Abradoks]

mkvmerge 4.0.0 does NOT write default values in the headers anymore. Default values are a feature that the Matroska specifications have had since the beginning (2002). For example, the default value for the track language is "eng" (English). Therefore this value will not be written to the headers if its actual value is "eng".
While you are technically right, IMO not setting "eng" code is wrong.
1) Such meta information should be set explicitly. Defaulting to "eng" in standard is very arguable.
2) It's not default value in mkvmerge. When user explicitly sets this parameter he obviously wants it to be in the file. As I understand, now there is no way to write language value as "eng".
3) You are breaking compliance without reason.
So please revert this change. When user specifies some parameter it should be written to the file. Or am I missing something?

[Mosu]

I'm not reverting the change. The specifications state explicitely that in case of an absent element its default value must be used instead. I'm not breaking compliance, I'm forcing others to fix their bugs.

For example, have the video stream and audio stream, and 2 versions of the subtitles, "eng" and "rus", I point "rus" subtitles to be - default.
Then after muxing and adding to Mkvmegre GUI displays all streams in default track flag - no.

That's indeed a bug in mkvmerge's handling of the files. I'll fix it.

[D.A.S.]

Also, in a small confusion regarding the present editing the header using the header editor.

[Abradoks]

I'm not reverting the change. The specifications state explicitely that in case of an absent element its default value must be used instead. I'm not breaking compliance, I'm forcing others to fix their bugs.
You are not breaking spec compliance, you are breaking compliance with some players. Of course those players should be fixed. But old behavior of mkvtoolnix was spec compliant too and it wasn't causing any problems.
Also, current behavior is unexpected and limiting. Specs don't say you shouldn't write "eng" value. Those defaults are for playback applications, not for muxers. It can be changed to "und" at any time (and that would be reasonable).

[Mosu]

If I change back then app developers will have no reason to fix their broken implementations -- again. I'm sorry, I won't change it back.

[Abradoks]

If I change back then app developers will have no reason to fix their broken implementations -- again.
Why do you care? There are many more important bugs and missing features in current implementations. This one doesn't make any sense. It was artificially raised by you.
Its even more logical to display "Not specified" instead of "English" when language tag isn't presented (but it's spec issue).
Nevertheless, you could just add something like "--language 0" meaning "don't write this tag". And if you want so much to break other apps you could specify it as default for "--default-language". That will be logical and won't remove functionality.

[Mosu]

I'm not discussing this any more. Sorry.

BTW: A few years ago there has already been exactly the same situation. mkvmerge switched to not writing the default values, users complained, I switched back. Obviously nothing changed on the playback side, so I'm upping the pressure on the others a bit now. I don't believe in "compatibility above everything else". With other specs people are very quick to blame the readers if they don't comply, while with Matroska everyone expects the muxers to circumvent bugs in the players. I want that to change.

[DeathWolf]

It's a bit sad to see devs. going on a crusade against the world. But alas it is of course your final choice. I would rather be able to force explicitly language for all tracks even if it's the default value, should it be for the idea that everything is *marked* and there isn't random things unmarked because their value is default. I can very well go along the idea of having the default behavior not mark defaults, but if I want to mark them I should be able to...

[Kurtnoise]

It's a bit sad to see devs. going on a crusade against the world. But alas it is of course your final choice. I would rather be able to force explicitly language for all tracks even if it's the default value, should it be for the idea that everything is *marked* and there isn't random things unmarked because their value is default. I can very well go along the idea of having the default behavior not mark defaults, but if I want to mark them I should be able to...
if you don't like it, fork it...plain & simple.


Thanks Mosu for your unbelievable work on these tools. Keep it the great work.

[DeathWolf]

if you don't like it, fork it...plain & simple.


Thanks Mosu for your unbelievable work on these tools. Keep it the great work.

Interesting reaction there. I was just expressing the way I feel. And while forking is something that seems "easy" to the eye, fragmentation is never good. It seems to me you your reaction was fairly... how to say... non constructive and inflammatory.

I was just hoping a non-default option would allow to force default tags, that's all.

[sneaker_ger]

/edit: nevermind...

[Atak_Snajpera]

While you are technically right, IMO not setting "eng" code is wrong.
1) Such meta information should be set explicitly. Defaulting to "eng" in standard is very arguable.

I agree! Since when english is the most important language on Earth??? It's very useful but it does not mean that it is above the rest. I as a Pole would like to see Polish language as default. People in Southern America would like to have spanish or portuguese as default and so on. Default language should not exists because there is no default language for all people. It is funny that you mosu as a german don't understand us. Please explain me why every movie in german is dubbed !?!? Why Brad Pit does not speak in english :) What you did does not make sense at all. If language is not specified it should be automatically marked as 'und' . If language is english then it must be 'eng' and so on! No exceptions!

[LeMoi]

Mosu said he's not discussing any more because some years ago he had same conversation with other people and made the changes he made. That's why he just doesn't want to change this feature any more, people won't stop changing their mind :)

[Atak_Snajpera]

He should use common sense. If I was doing everything what users want ripbot264 will probably end up as another bloated MeGui!

[sneaker_ger]

If language is not specified it should be automatically marked as 'und' . If language is english then it must be 'eng' and so on! No exceptions!

If you don't specify any language mkvmerge will still use "und" as the default flag. Only if you explicitly tell it to flag as "eng" no tag will be written.
But I agree that no tag equaling "eng" may not be a wise decision, but changing it now would only increase confusion and break backward compatibility. (Although that's no reason not to write the "eng" tag as before, but it seems that we can't do aynthing about it...)
I made a short test and both Haali's and Gabest's splitters and VLC interpreted the files correctly.

[Mosu]

I agree! Since when english is the most important language on Earth??? It's very useful but it does not mean that it is above the rest. I as a Pole would like to see Polish language as default. People in Southern America would like to have spanish or portuguese as default and so on. Default language should not exists because there is no default language for all people. It is funny that you mosu as a german don't understand us. Please explain me why every movie in german is dubbed !?!? Why Brad Pit does not speak in english :) What you did does not make sense at all. If language is not specified it should be automatically marked as 'und' . If language is english then it must be 'eng' and so on! No exceptions!

Please read sneaker_ger's answer. mmg is still defaulting to using "und" when you add a track from a container that does not contain language tags, e.g. AVI files or raw h264 files.

"eng" being the "default value" only applies to the container level. If the "language" element is not present in the file then a reading application has to use "eng" instead. This is indeed not the best value ("und" would have been better), but that's what the speficiations say since 2002. You cannot simply change that now and break every spec compliant program out there.

Like sneaker_ger said: mmg will select "und" by default. If you select "eng" on purpose only then will the "language" element not be written into the file. This is not "us" wanting to dominate the world (hey, I'm German and don't like the US's attitude of them being the center of the Universe either). It's rather a minor technicality.

Some more reasons why I'm not changing this back. Back in 2002 when Matroska was created I was there. I started the first program actually being able to create Matroska files. I wrote the very first patch for the very first player being able to play Matroska files (mplayer). I've been pushing it ever since. Now if I stopped pushing all of it and only concentrated on a common sub-set supported by every player out there then that would mean Matroska will never move forward again. Things like linked files would never happened. You'd never have totally uncommon stuff like FLAC, Kate, Dirac in Matroska. Hell, you'd never have had Matroska in the first place! Never mind the WebM project which would either not have happened at all or with something completely different -- maybe MP4, maybe not even that but Ogg.

Without pushes, without applications using more than just the most basic features no further development will be made. With unchartered territory there's always someone who's first to chart it, and that process is not always an easy one. In this case I'm not even the first. Like sneaker_ger said Haali, VLC support this properly, maybe even some or most hardware players (I only have one to test against, but it doesn't show the track's language anyway).

[GodofaGap]

I don't quite understand the consternation yet. I just muxed a file and set the language of both audio and video to eng, and both Haali, MPC-HC and VLC reported the track languages as English.

Which players do not support this? It doesn't seem like a particularly hard thing to implement anyway...

[Atak_Snajpera]

"eng" being the "default value" only applies to the container level. If the "language" element is not present in the file then a reading application has to use "eng" instead. This is indeed not the best value ("und" would have been better), but that's what the speficiations say since 2002. You cannot simply change that now and break every spec compliant program out there.
Can you at least modify mkvinfo.exe to show language?

+ A track
| + Track number: 2
| + Track UID: 253140655
| + Track type: audio
| + Enabled: 1
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 1
| + MinCache: 0
| + Timecode scale: 1
| + Max BlockAddition ID: 0
| + Codec ID: A_VORBIS
| + Codec decode all: 1
| + CodecPrivate, length 4330
| + Language: eng
| + Name: 2.0 Vorbis
| + Audio track
| + Sampling frequency: 48000
| + Channels: 2
| + A track

[Mosu]

Can you at least modify mkvinfo.exe to show language?

No. mkvinfo is designed to show the elements that are actually present. If you want to know things like basic flags, track type and language you can use "mkvmerge --identify-verbose yourfile.mkv". That's what mmg does when you add a file.

[EricJ2190]

I like the idea of not writing default flags and I don't think you should revert that behavior, but how about a command-line option to write default flags if we want that behavior?

If you aren't willing, I'll try and make a modified version for my own use, but I'd like to see that as an option in the official mkvmerge.

[Mosu]

I certainly won't add such an option myself, but I might consider applying patches if anyone wrote them. Such an option would have to be off by default, it won't show up in mmg (mmg is way too crowded as it is already), and it must be documented in the man page (DocBook XML).

[73ChargerFan]

DTS-HD master audio is different from TrueHD+AC3. With DTS-HD the "master audio" part is actually only the difference between the lossy core and the lossless original. Therefore a decoder needs both the core and the HD part in order to decode losslessly.

With TrueHD+AC3 this is not the case. The TrueHD is completely decodable on its own without the AC3 part.
Thanks for clarifying this.

[guillome]

Hi Mosu,

It seems that starting yesterday Avira AV started to see the mmg.exe located in the mkvtoolnix program folder as a trojan (TR/Dldr.Agent.dsqn' [trojan])

Looking on google, it seems kaspersky went for it too: http://forum.kaspersky.com/index.php?showtopic=172738

That was with v3.4.0 that i had been using since its release.

Gonna install v4.0.0 and report if it happens again. :devil:

[sneaker_ger]

mmg 4.0.0 : 1/41 scanners say it's infected (http://www.virustotal.com/de/analisis/50b9ae0fcc3ed9f1c3e0fae5f7de5663344a5a4c7dac81fa074e21195af62899-1276097920)
mmg 3.4.0 : 3/41 scanners say it's infected (http://www.virustotal.com/de/analisis/34d773441c8a8711206c5261adf3ea01eefd8d4e8ea1c8d6211c8e8ef2d18ee7-1276098129)
(hope the links work)

[Mosu]

Please report those findings to the AV makers. I cannot do anything about it but report them there as well. Again.

[sneaker_ger]

small addition to my previous post:
MPC-HC's splitter is NOT working fine without the language tag, but only subtitles are affected. ( error description (http://forum.doom9.org/showpost.php?p=1405881&postcount=13140) ) Use Haali's splitter (for now).

[Mosu]

Is there any support for H264 streams with open-gop planned? There are some problems with seeking which is probably caused by a missing support for open-gop in mkv. The problem and its possible cause are explained here: http://forum.doom9.org/showpost.php?p=1401348&postcount=178.

I just created an open GOP file with a patched x264 v1564. mkvmerge v4.0.0 can handle the file just fine without any further modification. Like I said mkvmerge already treats the first non IDR slice after a SEI NALU as a key frame from the container's point of view. So I guess this just works.

[sneaker_ger]

What will happen if we want to split such files? Will we see corruptions (as to missing I-frames) at the end of a file?

[foxyshadis]

What will happen if we want to split such files? Will we see corruptions (as to missing I-frames) at the end of a file?

Only in the very last frames of the open gop, if any reference the I. Going forward, nothing should because the x264 open-gop patch clears the ref list at each gop, so no corruption is possible. (However, you've always been able to set the gop to infinity and use i-frames only for scenecuts, where later frames can reference pre-I frames.) mkvmerge won't enforce an IDR (closed GOP) split.

Mosu: Concerning the discussion above, I appreciate anything enforcing higher efficiency, even if it's only a few bytes!

[Mosu]

mkvmerge won't enforce an IDR (closed GOP) split.

That's correct. mkvmerge doesn't distinguish between IDR-type key frames and non IDR-type keyframes outside of the MPEG4 p10 handling code. And the splitting code is a layer or two above that code.

Modifying this to pass extra information up to that layer (e.g. "splitting possible before this frame?") would not be that hard, but I won't spend more time on this until it's been officially accepted into x264. Other things to do as well :)

[Egh]

Hello Mosu,

in your most recent build, i.e. 265, there's quite a strange error.

I cannot add AC3s to the project in mkvmerge GUI cause mkvmerge crashes :)

http://imgur.com/qpnom.png

mkvmerge.exe itself crashes @ 001e4a8e but I guess that is not much useful :)

[Mosu]

Can you please upload the first 20mb of the file to my FTP server?

[Egh]

Can you please upload the first 20mb of the file to my FTP server?

That has been done. Not all files have this problem however I reckon a specific type of them does. I.e. I have found several files with such problem and uploaded the smallest of them. I think 448kbps 2_0 are broken (maybe some other types as well)

[Mosu]

That has been done. Not all files have this problem however I reckon a specific type of them does. I.e. I have found several files with such problem and uploaded the smallest of them. I think 448kbps 2_0 are broken (maybe some other types as well)

Thanks. I'm not at home for a couple of days and will not be able to take a look at it before next weekend though.

[Egh]

Update: didn't test extensively but I was able to replicate it even with 264 build mkvmerge.exe

I finally got rid of the problem by only replacing the exe file with the one from 3.4.0.0. So the problem is limited with mkvmerge.exe file.

Worse news -- it is a generic error it seems, so any track can potentially crash it, I was able to get a crash on h264 stream, for instance.

[Mosu]

The problem is not a generic problem. mkvmerge v4.0.0 just received a lot of updates in almost every part of its code, and that's why you may see such issues in multiple cases.

I've fixed the issue for the AC3 detection code in build 269 (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.0.0-build20100615-269-setup.exe). I haven't been able to reproduce the issue with h264 tracks though. Could you please upload the first 40 MB of that h264 that causes your crash?

[Egh]

I haven't been able to reproduce the issue with h264 tracks though. Could you please upload the first 40 MB of that h264 that causes your crash?

No problem, uploading 50mb segment. It crashes 265 build mkvmerge in the same way as AC3 did (obviously the whole file crashes it as well)

However it seems to be fixed in 269 build, both AC3 and h264 now seem to work.

[Mosu]

No problem, uploading 50mb segment. It crashes 265 build mkvmerge in the same way as AC3 did (obviously the whole file crashes it as well)

However it seems to be fixed in 269 build, both AC3 and h264 now seem to work.

That makes sense. The bug was in the AC3 detection code, and the AC3 detection is run before the h264 detection. So thanks for the upload, and I'll test it myself, but I don't think that there's another bug in the h264 code.

[moviefan]

I just created an open GOP file with a patched x264 v1564. mkvmerge v4.0.0 can handle the file just fine without any further modification. Like I said mkvmerge already treats the first non IDR slice after a SEI NALU as a key frame from the container's point of view. So I guess this just works.

Indeed you're right. I seem to have patched with a corrupt open-gop patch which caused the issue. Now it works. Thanks for checking the open-gop support, too.

[jasonwc]

I found a minor regression after switching from Mkvmerge 3.4 to 4.0. With 3.4, a subtitle's description and language showed correctly in MPC-HC using the internal Matroska splitter. With 4.0, subtitles display as Unknown (English) even though there is a description. I also noticed a difference in Mediainfo output:

Mkvmerge 3.4:

Text
ID : 5
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : English
Language : English

Mkvmerge 4.0:

Text
ID : 5
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : English

I used identical settings to mux both. The former shows up as English (English) and the latter Unknown (English) in recent SVN builds of MPC-HC. I can post a sample file if necessary, but this issue is easily reproduced.

EDIT: Sorry, I went back a few pages and saw that this is not in fact a bug of Mkvmerge. I'll move my request to the MPC-HC thread.

[Mosu]

Here's a build that can read PGS/SUP files directly (mkvmerge could already handle PGS subs in Matroska files): http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.0.0-build20100618-270-setup.exe

[dbone1026]

Here's a build that can read PGS/SUP files directly (mkvmerge could already handle PGS subs in Matroska files): http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.0.0-build20100618-270-setup.exe

Thanks Mosu, I have just confirmed that PGS subtitles worked perfectly with the new build

[SamuriHL]

thanks mosu, i have just confirmed that pgs subtitles worked perfectly with the new build

sweet!!!!!!

[SamuriHL]

Hey quick question. So I have a bunch of MKV's I've done with MKVMerge already and I had the subs in another folder. I used the original MKV as the source for MKVMerge and added the subs, but, I lost the embedded chapters. Am I doing something wrong?

[Mosu]

Not enough details. Usually mkvmerge copies the chapters unless you tell it not to (e.g. by disabling chapters in mmg or with command line options).

[SeeMoreDigital]

With reference to this post (http://forum.doom9.org/showthread.php?p=1409364#post1409364)...

I've generated a couple of "PGS" test muxes with the new build and although VLC player v1.1.0 RC is able to detect the PGS subtitle stream (as before), it can't display it (unlike before).


Cheers

[SamuriHL]

Not enough details. Usually mkvmerge copies the chapters unless you tell it not to (e.g. by disabling chapters in mmg or with command line options).

When I created my original MKV with mkvmerge 4.0.0, I added my video and DTS-HD MA tracks, and then went to the global tab and loaded a chapter file. The streams I used were all extracted using EAC3to. If I look at the original with media info, I see the chapter info at the bottom of the page. I now load that MKV into the mkvmerge GUI as the source. It sees the video and audio tracks, but, I don't see the chapters anywhere. When I output it, the chapters are lost in the output. I guess I can extract the chapter.txt file from the original and add it to the global tab, but, I was just wondering if I was missing something. You said it should copy the chapters, but, in this case it doesn't seem to be doing so. Didn't know if I did something wrong.

[Mosu]

I've generated a couple of "PGS" test muxes with the new build and although VLC player v1.1.0 RC is able to detect the PGS subtitle stream (as before), it can't display it (unlike before).

Try to disable compression for the subtitle track. Maybe your copy of VLC has problems with default values. For example:

mkvmerge -o out.mkv --compression -1:none in.mkv

Or use mmg and disable compression for all PGS tracks.

[Mosu]

You said it should copy the chapters, but, in this case it doesn't seem to be doing so.

Try to run "mkvmerge --identify-verbose in.mkv" on one of your original file (the one for which you do see the chapters). Post the result here.

Please also run "mkvinfo -v -v -z in.mkv --redirect-output in.txt" and upload the in.txt file to my FTP server (compressing it first with 7zip/RAR/ZIP/LZMA is fine).

[SeeMoreDigital]

Try to disable compression for the subtitle track. Maybe your copy of VLC has problems with default values. For example:

mkvmerge -o out.mkv --compression -1:none in.mkv

Or use mmg and disable compression for all PGS tracks.Okay...will do.

I think this is what Sami is referring too: -

Old build
http://img138.imageshack.us/img138/6609/previousbuild.png

New build
http://img3.imageshack.us/img3/5778/newbuild.png

Cheers

[SamuriHL]

Try to run "mkvmerge --identify-verbose in.mkv" on one of your original file (the one for which you do see the chapters). Post the result here.

Please also run "mkvinfo -v -v -z in.mkv --redirect-output in.txt" and upload the in.txt file to my FTP server (compressing it first with 7zip/RAR/ZIP/LZMA is fine).

Sure thing. Give me a few minutes as I'm in the middle of another encode but I will get to you asap. Thanks!!

[SamuriHL]

Yes, that's right. That's exactly what I'm saying. I was able to extract them using MKVCleaver and re-added them. Just curious as to why it wasn't detected. That's all.

[Mosu]

Definitely a bug that I haven't been able to reproduce yet. How big is such a file? Could one of you upload such a file to my FTP server? I don't have any disc to make my own file with MakeMKV.

[SeeMoreDigital]

Try to disable compression for the subtitle track. Maybe your copy of VLC has problems with default values. For example:

mkvmerge -o out.mkv --compression -1:none in.mkv

Or use mmg and disable compression for all PGS tracks.Nice one...

With "Compression" set to "None", the PGS subtitles are now displayed okay in VLC player v1.1.0 RC

Thanks Mosu

[SeeMoreDigital]

Definitely a bug that I haven't been able to reproduce yet. How big is such a file? Could one of you upload such a file to my FTP server? I don't have any disc to make my own file with MakeMKV.The "MakeMKV" sample can be found here: http://forum.doom9.org/showpost.php?p=1409335&postcount=1908

[Mosu]

With "Compression" set to "None", the PGS subtitles are now displayed okay in VLC player v1.1.0 RC

Please complain to the VLC developers that they should fix their handling of default values. In this particular case the default value they don't seem to use is the value '0' for the ContentCompAlgo element -- see http://www.matroska.org/technical/specs/index.html for details.

[SamuriHL]

Yea, my "samples" are in the neighborhood of 25 gigs so... :D

P.S. Mine happened with a mkvmerge created MKV just as an FYI.

[SeeMoreDigital]

Okay, will do. Thanks Mosu ;)

[SamuriHL]

Mosu, do you still need me to upload anything? I would think that now that you have a sample you could repro the issue? If not, I can still upload what you requested.

[SamuriHL]

Um, hmm. I just noticed something. I'm working on a TrueHD track right now. It says that it's using pass through for that. When I do DTS-HD MA tracks, it says it's doing DTS output module. Is it possible this DTS output module is causing problems with the DTS-HD MA track? Is there a way to just do "pass through" on DTS-HD MA tracks? The reason I ask is that TrueHD tracks output with mkvmerge work fine with Haali. DTS-HD MA tracks don't. I know you don't have time to look into that problem and feel it's a Haali issue...while I agree, I'm just wondering what the DTS output module does.

[Mosu]

Thanks for noticing. The chapter problem has been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.0.0-build20100618-272-setup.exe

[Mosu]

Is it possible this DTS output module is causing problems with the DTS-HD MA track?

No.

Is there a way to just do "pass through" on DTS-HD MA tracks?

No.

The reason I ask is that TrueHD tracks output with mkvmerge work fine with Haali. DTS-HD MA tracks don't.

Bug Haali with it.

I'm just wondering what the DTS output module does.

The same all the other output modules do: they analyze the bitstream, throw out non-spec compliant stuff, assign timecodes etc.

[SamuriHL]

That fixed the chapter issue. Thanks for the quick turnaround on that!!

[SamuriHL]

No.



No.



Bug Haali with it.



The same all the other output modules do: they analyze the bitstream, throw out non-spec compliant stuff, assign timecodes etc.

Ok. Thanks!

[bwhinnen]

Hi Guys,

I'm trying to track down an issue I have with DTS-MA in mkv files created by mkvmerge. If I use a tool such as MakeMKV to create my original (uncompressed version) of the BD movie into an MKV they play fine. If I then use some compression method to compress the video down from the original size to something a little smaller and use mkvmerge to create a new mkv from the original DTS-MA audio, subtitles and the newly compressed video I get playback issues.

The issues only seem to be when actually using HD bitstream passthrough to my AVR. Audio plays fine, but the video lags. Where as the original mkv from MakeMKV will play the file fine.

I'm using Haali to split the mkv, MS codecs to play the video side, and FFDShow x64 to play the audio and send directly to via HDMI to the AVR.

Windows 7 x64 Ultimate (all current patches)
Intel H55 chipset (GA-H55M-S2H) with current BIOS
Intel i530 CPU
All latest drivers
Shark-007 codec pack for both Win 7 and x64 components (2.53 and 2.57 respectively).
AVR is a Onkyo TX SR-706
Connection is a HDMI

This works fine with mkv's from MakeMKV which just copies the streams out, and a output from RipBot, where the audio is converted to AC-3 into mkv also works fine, but when using mkvmerge (from versions 3.2 to 4.0 on Windows) and using the original DTS-MA track from MakeMKV and the new Video track from RipBot I get the issue in playback. Opening Haali and watching the bitrate I can see Audio just steaming through, but Video is pretty much non-existent. Dolby True-HD done in the same manner works perfectly.

Thanks for any pointers, it is really frustrating me as I'd like to be able to shrink my BD collection down a bit to conserve a bit of space, specially Avatar which is 37GB for the raw mkv compared to 15GB for a shrunk one with DTS-MA.

Thanks,

Brett

[SamuriHL]

Yes, Mosu says it's a problem with Haali. I've reported it in the Haali thread. For now you can play them back in MPC-HC using the MPC internal splitter.

[rica]

Yes, Mosu says it's a problem with Haali. I've reported it in the Haali thread. For now you can play them back in MPC-HC using the MPC internal splitter.

And/or with Solveig...

[SledgeHammer_999]

Can I put two feature requests here?

1. Make mkvinfo output xml instead of the current format (add it as an command line option)
2. Make mkvinfo put an "Attachment number" to attachments like it does for tracks("Track number:").

The first one will make it easier to parse the output and grab certain values(using a good xml library).
The second one can be used in combination with the first one and later used with mkvextract. I know that I should use mkvmerge --identify, but I want to make decisions(my program) based on some additional info.
Also with xml output, I think more applications will be able to easier intergrate mkvtoolnix.
I hope it isn't much trouble. Thanks.

[Mosu]

I might implement the first option.

I won't implement the second one though because mkvmerge can already get you that information if you run "mkvmerge --identify-verbose yourfile.mkv" -- just like you said. The track/attachment numbers are the same that mkvextract expects. mkvinfo's "Track number" output is actually NOT the track number that mkvextract expects. It's just the EBML/Matroska element "TrackNumber". mkvextract and mkvmerge assign "track IDs" in a different way.

What exactly do you mean with "integrating mkvtoolnix"? If you want the applications to make decisions how to run mkvmerge/mkvextract based on the content of a Matroska file you're most likely out of luck due to the discrepency in track numbers/track IDs that I described above. Also note that mkvmerge's "--identify-verbose" outputs more information than a simple "--identify". "--identify-verbose" is what mmg uses when you add a file (actually it's "--identify-for-mmg", but the only difference to "--identify-verbose" is that the output of "--identify-for-mmg" is always in English safe for error/warning messages and the output of "--identify-verbose" is fully localized). It gets you information about the container (e.g. type), tracks (e.g. language, codec type, track type, default track flag...), attachments (name, MIME type, size), chapters and tags.

[SledgeHammer_999]

Yes, --identify-verbose and --identify-for-mmg is what I am looking for. (maybe xml those too?). You should include those into the man pages.

[Mosu]

Yes, --identify-verbose and --identify-for-mmg is what I am looking for. (maybe xml those too?).

No. They're dead easy to parse as they are. One line per item. Normal information first. Extended information between [ and ]. Extended information consists of space-separated key:value pairs. Special characters are escape: '\' maps to '\\', '"' to '\2', ' ' to '\s' and ':' to '\c'.

You should include those into the man pages.

Patches are welcome. Meaning I rather spend my time on other things.

[chipzoller]

I've got a strange problem that I don't believe is mkvtoolnix's fault; it is probably something wrong with my system but I don't know where to start. For whatever reason, when I encode mkvs at the correct resized resolution for my needs, then add them to be muxed in with audio, subs, etc., it always incorrectly detects the video stream's display width/height as 144 x 79--regardless of what the actual resolution I feed it. It could be 640 x 480 or 872 x 368--it still detects this as 144 x 79. I've un/reinstalled 4.0 a couple times and checked a few others including video drivers. I don't know what has caused this, but this never used to happen until fairly recently. What could be a possible explanation for this? How does mkvtoolnix derive the display resolution integers?

[Mosu]

mkvmerge calculates the display resolution either from the source container (e.g. if you're adding a Matroska file) or directly from the bitstream (e.g. if you're adding raw h.264 files). Raw h264 files contain the pixel width/height and the pixel aspect ratio in its headers. From those values mkvmerge calculates the display width/display height. Those values should not be 144x79 at all -- they're normally larger than the pixel resolution.

Can you give me more information about the video files you're adding to mmg/mkvmerge?

[chipzoller]

Generally, these are mkv video streams (x264) produced with MeGUI and are all SD resolutions. There is nothing special in the scripts producing them; only crop, resize, and occasional denoising. I verified that the encoded frame size set in the script is correct in the resulting file, but regardless of that resolution when dropping into mkvmerge it always sets these display values. Also, whenever I use the automated muxer in MeGUI (mkv), it also outputs a file with incorrect display settings.

[LeMoi]

mkvtoolnix actually displays the aspect ratio, not the display resolution.
If your video is 640x480, mkvtoolnix will show 4x3 instead of 640x480. Don't worry, your file will be played without any problem

[chipzoller]

Yes, I understand that, but as I mentioned, it doesn't matter what the resolution of the input file is, it will always set 144 x 79. The only way I can fix this is to put the display size the same as the frame size.

[LeMoi]

What is your initial output extension in MeGUI? MP4, AVI, MKV?

[chipzoller]

MKV always

[Mosu]

LeMoi: That's incorrect. mkvmerge will display the "display resolution". The values it display MAY come from a Matroska file whose "display width/height" values are set to "4/3" or similar small values, but if mkvmerge calculates the dimensions itself (e.g. for raw h264 files) then it will calculate the display resolution and not just the aspect ratio.

chipzoller: Look at the file MeGui created with mkvinfo's GUI and look for the "display width" and "display height" paramters of the video track. What do they contain?

[chipzoller]

In 3 cases it does show 144 x 79 but the pixel values are correct. Wonder what has happened to cause this in MeGui? The scripts are simple and encoder settings are basic crf and tune film.

[Mosu]

I've never used MeGui and have no clue as to what the problem might be. You should ask in a MeGui thread.

[Selur]

little feature request:
Would be cool if one could 'extract' a part of a mkv by defining start- and endtimecode (or start-position in seconds and end-position in seconds).
something like:
-extract TID:timecodes:00:30:00.000:00:39:09.000

I know one could abuse the '--split timecodes:A[,B[,C...]] ' option to do something similar, but if I understand it right this would always create three parts (part before the section, the section and the part behind the section), which is kind of a bummer when handling larger files and only wanting a few minutes,...

Cu Selur

Ps.: I also know I could use mencoder or ffmpeg to do this, but it would be nice to be able to do it with mkvmerge.

[LeMoi]

Afaik atm it's only possible to specify on which timecodes a new files should be created, which would result in three output files instead of one when trying to extract a stream from timecode X to timecode Y;
-> Is there already a way to call mkvmerge just create one file and extract just a portion of a stream?
if not: Would be nice if this could be added as a feature in an upcoming version.

No, it's not possible. I know it would be a nice feature to have, but I won't spend any time on that at the moment or in the near future. Patches are always welcome -- I'm not against such a feature, it just won't be me who'll implement it any time soon.
I think you just asked him some days ago, and he answered immediately ;)

[Selur]

LOL, wasn't sure if I asked and couldn't find it. ;)

[LeXXuz]

Recently updated from 3.2 to 4.0.

Have there been any changes to the vobsub muxer lately? With 4.0 my media players do not display vobsubs in 1080p anymore. Tracks get recognized, but no subpictures shown.
PC playback still works as usual.

However, same files muxed with 3.2 and everything works fine.

[Snowknight26]

Any chance of having the muxing status form start in the center of its parent instead of the center of the screen?

[Mosu]

Hey,

I've released mkvtoolnix v4.1.0. This release features a couple of bug fixes and enhancements especially in combination with WebM and full support for PGS/SUP subtitles. There's a new translation of the programs into Spanish and of the manual pages into Dutch. The Russian translation has received a huge update.

There are a couple of changes for package maintainers:

1. the new translations I've mentioned,

2. new .desktop and .xml files for menu and MIME type integration (installed into $datadir/applications and $datadir/mime/packages respectively; they're only installed if the GUIs are activated)

3. icons for the GUI applications (installed into $datadir/icons/hicolor/<size>; they're only installed if the GUIs are activated)

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-4.1.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.1.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.1.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.0.0:

------------------------------------------------------------
2010-07-01 Moritz Bunkus <moritz@bunkus.org>
* Released v4.1.0.

2010-06-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading AVC/h.264 tracks from AVI files if they're stored in NALUs inside the AVI.

2010-06-26 Moritz Bunkus <moritz@bunkus.org>
* Build system: enhancement: Improved the error reporting if certain Boost libraries are not found.

2010-06-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge will report if it finds data errors in a Matroska file (e.g. due to storage failure or bad downloads). The position is reported as well as a periodic update as long as mkvmerge re-syncs to the next Matroska element.
* mmg: enhancement: The "compression" drop down box is enabled for all track types. That way "no compression" can be forced for those tracks mkvmerge uses "header removal" compression for.

2010-06-23 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Matroska files read from/written to by the header and chapter editors will no longer be kept opened and locked. Fix for bug 498.
* mmg: bug fix: If mmg was called with "--edit-headers filename.mkv" then it crashed when the header editor was closed.

2010-06-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge will start a new cluster before a key frame of the first video track. Fix for bug 500/
* mkvmerge: enhancement: The default cluster length has been increased to five seconds (up from two seconds).

2010-06-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge will no longer report nonsensical progress reports (e.g. -17239182%) when reading Matroska files with all the flags "--no-audio --no-video --no-subtitles" enabled. Fix for bug 505.
* mmg: bug fix: Fixed a crash in the job runner when the total time was very big due to a division by zero.
* mkvmerge: enhancement: Implemented write caching resulting in faster muxes especially on Windows writing to network shares.

2010-06-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading PGS subtitles from PGS/SUP files.
* mkvmerge: bug fix: Specifying an FPS with "--default-duration" for AVC/h264 tracks in AVI files did not work. Fix for bug 492.

2010-06-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an invalid memory access possibly causing a crash in the AC3 detection code.

2010-06-14 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Changing mmg's interface language did not change the entries in the "command line options" dialog if that dialog had been opened prior to the language change.

2010-06-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge uses header removal compression by default for AC3, DTS, MP3, Dirac and MPEG-4 part 2 tracks.
* all: Added desktop files for mmg/mkvinfo, a MIME type file for .mmg files and icons to the installation procedure on Linux. Most files were contributed by Cristian Morales Vega (see AUTHORS).
* all: Added a translation of the programs into Spanish by Isra Lucas (see AUTHORS).

2010-06-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed access to uninitialized memory when reading DTS tracks from AVI and Matroska files.

2010-06-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The Matroska reader will use the MPEG audio packetizer for MP2 tracks instead of the passthrough packetizer.
* mkvmerge: bug fix: The Matroska reader did not handle compressed tracks correctly if the passthrough packetizer was used.

2010-06-08 Moritz Bunkus <moritz@bunkus.org>
* docs: Added a Dutch translation for the man pages by René Maassen (see AUTHORS).

2010-06-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The handling of Matroska files in which the 'default track flag' is not present has been fixed.
------------------------------------------------------------

Have fun.

[GuilhermeAraujo]

Interesting. I didn't know about this compression stuff.
However, I had a 3.81 GB file, then compressed every stream, and got a 3.82 GB!

And I found a bug:
I dragged a file which contain a Title (Segment information > Title, on Header Editor). Then I removed that file, leaving the list empty. Then added more files and muxed.
The title was kept. I believe it was supposed to be removed along with the first file, right?

[Mosu]

Interesting. I didn't know about this compression stuff.
However, I had a 3.81 GB file, then compressed every stream, and got a 3.82 GB!

Don't. Compressing an already compressed stream only makes it worse. There are exceptions, but they are few (e.g. you can usually gain a few bytes compressing MP3 files with RAR). Just let mkvmerge chose what it thinks is best.

I dragged a file which contain a Title (Segment information > Title, on Header Editor). Then I removed that file, leaving the list empty. Then added more files and muxed.
The title was kept. I believe it was supposed to be removed along with the first file, right?

That's not a bug but intentional. What you may want is "File -> New". Removing all input files is NOT supposed to clear everything else.

[GuilhermeAraujo]

Oh. I didn't know that file was already compressed. That makes sense now.
That's not a bug but intentional. What you may want is "File -> New". Removing all input files is NOT supposed to clear everything else.
I see.

[Adub]

It's already compressed if it uses a codec, like X264 or Xvid. Which is the case for about 99.999% of video files.

[soneca]

Today I used the version 4.1.0 and the result was a mkv with audio mute.
Again tested with versions 4.0.0 and .3.2.0 and audio came back...

mkvmerge v4.1.0 ('Boiling Point') built on Jul 1 2010 14:37:28
'D:\RECEM_CHEGADA_DEMUX\RECEM_CHEGADA_Track1.h264': Using the AVC/h.264 ES demultiplexer.
'D:\BLU_RAY\AUDIO_DD_DTS\RECEM_CHEGADA_PT.ac3': Using the AC3 demultiplexer.
'D:\RECEM_CHEGADA_DEMUX\RECEM_CHEGADA_Track1.h264' track 0: Using the MPEG-4 part 10 ES video output module.
'D:\BLU_RAY\AUDIO_DD_DTS\RECEM_CHEGADA_PT.ac3' track 0: Using the AC3 output module.
The file 'E:\VIDEOS MKV\RECEM_CHEGADA_TESTE.mkv' has been opened for writing.
'D:\RECEM_CHEGADA_DEMUX\RECEM_CHEGADA_Track1.h264' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1280/720.
Progress: 0%Progress: 1%Progress: 2%Progress: 3%Progress: 4%Progress: 5%Progress: 6%Progress: 7%Progress: 8%Progress: 9%Progress: 10%Progress: 11%Progress: 12%Progress: 13%Progress: 14%Progress: 15%Progress: 16%Progress: 17%Progress: 18%Progress: 19%Progress: 20%Progress: 21%Progress: 22%Progress: 23%Progress: 24%Progress: 25%Progress: 26%Progress: 27%Progress: 28%Progress: 29%Progress: 30%Progress: 31%Progress: 32%Progress: 33%Progress: 34%Progress: 35%Progress: 36%Progress: 37%Progress: 38%Progress: 39%Progress: 40%Progress: 41%Progress: 42%Progress: 43%Progress: 44%Progress: 45%Progress: 46%Progress: 47%Progress: 48%Progress: 49%Progress: 50%Progress: 51%Progress: 52%Progress: 53%Progress: 54%Progress: 55%Progress: 56%Progress: 57%Progress: 58%Progress: 59%Progress: 60%Progress: 61%Progress: 62%Progress: 63%Progress: 64%Progress: 65%Progress: 66%Progress: 67%Progress: 68%Progress: 69%Progress: 70%Progress: 71%Progress: 72%Progress: 73%Progress: 74%Progress: 75%Progress: 76%Progress: 77%Progress: 78%Progress: 79%Progress: 80%Progress: 81%Progress: 82%Progress: 83%Progress: 84%Progress: 85%Progress: 86%Progress: 87%Progress: 88%Progress: 89%Progress: 90%Progress: 91%Progress: 92%Progress: 93%Progress: 94%Progress: 95%Progress: 96%Progress: 97%Progress: 98%Progress: 99%Progress: 100%Progress: 100%
The cue entries (the index) are being written...
Muxing took 67 seconds.

[LeXXuz]

Recently updated from 3.2 to 4.0.

Have there been any changes to the vobsub muxer lately? With 4.0 my media players do not display vobsubs in 1080p anymore. Tracks get recognized, but no subpictures shown.
PC playback still works as usual.

However, same files muxed with 3.2 and everything works fine.

Same Problem with 4.1 now. Any ideas?

[SamuriHL]

I just remuxed some stuff with 4.1 and I'm not seeing an audio mute problem. Everything seems fine for me. I'm simply adding PGS subs from a file back into my MKV's so it's taking an existing one, adding PGS subs to it, and writing it back out. No problems.

[Mosu]

Today I used the version 4.1.0 and the result was a mkv with audio mute.
Again tested with versions 4.0.0 and .3.2.0 and audio came back...

Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression for an explanation and file a bug report with the vendor(s) of the software/hardware you use for playback (and the demuxer if its separate from the player).

[soneca]

Mosu,

You are right, it was a failure KMPlayer but already been resolved by changing the settings.:)


Thanks!

[steelista]

Hi,

I've installed an Ubuntu package from http://www.bunkus.org/ubuntu/lucid/binary/i386/ and I can't change the GUI's language. It's always English no matter what i select.

[Mosu]

I've installed an Ubuntu package from http://www.bunkus.org/ubuntu/lucid/binary/i386/ and I can't change the GUI's language. It's always English no matter what i select.

Probably because you don't have the locales compiled for the language you're trying to use. Please paste/tell me:

1. the output of the "locale" command,

2. which language you're trying to use,

3. the output of "cat /var/lib/locales/supported.d/*"

[hubblec4]

hi mosu

thanks for this great upgrade

""...
2010-06-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading PGS subtitles from PGS/SUP files.
..."

this new feature helps me to keep the original bluray.sup's.

I demux a bluray ever with eac3to and i get the sup files with the name of the language like this:
"00019 - 15 - Subtitle (PGS), German, 1685 captions.sup"

when i insert the file to the gui i must select the language manually. It would be nice that the language set automaticly.

hubble

[GuilhermeAraujo]

Reading info from file name? Yes, would be very interesting. Language and delay.

[LeMoi]

AFAIK delay is already read from filename (at least for audio files), see options.

[Mosu]

Hey,

I've released mkvtoolnix v4.1.1 just two days after v4.1.0 due to a serious bug introduced in v4.1.0. If causes mkvmerge to crash with default option in various circumstances, especially when handling MPEG-4 part 2 video tracks.

There are no changes for package maintainers in this 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-4.1.1.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.1.1-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.1.1.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.1.0:

------------------------------------------------------------
2010-07-03 Moritz Bunkus <moritz@bunkus.org>
* Released v4.1.1.
* mkvmerge: bug fix: Fixed invalid memory access in the header removal compressor. Fix for bug 508.
* mmg: bug fix: mmg will no longer add .mmg files opened by the job runner to the file menu's list of recently opened files. Fix for bug 509.
------------------------------------------------------------

Have fun.

[GuilhermeAraujo]

AFAIK delay is already read from filename (at least for audio files), see options.
Cool. I'm gonna make some tests :P

[johnsonlam]

I got this message frequently, and MMG stopped, how to solve the problem?

"Compression failed: Header removal compression not possible because the buffer contained 1 bytes which is less than the size of the headers that should be removed, 3."

Thanks.

[Mosu]

I got this message frequently, and MMG stopped, how to solve the problem?

"Compression failed: Header removal compression not possible because the buffer contained 1 bytes which is less than the size of the headers that should be removed, 3."

Force compression to 'none' for the problematic track. Also I'd like to know how what files and tracks you were muxing. If possible could you upload them to my FTP server? This should not happen, and I'd like to know the reason for it and to fix it.

The lenght, 3, lets me guess that it's a MPEG-4 part 2 video track that's causing the problem.

[woah!]

i dont know why/how but since 4.1.0 or 4.1.1 any mkv i make doesnt play sound on my wd hd live media player. remuxing exact same mkv made with 4.1.0,but using 4.0.0 and plays correctly on the media player?

just a heads up if people ever have an issue like this...

[sneaker_ger]

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

[woah!]

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

ok so a bug report to wd is needed thx :)

i will use 4.0.0 until enough people report to them, for them to fix it maybe...

[Mosu]

You can also use 4.1.1 but you have to disable extra compression for the audio tracks if you intend to play the file with such a player.

[soneca]

I also have the WDTV Live and confirm this "problem".
I doubt that this is corrected quickly by WD.:(

[cge]

Hi,
This is probably a very basic things bug I'd like to clarify it in my mind.
I thought that the default and forced flags are booleen values but there are 3 choices in the drop/down box in the mkvmerge dialog (YES|NO|DEFAULT) ?
Note: from the header editor dialog it's only possible to set them to Yes|No
Regards
Christophe

[Mosu]

mmg has a lot of booleans that contain 'yes', 'no' and either 'default' or an empty value. 'yes' means 'definitely set this value to "yes"'. 'no' means 'definitely set this value to "no"'. 'default' or an empty value means 'please mkvmerge, decide yourself'.

For the 'forced display' flag this means that mkvmerge will keep the value from the source container -- e.g. if you're remuxing from a Matroska file to another Matroska file.

For the 'default track' flag this means that mkvmerge will decide on the information from the source containers and the values of the 'default track' flags of all the other tracks whether or not to set this value.

In all cases mkvmerge will either set the value to 'yes' or to 'no'. That's why the header editor also only lets you chose between 'yes' and 'no'.

[sialivi]

Any plans to support .flv input files?

[Mosu]

No support for Flash video files is planned.

[cge]

Hi,
I'd like to know if there is an easy way to change the track order without remuxing ?
I tried to change the track ID using the header editor with no luck !
Thanks
Christophe

[Mosu]

Not really, no. There's nothing in the specs telling a player how to sort the tracks, so most players simply use the order in which they appear in the track headers. Neither mmg's editor nor mkvpropedit allow the track headers to be re-ordered, and such a feature is not planned at the moment.

[^*^]

I have recently bought new Samsung LED TV which is unable to play MKV files with new audio compression. I have to specify "none" each time I add an audio stream. This is easy, but also easy to forget about it. Muxing of 30 GB file to external HDD takes about 40 minutes. And sometimes this time is wasted due to wrong compression setting. It is very unlikely that Samsung will correct its firmwares, and therefore I would be very grateful that You add in program options a checkbox, which will make "audio compression - none" as default.

[Atak_Snajpera]

@Mosu
I think that you should disable audio compression by default. It only causes more confusion. You've added that feature too late ;)

[Mosu]

and therefore I would be very grateful that You add in program options a checkbox, which will make "audio compression - none" as default.

Sorry, but I won't.

[Mosu]

@Mosu
I think that you should disable audio compression by default. It only causes more confusion. You've added that feature too late ;)

Sorry, but I won't. Users have several options (some better suited than others for different kinds of users): keep using an earlier version; force compression off; use the command line which makes forcing easier; get the player vendors to support this feature that's been part of the specifications for eight years now.

[Guest]

Sorry, but I won't. Why is it so important for you that the default be enabled? Don't you care at all about the grief this causes users? Isn't it a trivial matter to enable the option if you want it? Doesn't backward compatibility mean anything to you?

Please don't get mad at me. I'm just inquiring as a concerned user.

[Mosu]

I'm concerned about backwards compatibility, but at the specs level. The specs haven't changed in this regard, this feature just has never seen very wide use until now. Haali's muxer has always supported header compression (muxer, not only the demuxer!), but it hasn't been enabled by default.

What I'm trying to do at this very moment is to get companies to update their software to support a wider range of the specs. Now is a good time for such a move due to an already existing major change in mkvtoolnix 4.0.0 (default values aren't written anymore) and due to the changes necessary for WebM playback. That's why I'm pushing for it now.

The Matroska project has always been about pushing into unchartered territory. If we were satisfied with the status quo then we'd still all be using AVIs or MP4 and neither OGM nor Matroska would have seen the light of day. Yes, this process is often painful, but you don't get (technical) advancement for free.

[Guest]

What I'm trying to do at this very moment is to get companies to update their software to support a wider range of the specs. Now is a good time for such a move due to an already existing major change in mkvtoolnix 4.0.0 (default values aren't written anymore) and due to the changes necessary for WebM playback. That's why I'm pushing for it now.
Seems to me that if you were serious about that you would have removed the option to disable it. :)

[Mosu]

I'm not about forcing everyone to push my agenda for them. I like to give the users a choice. The choices themselves are often not what the user would prefer though (e.g. use older versions of the software).

There's a technical reason why I don't let users chose in the 'default values' case: the libraries mkvtoolnix uses makes it very hard to not write default values and still create valid WebM files. I don't have that much time to fix this properly.

The 'compression' case is different. It's technically trivial to let the user chose in this case. Even the modifications in mmg were trivial because the 'compression' selection box was already present, it just couldn't be used for non-subtitle tracks.

[nurbs]

I second the request for an option in mmg to turn off audio compression by default. I compared a file (1*AVC/3*AAC/1*SUB/IDX) muxed with 3.4.0 and 4.1.1 and the latter is 0,002% smaller (45kB out of 2.12 GB) and didn't work on any of my hardware. There is zero gain and lots of trouble with that feature.

[Mosu]

There's no header removal compression with AVC and AAC tracks. VobSub tracks have always been compressed with zlib.

And no, I won't add such an option. Sorry.

[Guest]

Source is available. We can make our own branch. :)

[Mosu]

Sure, you can do that. But please don't call it mkvtoolnix then and change the program names (e.g. in the "about" dialogs and the help texts) to make it obvious that those are modified versions.

[nurbs]

There's no header removal compression with AVC and AAC tracks.
Which raises the question why the file doesn't work. I'll have to investigate.

[Mosu]

Here's a list of track types and their default compression methods:

VobSub, PGS/SUP, text subtitles (SRT/ASS/SSA), VobButtons: ZLIB

AC3, DTS, MP3, MPEG-4 part 2 (aka DivX aka Xvid), Dirac: header removal

Everything else: no additional compression

[Guest]

Sure, you can do that. But please don't call it mkvtoolnix then and change the program names (e.g. in the "about" dialogs and the help texts) to make it obvious that those are modified versions. Of course. I'm talking for personal use only. :)

[Mosu]

Ah ok. No need to change anything for personal use, just don't distribute it under the original name. Thanks.

[johnsonlam]

Force compression to 'none' for the problematic track. Also I'd like to know how what files and tracks you were muxing. If possible could you upload them to my FTP server? This should not happen, and I'd like to know the reason for it and to fix it.

The lenght, 3, lets me guess that it's a MPEG-4 part 2 video track that's causing the problem.

Thanks, you're right about the video track have problem, but it's a "DX50" (H263) video.

I've uploaded the video in 7z format (4 parts) with subtitle, I just want to add subtitle to the file, and I do as you say force "none" works!

I think it's a bit annoying to display this message without suggestion, people usually not able to determine what kind of files can be compressed, and for this kind of file MMG failed to decide.

I've tested subtitle can be compressed but sound and video already compressed (anyone will use WAV or uncompressed AIFF for sound track?), they should be automatically set to "none".

Thanks for your MKVTOOLNIX, it's the "savior" of MKV, also thanks for your work!

[SeeMoreDigital]

Sorry, but I won't.I seem to remember you having similar reservations about not letting MKVmerge automatically remove the aspect ratio signalling embedded within MPEG-4 video streams... But eventually you changed your mind ;)

[Mosu]

I seem to remember you having similar reservations about not letting MKVmerge automatically remove the aspect ratio signalling embedded within MPEG-4 video streams... But eventually you changed your mind ;)

True. But the case of aspect-ratio information is not as clear-cut as this one. The Matroska specifications don't say anything about where aspect ratio information must be stored. In fact it doesn't say anything about aspect-ratio information at all -- it only contains two elements that tell the player the preferred size of the video when it is played back.

Header removal compression is defined in the specs, as are default values.

[Mosu]

Thanks, you're right about the video track have problem, but it's a "DX50" (H263) video.

I've uploaded the video in 7z format (4 parts) with subtitle, I just want to add subtitle to the file, and I do as you say force "none" works!

Thanks, I'll take a look. DX50 is also MPEG-4 part 2 (DX50 is, if I'm not mistaken, the FourCC of DivX v5.0 or something like that). My guess is that frames of length 1 simply mean 'repeat previous frame'. So I have two options: disable header removal compression or drop those frames and calculate timecodes/duration accordingly. The latter is already done when muxing from AVI into Matroska, so it wouldn't be anything new.

I think it's a bit annoying to display this message without suggestion, people usually not able to determine what kind of files can be compressed, and for this kind of file MMG failed to decide.

I agree. I want to have a solution that succeeds in 99.99% of all cases ( = muxing succeeds in 99.99% of all cases; playback is a totally different matter). So if I cannot find a proper solution for such files as yours I'll disable header removal for MPEG-4 part 2 tracks by default.

[LeXXuz]

Here's a list of track types and their default compression methods:

VobSub, PGS/SUP, text subtitles (SRT/ASS/SSA), VobButtons: ZLIB


I dont understand very much of this topic, but I guess this is the reason why my players don't display any vobsubs with the 4.x builds? Am I right?

[^*^]

Then let's change these specifications! Your application has become de facto the standard for creation of Matroska files. Millions (or probably billions) of devices compatible with previous versions of mkvtoolnix are made. Now they are incompatible. OK, we still can make files suitable for our old devices. But other 95% (or even more) of consumers haven't knowledge to do this. They will attempt to play new films without success and then they will be starting to think about to purchase of new equipment. The old sooner or later will go to trash. Please, think "green", unless some corporations have paid You to make these changes and they could sell more "new and compatible" devices. Frequent change of standards are their bread.

[Mosu]

I dont understand very much of this topic, but I guess this is the reason why my players don't display any vobsubs with the 4.x builds? Am I right?

You may be right, but I doubt it. VobSub compression with ZLIB has been used since the day VobSub support was introduced itself. Meaning since Sep 11 2003:

commit 3fcd47dc6a9e5a9a22a0ad985f2fab2f761f5e86
Author: Moritz Bunkus <moritz@bunkus.org>
Date: Thu Sep 11 19:43:32 2003 +0000

Implemented the VobSub reader and packetizer. Implemented three compression algos which are selectable via the (undocumented) command line option --compression.


What's new in v4.1.0 (not in 4.0.0!) is that certain audio and video tracks use header removal compression by default.

What's new in v4.0.0 is that default values are not written anymore. This does concern ZLIB compression, and this is what most likely breaks your player: it does not support default values properly. Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values for an explanation.

Note that blaming mkvmerge is not really solving your problem. With the rise of WebM there are tons of new muxers popping up left and right, and some of them don't write default values either. So the only sensible long-term solution is to fix playback devices to support the specs properly.

[Mosu]

Then let's change these specifications! Your application has become de facto the standard for creation of Matroska files.

Not possible. Even if mkvtoolnix is the de facto standard in a limited number of situations it is by far not the only program using the existing specs. Changing the specs in backwards incompatible ways now that there are tons of muxers and demuxers already out there is out of the question.

Please, think "green", unless some corporations have paid You to make these changes and they could sell more "new and compatible" devices.

Since I've started working on mkvtoolnix in 2002 I've received all of 200 EUR in donations. No corporation has ever contacted me and asked me to change mkvtoolnix in any way.

Also it's a lie if a corp tells you that they cannot fix bugs in older hardware. This is not about implementing a whole new video codec for which the hardware might not be capable enough. These are minor software updates which would only require a new firmware, certainly not a new hardware device. I know corps like to sell new devices instead of support old ones. But changing their corporate mind is the responsibility of each and every consumer by making the choice which devices to buy and which not to buy.

So please don't start a discussion about corporate ethics, the impact of my decisions on the environment. This is a mkvtoolnix support thread, not a political discussion board.

[LeXXuz]

You may be right, but I doubt it. VobSub compression with ZLIB has been used since the day VobSub support was introduced itself. Meaning since Sep 11 2003:

Since it works with 3.2, you're right ofcourse!



What's new in v4.1.0 (not in 4.0.0!) is that certain audio and video tracks use header removal compression by default.

What's new in v4.0.0 is that default values are not written anymore. This does concern ZLIB compression, and this is what most likely breaks your player: it does not support default values properly. Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values for an explanation.

Note that blaming mkvmerge is not really solving your problem. With the rise of WebM there are tons of new muxers popping up left and right, and some of them don't write default values either. So the only sensible long-term solution is to fix playback devices to support the specs properly.

I get your point, thanks for your answer. I'm not blaming mkvmerge for anything. Just trying to figure out what I have to do temporarily to get subtitles to work. Now that I know what changed I can contact the vendor and ask them to make changes to their FW. As usual they wont do anything until customers start to complain, so this might take some time...

[asc28]

I recently remuxed H.264/flac to mkv with mkvmerge 4.1.0, no errors, but it came out damaged (file would skip in the middle). I did it again, same version, same inputs, same settings and it came out fine. Checksums of the files were different and there is an "NAL too big error" when extracting the damaged one. Filesizes are identical.

command-line: mkvmerge -o out.mkv --default-duration 0:24000/1001fps in.h264 in.flac

So, I did a surface scan of all the drives involved (including my pagefile drive) and did 5 passes of Memtest86+ with no errors found. Could this have something to do with that particular version of mkvmerge or should I be worried that something else is wrong with my system?

[edit] Just realized checksums will be different anyway because of encoding date metadata, but everything else applies

[stax76]

Such compatibility issues won't happen with a HTPC. :)

[Mosu]

True about the checksums. Hard to tell in general. The AVC code has received a couple of changes in the last few releases. But I haven't seen anything random happening for other users.

It could also have been a one-time hardware error, e.g. system getting very hot; intermittent memory fault. Such things happen, even if subsequent tests don't show anything wrong with the hardware.

What I'm trying to say is that there's no known issue with raw h264 files in v4.1.1.

[LeXXuz]

You were right Mosu. Setting vobsub compression manually in mmg and vobsubs work again on my players. Thanks for your help, would have never figured that out by myself. :thanks:

[tiny55]

I'm having a problem with the merge function(MMG) of MKVtoolNix.
The same problem as mentioned by Foofaraw.. (reference posts 1476 to 1480 page74)

Using MKVMERGE, I can take a BluRay rip made with MakeMKV with just a Video and audio track that works fine on my computer software players and Seagate Fat+ or WD media players, run it thru the MKVMerge program without changing anything and the resulting file now takes 10-20 seconds to load in all my players. The origional rip would load in 1-2 seconds.

Except for the Fat+ all the other players wait for the file to load and the movie will play without incident.The computer players take a little longer to load but not that much longer. The Fat+ however, will not wait. It just locks since it can't load the file immediately. However, with H264, I usually do not not have that problem. MMg asks for the frame rate and remuxes perfectly and the file will load in 1 to 2 seconds. Also with Mpeg and VC1 files less than an hour long they will usually load within the time frame allowed by the Seagate player and they will load and play as well.

Further, I can take the movie that MKVMERGE generated that takes too long to load run it thru tsMuxer, convert it to a Bluray folder without adding or removing anything and run it once again thru Makemkv. The resulting movie once again plays as before and loads in 1-2 seconds.

I've gone as far asdemuxing a VC1 file and adding only the video and chapters back into it. No audio or anything else and it still takes too long to load.

I've used the header editor as well as the verify selection and nothing was out of place as far as I could tell.

So after reading the above mentioned posts(1476-1480) and the explanation as why this happens, I was wondering if I could just get some advice on how to shorten the re-load time.


Thank you
Tony

[MeridiusUK]

a hugh bug in mkvtoolnix 4.1.1 please read this post and link

http://forum.doom9.org/showthread.php?p=1416294#post1416294

I rip a dvd to mkv using makemkv then i will use mkvtoolnix 4.1.1 to disable the subs so that they dont auto play well on the pc side anyway as i hate to keep turning them off then i remux the file all works fine on the pc but when i play it on the ps3 the sound just plays like a old spectrum loader game in the old days.

now if i do the same rip the dvd to kv with makemkv but do not use mkvtoolnix 4.1.1 it works so it looks like mkvtoolnix is damaging the file in some way.

I have not tried to remux the file without changing anything so i am going to do this first to see if it stil damages the file if it does not it must be when i change the subs from default to no but i will have to try this out.

its just a shame makemkv does not give you an option to stop the subs comming on stright away

at least i now know mkvtoolnix sems to be the problem i am going to try verion 4.0.0 to to see what happens

but the mkv file that i made with makemkv is now working as long as i dont use mkvtoolnix to disable the subs but i will do more testing

oh bugger i dont have 4.0.0 can anyone tell me where to get it to test it out as version 4.1.1 is totaly unusable for me now i know its for the ps3 but to be honest it should not be damaging the file in this way it might even cause problems for pc in the future or now.

hope this helps as i love this tool

[Mosu]

a hugh bug in mkvtoolnix 4.1.1 please read this post and link

http://forum.doom9.org/showthread.php?p=1416294#post1416294

I rip a dvd to mkv using makemkv then i will use mkvtoolnix 4.1.1 to disable the subs so that they dont auto play well on the pc side anyway as i hate to keep turning them off then i remux the file all works fine on the pc but when i play it on the ps3 the sound just plays like a old spectrum loader game in the old days.

Not a bug in mkvtoolnix but in the playback software. Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression for an explanation.

oh bugger i dont have 4.0.0 can anyone tell me where to get it

All versions ever released are available from http://www.bunkus.org/videotools/mkvtoolnix/win32/

[MeridiusUK]

Thanks for that so if I select none on the audio track it will
not remove the headers from the track and should make it more compatable with the ps3 so I don't need to go back to version 4.0.0 but in doing so will make the final mkv slighty bigger than the normal file. Is this correct ?

Also the files that I have already done can I reload them back in and select none on the audio track and will it fix it or will I need to rerio the DVDs again ? Cheers

so this feature is to make the mkv files smaller ?

Is there anything ealse I should watch out for just in case

Thanks for the help

[LeMoi]

The difference won't be huge, just a few bytes...

[Mosu]

Thanks for that so if I select none on the audio track it will
not remove the headers from the track and should make it more compatable with the ps3 so I don't need to go back to version 4.0.0 but in doing so will make the final mkv slighty bigger than the normal file. Is this correct ?

Yes.

Also the files that I have already done can I reload them back in and select none on the audio track and will it fix it

Definitely, yes. This type of "compression" is lossless. Technically it works like this: Each frame of a track starts with the very same bytes. Header removal compression takes these bytes and stores them once in the track headers and removes them from the start of each frame. A player (or a demuxer like mkvmerge's input module) must add the bytes from the track header to every frame in the file upon playback. This is a trivial process; a couple of lines of code at most.

[MeridiusUK]

Thanks for that will try it out later, so if its only saves a few bytes why use it ? If when not using it makes it a littile more compatable. I know the files worked on a pc with no problems butthe ps3 must. Be a littile more fussy.

I am happy that I don't need to re rip all my moves as u say I can just load them back into mkvtoolnix and change the audio to none and it will add all the headers back into each track to make it more comptable.

Is it normal for mkvtoolnix to have the settin all set to blank ?

Could u also let me know if there is anything ealse I should watch out for when using mkvtoolnix 4.1.1 as I upgraded from 4.0.0 and don't know if there anything ealse that has changed.

It's that I use makemkv for my DVDs but for some reason when u have select subtitles it will auto default them to on when playback wise it would not do that but I use mkvtoolnix to change it from yes to no to stop them from comming on automaticly is this the right option to select no to turn them off or default ?

[MeridiusUK]

hi there just got back in, what do i select none for just the audio track ? as there is an option for the video track and vobsub track do i just leave these blank ?

so is it

audio = none
rest of the settings leave alone or blank

or

audio = none
video = none

rest of the settings leave alone

or

audio = none
video = none
subtitles = none

?

not to sure what to use

version 4.0.0 did the file in 92sec

version 4.1.1 did it in
audio = none
video = none
93sec

version 4.1.1 did it in
audio = none
video = blank
104sec

so is it right that having the video and audio set to none as only doing the audio takes 10sec longer to do meaning it must be doing somthing extra over 4.0.0.

cheers

[MeridiusUK]

anyone ?

[SeeMoreDigital]

anyone ?This is a community forum, not a private "help-desk". Indeed, please refer to the forum rules (http://forum.doom9.org/forum-rules.htm). Particularly rule: 12

[steelista]

Probably because you don't have the locales compiled for the language you're trying to use.

Sorry for a late answer.

Missing locales was the problem. Thank you for the help.

[Mosu]

Thanks, you're right about the video track have problem, but it's a "DX50" (H263) video.

The next release will have header removal compression turned off for MPEG-4 part 2 video tracks again. It simply is incompatible with packed bitstreams which are the (vast?) majority of all MPEG-4 part 2 tracks out there.

[SeeMoreDigital]

The next release will have header removal compression turned off for MPEG-4 part 2 video tracks again. It simply is incompatible with packed bitstreams which are the (vast?) majority of all MPEG-4 part 2 tracks out there.Have you considered "removing" the packed bit-stream from the MPEG-4 ASP video stream during muxing to the .MKV container?

Given the processing power of todays software and hardware players, the use of packed bit-stream is completely un-necessary now. It's just another awful hack to place b-frames within the .AVI container. Indeed, it's a hack that is not required for use with the .MP4 container and therefore should not be required for use with the .MKV container either!


Cheers

[Mosu]

Yes, mkvmerge contains very complicated code for it. It can be activated with "--engage native_mpeg4". However, it still contains a couple of bugs, and I've already spent way too much time on it compared to an actual gain.

[SeeMoreDigital]

Yes, mkvmerge contains very complicated code for it. It can be activated with "--engage native_mpeg4". However, it still contains a couple of bugs, and I've already spent way too much time on it compared to an actual gain.Is there no way of implementing/modifying Moitah's MPEG4 Modifier code?

[Mosu]

I've already got all the code in place, but the problems are the remaining bugs. You can read about it here: https://www.bunkus.org/bugzilla/show_bug.cgi?id=289

Also why bother? It's not like MPEG-4 part 2 is the future of video encoding...

[zn]

Error: The demultiplexer for the file '1024.vc1' failed to initialize
vc1_es_reader: Could not open the source file.

muxing more then 1024 files didn't work using mkvmerge -o out.mkv a.vc1 +b.vc1 +c.vc1

tested on 2.7

[Mosu]

You probably hit a limit imposed by the operating system. mkvmerge does not have any artificial limit on the number of open files. Technically mkvmerge could close the files after reading the headers and re-open them when its their turn, but I will definitely not spend any time on something like that.

BTW: v2.7 is ancient. You should upgrade. Though that won't solve this particular problem.

[SamuriHL]

Holy snikes! 1024 files?!?!?! :D

[zn]

You probably hit a limit imposed by the operating system.

i can confirm this! I have similar error in both 64 bit linux ext3 and 32 bit xp sp3 ntfs
in linux it was possible to avoid this problem by increasing open files limit to (ulimit -n 2048)

Holy snikes! 1024 files?!?!?! :D
in total it was 1231 files :D

[SamuriHL]

in total it was 1231 files :D

Good Lord that's a lot of files to merge! :)

[SeeMoreDigital]

I've already got all the code in place, but the problems are the remaining bugs. You can read about it here: https://www.bunkus.org/bugzilla/show_bug.cgi?id=289

Also why bother? It's not like MPEG-4 part 2 is the future of video encoding...In that case...

How about issuing a "pop up notice" reminding people about the possible conflicts regarding muxing MPEG-4 ASP video streams... In much the same way you provide a notice to remind people to set the video streams FPS speed?

[Mosu]

The current way of muxing MPEG-4 ASP ("VfW compatibility mode") works nicely for playback on all devices, so such a warning would be bogus.

The FPS issue is completely different and definitely warrants a warning. The difference is that in the ASP case people don't have to do anything and it "just works". In the AVC case not specifying the FPS will usually result in wrong frame rate and therefore it doesn't "just work".

[Ramon4eg]

How can I fix the english subtitle trouble? In MPC-Homecinema they are named "Unknown", when I choose english language. Other languages are normal. Before mkvtoolnix 4.0.0 they're was "English".

[SamuriHL]

Try giving them a title. I always put "English" or "English - Forced"as a description in the title field.

[Snowknight26]

MPC-HC bug, take it up with the devs.

[Ramon4eg]

In older versions all be allright.

[sneaker_ger]

This has been discussed here and in the mpc-hc section already, it is a bug in mpc-hc's matroska splitter which doesn't correctly lable subtitle tracks without the "language" tag as "English" as defined by the matroska spec.
Solutions:
1.) Use Haali's splitter instead of the internal or
2.) switch to an older mkvmerge version or
3.) manually add the language tag with the header editor or
4.) get the mpc-hc devs to fix the problem

[Midzuki]

Solutions:

1.) Use Haali's splitter instead of the internal or
2.) switch to an older mkvmerge version or
3.) manually add the language tag with the header editor or
4.) get the mpc-hc devs to fix the problem

Only #4 would deserve to be called "solution". :)

[foxyshadis]

I created a patch to fix the problem, but it hasn't been applied yet. MPC Ticket 536 (https://sourceforge.net/apps/trac/mpc-hc/ticket/536)

[Ramon4eg]

OK, I'll wait app.

[Thunderbolt8]

is the option to turn off that header compression thing for ac3 tracks that one under 'extra options' -> compression = none?

[SamuriHL]

Yup, that's the setting.

[LeMoi]

Is there a way to add a setting in the options dialog "set audio/video compression to default/none/zlib" for all tracks, if not specified?

[sneaker_ger]

.....
I second the request for an option in mmg to turn off audio compression by default.
And no, I won't add such an option. Sorry.

[LeMoi]

No, it's not about turning off by default, it's just about letting the choice to the user, not the same thing

[Mosu]

You do have the choice. I'm not preventing you to turn it off in mmg. You can use the command line and use the wildcard track ID -1 which matches all tracks in a given file. You can use older releases.

[sneaker_ger]

No, it's not about turning off by default, it's just about letting the choice to the user, not the same thing

Nurbs asked for "an option in mmg to turn off audio compression by default". Which is pretty much what you were asking for.

[LeMoi]

It's like the 'und' option for language tracks, in first releases, every track added had its language set to English, and then Mosu decided to set the default language as Undetermined -even if Matroska specs say that default language is English, which may cause problems now (with latest releases) for some old splitters and players unlike Haali's one.
Again, I'm just saying that it would be nice to be able to set this option once for all in the GUI, not having to set it every time for every audio/video track. That means for example that if compression field is empty, it's set to what would be set in the options, which may be "default" (=yes), "none" and "zlib". It's just a matter of saving time, not changing or antagonizing Matroska specs.

And please, stop saying "use older version", you know that new versions fix other bugs or add new features, we (I) wouldn't change mkvtoolnix version just because of that.

I'll just add that I'm not concerned by the problem, I play all my MKV files on my PC, using MPC-HC and Haali Splitter, I don't have any hardware player or other buggy stuff. It's just about having the choice to turn on/off this option once for all ^^

[Mosu]

It's like the 'und' option for language tracks, in first releases, every track added had its language set to English, and then Mosu decided to set the default language as Undetermined -even if Matroska specs say that default language is English, which may cause problems now (with latest releases) for some old splitters and players unlike Haali's one.

You're confusing issues here. There are two different issues: 1. the language that mkvmerge assumes if the user hasn't specified anything specific and if the source container doesn't provide that information either (think of SRT subtitles) and 2. the value that a reader must use if the element is not present in the file. These are two completely different issues, and only the second one actually concerns players/readers.

What I changed was the 1. issue. In early releases mkvmerge assumed "English", and people (rightfully) complained that the world does not revolve around English, and I switched mkvmerge to use "undefined" instead. This has nothing (!) to do with specs.

The 2. issue has only been changed with v4.0.0, and that's only a matter of properly following the specs.

And please, stop saying "use older version", you know that new versions fix other bugs or add new features, we (I) wouldn't change mkvtoolnix version just because of that.

I'm giving you options. These options may not be what you want, but that's another issue. This is open source software. You're not forced to use the "latest and greatest". You could create such a build yourself, or lacking the programming skills you (or anyone else wishing for specific features that I won't implement) could ask other developers to do it for you.

Anyway. I'm not discussing this any further. I will not implement such an option.

[LeMoi]

OK, never mind. It's just a shame to implement an option nobody asked for and only few people use, while lot of users complain about it. And you know that even if your program is open source, you're the only one to compile public versions of it (I never saw other builds than yours, but maybe I didn't search for it...).
But you're right, if you really don't want to re-implement this feature, 'end of discussion' and sorry for bothering :)

[Mosu]

mkvtoolnix is not (only) about user requests, it's also (or even more so) about pushing Matroska features. I'm perfectly aware that "Matroska features" and "user requests" don't always overlap very well.

[b66pak]

@Mosu one request: can you add the audio delay in a .mkv (if any) to the report obtained with:

mkvmerge -i anyfile.mkv
_

[jasonwc]

I noticed that when MKVMerge is used to mux a FLAC track into an MKV, it strips out the bitrate metadata, and thus cannot show the bitrate or size of the FLAC track within a MKV container. A FLAC track produced with eac3to, for example, contains bitrate information, but after being muxed into an MKV container, merely displays as "Variable" within Mediainfo.

In addition, no percentage information is given for VC-1 or AVC streams from most Blu-Ray sources. I assume this is because no metadata is included within the m2ts, however, MKVMerge should be able to figure out the bitrate of the video stream by calculating the filesize - overhead.

One more question - how much space is saved by the use of header compression for AC3 and DTS streams, on average?

[LeMoi]

Calculating video bitrate is not very reliable. You should use MPEG File Bitrate Viewer.

[Mosu]

I noticed that when MKVMerge is used to mux a FLAC track into an MKV, it strips out the bitrate metadata

That's incorrect. mkvmerge keeps all FLAC blocks including FLAC's metadata blocks.

but after being muxed into an MKV container, merely displays as "Variable" within Mediainfo.

That's due to a combination of the Matroska container not having a bitrate header field and Mediainfo not looking into the FLAC stream inside the Matroska container.

[Mosu]

@Mosu one request: can you add the audio delay in a .mkv (if any) to the report obtained with:

mkvmerge -i anyfile.mkv
_

No, sorry. mkvmerge does not scan the input files further than the header fields for the output of "-i", and it would have to in order to be able to display that piece of information. You can calculate that value from the output of mkvinfo.

[jasonwc]

Mosu,

I think I have discovered an odd bug, and I can't tell if the problem is with MKVMerge or Haali's Matroska splitter. I have been able to reproduce the issue with MKVMerge 4.0, 4.1.0, and 4.1.1.

Issue: When an MKV contains an AVC and FLAC 1.0 track, it always stalls when played back when using the Haali Matroska splitter. It simply sits at the first frame and shows 1 frame drawn with a framerate of 0.0. The same MKV will playback using MPC-HC's internal matroska splitter.

To reproduce: Create an MKV with a AVC and FLAC 1.0 track.

Note: If I remove the FLAC 1.0 track, the video plays fine. I also haven't had any issues with FLAC 5.1 or 7.1 tracks. I think it's an issue with mono FLAC audio. I have also tested with and without the AC3 commentary tracks and PGS subs. The only factor that matters is the inclusion of a FLAC 1.0 track.

I have provided two samples which exhibit the issue, one from Everlasting Moments (2008) and another from Close-Up (1990). Both are small samples from a Blu-Ray remux. The original BD contained LPCM 1.0 tracks which were dithered to 16 bit, and encoded in FLAC.

The problem doesn't seem to affect all AVC + FLAC 1.0 MKVs. "M" (1931) fits this pattern yet doesn't have the problem. I used identical eac3to settings to demux, and verified that it still works when I create the MKV with MKVMerge 4.1.1. What's really odd is that all three films were produced by Criterion.

I have therefore provided a sample from M, which does work in Haali. Perhaps this will allow you to figure out why the others don't work:

Everlasting Moments Sample (Doesn't Work): http://www.mediafire.com/?htglad3iozbdt2d

Close-Up Sample (Doesn't Work): http://www.mediafire.com/?goulfu8ylc6ycds

'M' (1931) Sample (Does Work): http://www.mediafire.com/?1b2owc9f19mxsz5

Tested with MPC-HC SVN rev. 2099, Haali Splitter 05/20/2010, Mediaportal RC6 (uses Haali). Same behavior in each.

EDIT: Just realized that Everlasting Moments actually has a 5.1 track, yet it has the same behavior. I'm not sure what's going on as I have remuxed dozens of BDs and these are the only problematic ones.

FIXED: The problem was with the ffdshow FLAC decoder. Works with MPC-HC's internal FLAC decoder as well as madFLAC. Sorry for the inconvenience.

[Rodger]

Hy guys.

I don´t know what it is...but since updating to the current version the created mkv-files somehow are screwed up.

I found out because my Samsung TV suddenly didn´t play any audio in the newly created mkvs. Just to let you know....the video stream is played correctly. Older ones do play perfect as before.

I tried out some settings but I can´t get to work.
PLUS i just found out, that it´s not only my TV having problems with the files, but tsmuxer too!!!
"Some tracks not recognized....." comes with no recognized audio streams.

Anybody with a solution for this problem?

[SamuriHL]

Yes, if you'd have read this thread it has been discussed to death. You need to turn compression to NO on the extended tab for your audio track. And no, Mosu won't make that the default or give you a way to set that as default. :)

[Rodger]

Yes, if you'd have read this thread it has been discussed to death. You need to turn compression to NO on the extended tab for your audio track. And no, Mosu won't make that the default or give you a way to set that as default. :)

Sorry Mate. 0 Points for that answer. Doesn´t work.
And by the way...I found that tip before you posted it.

EDIT: I do have to correct. Playback on my SamsungTV does work now again, but tsmuxer still does not recognize the audio stream. THAT is still a HUGE disadvantage to me.

[SamuriHL]

Sorry Mate. 0 Points for that answer. Doesn´t work.
And by the way...I found that tip before you posted it.

EDIT: I do have to correct. Playback on my SamsungTV does work now again, but tsmuxer still does not recognize the audio stream. THAT is still a HUGE disadvantage to me.

And....you documented that in your original post that you set that? :rolleyes: Right, I know, we're all supposed to be mind readers as to what you've done and haven't done to fix the problem. Enough guessing games from me then.

[jasonwc]

Sorry Mate. 0 Points for that answer. Doesn´t work.
And by the way...I found that tip before you posted it.

EDIT: I do have to correct. Playback on my SamsungTV does work now again, but tsmuxer still does not recognize the audio stream. THAT is still a HUGE disadvantage to me.

I just tested one of the remuxes I made with MKVMerge 4.1.1. It added an AC3 stream to tsMuxer without issue, despite the fact that header compression was used. It was able to mux to TS as well. No errors.

When did your problem start and what was the last working version?

[Rodger]

I can pinpoint it to a certain Date. It was the 3rd of july.
I did´t update for quite a while before that. I think I do recall I updated from Version 3.4.

I do confirm, that I just have testet positively with a file, which wasn recognized fully by tsmuxer before.
Demuxed and remuxed it WITH setting to no compression.
NOW tsmuxer does find the fullHD AVC and the DTS-HD Stream inside.

That cuts my problem to my DVBS2-Recordings from a Vantage 7100s (SkyHD).
This is where I recognized the problem at first.

I currently have no such recordings at hand so I can´t test it right now. But surely will as soon as possible.

Thank you very much for your help so far.

[Sebastiii]

I created a patch to fix the problem, but it hasn't been applied yet. MPC Ticket 536 (https://sourceforge.net/apps/trac/mpc-hc/ticket/536)

Hi,
Aleksoid has reply on ticket and doesn't reproduce this issue, so it's seems all is ok :)

Could you post sample and or describe how you produce this issue ?

Thanks,
Sebastiii.

[sneaker_ger]

The problem only appears on subtitle tracks that are set to "eng" using mkvmerge >= 4.0.0 (thus do not have a track language element). All other combinations work fine.

[Brazil2]

I think that you should disable audio compression by default. It only causes more confusion. You've added that feature too late
Sorry, but I won't. Users have several options (some better suited than others for different kinds of users): keep using an earlier version; force compression off; use the command line which makes forcing easier; get the player vendors to support this feature that's been part of the specifications for eight years now.
mkvtoolnix is not (only) about user requests, it's also (or even more so) about pushing Matroska features.
In every car I had since I got my driving license several decades ago, there was an electric cigarette lighter receptacle. It's a built-in feature, a part of the specs of the car.
But I'm a non smoker. So here comes the question: should I start to smoke because this lighter is available so I MUST use it ? Or is it useless ?

Header compression is a part of the Matroska specs, you want to support it, perfect, no problem.
But why do you want to FORCE people to use it by default since it's a pretty useless feature that saves only few bytes. If it was about MB I could understand, but bytes !?
And if we could at least save the default configuration we want to use for this option, but no we can't and we have to go through menus to set if off on every mux.

[SeeMoreDigital]

Given the radical changes with these new MKVmerge releases, how about closing this 3 and a half year old thread and creating a new "mkvtoolnix 4.x.x" thread from post 1611 onwards?

[Mosu]

Given the radical changes with these new MKVmerge releases, how about closing this 3 and a half year old thread and creating a new "mkvtoolnix 4.x.x" thread from post 1611 onwards?

Not a bad idea. I've asked Foxyshadis to do it.

[SeeMoreDigital]

Not a bad idea. I've asked Foxyshadis to do it.I do have them... from time to time ;)

EDIT: And for all those interested. The old thread can be found here: http://forum.doom9.org/showthread.php?t=120648

[LeXXuz]

I think there might be a bug with keeping the <eng> language ID of tracks when importing older matroska files.

I remuxed a couple of older matroska files with 4.1.1 and noticed that the <english> language ID always gets stripped from the outcoming file. Even if it is set correctly in mmg. This occurs for all kinds of tracks (subs, audio, video). However, the <german> language ID of any track is been taken over to the final file, as it should. At the moment I have to reopen those files with the Header Editor and replace the "undetermined" values of the language IDs manually.

Pardon me, if this has been reported before. :)

EDIT: Header Editor also hangs up after editing 2 or 3 files. The open file dialogue box does not appear anymore and the right window is empty even if a file is still opened:
http://img3.imagebanana.com/img/nbl8712q/thumb/headereditor.png (http://www.imagebanana.com/view/nbl8712q/headereditor.png)

[Mosu]

I think there might be a bug with keeping the <eng> language ID of tracks when importing older matroska files.

Yes, this has been discussed a lot after the release of v4.0.0. Please read this FAQ entry for an explanation: http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values

EDIT: Header Editor also hangs up after editing 2 or 3 files. The open file dialogue box does not appear anymore and the right window is empty even if a file is still opened:
http://img3.imagebanana.com/img/nbl8712q/thumb/headereditor.png (http://www.imagebanana.com/view/nbl8712q/headereditor.png)

This seems to a bug. I'll take a look when I find the time (meaning hopefully in the next couple of weeks).

[Selur]

got a question (just to be sure): 2010-07-12 Moritz Bunkus <moritz@bunkus.org>
....
* mkvmerge: bug fix: Header removal compression has been deactivated for MPEG-4 part 2 (aka DivX/Xvid) video tracks due to incompatibility with packed bitstreams.
Does this mean Header removal compression will be automatically deactivated when feeding mkvmerge with a MPEG-4 part 2 with packed bitstreams?

[Mosu]

No, it's completely turned off for MPEG-4 part 2, no matter whether the bitstream is packed or not.

[Underground78]

What I'm trying to do at this very moment is to get companies to update their software to support a wider range of the specs.

And it does work ... I took the time to report the problem with "header removal compression" for the set-top box provided by the French FAI Free (http://en.wikipedia.org/wiki/Freebox) and the support of this feature will be added in next firmware !

[Keiyakusha]

I understtand the goal of making someone support wider range of the mkv specs by making changes to mkvmerge, but then I don't understand why we have webm support in mmg. More logical would be not allow creating VP8 videos in webm-compliant way.

[Mosu]

??? I want both Matroska and WebM to succeed. WebM is not a competitor to Matroska as it has a totally different focus.

[Keiyakusha]

Well, the focus is different, for now. But it will sneak in everywhere it can. From the perspective of a some manufacturer, why they should implement full matroska support if only webm is fine and most importantly its not bounded by patents? Currently webm is only lacking some subtitles support, but subs is a work in progress and webm will be expanded to support subs when they done. Also currently I'm doing backups with x264/apple aac but I'm gladely switch to VP8/vorbis and there will be no need for me in whole matroska. I'm sure the same valid for some other people.

[Mosu]

Sure, some people will switch, but h264+AAC in Matroska has gained way too much ground for companies to ignore. I simply don't think what you've described will happen, and not supporting WebM would be the worse for Matroska+WebM than the imaginary gain for Matroska by not supporting WebM.

[Snowknight26]

Shouldn't compression be turned on for A_PCM?

[Stephen R. Savage]

Possibly ZLIB compression or something similar, but I can't imagine header removal helping, since PCM has no headers.

[Selur]

btw. does webm support chapters?

[Snowknight26]

Possibly ZLIB compression or something similar, but I can't imagine header removal helping, since PCM has no headers.

Remuxed file was 85% of the original with compression turned on. And it wasn't PCM but WAV as mkvmerge doesn't support PCM (but says PCM as the codec when WAV is used).

[GodofaGap]

Remuxed file was 85% of the original with compression turned on. And it wasn't PCM but WAV as mkvmerge doesn't support PCM (but says PCM as the codec when WAV is used).
That doesn't make too much sense. WAV is a container and PCM is a way of representing uncompressed audio data in a digital way. Obviously MKVmerge supports PCM in WAV. :)

Perhaps the PCM data itself is compressed?

Sure, some people will switch, but h264+AAC in Matroska has gained way too much ground for companies to ignore.
Not only that. H264 and AAC have already found their way in lots of different hardware devices. They are not suddenly going to disappear. Also, you don't make a format open and then expect people to not use and build on it. :)

[AlistRain]

how to create a tag (eg "SourceFrom: string")
I could not do this with help and example-tags.xml

translated by google (translate.google.ru)

[mrbass]

Since I've started working on mkvtoolnix in 2002 I've received all of 200 EUR in donations. No corporation has ever contacted me and asked me to change mkvtoolnix in any way.


Truly sad state of affairs. I hope donations pick up eventually.

[Mosu]

Truly sad state of affairs. I hope donations pick up eventually.

Well... I don't do it for the money, and I don't ask for donations (I don't even have a "donate via paypal" button on my home page or something similar). So I'm perfectly OK with it. This was an argument that no decisions were ever based on the wishes of a company.

[DigitAl56K]

Mosu,

I see there have been many requests on the matter of header compression already so please do not take offense that I add mine also. I'm only contributing for what I feel is good for .mkv :)

Also it's a lie if a corp tells you that they cannot fix bugs in older hardware. This is not about implementing a whole new video codec for which the hardware might not be capable enough. These are minor software updates which would only require a new firmware, certainly not a new hardware device.

Firmware upgrades are something you and I and those we converse with here can all perform. They are not something 99% of people understand or are willing to do without being prompted with an easy-to-use "Update available, update now?" wizard popping up on their screen.

We're talking moms & pops, kids, grandparents, people who buy devices to watch movies, not to tinker with them. My mother would be too afraid to go through what's typically a poorly documented firmware upgrade process buried on a support website that's hard to find - if she could even download and extract the file to a suitable medium and follow the special startup procedure. My younger brother would manage it no problem - but he's a developer. My sisters? Again, no way. Lots of devices are sold rebranded under the names of big stores and have custom SKUs/model codes, complicating things even further.

*insert for yourself obvious blurb here about cost of regression tests, risk of bricking devices, etc. etc.*

I know corps like to sell new devices instead of support old ones. But changing their corporate mind is the responsibility of each and every consumer by making the choice which devices to buy and which not to buy.

That's very idealistic, but far from reality. Consumers might choose a device because it plays some format or it doesn't. And when it comes to internet delivery formats vs formats you see on store shelves, like DVD and Blu-Ray even that is a subset of the overall segment. A consumer could read every line of text on a product package and all the in-store material and have no idea whether or not header compression was supported by a device. What percentage of Doom9ers knew what it was before you explained it, even though it's been in the specs for a long time? :)

You're also working against your own statement here: Consumers will buy a new device because their old one isn't working well whether manufacturers provide an update or not. (unless the update is conspicuously presented and simple to perform, not the case on the majority of device types)

mkvtoolnix is not (only) about user requests, it's also (or even more so) about pushing Matroska features. I'm perfectly aware that "Matroska features" and "user requests" don't always overlap very well.

This is the key thing I wanted to put forth to you. What you are trading here is a few KB in data relative to a file that's likely to be GBs large against the masses having a positive experience around .mkv files. What happens when the average Joe tries to play an .mkv file and doesn't get any sound? Then he maybe tries another and it works. Then he tries another and it doesn't work again. He's not going to know that this is because header compression isn't supported. He probably doesn't even know where to find out and troubleshooting the issue probably hasn't crossed his mind. If you are lucky maybe he wastes his time and money trying a different device and perhaps it's no better. All he knows is that .mkv is unreliable compared to other formats. Average Joe is the vast, vast majority of people.

You can push a feature by having an option that people can set and even making it prominent, but let it be in a compatible mode by default. Pushing features is okay, but please give further thought to how this particular change might affect the perception of .mkv overall, which is much more vital to its success than these few KBs in data savings. If popular mkv writers will bluntly sacrifice interoperability over such issues stable, proprietary platforms will take away ground. Changing something fundamental like this in mkvmerge is pretty big and seems like an odd decision after so much effort has been spent trying to convince manufacturers to support .mkv. I don't think it helps the cause to willfully risk breaking devices only for the sake of pressing a very minor feature later. I've also had to make calls over interoperability many times and I know it is not easy, but I hope you will reconsider.

Those are my personal thoughts.

- Al

[Atak_Snajpera]

Average Joe will probably use RipBot264 for encoding. Don't worry I won't update mkvtoolnix to anything above 4.0.0

[Mosu]

That's very idealistic, but far from reality.

If I hadn't been idealistic I would never have started with Matroska in the first place. Again, sorry, but I won't change it.

[Mosu]

Average Joe will probably use RipBot264 for encoding. Don't worry I won't update mkvtoolnix to anything above 4.0.0

As an author of a frontend you can safely upgrade to > 4.0.0 if you're already using 4.0.0. Just add "--compression -1:none" to all non-subtitle files.

[LeMoi]

Average Joe will probably use RipBot264 for encoding. Don't worry I won't update mkvtoolnix to anything above 4.0.0

Average Joe doesn't rip, he downloads ! :D

[Atak_Snajpera]

As an author of a frontend you can safely upgrade to > 4.0.0 if you're already using 4.0.0. Just add "--compression -1:none" to all non-subtitle files.
How can i verify that track has not been compressed?

[Mosu]

Use mkvinfo. If that track does not have a 'content encoding' element listed then it is not compressed.

E.g. a compressed track (VobSub compressed with zlib in this case) looks like this:

| + A track
| + Track number: 2
| + Track UID: 2086699828
| + Track type: subtitles
| + Default flag: 0
| + Lacing flag: 0
| + Codec ID: S_VOBSUB
| + CodecPrivate, length 348
| + Language: dan
| + Content encodings
| + Content encoding
| + Content compression

Header removal compression looks like this (non-essential parts omitted):

| + Content encodings
| + Content encoding
| + Content compression
| + Algorithm: 3 (header removal)
| + Settings: length 1, data: 0xff

[Atak_Snajpera]

Thanks mosu!

[Audionut]

New VLC media player is fixed.

[7ekno]

Thanks for MKVToolnix and all the ongoing support ;)

Good idea to split the thread cause it took me a little while to find the relevant posts!

7ek

[shh]

Hello mosu,
I'm using your actual beta release from here: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/
version build20100719-289

Issue: Merging of files with compression on/off -> crash
I want to merge 2 MKVs containing MPEG4p10, AC3 and SRT.
1st (16.nocomp.mkv): not using header removal compression
2nd (17.comp.mkv): using header removal compression (=standard)
Now, when I activate "none" for compression of the video-track and try to mux the program crashes.
I've uploaded the files as:
16.nocomp.mkv
17.comp.mkv

[Mosu]

I can reproduce the issue here. I'll try to fix it this week.

[nautilus7]

I think that splitting a file after a given size functionality is broken in latest version.

[Mosu]

I don't think so:

[0 mosu@tionne (rake)# ~/prog/video/mkvtoolnix/data] ls -lL v.avi
-rw-r--r-- 1 mosu vj 13232128 2003-11-10 17:54 v.avi
[0 mosu@tionne (rake)# ~/prog/video/mkvtoolnix/data] mkvmerge -o v.mkv v.avi --split 5m
mkvmerge v4.1.1 ('Bouncin' Back') built on Jul 26 2010 23:49:13
'v.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'v.avi' track 0: Using the video output module.
'v.avi' track 1: Using the MPEG audio output module.
The file 'v-001.mkv' has been opened for writing.
Progress: 0%
The cue entries (the index) are being written...
The file 'v-002.mkv' has been opened for writing.

The cue entries (the index) are being written...
The file 'v-003.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 0 seconds.
[0 mosu@tionne (rake)# ~/prog/video/mkvtoolnix/data] ls -l v-00*.mkv
-rw-r--r-- 1 mosu vj 6094174 2010-07-27 09:06 v-001.mkv
-rw-r--r-- 1 mosu vj 5802909 2010-07-27 09:06 v-002.mkv
-rw-r--r-- 1 mosu vj 1245659 2010-07-27 09:06 v-003.mkv

What makes you say that?

[nautilus7]

Well, if i load a file and then select split after 50M, the files writen are very small (~5MB or so). Tried with different files and split sizes. Split after given duration works fine though.

[Mosu]

Can you upload such a file somewhere please? Along with a .mmg file with the settings you've chosen (or the command line).

[nautilus7]

i didn't do anything special. Opened an .mkv file (5 or 6 GB) with mkvmerge GUI and chose to split after a size, like in the picture above:

http://i26.tinypic.com/2ikbj40.png

I was able to reproduce the problem with different split sizes and and different .mkv files (one with h264 only and one with h264 and dts).

[Mosu]

The problem has been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.1.1-build20100727-290-setup.exe

[rpm7200]

mkvmerge is adding jitter my mkv files. is this a bug or something. what kind a problem is this?

[Mosu]

Issue: Merging of files with compression on/off -> crash

This problem should be fixed in the following build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.1.1-build20100727-291-setup.exe

[nautilus7]

The problem has been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.1.1-build20100727-290-setup.exeThanks a lot! :)

[shh]

This problem should be fixed in the following build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.1.1-build20100727-291-setup.exe

Thanks! Seems to work that way, but a problem still remains: It crashes, when I add files with compression just the other around:
16.comp.mkv
17.nocomp.mkv
with compression-option "none".
That are the same files as above, just with swapped compression.
I'm just uploading my two files....

[Mosu]

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.1.1-build20100728-292-setup.exe

[shh]

Great! It works for me now. :thanks:

[Mosu]

Hey,

I've released mkvtoolnix v4.2.0. It contains a lot of bug fixes and a few enhancements but no major new features.

There are no changes for package maintainers in this 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-4.2.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.2.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.2.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.1.1:

------------------------------------------------------------
2010-07-28 Moritz Bunkus <moritz@bunkus.org>
* Released v4.2.0.
* mkvmerge: bug fix: mkvmerge was accessing invalid memory In certain cases, e.g. when appending Matroska files that use compression while turning compression off.

2010-07-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Splitting output files by size was basing its decision when to create a new file on an uninitialized variable. This caused effects like a lot of small files being created with sizes much smaller than the intended split size.

2010-07-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The speed with which mkvmerge skips garbage in DTS tracks has been greatly improved.

2010-07-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Reading Matroska files: DisplayWidth & DisplayHeight values that are obviously not meant to represent pixels but only to be used for aspect ratio calculation (e.g. 16x9) are converted into proper ranges based on the track's PixelWidth & PixelHeight values and the quotient of DisplayWidth / DisplayHeight.

2010-07-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Attachments will be rendered at the end of the file instead of at the beginning. The attachments will be placed after the cues but before the chapters. Fix for bug 516.
* mkvmerge: enhancement: Header removal compression has been enabled by default for MPEG-4 part 10 (AVC/h.264) video tracks with a NALU size field length of four bytes.
* mkvmerge: bug fix: Header removal compression has been deactivated for MPEG-4 part 2 (aka DivX/Xvid) video tracks due to incompatibility with packed bitstreams.

2010-07-10 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The taskbar progress is reset as soon as mkvmerge finishes/as soon as all jobs are done (Windows 7).

2010-07-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading AVC/h.264 tracks from AVI files if they're stored without NALUs inside the AVI. Was broken by a fix for handling AVC/h.264 in NALUs inside AVI.
* mkvmerge: bug fix: All readers that only handled file formats which do not contain more than one track did not respect the "--no-audio / --no-video / --no-subtitles" options. This applied to the following readers: AAC, AC3, AVC/h.264, CorePicture, Dirac, DTS, FLAC, IVF, MP3, MPEG ES, PGS/SUP, SRT, SSA, TrueHD, TTA, VC1, WAV and WavPack.

2010-07-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Improved reading text files that use mixed end-of-line styles (DOS & Unix mixed).

2010-07-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed invalid memory access in the PCM packetizer. Fix for bug 510.
* mmg: bug fix: When mmg starts it will check the entries in the file and chapter menu's list of recently used files and remove those entries that no longer exist. Fix for bug 509.
* mkvmerge: bug fix: Fixed a crash when reading Matroska files that were damaged in a certain way.
------------------------------------------------------------

Have fun.

[b66pak]

thanks a lot..
_

[yumemi]

I'm trying to use the command-line interface to edit several files at once. I managed to edit track names and track flags correctly (with batchenc.exe) but there are 2 other things I would like to do. First, I want to remove all the fonts in the mkv and replace them with some others (let's say font1.ttf and font2.otf). Second, I want to put the file name in the title global tag because all my files are named "title.mkv". How can I do that with a command-line? I read your documentation but I didn't understand it very well (It's the first time I use the CLI and my English level doesn't help :-).

Anyway, thanks for your great work Mosu!

[Mosu]

You need a XML file for the tags, e.g. something like

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE Tags SYSTEM "matroskatags.dtd">

<Tags>
<Tag>
<Simple>
<Name>TITLE</Name>
<String>Your file name</String>
</Simple>
</Tag>
</Tags>

Then run mkvmerge, e.g.

mkvmerge -o newfile.mkv --no-attachments input.mkv --attachment-name originalfontname.ttf --attach-file newfont1.ttf ... --global-tags yourtagfile.xml

[Mosu]

There's a bug in v4.2.0 that results in tracks from SSA/ASS files not being copied into the output file if you use mmg. This has been fixed in the following build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.2.0-build20100729-293-setup.exe

Also the Matroska team is moving their IRC channel to Freenode: https://www.bunkus.org/blog/2010/07/matroska-moving-irc-channel-to-freenode-network/

[hubblec4]

hi mosu

when i mux with the mmg video and audio and sup's and i set the language to english and open the file with mediainfo. the eng-language is not shown. but all other language works.

with earlier version of mkvmerge it works.

here an example from mediainfo


Allgemein
Vollständiger Name : T:\Filme\Science Fiction\Star Trek 10 - Nemesis HD.mkv
Format : Matroska
Dateigröße : 23,7 GiB
Dauer : 1h 56min
Gesamte Bitrate : 29,1 Mbps
Kodierungs-Datum : UTC 2010-07-29 09:26:09
Kodierendes Programm : mkvmerge v4.2.0 ('No Talking') built on Jul 28 2010 18:38:23
verwendete Encoder-Bibliothek : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High@L4.1
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für ReFrame : 4 frames
Muxing-Modus : Container profile=Unknown@0.0
Codec-ID : V_MPEG4/ISO/AVC
Dauer : 1h 56min
Breite : 1 920 Pixel
Höhe : 1 080 Pixel
Bildseitenverhältnis : 16:9
Bildwiederholungsrate : 23,976 FPS
Auflösung : 8 bits
Colorimetrie : 4:2:0
Scantyp : progressiv
Titel : h264 untouched
colour_primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
transfer_characteristics : BT.709-5, BT.1361
matrix_coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio #1
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Codec-ID : A_AC3
Dauer : 1h 56min
Bitraten-Modus : konstant
Bitrate : 640 Kbps
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Surround: L R, LFE
Samplingrate : 48,0 KHz
Stream-Größe : 533 MiB (2%)
Titel : AC3 640
Sprache : Deutsch

Audio #2
ID : 3
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec-ID : A_FLAC
Dauer : 1h 56min
Bitraten-Modus : variabel
Kanäle : 6 Kanäle
Samplingrate : 48,0 KHz
Auflösung : 24 bits
Titel : TrueHD --> FLAC
verwendete Encoder-Bibliothek : libFLAC 1.2.1 (UTC 2007-09-17)

Audio #3
ID : 4
Format : AAC
Format/Info : Advanced Audio Codec
Format-Version : Version 4
Format-Profil : LC
Format-Einstellungen für SBR : Nein
Codec-ID : A_AAC
Dauer : 1h 56min
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Rear: L R, LFE
Samplingrate : 48,0 KHz
Titel : AAC 256
Sprache : Französisch

Audio #4
ID : 5
Format : AAC
Format/Info : Advanced Audio Codec
Format-Version : Version 4
Format-Profil : LC
Format-Einstellungen für SBR : Nein
Codec-ID : A_AAC
Dauer : 1h 56min
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Rear: L R, LFE
Samplingrate : 48,0 KHz
Titel : AAC 256
Sprache : Italienisch

Audio #5
ID : 6
Format : AAC
Format/Info : Advanced Audio Codec
Format-Version : Version 4
Format-Profil : LC
Format-Einstellungen für SBR : Nein
Codec-ID : A_AAC
Dauer : 1h 56min
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Rear: L R, LFE
Samplingrate : 48,0 KHz
Titel : AAC 256
Sprache : Spanisch

Text #1
ID : 7
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Titel : Das Nötigste
Sprache : Deutsch

Text #2
ID : 8
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Deutsch

Text #3
ID : 9
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs

Text #4
ID : 10
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Französisch

Text #5
ID : 11
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Italienisch

Text #6
ID : 12
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Spanisch

Text #7
ID : 13
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Arabisch

Text #8
ID : 14
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Kroatisch

Text #9
ID : 15
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Niederländisch/Holländisch

Text #10
ID : 16
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Finnisch

Text #11
ID : 17
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Norwegisch

Text #12
ID : 18
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Portugiesisch

Text #13
ID : 19
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Sprache : Schwedisch

Text #14
ID : 20
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Titel : Regiekommentar 1
Sprache : Deutsch

Text #15
ID : 21
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Titel : Regiekommentar 2
Sprache : Deutsch

Text #16
ID : 22
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Titel : Regiekommentar 3
Sprache : Deutsch

Text #17
ID : 23
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Titel : director's comments 1

Text #18
ID : 24
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Titel : director's comments 2

Text #19
ID : 25
Format : PGS
Codec-ID : S_HDMV/PGS
Codec-ID/Info : The same subtitle format used on BDs/HD-DVDs
Titel : director's comments 3

Menü
00:00:00.000 : de:Konspiration
00:04:15.297 : de:Blauer Himmel
00:08:28.842 : de:Positronische Signatur
00:12:00.678 : de:Gefährliche Geschwindigkeit
00:20:14.797 : de:Segeln ins Unbekannte
00:23:21.859 : de:Gedächtnis-Download
00:25:47.755 : de:Raubtier
00:28:14.484 : de:Praetor Shinzon
00:34:32.195 : de:Treueeid
00:38:42.820 : de:Nicht ganz menschlich
00:47:49.700 : de:Verstoß
00:51:54.737 : de:Das Echo über der Stimme
00:56:56.330 : de:Flucht
01:02:19.736 : de:Verfallrate
01:06:25.773 : de:Kampfstationen
01:09:49.435 : de:Wie durch dunkles Glas
01:16:48.020 : de:Romulanische Unterstützung
01:20:37.624 : de:Erinnerst du dich an mich?
01:25:35.547 : de:Vorbereitung auf den Aufprall
01:31:34.906 : de:Wert dafür zu sterben
01:35:23.384 : de:Das Gesicht des Feindes
01:40:29.941 : de:Ende der Reise
01:45:07.801 : de:Neue Horizonte
01:49:21.180 : de:Abspann

[Mosu]

when i mux with the mmg video and audio and sup's and i set the language to english and open the file with mediainfo. the eng-language is not shown. but all other language works.

Bug in mediainfo. Has been discussed a lot already. Please read this FAQ entry for an explanation: http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values

[hubblec4]

ok thanks. sorry for wasting your time :-)

[sneaker_ger]

Thx for the new release, but I'm having serious doubts about the fix for "bug" 516. If the file has attached fonts it would mean that people couldn't stream anymore if they wanted to view the subtitles in the correct style, but instead would have to download the complete file prior to viewing. Isn't this the main use of attachments at the moment?

[rack04]

Someone please correct me if I'm wrong. If I want to old behavior of mkvtoolnix then I have to select "no compression" on all tracks?

[Mosu]

Thx for the new release, but I'm having serious doubts about the fix for "bug" 516. If the file has attached fonts it would mean that people couldn't stream anymore if they wanted to view the subtitles in the correct style, but instead would have to download the complete file prior to viewing. Isn't this the main use of attachments at the moment?

True. We're aware of the problem, and the only sensible solution would be to offer the user the choice were to put the attachment on a per-attachment basis. Some attachments are indeed necessary for playback (fonts), some definitely aren't (cover images), and some are meant for long term storage of associated data (e.g. encoding output logs or whatever). Both places (all at the front and all at the back) have their own set of advantages and disadvantages. At the moment I will not invest time in implementing finer-grained control.

The problem is also only relevant for streaming, not for local playback. Playback of local files already requires seeking to the end in order to read the cues (index).

[Keiyakusha]

some definitely aren't (cover images)
Well, covers also can be used like... covers! I mean cover from a disc for audio file or some poster for video. There is no impact if they will be at the end of the file? However there is no tools to display this since haali removed thumbnails...

[sneaker_ger]

I see. If you do implement a finer-grained control it would be nice if mmg would auto-choose the position based on the file type if you don't specify it manually. I'd personally vote for reverting to the old behavior as I think that's what suits the vast majority of users (including myself). Not forgetting that's the first time someone complained, and he himself claims to "never have seen a streamed matroska file". (Also the quote on the matroska homepage has been updated to "which is not necesseraly good for streamed files".)

On a different matter: Are you considering adding support for the additional elements that link fonts to srt subtitles as proposed by DivX to mkvmerge?

[Mosu]

Well, covers also can be used like... covers! I mean cover from a disc for audio file or some poster for video. There is no impact if they will be at the end of the file? However there is no tools to display this since haali removed thumbnails...

I meant that covers aren't necessary to be at the front of the file when streaming files.

[Mosu]

On a different matter: Are you considering adding support for the additional elements that link fonts to srt subtitles as proposed by DivX to mkvmerge?

Not really. At least not at the moment.

[Gew]

It's like the 'und' option for language tracks, in first releases, every track added had its language set to English, and then Mosu decided to set the default language as Undetermined -even if Matroska specs say that default language is English, which may cause problems now (with latest releases) for some old splitters and players unlike Haali's one.Is that so?

So you mean that the Matroska specifications doesn't really allow on the "und" code slash flag in language metadata? I.e. that this is something that has "evolved into okey" throughout a vast majority of splitters agreeing on support the this "enhancement"..? I got curious, surfed into http://www.bunkus.org/videotools/mkvtoolnix/win32/old/ and fetched the oldest build there was (mkvtoolnix-0.4.2.zip). Tried a simple "mkvmerge.exe -o foo.mkv vid.avi aud.mp3" for kicks, and ran recent mkvinfo.exe aswell as mediainfo.exe on the file. No language entries whatsoever. Even hex-examined the .mkv ie. searching it for string 'eng', no result. Am I being ridiculous now? Halfway-neurotic? Perhaps. But since Matroska is my media container of choice it would feel like a real smash in the face if it turned out to be somewhat a semi-manufactured article. Just a little bit scared now, that's all. Clarification would please and comfort!

:thanks:

--EDIT--
I just made another experiment. I pulled a quick line (mkvmerge.exe -o foo.mkv vid.avi aud.mp3) with a more recent build (v4.1.1). Then I hex-examined foo.mkv, searching for string 'und'. The first two instances looked like a possible match, because they were right next to the header text (respectively ...MPEG4/ISO/AVC... and ...MPEG/L3...). I replaced "und" with "eng" and "dan" in these two instances. Then saved. First tried watching it, to make sure I hadn't f-cked something up badly. The playback was alright, anyhow. So, I dropped "mediainfo.exe foo.mkv" from CLI, and guess what? The two tracks (a/v) now turned up as respectively English and Danish. Interesting, indeed. Funny thing that I got no hex-search hits on "und" on the foo.mkv that I had muxed with mkvmerge v0.4.2, I could be on a lead here. Does this have some coherence/connection with what you (LeMoi) claimed in quoted post..?

[Mosu]

Is that so?

So you mean that the Matroska specifications doesn't really allow on the "und" code slash flag in language metadata?

No, you're completely misunderstanding the issue here.

A) There's an Matroska element called 'track language'. The Matroska specifications say that all ISO639-2 codes are valid for this element. The list of ISO639-2 includes, amongst others, the values 'eng' for 'English' and 'und' for 'undefined'. So both values are valid.

B) The next think is that the Matroska specification knows about 'default values' for some of its elements. The 'default value' is the value that a player must use if that element is not present in the file but its parent element is. In our example the value 'eng' is the 'default value' for the 'track language' element. A couple of examples:

1. The Matroska file contains a 'track language' element with the value 'ger'. The demuxer/player uses 'ger' for that track (German).
2. The Matroska file contains a 'track language' element with the value 'und'. The demuxer/player uses 'und' for that track (undefined).
3. The Matroska file does not contain a 'track language' element. The demuxer/player uses 'eng' for that track (English).

C) The third issue here is what mmg/mkvmerge uses by default if the source container for a track DOES NOT provide language information -- e.g. if you read raw h264 files, raw AC3 or AAC files etc. mkvmerge and mmg default to 'und' in those cases unless. This default has nothing (!) to do with the 'default values' mentioned in the Matroska specifications.

So what has changed in recent mkvtoolnix releases? mkvmerge does not write Matroska elements into output files which have a 'default value' in the specs and whose actual value equals their 'default value'. So in the case of 'track language' == 'eng' mkvmerge v3.4.0 would write that element into the output file whereas mkvmerge v4.0.0 does not do that anymore -- because it's redundant. See example 3 from above. Some demuxers/player, however, did not implement that part of the specifications properly and either used 'und' instead of 'eng' as the 'default value' or something else entirely.

I.e. that this is something that has "evolved into okey" throughout a vast majority of splitters agreeing on support the this "enhancement"..? I got curious, surfed into http://www.bunkus.org/videotools/mkvtoolnix/win32/old/ and fetched the oldest build there was (mkvtoolnix-0.4.2.zip). Tried a simple "mkvmerge.exe -o foo.mkv vid.avi aud.mp3" for kicks, and ran recent mkvinfo.exe aswell as mediainfo.exe on the file. No language entries whatsoever.

Don't take anything that old (especially the first releases) as a basis for any conclusion. They're not spec compliant, buggy, very early work in the development cycle in mkvtoolnix.

Now what LeMoi refers to is a change in C). Back in the day mkvmerge defaulted to using 'eng' if neither the user nor the source container provided language information. That was changed to 'und'. I repeat: that was a change that should NOT have had ANY effect on the players/demuxers -- it should only have affected mkvmerge's users because they would had to actively decide that their track's language was 'eng' instead of 'und'. It was done because people requested it, and because English is not the center of the world.

[LeMoi]

Is that so?

So you mean that the Matroska specifications doesn't really allow on the "und" code slash flag in language metadata? I.e. that this is something that has "evolved into okey" throughout a vast majority of splitters agreeing on support the this "enhancement"..? I got curious, surfed into http://www.bunkus.org/videotools/mkvtoolnix/win32/old/ and fetched the oldest build there was (mkvtoolnix-0.4.2.zip). Tried a simple "mkvmerge.exe -o foo.mkv vid.avi aud.mp3" for kicks, and ran recent mkvinfo.exe aswell as mediainfo.exe on the file. No language entries whatsoever. Even hex-examined the .mkv ie. searching it for string 'eng', no result. Am I being ridiculous now? Halfway-neurotic? Perhaps. But since Matroska is my media container of choice it would feel like a real smash in the face if it turned out to be somewhat a semi-manufactured article. Just a little bit scared now, that's all. Clarification would please and comfort!
No, sorry, but I think you didn't understand what I meant. I just said what Mosu said: in first mkvtoolnix builds, when you added a raw track (AVI, MP4, AAC, MP3, etc., = no mk*), mmg used to display/set 'eng' as track language if you didn't change it, while in later builds, but older than 4.0.0, it used to display/set 'und' (which used to mean "undetermined", as far as I remember, and not "undefined" ?). But it seems that this 'eng' value is not written any more, since it's the default value, the splitter has to recognize it as default value and set it to English instead of Undefined?

[wata]

i have this problem too when i update mkvtoolnix to 4.1 using megui, subtitle - language set to english when play back using mpc-hc become unknown, latest mediainfo also cannot detect the language of the subtitle track.
the default track flag also no when i choose YES when muxing

meantime switch back to 3.4

[Mosu]

Report that to the mpc-hc and mediainfo authors. This has been discussed time and again. There's already a bug report open for MPC-HC. I don't know about mediainfo. Please use the search form. Thank you.

[wata]

can't mkvtoolmix just change to old behaviour
i have some other player/utils also unable to detect eng language track

mediainfo eg.


Text #1
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : English

Text #2
ID : 4
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : Chinese


after version 3.4

Text #1
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text

Text #2
ID : 4
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : Chinese

[Mosu]

No, sorry, because this is not a defect in mkvtoolnix/mkvmerge.

[Gew]

Ty for your clafication Mosu. Very legible.
No further questions. Great job on v4.2.0 btw.

[sneaker_ger]

The bug in MPC-HC was fixed about a week ago. Upgrade to a newer version. ( You can get builds from here (http://xhmikosr.1f0.de/) until xvidvideo.ru is updated again.)

[Rodger]

I´m a bit surprised nobody else is experiencing THIS error, I get when I try to start "mmg.exe"

See screenshot for details:
http://www.bilder-space.de/show_img.php?img=66bb3f-1280508942.jpg&size=thumb (http://www.bilder-space.de/bilder/66bb3f-1280508942.jpg)

[Kurtnoise]

when i mux with the mmg video and audio and sup's and i set the language to english and open the file with mediainfo. the eng-language is not shown. but all other language works.

replace your MediaInfo.dll by this one (http://www.mediafire.com/?sdb49k20asqv23m).

[Mosu]

I´m a bit surprised nobody else is experiencing THIS error, I get when I try to start "mmg.exe"

See screenshot for details:
http://www.bilder-space.de/show_img.php?img=66bb3f-1280508942.jpg&size=thumb (http://www.bilder-space.de/bilder/66bb3f-1280508942.jpg)

Uninstall, remove HKEY_CURRENT_USER\Software\mkvmergeGUI, and re-install. Anyway, that error message should contain the actual executable's version in the parentheses... I'll fix that.

Edit2: No, it works as expected. Older mkvmerge versions don't output the version information in a way mmg expects, that's why the parenthesis are empty.

There are three scenarios that I can think of why this is the case for you:

1. You configured mmg to use a specific mkvmerge executable on purpose.

2. You did not configure mmg to use any specific mkvmerge executable. The default is just to call 'mkvmerge'. If your PATH variable contains mkvmerge.exe from another installation before the mkvtoolnix installation that than that mkvmerge.exe might be used instead of the one installed with mmg.

3. You overwrote the mkvmerge.exe in the mkvtoolnix installation path with an older version, e.g. due to problems with default values or header removal compression.

Edit3: It's also possible that for some reason you configured mmg to use an executable that doesn't exist. That's how I can reproduce the issue here.

[Rodger]

WELL THANK YOU!

Problem solved...actually without your help.

Originally there was a Drive K on that I installed an older Version.
Then I downloaded the complete 7z-file from your site and unpacked it to a USB-Stick.
Meanwhile (some time ago) I removed the Drive K.

So had this error at startup.

I removed the installation from vista...actually only the entry from vista but that didn´t work.
Then removed ALL mkvtoolnix related registry-entries by hand.

STILL NO GO! Then I read your ideas and decided to reboot vista.
Tadaaa! That´s it. Obviously restart is neccesary to have vista forget the old registry entries.

[hubblec4]

replace your MediaInfo.dll by this one (http://www.mediafire.com/?sdb49k20asqv23m).

thank you

[RadioactiveMan]

it looks like something is wrong here. note the minus signs in front of the total remaining time.

[Mosu]

it looks like something is wrong here. note the minus signs in front of the total remaining time.

Although the attachment is still pending approval I guess what you're referring to is this: https://www.bunkus.org/bugzilla/show_bug.cgi?id=529

[stax76]

It seems sometimes the --verbose switch is necessary to make mkvinfo output attachments, --verbose is however too slow, maybe you can change it to always output attachments.

[Mosu]

mkvinfo stops when it finds the first cluster if --verbose is not specified. That's by design. Therefore whether or not mkvinfo reports attachments depends on the position of the attachments. If they're written at the front (older mkvmerge versions) then mkvinfo will show them. If they're located at the current (current mkvmerge) then it won't.

I suggest you use "mkvmerge --identify-verbose yourfile.mkv" if you need such information.

[stax76]

I can use --identify-verbose thanks. Would showing everything except clusters be a option? (please excuse, I've no idea about the data structure)

[Mosu]

mkvinfo is a development and analysis tool that is supposed to show the elements present in a file in the order they appear. So I won't add options that condense information other than the "--summary" option already present.

[Foofaraw]

I'm not reverting the change. The specifications state explicitely that in case of an absent element its default value must be used instead. I'm not breaking compliance, I'm forcing others to fix their bugs.


Of course these days most players are hardware, and they usually never change their implementation - thus the endusers are crying whilst they save up for a new device.

But I don't care, I know how to use this program and can fix it :cool:


But what I would like to see (changing the topic) is this little feature:

That we can add our own custom FPS defaults to the drop down menu in 'format specific options'.

[Foofaraw]

No. mkvinfo is designed to show the elements that are actually present. If you want to know things like basic flags, track type and language you can use "mkvmerge --identify-verbose yourfile.mkv". That's what mmg does when you add a file.

I don't understand that. If mkvmerge can show the information it must be present? And so the info program could show it?

[stax76]

What's wrong with the current FPS defaults?

[Mosu]

But what I would like to see (changing the topic) is this little feature:

That we can add our own custom FPS defaults to the drop down menu in 'format specific options'.

I might actually do that.

[Mosu]

I don't understand that. If mkvmerge can show the information it must be present? And so the info program could show it?

The Matroska specifications know a feature called 'default values'. These apply for elements that are not present in the file. mkvmerge takes those values into account. mkvinfo only shows the elements that are actually present.

[Mosu]

But what I would like to see (changing the topic) is this little feature:

That we can add our own custom FPS defaults to the drop down menu in 'format specific options'.

Actually, it'd be much easier and faster for me to implement if you'd just tell me which options you want to have listed. That's more like two minutes than a couple of hours. Also no one else requested this so far, so I'm not really convinced such a feature is needed.

[vmrsss]

Hi Mosu,

After the latest update, I can't build mkvtoolnix any longer. I am on macosx 10.6.4 snow leopard. This is where the compilation breaks down( almost immediately after start)


In file included from src/merge/cluster_helper.cpp:25:
src/merge/cluster_helper.h:17:31: error: calling fdopen: Bad file descriptor
In file included from src/merge/cluster_helper.h:25,
from src/merge/cluster_helper.cpp:25:
src/merge/pr_generic.h:18:31: error: calling fdopen: Bad file descriptor
In file included from src/merge/cluster_helper.cpp:27:
src/merge/output_control.h:18:31: error: calling fdopen: Bad file descriptor


Can you help?

Thx

[Mosu]

Not really. Try disabling the use of precompiled headers (though that's a feature that has been introduced prior to 4.2.0) with the configure option --disable-precompiled-headers

[vmrsss]

Not really. Try disabling the use of precompiled headers (though that's a feature that has been introduced prior to 4.2.0) with the configure option --disable-precompiled-headers

doesn't help, same error. this must be related to the introduction of "rake", which I had never seen before. The last version I built successfully is 4.1.1, which I believe is just the previous one, is it not?


mkvmerge --version
mkvmerge v4.1.1 ('Bouncin' Back') built on Jul 13 2010 03:40:35

[Mosu]

No, 4.2.0 does not use rake yet. Only the current development version in my Git repo does.

Just FYI: rake is a build tool written in Ruby with build description files (Rakefiles) also written in Ruby.

[vmrsss]

No, 4.2.0 does not use rake yet. Only the current development version in my Git repo does.

So, what am I doing wrong? When I ./configure after git pull and ./autogen.sh, I get no Makefile at all. So, make does not work. In fact, ./autogen.sh instructs me to run ./configure and then rake.

[Mosu]

True. I don't know why rake isn't working on Mac OS the way it is on Linux. I can only test it on Linux and Windows as I don't have (shell) access to a Mac. So you should stick with the 4.2.0 release for the time being.

[Forteen88]

When I remux (with mkvtoolnix 4.2.0) some MKV-videos that contains "Cover: Yes / Yes / Yes", then the covers are removed in the remux. Anyone who knows why?

[Mosu]

What does "Cover: Yes / Yes / Yes" mean? Can you upload such a file somewhere or give me a link where I can download one (torrent is fine)?

[Forteen88]

What does "Cover: Yes / Yes / Yes" mean? Can you upload such a file somewhere or give me a link where I can download one (torrent is fine)?I think it means that it contains covers (pictures) for the video. I got that info when using MediaInfo on a file. Sry, I don't have a link for that particular MKV, but I can try to find a link on another one with "Covers".

EDIT: I made one myself (with only one picture, so MediaInfo says: "Cover: Yes"), I just added a JPEG-picture as an attachment to a video in Haali's gdsmux, http://www.mediafire.com/?6z4ljwgmg5n67qw
When I remux that file (using mkvmerge), then the "Cover: Yes" is removed, and I guess that the picture is removed too, as the filesize is lower.

Thanks Mosu.

[Mosu]

After checking such a file before and after muxing I'm certain that the problem is in MediaInfo. mkvmerge now puts attachments at the end but still references them via entries in the meta seek table at the start of the file. That's standard behavior for a Matroska file -- most of those elements (including track headers!) can be located at the end of the file as long as they're indexed at the front. MediaInfo does not seem to follow those indexes to the attachments and therefore it doesn't find the cover image that mkvmerge kept when remuxing.

Please file a bug with MediaInfo. I can explain to them how a proper algorithm should look for finding any of the important (level 1) elements in a Matroska file. Those include track headers, segment information, chapters, tags and attachments.

[Forteen88]

@Mosu: Thanks, I'll do that.

BTW, MediaInfo seem to be able to detect imagefiles inside a MKV that is muxed with Haali's gdsmux.

[Zenitram]

After checking such a file before and after muxing I'm certain that the problem is in MediaInfo.

I confirm it.

mkvmerge now puts attachments at the end but still references them via entries in the meta seek table at the start of the file. That's standard behavior for a Matroska file -- most of those elements (including track headers!) can be located at the end of the file as long as they're indexed at the front. MediaInfo does not seem to follow those indexes to the attachments and therefore it doesn't find the cover image that mkvmerge kept when remuxing.

You're totally right.
I follow headers at the end of the file for MP4 files, but I didn't think to check this for MKV because I never saw this kind of file and I don't follow SeekHead/Seek blocks, I stop the parsing when I find the clusters.

I can explain to them how a proper algorithm should look for finding any of the important (level 1) elements in a Matroska file.

Thanks for the proposal, but I already decode SeekHead block, I understand it, I only need to implement the management of this block in my tool, no worry about this.

Could I ask why you put attachements at the end of the file? From my point of view, this is a seek to do (+ another seek to go back to the beginning) for having them, this may be a lot slower with CD/DVD readers or HTTP streaming.

What does "Cover: Yes / Yes / Yes" mean?

This is the way for MediaInfo to display the presence of 4 attachments.
I agree this is not the best way, but MediaInfo is a general purpose tool, not dedicated to MKV, I need find a good generic display for attachments (eg display the name of attachments)

[Mosu]

Thanks for the proposal, but I already decode SeekHead block, I understand it, I only need to implement the management of this block in my tool, no worry about this.

Good to hear :)

Could I ask why you put attachements at the end of the file? From my point of view, this is a seek to do (+ another seek to go back to the beginning) for having them, this may be a lot slower with CD/DVD readers or HTTP streaming.

I know. There are arguments in favor of and against placing attachments at the end. The ones in favor include easier modification for tools and, more importantly, less stuff to transmit in streaming cases. The ones against include that extra seek (though you usually have to seek to the end in order to read the index anyway) and the situation that even in streaming cases you may need the attachments for playback (e.g. fonts for subtitles). However, no user wants to wait until the 40MB attached files have been downloaded when streaming a file, and seeking on a local medium is comparatively fast. Therefore they're at the end at the moment.

Basically there's no "right" answer, and the placement will most likely change again in the future. mkvmerge will likely use both places and either let the user chose where to put certain attachments or chose automatically based on content type.

[Mosu]

Use the search function: http://forum.doom9.org/showthread.php?p=1421587#post1421587

[BatKnight]

Hi,

I've muxed a video-only MKV with a FLAC audio file and placed a -9ms delay to the audio track before muxing.
I've noticed now that I shouldn't have placed the delay because eac3to already delayed the track when decoded the DTS-MA to FLAC.
If load the muxed MKV back to mkvtoolnix and set a positive 9ms delay to the audio, will the delay be correctly removed and this mistake corrected?

Thanks
Bat

[Mosu]

Not really. mkvmerge's delay option modifies the timecodes of the packets -- so far so good. But packets that would end up with a negative timecode are removed. So in your case your -9 might have caused the very first packet to be dropped during the first remux, and subsequent remuxes can of course not restore that packet.

[BatKnight]

Not really. mkvmerge's delay option modifies the timecodes of the packets -- so far so good. But packets that would end up with a negative timecode are removed. So in your case your -9 might have caused the very first packet to be dropped during the first remux, and subsequent remuxes can of course not restore that packet.
Thanks for the promptly reply.
In a perfectionist point of view, I lost the first 9ms of audio with this mistake, right? If i remux it with positive delays, what will it insert in the start? Blank audio?
(Not that 9ms would ever be noticed, though...)

Bat

[Mosu]

mkvmerge won't insert anything with positive delays, it simply adjusts the timecodes. As most (if not all) players use audio for A/V synchronization this is often not such a good idea for big offsets, but with such small values as 9ms it shouldn't be noticeable at all.

[sneaker_ger]

You will have lost more than 9ms because mkvmerge will drop complete audio frames, as it cannot delete only certain parts of frames. And yes, if you remux with +9ms the delay will be "perfect" again.

[BatKnight]

You will have lost more than 9ms because mkvmerge will drop complete audio frames, as it cannot delete only certain parts of frames. And yes, if you remux with +9ms the delay will be "perfect" again.
Yes, I now understand that the second remux would restore the delay, but at the cost of permanently loosing the previously dropped audio frames.

[Mosu]

I said 'packet' and not 'packets' on purpose. For FLAC one packet is typically a lot longer than 9ms -- roughly 96ms for a typical 44.100 Hz two channel file.

[toytown]

Ive recently been encoding some home movies and just finally got round to muxing them using 4.2, i noticed that as soon as i click the folder with the video files in, the OS (win7) will read the whole file MKV in and the ram will fill up completely to its max (4GB), after about 30-60seconds it will return to normal, if there are more MKV files it will do the same. During this time its impossible to move/copy/delete the file as windows has a lock on it.

The reason for the hang (i believe) is that its trying to extract the thumbnails and failing, i thought the reason could be the header compression option, however if i remux the file using 4.0 or 4.1.1 using default options then the files work perfectly.

Im using the latest haali splitter (with thumbnail extraction off) and ffdshow-tryouts, but i thought win7 had its own filters so that shouldnt matter anyway? Apologies if this is something screwy on my system and not a MKVtoolnix bug.

[Mosu]

Sounds like header removal, yes.

[toytown]

Sorry i meant that i originally muxed the files with 4.2 using default options, so header removal would be turned on. These files lock up explorer for some time.

If i take the 4.2 muxed file drop it into 4.1.1 or 4.0 and just click mux, this file will be ok, thumbnails are generated and everything is good. As i understand this file still contains header removal as im just using defaults.

If i take a good file and drop it into 4.2 and just click mux, i get the problems again.

I believe header removal has been in since v4.00 so if this is the case then it must be something else?

[Mosu]

4.2.0 added header removal for h264 tracks by default. 4.1.0 added header removal for various audio and video formats.

[toytown]

It's a bug in the DivX thumbnailer creator thats installed with the DivX codecs. I checked through the registry to see what ShellEx were being used for MKV files in explorer and found it, i uninstalled the DivX package and the problem is gone, of course i dont get thumbnails but i wasnt bothered about them either.

Im sorry to have wasted your time :(

[vmrsss]

Hi Mosu,

True. I don't know why rake isn't working on Mac OS the way it is on Linux. I can only test it on Linux and Windows as I don't have (shell) access to a Mac. So you should stick with the 4.2.0 release for the time being.

Can you pls check your rakefiles, configure and options? I have noticed that even if I disable precompiled headers,


./src/common/common_pch.h.gch

is generated all the same, and the compilation breaks immediately there (because the file is included twice).

There is a problem with ./configure, but that's not the only thing, precompiled headers are still active even if I edit config.h to remove the line #define USE_PRECOMPILED_HEADERS 1

Thanks a lot for your help.

[Mosu]

You're right: --disable-precompiled-headers was not doing what it was supposed to do. Bug in my configure script; fixed in Git. So please 'git pull', run './autogen.sh' followed by './configure --disable-precompiled-headers'. Afterwards you should also 'rake clean' and 'rm -rf rake.d/dependency.d'. Afterwards rake should not build common_pch.h.gch anymore.

There is a problem with ./configure, but that's not the only thing, precompiled headers are still active even if I edit config.h to remove the line

config.h does not control the build process, only the compilation. 'build-config' controls the build process.

[vmrsss]

You're right: --disable-precompiled-headers was not doing what it was supposed to do.

It works now, I was able to build 'No Talking'. Happy again. :)

Thx a lot for your work, mkvmerge is a great tool

[jasonwc]

It's a bug in the DivX thumbnailer creator thats installed with the DivX codecs. I checked through the registry to see what ShellEx were being used for MKV files in explorer and found it, i uninstalled the DivX package and the problem is gone, of course i dont get thumbnails but i wasnt bothered about them either.

Im sorry to have wasted your time :(

I can confirm this behavior. Any file with H.264 header compression causes the DivX Explorer filter to crash Explorer on my system as soon as the file is selected. Remuxing with 4.1.1 fixed the issue.

[Ritsuka]

Is there any real gain in header compression (by real meaning at least 1% of the size of an original file).
Because it seems to be a quite useless and problematic thing.

[happ]

Files (x264 video, AC3 or DTS audio) muxed with 4.2.0 cause WD Live TV to stuck. Restarting system (cut of and on power circuit) and remuxing with an earlier version of mkvtoolnix fixed the issue. I can confirm Explorer crash caused with DivX explorer filter, too.

[Brazil2]

Is there any real gain in header compression
Almost none, it's a matter of few kBs for GBs large files.

Because it seems to be a quite useless and problematic thing.
Yes it is. That's why many and more and more people don't understand why it's enabled by default.
There are actually more cons than pros for this useless and annoying feature.

[Brazil2]

Files (x264 video, AC3 or DTS audio) muxed with 4.2.0 cause WD Live TV to stuck. Restarting system (cut of and on power circuit) and remuxing with an earlier version of mkvtoolnix fixed the issue. I can confirm Explorer crash caused with DivX explorer filter, too.
http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression
and
http://forum.doom9.org/showthread.php?t=155976

[sneaker_ger]

Why is the Playstation 3 on that list if it does not even support Matroska to begin with? If some streaming softwares can't handle it, they should be listed.

[Mosu]

Because someone mentioned it to me, and I have no clue about what the PS3 supports in the first place :)

[sneaker_ger]

I also tried MPC from 2006: no problems with H.264+AC3. I think that you probably mixed it up with the "default values" issue.

/edit: newer mplayer versions also seem to work for me (at least the builds from here (http://oss.netfarm.it/mplayer-win32.php))

[jasonwc]

eac3to 3.2.3 has been updated to support demuxing MKVs with header compression enabled.

Unfortunately, I don't think we'll see a fix for the DivX explorer integration dll.

[dejong12]

If I try to append subs, mkvmerge crashes with error 3. What's the problem?

[Mosu]

Details, please.

[dejong12]

Details, please.
PM'ed you.

[Snowknight26]

Any chance of adding *.eac3 to the list of all supported media types when opening files? And how about setting the default window location of the muxing progress form to the center of the parent?

[Mosu]

Probably to the former, no to the latter (I'm not opposed to it, but you know, lack of time etc).

[Tomir]

4.2.0 isn't outputting ASS files for me. Using latest aegi but don't think that matters anything.

[Mosu]

4.2.0 isn't outputting ASS files for me. Using latest aegi but don't think that matters anything.

Quoting myself in this case:

Use the search function: http://forum.doom9.org/showthread.php?p=1421587#post1421587

[heldchen]

i understand there were some discussions already regarding the use of "und" vs "eng". my issue with this is a bit different, i think: if i specificially instruct mkvmerge to set a track language to "eng", i kinda expect it to do so - instead, the track is added as "und", and i have to change this manually to "eng" using the header editor.

while i have no problem with mkvmerge using "und" when no language is specified for a track, i do not understand its current behaviour...

[Mosu]

i understand there were some discussions already regarding the use of "und" vs "eng". my issue with this is a bit different, i think: if i specificially instruct mkvmerge to set a track language to "eng", i kinda expect it to do so - instead, the track is added as "und", and i have to change this manually to "eng" using the header editor.

No, that's not what happens. The program you use for playback/information simply does not support default values. Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values for an explanation.

[heldchen]

i understand that the default value (i.e. an *unset* value) should be considered english, and i'm fine with that. but i actually do set a value, which means i do not want to use a/the default value. whether the value i set is "ger", "eng", "und" or anything else shouldn't matter to mkvmerge, as i specifically instruct it to use it.

right now mkvmerge sees "eng" as the value and thinks "oh, 'eng' is set, so he probably doesn't want a value, i'll just leave it unset" which is wrong. and following this logic, the mmg header editor also would have to do the "eng" -> unset tranform, which it doesnt.

[Mosu]

right now mkvmerge sees "eng" as the value and thinks "oh, 'eng' is set, so he probably doesn't want a value, i'll just leave it unset" which is wrong.

No, it isn't. Semantically it's exactly the same. A player has to treat both cases as identical (element present & set to 'eng' vs. element not present at all). Due to technical reasons I will not change this behaviour (it's related to WebM files amongst other things).

Also mmg's settings are not 'enforce this' kind of settings. Neither mmg nor mkvmerge is designed that way.

and following this logic, the mmg header editor also would have to do the "eng" -> unset tranform, which it doesnt.

No, the header editor is in fact an enforcing thingy, unlike mmg. Think of it as as editing header values directly in the file and of mmg+mkvmerge as the 'filtering' version.

[heldchen]

oh well. it would just need another language entry like "eng (enforced)" which wouldn't break anything, but i guess that's not going to happen so i'll just continue to set the languages with the header editor...

[loekf]

Yes it is. That's why many and more and more people don't understand why it's enabled by default.
There are actually more cons than pros for this useless and annoying feature.

+1

I only found out about this after I got some movies, which resulted in no audio on my mediaplayer.

I have no problems making the implementation of a standard feature complete, but make it an option, switch if off by default.

[Mosu]

It has been switched off for the past four years. Still a lot of players/demuxers did not implement support for it. No, I'm not willing to reconsider or argue about it.

[Zenitram]

if i specificially instruct mkvmerge to set a track language to "eng", i kinda expect it to do so

...and mkvmerge does what you want: it sets the track language to "eng", ie it removes the track language from the file, because the specification says "no track language = eng".

while i have no problem with mkvmerge using "und" when no language is specified for a track, i do not understand its current behaviour...

It is conform to specs: eng is the default value if there is no track language. mkvmerge is conform to specifications.
I don't like this default value (default value should be "und"! why English?), but this is not mkvmerge fault, this is Matroska fault, you should blame Matroska for this. And you should blame other developpers not conforming to specifications.

It has been switched off for the past four years. Still a lot of players/demuxers did not implement support for it. No, I'm not willing to reconsider or argue about it.

And I am happy with this! This is a good demo for showing the flaw of my coding vs specifications! We were a lot not reading enough specifications (mainly the default values), this is a good motivation to change this.

[Daemon404]

Sorry if this has been posted/asked already, but I noticed mkvinfo no longer outputs attachment info from files created by newer versions mkvmerge (how new im not sure). Older files (I tested one created 2.9.8) display them file in mkvinfo.

[Mosu]

See http://forum.doom9.org/showthread.php?p=1425081#post1425081

Also note that mkvinfo's normal mode (without any "-v" or "--verbose") stops parsing when it encounters the first cluster. From your question I guess that what you really need is "mkvmerge --identify-verbose yourfile.mkv" instead of mkvinfo.

[Daemon404]

See http://forum.doom9.org/showthread.php?p=1425081#post1425081

Also note that mkvinfo's normal mode (without any "-v" or "--verbose") stops parsing when it encounters the first cluster. From your question I guess that what you really need is "mkvmerge --identify-verbose yourfile.mkv" instead of mkvinfo.

I've been using mvkmerge to do that for ages, but I just wondered why mkvinfo stopped displaying 'em.

[jasonwc]

It's a bug in the DivX thumbnailer creator thats installed with the DivX codecs. I checked through the registry to see what ShellEx were being used for MKV files in explorer and found it, i uninstalled the DivX package and the problem is gone, of course i dont get thumbnails but i wasnt bothered about them either.

Im sorry to have wasted your time :(

I reported this issue to Divx on their support page and a ticket has been opened. Let's see if a fix is forthcoming. Unfortunately, DivX is the only provider of a Mediafoundation filter for Windows 7. Without their filter, there is no way to get thumbnail support and other basic media attributes (e.g. duration, bitrate) to display in Windows Explorer.

[SamuriHL]

I reported this issue to Divx on their support page and a ticket has been opened. Let's see if a fix is forthcoming. Unfortunately, DivX is the only provider of a Mediafoundation filter for Windows 7. Without their filter, there is no way to get thumbnail support and other basic media attributes (e.g. duration, bitrate) to display in Windows Explorer.

Good luck with that. It's been an issue for years and they've never seen fit to fix it.

[jasonwc]

Good luck with that. It's been an issue for years and they've never seen fit to fix it.

Years? The problem appears to be the thumbnail generator breaking due to AVC header compression which wasn't used until MKVMerge 4.2.0. Even if it was in the spec, they had no reason to implement it before.

[SamuriHL]

Years? The problem appears to be the thumbnail generator breaking due to AVC header compression which wasn't used until MKVMerge 4.2.0. Even if it was in the spec, they had no reason to implement it before.

Not that specific problem, no. But Divx has had thumbnail problems going back a LONG LONG time. There are numerous threads all over the Net about explorer crashing when divx is installed and you look at a folder of avi's or (now) mkv's with thumbnails turned on. They've never fixed it. A few months ago in the MakeMKV forum we were discussing it and the ways to get around it. Someone reported it to them and got an awesome response back from them about it. Complete silence. :)

[stax76]

I reported this issue to Divx on their support page and a ticket has been opened. Let's see if a fix is forthcoming. Unfortunately, DivX is the only provider of a Mediafoundation filter for Windows 7. Without their filter, there is no way to get thumbnail support and other basic media attributes (e.g. duration, bitrate) to display in Windows Explorer.

As far as I know the MS thumbnail component is DirectShow based and can be enabled for every file type, IIRC user CLSID posted about this long time ago.

[AzraelNewtype]

There's a bug in v4.2.0 that results in tracks from SSA/ASS files not being copied into the output file if you use mmg. This has been fixed in the following build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.2.0-build20100729-293-setup.exe


Would it be possible to release a new minor version bump (4.2.1?) for this build? My primary OS isn't Windows, and while I could circumvent my package manager and build from git by hand, it seems a little silly to do so in order to use an official bugfix rather than third party patch. I've had to downgrade all the way back to 3.4.0 to attach subtitles, as 4.1.1 (the only version in the middle still available in the manager) had a different bug that neither 4.2.0 nor 3.4.0 was exhibiting. Even on Windows it would probably cut down on the number of people coming in to ask about this already fixed bug anyway.

[Mosu]

As each release requires roughly six hours to compile everything with two hours of continuous work I don't release too often. mkvtoolnix is already on a rather active release schedule (four to six weeks between releases). That being said -- I was planning on releasing this or weekend or the weekend after anyway.

[Mosu]

Btw, compiling from Git into a package installable with your package manager is pretty easy, at least for Debian, Ubuntu, OpenSuSE and Fedora as I provide the build files for those distributions in the source tarball/Git repo.

[AzraelNewtype]

Oh, okay then. I'm perfectly comfortable compiling from source actually, it's just that when you manually inject files like that, portage (gentoo user) freaks out next time you attempt to install from the official sources again due to finding files it isn't expecting. The feature exists to keep your system sane/stable, but can drive you crazy if you try dancing around it.

I'll try actually doing the right thing then in that case in the interim and modify the official ebuild to grab git instead of the tarball.

Thanks.

[jasonwc]

Not that specific problem, no. But Divx has had thumbnail problems going back a LONG LONG time. There are numerous threads all over the Net about explorer crashing when divx is installed and you look at a folder of avi's or (now) mkv's with thumbnails turned on. They've never fixed it. A few months ago in the MakeMKV forum we were discussing it and the ways to get around it. Someone reported it to them and got an awesome response back from them about it. Complete silence. :)

There actually is a "fix" for the earlier AVI issues. The response I got from DivX told me to install it. It appears to disable thumbnail generation for AVI, so it doesn't fix the MKV crashes.

See http://support.divx.com/faq/view/supportFAQen001/The-DivX-All-In-One-Fix-V181

Explorer Crash When Opening a Folder

When opening a folder containing DivX or XviD .Avi files under some specific configurations, the thumbnail generation crash Windows Explorer. This option Disable the Thumbnail generation.

[jasonwc]

I reported this issue to Divx on their support page and a ticket has been opened. Let's see if a fix is forthcoming. Unfortunately, DivX is the only provider of a Mediafoundation filter for Windows 7. Without their filter, there is no way to get thumbnail support and other basic media attributes (e.g. duration, bitrate) to display in Windows Explorer.

There is actually a really easy "fix" for the Explorer crashing. It disables thumbnail generation for MKVs but all the other metadata works, which is why I installed the Media Foundation filter.

Go to the the folder:
C:\Program Files\DivX\DivX Plus Media Foundation Components

You need to rename one DLL:

DivXThumbnailProvider.dll

After that, MKV thumbnail generation will no longer work, but explorer won't crash either. :P

[SamuriHL]

There actually is a "fix" for the earlier AVI issues. The response I got from DivX told me to install it. It appears to disable thumbnail generation for AVI, so it doesn't fix the MKV crashes.

See http://support.divx.com/faq/view/supportFAQen001/The-DivX-All-In-One-Fix-V181

Explorer Crash When Opening a Folder

When opening a folder containing DivX or XviD .Avi files under some specific configurations, the thumbnail generation crash Windows Explorer. This option Disable the Thumbnail generation.

Fascinating. They should do the same for MKV's. Thanks for the info!

[SamuriHL]

There is actually a really easy "fix" for the Explorer crashing. It disables thumbnail generation for MKVs but all the other metadata works, which is why I installed the Media Foundation filter.

Go to the the folder:
C:\Program Files\DivX\DivX Plus Media Foundation Components

You need to rename one DLL:

DivXThumbnailProvider.dll

After that, MKV thumbnail generation will no longer work, but explorer won't crash either. :P

Right, that's the work around I saw on MakeMKV forum. I've still not had a chance to try it myself yet.

[jasonwc]

Right, that's the work around I saw on MakeMKV forum. I've still not had a chance to try it myself yet.

The MakeMKV forum also said to disable "DivXPropertyHandler.dll" which is responsible for providing all metadata for MKV files. However, the problem seems solely related to the DLL responsible for thumbnail creation. This way, I'm still able to get duration, bitrate and other metadata within Explorer, without the crashes.

I contacted Divx support and told them that disabling "DivXThumbnailProvider.dll" fixed the issue. Perhaps they'll add that to the compilation of fixes, or you know, fix the underlying problem.

[AzraelNewtype]

On the off chance anybody here is using Gentoo and wants to cleanly update to the git version while we wait on an official new tarball, I edited up an ebuild for it here: http://pastebin.com/FKHU9JsD. I suggest deactivating the qt4 USE flag, since I know at least it wasn't building for me. Could be an isolated thing.

Mosu, I may have missed this, but are you sticking with rake for future versions, or will that just be the build system you're using for git trunk builds for the time being? I ask because moving from make to rake was by far the biggest cause for change in the ebuild, and if the next release is using it, the maintainers will have to make the same changes for the official ebuilds that I did, in which case trying to get this one into the main repo will be much more important.

[Mosu]

rake is the new build system. The README & ChangeLog make that very clear. The 'biggest change' you mentioned is rather small (I speak from the experience of adjusting the Debian, OpenSuSE and Fedora Core build files): add Ruby (you don't even have to add Rake itself 'cause mkvtoolnix includes its own version) to the dependencies and call './drake' instead of 'make'. Maybe adjust the name of one or two targets if the installation step is split into multiple calls instead of a simple './drake install'.

I don't really support Qt4 at the moment. I will fix build issues eventually, but it doesn't have a high priority for me.

[MeridiusUK]

hi i was just wanting some help is there anything to get tsmuxer to work with the new compressed file headers as at teh min i have to run it using mkvtoolnix 4.2.0 and turn it off and then use tsmuxer to get it into m2ts format. wanted to avoid doing this twice.

any help on that if poss

oh another question in mkvtoolnix 4.2.0 I know you nee to just turn off the compression on the audio and video but do you also need to do this on the subtitles to ? as chapters has it grayd out.



thanks

[Mosu]

oh another question in mkvtoolnix 4.2.0 I know you nee to just turn off the compression on the audio and video but do you also need to do this on the subtitles to ?

No. Subtitles have always been compressed with ZLIB in Matroska. Either a player supports subtitles with compression, or it doesn't support subtitles at all (neither with nor without compression).

as chapters has it grayd out.

Chapters and tags cannot be compressed at all. Therefore it's grayed out.

[MeridiusUK]

No. Subtitles have always been compressed with ZLIB in Matroska. Either a player supports subtitles with compression, or it doesn't support subtitles at all (neither with nor without compression).



Chapters and tags cannot be compressed at all. Therefore it's grayed out.

so is it best just to leave the subtitles option blank or do i need to select zlib as in your program its option is blank or does the blank mean it defaults to zlib ? and just select compresion none for audio and video when i remux the files ?

cheers

[AzraelNewtype]

The 'biggest change' you mentioned is rather small (I speak from the experience of adjusting the Debian, OpenSuSE and Fedora Core build files): add Ruby (you don't even have to add Rake itself 'cause mkvtoolnix includes its own version) to the dependencies and call './drake' instead of 'make'.

That isn't how ebuilds tend to work, as they tend to abstract out direct calls to make entirely, but nobody has ever bothered to set up a similar system for using rake, and certainly not for the builder being in the working directory. Don't get me wrong, it's not particularly hard considering at their base ebuilds are essentially gussied up bash scripts, it's just not conforming to the usual style at all. That said, I should actually edit my dependency list and call the local version accordingly in that case, since it's there.

I don't really support Qt4 at the moment. I will fix build issues eventually, but it doesn't have a high priority for me.

Yeah, that's fine. I prefer it since wx is GTK widget backed on linux and I run KDE, but this is honestly so trivial that I wouldn't even mind you yanking the whole damn thing instead of bothering to fix it.

[Mosu]

You know that only mkvinfo has a Qt GUI, right? mmg is wxWidgets only.

[AzraelNewtype]

Actually, I didn't. I care even less about the feature then, so it really deserves to be super low priority.

[MeridiusUK]

hi i was just wanting some help is there anything to get tsmuxer to work with the new compressed file headers as at teh min i have to run it using mkvtoolnix 4.2.0 and turn it off and then use tsmuxer to get it into m2ts format. wanted to avoid doing this twice.

any help on that if poss

oh another question in mkvtoolnix 4.2.0 I know you nee to just turn off the compression on the audio and video but do you also need to do this on the subtitles to ? as chapters has it grayd out.



thanks

any help on this last post ?

[sneaker_ger]

tsmuxer does not support it and there is no trick to make it work. Seems to be as simple as that.

[MeridiusUK]

Cheers.

so is it best just to leave the subtitles option blank or do i need to select zlib as in your program its option is blank or does the blank mean it defaults to zlib ? and just select compresion none for audio and video when i remux the files ?

[sneaker_ger]

You can leave it blank for subtitles because the default is and always has been compression = on for subtitles.

[onlym3]

Is there a way to set the header compression to "none" by default? I have a player with Realtek chipset and currently they don't work with header compressed video and who knows how long it takes them to fix it, if ever, so for every file i mux i have to set it to none. Would make my life a lot easier if i could set it to none by default.

Thanks

[SamuriHL]

Search this thread. Mosu has said he will not change that many times now. You will have to remember to set it manually each time. He's against setting it by default because he wants players to follow the FULL MKV standard. Whether you agree or disagree, if you search, you'll see Mosu believes this very strongly and absolutely won't change his mind. :)

[onlym3]

Search this thread. Mosu has said he will not change that many times now. You will have to remember to set it manually each time. He's against setting it by default because he wants players to follow the FULL MKV standard. Whether you agree or disagree, if you search, you'll see Mosu believes this very strongly and absolutely won't change his mind. :)Yeah well, and in the mean time there are a lot of players that don't play files because one man is trying to force an industry his way. The reality is that it's not worth it, on a 4 GB file you save less than 150 KB with the header compression, that is really peanuts compared to all the problems it causes so a little flexibility instead of a fight against windmills would help a lot.

[SamuriHL]

Yeah well, and in the mean time there are a lot of players that don't play files because one man is trying to force an industry his way. The reality is that it's not worth it, on a 4 GB file you save less than 150 KB with the header compression, that is really peanuts compared to all the problems it causes so a little flexibility instead of a fight against windmills would help a lot.

I wasn't making a judgement on the decision either way...simply an observation that this argument has been tried before and was unable to persuade Mosu to change his stance. I do get the frustration, but, at the end of the day, remember who's project it is. :) We may or may not like the decision he made, but, it's without a doubt his decision to make as the developer.

[Superb]

@onlym3: "his way"? header compression is in the mkv specification. I'm glad Mosu set it as default. It forces hardware manufactures to find bugs in their implementation and release a firmware updates.

[onlym3]

@onlym3: "his way"? header compression is in the mkv specification. I'm glad Mosu set it as default. It forces hardware manufactures to find bugs in their implementation and release a firmware updates.And it frustrates a lot of people who can't watch mkvs anymore without having to remux. It doesn't matter that hardware manufacturers didn't implement properly, the fact is, at the moment the easiest solution would be to at least allow people to disable compression by default. And let's not forget what kind of compression saving we are taking about, there isn't any significant saving, on GB sized files you save KB. 100 KB saving is worth so much trouble?

[Brazil2]

"his way"? header compression is in the mkv specification.
The specs don't say that this feature MUST be enabled but that it MAY be enabled. It's the user's choice. See the difference ?
So yes, Mosu has decided by his own to force us to use this useless feature by default and there is actually no way to save the default settings we want to use with mkvmerge/mmg so we have to do dozens of clicks each time we want to make an MKV without this feature.

It forces hardware manufactures to find bugs in their implementation and release a firmware updates.
Really ? I'm still waiting for an update for WD TV that is supporting this feature. And I have the feeling it's gonna take a long time and you know why ? Because this feature is USELESS, it brings almost no gain, last time I checked I think I got a file size reduction of about 800 kB from a 25 GB file IIRC. Yes, 800 kB for 25 GB !
That's why big companies are not in a hurry to support something that gives no real advantage to anyone and that's also why this feature shouldn't be enabled by default.

[prOnorama]

Setting header compression on by default is fine by me, however not letting the end user decide to change the default on a permanent basis is not very user friendly IMO.

I forgot to switch it off last time and the mkv didn't play on my brother's WD TV (there goes the movie night, my brother lives in another city :( ) Yes my fault, but had it been just a one time setting change I would not have made this mistake.

[Brazil2]

I forgot to switch it off last time and the mkv didn't play on my brother's WD TV
Exactly and it's so annoying and frustrating -to say it in a polite way- to realize that you have forgotten ONE click for ONE track after the mux is done, which took 20-30-40 minutes depending on the movie/tracks you want to mux. And you have to do it again........

[Underground78]

Hi Mosu,

About the FAQ entry for "header removal", it is written that "Freebox (One user got a response from the manufacturer stating that one of the next firmware upgrades would add support for this feature.)", the firmware has been changed now and it does work correctly.

[Mosu]

About the FAQ entry for "header removal", it is written that "Freebox (One user got a response from the manufacturer stating that one of the next firmware upgrades would add support for this feature.)", the firmware has been changed now and it does work correctly.

Thanks, I've changed the entry accordingly.

[sneaker_ger]

Should have removed MPC and PS3 while you've been at it. Also, NMT has fixed the C-200. Fixes for the other models are probably to follow.

[Superb]

The specs don't say that this feature MUST be enabled but that it MAY be enabled. It's the user's choice. See the difference ?
So yes, Mosu has decided by his own to force us to use this useless feature by default and there is actually no way to save the default settings we want to use with mkvmerge/mmg so we have to do dozens of clicks each time we want to make an MKV without this feature.If the mkv spec says a feature MAY be enabled, then the software/hardware player MUST support it. That's the correct logic. Useless or not, that's not even relevant. The spec should be fully implemented. Any other way is a player's BUG.

Really ? I'm still waiting for an update for WD TV that is supporting this feature. And I have the feeling it's gonna take a long time and you know why ? Because this feature is USELESS, it brings almost no gain, last time I checked I think I got a file size reduction of about 800 kB from a 25 GB file IIRC. Yes, 800 kB for 25 GB !
That's why big companies are not in a hurry to support something that gives no real advantage to anyone and that's also why this feature shouldn't be enabled by default.Big companies are definitely in a hurry to support this feature. Why? Cuz not supporting it renders their player useless w/ anything encoded online (e.g. illegal downloads) using the new mkvtoolnix. They will have no choice but to fix their implementation (as more and more releases are muxed w/ this new feature). I give it a month for >75% of them to release firmware updates.

[7ekno]

Why not just mux as you have always done, then at the end of your muxing run, double click a BAT file to fix it all up (fixMKV.BAT, posted here somewhere) ;)

No chance of forgetting a click, no chance of leaving without running the BAT, takes a few extra seconds to click the BAT while you go have a coffee :P

7ek

[onlym3]

Why not just mux as you have always done, then at the end of your muxing run, double click a BAT file to fix it all up (fixMKV.BAT, posted here somewhere) ;)

No chance of forgetting a click, no chance of leaving without running the BAT, takes a few extra seconds to click the BAT while you go have a coffee :P

7ekWell there is an easier solution if you only make your own mkvs. Revert to 4.1.0, that's what i have done and if enough people ignore any version above 4.1.0 until the situation is resolved, maybe the developer realises that a little flexibility never hurt anyone.

[Pulstar]

I'm trying to mux raw VFR streams using MKVMerge to no avail. It seems when I append the video track there's no option to import the assorted timecodes.txt generated by previous app (ex. FLVExtract). Could someone kindly write me a short example MP4Box batch to mux several H.264 streams into a single MP4 with the timecodes in mind? (Yamb doesn't have this feature, it just creates multiple tracks)

[Mosu]

I'm trying to mux raw VFR streams using MKVMerge to no avail. It seems when I append the video track there's no option to import the assorted timecodes.txt generated by previous app (ex. FLVExtract).

I don't have a solution for MP4Box for you, but you could first import the raw h264 streams into one Matroska file each and then append those Matroska files. Another way (though more complicated) would be to create one huge timecode file containing all the timecodes of the segments you want to append. That timecode file can be used in mmg on the first track, and mkvmerge will use the timecodes for the appended tracks as well.

If you want to talk more about that I suggest we do that over in the mkvtoolnix support thread (http://forum.doom9.org/showthread.php?t=155732).

[73ChargerFan]

Huh? Mosu, you pointed back to this thread.

[Mosu]

I'm pretty sure the two posts were moved here from another thread, one about MP4Box.

[Mosu]

I've released mkvtoolnix v4.3.0. It contains a lot of bug fixes and a few enhancements but no major new features.

There's one change for people building from source in general and package maintainers in particular: the build system has been changed from "make" to "rake". Here's the ChangeLog entry:

* build system: The build system has been changed from "make" to "rake", the Ruby based build tool. MKVToolNix includes its own copy of it so all you need is to have Ruby itself installed. The build proecss has been tested with Ruby 1.8.6, 1.8.7 and 1.9.1. Building is pretty much the same as before: "./configure", "./drake", "sudo ./drake install". Most of the build targets have similar if not identical names, e.g. "./drake install". You can override variables just like with make, e.g. "./drake prefix=/somewhere install".

Adjusting build scripts should be easy enough. If you need any help just let me know.

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-4.3.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.3.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.3.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.2.0:

------------------------------------------------------------
2010-09-04 Moritz Bunkus <moritz@bunkus.org>
* Released v4.3.0.
* mkvmerge: bug fix: Appending tracks which would normally be compressed (e.g. with header removal compression) and turning off compression for those tracks with "--compression TID:none" (or the corresponsing option in mmg) was resulting in the second and all following appended tracks to be compressed all the same.

2010-09-01 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Errors such as 'file does not exist' did not cause mkvextract to quit. Instead it continued and exited with the result code 0.

2010-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Certain frames in certain h.264/AVC raw tracks were handled wrong, e.g. files created by x264 versions starting with revision 1665. The situation occured if an IDR slice comes immedtiately after a non-IDR slice and the IDR slice has its frame_num and pic_order_count_lsb fields set to 0.

2010-08-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Attachments will be rendered at the beginning of the file again. Fix for bug 516.

2010-08-24 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, mmg's header editor: Fixed a crash corrupting files in certain situations. If the updated header fields required filling exactly one byte with an EbmlVoid element and if the next Matroska element's "size" was already written with its maximum length (8 bytes) then the crash would occur. Such files are written by e.g. lavf. Fix for bug 536.

2010-08-17 Moritz Bunkus <moritz@bunkus.org>
* All: bug fix: Fixed a couple of format strings in translations which could cause the programs to crash.

2010-08-14 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: new feature: mkvinfo will show the h.264 profile and level for AVC/h.264 tracks along with the CodecPrivate element.

2010-08-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Video tracks with a width or height of 0 are not read from AVI files anymore. Fix for bug 538.

2010-08-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an error with losing packets (error message "packet queue not empty") when reading IVF (VP8) files using --default-duration on it.
* mkvmerge: bug fix: Fixed access to uninitialized memory in the MPEG-2 ES parser.

2010-08-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The 'total remaining time' shown by the job manager was totally wrong. Fix for bug 529.

2010-08-01 Moritz Bunkus <moritz@bunkus.org>
* build system: The build system has been changed from "make" to "rake", the Ruby based build tool. MKVToolNix includes its own copy of it so all you need is to have Ruby itself installed. The build proecss has been tested with Ruby 1.8.6, 1.8.7 and 1.9.1. Building is pretty much the same as before: "./configure", "./drake", "sudo ./drake install". Most of the build targets have similar if not identical names, e.g. "./drake install". You can override variables just like with make, e.g. "./drake prefix=/somewhere install".

2010-07-30 Moritz Bunkus <moritz@bunkus.org>
* mmg header editor: bug fix: If a file was loaded that did not contain 'track language' elements and those elements were unchanged then they would be set to 'und' upon saving. Now they're left as-is, and when adding them to the file the drop-down box defaults to 'eng' being selected as per Matroska default value specifications. Fix for bug 525.

2010-07-29 Moritz Bunkus <moritz@bunkus.org>
* mkvextract, mkvinfo, mkvpropedit: new feature: Added the option "-q" and its long version "--quiet". With "--quiet" active only warnings and errors are output. Fix for bug 527.
* mkvmerge: bug fix: The option "--quiet" was not working properly.
* mkgmerge: bug fix: mkvmerge was treating SSA/ASS subtitle files as audio files for the purpose of track selection (--no-subtitles / --no-audio). Fix for bug 526.
------------------------------------------------------------

Have fun.

[b66pak]

thanks a lot...
_

[hubblec4]

Thumps up Mosu

[Pulstar]

I'm pretty sure the two posts were moved here from another thread, one about MP4Box.

Thanks, it worked! But such a time-consuming process. :eek:

[mandarinka]

2010-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Certain frames in certain h.264/AVC raw tracks were handled wrong, e.g. files created by x264 versions starting with revision 1665. The situation occured if an IDR slice comes immedtiately after a non-IDR slice and the IDR slice has its frame_num and pic_order_count_lsb fields set to 0.


Can we have some specifics about this behavior? It sounds like that creates problems (decoding corruption, wrong timestamps?), what should one look for?

Thanks!

[Sharktooth]

corrupted output on some frames in your encodes.

[Mosu]

Can we have some specifics about this behavior? It sounds like that creates problems (decoding corruption, wrong timestamps?), what should one look for?

Thanks!

Details are in this post and that whole thread in general.

[Video Dude]

Big companies are definitely in a hurry to support this feature. Why? Cuz not supporting it renders their player useless w/ anything encoded online using the new mkvtoolnix. They will have no choice but to fix their implementation (as more and more releases are muxed w/ this new feature). I give it a month for >75% of them to release firmware updates.
Or they could drop MKV support due to user complaints of files not working.

[Superb]

Or they could drop MKV support due to user complaints of files not working.Sure, like that could happen. A 2010 media streamer which drops support for the most common format used for online (and usually illegal) HD encodes.

[Devport]

Bug : mkvmerge-gui doesn't mux video if individual tracks aren't added in a certain order.

If I have two or more tracks, e.g.

test.mp2
test.m2v

and add them all at once to mkvmerge-gui by drag and drop it will only mux the audio tracks ignoring the video track even though all tracks are shown in the ui. If I add the tracks manually in a certain order only ( it has to be 1. *.mp2, 2. *.ac3, 3. *.m2v ) mkvmerge-gui will mux all tracks correctly. Same applies if there is an additional ac3 track.

Seems to be a bug to me. Version is 4.3.0 from your ppa for Ubuntu. I don't know if that happened in previous versions but I suppose it didn't.

edit : Corrected required file order

[[)370|\|470!2]

Files (x264 video, AC3 or DTS audio) muxed with 4.2.0 cause WD Live TV to stuck.
Yet another good reason not to use mkvtoolnix. Ever.

[7ekno]

Yet another good reason not to use mkvtoolnix. Ever.

Nah, just a great way to cull those that can't read :P After all, they and those that tend to believe blatent false statements are the biggest whingers :P Win Win ...

7ek

[LeMoi]

When appending multiple mkv files with chapters, there are errors in the timestamps
http://img36.imageshack.us/img36/4677/avinaptic.jpg
Look between Chapitre n°13 and Chapitre n°1, end of first chapter is not saved correctly. That results in chapters after Chapitre n°13 not displayed during playback (they don't appear in MPC menu, using Haali Media Splitter), but seeking file from beginning to the end works fine (5h25 movie).
Is this an error from first muxed file, which should have an end timing for this chapter ?

[Mosu]

When appending multiple mkv files with chapters, there are errors in the timestamps
http://img36.imageshack.us/img36/4677/avinaptic.jpg
Look between Chapitre n°13 and Chapitre n°1, end of first chapter is not saved correctly.

In a Matroska file there are two elements that select a chapter's start end end timestamp: ChapterTimeStart and ChapterTimeEnd. The first one is mandatory, the second one isn't. If there is no ChapterTimeEnd entry for a given chapter level (in Matroska chapters can be nested) then a player must assume that the chapter ends when the next chapter on the same level starts or at the end of the chapter one level above the current chapter if the current chapter is nested.

mkvmerge will not add ChapterTimeEnd entries itself. This is not a bug.

[drob]

Is there a way to tell via mediainfo or similar utils, if header compression was applied?

[Atak_Snajpera]

http://forum.doom9.org/showthread.php?p=1420306#post1420306

[Kurtnoise]

Is there a way to tell via mediainfo, if header compression was applied?
this is already implemented into the lib in internal but not available through the interface. Maybe using it in debug mode...

[Zenitram]

this is already implemented in internal but not available through the interface. Maybe using it in debug mode...

Oh, this feature is requested...
I added it to all displays:
Video
ID : 1
Format : MPEG-4 Visual
Muxing mode : zlib
Codec ID : DX50
Codec ID/Hint : DivX 5
Duration : 8s 560ms
Width : 720 pixels
Height : 400 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0

Audio
ID : 2
Format : MPEG Audio
Muxing mode : zlib
Codec ID : A_MPEG/L3
Codec ID/Hint : MP3
Duration : 8s 568ms
Channel(s) : 2 channels
Sampling rate : 48.0 KHz

In SVN and next official version.

[SeeMoreDigital]

In SVN and next official version.Nice one :)

[LeMoi]

In a Matroska file there are two elements that select a chapter's start end end timestamp: ChapterTimeStart and ChapterTimeEnd. The first one is mandatory, the second one isn't. If there is no ChapterTimeEnd entry for a given chapter level (in Matroska chapters can be nested) then a player must assume that the chapter ends when the next chapter on the same level starts or at the end of the chapter one level above the current chapter if the current chapter is nested.

mkvmerge will not add ChapterTimeEnd entries itself. This is not a bug.

So why bothering allowing appending a file to another with chapters if chapters are not appended correctly ?

[Mosu]

Huh? They are. Why do you assume mkvmerge is wrong in this case? It is not a muxer's job to interpret the absence of ChapterTimeEnd elements correctly; it's the _player's_ job.

Let's assume you have file A has three chapters, A1 - A3. A3 does not have a ChapterTimeEnd element. Let's further assume file B has two chapters, B1 and B2. Usually B1's ChapterTimeStart element is 00:00:00 (common case when splitting at chapter boundaries). When appending B to A mkvmerge will adjust all ChapterTimeStart and ChapterTimeEnd elements for the chapters in B by the length of A. So if a player sees chapter A3 without a ChapterTimeEnd element it will also see chapter B1 starting after A3 starts and therefore use B1's start time as the end time for A3. This pretty much what the user wants and expects.

[LeMoi]

Problem is the splitter, not the player, isn't it? Haali's Media Player only displays first chapters, that have ChapterTimeEnd, not the following


EDIT: sorry I was wrong, i identified the problem: resulting file doesn't have one chapter edition with all chapters in it, but 3 editions, each one containing chapters of original file, but with final timings. If I want to access all chapters, I have to switch from an edition to another one, meaning that i'll have access for only a part of the chapters, not all. This is a muxing 'bug', isn't it? Or is it expected result?

http://img826.imageshack.us/img826/3881/mmge.jpg

[Mosu]

EDIT: sorry I was wrong, i identified the problem: resulting file doesn't have one chapter edition with all chapters in it, but 3 editions, each one containing chapters of original file, but with final timings. If I want to access all chapters, I have to switch from an edition to another one, meaning that i'll have access for only a part of the chapters, not all. This is a muxing 'bug', isn't it? Or is it expected result?

Each edition has its own UID (mandatory element). If two editions in appended files have the same UID then mkvmerge will put the chapters into a single UID in the output file. It won't merge chapters from editions with different UIDs into one edition though. So yes, this is the expected result if the UIDs are different.

[LeMoi]

So how am I supposed to make editions have same UID?

EDIT: found in chapter editor

[LeMoi]

OK, now it works fine.
So, to summarize, if I actually want to append files and have their chapters really appended correctly, I have to manually edit each original chapter edition so that they have same UID (which is not U any more?), and then append files; then it seems it works correctly.
Sorry and thanks for explanations, that was not obvious at all ^^

[Mosu]

Additional information: If you have a Matroska file containing chapters and split it with mkvmerge then the resulting files will all have editions with identical UIDs. Appending those files again will of course only create a single edition with all chapters in it.

If you create three separate files with e.g. simple chapter format files then all the editions will have different UIDs. At the moment mkvmerge (and by extension neither mmg) does not have a switch for forcing a single edition to be used when you append such files. I will add such an option in the near future though so that you don't have to edit the source files with the chapter editor before appending them.

[LeMoi]

At the moment mkvmerge (and by extension neither mmg) does not have a switch for forcing a single edition to be used when you append such files. I will add such an option in the near future though so that you don't have to edit the source files with the chapter editor before appending them.That would be really great ! Thanks in advance for this feature

[Mosu]

Here's a build that always merges chapter editions when appending Matroska files. I decided against creating a specific option to enable the behaviour. I haven't even added an option to disable it. The reason is that I don't think anyone would need the old behaviour anyway. If someone does (and has a good example/reason for it) then I'll add an option to turn it off.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.3.0-build20100919-309-setup.exe

[hubblec4]

Hi Mosu

Can you have a look to add the Subtitle.sup-format of normal DVDs?(not Bluray.sup) I have extracted the Subtitles of a DVD as SUP-files (Vobsub: VSRip doesnt work correctly for this DVDs)

hubble

[Mosu]

Not interested at the moment, sorry. My guess is that there are tools that can convert that format to something else.

[Thunderbolt8]

is there a special reason why it doesnt seem to be possible to use sings like '&' in (.xml) name tags?

[Mosu]

"&" is a special char in XML (same as in HTML). You have to use "&amp;" instead. Other special chars include "<" ("&lt;"), ">" ("&gt;") and " itself ("&quot;").

This is standard XML.

[GodofaGap]

Hi Mosu

Can you have a look to add the Subtitle.sup-format of normal DVDs?(not Bluray.sup) I have extracted the Subtitles of a DVD as SUP-files (Vobsub: VSRip doesnt work correctly for this DVDs)
Subtitlecreator can convert sup to idx/sub.

http://sourceforge.net/projects/subtitlecreator/files/

(download the Setup_SubtitleCreator_v2_3rc1.exe file)

[stax76]

@hubblec4

When things fail you can always fix things with ProjectX or better rip with MakeMKV, probably best ripping method anyway.

[LeMoi]

Here's a build that always merges chapter editions when appending Matroska files. I decided against creating a specific option to enable the behaviour. I haven't even added an option to disable it. The reason is that I don't think anyone would need the old behaviour anyway. If someone does (and has a good example/reason for it) then I'll add an option to turn it off.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.3.0-build20100919-309-setup.exe
Works fine, thanks again !

[madshi]

@Mosu, I've a very small problem with the header compression thingy. Generally, it works fine. However, due to how the processing classes are structured in my software (e.g. eac3to), every time header compression is used, I have to reallocate every video and audio frame twice (can't change that). So my wish is this: Could you disable header compression by default for video tracks, if the savings is <= 1 byte? If the savings is 2 byte or more, fine. But with 1 byte savings for video tracks, the size gain is really incredibly small, and not worth the processing performance penalty - for me at least. The situation is a little different for audio tracks, because there the frames are much smaller, so the space saving (in percent) is bigger and the reallocation + memory MOV less costly.

Anyway, this is just a little wish, I can live with the status quo.

[Mosu]

One of the reasons I don't change the default option is that I refuse to make mkvmerge pay attention to each and every other Matroska processor out there. That would be a losing battle, and mkvmerge would always only cater to the least common denominator. Your program has a problem with feature X. That other program has a problem with feature Y. And yet another device doesn't like Z. Maybe what they don't like even contradicts itself. So my choice is to make the specs the thing I base mkvmerge's defaults and output on. Because ultimately that's the only sane thing to do.

It boils down to, you guessed it already: sorry, but no.

[madshi]

Ok with me. My software works just fine with mkvtoolnix as it is.

I was just saying that IMHO 1 byte savings per video frame is not worth the added complication (and CPU penalty) of header compression. Using header compression just because you *can* use it is IMHO a doubtful concept. I think a feature which makes things more complicated and processing intense should only be used if it's really worth it. The specs don't say you *should* use header compression, they just say that you can. The specs allow you to do a lot of funny things that don't always make sense, but that doesn't mean you should actually use every one of these things all the time. But that's just my personal opinion, of course. I understand that your opinion is different.

[MrVideo]

The specs don't say you *should* use header compression, they just say that you can. The specs allow you to do a lot of funny things that don't always make sense, but that doesn't mean you should actually use every one of these things all the time. But that's just my personal opinion, of course. I understand that your opinion is different.

Your opinion regarding the compression is felt by a lot of users, developers, etc. You are absolutely correct, just because the spec supports header compression, and because the spec does not say that header compression must be used, is no reason to use it and force everyone out there to find out that they don't support it.

Personal Opinion Mode = ON

To me, that is being a little arrogant. It is up to the owners of the specification to decide if they'll force the issue. It seems that they haven't, yet Mosu is. To add insult to injury, he refuses to add a configurable option that allows the ability to have it on, or off, by default. Instead, those using the GUI must make a few menu selections to kill the compression for each and every job being done. It is easily forgotten. Then the job must be redone. This has frustrated many a user.

Yes, Mosu have the right to do whatever he wants with his program. There is no denying that fact. But, I think that consideration should be given to the community at large. Why now, after all this time. And, as you point out, there is no savings in either the file size or required processing power.

Personal Opinion Mode = OFF

I'll go back under my rock now.

[burfadel]

Is there any reason why the the latest download build at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ is lower than the previous build, having the same build number as the one two builds before it?
mkvtoolnix-unicode-4.3.0-build20100919-307-setup.exe
mkvtoolnix-unicode-4.3.0-build20100919-307.7z
mkvtoolnix-unicode-4.3.0-build20100919-309-setup.exe
mkvtoolnix-unicode-4.3.0-build20100919-309.7z
mkvtoolnix-unicode-4.3.0-build20100928-307-setup.exe
mkvtoolnix-unicode-4.3.0-build20100928-307.7z

[Mosu]

Server crash on my build server. I had to restore from backups, and it looks like there have been builds since that backup was made. I'll increment the file manually and create a new build so that there's no confusion.

[Mosu]

Done. The newest build has number 311: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

[mmiii]

Hi,

sorry I´m new on this.
I´ve merged two MKV which had thubnails in W7 explorer.
After the merge the mkv file has lost the preview thumbnail.

Any ideas to solve the problem.
I´m using 4.3.0

Thanks

[Superb]

Hi,

sorry I´m new on this.
I´ve merged two MKV which had thubnails in W7 explorer.
After the merge the mkv file has lost the preview thumbnail.

Any ideas to solve the problem.
I´m using 4.3.0

ThanksYou probably see thumbnails because you have DivX installed.
AFAIK, the DivX thumbnail source doesn't support streams compression, so that might be the issue.
Simply remux w/ the compression off.

[mmiii]

Hi,
:thanks:for the help.
I'm embarrassed :o but I do not know where I can set this.
Do I need to activate this already when I create the MKV (h264/AVC with Super (C)?
Or can I disable the compression at mkvmerge?

Thanks

mmiii

[mmiii]

ok, I found the compression flag, if I activate the Video Stream.
But patently I have to select it individually for each stream. Is there a chance to set it globaly ?
Thumbnail is shown :-)

mmiii

[73ChargerFan]

:( Sorry, no

[MrVideo]

Is there a chance to set it globaly?

As indicated, the answer is no. The logic behind Mosu's reasoning has baffled many.

Go back through the postings to try to get a handle on the situation.

[|nvari]

@Mosu - is there a way to add an Intro before the movie (like a DVD) or a watermark ?

thanx

[asarian]

If I were to split a movie in, say, 5 minutes chunks, and then were to have mkvmerge splice them all back together again, would I get a properly timed, seamless movie again? As in exactly timed correctly. Or would there be small time gaps from breaking up at time boundaries?

I'm a bit unclear as to where precisely the cut-off points are; at the end of a GOP? Or just at the exact time-index (which would likely break parts off somewhere in limbo). I'm in need of a precision splitting/splicing tool; hence my question. Thanks.

[LeMoi]

For the first question, i would say. You won't see gaps or anything else, playback will be fluid.
For the second question, i'll send you to the documentation files in mkvtoolnix folder ;)

[sneaker_ger]

It will only cut off full GOPs. The timings can get changed - though I'm not sure if this is intended. Maybe Mosu can elaborate on this?

[asarian]

For the first question, i would say. You won't see gaps or anything else, playback will be fluid.
For the second question, i'll send you to the documentation files in mkvtoolnix folder ;)

I read the documentation, of course. Yet I saw/see nothing in there pertaining to my question. The closest is a line that says:

"For the time: The format is either HH:MM:SS.nnn with up to nine digits for up to nanosecond precision or a number followed by the letter 's' indicating a number of seconds."

It still doesn't mention cut-off points (or GOPs, for that matter). Though I probably wouldn't miss 20 miliseconds or so in terms of audio-sync (when using a 2 hour movie split over 5 minute segments), still, I'd like to be sure.

[sneaker_ger]

I read the documentation, of course. Yet I saw/see nothing in there pertaining to my question. The closest is a line that says:

"For the time: The format is either HH:MM:SS.nnn with up to nine digits for up to nanosecond precision or a number followed by the letter 's' indicating a number of seconds."

It still doesn't mention cut-off points (or GOPs, for that matter).Splits the output file after a given size or a given time. Please note that tracks can only be split right before a key frame. Due to buffering mkvmerge(1) will split right before the next key frame after the split point has been reached. Therefore the split point may be a bit off from what the user has specified.


---

Though I probably wouldn't miss 20 miliseconds or so in terms of audio-sync (when using a 2 hour movie split over 5 minute segments), still, I'd like to be sure.

If you don't notice any desync in the last segment you won't notice any desync in the spliced file. But the timings will not be exactly the same as in original file. Better to avoid this altogether. You may be able to reduce the timing differences to a minimum by using the "track" appending mode. (see doc)

[asarian]

---

Splits the output file after a given size or a given time. Please note that tracks can only be split right before a key frame. Due to buffering mkvmerge(1) will split right before the next key frame after the split point has been reached. Therefore the split point may be a bit off from what the user has specified.


This is actually a good thing, in my case. I want to be able to rejoin parts later; and I don't care whether they're exactly X minutes: I just want the individual parts not to lose information.

So, from what you're telling me, seems a rejoin should be pretty lossless, at least; and timeable to at least 1 ms.

Thanks.

[sneaker_ger]

Mkvmerge won't throw any frames away, if you mean that. The spliced file will have just as many frames as the original file. The timing differences can be bigger than 1 ms depending on the file and the appending mode. But you will probably not note any difference.

[Chumbo]

@Mosu,
Has anything been done about this issue from the old thread? It's still an issue. By the way, MKVs created by MakeMKV don't have this issue. Thanks.

Remuxing telecined material (Tried NTSC telecined MPEG2 from DVD) doesn't seem to work anymore with 3.3.0... video speed is not in sync. Tried specifying fps (24/1.001 and 30/1.001) but doesn't work.

I've forwarded the problem to the person who contributed the new MPEG timecode calculation method. I hope he can shed some light on this problem.

[Mosu]

Not that I know of, sorry.

[Chumbo]

Not that I know of, sorry.
Any chance you can touch base with that person again to see if they have the time to fix it please? Thank you.

[Lincoln Burrows]

There seems to be an issue some people have with MKV files not playing in a stand alone Blu-Ray player.

I was having this issue myself, some files would play some would not. It turns out that the problem I was having was with the MKV's header. It seems that the newest version of MKVToolnix compressed the headers for all the streams (video,audio etc.) by default and some players can not read these. Previous versions of MKVToolnix did not do this. I searched for several days before I found the solution but when you add your files click the video stream, then click the "Extra Options" tab and where is says "Compression:" choose none.

I do this for the video, audio and subtitle streams just to make sure they will play in my player and I have not had it fail yet.

I don't want you to have a huge MKV and waste a BDR disc because your player cant play the file now.Is this really happening? I looked at the "extra options" for each stream and nothing is selected by default:

http://img217.imageshack.us/img217/6048/imagemnxu.png

There are two options if you click on that box: none and zlib.

Should we always make sure "none" is selected? If that's the case why did you changed it?

Note: I used TsMuxer to demux the contents of m2ts files (video/audio/subtitle streams) and later MkvMerge to join all those streams into a MKV.

The author of this program replied:

Hardware players are notoriously behind in supporting official features. mkvmerge uses certain features like header removal compression by default because they've been part of the specs of over half a decade now. If your player does not support header removal compression then you have to turn it off manually, yes.

[LeMoi]

Yes, if it's not specified, it means it's enabled

[nurbs]

There is no real drawback if you disable it either. The size saved by the compression is basically zero. We're talking about a couple of hundred kilobytes per video.

[Sharc]

I have to disable the 'compression' for my new WDTV as well.
It took me a while to find out why the player refused to playback the files.....

[LeMoi]

Yes, this feature is completely useless for audio tracks and just adds compatibility issues with almost every hardware player and some software players, but Mosu refuses to disable it by default or let us the choice to disable it by default...

[GodofaGap]

Well the code for the GUI is available so if you want to make an alternate GUI that has compression 'none' as default you could do that with probably only adjusting a few lines of code.

Since there are so many complaints I'm surprised no one has done this and uploaded it somewhere yet anyway.

[LeMoi]

I don't know why, maybe because it concerns common users (like me) who don't know how to modify and compile a program like this

[robpdotcom]

I just use an older version (4.1.0 I think) from before the compression feature was added. Otherwise, I kept forgetting to disable compression, and ended up making incompatible mkv's.

[Lincoln Burrows]

Is there a way to reverse this if you already generated a MKV file with this issue?

All steps: TsMuxer (to demux the original BD files/m2ts) > Mkvmerge ----> MKV (with this problem) > What's next?

If I didn't selected "None" for all streams should I start all over again (from the beginning, see above) or simply open MKvmerge and select this option for all streams and create another MKV?

[robpdotcom]

simply open MKvmerge and select this option for all streams and create another MKV?

It's been a while, but I'm pretty sure that works.

[professor_desty_nova]

Is there a way to reverse this if you already generated a MKV file with this issue?

All steps: TsMuxer (to demux the original BD files/m2ts) > Mkvmerge ----> MKV (with this problem) > What's next?

If I didn't selected "None" for all streams should I start all over again (from the beginning, see above) or simply open MKvmerge and select this option for all streams and create another MKV?

In the official Matroska page (http://www.matroska.org/) go to the download section and see MKClean. This should come with a program to make files compatible with broken players.

[Superb]

I just use an older version (4.1.0 I think) from before the compression feature was added. Otherwise, I kept forgetting to disable compression, and ended up making incompatible mkv's.But then you're missing some very important bug fixes.

Example:
2010-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Certain frames in certain h.264/AVC raw tracks were handled wrong, e.g. files created by x264 versions starting with revision 1665. The situation occured if an IDR slice comes immedtiately after a non-IDR slice and the IDR slice has its frame_num and pic_order_count_lsb fields set to 0.

[nurbs]

There is no reason to create a raw AVC track with x264 if your target is MKV. Raw output is only necessary for Blu Ray (and possibly AVCHD). If you let x264 output MKV or MP4 to begin with that bug doesn't affect you.

Personally I stopped using the GUI and use the CLI now. That way I'm less likely to forget turning compression off. Setting things up is also faster that way if I do TV series. From what I read when other programs use mkvmerge they usually also disable the compression for audio and video tracks by default so I guess many people won't notice that it was added.

[asarian]

Yes, this feature is completely useless for audio tracks and just adds compatibility issues with almost every hardware player and some software players, but Mosu refuses to disable it by default or let us the choice to disable it by default...

Basically what it boils down to, is that I have to rewrite every mkv generated by mkvtoolnix with eac3to, as tools like tsMuxeR trip over the header compression as well.

[b66pak]

@Mosu feature request:

split .mkvs in equal size when provide ONLY the max number of splits...
_

[Mosu]

Won't happen, sorry. The reason is simple: mkvmerge does not know how big the file will become. It cannot know the size of all tracks before it starts muxing, therefore it's not possible to implement something like you've requested.

[Underground78]

Hello,

Is there an easy way to cut a sample from an mkv file (by cutting only the first X MB or seconds for example) ? If the splitting mode is used, more files than needed will be created. It is probably quite easy to do so but I have found the solution yet ...

[pelle412]

Is there a thread for future feature requests? I'd like to see automatic chapter joining when two MKV files are appended and each contains their own chapters. In the current version, only the chapters in the first MKV file is kept and the chapters in the second MKV file is lost.

[Mosu]

There's no extra thread, but what you've described should already be implemented. The next release has been built already, and I just have to find the time to write all of those release messages...

See also http://forum.doom9.org/showthread.php?p=1444584#post1444584 and the preceding posts for a related discussion.

[SamuriHL]

Sweet! That'll be a nice feature to have!

[Mosu]

Hey,

I've released mkvtoolnix v4.4.0. It contains the usual mix of bug fixes and a few enhancements but no major new features.

Nothing has changed for people building from source in general and package maintainers in particular.

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-4.4.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.4.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.4.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.3.0:

------------------------------------------------------------
2010-10-31 Moritz Bunkus <moritz@bunkus.org>
* Released v4.4.0.
* build system: bug fix: Installation no longer fails if xsltproc is available but the DocBook stylesheets aren't. Fix for bug 575.
* mkvmerge: new feature: If the name of an input file starts with '=' then mkvmerge will not try to open other files with the same name (e.g. 'VTS_01_1.VOB', 'VTS_01_2.VOB', 'VTS_01_3.VOB') from the same directory. A single '=' as an argument disables this as well for the next input file. Implements bug 570.
* mmg: new feature: Added an option to disable extra compression when adding tracks by default.
* mkvmerge: bug fix: Made file type detection stricter for MP3, AC3 and AAC files. This prevents mis-detection of other file types as one of these for certain files. Fix for bug 574.

2010-10-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the usage of iterators with the STL "deque" template class. This caused mkvmerge to abort on systems which did not use the GNU implementation of the standard template library, e.g. OpenSolaris with the SunStudio compiler. Fix for bug 567.

2010-09-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The warning about subtitle entries that are skipped because their start time is greater than their end time now includes the subtitle number.

2010-09-23 Moritz Bunkus <moritz@bunkus.org>
* Build system: bug fix: 'drake install' did not work if the login shell was not POSIX compatible (e.g. fish). Fix for bug 559.

2010-09-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: When appending two Matroska files which both contain chapters the chapter entries of all editions will be merged even if the edition's UIDs were different to begin with. This is done based on the order of the edition. If both files contain three editions each then the chapters from the first edition in the second file will be put into the first edition from the first file; the chapters from the second edition into the second edition and so on.
* all: Added a translation of the programs into French by Trinine (see AUTHORS).
* mkvmerge: bug fix: The MPEG ES reader was accessing uninitialized data. This could lead to crashes or source files not being read correctly.
* mkvmerge: bug fix: Using "--no-video" on AVI files caused the video track to be mistaken for an audio track and included anyway. Fix for bug 558.
------------------------------------------------------------

Have fun.

[nurbs]

Thank you for your hard work.

[jasonwc]

* mmg: new feature: Added an option to disable extra compression when adding tracks by default.

Thanks, this feature is greatly appreciated.

[hubblec4]

* mmg: new feature: Added an option to disable extra compression when adding tracks by default.

Thanks, this feature is greatly appreciated.

yeah thats great.

[pelle412]

Great! Thanks for all the hard work :-)

[LeMoi]

yeah thats great.

+1, thanks for the effort!

[MrVideo]

Basically what it boils down to, is that I have to rewrite every mkv generated by mkvtoolnix with eac3to, as tools like tsMuxeR trip over the header compression as well.

I think you are just one of many that have been caught with their pants down over Mosu's interpretation of the specification. While he is correct that the video header compression is an option in the specification, it is just that, an option. To me, he has taken it upon himself to force everyone to support said option, even after all this time. As a result, you and many others, including player manufacturers and software programmers are being forced to deal with, what should be a non issue.

I wonder how many player manufacturers have gotten phone calls about their player no longer playing some MKV files and their not knowing why. Even if the player manufacturer does figure it and does upgrade their firmware, how many customers are going to know that they have to upgrade the firmware in their player. A lot of users have no clue about how this stuff works.

And to top it off, as mentioned many a time, not being able to set an option in the GUI to always have no compression as a default, is not being very friendly to the users. It results in many forgetting to set the option and having to either do it over, wasting time, or having to fix it via other means. Worse yet, sending off a DVD to a friend/relative and having the friend/relative complain that the DVD didn't work, then remembering that the option wasn't set.

So you aren't the only one scratching their head over this decision.

I do all of my work via scripts, so I'll be setting the option to not use compression, as will everyone else that uses the CLI.

IMHO, nothing is being accomplished with video header compression, other than lots of grief for lots of users, you being one of them.

[SamuriHL]

I think you are just one of many that have been caught with their pants down over Mosu's interpretation of the specification. While he is correct that the video header compression is an option in the specification, it is just that, an option. To me, he has taken it upon himself to force everyone to support said option, even after all this time. As a result, you and many others, including player manufacturers and software programmers are being forced to deal with, what should be a non issue.

I wonder how many player manufacturers have gotten phone calls about their player no longer playing some MKV files and their not knowing why. Even if the player manufacturer does figure it and does upgrade their firmware, how many customers are going to know that they have to upgrade the firmware in their player. A lot of users have no clue about how this stuff works.

And to top it off, as mentioned many a time, not being able to set an option in the GUI to always have no compression as a default, is not being very friendly to the users. It results in many forgetting to set the option and having to either do it over, wasting time, or having to fix it via other means. Worse yet, sending off a DVD to a friend/relative and having the friend/relative complain that the DVD didn't work, then remembering that the option wasn't set.

So you aren't the only one scratching their head over this decision.

I do all of my work via scripts, so I'll be setting the option to not use compression, as will everyone else that uses the CLI.

IMHO, nothing is being accomplished with video header compression, other than lots of grief for lots of users, you being one of them.

IMO, you should look before you leap.


* mmg: new feature: Added an option to disable extra compression when adding tracks by default.

[MrVideo]

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

I just noticed that the FAQ has an error. To wit the header is:

Why does audio or video not play anymore since v4.1.0 (e.g. MP3, AC3, DTS audio tracks, h264 video tracks)?

But the body has the following:

Starting with v4.1.0 mkvmerge uses header removal compression for a couple of track types by default. These include AC3, DTS and MP3 audio tracks as well as Dirac and MPEG-4 part 2 (aka. XviD/DivX) video tracks. The user muxing a file may disable it by explicitely selecting 'none' as the compression scheme for such a track.

The header says h.264, yet the body says MPEG-4 part 2. Those are not equal. Does the header compression deal with ALL MPEG-4 video? If so, the FAQ needs to be fixed.

It would also be nice is the FAQ listed the CLI option to disable the video header compression.

[Lincoln Burrows]

Hey guys,
as explained here (please check this thread):
http://www.makemkv.com/forum2/viewtopic.php?f=1&t=2111

Do you think there's a chance that MKVToolnix can have a feature to make MKV slideshows work?

I have tested "The Adventures of Robin Hood (1938)" Blu-ray disc and attempted to convert the slideshows (pictures) into MKV, but failed. The resulted file only plays for 1 second. The m2ts file from the BDMV/STREAM also plays for 1 second. But using TMT player from Arcsoft, which reads the entire BD folder, it plays fine, showing all pics and with 2m40s lenght.

However, BDEdit was capable of playing the m2ts file with 2m40s when I pushed "play" on the MPLS file from the PLAYLIST folder that was reffering to this content. If BDEdit can send this instruction to the M2ts file and recognize this content as "slideshow", there must be a way to fix this.

[MrVideo]

IMO, you should look before you leap.


* mmg: new feature: Added an option to disable extra compression when adding tracks by default.


That is mmg, AFAIK, it has nothing to do with mkvmerge or the GUI.

By default, the compression is still on for all of the tools. mkvmerge has an option to disable the compression (if I can find it) and so does the GUI, but you have to set it every time.

The point is that you have to kill the compression. If you forget, it might not play everywhere.

[SamuriHL]

That is mmg, AFAIK, it has nothing to do with mkvmerge or the GUI.

By default, the compression is still on for all of the tools. mkvmerge has an option to disable the compression (if I can find it) and so does the GUI, but you have to set it every time.

The point is that you have to kill the compression. If you forget, it might not play everywhere.

UM, HUH???? MMG IS the GUI! Look in the options page!!

P.S. Mosu, thanks for adding that option, btw. I know it goes against what you want and I know a lot of people will SERIOUSLY appreciate it. Thank you.

[SamuriHL]

http://img97.imageshack.us/img97/6679/mmgoptions.png (http://img97.imageshack.us/i/mmgoptions.png/)

Uploaded with ImageShack.us (http://imageshack.us)

See there? It's a great addition.

[robpdotcom]

I have to say, after going back and re-reading through Mosu's reasons for not disabling compression, I think he was correct in his stance. I also think he is correct in giving us the option to disable it by default.

The more I thought about it, the more I began to see it this way:
The mkv's created my mmg (a free program, which was created by a programmer without compensation for his work) were fully within the Matroska specs. So, if someone sells a device claiming to be mkv compatible, then that device should be compatible with any mkv which complies to the Matroska specs. In other words, the person donating his time and skills had it right, while the manufacturers making money off their products had it wrong.

However, it also became clear that these manufacturers were not going to fix their broken players, so it was us who were paying the price.

So, I definitely appreciate Mosu's willingness to bend on this issue, but I also understand (and even admire) the stance he took in trying to force the manufacturers to fix their players.

:thanks:

[SamuriHL]

I have to say, after going back and re-reading through Mosu's reasons for not disabling compression, I think he was correct in his stance. I also think he is correct in giving us the option to disable it by default.

The more I thought about it, the more I began to see it this way:
The mkv's created my mmg (a free program, which was created by a programmer without compensation for his work) were fully within the Matroska specs. So, if someone sells a device claiming to be mkv compatible, then that device should be compatible with any mkv which complies to the Matroska specs. In other words, the person donating his time and skills had it right, while the manufacturers making money off their products had it wrong.

However, it also became clear that these manufacturers were not going to fix their broken players, so it was us who were paying the price.

So, I definitely appreciate Mosu's willingness to bend on this issue, but I also understand (and even admire) the stance he took in trying to force the manufacturers to fix their players.

:thanks:

100% correct. Mosu didn't have to bend to the will of users. However, as users of his product, since he did this for us, how about we take up his cause? If you have a device that doesn't work with compression on, pressure them to fix it! I think that's fair. :)

[MrVideo]

As an author of a frontend you can safely upgrade to > 4.0.0 if you're already using 4.0.0. Just add "--compression -1:none" to all non-subtitle files.

I'm a little confused. I think this is the option I want in order to turn off video/audio header compression, but when doing --help, it is listed under:

Options that only apply to VobSub subtitle tracks

Am I missing something here?

[SamuriHL]

I'm a little confused. I think this is the option I want in order to turn off video/audio header compression, but when doing --help, it is listed under:

Options that only apply to VobSub subtitle tracks

Am I missing something here?

I think the help description is wrong. It should apply to video/audio tracks.

[MrVideo]

UM, HUH???? MMG IS the GUI! Look in the options page!!

I don't use the GUI, have never used the GUI. Thought it was started with a different name.

As such, I stand corrected about GUI users having to always remember to set the option to disable header compression. For that I apologize.

Just what was accomplished by all of this? The mkvmerge program has an option to turn off compression and now Mosu has capitulated and added an option of turn off compression within the GUI.

Will programmers and player manufacturers update their software/firmware, now that the pressure is less? For sure word has gotten out about the header issue.

[robpdotcom]

However, as users of his product, since he did this for us, how about we take up his cause? If you have a device that doesn't work with compression on, pressure them to fix it! I think that's fair. :)

Starting daily emails to WD....... now.:p

[MrVideo]

Reading the mkvmerge.html has left me more confused than ever regarding how to disable video/audio header compression.

Here is what is in the document:
Options that only apply to video tracks:

--compression TID:method

Selects the compression method to be used for the VobSub track. Note that the player also has to support this method. Valid values are 'none', 'zlib', 'lzo'/'lxo1x', 'bz2'/'bzlib' and 'mpeg4_p2'/'mpeg4p2'. [...]

Track IDs

Some of the options for mkvmerge(1) need a track ID to specify which track they should be applied to. Those track IDs are printed by the readers when demuxing the current input file, or if mkvmerge(1) is called with the --identify option. An example for such output:
$ mkvmerge -i v.mkv
File 'v.mkv': container: Matroska™
Track ID 1: video (V_MS/VFW/FOURCC, DIV3)
Track ID 2: audio (A_MPEG/L3)

Track IDs are assigned like this:

AVI files: The video track has the ID 0. The audio tracks get IDs in ascending order starting at 1.

AAC, AC3, MP3, SRT and WAV files: The one 'track' in that file gets the ID 0.

Ogg/OGM files: The track IDs are assigned in order the tracks are found in the file starting at 0.

Matroska™ files: The track's ID is the track number as reported by mkvinfo(1). It is not the track UID.

The special track ID '-1' is a wild card and applies the given switch to all tracks that are read from an input file.

Where is my confusion?

1) Only applies to video tracks? It is supposed to apply to video and audio tracks.
2) Marked in red: VobSub?
3) Track IDs in general. Zero or one, which is it? The example shows that TID1 is the video track, yet if an AVI file is used as the source, the TID is zero? If the MKV file is to have video and audio, if a separate audio file is input (AC3 for example), the TID of the audio file can't be zero. What about when the video source is an MP4 file (output from x264)?

Doesn't mkvmerge just assign the TIDs based upon the order they appear on the command line, starting at one? So, if an AVI file has one video and two audio stream, TID1 is the video, TID2 is the first audio stream and TID3 is the second audio stream. If a separate audio file is also on the command line, it would get TID4.

I get the impression that the track assignments within source files are only useful if options like -a and -d are used. If the afore mentioned AVI file, having two audio streams, only has one of the audio streams desired, the -a option would be used, i.e., -a 1 in order to only import audio stream #1. The video stream is imported by default. Within the MKV file, the video stream is referenced as TID1 and the audio as TID2.

In my case, the mkvmerge command line look like:
mkvmerge --default-language eng -o "$WINDIRNAME\ \${NAME}.mkv" -A -S "$WINDIRNAME\\${NAME}.mp4" -a 0 -D -S "$WINDIRNAME\\${NAME}.ac3" --no-clusters-in-meta-seek

Ignore the funny looking file names, as this is a cygwin Z-shell script.

If I read the document file correctly, I should be able to use the following option: --compression -1:none and have it apply to both the video and audio files. Is that considered a global option and placed before the -o option?

As a side note, if I am reading the document right, I shouldn't need the -a, -A, -D or -S options, since the MP4 doesn't have any audio and AC3 doesn't have any video and neither have subtitles.

Should my command line look like:
mkvmerge --default-language eng --compression -1:none -o "$WINDIRNAME\ \${NAME}.mkv" "$WINDIRNAME\\${NAME}.mp4" "$WINDIRNAME\\${NAME}.ac3" --no-clusters-in-meta-seek

Sorry about the confusion, but the documentation needs to be fleshed out a little more as track IDs appear to take on different meanings and the placement of some options within the command line are unclear, i.e., is --compression a global option, or must it be placed before the file being imported, and why, since it contains a track ID that points to a video or audio stream?

UPDATE: The command line shown above needed the --no-clusters-in-meta-seek removed, as that option appears to no longer be valid.

More importantly, the --compression option kinda worked, and kinda didn't. I had to use MediaInfo 0.7.36 to find out how the header compression was being applied. It showed that compression was gone from the video, but not from the audio. I read the doc to mean that a TID of -1 would apply the "none" to all of the files imported into mkvmerge. Is there not a way to do that?

I ultimately had to use the following command line:
mkvmerge --default-language eng -o "$WINDIRNAME\ \${NAME}.mkv" --compression -1:none "$WINDIRNAME\\${NAME}.mp4" --compression -1:none "$WINDIRNAME\\${NAME}.ac3"

Now I'm really confused as to how TIDs are used. I'm guessing the video -1 could be changed to 1 and the audio -1 could be changed to 0.

[MrVideo]

Isn't mkvinfo supposed to display info on header compression?

When I run mkvmerge (4.4.0) without any --compression options, mkvinfo doesn't show anywhere that zlib was used on the video or audio. So I can't tell if the use of --compression -1:none is working (no fatal errors though).

As a side note, I am using --default-language eng and mkvinfo shows the video as being und and nothing reported for the AC3 audio. Why?

[Mosu]

Reading the mkvmerge.html has left me more confused than ever regarding how to disable video/audio header compression.

Here is what is in the document:
Options that only apply to video tracks:

--compression TID:method

Selects the compression method to be used for the VobSub track.

That part of the documentation is outdated. Extra compression can be used with any track type. Historically it was only used for VobSub tracks and that's why the documentation still mentions it. That and that I haven't gotten around to fixing it. The section in which the option appears is obviously wrong as well.

3) Track IDs in general. Zero or one, which is it?

It depends on the file type. That's why the documentation suggests you run "mkvmerge -i file.ext" and parsse its output in order to retrieve the actual track IDs. This output is guaranteed to list the actual track IDs as mkvmerge uses them durng muxing as well.

Doesn't mkvmerge just assign the TIDs based upon the order they appear on the command line, starting at one?

No, more like in the order they're found in the file. "Found" meaning different things for different file types.

If I read the document file correctly, I should be able to use the following option: --compression -1:none and have it apply to both the video and audio files. Is that considered a global option and placed before the -o option?

--compression is a file specific option, not a global one. Track IDs are local to each input file (meaning there can be a track ID 1 in the first input file as well as in the second one). Therefore the magical track ID -1 only applies to all tracks in the following input file (one file, not all following input files or all input files).

As a side note, if I am reading the document right, I shouldn't need the -a, -A, -D or -S options, since the MP4 doesn't have any audio and AC3 doesn't have any video and neither have subtitles.

The default in mkvmerge is "copy everything unless told otherwise". If there's nothing to copy for certain types then you don't have to tell mkvmerge not to copy it (e.g. f the source file does not contain an audio track than neither -a nor -A is needed).

mmg works a bit differently and doesn't produce the shortest command line possible.

Sorry about the confusion, but the documentation needs to be fleshed out a little more as track IDs appear to take on different meanings and the placement of some options within the command line are unclear, i.e., is --compression a global option, or must it be placed before the file being imported, and why, since it contains a track ID that points to a video or audio stream?

Patches are welcome.

More importantly, the --compression option kinda worked, and kinda didn't. I had to use MediaInfo 0.7.36 to find out how the header compression was being applied. It showed that compression was gone from the video, but not from the audio. I read the doc to mean that a TID of -1 would apply the "none" to all of the files imported into mkvmerge. Is there not a way to do that?

See above. Track IDs are local to a single input file. All track specific options, meaning all options that take a track ID as an argument, therefore only aplly to a single file.

[Mosu]

Isn't mkvinfo supposed to display info on header compression?

When I run mkvmerge (4.4.0) without any --compression options, mkvinfo doesn't show anywhere that zlib was used on the video or audio. So I can't tell if the use of --compression -1:none is working (no fatal errors though).

As a side note, I am using --default-language eng and mkvinfo shows the video as being und and nothing reported for the AC3 audio. Why?

If compression is used then mkvinfo shows the following elements:

| + Content encodings
| + Content encoding
| + Content compression
| + Algorithm: 3 (header removal)
| + Settings: length 1, data: 0xff

If no compression is used then those elements are absent.

[tormento]

Thanks for having heard the lambs cry ;)

[sneaker_ger]

Hey guys,
as explained here (please check this thread):
http://www.makemkv.com/forum2/viewtopic.php?f=1&t=2111

Do you think there's a chance that MKVToolnix can have a feature to make MKV slideshows work?

I have tested "The Adventures of Robin Hood (1938)" Blu-ray disc and attempted to convert the slideshows (pictures) into MKV, but failed. The resulted file only plays for 1 second. The m2ts file from the BDMV/STREAM also plays for 1 second. But using TMT player from Arcsoft, which reads the entire BD folder, it plays fine, showing all pics and with 2m40s lenght.

However, BDEdit was capable of playing the m2ts file with 2m40s when I pushed "play" on the MPLS file from the PLAYLIST folder that was reffering to this content. If BDEdit can send this instruction to the M2ts file and recognize this content as "slideshow", there must be a way to fix this.

50 frames
2m 40s = 160 s
Type "50/160" into the FPS field of the video track in mkvmerge GUI.

I just noticed that the FAQ has an error. To wit the header is:

Why does audio or video not play anymore since v4.1.0 (e.g. MP3, AC3, DTS audio tracks, h264 video tracks)?

But the body has the following:

Starting with v4.1.0 mkvmerge uses header removal compression for a couple of track types by default. These include AC3, DTS and MP3 audio tracks as well as Dirac and MPEG-4 part 2 (aka. XviD/DivX) video tracks. The user muxing a file may disable it by explicitely selecting 'none' as the compression scheme for such a track.

The header says h.264, yet the body says MPEG-4 part 2. Those are not equal. Does the header compression deal with ALL MPEG-4 video? If so, the FAQ needs to be fixed.

It would also be nice is the FAQ listed the CLI option to disable the video header compression.
You are correct. By the time this part of the FAQ was written there actually was compression for part 2, but it was removed due to problems in the mean time, while h.264 was not header compressed but is now.

[SamuriHL]

I don't use the GUI, have never used the GUI. Thought it was started with a different name.

As such, I stand corrected about GUI users having to always remember to set the option to disable header compression. For that I apologize.

Just what was accomplished by all of this? The mkvmerge program has an option to turn off compression and now Mosu has capitulated and added an option of turn off compression within the GUI.

Will programmers and player manufacturers update their software/firmware, now that the pressure is less? For sure word has gotten out about the header issue.

Yea, mmg= MkvMergeGui. :) The issue of players not supporting it is now well known. And now users have the option to disable it. So, I think the point has been made, users can now disable it, and now hopefully people will press the issue with their player mfg.

[SamuriHL]

Starting daily emails to WD....... now.:p

Excellent. :) I think this is the right thing to do.

[Lincoln Burrows]

50 frames
2m 40s = 160 s
Type "50/160" into the FPS field of the video track in mkvmerge GUI.How did you come up with these numbers? I tried 50/159 and the lenght of the file was 1 minute shorter I guess. Turns out the original lenght was 4m08s. I tried 50/248 but the lenght was shorter. Those numbers do not match. I had to try some random number, but always higher than the lenght in seconds.

But the first picture from the slideshow is quickly being switched (need to rewind to the first second and pause), when it should be viewed in the first 8 seconds. The chapter list contains only 30 chapters, and watching on TMT I see 32 (and the first picture in the beginning, lasting 8 seconds). Not only that: when I generate a 4m08s MKV file, the player jumps from chapter 25 to 26 and ends, even if it's almost 30s from the end.

I inserted a new lenght (more than 4m08s) and it was possible to use all chapters, but two are simply missing from the file (I used MakeMKV to create this - don't know why, but Mkvtoolnix is not reading .MPV files demuxed by TSMuxer - from extra features).

Bottom line: why is this whole thing broken? I thought we were able to convert anything by now...

[sneaker_ger]

Well, after the makemkv admin said that those files were normal videos, and you said it had 50 frames and should play 2m40s I came up with those numbers. I just now downloaded the m2ts sample you posted (00068.m2ts) and it has 21 frames. I had no problems playing the m2ts sample using Haali's splitter - it may be a bug in MPCs internal splitter. (Which is to be replaced in the future.) The mkv sample (title06.mkv) has 32 frames with 23.976 fps - you can correct that using mkvtoolnix by changing the fps like I demonstrated in my last post.

[MrVideo]

It depends on the file type. That's why the documentation suggests you run "mkvmerge -i file.ext" and parse its output in order to retrieve the actual track IDs. This output is guaranteed to list the actual track IDs as mkvmerge uses them during muxing as well.

I think I have a better handle on the TID thing. Initially I thought the TID was in relationship to the track IDs assigned to the pieces in the final MKV file, instead they are a reference to the track, or tracks, in the input file.

--compression is a file specific option, not a global one.

Any thought of adding a global --compression?

Patches are welcome.

I'm looking at the html source and will attempt to add some changes. What I've noticed is that it wants to use styles, yet there is no stylesheet file provided with the release, nor is said stylesheet referenced in the html source in order to read it in. So, all of the stylesheet stuff it is trying to do is not done.

[MrVideo]

If compression is used then mkvinfo shows the following elements:

| + Content encodings
| + Content encoding
| + Content compression
| + Algorithm: 3 (header removal)
| + Settings: length 1, data: 0xff

If no compression is used then those elements are absent.

Ah, found it. Right in front of my eyes.

[Mosu]

I think I have a better handle on the TID thing. Initially I thought the TID was in relationship to the track IDs assigned to the pieces in the final MKV file, instead they are a reference to the track, or tracks, in the input file.

That is correct.

Any thought of adding a global --compression?

There won't be a global option that affects tracks in all input files.

I'm looking at the html source and will attempt to add some changes. What I've noticed is that it wants to use styles, yet there is no stylesheet file provided with the release, nor is said stylesheet referenced in the html source in order to read it in. So, all of the stylesheet stuff it is trying to do is not done.

The source to modify is not the HTML file but the DocBook XML file in the source package (file "doc/man/mkvmerge.xml").

[MrVideo]

The source to modify is not the HTML file but the DocBook XML file in the source package (file "doc/man/mkvmerge.xml").

I don't have the source package.

Take a look at what I did and see if that fits your needs: mkvmerge doc page (http://vidiot.com/mkvmerge.html)

The changes are in red.

Any comment on the stylesheet that appears to be nonexistant?

[Thunderbolt8]

minor bug/problem: when I set some languages as default at the top of the language drop box, I apparently cannot choose the same language twice for that. e.g. when choosing spanish (castilian) and spanish (spanish), then only spanish (castilian) is added to that list.

[Mosu]

minor bug/problem: when I set some languages as default at the top of the language drop box, I apparently cannot choose the same language twice for that. e.g. when choosing spanish (castilian) and spanish (spanish), then only spanish (castilian) is added to that list.

That's not really a bug. In Matroska languages are stored as their three-letter ISO-639-2 code. That code is the same for "Spanish (Castilian)" and "Spanish (Spanish)": "spa". Therefore the two entries are identical.

[Mosu]

I don't have the source package.

Take a look at what I did and see if that fits your needs: mkvmerge doc page (http://vidiot.com/mkvmerge.html)

The changes are in red.

Any comment on the stylesheet that appears to be nonexistant?

I'll try to integrate it in the next couple of days (I'll be alway most mostly until Monday).

No comment on the stylesheet yet; will take a look later (it's probably part of the DocBook distribution).

[beandog]

I'll try to integrate it in the next couple of days (I'll be alway most mostly until Monday).

No comment on the stylesheet yet; will take a look later (it's probably part of the DocBook distribution).

Mosu, if you don't wanna futz with it, I can take his changes and roll a patch for you.

Edit: sent to user-ml

[MrVideo]

Thanks guys.

I hope the changes were to your liking, and correct.

[tormento]

Mosu, I have to mux a lot of similar files, i.e. same language video, same language audio tracks, same forced subs, etc. Using the GUI is very tedious (for me, al last).

Could you please put an output to the debug window where I can find the command line to use with mkvmerge? I have tried to use command line manual but every mkv I mux has to be composed by 6-8 different "tracks". It is a nightmare.

[Mosu]

Uhm... "Muxing -> Show command line"?

[LeMoi]

2010-09-19 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation of the programs into French by Trinine (see AUTHORS).Sorry but i didn't find it in the options of mmg?!

[Mosu]

How embarrassing. It has been fixed in Git revision 0c9eb34a and pre build 312: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.4.0-build20101107-312-setup.exe

[Lincoln Burrows]

Well, after the makemkv admin said that those files were normal videos, and you said it had 50 frames and should play 2m40s I came up with those numbers. I just now downloaded the m2ts sample you posted (00068.m2ts) and it has 21 frames. I had no problems playing the m2ts sample using Haali's splitter - it may be a bug in MPCs internal splitter. (Which is to be replaced in the future.) The mkv sample (title06.mkv) has 32 frames with 23.976 fps - you can correct that using mkvtoolnix by changing the fps like I demonstrated in my last post.I just came across another title with the same issue: The Truman Show (1998) has a photo gallery. I tried many numbers in the FPS field but there are two problems happening here that should be adressed as I explained:

1) The first picture is quickly changing and you can't see it no matter what.

2) Assuming the original video has 23.976 or 24 fps and 1 minute and 30 seconds, it doesn't matter. If you insert numbers like 24/90, 25/90, 23/90 or any other for that matter, you will never get the precise lenght, considering the second number is the lenght in seconds. So you are wrong.

Even if you manage to find a number that can give you 1m30s, you still have to deal with 1).

And contrary to what I said, Mkvtoolnix can recognize mpv files (demuxed by TSMuxer from Blu-ray extra features using MPEG-2), and insert them in the MKV container, but you need to browse "Any kind of files" instead of "All suported media files".

Is there a reason for that? If mpv is supported why Mkvtoolnix while browsing for media files can't see the file?

[Mosu]

If you have a video whose frames have varying lenghts (e.g. the first picture has to be shown for a long time, the rest for much shorter durations) then mkvmerge's only support for that is with external timecode files. Specifying the FPS doesn't help as it assumes that all frames have the same duration.

And contrary to what I said, Mkvtoolnix can recognize mpv files (demuxed by TSMuxer from Blu-ray extra features using MPEG-2), and insert them in the MKV container, but you need to browse "Any kind of files" instead of "All suported media files".

Is there a reason for that? If mpv is supported why Mkvtoolnix while browsing for media files can't see the file?

Normally MPEG-2 video files have the extension ".m2v", ".mpg" or ".mpeg". I haven't seen ".mpv" bevore, and there's simply no official standard for file extensions. Every program can chose its own extension for whatever purpose it wants. For example I could make mkvextract output raw AAC tracks to files called ".gnufudel" and other programs wouldn't be able to see them even though they might be perfectly able to read them. This is why mmg doesn't list the file extension by default.

mkvmerge determines file types by the file's content, not by their extension. This is why it can still open and process that file even though the extension is unknown to mmg.

[sneaker_ger]

2) Assuming the original video has 23.976 or 24 fps and 1 minute and 30 seconds, it doesn't matter. If you insert numbers like 24/90, 25/90, 23/90 or any other for that matter, you will never get the precise lenght, considering the second number is the lenght in seconds. So you are wrong.

What makes you think the original video has 23.976 or 24 fps? Because some flag says so? Don't make assumptions based on some flag. Extract the timecodes and you can calculate the real fps and the number of frames.

Also the math for fps is number of frames/number of seconds and NOT frames per second/number of seconds.

[LeMoi]

mkvmerge determines file types by the file's content, not by their extension. This is why it can still open and process that file even though the extension is unknown to mmg.

Really ? I remember wanting to mux an mp4 file, which extension was .mov. mmg refused to remuxed it when it was .mov, and renaming it .mp4 solved the problem... But it was monthers ago, I couldn't give you an example...

[Mosu]

mkvmerge has NEVER used file extensions for type detection. It only uses file extension for e.g. VobSubs (using ".sub" for the content file when you add the ".idx" file).

[Lincoln Burrows]

What makes you think the original video has 23.976 or 24 fps? Because some flag says so? Don't make assumptions based on some flag. Extract the timecodes and you can calculate the real fps and the number of frames.

Also the math for fps is number of frames/number of seconds and NOT frames per second/number of seconds.OK, here's what I did:

1) Used TSMuxer to demux the original m2ts file (from the slideshow);

2) Used Mkvtoolnix to create a MKV file;

3) Used MKVextractGUI to extract the timecode from 2). This is the TXT file generated (attached to this post).

How may I calculate the number of frames? Is there a formula for that?

One more thing: in order to follow your tip, should I just insert the number of frames/seconds and create another MKV file or MKVtoolnix needs to load the TXT file (attached on this post) in the "timecode" box? *

* I tried to do that but it's returning the following error:

File contains an unsupported/unrecognized format line. The very first line must look like '# timecode format v1'.

The manual also says "Normally mkvmerge will derive the timecodes for each frame from the source file, but it can also read and use timecodes from an external text file whose name you can specify here. This feature is a very advanced feature. Almost all users should leave this entry empty."

[sneaker_ger]

I can't open your attachment as it is not yet approved. You cannot load a timecode file into mkvmerge AND specify a value for fps. But we just need to do the latter anyways. To "calculate" the number of frames in your file you just have to count the lines of the file, because each number is the starting time of a frame. (minus the first "# timecode format v2" line and minus the empty last line)
Then you can remux your file and specify number of frames / number of seconds and should get your dia show. (Or you can just choose your own dia duration. If you want each picture to get shown 3 seconds you choose "1/3", if you want 5 seconds "1/5" and so on...)

/edit:
If this still does not work correctly you may have stumbled upon an error in your player. If you are using MPC you can try to set the output to e.g. "EVR Custom Pres.".

[hh1974]

Thanks for this!!

[tormento]

Uhm... "Muxing -> Show command line"?
How embarassing... Thanks...

[73ChargerFan]

Mosu, the links in the first post are for version 4.0.0. Could they be updated?
This isn't the first time idiot-me downloaded from that post, only to revert to an older version.

[Mosu]

Sorry, but not. There's a big red hint at the start of the post, and each signature contains the link. I'd like to leave the post history alone.

[yumemi]

I need some help here. I have a lot of mkv files named "title.mkv" and I would like to put these titles into the title tag of each file. Is it possible to automate the process?

[sneaker_ger]

Write a batch which uses mkvpropedit.exe. (see the doc (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvpropedit.html))

[Mosu]

With shell scripting this is rather easy. Most likely it's even possible with cmd.exe, though I don't know how. With a bash like shell it goes something like this (assuming you want to put the files into another output folder):

for file in *.mkv ; do
mkvmerge -o "output/$file" --title "${file%.mkv}"
done

Untested.

Edit: If you don't need safety then doing it directly with mkvpropedit as sneaker_ger has said is just as easy; something like


for file in *.mkv ; do
mkvpropedit "$file" --set title="${file%.mkv}"
done

[sneaker_ger]

for file in *.mkv ; do
mkvpropedit "$file" --set title="${file%.mkv}"
done

Don't you need to also specify "--edit info"?

/edit: apparently not.

[Mosu]

Don't you need to also specify "--edit info"?

No, as "info" is the default section to edit. Though I have to admit that the documentation doesn't mention this fact.

[sneaker_ger]

Yes, that's why I wondered. Thx.

Just tried the header editor (of mmg) and it crashes on me for files which need admin rights (Windows 7, directory "c:" for example). Can you reproduce this? If not I will do some more testing and file a proper report on the tracker.

http://www.abload.de/img/header_editor_crashtyc6.png

[Mosu]

I doubt this particular error results from needing admin rights. Try that file in another location in which your normal user has access rights, please. I don't have a Windows system here at the moment that I can investigate on; also I don't have the time to before Saturday or Sunday.

[sneaker_ger]

It works fine in other directories, which don't need admin rights. Giving it admin rights does not prevent the crash.
What's funny: it managed to actually modify the file despite of missing admin rights, which I thought would be needed. Normally a UAC prompt would show up when doing anything in these directories with Windows Explorer.

[Mosu]

Interesting.

Ah well, as it is a crash in libebml I will most likely not investigate it. Lack of time etc.

[sneaker_ger]

I see.

[bayex]

Mkv file in MKV file right.h264 left.h264 to the title, but I could not throw. Mux as I have right.h264 mp4 file. Now I can not make this Mux mkv to the mp4 file

\right-muxed.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 12.0 GiB
Duration : 2h 39mn
Overall bit rate : 10.8 Mbps
Encoded date : UTC 2010-11-19 21:10:22
Tagged date : UTC 2010-11-19 21:10:22

Video
ID : 1
Format : svc1
Codec ID : svc1
Duration : 2h 39mn
Bit rate mode : Variable
Bit rate : 10.8 Mbps
Maximum bit rate : 32.0 Mbps
Width : pixel0
Height : pixel0
Frame rate mode : Constant
Frame rate : 23.976 fps
Stream size : 12.0 GiB (100%)
Encoded date : UTC 2010-11-19 21:10:22
Tagged date : UTC 2010-11-19 21:20:19


\right.h264
Format : AVC
Format/Info : Advanced Video Codec
File size : 12.0 GiB

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Stereo High@L4.1
MultiView_Count : 2
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive

[robpdotcom]

Looks like WD finally fixed their player:

Release 1.03.49 (11/16/10)
Added DVD navigation support.
Added Mediafly application.
Resolved MP4 poor frame-rate and audio out of sync issue.
Resolved HDMI auto resolution selection issue.
Resolved playback issues related to mkvmerge.
Other bug fixes and product updates (see release notes).

http://www.wdc.com/wdproducts/updates/?family=wdfwdtv_live

[InsulinJunkie]

Looks like WD finally fixed their player:

Well, one of them, at least.

The Gen2 WD TV that came out the same time as that original Live model (Live had network capabilities, non-Live didn't, as well as some other smaller differences)? The firmware hasn't been updated in over a year, and I'd be surprised if it ever will be.

[elshagon]

I'm using MKVMerge to remove a Russian audio track so it defaults to the DTS HDMA track but the mkv it outputs has jitter where the video will speed up every so often for a split second. Is there something in the settings I need to do to prevent this? I've tried leaving the fps as is and also tried setting it manually and this had no effect the problem still exists.

[Mosu]

If you're using Haali's splitter then try this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.4.0-build20101115-315-setup.exe

[SamuriHL]

If you're using Haali's splitter then try this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.4.0-build20101115-315-setup.exe

Does this build fix DTS-HD MA compatibility with Haali??

[Mosu]

It sets the "default duration" header value for DTS audio tracks of any kind, and according to some users this seems to make Haali's splitter work with it. I haven't tested this myself. Therefore the answer is a clear "I guess it should".

[SamuriHL]

It sets the "default duration" header value for DTS audio tracks of any kind, and according to some users this seems to make Haali's splitter work with it. I haven't tested this myself. Therefore the answer is a clear "I guess it should".

Hmm, interesting. I'll give this a try in a little bit. Thanks for this!

[robpdotcom]

You can also make previously created DTS-HD mkv's compatible with Haali by using the header editor in mmg.

Just open the Header editor (under "File" in mmg), drag a file into it, go to Audio track > Default duration and enter 10666666 into the field. It only takes a few seconds since you don't have to remux the file.

I've tested it with over 50 mkv's and they all work with Haali now.

[SamuriHL]

That's absolutely fascinating. Thanks for the info!!

[robpdotcom]

The best part is the possibilities it opens up:

I created a "seamless-branching" mkv using ordered chapters - one mkv, containing three versions of a movie (theatrical, special edition, director's cut) with a DTS-HD track. The result is one file, slightly larger than the longest version of the movie, that plays seamlessly. While the file is open in MPC-HC, you can right click on the Haali icon in the system tray and select the version you want to watch.

Also (Samuri, I know you've been wanting support of the "forced" flag for subtitles): Haali doesn't seem to respect the forced flag, but it does respect the "default" flag. You can use the header editor to change the default flag as well: Just flag all forced subs as Default = Yes, and normal subs as Default = No. Forced subs will load automatically, while normal subs will not (but will be available in the stream selection menu of MPC-HC).

[SamuriHL]

Very nice!! I guess I have some playing around to do this afternoon. :)

[elshagon]

I'm still having the same problem with the video jitter (speeding up for a split second fairly often) using latest mkvtoolnix both on my xp 32bit machine and on my windows 7 64bit machine. This is after taking an existing mkv and using mkvmerge to remove the russian audio track. This happens with all the movies I've tried this with. Is there any other setting I should look at, or any other way to remove the audio track which may work?

[Mosu]

No idea, sorry.

[elshagon]

No idea, sorry.

Thanks, I'm narrowing it down. Tried again, this time removing all the audio tracks and the video played perfectly. It must have something to do with the DTS HDMA track.

[robpdotcom]

@elshagon:

If all you want to do is make the DTS-HD track the default track, try this:

First, I'd make a copy of the file (I doubt it's necessary, but I don't want you getting angry with me if something goes wrong:p).

Open mmg, and click File > Header editor, and then drag the file into the Header editor window. You should see two audio tracks. Determine which one is the one you want as default - it's probably the second audio track. Find the 'Default track' flag setting, and change the value to "yes". Change the other track's setting to "no", and then click File > Save. The DTS-HD track should now load by default.

[elshagon]

@elshagon:

If all you want to do is make the DTS-HD track the default track, try this:

First, I'd make a copy of the file (I doubt it's necessary, but I don't want you getting angry with me if something goes wrong:p).

Open mmg, and click File > Header editor, and then drag the file into the Header editor window. You should see two audio tracks. Determine which one is the one you want as default - it's probably the second audio track. Find the 'Default track' flag setting, and change the value to "yes". Change the other track's setting to "no", and then click File > Save. The DTS-HD track should now load by default.

Thanks, just tried it but the Russian track still plays by default. Very strange. I'll keep trying.

[clsid]

You can also make previously created DTS-HD mkv's compatible with Haali by using the header editor in mmg.

Just open the Header editor (under "File" in mmg), drag a file into it, go to Audio track > Default duration and enter 10666666 into the field. It only takes a few seconds since you don't have to remux the file.

I've tested it with over 50 mkv's and they all work with Haali now.
Is the value 10666666 always the correct one to use? If not, what is the correct way for a n00b to find the right magic number?

I am adding this workaround to the Haali bug tracker topic.

[Mosu]

The correct value to use is:

default_duration = 1000000000 * core_samples / core_sampling_frequency

core_samples is the number of (core) samples in one DTS core. The core_sampling_frequency is its sampling frequency. The number of samples is... well... this is from mkvmerge's code:

int samples = dts_header->num_pcm_sample_blocks * 32;
if (dts_header->frametype == dts_header_s::FRAMETYPE_TERMINATION)
samples -= dts_header->deficit_sample_count;

Meaning that in general 10666666 is not always the correct value.

Remuxing with http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.4.0-build20101115-315-setup.exe is probably easier.

Edit: Though you're probably OK if you try setting the value (10666666) manually with the header editor first as most if not all DTS tracks have the same number of samples with the same sampling frequency. Just remember to remux with mkvmerge if setting said value doesn't help. mkvmerge does not use the "default duration" field when reading DTS from Matroska files, therefore wrong/bogus values in source files won't confuse it.

[robpdotcom]

most if not all DTS tracks have the same number of samples with the same sampling frequency.

I believe the only exception would be the DTS-CD format, which uses a 44.1kHz sampling rate to maintain compatibility with standard CD players. So for anything from a Bluray or DVD, 10666666 should work. Even DTS 96/24 uses a standard 48kHz DTS core.

[Vincent Vega]

hi Mosu,

i have these sample dolby media encoder output files:

http://www.mediafire.com/?9u1mrfwghjwt964

- source 7.1 (speaker test) wav
- .ec3 - 7.1 DD+ [standard target]
- .eb3 - 7.1 DD+ [BD target]
- .mlp - 7.1 TrueHD [standard/BD target]

- the .ec3 file - can mux to .mka, can play with MPC decoder (which only supports 5.1 for DD+); but registered TMT3 Arcsoft DS decoder only outputs stereo (although it's configured to output channels "as is" (http://forum.doom9.org/showthread.php?p=1460662#post1460662), which does work fine with my dd+/truehd .m2ts files)
- the .eb3 file - cannot mux with mmg (it says importing elementary AVC, asks for FPS..)
- the .mlp file - can mux to .mka, can play with MPC decoder (7.1 ok for TrueHD); but not possible to use the Arcsoft decoder (MPC HC freezes)

do you plan to add support for .eb3 files?
why are these playback issues with Arcsoft filter and dd+/truehd in mkv?

thanks

[FlexQ]

Hi Guys

I have been led to believe that i can mux an subtitle into an mkv container without making a new file, just using the old filename as the output filename.

However i get this msg and i just simply cant figure out what is wrong.

Error: The name of the output file 'My-Movie.mkv' and of one of the input files is the same. This would cause mkvmerge to overwrite one of your input files. This is most likely not what you want.

But this is exactly what i want ?

I have removed the mark in "Ask before overwriting things".
Which could indicate that this function should work ?

I hope you can point me in the right direction.

Henrik

[Mosu]

No, it would not do what you want it to do. Instead it would most likely corrupt your input file irrevocably. mkvmerge can definitely not what you want to do in this case.

[FlexQ]

Okay,

Thanks for the quick reply.

But is it possible then to merge a new file and let the program delete the old one?

I have limited space, but around 100 files to merge, and it would be nice if my server could merge while i am away on holyday ;)

Henrik

[Mosu]

Not with the GUI. It's trivial with the command line utilities, of course, especially if you need mass-merging. Use cmd.exe or even better a capable shell like bash/zsh. Or some Ruby/Python/Perl/Whatever scripting.

[Mosu]

do you plan to add support for .eb3 files?

I have no such plans at the moment.

why are these playback issues with Arcsoft filter and dd+/truehd in mkv?

No idea.

[Snowknight26]

Hitting abort while mkvmerge is trying to sync to the next element after hitting an error in the Matroska file structure causes this:
http://stfcc.org/pics/i/a4b0044db479dd95b01c61427654cf64.png

[Ingram]

Can someone help me with putting H264 video ripped from HD-DVD's into an MKV container using MKVmerge?

I have done this for VC-1 titles no problems at all. But H264 are causing me problems. The file plays fine within MPC-HC, but every few seconds there is a flash of an old frame shown, like it's glitching or something.

In MKVmerge I specified the framerate was 23.976. But now I'm wondering if I should be saying 29.97 and then the pulldown flags should kick in and make it run at 23.976? Maybe this is why it's glitching?

Has happened on 2/2 H264 HD-DVD's so far, and no doubt is about to be 3/3 as I'm currently doing another one that's H264.

EDIT: Yep, 3/3 of my H264 encoded HD-DVDs are doing it. I've tried setting the framerate to 24000/1001 and no difference.

What are my options?

[MrVideo]

or even better a capable shell like bash/zsh.

Wow! I'm impressed, you like Zsh :cool:

All of my work on the XP box is down via Z-shell scripts (cygwin).

[MrVideo]

What are my options?

I personally suspect something wrong with the video file. Try taking the video and audio stream and creating a transport stream file using tsMuxer, then playing it with VLC. Have you tried playing the MKV file with VLC?

[setarip_old]

@Ingram

Hi! Can someone help me with putting H264 video ripped from HD-DVD's into an MKV container using MKVmerge... ?In light of your difficulty, instead use MakeMKV to DIRECTLY(No other programs needed) convert your original HD-DVD to .MKV ("movie only")...

[Ingram]

All the suggestions I've tried before sorry. I've found nothing that will fix it other than to not use DXVA. Seems it's a driver related issue unfortunately.

[setarip_old]

@Ingram

If, in fact, you did try my suggestion ("All the suggestions I've tried before sorry"), what version of MakeMKV did you use?

[sneaker_ger]

I noticed that the header editor's description for video stereo mode differs from the description on the matroska website (http://www.matroska.org/technical/specs/index.html#StereoMode). Is the description in the header editor outdated (v1?) or am I looking at the wrong field?

[Mosu]

I noticed that the header editor's description for video stereo mode differs from the description on the matroska website (http://www.matroska.org/technical/specs/index.html#StereoMode). Is the description in the header editor outdated (v1?) or am I looking at the wrong field?

Most likely the former.

[Ingram]

@Ingram

If, in fact, you did try my suggestion ("All the suggestions I've tried before sorry"), what version of MakeMKV did you use?

The latest one. It worked fine but the problem occurs before it even gets to the MKV stage. It's a driver bug with Ati 10.x apparently. Only apparent with MPC-HC DXVA, not PowerDVD10 DXVA, or Software decoding.

[[DSL]Sensenman]

Hi,

I'm getting an error when trying to mux a file if the file-/segment title in mkvmerge contains a "#".
The error message states the following (roughly translated from german):
Error: option '--title' is missing the title.

I think that the #-sign has to be escaped somehow, is this possible?

Thanks,
Sensenman

[Mosu]

Is the '#' the very first character in the title? And can you please send me the .mmg file? Or do you mux via the command line?

[[DSL]Sensenman]

Hi,

yes, it's the very first letter in the title (the movie is #9). Attached is the mmg-file (I just muxed my videofile and added the title, but the error also appears if i try to mux audio&video).

I uploaded the file also to your ftp (filename: #9.mmg)

Thanks very much!

[Mosu]

Ok then I know what the problem is. I'll see I'll get it fixed soon.

[[DSL]Sensenman]

Thanks for the fast response, Mosu!

Looking forward to the new release!

[Mosu]

You can try this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.4.0-build20101220-316-setup.exe

[[DSL]Sensenman]

I tried your build, but it now throws a different error when trying to open the source file:
Benutzte Kommandozeile:

"C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" --output-charset UTF-8 --identify-for-mmg "E:\DVD\#9.mkv"

Ausgabe:

Fehler: Die Quelldatei 'E:DVD#9.mkv' konnte nicht geöffnet werden, oder aber die Größenabfrage schlug fehl.

If i move the file from E:\DVD\ to E:\ it works fine, so it seems it has a problem with the "\" in the path.

[Mosu]

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.4.0-build20101220-317-setup.exe

[[DSL]Sensenman]

Works like a charm, :thanks:

[Cheshire Cat]

Hi!

Just recently i started using this tool to remux some of my mkv files. Specifically the ones that were first muxed with a DTS track... Didn't knew about the sound issues when having >1500kpbs dts with matroska, but since that there hasn't yet been a fix i opted to transcode the DTS track to AC3.

I have no problem remuxing my files into a mkv container. Unfortunately the problem comes after. The remuxed mkv file becomes extremely difficult to handle. Like just cutting and copying or for instance deleting takes a lot of time. The HDD just trashes around with activity, and doing something to the file just takes a lot of time... Like accessing the file has somekind of delay...

Does anyone know what could be causing this?

All other mkv files don't present this problem, just the ones being remuxed...

I've tried a previous version 2.5.3 and the problem didn't occured, however had a/v sync problems, probably configuration related but didn't look into it...

What am i missing with these new 4.4 versions?

[Mosu]

Most likely http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

[Cheshire Cat]

Most likely http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

I take it that URL was about header removal compression, correct?

But wouldn't then the problem just be "player" related? What i am experiencing is "explorer" (windows user) related. And i've just tried disabling that option and remuxing a mkv and the problem stills maintains...

I'm puzzled. I'm usually able to solve my "problems" through Google but this one has no references i can use...

[Mosu]

Problems with header removal compression (short: HRC) are not limited to players but affect each and every application that tries to parse the content of Matroska files. The well-known DivX thumbnailing shell extension for Explorer for example crashes Explorer when it tries to handle Matroska files with HRC. Other applications like MediaInfo are also affected, though MediaInfo doesn't crash and has updates available that deal properly with HRC.

Anyway, it was just a wild guess. If that isn't the cause then I don't know what might cause your issues.

[roozhou]

Hi Mosu,

mmg's header editor seems to corrupt mkv files made by ffmpeg when i tries to modify something. Is this a bug or a limitation?

[Cheshire Cat]

When transcoding the DTS mkvs with MKV2AC3 for instance, the program also uses mkvmerge, an older version, as I've used 2.5.3 and the problem I'm reporting does not show up. Unfortunately when solo using 4.x versions I'm getting the problem reported...

I've compared different mkv's made with different program versions and i haven't been able to find a substantial difference between them that may be causing the issue...

:confused:

I re-tried several time with hrc disabled and in fact it the time needed to access the file (moving/deleting as reading works just fine) is a bit shorter however still excessive compared to other non-remuxed mkvs.

[Cheshire Cat]

I have to do an update. As it turns out the A/V sync problems with 2.5.3 version were caused by myself. I was using a 25fps video with a 23.976 audio source.

:stupid:

About the lagging issues moving/copying the files, they still happen with newer versions even with HRC disabled. With version 2.5.3 (others maybe but i haven't tested) it does not happen.

What will i be missing if i opt to use an older version to do my remuxing?

These are mkvinfo files from two mkv. Made with exactly the same files, only with different mkvmerge versions. 4.4.0 vs 2.5.3. The file done with 4.4.0 has the problem, the one made with 2.5.3 has no problems... Do these files provide any info/insight into the problem?

Problematic file done with 4.4.0

(MKVInfo) + EBML head at 0
(MKVInfo) |+ EBML version: 1 at 5
(MKVInfo) |+ EBML read version: 1 at 9
(MKVInfo) |+ EBML maximum ID length: 4 at 13
(MKVInfo) |+ (Unknown element: EBMLMaxSizeLength; ID: 0x42f3 size: 4) at 17
(MKVInfo) |+ Doc type: matroska at 21
(MKVInfo) |+ Doc type version: 2 at 32
(MKVInfo) |+ Doc type read version: 2 at 36
(MKVInfo) + Segment, size 5907217442 at 40
(MKVInfo) |+ Seek head at 52
(MKVInfo) | + Seek entry at 57
(MKVInfo) | + Seek ID: 0x15 0x49 0xa9 0x66 (KaxInfo) at 60
(MKVInfo) | + Seek position: 4099 at 67
(MKVInfo) | + Seek entry at 72
(MKVInfo) | + Seek ID: 0x16 0x54 0xae 0x6b (KaxTracks) at 75
(MKVInfo) | + Seek position: 4254 at 82
(MKVInfo) | + Seek entry at 87
(MKVInfo) | + Seek ID: 0x1c 0x53 0xbb 0x6b (KaxCues) at 90
(MKVInfo) | + Seek position: 5907183198 at 97
(MKVInfo) |+ EbmlVoid (size: 4043) at 105
(MKVInfo) |+ Segment information at 4151
(MKVInfo) | + Timecode scale: 1000000 at 4157
(MKVInfo) | + Muxing application: libebml v1.0.0 + libmatroska v1.0.0 at 4164
(MKVInfo) | + Writing application: mkvmerge v4.4.0 ('Die Wiederkehr') built on Oct 31 2010 21:52:48 at 4202
(MKVInfo) | + Duration: 6288.115s (01:44:48.115) at 4269
(MKVInfo) | + Date: Mon Dec 27 06:25:28 2010 UTC at 4276
(MKVInfo) | + Segment UID: 0x9a 0x16 0x09 0xa9 0x26 0x9e 0xb2 0xcf 0xa2 0x75 0x99 0x57 0x36 0x94 0x83 0xe8 at 4287
(MKVInfo) |+ Segment tracks at 4306
(MKVInfo) | + A track at 4312
(MKVInfo) | + Track number: 1 at 4315
(MKVInfo) | + Track UID: 2416326286 at 4318
(MKVInfo) | + Track type: video at 4325
(MKVInfo) | + Lacing flag: 0 at 4328
(MKVInfo) | + MinCache: 1 at 4331
(MKVInfo) | + Codec ID: V_MPEG4/ISO/AVC at 4335
(MKVInfo) | + CodecPrivate, length 42 at 4352
(MKVInfo) | + Default duration: 41.708ms (23.976 fps for a video track) at 4397
(MKVInfo) | + Video track at 4405
(MKVInfo) | + Pixel width: 1280 at 4407
(MKVInfo) | + Pixel height: 712 at 4411
(MKVInfo) | + Display width: 1280 at 4415
(MKVInfo) | + Display height: 712 at 4422
(MKVInfo) | + Content encodings at 4429
(MKVInfo) | + Content encoding at 4432
(MKVInfo) | + Content compression at 4435
(MKVInfo) | + Algorithm: 3 (header removal) at 4438
(MKVInfo) | + Settings: length 1, data: 0x00 0x00 0x6c 0x01 0x30 0x66 0x6c 0x01 0xc5 0x5d at 4442
(MKVInfo) | + A track at 4446
(MKVInfo) | + Track number: 2 at 4448
(MKVInfo) | + Track UID: 2057858224 at 4451
(MKVInfo) | + Track type: audio at 4458
(MKVInfo) | + Codec ID: A_DTS at 4461
(MKVInfo) | + Audio track at 4468
(MKVInfo) | + Sampling frequency: 48000 at 4470
(MKVInfo) | + Channels: 6 at 4476
(MKVInfo) | + Content encodings at 4479
(MKVInfo) | + Content encoding at 4482
(MKVInfo) | + Content compression at 4485
(MKVInfo) | + Algorithm: 3 (header removal) at 4488
(MKVInfo) | + Settings: length 4, data: 0x7f 0xfe 0x80 0x01 0x70 0x67 0x6c 0x01 0xdb 0x5d at 4492
(MKVInfo) |+ EbmlVoid (size: 1122) at 4499
(MKVInfo) |+ Cluster at 5624


Perfect functioning file made with 2.5.3

(MKVInfo) + EBML head at 0
(MKVInfo) |+ Doc type: matroska at 5
(MKVInfo) |+ Doc type version: 1 at 16
(MKVInfo) |+ Doc type read version: 1 at 20
(MKVInfo) + Segment, size 5911024348 at 24
(MKVInfo) |+ Seek head at 36
(MKVInfo) | + Seek entry at 41
(MKVInfo) | + Seek ID: 0x15 0x49 0xa9 0x66 (KaxInfo) at 44
(MKVInfo) | + Seek position: 4099 at 51
(MKVInfo) | + Seek entry at 56
(MKVInfo) | + Seek ID: 0x16 0x54 0xae 0x6b (KaxTracks) at 59
(MKVInfo) | + Seek position: 4246 at 66
(MKVInfo) | + Seek entry at 71
(MKVInfo) | + Seek ID: 0x11 0x4d 0x9b 0x74 (KaxSeekHead) at 74
(MKVInfo) | + Seek position: 5910954276 at 81
(MKVInfo) | + Seek entry at 89
(MKVInfo) | + Seek ID: 0x1c 0x53 0xbb 0x6b (KaxCues) at 92
(MKVInfo) | + Seek position: 5910920032 at 99
(MKVInfo) |+ EbmlVoid (size: 4025) at 107
(MKVInfo) |+ Segment information at 4135
(MKVInfo) | + Timecode scale: 1000000 at 4141
(MKVInfo) | + Muxing application: libebml v0.7.7 + libmatroska v0.8.1 at 4148
(MKVInfo) | + Writing application: mkvmerge v2.5.3 ('Boogie') built on Mar 7 2009 15:00:41 at 4186
(MKVInfo) | + Duration: 6288.115s (01:44:48.115) at 4245
(MKVInfo) | + Date: Mon Dec 27 06:36:31 2010 UTC at 4252
(MKVInfo) | + Segment UID: 0x87 0x23 0xe8 0x6a 0xdf 0x8b 0xb6 0xb7 0x9a 0xa7 0x5d 0x1b 0xb5 0x24 0x69 0x76 at 4263
(MKVInfo) |+ Segment tracks at 4282
(MKVInfo) | + A track at 4288
(MKVInfo) | + Track number: 1 at 4291
(MKVInfo) | + Track UID: 2012958848 at 4294
(MKVInfo) | + Track type: video at 4301
(MKVInfo) | + Enabled: 1 at 4304
(MKVInfo) | + Default flag: 1 at 4307
(MKVInfo) | + Forced flag: 0 at 4310
(MKVInfo) | + Lacing flag: 0 at 4314
(MKVInfo) | + MinCache: 1 at 4317
(MKVInfo) | + Timecode scale: 1 at 4321
(MKVInfo) | + Max BlockAddition ID: 0 at 4329
(MKVInfo) | + Codec ID: V_MPEG4/ISO/AVC at 4333
(MKVInfo) | + Codec decode all: 1 at 4350
(MKVInfo) | + CodecPrivate, length 42 at 4353
(MKVInfo) | + Default duration: 41.708ms (23.976 fps for a video track) at 4398
(MKVInfo) | + Language: und at 4406
(MKVInfo) | + Video track at 4413
(MKVInfo) | + Pixel width: 1280 at 4415
(MKVInfo) | + Pixel height: 712 at 4419
(MKVInfo) | + Interlaced: 0 at 4423
(MKVInfo) | + Display width: 1280 at 4426
(MKVInfo) | + Display height: 712 at 4431
(MKVInfo) | + A track at 4436
(MKVInfo) | + Track number: 2 at 4438
(MKVInfo) | + Track UID: 2928030870 at 4441
(MKVInfo) | + Track type: audio at 4448
(MKVInfo) | + Enabled: 1 at 4451
(MKVInfo) | + Default flag: 1 at 4454
(MKVInfo) | + Forced flag: 0 at 4457
(MKVInfo) | + Lacing flag: 1 at 4461
(MKVInfo) | + MinCache: 0 at 4464
(MKVInfo) | + Timecode scale: 1 at 4468
(MKVInfo) | + Max BlockAddition ID: 0 at 4476
(MKVInfo) | + Codec ID: A_DTS at 4480
(MKVInfo) | + Codec decode all: 1 at 4487
(MKVInfo) | + Language: und at 4490
(MKVInfo) | + Audio track at 4497
(MKVInfo) | + Sampling frequency: 48000 at 4499
(MKVInfo) | + Channels: 6 at 4505
(MKVInfo) |+ EbmlVoid (size: 1024) at 4508
(MKVInfo) |+ Cluster at 5535

[Mosu]

No idea, sorry.

[Cheshire Cat]

Thanks anyway!

:)

What would the main differences be when remuxing a mkv with such an older version like 2.5.3?

[Mosu]

Too many to list them all (even if I could recall them all). You could read the ChangeLog at http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog

[Mosu]

Hi Mosu,

mmg's header editor seems to corrupt mkv files made by ffmpeg when i tries to modify something. Is this a bug or a limitation?

That's usually a bug. Does that happen with all files created by ffmpeg? Which ffmpeg version is this? Which mkvtoolnix version? Can you please upload a sample file that has not been edited with the header editor yet (see signature for upload info)?

[yetanotherid]

I've been using VirtualDubMod to edit some AVIs containing AC3 audio, then remuxing them to MKVs with MKVMergeGUI (It's 720p x264 video which I remux to AVI for editing with VirtualDubMod before converting it or remuxing to MKV). More often than not, while remuxing, MKVMergeGUI will offer a warning about finding "x" number of bytes of non-audio data in the AC3 stream which it's skipped, and which might effect the audio sync. For reasons I don't understand, sometimes the audio sync is effected, sometimes not, but either way is there any way to mux the AC3 into an MKV without it skipping parts of the stream?
Even though there's no doubt non-audio sections in the edited AC3 stream for some reason (I don't know what VirtualDubMod is doing there) it remuxes the video into an AVI which stays in sync and which plays perfectly, so I'm wondering if MKVMergeGUI can do the same thing.

So far the only way I've found around the problem is by re-encoding the audio while it's still in the AVI, via DirectShow, which then gives me a new AC3 stream that's of the correct duration. Converting it after demuxing it doesn't always work as then sometimes the non-audio parts of the AC3 stream get skipped anyway. It'd be nice to be able to use the original stream though, without having to convert it to another AC3 stream via DirectShow, just to keep the audio in sync.

Any suggestions anyone?

[Mosu]

but either way is there any way to mux the AC3 into an MKV without it skipping parts of the stream?

Not with mkvmerge, no. In Matroska such garbage data would be invalid anyway.

Even though there's no doubt non-audio sections in the edited AC3 stream for some reason (I don't know what VirtualDubMod is doing there) it remuxes the video into an AVI which stays in sync and which plays perfectly, so I'm wondering if MKVMergeGUI can do the same thing.

mkvmerge usually does a good job at staying in sync if the garbarge is at the very beginning by calculating the delay that garbarge inside the AVI represents. If there's garbarge somewhere in the middle then you're mostly out of luck.

[yetanotherid]

mkvmerge usually does a good job at staying in sync if the garbarge is at the very beginning by calculating the delay that garbarge inside the AVI represents. If there's garbarge somewhere in the middle then you're mostly out of luck.

Thanks for the reply.
But yeah..... it's the garbage in the middle which causes the problem. No doubt I can get around it. Re-encoding the audio stream while it's still inside the originally edited file seems to do the job (via directshow) but I thought I'd ask in case there is a way to avoid re-encoding which I'd been missing.

Cheers.

[yetanotherid]

I just thought I'd add something to my previous post in case someone with a similar problem stumbles across it. So far, I've been able to split files containing AC3 audio using VirtualDub 1.9.10 without any sync issues while remuxing to MKV, while the last version of VirtualDubMod does something to cause the sync problem when it edits.
For VirtualDub you need to install the AC3 plugin or it'll not not what you're giving it when the audio is AC3, and it'll laugh at you when you try to import AC3 audio without the plugin.

[Episodio1]

YETANOTHERID, yes, I have same problems with VDubMod: after you demux AC3 you have to run "ac3fix.exe" to fix that AC3 file. The output file will be OK for Mkv always.

[yetanotherid]

YETANOTHERID, yes, I have same problems with VDubMod: after you demux AC3 you have to run "ac3fix.exe" to fix that AC3 file. The output file will be OK for Mkv always.

Thanks for that. There's a program/utility for everything. :)
I also read where someone suggested demuxing with Project X would fix the problem too, although I can't remember where.

Unfortunately though I had a dummy spit and deleted all the files and started again, so now all the editing has been done with VirtualDub so I've not got any out of sync audio to test. I'll have to make one later and try them both out.

It seems kind of odd VirtualDubMod seems to make a mess of the AC3 as it edits video, while VirtualDub does not... Given the first supports AC3 audio but the second requires a third party plugin to open/decode it. At least it seems somewhat odd to me.

[dirk362]

Feature Request - Artist property via mkvpropedit
To be able to set the Artist property field via scripts etc.

At present properties such as Title is setable, but some applications also set Artist as part of their encoding to match their application name.
I'm all for shameless plugs of the programmers efforts, but feel it more preferable to have Artist relate to the original creator of the works.

[Mosu]

Matroska file headres don't contain a field for an author. What you want would require tags, and mkvpropedit cannot edit/replace set tags at the moment. This is planned, but without any priority.

[Xanderian]

hello mosu,
mkvmerge 4.4 here

trying to mux a mov into mkv but for the audio track i get this error

"Warning: Quicktime/MP4 reader: The audio track 1 is using an unsupported 'object type id' of 0 in the 'esds' atom. Skipping this track."

so the file output has no audio..do you have any suggestions ? I can pm you a link for the file btw..

[Mosu]

You can upload it, but I cannot promise you when or even if I take a look at it. The QuickTime format is not really a priority for me at the moment.

[MrVideo]

Tools 4.4.0

I have some h.264 source files, both 1080i and 720p.

When I use the --default-duration 0:59.94fps on 720p source, the playback is at 59.94 fps.

But, for the 1080i h.264 source (from two different suppliers), the 0:29.97fps setting appears to used, as mediainfo shows the frame rate as being 29.97. But, when VLC plays it back, or when streamed to my Blu-ray player, the audio is at the right speed, but the video appears to be at 25 fps.

[... time delay while I try something ...]

Actually it is 15000/1001 fps. As a wild stab, I set the frame rate to 59.94, which is totally wrong for interlace 1080 video, but now it plays correctly.

Anyone have any ideas why double the frame rate needs to be set for it to work?

[Mosu]

mkvmerge has a known issue with calculating the default FPS for interlaced h264 video. I cannot give you a time frame when or if I might get around to working on it.

I'd be really grateful if someone with knowledge about interlaced h264 could chime in a give me some clues about how to derive a frame's duration in interlaced cases. Does the frame rate in the h264 headers (the SPS or whereever it is stored) simply apply to fields in those cases? I'd guess "not always".

[MrVideo]

mkvmerge has a known issue with calculating the default FPS for interlaced h264 video. I cannot give you a time frame when or if I might get around to working on it.

OK, no rush, as there is a workaround.

[madshi]

I'd be really grateful if someone with knowledge about interlaced h264 could chime in a give me some clues about how to derive a frame's duration in interlaced cases. Does the frame rate in the h264 headers (the SPS or whereever it is stored) simply apply to fields in those cases? I'd guess "not always".
IIRC, the h264 "frame rate" is actually always the *field* rate. So e.g. for 1080i50 content, you have a field rate of 50. For 1080p50, you have a field rate of 100. For 1080p24 you have a field rate of 48/1.001. For 1080i60 you have a field rate of 60/1.001.

The average duration of an interlaced field should be "1000 / field rate" milliseconds. The average duration of a progressive frame should be "1000 / frame rate" = "2 * 1000 / field rate".

The QuickTime format is not really a priority for me at the moment.
What is a priority for you at the moment? Or is it a secret? :)

[Mosu]

Thanks for the info, Madshi. With that info fixing it shouldn't be too hard.

My priorities are pretty much fixing bugs and improving the documentation. Yeah, that's not a lot. Programming in my free time is on the back burner for me for the time being. Mostly a motivational issue as I program full time for a living at the moment. And no matter how much I like programming it's mentally exhausting.

With that being said I think I'll take a look at the frame/field rate issue sometime next week.

[Xanderian]

Mosu I've uploaded the mov file starting with Exp* along with the caps..Hope you can take a look at this issue..

[shon3i]

I have somehow weird problem, i don't know that maybe hardware fault, or is just problem with mkvtoolnix, other muxers are not show this behavior.

I have perfectly "gitch" free 264 stream, when i muxed and watch or examine that stream with DGIndexNV, there is gitches.

Problem is that i can't replicate it every time, at same place. Sometimes muxing can pass without completly.

is there any tool can detect it or something?

btw i think i found way to check, stream will not demux here is eac3to log:

[a02] Invalid EBML data (1). <ERROR>
[a02] Invalid EBML data (1). <ERROR>
[v01] Invalid EBML data (1). <ERROR>
Aborted at file position 1929641984. <ERROR>

[shon3i]

I think i found perfect way to check mkv for errors using mkvextract with

mkvextract tracks "input.mkv" which scans stream show errors (if any) without real extracting streams.

i will do future invastigate, and report what can be reason. And just less thinking that is problem is on hardware side, i already finished surface memory test without problems, now i do surface test for HDD's which i will have results later.

[LeMoi]

Your file seems to be corrupted. Try mkvverify or even MPEG File Bitrate Viewer to check integrity

[shon3i]

Thanks LeMoi, here is cutted log of scaned mkv.

(mkv parser) file is b0rked:
pos. 42,031,135: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,150: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,152: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,167: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,169: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,184: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,186: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,201: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,203: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,218: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,220: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,235: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,237: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,252: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,254: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,269: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,271: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,286: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,288: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,303: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,305: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,320: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,322: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,337: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,339: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,354: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,356: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,371: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,373: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,388: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,390: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,405: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,407: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,422: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,424: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,439: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,441: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,456: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,458: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,473: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,475: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,490: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,492: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,507: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,509: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,524: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,526: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,541: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,543: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,558: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,560: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,575: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,577: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,592: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,594: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,609: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,611: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,626: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,628: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,643: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,645: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,660: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,662: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,677: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,679: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,694: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,696: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,711: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,713: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,728: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,730: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,745: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,747: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,762: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,764: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,779: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,781: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,796: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,798: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,813: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,815: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,830: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,832: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,847: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,849: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,864: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,866: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,881: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,883: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,898: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,900: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,915: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,917: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,932: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,934: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,949: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,951: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,966: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,968: 1st byte of EBML-ID indicates size larger than 4

[Cheshire Cat]

No idea, sorry.

Don't know if you recall my posts, but they are right at the last page.

Since our last talk i have been kind of "debugging" what could cause those access issue to mkvs made with more recent mkvtoolnix versions and i've gathered some new data...

In the meanwhile i've tested mkvtoolnix on windows xp. Last version - 4.4.0 - and haven't had any problems. Haven't tested on vista though. But since 7 is my main OS, i guess that is what matters.

With Google's help i've been able to track down some other people with similar complaint and with some testing i've able been able to pinpoint the issue to be somewhat related to the file being left indefinitely open after being accessed (maybe somewhat related to thumbnailing since the files who show these symptoms never show any kind of thumbnail). Let me remind that they are somewhat blocked. Readable but unable to be deleted, renamed or moved. Just after a reboot and even then sometimes they refuse to budge. If one disables the "details pane" the files are indeed movable/deletable & etc. But as soon as that pane is turned back on, problems return with the "defective" files.

I've also been trying different mkvtoolnix versions since the older ones and currently i'm at 3.2.0.0. At the moment things still do work perfectly and i can't report any problem. But as you can imagine testing one version at a time is indeed time consuming. So in a shortcut fashion, could you, or would you be able to say if at a given time you have introduced some modifications to the way mkvtoolnix handles remuxed files?

Since the program's older versions don't have any problems and this symptoms i have been report only show up at these newer versions it has to be some bug related with mkvtoolnix, the way it handles/writes files and/or/with windows 7 explorer...

[sneaker_ger]

Just to be sure: did you really deactivate header removal compression? I'm asking because the mkvinfo log from your 4.4.0 file shows that it is in fact activated for that file, not deactivated.

Since no version of Windows comes with any kind of Matroska splitter the problem may indeed lie with DivX/Haali or whatever splitter the explorer is using. (Though I think that newer Haali versions do not include shell extensions anymore due to severe problems with them.)

[Mosu]

So in a shortcut fashion, could you, or would you be able to say if at a given time you have introduced some modifications to the way mkvtoolnix handles remuxed files?

The one important thing that has changed in header removal compression: http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

There are no changes in the way or when mkvmerge/mmg open/close files when adding/muxing them.

[Cheshire Cat]

Just to be sure: did you really deactivate header removal compression? I'm asking because the mkvinfo log from your 4.4.0 file shows that it is in fact activated for that file, not deactivated.

Since no version of Windows comes with any kind of Matroska splitter the problem may indeed lie with DivX/Haali or whatever splitter the explorer is using. (Though I think that newer Haali versions do not include shell extensions anymore due to severe problems with them.)

Yes i already tried, as Mosul suggested, to disable the HRC unfortunately with no effect. I must say on Windows 7 since on XP i had no need. mkvtoolnix 4.4.0 worked just fine. Both systems are running pretty much the same applications (as i've though about some conflict) and both systems are running the same codec combinations.

[Cheshire Cat]

The one important thing that has changed in header removal compression: http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

There are no changes in the way or when mkvmerge/mmg open/close files when adding/muxing them.

Thanks for you patience! I guess i will keep trying different versions until i stumble upon one which replicates these issues in order discover what may be causing this.

[nlnl]

Mosu
Will you include this fix for Haali + DTS HD MA mkvtoolnix-unicode-4.4.0-build20101115-315-setup (http://www.bunkus.org/videotools/mkv...-315-setup.exe) in future 'official' 4.0.1 release?
The fix sets the "default duration" header value for DTS audio tracks of any kind.
Thanks!

[Mosu]

Anything in a pre-build will also be in the next release.

[Cheshire Cat]

Hi once more. Got news this time!

After a marathon trying different versions of mkvtoolnix indeed did find some new info.

The major culprit is the thumbnail component from Divx. After testing all the versions, and with the help of Google i stumbled upon a thread describing the exact same symptoms.

What was leaving me even more puzzled on this was that the problems don't start up immediately at version 4.1.0.0 - that was when hrc was added to mkvtoolnix, ain't i correct?

In fact i can use 4.1.0.0 and 4.1.1.0 just fine. Only from 4.2.0.0 ahead i have the issues described.

So, i gave it a try, un-installed Divx and re-tested the versions. There wasn't a single problem.

So what may be causing this so that it works just with some mkvtoolnix version? Incompatibilities? Any ideas?

[sneaker_ger]

So you're basically saying it was what we were telling you the whole time and that you made some mistakes in your tests?

4.2.0 is the first version in which header removal compression is on by default for h.264 video tracks.

[Mosu]

The DivX thumbnail component is even mentioned explicitely in my FAQ entry (http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression).

[Cheshire Cat]

The DivX thumbnail component is even mentioned explicitely in my FAQ entry (http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression).

Since you are the most probable "faq" creator i do not need to paste it here. The faq mentions explorer crashes. I never had explorer crashes. Only the already reported sluggishness trying to deal with mkv files. As you may see what was happening to me did not fit completely the descriptions related to the divx component as you wrote about them on the faq.

[Cheshire Cat]

So you're basically saying it was what we were telling you the whole time and that you made some mistakes in your tests?

4.2.0 is the first version in which header removal compression is on by default for h.264 video tracks.

If you manage to re-read my posts, and as i've replied to Mosul, you will be able to see that the issues i were experiencing don't fit exactly the descriptions of solely HRC or the thumbnails issue. At a stretch you could say that somehow they are related.

Having the faq as source and on relation to the divx problem - i never had any kind of explorer crashes.

Also having been said from you guys, and taken from the faq also, disabling only the HRC wasn't a solution also.

I had to uninstall the divx thumbnail component and as far as i recall none of you guys has mentioned that detail nor it is mentioned as a possible solution on the faq.

Sorry for the double post, my bad.

[LeMoi]

I installed too this DivX component on my laptop, but not on my main PC. This component is just buggy and outdated, reported informations are often wrong (especially duration), and thumbnail extraction worked about 2 days, and since then, doesn't work anymore. I just kept it because Explorer can now read some media informations such as resolution of MKV files, but i don't recommend anyone to install it!

[SamuriHL]

Use MediaInfo for such information. The DivX plugin has been a known problem for years now. One would have thought they'd fix it by now but that is a pipe dream.

[sneaker_ger]

If you manage to re-read my posts, and as i've replied to Mosul, you will be able to see that the issues i were experiencing don't fit exactly the descriptions of solely HRC or the thumbnails issue. At a stretch you could say that somehow they are related.

Having the faq as source and on relation to the divx problem - i never had any kind of explorer crashes.

Also having been said from you guys, and taken from the faq also, disabling only the HRC wasn't a solution also.

I had to uninstall the divx thumbnail component and as far as i recall none of you guys has mentioned that detail nor it is mentioned as a possible solution on the faq.

Sorry for the double post, my bad.

We both mentioned DivX, but fair enough, you did not experience explorer crashes.

I can't help but to still think that your problem is related to header removal compression, since your problems starts with version 4.2.0. I know you said you deactivated it. Did you make sure that you didn't have any files with HRC in the same folder (or desktop) when you were testing it? Did you look into the mkvinfo log to make sure it really was deactivated? I can't see anything else in the changelog for 4.1.1 -> 4.2.0 that looks suspicious.

It may be better to take this to the guys at DivX, though I think they probably know about the issues already. Even if there was a problem with the files created with 4.2.0 and later (I doubt it, but there is no way to be sure of course), the DivX software is buggy.

[Cheshire Cat]

How to uninstall without removing Divx? I tried an application found at Divx forums to tweak the codec properties and it had the option to remove the thumbnail component, but unfortunately it did nothing, things kept just like if i had used it. And Divx not being absolutely needed it quite handy.

I did not knew that the video only started being compressed at 4.2.0.0 as the fact said that since 4.1.0.0 HRC was included i assume it was already integrated and working, so i did not understand why it was doing that just from 4.2.0.0 and after.

And i did not have explorer crashes nor disabling/enabling the hrc solved anything. Just removing Divx and therefore that thumnail component.

[LeMoi]

Maybe you can uninstall it and reinstall without this component?

[Cheshire Cat]

We both mentioned DivX, but fair enough, you did not experience explorer crashes.

I can't help but to still think that your problem is related to header removal compression, since your problems starts with version 4.2.0. I know you said you deactivated it. Did you make sure that you didn't have any files with HRC in the same folder (or desktop) when you were testing it? Did you look into the mkvinfo log to make sure it really was deactivated? I can't see anything else in the changelog for 4.1.1 -> 4.2.0 that looks suspicious.

It may be better to take this to the guys at DivX, though I think they probably know about the issues already. Even if there was a problem with the files created with 4.2.0 and later (I doubt it, but there is no way to be sure of course), the DivX software is buggy.

I find it really weird to be only related to hrc. No other people complaint about mkvtoolnix + hrc when normally using Windows. Why would my PC do it? As you have said that it is inly enable for video from 4.2.0.0 does make a sense now because both older version 4.0 an 4.1 don't have problems.

Disabling hrc on 4.2/3 & 4 does no good. But as soon as i uninstall Divx things work just fine.

I have a 30GB partition dedicated precisely to this kind of work/tests. I've tried with one file at a time, since when they had those problems it was extremely hard to rename/move or even delete. The last thing i wanted was to have a couple of files, several GB large, residing on my drive because they would be a pain to remove.

I'm not bashing Divx but since it is explained why problems only start at 4.2 it's pretty clear the problem is on their side and if here i reckon there is indeed support from authors i don't think that from Divx part things are similar. I may drop an e-mail but something tells they won't give it much attention. Don't really understand is why they bundle these thing on an installer without any option too chose what or what not to install.

[Cheshire Cat]

Maybe you can uninstall it and reinstall without this component?

There is no option for that.

You install the codec bundle + 3 other things - convert, web player and something else...

But i reckon it is not needed to be filling up mkvtoolnix thread with any more off-topic.

Let me just say thanks for your help guys! Even though it wasn't a mkvtoolnix problem you've been A+.

[Betsy25]

Could this framerate "bug" be related to many problems lately with audio/video sync issues appearing when streams were extracted from mkv and remuxed into .mp4 ?:stupid:

[sneaker_ger]

Are you talking about your problems with variable framerate? As Selur already told you, you have to copy the timecodes from your mkv file to your mp4 file. This is not a bug in mkvtoolnix. (I'm assuming here that you are in fact dealing with a vfr file - you haven't provided any timecodes, so I cannot check it.) Most GUIs out there don't take vfr into account and will fail miserably.
You can use this patched ffmpeg build (http://sourceforge.net/projects/direct264/files/Related%20Programs/ffmpeg%20(demuxer_muxer%20only)/) for simple remuxing purposes:
ffmpeg -i input.mkv -vcodec copy -acodec copy output.mp4

[Betsy25]

Are you talking about your problems with variable framerate? As Selur already told you, you have to copy the timecodes from your mkv file to your mp4 file. This is not a bug in mkvtoolnix. (I'm assuming here that you are in fact dealing with a vfr file - you haven't provided any timecodes, so I cannot check it.) Most GUIs out there don't take vfr into account and will fail miserably.
You can use this patched ffmpeg build (http://sourceforge.net/projects/direct264/files/Related%20Programs/ffmpeg%20(demuxer_muxer%20only)/) for simple remuxing purposes:
ffmpeg -i input.mkv -vcodec copy -acodec copy output.mp4

Thanks sneaker, yeah it was about the vfr issue, but when .mkv is opened in mkvtoolnix, i don't see any timecodes ?

[sneaker_ger]

It does not make sense for mkvmerge GUI to list timecodes, as every single Matroska track has them - they are always present. You can extract them using mkvextract, which is part of the mkvtoolnix package. You can use MKVcleaver (http://forum.doom9.org/showthread.php?t=152108) if you're not comfortable with using mkvextract from the command line. For usage with mp4 files see NHMLTransform (http://forum.doom9.org/showthread.php?t=150890).

[Betsy25]

Thank you very much sneaker, the patches ffmpeg build is working fine.:)

[DragonQ]

Sorry if this has been discussed before but with mkvmerge GUI 4.4.0, the MKV files I create aren't compatible with the latest version of tsMuxer and won't generate thumbnails within Windows 7 (which I think I managed to enable with CoreAVC - I don't think Haali Media Splitter worked).

If I use mkvmerge GUI 4.1.1, the files get thumbnails correctly and can be read by tsMuxer.

What changed between these two versions that could've caused this new incompatibility?

[sneaker_ger]

Header removal compression is used by default now for a variety of tracks. Go into options and tick "Disable header removal compression for audio and video tracks by default".
http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

[DragonQ]

Ah cool, that seems to work. Cheers.

[Brazil2]

I don't know why this thread hasn't been updated yet but MKVToolnix v4.5.0 has been released about one week ago:
http://www.bunkus.org/videotools/mkvtoolnix/

Changelog: http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog

[SamuriHL]

Probably cause the forum was down for almost a week. Thanks for posting that! Thanks, Mosu, for the new release!

[Mosu]

The downtime was indeed the reason. Here's the release message:

I've released mkvtoolnix v4.5.0. It contains a lot of bug fixes as well as a couple of new features and a few enhancements.

There are two important changes for package maintainers:

1. mmg's guide is now installed into the $docdir location ("--docdir" option to configure) instead of $datadir/mkvtoolnix. This usually means /usr/share/doc/mkvtoolnix/guide/... instead of /usr/share/mkvtoolnix/guide... As the guide was the only thing installed in $datadir/mkvtoolnix that directory is not needed anymore.

2. mkvtoolnix requires libebml 1.2.0 and libmatroska 1.1.0 for compilation. Both have been released a few days ago. However, starting with this release mkvtoolnix includes the source of libebml and libmatroska. configure will still try to find globally installed copies of libebml and libmatroska like before and use them if they're recent enough. If they're not then configure will fall back to using the included versions.

This breaks in certain cases. If CFLAGS/CXXFLAGS/LDFLAGS contain include/library path directives to directories containing older versions of libebml/libmatroska then configure will correctly say it'll use its internal copies of libebml/libmatroska but compilation will fail (due to the order in which CFLAGS/CXXFLAGS/LDFLAGS etc are passed to gcc). I plan to fix this for the next release. For the time being it should be enough NOT to specify include/library paths with any of these environment variables. Then you can even leave older copies installed and compilation will work.

Meaning:

Old libs in /usr/include/ebml /usr/include/matroska is OK.

Old libs in e.g. /opt/libebml /opt/libmatroska and configuring with CFLAGS="-I/opt/libebml -I/opt/libmatroska" LDFLAGS="..." ./configure will break.

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-4.5.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.5.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.5.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.4.0:

------------------------------------------------------------
2011-01-31 Moritz Bunkus <moritz@bunkus.org>
* Released v4.5.0.
* build: Building mkvtoolnix now requires libebml v1.2.0 and libmatroska v1.1.0 or later.
* build: enhancement: mkvtoolnix now includes libebml and libmatroska. The configure script will use them if either no installed versions of them is found or if the installed version is too old.

2011-01-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an infinite loop when reading program stream maps in MPEG program streams. Part of a fix for bug 589.

2011-01-21 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: new feature: Added an option "--track-info" (short: "-t") that displays one-line statistics about each track at the end of the output. The statistics include the track's total size, duration, approximate bitrate and number of packets/frames.
* mkvinfo: bug fix: The hexdump mode was accessing invalid memory if the data to dump was shorter than 16 bytes. It was also outputting the values as characters instead of hexadecimal numbers. Patch by ykar@list.ru. Fix for bug 591.

2011-01-20 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The output file name extension is automatically set to ".mk3d" if the stereo mode parameter for any video track is changed to anything else than "mono" or the default value.
* mmg: enhancement: Added ".mk3d" to the list of known file name extensions for Matroska files.
* mkvmerge, mmg: enhancement: Updated the "stereo mode" parameter to match the current Matroska specifications.

2010-12-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: If mkvmerge encounters invalid UTF-8 strings in certain files or command line arguments then those strings will simply be cut short. Before mkvmerge was exiting with an error ("Invalid UTF-8 sequence encountered").
* all: new feature: Added online update checks. The command line tools know a new parameter "--check-for-updates". mmg has a new menu entry ("Help" -> "Check for updates") and checks automatically when it starts, but at most once in 24 hours. Can be turned off in the preferences. This function requires libcurl and is not built if libcurl is not available.

2010-12-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Avoid a crash due to invalid memory access if a source file name contains numbers (happens only if mkvtoolnix is built with MS Visual Studio). Fix for bug 585.

2010-12-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading VP8 video from Ogg files. Implements bug 584.
* mkvextract: enhancement: mkvextract will exit with an error if the user specifies track IDs that do not exist in the source file. This works in the "tracks" and "timecodes_v2" extraction modes. Fix for bug 583.
* docs: mkvextract's man page has been updated to match the program's expected command line syntax for the "timecodes_v2" mode. Fix for bug 583.

2010-12-20 Moritz Bunkus <moritz@bunkus.org>
* build system: Fixed building the Qt version of mkvinfo's GUI. Fix for bug 576.
* mkvmerge, mmg: bug fix: Option files could not contain options that started with '#' as they were interpreted as comment lines.

2010-11-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: The "default duration" header field is set for DTS audio tracks.

2010-11-09 Moritz Bunkus <moritz@bunkus.org>
* build system: mmg's guide and its images are installed into the location given by configure's "docdir" variable. Patch by Cristian Morales Vega (see AUTHORS).

2010-11-07 Moritz Bunkus <moritz@bunkus.org>
* all: Made the French translation selectable in all programs.

2010-11-01 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: On Mac OS X the application type is set to a foreground application preventing issues like the GUI never getting focus.
------------------------------------------------------------

Have fun.

[LeMoi]

Progress bar is not working anymore, instead of it I have this message :
The file 'xxx.mkv' has been opened for writing.
Progress: 0%
Progress: 10%
Progress: 20%
The cue entries (the index) are being written...
The file 'xxx.mkv' has been opened for writing.
Progress: 29%
Progress: 37%
Progress: 47%
Progress: 58%
Progress: 69%
Progress: 80%
Progress: 90%
Progress: 100%
The cue entries (the index) are being written...

[Mosu]

Progress bar is not working anymore, instead of it I have this message :

I just verified that it still works for me on my German Windows 7 64bit.

[Mosu]

Ah ok, it only happens with the French translation. Interesting. I'll check it out.

[LeMoi]

Indeed, if i go back to english version, progress bar is working fine

[Mosu]

Fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.5.0-build20110208-324-setup.exe

[Abs62]

Mkvmerge GUI 4.5.0 occasionally crashes on exit - exception 0xc0000005 in wxmsw28u_core_gcc_custom.dll. Start mmg.exe -> press Ctrl+Q -> crash. Next time start mmg.exe -> press Ctrl+Q -> OK.
WinXP SP3 (x86) eng.
4.4.0 work OK.

[Motenai Yoda]

into the stereoscopy tag there isn't options for frame interleaved?

[Mosu]

No, because the specs don't contain such a value. If you want more information I have to refer you to the devel mailing list and the discussions about this topic over the last weeks: http://lists.matroska.org/pipermail/matroska-devel/

[Mtz]

4.5.0
Is possible that saving on external HDD (using USB cable connection) to result in sometimes corrupted files? Saving on internal HDD I never had problems, but on two external HDD sometimes the result is like this:

---
ERR080: Unknown element [BB] at 8539975200 size 17
ERR080: Unknown element [BB] at 8539975219 size 17
ERR080: Unknown element [BB] at 8539975238 size 17
ERR080: Unknown element [BB] at 8539975257 size 17
ERR080: Unknown element [BB] at 8539975276 size 17
ERR080: Unknown element [BB] at 8539975295 size 17
ERR080: Unknown element [BB] at 8539975314 size 17
ERR080: Unknown element [BB] at 8539975333 size 17
ERR080: Unknown element [BB] at 8539975352 size 17
ERR080: Unknown element [BB] at 8539975371 size 17
ERR080: Unknown element [BB] at 8539975390 size 17
ERR080: Unknown element [BB] at 8539975409 size 17
ERR080: Unknown element [BB] at 8539975428 size 17
ERR080: Unknown element [BB] at 8539975447 size 17
ERR080: Unknown element [BB] at 8539975466 size 17
ERR080: Unknown element [BB] at 8539975485 size 17
ERR080: Unknown element [BB] at 8539975504 size 17
ERR080: Unknown element [BB] at 8539975523 size 17
ERR080: Unknown element [BB] at 8539975542 size 17
ERR080: Unknown element [BB] at 8539975561 size 17
ERR080: Unknown element [BB] at 8539975580 size 17
ERR080: Unknown element [BB] at 8539975599 size 17
ERR080: Unknown element [BB] at 8539975618 size 17
ERR080: Unknown element [BB] at 8539975637 size 17
ERR080: Unknown element [BB] at 8539975656 size 17
ERR080: Unknown element [BB] at 8539975675 size 17
ERR080: Unknown element [BB] at 8539975694 size 17
ERR080: Unknown element [BB] at 8539975713 size 17
ERR080: Unknown element [BB] at 8539975732 size 17
ERR080: Unknown element [BB] at 8539975751 size 17
ERR080: Unknown element [BB] at 8539975770 size 17
ERR080: Unknown element [BB] at 8539975789 size 17
ERR080: Unknown element [BB] at 8539975808 size 17
ERR080: Unknown element [BB] at 8539975827 size 17
ERR080: Unknown element [BB] at 8539975846 size 17
ERR080: Unknown element [BB] at 8539975865 size 17
ERR080: Unknown element [BB] at 8539975884 size 17
ERR080: Unknown element [BB] at 8539975903 size 17
ERR080: Unknown element [BB] at 8539975922 size 17
ERR080: Unknown element [BB] at 8539975941 size 17
ERR080: Unknown element [BB] at 8539975960 size 17
ERR080: Unknown element [BB] at 8539975979 size 17
ERR080: Unknown element [BB] at 8539975998 size 17
ERR080: Unknown element [BB] at 8539976017 size 17
ERR080: Unknown element [BB] at 8539976036 size 17
ERR080: Unknown element [BB] at 8539976055 size 17
ERR080: Unknown element [BB] at 8539976074 size 17
ERR080: Unknown element [BB] at 8539976093 size 17
ERR080: Unknown element [BB] at 8539976112 size 17
ERR080: Unknown element [BB] at 8539976131 size 17
ERR080: Unknown element [BB] at 8539976150 size 17
ERR080: Unknown element [BB] at 8539976169 size 17
ERR080: Unknown element [BB] at 8539976188 size 17
ERR080: Unknown element [BB] at 8539976207 size 17
ERR080: Unknown element [BB] at 8539976226 size 17
ERR080: Unknown element [BB] at 8539976245 size 17
ERR080: Unknown element [BB] at 8539976264 size 17
ERR080: Unknown element [BB] at 8539976283 size 17
ERR080: Unknown element [BB] at 8539976302 size 17
ERR080: Unknown element [BB] at 8539976321 size 17
ERR080: Unknown element [BB] at 8539976340 size 17
ERR080: Unknown element [BB] at 8539976359 size 17
ERR080: Unknown element [BB] at 8539976378 size 17
ERR080: Unknown element [BB] at 8539976397 size 17
ERR080: Unknown element [BB] at 8539976416 size 17
ERR080: Unknown element [BB] at 8539976435 size 17
ERR080: Unknown element [BB] at 8539976454 size 17
ERR080: Unknown element [BB] at 8539976473 size 17
ERR080: Unknown element [BB] at 8539976492 size 17
ERR080: Unknown element [BB] at 8539976511 size 17
ERR080: Unknown element [BB] at 8539976530 size 17
ERR080: Unknown element [BB] at 8539976549 size 17
ERR080: Unknown element [BB] at 8539976568 size 17
ERR080: Unknown element [BB] at 8539976587 size 17
ERR080: Unknown element [BB] at 8539976606 size 17
ERR080: Unknown element [BB] at 8539976625 size 17
ERR080: Unknown element [BB] at 8539976644 size 17
ERR080: Unknown element [BB] at 8539976663 size 17
ERR080: Unknown element [BB] at 8539976682 size 17
ERR080: Unknown element [BB] at 8539976701 size 17
ERR080: Unknown element [BB] at 8539976720 size 17
ERR080: Unknown element [BB] at 8539976739 size 17
ERR080: Unknown element [BB] at 8539976758 size 17
ERR080: Unknown element [BB] at 8539976777 size 17
ERR080: Unknown element [BB] at 8539976796 size 17
ERR080: Unknown element [BB] at 8539976815 size 17
ERR080: Unknown element [BB] at 8539976834 size 17
ERR080: Unknown element [BB] at 8539976853 size 17
ERR080: Unknown element [BB] at 8539976872 size 17
ERR080: Unknown element [BB] at 8539976891 size 17
ERR080: Unknown element [BB] at 8539976910 size 17
ERR080: Unknown element [BB] at 8539976929 size 17
ERR080: Unknown element [BB] at 8539976948 size 17
ERR080: Unknown element [BB] at 8539976967 size 17
ERR080: Unknown element [BB] at 8539976986 size 17
ERR080: Unknown element [BB] at 8539977005 size 17
ERR080: Unknown element [BB] at 8539977024 size 17
ERR080: Unknown element [BB] at 8539977043 size 17
ERR080: Unknown element [BB] at 8539977062 size 17
ERR080: Unknown element [BB] at 8539977081 size 17
ERR080: Unknown element [BB] at 8539977100 size 17
ERR080: Unknown element [BB] at 8539977119 size 17
ERR080: Unknown element [BB] at 8539977138 size 17
ERR080: Unknown element [BB] at 8539977157 size 17
ERR080: Unknown element [BB] at 8539977176 size 17
ERR080: Unknown element [BB] at 8539977195 size 17
ERR080: Unknown element [BB] at 8539977214 size 17
ERR080: Unknown element [BB] at 8539977233 size 17
ERR080: Unknown element [BB] at 8539977252 size 17
ERR080: Unknown element [BB] at 8539977271 size 17
ERR080: Unknown element [BB] at 8539977290 size 17
ERR080: Unknown element [BB] at 8539977309 size 17
ERR080: Unknown element [BB] at 8539977328 size 17
ERR080: Unknown element [BB] at 8539977347 size 17
ERR080: Unknown element [BB] at 8539977366 size 17
ERR080: Unknown element [BB] at 8539977385 size 17
ERR080: Unknown element [BB] at 8539977404 size 17
ERR080: Unknown element [BB] at 8539977423 size 17
ERR080: Unknown element [BB] at 8539977442 size 17
ERR080: Unknown element [BB] at 8539977461 size 17
ERR080: Unknown element [BB] at 8539977480 size 17
ERR080: Unknown element [BB] at 8539977499 size 17
ERR080: Unknown element [BB] at 8539977518 size 17
ERR080: Unknown element [BB] at 8539977537 size 17
ERR080: Unknown element [BB] at 8539977556 size 17
ERR080: Unknown element [BB] at 8539977575 size 17
ERR080: Unknown element [BB] at 8539977594 size 17
ERR080: Unknown element [BB] at 8539977613 size 17
ERR080: Unknown element [BB] at 8539977632 size 17
ERR080: Unknown element [BB] at 8539977651 size 17
ERR080: Unknown element [BB] at 8539977670 size 17
ERR080: Unknown element [BB] at 8539977689 size 17
ERR080: Unknown element [BB] at 8539977708 size 17
ERR080: Unknown element [BB] at 8539977727 size 17
ERR080: Unknown element [BB] at 8539977746 size 17
ERR080: Unknown element [BB] at 8539977765 size 17
ERR080: Unknown element [BB] at 8539977784 size 17
ERR080: Unknown element [BB] at 8539977803 size 17
ERR080: Unknown element [BB] at 8539977822 size 17
ERR080: Unknown element [BB] at 8539977841 size 17
ERR080: Unknown element [BB] at 8539977860 size 17
ERR080: Unknown element [BB] at 8539977879 size 17
ERR080: Unknown element [BB] at 8539977898 size 17
ERR080: Unknown element [BB] at 8539977917 size 17
ERR080: Unknown element [BB] at 8539977936 size 17
ERR080: Unknown element [BB] at 8539977955 size 17
ERR080: Unknown element [BB] at 8539977974 size 17
ERR080: Unknown element [BB] at 8539977993 size 17
ERR080: Unknown element [BB] at 8539978012 size 17
ERR080: Unknown element [BB] at 8539978031 size 17
ERR080: Unknown element [BB] at 8539978050 size 17
ERR080: Unknown element [BB] at 8539978069 size 17
ERR080: Unknown element [BB] at 8539978088 size 17
ERR080: Unknown element [BB] at 8539978107 size 17
ERR080: Unknown element [BB] at 8539978126 size 17
ERR080: Unknown element [BB] at 8539978145 size 17
ERR080: Unknown element [BB] at 8539978164 size 17
ERR080: Unknown element [BB] at 8539978183 size 17
ERR080: Unknown element [BB] at 8539978202 size 17
ERR080: Unknown element [BB] at 8539978221 size 17
ERR080: Unknown element [BB] at 8539978240 size 17
ERR080: Unknown element [BB] at 8539978259 size 17
ERR080: Unknown element [BB] at 8539978278 size 17
ERR080: Unknown element [BB] at 8539978297 size 17
ERR080: Unknown element [BB] at 8539978316 size 17
ERR080: Unknown element [BB] at 8539978335 size 17
ERR080: Unknown element [BB] at 8539978354 size 17
ERR080: Unknown element [BB] at 8539978373 size 17
ERR080: Unknown element [BB] at 8539978392 size 17
ERR080: Unknown element [BB] at 8539978411 size 17
ERR080: Unknown element [BB] at 8539978430 size 17
ERR080: Unknown element [BB] at 8539978449 size 17
ERR080: Unknown element [BB] at 8539978468 size 17
ERR080: Unknown element [BB] at 8539978487 size 17
ERR080: Unknown element [BB] at 8539978506 size 17
ERR080: Unknown element [BB] at 8539978525 size 17
ERR080: Unknown element [BB] at 8539978544 size 17
ERR080: Unknown element [BB] at 8539978563 size 17
ERR080: Unknown element [BB] at 8539978582 size 17
ERR080: Unknown element [BB] at 8539978601 size 17
ERR080: Unknown element [BB] at 8539978620 size 17
ERR080: Unknown element [BB] at 8539978639 size 17
ERR080: Unknown element [BB] at 8539978658 size 17
ERR080: Unknown element [BB] at 8539978677 size 17
ERR080: Unknown element [BB] at 8539978696 size 17
ERR080: Unknown element [BB] at 8539978715 size 17
ERR080: Unknown element [BB] at 8539978734 size 17
ERR080: Unknown element [BB] at 8539978753 size 17
ERR080: Unknown element [BB] at 8539978772 size 17
ERR080: Unknown element [BB] at 8539978791 size 17
ERR080: Unknown element [BB] at 8539978810 size 17
ERR080: Unknown element [BB] at 8539978829 size 17
ERR080: Unknown element [BB] at 8539978848 size 17
ERR080: Unknown element [BB] at 8539978867 size 17
ERR080: Unknown element [BB] at 8539978886 size 17
ERR080: Unknown element [BB] at 8539978905 size 17
ERR080: Unknown element [BB] at 8539978924 size 17
ERR080: Unknown element [BB] at 8539978943 size 17
ERR080: Unknown element [BB] at 8539978962 size 17
ERR080: Unknown element [BB] at 8539978981 size 17
ERR080: Unknown element [BB] at 8539979000 size 17
ERR080: Unknown element [BB] at 8539979019 size 17
ERR080: Unknown element [BB] at 8539979038 size 17
ERR080: Unknown element [BB] at 8539979057 size 17
ERR080: Unknown element [BB] at 8539979076 size 17
ERR080: Unknown element [BB] at 8539979095 size 17
ERR080: Unknown element [BB] at 8539979114 size 17
ERR080: Unknown element [BB] at 8539979133 size 17
ERR080: Unknown element [BB] at 8539979152 size 17
ERR080: Unknown element [BB] at 8539979171 size 17
ERR080: Unknown element [BB] at 8539979190 size 17
ERR080: Unknown element [BB] at 8539979209 size 17
ERR080: Unknown element [BB] at 8539979228 size 17
ERR080: Unknown element [BB] at 8539979247 size 17
ERR080: Unknown element [BB] at 8539979266 size 17
ERR080: Unknown element [BB] at 8539979285 size 17
ERR080: Unknown element [BB] at 8539979304 size 17
ERR080: Unknown element [BB] at 8539979323 size 17
ERR080: Unknown element [BB] at 8539979342 size 17
ERR080: Unknown element [BB] at 8539979361 size 17
ERR080: Unknown element [BB] at 8539979380 size 17
ERR080: Unknown element [BB] at 8539979399 size 17
ERR080: Unknown element [BB] at 8539979418 size 17
ERR080: Unknown element [BB] at 8539979437 size 17
ERR080: Unknown element [BB] at 8539979456 size 17
ERR080: Unknown element [BB] at 8539979475 size 17
ERR080: Unknown element [BB] at 8539979494 size 17
ERR080: Unknown element [BB] at 8539979513 size 17
ERR080: Unknown element [BB] at 8539979532 size 17
ERR080: Unknown element [BB] at 8539979551 size 17
ERR080: Unknown element [BB] at 8539979570 size 17
ERR080: Unknown element [BB] at 8539979589 size 17
ERR080: Unknown element [BB] at 8539979608 size 17
ERR080: Unknown element [BB] at 8539979627 size 17
ERR080: Unknown element [BB] at 8539979646 size 17
ERR080: Unknown element [BB] at 8539979665 size 17
ERR080: Unknown element [BB] at 8539979684 size 17
ERR080: Unknown element [BB] at 8539979703 size 17
ERR080: Unknown element [BB] at 8539979722 size 17
ERR080: Unknown element [BB] at 8539979741 size 17
ERR080: Unknown element [BB] at 8539979760 size 17
ERR080: Unknown element [BB] at 8539979779 size 17
ERR080: Unknown element [BB] at 8539979798 size 17
ERR080: Unknown element [BB] at 8539979817 size 17
ERR080: Unknown element [BB] at 8539979836 size 17
ERR080: Unknown element [BB] at 8539979855 size 17
ERR080: Unknown element [BB] at 8539979874 size 17
ERR080: Unknown element [BB] at 8539979893 size 17
ERR080: Unknown element [BB] at 8539979912 size 17
ERR080: Unknown element [BB] at 8539979931 size 17
ERR080: Unknown element [BB] at 8539979950 size 17
ERR080: Unknown element [BB] at 8539979969 size 17
ERR080: Unknown element [BB] at 8539979988 size 17
ERR080: Unknown element [BB] at 8539980007 size 17
ERR080: Unknown element [BB] at 8539980026 size 17
ERR080: Unknown element [BB] at 8539980045 size 17
ERR080: Unknown element [BB] at 8539980064 size 17
ERR080: Unknown element [BB] at 8539980083 size 17
ERR080: Unknown element [BB] at 8539980102 size 17
ERR080: Unknown element [BB] at 8539980121 size 17
ERR080: Unknown element [BB] at 8539980140 size 17
ERR080: Unknown element [BB] at 8539980159 size 17
ERR066: The SeekPoint at 87 references an unknown Cues at 8539840950
WRN0C0: First Block for video track #1 in Cluster at 12261830 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 13812631 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 15441105 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 24265883 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 26600904 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 28321522 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 31532622 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 78165442 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 118489390 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 212408880 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 310223640 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 312052713 is not a keyframe

ERR0C3: Unknown track #11553 in Cluster at 314010403
ERR0C3: Unknown track #49 in Cluster at 314010403
ERR0C3: Unknown track #46 in Cluster at 314010403
ERR0C3: Unknown track #11400 in Cluster at 314010403
ERR0B2: Block at 314642666 is using an unknown track #11553
ERR0B2: Block at 314657956 is using an unknown track #49
ERR0B2: Block at 314690708 is using an unknown track #46
ERR0B0: SimpleBlock at 314690846 track #12 is laced but the track is not
ERR0B1: SimpleBlock at 314690846 track #12 is not a keyframe
ERR0B2: Block at 314712493 is using an unknown track #11400
ERR0A1: The Cluster PrevSize -?99462574776 at 314618053 should be 74869
ERR0A2: The Cluster position 233 at 314658125 should be 314010351
WRN800: The segment has Clusters but no Cues section (bad for seeking)
WRN0D0: There are 1548660 bytes of void data

file created with libebml v1.2.0 + libmatroska v1.1.0 / mkvmerge v4.5.0 ('Speed of Light') built on Feb 1 2011 02:10:32

---

The file is 8GB.
I think bug started with 4.4.0

Both HDD are checked from windows 7 and no errors.

[invincible]

Hi! Mosu, How to play mk3d? any codec to do it?

[Mosu]

Such questions are probably better posted to the Matroska users mailing list. I cannot help you with 3D video issues/questions as I have pretty much no knowledge about that topic.

[Mosu]

4.5.0
Is possible that saving on external HDD (using USB cable connection) to result in sometimes corrupted files? Saving on internal HDD I never had problems, but on two external HDD sometimes the result is like this:

Check if header removal compression is the culprit. If not then I cannot help you.

[Chumbo]

@Mosu,
Is there a way to set a default globally for items like Compression on the Extra options tab? For me, it's tedious since I have to set this on every file for every track since my players don't support this so I have to disable it. If not, any chance, when you have time, to add a settings file where we can set a global default for items like this please? Thank you for considering it.

[Mosu]

Look at the preferences.

[Chumbo]

Look at the preferences.
Oy! How did I miss that? I need to have my eyes checked. Thank you.

By the way, when I was searching the help I noticed that I can't use a "find" from within. I searched on "compression" and it found it supposedly, but the content is very large and I could not use a search from within the content window.

What help system do you use for the F1 help? I finally resorted to just pulling up the html file from the doc folder. Maybe add an option to pull up the HTML help instead? ;)

Thanks again.

[Mosu]

What help system do you use for the F1 help? I finally resorted to just pulling up the html file from the doc folder. Maybe add an option to pull up the HTML help instead? ;)

I use the one provided by the GUI toolkit I use: wxwidgets. No, I don't like it much either, but it's cross-platform and not a lot of work to set up. Therefore I'm not really keen on changing it or implementing platform-specific help systems.

[Mosu]

Hey,

I've released mkvtoolnix v4.6.0. It contains a couple of bug fixes as well as a few new features.

There are two important changes for package maintainer:

1. There’s a new translation available, Turkish.

2. mkvtoolnix requires boost 1.36 or newer for compilation.

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-4.6.0.tar.bz2

...to the Windows installer and 7zip archive: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.6.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.6.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.5.0:

------------------------------------------------------------
2011-03-09 Moritz Bunkus <moritz@bunkus.org>
* Released v4.6.0.

2011-03-08 Moritz Bunkus <moritz@bunkus.org>
* build system: Fixed building the Qt version of mkvinfo's GUI (again). Fix for bug 576.

2011-02-17 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: If the header editor finds 'language' elements with ISO-639-1 codes (e.g. "fra" instead of "fre" for "French") then it will map the code to the corresponding ISO-639-2 code. Fix for bug 598.
* mmg: bug fix: Fixed one of the issues causing mmg to report that it is configured to use an unsupported version of mkvmerge when the reported version was actually empty.
* mkvmerge: enhancement: HD-DVD subtitles are recognized as being an unsupported file format. This makes the error message presented to the user a bit clearer. Fix for bug 600.

2011-02-15 Moritz Bunkus <moritz@bunkus.org>
* build: Boost 1.36.0 or newer is required (up from 1.34.0). Also fixed building with v3 of Boost's filesystem library, e.g. with Boost 1.46.0 Beta 1 or newer.
* mkvpropedit: new feature: Added support for adding, replacing and removing tags.

2011-02-07 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation for the programs into Turkish by ßouЯock (see AUTHORS).

2011-02-06 Moritz Bunkus <moritz@bunkus.org>
* build system: Fixed compilation if configure choses the internal versions of libebml and libmatroska while older versions are still installed in a location named with "-I..." or "-L..." in CFLAGS/CXXFLAGS/LDFLAGS or with configure's "--with-extra-includes" and "--with-extra-libs" options.
------------------------------------------------------------

Have fun.

Mosu

[b66pak]

thanks a lot...
_

[Chumbo]

Thanks Mosu for your continued efforts.

[Mystiqq]

I'm having weird problem with playback when splitting MKV file that has more than 32 tracks and when linking is used i.e. the file length is screwed somehow and playback is not working properly. I've tested with MPC-HC and KMPlayer, both use the latest Haali Media Splitter, with multiple MKV files and all have the same problem.

Example:

I took the "mewmew" example file from here (http://matroska.free.fr/samples/mewmew/) and extracted the english subtitle file out and added it in mkvmerge until i had 32 tracks in total. I split the file at 3MB and the resulting files works normally. If i added one more track and split again the length would no longer be little under minute long but shows as over minute and half in the player. The segments are somehow mixed when trying to play as linked and playing files individually after the first part does not appear to work at all.

Not sure if the problem is mkvmerge (4.6.0) or splitter, hopefully someone who knows about these things can shed some light into this.

Thanks in advance!

[Mosu]

mkvmerge has no limitation on the number of tracks. I'm pretty sure I've read somewhere that Haali's splitter has a limit of 32 tracks.

[Mystiqq]

mkvmerge has no limitation on the number of tracks. I'm pretty sure I've read somewhere that Haali's splitter has a limit of 32 tracks.

Ah, ok. Thanks! Yea it's right on the unofficial Haali Media Splitter bug thread.

Files with a large number of tracks (>32 ?) won't load.

[Mystiqq]

I'm trying to use mkvinfo to output to a file using verbose level 2 and i'm getting weird results.

mkvinfo -v -v sample.mkv -r info.txt
The entire output file, which is over 200MB, appears consists only the following lines repeated.

+ EBML head at 0
+ EBML head at 0
mm_write_cache_io_c::flush_cache(): requested 18 written 18
+ EBML head at 0
mm_write_cache_io_c::flush_cache(): requested 18 written 18
mm_write_cache_io_c::flush_cache(): requested 79 written 79
+ EBML head at 0
...


However the console outputs normally and console redirection works i.e.

mkvinfo -v -v sample.mkv > info.txt

Possibly a bug of some sort or am i missing something? :confused:

[Mosu]

I can reproduce the problem and will take a look at it, but I don't have an ETA for a fix.

[skampy]

Why does mmg seemingly continue to cause problems when muxing mkv's? I had perfectly fine x264 encode (originally muxed with mmg) that I watched all the way through, then afterwards I decided to add some .srt subtitles to it. Now, after the remux, I discover that there is a 12 second 'jump' that occurs at a certain point in the video. It is now no longer possible to seek to any frame in that 12 second gap on any of the media players I tried (VLC, MPC-HC etc).

If I let it play through to the problem point, it will jump the 12 seconds and be frozen on the last playable frame - the only way to get the video to play again (I can still hear audio though) is to seek sometime after the gap.

Why does this continue to happen with mmg (I've had many similar problems in the past) and why does mmg continue to not throw up any error or even any warning?

Both times this video was muxed was with version 4.4.0.

[GodofaGap]

Well if you aren't going to be more clear (or upload a sample with which you can reproduce the error), it's going to be hard to offer help. I've (re-)muxed dozens of files without any kind of problem.

[skampy]

Not sure how much more 'clear' I can be, I described exactly how the problem occurred.

Anyway, here is the sample you have asked for, it's only 33MB.

http://www.mediafire.com/?t298092fk6lvoph

It's a 20 second section I cut out in which the problem I am talking about occurs about 4-5 seconds into the segment clip.

[sneaker_ger]

Can you rule out any hardware errors? Like running memtest86+ for a night without any warnings? Maybe hard drive or controller errors. Also try if this is a regression, i.e. try older mkvmerge versions.
Try to find out if you can always reproduce the error on the same exact spot and upload both the original and the broken file. Maybe Mosu will take a look at it then.

[skampy]

Can you rule out any hardware errors? Like running memtest86+ for a night without any warnings?

Hardware is stable enough to encode for 40+ straight hours @ 100% CPU utilization.

Maybe hard drive or controller errors. Also try if this is a regression, i.e. try older mkvmerge versions.
Try to find out if you can always reproduce the error on the same exact spot and upload both the original and the broken file. Maybe Mosu will take a look at it then.

I have 10 hard drives, and on the several occasions this has occurred, it has been with different drives across two different controllers. But I won't rule out a controller error - how would I test for errors/problems across a HDD controller?

:thanks:

[GodofaGap]

Not sure how much more 'clear' I can be, I described exactly how the problem occurred.
Not really. Muxing srts is a rather standard operation and if it always fails there are bound to be more complaints.

Anyway, here is the sample you have asked for, it's only 33MB.

http://www.mediafire.com/?t298092fk6lvoph

This file is already broken. It would be nicer to have a working file which to then can be remuxed so that it becomes broken.

[sneaker_ger]

Hardware is stable enough to encode for 40+ straight hours @ 100% CPU utilization.

Even if it does not crash it does not necessarily mean that no errors can occur. Try memtest.

But I won't rule out a controller error - how would I test for errors/problems across a HDD controller?

I don't know myself.

Maybe try to test if you can reproduce the error on the same spot first.
I'm sorry that I'm not of great help, but if nobody is able to reproduce your problem, chances are it won't be fixed. (Assuming that it is indeed a problem with mkvmerge.)

[e.mote]

mkvmerge -q --display-dimensions TID:WxH --cropping TID:L,T,R,B infile -o outfile

Given the command above, which takes effect first, the AR adjustment, or the cropping? Or does it depend on which command is first on the commandline?

Thanks in advance for an answer.

[Mosu]

For mkvmerge the cropping parameters are completely independent of the display dimension parameters. Cropping parameters are simply written into the cropping header fields, and the same is true for display dimension parameters (mkvmerge is not a codec and does not modify the video data).

Edit: I was wrong: The Matroska specs DO mention the order: Cropping first, then scaling (see http://www.matroska.org/technical/specs/notes.html ). Nevertheless I still have no experience with the players and cropping.

[e.mote]

Mosu,

Thanks for the reply. I've no experience with MKV soft-cropping either, because I've yet to find a player that recognizes it. VLC partially sees it, and I've entered a bug report with VLC to that effect.

Given that CoreCodec is a sponsor (is that the right word?) for the MKV format, I'm hoping that CorePlayer will support it as well, and will lobby for such if not.

The below is what I'm trying to do, to better fit a widescreen video onto a 4:3 tablet, by both adjusting the AR and cropping. The MKV container spec allows both, only that cropping isn't well supported at the moment.

2.40 AR image adjustment on a 4:3 screen
http://makeagif.com/i/FrOzIy

[Mosu]

I'm trying to use mkvinfo to output to a file using verbose level 2 and i'm getting weird results.

That has been fixed in this pre-build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.6.0-build20110323-332-setup.exe

[73ChargerFan]

Is there a way to feed the video from an avisynth script directly into mkvmerge? It plays (video only) in mpc-hc but mkvmerge says unknown file type.

[sneaker_ger]

No, and even if it was possible the result would be totally uncompressed - probably not what you'd want.

There are softwares that may allow it through a virtual file, though. (But still uncompressed)

[space1999]

Is there a way to feed the video from an avisynth script directly into mkvmerge? It plays (video only) in mpc-hc but mkvmerge says unknown file type.

You may create a fake .AVI file with makeAVIS.exe,
set ffdshow to decode it, and then tell us what happens. :)

Still, I do not see the point of your idea. :confused:

[Mosu]

That will never work, no.

[Mystiqq]

That has been fixed in this pre-build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.6.0-build20110323-332-setup.exe

Thanks, I'll try it out.

[mastrandrea]

Hi, I've a little feature request: a "predicted final size" value (maybe in the bottom, near the buttons).
Would it be difficult to sum the sizes of all the streams and output the result before the muxing process?

Thanks!

[Mosu]

Impossible, sorry. mkvmerge (and therefore mmg) has no way to tell the size of each stream to merge before having processed all input files fully.

[LeMoi]

did something change in the way mkvtoolnix muxes subs in latest versions ?
With Windows/VLC :
http://img849.imageshack.us/img849/2561/vlcsnap00328.png

With ubuntu/smplayer (not my screen):
http://oi51.tinypic.com/2n18g29.jpg
See the weird char after the R of ORDINATEUR...

with Debian/smplayer (not my screen):
http://oi55.tinypic.com/muxzpu.jpg
blue big weird chars instead of subs...

mkvtoolnix 4.6.0, subs are extracted from Blu-Ray, and converted in idx/sub with BDSup2Sub 4.0.0. Didn't test with previous versions sorry

[Mosu]

Nothing has changed regarding subs.

[PowerGamer]

I have extracted DTS-HD MA track from BluRay into orig.dtsma using eac3to. I have muxed that track into .mkv using mkvmerge 4.6.0. I have extracted that audio track from created .mkv file into new.dtsma using eac3to.
Both files (orig.dtsma and new.dtsma) have the same byte-to-byte content except orig.dtsma is longer by 2080 bytes.

Why is it so (maybe it has something to do with this warning: "'orig.dtsma' track 0: force_duration_on_last_packet: forcing at 01:21:09.888000000 with 10666.666ms")? Souldn't .dtsma file be the same after muxing/demuxing it from mkv? Is it possible to make mkvmerge to not remove those extra bytes from .dtsma track at the end of the track (so that when I mux and then demux .dtsma track I get exact byte-to-byte identical file)?

EDIT: upon further experimenting it now definitely looks like a bug in mkvmegre (or maybe eac3to). When muxing new.dtsma track into .mkv and then extracting it I get new2.dtsma that is 2080 bytes shorter than new.dtsma. Repeating the same process several times (mux .dtsma obtained at the end of previous iteration into .mkv with mkvmerge, extract .dtsma from created .mkv using eac3to) each time extracted .dtsma file is 2080 bytes shorter than the .dtsma file I muxed into .mkv. This is surely wrong, the question is what program has a bug? If it is mkvmegre, please fix it.

[Mosu]

Why is it so?

Maybe the last few bytes are not a complete DTS packet?

(maybe it has something to do with this warning: "'orig.dtsma' track 0: force_duration_on_last_packet: forcing at 01:21:09.888000000 with 10666.666ms")?

That's not a warning. A warning is prefixed with "Warning:". That's a debugging message you only see because you're running with "-v".

Souldn't .dtsma file be the same after muxing/demuxing it from mkv?

Not neccessarily, no. mkvmerge throws away incomplete packets (each DTS packet has a header stating how long that packet is, if fewer bytes are available in the input file then that packet is considered incomplete) and garbage that it cannot identify as DTS (this is not the case here).

Is it possible to make mkvmerge to not remove those extra bytes from .dtsma track at the end of the track (so that when I mux and then demux .dtsma track I get exact byte-to-byte identical file)?

No.

[PowerGamer]

Mosu, please see the EDIT at my previous post. The behaviour I described (.dtsma file steadily decreasing in size after several mux/demux iterations) surely is not normal?

[Mosu]

Ok, it shouldn't get shorter each time, that's true. I really doubt mkvextract is the culprit. Looks more like mkvmerge thinks there's no full DTS packet available anymore even though there is one when the end of the input has been reached. I'll look into it.

[Mosu]

I cannot reproduce it with two DTS files I have here. Can you please upload (at least a part of) your file somewhere, e.g. to my FTP server?

[PowerGamer]

I cannot reproduce it with two DTS files I have here. Can you please upload (at least a part of) your file somewhere, e.g. to my FTP server?
Uploading that .dtsma file to your ftp now (see my PM). Also, in my testing, mkvextract produced the same output as eac3to when extracting .dtsma track from .mkv file, so yes, the problem is probably in mkvmerge.

[Mosu]

Thanks for the upload. The issue should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.6.0-build20110413-335-setup.exe

[PowerGamer]

Thanks for the upload. The issue should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.6.0-build20110413-335-setup.exe

Thanks for the quick fix, I have tested new build and it works fine.

But now it seems another (not present before) bug have crept into new mkvmerge build:
I am using a merge file "g:\!BD\merge" containing:
--output
g:\!BD\test.mkv
I am running "mkvmerge @g:\!BD\merge" command from another folder on another drive and it creates "!BDtest.mkv" file in the "G:\!BD" folder.

[Mosu]

Backslashes in option files have to be escaped by another backslash. You'll have to write

--output
g:\\!BD\\test.mkv


Yes, this is a recent change. It was necessary in order to fix another bug: options could not start with '#' due to it being interpreted as a comment (e.g. "--title #9" inside an option file would not work). mkvmerge's man page (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.escaping) contains a section about the rules for escaping characters.

[Vincent Vega]

hi Mosu and everyone,

if i'm remuxing a 1920x1088 (h264/vc-1/mpeg2) BD stream into mkv, do i need to specify anything under aspect ratio/cropping in mmg? (to get the 8 pixels cropped during playback and remaining 1920x1080 displayed 16:9)

sorry for the stupid question, i just cant find clear answer with forum search.

[Mosu]

I don't know, sorry.

[Vincent Vega]

ok sorry, np, i'll just start a new thread.

[Snowknight26]

It may have been overlooked last time I asked, but any change of enabling compression by default for PCM?

[Mosu]

Are you really using PCM that much that you're asking me to spend time on this?

[Snowknight26]

I figured it be an extra 'or' in an if statement or something similar, but if not, oh well. It's really a trivial suggestion so no worries.

[Vincent Vega]

if i need to cut out a small clip from somewhere in the middle of a huge mkv file, my only option is still remuxing entire file with "after timecodes" splitting? there is no way to just mux that little segment that i need?

thanks

[Mosu]

That is correct.

[Vincent Vega]

thank you for quick reply.

just one more question, i am trying to mux an h.264 stream in mmg with default settings, and in mediainfo (0.7.44) for the muxed video stream i get "Muxing mode:Container profile=Unknown@0.0" (while i'm expecting the usual "header stripping") where can i read explanation on this?

[Mosu]

Please post such questions to the MediaInfo developers.

[Lincoln Burrows]

Is there a proper way to do this?

Do you know for sure if this is even possible without reencoding either the video or the audio streams?

1) I downloaded three videos of mine from Youtube in MP4 format. It was a single video cut in 3 pieces due to the extended lenght (more than 15 minutes).

2) I decided to mix those videos into a single file (MKV) and upload into another location.

3) I tried to mix those MP4 files together but no luck so far. I also extracted the streams from the MP4s using YAMBOX (h264 and AAC). MKVToolnix is reporting this error:

Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.Only the first video is saved into a MKV container, the second video is being ignored...

[sneaker_ger]

And no luck appending.

Be more specific. Any error message? Crash? The youtube links (and which resolution)?

[Mosu]

Also provide the command line you're using. And: something prefixed with "Warning:" is not an error.

[Lincoln Burrows]

Be more specific. Any error message? Crash? The youtube links (and which resolution)?Any link would present the same problem.

OK, here's a random video I just found out:

Part 3:
http://www.youtube.com/watch?v=qHG2cwOQlwE

Part 4:
http://www.youtube.com/watch?v=-pVIcHuclw0

Now you need to use Downloadhelper or some other way to download the original MP4 files from Youtube server.

Here's the problem: no matter what you do, you can't merge those videos.

This is the command line when you add the MP4 files:

"C:\Arquivos de programas\MKVtoolnix\mkvmerge.exe" -o "C:\\Documents and Settings\\Core Quad 9450\\Desktop\\IELTS Argument Essay Writing 1 (4 of 4).mkv" "--forced-track" "1:no" "--compression" "1:none" "--forced-track" "2:no" "--compression" "2:none" "-a" "1" "-d" "2" "-S" "-T" "--no-global-tags" "--no-chapters" "C:\\Documents and Settings\\Core Quad 9450\\Desktop\\IELTS Argument Essay Writing 1 (4 of 4).mp4" "--forced-track" "1:no" "--compression" "1:none" "--forced-track" "2:no" "--compression" "2:none" "-a" "1" "-d" "2" "-S" "-T" "--no-global-tags" "--no-chapters" "C:\\Documents and Settings\\Core Quad 9450\\Desktop\\IELTS Argument Essay Writing 1 (3 of 4).mp4" "--track-order" "0:1,0:2,1:1,1:2"

And this is the error message I am receiving when merging both MP4 videos:

Warning: 'C:\Documents and Settings\Core Quad 9450\Desktop\IELTS Argument Essay Writing 1 (4 of 4).mp4' track 2: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.
Warning: 'C:\Documents and Settings\Core Quad 9450\Desktop\IELTS Argument Essay Writing 1 (3 of 4).mp4' track 2: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.


The resulted file only contains the first MP4 file...

You will get the same errors with different warnings if you use YAMB (software) to extract both track IDs (video/audio) into raw format and attempt to merge them on MKVToolnix.

Should I use any specific command line in this case?

[Mosu]

You're not appending the files in question. You're merging the files so that they're parallel instead of consecutive to each other.

[sneaker_ger]

I also got the warning (which is not critical, as pointed out by Mosu), but the appending worked just fine - simply added the first file to mmg and then chose "append" for the second one. I don't see any "--append-to" in your command line.

[mariush]

I'm not 100% about this one, but here it goes.

Source h264 + mp3, set header compression to none for audio track, enable splitting after 10 seconds, create maximum 2 files (basically i'm interested in second file, from 10s to end). Running this results in second mkv generated being made with audio header compression (zlib) - either this or youtube fails to process the video for some other reason.

With the option disabled globally from options, the generated mkv is successfully processed by youtube, like any video without header compression.

[Mosu]

The difference is that you haven't disabled header removal compression manually for the video track.

[Mosu]

I’ve released mkvtoolnix v4.7.0. It’s mostly a bug fix release with few new features.

There’s one important change for package maintainer: The configure script will always use the internal versions of libEBML and libMatroska. They’re linked statically. I plan to provide a configure option for using external ones in a future 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-4.7.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.7.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.7.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.6.0:

2011-04-20 Moritz Bunkus <moritz@bunkus.org>
* Released v4.7.0.
* build system: For the time being the build system will always build and link statically against the internal versions of libEBML and libMatroska.
* mkvmerge: bug fix: Fixed appending timecode calculation for appended subtitle tracks if the subtitle tracks are read from complex containers (e.g. Matroska, MP4, AVI etc). Fix for bug 620 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=620).

2011-04-15 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Fixed extraction of MPEG-1/2 video tracks whose sequence headers change mid-stream but whose key frames are not all prefixed with a sequence header. Fix for bug 556 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=556).
* mkvmerge: bug fix: Fixed reading AAC tracks from AVI files with 7 bytes long codec data. Fix for bug 613 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=613).
* mkvmerge: enhancement: Added support for WAV and AVI files that use a WAVEFORMATEXTENSIBLE structure (wFormatTag == 0xfffe). Fix for bug 614 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=614).

2011-04-14 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The output file name extension will be updated on each track selection changed as well. The extension is based on the actually selected tracks, not on the presence of tracks of certain types. Fix for bug 615 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=615).

2011-04-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge was dropping the last full DTS packet from a DTS files if that file was not encoded in "14-in-16" mode and if the file size was not divisible by 16.

2011-03-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed huge slowdown when splitting by size is active with certain kinds of input files. Fix for bug 611 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=611).
* mkvinfo: bug fix: Fixed redirecting the output into a file with "--redirect-output"/"-r" and verbosity levels of 2 and higher.
* mkvpropedit, mmg header/chapter editor: bug fix: Fixed parsing Matroska files if mkvtoolnix is compiled with newer versions of libebml/libmatroska (SVN revisions after the releases of libebml 1.2.0/libmatroska 1.1.0).

2011-03-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: WAV files with unsupported format tags are rejected instead of being treated like containing PCM. Fix for bug 610 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=610).

2011-03-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The EBML header values "doc type version" and "doc type read version" are both set to 3 if at least one of the video tracks uses the stereo mode parameter.


Have fun.

[khagaroth]

Could you please fix the width of the above post. It's a pain to read, thanks.

[robpdotcom]

Can someone help me with the command line to replace global tags using mkvpropedit?

Example: I have a file, movie.mkv - it already contains a global tag file, but I want to replace it with newtag.xml.

[Mosu]

mkvpropedit movie.mkv --tags global:newtag.xml

[b66pak]

@Mosu thanks a lot...
_

[robpdotcom]

mkvpropedit movie.mkv --tags global:newtag.xml

Thank you very much Mosu.:thanks:

[Lincoln Burrows]

I also got the warning (which is not critical, as pointed out by Mosu), but the appending worked just fine - simply added the first file to mmg and then chose "append" for the second one. I don't see any "--append-to" in your command line.I have made more tests and the only way for me to append those videos is to use YAMB to extract the audio (they are always in AAC format) and convert these streams using a software like BeHappy into MP3. That way you can have a single MKV file with all the videos you want.

What's wrong with AAC, anyway?

Edit: I solved the problem myself. I only needed to merge all video (.h264 streams). Then the next step was to do the same for all audio tracks (parts 1/2/3) in AAC (or MP3) format, saving into a .MKA file. Next thing was to load the MKV file and insert the MKA into that file, creating another Matroska. It's working now.

The mistake I made was selecting both video/audio tracks at the same time to save them into a Matroska container.

[hopstiii]

frames) references to other frames. The timecodes for such frames will be out-of-order,
and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for
this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.


Youtube will not show that video, all is gray, i have only audio.

MP4 video was encoded with ripbot264 with x264 encoder.

[Midzuki]

For a change, error messages quite often do N0T mean what they say. :rolleyes:
I didn't know that having 2 different versions of MKVtoolnix on 2 different directories was going to be a source of headaches >_<

MMG <SN!P> will not accept any file I add, be it mp3, mp4, wav, aac, etc. it allways returns a

"file identification failed for <trackname>. Return Code xxx".

Playing those Files in regular (32bit) players like MPC (for mkv internal splitter deactivated), WMP, etc. is no problem at all, and even muxing via the mkv-muxer in megui is no problem (wich is calling mkvmerge as mmg would do, or am I wrong on that?). So I am really puzzled about this problem and have absolute no idea what may go wrong here.
Oh Boy - Problem solved....
...
Haven't considered that mmg is using the registry for its settings, so the link to mkvmerge in mmg was using an ages old pathname that wasn't there anymore (I know why I prefer ini files).
...


Yes — what would be the problem in using an mkvtoolnix.ini ???

[Midzuki]

Mencoder syndrome:

<BS>"video stream is mandatory!"</BS>

Command line used:

"C:\Path-To\mkvmerge.exe" --output-charset UTF-8 --identify-for-mmg "C:\Path-To\filename.avi"

Output:

Error: The demultiplexer for the file 'C:\Path-To\filename.avi' failed to initialize:

avi_reader: Could not initialize AVI source. Reason: avilib - AVI file has no video data

[Mosu]

Yes — what would be the problem in using an mkvtoolnix.ini ???

The toolkit I use (wxWidgets) uses the registry automatically on Windows and INI files on other systems. Patches are welcome to change that (you can request the toolkit to use an INI file instead even on Windows), but those patches would have to provide a migration path as well.

[hopstiii]

Is it true mkv merge can't mux mp4 container x264 native that has over 4 reference frames?

mp4 has been made by RipBot264.
So the avi x264vfw from virtualdub is much more stable format. :confused:

[Mosu]

Is it true mkv merge can't mux mp4 container x264 native that has over 4 reference frames?

I don't know. I'm guessing you're encountering some kind of problem. Care to enlighten us?

[Mosu]

Mencoder syndrome:

<BS>"video stream is mandatory!"</BS>

Won't be fixed, sorry.

[Midzuki]

The toolkit I use (wxWidgets) uses the registry automatically on Windows and INI files on other systems.

Thanks for making things clear :thanks:

Given that I am unable to stop wxWidgets from being blatantly stupid :devil: :p ,
I'd better learn to do without the GUI for mkvmerge -.-

[Mosu]

When you uninstall mkvtoolnix via the installer then all registry entries are removed. Given that Windows' primary system for storing configuration data is the registry I don't see anything blatantly stupid in what wxWidgets does. That you prefer INI files is a totally different matter.

[hopstiii]

I don't know. I'm guessing you're encountering some kind of problem. Care to enlighten us?

After i muxed my RipBot264 x264 encoded in mp4 container, i got that error. Youtube can't decode that video, all is gray.
Mediacoder can't mux the file.

MKV Merge error
frames) references to other frames. The timecodes for such frames will be out-of-order,
and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for
this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

In RipBot264 i used this settings:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 4mn 53s
Bit rate mode : Variable
Bit rate : 2 500 Kbps
Maximum bit rate : 14.1 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.090
Stream size : 87.0 MiB (100%)
Writing library : x264 core 114 r1924 08d04a4
Encoding settings : cabac=1 / ref=9 / deblock=1:0:0 / analyse=0x3:0x133 / me=tesa / subme=10 /
psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=40 / chroma_me=1 / trellis=2 /
8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 /
nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=16 / b_pyramid=1 /
b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=1 / scenecut=40 /
intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=2500 /
ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 /
vbv_bufsize=50000 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00

[Midzuki]

When you uninstall mkvtoolnix via the installer then all registry entries are removed.

Sorry, I've never "installed" MKVtoolnix, I simply extract its package into a "PATH-ed" directory.

[Mosu]

Sorry, I've never "installed" MKVtoolnix, I simply extract its package into a "PATH-ed" directory.

Then you can easily remove the registry entries by removing HKEY_CURRENT_USER\Software\mkvmergeGUI.

[Mosu]

After i muxed my RipBot264 x264 encoded in mp4 container, i got that error. Youtube can't decode that video, all is gray.
Mediacoder can't mux the file.

Wait... You're creating a MP4 file that several utilities cannot handle and you're asking here for help? Why? Why don't you ask the RipBot authors or x264 authors?

MKV Merge error
frames) references to other frames. The timecodes for such frames will be out-of-order,
and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for
this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

First, it's not an error. There are legitimate files that don't require a CTTS atom -- ones without B frames (to be exact: ones in which decoding order and presentation order are identical and video timecodes are increasing by a constant value for each frame).

Second, for AVC/h.264 CTTS atoms are usually present. I don't know how you can avoid creating such files. This is not a RipBot support thread.

[Midzuki]

Given that Windows' primary system for storing configuration data is the registry I don't see anything blatantly stupid in what wxWidgets does.

The Windows Registry is well-known for being a huge can of worms. :(

[hopstiii]

My file is fully DXVA compatible on my Ati HD-3870.
Should be from starting HD-2000 series.

I go to RipBot264 topic because VirtualDub x264vfw encode works in avi container (can be muxed in MKV merge 4.7 with no error). It must be encoder problem.

[b66pak]

remuxing mkv with h264+dts (for adding new tracks or subs) results in a +11ms delay for the dts track:


timecodes for source mkv dts track:

# timecode format v2
0
10.666666
21.333332
31.999998
42.666664
53.33333
63.999996
74.666662
85
95.666666
106.333332



timecodes for remuxed mkv dts track:

# timecode format v2
11
21.666666
32.333332
42.999998
53.666664
64.33333
74.999996
85
85.666662
95.666666
106.333332



timecodes for remuxed mkv dts track after a new remux:

# timecode format v2
22
32.666666
43.333332
53.999998
64.666664
75.33333
85
85.999996
95.666666
96.666662
106.333332



anyway, it looks like after 11 frames is compensated...
_

[Mosu]

I'm assuming you're using a format as a source that provides timestamps (e.g. MP4, Matroska files) for the DTS tracks. mkvmerge re-uses those timecodes unless you adjust them with --sync.

If you were using raw DTS files mkvmerge would start at 0, neither at 11 nor at 22ms.

So there's no bug here.

[b66pak]

the source is a .mkv (h264+dts) with timecodes for dts and h264 that start at 0...if i load the .mkv and an external .srt in last mmg and remux to a new .mkv (h264+dts+srt) i get the +11ms delay for the dts track...
_

[Mosu]

Maybe the DTS tracks contain garbage at the beginning? You can upload the file if you want me to take a look at it (the source file that is).

[b66pak]

no...its clean...i cant upload anything for now...her is how to reproduce yourself:

cut 30sec from a .mkv with h264+dts...demux to raw .h264 and .dts...mux the .h264 and the .dts with the last mmg (v.4.7.0)...you will get a new .mkv with start timescodes 0 for audio and video...load this new .mkv in mmg and remux it...the result is +11ms for the dts track...
_

[sneaker_ger]

I'm assuming you're using a format as a source that provides timestamps (e.g. MP4, Matroska files) for the DTS tracks. mkvmerge re-uses those timecodes unless you adjust them with --sync.

Is this true for all audio tracks?
Because I found it not to be true, mkvmerge seems to recreate the audio timestamps even for mkv sources. Tested on ac3. And it can do some strange things, which look similar to those b66pak reported.

[Thunderbolt8]

is there any tool which lets me edit the track names for video and audio inside a .mkv file without having to remux the whole thing? and if so, I take it this isnt harmful for the file or its contents quality?

[sneaker_ger]

mkvmerge GUI > file > header editor or mkvpropedit.exe (cli)
But remuxing with mkvmerge is recommended anyways, don't remember the reason right now. Try to search this thread.

[Mosu]

Remuxing was preferred in the past because there were known problems with the header editor (and mkvpropedit as both use the same code for modifying the files) that could lead to file corruption. However, those bugs have long been ironed out, and I haven't received a single report about problems in that area for quite some time yet. Therefore I'd say "go for it and use the header editor".

[sneaker_ger]

Good to know, thought it had something to do with fragmentation or similar.
Any comment on my question (and b66pak's report) about audio timecodes?

[Mosu]

Fragmentation? I don't remember such an argument. The resulting files are 100% spec compliant, and as all header info is always referred to frame a seekhead entry at the start of the file playback should not suffer at all (the only exception is if you want to stream the resulting file over a non-seekable channel).

[Mosu]

About the timecodes: You're partially right. mkvmerge recalculates timecodes for some audio codecs but not for others. The ultimate goal is to re-use existing source container timecodes though.

[sneaker_ger]

Fragmentation? I don't remember such an argument. The resulting files are 100% spec compliant, and as all header info is always referred to frame a seekhead entry at the start of the file playback should not suffer at all (the only exception is if you want to stream the resulting file over a non-seekable channel).

I see.

About the timecodes: You're partially right. mkvmerge recalculates timecodes for some audio codecs but not for others. The ultimate goal is to re-use existing source container timecodes though.

I asked after some tests I made to help out in this thread (http://forum.doom9.org/showthread.php?t=160596). (no need to read everything)

He had sync issues after re-encoding video, but copying audio straight from mkv->mkv with mkvmerge, so I at first thought it was the video timecodes not being copied correctly, but the problem still persisted. You can download the timecodes in the last post by the thread starter. It has gaps in the timecodes (some timecodes being very large) and those gaps didn't make it through mkvmerge.
Also mkvmerge screws up, if you manually edited the first timecode to say 10ms, which really put me off. I tested AC3 IIRC.

[Mosu]

I know that re-calculating timecodes poses problems. Like I said, it's on my TODO list.

[sneaker_ger]

Ok, just making sure we're talking about the same thing. When you find the time to implement it, it would be nice to have an option in mmg to force recalculation (like it can be done with video tracks by specifying fps).

[Mosu]

You'll have to use a timecode file for that. Or extract before and merge the extracted version. Such a feature would be interesting to a very few users and uses cases only, therefore most likely no extra option.

[Thunderbolt8]

Remuxing was preferred in the past because there were known problems with the header editor (and mkvpropedit as both use the same code for modifying the files) that could lead to file corruption. However, those bugs have long been ironed out, and I haven't received a single report about problems in that area for quite some time yet. Therefore I'd say "go for it and use the header editor".
is the only important criteria here the age of the mkvtoolnix version I use to edit the header? or does the mkvtoolnix version with which the according .mkv file has been created also play a role?

[robpdotcom]

I've used the header editor to rename tracks, titles, change default/forced flags, etc on at least 100 DVD and Bluray rips - never had a single problem.

If you have any doubts, just copy the file before using the editor.

[Mosu]

is the only important criteria here the age of the mkvtoolnix version I use to edit the header? or does the mkvtoolnix version with which the according .mkv file has been created also play a role?

Only the version you are editing with is relevant.

[Lighto]

Is it just me or is the mmg.exe in the mkvtoolnix 4.7.0 package meant for 4.6.0?

Edit: seems like some left over registry/temp file messed it up. it's working now.

[Mosu]

So far you're the only one reporting such a problem (even though I don't even know what your problem actually is).

[Superb]

A friend sent me a patch to fix negative delay parsing for idx/sub:
http://www.sendspace.com/file/5xk2at
Could you take a look at it and possibly integrate it to the next official version?

[Mosu]

Can you provide a sample file, please? The modifications are not that straight-forward that I want to simply apply it as it is.

[b66pak]

So far you're the only one reporting such a problem (even though I don't even know what your problem actually is).

hi,


i use the windows portable versions of mkvtoolnix...after running 4.7.0 for the first time some registry entries are done (mkvmerge_executable)...this will mark the path to mkvmerge in 4.7.0 folder...when run an old mkvtoolnix a warnig will pop up...this ruin the portability...
_

[sneaker_ger]

i use the windows portable versions of mkvtoolnix...after running 4.7.0 for the first time some registry entries are done (mkvmerge_executable)...this will mark the path to mkvmerge in 4.7.0 folder...when run an old mkvtoolnix a warnig will pop up...this ruin the portability...
_

The toolkit I use (wxWidgets) uses the registry automatically on Windows and INI files on other systems. Patches are welcome to change that (you can request the toolkit to use an INI file instead even on Windows), but those patches would have to provide a migration path as well.

5chars

[allouh]

Never mind

[Mosu]

Even though allouh figured it out before I could answer I think the answer may be interesting to more than one user. Therefore this was was his question:

Is there a way to use MKVtoolnix under linux without installation?
I mean i only have access to linux console without root privilege, so is there a compiled version that i can use?

You have two options:

1. Use the "--prefix" option of configure to redirect the installation into a sub directory of your home directory:

./configure --prefix=$HOME/opt/mkvtoolnix
drake
drake install

2. Don't install at all and execute directly from the source code directory. As a matter of fact mkvmerge doesn't need anything on Linux to be installed in the location figured out by the configure script. The only drawback you get is that it won't find its translation files resulting in English-only programs.

[Mosu]

A friend sent me a patch to fix negative delay parsing for idx/sub:
http://www.sendspace.com/file/5xk2at
Could you take a look at it and possibly integrate it to the next official version?

I've applied the patch with some minor adjustments.

[Mosu]

i use the windows portable versions of mkvtoolnix...after running 4.7.0 for the first time some registry entries are done (mkvmerge_executable)...this will mark the path to mkvmerge in 4.7.0 folder...when run an old mkvtoolnix a warnig will pop up...this ruin the portability...
_

I've fixed this for the next release. As long as you don't select a specific mkvmerge.exe via "Preferences -> mkvmerge -> browse..." mmg will not replace "mkvmerge" with its full path when it saves the registry settings.

[Mosu]

Hey,

I’ve released mkvtoolnix v4.8.0. It’s mostly a bug fix release with few new features.

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-4.8.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.8.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.8.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.7.0:

2011-05-23 Moritz Bunkus <moritz@bunkus.org>
* Released v4.8.0.
* mmg: bug fix (Windows): mmg will no longer convert the "mkvmerge executable" from just "mkvmerge" into a full path name when writing its preferences to the registry upon existing.
* mkvmerge: enhancement: Added support for VobSub IDX files with negative "delay" fields.

2011-05-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The 'doc type read version' EBML header field is only set to 2 even if a stereo mode other than 'none' is used for at least one video track. Fix for bug 625 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=625).

2011-05-06 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: new feature: Added support for adding, replacing and removing chapters.

2011-05-03 Moritz Bunkus <moritz@bunkus.org>
* All: Avoided a segmentation fault in gcc by not including a pre-compiled header if FLAC or CURL support is disabled.
* mkvmerge: bug fix: Reading DTS files stored in 14-to-16 mode were read partially.

2011-04-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge will rederive frame types for VC1 video tracks stored in Matroska files instead of relying on the container information. This fixes files created by e.g. MakeMKV that mark all frames as key frames even if they aren't.

2011-04-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed detection of AAC files with ADIF headers. Fix for bug 626 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=626).

2011-04-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The 'doc type version' and 'doc type read version' EBML header fields are only set to 3 if a stereo mode other than 'none' is used for at least one video track. Fix for bug 625 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=625).
* mkvmerge: enhancement: File identification for tracks read from Matroska files with a codec ID of "A_MS/ACM" will show the track's format tag field if it is unknown to mkvmerge. Implements bug 624 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=624).

2011-04-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Track, tag and attachment selection via --audio-tracks, --video-tracks etc. can have their meaning reversed by prefixing the list of IDs with "!". If it is then mkvmerge will copy all tracks/tags/attachments but the ones with the IDs given to the option (e.g. "--attachments !3,6").
* mkvmerge: bug fix: Fixed handling AVIs with AAC audio format tag 0x706d and bogus private data size. Fix for bug 623 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=623).

Have fun.

[SamuriHL]

Thanks, Mosu. It keeps getting better and better with every version.

[b66pak]

thanks a lot...
_

[allouh]

You have two options:

1. Use the "--prefix" option of configure to redirect the installation into a sub directory of your home directory:

./configure --prefix=$HOME/opt/mkvtoolnix
drake
drake install

2. Don't install at all and execute directly from the source code directory. As a matter of fact mkvmerge doesn't need anything on Linux to be installed in the location figured out by the configure script. The only drawback you get is that it won't find its translation files resulting in English-only programs.

It's not that i figured it out this way, i just looked for a compiled copy to use.
For once, i just extracted the files from the binary file(deb) and tried to run them, but unfortunately i got the error message
-bash: line 55: ./mkvextract: cannot execute binary file
Also i tried a compiled copy that is prepared to run on WDTV, but i got the same error message above.
So i think i don't have the privilege to execute such files!
After this i gave up hope.

Return to your suggestion:
I tried configure the way you suggested but it got interrupted by missing ogg library.
Tried to install this library the same way, it succeeded but configure for MKVtoolnix still got interrupted by missing the very same library.

Do you think there is a way for me to run MKVtoolnex (specially MKVextract)?

[Mosu]

It's not that i figured it out this way, i just looked for a compiled copy to use.
For once, i just extracted the files from the binary file(deb) and tried to run them, but unfortunately i got the error message
-bash: line 55: ./mkvextract: cannot execute binary file

This means you're probably trying to execute a 32bit binary on a 64bit system without having installed support for 32bit libraries & executables, or you're executing a 64bit binary on a 32bit system (which will never work).

I tried configure the way you suggested but it got interrupted by missing ogg library.
Tried to install this library the same way, it succeeded but configure for MKVtoolnix still got interrupted by missing the very same library.

Do you think there is a way for me to run MKVtoolnex (specially MKVextract)?

Sure, but you'll have to be prepared to compile more than just libogg as well. Basically you should install everything into a prefix, e.g. $HOME/opt. Then you'll have to tell the various configure scripts of the libraries and mkvtoolnix where to find the libraries you've just compiled. This is often done via environment variables:

export CFLAGS=-I$HOME/opt/include
export CXXFLAGS=-I$HOME/opt/include
export LDFLAGS=-L$HOME/opt/lib
./configure --prefix=$HOME/opt


For boost this is a bit different.

You can get some hints from the section "2.3 Manual installation" from the file README.Windows.txt. Even though it explains how to compile all the libs for Windows with a mingw cross compiler it also deals with having all the libs in such a prefix directory and telling the configure scripts where to find them.

[Mosu]

remuxing mkv with h264+dts (for adding new tracks or subs) results in a +11ms delay for the dts track:

I've verified and fixed this in the following pre build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.8.0-build20110526-339-setup.exe

I've also checked whether or not the audio packetizers preserve source timecodes. The DTS packetizer obviously had some problems. The AAC and AC3 packetizers already did preserve timecodes.

If you find that some packetizers don't preserve timecodes and always recalculate then please let me know.

[allouh]

Thank you Mosu
This worked for everything except boost.
With Boost there's been a new problem arose; I'm only limited to 27k files on the server space i have, which is less than the files in the Boost 1.46 archive.
So I've been trying for a day with boost 1.36 (which contains less files), but i didn't succeed.
Also i tried the 64bit binary files from deb file, and they run but they asked for the dependencies.
So i think my other option is to have a compiled 64bit version like the one i got for WDTV from here (http://forum.wdlxtv.com/viewtopic.php?f=40&t=568&start=20#p11162)!
Do you think this is possible Muse?
I know my problem is becoming more of a linux problem and this is not the place for it, so i appreciate any help here before i go into the hard way.

[Mosu]

Which Linux distro, version and architecture is your server using?

[allouh]

Which Linux distro, version and architecture is your server using?
I wasn't informed of these, but by running some script (http://moustix.dyndns.org/fred/index.php/2006/06/17/5-script-to-return-the-linux-distribution-version-and-architecture) i found i get:
Debian release 5.0.8 on x86_64 (2.6.34.6-xxxx-grs-ipv6-64)
And by running "cat /proc/version" command i get
Linux version 2.6.34.6-xxxx-grs-ipv6-64 (root@kernel-64.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #3 SMP Fri Sep 17 16:06:38 UTC 2010

[Mosu]

Debian 5.0 is Lenny. I'm sorry, but I don't provide binaries for Lenny anymore as the Boost version contained in Lenny is too old.

[allouh]

Debian 5.0 is Lenny. I'm sorry, but I don't provide binaries for Lenny anymore as the Boost version contained in Lenny is too old.
Does this mean i can't run mkvextract(because this is the only executable i need) unless i move to new distribution?
Or is there a workaround for this.
Even with an old version of mkvtooldnix, can't this be possible?

[Mosu]

Old versions of mkvtoolnix are still available, both in source code and in binary form. For Debian Lenny the last package I provided was for version 4.5.0. It is still available for download: http://www.bunkus.org/debian/lenny/binary/amd64/mkvtoolnix_4.5.0_amd64.deb

You can try to extract its content without installing it (if you don't have root access) with dpkg-deb.

[Abradoks]

Hi, Mosu!
I've finally managed to build mkvtoolnix with MinGW, but here are some questions.
1) Have you tried to compile gui with wxWidgets 2.9?
When I tried I've ended up with errors on startup and menu bar disapeared.
2) Why are you using threading=single when building boost? Could there be any issues with mt version?
3) Have you intentionally commented out "m4_include(ac/ebml.m4)" and "m4_include(ac/matroska.m4)" in configure.in?
4) What do I need to run scripts from ./tests?
5) Is it possible to update avilib?
Currently I have to add _Pragma ("GCC optimize \"0\"") into avilib.c to get mkvmerge work with avi files. I've tested it with gcc 4.5.2 -O3/-O2 and 4.5.0 -O3 and every time mkvmerge hanged with 100% CPU usage. Also it needs needs -D__USE_MINGW_ANSI_STDIO=1 on MinGW.
6) Actually, there are more issues with 4.5.2. Without --disable-precompiled-headers it miscompiles mkvmerge so it crashes when trying to mux from mkv. Here is backtrace, in case it helps:
#0 0x006ff8ac in __cxa_throw ()
#1 0x004b4df0 in mm_io_c::read_uint32_be (this=0x3eadd8)
at src/common/mm_io.cpp:541
#2 0x004ce5de in kax_file_c::resync_to_level1_element_internal (
this=0x3eae68, wanted_id=524531317) at src/common/kax_file.cpp:162
#3 0x004ce4f2 in kax_file_c::resync_to_level1_element (this=0x3eae68,
wanted_id=524531317) at src/common/kax_file.cpp:149
#4 0x004cddf7 in kax_file_c::read_next_level1_element_internal (
this=0x3eae68, wanted_id=524531317) at src/common/kax_file.cpp:64
#5 0x004cdbb6 in kax_file_c::read_next_level1_element (this=0x3eae68,
wanted_id=524531317) at src/common/kax_file.cpp:38
#6 0x004ce13e in kax_file_c::read_next_level1_element_internal (
this=0x3eae68, wanted_id=524531317) at src/common/kax_file.cpp:96
#7 0x004cdbb6 in kax_file_c::read_next_level1_element (this=0x3eae68,
wanted_id=524531317) at src/common/kax_file.cpp:38
#8 0x004ceee5 in kax_file_c::read_next_cluster (this=0x3eae68)
at src/common/kax_file.cpp:247
#9 0x0043fa5c in kax_reader_c::read (this=0x3ea888, requested_ptzr=
0x3f44e80, force=false) at src/input/r_matroska.cpp:1966
#10 0x005ef0d3 in generic_packetizer_c::read (this=0x3f44e80)
at src/merge/pr_generic.h:462
#11 0x0041d584 in main_loop () at src/merge/output_control.cpp:1870
#12 0x004142e0 in main (argc=4, argv=0x3e3fd0) at src/merge/mkvmerge.cpp:2210
7) BTW, it would be nice to have --disable-precompiled-headers mentioned in compilation instructions.
8) Also mentioning which versions of gcc and libs are known to work properly with mkvtoolnix would save a lot of time.
9) And it would be nice to see --debug, --capabilities and --compression parameters listed in mkvmerge's --help.
10) LZO and other compression options are missing in mmg.
11) src/info/resources.rc seems to fail building with --disable-gui.

Oh, and here is build itself: MKVToolnix-4.8.0-static-cfa64aa.7z (http://www.mediafire.com/?fgfsp67vw70r1pg). It's statically linked and stripped.
Patches used:
1) mkvtoolnix-static.diff (http://pastie.org/1981544) to get static build compiled
2) mkvtoolnix-extlibs.diff (http://pastie.org/1981547) to link with external libebml and libmatroska.
3) mkvtoolnix-avilib.diff (http://pastie.org/1981546) to avoid breaking avilib
4) mkvtoolnix-defaults.diff (http://pastie.org/1981549) to change default behavior of mmg and mkvmerge. Now header removal compression is disabled by default in mkvmerge. Relative option in mmg is enabled by default, but changing it does nothing.
Also this patch adds language "nul (None)" which implies not writing language tag at all. For playback application it should be equivalent to eng. But now, when you select "eng", it always gets written. Remuxing file which didn't contain language tag also writes "eng".

I would appreciate if someone can help me testing it.

[Mosu]

Hi, Mosu!
I've finally managed to build mkvtoolnix with MinGW, but here are some questions.
1) Have you tried to compile gui with wxWidgets 2.9?
When I tried I've ended up with errors on startup and menu bar disapeared.

I refuse to test with 2.9.1 as they still label it a "development release" -- even though they claim that it is stable enough for new production projects. I simply lack the time to support non-production releases.

2) Why are you using threading=single when building boost? Could there be any issues with mt version?

No idea, never tried.

3) Have you intentionally commented out "m4_include(ac/ebml.m4)" and "m4_include(ac/matroska.m4)" in configure.in?

Yes. For the time being the included versions of libebml and libmatroska are preferred.

4) What do I need to run scripts from ./tests?

Ruby and my test files, and most likely Linux.

5) Is it possible to update avilib?

My version contains fixes and patches; therefore in general: "no".

6) Actually, there are more issues with 4.5.2. Without --disable-precompiled-headers it miscompiles mkvmerge so it crashes when trying to mux from mkv. Here is backtrace, in case it helps:

Please report such errors to the gcc devs.

7) BTW, it would be nice to have --disable-precompiled-headers mentioned in compilation instructions.
8) Also mentioning which versions of gcc and libs are known to work properly with mkvtoolnix would save a lot of time.
9) And it would be nice to see --debug, --capabilities and --compression parameters listed in mkvmerge's --help.

Patches are welcome. I don't have a list of compatible gcc and library versions that are known good. I only have the versions I use at the time, but making that list public would only lead to questions like "but I'm using ver XYZ and it works, too!" or "why don't you upgrade to ver ABC?" etc etc.

10) LZO and other compression options are missing in mmg.

On startup mmg queries mkvmerge about its capabilities. If mkvmerge has been built without support for LZO and BZ2, then mmg won't list them. If mmg doesn't list those even though mkvmerge has been built with them then that could be a bug.

11) src/info/resources.rc seems to fail building with --disable-gui.

Interesting, but fixing that has no priority for me.

1) mkvtoolnix-static.diff (http://pastie.org/1981544) to get static build compiled
2) mkvtoolnix-extlibs.diff (http://pastie.org/1981547) to link with external libebml and libmatroska.
3) mkvtoolnix-avilib.diff (http://pastie.org/1981546) to avoid breaking avilib
4) mkvtoolnix-defaults.diff (http://pastie.org/1981549) to change default behavior of mmg and mkvmerge. Now header removal compression is disabled by default in mkvmerge. Relative option in mmg is enabled by default, but changing it does nothing.

I'll take a lookt at 1 and 3. Thanks.

Also this patch adds language "nul (None)" which implies not writing language tag at all. For playback application it should be equivalent to eng. But now, when you select "eng", it always gets written. Remuxing file which didn't contain language tag also writes "eng".

mkvmerge does not write default values at the moment, and "eng" is the default value. So what you're observing is... strange and should not happen.

[Mosu]

Both patches are not portable, and I don't know the proper #ifdefs to check for "mingw but not a cross-compiler".

[b66pak]

I've verified and fixed this in the following pre build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.8.0-build20110526-339-setup.exe

I've also checked whether or not the audio packetizers preserve source timecodes. The DTS packetizer obviously had some problems. The AAC and AC3 packetizers already did preserve timecodes.

If you find that some packetizers don't preserve timecodes and always recalculate then please let me know.

thank you...
_

[Abradoks]

Ruby and my test files, and most likely Linux.
Can you please share those test files?

My version contains fixes and patches; therefore in general: "no".
Is it working for you on Linux with GCC 4.5? Because it seems more like a bug in avilib, than in GCC.

Patches are welcome.
Well, I knew you'll give such answer. Obviously it isn't critical, but updating documentation is generally expected from those who change code.

I only have the versions I use at the time, but making that list public would only lead to questions like "but I'm using ver XYZ and it works, too!" or "why don't you upgrade to ver ABC?" etc etc.
And not making it public creates superfluous obstacles for those who try to build on there own.

On startup mmg queries mkvmerge about its capabilities. If mkvmerge has been built without support for LZO and BZ2, then mmg won't list them. If mmg doesn't list those even though mkvmerge has been built with them then that could be a bug.
Yeah, I meant that "mkvmerge --capabilities" reports both BZ2 and LZO, but they are absent in mmg. Same with your build.

mkvmerge does not write default values at the moment, and "eng" is the default value.
Yes, that's why I had to hack libmatroska to actually write "eng".
So what you're observing is... strange and should not happen.
That was description of patched behavior, with clean mkvmerge everything works as expected.

Both patches are not portable, and I don't know the proper #ifdefs to check for "mingw but not a cross-compiler".
Those are just quick fixes to get mkvtoolnix compiled. I've posted them for information, not for commiting.

[Mosu]

Is it working for you on Linux with GCC 4.5? Because it seems more like a bug in avilib, than in GCC.

Yes, it works just fine here on ubuntu 11.04 64bit with gcc 4.5.2 and -O2 or -O3 (I don't remember).

Well, I knew you'll give such answer. Obviously it isn't critical, but updating documentation is generally expected from those who change code.

True but:

--debug is intentionally not documented (just like --engage).

--capabilities is only useful for people writing frontends. This one could use documentation.

--compression is already listed in --help.

And not making it public creates superfluous obstacles for those who try to build on there own.

README.Windows.txt already lists libraries and version numbers that used to work for me at the time of writing. The number of people trying to build on a non-Linux platform is rather low, and catering to such a low number is really time consuming; time I just don't have. It's not a matter of principal; I just have to chose wisely where to spend time and where not to.

Yeah, I meant that "mkvmerge --capabilities" reports both BZ2 and LZO, but they are absent in mmg. Same with your build.

Alright, that's a bug then. I'll look into it.

Yes, that's why I had to hack libmatroska to actually write "eng".

That was description of patched behavior, with clean mkvmerge everything works as expected.

Ah, I misunderstood you.

Those are just quick fixes to get mkvtoolnix compiled. I've posted them for information, not for commiting.

But if we could get them to be portable then you wouldn't have to maintain the ones I'm willing to apply.

[Abradoks]

--debug is intentionally not documented (just like --engage).

--capabilities is only useful for people writing frontends. This one could use documentation.

--compression is already listed in --help.
Ok, you are right about --debug and --capabilities. But in help --compression is in the wrong section and lacks options, while man pages are ok.

README.Windows.txt already lists libraries and version numbers that used to work for me at the time of writing.
Nothing about GCC version and wx < 2.9 there. Or am I the first one who encountered miscompilation of mkvmerge?

But if we could get them to be portable then you wouldn't have to maintain the ones I'm willing to apply.
Maybe I'll look into avilib issue later. At least we should understand why it fails, not just workaround it wih -O0.

[Mosu]

Ok, you are right about --debug and --capabilities. But in help --compression is in the wrong section and lacks options, while man pages are ok.

Ah, you're correct. I'll move --compression. I've also added --debug, --capabilities and --engage for completeness.

Nothing about GCC version and wx < 2.9 there. Or am I the first one who encountered miscompilation of mkvmerge?

No, you're not the only one. But I usually don't update documentation for libs that are still in development stage. Like I said, it's a matter of time and priorities. mkvtoolnix is pretty much a one-person job (apart from the translations), so I cannot simply hand such things over to someone else either.

[Mosu]

I've fixed the compilation errors with 2.9.1, but not the errors upon execution. It looks like I'm using IDs for menu items that are too low/too high/that collide with internal IDs. If so then it should be easy enough to fix.

However, I've also added code to configure that will disable the wxWidgets based GUIs if 2.9.0 or newer is detected. This has also found its way into README and README.Windows.txt.

The bug with mmg not including lzo and bz2 in the compression drop down box has been fixed. It was trivial to fix as the reason was that the drop down box was populated before mkvmerge was queried for its capabilities.

[Thunderbolt8]

it doesnt seem possible to add lpcm tracks created with eac3to. whys that?

[Mosu]

Because mkvmerge doesn't LPCM at all.

[Thunderbolt8]

hm any special reason for that?

[Mosu]

Lack of time and interest.

[SledgeHammer_999]

I am not sure if I should post this in this thread.

I am a little confused on how to mux ASS subs which use custom fonts. I thought that if I muxed the ass script and attached the font file it would be enough. But no, ffdshow-tryouts(+mpc) doesn't seem to pick up the emdedded font file and thus uses a generic font. What am I missing? (yes I have attached the correct font file).

EDIT: Arghhh, I feel stupid. The problem was in the mime type. I muxed through the commandline not the GUI. As MIME I used whatever GNOME showed me which is "application/x-font-ttf" but then I tried the mkvmerge gui and I noticed that it detected it as "application/x-truetype-font".

Does mkvmerge(or other mkv tool) provide a function that can tell me the MIME type of a file? Or is there any way to let mkvmerge decide itself the MIME? (the docs say that I have to specify the MIME)

EDIT2: And yes the docs are misleading. If you ommit the "--attachment-mime-type" mkvmerge autorecognizes the MIME type. Sorry for the noise people.

[Mosu]

mkvmerge and mmg both use the "libfile" library for MIME detection. This is the same library used by the Linux/Unix command line utility "file" for file type recognition. Both programs can be built without that library present in which case they'll fall back to detection by file name extension -- which might sometimes produce the correct result.

I'll take a look at the documentation.

[SledgeHammer_999]

In Debian Unstable file -i bla.ttf gives bla.ttf: application/x-font-ttf; charset=binary

From the online docs:
--attachment-mime-type MIME type

MIME type of the following attachment. Applies to the next --attach-file or --attach-file-once option. A list of officially recognized MIME types can be found e.g. at the IANA homepage. The MIME type is mandatory for an attachment.

I guess the bold part can be read many ways.

[Mosu]

It's quite possible that newer versions of the libmagic library (I was wrong before: the tool is called "file", yes, but the library it and mkvtoolnix use is called "libmagic") report different MIME types for TrueType fonts than older ones. mkvtoolnix' Windows version comes with a not so up to date version of libmagic.

Note that there seems to be no official MIME type registration for TrueType fonts (see http://www.iana.org/assignments/media-types/application/index.html ); each type starting with "x-" is an unofficial extension. I've seen numerous variants for TrueType fonts including but most likely not limited to: font/ttf (this one is especially bad as there's no official "font/" prefix registration), application/font-ttf, application/ttf, application/octet-stream (well... this is just the generic "binary data!" type), application/x-font-ttf, application/x-font-truetype, application/x-truetype-font, application/x-ttf-font. I'm not saying any one of them is more correct than any other, mind you, just that reading applications should be extended to recognize several versions.

I guess that mmg will chose "application/x-font-ttf" as well when I upgrade the libmagic for the Windows port.

[SledgeHammer_999]

I guess that mmg will chose "application/x-font-ttf" as well when I upgrade the libmagic for the Windows port.

This will brake MPC at least.(It is a splitter's issue, right?)
In Linux, gstreamer picks up correctly emdedded fonts with "application/x-font-ttf" as MIME type. (haven't tested mplayer/vlc/xine)

[Mosu]

It's up to the splitter, yes. As MPC is an actively maintained OpenSource project I'm sure that asking the devs to update will fix it.

[TheFluff]

it doesnt seem possible to add lpcm tracks created with eac3to. whys that?
eac3to 00000.m2ts 2: mka_with_pcm.mka
should work. It is (as far as I know) impossible to automatically detect a random PCM file's bitdepth, channel layout and sampling rate in a reliable way, so it's not surprising at all that mkvmerge doesn't support it.

[Anakunda]

Greetings, does mkvmerge reconstruct once splitteed movie into exactly the same streams as were before splitting ?
It deals all kinds of streams, audio, video, text, chapters..

[Incast]

Hopefully a simple query here: If I have three files demuxed from eac3to, for example:
1. 1.mkv -1.ac3 - uncorrectable audio delay: 8ms
2. 2.mkv -2.ac3 - uncorrectable audio delay: 15ms
3. 3.mkv - 3.ac3 - uncorrectable audio delay: 9ms

And I use mkvmerge append function to combine them into a single mkv file, will MKVMerge correctly handle each audio delay I insert for the individual files 1.ac3 (8ms), 2.ac3 (15ms) and 3.ac3 (9ms) and retain overall sync in my final single mkv?

[Thunderbolt8]

has this warning

Warning: 'video' track 1: The AVC video track is missing the 'CTTS' atom
for frame timecode offsets. However, AVC/h.264 allows frames to have more than
the traditional one (for P frames) or two (for B frames) references to other frames.
The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed
for getting the timecodes right. As it is missing the timecodes for this track might be wrong.
You should watch the resulting file and make sure that it looks like you expected it to.

any relevant meaning? (Im trying to encode a normal BD @23.976fps with GOP size = 1)

[Mosu]

GOP size = 1 means only key frames, doesn't it? Then the warning isn't relevant.

[Thunderbolt8]

ok what what if I set GOP size back to 33 (so I will also have B- and P-frames), what could I do then to avoid timecode problems so that my video and audio wont go out of sync?

[Mosu]

Well, normally you don't have to do anything -- the software encoding the video should write the CTTS atom in such a case automatically.

[Thunderbolt8]

so does this warning also appear if the atom has been written correctly? because the encoding software doesnt seem to have done it.

[Mosu]

It only appears if the atom is not found ( = if it hasn't been written). I don't know if B frame timecodes are always out of order. If they aren't then the CTTS atom is not needed, and the warning can be disregarded.

[pdanpdan]

I just found out: v4.8 (oficial and all test builds) can not identify (-i and identify for mmg) .avi files (any type of avi file). v4.7 works as it should. Win7x64.
The program just does not return anything, and keeps one CPU in 100%.
It I can provide any other info please tell me.
Thank you

[Abradoks]

I just found out: v4.8 (oficial and all test builds) can not identify (-i and identify for mmg) .avi files (any type of avi file). v4.7 works as it should. Win7x64.
Works for me on WinXP. Try that (http://www.mediafire.com/?fgfsp67vw70r1pg) build.

[pdanpdan]

this build works

[ynamojn]

I have problem extracting audio from one particular mkv. The extracted audio is shorter in duration and smaller in size compare to the audio stream in the original mkv. The audio is 5.1 dts cbr 1510 kbps. Duration in original mkv is 1 hour 36 minute. The extracted one is 1 hour 32 minute. I use mkvextract. What would possibly cause it?

[Mosu]

The audio inside the Matroska files has timecodes. The "duration" of the audio inside the Matroska files is therefore the maximum timecode.

Outside of a Matroska file DTS audio tracks do not have timecodes. Therefore it's possible that the track inside the Matroska files has some gaps in it -- jumps in the timecodes with no audio samples to fill them.

This is perfectly normal, e.g. if someone uses mkvmerge's --sync option with a stretch factor > 1 on an audio track (though I don't advice doing that; better results are usually achieved by stretching video and subtitle tracks in the other direction due to players using audio as the synchronization source).

[ynamojn]

The audio inside the Matroska files has timecodes. The "duration" of the audio inside the Matroska files is therefore the maximum timecode.

Outside of a Matroska file DTS audio tracks do not have timecodes. Therefore it's possible that the track inside the Matroska files has some gaps in it -- jumps in the timecodes with no audio samples to fill them.

This is perfectly normal, e.g. if someone uses mkvmerge's --sync option with a stretch factor > 1 on an audio track (though I don't advice doing that; better results are usually achieved by stretching video and subtitle tracks in the other direction due to players using audio as the synchronization source).

Thank you for your reply and explanation. Currently I am able to solve my problem by:
1. demux the video (24 fps x264) and the audio (5.1 dts)
2. encode the 5.1 dts to 5.1 ac3 with stretching (25 fps to 24 fps)
3. remux the video (24 fps x264) and the audio (5.1 ac3)
4. and the av are perfectly in sync

I already suspected the problem has something to do with frame rate since the out-of-sync getting worst and worst, not constant. So yesterday I check the mkv element header using the mkvmerge. The timecode scaling for both the audio and video track is 1 so I think the stretching was not done in the mkv.

My guess is that the audio stream (5.1 dts) of the original mkv was taken from another source with 25 fps rate. Then the audio stream just remuxed to the mkv with 24 fps video. Is such scenario possible? Is there other possibility?

[Mosu]

The timecode strecth factor in the headers is only one way of stretching timecodes. mkvmerge's --sync option does NOT use it. Instead it directly scales the timecodes. If you have e.g. a video at 25fps (therefore 40ms per frame) and you'd specify a strecth factor of 1.5 then mkvmerge would produce timecodes at 0ms, 60ms, 120ms etc instead of 0ms, 40ms, 80ms etc.

Like I said before I'd advice against stretching audio. Just leave audio be. Modify the video FPS instead, the results are more predictable across devices, players and platforms.

[Kurtnoise]

Hi Mosu,

Does the last mkvmerge is able to create TrackOperation (http://www.matroska.org/technical/specs/index.html#TrackOperation) entries ? If yes, how to do that exactly ?

[Mosu]

No, not yet.

[ynamojn]

The timecode strecth factor in the headers is only one way of stretching timecodes. mkvmerge's --sync option does NOT use it. Instead it directly scales the timecodes. If you have e.g. a video at 25fps (therefore 40ms per frame) and you'd specify a strecth factor of 1.5 then mkvmerge would produce timecodes at 0ms, 60ms, 120ms etc instead of 0ms, 40ms, 80ms etc.

Like I said before I'd advice against stretching audio. Just leave audio be. Modify the video FPS instead, the results are more predictable across devices, players and platforms.

Thanks Mosu. So I can conclude that using the --sync option a 25 fps video will play longer. I am just curious, suppose I have such mkv produce using this --sync option, if I extract the video, will I get a longer playing time or the original one?

The mkv I got it from somewhere else. I just want to convert it to DVD. And the audio portion is making me a headache because it was created probably using the --sync option.

[Mosu]

As the sync option modifies both the timecodes and the default duration you could get a longer-playing video after extraction if the extraction is done into a container (MP4, AVI) and not into a raw bitstream.

However, mkvmerge does not modify certain fields inside the video bitstream. h264 videos can contain an FPS field inside their bitstream as far as I remember, and that one is not touched.

[bin_ch]

Hi,
Is there any easy way to disable header removal compression in mkvmerge without setting each and every track?
There is an option to do this in the GUI, but that option doesn't seem to apply to the CLI version.

Thanks.

[Mosu]

No, there isn't.

[Abradoks]

Hi,
Is there any easy way to disable header removal compression in mkvmerge without setting each and every track?
There is an option to do this in the GUI, but that option doesn't seem to apply to the CLI version.
You can try patched build from that post (http://forum.doom9.org/showthread.php?p=1503876#post1503876).

[bin_ch]

Thanks Mosu for the reply, and Abradoks for the patched build. Looks like a good solution for now.

[robpdotcom]

I received this warning when muxing a video today:

"A block group was found at position 13766262488, but no block element was found inside it. This might make mkvmerge crash."

As far as I can tell, everything went fine. What does this mean?

[Mosu]

I received this warning when muxing a video today:

"A block group was found at position 13766262488, but no block element was found inside it. This might make mkvmerge crash."

As far as I can tell, everything went fine. What does this mean?

A block group usually contains several Matroska elements: reference information (used for frame type distinction: I/P/B frame?), timecode, duration and the actual frame's content. If no frame content is found then that is very curious -- maybe the file is damaged at that part or it was created by a muxer with a bug. As I've never encountered such a file myself I haven't been able to test whether or not mkvmerge works correctly in that case by simply skipping that block group -- hence the warning. If muxing has gone fine for you and the result has been OK then you can simply ignore the warning.

[Mosu]

I just found out: v4.8 (oficial and all test builds) can not identify (-i and identify for mmg) .avi files (any type of avi file). v4.7 works as it should. Win7x64.
The program just does not return anything, and keeps one CPU in 100%.
It I can provide any other info please tell me.
Thank you

One other user reported the same issue, but I haven't been able to reproduce it. In order to get to the bottom of this I've compiled each and every revision between 4.7.0 and 4.8.0. They're all available from http://www.bunkus.org/videotools/mkvtoolnix/win32/debug/ ordered by commit date. If would be great if you could pinpoint which release was the first that started locking up. Thanks.

[pdanpdan]

It would be great if you could pinpoint which release was the first that started locking up.
None of them are working. But http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.7.0.7z is working.
Also, the statically built version from here http://forum.doom9.org/showthread.php?p=1510733#post1510733 worked.
So maybe it's not something in the code but something in the compiling environment.

[Mosu]

Looks that way, indeed. I have upgraded some of the libraries in the meantime, but I don't remember exactly what I updated. Bummer. Thanks for testing, though.

[Mosu]

Hey,

I've released mkvtoolnix v4.9.0. It's mostly a bug fix release with few new features.

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-4.9.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.9.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.9.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.8.0:

2011-07-10 Moritz Bunkus <moritz@bunkus.org>
* Release v4.9.0.

2011-07-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: DV files are recognized as an unsupported container type. Fix for bug 630 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=630).
* mkvmerge: bug fix: Fixed handling block groups in Matroska files with a duration of 0.

2011-07-08 Moritz Bunkus <moritz@bunkus.org>
* mmg: Various compatibility fixes for use with wxWidgets 2.9.x.

2011-06-23 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed building with Sun Studio's C compiler.

2011-06-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: ISO 639-2 terminology language codes are converted to the corresponding bibliography code upon file identification (e.g. 'deu' is converted to 'ger').

2011-06-02 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: The timecode scale is retrieved first before applying it to the segment duration.
* all: Added an Italian translation by Roberto Boriotti and Matteo Angelino (see AUTHORS).

2011-05-28 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed populating the 'compression' drop down box according to what mkvmerge was compiled with.

2011-05-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: When a DTS track is read from a source file that provides timecodes (e.g. Matroska files) then those timecodes will be preserved.

2011-05-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Fixed remuxing certain VC1 video tracks from Matroska files. Fix for bug 636 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=636).

Have fun.

[sneaker_ger]

Thx, but updater says that there is 5.0.0 already available?

[Snowknight26]

H.264 in MKV detection seems to be taking far longer with this new version.

Sample: http://stfcc.org/misc/mkvmerge490.mkv

[GuilhermeAraujo]

Thx, but updater says that there is 5.0.0 already available?

Indeed. An "update window" poped up on the 1st run saying there's a version 5.0.0.

[Chumbo]

H.264 in MKV detection seems to be taking far longer with this new version.

Sample: http://stfcc.org/misc/mkvmerge490.mkv
I've confirmed that this is true. I have a 7MB XviD clip that loads immediately in 4.8.0 and took just over 50 seconds to load in 4.9.0. Let me know if you want that clip. Here's the MediaInfo info:General
Unique ID : 210574927490640108572371383594975910910 (0x9E6B417EAC8112629966D9BDB4E25BFE)
Complete name : clip.mkv
Format : Matroska
Format version : Version 2
File size : 7.70 MiB
Duration : 55s 656ms
Overall bit rate : 1 160 Kbps
Encoded date : UTC 2011-06-15 02:51:24
Writing application : mkvmerge v4.6.0 ('Still Crazy After All These Years') built on Mar 13 2011 18:33:29
Writing library : libebml v1.2.0 + libmatroska v1.1.0

Video
ID : 1
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : Yes
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 55s 639ms
Bit rate : 1 009 Kbps
Width : 624 pixels
Height : 352 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.192
Stream size : 6.69 MiB (87%)
Writing library : XviD 1.0.3 (UTC 2004-12-20)

Audio
ID : 2
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : A_MPEG/L3
Codec ID/Hint : MP3
Duration : 22mn 11s
Bit rate mode : Variable
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 20.3 MiB
Writing library : LAME3.90.
Encoding settings : -m j -V 4 -q 2 -lowpass 17.6 --abr 128
Language : English

[Mosu]

Thx, but updater says that there is 5.0.0 already available?

No, that was an error in the release file on the update server.

[Mosu]

H.264 in MKV detection seems to be taking far longer with this new version.

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-353-setup.exe

[Carpo]

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-353-setup.exe

bad little moo cow!!!! :devil:

[Chumbo]

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-353-setup.exe
Thanks Mosu.

[Mosu]

None of them are working. But http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.7.0.7z is working.
Also, the statically built version from here http://forum.doom9.org/showthread.php?p=1510733#post1510733 worked.
So maybe it's not something in the code but something in the compiling environment.

Alright, I finally figured it out. The following build should be OK again: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-354-setup.exe

[LeMoi]

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-353-setup.exe

Thanks, i was afraid it was not working any more !!

[pdanpdan]

:D It's working - thank you.

[Mosu]

Hey,

I've released mkvtoolnix v4.9.1. It fixes two servere bugs that were introduced with v4.9.0.

Here are the usual links:

...to the homepage: http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code: http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-4.9.1.tar.bz2
...to the Windows installer: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.9.1-setup.exe
...to the 7zip archive for Windows: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.9.1.7z

Most of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are still being built and will be available later.

Here's the full ChangeLog since release 4.9.0:

2011-07-11 Moritz Bunkus <moritz@bunkus.org>
* Released v4.9.1.
* mkvmerge: bug fix: Fixed endless loop when reading AVI files on Windows if MKVToolNix was compiled with a gcc mingw cross compiler v4.4.x. Fix for bug 642 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=642).
* mkvmerge: bug fix: Fixed long file identification time caused by DV detection. Fix for bug 641 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=641).

Have fun.

[SamuriHL]

Windows installer not found?

[Mosu]

It was still being built. The upload should be done in a few minutes.

[SamuriHL]

Ok, thanks!

[Motenai Yoda]

The Italian translators have missed something.
http://img7.imagebanana.com/img/d798ro5y/thumb/miss1.png (http://www.imagebanana.com/view/d798ro5y/miss1.png) http://img7.imagebanana.com/img/mwjes0hc/thumb/miss2.png (http://www.imagebanana.com/view/mwjes0hc/miss2.png)

[b66pak]

@Mosu thanks a lot...it looks like your site is down...
_

[Mosu]

The Italian translators have missed something.

The Italian translation is still work in progress, yes.

[Mosu]

@Mosu thanks a lot...it looks like your site is down...
_

I know, but I don't know what the issue is yet. I'll try to get the server up and running again as soon as possible.

[Mosu]

The site is back up again.

[MrVideo]

Simple question...

Don't know if this has been previous mentioned somewhere, but is there a tool out there that will display the audio header compression setting? Is there an option within mkvmerge? Does MediaInfo display the setting?

[Zenitram]

A bit out of topic...

Don't know if this has been previous mentioned somewhere, but is there a tool out there that will display the audio header compression setting? Is there an option within mkvmerge? Does MediaInfo display the setting?

MediaInfo displays it:
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Muxing mode : Header stripping
Codec ID : A_AC3
Duration : 59mn 29s
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 : -28ms
Stream size : 163 MiB
Title : English AC3 5.1
Language : English

MediaInfo has its own Doom9 forum topic (http://forum.doom9.org/showthread.php?p=1513063)

[MrVideo]

Not exactly off topic, as the file is produced by mkvmerge. Even though MediaInfo does have its own thread, normal forum rules don't like the posting of the same question in multiple threads. Since the main subject of this question deals with mkvmerge output, I placed the question here.

That said, I really appreciate the response. Thanks.

[Mosu]

mkvinfo can display it as well. The information you're looking for is the ContentEncodings element. If it exists and contains a sub-sub element called "Algorithm" with a value of "3" then header removal compression is active.

[Merick]

I have a folder full dual audio files, whoever encoded these messed up the streams - they all show up as "undetermined" instead of jpn or eng. Is there any way I can batch process the entire folder to rename the streams without having to load them all into mvkmerg gui?

[robpdotcom]

Open mkvMergeGUI, then open the header editor (File > Header Editor). Drag the file into the editor and you will find options to assign a language and/or name the tracks. Once you make the changes, it only takes a second to save them - no need for re-muxing.

[MrVideo]

mkvinfo can display it as well. The information you're looking for is the ContentEncodings element. If it exists and contains a sub-sub element called "Algorithm" with a value of "3" then header removal compression is active.

Thanks for the info.

While looking at the files with MediaInfo, a couple of us saw the problem. The issue is that a person tries to play some mkv files on his TV, but the TV complains about an incompatible audio codec. We figured, at first, that it was the header compression issue, but none of the files had header compression.

What we noticed is the files not packaged with mkvmerge didn't work. They were marked as being done by x264 or unknown. Repackaging with mkvmerge fixed the problem.

[Mosu]

I have a folder full dual audio files, whoever encoded these messed up the streams - they all show up as "undetermined" instead of jpn or eng. Is there any way I can batch process the entire folder to rename the streams without having to load them all into mvkmerg gui?

Batch processing can be done easily with mkvpropedit and a little bit of scripting (e.g. with a shell or any scripting language you're comfortable with). Also see http://www.bunkus.org/videotools/mkvtoolnix/faq.html#batch_muxing_in_mmg

[Merick]

Thanks, this did it:

for %%X in (*.mkv) do c:\mkvtoolnix\mkvpropedit "%%X" --edit track:a1 --set flag-default=0 --set language=eng --edit track:a2 --set flag-default=1 --set language=jpn

[Thunderbolt8]

has there been any change recently in regards of tag(.xml) files?

I tried to add a tag xml file to my mux, together with a chapter xml file, but the tags are not to be found in the output.

edit: I guess the value for <EditionUID> must be the same in both files?

[Mosu]

Nothing has changed regarding tag handling. Yes, the EdititonUID must be the same if you want the chapter editions to be merged.

[Thunderbolt8]

that was which was wrong then. nvm -.-

[banzemanga]

Are the sequence headers mentioned on this thread (http://forum.doom9.org/showthread.php?t=128768) still being removed for AVC/h.264?

I try muxing raw AVC/h.264 files into MKV container using mkvmerge and when i demux it, it get a smaller raw video file. I can only think that the sequence headers mentioned before are still being removed. Note that i mux my MKV files with the "--compression 'none'" trigger so there should be no headers removed due to compression artifacts.

[Video Dude]

I had the same question regarding this post:

Yes, mkvmerge removes the sequence headers and stores the first ones that it finds in the CodecPrivate. Yes, I know that this a problem with changing sequence headers in the middle of the stream, and yes, I plan to change that someday. That being said, I don't spend any time coding mkvtoolnix at the moment, so your guess is as good as mine when mkvmerge will handle such streams correctly.

Does mkvmerge still remove the sequence headers?

[Mosu]

Nothing has changed.

[sneaker_ger]

What else does mkvmerge change?

Here's a sample:
https://rapidshare.com/files/384744953/iterations.7z

I muxed and demuxed a source a few times and all resulting raws differed from each other. ( source.h264 -> 1.mkv -> 1.h264 -> 2.mkv -> 2.h264 -> .... -> 5.h264 )

[Mosu]

Sorry, I don't have the time or motivation to investigate.

[Chetwood]

I will add such an option in the near future though so that you don't have to edit the source files with the chapter editor before appending them.
Speaking of which, when merging demuxed streams from 2 BDs, how do I append the chapter file of the second BD so that the MKV has all chapters from both discs in proper order? I'm trying to merge the two LOTR-Extended Edition BDs to test how my standalones handle huge files of 70 GB. Thx.

[Mosu]

One way would be to merge each BD separately (including chapters) into its own Matroska file. Then append the two Matroska file into the resulting file. That way mkvmerge will adjust the chapters of the second one automatically. Other than that you'll probably have to edit the chapter files manually.

[Chetwood]

I was afraid you were gonna say that ;) I'm gonna try both methods but I'm wondering what's the difference here cause MKVToolnix already is capable of doing both:

1) appending demuxed streams (.264, .dts, .idx, .sup, etc.) and
2) appending 2 chapter files (when muxed to mkv containers)

So how come, I can't do both, given the chapter files already are present in Matroska Chapter XML file format? Thanks again.

[Mosu]

Because a XML chapter file is not an input file but can only be used with the "--chapters" option.

However, you could try something similar:

1. Create two Matroska files that only contain chapters.
2. Append everthing, e.g. mkvmerge -o out.mkv part1.h264 + part2.h264 part1.dts + part2.dts chapters-part1.mkv + chapters-part2.mkv

Maybe this will work, too.

[Chetwood]

OK, I'm doing baby steps to see how far I get. For starters, I extracted the last chapter of disc 1 and the first of disc 2 with DVDFab and demuxed with TSMuxerGI. Since both have the same amount of streams, appending them with MKVToolnix worked fine. However, when the MKV reaches the disc 2 part, audio and video are out of sync. Muxing only the streams from disc 2, everything is in sync so I guess, MKVToolnix somehow introduces a delay while appending. Any suggestions?

[Mosu]

part1.h264 part1.dts part1.idx part1.xml > part1.mkv
part2.h264 part2.dts part2.idx part2.xml > part2.mkv

part1.mkv + part2.mkv > final.mkv

[Chetwood]

Despite these error messages

Warning: The track number 1 from the file 'D:\2.mkv' can probably not be appended correctly to the track number 1
from the file 'D:\1.mkv':
The codec's private data does not match. Both have the same length (69) but different content.
Warning: The track number 2 from the file 'D:\2.mkv' can probably not be appended correctly to the track number 2
from the file 'D:\1.mkv':
Warning: The track number 3 from the file 'D:\2.mkv' can probably not be appended correctly to the track number 3
from the file 'D:\1.mkv':

Please make sure that the resulting file plays correctly the whole time.
The author of this program will probably not give support for playback issues with the resulting file.
appending apparently worked fine. Gonna try it on the entire movie. Thx.

[NanoBot]

Hi,

Speaking of which, when merging demuxed streams from 2 BDs, how do I append the chapter file of the second BD so that the MKV has all chapters from both discs in proper order? I'm trying to merge the two LOTR-Extended Edition BDs to test how my standalones handle huge files of 70 GB. Thx.

This post primarly does not have something to do with mkvtoolnix, but since I am doing the same thing just ATM like Chetwood one advice from me:

Be aware of the fact that the video track and the audio tracks of the first BDs, at least from "The Fellowship of the ring" and "The two towers", do not have the same playtime. I can't speak about "The return of the king", because I don't have demuxxed those BDs yet. After decoding the audiotracks from DTS-MA to wavs, since I am reencoding them to 5.1 flac, I found the following playtimes:

On the first BD of "The fellowship", the playtime of the video track is 1:45:43.421, while the playtime of the audiotracks is only 1:45:42:336. Therefore you need to add 1085ms of silence to the end of the audiotracks before merging with the second BD, otherwise the audio will be out of sync from the start of the second part.

The same problem applies to "The two towers", here the videotrack of the first BD has a playtime of 1:46:39.185, while the audio is a few 100ms longer. I can't remember the exact audio playtime anymore, since I already successfully created the 5.1 flac and therefore already deleted the wav-files. Nevertheless, with this BD you need to shorten the audiotracks by cutting away a few 100 ms at the end to get a playtime of 1:46:39.185.

It is likely that a playtime correction of the audio tracks of the first BD will also be neccessary when concenating the two parts of "The return of the king".

A little bit more off topic: Does anyone had a look into a wav-file of the german BC track from "The two towers" ? This one looks really borked to me, while the english BC looks ok. I really wonder what kind of quality assurance, if any, the producers of these bluray set have. First, they had the problem with the wrong pitch of the german audio track, and now, on the "corrected" version, the german BC is borked.

C.U. NanoBot

[Chetwood]

This post primarly does not have something to do with mkvtoolnix
Maybe a mod can move these posts over to a new thread in 'Advanced authoring' or something.

Be aware of the fact that the video track and the audio tracks of the first BDs, at least from "The Fellowship of the ring" and "The two towers", do not have the same playtime.
Thanks, I hadn't realized this so far but I guess that's where my error messages came from.

It is likely that a playtime correction of the audio tracks of the first BD will also be neccessary when concenating the two parts of "The return of the king".
Well, I did as Mosu suggested and despite the error messages and no dealy being added, the tracks were completely in sync.

First, they had the problem with the wrong pitch of the german audio track, and now, on the "corrected" version, the german BC is borked.
BC? I was planning on watching the entire movies once I was finished encoding. I really did not expect them to screw it up again. BTW, why did you go for FLAC?

[NanoBot]

BC = Back center, and my statement that the german BC is "borked" is due to the fact, that this channel has a vague, but constant noise at a DC offset of about -66dB in the "positive" sample area throughout both BDs of the "Two towers". "The fellowship of the ring" and "The return the king" do not have this error, here all audio tracks are "clean". If you want to have a look into it, just decode the german DTS-MA track to wavs ( using eac3to together with the arcsoft decoder ) and load the german BC into audacity.

Fortunately, the level of this noise is so weak that you will barely notice it when not listening to the german BC only using a headphone, but looking at the decoded wav shows this constant noise. My best guess is that the producer of the german audio tracks used some kind of equipment with a defective capacitator in it, because that would result in the noise and dc offset I have found. But after my understanding of a quality assurance, such errors should be found and corrected during the authoring and production process before sending the masters to the BD pressing plant.

I have two reasons why I am reencondig to flac: Flac is patent free and a flac file is approximately 20% smaller than a DTS-MA file. Therefore I always reencode lossless formats to flac when remuxxing BDs to Matroska.

[Thunderbolt8]

merging lotr works best using eac3to

eac3to part1.m2ts+part2.m2ts and then all usual options etc.

fixes audio automatically so you get 1 big file for video and another for audio which are both in sync with each other.

after that just mux them together with mkvtoolnix

the new german BD is supposed to be fine btw.

[sneaker_ger]

the error messages and no dealy being added, the tracks were completely in sync.

When appending two mkv files, mkvmerge will make sure that the sync is not lost by default. But there will be gaps in all tracks but the longest of part 1.

There's also "--append-mode track", where there are no gap, but you have to manually edit them first like suggested by NanoBot to make sure sync is not lost. That also goes for appending the raw tracks, instead of creating intermediate mkv files like suggested by Mosu.

[Chetwood]

I've done it now as Mosu suggested
part1.h264 part1.dts part1.idx part1.xml > part1.mkv
part2.h264 part2.dts part2.idx part2.xml > part2.mkv

part1.mkv + part2.mkv > final.mkv
for the entire first movie rather than 2 chapters using mmg.exe (i.e. the GUI) under Win and without any extra tricks. Video, audio and subs are in sync during the course of the entire movie! BUT chapters are off by a longshot. Curiously enough only those of disc 1! As soon as the first scene of disc 2 starts, all chapters are fine.:confused:

[mindbomb]

were there improvements made to the zlib compression? i just compressed some subtitles to less than half their original size. Is this typical? I don't recall it being so potent.

[Mosu]

were there improvements made to the zlib compression? i just compressed some subtitles to less than half their original size. Is this typical? I don't recall it being so potent.

No. Subtitles just happen to contain a lot of redundancy that any compressing algorithm is very happy about.

[Lincoln Burrows]

When are you going to add support for the FLV format? Or it's not possible to append FLV files using the MKV container? *

* Edit: Just found a way of doing that:

http://forum.doom9.org/showpost.php?p=1519867&postcount=13

It seems to be working and now I can append the generated MKV files.

[Mosu]

FLV support is in the works from a third party that also created a TS demuxer. Both need considerable work though.

Also: FLV support will most likely be limited to h264 video and AAC audio (maybe other audio types as well); definitely not the older FLV files with h263 video.

[Chumbo]

There are some FLV tools available here: http://www.moitah.net/
You should be able to use the extract tool to get the elementary streams and then mux them to MKV.

[sneaker_ger]

"--engage remove_bitstream_ar_info" seems to be broken (i.e. does nothing, AR is still kept) atm - can anyone confirm?
Would be nice if mkvmerge would change the AR (although I guess you are probably against this, like you were very reluctant to keep the AR info since you consider container > bitstream info, which I agree with.)

[Mosu]

It's possible that some operations (e.g. h264 read from Matroska files if the codec ID is "V_MPEG4/ISO/AVC") don't go through the code path at all that reacts to "--engage remove_bitstream_ar_info". It should work every time a "raw" ES has to be converted to the Matroska way of storing the info; e.g. if it is read from a raw .h264 file, from an AVI, from an MPEG program stream or from a Matroska file that stores the AVC track in MS compatibility mode (codec ID "V_MS/VFW/FOURCC" with FourCC "AVC1").

[Mosu]

Oh, and my long term goal is to always make the bitstream information match the container information regarding both the aspect ratio and the FPS/default duration. But as I'm trying to get the MPEG transport stream support working passably well this is a bit on the back-burner.

My current priority list, in case anyone is interested: basic MPEG TS support; basic FLV support; bugs 434 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=434), 654 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=654) (which both have to do with h264 tracks and timing information; I will take care of AR information in the bitstream at the same time I guess); bug 652 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=652). Not necessarily in that order.

[sneaker_ger]

Those plans sound very good.
And yes, I was using an mkv source. ES seems to work. Thx, I didn't think of that.

[robpdotcom]

Those plans sound very good.

Agreed, especially the TS support. BTW: Does TS support also mean M2TS support?

[Mosu]

Agreed, especially the TS support. BTW: Does TS support also mean M2TS support?

They're the same, yes.

[sneaker_ger]

There's also a CFR/VFR info in H.264 tracks, would be nice if those were set correctly, too, when you find the time to work on these. (i.e. CFR for --default-duration and VFR for timecode file input.)

[Chumbo]

They're the same, yes.
Thanks Mosu, this is great news. :)

[robpdotcom]

Great new indeed. I'm looking forward to loading the M2TS files from a disc, and muxing them straight into an mkv.

I don't guess it'll be able to open seamless branching playlists, but maybe we could append them manually?

[nautilus7]

mosu,

Can you have a look into this sample (http://www.mediafire.com/?3bedr69hrjlh5r2)? It's from BBC's documentary "Yellowstone" (1080i 60/1.001fps frame blended from 25fps original source to fit blu-ray specs).
What is the proper fps to mux it with? I believe 30/1.001 as it has 29,97 frames per sec. But then it plays back with half speed. If I select 60/1.001 it 's ok.

[Mosu]

You've given yourself the correct answer already. Just use what works.

[nautilus7]

So, for interlaced content I have to put the fps based the number of fields but for progressive I put the fps based on number of frames? That's inconsistent imho.

[Mosu]

That's how it is, at the moment, yes. mkvmerge uses the "--default-duration" parameter for setting the duration for each "packet" output, and for interlaced content that's one field and not one frame. For audio it also has nothing to do with "...per second"; ok you don't usually use "--default-duration" for audio tracks. The input field in the GUI is only labeled "FPS" because people are used to that term.

[Chetwood]

So, I'm back at trying to append two MKVs and as I wrote above, everything's in sync except for the chapters. I've checked the merged file with Mediainfo which shows me there are two menus (!) in there, #1 being the chapter file of part2.mkv and #2 being the chapter file of part1.mkv. Opening final.mkv in MKVToolnix however shows only 1 chapter file which upon extraction turns out to be the one of part2.mkv. Also, is there any way to determine the exact length of the movie (.264 stream) in MKVToolnix, like hh:mm:ss:fff? Thanks.

[robpdotcom]

Someone taught me this trick the other day, and I have verified that it works:

To append 2 chapter files, the chapters must have different ID's.

Drag one of the files into the chapter editor box in mkvmerge (I would use part 2). Click on a chapter, and look for the chapter ID in one of the boxes below. Change the ID of all of the chapters. I'm guessing you used makemkv to create the files, so the ID's will probably be: 1, 2, 3, etc. I change those to something like 101, 102, 103, etc. It doesn't matter what the numbers are, and they don't have to be in order - the only thing that matters is that every chapter has a unique ID (you could even just randomly type numbers into the boxes).

At this point, if you like, you could also rename the chapters. So if the first part has chapter names 1-12, you could change the names in part 2 to 13, 14, etc.

After you change all of the ID's, click on the Chapter Editor menu, select "Save to Matroska File", and then select the file you loaded into the chapter editor.

Then, try appending the files again.

[LeMoi]

I tried twice to append files with their chapters, and after I reported a bug to Mosu (http://forum.doom9.org/showthread.php?p=1444255#post1444255), he fixed it and i managed to append the files with their chapters, it should work fine now...

[Chumbo]

@Mosu,
If I may bug you again and ask if you know if this has been fixed yet please? Thanks.
@Mosu,
Has anything been done about this issue from the old thread? It's still an issue. By the way, MKVs created by MakeMKV don't have this issue. Thanks.

Remuxing telecined material (Tried NTSC telecined MPEG2 from DVD) doesn't seem to work anymore with 3.3.0... video speed is not in sync. Tried specifying fps (24/1.001 and 30/1.001) but doesn't work.

I've forwarded the problem to the person who contributed the new MPEG timecode calculation method. I hope he can shed some light on this problem.

[Mosu]

No, it hasn't been fixed, and my guess is that it won't be, sorry.

[Chetwood]

it should work fine now...
I'm on 4.9.1 and unfortunately it does not.

To append 2 chapter files, the chapters must have different ID's.
Thanks but I have demuxed all streams with TSMuxerGUI and extracted the chapter files to .xml with ChapterGrabber. When opened in mmg's chapter editor, each of it has its own ID.

So I've tried to merge the chapters myself by converting them to the format listed in the mmg guide:

CHAPTER01=00:00:00.000
CHAPTER01NAME=Intro
CHAPTER02=00:01:00.000
CHAPTER02NAME=Act 1

That failed as well cause mmg does not accept my chapter file, despite me having trimmed down the digits after the dot to 3 (why are there 7 anyway?).

[Chumbo]

No, it hasn't been fixed, and my guess is that it won't be, sorry.
Is the code available to fix if another developer knows how to fix it? Maybe someone would be kind enough to patch it? I'd do it myself if I knew how.

[Mosu]

mkvtoolnix is completely OpenSource, sure. The code in question is the MPEG handling stuff in src/mpegparser.

[Chetwood]

Mosu, any idea why my plain text chapter file is not accepted though it appears to be exactly on specs?

[Mosu]

Because you made a mistake. Or because the moon is not in the right phase.

Read: Please provide the actual file so that I don't have to guess, thanks :)

[Chetwood]

Right. Please see attachment.

[Mosu]

While we wait for the attachment to be approved by some moderator I'd guess that you're trying to use it as an input file, and not with the "--chapters" option (or mmg's corresponding GUI control on the "global" tab).

[Chetwood]

Actually, I am using mmg's global tab where I'm browsing for the chapter file. I've also tried ANSI vs UTF-8 but to no avail.

[Mosu]

Still not approved. You could also send me an email with the chapter file to moritz@bunkus.org.

[Guest]

It's approved now.

[Mosu]

Thanks, neuron2.

The last two entries don't have a running number. The "name" lines must begin with "CHAPTERxxNAME=" and not "CHAPTERNAMExx=".

[Chetwood]

Sorry, I uploaded the botched file instead of the fixed one. Here is my current file that still won't get muxed:


CHAPTER01=00:00:00.000
CHAPTERNAME01=Prolog: Ein Ring, sie zu knechten
CHAPTER02=00:07:36.789
CHAPTERNAME02=Ueber Hobbits
CHAPTER03=00:10:35.551
CHAPTERNAME03=Das Auenland
CHAPTER04=00:15:39.855
CHAPTERNAME04=Sehr alte Freunde
CHAPTER05=00:19:58.488
CHAPTERNAME05=Ein lang erwartetes Fest
CHAPTER06=00:25:32.614
CHAPTERNAME06=Lebwohl, lieber Bilbo
CHAPTER07=00:29:57.378
CHAPTERNAME07=Halte ihn geheim, bewahre ihn gut
CHAPTER08=00:32:10.678
CHAPTERNAME08=Isildurs Aufzeichnen
CHAPTER09=00:34:51.798
CHAPTERNAME09=Im "Gruenen Drachen"
CHAPTER10=00:36:18.176
CHAPTERNAME10=Der Schatten der Vergangenheit
CHAPTER11=00:45:04.159
CHAPTERNAME11=Der Zug der Elben
CHAPTER12=00:46:44.301
CHAPTERNAME12=Saruman der Weisse
CHAPTER13=00:51:21.411
CHAPTERNAME13=Querfeldein zu den Pilzen
CHAPTER14=00:55:12.434
CHAPTERNAME14=Die Bockenburger Faehre
CHAPTER15=00:57:30.071
CHAPTERNAME15=Im Gasthaus "Zum taenzelnden Pony"
CHAPTER16=01:03:31.516
CHAPTERNAME16=Die Nazgul
CHAPTER17=01:07:16.115
CHAPTERNAME17=Die Mueckenwassermoore
CHAPTER18=01:08:53.587
CHAPTERNAME18=Die Zerstoerung Isengards
CHAPTER19=01:10:35.940
CHAPTERNAME19=Ein Messer im Dunkeln
CHAPTER20=01:15:15.385
CHAPTERNAME20=Die Verliese Isengards
CHAPTER21=01:17:46.620
CHAPTERNAME21=Flucht zur Furt
CHAPTER22=01:24:11.546
CHAPTERNAME22=Bruchtal
CHAPTER23=01:26:12.500
CHAPTERNAME23=Viele Begegnungen
CHAPTER24=01:29:41.584
CHAPTERNAME24=Das Schicksal des Rings
CHAPTER25=01:33:14.672
CHAPTERNAME25=Das zerbrochene Schwert
CHAPTER26=01:35:54.081
CHAPTERNAME26=Der Abendstern
CHAPTER27=01:37:32.972
CHAPTERNAME27=Elronds Rat


BTW, how come the XML chapter file extracted with ChapterGrabber has 7 digits behind the dot, e.g. 00:10:35.551577700?

[Mosu]

The "name" lines must begin with "CHAPTERxxNAME=" and not "CHAPTERNAMExx=".

Please read my whole post.

[NanoBot]

Hi,

Cheetwood, the following might be helpful to you, nevertheless I created those files with "chapadd" available here: http://forum.doom9.org/showthread.php?p=1403557#post1403557
I compiled the source with "mingw" and it works fine.


CHAPTER01=00:00:00.000
CHAPTER01NAME=Prolog: Ein Ring, sie zu knechten
CHAPTER02=00:07:36.789
CHAPTER02NAME=Über Hobbits
CHAPTER03=00:10:35.551
CHAPTER03NAME=Das Auenland
CHAPTER04=00:15:39.855
CHAPTER04NAME=Sehr alte Freunde
CHAPTER05=00:19:58.488
CHAPTER05NAME=Ein lang erwartetes Fest
CHAPTER06=00:25:32.614
CHAPTER06NAME=Lebwohl, lieber Bilbo
CHAPTER07=00:29:57.378
CHAPTER07NAME=Halte ihn geheim, bewahre ihn gut
CHAPTER08=00:32:10.678
CHAPTER08NAME=Isildurs Aufzeichnen
CHAPTER09=00:34:51.798
CHAPTER09NAME=Im "Grünen Drachen"
CHAPTER10=00:36:18.176
CHAPTER10NAME=Der Schatten der Vergangenheit
CHAPTER11=00:45:04.159
CHAPTER11NAME=Der Zug der Elben
CHAPTER12=00:46:44.301
CHAPTER12NAME=Saruman der Weisse
CHAPTER13=00:51:21.411
CHAPTER13NAME=Querfeldein zu den Pilzen
CHAPTER14=00:55:12.434
CHAPTER14NAME=Die Bockenburger Fähre
CHAPTER15=00:57:30.071
CHAPTER15NAME=Im Gasthaus "Zum tänzelnden Pony"
CHAPTER16=01:03:31.516
CHAPTER16NAME=Die Nazgul
CHAPTER17=01:07:16.115
CHAPTER17NAME=Die Mückenwassermoore
CHAPTER18=01:08:53.587
CHAPTER18NAME=Die Zerstörung Isengards
CHAPTER19=01:10:35.940
CHAPTER19NAME=Ein Messer im Dunkeln
CHAPTER20=01:15:15.385
CHAPTER20NAME=Die Verliese Isengards
CHAPTER21=01:17:46.620
CHAPTER21NAME=Flucht zur Furt
CHAPTER22=01:24:11.546
CHAPTER22NAME=Bruchtal
CHAPTER23=01:26:12.500
CHAPTER23NAME=Viele Begegnungen
CHAPTER24=01:29:41.584
CHAPTER24NAME=Das Schicksal des Rings
CHAPTER25=01:33:14.672
CHAPTER25NAME=Das zerbrochene Schwert
CHAPTER26=01:35:54.081
CHAPTER26NAME=Der Abendstern
CHAPTER27=01:37:32.972
CHAPTER27NAME=Elronds Rat
CHAPTER28=01:45:43.421
CHAPTER28NAME=Gilreans Grab
CHAPTER29=01:46:59.246
CHAPTER29NAME=Bilbos Geschenke
CHAPTER30=01:48:42.641
CHAPTER30NAME=Die Gefährten brechen auf
CHAPTER31=01:50:00.052
CHAPTER31NAME=Der Ring geht nach Süden
CHAPTER32=01:53:05.863
CHAPTER32NAME=Der Pass der Caradhras
CHAPTER33=01:57:52.149
CHAPTER33NAME=Moria
CHAPTER34=02:04:17.534
CHAPTER34NAME=Reise durch die Dunkelheit
CHAPTER35=02:10:47.882
CHAPTER35NAME=Balins Grab
CHAPTER36=02:20:12.613
CHAPTER36NAME=Die Brücke von Khazad-dum
CHAPTER37=02:29:54.069
CHAPTER37NAME=Lothlorien
CHAPTER38=02:33:06.719
CHAPTER38NAME=Caras Galadhon
CHAPTER39=02:40:23.739
CHAPTER39NAME=Galadriels Spiegel
CHAPTER40=02:46:03.746
CHAPTER40NAME=Der kämpfende Uruk-hai
CHAPTER41=02:47:45.097
CHAPTER41NAME=Abschied von Lorien
CHAPTER42=02:53:07.627
CHAPTER42NAME=Der Grosse Strom
CHAPTER43=02:57:59.878
CHAPTER43NAME=Parth Galen
CHAPTER44=03:04:27.640
CHAPTER44NAME=Die Wege trennen sich
CHAPTER45=03:11:43.576
CHAPTER45NAME=Boromirs Abschied
CHAPTER46=03:14:25.904
CHAPTER46NAME=Die Strasse gleitet fort
CHAPTER47=03:20:44.074
CHAPTER47NAME=Abspann
CHAPTER48=03:28:24.576
CHAPTER48NAME=Fan Club Abspann



CHAPTER01=00:00:00.000
CHAPTER01NAME=In den Tiefen von Moria
CHAPTER02=00:04:08.748
CHAPTER02NAME=Elbenseil
CHAPTER03=00:06:10.828
CHAPTER03NAME=Sméagols Zähmung
CHAPTER04=00:14:44.967
CHAPTER04NAME=Die Uruk-Hai
CHAPTER05=00:17:06.608
CHAPTER05NAME=Die drei Jäger
CHAPTER06=00:19:17.948
CHAPTER06NAME=Die Westfold brennt
CHAPTER07=00:23:07.094
CHAPTER07NAME=Die Schlacht an den Furten des Isen
CHAPTER08=00:23:58.311
CHAPTER08NAME=Die Verbannung von Eomer
CHAPTER09=00:27:09.044
CHAPTER09NAME=Auf der Fährte der Uruk-Hai
CHAPTER10=00:28:03.181
CHAPTER10NAME=Das Nachtlager im Fangorn-Wald
CHAPTER11=00:31:38.229
CHAPTER11NAME=Die Reiter von Rohan
CHAPTER12=00:35:45.518
CHAPTER12NAME=Merrys und Pippins Schicksal
CHAPTER13=00:38:17.878
CHAPTER13NAME=Baumbart
CHAPTER14=00:41:47.796
CHAPTER14NAME=Die Durchquerung der Sümpfe
CHAPTER15=00:50:49.755
CHAPTER15NAME=Der Weiße Reiter
CHAPTER16=00:58:19.412
CHAPTER16NAME=Das Lied von den Entfrauen
CHAPTER17=01:00:40.178
CHAPTER17NAME=Der Erbe der Numenor
CHAPTER18=01:02:48.306
CHAPTER18NAME=Das Schwarze Tor ist versperrt
CHAPTER19=01:08:05.998
CHAPTER19NAME=Entwasser
CHAPTER20=01:12:41.732
CHAPTER20NAME=Der König der Goldenen Halle
CHAPTER21=01:24:17.343
CHAPTER21NAME=Theodens Begräbnis
CHAPTER22=01:25:41.636
CHAPTER22NAME=Simbelmyne auf den Hügelgräbern
CHAPTER23=01:27:34.332
CHAPTER23NAME=Die Entscheidung des Königs
CHAPTER24=01:30:45.523
CHAPTER24NAME=Brego
CHAPTER25=01:32:30.586
CHAPTER25NAME=Barahis Ring
CHAPTER26=01:34:31.040
CHAPTER26NAME=Eine Tochter von Königen
CHAPTER27=01:35:57.042
CHAPTER27NAME=Die Flucht aus Edoras
CHAPTER28=01:37:02.316
CHAPTER28NAME=Die Wälder Ithiliens
CHAPTER29=01:38:43.959
CHAPTER29NAME=Gollum und Smeagol
CHAPTER30=01:41:14.818
CHAPTER30NAME=Kräuter und Kaninchenpfeffer
CHAPTER31=01:46:39.185
CHAPTER31NAME=Zwergenfrauen
CHAPTER32=01:47:21.978
CHAPTER32NAME=Einer der Dunedain
CHAPTER33=01:49:51.836
CHAPTER33NAME=Der Abendstern
CHAPTER34=01:54:58.392
CHAPTER34NAME=Die Wölfe von Isengart
CHAPTER35=02:01:36.581
CHAPTER35NAME=Helms Klamm
CHAPTER36=02:04:16.700
CHAPTER36NAME=Isengarts Heer zieht in die Schlacht
CHAPTER37=02:06:53.148
CHAPTER37NAME=Die Gunst der Valar
CHAPTER38=02:08:30.704
CHAPTER38NAME=Arwens Schicksal
CHAPTER39=02:12:13.468
CHAPTER39NAME=Die Weissagung in Lorien
CHAPTER40=02:14:39.447
CHAPTER40NAME=Das Fenster nach Westen
CHAPTER41=02:18:29.051
CHAPTER41NAME=Die Söhne des Statthalters
CHAPTER42=02:23:08.622
CHAPTER42NAME=Der verbotene Weiher
CHAPTER43=02:30:30.313
CHAPTER43NAME=Aragorns Rückkehr
CHAPTER44=02:36:03.563
CHAPTER44NAME=Entthing
CHAPTER45=02:37:23.435
CHAPTER45NAME=Die Glitzernden Höhlen
CHAPTER46=02:40:31.706
CHAPTER46NAME="Wo sind Ross und Reiter?"
CHAPTER47=02:42:16.436
CHAPTER47NAME="Nicht so hastig, Herr Meriadoc!"
CHAPTER48=02:43:07.111
CHAPTER48NAME=Das Heer der Eldar
CHAPTER49=02:46:41.200
CHAPTER49NAME=Die Schlacht um die Hornburg
CHAPTER50=02:53:03.582
CHAPTER50NAME=Altes Entisch
CHAPTER51=02:54:40.637
CHAPTER51NAME=Die Bresche im Klammwall
CHAPTER52=02:58:05.759
CHAPTER52NAME=Das Entthing trifft eine Entscheidung
CHAPTER53=02:59:50.906
CHAPTER53NAME=Rückzug in die Hornburg
CHAPTER54=03:05:53.393
CHAPTER54NAME=Meister Peregrins Plan
CHAPTER55=03:07:18.478
CHAPTER55NAME=Osgiliath
CHAPTER56=03:07:53.221
CHAPTER56NAME=Der letzte Marsch der Ents
CHAPTER57=03:10:22.745
CHAPTER57NAME=Die Attacke der Nazgûl
CHAPTER58=03:12:54.730
CHAPTER58NAME=Vorwärts Eorlingas!
CHAPTER59=03:17:33.217
CHAPTER59NAME=Isengart wird geflutet
CHAPTER60=03:19:59.571
CHAPTER60NAME=Geschichten, die wichtig sind...
CHAPTER61=03:24:44.856
CHAPTER61NAME=Der Fangorn Wald kommt nach Helms Klamm
CHAPTER62=03:25:37.409
CHAPTER62NAME=Der Endstand
CHAPTER63=03:26:17.949
CHAPTER63NAME=Treibgut und Beute
CHAPTER64=03:28:21.740
CHAPTER64NAME=Der Abschied von Faramir
CHAPTER65=03:30:51.598
CHAPTER65NAME="Der Kampf um Mittelerde steht bevor"
CHAPTER66=03:32:31.281
CHAPTER66NAME=Gollums Plan
CHAPTER67=03:34:55.425
CHAPTER67NAME=Abspann
CHAPTER68=03:43:51.710
CHAPTER68NAME=Fan Club Abspann



CHAPTER01=00:00:00.000
CHAPTER01NAME=Der Ringfund
CHAPTER02=00:06:24.342
CHAPTER02NAME=Wanderung zum Scheideweg
CHAPTER03=00:09:21.394
CHAPTER03NAME=Der Weg nach Isengart
CHAPTER04=00:11:21.847
CHAPTER04NAME=Die Stimme Sarumans
CHAPTER05=00:18:23.310
CHAPTER05NAME=Die Rückkehr nach Edoras
CHAPTER06=00:23:05.008
CHAPTER06NAME=Gollums Schurkerei
CHAPTER07=00:27:03.330
CHAPTER07NAME=Eowyns Traum
CHAPTER08=00:29:00.697
CHAPTER08NAME=Der Palathir
CHAPTER09=00:37:06.432
CHAPTER09NAME=Arwens Blick in die Zukunft
CHAPTER10=00:40:02.566
CHAPTER10NAME=Narsil wird wieder neu geschmiedet
CHAPTER11=00:42:03.229
CHAPTER11NAME=Minas Tirith
CHAPTER12=00:47:52.202
CHAPTER12NAME=Der Fall Gondors
CHAPTER13=00:50:18.640
CHAPTER13NAME=Die Wegscheide des Gefallenen Königs
CHAPTER14=00:52:18.760
CHAPTER14NAME="Das tiefe Luftholen vor dem Sprunge"
CHAPTER15=00:55:35.332
CHAPTER15NAME=Minas Morgul
CHAPTER16=00:59:36.406
CHAPTER16NAME=Sams Warnung
CHAPTER17=01:00:23.703
CHAPTER17NAME=Pippins Aufgabe
CHAPTER18=01:00:50.605
CHAPTER18NAME=Osgiliath wird eingenommen
CHAPTER19=01:04:30.074
CHAPTER19NAME=Das Anzünden der Leuchtfeuer
CHAPTER20=01:07:16.031
CHAPTER20NAME=Theodens Entscheidung
CHAPTER21=01:10:35.314
CHAPTER21NAME=Der Fall Osgiliaths
CHAPTER22=01:14:54.823
CHAPTER22NAME=Der Zauberlehrling
CHAPTER23=01:17:21.970
CHAPTER23NAME=Die Treppen von Citih Ungol
CHAPTER24=01:19:21.798
CHAPTER24NAME="Mut ist die beste Verteidigung"
CHAPTER25=01:20:01.087
CHAPTER25NAME=Peregrin, Wächter der Veste
CHAPTER26=01:21:26.798
CHAPTER26NAME=Treue zu Denethor
CHAPTER27=01:23:48.940
CHAPTER27NAME=Die Trennung von Sam und Frodo
CHAPTER28=01:29:08.593
CHAPTER28NAME=Die Opferung Faramirs
CHAPTER29=01:33:57.590
CHAPTER29NAME=Antritt in Dunharg
CHAPTER30=01:38:08.048
CHAPTER30NAME=Anturil - Die Flamme des Westens
CHAPTER31=01:42:49.705
CHAPTER31NAME=Aragorn wählt den Pfad der Toten
CHAPTER32=01:45:34.244
CHAPTER32NAME="Ich möchte, dass du nicht mehr zweifelst"
CHAPTER33=01:46:57.452
CHAPTER33NAME=Dwimorberg - Der Geisterberg
CHAPTER34=01:49:24.432
CHAPTER34NAME=Die Heerschau von Rohan
CHAPTER35=01:51:09.996
CHAPTER35NAME=Der Pfad der Toten
CHAPTER36=01:58:39.695
CHAPTER36NAME=Die Belagerung von Gondor
CHAPTER37=02:07:40.236
CHAPTER37NAME=Die Corsaren von Umbar
CHAPTER38=02:08:42.715
CHAPTER38NAME=Kankras Lauer
CHAPTER39=02:17:50.387
CHAPTER39NAME=Marry Tapferkeit
CHAPTER40=02:19:40.706
CHAPTER40NAME=Grond - Der Hammer der Unterwelt
CHAPTER41=02:20:17.075
CHAPTER41NAME=Das Grab der Truchsessen
CHAPTER42=02:21:50.711
CHAPTER42NAME=Das Tor von Gondor zerspringt
CHAPTER43=02:22:57.527
CHAPTER43NAME=Die Entscheidung von Meister Samweis
CHAPTER44=02:28:59.264
CHAPTER44NAME=Denethors Wahnsinn
CHAPTER45=02:30:04.579
CHAPTER45NAME=Die Stunde des Hexenmeisters
CHAPTER46=02:32:29.599
CHAPTER46NAME=Ritt der Rohirrim
CHAPTER47=02:36:44.020
CHAPTER47NAME=Denethors Scheiterhaufen
CHAPTER48=02:38:51.105
CHAPTER48NAME=Die Schlacht auf den Pelennor-Feldern
CHAPTER49=02:43:46.650
CHAPTER49NAME="Ein fernes grünes Land"
CHAPTER50=02:45:17.074
CHAPTER50NAME=Der Nazgûl und seine Beute
CHAPTER51=02:47:03.013
CHAPTER51NAME=Die Schwarzen Schiffe
CHAPTER52=02:47:55.440
CHAPTER52NAME=Schildmaid Rohans
CHAPTER53=02:48:39.693
CHAPTER53NAME=Der Sieg in Minas Tirith
CHAPTER54=02:51:15.390
CHAPTER54NAME=Theodens Tod
CHAPTER55=02:53:18.096
CHAPTER55NAME=Den Eid erfüllen
CHAPTER56=02:54:25.038
CHAPTER56NAME=Die Häuser der Heilung
CHAPTER57=02:56:41.049
CHAPTER57NAME=Pippin sieht nach Merry
CHAPTER58=02:57:33.101
CHAPTER58NAME=Der Turm von Cirith Ungol
CHAPTER59=03:04:29.016
CHAPTER59NAME=Die letzte Beratung
CHAPTER60=03:06:11.369
CHAPTER60NAME=Aragorn bewältigt den Palantir
CHAPTER61=03:07:40.458
CHAPTER61NAME=Der Hauptmann und die weiße Herrin
CHAPTER62=03:08:30.591
CHAPTER62NAME=In der Gesellschaft von Orks
CHAPTER63=03:12:11.979
CHAPTER63NAME=Das Land der Schatten
CHAPTER64=03:16:23.689
CHAPTER64NAME=Saurons Mund
CHAPTER65=03:19:39.593
CHAPTER65NAME=Das Schwarze Tor öffnet sich
CHAPTER66=03:23:13.390
CHAPTER66NAME="Ihn kann ich nicht für dich tragen, aber ich kann dich tragen"
CHAPTER67=03:25:26.189
CHAPTER67NAME=Der letzte Zug
CHAPTER68=03:26:29.294
CHAPTER68NAME=Der Schicksalsberg
CHAPTER69=03:28:25.368
CHAPTER69NAME="Die Adler kommen!"
CHAPTER70=03:28:59.694
CHAPTER70NAME=Die Schicksalsklüfte
CHAPTER71=03:34:37.948
CHAPTER71NAME=Sauron wird besiegt
CHAPTER72=03:36:51.332
CHAPTER72NAME=Am Ende aller Dinge
CHAPTER73=03:40:20.332
CHAPTER73NAME=Die Gemeinschaft ist wieder vereint
CHAPTER74=03:42:43.433
CHAPTER74NAME=Die Rückkehr des Königs
CHAPTER75=03:47:36.476
CHAPTER75NAME=Heimwärts
CHAPTER76=03:52:18.383
CHAPTER76NAME=Die Grauen Anfurten
CHAPTER77=04:01:36.983
CHAPTER77NAME=Abspann
CHAPTER78=04:12:44.399
CHAPTER78NAME=Fan Club Abspann


C.U. NanoBot

[Chetwood]

@Mosu
Sorry, but alcohol apparently influences one's reading comprehension skills more than expected. Gonna try to post sober next time.

@Nanubot
Thanks!

[Selur]

Small question regarding default and forced subtitle streams and my understanding of it.
I thought that default would mean that if subtitles are enabled the player should as a default should play the as default flagged stream. VLC automatically enables Subtitles when they are flagged as defaults is my understanding or VLCs handling wrong?
I thought that force would mean that if a subtitle stream is flagged as forced it should be shown by the player independent of the the fact that subtitles in general are enabled or not.

-> are my assumption correct are am I wrong ?

Cu Selur

[Mosu]

"Forced" has nothing to do with "default".

The specs (http://www.matroska.org/technical/specs/index.html) say:

FlagDefault: Set if that track (audio, video or subs) SHOULD be used if no language found matches the user preference.

FlagForced: Set if that track MUST be used 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.

Unfortunately the description for the "default" flag is ambiguous. Players have come interprete it as "turn on this track, regardless what!". I always tended to disagree with that interpretation, but well, it is how it is.

[Selur]

"Forced" has nothing to do with "default".
fixed, that was a copy&paste mistake ;)

Okay, so you agree that setting a stream as default should not cause the player to enable subtitles/audio on it's own?

Cu Selur

[Mosu]

I agree, yes, but the specs don't (or at least they can be interpreted both ways). And specs trump my opinion :)

[Selur]

Okay, thanks. :)

Cu Selur

[nevcairiel]

I've had the same discussion a while ago with some users, and i agree that "Default" should not control IF a track is active, it should only control WHICH.
This is especially true because mkvmerge always flags one stream of every kind as "Default", which would mean i always get subtitles active by default, even if i wouldn't want them...

People expect different things. People use the flags matching the players behavior - and alot of players take "Default" and use it decide whether to enable the stream. This is not only true for VLC, but also for the Haali splitter.
Even if the spec would be more clear on the matter, if 99% of all players behave that way, and files are flagged to match these players, it would be kinda silly to diverge from that behavior...

[Selur]

Thought this was an VLC only issue -> I'll adjust Hybrid to not set default audio/subtitle tracks unless manually specified then.

@Mosu: small feature request for the "mkvmerge -i" output would be nice it it could also output if a stream is flagged default and/or forced. (I know there's mkvinfo, but it would be nice to get some additional infos from mkvmerges identify. ;))

Cu Selur

[Mosu]

mkvmerge -I
or
mkvmerge --identify-verbose

[Selur]

Nice!! (didn't know that option :))

[Chetwood]

I am also somewhat confused by the GUI's options when it comes to stream flags:

default track flag: yes, no, default <- this default means that this particular flag is not set at all?

[Mosu]

"default" means "let mkvmerge chose". mkvmerge's algorithm is (for each track type):

- user input from the command line (via the '--default-track' flag if it is set to 'yes' for a track)
- source container information (currently only Matroska provides this information)
- the first track of its type get its 'default' flag set

Also see http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html about "--default-track".

[smegolas]

Hi,
If I use MKVMerge to split a file (H.264 video with DTS audio) and then at a later date use MKVMerge to re-join the two parts, is it possible that the joined file is not 100% identical to the original? Maybe some sync information or something is slightly different?

I did it with a movie and when splitting I got
Warning: The track number 2 from the file ****** can probably not be appended correctly to the track number 2 from the file *******
Please make sure that the resulting file plays correctly the whole time.
The author of this program will probably not give support for playback issues with the resulting file.

and when re-joining I think I can detect a slight....stutter is probably the wrong word but just a millisecond pause or stutter around the point of the join.

[Mosu]

Hi,
If I use MKVMerge to split a file (H.264 video with DTS audio) and then at a later date use MKVMerge to re-join the two parts, is it possible that the joined file is not 100% identical to the original?

Yes, that is possible.

[smegolas]

Yes, that is possible.

Thanks.

[Marsu42]

Small question and/or feature request: When joining files, is there a way to auto-generate chapters for the start point of each original section?

If there is no (automatic) way yet, imho this would make a great feature - one could conveniently join multiple parts e.g. of a ongoing documentary and still be able to jump to each section.

[Mosu]

There is no such feature, there will be no such feature (at least not coded by myself). Sorry.

[Marsu42]

There is no such feature, there will be no such feature (at least not coded by myself). Sorry.

Sorry to hear that, it would have made a nice way to promote the seldom used chapter feature in mkv files - but you're the one to have the idea where this application is going. Anyway, thanks a lot for your great work in the past!

[hello_hello]

Yes, that is possible.

So why would MKVMerge give a warning when appending MKVs containing DTS audio after they've been split?
smegolas asked the question as he posted about the problem in a different thread. I'm now asking too as while contributing to that discussion I tried splitting several MKVs containing DTS audio myself, but when appending the split parts I was getting the same warning.

"Warning: The track number 2 from the file ****** can probably not be appended correctly to the track number 2 from the file......"

It seems to only be a problem with DTS audio streams. MKVs I tried with other types of streams split and appended without warnings.
I'm using MKVToolNix 4.9.1

Thanks.

[Mosu]

It might be related to this bug report: https://www.bunkus.org/bugzilla/show_bug.cgi?id=652

[hello_hello]

I've got the option to "disable header removal compression" enabled in MKVMerge's options, so I'd assume it's something else. Something which for some reason only seems to effect dts streams.

[Mosu]

Then please file a bug report in my bug tracker and upload a sample file somehwere, e.g. to my FTP server (see signature). Otherwise I will likely forget about the issue.

[hello_hello]

Okay. Do you really need a sample though? I've tried several MKVs and it appears anything containing dts audio will reproduce the error.

[Mosu]

Yes, please. I don't know if/when I will get around to it, and it just may be that I cannot reproduce it with my own sample files.

[Mosu]

Hey,

here's a first test build for Windows (built from git revision a0d6da4):
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110916-361-setup.exe

It can read MPEG transport streams (usual file extensions: .ts and .m2ts). I'd appreciate testing & feedback :)

Known issues, limitations and things to note:

Video codecs tested: h264, VC1, MPEG-2
Audio codecs tested: AAC, AC3, DTS, TrueHD, MP2
No subtitle support yet at all. I don't have a sample file. Would anyone be willing to provide one? I mean the subtitle types that MakeMKV can write, e.g. PGSUB thingies.
A/V sync issues with MPEG-2 video. The cases I had had very small constant offsets that could easily be corrected with the --sync option.
If mkvmerge or the GUI crashes then please make sure that mmg/mkvmerge is set to use the English interface. I haven't updated/checked the translation files yet, and yes, GNU gettext in combination with Boost::format and translated entries marked as "fuzzy" can cause crashes.
Video distortions #1: I've only noticed this in two cases. One was right at the beginning of a file in which ffmpeg also reported that the h264 stream was referring to SPS and PPS IDs that did not exist. My guess is that the stream didn't start with SPS & PPS NALUs, even though it looked like it came from a BluRay disc.
Video distortions #2: I've seen one file in which the VC1 video track which stutered regularly. It looked like its timecodes were ordered in a strange way. I haven't investigated this further. I have tested several other VC1 video tracks from TS files that were all OK though.
Speed. Interesting enough mkvmerge is quite a bit faster on my Linux installation with a SATA-backed software-RAID6 instead of my SSD-backed Windows 8 box. Go figure. But this has always been true, not just for the new TS code.

If you encounter issues then having access to sample files would be greatly appreciated (uploads to my FTP server, URLs to downloads etc). No 12 GB BitTorrent downloads, please.

[SamuriHL]

That's pretty sweet! Thanks, Mosu! As for samples, I'm sure someone will post one. There's tons floating around. If not, I can create one this weekend. I'm going to be watching Star Wars all weekend but I can find time to do it if you need.

[Mosu]

I mostly need samples if mkvmerge is mis-behaving with certain material, or if it contains features not yet supported by mkvmerge (e.g. subtitles). I don't need ALL files, though, I have a few of my own. Thanks for the offer :)

[SamuriHL]

Well that's what I mean. I have files with subtitles in them that might be useful. Shouldn't be too hard to trim one up and host it for you but I'm in the middle of Phantom Menace at the moment so my machine is busy. :D

[sneaker_ger]

Thx.

Muxing this sample will result in an mp3 track in addition to the ac3 track:
https://rapidshare.com/files/2552758271/Sample__BBC_HD_.h264.ts

Is this correct? LAV Splitter and Media Info don't see any mp3 track, but VLC finds something.
I'm not sure whether this is correct or not.

[sneaker_ger]

Here's a sample with PGS, though not from a Blu-Ray (I think). Got it somewhere here on doom9 or doom10:
https://rapidshare.com/files/3011625169/Sample_AVC_1080-50p.m2ts

[Mosu]

Thx.

Muxing this sample will result in an mp3 track in addition to the ac3 track:
https://rapidshare.com/files/2552758271/Sample__BBC_HD_.h264.ts

Is this correct? LAV Splitter and Media Info don't see any mp3 track, but VLC finds something.
I'm not sure whether this is correct or not.

The PMT lists such a track, yes, but there don't seem to be payload packets with that PID. I'll fix mkvmerge to ignore such tracks.

[sneaker_ger]

Tested it on a TV capture with lots of packet loss: frames are dropped correctly, A/V sync is kept. This is already looking very good for a test version.

[Mosu]

Muxing this sample will result in an mp3 track in addition to the ac3 track:

Here's an updated build that ignores such tracks: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110917-362-setup.exe

I actually have another such a file like yours now works well now with the new build; with the old one I still have to exclude that track manually.

Thanks for the subtitle sample. Will work on it on over the weekend.

I'm off to bed now. Have fun testing everyone ;)

[Mosu]

Aaah don't use that build. It will skip valid tracks as well, e.g. VC1 and TrueHD ones. Will fix it properly tomorrow. I've removed the 362 build.

[nevcairiel]

How will it deal with TrueHD/AC3 interleaved tracks from Blu-ray m2ts files?
I kinda hope it will remove the interleaved AC3 frames, or split it into two tracks.

[Mosu]

As this questions comes up from time to time I decided to write a FAQ entry (http://www.bunkus.org/videotools/mkvtoolnix/faq.html#truehd_with_ac3) for it (just now, so don't think you've overlooked something if you had looked at the FAQ earlier).

[Mosu]

Muxing this sample will result in an mp3 track in addition to the ac3 track:

Here's a build that will only report (via "--identify") or mux tracks that it can actually find data for in the file (well, within the probing limit). Unlike the previously pulled build this one doesn't discard VC1 and TrueHD tracks by mistake.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110918-363-setup.exe

Off to bed now; upload is still running though. Should be done in a minute or two.

[Mosu]

Yet another build, this time with support for HDMV PGS subtitles, DTS HD master audio and a couple of bug fixes: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110918-364-setup.exe

Thanks for the samples.

[lovelove]

'D:\title08_track2.flac': Using the FLAC demultiplexer.
+-> Parsing the FLAC file. This can take a LONG time.
+-> Pre-parsing FLAC file: 0%
+-> Pre-parsing FLAC file: 5%

Why do FLAC files have to be pre-parsed contrary to ALL other input formats?

[Mosu]

Back when I implemented FLAC support I didn't want to write all the file code parsing myself. So I relied on libFLAC to do the file parsing for me. Unfortunately libFLAC uses a callback-based system that's fundamentally incompatible with how mkvmerge's main muxing process works. Therefore all the processing with libFLAC is done before muxing starts, the required information recorded and then re-used during muxing without any calls to libFLAC.

I never bothered to re-write that code to not relying on libFLAC 'cause I don't think it's that important (with "important" being determined by the number of people annoyed by it (unknown, probably low) times the actual impediment (very low, it simply takes a bit longer)).

[nautilus7]

Maybe people weren't annoyed because they didn't know why it was hapening. Now that I know that it can be bypassed / replaced by a better or faster algorithm, I am annoyed. :P

[robpdotcom]

I'd be annoyed if it really did take a long time. But since it actually happens very quickly, I have no problem with it.

[Mosu]

Well, I'm always open to patches ;)

[Thunderbolt8]

Yet another build, this time with support for HDMV PGS subtitles, DTS HD master audio and a couple of bug fixes: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110918-364-setup.exein what cases are the changes to dtsma audio relevant?
do I have to redo all my .mkv remuxes?

[SamuriHL]

@Mosu

Stupid question. Is there any chance that you'll add support for adding an MPLS file so that for seamless branching titles you can join all the separate m2ts files into a single MKV? Of course, I'm also assuming it doesn't do that before I even try it, but, I haven't seen any mention of this functionality hence why I ask. Thanks!

[Mosu]

in what cases are the changes to dtsma audio relevant?
do I have to redo all my .mkv remuxes?

Check your audio tracks. If they are considerably shorter than the video track (my problematic file resulted in the audio track being half as long as the video track -- but only regarding the timecodes; all the actual content was there) then you have to re-mux.

It also only concerns DTS-HD MA read from TS streams. As both the support for DTS-HD MA and the corresponding fix to the timecode handling were both introduced between builds 363 and 364 I highly doubt that you'd be affected.

[Mosu]

@Mosu

Stupid question. Is there any chance that you'll add support for adding an MPLS file so that for seamless branching titles you can join all the separate m2ts files into a single MKV? Of course, I'm also assuming it doesn't do that before I even try it, but, I haven't seen any mention of this functionality hence why I ask. Thanks!

It's not supported yet, true, but that would indeed be a nice feature to have. Any way I can get my hands on sample files or create them myself (e.g. split a m2ts I have into multiple ones and create such a file)? I don't know a lot about MPLS in the first place, so any hint would be appreciated.

[SamuriHL]

It's not supported yet, true, but that would indeed be a nice feature to have. Any way I can get my hands on sample files or create them myself (e.g. split a m2ts I have into multiple ones and create such a file)? I don't know a lot about MPLS in the first place, so any hint would be appreciated.

No, I don't know of any way to create them. Any seamless branching title will have them though. Sony's been using a java protection that relies on seamless branching so titles like Source Code would be a good one to experiment on. Nev or madshi might have some insight on how to read and parse those files. I think Nev uses the libbluray library. I'm not sure how madshi does it.

[mbcd]

How will it deal with TrueHD/AC3 interleaved tracks from Blu-ray m2ts files?
I kinda hope it will remove the interleaved AC3 frames, or split it into two tracks.
Stupid Question of mine:

What is with DTS? It has also a "core" inside.
Its likely the same as with THD/AC3.

Those are two different formats (DTS/DTS-HD) or am I wrong ?

[nevcairiel]

DTS is different. The DTS core is a vital part of the DTS stream. Both the DTS core and the DTS-HD extensions are required to decode the audio properly.
For TrueHD/AC3, the AC3 frames are only there for backwards compatible reasons, iow. useless. :p

[b66pak]

@mbcd

see the answer on wiki (http://en.wikipedia.org/wiki/DTS-HD_Master_Audio)...

[Video Dude]

Yes, mkvmerge removes the sequence headers and stores the first ones that it finds in the CodecPrivate. Yes, I know that this a problem with changing sequence headers in the middle of the stream, and yes, I plan to change that someday. That being said, I don't spend any time coding mkvtoolnix at the moment, so your guess is as good as mine when mkvmerge will handle such streams correctly.
Mosu, I was taking a look at the source code, would you know which source file(s) refers to this?

[Mosu]

Does that quote refer to MPEG-1/2 video? If so then this problem has long been solved by keeping the sequence headers in the bitstream as well.

[nevcairiel]

I believe it refers to H264.

[Mosu]

Hmm, I don't want to rule that out but I usually don't talk about "sequence headers" when talking about h264; instead I talk about SPS and PPS NALUs. But still... mkvmerge also keeps SPS and PPS NALUs in the bitstream for h264 tracks.

[nevcairiel]

The quote is from 2007, so things might have changed as well. ;)
Looking at the original quote, it did indeed refer to H264, in context of importing raw avc streams.
This was right around the time you disabled the removal of sequence headers for MPEG-1/2

[Mosu]

mkvmerge has been keeping SPS & PPS NALUs in the bistream for over four years now:

commit e88bb1aee5ebdf3cda3dc59817588a6ad8eecb8f
Author: Moritz Bunkus <moritz@bunkus.org>
Date: Wed Aug 15 17:59:22 2007 +0000

Don't remove SPS and PPS NALUs from AVC/h.264 streams.

[nautilus7]

Request about .m2ts re-muxing: When loading xxxxx.m2ts file from blu-ray read track languages from xxxxx.clpi.

[Mosu]

Maybe, not for the next release (time constraints).

What are clpi files (I see that they're stored in the CLIPINF sub-directory)? Where can I get a description about their format or see code that reads them?

[Mosu]

Ah, libbluray has code for parsing them. I'll take a look.

[nautilus7]

Thanks, mosu!

[Mosu]

Alright, that looks mighty easy to parse. I hope I can squeeze it in before the weekend (that's when I plan to release the next version).

[SamuriHL]

Absolutely great work, Mosu. Thank you for your efforts in this area!!

[Mosu]

Here's a build that parses a .clpi file with the same base name as the transport stream file extracting the track languages from it. It will look for this file a) in the same directory, b) in "path\to\source\file\..\CLIPINF" and c) in "path\to\source\file\..\clipinf" (for file systems that don't do case folding).

I only have one test file here (the .m2ts does not contain track language attributes of its own, the .clpi one provides them for all audio tracks), and it Works For Me(tm). Please test & report back. Thanks.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110920-365-setup.exe (upload should be done in a minute or two)

[lovelove]

Back when I implemented FLAC support I didn't want to write all the file code parsing myself. So I relied on libFLAC [...]

many thanks for the explanation, Mosu!

Maybe people weren't annoyed because they didn't know why it was hapening. Now that I know that it can be bypassed / replaced by a better or faster algorithm, I am annoyed. :P

big fat LOL :D

[Kurtnoise]

Thanks Mosu,

Here's a build that parses a .clpi file with the same base name as the transport stream file extracting the track languages from it. It will look for this file a) in the same directory, b) in "path\to\source\file\..\CLIPINF" and c) in "path\to\source\file\..\clipinf" (for file systems that don't do case folding).
what about m2ts file in \BDMV\STREAM\ folder and clpi in \BDMV\CLIPINF\ ?

the BD structure looks like this : http://www.videohelp.com/hd

[nevcairiel]

what about m2ts file in \BDMV\STREAM\ folder and clpi in \BDMV\CLIPINF\ ?

Didn't he explain that? :p

It'll look in "..\CLIPINF", so if the m2ts is in BDMV\STREAM, it'll look in "BDMV\STREAM\..\CLIPINF", which is just "BDMV\CLIPINF" - fully supporting BD structures. ;)

[Kurtnoise]

well...languages tracks detection doesn't work here then.

[Mosu]

well...languages tracks detection doesn't work here then.

Can you upload sample files, please? I need the clpi file (shouldn't be too big) and roughly 30 MB of the m2ts file. It would be extra cool if you could upload a ZIP file with the same folder structure as the one your files are in. Thanks.

[sneaker_ger]

A few random things:

1.) Currently the writing app info written to the file is localized, I think it should always be English.
2.) mkvinfo always seems to complain that "there is more than one track with the id x". Isn't this a false alarm?
3.) It seems that you've already implemented (more) SPS/PPS reading. Would it be possible to use the timing info from H.264 ES instead of defaulting to 25 fps/displaying a warning in mmg? (or is that (https://github.com/mbunkus/mkvtoolnix/commit/78a27c7ee0825b6d6bf686d458e89b0e925c9d59) for writing?)
That warning still pop ups in mmg, even if you load a timecode file, btw.

[Mosu]

A few random things:

1.) Currently the writing app info written to the file is localized, I think it should always be English.

Hmm, indeed. I'll fix that.

2.) mkvinfo always seems to complain that "there is more than one track with the id x". Isn't this a false alarm?

According to the Matroska specs this is an error. Oh wait, this could also happen if the same track headers are written more than once. Hmm... I'll think about it.

3.) It seems that you've already implemented (more) SPS/PPS reading. Would it be possible to use the timing info from H.264 ES instead of defaulting to 25 fps/displaying a warning in mmg? (or is that (https://github.com/mbunkus/mkvtoolnix/commit/78a27c7ee0825b6d6bf686d458e89b0e925c9d59) for writing?)
That warning still pop ups in mmg, even if you load a timecode file, btw.

That is planned, yes.

[sneaker_ger]

According to the Matroska specs this is an error. Oh wait, this could also happen if the same track headers are written more than once. Hmm... I'll think about it.

I don't really understand, just wondered, as it would be displayed for all tracks if mkvmerge or ffmpeg were used. Haali-muxed files don't display the warning.

/edit:
oh, sorry. I think it may be my error, it doesn't depend on the muxer, but me opening the files in mkvinfo one after another without closing. mkvinfo seems to somehow remember the old file. Is this expected?

/edit2:
I don't find anything about this in the mkvinfo docs, so I assume it's a bug? To reproduce just drag&drop a file on the mkvinfo window and then drag&drop the same file again on to it.

[Mosu]

I don't get that warning for files created with mkvmerge. Anyway, I've removed them.

[Mosu]

/edit:
oh, sorry. I think it may be my error, it doesn't depend on the muxer, but me opening the files in mkvinfo one after another without closing. mkvinfo seems to somehow remember the old file. Is this expected?

Ah, good point. Will have to fix that as well; mkvinfo doesn't clean up nicely when it opens a second file (I almost never use its GUI, therefore I seldom catch such issues).

[sneaker_ger]

So, that basically means that this change (https://github.com/mbunkus/mkvtoolnix/commit/52fafe5c08da9f537d38bd1788b9333c9ea16239) was unnecessary, right? Sorry 'bout that, I hope it wasn't too much work.

[svcdprayer]

hello! im wondering does mkvmerge supports smi?

thanks!

[Mosu]

So, that basically means that this change (https://github.com/mbunkus/mkvtoolnix/commit/52fafe5c08da9f537d38bd1788b9333c9ea16239) was unnecessary, right? Sorry 'bout that, I hope it wasn't too much work.

No. That warning could also have been output if a second copy of the track headers was found (e.g. AVIMux GUI writes such files, Haali can, too, if I'm not mistaken). That is legal and should not issue warnings.

[Mosu]

hello! im wondering does mkvmerge supports smi?

No, it does not.

[nautilus7]

Language detection doesn't work here either no matter where the clpi file is located. Sample on your ftp.

[Mosu]

Alright, found the issue & fixed it in build 367 (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.1-build20110921-367-setup.exe).

[nautilus7]

Working now. Thanks!