Fade-in ugly blocking problem, any progress?

[Dr.D]

Official....720.....519,548...bad
Ranguvar.950.....653,958...average
Ranguvar.965.....653,932...average
Ranguvar.965-2..324,079...disaster
Ranguvar.977.....810,358...good
Surprise surprise, totally useless test is totally useless! :rolleyes:

If your eyes exactly follow the bitrate curve, that is "high bitrate looks better than low bitrate," your test says absolutely nothing because we already know that.

Always do comparisons at the same bitrate, anything else is dishonest and pointless.
Useless and pointless for whom?

Dark Shikari, I'm not looking for the best (or satisfactory) encoder for fades only. It's not a my business to encode fades. Instead of that I'm looking for satisfactory encoder for whole movies with (possibly) fades. Also I always use crf mode and decided to use some value, let say 25.0.
For people, like me, my test is not useless. It says - don't use builds which destroy fades. For example, Ranguvar.965-2 bulid is good for the rest of movie, but I have to refuse it.

Your suggestion - "Always do comparisons at the same bitrate" - is definetely correct in common, but useless for this thread. Let say the Ranguvar.965-2 bulid is the best for my faded testing clip for bitrate 3000. And what? What conclusion can I make? This build the best for whole movie for crf 25? Why?
I can only make conclusion, that the build is best for fades only. But, again, it's useless for me.

[Audionut]

All those builds are different in more ways then one. ie: patches applied, code changes etc.

You didn't seem to comprehend something like inloop deblocking, so i gather that you are unaware of the difference that the different patches etc are making to the code.
Patches and code changes, by their design, change the output.


Comparing crf of different builds is completely useless.
It is so pointless, it's like having a conversation about physics with a blonde.

[Sagekilla]

@Dr. D: The reason why your test was useless was because of: (1) The varying bitrate (2) the different builds and (3) the use of CRF instead of bitrate.

Try encoding using 2-pass bitrate using the same bitrate for all encodes to ensure each build gets a fair number of bits to allocate to the clips, then you'll see which one is doing well on fades.

[Dark Shikari]

Useless and pointless for whom?

Dark Shikari, I'm not looking for the best (or satisfactory) encoder for fades only. It's not a my business to encode fades. Instead of that I'm looking for satisfactory encoder for whole movies with (possibly) fades. Also I always use crf mode and decided to use some value, let say 25.0.
For people, like me, my test is not useless. It says - don't use builds which destroy fades. For example, Ranguvar.965-2 bulid is good for the rest of movie, but I have to refuse it.

Your suggestion - "Always do comparisons at the same bitrate" - is definetely correct in common, but useless for this thread. Let say the Ranguvar.965-2 bulid is the best for my faded testing clip for bitrate 3000. And what? What conclusion can I make? This build the best for whole movie for crf 25? Why?
I can only make conclusion, that the build is best for fades only. But, again, it's useless for me.I'm not 100% sure what you're trying to say--are you saying you used 2pass mode for the whole clip, and the numbers you're posting are the bitrate allocated to the fade?

[Dr.D]

All those builds are different in more ways then one. ie: patches applied, code changes etc.

You didn't seem to comprehend something like inloop deblocking, so i gather that you are unaware of the difference that the different patches etc are making to the code.
Patches and code changes, by their design, change the output.
:D. Thank you for a few minutes of good laughing, Mr. Smart Guy!

Comparing crf of different builds is completely useless.
It is so pointless, it's like having a conversation about physics with a blonde.
Oh, that's even better!
Ok, my Lord, please teach me.
What should I do to decide - choose a new build or keep the old one. Step by step.
Keep in mind that I use crf only, the value is 25.0 and I'm not going to change the value without a serious reason.

[Dr.D]

My 965-2 build used VAQ2mod, among many other odd patches. Output would be drastically different. Please read the notes I post :) Default settings are not default across builds/revisions.
As for the recent build, CRF was adjusted to give more bitrate at a given CRF, due to offset caused by AQ.
Interesting, for all my "regular" testing clips bitrate has been decreased (or increased just slightly).

Glad to see you sorted the problem!
Thanks! :)

[Dr.D]

@Dr. D: The reason why your test was useless was because of: (1) The varying bitrate (2) the different builds and (3) the use of CRF instead of bitrate.

Try encoding using 2-pass bitrate using the same bitrate for all encodes to ensure each build gets a fair number of bits to allocate to the clips, then you'll see which one is doing well on fades.
Well, it makes sense, but only if 1) I will test whole clip (or a combined - part with fade-in and large non-faded part); 2) use regular bitrate based encodes.
It makes some sense if I test whole or combined clip and use regular crf encodes.
It doesn't make any sense if I test faded piece only.

Please keep in mind that:
1) I use crf only.
2) Testing clip is fade-in only piece.

[Dr.D]

I'm not 100% sure what you're trying to say--are you saying you used 2pass mode for the whole clip, and the numbers you're posting are the bitrate allocated to the fade?
I use crf always.
The numbers are filesizes for encoded cut-off fade-in piece mentioned in this post: http://forum.doom9.org/showthread.php?p=1183889#post1183889.

I really can't understand what is so complicated or specific in my logic.
I thought is very simple, so may be my explanations were bad.
Ok, another try.

I've encoded my clip (30 minutes) with Ranguvar.965-2 build and --crf 25. Few fade-ins were terrible (less than 1 minute total), the rest of the clip was fine.
I cut off one fade-in and used for testing.
Encoded (with crf 25) cut-off had very low bitrate, it was a clue.
I've played with parameters - just minor improvement.
This allowed me to say that fades handling is bad.
Then I've updated to Ranguvar.977, encoded (with crf 25) cut-off was fine.
As usually, before choosing another buils, I've encoded the few my testing clips - was fine (quality not worse, size not bigger).
This allowed me to say that in this build fades handling is good.
Then for curiosity I've tested another builds (with crf 25) and posted the results.

What's wrong here?
Why I need same-bitrate testing for cut-off fade only piece?
Why I need same-bitrate testing testing at al, if (for particular type of sources)
- I used to use crf 25
- I'm using crf 25 now
- I will use crf and I will use the value 25 until very serious reason to change it
- my children will use crf 25
- my grandchildren will use crf 25?

[Dark Shikari]

I use crf always.
The numbers are filesizes for encoded cut-off fade-in piece mentioned in this post: http://forum.doom9.org/showthread.php?p=1183889#post1183889.

I really can't understand what is so complicated or specific in my logic.
I thought is very simple, so may be my explanations were bad.
Ok, another try.

I've encoded my clip (30 minutes) with Ranguvar.965-2 build and --crf 25. Few fade-ins were terrible (less than 1 minute total), the rest of the clip was fine.
I cut off one fade-in and used for testing.
Encoded (with crf 25) cut-off had very low bitrate, it was a clue.
I've played with parameters - just minor improvement.
This allowed me to say that fades handling is bad.
Then I've updated to Ranguvar.977, encoded (with crf 25) cut-off was fine.
As usually, before choosing another buils, I've encoded the few my testing clips - was fine (quality not worse, size not bigger).
This allowed me to say that in this build fades handling is good.
Then for curiosity I've tested another builds (with crf 25) and posted the results.

What's wrong here?
Why I need same-bitrate testing for cut-off fade only piece?
Why I need same-bitrate testing testing at al, if (for particular type of sources)
- I used to use crf 25
- I'm using crf 25 now
- I will use crf and I will use the value 25 until very serious reason to change it
- my children will use crf 25
- my grandchildren will use crf 25?So if I made a patch that made it so that all CRF bitrates doubled completely arbitrarily (and quality doubled along with it), you'd say that patch was the greatest thing ever? :rolleyes:

You cannot compare two encodes at different bitrates. End of story.

[gizzin]

Whats the recommended tool for cutting x264 in a mp4 container?

[cyberbeing]

So if I made a patch that made it so that all CRF bitrates doubled completely arbitrarily (and quality doubled along with it), you'd say that patch was the greatest thing ever? :rolleyes:

You cannot compare two encodes at different bitrates. End of story.

I think you're missing his point. CRF is based on rate control of some sort. The rate control decides where and how many bits to allocate to each frame to meet a certain metric. Now lets say you have two builds each with a different variation of CRF rate control. With the two builds you encode a clip at CRF25. Lets for arguments sake say they come out at exactly the same size and avg bitrate (not likely but bare with me). One of the two clips had average quality throughout. Lets call this "average quality", "CRF25 quality". The other of the two had above average quality (CRF20 quality) in 95% of the video but below average (CRF30 quality) in 5% (fades). Only average "CRF25 quality" was needed so the one with both above average "CRF20 quality" and below average "CRF30 quality" gets junked. Basically he has a certain quality expectations of CRF25. If one build's CRF rate control gives more consistent quality then another he views it as better.

If you theoretically made a patch which doubled CRF bitrate that doesn't solve his dilemma. All the means is that in order for him to meet his quality expectations he would end up using a higher CRF because CRF25 all of a sudden started producing "CRF10 quality" and that's not what he wants. If the build isn't keeping what he sees as the quality expected from a given CRF even in areas where a disproportionate amount of bitrate may be required to maintain that quality he sees it as a failure. In other words he is unhappy when encoding in CRF mode and x264 decides to starve bits from complex areas (lets say because 4x the average bitrate is needed to maintain quality and it only allocates 2x) and in turn quality drops.

Now this opinion is a bit flawed in many respects, but not totally unwarranted if you look at it from his point of view. Bitrate doesn't matter to him, only the average "CRF25 quality" he expects maintained throughout the whole clip not just most of the clip.

[Dark Shikari]

I think you're missing his point. CRF is based on rate control of some sort.I don't think you're one to be lecturing me on how CRF works, given that I wrote a large portion of it.

CRF is scaled in a completely arbitrary manner to be somewhat similar to QP in terms of filesize. It has at least 2 or three completely arbitrary constants thrown in for this purpose.

Also, the entire point of constant ratefactor is the entire video has the exact same ratefactor, the exact same CRF. If you specify CRF25, the video will be all CRF25. There is no part which is magically 20 or 30.

[cyberbeing]

I don't think you're one to be lecturing me on how CRF works, given that I wrote a large portion of it.
Thank you for taking my quote way out of context. :rolleyes: Those two sentences were completely unrelated to each other (I should have made a new paragraph).

Also I don't know how you got the idea I was trying to lecture you. I was trying my best to talk in theoretical terms and trying to be as vague as possible. I was in no way claiming that was how CRF works. It was just written that way to try to explain the logic from what I see as his point-of-view, not to be accurate.

That's also why I said the opinion (my above post is not my own opinion but what I view his as) was flawed in many respects, but I think that's how he is viewing CRF as more of a subjective quality metric and not how it actually works.

[Audionut]

only the average "CRF25 quality" he expects maintained throughout the whole clip not just most of the clip.

There is no part which is magically 20 or 30.


So just to expand on that, if a scene requires qp of 20 to look decent, with encoding at crf 25, you're shit out of luck.

Doesn't matter how many times you guys want to explain your reasoning, the result is still the same.

You cannot compare two encodes at different bitrates. End of story.

[Dark Shikari]

So just to expand on that, if a scene requires qp of 20 to look decent, with encoding at crf 25, you're shit out of luck.But QP isn't CRF.

CRF varies the QP on a block-by-block and scene-by-scene basis to match a certain metric.

[cyberbeing]

So, trying to be solution oriented, if Dr. D wants to avoid subjective quality drops in parts of a clip but doesn't in the process want to add extra bitrate to parts he thinks look fine, what is the best way for him to achieve that?

[nm]

Zones, if manual adjustment is acceptable.

But I doubt his problems were really in rate control but the two things: missing decoder deblocking and the differences in CRF value mapping between builds.

I would suggest this test to Dr D., if he's interested in a valid experiment.
1. Select a clip with a fade and a minute or two of normal content.
2. Make a CRF=25 encode with a build that you claim encodes fades poorly (Ranguvar.965-2). Check the resulting bitrate or file size.
3. Make a CRF=X encode with a "good" build. Select X so that the resulting bitrate is about the same as in the first encode (you'll need to make a few encodes to find the correct X).
4. Compare the encodes visually.

[Quark.Fusion]

then i've compared the sizes and qualities of different builds. For fair comparison i've used default settings with --crf 25.0:

Official....720.....519,548...bad
ranguvar.950.....653,958...average
ranguvar.965.....653,932...average
ranguvar.965-2..324,079...disaster
ranguvar.977.....810,358...good

surprise surprise, totally useless test is totally useless! :rolleyes:

If your eyes exactly follow the bitrate curve, that is "high bitrate looks better than low bitrate," your test says absolutely nothing because we already know that.

Always do comparisons at the same bitrate, anything else is dishonest and pointless.
I think Dr. D wanted to say that metric used for CRF in ranguvar.965-2 failed to provide requested quality and ranguvar.977 do the job. Now it needs to see what patches was applied and what is difference in CRF handling in those builds.
When you request CRF control from x264 you want consistent quality across the clip.

[cyberbeing]

I think Dr. D wanted to say that metric used for CRF in ranguvar.965-2 failed to provide requested quality and ranguvar.977 do the job. Now it needs to see what patches was applied and what is difference in CRF handling in those builds.

This is what I was trying to explain in my previous post a couple up (#111 (http://forum.doom9.org/showpost.php?p=1184751&postcount=111)) in a rather roundabout manner.

When you request CRF control from x264 you want consistent quality across the clip.After some of Dark Shikari's posts in this thread I'm starting to have doubts that this is how CRF is supposed to work, unless he has been misunderstanding the questions. From his posts it sounds like, from a technical standpoint, CRF's goal isn't to produce consistent quality.

[Quark.Fusion]

I'm also starting to suspect that CRF is supposed to give consistent bitrate instead of quality after some posts in this forum… But if CRF is supposed to replace QP then first is wrong, else last is wrong…

[Sharc]

For a valid and fair comparison of crf based encodes I would suggest
1. The test clip should include not only the fade scene, but a pre-and post "normal" scene of a few seconds each.
2. Comparison has to made on equal file size = equal average bitrate in order to compare apples with apples.
3. Assuming crf mode, this means that for different patches and encoding parameters one needs to adjust (trial-and-error !) the CRF such as to obtain equal file sizes of the encoded test clip. Keeping crf at a fixed value (like crf 25) producing different filesizes is pointless.

[cyberbeing]

I'm also starting to suspect that CRF is supposed to give consistent bitrate instead of quality after some posts in this forum… But if CRF is supposed to replace QP then first is wrong, else last is wrong…

Well how does x264 define consistent quality considering it is objective from person to person? I'm assuming this is impossible 100% of the time without some sort of AI or intelligent adaptive algorithms that are able to accurately judge quality for every possible situation.

It also probably goes back to a that a given QP does not directly represent quality over a number of frames and since it sounds like CRF is in some way based on QP it suffers from the same problem.

[Quark.Fusion]

1. Clip can contains only fades —*think about slideshow of photos.
2. In this case you compare quality-to-bitrate, but you may want to compare quality only. (and it will be oranges with oranges, not apples with apples)
3. If CRF means quality-based encode and you want to compare how it do this job, then you shouldn't adjust it to size. Equal file sizes provides 2-pass or CRF is meant to replace 2-pass with trial-and-error?

[Quark.Fusion]

well how do you define consistent quality considering it is objective from person to person? I'm assuming this is impossible 100% of the time without some sort of ai or intelligent adaptive algorithms that are able to accurately judge quality for every possible situation.

It also probably goes back to a that a given qp does not directly represent quality over a number of frames and since it sounds like crf is in some way based on qp it suffers from the same problem.
1) I'm define consisnet quality as when clip don't breaks to blocks suddenly accross the clip and when you encode two diferent clips quality drop from source is same, not that in first case you get only blocks and in second transparent video.

2) Yes, it what I'm understand as psy-optimisation purpose.

[Sharktooth]

the CRF value is not a quality factor...
it has some relations to a certain level of quality but it changes between revisions, builds and options used for encoding.

[Inventive Software]

CRF uses a range specified between QPmin and QPmax to achieve xx.x ratefactor, that is nearly equivalent to QPxx in file size. Nearly being the operative word. Do a comparison between QP18 and CRF18 or QP20 and CRF20 and see which you prefer. I can't do it, cos I'm at work, but note the file sizes. They should be nearly equal.

[nm]

1. Clip can contains only fades —*think about slideshow of photos.
But in this case the question was whether rate control fails in some builds so that fades don't get enough bits compared to the rest of the encode. You can't test that without including both fades and normal content in the same video.

2. In this case you compare quality-to-bitrate, but you may want to compare quality only. (and it will be oranges with oranges, not apples with apples)
To compare two different encodes, either the quality or the bitrate needs to be anchored. If both vary, conclusions can only be made if one of the encodes has both better quality and lower average bitrate. In practice, it is easiest to anchor the average bitrate and compare visual quality.

3. If CRF means quality-based encode and you want to compare how it do this job, then you shouldn't adjust it to size. Equal file sizes provides 2-pass or CRF is meant to replace 2-pass with trial-and-error?
No, just pick a CRF that pleases you and use that for (almost) all sources. But as Sharktooth said, that CRF value may need to be adjusted when you update x264 or change the encoding options. Equal file sizes and trial-and-error are needed for comparisons between CRF encodes.

[Sharktooth]

also ratecontrol didnt fail. the problem was experimental patches used and the flawed testing method.

[Dr.D]

You cannot compare two encodes at different bitrates. End of story.
Ok, simple question for you.
Let say I have 2 builds, build1 and build2 and encode same clip with crf 25. The clip is 30 min long and has 1 min faded part.
Build1 gives bitrate 200 and awful quality for the faded part and bitrate 2000 for the rest.
Build2 gives bitrate 900 and good quality for the faded part and bitrate 2000 for the rest.
But Build1 encodes faded part better with 2-pass bitrate 900 encoding (as you suggest to test).

Which build handles fades better?

[Sharktooth]

such a build doesnt exist... unless you completely screw x264 by adding experimental patches...

[poisondeathray]

This was already suggested back on page 1, but I would encode with zones (e.g. crf20 for the 1min fade section, crf25 for the rest) - it's setup so it's very easy to do in MeGUI

Dr.D - Are you planning to run these tests on every patch and revision? or find a good revision to stick with and never upgrade?

[Audionut]

I'm also starting to suspect that CRF is supposed to give consistent bitrate instead of quality after some posts in this forum… But if CRF is supposed to replace QP then first is wrong, else last is wrong…

It was often thought that QP was constant quality.
However, 1 frame might look "good" with a quantizer of 18 but another frame might look, "not so good".

CRF mode was designed to alleviate that to a certain extent by varying the quantizer of frames in an encode while still maintaining an average of the quantizer set.

So as pointed out by Inventive above, if you do encode 1 at QP 20 and encode 2 at CRF 20, they both should have around the same bitrate. (although, this could have changed with the recent updates)

However, while encode 1 is blind quantizer 20 throughout, encode 2 uses a little bit of look ahead and variation to produce a theoretically more pleasing result for the viewer.

At least, that's how I recall it.

[Dr.D]

So just to expand on that, if a scene requires qp of 20 to look decent, with encoding at crf 25, you're shit out of luck.

Doesn't matter how many times you guys want to explain your reasoning, the result is still the same.
It's not the case.
The case is - at crf 25 fade scene requires qp 30 to look decent, encoder (some builds) give it qp 40.
Doesn't matter how many times I tried to explain that, you and some other do not understand.

[Sharktooth]

no. you do not understand... dont use experimental patched builds for final "production" or for bugreports.

[Dr.D]

Zones, if manual adjustment is acceptable.
No, thank you.
I don't need to spend hours to tweak parameters for each clip.
I'm expecting a constant quality for whole clip and for each clip.
Situation, when fades looks like shit and the rest of the clip looks fine is not a constant quality. In my understanding, at least.
So, I try to find a combination of parameters or a proper build. If I can't, I'm looking for another encoder. Plane and simple.

I would suggest this test to Dr D., if he's interested in a valid experiment.
1. Select a clip with a fade and a minute or two of normal content.
2. Make a CRF=25 encode with a build that you claim encodes fades poorly (Ranguvar.965-2). Check the resulting bitrate or file size.
3. Make a CRF=X encode with a "good" build. Select X so that the resulting bitrate is about the same as in the first encode (you'll need to make a few encodes to find the correct X).
4. Compare the encodes visually.
This definetely makes sense.
But, again, not for me.
Let say, I've found that X=22 and the quality is better. And what? Anyway I'll encode at CRF=25, for this CRF the quality could be worse than with the "bad" build.

[Quark.Fusion]

I was extreme to some extend in my previous posts to emphasize my point. I'm just don't understand why when developers introduce new features to CRF they want to make it same bitrate as before instead of quality or avg QP at least or don't care at all.

[Quark.Fusion]

So, I try to find a combination of parameters or a proper build. If I can't, I'm looking for another encoder. Plane and simple.You should try recent official GIT build at first.

[Audionut]

I'm just don't understand

The changes make the algorithm theoretically better "overall".

If people don't have the ability to adjust the crf value themselves to maintain the bitrate they want, :stupid: well, developer can't help that. ;)

[Quark.Fusion]

The changes make the algorithm theoretically better "overall".

If people don't have the ability to adjust the crf value themselves to maintain the bitrate they want, well, developer can't help that.

I think you misunderstood me. I'm perfectly happy if algorithm is better overall. And my point if you want same bitrate — use two pass or CRF2size program.

[Sharktooth]

exactly. so i cant understand all those complaints. CRF is not about bitrate... if you want a specific bitrate use a bitrate RC mode...

[nm]

I'm expecting a constant quality for whole clip and for each clip.
Situation, when fades looks like shit and the rest of the clip looks fine is not a constant quality. In my understanding, at least.
Indeed, but you haven't yet shown us anything that supports such observations.

Let say, I've found that X=22 and the quality is better. And what?
Then you have proved that the build (or the encoding options) produce better, or in this case, more constant quality. However, we would need to see the encodes to believe your results. ;)

[Dr.D]

For a valid and fair comparison of crf based encodes I would suggest
1. The test clip should include not only the fade scene, but a pre-and post "normal" scene of a few seconds each.
2. Comparison has to made on equal file size = equal average bitrate in order to compare apples with apples.
3. Assuming crf mode, this means that for different patches and encoding parameters one needs to adjust (trial-and-error !) the CRF such as to obtain equal file sizes of the encoded test clip. Keeping crf at a fixed value (like crf 25) producing different filesizes is pointless.
Well, this is good point, but I still don't agree.
CRF values should mean something. Like, for example - CRF 18 (with best another options) gives transparent quality. If this value jumps from build to build - I think it's not normal.

Here is my logic (simlified) to decide - move to a new build or not.
I encode a few test clips with a new build and same parameters (or, if a new feature-parameter has been introduced, I do both - with and without this parameter).
If filesizes are bigger - I stop testing and keep the old build.
If smaller, I make a visual comparison.
If noticeable worse - stay with old, otherwise - move to the new build.

[Audionut]

CRF values should mean something. Like, for example - CRF 18 (with best another options) gives transparent quality.

Why should they mean something?

Read the forum rules. There is no best, and what is transparent to you, could be something totally different to another.

[nm]

Well, this is good point, but I still don't agree.
CRF values should mean something. Like, for example - CRF 18 (with best another options) gives transparent quality. If this value jumps from build to build - I think it's not normal.
It doesn't usually jump significantly, but there have been some patches and changes that have caused larger variations. Like the VAQ2mod patch seems to do in Ranguvar's build that you used, and the AQ changes caused in r968. Have you read this thread: http://forum.doom9.org/showthread.php?t=141124

Still, making quality comparisons at the same CRF value is not a valid approach unless the average bitrates match, as has been repeated over and over again.

[Dr.D]

This was already suggested back on page 1, but I would encode with zones (e.g. crf20 for the 1min fade section, crf25 for the rest) - it's setup so it's very easy to do in MeGUI
Thanks, but it's a very last suggestion what I would to try. You see, I need "find and forget" technology and ready to spend extra time to find a good one. I don't need to spend time with each clip then.

Dr.D - Are you planning to run these tests on every patch and revision? or find a good revision to stick with and never upgrade?
Well, now I'm happy with the rang_977 build.
My strategy for future: once per month (or earlier, if I'll found some serious issue; or some WOW feature will be introduced) test the newest build as described here: http://forum.doom9.org/showpost.php?p=1184980&postcount=142

[Dr.D]

such a build doesnt exist... unless you completely screw x264 by adding experimental patches...
It does.
Not exact numbers, of course, but the same idea:

build.....faded piece..."normal" piece...ratio
Off 720......519,548....5,437,664.......10.5
Rang965-2..324,079....4,299,049.......13.2
Rang977.....822,764....4,106,181........5.0

This numbers tell me, that Rang977 build handles fades better than Off 720 and much better than Rang965-2.

[Dr.D]

I'm expecting a constant quality for whole clip and for each clip.
Situation, when fades looks like shit and the rest of the clip looks fine is not a constant quality. In my understanding, at least.

Indeed, but you haven't yet shown us anything that supports such observations.

Sure I can. But why you don't believe me? Otherwise, why I've started this thread? To blame developers? No, I don't need that. I need good encodes only.

[Dr.D]

the CRF value is not a quality factor...
it has some relations to a certain level of quality but it changes between revisions, builds and options used for encoding.
What I can't understand, why the developers don't keep it same, instead of this force millions user to spend a lot of time to find proper CRF value again and again...

[LoRd_MuldeR]

What I can't understand, why the developers don't keep it same, instead of this force millions user to spend a lot of time to find proper CRF value again and again...

Because when the behavior of the encoder changes, the meaning of the CRF value changes inherently. And if you want the encoder to improve (which I think you want ^^), the behavior must change. Of course the CRF value could be multiplied with some "magic" factor internally, so the CRF values specified by the user doesn't change it's meaning over different revisions. But it would be really hard to find that "magic" factor and it even might vary between different sources. So we simply have to life with changing CRF behavior. The CRF mode does an awesome job anyway...

[Sharktooth]

It does.
Not exact numbers, of course, but the same idea:

build.....faded piece..."normal" piece...ratio
Off 720......519,548....5,437,664.......10.5
Rang965-2..324,079....4,299,049.......13.2
Rang977.....822,764....4,106,181........5.0

This numbers tell me, that Rang977 build handles fades better than Off 720 and much better than Rang965-2.
numbers tell me you're a noob and as such you should not play with experimental builds that do not represent the x264 true encoding efficiency and quality potential.
that said you have no rights to criticize the encoder and jump to wrong conclusions if you dont even know the builds you tested have experimental patches and some of them have not even been wrote by the x264 devs.