Are my x264 settings correct ?

[BDHDLIGHT]

Hello

What do you think of these x264 settings?

I left the HandBrake default values to encode my movie.

Tune : Movie
Preset : VerySlow

Vidéo
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Oui
Format settings, Reference frames : 5 images
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 57 min
Bit rate : 5 000 kb/s
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2,40:1
Frame rate mode : Débit im/s constant
Frame rate : 23,976 (24000/1001) im/s
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressif
Bits/(Pixel*Frame) : 0.136
Stream size : 4,07 Gio (87%)
Writing library : x264 core 165 r3222 b35605ac
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=5000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : Oui
Forced : Non
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

[GeoffreyA]

The settings are all right, though you might want to use CRF instead of a target bitrate. AQ mode 3 helps dark scenes. I also use 4 reference frames, me_range of 48, and a bigger rc_lookahead, along with disabling fast_pskip and decimate.

[BDHDLIGHT]

Thank you for your response.

How do you change these settings?

For example, AQ mode 3 helps dark scenes

[hellgauss]

They are ok. I confirm tha a little bit higher me_range and rc_lookahead may help a little. Ref=5 is still ok with level 4.1 if source is cropped (1920x800). If you have time, I suggest also me=tesa. CRF encoding may save time if you need a target quality rather than target bitrate. Aq mode 3 may help or not, it depends on the source and personal tastes. I never used Handbrake, so I do not know how to change options.

Other suggestion:
- if the source is not a professional master, lower maxrate and bufsize. For bluray source they are rispectively 39500 and 29500, and it is a non-sense to keep them higher than the source. Try 20000 maxrate and 25000 bufsize (If there are no bitrate peaks, this change has no effect).

I never investigated disabling fast_pskip, what is its effect practically?

[BDHDLIGHT]

What exactly will an increase in the me_range and rc_lookahead parameters bring to my encoding?

Will this bring a better and significant quality?

[hellgauss]

Not significantly. Increasing me_range = better motion estimation . Can give a tiny extra compression at the cost of CPU. From 24 to 32 or to 48 there are still some little gain margin. Rc-lookahead gives better buffer management and, perhaps, better frame type decision at the cost of minor memory usage while encoding. I usually set it to 99, just for the sake to be 2digit. It can be increased up to max key-frame interval.

[GeoffreyA]

How do you change these settings?

For example, AQ mode 3 helps dark scenes

In HandBrake's "Advanced Options," add:

aq-mode=3

Separate it from other options with a colon. For example:

ref=4:aq-mode=3

AQ3 increases bitrate in CRF mode, so test to see if there is any benefit or detriment. Having said that, I enable it on all 8-bit x264 encodes.


I never investigated disabling fast_pskip, what is its effect practically?

Did not visually or numerically establish this, but remember reading old posts where disabling prevented rare artefacts. Most likely, placebo or minor.

Regarding merange, there is a subtle difference: https://slow.pics/s/xoQ0ehYw

[x264N00b]

With nowadays fast multicore CPUs preset veryslow is basically what you want for good quality encoding. Level 4.1 with Ref 4 and 4-8 b-frames for movies to maintain hardware playback compatibility. Cropping is not really needed because it dosen't saves any filesize (as often missunderstood). Tune film is also not needed.
AQ-mode 3 increases the the overall average bitrate with CRF encoding pretty much but only slightly in dark scenes (unfortunately). It's not the key to make dark scenes look perfect. Only bitrate is ;)
Related to some content, disabling mbtree with CRF encoding can sometimes give you nice quality benefit because it can give you a more balanced quality between grainy/noisy and dark/flat/soft und low contrast scenes. The magic is to find the sweetspot. (average bitrate will increase pretty much)

[BDHDLIGHT]

Good evening

I’m not interested in encoding with CRF.

I want to stay on the 2pass encoding in order to know exactly the size of my file, even if it’s longer.
At least I know that I will have the necessary storage space to store my movie.

I didn’t understand if the encoding settings recommended to me are valid during a 2pass encoding or if they are only valid for a CRF encoding ?

Thank you for your help.

[microchip8]

They are valid for all modes, 2pass or CRF.

CRF gives you the benefit of targeting a quality-like for your movies so all encoded with the same settings and CRF value will have roughly the same quality. In 2pass, guessing a correct bitrate for each movie is very hard and almost impossible. Your collection will have inconsistent quality.

[Z2697]

Regarding merange, there is a subtle difference: https://slow.pics/s/xoQ0ehYw

It's not easy to infer the effect of merange by just visually comparing one screenshot.
In theory it should only improve the "fast-moving" object, and the search is around the predicted MV so it's not like the merange is the actual range that can be searched.

I have a test clip that showcases this: 19193
Somehow the MV predictor falls flat on scrolling up motion (or is this scroll down? anyway, with contents moving up), if you reverse the motion, e.g. by -vf reverse (or I can change the keyframe in my kdenlive but I won't ;)), or use either of the horizontal directions, the predictor works well and you don't need large range.
A merange of at least 137 is required to get a "mostly as good as it gets" prediction out of this clip.
Actually this is a remake of a test clip I used when testing the "long range HEX" (x264 caps the range of DIA and HEX at 16).
When the cap is removed, HEX and DIA can benefit from the increased range as well (I get this idea from x265, where they are not capped like this).

[GeoffreyA]

It's not easy to infer the effect of merange by just visually comparing one screenshot.
In theory it should only improve the "fast-moving" object, and the search is around the predicted MV so it's not like the merange is the actual range that can be searched.

I have a test clip that chowcase this:
https://pixeldrain.com/u/dwcSKdgN
Somehow the MV predictor falls flat on scrolling up motion (or is this scroll down? anyway, with contents moving up), if you reverse the motion, e.g. by -vf reverse (or I can change the keyframe in my kdenlive but I won't ;)), or use either of the horizontal directions, the predictor works well and you don't need large range.
A merange of at least 137 is required to get a "mostly as good as it gets" prediction out of this clip.
Actually this is a remake of a test clip I used when testing the "long range HEX" (x264 caps the range of DIA and HEX at 16).
When the cap is removed, HEX and DIA can benefit from the increased range as well (I get this idea from x265, where they are not capped like this).

Yes, it ought to be a temporal test. The other day, I struggled to establish which was better. But some months ago, in one of the frames of this shot, I found that veryslow's default of 24 garbled the edges of Ms. Luv's face. Very slightly, and perhaps only noticeable on comparison. An me_range of 48 improved it substantially; and both x265 and SVT-AV1 were quite fine in this regard.

I'll check the clip in the morning when at the computer. Perhaps it fails in upward motion because of the pattern search. What about the exhaustive one, TESA?

Now I'm wondering if it's better to max out me_range. It does slow down encoding.

[Z2697]

Yes, it ought to be a temporal test. The other day, I struggled to establish which was better. But some months ago, in one of the frames of this shot, I found that veryslow's default of 24 garbled the edges of Ms. Luv's face. Very slightly, and perhaps only noticeable on comparison. An me_range of 48 improved it substantially; and both x265 and SVT-AV1 were quite fine in this regard.

I'll check the clip in the morning when at the computer. Perhaps it fails in upward motion because of the pattern search. What about the exhaustive one, TESA?

Now I'm wondering if it's better to max out me_range. It does slow down encoding.

MV predictor is a separate part of the codec.

[rwill]

Isnt the me range in x264 and x265 a hard limit of 'positive y mv' searches because of frame threading? What you can do is to make a search (in lowres frame) unconstrained and then for each MB/CU line check what downward Y MV you need to be able to handle 95%+ of units, and use that as me_range, that is, make it dynamic.

[Z2697]

I didn't know that, I can't understand the code because it has goto! :devil: (not really, but the code does have goto, I think it's a ways to "call" HEX search inside UMH search)

[rwill]

https://code.videolan.org/videolan/x264/-/blob/master/encoder/analyse.c?ref_type=heads#L330

where i_mv_range_thread is determined here:

https://code.videolan.org/videolan/x264/-/blob/master/encoder/encoder.c?ref_type=heads#L1319

You can use "--log-level debug" to check which i_mv_range_thread you are getting...

[Z2697]

Or is it an arbitrary limit like the hex 16 limit?
There's a command line option in x264 to adjust this.

Anyways, so the problem is not MV predictor, but the actual MV is clipped for some sort of threading reason.

[benwaggoner]

It's not easy to infer the effect of merange by just visually comparing one screenshot.
In theory it should only improve the "fast-moving" object, and the search is around the predicted MV so it's not like the merange is the actual range that can be searched.

I have a test clip that showcases this: 19193
Somehow the MV predictor falls flat on scrolling up motion (or is this scroll down? anyway, with contents moving up), if you reverse the motion, e.g. by -vf reverse (or I can change the keyframe in my kdenlive but I won't ;)), or use either of the horizontal directions, the predictor works well and you don't need large range.
Makes since as non-VPx codecs rasterize top to bottom left to right. Looking into what already happened above a given line is easier what is going to happen below. And for the credits case, new image is revealed bottom-up. Encoders can and have worked around that in many effective way, but it's not as easy by default as motion going the other way.

A merange of at least 137 is required to get a "mostly as good as it gets" prediction out of this clip.
Actually this is a remake of a test clip I used when testing the "long range HEX" (x264 caps the range of DIA and HEX at 16).
When the cap is removed, HEX and DIA can benefit from the increased range as well (I get this idea from x265, where they are not capped like this).[/QUOTE]

[GeoffreyA]

What me_range would be recommended as a good default for film content? I've been using 48 for some time. (The-lazy-brain in me is talking :))

[microchip8]

What me_range would be recommended as a good default for film content? I've been using 48 for some time. (The-lazy-brain in me is talking :))

I use 52, the double of 26

[Z2697]

Use as high as you can tolerate the speed.

[GeoffreyA]

Thank you, sirs.

[BDHDLIGHT]

I asked ChatGPT about it, here are his answers.

🔍 1. higher me_range

For example, if you go from 24 → 32:

What it really improves:
better search for movement in certain complex scenes
slightly fewer prediction errors on:
fast movements
panoramic
moving thin objects
But in practice:
x264 veryslow is already doing a very thorough search
Blu-ray is already well compressed at the source
so the cases where it changes something are rare

👉 result:

mathematically real gain, but visually minimal

🔍 2. higher rc_lookahead

If you spend 60 → 80:

What it improves:
better anticipation of the bitrate on the upcoming stages
slightly smarter allocation of bits
But:
veryslow + mbtree + psy preset are already doing 95% of the work
x264 quickly reaches an optimization ceiling here

👉 result:

gain even lower than me_range

🎬 In your encodings

You are in this context:

1080p Blu-ray already compressed cleanly
fixed bitrate 5000 kbps (structural limit)
veryslow preset (already very high level)

👉 So even if you augment:

you improve very rare cases
not the overall perception of the film

⚖️ Honest conclusion
✔ Yes:
actual technical improvement (measurable in analysis)
❌ But:
overall visual improvement: almost invisible
very low gain/cost ratio
🧠 Simple rule

👉 These settings follow a law:

the higher you go, the faster the gain becomes invisible

🎯 Verdict for you

With your current workflow:

me_range 24 → already optimal
rc_lookahead 60 → already useful ceiling

👉 Increase them = theoretical perfection, not real improvement

[Z2697]

OMG there's it! Our AI overlord!
There's something right though, it's not gonna look that different.

[GeoffreyA]

OMG there's it! Our AI overlord!
There's something right though, it's not gonna look that different.

Here's a thought: what if our universe were subject to lossy compression to save space and time? :)

[Z2697]

Here's a thought: what if our universe were subject to lossy compression to save space and time? :)

Then I will be optimized (out of existence) :(

[GeoffreyA]

The singularity must not be feared, allowing many bytes to be stored in zero space...

[BDHDLIGHT]

Hello

I made some changes to encode all my Blu-rays.

Tune : movie

me_range=64
fast_pskip=0
rc_lookahead=120
aq-mode=3

For this setting, it doesnÂ’t work.
Even though I write 0, the encoding displays 1.
Why ?

decimate=0 decimate=1

[GeoffreyA]

Not at the computer to double check, but try no-dct-decimate=1

[BDHDLIGHT]

There was indeed an error

I just fixed with dct-decimate=0

[BDHDLIGHT]

Hello

Is it useful to have a large rc_lookahead if I have the advanced option x264 mbthree=0 ?

I lowered the rc_lookahead to 60 because, if I’m not being silly, mbthree is the advanced option x264 that uses the most rc_lookahead.

I set mbthree to 0 because, from what I understand, it’s better for the grain and it blurs the backgrounds less.

[x264N00b]

When mbtree is disabled rc-lookahead has no effect / is not used. With mbtree on, higher rc-lookahead values are better.
In my experience grain preservation is better with mbtree and on the other hand low contrast / flat and dark scenes can look better without mbtree. (CRF encodes)
Also I'd highly recommend NOT to disable mbtree for single or multipass encodes, if you are a beginner. You can mess up the quality pretty easy with that.

[GeoffreyA]

I set mbthree to 0 because, from what I understand, it’s better for the grain and it blurs the backgrounds less.

Disabling mbtree improves quality across a frame but increases bitrate: about double. When enabled, blocks that are less referenced in the future—less important—have their quality lowered.

[hellgauss]

rc-lookahead has also effects on buffer management and, reading opinions in some doom9 threads, perhaps it also affects frame-type decision.

[StvG]

When mbtree is disabled rc-lookahead has no effect / is not used.

This is true only if vbv is disabled too (--vbv-bufsize 0), otherwise it has significant effect (mbtree 0 vbv-bufsize > 0).

[Z2697]

Disabling mbtree improves quality across a frame but increases bitrate: about double. When enabled, blocks that are less referenced in the future—less important—have their quality lowered.

more important blocks will have their quality raised too
so it is basically impossible to get background less blurry without it, if the so called background is more steady and can easily be referenced a lot

HOWEVER, there's a bug, or just some weird interaction, the keyframe(s) near the initial few seconds will have lower quality in CRF mode.
In both x264 and x265. I chose to do some experiment with x265 and by allowing aq and cutree to be enabled in "CQP" mode, there's no such quality drop.

[GeoffreyA]

more important blocks will have their quality raised too
so it is basically impossible to get background less blurry without it, if the so called background is more steady and can easily be referenced a lot

HOWEVER, there's a bug, or just some weird interaction, the keyframe(s) near the initial few seconds will have lower quality in CRF mode.
In both x264 and x265. I chose to do some experiment with x265 and by allowing aq and cutree to be enabled in "CQP" mode, there's no such quality drop.

That's a good point. So, we may say that: mbtree adjusts quality based on temporal importance.

I have noticed that issue, and always thought it was due to rate control not having kicked in properly.

[benwaggoner]

For CVBR encoding, I've tested gains from rc-lookahed up to rc-lookahead=keyint. And its more of a memory hog than a CPU hog, at least on systems with a lot of cores.