MKVToolNix 1.6.0 has been released

[Mosu]

Originally Posted by Liisachan

thanks Mosu,
like i said before, mkvinfo v1.5.0 was fine with
mkvinfo file.mkv > info.txt
(info.txt gets \r\n for eol not \r\r\n)
so I thought somethinw was broke after 1.5.0 when you added the -o feature...

Something did indeed break at that point

i'll test more later, but mkvtoolnix seems to be quite stable now...

That's good. Time to release 1.5.1 then, I guess.

another (unrlated) question:
is there any option that I can force mkvmerg to use 64bit-timestamps even for video,
like it did in 0995?

Yes: "--timecode-scale -1" or "-1" the appropriate option in mmg. Oh wait, I've never added an input box for that... But I did add it to "Muxing -> Add command line options".

[Liisachan]

Originally Posted by Mosu

That's good. Time to release 1.5.1 then, I guess.

mkvinfo ... > seems ok now, but i noticed this 'progress flood' cosmetic problem in mkvmerge: can't you 'overwrite' the old percentage as the percentage is increasing as you did in 1.5.0?

G:\test>mkvmerge -o out.mkv video.avi audio.mp3
mkvmerge v1.5.0 ('It's alright, baby') built on Aug 16 2005 19:17:45
'video.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'audio.mp3': Using the MP2/MP3 demultiplexer.
'video.avi' track 0: Using the MPEG-4 part 2 video output module.
'audio.mp3' track 0: Using the MPEG audio output module.
The file 'out.mkv' has been opened for writing.
progress: 0%progress: 0%progress: 0%progress: 0%progress: 1%progress: 2%progress: 2%progress: 3%progress: 3%progres
s: 4%progress: 5%progress: 6%progress: 7%progress: 7%progress: 8%progress: 9%progress: 9%progress: 10%progress: 11%
progress: 12%progress: 13%progress: 13%progress: 14%progress: 14%progress: 15%progress: 16%progress: 17%progress: 1
7%progress: 18%progress: 18%progress: 18%progress: 19%progress: 19%progress: 20%progress: 20%progress: 20%progress:
21%progress: 21%progress: 21%progress: 22%progress: 22%progress: 23%progress: 23%progress: 24%progress: 24%progres
s: 25%progress: 26%progress: 27%progress: 28%progress: 29%progress: 30%progress: 31%progress: 32%progress: 33%progr
ess: 34%progress: 35%progress: 36%progress: 37%progress: 38%progress: 39%progress: 40%progress: 41%progress: 42%pro
gress: 42%progress: 43%progress: 43%progress: 44%progress: 44%progress: 45%progress: 46%progress: 47%progress: 48%p
rogress: 49%progress: 50%progress: 51%progress: 52%progress: 53%progress: 54%progress: 55%progress: 57%progress: 58
%progress: 59%progress: 61%progress: 61%progress: 62%progress: 63%progress: 64%progress: 65%progress: 67%progress:
67%progress: 68%progress: 68%progress: 69%progress: 70%progress: 71%progress: 72%progress: 72%progress: 73%progress
: 74%progress: 75%progress: 75%progress: 77%progress: 77%progress: 79%progress: 80%progress: 81%progress: 82%progre
ss: 83%progress: 83%progress: 87%progress: 90%progress: 92%progress: 93%progress: 94%progress: 95%progress: 97%prog
ress: 97%progress: 98%progress: 99%progress: 100%
The cue entries (the index) are being written...
Muxing took 8 seconds.

[Pirks]

Originally Posted by Mosu

Ok, you can try http://www.bunkus.org/videotools/mkv...20050816-1.rar if you want

Tried it. Here's another bugreport for you. I followed these steps:

1) Loaded oops.mov (the file I've uploaded to your ftp) in mmg.exe

2) Deselected audio track, leaving only the video track selected

Command line was set to:

"mkvmerge" -o "C:\data\oops.mkv" -d 1 -A -S C:\cygwin\home\pirks\oops.mov --track-order 0:1

3) Clicked "start muxing" button, mkv has muxed successfully, the log was:

mkvmerge v1.5.0 ('It's alright, baby') built on Aug 16 2005 19:17:45
'C:\cygwin\home\pirks\oops.mov': Using the Quicktime/MP4 demultiplexer.
'C:\cygwin\home\pirks\oops.mov' track 1: Using the MPEG-4 part 10 (AVC) video output module.
The file 'C:\data\oops.mkv' has been opened for writing.
The cue entries (the index) are being written...
Muxing took 0 seconds.

4) Now here's the bug itself. I went to graphedit, inserted latest Haali splitter (August 15th build), it asked for a file to open, I opened the oops.mkv I've just muxed and there are no output pins. Nothing, just the square box with a file name and that's it.

Additional info: when I muxed oops.mov with sound (i.e. I left both AAC audio and AVC video tracks selected) the Haali splitter opens a file and displays only the audio output pin. No video output pins at all, just one audio output pin.

Mosu, can you reproduce this on your PC?

[Mosu]

Originally Posted by Liisachan

mkvinfo ... > seems ok now, but i noticed this 'progress flood' cosmetic problem in mkvmerge: can't you 'overwrite' the old percentage as the percentage is increasing as you did in 1.5.0?

Doh! Will fix this... This is of course not working as intended

[Pirks]

Originally Posted by Mosu

Ok, you can try http://www.bunkus.org/videotools/mkv...20050816-1.rar if you want

In addition to the previous post: some more info about that strange bug with video tracks disappearing when muxing QuickTime mov's.

1) Read my post here:

http://forum.doom9.org/showthread.ph...924#post699924

This strange mov I told Haali about is THE ONLY exception to the rule. I.e. this is the only mov I can remux with mmg and get video track and audio track played back properly by Haali splitter. As I mentioned in the post above, this mov is special in some sense - it has unusual track IDs, 44 and 45 instead of 1 and 2. All the other mov's have track IDs of 1 and 2.

2) Another small thing - when I mux my mov's in mmg, the green progress bar does not move. I.e. it stays white all the time, no green progress strip appearing. It was working before, you must've broken it.

[Mosu]

Originally Posted by Pirks

2) Another small thing - when I mux my mov's in mmg, the green progress bar does not move. I.e. it stays white all the time, no green progress strip appearing. It was working before, you must've broken it.

Related to the thing I'm trying to fix for Liisachan.

Will look at the Quicktime issues this weekend.

[Pirks]

Originally Posted by Mosu

Will look at the Quicktime issues this weekend.

Haali just replied to my post regarding that strange QT movie. He said that track IDs must be irrelevant, there's something else going on. So now I have one QT video that cannot be played back by Haali splitter, but remuxes properly by mmg (and then plays back perfectly with Haali splitter), and all the other QT videos that could be played back with Haali splitter but mmg cannot remux them properly.

Do you think it might help if I upload that strange QT movie with track IDs set to 44/45 to your ftp? Since this movie somehow is remuxed properly by mmg, and all the others are not, this could help you to find out the cause or the problem, right?

The size of the movie is about 850 megs, your ftp is not going to run out of space if I upload the movie, is it?

[Mosu]

Originally Posted by Pirks

Do you think it might help if I upload that strange QT movie with track IDs set to 44/45 to your ftp? Since this movie somehow is remuxed properly by mmg, and all the others are not, this could help you to find out the cause or the problem, right?

Definitely. It's be best if you could upload two movies: the one that works with mkvmerge but not with Haali's splitter and one of the others that don't work with mkvmerge. Please create a new folder for them and name those files appropriately, or (better) include a text file with a short description for each file, the command line used for muxing etc.

The size of the movie is about 850 megs, your ftp is not going to run out of space if I upload the movie, is it?

Still 6,5 GB available, so don't worry

(Damn, I have to clean up that partition again. There should be way more free space than only 6,5 GB...)

[Mosu]

Originally Posted by Liisachan

mkvinfo ... > seems ok now, but i noticed this 'progress flood' cosmetic problem in mkvmerge: can't you 'overwrite' the old percentage as the percentage is increasing as you did in 1.5.0?

and

Originally Posted by Pirks

2) Another small thing - when I mux my mov's in mmg, the green progress bar does not move. I.e. it stays white all the time, no green progress strip appearing. It was working before, you must've broken it.

are fixed in http://www.bunkus.org/videotools/mkv...20050818-1.rar

[Pirks]

Originally Posted by Mosu

Will look at the Quicktime issues this weekend.

OK, I asked the Mac guy to provide me a sample of that movie (a fragment of "Cube Zero" actually), it's now only 20 megs instead of 850 and exhibits almost the same behavior as the whole movie. I.e. mmg remuxes it properly, including video. So I've just uploaded that clip to your ftp. File name is cube.mov. Now you have oops.mov which can't be remuxed with video and cube.mov which can be remuxed with video. I hope it helps to find the bug.

"Almost the same behavior" because this fragment is now playable by the Haali splitter. As I mentioned to Haali the original movie is not recognized by the splitter but this fragment is parsed and played back successfully, however there's a serious problem with audio synchronization but that's another issue.

Still, the full movie will make a nice playground for Haali to hone his QuickTime parsing skills I've been told that this movie (and cube.mov as well) contains four tracks actually. Two are video and audio and the other two are tracks for chapters. Hey, that could be the reason why this is the only movie that is properly remuxed with video track in mmg! I just realized that all the other QT movies of mine have only two tracks, so maybe you should look into that.

Now, I'm going to report the problem with the small fragment of that movie to Haali in the proper thread (problem with audio synchronization), but I still would like to provide him with both the small fragment (cube.mov on your ftp) and the full version of the movie, which is 850+ megs, because they have different issues with the splitter. So, can I upload the movie to your ftp and let Haali know about these two available on your ftp?

[Pirks]

Originally Posted by Mosu

Definitely. It's be best if you could upload two movies: the one that works with mkvmerge but not with Haali's splitter and one of the others that don't work with mkvmerge. Please create a new folder for them and name those files appropriately, or (better) include a text file with a short description for each file, the command line used for muxing etc.

You'll get three now. Uploading the big movie now.

I'll provide detailed bugreports and description of steps to reproduce errors in the forum, ok? I might cross-post in both threads and include the links to each other so that you both could track things.

[Pirks]

Originally Posted by Mosu

It's be best if you could upload two movies: the one that works with mkvmerge but not with Haali's splitter and one of the others that don't work with mkvmerge.

Uploading of the big movie has finished. Its filename is cube_full_dniq.mov. (dniq is a guy who made it). Now you have three my mov's on your ftp, I'll list them here together with the problems they cause.

1) oops.mov

This file loses the video track when remuxed by mmg. Just remux it with default settings and you'll see you can get only audio track played back with Haali splitter. If you remux without audio track, then Haali won't show any output pins at all.

2) cube.mov

This is the fragment of the Cube Zero (cube_full_dniq.mov), you can remux it with mmg and it does NOT lose video track. Dniq told me this one and full movie both have four tracks, two audio/video and two for chapters. Haali splitter plays it but the audio and video are badly desynchronized there, audio plays a couple of seconds before matching video frames.

3) cube_full_dniq.mov

This is the full movie, it also has four tracks, same as cube.mov. And it also can be remuxed properly by mmg, just like cube.mov. I've sent it to you because it has distinct problem with Haali splitter. The splitter refuses to play it, saying that there are no supported tracks inside. The full movie is probably of little interest to you (maybe just for testing after you dealt with losing video bug) but it was meant for Haali. I'm going to post in his thread and refer him to both cube.mov and full Cube movie on your ftp.

[Mosu]

Heya,

here's another release of mkvtoolnix, 1.5.5 this time. A couple of bug fixes, a couple of new features. Check the ChangeLog below for details.

The usual links to...
...the home page:
http://www.bunkus.org/videotools/mkvtoolnix/
...the source code:
http://www.bunkus.org/videotools/mkv...-1.5.5.tar.bz2
...the Windows Unicode binaries:
http://www.bunkus.org/videotools/mkv....5.5-setup.exe

All other packages are available from my home page.

Have fun

Mosu

---------------------------------------
2005-08-21 Moritz Bunkus <moritz@bunkus.org>
* Released v1.5.5.
* mkvtoolnix: Disabled storing AVC/h.264 video tracks in VfW mode.

2005-08-16 Moritz Bunkus <moritz@bunkus.org>
* mkvtoolnix: bug fix: On Windows the command line output was terminated with CR CR NL instead of just CR NL.

2005-08-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The Quicktime/MP4 reader wasn't skipping unknown elements correctly.

2005-08-03 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: Added a new extraction mode for outputting timecodes in a timecode v2 format file. It is called "timecode_v2" and takes the same arguments as the "tracks" extraction mode.
* mkvinfo: new feature: Added a command line switch "--output-charset" which sets the charset that strings read from Matroska files are output in (e.g. if you want the output in UTF-8 and not your system's local charset).
* mkvinfo: new feature: Added a command line switch "-o" for redirecting the output to a file (for systems which re-interpret stdout).
* mkvmerge: bug fix: The combination of using external timecode files and video tracks with B frames was not working as intended. The user had to order the timecodes in the timecode file just like the frames were ordered (meaning the timecodes for a IPBBP sequence with 25 FPS had to be "0", "120", "40, "80"...). This has been fixed. They have to be ascending again and mkvmerge will assign them properly.

2005-08-02 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: Added support for extracting h.264 / AVC tracks into proper h.264 ES streams supported by e.g. MP4Box. Patch by Matt Rice (see AUTHORS).

2005-07-25 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Files with non-ASCII chars weren't opened because conversion to UTF-8 was done before the charset routines were initialized.

2005-07-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a crash if a track in a MP4/QuickTime file did not contain a STCO atom (chunk table) but a STSC atom (chunk map table).

2005-07-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Very large values were not kept correctly for a lot of elements (meaning they were truncated to 16 or 32 bits).
* mkvinfo: bug fix: Very large values were not displayed correctly for a lot of elements (meaning they were truncated to 16 or 32 bits prior to displaying).
* mkvmerge: bug fix: AVC/H.264 references were wrong, and muxing of AVC from Matroska files with proper references resulted in unplayable files.

2005-07-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed support for USF subtitles stored in UTF-16 and UTF-32. Added support for USF subtitles stored in UTF-8 without a BOM.
-----------------------------------------

Edit: Wrong links, sorry.

[Mosu]

Pirks: before you ask: No, I haven't looked at those files yet, sorry.

[jellysandwich]

Originally Posted by Mosu

At the moment mkvmerge does not support converting from VfW-mode AVC/h.264 tracks to native Matroska-mode AVC/h.264 tracks. You can, however, first import the video track into a MP4 file with e.g. 'MP4Box' (use Google). Then you can use mkvmerge and put the video into a Matroska file.
If you really know what you are doing then you can force mkvmerge to put this AVC/h.264 track into a Matroska file even in VfW mode if you add '--engage allow_avc_in_vfw_mode' to the command line. You can do that in mmg with the 'Add command line options' menu entry in the 'Muxing' menu.

How might I do this if I used GKnot to store the video directly into an mkv file (since YAMB/MP4Box can't open mkv inputs)?

I tried converting the mkv file to an avi file via Vdubmod and then using YAMB from there, but it didn't work.

[4:20:13 PM] : Muxing started...
[4:20:13 PM] : Importing & Writing streams...
[4:20:13 PM] : Muxing finished completely.

Basically, it started and finished in an instant without doing anything whatsoever.

Edit: Would anything be wrong with using "--engage allow_avc_in_vfw_mode?"

js

[Mosu]

Have you read the warning mkvmerge prints? It's not the official way, it might work, but in future it might not, and bugs that occur only with this mode might or might not be fixed.

[Pirks]

Originally Posted by Mosu

Pirks: before you ask: No, I haven't looked at those files yet, sorry.

Yeah, I noticed :-) Same problems remain. BTW it could be Haali splitter's fault, not yours.

[jellysandwich]

Originally Posted by Mosu

Have you read the warning mkvmerge prints? It's not the official way, it might work, but in future it might not, and bugs that occur only with this mode might or might not be fixed.

Yes, I read it, but I didn't know the possible consequences. Thanks for explaining them.

js

[Mosu]

Originally Posted by Pirks

Yeah, I noticed :-) Same problems remain. BTW it could be Haali splitter's fault, not yours.

Well, it could be, sure, but as you've already found new QuickTime files that either made mkvmerge crash or contained newer structures that I wasn't aware of it might very well be a problem in mkvmerge, too.

[Mosu]

Originally Posted by jellysandwich

Yes, I read it, but I didn't know the possible consequences. Thanks for explaining them.

js

I should probably improve the error message then