Various settings of X264

[Daodan]

Finished the test with direct auto. The results are nice. Used version 458.
Speed: +8.9%
SSIM: +0.066
PSNR: +0.26248
I'll add them soon to the list, but to get an idea, it is faster and better than spatial. Quite weird, I didn't expect to be faster actually, maybe it has something to do with the new version. In my test 80% was used as spatial, 20% as temporal.

[akupenguin]

The best direct mode is the one that correctly predicts the most motion. Thus it produces more Skip blocks. Skips are faster to encode than other types. So if the gain in number of Skips is more than the cost of analysing direct modes, you can get an overall speedup on some inputs.

[Daodan]

Thanks for clearing that up. So using no-fast pskip would nullify this speed. Anyway, direct-auto is a nice addition.

[akupenguin]

Well, fast-pskip is for P-frames. The equivalent no-fast-bskip is part of --b-rdo instead. But same idea.

[Daodan]

Added the values with the considered default values for custom build (Chrono Cross 437). The results are nice, for a little loss in speed SSIM increases more than any of the other settings considered. The last and final addition will be the RDO lvl2 in the custom build.

[ariga]

While it is made clear that "speed" column refers to time taken for encode, the term is quite misleading. On first look one would wonder why "higher" speed is bad ;)

[GodofaGap]

@Daodan

Is the source you use an AVS script or raw YV12? In case of an AVS-script it would be nice if you could figure out the CPU time of it (perhaps with avs2yuv with a NUL output?) and subtract this from the total encoding time. Otherwise the relative differences in speed between options would be influenced by the kind of script you use. The general trends are still the same of course.

Just a suggestion.

Thank you for the interesting table. :)

[Daodan]

Yes, it is through avs, but frankly it doesn't affect the test at all, since it is a comparison, always the same script used. After all, even if I would use an uncompressed clip, it would be kind of the same, since some power will be taken to decode (at least with huffyuv, not sure for raw). PS. the table is on the second page, I always get confused with the quote from bond.

[GodofaGap]

IMO it does affect the test somehat, because it will make the speed difference between two option sets artificially smaller.

Say A is the CPU time needed for rendering the AVS script, Y the CPU time x264 needs for an option set, and Z the CPU time x264 needs for another option set. The total encoding times for these two test will be then A+Y and A+Z. When you calculate the difference in percentage you will get:

100% * ((A+Y)-(A+Z))/(A+Y) = 100% * (Y-Z)/(A+Y)

While what you really want (IMO) is 100% * (Y-Z)/Y

As you can see when the CPU time needed for you AVS-script becomes bigger and bigger, the relative speed differences will become smaller and smaller. But it was just a consideration, not important enough to waste a whole lot of time on. :)

[Caroliano]

If this is a basic avisynth script, there is no problem in adding it to encoding time, since it make the test more realistic. I think that you don't compress raw sources often. You use avisynth to feed the encoder, and this always take some processing time, in all your x264 encodes.

[foxyshadis]

In my experience, fast x264/xvid settings result in 50% of processing being decoding from huffyuv, 50% encoding. No filters in the chain at all. The heavier the settings the less the decoding matters, though. Either way, the speed column will only ever give rough hints about how much faster/slower something is, unless it was done in a controlled environment with many sources and settings. ^^;

[Daodan]

Updated the table with the last setting: subme7. Quite slow but worth enabling if you want the best.
Foxyshadis, I don't quite understand about what speed you say it's unreliable. There is a error margin declared that is actually quite true, so very little errors there. And what is controlled environement? Indeed for different bitrates things can change a bit, but for a normal HD movie those values are accurate (the sample is from Lord of the rings).

[sasam]

Can someone test effects of AQ? (if its working now)

[emmel]

Sorry if this is a noobish question, or if this is the wrong thread to ask.

I'm wondering, if it would be possible to setup x264 to encode for a prescibed metric or norm? To be more specific, I would like to define a target accuracy, say, PSNR>45dB. And for the rest, be able to choose between the resulting file size and encoding speed.

Actually what I am doing at the moment is exactly this. My method is only iterative - trial and error - and I'm wondering if there is a better way for obtaining the goal? I'm aware of the fact that PSNR is not the whole truth and nothing but the truth, but still.

emmel

[Sirber]

I don't there's a way to encode by PSNR.

[Manao]

You might want to consider constant quantizer. It's with --crf the closest thing to constant PSNR and constant visual quality. So you only need to 'calibrate' it in order to know the rough equivalence quantizer / PSNR or crf / PSNR.