Could you list the TOP most important parms for x264 ?

[MarcioAB]

1) If I use [ --crf xx ] and associated bitrate is yy and now encode [--pass 2 --bitrate yy ], can I assume without any doubt that overall quality will be better ?

2) Leaving --bitrate and --crf aside, I would like to know from your experience, what are the TOP most important params in x264 I should concentrate to manipulate to improve quality (at first time is no problem, but avoid much waste is nice).

3) In multipass encode, I understand there is a kind of "intelligence" in the encoder to choose where to compress more and where to compress less. Is this "intelligence" free to the programmer to choose ? (example: could be possible to analyze luminance in each frame and if dark, compress much less ?)

Thank you
Marcio

Edit: Dark Shikari is correct. I meant CRF not QP (original post updated)

[Dark Shikari]

1. Possibly, but why use QP? Use CRF, and that most definitely is no worse than 2 pass.

2.

--trellis 2
--subme 6 or better
--bframes 3 or better
--ref 3 or better
--b-pyramid
--partitions all
--8x8dct
--me hex or better
--bime
--b-rdo
--mixed-refs
--direct auto
--weightb

are some popular ones.

[MarcioAB]

Thank you. Can I assume the first ones are the most important ?

[Dark Shikari]

Thank you. Can I assume the first ones are the most important ?
Well important is a relative term.

Important for what?

Why would one not use all the useful commands? If your question is "which ones have less speed impact relative to their quality impact", that's a different question.

[Tack]

If your goal is to improve quality at the cost of everything else (encoding time and bitrate), then I would use CRF, a custom CQM (such as *.mp4 guy's HRM matrix or the Prestige matrix, both of which can be found here) with AQ and avoid trellis.

These are the settings I use:
crf=20:frameref=10:partitions=all:bframes=4:threads=0:ssim:psnr:subq=7:mixed_refs:bime:nodct_decimate:weight_b:nofast_pskip:me=umh:me_range=24:cqm=/home/tack/.mplayer/prestige.matrix:brdo:b_pyramid:aq_strength=0.8:aq_sensitivity=17:8x8dct

These are the settings that satisfy my eyes the most. If this is important to you, I highly recommend you spend a weekend and do some (preferably blind) testing on some clips representative of the content you intend to encode.

Have fun :)

[MarcioAB]

considering ...
considering ...

1) Can I say that encoding oriented to maximize quality, a "minimal" base list could be something similar this ?:

--8x8dct
--bime
--mixed-refs
--b-rdo
--b-pyramid
--subme 7 (minimal 6)
--me umh (minimal hex)
--bframes 4 (minimal 3)
--weightb
--no-fast-pskip

2) So, [ --mixed-refs ] should not be is this "minimal" list ?


3) I was not able to find params below in MeGUI. Am I missing something ?

--partitions all
--direct auto
aq_strength=0.8
aq_sensitivity=17
nodct_decimate


4) Is frameref=xx the same as --ref xx ? If so, 10 vs 3: why such a difference ?


5) CRF vs 2-Pass: Just to double-check: Based on your experience, for EXACTLY the same bitrate 2-Pass will not be better than CRF ? (to my poor logic, it seems the encoder could better decide, collecting first information from the entire content, distribute based on same kind of "intelligence" and finally encode).


6) Custom CQM with AQ: OK for custom CQM (thanks), but what is AQ ?
EDIT: Just saw the Sagekilla post [ X264's Adaptive Quantization ] and will follow this one from there.

Thank you
Marcio

[Manao]

2 passes will be a tiny bit better, but it is generally agreed that if you don't care about the finalsize, CRF is the best speed/quality tradeoff. However, if you don't care about speed, then 2 passes is definitely the way to go.

The same is true for --ref : 3 is the usually best tradeoff between speed and quality, but some will go up to 10 nonetheless, because they don't care about speed ( Between 2Pass vs CRF and 10 ref vs 3, 2 pass brings more quality than 10 refs ).

Keep direct=auto, and partitions=all (though it could be argued that p4x4 isn't that important ).

[Dark Shikari]

Here's a test I did a few days ago on 40,000 frames of a DVD movie (denoised with FFT3Dfilter).

The "base" setting was --ref 16, --subme 7, --no-fast-pskip, --me umh, and so forth. To be exact:

--trellis 2 --merange 64 --subme 7 --bframes 16 --ref 16 --no-fast-pskip --b-pyramid --partitions all --aq-strength 0.5 --8x8dct --me hex --bime --b-rdo --mixed-refs --direct auto --progress --weightb --threads 2 --thread-input --pass 2 --bitrate 1000 --deblock 0:0

Here is the loss in quality, respectively, for each of these changes:

--ref 12 0.07%
--ref 6 0.15%
--ref 2 3.07%
--ref 1 7.01%
--trellis 1 3.12%
--subme 6 1.48%
--no-fast-pskip removed 1.43%
--merange 32 -0.01%
--merange 16 0.11%
--me hex 1.70%

High --ref values are quite literally useless on non-animated material. --trellis 2 proves to be pretty useful, and --subme 7 proves to be relatively ineffective: half as useful as --trellis 2 and about the same as --no-fast-pskip. --me umh also seems to be similar, but it halves encoding speed.

--merange seems to be totally useless on most standard-def material.

[Sagittaire]

6% for Elephant Dream between --trellis 2 --subme 7 --me umh and --trellis 1 --subme 6 --me hex. High Merange value can be usefull for HD content.

[MarcioAB]

Here is the loss in quality, ...6% for Elephant Dream ...
Allow me to ask: How to measure "loss in quality" ?

Thank you
Marcio

[Manao]

Sagittaire measures it in % of bitrate at same PSNR, which is an OK way to do it.

Dark Shikari uses his own formula based on SSIM ( 1/(1-SSIM) ), but it doesn't mean much as such.

[MarcioAB]

.
Regard PSNR and SSIM, please allow me to expose my experience and a quick question:

I extracted PSNR and SSIM from each frame of a sample (aprox 36000 frames) and used avisynth [ stackhorizontal(in,out) ] to visit each frame to compare the best and specially the worst numbers.

The best is much more difficult, but for the worsts, in no case PSNR or SSIM matched my opinion about "bad" visual quality. I looked frame by frame and find many really "bad" visual quality (in my opinion) that neither PSNR or SSIM was bad.

So, do you really believe/accept PSNR or SSIM as a way to measure quality and extract conclusions based on them ?

[Terranigma]

1. Possibly, but why use QP? Use CRF, and that most definitely is no worse than 2 pass.

2.

--trellis 2
--subme 6 or better
--bframes 3 or better
--ref 3 or better
--b-pyramid
--partitions all
--8x8dct
--me hex or better
--bime
--b-rdo
--mixed-refs
--direct auto
--weightb

are some popular ones.

If that's in chronological order for the most important factor to
least, then i'd have to disagree.

From personal experience, I'd arrange it like so:

1. entropy encoding (cabac)
2. subme (7)
3. in-loop deblocking
4. reference frames (5 is totally ok, but 16 would be better, but by only a small margin)
5. mixed-refs
6. bframes (3-16, preferably 16)
7. b-rdo
8. weighted b prediction
9. b-pyramid
10. trellis (1 or 2. 1 is fine, I use 1. Show me some substantial evidence where trellis 2 would be much better than 1.)
11. direct auto
12. 8x8dct
13. motion estimate (umh, esa is just insane)
14. motion estimate range (16 is toally fine, even for hd content, imo, but the best possible value is 64)
15. Adaptive Quantization (0.3). Only available as a patch.
16. Custom Matrices


Of course there's other important parameters, but I listed the ones I think would affect the quality the most in chronological order. :)

[Tack]

So, do you really believe/accept PSNR or SSIM as a way to measure quality and extract conclusions based on them ?Most people here recognize that PSNR or SSIM or any other algorithmic-based measure of quality rarely maps to the subjective perception of quality. At least not once you pass a certain threshold (maybe a PSNR of 40 or so).

But talking about subjective quality makes the conversation somewhat meaningless unless the participants are careful, because quality in the psychovisual sense is going to vary from person to person.

As a concrete example, in spite of the fact that trellis consistently increases global PSNR, I consistently disfavour trellis in self-administered blind tests. The problem really is that I've done so many of these damn tests on myself, I've really rather ruined any possibility that I can be "objective" because my eyes immediately seek out areas of video I know to be traditionally troublesome in terms of artifacting. To someone else, trellis could well look better, because their eyes wander to spots mine don't.

But at the very least, PSNR/SSIM let us see objectively in what direction a setting will affect the result. We can't stop here of course, and everyone must decide for themselves what they think looks better, but at that point it becomes a lot more difficult to express results.

[Sagittaire]

So, do you really believe/accept PSNR or SSIM as a way to measure quality and extract conclusions based on them ?

PSNR is not absolute measure of quality. Frame at 35 dB could be very good for eyes and Frame at 45 dB very bad for eyes. PSNR is a relative measure of quality (relating to the source). For example encoding at 40 dB will be really good for eyes with really noisy source. x264 use internal PSNR computation for quality search and better psnr for the same source mean generaly better quality for eyes too (I don't speak here for HVS setting like AQ, Custom Matrix ...)

[MarcioAB]

From personal experience, I'd arrange it like so:Terranigma, that was EXACTLY my initial expectation regard the question, so:

Considering "in-loop deblocking" ( --deblock <alpha:beta> ) is so high in the list, could we have a very quick advice (or link) regard alpha and beta based on yours and all here experience ?

Custom matrices so low in the list: Interesting. So is <NONE> reasonable ?

Thank you
Marcio

[Dark Shikari]

If that's in chronological order for the most important factor to
least, then i'd have to disagree.

From personal experience, I'd arrange it like so:

1. entropy encoding (cabac)
2. subme (7)
3. in-loop deblocking
4. reference frames (5 is totally ok, but 16 would be better, but by only a small margin)
5. mixed-refs
6. bframes (3-16, preferably 16)
7. b-rdo
8. weighted b prediction
9. b-pyramid
10. trellis (1 or 2. 1 is fine, I use 1. Show me some substantial evidence where trellis 2 would be much better than 1.)
11. direct auto
12. 8x8dct
13. motion estimate (umh, esa is just insane)
14. motion estimate range (16 is toally fine, even for hd content, imo, but the best possible value is 64)
15. Adaptive Quantization (0.3). Only available as a patch.
16. Custom Matrices


Of course there's other important parameters, but I listed the ones I think would affect the quality the most in chronological order. :)
No, I didn't mean it in order in any way.

I would disagree slightly with that list; --subme 7 provides relatively minimal benefit over --subme 6 (as I showed earlier); its useful, sure, but not that high on the list.

--trellis 2 is basically always better than --trellis 1; my tests showed, as I pointed out earlier, a roughly 3% SSIM boost at the same bitrate. That's twice as good as the boost from --subme 7.

[MarcioAB]

Most people here recognize ...Fully understand you. In some point I was considering that even looking slowly frame-by-frame and noticing all the issues, like I did, was also not appropriated.

100% agree a number to express visual quality result is necessary. It's just difficult to understand why so talented people like all here was not yet able to find any algorithm to better express the visual quality.

Thanks
Marcio

[MarcioAB]

PSNR is not absolute measure of quality...
Sagittaire, I see, but for example, assume I have a 2 frames sample with PSNR as 35 and 45. Than I change a parm I want to prove will increase quality and end up with numbers like 40 and 40.

Did the quality improve ?

Thank you
Marcio

[MarcioAB]

..

Maybe a 2-dimensions in 1-dimension list like this one below could give a better perspective:
Obs: The order is not correct (please correct it). It's just an example based on Terranigma proposal crossed with Dark Shikari proposal.

1. entropy encoding (cabac)
2. subme (7)
3. in-loop deblocking
4. subme (6)
5. reference frames (16, by only a small margin)
6. reference frames (5)
7. trellis (2)
8. mixed-refs
9. bframes (16)
10. bframes (3)
11. b-rdo
12. weighted b prediction
13. b-pyramid
14. trellis (1)
15. direct auto
16. 8x8dct
17. motion estimate (umh, esa is just insane)
18. motion estimate range (16 is toally fine, even for hd content, imo, but the best possible value is 64)
19. Adaptive Quantization (0.3). Only available as a patch.
20. Custom Matrices

Thank you
Marcio

[Dark Shikari]

Sagittaire, I see, but for example, assume I have a 2 frames sample with PSNR as 35 and 45. Than I change a parm I want to prove will increase quality and end up with numbers like 40 and 40.

Did the quality improve ?

Thank you
Marcio
It probably improved as the quality became more consistent. The eye notices inconsistent quality more than it notices overall bad quality.

SSIM is a much better indicator than PSNR. What you have to take into account in addition to SSIM is primarily the fact that one bad area of an image, or one bad area of a video, is a lot worse than slightly reducing the quality of everything else.

This is the problem with highly optimizing video encoders; they may decide that creating an ugly block here would save enough bitrate to increase the quality a lot more over there. But what we see is the ugly block.

[MarcioAB]

... is primarily the fact that one bad area of an image, or one bad area of a video, is a lot worse than slightly reducing the quality of everything else.

This is the problem with highly optimizing video encoders; they may decide that creating an ugly block here would save enough bitrate to increase the quality a lot more over there. But what we see is the ugly block.

Fully agree. At least my eyes/brain works like that. Is there any parms in x264 that we can use to minimize this problem ?

Obs: I'm running MSU application [ Blocking (MPEG-4) Beta comparison ] to see if my eyes/brain agree with that. It's very time consuming (on Intel 6600 2.4GHz dual-core at 70% cpus utilization).

[Dark Shikari]

Fully agree. At least my eyes/brain works like that. Is there any parms in x264 that we can use to minimize this problem ?

Obs: I'm running MSU application [ Blocking (MPEG-4) Beta comparison ] to see if my eyes/brain agree with that. It's very time consuming (on Intel 6600 2.4GHz dual-core at 70% cpus utilization).
I think --no-dct-decimate or whatever the commandline is helps.

Actually, an idea just struck me: add a new feature to x264 that does the following; it wouldn't be hard (it would be an optional commandline of course):

Commandline: --qf --qf-threshold
Variables: block-width, block-height

Quality Fixer does the following:

1. At the end of encoding an area of the frame equivalent to a block of block-width and block-height, QF is activated.
2. QF does SSIM on the block. If SSIM is less than qf-threshold, it estimates how many more bits are needed to get the quality equal to or above qf-threshold.
3. In the case that SSIM is less than the threshold, the block is re-encoded with a newly estimated quantizer.
4. (Possibly) repeat process until SSIM is above threshold.
5. (Possibly) do the above if SSIM is a lot above the threshold in order to lower the SSIM and save bits. In other words, find the area of the frame where lots of bits are being wasted and fix that.

It would be time-consuming, but it could provide a visually optimum result.

It could even be a new ratecontrol option: not only would it provide a target SSIM, but it would also provide an equal SSIM in all portions of the frame.

[Terranigma]

No, I didn't mean it in order in any way.

I would disagree slightly with that list; --subme 7 provides relatively minimal benefit over --subme 6 (as I showed earlier); its useful, sure, but not that high on the list.
Subme with RDO in general, not just subme 6 or 7. Using a subme level under 6 would give you a similar quality level that a .avi container would yield (which is limited in almost every aspect when it comes to h.264 encoding). From a visual standpoint (without doing a ssim/psnr test), you can easily see the differences between 5 and 7. 7 will give you a great picture, while 5 would give a sorta undetailed result. This's why I have is as no.2. :)

Terranigma, that was EXACTLY my initial expectation regard the question, so:

Considering "in-loop deblocking" ( --deblock <alpha:beta> ) is so high in the list, could we have a very quick advice (or link) regard alpha and beta based on yours and all here experience ?

Custom matrices so low in the list: Interesting. So is <NONE> reasonable ?

Thank you
Marcio
--filter -3,-3 (In-Loop)
Actually, all those options are important. I mentioned custom matrices in the first place, because the default quantization tend to block. Try looking for the "Prestige CQM".

One thing I forgot to mention, that should also be on the list (Very High, maybe like no.4 or 5), is the deadzone options. This affects grain retention.

[foxyshadis]

3) I was not able to find params below in MeGUI. Am I missing something ?

--partitions all
--direct auto
nodct_decimate


I don't know if this is still a problem for you, but here:
http://foxyshadis.slightlydark.com/random/meguimissingoptions.png
AQ still requires custom, as you surmise.

When you reordered the list, lower values should be higher on it than higher. (ie, subme 6 is more important than subme 7, as it provides more benefit compared to the amount of extra time it requires than 7. 7 still provides more absolute benefit, of course. Trellis and reference frames are the same way.) In fact some time ago, someone posted a comparison of most of the options with speed hit and quality gain listed, ordered by the ratio of the two; might have been manao or akupenguin.

[Sagittaire]

Fully understand you. In some point I was considering that even looking slowly frame-by-frame and noticing all the issues, like I did, was also not appropriated.

100% agree a number to express visual quality result is necessary. It's just difficult to understand why so talented people like all here was not yet able to find any algorithm to better express the visual quality.

Thanks
Marcio

Simply because metric in practice work very well for codec developpement and for all the codec in the world ... it's simply like that. PSNR seem not work for you but it's simply because you don't know how work metric and how use metric. for a same frame if the PSNR increases then generaly visual quality will increase too. You can't compare differents frames with PSNR: frame A with PSNR at 35 dB could be visually better for eyes than frame B with PSNR at 45 dB for a same video source. Simply because The PSNR is not an absolute measurement of quality ...

[ToS_Maverick]

Fully agree. At least my eyes/brain works like that. Is there any parms in x264 that we can use to minimize this problem ?

at the moment, the only way is to use Adaptive Quantisation (AQ), wich works quite well.

just to be complete, here's my current preferred setting:


--crf 20.0 --level 3 --keyint 100 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 1835 --vbv-maxrate 10000 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "" --aq-strength 0.9


i personally don't like trellis, because it "optimizes away" too much. without it, the picture looks more harmonic, to me. to me it's worth the bitrate increase of 3 % for a faster compression.

beware, i optimize my settings for a good overall "look" and a balanced encoding speed, not for maximum compression or good metrics.

[Terranigma]

Oh, I must warn you. Never use trellis 2 for 2-pass encoding (At least for the first pass anyways). Doing so would surely cause an erratic behavior; corrupting your encode in the end
e.g.
Presenting blocks where it should'nt be present, not using a high enough bitrate for certain frames, etc...

Only use trellis 2 for the final pass. You can, however, safely use trellis-1 without any noticeable side effects as you would if you use trellis 2 for the passes where it gathers stats.

[MarcioAB]

I don't know if this is still a problem for you ...Yes, it is. Well, it was now: Very clear/helpful picture. So --partitions equals -- analyse. OK got it.When you reordered the list ... (ie, subme 6 is more important than subme 7)My expectation is to have a list ordered by the importance of parm in QUALITY with no respect to encode time or size. In that sense, --subme 7 should be more in the top regard --subme 6 because 7 will produce better quality then 6. Please, see the clean version of the listIn fact some time ago, someone posted a comparison of ...Very interested in it, but could not find it so far.

[MarcioAB]

Actually, an idea just struck me: add a new feature to x264 that does the following ...If I understood correctly, in some sense, you addressed my 3rd question in the first post:

3) In multipass encode, I understand there is a kind of "intelligence" in the encoder to choose where to compress more and where to compress less. Is this "intelligence" free to the programmer to choose ? (example: could be possible to analyze luminance in each frame and if dark, compress much less ?)

The difference I was looking to encode based on luminance and you propose based on SSIM.

I still have a problem with SSIM or I am still trying to understand SSIM, but it sounds a great idea to me: give us some control of the "intelligence".

[MarcioAB]

... for a same frame if the PSNR increases then generaly visual quality will increase too. You can't compare differents frames with PSNR...
Yes, I do not know, but please allow me to reply:
- "for the same frame ..."
- "you can not compare diff frames ..."
Ok, but in the end we will be comparing different frames because that is what video is: sequence of different frames.

Back in my example: If I have a sample with 2 frames and PSNRs are 35 and 45, and I apply a parm that give me now 39 and 39, what can I say ?

Let's assume for example, the first frame with 35 was visually bad and now with 39 became good and the 2nd frame with 45 was good and now with 39 it is still good (sure not as good as 45, but still visually good). I will say that parm I applied increased the quality despite the mean PSNR became reduced.

[Theliel]

entropy encoding (cabac) only enhanced compression, not affect to IQ.

I think that is impossible determinate. You only can compare the same frame. Its posible that now the 2nd frame with 39 are so bad that the old 1st 35, or maybe 1st frame with 39 dont have enought IQ. Differents frames different IQ.

[Terranigma]

entropy encoding (cabac) only enhanced compression, not affect to IQ.

And because of that, it saves a ton on the bitrate (Now i'm sounding a bit like the slogan for the geico auto insurance). This's why I chosed it as the most important factor, but this's just my opinion. h.264 is meant for high compression wasn't it, or am i'm wrong in thinking that? :confused:

[Theliel]

of course :)

i said this because i belive that MarcioAB want search only the IQ parameters "Importance in Quality (no care about time or size)". of course, if cabac save up arround 30% in size, you always can increase the bitrate and increase the IQ

[MarcioAB]

entropy encoding (cabac) only enhanced compression, not affect to IQ.

(assuming IQ = Image Quality = My personal judgment of Image Quality )

If I encode a source keeping the same bitrate (of filesize) and set CABAC in the 1st and not set CABAC in the 2nd, I guess IQ will be better in the 1st than the 2nd. Is that true ?

Maybe I should say the list is for "no care of time encode" but keeping the same bitrate.

EDIT: Read your 2nd post now. Correct: Definitively must adjust the context of the list.

[MarcioAB]

I think that is impossible determinate. You only can compare the same frame. Its posible that now the 2nd frame with 39 are so bad that the old 1st 35, or maybe 1st frame with 39 dont have enought IQ. Differents frames different IQ.

(assuming IQ = Image Quality = My personal judgment of Image Quality )

Its possible that now the 2nd frame with 39 are so bad ...
Yes, but it is also possible that the large drop in the 2nd frame, from 45 to 35 may still generate a good visual quality to me (or IQ).

That is my problem with SSIM and PSNR. I know we need numbers to compare, personal opinion is too much subjective, check frame by frame is boring and that I just did it in 3 medium size samples, but all of them indicated me such discrepancies regard my concept of bad image quality versus SSIM and PSNR.
I can judge much more easily bad frames than the good ones.

[Sagittaire]

Let's assume for example, the first frame with 35 was visually bad and now with 39 became good and the 2nd frame with 45 was good and now with 39 it is still good (sure not as good as 45, but still visually good). I will say that parm I applied increased the quality despite the mean PSNR became reduced.

Yes I confirm that you don't know how work PSNR. The best way to compare quality video is Overall PSNR and not Average PSNR. Overall PSNR measure simply distortion between 3D matrix. In your example Overall PSNR could be better for 39,39 than for 45,35. But for me your example is typically a Rate Control tweak. In the reality if you use better ME/RDO search then 39db and 45db will generaly become 39.5 dB and 45.5 dB.

PSNR work good if you know how work PSNR. If you use CQM, AQ or other HVS setting then PSNR can't help. If you change only internal search for x264 (ME, RDO ... ect) then better OPSNR mean generaly better quality for eyes.

[DeathTheSheep]

3) In multipass encode, I understand there is a kind of "intelligence" in the encoder to choose where to compress more and where to compress less. Is this "intelligence" free to the programmer to choose ? (example: could be possible to analyze luminance in each frame and if dark, compress much less ?)
There is an underlying rate control algorithm you can tweak. It sticks more quality in better places, to put it simply, sacrificing some from highly complex scenes and sticking it in low-motion/complexity scenes in the attempt to deceive the eye into thinking the overall quality is the same high level. ...Well that's one funky way of putting it :D. qcomp, ratetol, etc....

[MarcioAB]

Yes I confirm that you don't know how work PSNR.Ok.
The best way to compare quality video is Overall PSNR and not Average PSNR. Overall PSNR measure simply distortion between 3D matrix.
Ok ( quick question: Is this Overall PSNR the same as Global PSNR in x264 output ?)
If I understood well, OPSNR treat the entire video as a single picture. I wonder how a single number can be so meaningful for 200000 frames, but ok, let me respect that and use it as an auxiliary indicator.

After each PSNR "judgment", I tend to go to the "crime scene" and check. My perception (IMO) is that PSNR can see well "blurry" and "color shift" parts, but it is blind to "blocky".

To my taste, "blocky" is the worst part, followed by "blurry" and almost no care about "color shift".

In your example Overall PSNR could be better for 39,39 than for 45,35. But for me your example is typically a Rate Control tweak.
It is just an example to easy communication. I do not have such 2 frames.

In the reality if you use better ME/RDO search then 39db and 45db will generaly become 39.5 dB and 45.5 dB.Correct. Tend to agree that PSNR/SSIM increase in both frames means the right move. The question is when one increase and the other decrease and/or when PSNR increase and SSIM decrease or vice-versa. Was that a good move. But ok, let us move on.

PSNR work good if you know how work PSNR. If you use CQM, AQ or other HVS setting then PSNR can't help. If you change only internal search for x264 (ME, RDO ... ect) then better OPSNR mean generaly better quality for eyes.
Thank you.

[MarcioAB]

There is an underlying rate control algorithm you can tweak.
qcomp, ratetol ? Could I have any comments on how these parms could work to improve the point you mention below ?

It sticks more quality in better places, to put it simply, sacrificing some from highly complex scenes and sticking it in low-motion/complexity scenes in the attempt to deceive the eye into thinking the overall quality is the same high level. ...Well that's one funky way of putting it :D. qcomp, ratetol, etc....
Nice. Like to move in this direction. Looking for something that could sacrifice some bits from highly clear (more light) areas in one frame and use them into more dark/low motion in another frame, even if those frames are 200000 frames apart.

Thank you