x264vfw speed info

[TCmullet]

Hi. I've been using x264vfw as output from Virtualdub for awhile. Those speed settings have been so mysterious. I decided to run a bunch of small encodes to see both how fast or slow those settings really are, PLUS what the size tradeoffs are.

My source file was:
Lagarith video codec, 763x432, 29.97 fps, 5 min. of various content such as talking heads, stills and sports action (mostly the latter).
PCM audio, 48k, 16-bit stereo.

x264vfw was set to lossless. FWIW, I run on an i5 quad-core system, Windows 7.

PRESET DURATION FILESIZE

Ultrafast 1:03 1.19gb (1,255,965kb)
Superfast 1:31 1.04gb (1,097,558kb)
Veryfast 1:39 1.03gb (1,082,023kb)
Faster 1:51 1.01gb (1,068,962kb)
Fast 3:00 1.00gb (1,052,418kb)
Medium 3:19 .99gb (1,046,317kb)
Slow 4:46 .99gb (1,040,186kb)
Slower 6:20 .98gb (1,032,874kb)
Very slow 9:09 .98gb (1,032,598kb)
Placebo 20:10 .98gb (1,032,926kb)

I thought this was very revealing. If I'm creating a temporary file, it seems Superfast is the best speed, as it's less than HALF the time of Medium, yet with only a 5 percent increase in file size. But if you go further to Ultrafast, then you get a rather big increase in filesize.

It's very odd that the Placebo setting, while taking twice as long as the next speed up (Very slow), it actually made the file BIGGER instead of anything smaller.

Then I ran more runs while I was curious. I wanted to see how size changed with Q factor (quantization). So I stuck with Medium speed and ran Q from 0 to 23. Based on the 1st two lines (lossless and cqp01), lossless must be somewhat different than q=0 because lossless has a SMALLER size than q=1, when I would expect the opposite.

And while I was at it, I threw in the durations. But I suspect the duration values are largely driven by the I-O time taken to write the smaller files out, explaining why as Q goes up (equating with quality and filesize going down), that it takes less time. This also was a bit surprising, as I really thought varying Q would not affect running time.

MEDIUM (speed)
lossless 3:19 .99gb (1,046,317kb)
cqp01 5:02 1.05gb (1,103,895kb)
cqp02 4:57 .97gb (1,027,276kb)
cqp03 4:47 .931gb (0,953,810kb)
cqp04 4:42 .864gb (0,885,661kb)
cqp05 4:29 .793gb (0,812,773kb)
cqp06 4:21 .726gb (0,744,271kb)
cqp07 4:14 .663gb (0,679,720kb)
cqp08 4:02 .598gb (0,612,918kb)
cqp09 3:51 .545gb (0,558,354kb)
cqp10 3:46 .495gb (0,507,572kb)
cqp11 3:37 .451gb (0,462,402kb)
cqp12 3:31 .412gb (0,422,874kb)
cqp13 3:26 .389gb (0,389,112kb)
cqp14 3:16 .345gb (0,353,927kb)
cqp15 3:09 .317gb (0,324,800kb)
cqp16 3:02 .290gb (0,297,898kb)
cqp17 2:56 .266gb (0,272,997kb)
cqp18 2:52 .245gb (0,251,229kb)
cqp19 2:47 .226gb (0,231,659kb)
cqp20 2:38 .206gb (0,211,329kb)
cqp21 2:32 .190gb (0,194,668kb)
cqp22 2:29 .174gb (0,178,996kb)
cqp23 2:22 .160gb (0,164,601kb)

Hopefully this may help someone.

[nevcairiel]

Slower presets don't necessarily make for smaller files, they only produce higher quality - this can result in bigger files in some cases, or smaller files, or remain the same size.
As your test shows, size is somewhat constant in all presets, only changing maybe 10% between ultrafast and placebo.

A simple rule to remember, the preset controls the speed/quality trade off, and only has a minor impact on the size, while the bitrate/qp/crf values control the size/quality.
If you want to maximize quality, you have to sacrifice both speed and size, or stick to a faster preset and increase size even more. Or if you want small and high quality, you definitely have to go for a slow preset.

[vivan]

Well, first test was lossless - so there's no "higher quality", only pure size/speed ratio.

It's very odd that the Placebo setting, while taking twice as long as the next speed up (Very slow), it actually made the file BIGGER instead of anything smaller.Placebo is basically maxing everything out, in some cases it might backfire.

Based on the 1st two lines (lossless and cqp01), lossless must be somewhat different than q=0 because lossless has a SMALLER size than q=1, when I would expect the opposite.Lossless is a special mode, it skips some stuff - that's why it's faster and more effective than qp/crf close to 0. It even uses special H.264 profile that can't be decoded using HW decoders.
(and with cli encoder --qp 0 activates this mode instead of using qp ratecontrol)

And while I was at it, I threw in the durations. But I suspect the duration values are largely driven by the I-O time taken to write the smaller files out, explaining why as Q goes up (equating with quality and filesize going down), that it takes less time. This also was a bit surprising, as I really thought varying Q would not affect running time.It's not about I/O. Lossless compression of encoded information (CABAC) is the part of H.264 standart, and it could take quite some time.

[sneaker_ger]

I thought this was very revealing. If I'm creating a temporary file, it seems Superfast is the best speed, as it's less than HALF the time of Medium, yet with only a 5 percent increase in file size. But if you go further to Ultrafast, then you get a rather big increase in filesize.
Careful when comparing filesize at same crf at different settings (read: don't do it). Superfast and Ultrafast don't use mbtree and thus have a different crf calculation than the rest.

[foxyshadis]

Also, the reason lossless is smaller than qp1 is probably transform skip, which is only enabled in lossless. Sometimes it's just quicker and more efficient to treat the predicted frames like PNGs instead of turning them into DCT coefficients.

All that tells you is pretend qp1 doesn't exist, though, everything else is still a trade-off.