CRF x CQP

[Makaveli84]

I think by now I pretty much understand all the nuances and aspects of different 1-pass encoding techniques in h.264, except for one detail really. Which of the below 3 statements is most accurate?

a) CRF, via the look-ahead technique, produces higher "perceptible" quality than CQP because it redistributes the bits it saves in high motion scenes to the more still scenes, kind of in the same way like 2-pass encoding.

b) CRF produces the exact same "perceptible" quality as CQP only at a lower disk space cost, because it saves unnecessary bits in high motion scenes, while applying the same quantizer as CQP in the more still scenes.

c) The truth is that CRF actually does some combination of both a and b. If this is the case, maybe someone can actually explain how that practically works, because to me, it's either save the bits, or redistribute them. If CRF does both, how does it technically decide when and where to splurge or save??

Thanks for your help!

[MasterNobody]

"a" is more correct, but it doesn't have anything todo with lookahead (if we don't count MBTree which can be disabled as part of CRF). Also main advantage of CRF (vs CQP) is that it allow to use AQ (and MBTree).

[Makaveli84]

"a" is more correct, but it doesn't have anything todo with lookahead (if we don't count MBTree which can be disabled as part of CRF). Also main advantage of CRF (vs CQP) is that it allow to use AQ (and MBTree).

1) Well, regarding "lookahead", I was under the impression that it's actually lookahead that paves the way for AQ in CRF. I mean if bits saving is mostly related to complex scenes where the human eye can't really notice the lesser quality (i.e. high motion scenes), then how is lookahead not responsible for it? So my understanding is that CQP doesn't use lookahead, whereas CRF does as a crude simulation of 2-pass encoding.
qp mode also disables adaptive quantization, since by definition 'constant quantizer' implies no adaptive quantization.
[...]
You should generally use --crf instead, although qp doesn't require lookahead to run and thus can be faster.


2) Regarding the whole issue, I myself was also under the impression that "a" is most accurate. But again, the X264 documentation really implies that "c" is more accurate, and here's how:
qp produces larger files than --crf for the same visual quality.
+
The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space.
+
The bits saved in frames like these are redistributed to frames where they will be more effective.
All of this implies that CRF both raises and lowers the user set quantizer depending on the scene (i.e. redistributing the bits), while still saving bits at the same time, thus producing smaller files than CQP at a similar perceptible quality. So what gives? How does CRF both save and redistribute the bits?!

[Asmodian]

I agree that a is more correct but not fully correct.

crf uses exactly the same rate control as two pass, the only difference is what the average bit rate is. Think of two pass as auto-crf, the crf value picked to achieve a target average bit rate.

I have no idea how x264 decides fast motion scenes, it isn't simple afaik, but crf doesn't need to know how long they are; it just needs to be able to distinguish them.

You cannot redistribute bits in crf because you do not have a set pool of bits you need to share out. Bits saved are not really given to the low motion scenes; low motion scenes are just encoded to meet a quality target too. At a given crf the low motion scenes in a high action movie will be the same quality and size as the low motion scenes in a low action movie. Just total file size is different. Of course this is true of the high motions scenes as well.

[akupenguin]

I mean if bits saving is mostly related to complex scenes where the human eye can't really notice the lesser quality (i.e. high motion scenes), then how is lookahead not responsible for it?
Amount of motion can be estimated by comparing the current frame the the previous, without knowing anything about future frames. And spatial complexity can be estimated from the current frame alone. There are more optimizations that can be made if you know the future frames too, but they're not necessary.

How does CRF both save and redistribute the bits?!
There is no difference in principle between saving bits at the same quality and improving quality at the same bitrate. When an x264 developer says "option X improves quality", or "option X saves bits", or "option X improves quality-per-bitrate", we mean "Option X improves quality at any given bitrate, and reduces bitrate at any given quality, but might not keep either quality or bitrate constant. You might have to adjust the value of the primary ratecontrol variable (--crf or --qp or --bitrate, whichever you're using) to compensate." If option X increases both quality and bitrate, as long as the improvement is more than the cost I'll still call it "saves bits", because you could have increased --crf.

raises and lowers the user set quantizer depending on the scene
The argument to --crf is not a quantizer. It's an entirely different measurement scale, which happens to be calibrated such that CRF=x produces QP=x on a medium complexity block/frame/scene/whatever, or QP<x on low complexity, or QP>x on high complexity. "Medium" is defined as "average complexity over the set of movies I calibrated it on". The definition of "medium" is purely a matter of user interface; if I had chosen a constant 1 higher, then all the users would have picked CRF values 1 lower, and the resulting encodes would be exactly the same as they are now.

AQ and MBTree had to be calibrated likewise.

[Makaveli84]

akupenguin,
I'm glad to hear from an x264 developer. However, I am aware of most of what you said regarding improving the quality-per-bitrate concept and that CRF's argument is not a quantizer.
And even knowing all of this, my question still stands. I will try to clarify what I'm asking, but first, let me re-quote 2 statements from the CRF section in the X264 settings wiki:
The bits saved in frames like these are redistributed to frames where they will be more effective.
but also,
The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space.
Obviously, both those statements are accurate, so this can only mean that CRF n saves more bits then CQP n in complex or high motion scenes than it spends more then CQP in low motion scenes, which in turn means that CRF produces smaller files then CQP.

So my question is a double layered one:

1) If CRF saves or spends more than CQP depending on the scene/frame, how is it known beforehand that it will produce a smaller file then CQP?

2) If producing smaller files is how the CRF algorithm is programmed, will it not produce lower quality then CQP in certain cases where the video is mostly or almost entirely consisted of low motion scenes?

[Asmodian]

The argument to --crf is not a quantizer. It's an entirely different measurement scale, which happens to be calibrated such that CRF=x produces QP=x on a medium complexity block/frame/scene/whatever, or QP<x on low complexity, or QP>x on high complexity.

Given this statement I think you can say the quality and size for a crf encode would be better and larger, not worse and smaller, in your theoretical low complexity video. It isn't coded based on total bit rate vs. a qp encode at all. The wiki just applies as "usually on normal movies".

You can set a high min-qp if you want to keep low motion scenes from getting lower QPs.

[ajp_anton]

akupenguin,
I'm glad to hear from an x264 developer. However, I am aware of most of what you said regarding improving the quality-per-bitrate concept and that CRF's argument is not a quantizer.
And even knowing all of this, my question still stands. I will try to clarify what I'm asking, but first, let me re-quote 2 statements from the CRF section in the X264 settings wiki:

but also,

Obviously, both those statements are accurate, so this can only mean that CRF n saves more bits then CQP n in complex or high motion scenes than it spends more then CQP in low motion scenes, which in turn means that CRF produces smaller files then CQP.

So my question is a double layered one:

1) If CRF saves or spends more than CQP depending on the scene/frame, how is it known beforehand that it will produce a smaller file then CQP?

2) If producing smaller files is how the CRF algorithm is programmed, will it not produce lower quality then CQP in certain cases where the video is mostly or almost entirely consisted of low motion scenes?Maybe it keeps low-motion scenes close to qp quality but decreases high-motion quality where it can't be seen, hence smaller files but looks about the same.

[Makaveli84]

Asmodian, I've done some additional researching, reading and testing, and I don't think what you said is entirely accurate. The way I understand it now, CRF n cannot produce better quality in larger file size than CQP n. It either produces same "perceptual" quality at a smaller file size, or very-close-to-same-actual-quality at same size as CQP n in a theoretical low-complexity and low-motion video. So you were right about the part of CRF not being coded in a less bit-rate than CQP manner, and that the "smaller file size" is a generalization in the wiki that applies to most "real-life" cases.

Anyways, thanks to all who replied. I have a better understanding of how CRF actually works now. I think the wiki over simplified some things as well as went a little overboard in tying how CRF and CQP work, when in fact, and from what I got from the replies in this thread, CRF doesn't really rely on CQP, but rather has a somewhat independent algorithm of its own.

[akupenguin]

Asmodian is entirely correct.

[Makaveli84]

Asmodian is entirely correct.
In saying that CRF n might produce a larger file and better quality encode than CQP n on a theoretical low-complexity low-motion video??

[Vurbal]

I find it simplest to think about the difference between CRF and CQ in more generic terms. Imagine instead of a bunch of blocks, frames, scenes or whatever unit you pick you were simply looking at a list of numbers representing measurements, which you are more or less. Each measurement has the same precision (ie number of decimal places). For example, 10.5827325 and 12.0000000 have the same precision.

To save space required to store these numbers you round them, which is an incredibly simplistic way of thinking about quantization. You can round all your numbers to the exact same decimal place (CQ mode) so they all have the same accuracy (once again number of decimal places). If you round those numbers to the nearest thousandth you get 10.583 and 12.000. Once you have rounded them, though, you can never reverse the process exactly. If you expand (decode) them you will end up with 10.5830000 and 12.0000000.

Even though you've rounded to the same decimal place (used the same quantizer), the first is substantially different than the source when decoded but the second is identical. For all practical purposes the first is lossy and the second lossless. It's not really lossless. It's still only accurate to the nearest thousandth and it always will be. But you will never be able to tell the difference.

Using CRF mode is like rounding each number to a variable decimal place based on how much the choice actually changes the value. On one hand a lower (smaller) decimal place can be sacrificed in every number, but sometimes a number can be rounded more without changing at all. Going back to those original numbers, you might round the first one to 10.5827 and the second to just 12. Even though you've used fewer digits (bits) this time, the first number has retained more original detail compared to rounding blindly and the second remains lossless.

Like I said, it's an extreme simplification, and in reality the difference is typically not whether there's visual loss but how much and how consistent it is. And consistency is an important part of the equation too. If you look at two blocks right next to each other, or two consecutive frames, where one is visibly worse than the other it can actually seem worse than if both were encoded at the lower quality.