mkvtoolnix 4.1.1 released

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