mkvtoolnix 4.1.1 released [Archive] - Page 7

View Full Version : mkvtoolnix 4.1.1 released

Pages : 1 2 3 4 5 6 [7]

dragoncat852

29th March 2010, 23:22

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

30th March 2010, 08:05

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

31st March 2010, 03:55

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

31st March 2010, 08:08

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

6th April 2010, 16:01

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

6th April 2010, 16:11

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

6th April 2010, 17:31

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

6th April 2010, 17:41

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

6th April 2010, 17:41

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

6th April 2010, 18:04

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

6th April 2010, 18:16

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

6th April 2010, 18:20

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

6th April 2010, 18:28

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

6th April 2010, 19:37

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

6th April 2010, 19:48

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

6th April 2010, 20:15

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

6th April 2010, 20:50

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

7th April 2010, 14:59

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

7th April 2010, 15:18

Which mkvtoolnix version are you using?

lamer_de

9th April 2010, 09:58

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

9th April 2010, 18:33

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

10th April 2010, 14:16

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

12th April 2010, 19:18

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

14th April 2010, 01:51

is possible create GUI like mkvinfo/mmg for mkvextract natively and multiplataform?

Mosu

14th April 2010, 08:09

Of course it is technically possible, but I will never create such a GUI myself.

smok3

14th April 2010, 10:28

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

14th April 2010, 10:36

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

14th April 2010, 11:56

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

14th April 2010, 12:31

is possible create GUI like mkvinfo/mmg for mkvextract natively and multiplataform?

Try porting MKVtoolnix to Java. ;)

Mosu

14th April 2010, 12:38

I think the main reason for his request was that there is no official GUI for mkvextract -- only third-party tools on Windows.

buzzqw

14th April 2010, 14:43

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

14th April 2010, 18:58

@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

14th April 2010, 19:00

You cannot. You can only extract either tracks or timecodes.

sl1pkn07

14th April 2010, 22:16

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

14th April 2010, 22:32

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

14th April 2010, 22:42

ok. thanks

hubblec4

16th April 2010, 21:01

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

16th April 2010, 21:15

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

20th April 2010, 05:34

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

20th April 2010, 07:30

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

20th April 2010, 17:38

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

20th April 2010, 19:30

Ok so disabling precompiled headers didnt do anything, but enabling debug fixes it.

Mosu

20th April 2010, 19:33

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

20th April 2010, 21:14

Oh boy I love gcc bugs.

froggy1

22nd April 2010, 11:50

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

22nd April 2010, 12:46

Sorry, cannot help you with such minor issues at the moment due to lack of time.

stax76

22nd April 2010, 13:05

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

27th April 2010, 21:16

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

28th April 2010, 11:42

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

29th April 2010, 17:54

Mosu

29th April 2010, 18:25

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

29th April 2010, 18:34

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

8th May 2010, 17:07

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

8th May 2010, 17:16

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

9th May 2010, 16:57

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

9th May 2010, 17:40

"--default-duration" "0:24000/1001fps" ("0" being the TID)

MrVideo

9th May 2010, 18:48

"--default-duration" "0:24000/1001fps" ("0" being the TID)

Thanks. It worked, after getting home and testing it.

Mosu

10th May 2010, 09:41

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

15th May 2010, 12:14

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

15th May 2010, 19:31

thanks a lot...
_

hubblec4

17th May 2010, 01:17

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

17th May 2010, 07:35

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

17th May 2010, 12:26

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

17th May 2010, 14:47

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

17th May 2010, 15:12

ahja ok thanks

roozhou

19th May 2010, 12:45

@Mosu

Where can i find documentation for the "hidden" options in mkvmerge? e.g. --engage native_mpeg4

Mosu

19th May 2010, 14:47

@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

19th May 2010, 17:30

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

27th May 2010, 00:30

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

27th May 2010, 10:55

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

27th May 2010, 14:39

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

28th May 2010, 09:24

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

28th May 2010, 09:43

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

28th May 2010, 23:03

Mosu

28th May 2010, 23:22

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

30th May 2010, 14:52

OK. Do you know of any other mkv muxer that can handle open-gop?

Mosu

30th May 2010, 14:54

I don't, maybe others do.

moviefan

30th May 2010, 15:59

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

30th May 2010, 16:05

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

30th May 2010, 16:14

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

30th May 2010, 16:20

Everything's possible, it's OpenSource after all. But I won't add such a feature. Sorry.

Nic

31st May 2010, 13:40

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

2nd June 2010, 13:57

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

2nd June 2010, 13:58

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

2nd June 2010, 14:07

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

2nd June 2010, 14:26

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

2nd June 2010, 14:38

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

2nd June 2010, 15:00

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

2nd June 2010, 15:08

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

2nd June 2010, 15:55

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

2nd June 2010, 16:01

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

3rd June 2010, 17:01

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

3rd June 2010, 17:35

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

3rd June 2010, 17:50

@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

3rd June 2010, 19:44

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

4th June 2010, 09:48

Can you please upload it, e.g. to my FTP server?
Done. You can use eac3to (v3.20 or newer) to demux it.

Krawhitham

4th June 2010, 18:22

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

4th June 2010, 18:27

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

4th June 2010, 18:59

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

4th June 2010, 19:01

Alright.

moviefan

5th June 2010, 14:31

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

5th June 2010, 14:47

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

5th June 2010, 14:52

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

5th June 2010, 15:14

Apart from a couple of programs being incompatible with it...

moviefan

5th June 2010, 15:21

But that's a thing that will be fixed at some point in the future... right?

Mosu

5th June 2010, 15:31

Maybe. h264 doesn't have a high priority for me at the moment. Like always: patches are welcome.

shon3i

5th June 2010, 16:40

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

5th June 2010, 17:52

Ah great, thanks for the comment, shon3i! Without in-depth knowledge of video encoding, I basically thought it should benefit efficiency.

Keiyakusha

5th June 2010, 18:09

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

5th June 2010, 18:46

I don't know. Try it.