VfW-mode AVC/h.264 tracks vs. Native Matroska-mode AVC/h.264 tracks

[jellysandwich]

Could someone please explain the difference between vfw mode and native mode, and why native mode is preferred?

I tried google and wikipedia, but couldn't find anything (mostly because I dont know what keywords to search for).

js

[bond]

native mode is the way to store avc in mkv as defined in the mkv specs, anything else you need to know?

vfw mode is a special way for storing streams in mkv as some sort of "private stream" when going via the vfw codec interface (as used in virtualdub) meaning its nowhere defined how the stream is stored in the mkv

here a list about the downsides of vfw mode:
1) you will loose interoperability. if you dont use the native way its not ensured that your files will work with mkv tools meant to support avc following the specs.
placing avc in mkv the vfw way is like placing avc in some private not defined way in .mp4: its not ensured that the files will work anywhere

2) you will get decoding delays with any avc encoding mode not being support in vfw (that is b-frames, b-references or arbitrary frameorders without b-frames).
you will get a delay of 1 in case of b-frames plus 1 additional frame if b-pyramid is used (that is a delay of 80ms for a 25fps stream)

3) you will get an "encoding delay", so called delay frames into the stream. in the case of asp video they will break the compliancy of the video stream to the mpeg-4 standard, dunno if this is true for avc too.
that is an additional delay of 2 frames in the case of useage of 2 b-frames: 80ms (never tested how b-pyramid influences this, but surely not positively). i think the delay will be higher if you use more b-frames (eg 3 delay frames with 3 b-frames aso)

4) the framenumber of the stream will not be correct anymore. you will loose two frames in the case of using 2 b-frames (3 frames with 3 b-frames aso)

5) people will laugh at you if you use it ;)

[Sirber]

@bond

It's coz of #4 I implemented it in RealAnime ;)

[bond]

It's coz of #4 I implemented it in RealAnime ;)i thought you use x264cli?

moved to container forum

[Caroliano]

1) you will loose interoperability. if you dont use the native way its not ensured that your files will work with mkv tools meant to support avc following the specs. placing avc in mkv the vfw way is like placing avc in some private not defined way in .mp4: its not ensured that the files will work anywhere
If you use the native mode you will loose interoperability. If you use native mode way its not ensured that your files will work with older mkv tools that only suport avc in vfw mode, like virtualdubmod. So you have no escape, only define what tools you want to use.

Any way, for more detailed information of the b-frame delay thing you can read this (http://forum.doom9.org/showthread.php?t=80430), but it was for ASP, I don't know what changed.

And bond: :goodpost:

[bond]

If you use the native mode you will loose interoperability. If you use native mode way its not ensured that your files will work with older mkv tools that only suport avc in vfw mode, like virtualdubmod. So you have no escape, only define what tools you want to use.virtualdubmod is the only tool which suffers from this. and of course avc stored the vfw way in mkv will also only work in virtualdub when there is explicit support for the way its stored in there, eg in ffdshow
once someone invents some private storage mode (eg packed bitstream-like) for avc-in-mkv and no vfw decoder (speak: ffdshow) supports it you can go to hell with your vfw mode
the native mode is the only way to ensure interoperability

btw the vfw mode was especially created for supporting old tools, like vdm

[stephanV]

i though x264vfw didnt use delay frames? it seems to me it just outputs nothing the first few frames and VirtualDub responds to that by writing a drop frame. but this doesnt break anything in the bit stream as such...

[bond]

i though x264vfw didnt use delay frames? it seems to me it just outputs nothing the first few frames and VirtualDub responds to that by writing a drop frame. but this doesnt break anything in the bit stream as such...indeed but you will get the delay and you will loose frames

[stephanV]

im not sure how drop frames are handled by avi parsers in the beginning of a file, i thought AVIMux GUI remvoed them, and that MS avi splitter just skipped them too. so i think the only delay you will see is from decoding.

However, it is of course recommended to use the native mode for h264 in MKV. Unless you know what you are doing, you should use things the way they are intended to be used.

[bond]

im not sure how drop frames are handled by avi parsers in the beginning of a file, i thought AVIMux GUI remvoed them, and that MS avi splitter just skipped them too. so i think the only delay you will see is from decoding.hm i think the question is with which frame the audio is synced to. if the audio starts with the avi frame 1, but the video actually starts with frame 3 (when using two b-frames) you will get a desync of two frames no matter if the avi parser drops the first two frames (and the audio too) or if nothing gets displayed in the first two frames

[Caroliano]

BTW, there is any tool that can convert a native mode matroska to an vfw mode matroska and vice-versa? W/o re-encoding?

[bond]

BTW, there is any tool that can convert a native mode matroska to an vfw mode matroska and vice-versa? W/o re-encoding?not for avc.
maybe its possible for asp in mkvmerge, dunno

in any case you can demux the avc to raw .264, import to .mp4 and than remux to .mkv

but of course the best is to encode directly to .mp4 or .mkv as supported in x264 already...

[stephanV]

hm i think the question is with which frame the audio is synced to. if the audio starts with the avi frame 1, but the video actually starts with frame 3 (when using two b-frames) you will get a desync of two frames no matter if the avi parser drops the first two frames (and the audio too) or if nothing gets displayed in the first two frames
The skipped frames would have a 0s duration, so no delay will occur. Audio is not synched to video frames in AVI (there are no timecodes or anything, remember?). Video is played at constant rate, audio is played at a constant rate and if the rates and start times are such that audio and video are in synch, then that's a bonus. ;)

BTW, there is any tool that can convert a native mode matroska to an vfw mode matroska and vice-versa? W/o re-encoding?
It probably is possible by using a combination of tools, but there is not one tool for it.

[Haali]

The skipped frames would have a 0s duration, so no delay will occur.
Not really, dropped frames still occupy time slots. I think VD or VDM had some special code to delete them for mpeg4-2, don't know if the same is implemented for avc.

[jellysandwich]

Wow, very detailed. Thanks a lot. I especially like #5. :)

js

[stephanV]

Not really, dropped frames still occupy time slots. I think VD or VDM had some special code to delete them for mpeg4-2, don't know if the same is implemented for avc.
Yes, you're right. Maybe the delays I checked with before never were big enough to notice.

[kdm]

BTW, there is any tool that can convert a native mode matroska to an vfw mode matroska and vice-versa? W/o re-encoding?
AVC2AVI -f framerate -i input.raw -o output.avi

[Yong]

AVC2AVI -f framerate -i input.raw -o output.avi
Of course you have to extract the avc stream from mkv,
by using the mkvextract :)

[Eric B]

Today, I ve made my first DVD Rip with x264 under VirtualDubMod as I used to for Xvid. I have a soundtrack in OggVorbis. But now, I cannot mux the tracks into a mkv.

If I understood correctly, VDM should not be used for x264.

Is there still a possibility to mux my x264 avi into a mkv or must I reencode the movie?

[thoralf]

Today, I ve made my first DVD Rip with x264 under VirtualDubMod as I used to for Xvid. I have a soundtrack in OggVorbis. But now, I cannot mux the tracks into a mkv.

If I understood correctly, VDM should not be used for x264. Is there still a possibility to mux my x264 avi into a mkv or must I reencode the movie?

just use the avi2raw / mp4box-approach as suggested by mkvmerge (note that the framerate for pal is 25 and not 23.976). there's definitely no need to reencode.
you end up with a raw .264 stream that should be pretty much identical to a .264 produced by any of the non-vfw-x62-frontends. mkvmerge will quite happily mux such a video stream along with your audio into a perfectly standard-compliant mkv.

hope i didn't confuse you too much,
thoralf.

[foxyshadis]

--engage allow_avc_in_vfw_mode (it's in the mmg extra command-line window).

Or yes, raw extraction, which will be a little less fragile.

[Eric B]

Yes, I read the solution in another post before your replies and test it via a raw file and a mp4:
mp4box.exe -aviraw video input.avi
mp4box.exe -add input_video.h264 output.mp4 (mp4box says "I/O Error" here, tried successfuly via Yamb)
and then mkvmerge ouput.mp4 ... output.mkv
Pb is then that at it requires a mp4 splitter besides the mkv splitter (I had pb with the haali spliter under TCMP so I went back to the matroska splitter of Gabest). I fear I have no possibility to have my video directly. Mkv do not seems to support raw .h264 :/

[foxyshadis]

It supports it just fine if you make it that way. It should work fine the way you're doing it too, and won't require an mp4 splitter, I did that several times before I switched to native encoding. Could be an issue with the version of mp4box though, sometimes they break in mysterious ways. (Probably why yamb worked and the other didn't.)

Did the mp4 play?

[Eric B]

"in that way", you mean using --engage allow_avc_in_vfw_mode ?
Or with avi2raw (for which I didnot find a correct link)?

I am using mp4box GPAC 0.4.1-DEV of this month. The mp4 is playing fine.
When mkvmerge takes the mp4 as source, it mux it also as a mp4 ("avc1"), not as a raw h264.

[thoralf]

When mkvmerge takes the mp4 as source, it mux it also as a mp4 ("avc1"), not as a raw h264.

mkvmerge does the same thing here, and quite rightly so: h264 is technically identical to the mpeg4 part 10 standard aka avc (advanced video coding), see wikipedia for details.

An additional mp4 splitter might get used if your audio is something like m4a - a mpeg4 audio stream (aka aac) that is not a raw aac stream but is itself encapsulated in the mp4 container. some apple tools seem to produce such weird things.
if you load your mkv in graphedit, you can tell for sure what splitters / codecs are used for that file in your dshow configuration. you can get graphedit as part of the ms directx sdk or just off the net.

hope this helps,
thoralf.

[Eric B]

I open my mkv with graphedit, and it shows the haali before going to CoreAVC and CoreVorbis (I have a x264 video and vorbis audio track).
I've uninstalled the haali splitter, and it shows now only the CoreVorbis. The Gabest matroska splitter seams not to be able to connect itself with CoreAVC (perhaps because I have a beta version)

So I ve unregistred gabest and haali, but in DS Filter Enumerator, I still see some files that do not exist anymore on my system (envivioTV video rendrer, haali video renderer)

[thoralf]

hi eric,

you _need_ a splitter to demux all the streams from the mkv when playing it. the demuxer sends those streams to the right decoders: coreavc then decodes your video and corevorbis your audio-streams, so i guess your setup is right.
in general, ds-splitter and decoders don't get called when thy're not actually being used, so i wouldn't worry about the envivio stuff.
I never tried gabest's mkv splitter - haali is my choice since it seems to be more actively used, and there's more documentation available.

with kind regards,
thoralf.

[Eric B]

I've tried different install/uninstall / registry cleanup and updated my players.
I still do not have a correct seeking under my mkv containing AVC video.

I ve registred the gabest filter after the installation of the haali one (unckecking as you said), and it is working for everything else than AVC. Gabest filter cannot connect to CoreAVC.

Haali is working well with mp4.

I ve made a native encoding of another video to AVC/MP4 and AVC/MKV (MeGUI x264). You were right: after demuxing the raw from an avi/VfW mode, there is no difference with a native mode. If I though the MKV was containing a MP4, it is only because AVC need the Haali as said.

So, as I did not find a perfect solution, I will simply abandon the MKV container for AVC video and stay by MP4.

My other MKV video (ASP) are playing well with the Gabest filter.

Thanks for your help anyway.

[thoralf]

I've tried different install/uninstall / registry cleanup and updated my players.
I still do not have a correct seeking under my mkv containing AVC video.


so your directshow configuration is probably pretty messed up by now ... try vlc or mplayer and it see if it works with those players, as the do not depend on dshow.
i remember that some older versions of oggds had some issues with matroska, as had older vobsub builds. i usually let ffdshow do all the deconding (apart from vobsubs), and this works quite fine.

with kind regard,
thoralf.