CRF or CQP?

[Sharc]

The keyframe pumping (step change in sharpness) is stronger for CQP. See for example the trasition frame 249->250 or 2879->2880 (gray shirt with squares).

How it can be if CQP imply same QP to every frame so you have pure VBR? In CQP there should be no pumping unless this is not CQP but some other mode with bitrate shaping.

No pumping only if all frames were I-frames, as I understand. Both the CRF and CQP variant of sophisticle's example have I,P and B frames. The decay in quality along the timeline of a long GOP without scene change is apparently stronger for CQP encoding without AQ than for CRF with AQ support. With the next I-frame (which is independent of adjacent frames) the quality gets a "reset" so to speak, hence the jump in sharpness which is more pronounced for the CQP variant.

FWIW attached a graph showing the variable quantizer for the CRF encode with AQ from frame 2850 onwards.
For CQP it would be q=33 fix.

[pandy]

No pumping only if all frames were I-frames, as I understand. Both the CRF and CQ variant of sophisticle's example have I,P and B frames.

Apologies, this can be true but to be honest it never come to my mind idea to use long GOP with P and B frames - i see no point in using long GOP and B frames in CQP mode - then you loose CQP benefits (encoding speed) not gaining in exchange anything offered by more complex encoding modes.

CQP has practical sense when encoding speed is prioritized over filesize (bitrate) - no decision (quality vs bitrate) just quantization - personally never used CQP with restricted bitrate and more than single P in GOP (so IP,IP, IP etc) and i use P only when bitrate need to be reduced but long GOP and B frames is patology in such case - then probably you need to elevate P and B frames quality (i.e. reduce QP further for P and B to compensate accumulation of quality loss ).

--after while

briefly checked qp for both files - seem CQP apply different QP for I, P, B - perhaps this is outcome of default settings for:

      --ipratio <float>       QP factor between I and P [1.40]
      --pbratio <float>       QP factor between P and B [1.30]

Obviously with this pumping will be visible and with long GOP quality degraded.

[Sharc]

Here the same for the CQP33 encode. It varies little between 33 and 35.

[gelo333]

I don't doubt the benefits of CRF. But I'm talking about something else. I'll try to explain again. Look at the hand. Image cells shift strongly on CRF. And almost do not shift to CQP.

Compare Original an CRF
https://imgsli.com/MTgyMDY0

Compare Original and CQP
https://imgsli.com/MTgyMDY1

Compare CRF and CQP
https://imgsli.com/MTgyMDY2

[poisondeathray]

I don't doubt the benefits of CRF. But I'm talking about something else. I'll try to explain again. Look at the hand. Image cells shift strongly on CRF. And almost do not shift to CQP.

Compare Original an CRF
https://imgsli.com/MTgyMDY0

Compare Original and CQP
https://imgsli.com/MTgyMDY1

Compare CRF and CQP
https://imgsli.com/MTgyMDY2

The edge defect is probably related to AQ redistributing bits, what I referred to earlier as the main drawback of AQ . if you reduce the strength or disable AQ, and it disappears, you have your answer - then wouldn't be a "crf" issue, but an "AQ" issue. Check the other parts of the image, and the temporal consistency because they might be worse with --qp and no AQ.

AQ is only part of the story of crf , but you can reduce the AQ strength. Bits are taken away not just from object edges, but frame edges. You have to be careful with grainy or noisy sources when using AQ, because you can have a "halo" of noiseless/grainless effect around objects and frames if you use insufficient bitrate. --tune grain reduces the default AQ strength in half

I'll post some crf/qp examples later tonight or tomorrow

[Sharc]

I don't doubt the benefits of CRF. But I'm talking about something else. I'll try to explain again. Look at the hand. Image cells shift strongly on CRF. And almost do not shift to CQP.

I think I see what you mean. It would help the discussion and be more conclusive if you would also post your x264 settings, or better upload a short clip (few seconds, spanning at least a full GOP (250 frames in your case?)) of the source and of your encode.
(I wonder what your x.264 version "Mod. by Patman" is .....?)

[sophisticles]

After reading some of the comments here i realized I had made a mistake with my first test.

I redid the tests with the same source but i made some important changes:

I started with the very fast preset and no tune.

For both CRF and CQP I changed gop to 60, subme to 7, trellis to always, psy-rd to 2, trellis strength to 1.

For CRF, I also enabled mb-tree, set AQ to auto, I/P and B/P to 1.

[poisondeathray]

This is an example of --qp keyframe popping, mushy shadows and water . The camera is not moving by the end of the shot, and the 499,500 frame transition "pops" more when you use --qp (also for --crf, but less severe ). It's especially distracting because the camera is no longer moving by the end of the shot. --qp doesn't allocate spatially very well (foliage in the background shadows, or the reflections on the water of the reeds or pier, or details at the bottom of the water), or temporally very well - there is exhaustion and deterioration gradually in the GOP, until the next keyframe.


These are animated png's that should animate in most browsers, if they don't try opening in a new tab. Frametypes are the same for each P,P, then I for the keyframe

--qp


--crf


The original clip "ezsm021.mts" was 1080i29.97 from an old canon camcorder , deinterlaced to 720p59.94 using QTMGC for the test. Feel free to play with other encoding settings, other deinterlacers etc..

LWLibavVideoSource("ezsm021.mts")
AssumeTFF().QTGMC(preset="faster", sharpness=0.25, border=true)
Spline16Resize(1280,720)

Single frame comparison vs. original



Which do you think is more similar to original ? If you blindly believe metrics like PSNR , without correlating with other information - the PSNR for that frame would imply that the qp frame is more similar to original than the crf frame. PSNR is not very useful for lossy evaluations by itself, but can provide information on trends or other issues

qp frame 499
[Parsed_psnr_4 @ 0000003afda31440] PSNR y:32.555986 u:39.924648 v:44.096805 average:34.050116 min:34.050116 max:34.050116

crf frame 499
[Parsed_psnr_4 @ 0000000ac3ee1440] PSNR y:32.449817 u:40.257903 v:44.956600 average:33.976357 min:33.976357 max:33.976357



This is not a problem few edge pixels - large portions of the frame smoothed away or missing. Large areas of detail can be dramatically changed using --qp . CRF and AQ is not perfect, but at least the AQ strength and modes are adjustable. You will never get those details back with --qp unless you use much higher bitrate (and thus mcuh higher filesize). If small edge defects bother you, maybe you'd be happy with adjusting some settings such as lower AQ strength, maybe disable or lower --psy-rd - because --qp is definitely not the way to go if you want "set and forget" settings. But if you want to do a proper job of reducing the filesize while keeping details, the most important step is actually prefiltering > proper encoding settings.



I'll add some more examples in a bit, and you will begin to see a trend as what areas tend to be "very bad" with --qp encoding

[poisondeathray]

Mushy shadows are a common problem with --qp encoding (has more to do with no AQ). Ever decent modern encoder, open source or commercial, uses some form of AQ. Only the cheap low SKU bundled versions do not. The high end expensive ones all have some form of AQ options. Dark , smooth areas are underallocated for alpha and beta stages because all early development optimizes for PSNR. This typical example from a sci-fi dvd

It depends on your display setup, calibration , for some people these might look similar. TV's generally show more shadow and highlight detail rolloff compared to PC monitor setups, because TV's are usually setup for limited range RGB out of the box

Again, apng


But if you watch on a proper display setup, or you boost the gamma a bit, you can see how much detail is actually lost by --qp encoding . These are both p frames. That's a significant quality difference and detail loss from --qp encoding, not just a few edge pixels

apng with gamma boost



more coming...

[Sharc]

After reading some of the comments here i realized I had made a mistake with my first test.

I redid the tests with the same source but i made some important changes:

I started with the very fast preset and no tune.

For both CRF and CQP I changed gop to 60, subme to 7, trellis to always, psy-rd to 2, trellis strength to 1.

For CRF, I also enabled mb-tree, set AQ to auto, I/P and B/P to 1.

It doesn't help.
See Keyframe pulsing frame 2869->2870 for CQP, much less so for CRF.
And see how CQP wipes the powerlines in the sky on the top of the frames around 2137. CRF preserves them more complete. Similar loss of details exist for other frames for CQP.
CQP is inferior compared to CRF.

[gelo333]

I don't doubt the benefits of CRF. But I'm talking about something else. I'll try to explain again. Look at the hand. Image cells shift strongly on CRF. And almost do not shift to CQP.

Compare Original an CRF
https://imgsli.com/MTgyMDY0

Compare Original and CQP
https://imgsli.com/MTgyMDY1

Compare CRF and CQP
https://imgsli.com/MTgyMDY2

With the help of Gimp, I made a blending of the layers to show the difference in the images. Obviously, the deviation in CRF is stronger.

Difference between Original and CRF.


Difference between Original and CQP.

[gelo333]

My encoder 0.164.3094+13-7816202-.Mod-by-Patman.-x64-gcc11.2.0

All settings it is default.

[gelo333]

These are animated png's that should animate in most browsers, if they don't try opening in a new tab. Frametypes are the same for each P,P, then I for the keyframe

Merge with difference for your examples

Difference between original and CRF


Difference between original and CQP

[poisondeathray]

More shadow mush. In any --qp encode, check the shadow detail, it will usually be "mushy"




Blocky skies, and blockier skies. The "blue skies" are both bad, as it's 8bit and crf 23 is lowish quality, but look at the quantization difference. The banding/blocking is worse with qp . For people with bad eyes or bad display and can't see it , histogram("luma") is an enhanced mode. The original has a fine pattern, --crf has blocks, but --qp has coarser blocks. 10bit encoding with proper settings usually helps with this type of banding, but if you're "set and forget", you'd need more bitrate to make it look ok using --crf , and even more when using --qp

orig

crf

qp

original enhanced view

crf enhanced view

qp enhanced view



If you go back to the dark scenes on the DVD example, notice the worse blocks in flat areas introduced with --qp. --crf is blocky, but --qp will have worse, coarser, "blockier" artifacts. This is the gamma boosted view, apng again



The blocks are from higher quantizers assigned to those areas. The artifacts tend to flicker in motion - noisy/blockiness in the shadows. That was one of the more frequent complaints when x264 was being used often, and it's made worse using --qp. So many complaints, that other AQ modes were developed. x265 has several more AQ modes than x264.

It's actually the same phenomenon. This is the underlying reason why --qp gives more blocky artifacts compared to --crf . You can see this on anything with flat gradients, such as certain types of anime, cartoon shading

[gelo333]

I don't understand why you are comparing Q=23 in CRF and Q=26 in CQP. It is natural that 23 will be better than 26.

I read the comments and realized that I-frames affect the quality. I set GOP 1/10 and the quality really improved for both CQP and CRF. But the problem still remains. The skin on the forehead does move in CRF:




this CQP

[poisondeathray]

I don't understand why you are comparing Q=23 in CRF and Q=26 in CQP. It is natural that 23 will be better than 26.

Forget the crf or qp number, they are irrelevant and arbitrary. The crf scale was rebalanced several times in x264 development (e.g. crf 18 meant something different 12 years ago than crf 18 today)

You compare at the same bitrate (also the filesize, because filesize=bitrate*running time) . You do serial encodes and adjust either the crf and/or qp until the bitrates match (or close) . --qp only accepts positive integer values, but --crf can accept decimal values. That's why there are things like CRF 23.2 in that example. CRF 23 produces a file too large. 13.27MB is slightly larger than 13.1MB, but the delta is within acceptable limits

I read the comments and realized that I-frames affect the quality. I set GOP 1/10 and the quality really improved for both CQP and CRF. But the problem still remains. The skin on the forehead does move in CRF:

Warping areas like that forehead example are usually from bad motion vectors. But you would expect the same problem in --qp rate control

Post your source.

I read the comments and realized that I-frames affect the quality. I set GOP 1/10 and the quality really improved for both CQP and CRF. But the problem still remains

What does that mean GOP 1/10 ? --keyint 10 ?

If you reduce the max keyframe interval, the filesize will generally increase for a given quality (whatever "quality" means, or how you're measuring or viewing it). Shorter max keyframe interval means lower temporal compression. Longer keyframe intervals have potential for higher temporal compression (with diminishing returns)

[Sharc]

I don't understand why you are comparing Q=23 in CRF and Q=26 in CQP. It is natural that 23 will be better than 26.

What you don't understand is that the numbers for CRF and CQP do not have the same meaning, nor do they represent an absolute quality.
The number in CRF stands for the rate factor (also called distortion rate factor). The value for --qp in CQP specifies the quantizer for the P-frames. Two different pairs of shoes.
Comparison has to be done for same file size (=same average bitrate) rather than same value for --qp and --crf.

(Edit: Just noticed that poisondeathray has already explained this above).

CRF is not perfect either, just generally better than CQP as has been demonstrated ad nauseam now and in the past. Don't you recognize the CQP deficiencies, or are you just trolling?

A scenario of (transient, few frames) non-perfect bitrate control has been discussed here:
https://forum.doom9.org/showthread.php?t=175662&highlight=mp3dom
It was however attributed to buffer control mechanisms (VBV constraints) rather than anything else, and I don't think this applies in your case.

[gelo333]

What does that mean GOP 1/10 ? --keyint 10 ?

keyint_min=1 / keyint=10

Warping areas like that forehead example are usually from bad motion vectors. But you would expect the same problem in --qp rate control

With all the examples, I have shown that the problem with shifting parts of the image is much less in CQP.

Don't you recognize the CQP deficiencies, or are you just trolling?

I already wrote that I recognize the benefits of CRF, but I'm interested in a specific problem with changing the image. Perhaps there is some tricky codec setting that fixes this.

Source File
history of file: downloaded from somewhere a very long time ago, and then cut without re-encoding by Virtualdub. Now I've cut this scene into Avidemux without re-encoding.
https://drive.google.com/file/d/1X2kaqez2PXMmh03SX6INeuF7pyl6Nr5j/view?usp=share_link

[gelo333]

The edge defect is probably related to AQ redistributing bits, what I referred to earlier as the main drawback of AQ . if you reduce the strength or disable AQ, and it disappears, you have your answer - then wouldn't be a "crf" issue, but an "AQ" issue. Check the other parts of the image, and the temporal consistency because they might be worse with --qp and no AQ.

I mean not only the edges, but the semi-shadows inside the object (hand), on the fingers, on the metacarpus, on the joints. I already spoke about the influence of AQ, it will be necessary to do more precisely with screenshots.

[jagabo]

The skin on the forehead does move in CRF:

Turn down psy-rd. This is part of x264's psy optimizations. The idea is that you are less likely to notice (at normal playback speeds) slightly inaccurate moving edges than you are other types of errors like posterization (note the dark area on the head of the guy on the left).

[Platos]

I wonder sth similair too on this question, which encoding mode ist best, but for NVEnc (h265).

What would you say is the best quality per filesize? I personally use always variable bitrate. I testet it with several sources and for me it was waaay better than constant quality. But i never used constanz quantisizer or constant bitrate except for lossless.

What would you say ? And why ?

[Sharc]

Source File
history of file: downloaded from somewhere a very long time ago, and then cut without re-encoding by Virtualdub. Now I've cut this scene into Avidemux without re-encoding.
https://drive.google.com/file/d/1X2kaqez2PXMmh03SX6INeuF7pyl6Nr5j/view?usp=share_link

A possible reason why this clip is not clearly inferior using CQP may be because this source - or this particular and pretty "homogenuous" dark scene - has been encoded with --qp 24 already. Hence there is perhaps little to gain by re-encoding this scene with CRF. A speculative thought only, no science.
jagabo raised a good point regarding the "deformations" caused by psy-rd activities aiming at best perceived real-time visual experience.

[Sharc]

I wonder sth similair too on this question, which encoding mode ist best, but for NVEnc (h265).

Wonder why NVIDIA was striving hard to support B-frames with their GPU encoders?
Constant quantizer (CQP) and CRF produce both variable bitrates b.t.w.

[pandy]

Constant quantizer (CQP) and CRF produce both variable bitrates b.t.w.

But CRF provide some form of bitrate control when CQP not (perhaps you can set maximum bitrate to not overload decoder) - CQP with bitrate control begin drifting into CRF area only without all psy-tuning stuff.

[gelo333]

I experimented with the psi and AQ settings, reducing the compression. I realized that the movements in the picture are related to the essence of CRF. These are operations with object areas for rate allocation on the image.

It turned out like this
--crf 20 --no-psy --aq-mode 0

[jagabo]

Now you have a video full of blocky posterization artifacts.

[Sharc]

Despite the tiny "movements" I prefer the CRF encode (CRF 23.1, preset slow, rest default settings) over the more blotchy dark areas of the CQP (qp 23) encode. Even more so because the rest of the movie will be more natural daylight scenes, I assume.
Surprisingly and by chance the CQP and CRF values are almost the same for the same filesize, for this case.

[gelo333]

Now you have a video full of blocky posterization artifacts.

Did I do wrong? The only thing that I was told about my problem was to disabled AQ and psy.

I have come to a new conclusion. do not use CRF for low bitrate. since it is impossible to manipulate the quality if this quality is not enough. Therefore, such artifacts of quality assignments arise. The minimum bitrate to use CRF is probably 1000 kbps.

[Sharc]

I have come to a new conclusion. do not use CRF for low bitrate. since it is impossible to manipulate the quality if this quality is not enough. Therefore, such artifacts of quality assignments arise. The minimum bitrate to use CRF is probably 1000 kbps.

You have to be cautious with such conclusions based on a single and special scene like in your case. The bitrate for acceptable quality depends on the complexity of the pictures, of the scene and the resolution. Poor sources with noise and compression artifacts present an extra challenge for the encoder and drive the bitrate up just for reproducing the "crap" of the source and avoid introducing additional artifacts at the same time. If one is re-encoding compressed material and reducing the filesize (bitrate) by a factor of 4 like in your case one has to accept a quality loss. AQ (for CRF) and psy-rd are x264 encoder settings for assigning the bits most efficiently for the "best" real-time viewing experience (however you perceive it). A means to choose your poison in a way, depending on what you are looking for.
If you want a perfect reproduction make a copy or use --qp 0 or --crf 0 for x264.

[gelo333]

On the whole, is it true that quality should be enough to assign quality? And that below 1000 kbps it is more correct not to use CRF?