View Full Version : MKVToolNix 1.6.0 has been released
The current version is 1.6.0 Direct download link to the Windows Unicode installer: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-1.6.0-setup.exe Release notes can be found on page 11 (http://forum.doom9.org/showthread.php?t=96703&page=11&pp=20).
(Yes, yet another thread. But searching in threads sucks... You just don't find the kind of information you're looking for. So here it goes.)
Hey guys,
It's been over two and a half months since the last release, and that's quite a long time. But here it is: MKVToolNix v1.5.0.
This release contains a couple of new features (splitting after arbitrary timecodes and muxing of USF subtitles) and tons of bug fixes.
The usual links to...
...the home page:
http://www.bunkus.org/videotools/mkvtoolnix/
...the sources:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-1.5.0.tar.bz2
...the Windows Unicde binaries:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-1.5.0-setup.exe
...the Windows non-Unicode binaries:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-1.5.0-setup.exe
The other binaries are all available from the home page.
Here's the ChangeLog of what I've done in those past ten weeks:
-----------------------------------------
2005-06-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The track language read from old Matroska files was wrongfully set to "und" if it was not written although the specs say that "eng" is the default value.
* mkvmerge: bug fix: USF subtitles: If identical tags were nested (e.g. "font") and both were closed right after each other then the result looked like "</font/>".
* mkvmerge: bug fix: Native MPEG-4 was not working if read from OGM files.
2005-06-24 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added an input box for mkvmerge's new "split after these timecodes" feature.
2005-06-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fixes: Improved the native MPEG-4 generation a lot (thanks to Haali for testing and pushing me). The codec version string inside the MPEG-4 initialization data is now checked if it indicates "DivX packed bitstream" and changed to not indicate it anymore.
2005-06-07 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: If mmg was minimized when it was closed (e.g. with Windows' "Show desktop" function) then it didn't show up after a restart and could only be shown by maximizing it.
* mkvmerge: bug fix: If a OGM style chapter file contains empty chapter names ('CHAPTER01NAME=' without something after the '=') then this chapter's timecode is used as the name instead of aborting.
2005-06-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added splitting after specific timecodes.
2005-06-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvinfo, mkvextract: bug fix: Inifite sized segments were not handled correctly.
2005-05-23 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: On Windows mmg could be crashed by adding a file and clicking into the empty space in the "track" selection box. Fixes Anthill bug 133.
* mkvextract: new feature: Implemented the extraction of USF subtitles.
* mkvmerge: new feature: Implemented the muxing of USF subtitles.
2005-05-17 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The MPEG packets are now padded to 2048 byte boundaries as some programs require them to be. Patch by Mike Matsnev (see AUTHORS).
2005-05-07 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Removed the restriction of max. ten levels of nested elements.
* mmg: bug fix: If splitting was enabled and "splitting by time" selected and the user chose "new" from the "File" menu then "splitting by time" was not selectable anymore. This happened only on Windows. Fixes Anthill bug 131.
2005-05-05 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Use the native newline style when extracting text subtitles (\r\n on Windows and \n on all other systems).
* mkvextract: bug fix: SSA/ASS text was missing in the output if the "Format=" line contained newlines at the end of the CodecPrivate data (e.g. our old Mew Mew sample file).
2005-05-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for the hapterSegmentUID element.
2005-04-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Support WAV files that use other RIFF chunks than the usual "fmt " followed by "data".
2005-04-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Remuxing MPEG1/2 tracks resulted in a failing "assert(0)".
-----------------------------------------
Have fun :)
Mosu
Tomir
2nd July 2005, 18:29
The vobsub extraction is still buggy.
The vobsub extraction is still buggy.
Too bad.
Details?
Tomir
2nd July 2005, 19:09
Well, once extracted, subs from the vobsub file looks corrupted, like on the screen
http://goos.republika.pl/images/1.jpg
when they should look like this
http://goos.republika.pl/images/2.jpg
If someone want the subs, here they are: idx (http://goos.republika.pl/images/Track4.idx) and sub (http://goos.republika.pl/images/Track4.sub) . When these files are in mkv, they look fine, but when the're out, some look like in the first picture (and subresync doesn't render them at all). Sometimes it happens there are 0 corrupted subs, and sometimes there are many of them.
And subrip displays them somewhat like this
http://goos.republika.pl/images/3.jpg
HQ-LQ
4th July 2005, 12:39
hello.
I have times a question.
is it possible that you contain the support for demux mkv files which support the 'mpeg1 mpeg2 mpeg4(sp/asp) mpeg4(avc)'-steams.
Well, once extracted, subs from the vobsub file looks corrupted, like on the screen
...
Ok, thanks for the files. I'll try to find out what's wrong, but I can't give you a time frame.
Sirber
4th July 2005, 12:53
Updated RealAnime. Thanks!!! :D
hello.
I have times a question.
is it possible that you contain the support for demux mkv files which support the 'mpeg1 mpeg2 mpeg4(sp/asp) mpeg4(avc)'-steams.
translated by google
thanks for reads
No, sorry (not enough time and I don't consider it important enough).
nexus
5th July 2005, 13:00
I think extracting the streams is important. However, if i extract an AVC-Stream (raw mode) it seems to be damaged. Would this need much time to fix?
Anyways, you do a great job! :thanks:
I think extracting the streams is important. However, if i extract an AVC-Stream (raw mode) it seems to be damaged. Would this need much time to fix?
Yes, it would require writing a MP4 muxer. I don't have the time to do that.
HQ-LQ
5th July 2005, 13:35
you could ask the people of mp4box.
I already was to support them said them to support 'avc in mkv'
http://forum.doom9.org/showthread.php?t=94874&page=5&pp=20
that would accelerate some.
nexus
5th July 2005, 13:52
Yes, it would require writing a MP4 muxer. I don't have the time to do that.There already is an mp4 muxer: mp4box. However it crashes when trying to mux an avc stream which is extracted with mkvextract. But i don't know if the bug is in mkvextract or mp4box.
Doom9
5th July 2005, 14:15
But i don't know if the bug is in mkvextract or mp4box.I believe mosu already answered this 2 posts above yours ;)
nexus
5th July 2005, 14:29
I believe mosu already answered this 2 posts above yours ;)But I don't understand it. Why is a mp4 muxer required to extract the raw stream from mkv? :confused:
Not for raw streams, of course, but raw streams miss the timecode information. So you won't be satisfied with that either, I guess.
The reason why raw streams don't work right now is that I have no clue about how raw AVC streams are supposed to look like. Are they simply the avcc atom followed by the data from all frames? That's what mkvextract can already do, but obviously the other tools don't like this. So if you want to help me then find me some specs on AVC elementary streams.
nexus
8th July 2005, 10:01
Maybe this document will help: AVC File Format AVC File Format (Study Text of ISO/IEC 14496-15/FCD) (http://www.chiariglione.org/mpeg/working_documents/mpeg-04/avc_ff/avc_ff.zip)
(38.1 Elementary Stream Structure)
hubereevez
11th July 2005, 00:03
Help !
Error: The track number 3 from the file 'D:\n\credits.mp4' cannot be appended to the track number 3 from the file 'D:\Movie.mp4' because the track parameters do not match (The codec's private data does not match (lengths: 39 and 35).).
and with mp4info (mp4iptools) :
Movie :
Track Type Info
1 od Object Descriptors
2 scene BIFS
3 video H264 Main@4, 8323.840 secs, 604 kbps, 528x288 @ 25.000000 fps
Credits
Track Type Info
1 od Object Descriptors
2 scene BIFS
3 video H264 Main@4, 604.720 secs, 154 kbps, 528x288 @ 25.000000 fps
Thanks
Mosu
11th July 2005, 07:55
Help !
Error: The track number 3 from the file 'D:\n\credits.mp4' cannot be appended to the track number 3 from the file 'D:\Movie.mp4' because the track parameters do not match (The codec's private data does not match (lengths: 39 and 35).).
and with mp4info (mp4iptools) :
Movie :
Track Type Info
1 od Object Descriptors
2 scene BIFS
3 video H264 Main@4, 8323.840 secs, 604 kbps, 528x288 @ 25.000000 fps
Credits
Track Type Info
1 od Object Descriptors
2 scene BIFS
3 video H264 Main@4, 604.720 secs, 154 kbps, 528x288 @ 25.000000 fps
Thanks
Sorry. mkvmerge compares the complete codec private data. If they don't match, then it refuses to concatenate those streams. mkvmerge cannot know whether differences in the codec private are important or not. Most of the time the codec private data contains stuff the codec needs for initialization of its decoding routines like... uhm... huffman tables or whatever. If you concatenate two streams with different decoding initialization data then your results will at best be weird and unplayable at worst. That's why mkvmerge doesn't allow this.
The data your mp4 thingy shows is not even stored there if I'm not mistaken...
However, you could do the following. Run "mkvmerge -v -v -v -v -o whatever.mkv credits.mp4 > credits.txt" and "mkvmerge -v -v -v -v -o whatever.mkv movie.mp4 > movie.txt". This will create two .txt files. Compress those with e.g. ZIP or RAR and upload that archive to my FTP server, please. During this process mkvmerge dumps the codec private data (it does that only when reading MP4 files for debugging purposes); maybe I can see what the differnces are in your case.
hubereevez
11th July 2005, 08:51
Aïe, just deleted the two streams.
I did use Yamb for joining and then mmg for muxing.
Thanks anyway :)
hubert
PS : tell me if I can still extract infos from the mkv
Mosu
11th July 2005, 09:04
No, not anymore. But if you've solved your problem then I don't need that info aynmore.
hubereevez
11th July 2005, 23:51
Ok, sorry then :(
Yep solved when merging with Yamb and mp4box.
Randi
12th July 2005, 18:03
Hi,
is there any way to get the chapter info from nero/h264/mp4 files into the mkv file? Preferably automatic, or if this doesnt work via text ex-/import. reason for using matroska: get avc with ac3. Searched a bit, but didnt find anything.
Thanks
Randi
Mosu
12th July 2005, 21:09
Hi,
is there any way to get the chapter info from nero/h264/mp4 files into the mkv file? Preferably automatic, or if this doesnt work via text ex-/import. reason for using matroska: get avc with ac3. Searched a bit, but didnt find anything.
Thanks
Randi
If you could point me to some specs or at least a nice description for how chapters in MP4 files are realized and to some sample files with chapters, then perhaps I could implement that.
pcjco04
18th July 2005, 10:42
I have a problem with using mkvtoolnix with .mkv file coming from x264 CLI :
MKV output from x264 CLI (build 273B) is playable and seekable with MPC (ffdshow 07032005 + Haali splitter 17 July 2005).
But re-mux with Mkvtoolnix 1.5.0 (without additional stream) it is playable but not seekable.
( the problem as also been discussed here http://forum.doom9.org/showthread.php?t=97126 )
Mosu
18th July 2005, 10:45
Please upload a (small) sample file, thanks.
pcjco04
18th July 2005, 11:52
Done : mkv_from_x264.mkv (2298Kb)
Mosu
19th July 2005, 18:38
I have a problem with using mkvtoolnix with .mkv file coming from x264 CLI :
I hope to have fixed this in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050719-2.rar
pcjco04
20th July 2005, 08:47
Thanks, it solves the problem.
As I was trying to solve the problem, I found another one : I used the following graph in Graphedit to generate an MP4 file :
Haali Splitter (input.mkv) --> Nero AVC Muxer --> File writer (output.mp4)
(only video)
The result mp4 file is playable with MPC but crash mkvmerge. I upload the file in your ftp.
By the way is it normal that when I append a small file after a big one the progress bar reach half after the first file and quickly reach the end during the small one ?
It seems proportional to the number of files and not their size.
Mosu
20th July 2005, 08:57
Thanks, it solves the problem.
As I was trying to solve the problem, I found another one : I used the following graph in Graphedit to generate an MP4 file :
Haali Splitter (input.mkv) --> Nero AVC Muxer --> File writer (output.mp4)
(only video)
The result mp4 file is playable with MPC but crash mkvmerge. I upload the file in your ftp.
Thanks.
By the way is it normal that when I append a small file after a big one the progress bar reach half after the first file and quickly reach the end during the small one ?
It seems proportional to the number of files and not their size.
Depends on the program you use. You can resume uploads on my server, but how your program displays the progress has nothing to do with my server ;)
pcjco04
20th July 2005, 09:00
By append I mean creating an .mkv appending 2 files with mkvtoolnix not resuming files with ftp. :D
Mosu
20th July 2005, 09:24
Please try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050720-1.rar
Mosu
20th July 2005, 09:26
By append I mean creating an .mkv appending 2 files with mkvtoolnix not resuming files with ftp. :D
Aaaah! Yes, that is indeed proportional to the number of files, not to the size of each files. Reason is that mkvmerge handles appending based on tracks, not on whole files, and for a lot of formats it's simply impossible to get each track's length without scanning the complete input file. And that is something I don't want to do as it'd take a lot of time.
So we'll have to live with the inaccuracy.
jellysandwich
22nd July 2005, 02:51
I'm having trouble muxing in Vobsub subtitles
with custom colors enabled.
http://jellysandwich.info/js/vobsub_customcolors.JPG
The resulting file has the subtitles (I can even
switch between the different language subtitles),
but the subtitles simply don't show up.
If I mux in the subtitles with custom colors
disabled, then the subtitles appear.
What's weird is that if I load the custom colors
enabled subtitles through MPC's file menu, then
they appear. They only don't show up after
muxing them in with mkvmerge 1.5.0.
Anyone know what the problem might be?
js
Mosu
22nd July 2005, 08:16
What's weird is that if I load the custom colors
enabled subtitles through MPC's file menu, then
they appear. They only don't show up after
muxing them in with mkvmerge 1.5.0.
Anyone know what the problem might be?
js
I'm pretty sure that this isn't a problem with mkvmerge because it simply copies all the text from the .idx up to the actual events. But you could upload the .idx and the .sub to my FTP server if you want, then I can check if mkvmerge or vsfilter/the splitter/the player is to blame.
jellysandwich
22nd July 2005, 23:40
I'm pretty sure that this isn't a problem with mkvmerge because it simply copies all the text from the .idx up to the actual events. But you could upload the .idx and the .sub to my FTP server if you want, then I can check if mkvmerge or vsfilter/the splitter/the player is to blame.
I had trouble logging into your FTP, so I uploaded the
subtitle files onto my own site (3 MB zipped):
http://jellysandwich.info/js/js_subs.zip
Hmmm, if that's the case, then it probably isn't
mkvmerge, but instead something else. Unfortunately,
I don't know how to check/test the other things...
js
Doom9
23rd July 2005, 12:46
Given a mkvmerge commandline and basic properties of the source (video: codec, nb b-frames, audio: format, vbr or cbr) is there any way to estimate the overhead of the final file?
Mosu
23rd July 2005, 14:08
Given a mkvmerge commandline and basic properties of the source (video: codec, nb b-frames, audio: format, vbr or cbr) is there any way to estimate the overhead of the final file?
Let's see...
An empty Matroska file created by mkvmerge is roughly 4300 bytes large (no, it doesn't have to be that large, but that's how mkvmerge does its thing).
A video track header follows with approx. 140 bytes.
A typical audio track header is a bit smaller unless it's Vorbis, then it is considerably larger (anywhere between 2 KB and 6 KB depending on the code book size & Vorbis comments).
For each 2s length add 10 bytes for cluster overhead as a new cluster is started every 2 seconds.
Video frames: for each I frame add 10 bytes of overhead, for each P frame 13 and for each B frame 16 bytes.
Audio frames: depends on lacing. If typical lacing is used (eight audio frames per Matroska block) then add 22 bytes for eight audio blocks.
Finally the indexes. Add 16 bytes for each video I frame for the index (can be turned off in mkvmerge but shouldn't).
For each cluster ( = for each 2s of video) add another 16 bytes (can be turned off in mkvmerge, doesn't matter all that much whether it's on or not).
Doom9
23rd July 2005, 14:14
add 22 bytes for eight audio blocks.Is there any way to break audio length in ms down to blocks? I have no clue on how to get the number of blocks given audio type and audio length / size.
Mosu
23rd July 2005, 14:25
More comments:
As you can see you need...
...for video: number of I, P and B frames as well as the total length,
...for audio: the number of audio blocks (CBR vs VBR does not matter). The number of blocks depends on the audio codec used. E.g. AAC: 1024 samples/block; AC3: 1536 samples/block; MP3: depends on layer, sample rate and MPEG version; Vorbis: anywhere from 64 (?) to 4096.
Mosu
23rd July 2005, 14:27
Is there any way to break audio length in ms down to blocks? I have no clue on how to get the number of blocks given audio type and audio length / size.
Yes, if you know the audio type. Like I've written just a second ago ;) Which audio types are you interested in?
BTW: For MPEG audio (MPEG 1, 2 and 2.5, layers 1 - 3) the number of samples per block is:
// | MPEG |
// | v1 | v2 | v2.5 |
// --------+------+------+------+
// Layer-1 | 384 | 384 | 384 |
// Layer-2 | 1152 | 1152 | 1152 |
// Layer-3 | 1152 | 576 | 576 |
// --------+------+------+------+
Doom9
23rd July 2005, 16:00
Which audio types are you interested in?Currently MP3, AC3 and AAC, but it might not hurt to know about Vorbis either.
for video: number of I, P and B frames as well as the total length,that's going to be impossible to determine properly due to the fact that I have to calculate the video bitrate (that's what I need the overhead for) before video encding. x264 is so nice to display the final stats but at that point it's too late. Either way I'll just have to be creative and estimate based on the max i-frame spacings and number of b-frames set.
Mosu
23rd July 2005, 17:11
Currently MP3, AC3 and AAC, but it might not hurt to know about Vorbis either.
Ok, for MP3, AC3 and AAC I've given you more or less everything you need to know. The basic formula is number_of_audio_frames = length_in_seconds * audio_frames_per_second = length_in_seconds * sample_rate / samples_per_audio_frame.
samples_per_audio_frame is easy for AAC and AC3, a tiny bit trickier for MP3 (but as the controlling program for the MP3 encoder knows everything important (level and MPEG version) this is not really a problem), and pretty impossible for Vorbis.
For Vorbis, the number of samples per frame can vary greatly, and there's absolutely no way of even estimating them before you've got the result. Even if you have the result calculating the number of samples isn't easy. First, the codebook has to be decoded. Then you have to use something like this:
this_packet_block_size = vorbis_packet_blocksize(&vi, &op);
samples_in_this_packet = (this_packet_block_size + previous_packet_block_size) / 4;
previous_packet_block_size = this_packet_block_size;
with vorbis_packet_blocksize() coming from libvorbis.
It'd probably be best for you to make an educated guess based on tons of files you'll have to mux manually...
Doom9
25th July 2005, 09:26
For each 2s length add 10 bytes for cluster overhead as a new cluster is started every 2 seconds.
For each cluster ( = for each 2s of video) add another 16 bytes (can be turned off in mkvmerge, doesn't matter all that much whether it's on or not).Are those tied together or will I always have to take the first one into account? And how to turn off the second one?
And I guess vorbis basically means I have to put my finger in the wind. That doesn't exactly motivate me to add Vorbis support. The calculations are getting more complex with each container that I support :(
Mosu
25th July 2005, 09:32
Are those tied together or will I always have to take the first one into account? And how to turn off the second one?
They're not tied together. Yes, you always have to take the first into account (but that's easy ;)). The option to turn off creating the second one (clusters in the index) is "--no-clusters-in-meta-seek" anywhere on the command line.
And I guess vorbis basically means I have to put my finger in the wind. That doesn't exactly motivate me to add Vorbis support. The calculations are getting more complex with each container that I support :(
I can fully understand that. I've cursed about Vorbis a couple of times myself...
Mosu
25th July 2005, 09:38
Oh, I forgot: The overhead for clusters is 12 bytes, not 10 (12 bytes for every 2s of length, not for clusters in the index).
Doom9
26th July 2005, 05:41
alright, one more thing: can I mux raw asp streams with mkvmerge or do they need to be in a container? And if the latter, is AVI a good choice as long as the codec in question isn't AVC?
Mosu
26th July 2005, 07:57
alright, one more thing: can I mux raw asp streams with mkvmerge or do they need to be in a container?
No, they have to be in a container. I should really update the section in the documentation.
And if the latter, is AVI a good choice as long as the codec in question isn't AVC?
AVI is quite ok for MPEG-4 part 2 (aka DivX etc). For AVC it has to be MP4 though.
Doom9
26th July 2005, 12:24
what about snow, or other VfW based codecs (like VP6/7)?
Is there any way getting track overhead information on a muxed file? In order to compile some statistics on the muxed output, it would be great if I could get such info somehow so I can improve the calculation approximations over time.
Ishan
26th July 2005, 19:37
I got a problem with mkvmerge : when i mux a vobsub file with the video the subtitle is listed in haali and vobsub is active but it doesn't display any sub :|
all programs are up to date (haali,mpc,vobsub,ffdshow) anyone can help me?
(The strange thing is the file works perfectly in xbox media center)
jellysandwich
27th July 2005, 00:37
Mosu, you try out mkvmerge with custom
colored subtitles yet?
js
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.