x264 Minimum Maximum Quantizer settings

[elguaxo]

Hi, I am using x264 r614A, the one updated by MeGUI. Since I started using dotBL0t's Stats Analyzer I'm playing around with many Quantizer options. I just did an encode with --qpmin 15 --qpmax 30 but I got these:
Frame Quality Statistics:

Q = 15: 2286 (2,63%)
Q = 16: 3289 (3,78%)
Q = 17: 6481 (7,45%)
Q = 18: 10673 (12,27%)
Q = 19: 11893 (13,67%)
Q = 20: 13088 (15,04%)
Q = 21: 11799 (13,56%)
Q = 22: 9739 (11,19%)
Q = 23: 6807 (7,82%)
Q = 24: 4277 (4,92%)
Q = 25: 3140 (3,61%)
Q = 26: 1624 (1,87%)
Q = 27: 1162 (1,34%)
Q = 28: 488 (0,56%)
Q = 29: 187 (0,21%)
Q = 30: 55 (0,06%)
Q = 31: 6 (0,01%)
Q = 32: 1 (0,00%)

Minimum Frame Quantizer: 15
Maximum Frame Quantizer: 32

Why can't x264 keep the maximum quantizer at 30? It's really not important for me to keep the max Quant at 30, I am just doing some tests, but I just wonder why it doesn't work. Thanks.

[buzzqw]

look at stat file... maybe the first frames is at 32-31 after that the encoder is able to respect the constraint

BHH

[elguaxo]

look at stat file... maybe the first frames is at 32-31 after that the encoder is able to respect the constraint

BHH

Nope. This was the first 31:
in:60252 out:60253 type:b q:31.00 itex:4653 ptex:32839 mv:13156 misc:1152 imb:46 pmb:538 smb:574 d:s;

And this was the first 32:
in:60250 out:60251 type:b q:32.00 itex:6843 ptex:26933 mv:11734 misc:922 imb:70 pmb:382 smb:717 d:s;

[buzzqw]

look at these frames in movie , all black ? something particular?

BHH

[elguaxo]

Good suggestion! Thanks.

Now the n00b question. Those frames are supposed to be 60251 and 60253 or 60250 and 60252? Anyway, they are not black and there is some action.

60251 (original frame, I don't have the encoded version here):
http://img171.imageshack.us/img171/3357/60251nv8.png

[DarkZell666]

Maximum QP value applies to P-frames IIRC, so the B-frame quant can potentially be pframe_quant*pb_ratio (which is 35-ish rather than the 30 you specified).

[elguaxo]

:thanks:

[akupenguin]

pb_ratio is in units of bitrate, not qp. Since qp is a logarithmic scale, a bitrate factor is additive in qp. Multiplying qp by anything is meaningless. It turns out that the default pb_ratio=1.3 is equivalent to +2 qp, so limitting P-frames to qp<=30 limits B-frames to qp<=32, exactly as you saw.

[elguaxo]

Exactly, thanks for the info!

[DarkZell666]

aku:lol, you already corrected me about that once a couple of months back, I keep getting mixed up with XviD's bframe settings ... *needs to learn to change some thinking habits a bit quicker*

[Ranguvar]

If I may resurrect an old thread, why does x264 default to a qpmin of 10? I've heard many times that a quant of 18 is almost always transparent - wouldn't it be good to raise that default to, say, 15?

[Dark Shikari]

If I may resurrect an old thread, why does x264 default to a qpmin of 10? I've heard many times that a quant of 18 is almost always transparent - wouldn't it be good to raise that default to, say, 15?Short reason: Legacy

Long reason: With adaptive quantization, there's very good reason to have quantizers as low as 10. 18 is definitely not transparent for a very very flat block with fine detail.

[Ranguvar]

Thanks very much. I shall hurriedly put those quantizers back where they came from :p

[cyberbeing]

I had a rather grainy anime source that I had to get down to CRF10 (once I moved it up to CRF11 I started having shifting/flickering flat areas where they should have been static with grain on top) to be completely visually lossless to my eyes. The resulting QP were like I=7, P=9, B=10 so depending on the source and how high quality you want, you definally have some wiggle room to even move the qpmin below 10 and still see an increase in quality.

[Ranguvar]

Well, yeah, it goes without saying that when targeting a CRF of a certain value, it makes sense to have the minimum quant lower than what you're targeting :)

[Selur]

is there some disadvantage when setting qpmin to 1 ?

[type1encryption]

and....

I did some compressibility tests with avisynths "selectrangeevery" and with a --qpmin of 8 @crf19 I got a smaller file (maybe 1-3 %) than with --qpmin 10.

I'll test that again.

[Ranguvar]

is there some disadvantage when setting qpmin to 1 ?
Yes, then the encoder might choose way oversized frames, meaning that later, it will have less bits for other frames.

If you're familiar with Xvid, think of how it's almost always beneficial to limit the quantizers to a minimum of 2 - Quants of 1 are much bigger and look very little better.

[Dark Shikari]

Yes, then the encoder might choose way oversized frames, meaning that later, it will have less bits for other frames.Why would it do such a thing? Using qpmin to restrict ratecontrol actually means "I don't trust the ratecontrol algorithm," which creates all sorts of problems.

[Sharktooth]

qpmin = 10 is the default...

[Sagittaire]

Yes, then the encoder might choose way oversized frames, meaning that later, it will have less bits for other frames.


No because encoder will use low quantizer for very simple complexity frame (rate control is based on texture complexity). Use lower quantizer for very simple complexity frame doesn't mean "oversized" frame because these frame will always use lower relative size.

[Ranguvar]

Okay, thanks for the clarification Sagittaire :) I used 'oversized' incorrectly. I meant more like it would choose a lower quantizer than it could probably get away with, and waste bits.

@Dark Shikari: If what you say is true, then why isn't the default qpmin 1? That would be the epitome of trusting the rate control... but it appears that pengvado, or whoever set the qpmin default to 10, doesn't trust the rate control either.

[Dark Shikari]

Okay, thanks for the clarification Sagittaire :) I used 'oversized' incorrectly. I meant more like it would choose a lower quantizer than it could probably get away with, and waste bits.

@Dark Shikari: If what you say is true, then why isn't the default qpmin 1? That would be the epitome of trusting the rate control... but it appears that pengvado, or whoever set the qpmin default to 10, doesn't trust the rate control either.As I said, legacy. I have no idea how far back such an option goes, but I would not be surprised if it was originally set by Laurent Aimar.

Edit: It was set as part of a patch introducing 1pass ratecontrol, by Loren (http://git.videolan.org/?p=x264.git;a=commitdiff;h=aecc6ab057616f32eb0643b36db2d5b04d7a07ea).

[Sagittaire]

If what you say is true, then why isn't the default qpmin 1? That would be the epitome of trusting the rate control... but it appears that pengvado, or whoever set the qpmin default to 10, doesn't trust the rate control either.

Well perhaps simply because q10 with flat16 is a really high quality and RC author limit by default the quantizer at this level.

Anyway in my Elephant Dream challenge I make encoding at 18Mbps with qmin set to 5 to target the good bitrate and the RC work very well.

[lexor]

While we on the subject of quantizers, is --qcomp used in crf at all? It talks about quantizer curve compression, so seems like it's relevant, but --qcomp 0.6 and 1.0 produce identical output at crf13. Working as intended?

[Dark Shikari]

While we on the subject of quantizers, is --qcomp used in crf at all? It talks about quantizer curve compression, so seems like it's relevant, but --qcomp 0.6 and 1.0 produce identical output at crf13. Working as intended?AQ strength weights up qcomp, and qcomp caps at 1.0. So sufficiently high values of qcomp will do nothing for sufficiently high values of AQ strength.