mkvtoolnix 4.1.1 released [Archive] - Page 31

View Full Version : mkvtoolnix 4.1.1 released

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 [31] 32 33

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.

microchip8

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