--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.
--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be
much more visible near black than near white.
--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits.
It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness.
10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking.
I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like
Code:
--aq-mode 4 --low-luma-bias 0.7
And make --aq-mode 3 essentially an alias to
Code:
--aq-mode 2 --low-luma-bias 1.0