How good is x264 --nr parameter?

[tormento]

I am about trying to use --nr parameter of x264 but it is very obscure in its implementation and quality.

Anyone tried before me?

[Dark Shikari]

It's not very good -- but if you're encoding with x264, it's the fastest motion-compensated denoiser.

[tormento]

Is it good enough to downsize a video keeping good quality? Or is it better to use a higher -crf value?

How the -nr parameter scales?

[Gser]

It's not very good -- but if you're encoding with x264, it's the fastest motion-compensated denoiser.

So it is indeed MC'd? I am surprised.

[ajp_anton]

Is there an avisynth version of it for easier comparison between it and different avisynth filters?

[burfadel]

For comparison, when doing the run for the avisynth filter just remove the option or keep it at zero. Its defult is off (--nr 0).

[LoRd_MuldeR]

So it is indeed MC'd? I am surprised.

AFAIK the only reason why they made a denoiser part of x264, instead of leaving that job to the pre-processing chain (e.g. Avisynth), is that the motion information can be re-used.

[tormento]

So, why is this feature so little used? We should talk about it...

[LoRd_MuldeR]

So, why is this feature so little used? We should talk about it...

...probably because it really is not optimized for high quality. And they never said it is. So with one of those fancy Avisynth denoisers you'll get much better results.

However if you just need something that works fast and easily fits into your encoding process, give it a try and judge yourself ;)

[Blue_MiSfit]

I do need a denoiser that just works and can be integrated into a large scale encoding process. No time to spend tweaking scripts for 99% of my thousands of encodes per month.

I'm doing some testing now on a very grainy 1080p source... Here's the idea:

Source -> x264 lossless @ NR500 -> x264 CRF23 (analysis)
Source -> MDegrain @ thSAD 400 -> x264 lossless -> x264 CRF23 (analysis)
Source -> DeGrainMedian @ 6,12,1 -> x264 lossless -> x264 CRF23 (analysis)
Source -> x264 CRF23 (analysis)

I think DeGrainMedian is a good thing to compare x264's denoiser to, because it's incredibly fast. Practically free as a matter of fact :)

MDegrain is of course the gold standard, and is the benchmark to aspire to in this case. While I'd love to use it on everything, I simply cannot afford the time. Everything else I've tried is either too slow to be worth it (FFT3DFilter), or doesn't work over remote desktop (FFT3DGPU), or not powerful enough.

I'll report my findings...

~MiSfit

[burfadel]

Keep in mind SSIM and PSNR values when using x264's NR shouldn't be used! Those values are based on the comparison of the avisynth output to x264 and x264's output. If you use an avisynth NR filter, the SSIM and PSNR values are calculated on the output of the filter (and whatever else comes after it). The SSIM and PSNR values for x264 are calculated before the NR filter is run and the output, hence the PSNR and SSIM will always be lower when using x264's NR, or when comparing x264's NR and an avisynth one.

For the NR, you have to physically check the encodes and use your own opinion of which one looks better. Also when using CRF mode comparing the output file size... (but visual comparison is a better analysis). At CRF 500, you probably won't notice any difference in the output picture, but the file size will be slightly smaller :). It can aslo be used in conjunction with an avisynth NR filter. If the source is really bad then a much higher value may be beneficial, as in Blue_Misfit's case its pointless in some respects to have a 1080P video thats so grainy it doesnt't offer much over 576P.

[MasterNobody]

Source -> x264 lossless @ NR500 -> x264 CRF23 (analysis)
--nr doesn't work while encoding lossless
so this probably would be:
Source -> x264 CRF23 @ NR500 (analysis)

[burfadel]

That makes sense, how can it be lossless from input to output if you've removes noise in the process! Avisynth noise removal works of course, but then it wouldn't be lossless (in the sense of the base source to x264 output).

[Blue_MiSfit]

I'm testing this hypothesis. x264 did not whine when I specified --qp 0 and --nr 500, and the output bitrate was ~107mbps. I'll see what the source without nr compresses to.

If it's the same, then clearly you're correct.

~MiSfit

[Blue_MiSfit]

Not bad.. early reports - at CRF23, NR500 saved about 700kbps (~13%). This was a very grainy 1080p source, and the result with NR 500 actually looked a little better in some cases. It did kill some detail, but it wasn't bad.

I'm cautiously impressed. I'll give more info later of course ;)

And yes, in lossless mode NR had no effect.

~MiSfit

[BigDid]

I do need a denoiser that just works and can be integrated into a large scale encoding process. ...
Source -> MDegrain @ thSAD 400 -> x264 lossless -> x264 CRF23 (analysis)
...
MDegrain is of course the gold standard, and is the benchmark to aspire to in this case. While I'd love to use it on everything, I simply cannot afford the time...
Hi Misfit,

I have recently discovered (with one of Didée's post)that Mdegrain can benefit of a blksize=16 (instead of =8 by default)
1/quality from better to worse:
Mdegrain3-blksize=8 => Mdegrain3-blksize=16 => Mdegrain2
2/speed from quick to slow
Mdegrain3-blksize=16 => Mdegrain2 => Mdegrain3-blksize=8

I use the blksize=16 for my test/tuning and when final encode is ready I switch to blksize=8. Also if used with MT the overlap needs to grow (usually from 4 to 8..)
Quality is visual only, make your own tests ;)
Speed factor for my Q9400: blksize=16 is 2.5/3 times quicker than blksize=8

If it can help...

Did

[Blue_MiSfit]

K so instead of using CRF, I decided to use 1 pass CBR (since this is what a lot of my production workflows involve, horribly enough. Not my decision :devil:)

Basically, NR isn't too bad, but DeGrainMedian is usually better.

MDegrain2 is great, but runs at 2fps on my system for 1080p when encoding CBR x264 with --preset fast, whereas NR or DGM both get ~12fps.

I'd say if your workflow involves avisynth, and you need FAST denoising, use degrainmedian. If you don't care about speed (or it's a special project), use something better. If you don't use avisynth, x264 NR is reasonably useful, just don't expect much. You can squeeze a few percent out of a noisy source - trade some blocking / grain fail for some softness.

I can post the excel logs of average QPs, speed, etc if anyone is interested, along with the 4 CBR encodes I made.

~MiSfit

[burfadel]

You can use the two together when using suitable settings for both, since they work differently from each other. It should be pretty fast when doing so too! If you're worried or notice its too heavy filterning, just simply ease the strength back for both (should be less strength than each individually).

[DTL]

Some test results of x264 noise reduction vs denoise-stage block duplication for slow changing parts of a scene: https://forum.doom9.org/showthread.php?p=1984488#post1984488

Copy x264-test related part here:
For static camera scene from documentary title with sitting and talking person taking about 10..20% of total frame samples in 1920x1080i 25fps, x264 crf=18 encoding:

After 'visually noiseless' MDegrainN denoising -
2427 Kbit/s,
mb P skip: 40.9%
mb B skip: 76.2%

After creating 1bit BW mask in MS Paint masking talking person with white and all other (about 80% frame) in black and simple scripting:

mask_clip=ImageReader("mask.bmp")
bckgr=Trim(1,1)
bckgr=Loop(bckgr,1000)

Overlay(bckgr, last, mask=mask_clip)


1383 Kbit/s
mb P skip: 85.2%
mp B skip: 93.2%


So with completely static background the number of skipped blocks in MPEG encoder is significantly higher and output bitrate is about 75% lower.

Attempt to apply internal noise-reduction of x264 --nr=600:
1647 K
mb P skip: 37.1%
mb B skip: 77.5%

So even high enough noise-reduction setting for x264 encode can not reach such high skip ratio and so low output bitrate as possible with total block-duplication for non-changed blocks of static parts of the scene.

May be some settings of x264 (or may be developer patch for new builds of x264) can increase internal noise-skipping processing to reach efficiency of external block duplication methods for static and slow changing parts of a frame ?

May be some hard threshold may be added to process 'visually noiseless' input clips to skip low-temporal changing blocks completely instead of linear division resulting of still big enough amount of residual nosie bits to encode to output file.

Currently setting --nr to 'very high' 6000 value (is it really high ?) helps very few:
1549 Kbit/s
mb P skip: 37.2%
mb B skip: 76.2%
And already cause visible degradation of moving subjects.

[benwaggoner]

Is there an avisynth version of it for easier comparison between it and different avisynth filters?
That's not really possible. --nr essentially acts as an adaptive deadline in intra predicted blocks (equivalent to --nr-inter in x265). It happens at the quantization stage, not at the pixel level, and interacts with other quantization features. That's not possible (or perhaps merely extremely difficult) to emulate in a pixel processor like avisynth. And the results will vary based on output bit depth and other factors.

[DTL]

MDegrain2 is great, but runs at 2fps on my system for 1080p when encoding CBR x264 with --preset fast, whereas NR or DGM both get ~12fps.


Heh - we have really progress over 1/10 of a century in endusers data computing chips and motion estimation home-based hardware accelerators. Thanks to Microsoft for finally putting motion estimation hardware accelerator in list of standard services of endusers operating system service in DirectX12. General accelerators manufacturers (not intel yet ?) already support this API in 201x products. So the Windows 10 is the first operating system at the current civilization with direct orientation on the moving pictures processing by endusers.

202x chips can run several MAnalyse/MDegrainN in a chained multi-generation MVs refining and lots of new temporal processing like MVs filtering in temporal axis with tr about 10 at the same 2 fps.

Yesterday release of a pre-x264 software robot based on mvtools2 with completely stopping block updates if block's view changes too few (threshold-based) - https://forum.doom9.org/showthread.php?p=1984527#post1984527

Still can not motion-follow of stopped in update block over frame field if scene (area of scene) is moving relative to frame block-sampling grid (expected in next versions).