Why x264 "placebo" preset produce bigger file than "very slow"?

[aleaksunder]

Hello!

I have noticed that x264 placebo produces bigger file in comparison with "very slow" preset... I've searched a lot trying to find out why, but nothing certain, almost everywhere the same thing: "placebo is just a waste of time since it produces 1% better quality but requires 10x more encoding time"

And the question is? Even if it requires 10x more encoding time and represents the most tough settings... why it is less efficient with the same CRF encoding?

Or maybe I'm totally misundertand something...

I have noticed this effect always when I tried to encode with placebo... but in particular case for now I have input 1080p video and run x264-encoder unrestriced, setting only the preset parameter:

x264.exe --preset placebo --keyint 240 --sar 1:1 --frames 533
x264.exe --preset veryslow --keyint 240 --sar 1:1 --frames 533

And the placebo output is 5% bigger file...

I've compared output settings:

------------------------------------
preset      placebo     very slow
------------------------------------
me          tesa        umh
------------------------------------
subme       11          10
------------------------------------
fast_pskip  0           1
------------------------------------
bframes     16          8
------------------------------------

So if I understand correctly placebo settings are more efficient? But why it produces bigger file since CRF is the same in both cases, and AFAIK constant quality CRF-encoding are the same quality

So what's the deal with placebo if it encodes significantly longer and produce bigger files of the same quality?
Why does it even exist? For what purpose?

[poisondeathray]

And the question is? Even if it requires 10x more encoding time and represents the most tough settings... why it is less efficient with the same CRF encoding?

You haven't measured compression "efficiency", because you haven't measured "quality"

crf does not ensure a certain filesize, it's only a method of rate control . crf is not a measure of quality. It can be used as a rough estimate of "quality" with the same settings - but you're using different settings .

You would need to encode serial crfs e.g. crf 23.1, 23.2, 23.3, and measure the "quality" at a given filesize (e.g. ssim, psnr, vmaf etc...). You will find the quality marginally higher at a given bitrate for placebo vs. say veryslow

[aleaksunder]

So I've encoded one more time to achive the same bitrate with placebo and veryslow preset... this time I've changed CRF to 22.5 for veryslow preset so the bitrate now is 2330 for placebo and 2333 for veryslow, 3 bps is no big deal, right?

And compared both video to original using PSNR, SSIM, VMAF and VMQ techniques of MSU VQMT

Results below:

PSNR

[Attachment 48071 - Click to enlarge]

SSIM

[Attachment 48072 - Click to enlarge]

VMAF

[Attachment 48073 - Click to enlarge]

VMQ

[Attachment 48074 - Click to enlarge]

So does that mean that in case of this particular video it is better to encode with veryslow preset and CRF 22.5 than placebo with 23.0 ?

[poisondeathray]

Maybe marginally worse for placebo, but those results are probably not statistically significant on that test.

The quality metrics don't necessarily have high correlation with human perception of "quality" or "similarity" . But if you check with your eyes and zoomed in , frame by frame, it's probably quite close too , right ? You might be able to pick up some part of a frame slightly better on one, but slightly worse on the other.

What was the encoding time difference ? Probably not worth it

[sneaker]

I wonder why the devs called it "placebo".

[teodz1984]

Probably because it gives the encoder a false sense of wellness..

[aleaksunder]

What was the encoding time difference ? Probably not worth it

placebo CRF 23.0 took 25 minutes to encode
veryslow CRF 22.5 took 9 minutes to encode

So the long story short... I see this, I mean placebo's bigger files, every time when I try to encode with it, and every time file is bigger on the same CRF

So I've finally decided to point out why and what's going on here

For me it is almost clear that placebo preset is kind of thing that literally don't worth attention since I've never saw it produces smaller output file =)

And this particular test was just to check things out and indirectly prove it, since I understand that another lab test with special video sequence may result that placebo worth it, but for me in real-life placebo preset is just a waste of time... It was a waste of time even when I was trying to prove it =)

So maybe placebo is for lab, not for real-life

[Ant_G]

just my theory maybe since the search method is exhaustive, it cover more detail than you expect that make bitrate going up

[_Al_]

This is not exact science where you have equations as a rule going on. There is so many variables. If you compare different settings, hell breaks off and developers set values , presets, so it is about right, but not 100%. It is sort of glued together. The whole principal is a camouflage anyway. As a proved principal though, while measuring things is real analog world, looking at the gauge of a gadget, values are not accurate on the far left and right as well, because design is meant for about the middle.

[aleaksunder]

Yes, you are absolutely right... I just want to figure out that placebo is not worth it at least at least 90-95% of situations, because I tried it a lot of times during a long time period and every time it confuses me with the results that I can not understand... I cleary understand that there will be situations when placebo is right choice

One thing I've figured out reading all I can find about placebo preset is "placebo is just a waste of time since it produces 1% better quality but requires a lot more encoding time" ( even FFMPEG help site says about it), but this is not distinctly since all practice I saw: "it produces 1% better quality, requires a lot more encoding time and produce 5% bigger file"

So this particular encode was just to prove some guess that in 90-95% of situations you can simply slightly move CRF slider with "veryslow" preset and get at least the same or even better result without "lot more encoding time"

[Selur]

Only cases where placebo did make really noticeable improvements for me was when encoding at ultra low bit rates.
With normal rates 'very slow' (or even 'slower' or 'slow') is usually enough for me.

[aleaksunder]

Well...

I guess I've finally figured this out... "Placebo" preset is for very high quality encoding and that's only one purpose I think it's deserves it's "waste of time"

So long story short: use "placebo" only when you trying to encode as much quality as you can get out of x264... "placebo" will not get you smallest possible file size with best possible quality out of that smallest file size ( if you looking for this then use "very slow" )

"Placebo" preset in conjunction with "Grain" tune will give the best quality that encoder can get from source video IRL



So for 1-pass CRF-based encoding we may get a simple "formula":

"Placebo" preset + "Grain" tune = best quality that you can get
Maximum of the visual parts ( tiny details, fades, etc ) even not important will be captured at best

"Very Slow" preset + "Film or Animation" tune = best ratio of file size and quality from that size
Not visually important parts will be dropped on purpose to achive best file size

[Zero-11]

there is no way around placebo, it's perfect while very slow is still visually inferior

[aleaksunder]

Finally I think that the only real case when we may need placebo is when we have very high quality source material and want to get as much from it as we can with x264

So for example for video artist who produce lossless video sequence and since lossless video is not playable in most cases we want to make easily playable video with everything we can save from source with minimal losses

In that case you can and even should use "placebo" preset + "grain" tune, otherwise "Very Slow" preset + "Film or Animation" tune will be the best choice

[sneaker]

Finally I think that the only real case when we may need placebo is when we have very high quality source material and want to get as much from it as we can with x264

How did you come from to that conclusion when in your test preset veryslow was (ever so slightly) better than placebo?


I think the logical conclusion would be: never use preset placebo. It's a waste of time/electricity. You could spend that time better, e.g. better filtering.

[aleaksunder]

Finally I think that the only real case when we may need placebo is when we have very high quality source material and want to get as much from it as we can with x264

How did you come from to that conclusion when in your test preset veryslow was (ever so slightly) better than placebo?


I think the logical conclusion would be: never use preset placebo. It's a waste of time/electricity. You could spend that time better, e.g. better filtering.

In that comparison veryslow preset had better CRF, so I compared CRF 22.50 "very slow" vs CRF 23.00 "placebo"...
and I did it just to match same bitrate on "placebo" and "very slow"...

on the same CRF value "placebo" produces larger file but have better quality because placebo uses more complex motion estimation algoritm ( --me tesa ) better subpixel refinement ( --subme 11 ) and do not skip P-frames which encoder decides not worth to pay attention ( --no-fast-pskip )... and all of those parameters bumps up bitrate

So in conjunction with "grain" tune which in addition change following x264 parameter:

--aq-strength 0.5 --no-dct-decimate --deadzone-inter 6 --deadzone-intra 6 --deblock -2:-2 --ipratio 1.1 --pbratio 1.1 --psy-rd <null>:0.25 --qcomp 0.8

and AFAIK key parameters here:
--no-dct-decimate
--deblock -2:-2
--qcomp 0.8
and that parameters may have drastic effect on final quality ( especially --qcomp ) bumping up bitrate and retaining more visual details, but not always visually important.

So that's why I've made such conclusions

Placebo has very very very narrow application, and IRL I can image only people who produce original RAW-content may need it to encode their content with minimal visual and technical losses

P.S. So in a nutshell:
If you re-encode video originally encoded with some lossy-codec you will not recive any valuable gain from "placebo", just forget about it and use "veryslow" preset + "film,animation or grain" tune
And if you want to encode original "lossless" video with the best quality ( or for example to encode RAW-video to Bluray-standart AVC ) than usage of "placebo" may be reasonable
And since Bluray have limited space your best choice will be not CRF-based but 2-pass encoding with "placebo" preset + "grain" tune with target bitrate to get certain file size that will fit nicely to target medium... because I don't think that "placebo" preset set "--slow-first-pass" parameter accidentally =) Placebo exists to get the best result from the best source

[sneaker]

In that comparison veryslow preset had better CRF, so I compared CRF 22.50 "very slow" vs CRF 23.00 "placebo"...
and I did it just to match same bitrate on "placebo" and "very slow"...

on the same CRF value "placebo" produces larger file

So what? We can arbitrarily choose the CRF value. It doesn't make sense to choose one preset over another simply because it happens to produce better quality (at bigger filesize!) at a fixed CRF value when we can change CRF any time.

To take your test: why would you ever choose preset placebo CRF 23 over preset veryslow CRF 22.5 on that source if it is neither smaller nor has better quality?

[aleaksunder]

Please read topic more carefully...

Topic question was: Why x264 "placebo" preset produce bigger file than "very slow"? ( on the _same_ CRF )
And the second question was: Why does "placebo" even exists?

Answers: 1. Because it saves more visual details
2. Because it has it's own application area ( production studios where we have powerful computing equipment and encoding time do not matters at all )

That's it... No more no less
Nobody have chosed "placebo" over "veryslow"... I've imagined real situation when "placebo" becomes reasonable, since normally when you do your encode, you do not want to compare variously encoded "pass" after that change your settings and do encoding again... all you want to do is just to encode it once and be absolutely sure that you get the best from your encode considering your application area

[sneaker]

2. Because it has it's own application area ( production studios where we have powerful computing equipment and encoding time do not matters at all )

Ok, let's say I run a production studio. Going by your test: why would I choose preset placebo over veryslow? In your test veryslow was superior to placebo at the same bitrate. Production studios aren't any more keen on getting worse compression than anyone else.

[aleaksunder]

Ok, can you tell me how are going to achive same bitrate in 1-pass CRF-based encoding?

[sneaker]

Obviously I don't. But if I cared about hitting a certain bitrate I wouldn't be using CRF encoding in the first place.

[aleaksunder]

I have to thank you for your perseverance... you forced me to make another couple of tests

--preset veryslow --tune grain --pass 2 --bitrate XXXX --stats ".stats" --slow-firstpass
vs
--preset placebo --tune grain --pass 2 --bitrate XXXX --stats ".stats" --slow-firstpass

I've compared 500, 1000, 2000, 3000 bitrate encodes and always "veryslow" has better VQM-metric test average values, PSNR and SSIM differences are negligible

I just don't want to spam this message with bunch of graphs but here is 2000 VQM-result ( lower is better ):

[Attachment 48241 - Click to enlarge]

The results are almost the same on every test even 500

So finally... I do not know why does "placebo" even exists =)