crf=16 & qcomp=1 is not the same as qp=16, and also qcomp=0.999 > qcomp=1...?

[SlowDelivery]

I was playing around with x264 (core 157 r2969 d4099dd) as I recently got into encoding and noticed a couple of unexpected things.
Here are the list of settings I used and the corresponding file sizes. (the source was 1920x1080p 23.976 YV12, with some static and dynamic scenes)

--crf 16 --qcomp 0.6 45774 kb
--crf 16 --qcomp 0.7 51052 kb
--crf 16 --qcomp 0.8 57875 kb
--crf 16 --qcomp 0.9 67228 kb
--crf 16 --qcomp 0.95 73215 kb
--crf 16 --qcomp 0.99 78848 kb
--crf 16 --qcomp 0.999 80253 kb
--crf 16 --qcomp 1 69940 kb
--qp 16 --qcomp 0 56139 kb
--qp 16 --qcomp 1 56139 kb

Some remarks:
- File size increases monotonically with increasing qcomp, but drops at qcomp=1
- qcomp=0.999 and qcomp=1 give very different file sizes
- qp=16 gives a much smaller file size than crf=16 & qcomp=1 (but I thought setting qcomp=1 makes it a constant quantizer mode?)

Are these settings supposed to be doing this or could I be doing something wrong?

[Blue_MiSfit]

You're doing it wrong no matter what. Don't mess with the RC algorithm like this.

If you want CRF, use it. If you want fixed QP for some weird reason, use it.

[SlowDelivery]

You're doing it wrong no matter what. Don't mess with the RC algorithm like this.

If you want CRF, use it. If you want fixed QP for some weird reason, use it.

Just trying things out of curiosity, there's no harm in that:)

[amichaelt]

- qp=16 gives a much smaller file size than crf=16 & qcomp=1 (but I thought setting qcomp=1 makes it a constant quantizer mode?)

Are these settings supposed to be doing this or could I be doing something wrong?

The disconnect is where you are assuming that CRF maps 1:1 to QP which it doesn't. CRF and QP don't even share the same value range. To quote from the x264 fullhelp:

-q, --qp <integer> Force constant QP (0-81, 0=lossless)
--crf <float> Quality-based VBR (-12-51) [23.0]

[SlowDelivery]

The disconnect is where you are assuming that CRF maps 1:1 to QP which it doesn't. CRF and QP don't even share the same value range. To quote from the x264 fullhelp:

Ah I see, I didn't realise that.

[benwaggoner]

The disconnect is where you are assuming that CRF maps 1:1 to QP which it doesn't. CRF and QP don't even share the same value range. To quote from the x264 fullhelp:
You can have NEGATIVE CRF?

If so, mind blown.

[Selur]

Just did a small test (never knew the help states -12-61), from the looks of it 0 to -12 all seem to create the same lossless output.
My guess it's a 'cosmetic' bug since quantizer/crf range should be:
for 8bit: 0-51
for 9bit: 0-57
for 10bit: 0-63
as far as I know :)

#define QP_BD_OFFSET (6*(BIT_DEPTH-8))
#define QP_MAX_SPEC (51+QP_BD_OFFSET)
source: https://github.com/mirror/x264/blob/master/common/common.h

Cu Selur

[MasterNobody]

crf can be negative for bit-depth > 8 because it is shifted (for 10-bit by -12 vs QP) to produce same size as in 8-bit mode. And that is why --crf 0 is not lossless in 10-bit mode and you need to use --qp 0 instead.
As for topic starter discontinue of --qcomp 1 vs --qcomp 0.999 it is because --qcomp 1 disables mbtree and without mbtree --pbratio 1.3 (default) take effect again (with mbtree it is effectively 1.0).

[SlowDelivery]

I realised that it is possible to compare the settings in a more controlled manner by using 2-pass instead of crf, so I gave it a try.
The file size was fixed and only the qcomp was varied from 0.6 to 1, then I looked at the bitrate.
--pass 2 --bitrate 10000 --stats ".stats" --qcomp x
Graph: https://ibb.co/MPZ5NpD

As expected, more bitrate was distributed to dynamic scenes as qcomp went up.
However, despite qcomp=0.9 and qcomp=0.999 giving very different file sizes for a given crf, there is very little difference between them in terms of bitrate distribution for a given file size.
So there is probably not much point in going above qcomp=0.9.
Also the profile at qcomp=1 deviates significantly from others, I guess due to the disabled mbtree.

[Boulder]

I think it's mostly agreed that the range 0.6-0.8 is the most practical at least in CRF mode. I've personally used 0.7 for a long time now with both x264 and x265.

[SlowDelivery]

I think it's mostly agreed that the range 0.6-0.8 is the most practical at least in CRF mode. I've personally used 0.7 for a long time now with both x264 and x265.
Yes, after some testing I think qcomp=0.6-0.7 is good for films and qcomp=0.7-0.8 for animations. I guess there is a reason why people stick to values around qcomp=0.7.;)