MKVToolNix 1.6.0 has been released

[Mosu]

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]

The vobsub extraction is still buggy.

[Mosu]

The vobsub extraction is still buggy.

Too bad.

Details?

[Tomir]

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]

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.

[Mosu]

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]

Updated RealAnime. Thanks!!! :D

[Mosu]

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]

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:

[Mosu]

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]

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]

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]

But i don't know if the bug is in mkvextract or mp4box.I believe mosu already answered this 2 posts above yours ;)

[nexus]

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:

[Mosu]

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]

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]

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]

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]

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]

No, not anymore. But if you've solved your problem then I don't need that info aynmore.

[hubereevez]

Ok, sorry then :(

Yep solved when merging with Yamb and mp4box.

[Randi]

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]

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]

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]

Please upload a (small) sample file, thanks.

[pcjco04]

Done : mkv_from_x264.mkv (2298Kb)

[Mosu]

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]

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]

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]

By append I mean creating an .mkv appending 2 files with mkvtoolnix not resuming files with ftp. :D

[Mosu]

Please try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050720-1.rar

[Mosu]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Mosu, you try out mkvmerge with custom
colored subtitles yet?

js

[Mosu]

Mosu, you try out mkvmerge with custom colored subtitles yet?

No, not yet, but I haven't forgotten it either. Will do that tonight.

[neo_anderson]

has anyone else experinced a little sluggish playback when avc (nerodigital) video is muxed in mkv container?

[Mosu]

has anyone else experinced a little sluggish playback when avc (nerodigital) video is muxed in mkv container?

If you've muxed such a file with mkvmerge/mmg then I suggest you try the latest build from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ I had to fix an issue with wrong references that Haali noticed. Maybe it doesn't fix your problem, but maybe it does. Who knows? :)

[azsd]

I have an Anamorphic encoded mp4 file with dimensions 480x560,I wan't to it play at 480x280 framesize, when I set Display width/height to 480 and 280,the muxed file played as 960x560.

is the mkvmerge can set the frame size in mkv container?
Is the "--display-dimensions" only used the frame size to calculates AR?

thx

[TNM]

Hi, I have a question. If the audio is longer than the video, is there a way for mkvtoolnix to cut off the audio just when the video ends? you know, like the way vdub/mod does it..

[azsd]

--default-duration <TID:Xms|us|ns>
Force the default duration of a track to X.
is this arg may set the during of the audio track

[Mosu]

I have an Anamorphic encoded mp4 file with dimensions 480x560,I wan't to it play at 480x280 framesize, when I set Display width/height to 480 and 280,the muxed file played as 960x560.

is the mkvmerge can set the frame size in mkv container?
Is the "--display-dimensions" only used the frame size to calculates AR?

thx

If you set display width and display height then on playback the video should be resized to that exact size. If it doesn't then the player/filter/decoder is at fault. Unfortunately I have no clue about what you have to do on Windows in order to get that working. Someone mentioned "overlay" in combination with "ffdshow", but again that may be totally wrong :)

[Mosu]

Hi, I have a question. If the audio is longer than the video, is there a way for mkvtoolnix to cut off the audio just when the video ends? you know, like the way vdub/mod does it..

No, mkvmerge does not support this.

[Mosu]

is this arg may set the during of the audio track

Nope. That option does something else.

[niamh]

azsd : it could be directvobsub at fault. check the picture resizing in "general" (if it loads at playback, of course). It's defaulted to double if smaller than 384x288

[Liisachan]

MMG is not Unicode enabled.
For instance, MMG failes to open a file when the filename is a French/Korean mix, saying
--------------------
File identification failed

File identification failed for 'C:\????.avi'. Return code: 2
--------------------

???? is what originally is a French/Korean mix, but it is displayed as "???" literally.
Is this a known limitation?

[Mosu]

MMG is not Unicode enabled.

Knowing you I won't ask if you've used the Unicode build ;) But maybe you could tell me how I could create such a file name myself with my German keyboard and which Windows components I have to install so that I can check it out.

Is this a known limitation?

Only for the non-Unicode build, but I can only test with German Umlauts (which are not ASCII anymore, so it's at least half a test).

[Liisachan]

You can copy and paste a random string from (for instance) a Korean webpage, after installing East Asian Language Support:
e.g. "꽃의 마법사 매리벨.avi"

Another thing:
Apparently Windows OS does unwanted service for stdio when the System Locale is CJK:
it tries to read a UTF-8 string as a legacy multibyte string (without converting properly), and as a result, a part of the UTF-8 string is discarded if that part is illegal as the MB string in question (such as Shift_JIS). UTF-8 is "ASCII-transparent" but NOT CJK-transparent.

Simply put, "Title" stored in MKV may be broken in this utf8.txt:
mkvinfo file.mkv > utf8.txt
Even when the title is in Japanese, and the System Locale is Japanese.
Why? Because that silly DOS Box (standard output) tries to interpret the UTF-8 string passed from mkvinfo as Shift_JIS, and fails.

The similar thing can happen in input too, but I found a workaround for input:
mkvmerge --command-line-charset UTF-8 -o out.mkv @command.utf8

This way, UTF-8 strings (track names, titles) in command.utf8 won't be broken even when direct input wouldn't work. This workaround should work for the above problem about MMG, but still, output is foobared. I'd need something like this so that Windows won't mess with my UTF-8 strings.
mkvinfo file.mkv -o info.txt

[Mosu]

You can copy and paste a random string from (for instance) a Korean webpage, after installing East Asian Language Support:
e.g. "꽃의 마법사 매리벨.avi"

Thanks, Haali tried to coach me through this as well. Unfortunately I cannot reproduce this. I've tried file names with German Umlaute, Arabic and Latin chars as well as the file name you've used as an example. They are all muxed just fine.

Another thing:
...
The similar thing can happen in input too, but I found a workaround for input:
mkvmerge --command-line-charset UTF-8 -o out.mkv @command.utf8

This is what mmg does as well (not only for the charset reason, also because the command line length on Windows is VERY limited). mmg puts all arguments into such a file with a UTF-8 BOM.

This way, UTF-8 strings (track names, titles) in command.utf8 won't be broken even when direct input wouldn't work. This workaround should work for the above problem about MMG, but still, output is foobared.

Well, it does already work here... And mmg already uses such a file. You can check for such a file if you mux but don't close the muxing window. The command file should be in the user's temporary directory (which is usually something like "C:\Documents and Settings\UserName\Local Settings\Temp") and called mmg-mkvmerge-options-... in case you want to take a look at it.

I'd need something like this so that Windows won't mess with my UTF-8 strings.
mkvinfo file.mkv -o info.txt

This is easy to add. That doesn't solve your problem with mmg/mkvmerge, though...

[Liisachan]

It's really weird, but just re-installing MKVToolnix fixed my problem. :confused:
I think I was using Unicode build, because mkvmerge was able to handle a French/Japanese mix even when I was having that MMG problem...but sorry, I wasted your time anyway...

and I was wrong in another thing: out.txt in mkvinfo file.mkv > out.txt is not in UTF-8 but System Code Page. (Is this by design?) If so...
This is easy to add. That doesn't solve your problem with mmg/mkvmerge, though...
...what I'd really want to have is, something like:
mkvinfo file.mkv --output-charset UTF-8 -o utf8.txt

[Mosu]

It's really weird, but just re-installing MKVToolnix fixed my problem. :confused:
I think I was using Unicode build, because mkvmerge was able to handle a French/Japanese mix even when I was having that MMG problem...but sorry, I wasted your time anyway...

Don't worry. I'm on vacation at the moment, and I actually enjoy coding and bug hunting if I'm not as pressed for time as I've been during the last few weeks/months. And I'm just happy that it works for you now.

and I was wrong in another thing: out.txt in mkvinfo file.mkv > out.txt is not in UTF-8 but System Code Page. (Is this by design?) If so...

...what I'd really want to have is, something like:
mkvinfo file.mkv --output-charset UTF-8 -o utf8.txt

The -o part is already done. I'll do the --output-charset option next.

[Liisachan]

If you are going to add that thing, could you please think about this while you're at it?
http://forum.doom9.org/showthread.php?p=691095#post691095
This can be easily done manually, but...
mkvinfo (or mkvextract) timecode file.mkv -o v2.tm

[Mosu]

If you are going to add that thing, could you please think about this while you're at it?
http://forum.doom9.org/showthread.php?p=691095#post691095
This can be easily done manually, but...
mkvinfo (or mkvextract) timecode file.mkv -o v2.tm

Hmm yeah, I'll do that. Anyway, use this for --output-charset and -o:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050803-7.rar

[Mosu]

On another matter.

There has always been an issue with mkvmerge's handling of B frames if external timecode files were used. Up until yesterday the order of timecodes in a v2 timecode file had to match how B frames were timestamped, and other timecode file formats weren't useful at all because they screwed up the order of timecodes. For example, the simple frame sequence IPBBP... at 25 FPS required a timecode file like this:

# timecode format v2
0
120
40
80
...

I've fixed mkvmerge now so that it assigns timecodes properly. But this means that timecodes in v2 format files have to be ordered now. For the same example above you now need this file:

# timecode format v2
0
40
80
120
...

The advantage is clear: You do now need to know which frames are what prior to creating such a file. The disadvantage is that old timecode files will not work with mkvmerge >= 1.5.1 (which will be released shortly) anymore. But the advantage clearly outweighs the disadvantage. I will probably include a warning if the timecodes from a v2 file are not ordered, so that users might actually see that there's something wrong ;)

The tool that you, Liisachan, wants for extracting timecodes would of course take this into account and re-order the timecodes as they're read from the Matroska file before outputting them so that mkvmerge will not complain.

[Liisachan]

Hmm yeah, I'll do that. Anyway, use this for --output-charset and -o:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050803-7.rar

Thanks for your swift work.
Test results:

mkvinfo -o def.txt = Worked fine, Windows Code Page
mkvinfo --output-charset UTF-8 -o utf8.txt = Worked fine, without BOM

So, practically everything is now possible, but I tested UTF-16 too, and these --output-charset don't work, giving me an almost blank output file.
UTF-16, UTF-16LE, UTF-16BE, UCS-2

And "--output-charset UTF16" will give me this message:

Warning: Could not initialize the iconv library for the conversion from UTF16 to UFT-8. Some strings will not be co
nverted to UTF-8 and the resulting Matroska file might not comply with the Matroska specs (error: 22, Invalid argum
ent).
Warning: Could not initialize the iconv library for the conversion from UFT-8 to UTF16. Some strings cannot be conv
erted from UTF-8 and might be displayed incorrectly (error: 22, Invalid argument).

Maybe iconv doesn't like "UTF16" and it wants a hyphen ("UTF-16")

[Liisachan]

On another matter.

# timecode format v2
0
120
40
80
...

...For the same example above you now need this file:

# timecode format v2
0
40
80
120
...
If all that's needed is 0 120 40 80 --> 0 40 80 20 conversion, technically mkvmerge could just automatically "sort" the timestamps in increasing order, couldn't it?
Afaik, avi2timecode.exe outputs timestamps in increasing order even if the input AVI has b-vops (so mkvmerge1.5.1-compatible?)

[Mosu]

Thanks for your swift work.
Test results:

mkvinfo -o def.txt = Worked fine, Windows Code Page
mkvinfo --output-charset UTF-8 -o utf8.txt = Worked fine, without BOM

Ah yes, the BOM. Hmm... I'll have to add that somehow.

So, practically everything is now possible, but I tested UTF-16 too, and these --output-charset don't work, giving me an almost blank output file.

Yeah. Unfortunately wide char output does not work anywhere in mkv*. Changing that would require some big changes. If I really wanted to do it right I'd use wide strings everywhere instead of UTF-8 coded normal strings. I didn't do that because older gcc versions contained a VERY nasty bug totally preventing the use of wide strings. And changing everything now is... well... a huge task. So for the moment I won't do that. Sorry.

And "--output-charset UTF16" will give me this message:

Warning: Could not initialize the iconv library for the conversion from UTF16 to UFT-8. Some strings will not be co
nverted to UTF-8 and the resulting Matroska file might not comply with the Matroska specs (error: 22, Invalid argum
ent).
Warning: Could not initialize the iconv library for the conversion from UFT-8 to UTF16. Some strings cannot be conv
erted from UTF-8 and might be displayed incorrectly (error: 22, Invalid argument).

Maybe iconv doesn't like "UTF16" and it wants a hyphen ("UTF-16")

Correct. iconv only knows the versions with the hyphen, and I simply pass the string the user enters to iconv.

[Mosu]

If all that's needed is 0 120 40 80 --> 0 40 80 20 conversion, technically mkvmerge could just automatically "sort" the timestamps in increasing order, couldn't it?

Correct, and that's how I've implemented this feature now.

Afaik, avi2timecode.exe outputs timestamps in increasing order even if the input AVI has b-vops (so mkvmerge1.5.1-compatible?)

That is definitely 1.5.1-compatible. So avi2timecode doesn't have to be changed at all (which is good news indeed).

If you want to try out mkvextract's new timecodes_v2 mode then please download (... waiting for the build to finish ...) http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050803-8.rar


The command line should be something like mkvextract timecodes_v2 input.mkv 1:timecodes-track1.txt 2:same-for-track-2.txt

Basically just like the format for the "tracks" extraction mode.

[Liisachan]

I think if you really need to output in UTF-16, you can easily convert UTF-8 to 16 by yourself. (But that's what I just think without knowing the inside of mkv*)

If you want to try out mkvextract's new timecodes_v2 mode then please download (... waiting for the build to finish ...) http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050803-8.rar


The command line should be something like mkvextract timecodes_v2 input.mkv 1:timecodes-track1.txt 2:same-for-track-2.txt as a starter I tested it for a clip with a constant frame rate (23.976fps), but the out put is like
0.000000
42.000000
83.000000

Shouldn't it be
0.000000
41.708375
83.416750
if the fractional part (<1ms) matters...?

[Mosu]

as a starter I tested it for a clip with a constant frame rate (23.976fps), but the out put is like
0.000000
42.000000
83.000000

Shouldn't it be
0.000000
41.708375
83.416750
if the fractional part (<1ms) matters...?

No. I mean yes, that would be correct if the Matroska file in question used nano-second precision for timecodes, but usual Matroska files only use milli-second precision. Audio-only files use sample precision.

[Rayek]

Threads like this one keeps adding to the utter crapability of threads like this one. (http://www.tokyotosho.com/forums/viewtopic.php?t=524) Keep up the good work.

[Mosu]

Threads like this one keeps adding to the utter crapability of threads like this one. (http://www.tokyotosho.com/forums/viewtopic.php?t=524)

Ah yes, GUTB. The one whose first post was such a nice insult to.. well me, effectively. I love suck folks :)

Keep up the good work.

I'm definitely trying to :)

[Mosu]

mkvinfo --output-charset UTF-8 -o utf8.txt = Worked fine, without BOM

It'd be nice if you tried http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050803-9.rar which does include a BOM. Actually I've implemented --output-charset and --redirect-output (as it is now called, not --output anymore, because that is used by mkvmerge for the output Matroska file already) (or short "-r") for all three programs. It might have broken something, though, but I hope it didn't.

Please be careful that you don't download builds after -9 for the time being because I'm experimenting with different wxWidgets versions, and the newer builds that will pop up will be linked against those and won't work with the runtime files that are available.

[Pirks]

I've got a couple of .mov files from a friend, both made in QuickTime 7.0 on his Mac, both with H.264 video and AAC 5.1 audio. Since I don't own a Mac and QuickTime 7.0 for Windows is not very usable at the moment, plus eats almost 100% of CPU while playing these files back, I decided to remux them in Matroska. I downloaded mkvtoolnix 1.5.0 for Windows, Unicode build (I use WinXP) and loaded these .mov files in mmg. They loaded OK, showed two tracks, avc1 video and mp4a audio. The trouble starts when I try to mux these tracks in mkv. So, I set the output file name and then press "Start muxing" button. I do not change any other options, everything is left at default. The muxing window appears and then there's a message immediately printed in the "Warning" pane, saying: "Warning: Quicktime/MP4 reader: The audio track 2 is using an unsupported 'object type id' of 0 in the 'esds' atom. Skipping this track." The resulting mkv is playable, but of course without sound. Well, actually one of these files won't play even video after remuxing, but let's focus on the audio problem for now. I can provide you with more info, or even send you a sample of that file, or its audio track, if you are interested. I don't know yet how to demux AAC 5.1 stream from .mov made by QT 7, and I don't know how to split those mov's, but I'll ask around on doom9 forums if demuxing or cutting a sample for you is necessary.

[Mosu]

The muxing window appears and then there's a message immediately printed in the "Warning" pane, saying: "Warning: Quicktime/MP4 reader: The audio track 2 is using an unsupported 'object type id' of 0 in the 'esds' atom. Skipping this track."

Hmm, I've never had my fingers on a Quicktime file with AAC inside. So yes, it'd be great if you could upload such a file to my FTP server (see my signature).

[thana]

hi mosu!

great to hear that you have some time again for coding (and actually having fun while doing it). and as you said you are looking into new wxwidgets versions anyway, i would like to make a suggestion for mmg:

i think that it would be way more logical for the settings and the chaptereditor to be in seperate windows instead of tabs. as it is right now, it is a bit confusing for first time users that loaded chapters in the chaptereditor are not gonna ending up in the muxed file, and that the chaptereditor actually has no logical connection with the rest of the gui.. by removing 'settings' and 'chaptereditor' and making them available in seperate windows f.e. via entries in the file menu, all tabs that are left then (input, attachments, global) are the ones which actually belong to the muxing-process.. and this is still the main purpose of mmg and should be as straight forward as possible.. i know its probably a lot of work, and not really necessary for the regular users of mmg (as they most probably know these things), but it would actually simplify mmg and make it more accessible for 'newbies'..

what do you think about this?

[Liisachan]

It'd be nice if you tried http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050803-9.rar which does include a BOM. Actually I've implemented --output-charset and --redirect-output (as it is now called, not --output anymore, because that is used by mkvmerge for the output Matroska file already) (or short "-r") for all three programs. It might have broken something, though, but I hope it didn't.

Please be careful that you don't download builds after -9 for the time being because I'm experimenting with different wxWidgets versions, and the newer builds that will pop up will be linked against those and won't work with the runtime files that are available. mkvtoolnix-unicode-1.5.0-build20050803-9.rar and after -9...
you sure work a lot :D
And yes, now the file generated with --output-charset UTF8 has BOM.
Actually, when I said "I got a UTF-8 without BOM" I just reported the fact and I didn't mean "there should be BOM." Although BOM is generally good to reduce ambiguity...

EDIT:
mkvinfo file1.mkv --output-charset UTF-8 > info.txt
gives me CR+CR+LF at the end of each line. Weird. Looks like Windows standard IO service gets in my way, adding an extra CR to each line... Anyway, im going to use -o always, not > nor >> since I don't believe Windows.

[Pirks]

Hmm, I've never had my fingers on a Quicktime file with AAC inside. So yes, it'd be great if you could upload such a file to my FTP server (see my signature).

Just uploaded file oops.mov, muxed in QuickTime 7.0 on a Mac, H.264 video and AAC 5.1 audio. Keep us posted how things are going, I'd really love to get rid of QT movies on my machine. Thanks in advance!

[Mosu]

i think that it would be way more logical for the settings and the chaptereditor to be in seperate windows instead of tabs.

I fully agree. Making the chapter editor "just" another tab was a decision I've come to regret. But I'm not willing to spend that much time with wxWidgets anymore as there are things that have ticked me off time and again.

However, at the moment I'm working with Qt at work, and I'm enjoying it. As Qt 4 also has a GLP port for Windows I'm inclined to port mmg from wxWidgets to Qt 4 in the near future. If I do that (actually I've already started doing the main dialog) then the chapter editor will be in a separate window. Until then I will probably not change it.

[Mosu]

mkvtoolnix-unicode-1.5.0-build20050803-9.rar and after -9...
you sure work a lot :D

Nah. I was just trying to nail a bug that only occured on Windows. But I don't have a development environment on this Windows computer. So I compile on my server, create a new build, download it and test it here on Windows. This accounts for at least half of those builds ;)

And yes, now the file generated with --output-charset UTF8 has BOM.
Actually, when I said "I got a UTF-8 without BOM" I just reported the fact and I didn't mean "there should be BOM." Although BOM is generally good to reduce ambiguity...

Maybe you didn't, but I did think that there should be a BOM :)

EDIT:
mkvinfo file1.mkv --output-charset UTF-8 > info.txt
gives me CR+CR+LF at the end of each line. Weird. Looks like Windows standard IO service gets in my way, adding an extra CR to each line... Anyway, im going to use -o always, not > nor >> since I don't believe Windows.

Ok, so I'll ignore this for the time being. If it bothers you then tell me to fix it.

[Mosu]

Just uploaded file oops.mov, muxed in QuickTime 7.0 on a Mac, H.264 video and AAC 5.1 audio. Keep us posted how things are going, I'd really love to get rid of QT movies on my machine. Thanks in advance!

Thanks. I'll see what I can do.

[Liisachan]

Ok, so I'll ignore this for the time being. If it bothers you then tell me to fix it. Will you try to check if this is something that can be fixed easily? Personally, I could say I wouldn't mind, but obviously you broke something, since this simple commandline:
mkvinfo file.mkv > info.txt
doesn't work anymore on my Win2K as it did (you get CR CR LF as EOL), even without the --output-charset.

[Skaarj]

Forsed subtitles are planned in the near future?

And reproduction simultaneously two sound tracks (the original + translation)?

[Mosu]

Will you try to check if this is something that can be fixed easily? Personally, I could say I wouldn't mind, but obviously you broke something, since this simple commandline:
mkvinfo file.mkv > info.txt
doesn't work anymore on my Win2K as it did (you get CR CR LF as EOL), even without the --output-charset.

That's very strange, because I get the normal CR LF here on Windows XP with cmd.exe and the latest from the pre-directory.

Ah wait, you're right. That's interesting... Will check it.

[Mosu]

Sorry, Liisachan, but Windows is doing stuff that I simply cannot understand. If the only thing I do in my program is

fprintf(stdout, "test\r\n");

and redirect this into a file then it still ends up as CR CR LF just like you saw. Maybe there is something I can do about it, but I don't know what it is.

[Liisachan]

It sounds like fopen("w") vs. fopen("wb")
In ASCII mode or fopen("w"), Windows converts \n to \r\n, hence \r\n to \r\r\n

[Mosu]

It sounds like fopen("w") vs. fopen("wb")
In ASCII mode or fopen("w"), Windows converts \n to \r\n, hence \r\n to \r\r\n

It's not like I fopen stdout myself ;) But I can fix that.

[Mosu]

Everyone creating timecode files please read http://forum.doom9.org/showthread.php?t=98573 Thanks

[thana]

i found two files which can't be read by latest mkvmerge:
>mkvmerge -i G:\Quake4Multi.mp4

Error: Quicktime/MP4 reader: Invalid chunk size 2 at 92.the file can be played without problems with haali-splitter+ffdshow and mplayer/vlc

the other:
>mkvmerge -i G:\Quake4cycle1.mov

Error: File G:\Quake4cycle1.mov has unknown type. Please have a look at the supported file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <moritz@bunkus.org> if your file type is supported but not recognized properly.this one can be played too with quicktime and mplayer. the fourcc seems to be 'JPEG', which is some 'Microsoft - Motion JPEG DIB Format'

i uploaded both files on your ftp

[Mosu]

i found two files which can't be read by latest mkvmerge:
the file can be played without problems with haali-splitter+ffdshow and mplayer/vlc

the other:
this one can be played too with quicktime and mplayer. the fourcc seems to be 'JPEG', which is some 'Microsoft - Motion JPEG DIB Format'

i uploaded both files on your ftp

Fixed file recognition for both files. The first one can now be muxed normally. The second cannot because Motion JPEG tracks are not supported by mkvmerge (nor specified for Matroska if I'm not mistaken).

Please download this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050813-1.rar

[Pirks]

Please download this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050813-1.rar

Is the AAC 5.1 demuxing bug fixed in that build?
Just checking, maybe I should also download and try it :-)

[Mosu]

Is the AAC 5.1 demuxing bug fixed in that build?
Just checking, maybe I should also download and try it :-)

You mean the oops.mov sample? No, it isn't. Those two issues I've fixed were unrelated.

[Mosu]

Is the AAC 5.1 demuxing bug fixed in that build?
Just checking, maybe I should also download and try it :-)

You can download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050814-1.rar which should work with such files now.

[Mosu]

It sounds like fopen("w") vs. fopen("wb")
In ASCII mode or fopen("w"), Windows converts \n to \r\n, hence \r\n to \r\r\n

Ok, you can try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050816-1.rar if you want :)

[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...
glad if that is fixed now :)
i'll test more later, but mkvtoolnix seems to be quite stable now...

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

[Mosu]

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]

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]

Ok, you can try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050816-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]

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]

Ok, you can try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050816-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.php?p=699924#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]

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]

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]

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]

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

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/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.0-build20050818-1.rar

[Pirks]

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]

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]

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/mkvtoolnix/sources/mkvtoolnix-1.5.5.tar.bz2
...the Windows Unicode binaries:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-1.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]

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]

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]

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]

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]

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

[buzzqw]

Hi Mosu

can you take a look at this thread (http://forum.doom9.org/showthread.php?p=702738&)

(is for adding raw h264 to matroska)

Thanks for your attention :thanks:

BHH

[lrms]

What about MPEG-4 ASP inside mkv?
Don't we have the same problems when muxing from AVI, at least when b-frames are used?
Can one force MPEG-4 ASP also to use a "native mode" inside mkv?? It seems the CodecID used is always V_MS/VFW/FOURCC instead of V_MPEG4/ISO/ASP.

Thanks

[thana]

Can one force MPEG-4 ASP also to use a "native mode" inside mkv??
yes you can with '--engage native_mpeg4' on the commandline or via 'add commandline options' in mmg..

but it's not recommended because it breaks compatibility with gabest's splitter for playback and virtualdubmod for editing.. it should work without problems with haali's splitter (don't know about mplayer/xine/vlc).

[azsd]

To Mosu
bad link report - file not found:
MKVToolnix v1.5.5 runtime (Unicode)

[lrms]

@thana

Thanks for the tip. Well I tried it, but as you said, it did cause a lot of problems:

MPC (6.4.8.4) with internal or Haali splitter (2005-08-18) and ffdshow (2005-08-03) -> plays movie, but with a huge audio delay
mplayer (2005-08-13) -> plays only sound (doesn't recognize CodecID)
VLC media player (0.8.2) -> crashes

[Pirks]

To Mosu
bad link report - file not found:
MKVToolnix v1.5.5 runtime (Unicode)

I'm not Mosu, but...

Do you have mkvtoolnix runtime installed?

mkvtoolnix consists of two packages, one is mkvtoolnix itself and the other is mkvtoolnix runtime. Make sure you have runtime downloaded and unpacked into mkvtoolnix directory.

[Mosu]

What about MPEG-4 ASP inside mkv?
Don't we have the same problems when muxing from AVI, at least when b-frames are used?
Can one force MPEG-4 ASP also to use a "native mode" inside mkv?? It seems the CodecID used is always V_MS/VFW/FOURCC instead of V_MPEG4/ISO/ASP.

Thanks

Yes, it is possible with "--engage native_mpeg4". I don't make this the default for several reasons:

Until this release this function was very buggy. It still isn't bug-free as Haali has already sent me another file for which it breaks.
Most players and filters do not really support native ASP storage yet. This includes Gabest's splitter, unfortunately. I/we should work on getting support for playback integrated into at least some of the Linux players first.
We decided very early that using the VfW compatibility mode for ASP was OK and the official way at least until native storage was solid enough to be made the standard for new files. We will not discontinue support for those files, ever.

[Mosu]

To Mosu
bad link report - file not found:
MKVToolnix v1.5.5 runtime (Unicode)

Ups, thanks, fixed.

[Mosu]

I'm not Mosu, but...

Do you have mkvtoolnix runtime installed?

mkvtoolnix consists of two packages, one is mkvtoolnix itself and the other is mkvtoolnix runtime. Make sure you have runtime downloaded and unpacked into mkvtoolnix directory.

Yeah, you don't have to re-download the runtime if you still have it -- it hasn't changed since the 1.4.0 release (hence the file name, mkvtoolnix-runtime-unicode-1.4.rar). Or just use the installer which includes all necessary files.

[MeteorRain]

* 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.
/me cries loudly
Have waited this feature for thousands of minutes. ;)

great thanks. and now i can put x264+vfr+subtitle into mkv XD

[Mosu]

/me cries loudly
Have waited this feature for thousands of minutes. ;)

great thanks. and now i can put x264+vfr+subtitle into mkv XD

:) I just hope that it works correctly. I don't have a lot of VFR content available for testing, but it _should_ be OK.

[lrms]

Yes, it is possible with "--engage native_mpeg4". I don't make this the default for several reasons:

Until this release this function was very buggy. It still isn't bug-free as Haali has already sent me another file for which it breaks.
Most players and filters do not really support native ASP storage yet. This includes Gabest's splitter, unfortunately. I/we should work on getting support for playback integrated into at least some of the Linux players first.
We decided very early that using the VfW compatibility mode for ASP was OK and the official way at least until native storage was solid enough to be made the standard for new files. We will not discontinue support for those files, ever.

Thanks for the info - now I don't feel so bad creating mkvs with VfW ASP streams :)

[Pirks]

A minor suggestion to Mosu, regarding mmg help baloons.

I was muxing my "Sin City" DVD rip yesterday. I ripped bitmap subs with Gabest's tool and tried to mux these VobSubs in. When I hovered my mouse over subtitle compression field in mmg, it displayed short note about compression methods available, saying that zlib is default and "none" compression is a bad idea (yeah, for VobSub bitmap subs it's a bad idea indeed). mmg offered other compression methods for VobSubs, such as bz2 and some others. However, here's the catch: I tried bz2 compression and found that Haali splitter does not support any VobSubs compression besides zlib. Seems like it's the case for Gabest Matroska splitter as well. It might be a good idea for Mosu to add a short note to the compression method help baloon in mmg, saying someting like "only zlib is currently supported, make sure you know what you're doing if you use anything else - bz2, etc."

BTW when I chose bz2 I got slightly BIGGER .mkv file than the one with zlib. Now that's really weird... bz2 supposed to be better than zlib.

[Mosu]

It might be a good idea for Mosu to add a short note to the compression method help baloon in mmg, saying someting like "only zlib is currently supported, make sure you know what you're doing if you use anything else - bz2, etc."

Indeed a good idea.

BTW when I chose bz2 I got slightly BIGGER .mkv file than the one with zlib. Now that's really weird... bz2 supposed to be better than zlib.

Back when we decided which compression algorithm to use I wrote tests for zlib, bz2 and lzo1x (all free). lzo1x is definitely hat the least CPU usage but the worst compression with bz2 usually being the other way round and zlib taking the middle in both cases. However, one thing we have to do is compress each subtitle block independently from the others so that seeking to arbitrary subtitle entries works (and you don't have to uncompress entries before them, too). This seriously hurts the compression ratio. So if you compress e.g. the original .sub file with BZ2 then you'll definitely get a noticable smaller file than one compressed with gzip. But the differences in compressed size between the three in "Matroska mode" were neglilible. So we chose the "old and trustworthy and widely spread" zlib algorithm.

[MeteorRain]

:) I just hope that it works correctly. I don't have a lot of VFR content available for testing, but it _should_ be OK.
i've tested a video, x264 with 16b-frames, pyraid, adaptive, and so on.

avc video + aac audio + timecode v1 + ssa subtitle * 2 => MKV

works perfectly. XD

thanks and regards XD

[Liisachan]

Hey Mosu, about this message you get when you try to mux AVC-in-AVI into MKV:


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.


MP4Box can't import AVC-in-AVI to MP4.

http://sourceforge.net/tracker/index.php?func=detail&aid=1189633&group_id=84101&atid=571741

Acutally, it was like this:

mp4box.exe -add avc.avi -new avc.mp4
Video format H264 not supported - recompress the file first
Error: Feature Not SupportedError importing :Path\to\avc.avi
Feature Not Supported


My question is, what is the best way to handle AVC-in-AVI?
About new files, I can just make it as MP4 from the begining, but there are a few existing files, and as mentioned above, I can't convert them into MP4 either...

[Doom9]

why do people feel the need to put avc in avi when they want to go for another format? I think avi2raw from the mpeg4ip project would do the extraction just fine.. I recalling that once back in the day before I figured AVI was a bad thing for AVC.

[Liisachan]

why do people feel the need to put avc in avi when they want to go for another format? I think avi2raw from the mpeg4ip project would do the extraction just fine.. I recalling that once back in the day before I figured AVI was a bad thing for AVC.
Personally I'm ok with MP4 (thanks to your MeGUI :D)
I don't think they really like AVI (if not why MKV?), but many people want to use VirtualDub(mod) and hence VfW.

[Doom9]

well, in case of VirtualDubMod, it puts AVC into MKV the AVI (actually VfW) way with all its drawbacks. Unless VDM gets an upgrade that supports native mode (kinda unlikely considering there's no development at all and it might not be that simple), the app isn't such a good solution for Matroska anymore. Just another reason why there needs to be another non VfW based editor (imho the main reason why people use VirtualDub and AVI)

[Mosu]

My question is, what is the best way to handle AVC-in-AVI?

People told me that if you first extract AVC from AVI with e.g. the program Doom9 mentioned in his reply to you then you'll get an AVC elementary stream that MP4Box can import. Then you can mux from this MP4 to MKV.

I will implement reading AVC elementary streams soon ( = in the next four weeks, hopefully). Then muxing AVC from AVI should work, too.

[Liisachan]

Extracting .h264 should work one way or another, but I have no luck so far.
The bottom line is, I will use x264.exe, not VfW. Like Doom9 said, it's pointless to use AVI when transmuxing it into MKV.

Anyway this doesn't work:

C:\test>avi2raw60 avc.avi avc.m4v
avi2raw60 - mpeg4ip version 1.3.6
avi2raw60: warning: 3 zero length frames ignored
2214 video frames written

It says 3 frames were dropped. I guess because I used 3 consecutive b-frames and apparently avi2raw60 doesn't know the hack used by x264vfw... And even if I ignore the 3 frames mp4box doesn't like the above output.

C:\test>mp4box -add avc.m4v -new avc.mp4
MPEG-4 Video import - 0 x 0 @ 25.0000 FPS
Indicated Profile: Simple Profile @ Level 1
Import results: 0 VOPs (0 Is - 0 Ps)
Converting to ISMA Audio-Video MP4 file...
Adjusting visual track size to 0 x 0
Saving avc.mp4: 0.500 secs Interleaving

C:\test>mkvmerge -o test.mkv avc.mp4
mkvmerge v1.5.5 ('Another White Dash') built on Aug 21 2005 15:40:13
'avc.mp4': Using the Quicktime/MP4 demultiplexer.
Warning: Quicktime/MP4 reader: Track 201 is missing some data. Broken header atoms?
Warning: 'avc.mp4': No tracks will be copied from this file. This usually indicates a mistake in the command line.

Error: No streams to output were found. Aborting.

I tried mp4creator too. mp4creator is a bit kind, saying "This is not recommended due to the use of b-frames" but in the end it says "mp4creator: video compressor x264 not recognized"...

I asked VLC Player too to transmux my AVI to MP4, but the resulted file was broken. So my impression now is, almost nobody knows the hack used by x264vfw...perhaps the only exception is ffdshow.

[Doom9]

avi2raw60 avc.avi avc.m4vavi2raw60 is ooooold. Download an up-to-date mpeg4iptools package from celtic-druid: http://www.aziendeassociate.it/cd.asp?dir=/mpeg4iptools
Then you're using the wrong extension.. mp4box recognizes the input type by its extension.. raw ASP has to be .m4v, raw AVC must be .264.

[Liisachan]

Thanks for the tip, it worked now, after I renamed .m4v to .264
MP4 is 3 frames shorter, but the dropped are the last 3 frames (not the frist 3 frames nor random 3 frames) and lucily they happen to be the sequence of meaningless black frames.

Oh, btw didn't you see this part?

C:\test>avi2raw60 avc.avi avc.m4v
avi2raw60 - mpeg4ip version 1.3.6

It's very new--even newer than the newest version on the page you mentioned (that is 1.3.5 as of writing). I know it was renamed, but celtic_druid's 1.3.6cvs has avi2raw"60"

--edit
I tried 1.3.5 too just in case, but the 3 frames will be dropped no matter what. They are unimportant frames in this case tho.
I've also noticed that I need -fps switch unless the video is 25.0fps.
so, for reference, the commandline I used is:

avi2raw avc.avi raw.264
mp4box -fps 23.976 -add raw.264 avc.mp4
mkvmerge -o output.mkv avc.mp4

[stephanV]

The three dropped frames are empty chunks at the beginning of the avi file needed for the b-frame encoding delay and you will lose the last three frames because effectively those frames are never received by your encoding app (again, due to the delay).

[Liisachan]

I've suddenly realized that maybe I should use MP4 too even when I'm encoding with XviD, if the final target format is MKV. I think mkvmerge will accept MPEG-4 Part2 Video in MP4 and at least Haali Splitter (and perhaps MPC) will play it too. I should test that later to see the upsides and downsides...

@stephanV: I see. Thanks for info. But can't the encoder (x264) add 3 null frames at the end of the clip when it decides to put the 'empty chunks at the beginning of avi file'?

[Mosu]

I've suddenly realized that maybe I should use MP4 too even when I'm encoding with XviD, if the final target format is MKV. I think mkvmerge will accept MPEG-4 Part2 Video in MP4

It does :)

[celtic_druid]

Guess I usually rename avi2raw. I was in somewhat of a hurry Friday night when I compiled/released 1.3.6.

[stephanV]

I've suddenly realized that maybe I should use MP4 too even when I'm encoding with XviD, if the final target format is MKV. I think mkvmerge will accept MPEG-4 Part2 Video in MP4 and at least Haali Splitter (and perhaps MPC) will play it too. I should test that later to see the upsides and downsides...
I don't see how it would matter... muxing from MP4 still would use the VFW mode and Native mode is supported from AVI as well. (Mosu can correct me if I'm wrong. :) )

@stephanV: I see. Thanks for info. But can't the encoder (x264) add 3 null frames at the end of the clip when it decides to put the 'empty chunks at the beginning of avi file'?
It could, but it doesn't.

Note that the empty chunks are placed at encoding start, not end. It's the well known 1 frame in - 1 frame out restriction of VFW that causes it. Basically VirtualDub starts feeding x264 with frames, but x264 needs to buffer to make it possible to encode b-frames. While x264 is buffering it outputs 0 byte frames (or nothing) so 0 byte frames is what VirtualDub will write. When VirtualDub is done feeding x264 all frames it quits, and the frames that are still in x264's buffer will stay forever in Limbo. (those are the missing frames).

So basically 2 things need to be done:

1. VirtualDub needs to know when x264 is finished with buffering, so it starts to write the file at the right time, and
2. VirtualDub shouldn't quit after it is finished feeding all frames, but when x264's buffer has been emptied.

This will probably require a few work arounds on both ends.

I don't consider the empty chunks at the beginning a very big problem though, they can quite easily be removed, and for the last few missing frames... don't care about that either.

But since you are going to MKV, I would seriously consider using x264cli with MKV-output. It saves you quite some steps. :)

[Mosu]

I don't see how it would matter... muxing from MP4 still would use the VFW mode and Native mode is supported from AVI as well. (Mosu can correct me if I'm wrong. :) )

That's correct. For ASP ( = MPEG-4 part 2) the VfW mode is the default one, regardless of the source container (AVI, OGM, MP4). The native mode is only enabled with "--engage native_mpeg4" or if you're remuxing a native ASP track from a Matroska file.

For AVC things are different.

[Liisachan]

I don't see how it would matter... muxing from MP4 still would use the VFW mode and Native mode is supported from AVI as well. (Mosu can correct me if I'm wrong. :) ) It was just a sudden random thought, and I said maybe. This morning (my time), I was a purist somehow thinking "B-Frames in AVI are evil" after seeing those 3 frames are dropped. Yes, I was kinda shocked, honestly.

That's correct. For ASP ( = MPEG-4 part 2) the VfW mode is the default one, regardless of the source container (AVI, OGM, MP4). The native mode is only enabled with "--engage native_mpeg4" or if you're remuxing a native ASP track from a Matroska file.

For AVC things are different. thanks for the clarification, so, what you are saying in a nutshell is that XviD-in-AVI is a "well-established" hack supported by every tool and we don't have to worry about anything, right?

edit:
@stephanV: Personally I don't mind using x264.exe directly, the problem is not just AVI vs MP4, x264.exe is more powerful, and MeGUI is more convenient (for instance when you want to use the Main Profile)... I had already made up my mind that I wouldn't use x264VfW anymore. Still I was interested how I could convert AVC-in-AVI to AVC-in-MP4, partly out of curiosity, but I think this experience will help me a lot in some cases in the future.
Thanks a lot, anyway...

[Isochroma]

When I mux xvid mp4 natively, media player classic 6.4.8.4 cannot recognize the stream anymore?

[Mosu]

thanks for the clarification, so, what you are saying in a nutshell is that XviD-in-AVI is a "well-established" hack supported by every tool and we don't have to worry about anything, right?

That is 100% correct.

[Mosu]

I created a native xvid mp4 from an xvid avi using mp4box. However, after I've muxed it into MKV using mkvmerge 1.5.0, the properties box shows the Codec ID as:

V_MS/VFW/FOURCC

Why is it being muxed as vfw and not natively?

I've given reasons a couple of posts ago. The quick version is:

a) compatibility (not all splitters/players support it),
b) until 1.5.5 it was very buggy (I've already fixed another bug that's still present in 1.5.5),
c) like Liisachan put it "it's a well-established hack that is supported by every tool out there". Again compatibility.
d) native ASP storage doesn't give a lot of pros compared to VfW mode storage at the moment.

[#2]

Hi guys every time I try to appened my end credits to the main film I get this error. In fact every time I try to append anything it fails.

mkvmerge 1.55
windows xp sp2
rmvb format tracks
useing Auto rv10 7.1 update to encode the rmvb streams

I'm sure this used to work in 1.40 or arround there :?

[Mosu]

Any return code > 2 is a crash. Please upload the files somewhere, e.g. on my FTP server. Thanks.

[Mosu]

Heya guys,

here we go! I consider this release to be a "major bugfix" release. There were a lot of issues that I was finally able to track down or that were simply new bugs I didn't know about before. So I strongly advise to upgrade to this version.

However, AVC aspect ratio info handling has been changed (see the ChangeLog below for details), and it's quite possible that new bugs have introduced in the process.

Here are the typical links...
...to the home page:
https://www.bunkus.org/videotools/mkvtoolnix/
...the source code:
https://www.bunkus.org/videotools/mkvtoolnix/mkvtoolnix-1.5.6.tar.bz2
...the Windows Unicode installer:
https://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-1.5.6-setup.exe

All the other packages are/will be available from the home page.

The ChangeLog since 1.5.5:
-----------------------------------------------------------------
2005-09-06 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: If the user selected an aspect ratio for a video track, then chose "File -> new", added a file, selected another video track and chose the same aspect ratio as before then it wasn't added to the command line. Fixes Anthill bugs 132 and 146.
* mkvmerge: bug fix: Support Qt/MP4 files with 64bit offset tables ('co64' atom instead of 'stco' atom).

2005-09-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will remove the aspect ratio information from a AVC/h.264 video track bitstream and put it into the display dimensions (until now the AR information was kept on the bitstream level). The reason is that in Matroska the container AR is supposed to take precedence over bitstream AR, but some decoder programmers ignore the container AR in favour of bitstream AR.

2005-08-31 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: The GUI couldn't open files with non-ASCII chars in the file name.

2005-08-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Display dimensions were reported for all tracks, even if they weren't present. In that case they allegedly were "0x0" which caused mmg to add "--display-dimensions ...:0x0" for each track read from a Matroska file, even if the tracks were not video tracks.

2005-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The extracted timecodes were wrong for blocks with laced frames.

2005-08-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If a Matroska file with a MPEG-4 part 2 video track was muxed into a Matroska file and the source file did not contain the display width/height elements for that track then the aspect ratio was extracted from the video data itself which clashes with the Matroska specs which say that display width/height default to the pixel width/height if they're not present.

2005-08-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Native MPEG-4 ASP storage was still bugged: timecodes were assigned twice, frames referenced themselves.
* mkvmerge: bug fix: Embedded fonts and pictures in a SSA/ASS file are not discarded any longer. They are converted to Matroska attachments instead. Other sections that were discarded are added to the CodecPrivate data as are "Comment:" lines in the "[Events]" section. Those comment lines still lose their association for which "Dialogue:" line they were meant, but that cannot be changed.

2005-08-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: --delay was not working at all.
* mkvmerge: bug fix: Single digit numbers followed by 's' were not recognized as valid numbers with a unit (e.g. in '--delay 0:9s').
-----------------------------------------------------------------

Have fun :)

[Pirks]

* mkvmerge: bug fix: Support Qt/MP4 files with 64bit offset tables ('co64' atom instead of 'stco' atom).
Have fun :)

Where is my portion of fun, Mosu? :-) I thought that 'co64' bug was mine but it was not. So where is my big fat ugly 'oops.mov' bug? :)

[Liisachan]

Other sections that were discarded are added
to the CodecPrivate data as are "Comment:" lines in the "[Events]"
section. Those comment lines still lose their association for
which "Dialogue:" line they were meant, but that cannot be
changed.


The Actor field is all empty in the demuxed ASS. Is this a known limitation, by desing, or a bug? If this can't be fixed, maybe we should include every single SSA/ASS muxed into MKV redundantly as attachments.

[Mosu]

The Actor field is all empty in the demuxed ASS. Is this a known limitation, by desing, or a bug? If this can't be fixed, maybe we should include every single SSA/ASS muxed into MKV redundantly as attachments.

Quoting the Matroska codec specs for SSA/ASS:

Events are stored in the Block in this order: ReadOrder, Layer, Style, Name, MarginL, MarginR, MarginV, Effect, Text (Layer comes from ASS specs ... it's empty for SSA.) "ReadOrder field is needed for the decoder to be able to reorder the streamed samples as they were placed originally in the file.

So yes, it is a limitation. You can of course attach the ssa/ass file in each case. It was never my intention that you could first mux and then demux ssa/ass into Matroska and out again without any losses because that is simply not possible (and not wanted either).

[Mosu]

Where is my portion of fun, Mosu? :-) I thought that 'co64' bug was mine but it was not. So where is my big fat ugly 'oops.mov' bug? :)

That one's still broken, yes :(

[Liisachan]

Quoting the Matroska codec specs for SSA/ASS:
Events are stored in the Block in this order: ReadOrder, Layer, Style, Name, MarginL, MarginR, MarginV, Effect, Text (Layer comes from ASS specs ... it's empty for SSA.) Ah, then probably it's a kind of bug...or rather, the specs are not clear enough. Name in SSA is sometimes called Actor in ASS, but they are totally the same thing. You can (and should) store ASS's Actor just like SSA's Name. The only difference is the name of the filed. It may be called Name or Actor but anyway it's the 6th Field, essentially the same thing.

Edit: Examples

Dialogue: Marked=0,0:00:00.00,0:00:00.00,Style1,Alice,0000,0000,0000,,This is SSA.
Dialogue: Marked=0,0:00:00.00,0:00:00.00,Style1,Bob,0000,0000,0000,,"Alice" and "Bob" = "Name"

Dialogue: 0,0:00:00.00,0:00:00.00,Style1,Alice,0000,0000,0000,,This is ASS.
Dialogue: 0,0:00:00.00,0:00:00.00,Style1,Bob,0000,0000,0000,,"Alice" and "Bob" = "Name" or "Actor"

[Mosu]

You can (and should) store ASS's Actor just like SSA's Name.

Ah ok, that's easy. I'll be away until Sunday, though, so no fix before the end of the weekend.

[Mosu]

Where is my portion of fun, Mosu? :-) I thought that 'co64' bug was mine but it was not. So where is my big fat ugly 'oops.mov' bug? :)

Now at least I know what's wrong. Your file uses edit lists which are not supported by mkvmerge. Edit lists can tell the player ('demuxer' would be more accurate) which frames to use. I'll add a check so that mkvmerge will abort if edit lists are in use because correct muxing is not guaranteed in such cases.

I might add support for edit lists at some point, but not right now.

[Liisachan]

str += _T("[Events]\n");
str += (et == EXTSSA)
? _T("Format: Marked, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text\n")
: _T("Format: Layer, Start, End, Style, Actor, MarginL, MarginR, MarginV, Effect, Text\n");
f.WriteString(str);
From: http://cvs.sourceforge.net/viewcvs.py/guliverkli/guliverkli/src/subtitles/STS.cpp?view=markup

There is a sample SSA generated by Subresync in [matroska-devel] proposed storage of ssa/ass (http://lists.matroska.org/pipermail/matroska-devel/2003-May/000571.html). If the same file is saved as ASS with the same Subresync, you'd see "Actor"

[Mosu]

You can (and should) store ASS's Actor just like SSA's Name.

Try
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.6-build20050909-1.rar

I'm off for the weekend now :)

[Liisachan]

Ah ok, that's easy. I'll be away until Sunday, though, so no fix before the end of the weekend. Thank you. There are a few things that are not well-documented, or not compatible with the written specs (ass-specs.doc): of course it's not your fault :)

[Liisachan]

Try
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.6-build20050909-1.rar

I'm off for the weekend now :) Have fun :)
Tested your quick build, and it worked fine except one tiny unimportant cosmetic problem.


G:\>mkvmerge -o test.mks test.ass
mkvmerge v1.5.6 ('Breathe me') built on Sep 7 2005 18:18:02
...
G:\>mkvextract tracks test.mks 1:demuxed.ass
...
G:\>diff -U 1 test.ass demuxed.ass
--- test.ass 2005-09-09 18:05:00.755625000 +0900
+++ demuxed.ass 2005-09-09 18:05:53.708750000 +0900
@@ -22,2 +22,3 @@
Format: Layer, Start, End, Style, Actor, MarginL, MarginR, MarginV, Effect, Text
+
Dialogue: ...
One empty line is added between the "Format" header and the first "Dialogue" line. No real problem.

OT: imo it's important that you can demux and reuse the data once stored in the container. That's what flexibility/usability means, isn't it? I don't like a "one-way" container where you can put things into but you can't get things out of. Demuxing doesn't necessarily have to be bit-identical, but a significant part like Name/Actor shouldn't be lost.

Being reusable is important in creation. My dream is a GPL-like "open-sub" development. Reusing (retranslation from English to French for instance) would be easier with Names, than without them.

[_E_]

Hi there.

I've been trying to produce a vfr matroska. First of all, I produced the timecodes, chapter file and audio needed. Then I encoded the video using MeGUI into a mp4 file. I've checked it out and it works absolutly fine. However, when I add it in mkvmerge ( along with the audio/timecodes/chapter files), the resultant mkv file doesnt play. I tried encoding the same file again using MeGUI to mkv then add it to mkvmerge...the result is still the same.

At the end, I had to restore to vfw avi x264 output and force mkvmerge to accept it ( I've used the command line --engage allow_avc_in_vfw_mode ) and the resultant mkv file did work. However, I am not aiming to use vfw AVC due to it's limitations/current bugs. Is there any way I can add native AVC mkv/mp4 files on mkvmerge , or are these still not supported for some reason?

I appologize if this was a redundant question.

[jellysandwich]

At the end, I had to restore to vfw avi x264 output and force mkvmerge to accept it ( I've used the command line --engage allow_avc_in_vfw_mode ) and the resultant mkv file did work. However, I am not aiming to use vfw AVC due to it's limitations/current bugs. Is there any way I can add native AVC mkv/mp4 files on mkvmerge , or are these still not supported for some reason?

I appologize if this was a redundant question.

What version are you using? I have no problems handling native AVC with Mkvtoolnix 1.5.6.

js

[LeMoi]

Could you make that we dit the output filename and press enter, the muxing process start ?

[_E_]

What version are you using? I have no problems handling native AVC with Mkvtoolnix 1.5.6.

js

I am using MkvToolsNix 1.5.6

[stephanV]

Are you using the correct timecode file format? (you must use v2 i believe)

[_E_]

I am using v1 timecode ( always worked for me before). But even when I don't use a timecode file nor an audio file, the resultant mkv file still doesn't play. :(

[Liisachan]

Are you using the correct timecode file format? (you must use v2 i believe)

How about the v3 thing? (I don't know what exactly it is though)

I am using v1 timecode ( always worked for me before). There was a major change related to Timecode in 1.5.x. Maybe that's why.
http://forum.doom9.org/showpost.php?p=694472&postcount=69

[iapir]

Timecode files v3 are the easiest ones when dealing with VFR, because it's human readable :D

[_E_]

I dunno, v1 is pretty readable for me....or maybe that's because I am getting blind ;) j/k

Anyways, it turned out to be a splitter problem, updating it with the build available on Jarod's page made the video play again.

[Mosu]

Have fun :)
Tested your quick build, and it worked fine except one tiny unimportant cosmetic problem.

Great :) I can live with an extra empty line, and so should everybody else ;)

OT: imo it's important that you can demux and reuse the data once stored in the container. That's what flexibility/usability means, isn't it?

True, and you can demux a SSA file. But for a lot of formats you will never be able to demux to a bit-identical file. Just think of putting VFR content from Matroska into AVI. Bit identical? No way.

Same for SSA. Bit identical? Nope, there may be empty lines. For SSA it's even worse: comment lines are still stored in CodecPrivate, but they lose their position among the dialogue lines during muxing. Will that be fixed? No. Why? Because Matroska is not meant as a lossless container for everything (including data that's not needed for playback). The only "container formats" that keep source files 100% intact are archivers like ZIP, RAR etc.

I don't like a "one-way" container where you can put things into but you can't get things out of. Demuxing doesn't necessarily have to be bit-identical, but a significant part like Name/Actor shouldn't be lost.

True, and Name/Actor was clearly a bug in mkvmerge.

[Mosu]

Could you make that we dit the output filename and press enter, the muxing process start ?

Sure, I just hope I don't forget about it ;)

[Doom9]

I took the liberty of changing the thread title to reflect the latest version.. mkvtoolnix 1.5.0 is rather old by now.

[jellysandwich]

Mosu, would it be possible for you to add a "remove all" button for the input files?

js

[Liisachan]

Isn't Ctrl+N enough?

[foxyshadis]

I was thinking how it seems mmg would be the perfect place to add a mkv demuxer. Right click on the track, or have a button below "down" for demux.

Obviously for mp4, rm, and some other video formats a translation to AVI isn't always feasible, but for the most part video frames can be pulled right out of mkv and inserted into avi, and I believe most audio formats could be simply demuxed or written into a wave container as well. For the goofy formats, a raw bitstream fallback would be used.

Maybe just an idea for a future version of mkvtoolnix, but it'd sure be nice to not have to hit up the command-line every time I need to rip the audio track or transfer video to another container to edit.

[LeMoi]

So maybe MKVExtractGui is for you ;)
http://corecodec.org/projects/mkvextractgui/

[foxyshadis]

Interesting. I'd still like to have an all-in-one, but that's a nice alternative, with a few minor nitpicks.

[jellysandwich]

Isn't Ctrl+N enough?

Not really. I'd like to keep the Output filename and File/segment title so that I could simply change the number in them instead of having to type/paste them for every single episode.

js

[#2]

In fact every time I try to append anything it fails.

1.56 dosen't work, 1.41 dose, 1.42 dosen't. Hope that helps.

[Pirks]

Your file uses edit lists which are not supported by mkvmerge. I'll add a check so that mkvmerge will abort if edit lists are in use because correct muxing is not guaranteed in such cases.

I have uploaded another small sample to your ftp, named oops_remux.mov. It's the same fragment as oops.mov, except I have remuxed it in QuickTime. The video and the audio streams are the same as in oops.mov as well. And, quite important, I think it also has edit list atom. If you check both oops.mov and oops_remux.mov you'll see that they both contain atom "elst" which is QuickTime's edit list atom. Just do string search, elst is there in both files, and even with the same offset, 0x11C.

Now, if you try to remux oops_remux.mov in mmg you will see that mkv you get on output contains BOTH video and audio. Haali sees both streams, plays them smoothly, everything works great. Unlike oops.mov, which was losing video track after remuxing by mkvmerge.

The question is: why mkvmerge loses video track in oops.mov and does not lose video track in oops_remux.mov? Is this because of edit list or the edit list by itself is not enough?

If presence of edit list by itself is enough to force mkvmerge lose the video track, why then oops_remux.mov contains elst (i.e. edit list) atom AND gets remuxed into mkv with BOTH tracks, without a hitch? Isn't that a contradiction?

[Mosu]

If presence of edit list by itself is enough to force mkvmerge lose the video track, why then oops_remux.mov contains elst (i.e. edit list) atom AND gets remuxed into mkv with BOTH tracks, without a hitch? Isn't that a contradiction?

It's not a contradiction. The thing is that mkvmerge does not lose the video track at all! Even remuxing oops.mov resultings in a file containing both video and audio. But for oops.mov the video track contains one garbage frame at the beginning which the edit list says to skip. mkvmerge simply ignores edit lists and does not skip that first "frame".

Upon playback the codec/player/whatever tries to decode that garbage, failes, and won't display anything. Hence your thought that there's no video track in the MKV to begin with.

Now your remuxed file might still contain an edit list but in this case the first frame that mkvmerge muxes is actually the first "real" frame of the video, so playback works.

Edit list atoms are simply ignored and sometimes not necessary for playback.

[Mosu]

Mosu, would it be possible for you to add a "remove all" button for the input files?

No. Technically it is possible, of course, but I won't implement that, sorry. Ctrl-n should be enough. mmg has too many features as it is already.

[Mosu]

I was thinking how it seems mmg would be the perfect place to add a mkv demuxer. Right click on the track, or have a button below "down" for demux.

Won't happen, sorry. Too many features in mmg already.

[foxyshadis]

Won't happen, sorry. Too many features in mmg already.
That's fine. In that case I'll work with the creators of mkvextract to fix a few things instead.

[Mosu]

Hi guys every time I try to appened my end credits to the main film I get this error. In fact every time I try to append anything it fails.

This should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.6-build20050915-1.rar

[#2]

Thanks Mosu :)

[lrms]

I've found a small bug in mkvmerge GUI v1.5.6 in the chapter editor.
If you add double quotes (") in chapter titles (like: The Mission is a "Go") after you save and reload the XML file, mmg crashes. The workaround I've found is simple: I've just used single quotes instead (').

[Mosu]

I've found a small bug in mkvmerge GUI v1.5.6 in the chapter editor.
If you add double quotes (") in chapter titles (like: The Mission is a "Go") after you save and reload the XML file, mmg crashes. The workaround I've found is simple: I've just used single quotes instead (').

You've indeed found a bug, but it wasn't " vs '. mmg crashes if you do this:

Create new chapters, add a subchapter, chose a name + start time.
Save those chapters in XML format.
Chose "Chapter Editor -> New".
Reload the saved chapters. mmg will now crash.

However, if you restart mmg and load the XML file save earlier it works OK. So it's not the file.

Unfortunately I haven't found out what the problem is yet... I'll keep working on it.

[LeMoi]

When i extract idx/sub from an mkv file, most of the time, i have at least 5 subs which are not extracted correctly : their timestamps are not extracted correctly, they disappear before they appear :s

[Mosu]

When i extract idx/sub from an mkv file, most of the time, i have at least 5 subs which are not extracted correctly : their timestamps are not extracted correctly, they disappear before they appear :s

Are those entries OK when they're inside the MKV?

[LeMoi]

Yes, they are OK inside the original mkv, and after extraction and remux in another mkv, these entries are no more

[Mosu]

Yes, they are OK inside the original mkv, and after extraction and remux in another mkv, these entries are no more

Ok, definitely a bug in mkvextract then. Could you please upload that file to my FTP server into the subdirectory "bug-152" that I've already created along with a text file containing the timecodes that are wrong? I don't need all the timecodes that are wrong, three or so should suffice.

Thanks.

[LeMoi]

Hmm, it's a 700MB file... i'll try and split the moment where they are wrong

[m_yas]

I want to create matroska file with few subtitles but with no default subtitle track. But, if I set no default track, the first track become default during mkvmerge'ing. Is it a bug, or there is some way to assemble matroska file with no subtitles by default?

[Liisachan]

There is a workaround: Mux an "empty" SRT or SSA as the 1st subtitle track (and make it the default sub for sure). You can set the track name for it "no subtitles"

[Mosu]

I want to create matroska file with few subtitles but with no default subtitle track. But, if I set no default track, the first track become default during mkvmerge'ing. Is it a bug, or there is some way to assemble matroska file with no subtitles by default?

That's not a bug because you misunderstand the meaning of the "default" flag. It's meaning is that if the user wants to see subtitles and the user hasn't chosen a specific subtitle track for playback then this track should be chosen. It does not mean that the player should definitely play this subtitle track, forcing the playback on the user even if he doesn't want it.

[Elic]

Mosu
> It does not mean that the player should definitely play this subtitle track, forcing the playback on the user even if he doesn't want it.
Hmm... I use LightAlloy player with MatroskaSplitter and VSFilter, and player shows subtitles every time when I try to play .mkv file with subtitle track(s). But today I tried to clear default flag of subtitle track in .mkv using hex editor (I got offset based on output of "mkvinfo -g" and then replaced nearby byte with value 01 by 00) - and I got exactly I want to have (and maybe the same m_yas is asking for): matroska with no subtitles by default; and when I played that file, MatroskaSplitter's subtitles menu looks as usually - "English", "Russian", "No subtitles", with last choice marked.

So, can you please add "--no-default-subtitles" option to mkvmerge? It will be very useful for people who like to embed many subtitles but don't like to see it by default :)

Also, I have few more questions:
a) After I dig into .mkv file with hex editor and altered some bytes, neither mkvinfo nor mkvmerge nor HaaliSplitter have noticed that file content changed and probably some CRCs don't match, no error messages appear, no changes in player's behaviour (except default subtitle changed), etc. Does this mean that matroska files have no CRC protection of such a vital part as track descriptors?
b) Tell me please what player should allow user to switch subtitles on without choosing subtitles track exactly (i.e. "subs on" instead of "subs select"); the only place I have noticed show/hide switch is vsfilter's context menu, but IMHO it is not very comfortably to switch subs on/off in one menu and then select proper subs in other place (in MatroskaSplitter's context menu).

[Koti]

So, can you please add "--no-default-subtitles" option to mkvmerge? It will be very useful for people who like to embed many subtitles but don't like to see it by default :)
.
you have missed one of the greatest features of Haali's splitter , the ability to flag no subtitle display if your native or prefered language is available in the file.
Options / languages / Audio and Subtitles languages.
Example (eng,off;*,eng) english audio present , no subtitles will show ; any language besides english , eng subtitles will be prefered.
Of course you can set a multitude of preferances here

not to mention complete audio, subtitle, and chapter control all in one place thru the tray icon.

[Elic]

Koti
> one of the greatest features of Haali's splitter [...] Example (eng,off;*,eng)
"I know." (c) J.B.E. Zorg :) But this feature is nearly unacceptable to me because of specific Russian mentality :) of people who translate movies into Russian or Ukrainian (in particular, on Ukrainian TV). You see, there are at least four kinds of Russian (and/or Ukrainian, of course) translations:
- original sound with subtitles;
- dubbing;
- so-called "voice-over" translation (one nasal voice translates all characters simultaneously, with delay about few seconds) as separate track;
- mix of original and voice-over sounds (IMHO the worst kind of track).
I like native Russian and Ukrainian and good dubbings; I tolerate separate voice-overs; but I hate "voice-over" mixes - especially Ukrainian voice over Russian and Polish soundtrack, in that case I prefer to hear native track and see subtitle translation.

But all that kinds of translated soundtracks usually marked as "Russian" (or "Ukrainian", respectively). So I cannot rely upon language settings of MatroskaSplitter, and at least I need some kind of additional tagging burned into each matroska file; IMHO "defaul flag" maybe sufficient for this purpose, isn't it?

Another kind that maybe helpful is "forced subtitles", but I don't know how to implement it by means of Matroska and SRT... :(

[Mosu]

Mosu
So, can you please add "--no-default-subtitles" option to mkvmerge? It will be very useful for people who like to embed many subtitles but don't like to see it by default :)

I'll add that somehow, even if I'm supporting broken player support that way.

Also, I have few more questions:
a) After I dig into .mkv file with hex editor and altered some bytes, neither mkvinfo nor mkvmerge nor HaaliSplitter have noticed that file content changed and probably some CRCs don't match, no error messages appear, no changes in player's behaviour (except default subtitle changed), etc. Does this mean that matroska files have no CRC protection of such a vital part as track descriptors?

Correct.

[Mosu]

When i extract idx/sub from an mkv file, most of the time, i have at least 5 subs which are not extracted correctly : their timestamps are not extracted correctly, they disappear before they appear :s

What about that sample file I asked for? Can you provide one?

[LeMoi]

Hum, sorry, i didn't have time this week, i'll try and up it this week-end...

[lcld]

Found 2 bugs :

1. (minor bug) mkvmerge freezes on a 1-frame avi file. Command used:
$ mkvmerge -o 1.mkv 1.avi (http://alainmuchembled.free.fr/Doom9/1.avi)

2. For V_MS/VFW/FOURCC, mkvextract discards extra private bytes of the BITMAPINFOHEADER structure, so it can't be used for tracks encoded with, for example, Huffyuv or Arithyuv.
$ mkvmerge -o 2.mkv 2.avi (http://alainmuchembled.free.fr/Doom9/2.avi) && mkvextract tracks 2.mkv 1:2\'.avi

[Mosu]

Found 2 bugs :
...


Should both be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.6-build20051004-1.rar

[Mosu]

I've just released the next mkvtoolnix version, 1.6.0. It's another bug fix release, and I definitely recommend to update.

The usual links...
...to the home page: http://www.bunkus.org/videotools/mkvtoolnix/
...the source code: http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-1.6.0.tar.bz2
...the Windows Unicode binary: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-1.6.0-setup.exe

Here's the ChangeLog since 1.5.6:
-------------------------------------------------------------------
2005-10-14 Moritz Bunkus <moritz@bunkus.org>
* Released v1.6.0.

2005-10-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented the new header removal compression: compression for native MPEG-4 part 2, decompression for all types (don't use it yet, folks!).

2005-10-04 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Extra codec data wasn't written to AVI files if it was present (e.g. for the HuffYuv codec). Fixes bug 157.
* mkvmerge: bug fix: mkvmerge was choking on AVIs with a single frame inside. Fixes bug 156.

2005-09-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Changed how AVC video frames are referenced. This is not ideal yet, but at least references are kept intact when reading AVC from Matroska files. Should fix bug 154.

2005-09-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Appending AVC video tracks was broken if they contained aspect ratio information that the user overwrote on the command line.
* mmg: bug fix: If a video track was selected that was appended to another track then the aspect ratio drop down box was still active.
* mkvmerge: new feature: MPEG-4 part 2 streams are searched for the pixel width/height values. Those are taken if they differ from those values in the source container. This is a work-around for buggy muxers, e.g. broken video camera firmwares writing bad MP4 files. Fixes bug 149.

2005-09-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Appending files with RealVideo was broken.

2005-09-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: bug fix: ASS files sometimes use a column called 'Actor' instead of 'Name', but both should be mapped to the 'name' column in a Matroska file.
-------------------------------------------------------------------

Have fun :)

[foxyshadis]

Can you tell me what this means?
* mkvmerge: new feature: Implemented the new header removal compression: compression for native MPEG-4 part 2, decompression for all types (don't use it yet, folks!).

I know it's something experimental, I'm just curious. ;)

[Liisachan]

I was wondering about that too, and found this explanation:
[Matroska-devel] Compression track 3 (http://lists.matroska.org/pipermail/matroska-devel/2005-October/002751.html)

To make a long short, I understand that you can make your mkv file a bit smaller without losing the quality at all (in other words, higher quality in the same size), which might be nice especially in very low bitrate encoding. But since the changelog says "native MPEG-4 part 2" perhaps it's not yet ready for MPEG-4 part 2 in AVI?

[Skaarj]

I can`t append two tracks in mmg 1.6.0 (x264 in mkv), previous version works fine.

Error: The file no. 0 ('D:\01.mkv') does not contain a track with the ID 0, or that track is not to be copied. Therefore no track can be appended to it. The argument for '--append-to' was invalid.

[iapir]

try Track ID 1 ? Or use MMG and check the track ID it uses.

[Mosu]

We're playing around with some stuff at the moment. Compression 3 (or header removal) removes a fixed amount of bytes (more like a fixed set of bytes) from the start of each frame on muxing and prepends those bytes to each frame on demuxing. This only works with codecs that actually start each and every frame with the same byte sequence, of course.

Now this is not really working in mkvmerge at the moment. Demuxing should work, but muxing not yet. Therefore: don't use it :)

[LeMoi]

When I try to mux x264 in mp4 with he-aac tracks and sub tracks, it crashes at the end :
mkvmerge v1.6.0 ('Ist das so') built on Oct 14 2005 15:22:21
'G:\Rip\Nouveau dossier\film.video.mp4': Using the Quicktime/MP4 demultiplexer.
'G:\Rip\Nouveau dossier\VTS_07_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Français - DELAI 0ms.ra': Using the RealMedia demultiplexer.
'G:\Rip\Nouveau dossier\VTS_07_1 - 0x81 - Audio - AC3 - 6ch - 48kHz - DRC - English - DELAI 0ms.ra': Using the RealMedia demultiplexer.
'G:\Rip\Nouveau dossier\sub.idx': Using the VobSub subtitle reader (SUB file 'G:\Rip\Nouveau dossier\sub.sub').
'G:\Rip\Nouveau dossier\film.video.mp4' track 1: Using the MPEG-4 part 10 (AVC) video output module.
'G:\Rip\Nouveau dossier\VTS_07_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Français - DELAI 0ms.ra' track 0: Using the AAC output module (FourCC: racp).
'G:\Rip\Nouveau dossier\VTS_07_1 - 0x81 - Audio - AC3 - 6ch - 48kHz - DRC - English - DELAI 0ms.ra' track 0: Using the AAC output module (FourCC: racp).
'G:\Rip\Nouveau dossier\sub.idx' track 0: Using the VobSub subtitle output module (language: fr).
'G:\Rip\Nouveau dossier\sub.idx' track 1: Using the VobSub subtitle output module (language: fr).
The file 'G:\Rip\Nouveau dossier\film.video.mkv' has been opened for writing.
mkvmerge FAILED with a return code of -1073741676
same error number at every try
No problem with latest 1.5.6 beta :s

[Mosu]

When I try to mux x264 in mp4 with he-aac tracks and sub tracks, it crashes at the end :
...
same error number at every try
No problem with latest 1.5.6 beta :s

Do you have the same problem on all muxes? What happens if you only mux one of those source files? Which file causes the crash? Do you mean mkvtoolnix-unicode-1.5.6-build20051004-1.rar with "latest beta"?

[LeMoi]

Do you have the same problem on all muxes?
Sorry I didn't try antyhing else, i don't have similar files to mux
EDIT : i tried with .ra alone, containing he-aac, no problem

What happens if you only mux one of those source files? Which file causes the crash?
Without the video and with all other tracks, it crashes
With the video and without audio tracks, it's OK
With the video and with only one audio track (english or french), it crashes. Idem with only audio tracks.
The muxing of the audio track alone (no sub, no title, no chaps, etc.) is OK

Do you mean mkvtoolnix-unicode-1.5.6-build20051004-1.rar with "latest beta"?
Yes, this one

[Mosu]

Without the video and with all other tracks, it crashes
With the video and without audio tracks, it's OK
With the video and with only one audio track (english or french), it crashes. Idem with only audio tracks.
The muxing of the audio track alone (no sub, no title, no chaps, etc.) is OK

Hmm, interesting. Could you please upload the audio files to my FTP server? Unfortunately too much has changed in the source code between the latest 1.5.6 build and the 1.6.0 release, so I can't just pinpoint the error without a test file.

Thanks.

[LeMoi]

It's on your ftp

[omion]

Mosu -

I notice that the default codec ID for .aac files is "A_AAC/MPEG2/LC [/SBR] ". However, I'm fairly certain that my .aac file is an MPEG4 AAC. I used Winamp's new HE-AAC converter, which only outputs .aac files. Using Foobar's MP4 converter and feeding that into MMG results in an MPEG4 codec ID (which would make sense, as it is in an MPEG4 container). Two questions:
1. Is there any difference between playback of MPEG2 and MPEG4 AAC?
2. Is there any way to force the codec ID to "A_AAC/MPEG4/LC/SBR"?

I'm using 1.6.0 on Windows XP.

[Isochroma]

Will it soon be possible to insert WMV and ASF into MKV using your tools? This feature would be really nice to have, so thanks in advance if you can implement it!

[Haali]

Will never happen. ASF format is patented and MS allows its use only when you commercially license it. WMV from avi already works though in vfw compatibility mode.

[stephanV]

You can do this using gabests muxer in graphedit.

[Mosu]

It's on your ftp

Thanks, will take a look this weekend.

BTW: I hate it when I don't receive those "new replies in thread" mails from this board :(

[Mosu]

Mosu -

I notice that the default codec ID for .aac files is "A_AAC/MPEG2/LC [/SBR] ".

mkvmerge extracts the MPEG version and the profile from the codec private data for AAC. For raw ADTS AAC files the header contains a bit which says whether it's supposed to be MPEG-4 or MPEG-2.

However, I'm fairly certain that my .aac file is an MPEG4 AAC. I used Winamp's new HE-AAC converter, which only outputs .aac files. Using Foobar's MP4 converter and feeding that into MMG results in an MPEG4 codec ID (which would make sense, as it is in an MPEG4 container).

The container (MP4) has nothing to do with it. Maybe it's a bug in Winamp's HE-AAC converter?

Two questions:
1. Is there any difference between playback of MPEG2 and MPEG4 AAC?

Dunno about the technical differences, but in my experience it doesn't really matter.

2. Is there any way to force the codec ID to "A_AAC/MPEG4/LC/SBR"?

No.

However, some time ago we decided that coding the format in the CodecID was a stupid decision, and we introduced A_AAC which contains the 2, 3 or 5 bytes of codec initialization data in CodecPrivate just like MP4 contains them. I'm not certain if all the usual players already support this, but I guess I should switch to using A_AAC in the near future.

[Mosu]

Will it soon be possible to insert WMV and ASF into MKV using your tools? This feature would be really nice to have, so thanks in advance if you can implement it!

No. Haali has already given the reason.

[Mosu]

It's on your ftp

Thanks, but your file works fine. Haven't you said something about two audio tracks? I need all files that cause mkvmerge to crash. You said that adding the two audio tracks would cause the crash; those would be prefereable to uploading the video track I guess.

[LeMoi]

It didn't happen only one time... it wasn't because of the video (without video, no problem), maybe it was because of the sub files WITH audio...

[OCedHrt]

This thread is reallly long...anyways, to pipe output from mkv using the command prompt on 2k/XP, you need to run the command prompt with the /u parameter.

I'm having a problem with using timecodes to split files. I have a timecode ( 01:11:24.918251585 ) that I want to use for which it says the format is invaild. Works without the nanoseconds.

[pcjco04]

With version 1.6.0 I have never been able to use append ( MP4 AVC in MKV + MP4 AVC in MKV).

It always throw this message :
Error: The file no. 0 ('output.mkv') does not contain a track with the ID 0, or that track is not to be copied. Therefore no track can be appended to it. The argument for '--append-to' was invalid.

The command line is :
mkvmerge -o output.mkv --language 1:eng --default-track 1 --display-dimensions 1:5x2 -d 1 -A -S 1.mkv -d 1 -A -S +2.mkv --track-order 0:1 --append-to 1:1:0:0


The version 1.5.6 works because the command line for the same process is different :
mkvmerge -o output.mkv --language 1:eng --default-track 1 --display-dimensions 1:5x2 -d 1 -A -S 1.mkv -d 1 -A -S +2.mkv --track-order 0:1 --append-to 1:1:0:1

[Mosu]

With version 1.6.0 I have never been able to use append ( MP4 AVC in MKV + MP4 AVC in MKV).

I can reproduce this problem here. Unfortunately it only occurs on Windows, and those are the hardest bugs to track down for me. So please be patient until I get it fixed.

[Egh]

I can reproduce this problem here. Unfortunately it only occurs on Windows, and those are the hardest bugs to track down for me. So please be patient until I get it fixed.

Bug confirmed :P i.e. i have same error message trying to append avc streams from mp4 files.

Also, from MMG's log:

'G:\1\negima.2\all2.2.d2v.mp4': Using the Quicktime/MP4 demultiplexer.
'G:\1\negima.2\avc.ppend.mp4': Using the Quicktime/MP4 demultiplexer.
'G:\1\negima.2\all2.2.d2v.mp4' track 3: Using the MPEG-4 part 10 (AVC) video output module.
Track 3 of 'G:\1\negima.2\avc.ppend.mp4': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 720/480.
'G:\1\negima.2\avc.ppend.mp4' track 3: Using the MPEG-4 part 10 (AVC) video output module.

Commandline is "mkvmerge" -o "G:\1\negima.2\all2.2.d2v.mkv" --aspect-ratio 3:4/3 -d 3 -A -S G:\1\negima.2\all2.2.d2v.mp4 -d 3 -A -S +G:\1\negima.2\avc.ppend.mp4 --track-order 0:3 --append-to 1:3:0:0

I wonder why one of the tracks has "and set the display dimensions to 720/480" despite using user-configured AR. Is it OK or bug as well? (Similar to the one I reported long ago in 1.5.6).

[ChronoCross]

I have a slight problem with the latest version when trying to use vfr timecodes. If it has a packed bitstream for some reason it says it's 5 minutes longer than it is in playback. However the vfr works fine and it plays correctly and never loses sync. Just the total time of the video is wrong. any suggestions?

[foxyshadis]

Add an extra line to the end of your timecode file, something just higher than the last line. Use 40 ms or 33 ms if you want to keep it consistent but it doesn't matter.

Some frame is getting chopped off between the timecode generation and the encode, you might want to check that out, but if it's just one frame (and you don't chop long swaths via dedup like me) it doesn't really matter.

[thana]

i found a bug in mmg 1.6.0 on winxp: during muxing i ran out of space on the drive, and mmg stated mkvmerge FAILED with a return code of 2. There were ERRORs. but didn't show any message in the error box. when i copied the command and ran it from the commandline, mkvmerge showed the error message: Error: Cound not write to the output file: 112 (Es steht nicht genug Speicherplatz auf dem Datentr i tried some older versions of mmg and i appears that it worked correctly in 1.4.2 and broke with 1.5.0. i can't confirm it with warnings or other errors because i don't know how to force any other of them.

and a few minor nitpicks i discovered during testing of this bug: as you can see from the error above there is a typo (Cound -> Could) and it looks like mkvmerge truncates the windows error-message as it encounteres an umlaut. and when you save the log from mmg's muxing window it writes them with unix-style linebreaks (0x0A) instead of DOS-style linebreaks (0x0D 0x0A), this looks very messy in notepad.

[OCedHrt]

With version 1.6.0 I have never been able to use append ( MP4 AVC in MKV + MP4 AVC in MKV).

It always throw this message :
Error: The file no. 0 ('output.mkv') does not contain a track with the ID 0, or that track is not to be copied. Therefore no track can be appended to it. The argument for '--append-to' was invalid.

The command line is :
mkvmerge -o output.mkv --language 1:eng --default-track 1 --display-dimensions 1:5x2 -d 1 -A -S 1.mkv -d 1 -A -S +2.mkv --track-order 0:1 --append-to 1:1:0:0

The version 1.5.6 works because the command line for the same process is different :
mkvmerge -o output.mkv --language 1:eng --default-track 1 --display-dimensions 1:5x2 -d 1 -A -S 1.mkv -d 1 -A -S +2.mkv --track-order 0:1 --append-to 1:1:0:1

I just copy out the commandline, modify it, and run it in command prompt :P

[Mosu]

This issue...

With version 1.6.0 I have never been able to use append ( MP4 AVC in MKV + MP4 AVC in MKV).

and this issue...

and a few minor nitpicks i discovered during testing of this bug: as you can see from the error above there is a typo (Cound -> Could) and it looks like mkvmerge truncates the windows error-message as it encounteres an umlaut. and when you save the log from mmg's muxing window it writes them with unix-style linebreaks (0x0A) instead of DOS-style linebreaks (0x0D 0x0A), this looks very messy in notepad.

...have been resolved; maybe even the issue with the cut-off German error message. Please try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.0-build20051101-1.rar

[thana]

This issue... and this issue... have been resolved; maybe even the issue with the cut-off German error message. Please try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.0-build20051101-1.rarthx, everything works as expected.. only one last cosmetic error is left, when you start mkvmerge from the commandline the german error-message gets printed with the wrong codepage:Error: Could not write to the output file: 112 (Es steht nicht genug Speicherplatz auf dem Datentrõger zur Verf³gung.)it gets correctly printed in the mmg muxing window. but this is really not an issue so i wouldn't put too much time into fixing it.

another small problem i found is that mmg deletes the content of the clipboard when you hit the "copy to clipboard" button and immediately close mmg afterwards, so you can't paste the mkvmerge-commandline anymore. as long as mmg is open pasting works.

[pcjco04]

Working fine for me.

Thanks. :)

[Egh]

Not so fast :)

Same bug confirmed as in 1.5.6 pre Oct 4th version.

On attempt to mux in two avc streams from mp4 containers.

mkvmerge v1.6.0 ('Ist das so') built on Nov 1 2005 17:09:57
'G:\1\negima.2\base.mp4': Using the Quicktime/MP4 demultiplexer.
'G:\1\negima.2\all2.d2v.mp4': Using the Quicktime/MP4 demultiplexer.
'G:\1\negima.2\all2 T01 2_0ch 384Kbps DELAY 0ms.ogg': Using the OGG/OGM demultiplexer.
'G:\1\negima.2\subz\negima02.ass': Using the SSA/ASS subtitle reader.
'G:\1\negima.2\base.mp4' track 3: Using the MPEG-4 part 10 (AVC) video output module.
Track 3 of 'G:\1\negima.2\all2.d2v.mp4': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 720/480.
'G:\1\negima.2\all2.d2v.mp4' track 3: Using the MPEG-4 part 10 (AVC) video output module.
'G:\1\negima.2\all2 T01 2_0ch 384Kbps DELAY 0ms.ogg' track 0: Using the Vorbis output module.
'G:\1\negima.2\subz\negima02.ass' track 0: Using the text subtitle output module.
The file 'G:\1\negima.2\base.mkv' has been opened for writing.
Appending track 3 from file no. 1 ('G:\1\negima.2\all2.d2v.mp4') to track 3 from file no. 0 ('G:\1\negima.2\base.mp4').

'die' called: bref_packet == NULL. Wanted bref: -1614410304.


So ALL seems to go well, until the very end of muxing.

I'd suggest to revise any changes for (AVC) video output module made inbetween 1.5.6 18-3 build (which works absolutely fine from same mmg project) and 04 oct (i haven't tested 19 and 24 though).

full message is there (30KB, prints the whole content of a queue :)
http://rapidshare.de/files/7090903/mmg.output.txt.html

Can others confirm that? The mp4 files contain high-profile avc streams from Nero. b-frames and references used, of course.

[Mosu]

Not so fast :)

Same bug confirmed as in 1.5.6 pre Oct 4th version.

Two different things; the bug I've fixed yesterday was in mmg's code, this one is in mkvmerge's code.

Can others confirm that? The mp4 files contain high-profile avc streams from Nero. b-frames and references used, of course.

Happens for me, too, so no need to test it any further.

[Egh]

Two different things; the bug I've fixed yesterday was in mmg's code, this one is in mkvmerge's code.


yeah, i know. I only meant that there're still problems with append, though they are not releated to that mmg bug.

[mikeX]

Hello there, I'm having trouble compiling mkvtoolnix 1.6.0 on Debian Sarge. Even though I have libeblm-dev and libmatroska-dev installed (from your repository moritz) I get this error during ./configure:

...
checking for libmatroska version >= 0.7.5... yes
checking if linking against libmatroska requires -DMATROSKA_DLL... not found
*** libmatroska was not found.

And that's where it fails. I even tried installing libmatroska from source (built the debian packages), and still the same problem. The reason I want to test 1.6.0 is because I'm having trouble with some .ssa files, my current version (1.5.0) seems unable to recognise them as supported files, and I can't install the debian package (from testing or from your repository) because of unmet dependencies!

[Mosu]

mikeX: my packages are built for etch (sid). sid contains gcc 4.0. sarge uses 3.3. Those two are incompatible regarding their C++ ABI (application binray interface), so you can't use a C++ lib built with 4.0 ( = my packages) with gcc 3.3.

The solution is to rebuild the packages yourself:

apt-get remove libebml-dev libmatroska-dev
apt-get source libebml-dev libmatroska-dev
cd libebml-0.7.5
dpkg-buildpackage
dpkg -i ../libebml*deb
cd libmatroska-0.7.7
dpkg-buildpackage
dpkg -i ../libmatroska*deb

Replace the version numbers with the correct ones.

[issa]

When I try to mux x264 in mp4 with he-aac tracks and sub tracks, it crashes at the end :


same error number at every try
No problem with latest 1.5.6 beta :s

LeMoi,

Would you try this build to see if it fix the crash problem you have?
I am not sure if I fix the right place, please let me know if it work or not.
It is a unicode build.

URL: http://rapidshare.de/files/7378347/mkvtoolnix-1.6.0-20051109.7z.html

[mikeX]

That worked fine Mosu, thanks. I thought the error only had to do with libmatroska, so I didn't try backporting libeblm too. Turns out the problem with the ssa file had to do with a malformed header (missing opening bracket at the first line, weird how that happened). I could also upload you the backports for sarge if you are interested.

[Egh]

@Mosu:

about splitting stuff :) I use splitting quite often for patching (i.e. overwriting small parts of non-vfw avc streams. Luckily mkvtoolnix is far better for that purpose compared to mp4box :P).

So the little trouble I have is that I very often use VFR but I know *precisely* which frames to use as splitting points. Is there any possibility to have that functionality in mkvmerge? I.E. allow a list not of timecodes, but frame numbers?

Also please clarify which method mkvmerge uses for splitting (to get full GOP). Whenever it expands the interval or goes forward/backwards from each timecode ?