MKVToolNix 1.6.0 has been released

[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...