mkvtoolnix 4.1.1 released

[Mosu]

Oh, I also downloaded both of your sample files and they play identically for me (using MPC Homecinema + DirectVobSub).

[Snowknight26]

The MP4 file, but don't expect a quick fix, please.

Here is the first 50,000,000 bytes of the file:
http://stfcc.org/misc/source.mp4

[TheFluff]

Demuxers and filters are not bug-free. Just sayin'.

I'm not saying it's your fault, in fact it's more likely to be a bug in the splitter (or even more likely a bug in vsfilter/dvobsub) just pointing out that it could have been wrong the entire time without anybody noticing (as per discussion on IRC it's pretty easy to miss it). The point of the original post was just to see if you happened to know anything about it.

[Mosu]

Just to sum up our IRC discussion: After being told what to look for (the first line has a different brightness than the second one in the 'unsorted' case) I can see it here, too. So yes, same problem.

[LeMoi]

Hey,

I've released mkvtoolnix v2.9.0.

Fixed bugs include several segfaults, crashes in the header editor and mmg always reporting that adding files has failed with a return code of 1 on certain Windows systems.

* mkvmerge: bug fix: Fixed support for Windows systems that use code pages that are not supported by the iconv library (e.g. code page 720). mkvmerge was exiting with warnings causing mmg to report that file identification had failed. Fix for bug 376.


Finally, works perfect, thansk a lot :)

[Mosu]

I recently remuxed an MP4 file to MKV but I noticed that whenever I played it, switching audio tracks would cause the video to stutter. As I was cutting a sample of that newly created MKV file, I noticed that mkvmerge gave me hundreds of these warnings:

The issue has been fixed in this build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.0-build20090530-135-setup.exe

However, you have to start muxing from the MP4 file again. The timecodes in the Matroska file are already bad, and there's no easy way to fix mkvmerge to correct those bad timecodes coming from such Matroska files.

[tetsuo55]

The issue has been fixed in this build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.0-build20090530-135-setup.exe

However, you have to start muxing from the MP4 file again. The timecodes in the Matroska file are already bad, and there's no easy way to fix mkvmerge to correct those bad timecodes coming from such Matroska files.Does that mean that muxing to MKV is not a completely lossless process

[Mosu]

That is a stupid question. Sorry for saying that. Remuxing from one container to another is ALWAYS a lossy process because no two containers offer the very same set of features.

Muxing to Matroska has never been a lossless process. It was never supposed to be that. The same is true for muxing to MP4 files. Or AVI. Or MPEG PS/TS.

It doesn't involve re-encoding the audio or the video though -- these bitstreams are mostly (!) kept 1:1 intact.

[tetsuo55]

That is a stupid question. Sorry for saying that. Remuxing from one container to another is ALWAYS a lossy process because no two containers offer the very same set of features.

Muxing to Matroska has never been a lossless process. It was never supposed to be that. The same is true for muxing to MP4 files. Or AVI. Or MPEG PS/TS.

It doesn't involve re-encoding the audio or the video though -- these bitstreams are mostly (!) kept 1:1 intact.Sorry, i should have been more clear.

I meant if the audio/video/subtitles are remuxed 100% losslessly. In which cases do the bitstreams get changed?

[Mosu]

Think of things like aspect ratio handling (the bitstream AR might be removed/added/changed to match the container AR); dummy frames in MPEG4 part2 that are removed completely.

ID3 tags are stripped from audio files.

For text subtitle formats some reformatting is done -- e.g. attachments like fonts and images are removed from SSA/ASS bitstreams and kept as attachments in the Matroska files. VobSub subtitle files are stripped of the surrounding MPEG program stream container, and even the SPU packets themselves are sometimes fixed because length fields are bad due to buggy authoring software.

You see, there are numerous cases in which the bitstreams get modified themselves, not just the meta information (timecodes etc).

However, all of those changes to not degrade the quality of the content. Like I said, audio/video is not re-encoded in the process.

[tetsuo55]

thanks for the reply, i guess a lot changes.

Imho MKV is the best container for PC archival use, so it doesn't really matter. (I have had to remux in the past though, and wanted to be sure that the movie would still work in that other container).

We also might have found a problem with a file mergeed with MKVmerge, a mkv containing a mpeg2 track and a simple audio track that does not have CodecPrivate field (causing it to either crash the player on only play audio).

Here is a sample: http://www.megaupload.com/?d=X4FA5TX3

[Mosu]

Not every codec needs a CodecPrivate element. Some audio codecs don't (MP2/3, AC3, old way of storing AAC ...), some do (new way of storing AAC, Vorbis...).

The file you've uploaded is not affected by the bug that I've fixed today. That bug was only happening for source containers that chose the very same timecode for a lot of samples -- MP4 in today's case. In that file contained the same timecode for over half a second of samples; this is not only bad for playback but also bad for storage in other containers.

Your MPEG2 file seems fine to me.

[tetsuo55]

Not every codec needs a CodecPrivate element. Some audio codecs don't (MP2/3, AC3, old way of storing AAC ...), some do (new way of storing AAC, Vorbis...).

The file you've uploaded is not affected by the bug that I've fixed today. That bug was only happening for source containers that chose the very same timecode for a lot of samples -- MP4 in today's case. In that file contained the same timecode for over half a second of samples; this is not only bad for playback but also bad for storage in other containers.

Your MPEG2 file seems fine to me.Yet it does not work with the MPC-HC built in splitter.
Note the file does work if it's remuxed through eac3to

Maybe the MPC-HC built in splitter expects the CodecPrivate element always

[Mosu]

I don't know, I don't care. MPC-HC is not my product. Haali's splitter works just fine. So this is a bug or missing feature (or whatever you want to call it) in MPC-HC.

[tetsuo55]

This post:http://forum.doom9.org/showthread.php?p=1291787#post1291787
It's a quote of the matroska specs that says for mpeg2 CodecPrivate appears required

[Mosu]

Ok, now I see what you mean. I misunderstood earlier -- I thought that the audio track was posing the problem and not the video track. I've replied to the thread you've linked to as you've probably seen already. This is indeed a bug in mkvmerge but also a bug in MPC-HD; I'm actually quite surprised -- the code is there to write CodecPrivate for MPEG-1/2 but is not called. I'm pretty sure that this was working a couple of versions ago, and fixing it is rather easy.

[Mosu]

Here's a build that creates a CodecPrivate element for MPEG-1/2 video tracks again. I also found out why I disabled this in the first place (see https://www.bunkus.org/bugzilla/show_bug.cgi?id=174 in case you're curious) but changing it back does not harm anything.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.0-build20090531-136-setup.exe

[allak]

Mosu, I don't know if this may help you, but I can confirm that, at least under some circumstances, the code is there to write CodecPrivate for MPEG-1/2 was still working in mkvmerge v2.8.0.

I've got a mkv I did mux last month and it is working fine.




|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v0.7.7 + libmatroska v0.8.1
| + Writing application: mkvmerge v2.8.0 ('The Tree') built on May 9 2009 18:02:06
| + Duration: 6492.200s (01:48:12.200)
| + Date: Wed May 20 19:22:13 2009 UTC
| + Segment UID: 0x99 0x19 0x4d 0xc7 0x0c 0x35 0x55 0xfb 0x9c 0xb0 0xc8 0x52 0x60 0x8c 0x2a 0x34
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Enabled: 1
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 0
| + MinCache: 1
| + Timecode scale: 1
| + Max BlockAddition ID: 0
| + Codec ID: V_MPEG2
| + Codec decode all: 1
| + CodecPrivate, length 152
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Language: und
| + Video track
| + Pixel width: 720
| + Pixel height: 576
| + Interlaced: 0
| + Display width: 1024
| + Display height: 576

[ibanez]

OK is sup support still on the table?

SUP support would be fantastic.

Thanks for a great application.

[Isochroma]

WMV support would be fantastic.

Many thanks for this great application.

[Mosu]

Sorry, but WMV support will not happen.

[LeMoi]

WMV support would be fantastic.

Many thanks for this great application.

http://forum.doom9.org/showthread.php?p=1283300#post1283300

[Mosu]

Just as an update: MPEG transport stream support is one of the next features I will implement; probably not THE next feature, but the next big one.

[Mosu]

Hey,

I've released mkvtoolnix v2.9.5. This release contains contains the usual mix of bug fixes, new features and smaller enhancements. Also some of the command line options have been renamed (check the ChangeLog for details). The old versions are still working for the time being, and users of mmg aren't affected by this change anyway.

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

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

The Linux binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.0:

------------------------------------------------------------
2009-06-07 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.5.

2009-06-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The handling of TrueHD/MLP audio in MPEG program streams was broken resulting in many dropped packets.
* all: bug fix: There was the possibility that invalid memory access occured and e.g. mkvmerge crashed on systems with the posix_fadvise() function (mainly Linux) if mkvmerge was opening several files from certain file systems (e.g. VFAT). Apart from obvious crashes the only other side effect was that the posix_fadvise() function would not be used resulting in slightly worse I/O performance.

2009-05-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Improved the control over which tags get copied from a source file to the output file. The old option "--no-tags" was replaced with the new options "--no-global-tags" which causes global tags not to be copied and "--no-track-tags" which causes track specific tags to not be copied. The new option "--track-tags" can be used to select tracks for which tags will be copied. The default is still to copy all existing tags.
* mkvmerge: new feature: Included chapters, global and track specific tracks in the output of mkvmerge's identification mode.
* mkvmerge: Renamed a couple of command line options to make the command line interface more consistent: "--no-audio", "--no-video", "--no-subtitles", "--no-buttons", "--audio-tracks", "--video-tracks", "--subtitle-tracks", "--button-tracks". The old versions of these options "--noaudio", "--novideo", "--nosubs", "--nobuttons", "--atracks", "--vtracks", "--stracks" and "--btracks" still work.
* mkvmerge: bug fix: The sequence header of MPEG-1/2 video tracks is put into the CodecPrivate again while still leaving sequence headers in the bitstream as well. This is more compatible with some existing parsers.

2009-05-30 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Removed the check if the user has added tracks and files before starting mkvmerge because mkvmerge itself is able to create track-less files (e.g. chapters only). Fix for bug 402.
* mkvmerge: bug fix: Improved the handling of consecutive AC3 packets with the same timecode (e.g. if AC3 is read from MP4 files). Fix for bug 403.

2009-05-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an endless loop in the TrueHD code occuring when the TrueHD stream is damaged somewhere.

2009-05-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the detection of MPEG transport streams with other packet sizes than 188 bytes (e.g. 192 and 204 bytes).

2009-05-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The detection of invalid padding packet lengths in the MPEG program stream reader was improved to not produce as many false positives. Patch by Todd Schmuland (see AUTHORS). Fix for bug 393.

2009-05-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for the FourCCs ".mp3" and "XVID" in QuickTime files.
* mmg: bug fix: Pressing 'return' in the job dialog will close the dialog on Windows, too. Fix for bug 392.

2009-05-22 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed the behaviour of how mmg sets the output file name automatically if the option is enabled. If the user adds more than one file then the extension of the output file name is set each time a file is added and not only when the first one is. The full file name and path will only be set when the first file is added. Fix for bug 391.
------------------------------------------------------------

Have fun.

[Isochroma]

The program always adds a shortcut to itself to the All Users / Programs folder during setup. I don't want it there and every setup I delete it. The installer doesn't ask. It asks other things, but not that. It just goes ahead and bullies my folders. It is a master of preconception. I am a worker of post-deception.

[Mosu]

Then please provide a patch for my NSIS installer script. Thanks. Or you could skip the Windows installer altogether and use the .7z archive which doesn't do anything to the start menu or registry at all.

[flebber]

This may be a strange question but is there a way I could make mkvtoolnix remux an mkv to incorporate updated tag information.

vlc uses xspf xml format for their playlist. Due to a lot of previous encodes I have done in mkv without much tagging I want to go back and update the tags in the metadata.

If i create a script to read file names and update an xml format will mkvtoolnix be able to update the metadata without the need to remux all data to a new file?

[Mosu]

No, mkvmerge only does full remuxes. mmg can only update the header fields without a full remux, and that's not scriptable.

[LeMoi]

Would it be possible to add "mis" language to the top language list ? I often use it but i have to scroll the list to the 'm' letter and it's quite long ^^ thanks in advance

[pdanpdan]

Would it be possible to add "xxx" language to the top language list
I have a feature request also - to allow us to define the order of languages in the lists (I think that if someone's language is not in the top list he has to search for it very often). Maybe a text file with the languages list, one on each row, that can be reodered and saved and imported.
Thanks for the program.

[Mosu]

Hey,

I've released mkvtoolnix v2.9.7. This release contains mostly bug fixes and two prominent changes to mmg.

1. Chapters and tags are now handled in the same way that tracks are: they can be checked individually, and properties like charset can be set for each entry.

2. The user can now change the list of "common" languages that appear at the top of language drop down boxes.

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

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

The Linux binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.5:

------------------------------------------------------------
2009-07-01 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.7.

2009-06-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The handling of NVOPs in native MPEG4 part 2 video storage has been improved. NVOPs are dropped again both from packed and non-packed bitstreams, and timecodes are adjusted to match the number of dropped frames.

2009-06-25 Moritz Bunkus <moritz@bunkus.org>
* mmg: The "preferences" dialog has been split up into several tabs. Some other preferences available in other dialogs have been merged into the "preferences" dialog.
* mkvmerge: bug fix: The I frame detection for AVC/h.264 video has been fixed. Sometimes a single I frame was recognized as two or more consecutive I frames resulting in garbled display and wrong timestamps. Fix for bug 415.

2009-06-23 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: The list of common languages can be configured by the user via the 'preferences' dialog.

2009-06-22 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: The programs do not try to close iconv handles -1 anymore which resulted in segfault during uninitialization on some platforms (e.g. FreeBSD, Mac OS X). Fix for bug 412.

2009-06-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Complete rewrite of the code for the native storage mode for MPEG4 part 2 video tracks. Fix for bug 298.

2009-06-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Made the detection rules for raw MP3, AC3 and AAC audio files more strict. This avoids a mis-detection of certain files, e.g. AVC/h.264 ES files being misdetected as MP3 files. Fix for bug 414.

2009-06-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Appending MP4 or OGM files with chapters will merge the chapters from all appended files and not just take the chapters from the first file and discard the chapters from the following files. Fix for bug 397.
* mkvmerge, mmg: new feature: The language for chapters read fromfiles such as OGM and MP4 files can be chosen with the --chapter-language command line option. Fix for bug 399.
* mkvmerge, mmg: new feature: Chapter and tag information contained in source files are now shown in the "track" selection box and can be toggled individually. The user can set the charset for chapters if the source file's chapters are not encoded in UTF-8 (e.g. in some OGM/MP4 files). The old file specific checkboxes "no tags" and "no chapters" have been removed. Fix for bug 400.

2009-06-13 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The chapter editor was corrupting Matroska files if the chapters were saved to a file twice in a row without reloading them from the Matroska file.

2009-06-09 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: If the user selects the option "Verify" from the "Chapters" menu then a message will be shown even if the validation succeeded. Fix for bug 410.
* mmg/mkvmerge: bug fix: Adding MP4 files with chapter entries that are not encoded in UTF-8 will not result in mkvmerge aborting with a message about invalid UTF-8 sequences anymore. Fix for bug 408.
----------------------------------------------------

Have fun.

[tetsuo55]

Thanks for the release.

I will make sure to remux my MPEG4 part 2 and MPEG4 part 10 files with the new version.

[Liisachan]

2. The user can now change the list of "common" languages that appear at the top of language drop down boxes.

Hi, thank you.
I'm trying to test the above feature but getting this error message:


---------------------------
Invalid country selected
---------------------------
The country '' is not a valid ccTLD and cannot be selected.
---------------------------
OK
---------------------------

Any suggestion?


Edit:
Although this error message is annoying, the list is updated properly, with selected languages on top, next time you restart MMG.

[Mosu]

That error message refers to the "chapters" page of that dialog. It will be fixed in a future release because you may indeed not select a country code.

[Liisachan]

confirmed. no error message if you set a dummy, benign thing in the Chapters tab, such as eng->uk.
However, this means that when a user wants to change the Languages settings, he or she is forced to update the Chapters settings,
with no good reason. Even if they don't change anything in the Chapters tab, MMG insists it will update the Chapters settings.
Which is probably less than ideal.

[Mosu]

Like I said, that problem will be fixed :) E.g. in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090702-142-setup.exe (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090702-142.7z).

[73ChargerFan]

Thanks for the update - I've had 3 bad 264 muxes in the last day, just tested them out and they are all garbled. I'll try the new one.

Request again - support of TS & M2TS files.
I had muxed by BDs with DTS-MA to TS when mmg couldn't, and am now trying to convert the TS files to MKV. I demux with tsMuxeR, which gives elementary .264 streams, then I use mmg - but the video is garbled in mpc-hc. The original TS file is fine. I don't care about subtitle support, just getting the video & audio out.

[Mosu]

Request again - support of TS & M2TS files.

I hate to repeat myself but: Yes, supoprt for transport streams will be implemented in the near future, and no, I don't have an ETA.

[73ChargerFan]

Another request - create chapters every 5 minutes

The last chapter should be minimum 5 minutes (credits), e.g. 122 minute film has chapters at 0:00, 0:05, ..., 1:50, 1:55

I've got txt files set up for this, but have to edit them each time to fit the movie. I think this is would be a very useful feature, because it would allow using the >> button to skip 5 minutes at a time.

Thank you.

[Mosu]

No, sorry. I've refused to implement such features in the past due to them being either way too specialized to be of use for more than a handful of persons or the amount of work being way, way too much to make such a feature flexible enough to appeal to many people.

[sneaker_ger]

Thanks for the release.

I will make sure to remux my MPEG4 part 2 and MPEG4 part 10 files with the new version.

Please note that native MPEG4 part 2 mkv files created from VfW material with versions prior to 2.9.7 are not fixed by remuxing them. Mosu says it's not possible.

[Mosu]

Please note that native MPEG4 part 2 mkv files created from VfW material with versions prior to 2.9.7 are not fixed by remuxing them. Mosu says it's not possible.

That's correct.

1. Only merging files with "--engage native_mpeg4" has been affected by the changes in 2.9.7. Normal xvid/divx/MPEG4 part 2 merging without that --engage option has NOT changed.

2. Remuxing files with V_ISO/MPEG4/{SP,AP,ASP} codec IDs that have been written by mkvmerge versions before 2.9.7 cannot be fixed by a remux with 2.9.7 because too much valuable timecode and frame information has already been lost in the first step.

3. The native muxing will be made the default (and probably the only choice) in mkvmerge 3.0.0.

[tetsuo55]

Too bad :(

[stax76]

Kann man mkvmerge so einstellen das die Konsole englisch ausgibt und deutsche Umlaute in den Pfaden korrekt dargestellt werden?

[Mosu]

Kann man mkvmerge so einstellen das die Konsole englisch ausgibt und deutsche Umlaute in den Pfaden korrekt dargestellt werden?

This is an English forum, so I'll reply in English.

The language mkvmerge uses and the charset it uses are two distinct things. The language and charset default to the system values. How those values are determined depends on the operating system you're running mkvmerge on.

Generally there are two options for changing these aspects: --ui-language and --output-charset. The former sets the language and the latter changes the charset that all tools use for outputting to the console.

On Windows you shouldn't have to change the output charset as mkvmerge detects the charset used by the console itself. Changing the output charset is only useful if you redirect the output, e.g. to a text file, and use an editor for looking through that text file. Changing the language on Windows is easy enough, just add "--ui-language en" to the command line.

On non-Windows systems mkvmerge usually gets its defaults from the locale environment variables (LC_ALL, LC_MESSAGES and LANG are examined in this order. The first one that is set is chosen.). You can still use --ui-language and --output-charset, or you could simply change the environment variable appropriately (e.g. "LC_MESSAGES=en_US.UTF-8 mkvmerge ..."). Unlike Windows the --ui-language parameter actually takes the same format as the LC_* and LANG variables meaning that for English you'll have to use "en_US" and not just "en" as on Windows.

Note for non-Windows systems: setting LC_MESSAGES to "en_US" (without an explicit charset) means that the charset defaults to "ASCII" and not to UTF-8. If you need German Umlaute then your Linux system is usually either set up for ISO-8859-15 or for UTF-8. Achieving the latter is easy: "en_US.UTF-8". However, the former is usually not supported out of the box by most Linux distributions. You'll have to use something like "en_US@euro" and use locale-gen to define en_US@euro as being ISO-8859-15, or you'll have to change en_US itself to map to ISO-8859-15. How that is done depends heavily on the distribution in question.

[stax76]

Thanks for the quick and detailed explanation, it didn't help with none of both issues.

mkvmerge.exe -h -ui-language en -> Gespr"chigkeit erh"hen
mkvmerge.exe -h -ui-language en --output-charset en -> Gesprächigkeit erhöhen

edit: I'm on Win 7 32bit english with german locale, if it helps you I can boot into XP german and check if it behaves different.

[Mosu]

There have to be two dashes with long options, not just one. --output-charset en won't work because "en" is not a valid charset. Just leave it out. It works nicely on Windows XP and Vista for me, and I don't have access to Windows 7 -- nor do I know which damn charset Windows 7 uses for its console. You could try "--output-charset CP850" or "--output-charset CP1252" or something like that.

Please read http://forum.doom9.org/showthread.php?p=1288702#post1288702 for an explanation of the issue of code pages on Windows (short version: Windows uses two different ones, one for the system and one for the cmd.exe thingy. Maybe they changed that in Windows 7 for cmd.exe).

[stax76]

I've entered chcp to find out the codepage, it's 850 on my english Win 7 system and Umlaute are NOT displayed correctly. On my german XP system codepage is also 850 but Umlaute are displayed correctly. Would it be possible that mkvmerge would output Umlaute on my system correctly without requiring me to use '--output-charset CP1252'?

[Mosu]

Not at the moment. And I won't spend any time on it until I have a Windows 7 installation myself which will most likely not be for the next couple of months.

[stax76]

I guess the problem occurs also on english XP and Vista, the thing is english people use english versions and german people use german versions which is the common case which don't cause the issue I guess. I'm german but use a english version and this is uncommon.

How about using GetACP instead of GetOEMCP for determining which CP to use for console output? Would this possibly break something?

[Mosu]

Yes, it breaks pretty much everything for anyone using any of my tools on the console. E.g. on a German Windows XP using "--output-charset CP1252" (1252 = GetACP()) in cmd.exe results in unreadable Umlaute.

My guess is that Windows 7 changes something fundamentally regarding which code page cmd.exe uses. So my tools will have to check the OS it is run on and use GetACP() even for console output on Windows 7, but again, that's just guesswork.

Consider Windows 7 the uncommon case, and that's why I will certainly not get rid of GetOEMCP() for the time being.

[stax76]

I don't think Win 7 changes something, if you like I can install a english XP to verify this.

[Mosu]

German Windows XP: CP 850, Umlaute work. Same on a German Vista. English Windows 2003 Server: CP 437. Umlaute work without changing the --output-charset (!).

So no, there's no real need for you to install an English XP. The only thing that would actually interest me is having a copy of Windows 7 myself. Until then -- topic closed for me.

[stax76]

Before I saw your post I've installed an english Windows 2000 with german locale settings within VirtualBox, no problem with Umlaute. You can get Windows 7 RC here:

http://www.microsoft.com/germany/windows/windows-7/download.aspx

I've skipped Vista using XP until 25 days ago so for me it's quite a improvement, it works and looks very well.

I don't know how long it will work legally, I think 3-4 months.

http://www.mydigitallife.info/2008/11/06/how-to-rearm-and-extend-free-usage-activation-grace-period-of-windows-7-to-120-days

[Mosu]

Until Windows 7 is final and released I will not spend any time on it. At least not regarding mkvtoolnix.

[tetsuo55]

Until Windows 7 is final and released I will not spend any time on it. At least not regarding mkvtoolnix. Any beta or RC1 build of Windows 7 is at least 1% (and at most 100's of %) faster and more stable than vista SP2/XP(where xp is faster it comes at the cost of either security or stability).

Also the final build has already been compiled and is available for OEM partners.

The whole point of MS releasing the OS in its pre-release form to software developers and end users it to make sure, that when it gets released in 2 months all software will work properly on it.

(I don't think there are any changes between RC1 and RTM that would make any difference for mkvtoolnix)

---------
Actually, and i'm not sure how it works, but you can sign up to the Microsoft software testing program, as a trused software vendor.
This will give you access to all the crash dumps generated by mkvtoolnix and performance data and other stuff handy for bugfixing.
Also this might cost money, but i don't think it does.
Being part of this group also gives you (100% legal and free) access to the latest test builds of all microsoft software (IIRC). And of you expose a bug in windows itself, they will supposedly fix it sooner than other bugs found.

[Mosu]

I don't care. I have more than enough to do with mkvtoolnix as it is in areas that are way more important that the issue at hand. I don't WANT to spend any time on beta versions of Windows. Simple as that. That the default charset for the console does not seem to work 100% on Windows 7 is a nuisance, but nothing more. I have no interest in being a beta tester. I've done that often enough in the past and I know how time consuming it can be.

[tetsuo55]

Yes, ofcourse you are free to chose what you do yourself.

I just wanted to make sure there are no misunderstandings about the "release candidate" label on Windows 7 which actually means something like XP SP8.

I bet that for english local, there will be no compatibility problems.

[khagaroth]

Encountering the same issue with localized command line output in Window 7, I played around a bit with mkvmerge and found out, that version 2.5.3 works correctly, anything after that shows garbled output.

[microchip8]

Hi Moritz,

I've noticed a small "problem" with mkvmerge v2.9.7 (on Linux). It seems that when you feed mkvmerge with a chapter file generated by dvdxchap, it creates an extra Menu chapter entry. I checked mkv files both in mediainfo and smplayer and, for example, if one has imported a chapters file with 25 chapter entries in it, the mkv will have 26 instead. The last chapter is somehow added by mkvmerge itself and sits in Menu #2 as reported by mediainfo on Linux. I have not had such behavior with past versions of mkvmerge. This is the report by mediainfo and the extra chapter entry is really there as I can also see it in smplayer

General

Format : Matroska

File size : 552 MiB

Duration : 1h 52mn

Overall bit rate : 689 Kbps

Movie name : The Bank Job

Encoded date : UTC 2009-07-06 20:11:17

Writing application : mkvmerge v2.9.7 ('Tenderness') built on Jul 2 2009 03:11:07

Writing library : libebml v0.7.8 + libmatroska v0.8.1

Cover : Yes



Video

ID : 1

Format : AVC

Format/Info : Advanced Video Codec

Format profile : High@L4.1

Format settings, CABAC : Yes

Format settings, ReFrames : 4 frames

Muxing mode : Container profile=Unknown@4.1

Codec ID : V_MPEG4/ISO/AVC

Duration : 1h 51mn

Width : 720 pixels

Height : 368 pixels

Display aspect ratio : 2.35

Frame rate : 23.976 fps

Resolution : 24 bits

Colorimetry : 4:2:0

Scan type : Progressive

Title : The Bank Job

Writing library : x264 core 67 r1173M f6d3166


Audio

ID : 2

Format : AAC

Format/Info : Advanced Audio Codec

Format version : Version 4

Format profile : LC

Format settings, SBR : Yes

Format settings, PS : No

Codec ID : A_AAC

Duration : 1h 52mn

Channel(s) : 2 channels

Channel positions : L R

Sampling rate : 48.0 KHz

Resolution : 16 bits

Title : HE-AACv1 Stereo

Language : English



Menu #1

00:00:00.000 : en:Chapter 01

00:07:20.800 : en:Chapter 02

00:11:15.800 : en:Chapter 03

00:13:46.333 : en:Chapter 04

00:18:58.499 : en:Chapter 05

00:21:25.333 : en:Chapter 06

00:24:45.666 : en:Chapter 07

00:28:54.699 : en:Chapter 08

00:36:29.699 : en:Chapter 09

00:40:25.666 : en:Chapter 10

00:45:53.666 : en:Chapter 11

00:50:12.333 : en:Chapter 12

00:54:07.200 : en:Chapter 13

00:56:59.366 : en:Chapter 14

00:59:48.200 : en:Chapter 15

01:02:25.300 : en:Chapter 16

01:05:46.700 : en:Chapter 17

01:09:50.000 : en:Chapter 18

01:15:37.500 : en:Chapter 19

01:22:34.533 : en:Chapter 20

01:30:42.666 : en:Chapter 21

01:38:21.166 : en:Chapter 22

01:41:49.833 : en:Chapter 23

01:45:45.633 : en:Chapter 24

01:51:53.333 : en:Chapter 25



Menu #2

00:00:00.097 : en:00:00:00.097

[Mosu]

I cannot reproduce this. I've created a chapter file with dvdxchap from ogmtools 1.5 which contains 36 entries. Then I've merged this file normally into a Matroska file (mkvmerge -o v.mkv v.avi --chapters chapters.txt). The resulting file also contains exactly 36 chapters:

[0 mosu@tionne /tmp] mkvinfo -v -v v.mkv | grep -i 'atom' | wc -l
36

Then I created a Matroska file without chapters (mkvmerge -o v.mkv v.avi) and used mmg's chapter editor's "save to Matroska file" function with the same chapters.txt file as before. The same result.

I don't know what MediaInfo thinks happens in that file or what exactly happens on your computer. How did you create that Matroska file?

Please re-check with mkvinfo. I don't trust other programs all that much in this regard.

What kind of a container format was your source file? If it was a MP4 file which in turn contained chapters (a single entry) then this might explain this behaviour. You can check this with "mkvmerge -i input.mp4".

[microchip8]

Hi Moritz,

I checked with mkvinfo and it's reported there as well. This is usually my mkvmerge command line

/usr/bin/mkvmerge --attachment-mime-type image/jpeg --attachment-name Cover --attach-file "/home/neutrino/cover.jpg" -A --title "The Bank Job" --track-name 0:"The Bank Job" "/home/neutrino/The Bank Job.avi" --track-name 1:"HE-AACv1 Stereo" --language 1:en --aac-is-sbr 1:1 /home/neutrino/audio.aac --chapters "/home/neutrino/The Bank Job.chaps" -o "/home/neutrino/The Bank Job.mkv"

I only take the video from the AVI and an external audio encoded by neroAacEnc which both get muxed into mkv.


neutrino@neutrino:~> mkvinfo -v -v "The Bank Job.mkv" | grep -i 'atom' | wc -l
26

[Mosu]

Upload the chapter file somewhere, please, or send me an email to moritz@bunkus.org

[microchip8]

Here it is http://www.mediafire.com/download.php?wemmjcmomdo

btw, could it have something to do that I use -o as last instead of as first parameter? eg, mkvmerge blablabla -o output.mkv VS mkvmerge -o output.mkv blablabla

[Mosu]

/usr/bin/mkvmerge --attachment-mime-type image/jpeg --attachment-name Cover --attach-file "/home/neutrino/cover.jpg" -A --title "The Bank Job" --track-name 0:"The Bank Job" "/home/neutrino/The Bank Job.avi" --track-name 1:"HE-AACv1 Stereo" --language 1:en --aac-is-sbr 1:1 /home/neutrino/audio.aac --chapters "/home/neutrino/The Bank Job.chaps" -o "/home/neutrino/The Bank Job.mkv"

1. The audio track in an AAC file has the ID 0, not 1. All the parameters e.g. "--track-name 1:..." will do nothing at all. mkvmerge outputs a warning for that.

2. I still cannot reproduce the problem here with the chapter file you've uploaded. AVI files do not contain chapters (or mkvmerge doesn't support reading chapters from them). So I really don't know what's wrong here. You may upload the AVI file in question to my FTP server if you want, but if not then I cannot really help you. BTW, please post the output of 'mkvmerge --identify-verbose "/home/neutrino/The Bank Job.avi"'.

btw, could it have something to do that I use -o as last instead of as first parameter? eg, mkvmerge blablabla -o output.mkv VS mkvmerge -o output.mkv blablabla

3. No.

The following command line uses dummy files in place of your original ones, obviously:

[0 mosu@tionne ~/dl] mkvmerge --attachment-mime-type image/jpeg --attachment-name Cover --attach-file ~/files/Pictures/Desktop/gilmorewall.jpg -A --title "The Bank Job" --track-name 0:"The Bank Job" ~/prog/video/mkvtoolnix/data/v.avi --track-name 0:"HE-AACv1 Stereo" --language 0:en --aac-is-sbr 0:1 /ftp/.rip/mkv/qtmp4/aac/sbr/sample_44-2-16_HE_AAC.aac --chapters "The Bank Job.txt" -o "The Bank Job.mkv"
...
[0 mosu@tionne ~/dl] mkvinfo -v -v The\ Bank\ Job.mkv| grep -i atom | wc -l
25

[microchip8]

Hi, Moritz

@1 - well, I tried both --track-name 0 and --track-name 1 on the audio.aac file and mkvmerge does not display a warning. All I see in both cases is this
'The Bank Job - chapter 1-1.avi' track 0: Using the MPEG-4 part 10 ES video output module.
'audio.aac' track 1: Using the AAC output module.

@2 I can't upload the whole AVI file since I don't have it anymore (deleted after remuxing). However, I did encode just now the first chapter of the DVD using very fast settings and very low resolution, just for testing purposes and exported the chapters with dvdxchap (I can upload that and the chapters file in a minute). Then manually muxed everything and still I get 26 chaps instead of 25

as for the identify thing...
mkvmerge --identify-verbose "/home/neutrino/The Bank Job - chapter 1-1.avi"
File '/home/neutrino/The Bank Job - chapter 1-1.avi': container: AVI
Track ID 0: video (h264) [packetizer:mpeg4_p10_es_video]
Track ID 1: audio (PCM)

[Mosu]

Hi, Moritz

@1 - well, I tried both --track-name 0 and --track-name 1 on the audio.aac file and mkvmerge does not display a warning. All I see in both cases is this

Then you only have a single AVI file as an input file and not a separate AAC audio file. In any case your command line does not match what you're seeing at the moment as mkvmerge's output.

@2 I can't upload the whole AVI file since I don't have it anymore (deleted after remuxing). However, I did encode just now the first chapter of the DVD using very fast settings and very low resolution, just for testing purposes and exported the chapters with dvdxchap (I can upload that and the chapters file in a minute). Then manually muxed everything and still I get 26 chaps instead of 25

A short AVI will be enough if it shows the same problem, but please upload all the files that are part of the remuxing process.

[microchip8]

Then you only have a single AVI file as an input file and not a separate AAC audio file. In any case your command line does not match what you're seeing at the moment as mkvmerge's output.

Now I did get a warning though, but only when using --track-name 0 and --language 0. Everything set to 1 for audio.aac does not produce a warning and shows the track name and language specified while when using 0 (and getting a warning) no track name and language are shown by mediainfo

With --track-name 0 --language 0

mkvmerge -A The\ Bank\ Job\ -\ chapter\ 1-1.avi --track-name 0:"foobar" --language 0:en audio.aac -o output.mkv
mkvmerge v2.9.7 ('Tenderness') built on Jul 2 2009 03:11:06
'The Bank Job - chapter 1-1.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'audio.aac': Using the Quicktime/MP4 demultiplexer.
'The Bank Job - chapter 1-1.avi' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 313/176.
'The Bank Job - chapter 1-1.avi' track 0: Using the MPEG-4 part 10 ES video output module.
'audio.aac' track 1: Using the AAC output module.
Warning: 'audio.aac': A track with the ID 0 was requested but not found in the file. The corresponding option will be ignored.
The file 'output.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 3 seconds.

With --track-name 1 --language 1
mkvmerge -A The\ Bank\ Job\ -\ chapter\ 1-1.avi --track-name 1:"foobar" --language 1:en audio.aac -o output.mkv
mkvmerge v2.9.7 ('Tenderness') built on Jul 2 2009 03:11:06
'The Bank Job - chapter 1-1.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'audio.aac': Using the Quicktime/MP4 demultiplexer.
'The Bank Job - chapter 1-1.avi' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 313/176.
'The Bank Job - chapter 1-1.avi' track 0: Using the MPEG-4 part 10 ES video output module.
'audio.aac' track 1: Using the AAC output module.
The file 'output.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 6 seconds.

Also, even if no chapters file is added, mkvmerge still creates that very same chapters entry and each time it has a value of 00:00:00.097



A short AVI will be enough if it shows the same problem, but please upload all the files that are part of the remuxing process.

Yes, doing it now. I'll upload the AVI, chapters file, audio.aac file and the muxed mkv file so you can see the chapters entries. Since you can't reproduce it on your side, I begin in thinking that it's on my machine somehow and not mkvmerge's fault

[Mosu]

'audio.aac': Using the Quicktime/MP4 demultiplexer.

You can stop the upload(s). The audio.aac file is actually a MP4 file and not a raw AAC file. That's why the track ID starts at 1 for you and not at 0, and that's probably where the lone chapter entry comes from. Reading chapters from MP4 files is a rather new feature, that's why you don't see the problem with older versions.

You can verify this with "mkvmerge -i audio.aac"; it should show chapters. You can turn off copying chapters from that file with the "--no-chapters" option, e.g. "mkvmerge -o ... --no-chapters audio.aac".

You'd better rename the file to audio.mp4, too ;)

[microchip8]

You can stop the upload(s). The audio.aac file is actually a MP4 file and not a raw AAC file. That's why the track ID starts at 1 for you and not at 0, and that's probably where the lone chapter entry comes from. Reading chapters from MP4 files is a rather new feature, that's why you don't see the problem with older versions.

You can verify this with "mkvmerge -i audio.aac"; it should show chapters. You can turn off copying chapters from that file with the "--no-chapters" option, e.g. "mkvmerge -o ... --no-chapters audio.aac".

You'd better rename the file to audio.mp4, too ;)

Ahhh, now it's so clear. Yes indeed, neroAacEnc wraps the audio in mp4 and I didn't think of that so it was user "error" on my part :D

I'll be using --no-chapters in the future then. Thanks for the great support ;)

[Mosu]

You're welcome.

[sneaker_ger]

I've probably found another small bug in the native mpeg4 part 2 muxing. I'd advise everyone to wait until Mosu has taken a look at it before remuxing your files.

[Chumbo]

I tried adding a PCM file but it keeps thinking it's an h.264/avc MPEG4 part 10 elementary stream. Here's the eac3to info for the file.eac3to v3.16
command line: eac3to audio.pcm -log=pcm.info.txt
------------------------------------------------------------------------------
This might be a RAW/PCM file. Trying to figure out the details.
This will probably take a while. Please be patient...
The RAW/PCM file seems to be big endian.
The RAW/PCM file seems to have a bitdepth of 16 bits.
The RAW/PCM file seems to have 6 channels.
RAW/PCM, 5.1 channels, 0:00:47, 16 bits, 4608kbps, 48khzI'm still using 2.9.5 right now.

[Mosu]

Raw PCM files are not supported and never will be.

[Tima]

I have two files:

1. a.mkv with one ASS track and 3 attaches fonts.
2. b.ass

Look at the following sequence:

1. add a and b into mmg
2. uncheck ASS track (from a.mkv)
3. remux the result into c.mks

After this sequence I get c.mks without attached fonts.
Don't think it's intended behaviour.


This workaround works ok:

1. add a and b into mmg
2. remux the result into t.mks
3. reset mmg; add t.mks
4. uncheck old ASS track
5. remux the result into c.mks


If this description isn't enough, I can provide all necessary test files :)

[sneaker_ger]

I have two files:

1. a.mkv with one ASS track and 3 attaches fonts.
2. b.ass

Look at the following sequence:

1. add a and b into mmg
2. uncheck ASS track (from a.mkv)
3. remux the result into c.mks

After this sequence I get c.mks without attached fonts.
Don't think it's intended behavior.


This workaround works ok:

1. add a and b into mmg
2. remux the result into t.mks
3. reset mmg; add t.mks
4. uncheck old ASS track
5. remux the result into c.mks


If this description isn't enough, I can provide all necessary test files :)

I can't reproduce it here so you may want to upload your samples.

[Mosu]

You might also make sure that you're testing this with mkvtoolnix 2.9.7 as I have changed the way that "track-less" files are handled in one of the latest releases due to the change how mmg presents attachments, chapters and tags present in source files.

[Tima]

You might also make sure that you're testing this with mkvtoolnix 2.9.7 as I have changed the way that "track-less" files are handled in one of the latest releases due to the change how mmg presents attachments, chapters and tags present in source files.

Yes, its, 2.9.7.

Samples:
http://nwfiles.gorodok.net/a.mkv
http://nwfiles.gorodok.net/b.ass

[sneaker_ger]

Yes, its, 2.9.7.

Samples:
http://nwfiles.gorodok.net/a.mkv
http://nwfiles.gorodok.net/b.ass

OK, now I get the same behavior. It always happens when trying to only copy the attachments, but no track.

[Chumbo]

Raw PCM files are not supported and never will be.
Thanks for the info. May I ask why if you don't mind? I'm curious.

[Mosu]

Thanks for the info. May I ask why if you don't mind? I'm curious.

Almost noe one uses raw PCM files with a container format that's designed for final storage. There are several lossless audio formats that are support, and the WAV container is among them.

TLDR: Way too much work for almost no gain.

[Chumbo]

Almost noe one uses raw PCM files with a container format that's designed for final storage. There are several lossless audio formats that are support, and the WAV container is among them.

TLDR: Way too much work for almost no gain.
That's what I figured. Thank you.

[SeeMoreDigital]

Hi Mosu,

I've just done some test muxes using MKVmerge v2.9.7 and it would appear an AVC streams "stream level" aspect ratio signalling is no longer removed by default.... What was the reason behind this change?


Cheers

[sneaker_ger]

Hi Mosu,

I've just done some test muxes using MKVmerge v2.9.7 and it would appear an AVC streams "stream level" aspect ratio signalling is no longer removed by default.... What was the reason behind this change?


Cheers

I'll try to translate Mosu's post as best as possible from the German forum:


Because many hardware players can't cope with files without the SAR set within the video bitstream mkvmerge 2.7.0 was changed in a way so that the SAR is no longer removed. Personally, I think it's complete nonsense because the container - as the outer layer - is much easier to modify as the contained bitstream if you want to change the SAR. But OK, reality has told us otherwise - everyone thinks SAR within the bitstream is the way to go.

[SeeMoreDigital]

Many thanks for the confirmation sneaker_ger...

I thought it might be for that reason. So bitstream AR signalling dominates, even in the .MKV world... Great, it's about time :D

[Mosu]

No, it's not "about time". It's ridiculous. How do you expect to fix broken streams in which the encoder (either due to software bugs or human error) has stored the wrong aspect ratio in the bitstream? That's right, you demux the stream, fix it somehow, and remux again, probably losing A/V sync on the way. But the easier, more logical way of only modifying the container is barred because a lot of cheap-ass hardware players did not spend the time to pass some of the essential information from the container level to the deocer level making life harder for almost everyone else.

It's a major hassle, it sucks, it is user-unfriendly. I will never, ever write a tool that can fix the aspect ratio of the bitstream contained in a Matroska file without remuxing because it is such an unbelievable amount of work.

The container is there for a reason. That reason is to provide a lot of information in addition to the information stored in the bitstream. Some pieces of information are absolutely neccessary for proper playback -- e.g. timecodes (no, the FPS stored at bitstream level will usually not cut it, think of variable FPS video tracks).

There are generally three layers of settings/information involved in playback: bitstream layer (furthest away from human control, a bitch to modify, only information that is absolutely essential for decoding); container level (middle ground between ease of access, how easy it is to change these settings, but still distributeable and kept intact if copied from one device to another); player level (easiest to modify but not permanent). The information at higher levels should always override the information at a lower level (e.g. choice of language, display size, aspect ratio (!)) unless it makes no sense (physical dimension of the encoded picture, sampling rate for audio).

Not everyone agrees. I don't really know why nor do I want to know. For me as a software developer this leads to interesting conflicts: one group of people complains that their crappy hardware devices do not handle "no aspect stored at bitstream level", another group complains that they now cannot change the aspect ratio properly anymore.

End of rant.

[hvda]

Question about MKVMerge command line interface (from newbie).

How can I with one single mkvmerge command line (in Windows environment) put 1 video track (= .m2v file) and 2 audio tracks (each audio = single .mp2 file) into a Matroska container and at the same time set the language codes for the audio tracks ?

I managed to do it in two steps (= 2 separate mkvmerge commands) : step 1= merge into .mkv, step 2= set language codes; example:

mkvmerge -o E:\DVR\name-of-movie_NoLangCode.mkv E:\DVR\name-of-movie.m2v E:\DVR\name-of-movie.fre.mp2 E:\DVR\name-of-movie.ger.mp2
mkvmerge -o E:\DVR\name-of-movie_WithLangCode.mkv --language 2:fre --language 3:ger E:\DVR\name-of-movie_NoLangCode.mkv

But I would like to do the muxing and the settting of the language codes in one single step; something like this:
mkvmerge -o E:\DVR\name-of-movie.mkv E:\DVR\name-of-movie.m2v E:\DVR\name-of-movie.fre.mp2 --language 2:fre E:\DVR\name-of-movie.ger.mp2 --language 3:ger
(however: this syntax does not seem to work: no language codes are set in the .mkv output).

Help would be much appreciated.

[Mosu]

Yes, that is possible. There are two things to remember:

1. You should always ask mkvmerge which track IDs it assigns to each input file because track IDs are local to each input file and the method for how they are numbered varies from file type to file type.
2. All command line options apply to the following input file.

1. is easy to do: use "mkvmerge -i movie.m2v", "mkvmerge -i movie.ger.mp2", "mkvmerge -i movie.fre.mp2". You'll probably get "1" for the track in the .m2v and "0" for each of the .mp2 files.
2. means that your order is wrong.

You should end up with a command line like

mkvmerge -o E:\DVR\name-of-movie.mkv E:\DVR\name-of-movie.m2v --language 0:fre E:\DVR\name-of-movie.fre.mp2 --language 0:ger E:\DVR\name-of-movie.ger.mp2

[hvda]

Yes, that is possible. There are two things to remember:

1. You should always ask mkvmerge which track IDs it assigns to each input file because track IDs are local to each input file and the method for how they are numbered varies from file type to file type.
2. All command line options apply to the following input file.

1. is easy to do: use "mkvmerge -i movie.m2v", "mkvmerge -i movie.ger.mp2", "mkvmerge -i movie.fre.mp2". You'll probably get "1" for the track in the .m2v and "0" for each of the .mp2 files.
2. means that your order is wrong.

You should end up with a command line like

mkvmerge -o E:\DVR\name-of-movie.mkv E:\DVR\name-of-movie.m2v --language 0:fre E:\DVR\name-of-movie.fre.mp2 --language 0:ger E:\DVR\name-of-movie.ger.mp2

Thank you so much, that works perfectly well.
(I should have better read the synopsis of mkvmerge:
mkvmerge [global options] −o out [options1] <file1> [[options2] <file2> ...] [@optionsfile])

[Tima]

Mosu, any update on my issue with attachments?

[Mosu]

I will post here when and if I have an update. So no.

[jmnk]

No, it's not "about time". It's ridiculous. How do you expect to fix broken streams in which the encoder (either due to software bugs or human error) has stored the wrong aspect ratio in the bitstream? That's right, you demux the stream, fix it somehow, and remux again, probably losing A/V sync on the way. But the easier, more logical way of only modifying the container is barred because a lot of cheap-ass hardware players did not spend the time to pass some of the essential information from the container level to the deocer level making life harder for almost everyone else.

It's a major hassle, it sucks, it is user-unfriendly. I will never, ever write a tool that can fix the aspect ratio of the bitstream contained in a Matroska file without remuxing because it is such an unbelievable amount of work.

The container is there for a reason. That reason is to provide a lot of information in addition to the information stored in the bitstream. Some pieces of information are absolutely neccessary for proper playback -- e.g. timecodes (no, the FPS stored at bitstream level will usually not cut it, think of variable FPS video tracks).

There are generally three layers of settings/information involved in playback: bitstream layer (furthest away from human control, a bitch to modify, only information that is absolutely essential for decoding); container level (middle ground between ease of access, how easy it is to change these settings, but still distributeable and kept intact if copied from one device to another); player level (easiest to modify but not permanent). The information at higher levels should always override the information at a lower level (e.g. choice of language, display size, aspect ratio (!)) unless it makes no sense (physical dimension of the encoded picture, sampling rate for audio).

Not everyone agrees. I don't really know why nor do I want to know. For me as a software developer this leads to interesting conflicts: one group of people complains that their crappy hardware devices do not handle "no aspect stored at bitstream level", another group complains that they now cannot change the aspect ratio properly anymore.

End of rant.
@Mosu - first, thanks for great piece of software. I have almost no issues ever with it, and the results are not only predictable but also logical.
Now, I almost agree with you completely, except one case. If I mux multiple video streams (let's assume two x264 streams) into mkv, and the streams happen to be flagged at different aspect ratio (like there are DVD extras that are often 4:3 while the main feature is 16:9), how would I deal with it if only container level signaling was to be used?

[Mosu]

I'm not proposing that bitstream AR information is to be ignored -- but that container AR information should override bitstream AR information if container AR information is available. If it isn't then bitstream AR information should be used. This is already implemented for most cases in the "player" layer: if you set MPC to a specific aspect ratio than that will be used regardless of what is stored in the bitstream.

The case of changing aspect ratio mid-stream is another problem, I agree. For this containers should provide a way of signaling such changes. For Matroska there is no such element available, so such cases are not covered by my ideal case outlined in the rant above.

[buzzqw]

maybe a stupid question

why the same file, muxed two time (with different name) have dirrect crc/md5 value ?

should be mkv 's md5 equal for the same input file every time is muxed ?

thanks

BHH

[Mosu]

Several fields in a Matroska file differ each time mkvmerge is run, even if you have identical input and settings. Among them are fields like unique IDs for tracks/attachments/chapters etc or the muxing timestamp.

mkvmerge knows an option that causes it to produce bit-identical files for identical inputs and settings. However, such files are not meant for playback, and that option is only used by myself for regression tests.

[buzzqw]

yep, using same input, muxed with same options, produced different crc

not a problem

thanks again

BHH

P.S. and you cannot share this hidden option ?

[sneaker_ger]

"--engage no_variable_data"

[buzzqw]

thanks!

BHH

[Mosu]

I have two files:

1. a.mkv with one ASS track and 3 attaches fonts.
2. b.ass

Look at the following sequence:

1. add a and b into mmg
2. uncheck ASS track (from a.mkv)
3. remux the result into c.mks

After this sequence I get c.mks without attached fonts.

The problem was only present in mmg, not in mkvmerge itself. It has been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090713-146-setup.exe

[Egh]

@Mosu:

neither 145 nor 146 build MMG works here. (Windows XP x64). Reverted back to 142 and all is OK.

BTW, I keep forgetting to tell you -- it seems your installer doesn't overwrite newer files. Is it per design?

[Mosu]

@Mosu:

neither 145 nor 146 build MMG works here. (Windows XP x64). Reverted back to 142 and all is OK.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090713-149-setup.exe should work.

BTW, I keep forgetting to tell you -- it seems your installer doesn't overwrite newer files.

I know.

Is it per design?

I have no strong feelings one way or the other. But I won't spend any time on it either; so unless someone provides a patch for the NSIS script I won't change it.

[fingershop]

Two possible bugs:

For subtitle tracks, the Default track flag, if set to "default", is being set to Yes instead, as seen when I open the muxed file in MMG. If I set the flag to No, mux, open the file, its now set to Default.

For chapter tracks, the language value is not being saved to the muxed file.

[Mosu]

Two possible bugs:

For subtitle tracks, the Default track flag, if set to "default", is being set to Yes instead, as seen when I open the muxed file in MMG. If I set the flag to No, mux, open the file, its now set to Default.

The value "default" refers to mkvmerge's default settings, not to the actual value of the flag in the resulting file. Setting it to default means "let mkvmerge decide". mkvmerge does indeed set the DefaultTrack flag for the first subtitle track.

Setting the drop down box to "No" results in the DefaultTrack flag being set to "0" for that track for me, so I cannot reproduce this. Anyway, I doubt that there's really a bug.

For chapter tracks, the language value is not being saved to the muxed file.

The language value only applies to chapters read from files which do not contain language tags for the chapters themselves. These include MP4 and Ogg/OGM files, but not Matroska files, as chapters in Matroska files have their own language tags. If you want to force a different language for chapters in a Matroska file you have to use the chapter editor's "adjust values" function.

[fingershop]

The value "default" refers to mkvmerge's default settings, not to the actual value of the flag in the resulting file. Setting it to default means "let mkvmerge decide". mkvmerge does indeed set the DefaultTrack flag for the first subtitle track.


Oh, that explains it then. I'd been thinking that mkvmerge/mmg were muxing transparently, but its applying a default of Yes to the first sub track. For me this behavior is only useful for non-dubbed foreign language movies and shows, which make up at most a tenth of my files.

Could you provide a global setting that would by default copy all track attributes as they are? This would help a lot, especially when re-muxing. When I load a file that contains subs, I'd rather it show "No" if that is what the sub track was originally set to.

The language value only applies to chapters read from files which do not contain language tags for the chapters themselves. These include MP4 and Ogg/OGM files, but not Matroska files, as chapters in Matroska files have their own language tags. If you want to force a different language for chapters in a Matroska file you have to use the chapter editor's "adjust values" function.

I learn more all the time! Thanks. I do think it would be more consistent if mmg treated chapter tracks the same as it does all the other track types that support the language attribute. Setting the chapter language from the track list would also be much easier too.

[nurbs]

Does that really matter? The only player (both hardware or software) I know that displays the default subtitle track without user intervention is VLC.

[Mosu]

Oh, that explains it then. I'd been thinking that mkvmerge/mmg were muxing transparently, but its applying a default of Yes to the first sub track. For me this behavior is only useful for non-dubbed foreign language movies and shows, which make up at most a tenth of my files.

Yeah I noticed this myself yesterday. This is a bug. Normally when left on "default" mkvmerge should honor the source container's setting for the flags. So if you add a Matroska file with a subtitle track and its "default track" flag was set to "no" ("0" in mkvinfo's output), leave the drop down box in mmg on "default" then the subtitle track should have its "default track" flag turned OFF in the output file as well. I'll get it fixed in the next couple of days.

I do think it would be more consistent if mmg treated chapter tracks the same as it does all the other track types that support the language attribute. Setting the chapter language from the track list would also be much easier too.

I will not change that, sorry.

[Mosu]

For subtitle tracks, the Default track flag, if set to "default", is being set to Yes instead, as seen when I open the muxed file in MMG. If I set the flag to No, mux, open the file, its now set to Default.

This problem should be fixed in the following build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090716-158-setup.exe

[fingershop]

This problem should be fixed in the following build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090716-158-setup.exe

Cool! Now it acts like I was thinking it did. Thanks for the quick update.

[fingershop]

Does that really matter? The only player (both hardware or software) I know that displays the default subtitle track without user intervention is VLC.

Zoom Player does as well, and I suppose standards are there for a reason :-)

[fingershop]

I do think it would be more consistent if mmg treated chapter tracks the same as it does all the other track types that support the language attribute. Setting the chapter language from the track list would also be much easier too.

I will not change that, sorry.



I understand. And since we're on the subject... here are two related wishes of mine for your consideration:

1) The ability to add chapter text files to the track list in the same way as other track types. Most chapters I work with are unique to each muxed file and are not global, and I'm constantly forgetting to remove or update the chapters file on the global tab.

2) For chapters in the track list, I'd like to open them in the Chapter Editor to edit them, and then use this edited version when I mux (maybe a "save track changes" command on the Chapter Editor menu?). An alternate version of this wish would be: to allow setting a Delay for chapter tracks, the same as other track types.

A large part of my reason for these requests is that I'm converting my dvd collections to mkv, and I like keeping the original chapters from the dvds. The ripper I use saves the chapters in a file with the same name as the individual vobs and/or individual streams, and I can quickly add these files to mmg by using a wildcard file extension in the Add window -- except for the chapter files that are currently entered separately on the Global tab. After the initial mux, I need to briefly play each file and test the chapters to make sure they line up correctly, and if they don't then I need to adjust their timing. This would be much quicker and easier if adjusting (or editing) chapter timings were possible from the track list.

[Mosu]

I understand. And since we're on the subject... here are two related wishes of mine for your consideration:

1) The ability to add chapter text files to the track list in the same way as other track types. Most chapters I work with are unique to each muxed file and are not global, and I'm constantly forgetting to remove or update the chapters file on the global tab.

No, sorry.

2) For chapters in the track list, I'd like to open them in the Chapter Editor to edit them, and then use this edited version when I mux (maybe a "save track changes" command on the Chapter Editor menu?). An alternate version of this wish would be: to allow setting a Delay for chapter tracks, the same as other track types.

Neither this, again, sorry.

The time I save you is very short compared to the time it would require me to implement such features. And free time is the one thing that I do not have in abundance. I'm not against implementing those features per se. If someone contributed a patch that implemented them I'd happily accept it. That someone just won't be me.

[Mosu]

In case anyone wonders. What I am working on is fixing bugs (always time consuming) and dealing with support requests (even more time consuming). The next two new big features will be support for MPEG transport streams (will take huge amounts of time to do it right -- especially with all those abominations of spec violations out there) and support for specifying cut points ("only copy from timecodes A to B and from K to L", again a lot of work) -- probably in that order.

[Egh]

The next two new big features will be support for MPEG transport streams (will take huge amounts of time to do it right -- especially with all those abominations of spec violations out there)

Good luck with that, that would be a very cool feature. I completely agree regarding all the possible abominations. I don't know any .ts related software which would be able to process properly all the kinds of different .ts files I have. Amongst them, DGIndex is probably most stable, though not for all files. Proper implementation may indeed take a great deal of time...

[Chumbo]

...The next two new big features will be support for MPEG transport streams (will take huge amounts of time to do it right -- especially with all those abominations of spec violations out there) and support for specifying cut points ("only copy from timecodes A to B and from K to L", again a lot of work) -- probably in that order.
These are great features. Thank you for your continued efforts. This tool is invaluable.

[fingershop]

The time I save you is very short compared to the time it would require me to implement such features. And free time is the one thing that I do not have in abundance.

Especially with what you're currently working on.


I'm not against implementing those features per se. If someone contributed a patch that implemented them I'd happily accept it. That someone just won't be me.

Glad to know...

Cheers!

[Mosu]

Especially with what you're currently working on.

In fact I haven't really started working on TS support yet (apart from two, three hours of reading ffmpeg's/mplayer's source code). But what little free time I do have I don't want to spend on other features.

[Snowknight26]

Croatian (scr) seems to be missing from valid language choices in the newest builds. Every time I try to mux an mkv I made with scr set as one of the languages (done with v2.4.1), 2.9.7 says
Error: 'scr' is neither a valid ISO639-2 nor a valid ISO639-1 code. See 'mkvmerge --list-languages' for a list of all languages and their respective ISO639-2 codes.


Granted, I can't find scr in neither list of languages (not surprising as its really hvr), though it's strange that it once worked before. Heck, even eac3to it shows the track as Croatian (confirmed with the -logmkv switch).


Edit: And that solves that..
http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=commitdiff;h=12d4a2f59f2985d89bc735503fdf55390505aa71

[Mosu]

Correct. 'scr' was an obsolete code that has been removed because it has been removed from the official ISO639-2 lists as well.

[mbcd]

I often read (and had) some mkv have errors in EBML-Structure.

Now I´m asking if it is possible to repair such errors. There is no known methode or program for repairing such errors, but fact is:

- These files often play (with errors on scrubbing or jumping on timeline) with some players.
- You can not demux/extract them or do any other things with them until to this specific error-position.

Is it possible to repair those files ?
Recovering Data is of course maybe impossible, but maybe its possible to scan the whole stream an rewrite/reorder/skip some Header, or skip faulty Bytes who are damaged.

I mean: Its better to get a repaired file with "one frame missing" (due wrong EMBL-Entry) as loosing the whole file.

Or maybe: Implementing a check after muxing. These EBML-Errors must have its fault somewhere. Maybe a check after muxing should be fine.

Regards

[Mosu]

My answer will be a bit longer. Get some coffee.

You're talking about two different aspects: error prevention and error recovery.

Error prevention:

I can almost guarantee that the muxing process produces 100% correct EBML structures. The libraries I use have been basically unchanged for five years, and there's not a single confirmed report that one of my tools create corrupt EBML structures. Also having a check after muxing imposes a false sense of security due to several reasons:

1. The library used for validation would be the same library used for creation. If one is serious about validation then this is a no go.
2. Caching. The file just created will always be partially cached by the operating system, and how big this part is depends on various factors like overall memory size, operating system type and version and current memory usage. Therefore the validation process would not be able to test if the file is stored correctly on the hardware ( = hard disc, flash drive etc) reliably.

Which leads me to the two obvious reasons and another not so obvious one why files get corrupted.

The first is bad hardware. This is actually more common than one might think or hope. Having unrecoverable hard disc read errors does occur, it's no myth. While this is usually not a fatal error in the sense that the hard disc cannot be used anymore (due to techniques like sector reallocation) it does mean that data read from that sector is corrupt and that the application has to deal with it. This is even more common for flash drives. Most flash drives use cheap memory, and those chips (cheap or not) are very susceptible to things like environmental conditions etc. Those things are not suited for long-term data storage. I even go so far as to create checksums of all important files that I transfer with flash drives due to past experience with corrupted files.

The second cause is bad transmission. Downloading files from the Internet (no matter if it's legal or not) always poses a risk of data transmission errors. If checksum files are available together with the download then you should always use them to verify data integrity.

The not so obvious reason applies to illegal downloads. There are companies working for the major movie and music studios that create faulty files or files that are 100% garbage, name them after certain popular movies and offer them for download.

Like I already said: use checksum tools for error detection even if you store your files locally. They're freely available and only require a little bit more work.

Now on to error recovery.

The library mkvmerge uses is not good in dealing with faulty files. Sometimes it can recover and continue from the next valid cluster, but often it cannot. There's nothing I can do about it, or at least nothing I'm willing to do due to the huge amount of time involved in creating my own set of libraries and changing about 60% of all of mkvmerge's code that depends on this library either directly or indirectly.

If you need error recovery and restoration of original files then there are external techniques like PAR files that can offer increased security at the cost of a certain percentage of the file's size.

[Kurtnoise]

Hey Mosu,

I've a question regarding the EditionUID value : does the length of this is defined somewhere ? or does any random value is acceptable ?

[Mosu]

EditionUIDs are unsigned integers != 0. Integers in Matroska files can be up to eight bytes long; however, due to the way they're stored in a Matroska file (variable length encoding) only seven bytes can actually be used.

[sneaker_ger]

A small request:

When muxing raw AVC content mkvmerge GUI displays a warning when not setting the FPS field even when feeded with a timecode file. It could lead to irritation as the FPS value is neither required nor used in that case and shouldn't be displayed.

[sneaker_ger]

In the MPC-HC thread there was a small discussion about UTF-8 subtitles. Maybe you could expand the documentation a little and explicitly state that UTF-8 subtitles with BOM are automatically detected as UTF-8 and not with the system charset.

[Mosu]

Maybe, maybe not. Patches are always welcome. mkvmerge handles all text files the same way: if there's a BOM present then the BOM dictates the file's charset. Otherwise an --xyz-option will be used if one is present, and if it isn't then the system's locale is used.

[Gew]

Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 60 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 121 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 147 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 317 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 113 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 146 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 256 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.


Each part is not a lot of data... 100-300 bytes here and there isnt a problem... But when this happens 50 times in a single video, by the end the sound is out of sync. Is there any way to get mkvmerge to ignore these errors and keep these bytes intact? Or possibly replace these bytes with delays equivalent to the timing?

I know I'm bumping a ~2 year old post, but I believe that the question is still relevant. I had the very same issue earlier this day, when trying to MKVmerge an .avi w/ the same "garbage padded" mp3 audio, causing the end-product .mkv to lose it's sync at the end of the video.

I was looking for a solution, so I figured I would try some alternative muxers. I started labbing..


1st tryout: ffmpeg (-vcodec copy -acodec copy -f matroska).

Resulted in a a mkv without sync issues, but with b-frame malfunction, causing picture to become all messy (for a longer time, aswell) after seek.

2nd tryout: AVI-mux

Resulted in an mkv with audio just "cut off" about 10 minutes into the clip, presumably after the first occurrence of audio chop spot. Gah!

3rd tryout: VirtualDubMod

This is where I reached success. The .MKV file was playing fine, seeking was fine, without any sync errors.


MediaInfo reported a slightly outdated libmatroska (go figure :)) though, so just for compatibility I ran "mkvmerge -o finalproduct.mkv vdubmodmuxres.mkv".

Now, it worked fine.

I'm still a bit left out in the cold in regards to what happened under the hood of this machinery, but I assume that VDubM could have made a few assumptions and/or automatized silent mp3 padding when muxing.

Anyways. Worked! :)

[Liisachan]

Interesting. It is not unusual to see AVI that has a broken MP3 frame at the very first or at the very end. Cut-and-pasting AVI segments can easily cause the problem.
One typical situation is the one where the video must have a length of 1001/24000*integer seconds (i.e. 1 frame = about 42ms), and when AVI is edited the last MP3 frame gets broken, cut at the wrong place in the middle, unless the length is exactly 24ms*integer, which is unlikely because of the first condition.
If VDM just does zero padding and reconstructs one complete MP3 frame whenever it finds a broken MP3 frame, then I think the audio will be delayed little by little and getting out of sync anyway. At least in the above situation. If AVI has a lot of broken MP3 frames and the result by VDM is still ok, VDM might be doing both padding and discarding--if the bad MP3 frame is big, zero-pad (or discard it and make up a new one by just repeating the previous MP3 frame), and if the bad frame is smaller discard it. Then the result would be acceptable on average. Who knows?

Anyway, I heard that MKV created by VDM is broken, because like you said, the app is quite old and not maintained. Doing mkvmerge again is a good idea. Hope that will fix the problem. I mean, VDM may fix your problem, but it may create other (not-so-noticeable) problems :)

[Mosu]

Hey,

I've released mkvtoolnix v2.9.8. This release contains contains the usual mix of bug fixes and smaller enhancements. The most prominent enhancement is probably the big speed-up in mmg's header editor for parsing existing files.

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.7:

------------------------------------------------------------
2009-08-13 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.8.
* mmg: bug fix: The inputs for timecode files and the language are deactivated if the user has selected a track that will be appended to another track. Fix for bug 432.

2009-08-06 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: mmg will handle multiple consecutive spaces in the options given with "add command line options" properly and not cause mkvmerge to exit with misleading error messages anymore. The "add command line options" dialog has been reordered, and the drop down box in it is now read-only. Fixes for bug 429.
* doc, mmg: bug fix: The tooltip and documentation for the 'delay' option was misleading. Fix for bug 420.

2009-07-31 Moritz Bunkus <moritz@bunkus.org>
* mmg/header editor: enhancement: Implemented a considerable speedup in the processing of large files.

2009-07-30 Moritz Bunkus <moritz@bunkus.org>
* mmg/header editor: bug fix: The header editor copes better with files that do not contain all mandatory header fields. The missing ones are added or assumed to be default values.

2009-07-23 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: Selecting the translations with the "--ui-language" option did not work on Mac OS X.

2009-07-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an invalid memory access in the VobSub reader module. Fix for bug 426.
* mmg: bug fix: Tracks added from Matroska files did not get their 'default track' drop down box set correctly if the flag was 'off' in the source file and no other track of its kind hat its 'default track' flag set.
* mkvmerge: bug fix: mkvmerge was wrongly turning the 'default track' flag back on for the first subtitle track muxed from a Matroska file if none of the subtitle tracks muxed had their 'default track' flag set in their source files and if the user didn't use the '--default-track' option for setting that flag explicitely.

2009-07-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Running mkvmerge on Windows from an installation directory with two spaces in the path (e.g. "C:\Program Files\Video tools\mkvtolnix") crashed mmg when the user started muxing. Fix for bug 419.

2009-07-13 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Files for which all tracks were disabled were left out from mkvmerge's command line so that tags, chapters and attachments were not copied from such files either.
* mkvmerge: bug fix: Appending MPEG4 part 2 video tracks from Matroska files which contain aspect ratio information will not result in an error message "connected_to > 0" anymore. Fix for bug 427.

2009-07-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the audio sync for tracks read from AVI files containing garbage at the beginning. Fix for bug 421.
* mmg: bug fix: Trying to save chapters that contain editions without a single chapter entry does no longer result in a crash but a descriptive error message instead. Saving empty chapters to a Matroska file will remove all chapters contained in the file instead of not doing anything. Fixes for bug 422.

2009-07-05 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: enhancement: Implemented speed-ups of up to 50% for middle to larger files.

2009-07-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading AVC/h.264 video tracks from OGM files. Fix for bug 418.
* mmg: bug fix: The chapter language for chapters copied from source files (e.g. Matroska, MP4 or OGM files) is only changed if the user has selected any language other than "und". Fix for bug 420.
* mmg: bug fix: mmg will no longer show an error message if the user has not selected a country in the "chapters" tab of the preferences dialog.
------------------------------------------------------------

Have fun.

[Mosu]

In the MPC-HC thread there was a small discussion about UTF-8 subtitles. Maybe you could expand the documentation a little and explicitly state that UTF-8 subtitles with BOM are automatically detected as UTF-8 and not with the system charset.

The man page now contains such a paragraph ("Text files and character set conversions").

[roozhou]

Hi Mosu,

Recently I have noticed a problem concerning delay in aac audio. Maybe I should start a new thread because this problem does not only occur with matroska.

I cut an audio sample of 10.031s and encoded it to he-aac using neroAacEnc. The resulting mp4 show 10.136s in MediaInfo. If I decode the mp4 through foobar2000 or neroAacDec, the decoded wav has an exact length of 10.031s. But if I decode the mp4 through mplayer or directshow it gave me 10.090s and a delay of ~59ms. When I mux it into mka through mmg and decode it again through foobar2000 it gave me the same 10.090s and the delay.

The delay also occurs when I extract the aac to adts or remux it to mp4. Apparently there was information, which cannot be shown from MediaInfo, indicating the decoding delay of the aac stream in mp4. Such information gets lost when you remux it to another container. I also tried adding a negative delay in mmg but it just strip one or two frames at the beginning of aac stream, which is not what i want.

My question:
Will there be an A/V async if I mux aac with video into matroska and play it in mplayer or through directshow? Although 59ms delay could be too difficult for me to notice, there can larger delay (e.g. CT AAC with SBR+PS gives me ~112ms delay on 44100Hz source).

[Mosu]

Probably not.

[LeXXuz]

Hi Mosu,

I backed up my whole DVD Collection a couple of month ago to AVC with AC3/DTS or AAC audio. Now I want to add some extra audio tracks with heavy DRC.

So far so good, but every 4th or 5th movie is out of sync (when playing it with the new audio tracks). I remember that a lot of discs had some audio delay which I let mmg/mkvmerge take care of when creating my backups.

From what I found on the last 57 pages of this thread, since version 2.4.0 mkvmerge no longer tampers with the files. It modifies the timecodes instead.

Is there no way to find out this delay? It would save me a huge ammount of time, since I have to manually check and correct every movie for a/v-sync.

[Mosu]

No, sorry.

[LeXXuz]

No, sorry.

I had a feeling I would get an answer like that. :D

Just out of curiosity, can you explain a bit more in detail why this is not possible? :)

[VEGITA]

Hello, I'm having trouble merging 4 mkv files, all encoded with the same settings using x264. Two of the files are under 200MB and the other are a little over 200. The smaller files join without a problem but when I try to join the bigger files to the smaller ones the output file is smaller than it should be, I'm talking 25% smaller.
Anyone else had this problem, because I've had this problem 2 months ago on an older build of mmg and gave up on it but I spent like 4 days encoding these and it would be a pain to encode it again.

[buzzqw]

but it is ok ?

don't look at file size, is your muxed file perfectly watchable or is ruined ?

BHH

[VEGITA]

it always cuts a few minutes from the resulting file, the last 4-5 minutes, other than that it looks like the input files.

[Mosu]

I had a feeling I would get an answer like that. :D

Just out of curiosity, can you explain a bit more in detail why this is not possible? :)

Because there's no such thing as 'the delay of this track'. There are only timecodes. Packets are not muxed into the resulting file if their effective timecode is < 0. However, that doesn't mean that the first packet's timecode is automatically 'the delay'. An example:

In the original file the first video frame starts at 0ms, the first audio track's packet at 15ms with a duration of 40ms. Now you delay the audio track by let's say -40ms. The resulting file's first audio packet will be at 35ms then. But does this mean that you can use +35ms as the delay for muxing other tracks? Obviously not.

[sneaker_ger]

1.) shouldn't the first packet also start at 15 ms in your case as you're delaying by the length of exactly one frame? What am I missing?
2.) If the delay is longer than the audio frame duration it should probably be sufficient to look at the timecodes, right?

[Mosu]

The 40ms delay was a bad example, yes. Take any other value, e.g. -5ms. Then the first audio packet would start at +10ms, but those +10ms are not the delay you'd need for adding yet another track.

[sneaker_ger]

Despite obviously being a bad example I wanted to state that your calculation was wrong.
And your new example's also bad, since you're not cutting away any frames in it, so "+10ms" is the delay you'd need for adding another track. Or am I mistaken?
And what about my second question?

[Mosu]

If both of the audio tracks come from the same source then both need the same delay of -5ms obviously, even though that isn't obvious from the first packet's timecode. There are several cases in which simply taking the first packet's timecode as the delay will not work. There are cases where it will work. Just try it, watch the resulting file, if A/V sync is off then re-mux with adjusted delay and repeat.

2.) If the delay is longer than the audio frame duration it should probably be sufficient to look at the timecodes, right?

No. For the same reason as stated above.

Anyway, end of topic for me. Sorry. Just try muxing with different values; if the first timecode works for you then fine, if not then adjust and retry.

[zn]

Is it possible to select/skip some parts in --split mode?
When I need to extract only 1 part of video it is doing full processing.

[Mosu]

No. Yes, it has been requested multiple times. Yes, I will probably implement something like that. No, this will not be in the near future.

[LeXXuz]

I've noticed that mkvmerge and mkvextract produce heavily fragmented output files (Windows).

I was wondering if this is a problem of mkvmerge's writing routine, as other muxers (tsmuxer, avimuxgui,...) do not produce such fragmented files.

I've demuxed a 9GB Matroska file to an almost empty partition. OO Defrag show's that the files are spread all over the volume.

[Mosu]

Both tools write files in small chunks, does not use any preallocation or similar and have pretty much no optimizations in this regard. This will stay that way until someone provides a good patch for me.

[Inspector.Gadget]

Is there a way I can append Matroska files - each containing streams that I encoded with the same parameters - to generate one big file with automatic chapter markers at join points?

[sneaker_ger]

Are there any plans on supporting Blu-Ray Subtitles?

[Mosu]

Plans yes, but no timetable.

[Eraser_stp]

Any chances for Windows x64 build?

[Mosu]

No, sorry.

[73ChargerFan]

Mosu, it works fine under x64, right? I'm moving from xp to Win7 64 soon.

[Mosu]

I don't have any first hand experience with 64bit Windows as I don't have such an installation. But I haven't heard of it not working on 64bit Windows yet, so my guess is that yes, it does work.

[Thunderbolt8]

a small request, would it be possible to add the field 'var (various)' in the language field of tracks? atm the only other option is undetermined, but this is just different from saying that this tracks features more than just 1 language.

[Mosu]

No, sorry. The Matroska specs list which values are acceptable for the 'track language' element, and those are the ISO639-2 codes and 'und'.

[m3mbran3]

I am having trouble with the Header Editor on Vista x64 and mkvmerge 2.9.8. I open up my .mkv file created with x264 and make a couple of changes, but when I hit save the program crashes. I have even tried opening the file and saving it without making any changes but it still crashes. logfile is below, any help appreciated.


Problem signature:
Problem Event Name: APPCRASH
Application Name: mmg.exe
Application Version: 2.9.8.0
Application Timestamp: 4a83f000
Fault Module Name: mmg.exe
Fault Module Version: 2.9.8.0
Fault Module Timestamp: 4a83f000
Exception Code: c0000005
Exception Offset: 000e0ec5
OS Version: 6.0.6002.2.2.0.768.3
Locale ID: 3081
Additional Information 1: fd00
Additional Information 2: ea6f5fe8924aaa756324d57f87834160
Additional Information 3: fd00
Additional Information 4: ea6f5fe8924aaa756324d57f87834160

Read our privacy statement:
http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409

[Mosu]

Please try to create a small(er) file with x264 for which the header editor crashes. Then upload that file to my FTP server and I'll take a look at it. Thanks.

[LeMoi]

a small request, would it be possible to add the field 'var (various)' in the language field of tracks? atm the only other option is undetermined, but this is just different from saying that this tracks features more than just 1 language.

You have 'mul' = multiple languages, doesn' fit ?

[Mosu]

Nice one, LeMoi. I didn't know that was in there already :) Looks like that one came directly from the official ISO639-2 list because I certainly don't remember adding it manually.

[stax76]

Hi mosu, is it OK to package mkvtoolnix without GUI stuff? My package is 20 MB and I want to keep it as small as possible so I've removed mmg.exe and files starting with wx as I assumed wxwidgets is only used in mmg. A user reported a crash due to missing wx files so it seems at least one of the command line applications uses a wx file.

[Mosu]

mkvmerge, mkvextract and mkvpropedit (new application coming soon) are all text-only and don't need any of the wxWidgets libraries. mmg and mkvinfo both need the libraries even though mkvinfo can be compiled without GUI support -- but my Windows build isn't.

You can safely leave out the wxWidgets DLLs. But please remember to include at least the doc\README.txt and the doc\COPYING.txt files -- they contain the license and are NOT optional for a binary distribution.

[stax76]

Thanks, do you know where I can download a mkvinfo build that don't need wx? Maybe this was the reason for the issue reported (http://forum.doom9.org/showthread.php?p=1320372#post1320372) by a StaRip user.

[Mosu]

There is none at the moment. I could build one from time to time, but as it doubles the compilation time up to 15 minutes I will not do that regularly.

[stax76]

IIRC RipBot264 uses mkvinfo without any wx files as well so I wonder if it's such a wx free built, I'll ask the author.

[Mosu]

http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvinfo-nogui-2.9.8.7z

This is mkvinfo.exe without the GUI dependencies.

[m3mbran3]

Please try to create a small(er) file with x264 for which the header editor crashes. Then upload that file to my FTP server and I'll take a look at it. Thanks.

Hi mosu, I appreciate your effort looking into my problem.
I have uploaded a file to your ftp m3mbran3_headereditor.mkv that I have been having trouble with.

I downloaded a fresh copy of 2.9.8 and it still didn't work. Other than that I am using Vista x64, not sure what other dependencies are important though.

[stax76]

Danke!

[stax76]

Do I need the --aac-is-sbr switch for m4a files or does mkvmerge read this from the mp4 container?

[Mosu]

Quoting the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html):

This options is needed if a) the source file is an AAC file (NOT for a Matroska file) and b) the AAC file contains SBR AAC data.

However, this is indeed not as clear as it could be. For AAC tracks in MP4 files you usually do not need this flag as the type can be derived from the track's private data. The same is true for AAC in Matroska files. The "usual" is due to the fact that there are badly mastered files which contain the wrong private data -- e.g. if you add AAC to Matroska files using the wrong option for --aac-is-sbr.

However, there are other contains which do not contain said private data. Amongst them are AVI, OGM, raw AAC files. For those you definitely need the option if the AAC track is in fact SBR/HE. If it isn't then you don't need it :)

So in order to answer your question: Most likely you don't need the option.

[microchip8]

@Mosu, you forgot to update this thread's title. mkvtoolnix is at version 2.9.8 while thread title still says 2.9.7 ;)

[Mosu]

I know. I'll update it with the next release. Too lazy to do it now ;)

[m3mbran3]

Another thing. I noticed that the Windows 2.9.8 version zip archive version from your site reports that it is 2.9.5 in its debug window. I also downloaded and installed 2.9.8 with the installer and it reports that it is 2.9.8 in the debug window.

Both versions still crash when I try and use the header editor though.

[Mosu]

That's not correct. The 7z version of the 2.9.8 release (!) reports 2.9.8 as well -- especially as both archives (the exe and the 7z) are built from the very same compiled files. If you're using the 7z version and the debug window shows 2.9.5 then you're actually using an older mkvmerge.exe lying around somewhere in your file system. Check mmg's preferences dialog in such a case in order to find out which mkvmerge executable it is calling.

What is possible is that both the installer and the 7z version of "pre" builds report the wrong version number. This is due to the fact that they're built directly from my development directory (whereas the release versions of the installer and the 7z are built from a freshly extracted directory of the release source code archive) and I sometimes forget to re-build everything after a version number change.

But again -- http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.9.8.7z reports 2.9.8 in the debug window as well for a proper installation (I just checked to make sure).

[Mosu]

About your crash: I can reproduce it, and I know what causes it. But I don't have a lot of time at the moment, so fixing it will take a couple of days.

[Vincent Vega]

i have an avi with 1 xvid, 2 ac3 and 2 srt tracks. no matter whether i check both srt tracks or just one of them or uncheck both mmg still muxes both subtitle tracks into the .mkv. tried versions 2.9.7 and 2.9.8

p.s. i posted the same on gmane/user a few days back but there was no reply

[Liisachan]

p.s. i posted the same on gmane/user a few days back but there was no reply

Sorry about that. Actually I read your mail but only I could have said in my reply would have been "I have no idea." Does mmg/mkvmerge recognize SRT in AVI, as in muxed with AviSubMux?

Also, Vincent, you asked another question there, right?
"Is there any way to convert V_MPEG4/ISO/ASP 'back' to V_MS/VFW/FOURCC?"
I don't think I'd do that myself, but I'm curious. Mosu, can we somehow do that, directly or indirectly, using mkvextract?

[Mosu]

i have an avi with 1 xvid, 2 ac3 and 2 srt tracks. no matter whether i check both srt tracks or just one of them or uncheck both mmg still muxes both subtitle tracks into the .mkv. tried versions 2.9.7 and 2.9.8

p.s. i posted the same on gmane/user a few days back but there was no reply

This is a bug that I've already tracked down, but I don't have any AVI to test at the moment. I'll try to create one later today and check whether or not my fix works.

[Mosu]

Also, Vincent, you asked another question there, right?
"Is there any way to convert V_MPEG4/ISO/ASP 'back' to V_MS/VFW/FOURCC?"
I don't think I'd do that myself, but I'm curious. Mosu, can we somehow do that, directly or indirectly, using mkvextract?

I don't think that there's an easy way to do it (if at all). I'm aware that mkvmerge does not contain code to convert back from ASP to VFW mode, and that will not change. What might be possible is extraction with mkvextract in raw or full raw mode and then importing the file with some MP4 tool (mp4creator, MP4Box) into a MP4 and from there to AVI, but I've never tried it myself.

[SeeMoreDigital]

I don't think that there's an easy way to do it (if at all). I'm aware that mkvmerge does not contain code to convert back from ASP to VFW mode, and that will not change. What might be possible is extraction with mkvextract in raw or full raw mode and then importing the file with some MP4 tool (mp4creator, MP4Box) into a MP4 and from there to AVI, but I've never tried it myself.Just so as you know...

MP4box provides an option to de/re-mux MPEG-4 Part-2 (SP/ASP) streams from .MP4 directly to the .AVI container. It will add Xvid fourCC codes by default too.


Cheers

[microchip8]

Hi Moritz

Maybe a somewhat stupid question but I was wondering a bit here. I know that one can set movie titles (with --title) and track names (with --track-name) but there's no --genre option present. I know I can use an XML tag file (and I just added that to h264enc) to set the genre and much more, but I was wondering if a --genre option could be added for when I don't want to create an XML just for that. It'll be also nice for audio files in MKA's

[Thunderbolt8]

You have 'mul' = multiple languages, doesn' fit ?never saw that one before, thanks.

[Mosu]

Maybe a somewhat stupid question but I was wondering a bit here. I know that one can set movie titles (with --title) and track names (with --track-name) but there's no --genre option present. I know I can use an XML tag file (and I just added that to h264enc) to set the genre and much more, but I was wondering if a --genre option could be added for when I don't want to create an XML just for that. It'll be also nice for audio files in MKA's

No, sorry. I will not add any option for directly modifying tags. One of the reasons is that such an option would either be very simple and therefore completly situational (which usually leads to a lot more requests like "but I want it to do xyz" and "but I also need abc") or it's powerful and very complicated to use (which in turn leads to the users requesting a simple GUI component in mmg for it which then is supposed to turn into a full-blown tag editor).

[microchip8]

Fair enough. It's just strange that there's --title and --track-name options but --genre is completely missing (which is pretty important for audio files). I'll use the XML then

[Mosu]

Fair enough. It's just strange that there's --title and --track-name options but --genre is completely missing (which is pretty important for audio files). I'll use the XML then

That's because the title and track name elements are actual header elements and not stored in tags.

[microchip8]

I see. Can't genre be a header element too or does this violate something?

[Mosu]

The Matroska specs don't contain such an element in the track headers, and I cannot simply add one. Back when we created the specs we consciously decided against creating a multitude of tag-like header elements because all we'd accomplish is either creating a huge list of elements that almost no one ever used or we'd end up with a list that would notoriously lack one or the other. Therefore we settled for the most important elements, a title/track name, languages. The rest is supposed to be stored in tags.

[microchip8]

Makes sense. Thanks for clarification. Indeed XML is pretty powerful on itself and very flexible so I can see why such decision was made. Thanks again ;)

[Mosu]

i have an avi with 1 xvid, 2 ac3 and 2 srt tracks. no matter whether i check both srt tracks or just one of them or uncheck both mmg still muxes both subtitle tracks into the .mkv. tried versions 2.9.7 and 2.9.8

The following build fixes this issue:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.8-build20090906-171-setup.exe

[Vincent Vega]

The following build fixes this issue:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.8-build20090906-171-setup.exe

thank you Mosu for the new build, sorry didnt have a chance to see and try it earlier. worked fine for me this time srt-wise.

there's one other glitch i noticed: original file was xvid+5.1ac3+5.1ac3+srt.avi -> xvid+5.1ac3.mkv. mkvinfo and matroska shell extension show audio in the mkv not as 5.1 but as 5 channels. though ac3filter still plays it fine as 5.1

[juGGaKNot]

Rename the thread.

[Warpman]

Rename the thread.

http://forum.doom9.org/showpost.php?p=1321014&postcount=1171

[Palikrovol]

Hello Mosu.

Little problem:

I have a mkv with some attachments (images). When remuxing it with mmg (version 2.9.8 or 2.9.8 build 171) the output mkv doesn't have the files.

In the "Attachments" tab the files are checked before muxing.

To check if the mkv has the files i use the matroska shell extension or open it with mmg and take a look at the "Attachments" tab.

The image files are 'jpg' between 50 kB and 400 kB.
The input MKVs that i've tried had between 1 and 24 image files.

Any idea?

Thanks

[Mosu]

Works fine for me (I've just re-tested it).

1. Make sure your mmg is using the correct mkvmerge.exe executable and that you don't have an older version lying around somewhere.

2. What does "mkvmerge --identify-for-mmg the-remuxed-file.mkv" say?

3. What does "mkvmerge -o remuxed-test.mkv original-source-file.mkv" followed by "mkvmerge --identify-for-mmg remuxed-test.mkv" say?

Add paths to mkvmerge/the files where appropriate.

[Palikrovol]

Works fine for me (I've just re-tested it).

1. Make sure your mmg is using the correct mkvmerge.exe executable and that you don't have an older version lying around somewhere.

2. What does "mkvmerge --identify-for-mmg the-remuxed-file.mkv" say?

3. What does "mkvmerge -o remuxed-test.mkv original-source-file.mkv" followed by "mkvmerge --identify-for-mmg remuxed-test.mkv" say?

Add paths to mkvmerge/the files where appropriate.

Hi.

I have uninstalled and reinstalled version 2.9.8 build 1.7.1.
"D:\AdP\_Video_\Mkvtoolnix\"

The first test is the commad line used in mmg "Muxing -> Copy command line to clipboard"

mkvmerge is called from its original folder (no use of "path" env var).

Output: Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv


F:\>"D:\AdP\_Video_\Mkvtoolnix\mkvmerge.exe" -o "F:\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv" "--track-name" "1:Quantum of Solace" "--default-track" "1:yes" "--forced-track" "1:no" "--display-dimensions" "1:720x304" "--language" "2:spa" "--track-name" "2:(AC3 5.1)" "--default-track" "2:yes" "--forced-track" "2:no" "--language" "3:eng" "--track-name" "3:(AC3 5.1)" "--default-track" "3:no" "--forced-track" "3:no" "--language" "4:spa" "--default-track" "4:no" "--forced-track" "4:no" "--language" "5:eng" "--default-track" "5:no" "--forced-track" "5:no" "-a" "2,3" "-d" "1" "-s" "4,5" "--attachments" "8389311906485108737,8389311906485108738,8389311906485108739,8389311906485108740" "-T" "--no-global-tags" "--no-chapters" "G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv" "--track-order" "0:1,0:2,0:3,0:4,0:5" "--title" "Quantum of Solace"
mkvmerge v2.9.8 ('C'est le bon') built on Sep 6 2009 21:40:12
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv': Using the Matroska demultiplexer.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 1: Using the MPEG-4 part 2 video output module.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 2: Using the AC3 output module.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 3: Using the AC3 output module.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 4: Using the text subtitle output module.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 5: Using the text subtitle output module.
The file 'F:\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 31 seconds.


And the "--identify-for-mmg"
(The result is the same if mkv is muxed within mmg instead of command line)


F:\>"D:\AdP\_Video_\Mkvtoolnix\mkvmerge.exe" --identify-for-mmg "F:\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv"
File 'F:\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv': container: Matroska [title:Quantum\sof\sSolace duration:6374280000000]
Track ID 1: video (V_MS/VFW/FOURCC, XVID) [language:und track_name:Quantum\sof\sSolace display_dimensions:720x304 default_track:1 forced_track:0]
Track ID 2: audio (A_AC3) [language:spa track_name:(AC3\s5.1) default_track:1 forced_track:0]
Track ID 3: audio (A_AC3) [language:eng track_name:(AC3\s5.1) default_track:0 forced_track:0]
Track ID 4: subtitles (S_TEXT/UTF8) [language:spa default_track:0 forced_track:0]
Track ID 5: subtitles (S_TEXT/UTF8) [language:eng default_track:0 forced_track:0]


The Second test (your test)

Output: Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos)2.mkv


F:\>"D:\AdP\_Video_\Mkvtoolnix\mkvmerge.exe" -o "F:\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos)2.mkv" "G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv"
mkvmerge v2.9.8 ('C'est le bon') built on Sep 6 2009 21:40:12
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv': Using the Matroska demultiplexer.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 1: Using the MPEG-4 part 2 video output module.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 2: Using the AC3 output module.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 3: Using the AC3 output module.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 4: Using the text subtitle output module.
'G:\\Peliculas\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv' track 5: Using the text subtitle output module.
The file 'F:\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos)2.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 31 seconds.


And the "--identify-for-mmg"


F:\>"D:\AdP\_Video_\Mkvtoolnix\mkvmerge.exe" --identify-for-mmg "F:\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos)2.mkv"
File 'F:\\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos)2.mkv': container: Matroska [title:Quantum\sof\sSolace duration:6374280000000]
Track ID 1: video (V_MS/VFW/FOURCC, XVID) [language:und track_name:Quantum\sof\sSolace display_dimensions:720x304 default_track:1 forced_track:0]
Track ID 2: audio (A_AC3) [language:spa track_name:(AC3\s5.1) default_track:1 forced_track:0]
Track ID 3: audio (A_AC3) [language:eng track_name:(AC3\s5.1) default_track:0 forced_track:0]
Track ID 4: subtitles (S_TEXT/UTF8) [language:spa default_track:0 forced_track:0]
Track ID 5: subtitles (S_TEXT/UTF8) [language:eng default_track:0 forced_track:0]
Attachment ID 1: type "image/jpeg", size 437901 bytes, description "Poster", file name "Quantum\sof\sSolace\sver1.jpg"
Attachment ID 2: type "image/jpeg", size 212939 bytes, description "Poster", file name "Quantum\sof\sSolace\sver2.jpg"
Attachment ID 3: type "image/jpeg", size 210077 bytes, description "Poster", file name "Quantum\sof\sSolace\sver3.jpg"
Attachment ID 4: type "image/jpeg", size 276761 bytes, description "Poster", file name "Quantum\sof\sSolace\sver4.jpg"

[Mosu]

Thanks for the info. This is the problem but not the cause:


F:\>"D:\AdP\_Video_\Mkvtoolnix\mkvmerge.exe" ... "--attachments" "8389311906485108737,8389311906485108738,8389311906485108739,8389311906485108740" ...

The attachement IDs are totally out of bounds. I'll try to see where this problem might come from.

Which Windows version is this, and is this a 32bit or 64bit version?

[Palikrovol]

Thanks for the info. This is the problem but not the cause:



The attachement IDs are totally out of bounds. I'll try to see where this problem might come from.

Which Windows version is this, and is this a 32bit or 64bit version?

The OS is a 32 bits Windows XP.

Thanks a lot.

PD: If you need any more info, let me know.

[Mosu]

Please do another test for me. Run mmg, open its preferences dialog and enable "show debug window". Close the preferences dialog. Add the original file (the one with the attachments intact). Post the content of the debug window here or send it to me by email (the debug window contains a "save to file" menu option).

[Palikrovol]

Please do another test for me. Run mmg, open its preferences dialog and enable "show debug window". Close the preferences dialog. Add the original file (the one with the attachments intact). Post the content of the debug window here or send it to me by email (the debug window contains a "save to file" menu option).

I'm not at home right now (where i have the files). When a get there this night, i'll made the test.

[Palikrovol]

Please do another test for me. Run mmg, open its preferences dialog and enable "show debug window". Close the preferences dialog. Add the original file (the one with the attachments intact). Post the content of the debug window here or send it to me by email (the debug window contains a "save to file" menu option).

Here is the output from debug window.

BTW the size of the mkv is "1,49 GB (1.601.952.120 bytes)"


18:55:31: Querying mkvmerge's capabilities
18:55:31: Capability: VERSION=mkvmerge v2.9.8 ('C'est le bon')
18:55:31: Capability:
18:55:31: Capability: BZ2
18:55:31: Capability:
18:55:31: Capability: LZO
18:55:31: Capability:
18:55:31: Capability: FLAC
18:55:31: Capability:
18:55:34: Locale selection logic: select_locale English (English) uu_locale_lower en translation_c::get_default_ui_locale() en app->m_ui_locale en
18:55:37: Querying mkvmerge's capabilities
18:55:37: Capability: VERSION=mkvmerge v2.9.8 ('C'est le bon')
18:55:37: Capability:
18:55:37: Capability: BZ2
18:55:37: Capability:
18:55:37: Capability: LZO
18:55:37: Capability:
18:55:37: Capability: FLAC
18:55:37: Capability:
18:55:53: identify 1: command: ``"D:\AdP\_Video_\Mkvtoolnix\mkvmerge.exe" "@C:\TEMP\mmg-mkvmerge-options-3884-1254848153"''
18:55:53: identify 1: result: 0
18:55:53: identify 1: output[0]: ``File 'G:\Peliculas\Quantum of Solace (XviD)(Español AC3 5.1)(English AC3 5.1)(Subtitulos).mkv': container: Matroska [title:Quantum\sof\sSolace duration:6374280000000]''
18:55:53: identify 1: output[1]: ``''
18:55:53: identify 1: output[2]: ``Track ID 1: video (V_MS/VFW/FOURCC, XVID) [language:und track_name:Quantum\sof\sSolace display_dimensions:720x304 default_track:1 forced_track:0]''
18:55:53: identify 1: output[3]: ``''
18:55:53: identify 1: output[4]: ``Track ID 2: audio (A_AC3) [language:spa track_name:(AC3\s5.1) default_track:1 forced_track:0]''
18:55:53: identify 1: output[5]: ``''
18:55:53: identify 1: output[6]: ``Track ID 3: audio (A_AC3) [language:eng track_name:(AC3\s5.1) default_track:0 forced_track:0]''
18:55:53: identify 1: output[7]: ``''
18:55:53: identify 1: output[8]: ``Track ID 4: subtitles (S_TEXT/UTF8) [language:spa default_track:0 forced_track:0]''
18:55:53: identify 1: output[9]: ``''
18:55:53: identify 1: output[10]: ``Track ID 5: subtitles (S_TEXT/UTF8) [language:eng default_track:0 forced_track:0]''
18:55:53: identify 1: output[11]: ``''
18:55:53: identify 1: output[12]: ``Attachment ID 1: type "image/jpeg", size 437901 bytes, description "Poster", file name "Quantum\sof\sSolace\sver1.jpg"''
18:55:53: identify 1: output[13]: ``''
18:55:53: identify 1: output[14]: ``Attachment ID 2: type "image/jpeg", size 212939 bytes, description "Poster", file name "Quantum\sof\sSolace\sver2.jpg"''
18:55:53: identify 1: output[15]: ``''
18:55:53: identify 1: output[16]: ``Attachment ID 3: type "image/jpeg", size 210077 bytes, description "Poster", file name "Quantum\sof\sSolace\sver3.jpg"''
18:55:53: identify 1: output[17]: ``''
18:55:53: identify 1: output[18]: ``Attachment ID 4: type "image/jpeg", size 276761 bytes, description "Poster", file name "Quantum\sof\sSolace\sver4.jpg"''
18:55:53: identify 1: output[19]: ``''
18:55:53: Attached file ID 64424509441 MIME type 'image/jpeg' size 64424947341 description 'Poster' name 'Quantum of Solace ver1.jpg'
18:55:53: Attached file ID 9793435967946754 MIME type 'image/jpeg' size 9793435968159691 description 'Poster' name 'Quantum of Solace ver2.jpg'
18:55:53: Attached file ID 9793435967946755 MIME type 'image/jpeg' size 9793435968156829 description 'Poster' name 'Quantum of Solace ver3.jpg'
18:55:53: Attached file ID 9793435967946756 MIME type 'image/jpeg' size 9793435968223513 description 'Poster' name 'Quantum of Solace ver4.jpg'
18:55:53: EAFB size 1
18:55:53: EAFB size 2
18:55:53: EAFB size 3
18:55:53: EAFB size 4

[Mosu]

Thanks. The problem should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.8-build20091006-172-setup.exe (still being uploaded; should be done in eight minutes).

[Mosu]

Upload's complete now -- took a bit longer than anticipated.

[Palikrovol]

Upload's complete now -- took a bit longer than anticipated.

Now it works.

Thanks a lot.

[Keiyakusha]

Mosu
Hi. Today I get this error message (mkvtoolnix v2.9.8):
http://img28.imageshack.us/img28/6084/erroriy.png
If you really need it, here (http://www.mediafire.com/?j3jk2goyjyn) is a sample. This is a mp4 file with AAC-LTP audio. File was muxed using Haali's directshow muxer 1.9.63.13 There is 10 second silence at the beginning.

[Mosu]

Yeah, but I will not fix this, sorry.

[Keiyakusha]

Yeah, but I will not fix this, sorry.

No problems. I created this file for testing only. ;)

[Snowknight26]

Why is MPEG-2 ES muxing so slow? Compared to the speed of AVC/VC-1 muxing, I'd say its about 10 times slower. I can mux a 20GB AVC ES to MKV in under 3 minutes, whereas a 20GB MPEG-2 ES takes ~20 minutes.

[Mosu]

Because the code is not particularly optimized, I guess.

[Selur]

Small question about the '-aac-is-sbr' option, I got a bunch of aac streams and wanted to mux them but I'm not sure if they use sbr or not, so will it cause a problem when I enable the option even for non-sbr streams (when remuxing later to mp4)

[Mosu]

Probably, but I don't remux to MP4, so I honestly don't know.

[Keiyakusha]

Is there any reason why we need to choose fps when muxing h264 elementary streams? For example DGAVCIndex seems to know what fps should be here and there...

[LoRd_MuldeR]

Is there any reason why we need to choose fps when muxing h264 elementary streams? For example DGAVCIndex seems to know what fps should be here and there...

There's obviously is no "frame rate" stored in an elementary H.264 stream on container-level, simply because there is no container ;)

AFAIK H.264 does have a way to indicate the frame rate on stream-level, but this may not be too easy to detected, as it requires parsing of the bitstream.

As opposed to simply reading one field from the header of the container file...

[Keiyakusha]

Yes, but mmg knows sar values and sets display dimensions according to it. Isn't some stream parsing is needed for this too?

[Mosu]

Not every stream contains the frame rate, and I never got around to implementing the feedback needed between mkvmerge and mmg if the frame rate is actually found. And no, I will not do that now either; I'm pretty much in "bug fixes only" mode at the moment.

[Forteen88]

Thanks. The problem should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.8-build20091006-172-setup.exe (still being uploaded; should be done in eight minutes).Mosu, where can I find your latest builds (like this), in portable version?

BTW, thanks a lot for mkvtoolnix.
EDIT: Thanks for the links, although I should've found it out myself (by modifying the link I quoted :P)

[XhmikosR]

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/.dirindex.php?sort=date&order=desc

[Mosu]

Yeah, at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

Disclaimer: I don't explicitely provide a portable version. The 7z archives just happen to work mostly even if the program hasn't been installed earlier via the setup.exe. But I don't provide support if something doesn't work with just unpacking the 7z version.

[Palikrovol]

Hello Mosu,

I think i have discovered a bug related to the mmg settings file or its parsers.

I load an avi into mmg, set the output mkv file and save settings into a mmg file (File -> Save Settings). Then restart mmg (or File -> New) and load the settings file (File -> Load Settings).

Only the output mkv file is read from mmg file, the input tab remains empty after the settings load, so when i hit "Start Muxing" the error
"Error: No input files were given. No output will be created."
is given.

The same happens when adding to the job queue.

[Mosu]

I think i have discovered a bug related to the mmg settings file or its parsers.

I load an avi into mmg, set the output mkv file and save settings into a mmg file (File -> Save Settings). Then restart mmg (or File -> New) and load the settings file (File -> Load Settings).

Only the output mkv file is read from mmg file, the input tab remains empty after the settings load

Interesting, haven't had that problem before. What is the exact name of that AVI? And can you please send me that .mmg file you've said via email? Thanks.

[Palikrovol]

Interesting, haven't had that problem before. What is the exact name of that AVI? And can you please send me that .mmg file you've said via email? Thanks.

It happens with every avi i have tested.

I have put a 1 minute test video and his mmg file in your ftp server.
Test_Video.avi
Test_video.mmg (The source Test_Video.avi was in "C:\Documents and Settings\%username%\Mis documentos\")
Test_video_inC.mmg (The source Test_Video.avi was in "c:\")

It's a tv show from the spanish television tve2

The mediainfo output of Test_Video.avi:


General
Complete name : C:\Documents and Settings\%username%\Mis documentos\Test_Video.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 7.22 MiB
Duration : 1mn 6s
Overall bit rate : 914 Kbps
Writing library : VirtualDub build 29963/release

Video
ID : 0
Format : MPEG-4 Visual
Format settings, BVOP : Yes
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Muxing mode : Packed bitstream
Codec ID : DX50
Codec ID/Hint : DivX 5
Duration : 1mn 6s
Bit rate : 775 Kbps
Width : 480 pixels
Height : 352 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.183
Stream size : 6.12 MiB (85%)
Writing library : DivX 5.1.0 (UTC 2003-09-02)

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1mn 6s
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Resolution : 16 bits
Stream size : 1.01 MiB (14%)
Alignment : Split accross interleaves
Interleave, duration : 40 ms (1.01 video frame)
Interleave, preload duration : 500 ms

[ajp_anton]

When I use the "Save to Matroska file", MPC-HC gives me a "File not found" error on the file.

There's nothing wrong with the chapters or MPC-HC as it also happens when I take the chapters from a working file and save to another.

[Mosu]

There is a known problem with that function if you save to a Matroska file created by any other program than mkvmerge (e.g. Haali's muxer). This partially destroys the file structure. I don't have an ETA for a fix.

[colinhunt]

Mosu, how come I can't mux a Dolby Digital Plus 7.1ch audio file with a x264 video file? mkvmerge thinks the audio file is another video file, and the muxed .mkv plays without audio. MediaInfo says the audio file's format is "E-AC-3".

[Mosu]

Probably defective file. There are invalid EAC3 files out there whose headers contain wrong information. mkvmerge is pretty picky about what it accepts.

You can upload the first 1 MB of the EAC3 file to my FTP server, but I don't have much/no time at the moment to spend on debugging such things, so it might take a while until I get around to it.

[Egh]

@Mosu: just confirming previously reported bug.

I see it 100% of times in 174 build. All works, mmg saved, then reopened -- input files and obviously tracks info are missing. Global settings like timecodes for splitting are present still.

[Mosu]

Egh & Palikrovol: Can you please test whether or not this happens with older versions of mkvtoolnix, too? I'm especially interested in 2.9.7 (release) and earlier test builds of 2.9.8 (164 or earlier). Here are direct links to both versions:

http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.9.7-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.8-build20090816-164-setup.exe

Please always make sure that you save the .mmg file and load it with the same version, e.g. don't try to load a .mmg with 2.9.7 that was saved with 2.9.8-174.

Thanks for the feedback.

[Egh]

Egh & Palikrovol: Can you please test whether or not this happens with older versions of mkvtoolnix, too? I'm especially interested in 2.9.7 (release) and earlier test builds of 2.9.8 (164 or earlier). Here are direct links to both versions:


Just tried on 164 (confirmed to be August build).

Well probably little wonder btw the newer files that do not load :P

compare (fragment of MMGs saved after absolutely same sequence of actions in 164 and 174)


before: [164]
container=1
appending=0
number_of_tracks=1
number_of_attached_files=0


after: [174]
container=9810203520270337
appending=9810203520270336
number_of_tracks=9810203520270337
number_of_attached_files=9810203520270336



Overflow problem? :))

But muxing itself seems to be fine by 174 build, most likely the bug is in .mmg export routine.

[Mosu]

Just tried on 164 (confirmed to be August build).
...
Overflow problem? :))

But muxing itself seems to be fine by 174 build, most likely the bug is in .mmg export routine.

Thanks for the analysis. The problem is actually worse. Technical explanation:

With releases and builds up to and including 2.9.8-168 I was using the mingw cross-compiler v3.3.5 on Linux in order to produce Windows binaries. Afterwards I had to switch to mingw v4.2.1 because I started using wstring in my source code, and mingw 3.3.5 didn't support the Unicode features of the C++ standard template library. 4.2.1 does, so that's why I switched. Unfortunately the GUI toolkit I'm using (wxWidgets) now has a problem. The "wxLong" class that should provide object oriented access to the native "long" type was working correctly with 3.3.5 but fails with 4.2.1. To be more precise "wxLong" thinks that the underlying native data type "long" was 64bit wide and not 32bit. For cross compilation purposes this is simply wrong; "long" is still only 32bit wide on the Windows side.

I've had another problem due to this regarding the attachment selection (should be somewhere in this thread as well), and this particular problem should be fixable as well, but it's a major PITA.

[Vincent Vega]

just reporting a minor issue (noticed in 2.9.8-174): appending together several h264 ES files and setting FPS for first fragment, still results in mmg warning about "FPS not set" for each of the remaining segments after pressing start muxing.

[Mosu]

Should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.8-build20091111-179-setup.exe

[Thunderbolt8]

what I noticed is that apparently since a few versions the job queuing is broken, each time I want to run the batch I get the message "the file does not seem to be a valid mkvmerge gui settings file" even though I only added this one item 5 seconds ago.

[Mosu]

Known issue; don't use anything past 2.9.8 release.

[LeMoi]

When I add an avi file (video only) + a mp3 file, i uncheck the mp3 file in the GUI but it still is muxed in the final file

[Mosu]

When I add an avi file (video only) + a mp3 file, i uncheck the mp3 file in the GUI but it still is muxed in the final file

Known issue that will never be changed/fixed. Track selection is not implemented for all raw container types (e.g. MP3, AAC, AC3, AVC ES etc).

[LeXXuz]

Is there a command switch for mkvextract to show the tracks of a Matroska file?

[SledgeHammer_999]

Is there a command switch for mkvextract to show the tracks of a Matroska file?

use mkvinfo for that.

[Mosu]

No, use mkvmerge, not mkvinfo: "mkvmerge -i yourfile.mkv"

[LeXXuz]

:thanks:

[Mosu]

Just as an explanation why I wrote "use mkvmerge and not mkvinfo" even though it is somewhat counter intuitive. mkvinfo is supposed to be a tool for verbose reporting of the whole Matroska structure. mkvmerge on the other hand is also supposed to be queried by mmg when the user adds a file to mmg. mkvmerge's output for that query is designed to be terse and right to the point. Furthermore mkvmerge's output lists the track IDs that can be used on mkvextract's command line whereas locating those in mkvinfo's output is slightly more difficult.

[fangorn]

Hi,

I have a problem muxing h.264 (x264 encodings, controlled by mencoder) with DTS audio again. Streams get muxed, but Multimedia in container has shorter length than the source AVI container. File is also much smaller than the video and audio streams combined.

Is there a known issue that I have missed?

Problem does not occur when audio is AC3.

In more detail:
I am encoding HD video with DTS audio to AVI containing h.264 video stream and MP3 audio. Then I am ripping DTS audio streams to external files. Then I mux, dropping the MP3 audio from the AVI. This is necessary to prevent sync issues and worked for quite some time and now fails for >80% of the sources containing DTS.

ATM I don't know where to look for this problem. Is it the source (unlikely, for the pure number of sources failing), the encoding chain (x264, mencoder from GIT/SVN in several versions over the last months), my scripts, mkvmerge or an unfortunate combination of all of this?

Has someone else reported such a problem?

[fangorn]

Forget it.

It seems to be an interaction of x264s mbtree feature, mencoder and converting DTS to 2channel MP3. I deactivated mbtree and it produced a flawless DTS audio mkv so far. (HD movies are not the best source when it comes to testing a script ;-) Even my slightly OCed Core i7 920 takes quite some time to encode a 2 hour movie in 1080p.)

[ibanez]

Is anyone using Mkvmerge GUI 2.9.8 with Windows 7 64-bit?

I muxed an MKV (video extracted from Blu-ray with Eac3to) and a DTS file (and chapters) to an MKV file of around 28 GB in size this morning and it took around 5 minutes. With XP 32-bit it would take 30-45 minutes. I have never seen any performance gain from Win 7 for 32-bit applications so it is abit strange.

[73ChargerFan]

Yeah, I do, works great. As for how long it takes to mux, it depends on hd usage - it is fastest for me from one disk to another. Very slow if I try and do a second operation at the same time, like file scan, copy, rar, etc.

[Mosu]

Thanks for the analysis. The problem is actually worse. Technical explanation:

After several hours spent debugging in the depths of wxWidgets I finally discovered that this is a bug in the compiler's runtime library. After fixing that particular issue the .mmg files look fine again. Here's a build for you guys:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.8-build20091120-180-setup.exe

Note that .mmg files (as well as jobs as those are just .mmg files saved in a special directory) created with builds after 2.9.8-164 and prior to 2.9.8-180 are unusable and should be deleted.

[b66pak]

here are some .mp4 that i converted to .mkv (using mkvtoolnix-unicode-2.9.8-build20091120-180)...the resulted .mkv's can't be demuxed by mkvextract!

http://www.mediafire.com/?gwywzimomqx
_

[Mosu]

True, and that will most likely never be changed.

[b66pak]

why is that?...and what is the point in muxing .mkv's that can't be demuxed?
_

[Mosu]

Matroska files are not ZIP files. Meaning that it's not a container format meant for transport or temporary storage. Not everything that would be technically possible is useful and should be implemented.

If you don't see a use for a container apart from putting stuff in it and taking it out again (and losing information in the process) then Matroska might not be the container for you.

[WillKane]

I've used Matroska to store my TV captures mainly because your GUI is so easy to use and has worked very well. Big thanks for providing it.:thanks:

However I hope that you could revise your stance about demuxing because I would feel much more safer if I could later get streams out for possible re-encoding.

[sneaker_ger]

If you really want to demux those files set the "default duration" according to the fps in the header editor. The only problem you'll get is that N-VOPs dropped during the muxing process are not reconstructed during the demux. (I guess it would be possible to reconstruct them if the original file had a constant frame rate but I don't know any program that's actually able to do it.)

[Palikrovol]

After several hours spent debugging in the depths of wxWidgets I finally discovered that this is a bug in the compiler's runtime library. After fixing that particular issue the .mmg files look fine again. Here's a build for you guys:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.8-build20091120-180-setup.exe

Note that .mmg files (as well as jobs as those are just .mmg files saved in a special directory) created with builds after 2.9.8-164 and prior to 2.9.8-180 are unusable and should be deleted.

It works again, thank you very much :)

[Mosu]

I've used Matroska to store my TV captures mainly because your GUI is so easy to use and has worked very well. Big thanks for providing it.:thanks:

However I hope that you could revise your stance about demuxing because I would feel much more safer if I could later get streams out for possible re-encoding.

Like sneaker_ger said, there are possibilities. And the fact that you can watch the files means that there are even more ways to demux stuff, just not with mkvextract.

One problem and the foremost reason why I won't implement this in mkvextract itself is that files without a default duration most often do not have a fixed frame rate. Such video tracks cannot be put into AVI files without them getting all wrong regarding A/V sync. A possiblity would be to "extract" them into MP4 files instead because MP4 files don't need a fixed frame rate. That however would require tons of work because mkvextract doesn't have a MP4 muxer built in, and even though there are libraries that make this easier this is waaaaaaaaaaay more work than I'm willing to spend on such a feature.

[avivahl]

What about extracting the raw streams (separated) each to its own raw file? (instead "to a different container)
Does mkvextract supports that?

[VHT]

Hi,i've got a strange problem with mkvmerge. I currently use lg-bd390 blu-ray player to watch my mkv muxed movies.Audio and video runs just smooth when I mux raw h.264 stream and raw DTS stream into mkv with mkvmergeGUI. Yesterday I noticed that if I open the mkv movie I've created from raw streams with mkvmerge and mux it again (and add subs or add nothing) i get drops in audio that lasts less than a half second.Using the same method with DD audio, i get no problems.Any ideas?

[sneaker_ger]

What about extracting the raw streams (separated) each to its own raw file? (instead "to a different container)
Does mkvextract supports that?

It's possible. Use the switches "--raw" or "--fullraw". See the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvextract.html) for more info.

[b66pak]

One problem and the foremost reason why I won't implement this in mkvextract itself is that files without a default duration most often do not have a fixed frame rate. Such video tracks cannot be put into AVI files without them getting all wrong regarding A/V sync.

don't we have already TimeCodes for this kind of situations?
_

P.S. @sneaker_ger thanks for the tip!
_

[WillKane]

Sorry but I misunderstood that mkvextract would be abandoned altogether. It makes much sense that mkvextract doesn't write to AVI without default frame duration. When I mux M2V files default duration is written to file as before.

[Isochroma]

So MKVextract's gonna be toast, eh?

[Mosu]

Huh? No one said that. I was talking about this one particular type of video codec with that certain problem of not having a default duration field. However, mkvextract has never been my highest priority. Priority for me is creating Matroska files, not taking them apart.

[roozhou]

here are some .mp4 that i converted to .mkv (using mkvtoolnix-unicode-2.9.8-build20091120-180)...the resulted .mkv's can't be demuxed by mkvextract!

http://www.mediafire.com/?gwywzimomqx
_

Try my ffmpeg build to remux mkv to mp4. Don't use official ffmpeg build. They won't work on mkv.

https://sourceforge.net/projects/direct264/files/Related%20Programs/ffmpeg%20%28demuxer_muxer%20only%29/ffmpeg_svn_r20373.7z/download

[b66pak]

@ roozhou thanks...
_

[Keiyakusha]

Mosu
Hi! When I'm trying to append 2 raw h264 streams, after setting FPS for the first stream there is no way to set it for second one , but if I try to mux it, the message still appears and asks me to set FPS... Is it possible to fix this?

By the way, why all settings for appended stream becames grayed out? Its should be possible to have second segment with different fps/dar/something else... or no?

[Mosu]

Mosu
Hi! When I'm trying to append 2 raw h264 streams, after setting FPS for the first stream there is no way to set it for second one , but if I try to mux it, the message still appears and asks me to set FPS... Is it possible to fix this?

This has already been fixed in one of the latest builds available at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

By the way, why all settings for appended stream becames grayed out? Its should be possible to have second segment with different fps/dar/something else... or no?

Most settings directly influence the track headers, and therefore only the first track in an append chain may have those set. It's pretty much the same for FPS; mkvmerge also doesn't support changing the FPS for appended tracks.

To make this clearer: Appending two tracks results in a single track in the output file. This single track only has one copy of its headers, obviously, therefore most settings cannot be changed and therefore most stream parameters (private data, pixel width/height etc) must match in the first place or mkvmerge will not allow you to append them.

[Mosu]

Hey,

I've released mkvtoolnix v2.9.9. This release contains contains the usual mix of bug fixes and smaller enhancements. Nothing overly exciting to mention, I guess. I also started providing binary packages for OpenSuSE 11.3 and Ubuntu 9.10 Karmic Koala (both 32bit and 64bit).

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.8:

------------------------------------------------------------
2009-11-25 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.9.

2009-11-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The warning that no FPS has been entered for AVC/h.264 elementary streams is not shown anymore for appended tracks (only once for the first track that they're appended to).

2009-10-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The pixel cropping parameters were not kept when muxing from Matroska files.
* mkvmerge: bug fix: The display width/height parameters were not kept when muxing from Matroska files if the bitstream of the track contained different aspect ratio information. Now the order is "command line" first, "source container" second and "bitstream" first.

2009-09-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the subtitle track selection for AVI files.

2009-08-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: A single '+' causes the next file to be appended just like putting the '+' in front of the file name.

2009-08-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The integrated help ('--help') contained wrong information about the '--sync' option. Fix for bug 435.

2009-08-18 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The file dialogs for 'add file'/'append file' will show files with extensions in all uppercase as well. This only applies to file systems that distinguish between case (e.g. most of the non-Windows, non-FAT world). Fix for bug 433.

2009-08-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Missing ChapterLanguage elements were assumed to be set to "und". They're now assumed to be "eng" in accordance with the Matroska specifications.
* Added a new program 'mkvpropedit' that can modify certain properties of existing Matroska files. It is mmg's header editor, just for the command line.
------------------------------------------------------------

Have fun.

[J_Darnley]

Nice work. One small issue with the changelog: 'Now the order is "command line" first, "source container" second and "bitstream" first.' You have said first twice, should that be '"bitstream" last'?

[Mosu]

Yes, it should.

[WantStuff]

Wow. Just downloaded 2.9.9 and the first thing I used was the header editor, it's really quick now!
A massive performance gain. Well done.

A feature I would love now is a CLI version of the header editor... any chance?

[Mosu]

Quoting myself here:

2009-08-16 Moritz Bunkus <moritz@bunkus.org>
* Added a new program 'mkvpropedit' that can modify certain properties of existing Matroska files. It is mmg's header editor, just for the command line.


That program is part of all binary packages (Linux, Windows) and will be compiled if you compile mkvtoolnix yourself without the need for further configuration/special options.

[WantStuff]

Damn you're quick, excellent service!

Yes sorry, I should have read it properly. I guess I was caught up in the moment...

[Mosu]

No problem :)

[MatLz]

Hi Mosu!
Why when I precise the fps of an avc stream to 23.976 the resulting mkv is 24000/1001 fps?
I must precise a fraction like 23976/1000 or 2997/125 to get 23.976fps.

[nurbs]

I assume it's because normally people use 23.976 as a short form for when they mean 24000/1001. Personally I've never seen a source that is really 23.976, they are all 24000/1001 (Blu-Ray, HD-DVD, NTSC DVD).

[Mosu]

nurbs' description is spot on. Way back in the day users requested that the values 23.976 and 29.97 are treated as 24000/1001 and 30000/1001 respectively.

[Abradoks]

mkvtoolnix recognises MP3 in WAV container as PCM. Not a big problem, but thought I should report it.

[Mosu]

Will not be fixed.

[Snowknight26]

Is it possible to mention the offset (in bytes perhaps) as to when a track contains bad data? I captured some video that happened to have corruption in it, so when I went to remux it to MKV with mkvmerge, it spat out an error along the lines of 'the AC3 track contained 1536 bytes of malformed packets, a/v synchronization may be lost.' It'd be nice to know where that happens so I can further investigate.

[Mosu]

It is technically possible, but it requires some work because neither of those packetizers (MP3, AAC, AC3) keeps track of the current stream position. So not in the near future.

[Keiyakusha]

Hi, Mosu. I want to ask something about how Display width/height in matroska meant to be handled...
Something like splitter tells exact resolution to the player and player do some scaling to accomplish this? So if original resolution is 640x360 and Display width/height is 1280x720, I should not be able to tell if the video is scaled from 360p on the fly or before encoding unless I look to some statistics?
If this is so, does haali splitter respects that?

[Mosu]

Hi, Mosu. I want to ask something about how Display width/height in matroska meant to be handled...
Something like splitter tells exact resolution to the player and player do some scaling to accomplish this? So if original resolution is 640x360 and Display width/height is 1280x720, I should not be able to tell if the video is scaled from 360p on the fly or before encoding unless I look to some statistics?

The idea is indeed that the initial size of the video during playback is set to display width/height by the player (not the demuxer or codec though -- it is supposed to be up to the player so that the user still has the choice which scaling methods to use etc). It is not supposed to be a fixed size so the user should still be able to resize the playback window afterwards.

However, most players if not all only use the quotient "display_widht/display_height" as the aspect ratio for playback and determine the initial size themselves. Some muxing applications or users of those even go so far and use e.g. "16" for the display_width and "9" for the display_height parameter -- but this is mostly a result of the players not honoring the actual display width/height but only using its quotient for aspect ratio calculation.

If this is so, does haali splitter respects that?

I don't know, and like I said, it is supposed to be the player's job, not the splitter's/demuxer's/codec's. However, I'm not familiar with Windows' multimedia stack and cannot judge whether or not it would be easier to implement proper display width/height handling in the splitter itself.

[Keiyakusha]

Mosu
Thank you! :goodpost:

[WestFlame]

Hi, I would like to ask if there will be any “Tag Editor” for Matroska files like the Chaper one in mmg?

Thanks.

[Mosu]

Maybe, maybe not.

[Chumbo]

Mosu,
I have a stream where the audio is 1 second behind the video. Rather than chopping off the first 1024ms of the audio, I decided to use a delay of +1024 on the video track but it made no difference in the resulting file. Using -1024 on the audio track works just fine. Not sure if the delay for the video track is supposed to work or not or if it ever did, but wanted to let you know that it does not work. At least not in 2.9.9.

[Mosu]

Have you made sure with mkvinfo that the video track timestamps are REALLY not adjusted by that 1024? Because it's working just fine for me:

[0 mosu@tionne ~/prog/video/mkvtoolnix/data] mkvmerge -i v.avi
File 'v.avi': container: AVI
Track ID 0: video (DIV3)
Track ID 1: audio (MP3)
[0 mosu@tionne ~/prog/video/mkvtoolnix/data] mkvmerge -o v.mkv --sync 0:1000 v.avi
mkvmerge v2.9.9 ('Tutu') built on Dec 5 2009 19:04:14
'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.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 0 seconds.
[0 mosu@tionne ~/prog/video/mkvtoolnix/data] mkvinfo -s v.mkv | grep -i 'track 1' | head -n 2
Track 1: video, codec ID: V_MS/VFW/FOURCC (FourCC: DIV3, 0x33564944), default duration: 41.708ms (23.976 fps for a video track), language: und, pixel width: 640, pixel height: 352, display width: 640, display height: 352
I frame, track 1, timecode 1000 (00:00:01.000), size 13424, adler 0x6e3488a8


I can see two possiblities:

1. Your command line is wrong. This could even be the case if you're using mmg; though in that case it would obviously be a bug in mmg.

2. The process is working fine, but playback doesn't honor that 1s offset. In this case there's nothing I can do about it.

[burfadel]

I was wondering whether a batch remux facility could be incorporated in to mmg. An example would be to click on remux, select 'add files' where you can select all acceptable containers currently, and then proceed and it automatically convert the avi and mp4 container input files to mkv. Even handier would be the ability to select files, and subfolders where you may have tv shows, and be able to output the files with the same folder structure. In the next month or so, I will be transferring files to new hdd's, so thought it would be good to standardise my video content in terms of container format. The ability to do subfolders etc would be handy, so I could essentially just select the main video folder on the old 750gb drives, and output the main folder on the new drives keeping the current folder structure.

MMG is an excellent muxer, I'm sure a batch remux function as outlined above wouldn't be too difficult to implement and I'm sure many would find it useful.

[Mosu]

Sorry, but such a feature will never be implemented. There are excellent shells out there that can do this easily. For example, with a bash you could convert all .avi files into Matroska with these commands:

find -type f -name '*.avi' | { while read filename ; do mkvmerge -o /path/to/output/dir/"`basename "$filename" .avi`.mkv" "$filename" ; done ; }

I know that using shells is not everyone's thing. However, implementing a powerful and flexible batch remuxer requires countless hours of work. If I cut down on the hours then either the flexibility or the number of features would be severely reduced and therefore the work would not be worth it because too few people could actually use it in such a state.

The short version is that it's waaaaay too much work and that I don't have that amount of free time. So.... no. Sorry.

[burfadel]

Ah ok! I didn't realise it would be such a complex thing :) lol

[thymej]

mmg sees the first DVD movie vob, vts_0x_0.vob with a mpeg2 video and ac3 audio as it should, but all the other vobs part of the dvd movie are seen with an AVC/h.264 video with ac3 audio. So I cant append the vobs together on a dvd, to make a mkv.

tsRMuxer, MediaInfo all see the vobs with mpeg2 video, only mmg sees only the first vob with mepg2 video. Does this mean its not supported and I have to use a 3rd party vob joiner first?

[Chumbo]

Have you made sure with mkvinfo that the video track timestamps are REALLY not adjusted by that 1024? Because it's working just fine for me:



I can see two possiblities:

1. Your command line is wrong. This could even be the case if you're using mmg; though in that case it would obviously be a bug in mmg.

2. The process is working fine, but playback doesn't honor that 1s offset. In this case there's nothing I can do about it.
I'll have to use mkvinfo to check what you suggested, so no I have not done that.

In regards to the two possibilities: #1) I used the UI so I assume the command it executes is fine and #2) You may be correct in this.

I'll grab mkvinfo and check it out. Thank you.

[Mosu]

mmg sees the first DVD movie vob, vts_0x_0.vob with a mpeg2 video and ac3 audio as it should, but all the other vobs part of the dvd movie are seen with an AVC/h.264 video with ac3 audio. So I cant append the vobs together on a dvd, to make a mkv.

That's a known problem that I haven't had the time to look at yet. See also https://www.bunkus.org/bugzilla/show_bug.cgi?id=437

Does this mean its not supported and I have to use a 3rd party vob joiner first?

"Well... it's kinda supposed to work" to the first question and "that'd be the best workaround to use for the time being" to the second one.

[Snowknight26]

Apparently if you Alt+F4 the muxing progress window, the muxing still continues in the background.

[Mosu]

Use the "Cancel" button instead. I won't fix that.

[osgZach]

The header editor is a pretty nice tool, although I was wondering if there are other tools out there that might allow batch modifications of specific tags by specific criterea ? I tried messing with the CLI but I ended up feeling overwhelmed real fast and worried I was gonna screw up the file somehow.

e.g Process 10 files, and set all tracks with tag value of "X" to the default playback track, and any other languages to "not default". It seems I've messed up some of my stuff in the past, would be nice to fix without a remux.

Also.. keeping that in mind, I think my WDTV Live doesn't even recognize the default playback tag (I haven't tested it for sure), I'm not sure.. It may be going by the first audio track it finds - is there a way I can re-assign track numbers without remuxing ? Or for that matter editing or adding new chapters?

I'm guessing its probably just easier to demux and remux though..

[Mosu]

The header editor is a pretty nice tool, although I was wondering if there are other tools out there that might allow batch modifications of specific tags by specific criterea ? I tried messing with the CLI but I ended up feeling overwhelmed real fast and worried I was gonna screw up the file somehow.

Not in that detail, but there's mkvpropedit which is like mmg's header editor just for the command line. And it is as it is with the command line -- there's no tool more powerful if you know how to use it :)

e.g Process 10 files, and set all tracks with tag value of "X" to the default playback track, and any other languages to "not default". It seems I've messed up some of my stuff in the past, would be nice to fix without a remux.

Easily scriptable with a proper shell (e.g. bash), analyzing the output of "mkvmerge --identify ..." and calling mkvpropedit with the appropriate parameters.

It may be going by the first audio track it finds - is there a way I can re-assign track numbers without remuxing ?

You can do that with mmg's header editor and with mkvpropedit.

[osgZach]

Well like I said, I tried using the CLI but just found it a little over my head I think. Perhaps I'll give it another go, if there are any in-depth guides to using it (besides the documentation) maybe that would help me get the hang of it a little more.

I was planning to just write a batch file to do a bunch of CLI stuff, just having trouble getting to hang of the mkvpropedit tool I guess.

[Mosu]

Hey,

I've released mkvtoolnix v3.0.0. This release contains contains the
usual mix of bug fixes and smaller enhancements.

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.9:

------------------------------------------------------------
2009-12-12 Moritz Bunkus <moritz@bunkus.org>
* Released v3.0.0.
* mmg: enhancement: Added support for showing the muxing progress for both normal muxes and the job manager in Windows 7's taskbar.

2009-12-06 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: The charset for output in cmd.exe for non-English interface languages has been fixed on Windows Vista and Windows 7.
* all: enhancement for Windows platforms: If one of the mkvtoolnix components is run without having been installed before then translations will be read from the directory the .exe is run from.

2009-12-05 Moritz Bunkus <moritz@bunkus.org>
* configure: Added an option ('--without-build-timestamp') that omits the build timestamp from all version information so that two builds of mkvtoolnix can be byte-identical.

2009-12-04 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, mmg: bug fix: Editing headers of files created by HandBrake would cause crashes and/or corrupted files after saving. Fix for bug 445.
------------------------------------------------------------

Have fun.

Mosu

[Chumbo]

Congrats on the new major version release Mosu. Thank you for your continued efforts on this tool. I, for one, really appreciate it.

[sneaker_ger]

Thx for the release. Any news on bug 289?

[stax76]

Congrats Mosu on the major release and thanks for everything.

[Snowknight26]

The output text box's text isn't vetically centered properly due to the text box being taller than usual.

[Mosu]

Congrats on the new major version release Mosu. Thank you for your continued efforts on this tool. I, for one, really appreciate it.

Thanks & you're welcome :)

Thx for the release. Any news on bug 289?

Nope. To be honest, you're the only person who ever showed interest in this particular problem. I've already spent a lot of hours working on it during our debugging session mid-summer, and I don't consider further work on it worth the effort. I won't close the bug; maybe one day I'll find myself having some spare time and actually wanting to fix this. But I wouldn't hold my breath.

Congrats Mosu on the major release and thanks for everything.

Thanks & you're welcome :)

The output text box's text isn't vetically centered properly due to the text box being taller than usual.

The text is not supposed to be centered.

[sneaker_ger]

Nope. To be honest, you're the only person who ever showed interest in this particular problem. I've already spent a lot of hours working on it during our debugging session mid-summer, and I don't consider further work on it worth the effort. I won't close the bug; maybe one day I'll find myself having some spare time and actually wanting to fix this. But I wouldn't hold my breath.

I see. I just wondered because I know that you spent much time on it and the remaining issue seems rather small to my newbie brain compared to what you've already done (more or less complete rewrite of the concerned parts). Files without NVOPs ("real" NVOPs, not those "dummies" in packed bitstream) are already working 100% nice. It's just that the timecode correction on these few not working files is done one frame too late. Since mkvmerge is the Matroska-Muxer and the support for Matroska in hardware devices is growing constantly these days the usage of native mode by default could push vendors to support it instead of the now widely used VfW mode.

[buzzqw]

a bit later.. but.. :thanks: Mosu MKVToolnix is an wonderful suite!

BHH

[RadioactiveMan]

Thanks for this nice program.

Unfortunately it looks like version 3.0.0 doesn't support drag&drop of inputfiles anymore. Is this a feature or a bug?

I'm on windows 7 enterprise 64 bit and tried it with mp4 and mkv files.

[73ChargerFan]

Confirmed on Win7-64 Ultimate.

[Snowknight26]

Works just like it has in previous versions here..

[73ChargerFan]

Weird, it works today. It didn't on first run.

[RadioactiveMan]

Weird, it works today. It didn't on first run.

same for me now. really mysterious. :confused:

[Mosu]

Not that mysterious at all. If you've just installed 3.0.0 and run it afterwards DIRECTLY from the installer AND your normal user account runs without administrator privileges then the mmg instance spawned by the installer will run as Administrator and not as your normal user. Drag and drop between applications running under different user accounts does not seem to work. This is not only the case with mkvtoolnix; most installation programs that offer to run the just installed program when the installation finishes let the program run as Administrator which is usually not what you want.

I'll probably change the installer's "run mmg now" checkbox to be unchecked by default.

[weasel_]

Why no Serbian and Croatian in Language list in v3.0.0 ?

[sneaker_ger]

Why no Serbian and Croatian in Language list in v3.0.0 ?

What do you mean? I've found srp and hrv. :confused:

[weasel_]

never mind i misslooked ;)

[Mosu]

Why no Serbian and Croatian in Language list in v3.0.0 ?

The language list contains the ISO639-2 codes and is sorted by them. The ISO639-2 code for Croatian is "hrv", and for Serbian it's "srp". Both entries are present, so my guess is that you were looking at the wrong place.

[weasel_]

Yes that was :) i use to old list ;)

tnx

[73ChargerFan]

I can't append VOB files from my DVD. I added VTS_02_01.VOB (identified as mpeg2), and appended 2 more, but 3.0.0 Dec12,09 build says they are h264 files, which is wrong.

[sneaker_ger]

That's a known issue (https://www.bunkus.org/bugzilla/show_bug.cgi?id=437). Use a vob joiner for now.

[Keiyakusha]

Hi Mosu. What do you think about changing Abort button to "open folder" after muxing is done? So it will open folder where the file was saved.

[Mosu]

Hi Mosu. What do you think about changing Abort button to "open folder" after muxing is done? So it will open folder where the file was saved.

Sounds useful. Maybe I'll implement it (at least for the Windows version).

[neb1236]

Hi, I have tried the new --without-build-timestamp but I have a resulting error (Error: The source file '--without-build-timestamp' could not be opened successfully, or retrieving its size by seeking to the end did not work.)

I have tried to put the tag in different places in the command line but didn't change anything, is anyone have tried this?

full script here (http://tinypaste.com/625f3)

[Mosu]

The option '--without-build-timestamp' is an option to the configure script, not a runtime option for mkvmerge.

[neb1236]

Thank you for the answer, but I didn't understand it, or I think I didn't.
Do you mean that this is an option for building a version of mkvmerge? And if I want to use this feature I will need to build it myself from source?
And therefore the byte-to-byte equality is about the software and not the mkv... my dream won't be granted? damn...

[Mosu]

That is correct. The reason this option exists is for Linux distributions to be able to build byte-identical packages of mkvtoolnix given the same library/compiler versions etc.

[neb1236]

So is there a possibility to have the same option for mkv muxing? maybe mkvpropedit can be useful.
I'm trying to achieve this to be able to mux a file on a distant server where I have the same source file as the local ones, without needing to download it and view it (md5 sum checking)

[Mosu]

No, sorry. Quoting myself and others from a recent IRC session:

21:50 Snosnhoj:: oh yeah is there a way to mux the exact same things each time to generate the exact same file with mkvmerge or some other tool.
21:55 Myrsloik:: there's a flag for that in mkvmerge
21:55 Myrsloik:: read the manual to fina it
22:05 Mosu:: Snosnhoj: no, not really
22:17 Myrsloik:: wasn't it possible before at least?
22:18 Mosu:: not really
22:18 Myrsloik:: hmm... then I have to try to giure out exactly what we did
22:19 Mosu:: there is a switch that lets mkvmerge/extract create identical files with identical options, but the resulting files are not spec compliant and may pose problematic to play back or work with. that switch is therefore not documented, and its only purpose is being used for my regression test suite
22:19 Myrsloik:: why aren't they compliant?
22:20 Mosu:: because the unique IDs are not unique; additionally all chapters/tags that use UIDs as targets are broken by that
22:21 Myrsloik:: if you ever come across some broken files...
22:22 Mosu:: :)
22:27 Snosnhoj:: thanks for the answer/details, what is the switch called?
22:28 Mosu:: don't use that switch
22:28 Mosu:: there's no reason to
22:29 Myrsloik:: now listen to the nice developer and do as he says
22:29 Mosu:: :)
22:32 Snosnhoj:: ok o;

Note that even with the configure option "--without-build-timestamps" the resulting files will not be identical.

[neb1236]

Understood, I will not beg for it since it will effectively result in strange file unless we can explicitly furnish custom UID for one specific mux for each track on other xml element
I will try to find third party tool which could perform a some sort of synchronization between two muxed file with same option, since the difference between the two would be very small (timestamp and segment UID)
Perhaps, one small question that could help, is the difference between two mux is compressed in the header of the file or dispatched, well I guess I can do it myself, don’t bother.
Thank you for your help

[Mosu]

The differences are indeed only in a very small number of elements, and those should always have the same size. Therefore syncing the two files should be nearly trivial. I cannot tell the actual elements off-hand, but they should be the various UID elements (track UID, segment UID, tag/edition/chapter/attachment UIDs), the muxing timestamp ("Date:" in mkvinfo's output), and (if you have two different sets of mkvmerge executables) the "writing app" element.

The position of these elements varies: most of them are located at the start of the file before the first cluster (track/segment/chapter UIDs, muxing timestamp, writing app). Others can be at the end of the file because mkvmerge puts them there (tag/edition/attachment UIDs).

There are two sync tools I use regularly: rsync and unison. rsync is mostly a "from point A to point B" tool, and unison is a "keep two directory structures in sync and resolve differences" tool. Therefore rsync is better suited for this particular purpose. Both are available for various Linux/Unixy systems as well as for Windows, but my experience with them on Windows hasn't been that great. However, both run over ssh and only update those parts of a file that has actually changed making them incredibly efficient for huge files with small differences.

[LeXXuz]

I have a question about the "--cropping" command.

Does it really tamper with the video stream by deleting specified number of macroblocks or is it just setting some kind of flag for the decoder filter to apply cropping during playback?

[Mosu]

I have a question about the "--cropping" command.

Does it really tamper with the video stream by deleting specified number of macroblocks or is it just setting some kind of flag for the decoder filter to apply cropping during playback?

The latter. mkvmerge is not an encoder/decoder, and the cropping parameters are only stored in the track headers. It's up to the decoding chain to honor them and use the appropriate filters.

[neb1236]

I thought it could be interesting for other to see if it was trivial or not, well it is.
First thank you for the name of rsync Mosu, I already knew the name but I couldn't recover it, you saved me some time.
Here is the result:

- 6 mkv total of 4.09Go
- Sent: 436Ko Received: 1.08Mo
- Achieved in 4 min and 10 sec
Limited by a slow P4@2.8ghz processor and done through a 100ko/s upload and 50ko/s download broadband restriction.
- rsync effectiveness: 2774!!!

Mkv made with same version of mkvmerge with identical batch and source files
Made between a Windows XP and Windows 7 desktop, I didn't used rsync under cygwin but a modded rcync for windows called DeltaCopy (work good with mix linux/win server/client too)

I knew it was an effective technique, but it has surpassed my expectation.

[Mosu]

Nice numbers indeed :) Ah yes DeltaCopy; I actually know that one but didn't think of it. Anyway, glad to see you've got a working solution.

[smok3]

how would i split mkv to lil mkvs by chapters?

mkvmerge GUI v2.4.1 ('Use Me')
built on Dec 13 2008 21:02:59
(ubuntu)

[Mosu]

mkvmerge cannot split by chapters (neither in current versions -- 2.4.1 is rather old, btw). It can split by timecodes, but you'll have to get the chapter start times manually and use them as the split timecodes.

[smok3]

you'll have to get the chapter start times manually and use them as the split timecodes

thanks, that was actually the 2nd thing i tried, i have problems with required format i guess this:

HH:MM:SS, HH:MM:SS, HH:MM:SS
or this
HH:MM:SS.MS, HH:MM:SS.MS, HH:MM:SS.MS

is not the right thing? wrong delimiter?

edit:
here is the data as reported by mediainfo;
00:00:00.000
00:00:15.880
00:05:02.440
00:05:18.280
00:10:05.320
00:10:21.160
00:15:07.240
00:15:23.080
00:20:09.640
00:20:25.480
00:25:12.520
00:25:28.360
00:30:14.920
00:30:31.240
00:35:17.320
00:35:33.160
00:40:19.720
00:40:35.560
00:45:22.120
00:45:37.960

[Mosu]

Quoting the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html) for the "--split" option:

--split size:<d[k|m|g]> or shorter --split <d[k|m|g]>
--split duration:<HH:MM:SS.nnnnnnnnn|ns> or shorter --split <HH:MM:SS.nnnnnnnnn|ns>
--split timecodes:A[,B[,C...]]

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 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.
At the moment mkvmerge supports three different modes.
1. Splitting by size.
The parameter d may end with k, m or g to indicate that the size is in KB, MB or GB respectively. Otherwise a size in Bytes is assumed. After the current output file has reached this size limit a new one will be started. The size: prefix may be omitted for compatibility reasons.
2. Splitting after a duration.
The paramter must have the form HH:MM:SS.nnnnnnnnn for specifying the duration in up to nano-second precision or a number n followed by the letter ’s’ for the duration in seconds. "HH" is the number of hours, "MM" the number of minutes, "SS" the number of seconds and "nnnnnnnnn" the number of nanoseconds. Both the number of hours and the number of nanoseconds can be omitted. There can be up to nine digits after the decimal point. After the duration of the contents in the current output has reached this limit a new output file will be started. The duration: prefix may be omitted for compatibility reasons.
3. Splitting after specific timecodes.
The parameters A, B etc must all have the same format as the ones used for the duration (see above). The list of timecodes is separated by commas. After the input stream has reached the current split point’s timecode a new file is created. Then the next split point given in this list is used. The timecodes: prefix must not be omitted.
For this splitting mode the output filename is treated differently than for the normal operation. It may contain a printf like expression ’%d’ including an optional field width, e.g. ’%02d’. If it does then the current file number will be formatted appropriately and inserted at that point in the filename. If there is no such pattern then a pattern of ’-%03d’ is assumed right before the file’s extension: ’-o output.mkv’ would result in ’output-001.mkv’ and so on. If there’s no extension then ’-%03d’ will be appended to the name.

If you use the command line then you really, really do have to use the format's name (e.g. "--split timecodes:00:05:00,00:12:41"). If you use mmg then you only need to enter the list of timecodes into the input box.

[Mosu]

Hey,

I've implemented reading multiple VOBs that logically belong together as if they were a single big file. Here's the ChangeLog entry that should make clear what I mean:

* mkvmerge, mmg: new feature: If a MPEG-2 program stream file is added to mkvmerge whose base name ends in a number then mkvmerge will automatically read and process all other files in the same directory with the same base name, same extension and different numbers. Those files are treated as if they were a single big file. This applies e.g. to VOB files from DVD images that are named VTS_01_1.VOB, VTS_01_2.VOB, VTS_01_3.VOB etc. mmg will output an error message if the user tries to add or append one of the other files that mkvmerge will process automatically (e.g. if the user has added VTS_01_1.VOB already and tries to append VTS_01_2.VOB).

This also fixes bug 437.

I certainly need some folks to test this. I've successfully muxed files on both Windows and Linux.

This also means that mkvmerge will still detect VOB files from the middle of such a set as e.g. h264 instead of MPEG-2 if you decide to add e.g. VTS_01_3.VOB instead of VTS_01_1.VOB -- don't do that :)

BTW: No, this of course does not mean that mkvmerge can read directly from encrypted DVDs. It does not contain decryption routines.

Here's the link to the Windows build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.0.0-build20091228-193-setup.exe

[smok3]

Thanks again, what fixed the problems was one or more of this things:

1. remove the repo version (old one), mkvtoolnix + gui
2. install the debs (jaunty amd64):
mkvmerge GUI v3.0.0 ('Hang up your Hang-Ups') built on Dec 12 2009 19:13:47
3. paste timecodes like '00:00:00.000,00:05:02.440,00:10:05.320,00:15:07.240,00:20:09.640'

to admin: this was probably the wrong thread, posts:
1330-1333 + 1335 could make a cute lil thread named 'how would i split mkv to lil mkvs by chapters?'
sorry about that...

[73ChargerFan]

I certainly need some folks to test this.
Thanks for being motivated! My first test came out fine on Win7. I'll test with a few other dvds.

[nkk]

Why mkvmerge GUI does not allow manage ChapterSegmentUID XML tag in Chapter editor?

[Mosu]

No particular reason.

[73ChargerFan]

I tested on a dvd with more than one title, (vts_02_ ...) and it works fine. The change's I'd make is to state in the change log that this is tested only with dvd vob files, and an indication in mmg when adding the first file that it is also loading files +02 +03 etc. instead of the warning message.

[Mosu]

The change's I'd make is to state in the change log that this is tested only with dvd vob files,

I've done this already after posting the announcement above.

and an indication in mmg when adding the first file that it is also loading files +02 +03 etc. instead of the warning message.

Good idea. I'll keep the error message, though.

[Brother John]

Hi,

I’ve found a small bug in MMG’s (3.0.0 on Windows) setting »File / Options / mmg / Use this directory«. When you enter a path with a backslash at the end here, the auto-created output filename in the main window will wrongly contain a double backslash before the actual file name.

Edit:
At least with Win XP that double backslash doesn’t have any negative effects. Muxing still works as expected. Still looks weird, though.

[Mosu]

Double backslashes (on Windows) and double slashes (on Linux, Mac) don't change the directory. Only at the beginning of the file name are double backslashes interpreted differently then a single one (as a network path).

[Atomic420]

On the same subject as output file names, with MKVMerge (3.0.0 Windows) would it be possible to add some character to the default output file name?
As it is the default is exactly the same as the input file name, so if you inadvertently click to start the operation it will overwrite the source file.
So source is "video.mkv" new default output something like "video(2).mkv"

Thanks for this great app and .... HAPPY NEW YEAR!

[Brother John]

@Mosu
Ah, ok. Learned something new again. Thx. I still think those double backslashes might confuse users. But it only happens under such unlikely circumstances that it’s probably not worth spending any effort on; unless you’re extremely bored of course. :)

[Mosu]

On the same subject as output file names, with MKVMerge (3.0.0 Windows) would it be possible to add some character to the default output file name?
As it is the default is exactly the same as the input file name, so if you inadvertently click to start the operation it will overwrite the source file.

Actually it won't -- mkvmerge will output an error message in such a case and will not start muxing. That being said:

So source is "video.mkv" new default output something like "video(2).mkv"

I think this is a good idea, and here's a build that does exactly that: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.0.0-build20100102-199-setup.exe

[Mosu]

Hi Mosu. What do you think about changing Abort button to "open folder" after muxing is done? So it will open folder where the file was saved.

Aaaaand here it is: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.0.0-build20100103-200-setup.exe

[Keiyakusha]

Aaaaand here it is: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.0.0-build20100103-200-setup.exe

That's great! :thanks:

[smok3]

report: the bins provided by jonthn seems to work fine on osx snow leopard - v 3.0.0.

[bigpapa4u]

Thanks for the great app ...

Happy New Year everyone!:thanks::thanks::thanks:

[stax76]

@Mosu

I noticed there is a GUI for mkvinfo, besides mmg are there other GUIs included?

Maybe you could add mkvinfo showing a file extension for each stream so applications don't need to maintain a dictionary, I'm not sure if my dictionary is up-to-date and bug free, where do I find which formats are currently supported by mkvextract?

Dim dic As New Dictionary(Of String, String)

dic("A_AAC") = "aac"
dic("A_AC3") = "ac3"
dic("A_DTS") = "dts"
dic("A_FLAC") = "flac"
dic("A_MPEG/L1") = "mpa"
dic("A_MPEG/L2") = "mp2"
dic("A_MPEG/L3") = "mp3"
dic("A_PCM/INT/LIT") = "wav"
dic("A_QUICKTIME") = "qdm"
dic("A_REAL") = "ra"
dic("A_TTA1") = "tta"
dic("A_VORBIS") = "ogg"
dic("A_WAVPACK4") = "wv"
dic("Attachment") = "att"
dic("Chapters") = "Chapters"
dic("S_TEXT/ASS") = "ass"
dic("S_TEXT/SSA") = "ssa"
dic("S_TEXT/USF") = "usf"
dic("S_TEXT/UTF8") = "srt"
dic("S_VOBSUB") = "idx"
dic("Tags") = "Tags"
dic("V_MPEG1") = "m1v"
dic("V_MPEG2") = "m2v"
dic("V_MPEG4/ISO/ASP") = "m4v"
dic("V_MPEG4/ISO/AVC") = "h264"
dic("V_MS/VFW/FOURCC") = "avi"
dic("V_REAL") = "rmvb"
dic("V_THEORA") = "ogg"

[MuLTiTaSK]

@stax76 & Mosu

:eek: i was wondering why it had a icon very cool function i did not know about i have to read the docs more carefully :thanks:
http://img532.imageshack.us/img532/7736/ss20100110125227.png

[Mosu]

@Mosu

I noticed there is a GUI for mkvinfo, besides mmg are there other GUIs included?

No. mmg & mkvinfo's GUI are the only ones.

Maybe you could add mkvinfo showing a file extension for each stream so applications don't need to maintain a dictionary, I'm not sure if my dictionary is up-to-date and bug free, where do I find which formats are currently supported by mkvextract?

mkvextract does not care about file extensions (neither does mkvmerge, btw, safe for a few exceptions -- VobSubs (the ".sub" for the ".idx") WavPack (the ".wvc" for the ".wv") etc.

There's no concise list of supported CodecIDs, but there's always the source code at e.g. http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=blob;f=src/extract/xtr_base.cpp :

// Audio formats
else if (new_codec_id == MKV_A_AC3)
return new xtr_base_c(new_codec_id, new_tid, tspec, "Dolby Digital (AC3)");
else if (new_codec_id == MKV_A_EAC3)
return new xtr_base_c(new_codec_id, new_tid, tspec, "Dolby Digital Plus (EAC3)");
...

etc etc. The MKV_A_XYZ definitions are found in http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=blob;f=src/common/matroska.h

The xtr_xyz_c class determines the file type written. "xtr_base_c" means just the raw file, all the others use some kind of container format.

dic("A_FLAC") = "flac"

FLAC can also be written into OggFlac files (though no one does that, I guess).

dic("A_QUICKTIME") = "qdm"

Extraction of A_QUICKTIME and A_QUICKTIME/* tracks is not supported.

dic("A_REAL") = "ra"

".ra" is usually used for older RealAudio type containers. mkvextract writes "Real Media File Format" containers both for audio and video tracks (and both can be put into the same file, like multiple VobSub tracks can be extracted into the same .idx file). ".rm" is usually used for these containers.

dic("V_REAL") = "rmvb"

Same as above -- I guess that ".rm" is more common than ".rmvb", but I'm hardly the expert on Real files.

The rest looks ok, but I haven't checked whether or not you're missing CodecIDs.

[Mosu]

i was wondering why it had a icon very cool function i did not know about i have to read the docs more carefully :thanks:

And you didn't simply try clicking said icon? :) I guess I'm more curious than you are ;)

[stax76]

@Mosu

Thanks for the info, your support is fantastic.

@MuLTiTaSK

All GUI's packaged with StaxRip I know about can be launched under Tools > Launch, I've added mkvinfo GUI. Since MeGUI's loosely coupled toolbox approach of doing a GUI has advantages I'm adding better support to perform individual tasks manually, automation is good but sometimes a task needs to be performed manually. I've added Tools > Advanced > Demuxing > Demux a mkv file using mkvextract and I will add as many manual tasks as I can.

[sneaker_ger]

I have 2 feature requests:

1.) a command line viewer in the header editor gui
2.) an option to extract all streams and/or all attachments of a file without having to write huuge command lines every time if you simply want to demux everything and don't need any custom filenames

[Mosu]

I have 2 feature requests:

1.) a command line viewer in the header editor gui

Sorry, I will not implement this. Reason is that the header editor GUI does not call mkvpropedit for doing the work but actually writes to the file itself.

2.) an option to extract all streams and/or all attachments of a file without having to write huuge command lines every time if you simply want to demux everything and don't need any custom filenames

This may be implemented in the future.

[MatLz]

Hi Mosu!

Instead of splitting only at times, Will be possible to add a feature for splitting at frames?(of course at keyframes) By specifiing the frames....'100,4500,8864...' or by reading a X264 .qp file ?

[Mosu]

Probably not.

[MatLz]

Probably not.

What a probably pity...

Thx for your quick answer.

[sneaker_ger]

Sorry, I will not implement this. Reason is that the header editor GUI does not call mkvpropedit for doing the work but actually writes to the file itself.

I see. The reason I'm asking is that I actually couldn't find any complete documentation on how to use it. This one (http://darkflame.tenet.odessa.ua/cgi-bin/man/man2html?1+mkvpropedit) explains the basic usage but I have no idea how the flags etc. are named so I end up being unable to set them.


This may be implemented in the future.

That would be a huge time and hassle saver. Thank you for considering it.

[stax76]

@sneaker_ger

The latest StaxRip test built makes mkv demuxing easy, you would choose:

Tools > Advanced > Demuxing > Demux a mkv file using mkvextract

It will show a file browser where you choose a mkv file and it will show a folder browser where you choose a target directory, it'll demux all streams in the mkv file to the target directory. If you are interested you can find the test built here:

http://forum.doom9.org/showthread.php?p=1362809#post1362809

[sneaker_ger]

Thank you, but it only shows "Command prompt" for me under "Advanced". (And I'd like to use the CLI anyways...)

[stax76]

Do you have version 1141? If so then I forgot to reset the main menu, you can do this in three different ways, do you know one of them? I can't help with the command shell unless somebody built a console app with my code, 100 lines simple VB.NET code, should take less an hour to port.

[sneaker_ger]

I'll answer in the StaxRip thread to keep it on topic.

[Snowknight26]

Any chance of optimizing network muxing? Remuxing an from and to an mkv over a gigabit network takes ~2 minutes where as when running the same job locally took 9 seconds for ~2.5GB of total throughput.

[millerci]

Cropping Mkv.

With head editor i choose Video Track 1/Video Crop top and enter the value. 140 pixel for black bars. Video Crop bottom 140 pixel too. Save it. Then i returned to mkvmergegui and opened the movie inside the input section. Make the mux. Nothing happens. So after a long search and many tries i gave up.

Tried another solution for Crop the mkv. again in mkvtoolnix.

With Muxing -> Add command line options i entered this code --cropping <TID:left,top,right,bottom>. But i don't know any further operation. Which area i will give the cropping value? How do i write it? (Example 140 pixel fro top,140 pixel for bottom crop) Then How do i add this operation to Add to Job Queue? Or what is the right solution for this?

I want to crop my mkv movie without remux without encode again. Please somebody help me or show me a link how i can do it right.
:/

[Mosu]

I see. The reason I'm asking is that I actually couldn't find any complete documentation on how to use it. This one (http://darkflame.tenet.odessa.ua/cgi-bin/man/man2html?1+mkvpropedit) explains the basic usage

Just a note: the current documentation for all mkv* command line tools is always available at http://www.bunkus.org/videotools/mkvtoolnix/docs.html but I didn't include mkvpropedit's man page. Thanks for pointing this out (even indirectly ;) ). I've added it now: http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvpropedit.html

but I have no idea how the flags etc. are named so I end up being unable to set them.

That's what mkvpropedit's --list-property-names option is for.

[Mosu]

Any chance of optimizing network muxing? Remuxing an from and to an mkv over a gigabit network takes ~2 minutes where as when running the same job locally took 9 seconds for ~2.5GB of total throughput.

No, sorry.

[Mosu]

With head editor i choose Video Track 1/Video Crop top and enter the value. 140 pixel for black bars. Video Crop bottom 140 pixel too. Save it. Then i returned to mkvmergegui and opened the movie inside the input section. Make the mux. Nothing happens. So after a long search and many tries i gave up.

My guess is that you actually mean "playback of the muxed file has not changed at all, no cropping is in effect" when you write "Nothing happens". In that case this is most likely a problem or missing feature in the playback software (demuxer, splitter, player). Cropping parameters are not widely supported by players.

Note that mkvmerge ONLY sets header values for cropping -- it does not alter the video stream at all. It is not an encoding application.

[Mosu]

Hey,

I've released mkvtoolnix v3.1.0. This release contains contains the usual mix of bug fixes and smaller enhancements.

Notes for folks building from source:

1. Library dependency changes: Boost v1.34.0 or later is now required. Boost's filesystem library is required as well (for those distributions that split the Boost development packages).

2. The man pages & mmg's guide have been translated to other languages, and the file layout in /usr/share/mkvtoolnix has been changed accordingly. I suggest you take a look at what a normal 'configure && make && make install' does and adjust the build scripts afterwards.

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 3.1.0:

------------------------------------------------------------
2010-01-18 Moritz Bunkus <moritz@bunkus.org>
* Released v3.1.0.

2010-01-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If the first input file was a Quicktime/MP4 file and all tracks from that file were deselected for muxing then mkvmerge would crash. Fix for bug 458.

2010-01-09 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The option 'AAC is SBR/HE-AAC' was not honored for appended AAC tracks. This could lead to mkvmerge aborting with an error that the track parameters did not match if it itself could not detect HE-AAC in the second file.

2010-01-06 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a Chinese Simplified translation for mmg's guide by Dean Lee (see AUTHORS).

2010-01-05 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a Japanese translation for the man pages by Katsuhiko Nishimra (see AUTHORS).

2010-01-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The output file name is checked for invalid characters before the muxing process is started. Fix for bug 455.
* mkvpropedit, mmg: bug fix: Files with an infinite segment size are handled correctly now. Fix for bug 438.
* mkvmerge: bug fix: Matroska files which have its 'tracks' element located behind the clusters are read correctly now.
* mmg: enhancement: After muxing the "abort" button is changed to "open folder" which opens the explorer on the output file's folder. This only happens on Windows.

2010-01-02 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: When constructing the output file name mmg will only suggest names that don't exist already by appending a number to the file name (e.g. resulting in "/path/file (1).mkv").

2009-12-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading chapters from MP4 files that are stored in tracks with subtype 'text'. Such files are used e.g. on iPods/iPhones and can be created by HandBrake. Fix for bug 454.

2009-12-29 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The "tags" input box on the "general track options" tab was not updated when a track was selected. Fix for bug 453.

2009-12-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: If a MPEG-2 program stream file is added to mkvmerge whose base name ends in a number then mkvmerge will automatically read and process all other files in the same directory with the same base name, same extension and different numbers. Those files are treated as if they were a single big file. This applies e.g. to VOB files from DVD images that are named VTS_01_1.VOB, VTS_01_2.VOB, VTS_01_3.VOB etc. mmg will output an error message if the user tries to add or append one of the other files that mkvmerge will process automatically (e.g. if the user has added VTS_01_1.VOB already and tries to append VTS_01_2.VOB).

This also fixes bug 437.
* Build requirements changed: mkvtoolnix requires Boost v1.34.0 or later. It requires the Boost::Filesystem library (with all Boost versions) and the Boost::System libraries (starting with Boost v1.35.0).

2009-12-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: SRT files with negative timecodes will are not rejected anymore. Negative timecodes will be adjusted to start at 00:00:00.000.

2009-12-25 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: Added support for extracting Blu-Ray subtitles (CodecID "S_HDMV/PGS").

2009-12-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge/mmg: enhancement: Added an option '--segment-uid' for specifying the segment UIDs to use instead of having to use a XML file and '--segmentinfo'.
* Installer: The installer will no longer offer to run mmg after it has been installed. On Windows setups where a normal user account doesn't have administrator privileges this caused mmg to be run as the user "Administrator" instead of the normal user account causing confusion and some things not to work, e.g. drag & drop.

2009-12-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Zero-length frames in Theora bitstreams as created by libtheora v1.1 and later were dropped. Fix for bug 450.

2009-12-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: On Windows 2000/XP the 'add/append file' dialog was not showing files with certain extensions (e.g. ".srt" or ".mp4") if the option "all supported media files" was selected. Fix for bug 448.
------------------------------------------------------------

Have fun.

[millerci]

My guess is that you actually mean "playback of the muxed file has not changed at all, no cropping is in effect" when you write "Nothing happens". In that case this is most likely a problem or missing feature in the playback software (demuxer, splitter, player). Cropping parameters are not widely supported by players.

Note that mkvmerge ONLY sets header values for cropping -- it does not alter the video stream at all. It is not an encoding application.

You are right "no cropping is in effect".


hmm if i want a crop than i must do an encode. so how can i know the exact encode parameters that is used for the movie? If i knew it than i can put the right values so the movie won't lose its quality.

by the way mkvtoolnix is a great program. thank you for doing a great job like this. :) i just wish that a video tutorial includes tips for this good program will be most welcome.

[stax76]

I had also problems with the crop feature, I had a WMV that needed to be cropped, mkvmerge did not allow me to import wmv so I used Haali's DS muxer. The resulting mkv file played fine. Then I opened this file with mmg, entered the cropping, remuxed it. It would play jerky then and no matter what player I tried the crop didn't work. I ended up to reencode which didn't hurt much anyway.

[sneaker_ger]

Just a note: the current documentation for all mkv* command line tools is always available at http://www.bunkus.org/videotools/mkvtoolnix/docs.html but I didn't include mkvpropedit's man page. Thanks for pointing this out (even indirectly ;) ). I've added it now: http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvpropedit.html



That's what mkvpropedit's --list-property-names option is for.

Thank you. I tried it again and it worked this time. The reason why I couldn't get it to work was because I tried your example in the help file:
The command line 'mkvpropedit source.mkv --edit track:a2 --set title=Comments' could be converted into the following option file:

It doesn't work because you cannot set "title" for a single track.

I had also problems with the crop feature, I had a WMV that needed to be cropped, mkvmerge did not allow me to import wmv so I used Haali's DS muxer. The resulting mkv file played fine. Then I opened this file with mmg, entered the cropping, remuxed it. It would play jerky then and no matter what player I tried the crop didn't work. I ended up to reencode which didn't hurt much anyway.

How about filing a bug report and uploading the sample? (Even if you ended up re-encoding)

[Mosu]

Thank you. I tried it again and it worked this time. The reason why I couldn't get it to work was because I tried your example in the help file:
...
It doesn't work because you cannot set "title" for a single track.

Dang. That's what happens when I write documentation but don't actually test it :) Exchanging "title" with "name" is probably what I'll do.

[MuLTiTaSK]

2010-01-20 Moritz Bunkus <moritz@bunkus.org>

* mmg: new feature: Added a control for mkvmerge's "--cropping"
parameter.

* mmg: enhancement: Added the file extensions ".dtshd", ".dts-hd",
".truehd" and ".true-hd" to mmg's"'add/append file" dialogs.

* mkvextract: bug fix: "mkvextract --version" was only writing an
empty string. Fix for bug 463.

top notch support like always Mosu :thanks:

[Mosu]

2010-01-20 Moritz Bunkus <moritz@bunkus.org>

* mmg: new feature: Added a control for mkvmerge's "--cropping"
parameter.

* mmg: enhancement: Added the file extensions ".dtshd", ".dts-hd",
".truehd" and ".true-hd" to mmg's"'add/append file" dialogs.

* mkvextract: bug fix: "mkvextract --version" was only writing an
empty string. Fix for bug 463.

top notch support like always Mosu :thanks:

Btw, there's also a pre-build including these fixes: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100120-208-setup.exe

[Maccara]

Btw, there's also a pre-build including these fixes: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100120-208-setup.exe

This has the path problem again (happily overwrote the whole existing path settings, claiming it was "empty").

...I wonder why NSIS (or whoever's the installer was - didn't look :)) can't get this right...

[Mosu]

This has the path problem again (happily overwrote the whole existing path settings, claiming it was "empty").

? I don't quite understand what you mean. Care to elaborate?

[Maccara]

? I don't quite understand what you mean. Care to elaborate?

This is an old bug you've fixed once already: https://www.bunkus.org/bugzilla/show_bug.cgi?id=365

I know this is not your fault, but if you could check in case you updated NSIS and re-introduced this bug.

[Mosu]

Oh THAT problem. You guessed right. I've re-built NSIS again with 32k string size. Here's an updated installer: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100121-209-setup.exe

[Atak_Snajpera]

Will you add support in mkvextract for A_MS/ACM audio?
http://www.crist.com/Temp/pirates2_sample.mkv_0

[Maccara]

Oh THAT problem. You guessed right. I've re-built NSIS again with 32k string size. Here's an updated installer

Thank you very much!

Didn't test it yet, but no reason to think it isn't working now (old known issue from 3 rd party component with a known solution ;)).

A bit annoying issue, though. Luckily I was feeling "unsecure" as I hadn't updated mkvtoolnix for a long time, so I had just backed up the registry keys involved in anticipation. ;)

[Mosu]

Will you add support in mkvextract for A_MS/ACM audio?

No, sorry.

[Snowknight26]

The tooltips for Language, Charset and Cue name format under Chapters, Segment UID's under File/segment linking and max. number of files under Splitting don't have any line breaks in it making them get cut off on everything but very high resolution desktops.

[Mosu]

Tooltips suck on Windows (from a programmer's point of view). Maybe it's only wxWidget's tooltip implementation, I'm not sure.

I'll fix this, though.

[fingershop]

Hi, I frequently need to remux batches of similarly structured files, in which I'm adding and removing streams, and setting track attributes, all the same way for each file. Adding all these similar files to the job queue is very tedious and error prone, and I had an idea for simplifying this process, a kind of "quick batch" mode.

The way it is now, each queued file must be configured one at a time, for enabled and disabled tracks, and their attributes, like language, default flags, framerates, aspect, etc.

Here's the idea: After configuring and adding the first file to the job queue, mmg would be able to automatically re-use that configuration for all other files added to the job queue. Of course this assumes that all files added will have the same or similarly structured files. This might also assume, when adding in streams, that a certain file naming method is used, so that those stream files could automatically be included.

Near the existing Add button, perhaps there could be a "Batch Add" button or similar, which would add the next file (or an entire folder of files?) to the job queue, automatically applying the same settings to each one it finds.

This would be a huge time saver, and would also keep you from making forgetful mistakes when creating batch jobs.

[Chumbo]

Hi, I frequently need to remux batches of similarly structured files, in which I'm adding and removing streams, and setting track attributes, all the same way for each file. Adding all these similar files to the job queue is very tedious and error prone, and I had an idea for simplifying this process, a kind of "quick batch" mode.

The way it is now, each queued file must be configured one at a time, for enabled and disabled tracks, and their attributes, like language, default flags, framerates, aspect, etc.

Here's the idea: After configuring and adding the first file to the job queue, mmg would be able to automatically re-use that configuration for all other files added to the job queue. Of course this assumes that all files added will have the same or similarly structured files. This might also assume, when adding in streams, that a certain file naming method is used, so that those stream files could automatically be included.

Near the existing Add button, perhaps there could be a "Batch Add" button or similar, which would add the next file (or an entire folder of files?) to the job queue, automatically applying the same settings to each one it finds.

This would be a huge time saver, and would also keep you from making forgetful mistakes when creating batch jobs.
I do this all the time with a DOS batch/command file. Just copy the command line to the clipboard from the UI, paste it into a command file and use the dos-based for command to process each file by feeding it to the for loop.

Below is an example of a batch file I used just today to mux a bunch of episodes from elementry streams to MKV.
for /f "delims=" %%i in ('dir /b "*.h264"') do "d:\Program Files\MKVtoolnix\mkvmerge.exe" -o "d:\\media\\tv\\%%~ni.mkv" "--forced-track" "0:no" "--default-duration" "0:24000/1001fps" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "%%i" "--language" "0:eng" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "%%~ni.ac3" "--track-order" "0:0,1:0"

[fingershop]

Thanks Chumbo, I do use this method already, but its also cumbersome having to create and edit dos batch files each time I want to mux a bunch of files. The idea of simplicity for me is to keep all the configurations happening in the gui, without having to go back and forth to command prompts or such all the time. I appreciate being hands-on, but computers can handle this type of automation so much quicker and easier than doing it manually.

Oh, and you kinda emphasized my point :-)
If the gui made it easier to do this then you wouldn't need to use batch files instead.

[Mosu]

Hi, I frequently need to remux batches of similarly structured files, in which I'm adding and removing streams, and setting track attributes, all the same way for each file. Adding all these similar files to the job queue is very tedious and error prone, and I had an idea for simplifying this process, a kind of "quick batch" mode.

No, sorry. I've answered as to why I won't implement such a thing a couple of times before. The run-down is that in order to make such a thing really useful to a lot of people (instead of only a handfew or even only one: you) it would have to be really, really powerful requiring really, really a lot of work. I don't have that kind of time, nor do I have the motivation to do that as there are several scripting languages (shells like bash, zsh, maybe even the Windows Power Shell; scripting languages like Python, Ruby, Perl, Lua) available on all platforms for power users like yourself that are way more flexible and not that hard to learn.

[fangorn]

I, for instance, created a bash script using mkvmerge and many others to mux many input containers to MKV, MP4, TS, M2TS. (see avi2mkv from my Sig.)

It is much more convenient (in my eyes at least) than having to load hundreds of files in a oh so powerfull batch processor. (I designed it originally to transfer and markup multiple language TV show episodes in AVI containers to MKV, hence the name.)

It should be runnable in Cygwin under Windows, but I did not try to set it up. The dependencies are named in the script though, if someone wants to try getting it to run. I could even host a package adding all necessary programs to make it run under Cygwin standard installation if somebody would step up and mad it work. As I don't use Windows I am slightly handicaped in this matter. ;-)

[Snowknight26]

Any chance of having invalid paths be the first step in muxing? Even before, say, FLAC parsing?

[fingershop]

I'd like to rephrase my request... :-)

After you've configured a file for muxing, it would be handy if mmg would allow you to "replace" that file by choosing another one, while maintaining all configured settings.

Normally, you would click on the file in the Input files list, click the remove button, then click the add button to add another one and configure it.

Instead, you would click on the file in the Input files list, click the "replace" button, and (after manually choosing the replacement file) that's it, this file would be ready for muxing (or queuing) with no re-configuration needed.

I agree that a full automation method would take lots of work to implement. This simpler idea would, I'm guessing, take a much smaller amount work. Functionally, it might be as simple as verifying the replacement file's structure, and changing the file name variables (input and output) that will be used for muxing.

Yes, scripting languages are powerful, but none of them particularly let you choose streams and attributes from a gui, which is the key thing for ease of use.

[Mosu]

Any chance of having invalid paths be the first step in muxing? Even before, say, FLAC parsing?

If you want mkvmerge to check if all files named on the command line exist before actually opening and analyzing them then my answer is "no". This would mean quite a lot of changes to the very core of mkvmerge, one area I try to change as little as possible.

However, I can and will get rid of the 'pre-parsing' stage in FLAC's reader soon. It is not necessary if I get rid of the libFLAC dependency at the same time and implement my own FLAC file format parser which is easy enough to do -- mkvmerge only needs to know a few basic parameters about each FLAC frame; the data doesn't have to be decoded.

[Mosu]

I'd like to rephrase my request... :-)

After you've configured a file for muxing, it would be handy if mmg would allow you to "replace" that file by choosing another one, while maintaining all configured settings.

I won't implement that either, sorry. I'm not against having such a feature in the first place (so if someone would implement it and provide a patch I'd accept it gladly). I just reserve the right to spend my time on other things :)

[Audionut]

Any chance of supporting .ts

I've got a ton i'd like to transfer to .mkv.

[Mosu]

Not in the near future.

[Snowknight26]

Is it normal for the form components to be in different locations after muxing? I don't recall this prior to 3.1.0.

http://i45.tinypic.com/x0wu1x_th.jpg (http://i45.tinypic.com/x0wu1x.jpg)

http://i49.tinypic.com/1sz61g_th.jpg (http://i49.tinypic.com/1sz61g.jpg)

[Mosu]

Is it normal for the form components to be in different locations after muxing? I don't recall this prior to 3.1.0.

Hmm. It's possible that a carriage return has been added to the end of the "everything went fine" sentence by accident. It's not intentional, no. Maybe it also has something to do with the change to the 'Cancel' button's label to 'Open Folder'. I'll look into it one of these days.

[Mosu]

Hmm. It's possible that a carriage return has been added to the end of the "everything went fine" sentence by accident.

That carriage return has been present for ever. However, it has only been causing a re-layout of the dialog after the feature to change the 'cancel' button to 'open folder' had been added recently.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100131-212-setup.exe

[whatever-ever]

Ok here goes...

I've tried for 5 days to compile mkvtoolnix (or any part thereof) for windows. I compiled it with no hassle on my ubuntu pc, but for some reason i'm having a lot of trouble compiling with either mingw or cygwin.

All libraries have been compiled under mingw (./configure --prefix=/mingw), except boost, which i'm not sure i've "installed" properly. took a bit of copying and pasting files from here and there to /lib before i could finally get mingw to recognize that i have boost. but it get erros like this (currently only this one):
checking for boostlib >= 1.29.0... yes
checking whether the Boost::Regex library is available... yes
configure: error: Could not link against the Boost regex library !
First off, yes that is not the configure file for 3.10, i pasted the above from when i tried to compile 2.5.3 instead. The error is similar for 3.10 (although it's Boost::Filesystem it checks for first, and gives same output as above).

So it's probably my boost library that is foobar-- however, it always reports that the boost libraries exist, so maybe it's something about setting variables that my mingw has trouble with?

if test "x$as_val" = x""yes; then :
BOOST_FILESYSTEM_LIB="-l$ax_lib"; link_filesystem="yes"; break
else
link_filesystem="no"
fi

done

fi
if test "x$link_filesystem" != "xyes"; then
as_fn_error "Could not link against $ax_lib !" "$LINENO" 5

I've checked that this is where it reports the "could not link", and as you can see, ax_lib is not set for some reason, but link_filesystem both is and isn't set to yes?

Sorry if this is an obvious question, but for the life of me I cannot figure out how to fix this.

PS: "have you tried building boost?", yes, however not with any luck. i tried so by running bootstrap.sh etc., but it doesn't go so well, http://pastebin.com/f761baf28 (forever paste).

Currently using gcc 3.4.5 (mingw-vista special r3) and boost 1.41.0. Have also tried with 4.4.1 (which is the same as my ubuntu pc uses). iconv (GNU libiconv 1.13) here, but iconv (EGLIBC) 2.10.1 on the ubuntu pc.

Any hint that can help even the tiniest bit is greatly appreciated!

[Mosu]

First things first: Having to set up a mingw build environment sucks. Big time. I've done it a couple of times and each and every time I spend hours until everything's working fine.

Ok here goes...

I've tried for 5 days to compile mkvtoolnix (or any part thereof) for windows. I compiled it with no hassle on my ubuntu pc, but for some reason i'm having a lot of trouble compiling with either mingw or cygwin.

Use mingw, forget about cygwin. I don't use mingw on Windows myself, I use a mingw cross compilation environment on Ubuntu.

All libraries have been compiled under mingw (./configure --prefix=/mingw), except boost, which i'm not sure i've "installed" properly. took a bit of copying and pasting files from here and there to /lib before i could finally get mingw to recognize that i have boost. but it get erros like this (currently only this one):

I usually have to use explicit arguments for configure so that it will find the Boost libraries. Here's my current script for configuring mkvtoolnix:

#!/bin/zsh
M=$HOME/prog/video/mingw
TFT=$M/src

test -z $WX && WX=$(cat ~/prog/video/mingw/default_wxwidgets_version)
W=$M/wxWidgets-$WX
test -d $W || {
echo "$W" does not exist
exit 1
}

if pwd | grep -q -E 'nogui$' ; then
WX=""
NOGUI="--disable-gui"
else
WX="--with-wx-config=$W/bin/wx-config"
NOGUI=""
fi

./configure \
--host=i586-mingw32msvc \
--cache-file=config.cache \
--with-extra-includes=$TFT/libebml\;$TFT/libmatroska\;$M/include \
--with-extra-libs=$TFT/libebml/make/mingw32\;$TFT/libmatroska/make/mingw32\;$M/lib \
--with-boost=$HOME/prog/video/mingw/boost \
$WX $NOGUI \
"$@"

As you can see my base path to all mingw stuff (except the compiler itself) is ~/prog/video/mingw

Sorry if this is an obvious question, but for the life of me I cannot figure out how to fix this.

It isn't, but I cannot help you either; debugging Boost linking problems is one of the areas that suck so much. It might be a couple of reasons:

1. It is missing other libraries that your Boost build requires but that configure does not tell the link check to use.
2. You Boost build has been done with a different/incompatible mingw version and the link check fails due to unknown symbols.
3. The configure script itself cannot find a suitable file (!) to hand over to the link check. Configure itself tries to find the proper name for the Boost libraries because Boost's library names consist of various parts like architecture, multi threading on/off, version etc.

The configure checks I use have only been tested on bash/sh/zsh like shells on Linux. I haven't tested them on Windows with msys or cygwin's bash.

PS: "have you tried building boost?", yes, however not with any luck. i tried so by running bootstrap.sh etc., but it doesn't go so well, http://pastebin.com/f761baf28 (forever paste).

I wouldn't suggest building Boost on mingw yourself ;) Mostly because I haven't had much luck with it myself, at least not with my cross compilation environment.

A couple of months ago another user asked for support on building Windows builds. Back then I uploaded my ~/prog/video/mingw tree along with my self-built mingw cross compiler. Those packages won't work anymore (mingw 3.4 cross compiler didn't support Unicode, newer mkvtoolnix versions require Unicode support), but I can create a new tree and upload it along with slightly patched mingw .deb packages for Ubuntu 9.10 64bit if that would help you. It would probably not help you getting mkvtoolnix to compile on Windows with mingw, I guess, but it is a working cross compilation environment.

[whatever-ever]

Hi Mosu,
thanks a lot for the thorough answer.
I was not aware of cross compilation (besides having bumbed into it a couple of times). I'll try that out, thanks!

and thanks for the script, will help me configure it properly.

[Mosu]

If you do try to cross compile then you should be aware of a bug in the mingw runtime package for Ubuntu. I have a diff that fixes this bug available at http://www.bunkus.org/videotools/mkvtoolnix/mingw-build-tree/mingw32-runtime-snprintf.diff

Applying and compiling the package works something like this (from memory and vague, adjust file names/paths as necessary):

cd /usr/src
apt-get source mingw32-runtime
apt-get build-dep mingw32-runtime
cd mingw32-runtime-VERSION
patch -p1 < ~/mingw32-runtime-snprintf.diff
dpkg-buildpackage -b

[Mosu]

BTW: The tarball of my mingw cross compilation directory is up and available at http://www.bunkus.org/videotools/mkvtoolnix/mingw-build-tree/mkvtoolnix-mingw.tar.lzma

The file http://www.bunkus.org/videotools/mkvtoolnix/mingw-build-tree/mtx-win32-build.txt mentions a couple of things to keep in mind (it's an IRC log excerpt and not up to date but still relevant).

[whatever-ever]

Oh thanks. seems i just need to point it to some valid libiconv, other than that things seems to be in order :)

[whatever-ever]

Hmm, as soon as i switch to cross-compilation libiconv won't be found. (and yes there is libiconv in your tree, and i also tried building it myself). have i put it in a wrong place? i installed into /home/../prog/video/mingw/


UPDATE:
I got mkvtoolnix 3.10 compiled now. All credit goes to you, Mosu, as all it took was to use your tree and your zsh. The reason I failed before with iconv was that my own EXPORT commands apparently did not work the way i expected them to. Relying on your zsh it worked.

One little heads up to what you said earlier about a mingwruntime bug... I was not able to apply the patch as the file didn't exist. But before I started googling to see where I could get a source with the needed file, I got it to compile. So what I'm saying is, I did not need that patch in order to build mkvtoolnix 3.10.

Thanks again for your patience and helpful effort!

[Mosu]

I don't really have an idea, sorry.

[mikeyakame]

Any chance you guys could add the following "Add command-line options" to the next build of MKVToolnix?

--segmentinfo
--segment-uid

I have no real problem with adding them manually each time, but it'd handy to have them available in the drop down list! I've been using --segmentinfo quite a lot recently and find its amazingly useful.

Cheers for all the work on the app anyway ;)

[Mosu]

Any chance you guys could add the following "Add command-line options" to the next build of MKVToolnix?

--segmentinfo
--segment-uid

mmg 3.1.0 already contains support for --segment-uid: "global" tab, option "segment UIDs".

The following build adds an option for the segment info XML file, also on the "global" tab: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100206-214-setup.exe (still uploading)

[thetoof]

Hi,

I'm trying to figure how file linking works with mkv and I am quite puzzled. Here's what I'm trying to do:

5.1 AC3 audio / 1 file
h.264 video / 2 files with different resolution and DAR (somehow it changed in the middle of the DVD)
Subtitles

So, I need the 2 videos linked together, but since the audio is muxed with the first video segment, I can't link them as "play this file, then this one" since I lose audio this way. How would I use advanced editing to achieve what I want?

Thanks

[Mosu]

Please create a new thread for this. This is more a general Matroska & playback question, not really a mkvtoolnix question.

[RadioactiveMan]

I tried to rip a bluray and save it as mkv.
x264 gives a me .mp4 with about 4.5 GB. When muxing it with mkvtoolnix it says "everything ok" but the resulting mkv is just 17 KB in size.
What could be the error?

I want to add that I can watch the video without problems in mpchc.

[Mosu]

I don't know.

[Keiyakusha]

RadioactiveMan
I'm not sure, but I believe mp4 normally not supports such huge files. Even if it is possible to create them, maybe they need some special treatment on demuxer side... Try to do all the same steps but cut some of the movie to get small but similar file and check if it works.
EDIT: anyway if you want mkv, why you not using mkv or raw output in x264?

[Mosu]

MP4 files can have arbitrary sizes with 64bit atoms. mkvmerge supports such files & atoms.

[Mosu]

I tried to rip a bluray and save it as mkv.
x264 gives a me .mp4 with about 4.5 GB. When muxing it with mkvtoolnix it says "everything ok" but the resulting mkv is just 17 KB in size.
What could be the error?

I'd like to get to the bottom of this. Can you please tell me how you created that file (which programs in which version)? I'll try to create such a problematic file myself.

Alternatively you can upload the file to my FTP server if you have the bandwidth to spare even though it is quite huge :)

[RadioactiveMan]

I'd like to get to the bottom of this. Can you please tell me how you created that file (which programs in which version)? I'll try to create such a problematic file myself.

I have just used x264 r1416 32bit from x264.nl. Input was an avs. I fear I can't give you more information than you can see in the screenshot. It might be of interest that DsMux from haalis Splitter was able to mux it but was terrible slow (i.e. it took 30 minutes from a hdd to an sdd). Additionally the resulting file was completely out of sync. So it looks like something must have been wrong with the file.


Alternatively you can upload the file to my FTP server if you have the bandwidth to spare even though it is quite huge :)
Unfortunately I have already reencoded it directly into an mkv container and deleted all temporary files. :(

[Mosu]

I tried to reproduce it with x264 but didn't succeed. Do you still have the AVS file? If not then I guess it'll remain a mystery.

[73ChargerFan]

I was thinking, that his snapshot of the directory showed that he hadn't refreshed the view. Windows will sometimes show a small file size as it is being created, and then updates to the size are half-hazzard. Perhaps the file is in his recycle bin?

[Mosu]

Nah. mmg also shows that muxing only took three seconds. And muxing a 4 GB file in three seconds is... unrealistic :)

[73ChargerFan]

Mpc-hc will autoload all other files with the same root file name within the same directory. Perhaps it loaded the .mkv file, autoloaded the .mp4 file (thinking it was audio) and then its custom graph builder used the mp4 but ignored the mkv.

[RadioactiveMan]

I tried to reproduce it with x264 but didn't succeed. Do you still have the AVS file? If not then I guess it'll remain a mystery.

It is all deleted. Maybe I have the time at the weekend to try it again.

[Mosu]

Alright. Just shout if you get that behavior again.

[tormento]

@Mosu

Could you please, please, please (repeat ad libitum) add a feature that automatically creates a chapter list when merging some (imagine a lof of) media files?

Thanks!

[Mosu]

Please elaborate on what you're doing and what you'd need from that function.

[buzzqw]

(guessing): a chapter for every files added ?

BHH

[Mosu]

I'm pretty sure that this is not what he wants. Consider the case in which you have separate files for audio, video and subtitles. You probably don't want to have a chapter for each file in that case. Of course you could say that mkvmerge should only create chapters for the video tracks.

Next example. You have one huge source file with a video track but several separate subtitle and audio files. For which files do you create chapters in that case? The solution from the example above won't work: you'd end up with a single chapter.

mkvmerge is very flexible in how you append files and therefore it's almost impossible to guess what the user actually wants ( = for which files the user wants the chapters created).

[tormento]

Sorry, I was a bit in a hurry ;)

I am currently converting a lot of mts video from my Sony cam to single separated mkvs. I'd like to join some of them, while keeping the ability to jump from one to another.

[Mosu]

I've thought a bit about how I would have to implement this and came to the conclusion that it's way too much work. Sorry. At the moment mkvmerge requires that all chapter information is available right from the start so that it can be handled properly in all cases -- even when splitting is active.

[tormento]

I've thought a bit about how I would have to implement this and came to the conclusion that it's way too much work. Sorry.
Sigh. Sob.

Can you address me to an alternative way of creating a correct incremental chapter list, using something to get the correct time format and some program to calculate progressive time codes? I have "googled" (hating that term) but found nothing useful.

[Mosu]

Not really. Here's what I'd do:

1. Mux the whole thing without chapters.
2. Watch the resulting file; seek to the positions you want the chapters at.
3. Write down the timecodes.
4. Create chapters with those timecodes.

The timecode format is easy enough. Use short ones: HH:MM:SS (hours, minutes, seconds)

[Mosu]

Hey,

I've released mkvtoolnix v3.2.0. This release contains contains the usual mix of bug fixes and smaller enhancements.

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 3.1.0:

------------------------------------------------------------
2010-02-12 Moritz Bunkus <moritz@bunkus.org>

* Released v3.2.0.
* Build requirements changed: The GUIs for mkvtoolnix now require wxWidgets 2.8.0 or newer.

2010-02-11 Moritz Bunkus <moritz@bunkus.org>
* mmg, mkvpropedit: Fixed another bug causing a crash writing chapters/other elements to existing Matroska files.

2010-02-10 Moritz Bunkus <moritz@bunkus.org>
* Build system: bug fix: Improved detection of Boost::Filesystem for newer Boost versions.

2010-02-09 Moritz Bunkus <moritz@bunkus.org>
* docs: Added a Chinese Simplified translation for the man pages by Dean Lee (see AUTHORS).

2010-02-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Outputting error messages about invalid XML files will not cause mkvmerge to crash on Windows anymore.
* mmg: enhancement: Added an input field for the segment info XML file (mkvmerge's "--segmentinfo" option) on the "global" tab.

2010-02-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The jobs will be saved in the 'mkvtoolnix/jobs' sub-directory of the 'application data' folder instead of the 'jobs' folder in the current directory. On Windows this is the special 'application data' folder inside the user's profile directory, e.g. 'C:\Users\mbunkus\AppData\mkvtoolnix'. On non-Windows systems this is the folder '.mkvtoolnix' in the user's home directory. mmg's configuration file has also been moved from ~/.mkvmergeGUI to ~/.mkvtoolnix/config on non-Windows systems. Fix for bug 466.

2010-01-28 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Files are only opened for reading, not for writing, so that mkvextract will work on files the user only has read-only permissions for.
* mkvextract: bug fix: Modes 'attachments', 'chapters', 'tags' and 'cuesheet': mkvextract will output an error message if the file cannot be opened (e.g. because it does not exist or due to lack of access).

2010-01-24 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Changing the interface language does not require a restart anymore.
* mkvmerge: bug fix: Reading VOB files bigger than 4 GB was broken in v3.1.0 on 32bit platforms.

2010-01-22 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Tooltips were not word-wrapped on Windows.
* mkvinfo: enhancement: Added the "EBML maximum size length" element to the list of known elements. Fix for bug 464.

2010-01-20 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added a control for mkvmerge's "--cropping" parameter.
* mmg: enhancement: Added the file extensions ".dtshd", ".dts-hd", ".truehd" and ".true-hd" to mmg's"'add/append file" dialogs.
* mkvextract: bug fix: "mkvextract --version" was only writing an empty string. Fix for bug 463.
------------------------------------------------------------

Have fun.

[coastline]

Hi,

Not sure if this is the right place to ask this so if not please accept my apologies.

I want to take an MKV of a Bluray made using MakeMKV and add the colour flags for BT.709 (I don't want to make any other changes):

colour_description_present_flag : 1
colour_primaries : 1
transfer_characteristics : 1
matrix_coefficients : 1

I think this is possible using MKVmerge but I have no idea where to start.

I have little to no experience with mkvtoolnix so be gentle with me please :-)

Many thanks for any help with this.

[Mosu]

Those seem to be codec parameters (I don't know them) and have nothing to do with the Matroska container. mkvmerge cannot help you with that.

[coastline]

Thanks

[renqian]

i use the 3.2.0 mux .thd+ac3 to mkv. but it seems not contained the ac3 core. and the TSmuxer can't recognise the truehd track.
and i mux .thd+ac3 to mka. and the mka size is not as the same as the original
and when i play it,ffdshow is well . Arcsoft TMT can't play sound.
so my question is . did the mkvtoolnix abandoned the ac3 core when it muxing ? can i mux the the full track (truehd+ac3) to mkv?

[Mosu]

mkvmerge discards AC3 cores in TrueHD tracks, yes. No, that won't change anytime soon (if at all).

[renqian]

thanks for your reply
so mmg discards ac3 core ,did it broke the TrueHD's integrality?
the ac3 core is not necessary for truehd?

[Mosu]

As far as I understand the AC3 core is only present so that decoders that don't support TrueHD can play back _something_ from such a track. TrueHD is a lossless compression format, therefore the AC3 part is redundant if the decoder supports TrueHD.

[renqian]

yes. it can playback well with ffdshow. but it not compatible with Blu-ray format without ac3 track.
thanks for your answer and one more question
when i mux the *.thd to mka file. i found the mka file's size is bigger than .thd file . why?

[Mosu]

Because along with the actual TrueHD data there are the bytes that make up the Matroska container itself.

[Foofaraw]

Is there a newer (or other) gui that MKVextractGUI 1.6.4.1 ? It doesn't seem to support everything.

[sneaker_ger]

MKVcleaver (http://forum.doom9.org/showthread.php?t=152108)

[Foofaraw]

Thanks sneaker_ger!

Now if only I can figure out why the WDTVLive has problems with some mkv's depending on what created them and which xml files are in it....

[jeremy33]

there is a bug when we try to mux and .mp4 video.

[73ChargerFan]

there is a bug when we try to mux and .mp4 video.
You can try the following:

1. Anything that mosu asks you to do. :)

2. Rename the .mkv file you made and play it again.

3. Try muxing using an earlier version of mkvtoolnix.

4. Try muxing using GDSmux, included within the Haali Media Splitter package.

5. Use Mediainfo on each file, select text mode, and post the results here.

[jeremy33]

I just demux my file with tsmuxer and it worked.

My file was created with the latest megui 0.3.4.2 and x264 1442.

[Mosu]

there is a bug when we try to mux and .mp4 video.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.2.0-build20100226-219-setup.exe

[jeremy33]

Thanks.

I'll try that.

[fingershop]

Is there a way to get the sizes (in Bytes or MB or whatever) of all the tracks in an mkv file? or for specific tracks?

Thanks

[Mosu]

Not with one of the programs from mkvtoolnix -- at least not without external scripting around mkvinfo's output.

[fingershop]

Thanks. I saved the output of mkvinfo to a file, imported it into Excel, and got the total sizes of each track. Oddly, it may be just as quick to use mkvextract to see those track sizes directly.

[sneaker_ger]

You could also use AVIMUX Gui for that, it will the show the size of each video and audio track in MBytes (one decimal).

[Mosu]

Thanks. I saved the output of mkvinfo to a file, imported it into Excel, and got the total sizes of each track. Oddly, it may be just as quick to use mkvextract to see those track sizes directly.

Both mkvinfo and mkvextract have to parse the whole file (as does AVIMuxGUI btw) in order to get the track sizes as there's no header field for this information in Matroska files.

[[)370|\|470!2]

Just wondering if there's a way to make this crappy app to respect splitting filesize. 4499 MB instead of 4475 huh? If it's not too much to ask.

[Inspector.Gadget]

I'm convinced "[)370|\|470!2" doesn't actually know what the word "crap" means, or else he wouldn't use it to describe the most popular and feature-rich Matroska muxing application in the world.

[nurbs]

He also doesn't seem to know that you can't split (most) video files in arbitrary places.

[Mosu]

He also doesn't know that asking nicely and politely is usually the best way to get good answers.

[[)370|\|470!2]

C'mon, the question was corny, thought it'd be obvious. This bug/feature/whatever that is that sits in there - for how long... forever? Which means that author has no intention to look into it really. Oh, and yet another good reason for me to stay away from this app and quit giving it a try, which would've prevent me from wasting two hours for nothing today, thanks for asking.

Sorry if it was too sincere/not polite enough.

[MatLz]

Instead of continue to troll, you should ask 'why?'. Maybe the discussion would be more constructive...

[Inspector.Gadget]

Oh, and yet another good reason for me to stay away from this app and quit giving it a try, which would've prevent me from wasting two hours for nothing today, thanks for asking.

I think I speak for everyone when I say that software developers' time is so much more valuable than the time of some forum troll that we haven't yet invented the numerical order of magnitude with which to express it. Hope this helps.

[fingershop]

You could also use AVIMUX Gui for that, it will the show the size of each video and audio track in MBytes (one decimal).

Thanks, I just tried that, and it does give you the track sizes in just a few seconds.

However, some of the track sizes are way off, by a factor of 17 in some cases, depending on the file you're checking. At that accuracy level I may as well just make my own guess :-)

[falexak]

Thank you very much for the news, I have been using MkvToolnix for a long time.

[Chumbo]

Just wondering if there's a way to make this crappy app to respect splitting filesize. 4499 MB instead of 4475 huh? If it's not too much to ask.
No one's forcing you to use this tool. You can always write your own to do exactly what you want. Maybe walking an inch in developers shoes would shed some light in that dark space between...[I better stop before I get banned ;)].

Every software has bugs and limitations and developers appreciate help when its done constructively. What exactly have you contributed to make this a better tool and discussion? Please we're all ears...but I guess so are trolls.

[[)370|\|470!2]

That's amazingly funny how fast someone starts hollering "troll" just as they smell a tiny bit of criticism airborne. Oh, and also there's a very nice remark once made by B. Shaw: “Although I cannot lay an egg, I am a very good judge of omelettes”. :rolleyes:

And to conclude, since no one have added nor brought anything constructive conserning subject to shed a light on it, i'd assume there's nothing else remains to discuss.

[nurbs]

I told you the likely cause of why it doesn't split exactly where you want. It probably gave you 4475 MB because the next possible split point would have resulted in a size bigger than 4499 MB. Without telling anything about the file there is no way to know for sure of course.
Also you should try being polite to people sometimes. Maybe then people would be more inclined to spend their spare time helping you with your problems even though they have no obligation to to so.

[liquidskin76]

mkvmerge discards AC3 cores in TrueHD tracks, yes. No, that won't change anytime soon (if at all).

Hi Mosu,

You're sort of right in saying that with ffdshow you can either bitstream truehd or decode it to lpcm, so why would you need the ac3 core.

One thing though... how does that relate if you're using spdif for instance? I didn't think spdif could handle the bandwidth of truehd decoded to lpcm, hence the need for hdmi?

I'd love the ability to include the ac3 core as an automatic fallback (without having to select another audio track).

Thanks!

[Mosu]

No, sorry.

[rica]

mkvmerge discards AC3 cores in TrueHD tracks, yes. No, that won't change anytime soon (if at all).


The command line which i gave before creates a thd+ac3 file.
And i can watch the mkv (created by mkvmerge gui 3.2.0) with ac3 or with thd.
Disabling thd passthrough and enabling ac3 SPDIF encode mode in ffdshow must fix your issue. (you'll get ac3 in this case)
Enabling thd passthrough will bring thd bitstreaming back.


Dunno mossu how i get ac3 or THD separately???


_ _ _ _ _ _

[Mosu]

Dunno mossu how i get ac3 or THD separately???

Not with mkvmerge. mkvmerge will always discard the AC3 core of a THD+AC3 file/track.

However, often a disc containing a THD+AC3 as a single track also contains another AC3 track, and you can use that as input as well.

[turbojet]

I see demuxing pgs is supported now, thanks, any news on muxing pgs?

[Mosu]

I see demuxing pgs is supported now, thanks, any news on muxing pgs?

Partially. You can re-mux PGS tracks from one Matroska file to another (mkvmerge will use its general purpose "pass-through" packetizer), but you cannot mux it from PGS elementary streams. It's also not on the agenda just yet.

[Mosu]

This is a mkvtoolnix support thread, not a MakeMKV or "playback on hardware players" support thread. Please create a new one for such a question.

One thing to look into: indexes (called "cues" in Matroska terms). mkvmerge always writes them, maybe makemkv doesn't or doesn't reference them from metaseek elements.

[sheck]

Mosu, in this release I noticed you added --parse-fully switch to mkvextract.exe. What does it add to the functionality ? I tried using it, but results seem to be the same as when not using it.

[Mosu]

Quoting the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvpropedit.html) (both mkvextract and mkvpropedit know this parameter under different names but it seems I've only added it to mkvextract's man page):

-p, --parse-mode mode
Sets the parse mode. The parameter 'mode' can either be 'fast' (which is also the default) or 'full'. The 'fast' mode does not parse the whole file but uses the meta seek elements for locating the required elements of a source file. In 99% of all cases this is enough. But for files that do not contain meta seek elements or which are damaged the user might have to se the 'full' parse mode. A full scan of a file can take a couple of minutes while a fast scan only takes seconds.

Getting a bit more technical:

The 'full' parse mode starts at the beginning of the file and finds all level 1 Matroska elements. These are e.g. 'meta seek', 'cues', 'chapters', 'track headers' and most important 'clusters'. For each level 1 element it reads the ID and the size but not necessarily its content -- only if it has to (for the track headers, the rest depends on the extraction mode/editing mode). However, reading all cluster IDs and sizes takes quite a lot of time as there are a lot of clusters over the whole file.

BTW: The programs will fall back to 'full' if no index is found and 'fast' mode is selected.

[Foofaraw]

At the risk of upsetting someone, mkvtoolnix does not function in isolation - it produces data from or for other products and as such one has to mention other things than mkvtoolnix... (if English is not your first langauge, let me underline this is not an attack or critique of mkvtoolnix)

So my question is in relation to mkvtoolnix.... (so please read it twice)

ProgramA outputs an mkv - we'll call it mkvA

If I now play mkvA in deviceB it has certain defects.

I now take mkvA and 'add' it to Mkvmerge Gui - uncheck a few items in MkvMerge Gui and output mkvB

If I now play mkvB it takes a while to play, but then it plays fine.

BUT

If I take Mkvcleave and extract all items from mkvA

And I then only add the items required to Mkvmerge GUI and output mkvC

Then mkvC starts playing fine right away.


So the question about Mkvmerge gui/mkvtoolnix is:

why is there a difference between mkvB and mkvC - they both contain the same(3) items - we just arrived at the content differently.

Does mkvmerge gui reuse the parts of the container (but not the contents) when you start out by using an existing mkv??? I would have thought it authored from scratch so there shouldn't be a difference? (But there is)

[73ChargerFan]

Ah... output files mkvB & mkvC are different just enough, so that they behave differently when played.

I've encountered something similar. I can have three non-identical copies of a video track (demuxed from .TS, or demuxed from .M2TS using eac3to, or extracted from .M2TS into .MKV using eac3to) and mkvmerge will accept all three tracks. But the output .MKV files don't play back identically in mpc-hc.

In my mind, Audio+Video->MKV should work no matter where I get the source files, but that isn't always the case. I don't have any samples handy now, however.

[Foofaraw]

In my mind, Audio+Video->MKV should work no matter where I get the source files, but that isn't always the case. I don't have any samples handy now, however.

Yeah, in my mind i agree with you. But perhaps there is something we don't know :-/

[Mosu]

Summarizing Foofaraw's question:

A.mkv -> (mkvmerge) -> B.mkv is different from A.mkv -> (mkvcleaver) -> elemental_streams.h264/.ac3/.mp3 -> (mkvmerge) -> B.mkv

mkvmerge has different paths for the same content depending on where they come from. You guessed as much from the evidence. There are several reasons for this, amongst them are:

1. It tries to re-use as much information as possible as can be retrieved from the source container. If you have a h.264 track inside a Matroska file then you have a lot more meta-information about it that you do when it is stored outside of a container as an elementary stream. Information that is reused includes but is not limited to the timestamps, track parameters like display width/height, track name, language etc etc.

2. What is not so obvious is that mkvmerge also reuses the framing. If you have a raw track type like MP3, AC3, AAC or h.264 elementary streams then mkvmerge has to determine how many bytes of the track to put into each Matroska block (also called 'frame' sometimes even though a Matroska block does not necessarily contain exactly one 'frame' in the way people think of frames). This process is usually called framing and has to be done by any raw -> container converter. If a track is stored inside a Matroska file then mkvmerge sometimes skips this process and takes the input file's framing -- one Matroska block in, one Matroska block out.

3. Another important thing to remember is that raw tracks outside of a Matroska file are not simply the concatenation of all the contents of all Matroska blocks. This is the case for some very simple track types (e.g. MP3, AC3, AAC, DTS) but for most others it isn't, especially for video track types like h.264. Elementary streams often contain special framing markers (think of '00 00 01' prefixes for MPEG-1/2 or '00 00 00 01' for h.264). Also some parts of the stream are not put into Matroska blocks but into the CodecPrivate element (e.g. SPS/PPS NALUs in h.264 tracks). The CodecPrivate almost always has some special kind of storage format that is always different than how that information is stored in an elementary stream. mkvextract and mkvmerge convert this data from one form into the other and back again. In the case of direct mkv -> mkv conversion the CodecPrivate element is kept as-is.

4. There are muxers out there that create invalid Matroska files. For example there are files with the CodecID V_MPEG4/ISO/AVC (h.264 video) that contain the elementary stream 1:1 including the '00 00 00 01' prefixes in each Matroska block. They also don't have a CodecPrivate element but store the SPS/PPS NALUs inside the first Matroska block. This not only violates the specs it is also incompatible with most playback software out there. So mkvmerge has yet another processing path for such tracks.

There are more cases, but I guess you get the drift. It is not possible to switch this behavior in mkvmerge -- it is hard coded for each and every combination of track type and source file format (and even for the same tuple "container & track format" there may be different paths as 4. illustrates).

[Foofaraw]

Thank you for the explanation Mosu.

I'm still fairly new to the mkv format (coming rather late to the party!)

Would you say its a good format for streaming video? (Via media players, not the internet)

Reason I'm wondering is because someone said we can't see how long tracks are but you have to scan the entire file to figure it out (i would have thought there was a header somewhere).

[Foofaraw]

Two questions about frames.

Is there an easy way to convert celltimes.txt (a list of frames) to a format mmg understands?

and; you explain about OGM style chapter files

"Due to its limitations mmg cannot output chapters in this format."

What does that mean? mmg won't put them in a mkv file but converts it to xml first?

[Mosu]

Two questions about frames.

Is there an easy way to convert celltimes.txt (a list of frames) to a format mmg understands?

Not with mkvtoolnix per se, but if it's a plain text format then it should be easy to write scripts in whatever scripting language you like (Perl, Python, Ruby, awk...) to convert such files.

and; you explain about OGM style chapter files

"Due to its limitations mmg cannot output chapters in this format."

What does that mean? mmg won't put them in a mkv file but converts it to xml first?

There are two text chapter formats, OGM style and XML files. OGM style files can only store the start timestamp and the name of each chapter, and chapters cannot be nested. The XML file format can contain many more attributes (end timestamp, editions etc) and chapters can be nested.

Therefore mmg will not save to OGM style chapter files -- too much information is lost. It can either save a XML text file for further processing or it can save directly into an existing Matroska file. In both cases no information is lost.

[Mosu]

Would you say its a good format for streaming video? (Via media players, not the internet)

Depends on your definition of "streaming" and the type of media player in question. I'm using an Asus O!Play myself and play my files back from a network share. Some people call that streaming. Works flawlessly.

Reason I'm wondering is because someone said we can't see how long tracks are but you have to scan the entire file to figure it out (i would have thought there was a header somewhere).

True, but no player should have to know the length of any track in order to play back a file. MP4 is no better in this regard than Matroska: Either it's "true" streaming (meaning the player cannot seek in the file it reads -- in that case neither format usually has information about total length available) or it's a seekable file (in which cases a player can get the total length from both file types, the methods are just different).

[Foofaraw]

Not with mkvtoolnix per se, but if it's a plain text format then it should be easy to write scripts in whatever scripting language you like (Perl, Python, Ruby, awk...) to convert such files.


Its a text files with a frame number pr line like:
7620
15175
22495
29996
37502
45019
52520

Made by PgcDemux

[liquidator87]

If I may ask... when will you make a repository for Lucid available?

[Mosu]

Certainly not before it's released. I'm busy enough without chasing after betas. "In April" is probably accurate :)

[Mosu]

Additionally you can easily compile the packages yourself; see http://www.bunkus.org/videotools/mkvtoolnix/source.html#debian_ubuntu_package

[liquidator87]

Wow... It took me... like... 10 seconds to build the package... eheh thanks

[Mosu]

Hey,

I've released mkvtoolnix v3.3.0. This release contains contains several important bug fixes and a few new features. Behind the scenes huge parts of the code have seen adjustments, especially the order and amount of included header files. I've gone to great lengths to ensure everything compiles as usual on several platforms and versions but be prepared for compiler errors if you compile the package yourself.

There are no changes that package maintainers have to look out for.

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 3.2.0:

------------------------------------------------------------
2010-03-24 Moritz Bunkus <moritz@bunkus.org>
* Released v3.3.0.
* Build system: Sped up builds by using pre-compiled headers. Patches by Steve Lhomme (see AUTHORS) and myself.

2010-03-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the default duration for interlaced MPEG-1/2 video tracks. Also added the 'interlaced' flag for such tracks. Patches by Xavier Duret (see AUTHORS). Fix for bug 479.

2010-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Specifying a FourCC with spaces at the end will not result in an error anymore. Fix for bug 480.

2010-03-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Timecodes for MPEG-1/2 tracks are calculated properly, especially for B frames. Patch by Xavier Duret (see AUTHORS). Fix for bug 475.

2010-03-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Added a message in verbosity level 2 to the splitting code. It reports before which timecode and after what file size a new file is started.
* All: A lot of changes preparing mkvtoolnix for use with the upcoming libebml2/libmatroska2 versions were applied. Patches by Steve Lhomme (see AUTHORS).

2010-03-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a crash when reading Matroska files that contain Vorbis audio with in MS compatibility mode (CodecID A_MS/ACM). Fix for bug 477.
* All: enhancement: Added support for old Mac-style line endings (only '\r' without '\n') in text files.

2010-03-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added the values "4483M" and "8142M" to the "split after this size" drop down box.

2010-03-06 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed compilation if gettext is not available.

2010-03-03 Moritz Bunkus <moritz@bunkus.org>
* Build system: Added project files and fixes for compilation with Microsoft Visual Studio 8. Patches by David Player (see AUTHORS).
* Installer: bug fix: A couple of start menu links to pieces of the documentation were broken. Added missing start menu links to translations of the documentation.
* mkvmerge: bug fix: The SRT reader skips empty lines at the beginning of the file.

2010-03-02 Moritz Bunkus <moritz@bunkus.org>
* Build system: bug fix: Fixed the configure script and compilation on OpenSolaris.

2010-02-26 Moritz Bunkus <moritz@bunkus.org>
* Installer: bug fix: The "jobs" directory in the application data folder is removed during uninstallation if the user requests it. Fix for bug 474.
* mkvextract: bug fix: Fixed granulepos calculation when extracting Vorbis tracks into Ogg files. Fix for bug 473.

2010-02-24 Moritz Bunkus <moritz@bunkus.org>
* All: bug fix: The programs will no longer abort with an error message if a selected interface translation is not available. The "C" locale is used instead. Fix for bug 472.

2010-02-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: enhancement: Improved the error resilience when dealing with damaged Matroska files. When a damaged part is encountered reading will continue at the next cluster.

2010-02-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the handling of UTF-16 encoded chapter names in MP4/MOV files.

2010-02-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Some Matroska files contain h.264/AVC tracks lacking their CodecPrivate element (e.g. files created by gstreamer's muxer). For such tracks the CodecPrivate element (the AVCC) is re-created from the bitstream. Fix for bug 470.
* mkvmerge: bug fix: MP4 files that do contain edit lists but whose edit lists do not span the entire file are processed properly. Such files are created by current x264 builds. Fix for bug 469.

2010-02-13 Moritz Bunkus <moritz@bunkus.org>
* Build system: Fixed configure for systems on which 'echo' does not support the '-n' parameter (e.g. Mac OS).
------------------------------------------------------------

Have fun.

[b66pak]

thanks...
_

[Liisachan]

@Mosu
A minor thing: sha1sums.txt in http://www.bunkus.org/videotools/mkvtoolnix/win32/ is too old
and not helpful. Ty :)

[lych_necross]

I love mkvtoolnix! Thanks Mosu et al. for the update! :D

[kurt]

after installation v3.3.0 windows 7 (prof) complains that the program was probably not properly installed. anybody had the same issue?

[73ChargerFan]

Confirmed. Windows 7x64 doesn't like the new installer; I got a UAC shield on the install app immediately after download. Gui app is fine.

[asc28]

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.

Perhaps, it's mistaking it for pure interlaced? Any ideas?

FYI Remuxing an older mkv file with the newer version is fine, as it doesn't re-create the timecodes.

[Mosu]

@Mosu
A minor thing: sha1sums.txt in http://www.bunkus.org/videotools/mkvtoolnix/win32/ is too old
and not helpful. Ty :)

Dang. Thanks for noticing. I've updated the file.

[Mosu]

after installation v3.3.0 windows 7 (prof) complains that the program was probably not properly installed. anybody had the same issue?

Can't reproduce. I'm using Win7 Professional 64bit myself. My user doesn't have admin privileges.

So what I'm seeing is:

1. Download finishes.
2. I start the setup.exe, UAC kicks in and asks me for the administrator's password.
3. Setup starts. I answer all questions with the default answer.
4. The installer finishes, closes normally, everything's done.

So please give me more details about your system, the user you're running the setup under, any options you chose differently than I did etc etc etc.

[Mosu]

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]

Confirmed. Windows 7x64 doesn't like the new installer; I got a UAC shield on the install app immediately after download. Gui app is fine.

??? I don't understand your problem. The installer requires admin privileges, so I don't see why the UAC coming up should be considered "does not work".

[Mosu]

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.

Can you please upload a source file for me for testing purposes? It doesn't have to be the whole file, but it should be long enough that the speed problem becomes obvious. You can upload to my FTP server (see my signature).

Also I need some more information:

1. Which program did you use for extracting the MPEG2 from the DVD? Do you mux the .VOB file directly with mkvmerge or has the video been extracted to separate MPEG2 elementary or program streams?

2. Which program do you use for playback? We know that older versions of ffmpeg (and therefore ffdshow) contain a bug that causes it to play video too slow or too fast.

3. "Video speed is not in sync" -- do you mean that the video plays slower/faster than the accompanying audio track?

[dragoncat852]

??? I don't understand your problem. The installer requires admin privileges, so I don't see why the UAC coming up should be considered "does not work".

same situation as 73ChargerFan under win7 x64, I just uninstall it then dl .7z and unzip it works fine
the old MKVExtract GUI1.6.4.1 with 3.3.0 seems got some progress bar problem, it show nothing then done but demuxed sucessfully
anyway, thx for the update and cheers:p

[asc28]

Can you please upload a source file for me for testing purposes? It doesn't have to be the whole file, but it should be long enough that the speed problem becomes obvious. You can upload to my FTP server (see my signature).

Also I need some more information:

1. Which program did you use for extracting the MPEG2 from the DVD? Do you mux the .VOB file directly with mkvmerge or has the video been extracted to separate MPEG2 elementary or program streams?

2. Which program do you use for playback? We know that older versions of ffmpeg (and therefore ffdshow) contain a bug that causes it to play video too slow or too fast.

3. "Video speed is not in sync" -- do you mean that the video plays slower/faster than the accompanying audio track?Uploaded a sample to ftp (sample.mkv). It was muxed by 3.2.0 and plays at the correct speed. Demux the streams and remux with 3.3.0 to see the change.

Did some more testing and it appears the problem happens with tracks demuxed with PGCDemux, but not with DVDDecrypter. Unfortunately, PGCDemux is the new de facto standard since it does sup subtitles and more "proper" handling on cutpoints. Here's a word about the differences between the files they produce, which might be of help:PGCDemux calculates the delay properly for remultiplexing the audio and video directly, or with the newer avisynth programs. DVDDecrypter and SmartRipper calculate the delay for the old dvd2avi which dropped video frames.
The vidoe bytes that are different are probably the gop timecode. Since there are no fixed offsets in mpg that's only a guess. Look for the header preceeding the bytes that are different, it will be 00 00 01 xx - the xx will tell you what header you are looking at. B8 is the gop header, which contains a timecode. Some rippers give you the option to reset the timecode to start at 00:00:00.00from this thread: http://forum.doom9.org/showthread.php?t=84778

1. PGCDemux, Elementary stream m2v
2. Tested MPC-HC's built-in decoder, ffdshow, DScaler's decoder, Microsoft's decoder. Splitter is latest Haali's
3. Speed is faster, duration is shorter. For example, a 23:04 file shows up as 19:39.

[renqian]

i using 3.3.0 to mux Truehd is too slow. HD speed is less than 15M/S
i use eac3to to extract the thd file .

[Mosu]

One of mkvtoolnix' disadvantages is that is is rather slow, yes. No, that will most likely not be addressed in the near future. My priorities are usually correctness & features, not speed.

[Abradoks]

Hi, Mosu.
Currently GUI parameter "Stretch by" is an alias for --sync. And as far as I understand both of them modify "Track: DefaultDuration" which seems to be somewhat hackish.
Why not to use TrackTimeCodeScale (http://www.matroska.org/technical/specs/notes.html#TrackTimecodeScale) instead?

[Mosu]

Hi, Mosu.
Currently GUI parameter "Stretch by" is an alias for --sync.

Correct.

And as far as I understand both of them modify "Track: DefaultDuration" which seems to be somewhat hackish.

They don't modify any header value, they just modify the timestamps of each packet. This is the most compatible method.

Why not to use TrackTimeCodeScale (http://www.matroska.org/technical/specs/notes.html#TrackTimecodeScale) instead?

Because not every player supports that element (unfortunately).

[Abradoks]

They don't modify any header value, they just modify the timestamps of each packet.
Actually they do both. It changes "Track: DefaultDuration" which shouldn't be done for such purposes. Because for audio you have fixed frame duration according to codec used. Also, after muxing you can't easily detect if --sync was used.
Because not every player supports that element (unfortunately).
Current method works (in different ways) with Gabest and Haali splitter and with ffplay. It doesn't work with mplayer and VLC.

Actually, it works with VLC just as it should. VLC respects timecodecs and tries to add silence/cut audio respectively (I haven't looked at sources, so it's just a guess from user point). Other splitters detect difference between "Track: DefaultDuration" and real audio frame duration and modify timecodes. But it's the way, how TrackTimeCodeScale should work:
It would also be possible to adjust the video to match the audio's speed. However, for playback, the only thing that should be counted on is the selected track(s) timecodes being adjusted if they need to be scaled.

I don't think things going to change until you make the first move in mkvmerge. Currently --sync is not usable for a/v sync as it only works with limited number of splitters (those which use hack to make it work).

[Mosu]

I don't think things going to change until you make the first move in mkvmerge. Currently --sync is not usable for a/v sync as it only works with limited number of splitters (those which use hack to make it work).

It sure it, you just shouldn't use it on audio tracks. You can easily use it on video or subtitle tracks though. Using TrackTimecodeScale for audio tracks doesn't improve the situation by much because you still have the problem that there are more or less actual samples than fit the timecodes of the packets.

So no, I won't change that.

[Mosu]

I don't think things going to change until you make the first move in mkvmerge. Currently --sync is not usable for a/v sync as it only works with limited number of splitters (those which use hack to make it work).

It sure is, you just shouldn't use it on audio tracks. You can easily use it on video or subtitle tracks though. Using TrackTimecodeScale for audio tracks doesn't improve the situation by much because you still have the problem that there are more or less actual samples than fit the timecodes of the packets.

So no, I won't change that.

[Abradoks]

It sure is, you just shouldn't use it on audio tracks. You can easily use it on video or subtitle tracks though.
Well, mkvmerge allows it to be used on audio tracks.
Using TrackTimecodeScale for audio tracks doesn't improve the situation by much because you still have the problem that there are more or less actual samples than fit the timecodes of the packets.
TrackTimecodeScale was created specifically for synchronisation of different tracks, wasn't it? As I understand, it allows modifying video/subtitle timecodes instead of resampling audio. So, if you agree that current method isn't suitable for audio, why not to use the proper one?
So no, I won't change that.
That's a pity. I'm not trying to force you to change it, but I still don't understand the reason.

[Mosu]

Well, mkvmerge allows it to be used on audio tracks.

True, because I don't want to limit the user in what he can or cannot do.

TrackTimecodeScale was created specifically for synchronisation of different tracks, wasn't it? As I understand, it allows modifying video/subtitle timecodes instead of resampling audio. So, if you agree that current method isn't suitable for audio, why not to use the proper one?

Because it wouldn't improve anything. You can use the current --sync method for video and subtitle tracks. You could use TrackTimecodeScale the same way for video and subtitle tracks. However, using TrackTimecodeScale on audio tracks would result in the same problems that using the current --sync method on audio track has. There's not much (if anything at all) to be gained.

[Mosu]

Ok, there is something to be gained. Playback applications could activate actual audio resampling. However, as I said before, this is not implemented at the moment. Yes, it's a "chicken vs egg" problem. No, I will still not do it; mostly because I don't want to spend the time on implementing this in a backwards compatible manner.

[Mosu]

Playback applications could activate actual audio resampling.

I take that back. The TrackTimecodeScale parameter explicitly only adds another multiplier for the timecodes. Its semantics do not imply that a track should be resampled in any way. So in order to find out whether or not the track has to be resampled the decoder would have to read a couple of packets, get their timecodes, compare the timecodes to the number of samples in respect to the sampling rate etc etc. This would all be guesswork and not be very precise.

[Abradoks]

True, because I don't want to limit the user in what he can or cannot do.
But it's completely not suitable for audio. Modifying audio frame duration is just wrong and it has nothing to do with the name of the option used for it.
Because it wouldn't improve anything. You can use the current --sync method for video and subtitle tracks.
There is already --default-duration for it.
You could use TrackTimecodeScale the same way for video and subtitle tracks.
Is there such option in mkvmerge or in mmg?
However, using TrackTimecodeScale on audio tracks would result in the same problems that using the current --sync method on audio track has. There's not much (if anything at all) to be gained.
Well, TrackTimecodeScale modifies only specific header parameter and not the whole timecodes. It doesn't require audio resampling. It's easy to recognize if this parameter was used. TrackTimecodeScale was designed for sync, it doesn't produce weird audio tracks and doesn't require to break spec compliance for proper playback. So the only problem is lack of support, which is partially caused by mkvmerge using some hack instead of this parameter.
I don't want to spend the time on implementing this in a backwards compatible manner.
What do you mean by "backwards compatible"? Yes, current --sync looks just like an alias for this parameter, and it would be better to change it's behavior. But you can add something like --TrackTimecodeScale instead and leave --sync unchanged.
So in order to find out whether or not the track has to be resampled the decoder would have to read a couple of packets, get their timecodes, compare the timecodes to the number of samples in respect to the sampling rate etc etc. This would all be guesswork and not be very precise.
Not at all. If player doesn't want to resample, then it just modifies timecodes of other streams to keep in sync. That's what some splitters do with current method.

[Mosu]

There is already --default-duration for it.

No. --default-duration only sets the default duration parameter. The default duration is used if no timecode information is provided by the source (which is rare, e.g. raw h264 streams). Other than that --default-duration does not modify timecodes at all.

Is there such option in mkvmerge or in mmg?

No.

What do you mean by "backwards compatible"? Yes, current --sync looks just like an alias for this parameter, and it would be better to change it's behavior.

No.

But you can add something like --TrackTimecodeScale instead and leave --sync unchanged.

That's exactly what I won't do due to limited free time. For proper support this would mean adding the parameter do mkvmerge, documenting it in the man page, in mkvmerge's help text, adding a control in mmg, adding the tooltip for it, translating all of the help texts into German (that's the one language I'm translating into myself). It's not done in merely five minutes, you know.

Patches are always welcome.

Not at all. If player doesn't want to resample, then it just modifies timecodes of other streams to keep in sync. That's what some splitters do with current method.

That only works if only a single track has that parameter set. What if you have three tracks (audio, video, subtitles) and both the audio and subtitle track have different TrackTimecodeScale values set?

Anyway, like I said, I won't do this _myself_.

[Abradoks]

No. --default-duration only sets the default duration parameter. The default duration is used if no timecode information is provided by the source (which is rare, e.g. raw h264 streams). Other than that --default-duration does not modify timecodes at all.
Oh, so. Than you should correct docs:
Forces the default duration of a given track to the specified value. Also modifies the track's timecodes to match the default duration.

Patches are always welcome.
That's much better answer than "I won't change that".

That only works if only a single track has that parameter set. What if you have three tracks (audio, video, subtitles) and both the audio and subtitle track have different TrackTimecodeScale values set?
It's pretty simple. Only audio timecodes are hard to change, so player multiples every active track's timecodes by (Own_TrackTimecodeScale/Audio_TrackTimecodeScale). For audio it will always be "1".

[Mosu]

That's much better answer than "I won't change that".

On this forum this usually amounts to the same as there are almost no developers here that are interested in helping out. I'm always open to patches.

[lamer_de]

There's quite an important bug in the header editor: When you try to edit a file that was generated with Haali's DS Muxer, both the cli mkvpropedit as well as the GUI in mmg crash with a cpp error:

Assertion failed: CheckMandatory(), file ../../src/EbmlMaster.cpp, line 138

Happens every time, content of the files doesn't matter. Seems the way the 2 programs create their headers is differently.

[Mosu]

Which mkvtoolnix version are you using?

[lamer_de]

Oh, sorry: mkvtoolnix 3.3.0 from 24.03.10, WinXP 32bit, Haali gDsMux from 14.11.2009 (hm, maybe I should update that). EDIT: After updating Haali to the 27/03/2010 version, the error still occurs.

However, I found a case where it's not crashing: WMV1 video + wma2/divx audio. Files with MPEG4-ASP+MP3 crash, so do files with H264+AC-3 5.1 and MPEG4-ASP+WMA9 audio.

[Mosu]

However, I found a case where it's not crashing: WMV1 video + wma2/divx audio. Files with MPEG4-ASP+MP3 crash, so do files with H264+AC-3 5.1 and MPEG4-ASP+WMA9 audio.

I cannot reproduce the problem here, but I don't doubt there is such a problem. Can you please upload a file for which the header editor and/or mkvpropedit crashes to my FTP server, please (see signature)? What I need is the original file before it is modified by the header editor.

[lamer_de]

I did upload a small sample of 3 sec of a BBC HD cap in .ts format with H264+AC3 as well as the with haali gdsmuxer remuxed mkv to your ftp. When I try to edit the header of the mkv file (for example change the name of the video track), the crash occurs. Files are called crashes_header_editor.mkv / crashes_header_editor_original.ts

[Mosu]

Thanks for the upload. The problem has been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.3.0-build20100412-230-setup.exe

[sl1pkn07]

is possible create GUI like mkvinfo/mmg for mkvextract natively and multiplataform?

[Mosu]

Of course it is technically possible, but I will never create such a GUI myself.

[smok3]

great release as usual,

some questions:
a. in the spliting section the gui says something like 'split AFTER timecodes', but the split points are actually done BEFORE TC, whats that about? :)

slightly offtopic;
b. is there a concept of thumbnails per chapter (or any other external file metadata?)
c. if yes, are there any standalone of sw players that would support that?

[Mosu]

some questions:
a. in the spliting section the gui says something like 'split AFTER timecodes', but the split points are actually done BEFORE TC, whats that about? :)

The label is wrong, of course. My guess is that this is due to earlier releases of mmg having a control labeled "split after..." with several other inputs that were simply labeled "timecode", "duration" etc.

b. is there a concept of thumbnails per chapter (or any other external file metadata?)
c. if yes, are there any standalone of sw players that would support that?

No to b. and none that I know of to c.

[stax76]

is possible create GUI like mkvinfo/mmg for mkvextract natively and multiplataform?

Actually the current GUI is native on all platforms because wxWidgets wraps the native GUI toolkit, problem is slow startup and big file size, not sure why it loads slow but the file size is related to the OOP nature of the GUI libary, all methods in a class will end up in the binary even when never used. It would probably be possible to shrink the file size and speed up the loading but probably it's not worth the trouble otherwise Mosu would have done it already.

Best is to forget about the native term, there are so many different toolkits and development platforms, .NET for instance won't often wrap a native widget but rather draw one calling into the VisualStyles API so it's only partly native, other toolkits do the same.

Then you have the new GUI library WPF which has a very steep learning curve and is extremely powerful, it also imitates the native toolkit somehow and I don't think it uses the VisualStyles API doing it. WPF will be popular even though it has a very steep learning curve and is very resource hungry. It's already part of the Windows platform since Vista, the PowerShell script editor included in Win 7 is built with it, VisualStudio 2010 and most other new MS applications too. WPF's small brother for the Web is called Silverlight competing with Flash, most will use HTML5 instead which is technically inferior for application development but open which is crucial for the web.

You might as well use the term legacy instead of native speaking of the classical Win UI, most new UI stuff in Win 7 use already a newer and internal non public UI toolkit so only Microsoft can use it so C++ programmers are stuck with poor MFC, this toolkit is native meaning not managed so don't need much resources. It's much older than WPF, I think it was already used in XP, it's basically a native control hosting a UI toolkit, Spy++ report this as DirectUIHWND, not sure much is known about it, it's used a lot in Win 7, most parts of explorer are built with it.

[Midzuki]

is possible create GUI like mkvinfo/mmg for mkvextract natively and multiplataform?

Try porting MKVtoolnix to Java. ;)

[Mosu]

I think the main reason for his request was that there is no official GUI for mkvextract -- only third-party tools on Windows.

[buzzqw]

purebasic is crosscompiling and avaiable (with commercial license) from win/linux/mac

automen (a gui to mencoder) is build with the same source for win and linux (on win and linux pc...)

no need to use java..

even on my HDConvertToX i added a simple gui to mkvextract...

BHH

[b66pak]

@Mosu how do i extract three tracks (1:video.h264, 2:audio.aac, 3:audio.ac3) and the timecodes in one pass using mkvextract in windows?
_

[Mosu]

You cannot. You can only extract either tracks or timecodes.

[sl1pkn07]

I think the main reason for his request was that there is no official GUI for mkvextract -- only third-party tools on Windows.

yea. this is my only reason for this request. extist GUI for mkvmerge (mmg), exist GUI for mkvinfo (mkvinfo -g)... Why does not Mkvextract GUI exist?

[Mosu]

Creating and maintaining GUIs takes time, and it's pretty much the part I dislike the most about programming in general. Combined with the fact that my main focus is on creating Matroska files and not deconstructing them this leads to me not creating such a GUI.

[sl1pkn07]

ok. thanks

[hubblec4]

hi Mosu

I can imagine you have a lot of thinks to do.

But when comes the support of Bluray.sup (and HD-DVD.sup)?

[Mosu]

mkvextract can extract them. mkvmerge can read them from Matroska files. Reading them from .sup files will be done when it's done, meaning I don't have an ETA.

[Daemon404]

So ever since upgrading to to mkvtoolnix 3.3.0 on my centos 5 box (yes, it's old, I know), mkvmerge hangs and uses 100% cpu (at anywhere from 0-6% done) whenever muxing more than one track. It can mux 1 track just fine, but any more and this bug occurs. It's also worth noting that it happens to at least one other person I know (running fc7.. yea.. old.. etc :P). Anyone else having similar problems? Also note 3.2.0 works perfectly fine for both of us. This happens for all input filetypes I've tried (vorbis in ogg, ass subtitles, aac, h.264 (ES), and all of the above in mkv).

[Mosu]

I haven't seen this behaviour myself, nor have I heard from others having the same issue.

Does that happen with all kinds of source files? AVI, Matroska, AC3, Ogg Vorbis, FLAC, AAC... Meaning do you only test the same file on both machines or do you try different ones with different codecs? Can you upload one of the problematic files somewhere, preferably to my FTP server (see signature)?

Do you use binary packages from somewhere (I don't provide packages for FC7 anymore) or do you compile them yourself?

If the latter try compiling them without optimizations and without precompiled headers by running configure with the following options: ./configure --enable-debug --disable-precompiled-headers

[Daemon404]

Yes it happens with every type of every file. I've tried several more now (various things in avi, mp3, flac, wavpack, srt, and combinations of these as well as the ones i previously listed). I don't know if I can upload a problematic file... since well, everything is problematic.

Both of us do compile it ourselves, and I will compile it with the requested settings and post the results.

[Daemon404]

Ok so disabling precompiled headers didnt do anything, but enabling debug fixes it.

[Mosu]

So it works fine with debugging enabled? Then it's a gcc bug (I've had those before with old gcc, e.g. 4.1.x, and high optimizations).

[Daemon404]

Oh boy I love gcc bugs.

[microchip8]

Hi Moritz

I'm not sure which is at fault here, but thought to report it. I've noticed that whenever creating AVI files with mencoder which contain AAC audio from FAAC, regardless if one uses object=2 (for LC AAC) or not in the options, they all end up being reported by MediaInfo as being Main profile in the MKV. This happens when directly taking the AAC audio from the AVI, ie mkvmerge -o output.mkv myfile.avi. However, if repeating the same but this time dumping the AAC audio with -of rawaudio and then using the audio file to feed mkvmerge, MediaInfo correctly reports LC profile when object=2 is used for encoding (and it reports Main profile when object=1 is used, which is correct). I've also compared the results of another muxer (MP4Box) and if I use object=1 while encoding and then muxing to mp4, MP4Box correctly reports it being Main profile AAC. When object=2 is used during encode, MP4Box reports it as being LC profile, which is correct. So, I suspect either mkvmerge has a small bug when dealing with AAC audio in AVI or MediaInfo does but I'm not sure which one.

[Mosu]

Sorry, cannot help you with such minor issues at the moment due to lack of time.

[stax76]

Maybe the problem is mkvmerge cannot detect aac mode from raw aac data so it detects it from container meta data and avi don't hold such data. A simple solution is to not mux AAC in AVI but rather in MKV.

[mikeathome]

Hi,
don't know whether this had be reported before:

I tried the old 2.... and the new 3... (latest) version same behavior. I re-encode a BD with x264 (vs.1541), one job was ok, the otherone, no matter what I tried, got imported as DTS audio. Same parameter on both re-encodes (but different bitrate).

My workaround: I made an .mp4 (with MP4Box) and it was imported as H264 AVC (4.1, HP.....).

Resulting MKV was perfectly playing and in sync. I opened both in WinHex to compare the header and the looked the same.

Let me know if you need more details. Can send you a few seconds of the re-encode.

mike

P.S.
Not urgent, since I have a workaround...

[Mosu]

No, I haven't heard from such an issue yet. It would if you could upload the first 20 MB or so of the h264 file that mkvmerge thinks is a DTS file to my FTP server.

[trondmm]

Hi.

I'm using mkvtoolnix 3.3.0 on 64 bit Ubuntu 9.10

I'm trying to use mkvpropedit to set the correct language for the audio track, and also to add a name for the track. However, after I've changed the language, mkvinfo will no longer find any tracks at all, and mplayer won't play the file. VLC will still play it, though, and if I use mkvpropedit to delete the language property, everything's back to normal.

The command I'm using is:
$ mkvpropedit title00.mkv -e track:a1 -s language=nor

and here is the output of mkvinfo before and after I set the language property


+ EBML head
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 4540760179
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 29)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libmakemkv v1.5.4 beta (0.7.7/0.8.1) x86_64-linux-gnu
| + Writing application: MakeMKV v1.5.4 beta linux(x64-release)
| + Duration: 7411.632s (02:03:31.632)
| + Segment UID: 0x44 0xfd 0x3a 0x89 0x63 0x61 0x72 0x9a 0x95 0x96 0x11 0x9a 0xb3 0x4d 0xa0 0xc0
| + Date: Sat Apr 24 17:22:22 2010 UTC
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Enabled: 1
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 0
| + MinCache: 0
| + Timecode scale: 1
| + Max BlockAddition ID: 0
| + Codec ID: V_MPEG2
| + Codec decode all: 1
| + CodecPrivate, length 95
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Video track
| + Pixel width: 720
| + Pixel height: 576
| + Interlaced: 0
| + Display height: 576
| + Display width: 768
| + Display unit: 0 (pixels)
| + A track
| + Track number: 2
| + Track UID: 2
| + 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_AC3
| + Codec decode all: 1
| + Default duration: 32.000ms (31.250 fps for a video track)
| + Audio track
| + Sampling frequency: 48000
| + Channels: 2
|+ EbmlVoid (size: 4)
|+ Chapters
| + EditionEntry
| + EditionFlagHidden: 0
| + EditionFlagDefault: 1
| + EditionUID: 3511130888
| + ChapterAtom
| + ChapterUID: 1
| + ChapterTimeStart: 00:00:00.000000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 00
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 2
| + ChapterTimeStart: 00:00:00.216000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 01
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 3
| + ChapterTimeStart: 00:10:04.224000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 02
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 4
| + ChapterTimeStart: 01:03:01.960000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 03
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 5
| + ChapterTimeStart: 01:03:49.088000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 04
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 6
| + ChapterTimeStart: 01:04:08.424000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 05
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 7
| + ChapterTimeStart: 01:54:16.752000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 06
| + ChapterLanguage: eng
|+ Cluster



+ EBML head
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 4540760449
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 26)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libmakemkv v1.5.4 beta (0.7.7/0.8.1) x86_64-linux-gnu
| + Writing application: MakeMKV v1.5.4 beta linux(x64-release)
| + Duration: 7411.632s (02:03:31.632)
| + Segment UID: 0x44 0xfd 0x3a 0x89 0x63 0x61 0x72 0x9a 0x95 0x96 0x11 0x9a 0xb3 0x4d 0xa0 0xc0
| + Date: Sat Apr 24 17:22:22 2010 UTC
|+ EbmlVoid (size: 266)
|+ Chapters
| + EditionEntry
| + EditionFlagHidden: 0
| + EditionFlagDefault: 1
| + EditionUID: 3511130888
| + ChapterAtom
| + ChapterUID: 1
| + ChapterTimeStart: 00:00:00.000000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 00
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 2
| + ChapterTimeStart: 00:00:00.216000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 01
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 3
| + ChapterTimeStart: 00:10:04.224000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 02
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 4
| + ChapterTimeStart: 01:03:01.960000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 03
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 5
| + ChapterTimeStart: 01:03:49.088000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 04
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 6
| + ChapterTimeStart: 01:04:08.424000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 05
| + ChapterLanguage: eng
| + ChapterAtom
| + ChapterUID: 7
| + ChapterTimeStart: 01:54:16.752000000
| + ChapterFlagHidden: 0
| + ChapterFlagEnabled: 1
| + ChapterDisplay
| + ChapterString: Chapter 06
| + ChapterLanguage: eng
|+ Cluster


and mplayer says:


$ mplayer title00.mkv
MPlayer UNKNOWN-4.4.1 (C) 2000-2009 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing title00.mkv.
[mkv] No video track found/wanted.
[mkv] No audio track found/wanted.
Matroska file format detected.
No stream found.


Exiting... (End of file)


Is this normal? Am I not using mkvpropedit right? Or is this a bug in either mkvpropedit or mkvinfo (and mplayer)?

If I use mkvmerge to remux the file, like this:

$ mkvmerge -o new.mkv --language 2:nor title00.mkv

everything works fine, and mkvpropedit can change language on this new file without any problems. This takes quite a long time, though, so I would really prefer it if I could use mkvpropedit.

[Mosu]

Known problem that should be fixed in my Git repo. Get the sources from there and compile your own version -- it's pretty easy. See http://www.bunkus.org/videotools/mkvtoolnix/source.html#debian_ubuntu_package

[Mosu]

Ah wait. I've misinterpreted what you've written.

mkvpropedit and mkvinfo are working normally. What happens is this:

You add data to the track headers by setting the language. Now the track headers do not fit into the space they've occupied before. Therefore mkvpropedit writes them at the end of the file and adjusts the meta seek elements so that they point to the new place.

mkvinfo will no longer find any tracks at all

mkvinfo is a development tool. It reads a file from beginning to the end. If it doesn't encounter a track info element before the first cluster then it won't report the tracks. Simple as that.

If you want to know which tracks are present then use "mkvmerge --identify yourfile.mkv" which acts like a player should act by reading and analyzing the meta seek elements and reading the track info even if it is located at the end of the file.

mplayer won't play the file

This is most likely a bug in mplayer.

Everything's working as intended.

[Keiyakusha]

Hi Mosu. If I have mkv file with audio, video and chapters. When I open it in mkvmergeGUI, it shows active "Language" dropdown menu for these chapters. However if I'll set some language there, mux new file and open this saved file in mkvmerge again, then field in this menu shows "undetermined". I just wondering is this how it should be or should it recognize the language that was set before (like with video/audio tracks)?

[Mosu]

The content of the chapter editor are not written to the output file when you start muxing in mmg. Yes, it's a bad design, but that's the way it is at the moment. Think of the chapter editor as a separate program. Save the chapters to a XML file, chose that XML file in the "global" tab and mux it.

[MrVideo]

While doing some experimentation, I used x264 to encode video as filename.264. I usually output as filename.mp4. When I mkvmerge the filename.mp4 with the audio, the framefrate is correct (23.976).

But the filename.264 video gets set to the default 25 fps for some reason, even though mediainfo reports that the original frame rate of the filename.264 is 23.976 fps.

What do I need to place on the mkvmerge command line to set the frame rate to 23.976?

Thanks.

[sneaker_ger]

"--default-duration" "0:24000/1001fps" ("0" being the TID)

[MrVideo]

"--default-duration" "0:24000/1001fps" ("0" being the TID)

Thanks. It worked, after getting home and testing it.

[Mosu]

As a note I have code that will read the FPS information from the AVC bitstream so that one shouldn't have to add that parameter in cases as yours. However, that has to be tested before I can release it.

[Mosu]

Hey,

I've released mkvtoolnix v3.4.0. This release contains several important bug fixes and a few new features. Two new translations (Russian and Ukrainian) have been added.

There are two changes for package maintainers and folks building their own copy from the source: 1. the two new translations I've mentioned and 2. mkvtoolnix requires the new releases libebml v0.8.0 and libmatroska v0.9.0 available at http://dl.matroska.org

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 3.3.0:

------------------------------------------------------------
2010-05-14 Moritz Bunkus <moritz@bunkus.org>
* Released v3.4.0.
* build: Building mkvtoolnix now requires libebml v0.8.0 and libmatroska v0.9.0 or later.
* all: Added a translation into Ukrainian by Serj (see AUTHORS).

2010-05-06 Moritz Bunkus <moritz@bunkus.org>
* Windows installer: Added the choice to run the installer in the same languages that the GUIs support. Patch by Serj (see AUTHORS) with modifications by myself.

2010-04-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the handling of non-spec compliant AVC/h.264 elementary streams in Matroska files with the CodecID V_ISO/MPEG4/AVC. Fix for bug 486.

2010-04-23 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation into Russian by Serj (see AUTHORS).

2010-04-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge will not output a message that it has extracted the display dimensions from AVC/h.264 bitstream if the source container (e.g. Matroska) overrides that setting. Fix for bug 485.

2010-04-12 Moritz Bunkus <moritz@bunkus.org>
* mmg's header editor, mkvpropedit: Fixed crashes with files created by Haali's GS Muxer containing "content encoding" header elements.

2010-04-11 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Extracting SSA/ASS files which miss the "Text" column specifier in the "Format:" line are handled correctly. Fix for bug 483.

2010-04-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a segfault when reading Matroska files containing level 1 elements other than clusters with a size of 0.

2010-04-03 Moritz Bunkus <moritz@bunkus.org>
* Build system: The LINGUAS environment variable determines which man page and guide translations will be installed.

2010-03-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a tiny memory leak. Fix for bug 481.
------------------------------------------------------------

Have fun.

[b66pak]

thanks a lot...
_

[hubblec4]

There are two changes for package maintainers and folks building their own copy from the source: 1. the two new translations I've mentioned and 2. mkvtoolnix requires the new releases libebml v0.8.0 and libmatroska v0.9.0 available at http://dl.matroska.org.

hi mosu

is there anywhere a compiled build?

i can download there the source code only.

[Mosu]

Binary packages for libEBML and libMatroska for Debian, Ubuntu, OpenSuSE and Fedora Core are available from http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

[hubblec4]

Binary packages for libEBML and libMatroska for Debian, Ubuntu, OpenSuSE and Fedora Core are available from http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

...and for windows? or dont need the new libEBML and libMAtroska for windwos?

[Mosu]

You only need the two libraries if you're building mkvtoolnix from source. That's why that line was prefixed with "note for package maintainers".

[hubblec4]

ahja ok thanks

[roozhou]

@Mosu

Where can i find documentation for the "hidden" options in mkvmerge? e.g. --engage native_mpeg4

[Mosu]

@Mosu

Where can i find documentation for the "hidden" options in mkvmerge? e.g. --engage native_mpeg4

There's almost none because those are development options. I usually don't support them, meaning that I probably won't help you with any problems arising from their usage.

mmg has a dialog for adding arbitrary command line options ("Muxing" -> "Add command line options"). That dialog contains all the available hacks and a short description for each, but that's about all the documentation there is.

[Mosu]

Great news for free multimedia in general and Matroska in particular: Google open-sources VP8 and choses Matroska for their new WebM project (http://www.bunkus.org/blog/2010/05/google-open-sources-vp8-choses-matroska/)

[Keiyakusha]

Hi Mosu!
Not so long ago I discovered (official?)tool called mkvalidator (http://dl.matroska.org/downloads/mkvalidator/HEADER.html). Not sure why I need it but I tried it just out of curiosity and found that it displays a lot of warnings for files muxed with mkvmerge. like this: "WRN0C0: First Block for video track #1 in Cluster at 69826954 is not a keyframe" However there is also some errors sometimes.
So the question is, does this validator actually valid? :)

[Mosu]

mkvalidator is developed by Steve Lhomme (robux4), one of the co-creators of Matroska. Yes, its analysis is mostly valid, however it's also a very new tool and there are bugs and inconsistencies it doesn't account for. It would be best if you could talk to robux4 directly, e.g. on IRC (irc.corecodec.com, channel #matroska).

For example, mkvalidator assumes ideal files in which each cluster starts with a key frame in order to make seeking as fast as possible. This is technically unnecessary, and mkvmerge will never write such files, because its current way is not really worse and supported by all readers anyway. That's why it's only a warning in mkvalidator, not an error. It basically says "this file might be improved".

[Mosu]

Here's a build with support for reading VP8 from and writing it to IVF files: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.4.0-build20100527-255-setup.exe

[Selur]

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.

[Mosu]

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.

[moviefan]

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.

[Mosu]

I know of the problem but have no plans of working on that at the moment. Patches are MORE than welcome, but I neither have the expertise nor the time to do this myself just now.

[moviefan]

OK. Do you know of any other mkv muxer that can handle open-gop?

[Mosu]

I don't, maybe others do.

[moviefan]

I've just asked in the x264 thread in IRC about the open-gop issue and kierank said it would be an easy thing to adapt to open-gop.

[16:54] kierank: he needs to flag the frame as a keyframe if there's a recovery point sei

I would create a patch if I had any experience in developing media related software. Does this information help and would you change your mind based on this to implement open-gop support? It seems to be easy and if you know what kierank is saying...

[Mosu]

mkvmerge already marks the next frame after a recovery point SEI as a key frame. So if it doesn't work for you it's something else.

[GuilhermeAraujo]

Is it possible to add the job start time in the output? When working with large files, it'd be good to know how long has passed since it started and to estimate how long it'll take to finish.

[Mosu]

Everything's possible, it's OpenSource after all. But I won't add such a feature. Sorry.

[Nic]

Many thanks for the WebM support in mkvmerge :)

Although, not your problem, Vorbis in WebM cannot be played by the WebM DirectShow filters unless I add "--timecode-scale 1000000 --disable-lacing". Plays fine in VLC though.

Probably a limitation of the MKV parser code in the WebM filter, might peek thru the source and try and come up with a patch.

Cheers,
-Nic

EDIT: Oh, although probably of no use to anyone as there's other solutons: http://nic.dnsalias.com/ivfenc.zip is ivfenc with AviSynth input support (do a ConvertToYV12() at the end of the script)

[Brazil2]

Here's a build with support for reading VP8 from and writing it to IVF files: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.4.0-build20100527-255-setup.exe
Thanks for this build but I've noticed a small bug: in MMG the Webm files are not listed with the other compatible files when using Add and All Supported Media Files default option. You have to specifically select Webm audio/video files to see them.

[Brazil2]

Although, not your problem, Vorbis in WebM cannot be played by the WebM DirectShow filters unless I add "--timecode-scale 1000000 --disable-lacing". Plays fine in VLC though.
Nice find! Works like a charm now :)

[Mosu]

Thanks for this build but I've noticed a small bug: in MMG the Webm files are not listed with the other compatible files when using Add and All Supported Media Files default option. You have to specifically select Webm audio/video files to see them.

Works fine for me on Windows 7. I see files with the .webm extension if I chose "All supported media files" in the file selection dialog. Which Windows version are you using?

[Brazil2]

Works fine for me on Windows 7. I see files with the .webm extension if I chose "All supported media files" in the file selection dialog. Which Windows version are you using?
I'm on Windows XP. I've just updated to build 257 and it's still the same. For instance I can see MP4 M4A OGG AVI MKA FLAC H264 and even IVF files but no WEBM ones. I must select this extension to be able to see them.

[Mosu]

Then that is a limitation of Windows XP, 'cause it works on Vista as well. I don't think there's much I can do about it safe list all files instead of all supported files when mmg is running on XP. I'll get it fixed soonish.

[Brazil2]

Then that is a limitation of Windows XP
I'm sorry but I don't think it's a limitation of Windows XP because I have other programs, like MPC-HC and VLC, which are using a much longer list of files and they are all showing up.
For instance this build of VLC (http://www.megaupload.com/?d=EU2B1PGB) which supports VP8/Webm decoding is showing the WEBM files in the Open File dialog box among all other files.

[sneaker_ger]

I cannot reproduce the problem in Windows XP. It correctly lists all files with ".webm" extension when choosing "all supported files". 3.4.0 pre 257

[Brazil2]

I cannot reproduce the problem in Windows XP. It correctly lists all files with ".webm" extension when choosing "all supported files". 3.4.0 pre 257
So it's definitely not an XP problem :)
Additional information: I've never installed Mkvtoolnix on my system but I've always used a zipped version.

[Mosu]

Ok, then I don't know why it would happen on your system. Won't look into it due to limited free time & no available XP installation. Sorry.

[madshi]

OK. Do you know of any other mkv muxer that can handle open-gop?
You could try eac3to, but to be honest, I don't really know if it works.

[rack04]

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.

If your goal is to output a compliant Blu-ray Disc structure, which from what I've read is the only reason to use open-gop, then you shouldn't be muxing to MKV. AFAIK, once you mux the raw 264 stream generated by x264 to MKV you lose NAL-HRD. If you use the MKV file to generate the Blu-ray Disc structure then txMuxeR assumes VBV values to generate NAL-HRD if no information exists.

[madshi]

@Mosu,

would you consider adding support for h264 MVC? That's an extension to the h264 format, used by the new 3D Blu-Rays. I've analyzed the format and I think for muxing purposes it's pretty easy to handle. Here is the information that you probably need:

(1) For 3D movies there's a "left eye" stream, which is simply a normal standard h264 file. For the "right eye" there is a separate h264 MVC stream, which is slightly different to standard h264, cause it's coded as a "difference" to the left eye stream.

(2) The AUDs in a h264 MVC stream are "00 00 01 18" instead of "00 00 01 09". The sequence parameter set is "00 00 01 0f" instead of "00 00 01 07". The sequence parameter format is identical to standard h264, it has just some added information at the end of the data. The idc_profile for the h264 MVC stream is 128.

(3) For h264 MVC muxing purposes, the easiest solution is to split the stream exactly where the AUDs are. That way no complicated parsing of the frames is necessary. The AUDs also show which frame is a key frame, IIRC.

If you're interested, I can provide you with a short 3D sample.

[Mosu]

For quite some time h264 has had a pretty high priority for me. However, at the moment other things have higher priority, so I will not invest time into 3D video at the moment.

But having a sample would definitely by nice in case I change my mind. Can you please upload it, e.g. to my FTP server?

[madshi]

Can you please upload it, e.g. to my FTP server?
Done. You can use eac3to (v3.20 or newer) to demux it.

[Krawhitham]

I get this at about the 11% mark when using mkvextract.exe

Error: Could not write to the output file: 998 (Invalid access to memory location.)

This just happens on one file not all files but it plays perfectly

any ideas?

[Mosu]

I'd have to look at the file in order to see what the problem is. Can you upload it to my FTP server?

[Krawhitham]

I'd have to look at the file in order to see what the problem is. Can you upload it to my FTP server?

Sorry you can delete the file I was uploading, I found 8192 bytes that were zeroed out about 12% into the file

[Mosu]

Alright.

[moviefan]

If your goal is to output a compliant Blu-ray Disc structure, which from what I've read is the only reason to use open-gop, then you shouldn't be muxing to MKV. AFAIK, once you mux the raw 264 stream generated by x264 to MKV you lose NAL-HRD. If you use the MKV file to generate the Blu-ray Disc structure then txMuxeR assumes VBV values to generate NAL-HRD if no information exists.

I thought open-gop gives more efficiency (probably only slightly) so that file sizes decrease. I do not intend to encode Blu-ray compliant streams.



I ran my file (encoded with the latest rev of x264 with open-gop and muxed with mkvmerge) through mkvalidator and it returns a huge amount of messages like: "ERR0B1: Block at -1234567890 track #4 is not a keyframe". Does this have to do with open-gop and does it help to fix the issue?

[rack04]

I thought open-gop gives more efficiency (probably only slightly) so that file sizes decrease. I do not intend to encode Blu-ray compliant streams.

Here are a couple quotes from this (http://forum.doom9.org/showthread.php?t=148004) thread.

This patch really is only useful if you have small gops (ie bluray) . my tests were at min keyint of 12. This patch is not for your production encodes as it is experimental. Do not create any binaries with this patch that may be in automatic upgrading scripts to protect the innocent.

As Trahald already said, this patch is useful mostly when you use a low max keyint interval. The reason for its usefulness is that, without the patch, x264 considers that key frames are IDR, which are special picture types that prevents the previous picture type to be a B frame. So, even if x264 would have wanted to use a B frame, if the following frame must be a key frame because of max keyint, without the patch the B will be transformed into a P frame, which isn't as good.

[moviefan]

The first one about the patch being experimental is OK. I know about this but I've not found any drawbacks so for me it seems fine. About its gain in situations with longer GOPs, I sure there's not such a big difference between encoding with and without open-gop if keyframe intervals range around 250 but there isn't any disadvantage to use open-gop is there?

[Mosu]

Apart from a couple of programs being incompatible with it...

[moviefan]

But that's a thing that will be fixed at some point in the future... right?

[Mosu]

Maybe. h264 doesn't have a high priority for me at the moment. Like always: patches are welcome.

[shon3i]

OpenGOP will be soon merged to GIT, we done some testing that show everything pass. Anyway OpenGOP help in all situations, even default x264 settings (250,25) so should be used in normal encodes, not only in Blu-Ray ones.

[moviefan]

Ah great, thanks for the comment, shon3i! Without in-depth knowledge of video encoding, I basically thought it should benefit efficiency.

[Keiyakusha]

If we will do encoding with opengop to mkv (in x264), everything will be fine? No changes should be made to the x264's muxer?
The resulting mkv will be remuxed fine with mkvmerge? (afaik mmg uses some king of pass-through for mkv->mkv muxing, no?)
If there is some changes need to be made to x264's muxer, maybe they can be ported to mkvmerge?

P.S.
So much questions, sorry for that.

[Mosu]

I don't know. Try it.