Various settings of X264

[kotrtim]

I encoded a 496x272 short video clip wih different settings
This are the settings used as reference

--crf 20 --bframes 3 --b-pyramid --subme 1 --analyse none --me dia

the bitrate produced by this command line will be refered as "1" or 100%

Variables is the only setting that differs from the reference command line


http://img67.imageshack.us/img67/850/x264table7jz.png
*NOTE = analyse all includes 8x8dct
reference bitrate = 1304.26



The previous sample is a fast motion anime
This sample is an extract from exorcism of emily rose
slow motion, mostly static backgrund

The reference is "0"
Bitrate , negative means smaller filesize than reference
Speed, negative means slower (percentage)

http://img152.imageshack.us/img152/8503/x26354zu.png

[nm]

Wouldn't it be better to use two-pass ABR to keep the bitrate constant between runs with different settings? Then you can easily see the differences in PSNR. It would also be interesting to see results for different clips, not only one.

Nice work with the table though :)

[Daodan]

Indeed a nice test (to bad usually people use two-pass encoding). May I know what version of x264 did you use?
nm, I'll try to make some similar test with 2-pass and SSIM metrics, maybe this weekend.

[Manao]

You should have chosen, as reference, the following command line : --crf 20 --subme 5 --analysis all --me hex

There are several reasons for that, but mainly :
- you would have seen the difference with / without mixed ref ( mixed ref is used only if p8x8 is enabled )
- it's 'sane' defaults settings, while yours are the fastest available, so it's closer to all the other settings you could think of, in term of psnr & bitrate.
- you'd have a bigger difference between --analysis all and none ( and in general, you'd magnify the differences that are important/pertinent )

nm, Daodan : crf is quite close to what a two pass encoding gives. The only problem is the bitrate that varies with the quality, but on a short clip bitrate also varies in two passes.

[asdfsauce]

Thanks for sharing your results. Should you ever happen to do this again, could you include a delta-time/FPS column as well?

[kotrtim]

--crf 20 --subme 5 --analysis all --me hex

I'll make this as reference and do another table....

delta-time/FPS, Megui will report the time starts and end, is it OK to just include time taken instead of FPS?

[foxyshadis]

The best way would be to compare time taken divided by the reference time. So .9 means it's faster, 134.3 means you need your head checked to use those options. :D Including raw time just means everyone has to do that conversion in their heads. You can make a formula in excel to convert the timestamps into ratios like that pretty easily.

I'm considering writing a short script to encode and then compare via ssim. I've been kind of flying by the seat of my pants when it comes to some options, like mixed refs and bime, and it'db be really nice to know conclusively how well they work.

Can you also provide a snippet of your sample so we get a general idea of what these settings apply to here?

[Audionut]

I think it's an excellent test. The test clearly show's the affect on bitrate each setting has.

Why people think you need 2 passes to determine the affect a setting has on PSNR is beyond me.

You can clearly see that with subme 1 the PSNR value is 43.077
And that with subme 6 the PSNR value is 42.327

[Selur]

People want the same size in a comparison so that they can take some conclusions for their 2pass encodes where they aim for a specific size.

that subme 1 delivers a higher PSNR at a higher size than subme 6 doesn't mean much, since when people aim for a specific size they normaly want to choose the subme that delivers better PSNR/SSIM. (subme 1 needs more than 25% more datarate to archive a 0.7 difference in PSNR,...)

[kotrtim]

You can clearly see that with subme 1 the PSNR value is 43.077
And that with subme 6 the PSNR value is 42.327

I just put the PSNR value for reference, the purpose of this test is not psnr, it is at given same qualty (CRF 20), assume the same, which settings could achieve at the lowest bitrate possible, this means subme 6 is so much better than subme 1... psnr is useless, I would rather believe the quality is crf 20 instead of psnr, if bitrate is the same, then you refer to psnr.

on 2 pass mode, subme 6 will definitely give you a lower overall rate factor

Besides, is it better to use subme 2,3,4 for pass 1?, it can give you a much more accurate / closer bitrate to subme 6 than using the turbo (subme 1)...and speed is almost as fast as subme 1

[Manao]

crf is constant quality, if, and only if settings are the same. It never was intended to make a constant quality across a different set of settings.

[nm]

That's what I was thinking. Now you have big changes both in bitrate and PSNR, which make it a bit hard to decipher how large the differences between settings actually are. SSIM would probably be a better metric, if you know how to use those tools.

[kotrtim]

SSIM would probably be a better metric, if you know how to use those tools.

We have to wait for Daodan to do it, coz I don't know how, SSIM is avilable in avisynth?

anyway, it is really weird that subme 7 is faster than subme 6, is it a bug?

[Daodan]

I think by monday i'll have some tests with both SSIM and PSNR but it's slow bussiness since I wanted to use HD sample (beacuse I mostly encode HD atm so I wanted to be also usefull to what I'm doing). kotrtim, I asked what version of x264 you used because from what I understood subme7 is a valid option only in Sharktooth's builds. (or am I wrong?)

[dude051]

Straight from the newest build of X264 off of http://www.x264.nl
-m, --subme <integer> Subpixel motion estimation and partition
decision quality: 1=fast, 6=best. [5]

[foxyshadis]

Sharktooth's and ChronoCross's.

http://chronocrossdev.com/apps/x264/

That subme7=faster is sort of mindblowing, I always thought it was slower. That second table is very useful, I really like how it was laid out. Thanks!

[DarkZell666]

Dammit that's exactly what I was trying to do !

Only I'm just a tad more lazy =)

Just noticed one thing : if I want to use subme 5 I'm better off using subme 4 since it's joly faster and only loses 0.033dB compared to subme 5.

Noticed something else : trellis is just as useless as I thought :p

Congrats man, I hope more comparisons like this will appear in the near future :) (should have finished mine but never got round to ..)

[akupenguin]

Noticed something else : trellis is just as useless as I thought :p
What's useless about +0.28 dB?

anyway, it is really weird that subme 7 is faster than subme 6, is it a bug?
It means he didn't use Sharktooth's or Chrono's builds. Note that the bitrate and psnr from subme 7 were identical to 6. The speed difference was just random variation. (From which we can guess that the rest of the speeds are probably also only accurate to within 1%.)

[DarkZell666]

Quote:
Originally Posted by DarkZell666
Noticed something else : trellis is just as useless as I thought

What's useless about +0.28 dB?



Sorry my bad, just saw 1.002 in the bitrate savings ^^'
That'll teach me to think twice before saying something :)

[kotrtim]

Sorry my bad, just saw 1.002 in the bitrate savings ^^'
That'll teach me to think twice before saying something

an addition of 0.2% bitrate isn't so important, and in 2 pass mode trellis 1 would surely be better than none, it's just that trellis 2 is not significantly better than trellis 1.... so do always enable trellis, if quality is priority, the table 2 is so misleading.......this time, i'll do a 2-pass table.

[Sharktooth]

it's just that trellis 2 is not significantly better than trellis 1....
it highly depends on the source and on the other settings.

[kotrtim]

it highly depends on the source and on the other settings.
:thanks:

Sharktooth, from the 2 pass table, I noticed that ref 5 mixed refs is almost at the saturation point, ref 4 mixed-refs is the best speed trade off and psnr


--pass 2 --bitrate 1000 --stats ".stats" --ref 10 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct

The above combination is HQ-slower from Sharktooth
I tried to twaek it a bit (ref=10 to ref=4, me hex to me umh)

--pass 2 --bitrate 1000 --stats ".stats" --ref 4 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh

sample 1
hq-slower fps = 2.0 psnr = 48.092
hq-(tweaked) fps = 2.35 psnr = 48.086

sample 2
hq-slower fps = 2.94 psnr = 41.777
hq-(tweaked) fps = 3.09 psnr = 41.822

I don't know how much will it affect the visual quality, but psnr wise, the tweaked one is similar to the hq-slower, and the most important thing, FASTER.....hehe, I know, 0.++ fps is not that much

[Sharktooth]

Yeah... HQ-Slower should have had UMH insted of HEX.

[akupenguin]

Update on the features that were not properly tested, and are still listed in one or more of the tables:
subme 6 vs subme 7: you didn't use a build that supported subme 7 at all. x264 silently ignores options outside the supported range.
trellis 1 vs trellis 2: trellis 2 requires subme >= 6.
ME range: requires UMH or ESA.
Mixed refs: requires partitions.

Also, before declaring that some option is faster than some other option, make sure that the difference is statistically significant. Run an encode a few times, and record how much the speed varies when you don't change options. If you're on unix, the `time` command can give a very accurate account of cpu time actually used, but even that varies. If you rely only on wallclock time (as used by x264cli's "fps"), expect a rather large amount of randomness, due to what else the cpu was doing (even if you personally weren't using the computer), and how much of the input file had to be read from HD vs RAM cache, and other stuff.

[kotrtim]

thanks for reminding me akupenguin, that's the right way to do experiment to eliminate errors.... computer might not encode with same speed evrytime even settings are the same....

akupenguin, I downloaded chronos build and tested subme 7

subme 7 is faster than subme 6 with B-RDO, and also higher psnr
Which should I choose? If I'm not wrong, RDO-7 means a more efficient RDO for I & P, but B-frames is skipped?

Which is better?
1. RDO-6 on all frames, I P B all equally important...
2. RDO-7, a better RDO for I & P but B is skipped, B-frames quality is not as important as I P frame?

[Sirber]

I updated my profils according to the chart!
Thanks!

[Caroliano]

RDO-7 still not optimal with mixed references? If yes, would be good to include a comparision of RDO-6 + mix and RDO7 + mix.

The bitrate was exactly, or almost, the same in all the clips in this last table? You checked it?

[kotrtim]

RDO-7 still not optimal with mixed references? If yes, would be good to include a comparision of RDO-6 + mix and RDO7 + mix.

No. I don't know whether RDO-7 will have special impact with mix reference... since most of the time, i use subme 6, and most people use subme 6? So I did not test subme 7 + mix

The bitrate was exactly, or almost, the same in all the clips in this last table? You checked it?

It's a 2 pass mode, of course they are not exact, but the difference are negligible, just 1 or 2 kbps... x264 rate control is very accurate

[Oline 61]

This is very useful in determining what settings to use. Would you consider doing any testing of the effects of --qcomp on PSNR?

[kotrtim]

what --qcomp settings you suggest?
I've tried ratetol, for 2-pass, the difference of psnr of ratetol 1 and ratetol 100 is ~0.05 db, --ratetol 100 produce a file considerably quite far away from the desired size

also tried to change ipratio pbratio and it seems the default is still the best

From the table, you can see, subme, trellis, B-RDO are the 3 main factors that will improve psnr (+0.1) significantly, increasing ref frames, ME other than hexagon, ME range doesn't really affect the psnr that much

[Daodan]

Ouf, finally I finished my tests. So here are the settings: sample of 5331 frames 1280x544, both low and high motion scenes. Testing machine Venice 3200+@2300 mhz, DDR 460 mhz 2.5,3,3,7. x264 vers 0.437 from www.x264.nl. Encoding time with default settings: 3245 seconds. Error in speed values +/- 0.15%. Other errors: bitrate variation between different tests max. 0.1 kbps (2500 kbps target bitrate).
Default settings used:
-ref 5 --bframes 3 --b-pyramid --weightb --filter -2,-2 --subme 6 --analyse all --8x8dct
2-pass, both passes the same unless specified. Both values of SSIM (the main purpose of the test) and PSNR included.

For the default settings:
PSNR: 42.965
SSIM: 78.85237749
Speed: 3245 seconds

Now follows the list with varying of different settings and how they affect the three parameters considered.

http://img76.imageshack.us/img76/5875/ssimtablev4final7hk.jpg (http://imageshack.us)

The values without - should have a + in front but for some reason I can't do that in excel. Obviously, green is better, red is worse.
Some of the values are quite surpising (to me at least). The last value, the 'optimized' one is based on the values measured and optimized for large SSIM value without losing too much speed. The settings for this profile are:

--ref 5 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --direct spatial with a fast first pass.

I'll leave the interpreting for now to you since you are big boys (and girls?). Note that the table is no yet finished. I will add a few tests in 1-2 days, especially concerning rdolvl2 in Chrono Cross's builds. I will add also the encoded sample with default settings to see what kind of scenes we are talking about as soon as I find a site that accepts it. Also feel free to request some of the other samples if you consider you should have a look to compare by eye.
edit 1: link to sample default: http://s51.yousendit.com/d.aspx?id=33ZO2X8MAGC880MZ0W67NVY05U
edit 2: Chrono Cross build 0.437, with the settings considered defaults.

[kotrtim]

me dia --merange 16
46.496

me hex --merange 16
46.507

me umh --merange 16
46.526

me umh --merange 24
46.531

me esa --merange 16
46.537

me umh --merange 32
46.528

ME range 32 seems to spoil the quality, from 16 to 24 there's still a slight increase in psnr

[Daodan]

Yes, strangely in my 2pass tests merange 32 was slightly worse and much slower than 16. Clearly the default should be used in this case. What puzzles me most about 2pass is why a fast first pass is better and obviously faster than full 2pass. Also what I observed is that SSIM follows PSNR pretty much except trellis where 1 seems great with PSNR but 2 seems great with SSIM. Also added link to sample (hard to find a site that actually works nowadays).

[Sagittaire]

Simply because "biger is not always better" ... lol. For example try 10 bframes with no adaptative and see the result.

More seriously akupenguin say multiple time to not use merange because default setting is the best.

Moreover your PSNR result are extremely high (45 or 46 dB). If you want see real affect for the setting you must use encoding with higher average quantizer like q25 and 720*400 for example. With that delta for metric will be very higher.

With low average quant powerfull setting (RDO, WPred, trellis, multiref, bref ...) become useless for eyes and for metric too ...

[Daodan]

You're confusing a bit the different tests, my tests have 42-43 PSNR , and 2500 kbps for 1280*544 which is not a high bitrate I would say at this res. I know that going for lower bitrates helps see the differences but I think a test is made to help with real encodes, where I think most of us want with q at least 20-21. Still, I think that the test shows at least one thing for sure: there is definetely no need to not use turbo in 2pass encodes (at this bitrate at least) , which makes things much faster.

[kotrtim]

there is definetely no need to not use turbo in 2pass encodes (at this bitrate at least) , which makes things much faster.

"no need to not" = should use ... wow I read it wrongly the first time, I thought it means "should not use"

I'm pretty surprise that turbo 1st pass yield better results than non-turbo.... Mplayer site says turbo will decrease the psnr by ~0.1 dB, that's totally not true

[Oline 61]

Could you test the effects of --qcomp 0.6 and --qcomp 1.0? I am interested to see how that will effect the average PSNR.

[ariga]

What's the "turbo" setting in 1st pass ?:confused:

[foxyshadis]

The megui turbo or vfw fast first pass. It's not implemented in x264 itself, it just throttles down the options to the simplest, fastest encoding possible.

I'm running my own test now, dual-core HD material, hopefully I'll get results interesting enough to share. (If they're essentially the same I won't bother.)

[Daodan]

What's the "turbo" setting in 1st pass ?:confused:
Turbo means first pass looks like this:
--bframes 3 --b-pyramid --filter -2,-2 --subme 1 --analyse none --me dia
(in my case)
which makes the first pass around 3 times faster for the settings I used.
foxyshadis, could you please make a comparison between quality using one core and both (with the same settings)? I'm just curios (I don't think I'll have a dualcore very soon).

[foxyshadis]

Just run x264 with 2+ threads. It won't improve speed of course, but it should be byte-identical to whatever output you'd get with 2 cores or cpus.

[ariga]

The megui turbo or vfw fast first pass. It's not implemented in x264 itself, it just throttles down the options to the simplest, fastest encoding possible.I see. Got to try megui. Couldn't use it since it required .NET. Got a bigger hard drive now.

foxy/Daodan, thanks for the replies.

[foxyshadis]

Daodan, would you be willing to add to your matrix the results of --direct auto (if you still have the clip handy)?

[Oline 61]

What is this new trickery --direct auto?

[foxyshadis]

http://forum.doom9.org/showthread.php?p=794731#post794731

[nm, one-pass bug only and fixed already]

[bond]

http://img301.imageshack.us/img301/8227/ssimtable6fx.jpg (http://imageshack.us)very interesting results! thanks a lot :)

[Daodan]

Foxyshadis, yes, as always I'm willing to try anything that can give a better use of x264 because frankly lately I've been quite disappointed in how x264 handles some scenes. I'll try that as soon as I can (1-2 days). Also I hope I'll be able to add that comparison between custom Chrono Cross builds and official ones as promised.

[foxyshadis]

No hurry at all, I was just curious and still haven't set up any framework for finding out how much better, if at all, it is. Thanks!

[Oline 61]

So auto chooses between spatial and temporal for each frame?

[foxyshadis]

Yup, exactly that.