mkvmerge and avc streams

[thoralf]

hi mosu, hi all,

sorry for having to ask this, but what version of mp4box / avi2raw are you normally using to put h264 into mkv?
I was using the latest celtic_druid builds (mp4box: 0.4.1-dev, avi2raw: 1.4.4), which gave me a major headache: the audio and video of the resulting mkv was out of sync when using the x264->vdubmod->avi->raw->mp4 way.
on a related note, haalis demuxer (latest version) didn't like the resulting mkvs too much: it froze reproducible when extensively searching around in the files (okay, that's not to blame on mp4box / avi2raw).
using "--engage allow_avc_in_vfw_mode" worked like a charm, and - if i may say this - didn't break the workflow :-)

and a related question: did the pre-1.5 versions of mkvmerge use the vfw-compatibility mode? i have some avc-in-mkv i muxed with those, and i fear that they will become unplayable in the future ...

i'm putting this in a new thread since the mkvtoolnix ones are becoming unusable.

thanks in advance,
thoralf.

[jellysandwich]

I don't understand your question. What does mp4box and avi2raw have to do with mkvmerge?

I believe it used vfw compatibility mode, but only if you encoded via vfw. The only difference is that from 1.5 on, you needed to force it via commandline.

js

[thoralf]

hi jellysandwich,

sorry for not being very clear - i'll try again.

with recent versions of mkvmerge, it is not possible to mux a vfw-produced avc stream (read: made with virtualdubmod / gknot) into a mkv container unless you are forcing the compatibility mode. there are some posts by mosu floating around here in which he made it clear that one shouldn't take it for granted that mkvs muxed that way will be supported by future splitters or future versions of mkvmerge - so using this mode seems to be a no-go.
as you probably know, mkvmerge pops up a message suggesting the use of the raw -> mp4 workaround when you try to mux a vfw-avc. i tried this workaround yesterday, with said results (audio out of sync, searching in the muxed file less stable).

i am still searching for a reliable way to mux vfw-generated avc video streams into mkvs without using the compatitility mode. i'm somewhat reluctant to use megui or another gui frontend for the cli version of x264: vdubmod is a tried-and-tested application, and i consider .net to be a horrible bloat.

with kind regards,
thoralf.

[GodofaGap]

You don't need .net to run the CLI with a bat file, and it would save you 2 steps (avi2raw and mp4box). (And you would avoid the monthly GPAC weirdness as well ;) )

Really, the best way to get native AVC is *not* via VFW.

Coming back to the problem. You say you have desynch, but this can easily be corrected with the delay feature of MKVMerge. (or not?)

[jellysandwich]

Ok, I just tried muxing an avc-in-avi into mkv. I did it both ways, using "--engage allow_avc_in_vfw_mode" and mp4box (I used YAMB (http://yamb.unite-video.com/download.html) and mp4box (http://ffdshow.faireal.net/mirror/gpac/dev/), not avi2raw - sorry, I don't know the version numbers). Both of them worked fine; audio and seeking were normal.

i'm somewhat reluctant to use megui or another gui frontend for the cli version of x264: vdubmod is a tried-and-tested application, and i consider .net to be a horrible bloat.

If that's the case, then why are you using H264 at all? It's not very "tried-and-tested" either; it's still in development. And you can avoid using a frontend if you learn how to write your own command lines. :)

js

[foxyshadis]

You can extend that logical statement: AVC via virtualdub is a tried-and-tested failure which always causes subtle problems and occasionally spectacular failures, like this.

Although IMHO apps written in .net are less bloaty, more stable, and faster developed (that's why the big three are written in it), it's your choice; that's why SUPER and MkvMagic exist. They are less streamlined, but still more so than straight encoding via vdub.

[thoralf]

thank you all for your answers ... so i guess i'll have to make myself familiar with the command line version of x264. sigh.

godofagap: the desynch was caused by the avc-mp4 stream that was suddenly a few seconds shorter than its avi ancestor after going through the raw procedure.

jelly: just as a matter of interest, could you do a mp4box -v (or whatever switch gives the version number - can't look it up atm) ?

foxyshadis: muxing vdubmod-avc in compatibility mode has always worked like a charm for me. the resulting mkvs are playing fine with mplayer on linux, too.
i don't want to be overly picky here, but from my point of view it's dropping the comp. mode that causes problems here ... i understand that that this is due to the crappy nature of the vfw framework, but still: it's a de-facto standard.

[GodofaGap]

You did set the correct framerate when muxing with mp4box, right?

[jellysandwich]

041dev, same as yours.

js

[bond]

the mp4 files are shorter than the avi because the avc stream in the avi is shorter than the avi tries to tell you

open the avi in virtualdub and you will check that there are empty frames at the beginning

using vfw to encode to avi with avc and b-frames means lossing frames (at the end), thats why your stream is shorter

but this surely doesnt cause the desync

[GodofaGap]

It would take quite an idiotic number of consecutive b-frames to lose a couple of seconds due to this though... oh well.

[imcold]

thank you all for your answers ... so i guess i'll have to make myself familiar with the command line version of x264. sigh.

just use MeGUI or some of the other front-ends ;)

[thoralf]

i had another go. the vfw-avc-in avi is 1.24:53. after extracting the raw data and muxing into mp4 as suggested by mkvmerge ...
C:\DVD\Projects\THX_1138_VTS_01_PGC1>avi2raw "THX_1138.avi" raw.264
avi2raw - mpeg4ip version 1.4.4
avi2raw: warning: 2 zero length frames ignored
127327 video frames written

C:\DVD\Projects\THX_1138_VTS_01_PGC1>mp4box -fps 23.976 -add raw.264 avc.mp4
Adjusting AVC SizeLength to 16 bits
AVC-H264 import - frame size 704 x 288 at 23.976 FPS
Adjusting AVC SizeLength to 24 bits71/100)
Import results: 127327 samples - Slices: 6365 I 64715 P 56247 B - 1 SEI - 5390 I
DR
Stream uses B-slice references - max frame delay 2
Saving to avc.mp4: 0.500 secs Interleaving
... the length of the video stream is 1.28:30. When using -fps 25, I get the right length, minus the two frames swallowed by vfw. Strangely enough, when I tried -fps 25 last time, the resulting mp4 was only half the size it was supposed to have (but still had the right length displayed). If my memory serves me right, the "Adjusting AVC SizeLength to 24 bits" message didn't appear in this case.

so everything is fine now - thank you for your help.

with kind regards,
thoralf.