Did qpmin change?!

[asarian]

I was reading up again on the x264 options, and suddenly realized -qpmin now defaults to 0. Odd. I remember entire discussions here, with ppl saying going below 10 was absurd.

Did something change? Or have I been doing it wrong all the time?

Thx.

[hello_hello]

It doesn't seem to be mentioned in the Wiki, but MeGUI's tooltip says --qpmin and --qpmax are ignored when encoding in quality based VBR modes (CRF mode or 2/3 pass, I assume). It probably only applies to Constant Quantizer encoding.

Edit: That's probably not correct, as --qp mode implies a constant quantiser, and when I checked, x264 didn't write --qpmin or --qpmax to the encoder settings in --qp mode. Now I'm confused. Maybe MeGUI's tooltip is wrong...

I found a reference to 10 being the default here, but I don't know how old it is.
https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

I had a hard drive handy, so I checked an encode from 2013. Some of the encoder settings, courtesy Of MediaInfo.

Writing library : x264 core 138 r2358 9e941d1
Encoding settings : cabac=1 / ref=5 / .....
rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 .....

[asarian]

It doesn't seem to be mentioned in the Wiki, but MeGUI's tooltip says --qpmin and --qpmax are ignored when encoding in quality based VBR modes (CRF mode or 2/3 pass, I assume). It probably only applies to Constant Quantizer encoding.



Thank you! I use CRF mode, so I should be good, I guess. Tip to self: try and keep up with changes over time. :)

[Groucho2004]

I was reading up again on the x264 options, and suddenly realized -qpmin now defaults to 0. Odd. I remember entire discussions here, with ppl saying going below 10 was absurd.

Did something change? Or have I been doing it wrong all the time?

Thx.
It changed 8 years ago. (http://git.videolan.org/?p=x264.git;a=commit;h=ca8f00c7604cac37bd3103135521ebdc2d94340b)
You can also just use "x264 --fullhelp" to check the default values for qpmin/max:
--qpmin <integer> Set min QP [0]
--qpmax <integer> Set max QP [81]

[Groucho2004]

Thank you! I use CRF mode, so I should be good, I guess. Tip to self: try and keep up with changes over time. :)qpmin (and qpmax) will affect all types of x264 encoding.

[asarian]

qpmin (and qpmax) will affect all types of x264 encoding.

By the way, I highly recommend to ignore the hello*2 posts. He basically knows nothing that goes beyond megui, certainly nothing about x264's inner workings.


Thx, Groucho. So it would seem I was 8 years behind the times. :p Good thing you set me straight.

[LoRd_MuldeR]

Ever since AQ (adaptive quantization) has been implemented, the QP is not selected per frame anymore, but individually for each macroblock in the frame.

This applies to all RC modes, with CQP being the only exception.

So, while a QP below 10 would be highly unusual (and probably undesired) for an entire frame, it is not that unusual (and can make sense) for individual macroblocks...

[asarian]

While we're at it (seems a waste to start a whole new topic about it), I noticed the following:

- placebo:
--bframes 16 --b-adapt 2 --direct auto
--slow-firstpass --no-fast-pskip
--me tesa --merange 24 --partitions all
--rc-lookahead 60 --ref 16 --subme 11
--trellis 2

'--ref 16' feels like a lot. In an (automated) cmd file, I usually calculate the amount of reference frames as follows:

set /a _reframes = 12582912 / (((%_width% * %_height%) * 3) / 2)

Which basically amounts to 4 ref frames for 1080p, 5 for 800p (cropped movie), etc. So, 16 seems way over what the wiki says is allowed for Blu-Ray.

So, is it safe to use as many as 16?!

[Rocinante]

While we're at it (seems a waste to start a whole new topic about it), I noticed the following:

- placebo:
--bframes 16 --b-adapt 2 --direct auto
--slow-firstpass --no-fast-pskip
--me tesa --merange 24 --partitions all
--rc-lookahead 60 --ref 16 --subme 11
--trellis 2

'--ref 16' feels like a lot. In an (automated) cmd file, I usually calculate the amount of reference frames as follows:

set /a _reframes = 12582912 / (((%_width% * %_height%) * 3) / 2)

Which basically amounts to 4 ref frames for 1080p, 5 for 800p (cropped movie), etc. So, 16 seems way over what the wiki says is allowed for Blu-Ray.

So, is it safe to use as many as 16?!

It's okay to set extremely high ref because it's restricted by your profile level & resolution anyways. In the case of Blu-Ray, which is L4.1, it will still get limited at 4 ref frames for 1080p no matter how high the value you set.

[asarian]

It's okay to set extremely high ref because it's restricted by your profile level & resolution anyways. In the case of Blu-Ray, which is L4.1, it will still get limited at 4 ref frames for 1080p no matter how high the value you set.

Cool. :) Thank you!

[benwaggoner]

While we're at it (seems a waste to start a whole new topic about it), I noticed the following:

'--ref 16' feels like a lot. In an (automated) cmd file, I usually calculate the amount of reference frames as follows:

set /a _reframes = 12582912 / (((%_width% * %_height%) * 3) / 2)

Which basically amounts to 4 ref frames for 1080p, 5 for 800p (cropped movie), etc. So, 16 seems way over what the wiki says is allowed for Blu-Ray.

So, is it safe to use as many as 16?!
It's called placebo for a reason :)! That's the maximum supported by H.264. But the real-world values are limited by profile @ level. The Wikipedia page for H.264 used to list the maximum values for typical resolutions at different levels. But it seems to be gone from the current page.

The math for the maximum value is here: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Decoded_picture_buffering

[LoRd_MuldeR]

'--ref 16' feels like a lot. In an (automated) cmd file, I usually calculate the amount of reference frames as follows:

set /a _reframes = 12582912 / (((%_width% * %_height%) * 3) / 2)

Which basically amounts to 4 ref frames for 1080p, 5 for 800p (cropped movie), etc. So, 16 seems way over what the wiki says is allowed for Blu-Ray.

So, is it safe to use as many as 16?!

Also keep in mind that a higher "--ref" value only gives the encoder more reference frames to choose from. Still, the encoder will choose the "optimal" reference frame from the available reference frames!

If you look at the stats printed at the end, you will see how many reference frames are actually used. It typically looks somewhat like this:

x264 [info]: ref P L0: 40.8% 8.5% 15.2% 7.1% 6.3% 4.8% 4.4% 2.2% 2.2% 1.7% 1.6% 1.3% 1.3% 1.1% 0.9% 0.7%
x264 [info]: ref B L0: 52.2% 15.2% 9.9% 5.4% 4.1% 3.7% 2.8% 1.6% 1.2% 1.1% 0.8% 0.7% 0.6% 0.4% 0.2%

The above has been created with "--ref 16", but we can see that the first 3 reference frames are used the most by far, reference frames 4 to 7 are still used to some degree, and anything beyond that is probably expendable ;)

So, using 16 reference frames is always "safe" in the sense that it won't hurt quality – because the additional reference frames simply won't be used where they do not have a beneficial effect on compression.

Anyhow, there usually is not much to be gained from allowing more than ~5 reference frames. But, in any case, allowing more reference frames always increases the amount of work that needs to performed in motion search!

(How many reference frames you can fit into the DPB, because of Level restrictions, is a different story; Presets are all about the “speed -vs- compression” trade-off; Level restrictions apply on top of the Preset)