CLI vs VFW encoding speed

[DigitalDivide]

Just curious, all things being equal would the CLI version encode faster than the VFW version?

I normally use GKNOTT to encode to x264. 3b frames, 8 ref, Uneven Multihex, etc etc. Target size 2gb. Normal encode time is about 14hrs for a 2hr movie.

I tried MeGui last night using the HQ Slower setting. Modified it to 6-RDO Slow and uneven multihex and noticed this morning it was almost done. It appears it saved about 2 or 3hrs.

Just curious if in general the CLI version is faster. Can't imagine it is but...

[ChronoCross]

CLI Version is supposed to be faster as it doesn't have any of the go betweens that vdub/mod have.

[temporance]

I would say that the "go betweens" come almost for free and actual speed would depend on secondary things like:

threading model and scheduler
random effects when binary was linked (for example, do you get any instruction cache misses or aliasing)


These could affect speed by as much as 10-20% but the only way to find out how it would influence CLI vs. VfW on your processor and OS is to experiment and see.

[Sharktooth]

The difference is due to different defaults and different options (some of them are implemented in CLI only).

[DeathTheSheep]

Too true... As an avid VFW user, I'm curious as to whether or not the "CLI-only" options will ever find their way into the nice-looking VFW...?

[Manao]

On multicores, with a complicated avs script, virtual dub will be faster : the input is threaded. But for single CPU, CLI is the way to go ( and even for multicore, since you can use several threads in the codec itself )