View Full Version : Optimizing x264 CLI parameters to preserve noise
LigH
1st August 2025, 20:23
I got a Blu-ray of a movie which uses heavy noise as stylistic device: Avalon (https://www.imdb.com/title/tt0267287/) (a Polish Sci-Fi movie about players of a VR game risking their lives to find a meaning). Small scene as AVC-MP4 (https://www.ligh.de/test/Avalon_noisy2.mp4)
Do you have any advice how to preserve the noise with CLI parameters for x264 while still reducing the size conveniently? I guess that --nr will be important, but I cannot find a verbose documentation of the amount of effect in relation to its magnitude (e.g. rather 100 or 1000?).
Z2697
1st August 2025, 20:43
"nr" is noise reduction...
LigH
1st August 2025, 20:46
Not exactly, IIRC: It is rather "noise modelling" (decreasing it while encoding, reconstructing it while decoding). If I am wrong, explain it better...
Asmodian
1st August 2025, 22:50
x264 does not have noise modelling. --nr is simple noise reduction. I don't know of any codecs that use noise/grain modelling today. It has been talked about a lot but never implemented.
rwill
2nd August 2025, 07:37
x264 does not have noise modelling. --nr is simple noise reduction. I don't know of any codecs that use noise/grain modelling today. It has been talked about a lot but never implemented.
Yeah, these AOM AV1 guys sure talk a lot about their film grain synthesis that never implemented.
Z2697
2nd August 2025, 07:49
https://code.videolan.org/videolan/x264/-/blob/master/x264.h?ref_type=heads#L424
There's the definition, I don't fully understand the code...
To me it looks like we should never use nr in "normal" situation, the main purpose of the denoise function inside x264 (and x265) is to do emergency denoise when a requested bitrate is lower than normal quantization can get.
The parameter is exposed to the user, probably, "just in case" for some extremely rare things. The quality is not good because it's designed to just smash the bits.
(I just realized that x264's official documentation is actually worse than x265's?)
LigH
2nd August 2025, 09:05
Enough talk about what I shall not do. More about what I may...
GeoffreyA
2nd August 2025, 10:11
I remember Ben saying that if one doesn't go over 300 to 500, it should be mostly transparent. However, the bitrate savings are minimal.
With CRF 18:
NR 0: 23.6 MB
NR 300: 20.2 MB (-14.4%)
KNLMeansCL + NR 0: 15.3 MB (-35.17%)
KNLMeansCL + NR 300: 13.2 MB (-44.07%)
So, you might save more by applying something like KNLMeansCL in VapourSynth; the picture is similar.
https://workupload.com/archive/ntAEmJhnTH
(I just realized that x264's official documentation is actually worse than x265's?)
x265's documentation seems to be a rarity in the codec world.
LigH
2nd August 2025, 11:48
I will not use general noise filters because I do not want to reduce the noise/grain. I want to preserve it visually. But I would like not to waste too much bitrate while doing so. Maybe there is a feature to preserve the visual amount but rearrange it to improve compressibility. Can KNLMeansCL do that?
GeoffreyA
2nd August 2025, 12:18
I will not use general noise filters because I do not want to reduce the noise/grain. I want to preserve it visually. But I would like not to waste too much bitrate while doing so. Maybe there is a feature to preserve the visual amount but rearrange it to improve compressibility. Can KNLMeansCL do that?
No. KNLMeansCL has a strength setting, radius, and temporal window, but I think it will always remove some noise, though it may not be very noticeable.
https://github.com/Khanattila/KNLMeansCL/wiki/Filter-description
To preserve the noise, it may be better to try raising --nr till you can notice a difference (~ < 1,000), but the reduction won't be much.
Z2697
3rd August 2025, 05:19
I think I misunderstood the objective.
I was thinking that the goal is to optimize the grain preservation for a given target size.
But if the goal is actually to reduce the file size while maintaning a similar look, then sure, nr can have its use. It's fast, virtually no cost.
GeoffreyA
3rd August 2025, 08:12
I think I misunderstood the objective.
I was thinking that the goal is to optimize the grain preservation for a given target size.
But if the goal is actually to reduce the file size while maintaning a similar look, then sure, nr can have its use. It's fast, virtually no cost.
As a side note, what denoiser would one use to reduce live-action grain a bit, keeping the picture similar? I feel that KNLMeansCL gives a slightly better result than BM3D, which people tend to recommend. I'm not sure if I'm using it correctly.
Z2697
3rd August 2025, 08:33
As a side note, what denoiser would one use to reduce live-action grain a bit, keeping the picture similar? I feel that KNLMeansCL gives a slightly better result than BM3D, which people tend to recommend. I'm not sure if I'm using it correctly.
KNLM has temporal averaging / smoothing (if you left it default), BM3D on the other hand is what I would call "spatial only", even when V-BM3D extends the block matching range to adjacent frames, it's not doing temporal averaging, or not the type I'm trying to describe but not having better words.
So yeah, it's totally reasonable that KNLM works better for dynamic noises, compared to pure BM3D.
GeoffreyA
3rd August 2025, 13:39
KNLM has temporal averaging / smoothing (if you left it default), BM3D on the other hand is what I would call "spatial only", even when V-BM3D extends the block matching range to adjacent frames, it's not doing temporal averaging, or not the type I'm trying to describe but not having better words.
So yeah, it's totally reasonable that KNLM works better for dynamic noises, compared to pure BM3D.
That makes sense. Also, without CUDA, it's not very practical, depending on the CPU.
benwaggoner
6th August 2025, 01:16
x264 does not have noise modelling. --nr is simple noise reduction. I don't know of any codecs that use noise/grain modelling today. It has been talked about a lot but never implemented.
Specifically, it is an adaptive deadzone applied to inter blocks, which excludes high spatial and temporal frequency data. This results in grain remaining more stable compared to the IDR while lowering QP and/or bitrate.
LigH
6th August 2025, 15:45
I experimented a little bit. In my case (with the "Avalon" Blu-ray), --nr helped a lot.
And then I convinced myself to reducing the grain anyway with a moderate hqdn3d and was very satisfied with the different (more stable but still detailed) look.
benwaggoner
7th August 2025, 16:42
I experimented a little bit. In my case (with the "Avalon" Blu-ray), --nr helped a lot.
And then I convinced myself to reducing the grain anyway with a moderate hqdn3d and was very satisfied with the different (more stable but still detailed) look.
Yeah, a really good creatively tuned noise reduction is better than --nr. One benefit to --nr is, because it is integrated into quantization, it does get a particularly good bitrate reduction for amount of noise removed.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.