Does x264vfw produce the same video quality as x264 command line encoder?

[orion44]

Does x264vfw and x264 command line encoder for Windows produce the same level of quality in the encoded video?
Or does x264vfw produce worse-looking videos?

There is a sticky above from 2006 about the missing features in x264vfw.
Does this still hold true in the present, or has it been fixed?

I want to use x264vfw in VirtualDub and for game recording, and I'd appreciate if anyone could clarify the above.

Thanks.

[sneaker_ger]

Quality is exactly the same.

P.S.: There's also the option to use x264.exe as an "External Encoder" in VirtualDub.

[raffriff42]

Also note VirtualDub FilterMod has integrated x264 compressors (10 and 8 bit) and can save to MKV/MOV/MP4 directly.
https://sourceforge.net/p/vdfiltermod/wiki/compression/
Hopefully the external encoders can be retired soon, if not immediately.

[Groucho2004]

Also note VirtualDub FilterMod has integrated x264 compressors (10 and 8 bit) and can save to MKV/MOV/MP4 directly.
https://sourceforge.net/p/vdfiltermod/wiki/compression/
Hopefully the external encoders can be retired soon, if not immediately.
I didn't even know that shekh's VDub build had these features. I just tried it out, very nice.

[LoRd_MuldeR]

Does x264vfw and x264 command line encoder for Windows produce the same level of quality in the encoded video?
Or does x264vfw produce worse-looking videos?

There is a sticky above from 2006 about the missing features in x264vfw.
Does this still hold true in the present, or has it been fixed?

I want to use x264vfw in VirtualDub and for game recording, and I'd appreciate if anyone could clarify the above.

Thanks.

Well, quality should be the same, provided that you can find a VFW build of x264 that is based on the very latest libx264 revision. Only the core library (libx264) and the CLI front-end are officially maintained. The VFW front-end has been dropped from "official" x264 long ago, so other people have been back-porting the VFW front-end on their own. That's why the available VFW builds have often been way behind "official" x264 development.

Furthermore, VFW does not really support B-Frames, because the VFW interface assumes a strict "one frame in, one frame out" ordering, i.e. the encoder can not get the next input frame until it has returned the encoded data of the current frame. Clearly, this is not "compatible" with the idea of B-Frames - and thus has lead to the development of abstrusities like the notorious "packet bitstream" hack. So, if you switch off B-Frames in order to avoid VFW problems, then quality (at a given bitrate) will suffer! With VirtualDub this should not really be an issue though, as the x264 VFW encoder has the so-called "VirtualDub Hack" option, which works around B-Frame problems with VirtualDub - and which only works with VirtualDub.

Last not least, I don't think VFW has ever supported any "high bit-depth" pixel formats. So, you are pretty much restricted to YV12 or RGB24, which are 8-Bit per component. Encoding 10-Bit or even 12-Bit footage is not possible.

[mariush]

Some of these codecs have an option to save the encoded data separately to disk as a h264 or mkv file, and return a bogus compressed frame to the application working with the codec (like returning the absolute minimum required for the application to think the codec did the compression correctly)
I'm fairly sure what they output to disk (if you choose that option) is not the hackish stream the codec would otherwise output to the application (as explained above).

Virtualdub nowadays has option to use external encoder (send the raw data to separate application which can be command line x264) ... Personally, I'm not sure the feature is working quite right as in some situations (only with some resolutions) no matter how i specify the output color format in virtualdub and in x264 command line, i still get bad encodings (like green and blue flipped, color space crap)

Anyways, these days it's just easier to make up a small avisynth script and load it directly in x264

[WorBry]

Last not least, I don't think VFW has ever supported any "high bit-depth" pixel formats. So, you are pretty much restricted to YV12 or RGB24, which are 8-Bit per component. Encoding 10-Bit or even 12-Bit footage will not be possible.

The accepted input pixel formats for the 10-bit x264 compressor in YUV 4:2:0 and YUV 4:2:2 space are YUV420p16 and YUV422p16 only, and the encodes are indeed 10-bit:

http://i.imgur.com/PQFjAJg.png
http://i.imgur.com/gfrwOAR.png

http://i.imgur.com/WBZ7D0u.png
http://i.imgur.com/HBIRE4k.png

[LoRd_MuldeR]

WorBry, obviously you are not using "original" VirtualDub, but the VirtualDub "FilterMod" fork, which apparently has added "high bit-depth" support.

Furthermore, you screenshot shows that you are not using x264 trough the VFW interface, but instead you are using some "x264" VirtualDub plug-in (x264-10.vdplugin) that ships with the VirtualDub "FilterMod" package.

Clearly, if both, the particular host application (here: VirtualDub "FilterMod") and the particular Codec (here: x264 plug-in for VirtualDub) agree on some non-standard interface, they can get rid of the limitations of the old/limited VFW interface.

Doesn't change anything about the fact that the vast majority of all "VFW-enabled" applications (most of which are no longer developed) and the vast majority of all VFW Codecs (most of which are no longer developed) will never support this.

If you are fine with the fact that things are only ever going to work with VirtualDub "FilterMod" and its x264 plug-in, i.e. it's not going to work with other applications or Codecs, then you don't need to bother, of course...

[WorBry]

WorBry, obviously you are not using "original" VirtualDub, but the VirtualDub "FilterMod" fork, which apparently has added "high bit-depth" support.

Furthermore, you screenshot shows that you are not using x264 trough the VFW interface, but instead you are using some "x264" VirtualDub plug-in (x264-10.vdplugin) that ships with the VirtualDub "FilterMod" package.

Correct, and I have to admit I wasn't exactly sure if the Vdub FilterMod x264 codecs were VFW or not.

Doesn't change anything about the fact that the vast majority of all "VFW-enabled" applications (most of which are no longer developed) and the vast majority of all VFW Codecs (most of which are no longer developed) will never support this.

Point taken. You were addressing the OP's inquiry. Sorry to confuse matters.

[shekh]

Correct, x264-x.vdplugin uses private (non-VFW) interface.

x264 VFW encoder has the so-called "VirtualDub Hack" option, which works around B-Frame problems with VirtualDub - and which only works with VirtualDub

I believed other tools implemented it too.
Thanks for clearing mystery :)