Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th May 2010, 15:39   #1  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
How good is x264 --nr parameter?

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

Anyone tried before me?
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 17th May 2010, 15:46   #2  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
It's not very good -- but if you're encoding with x264, it's the fastest motion-compensated denoiser.
Dark Shikari is offline   Reply With Quote
Old 17th May 2010, 15:50   #3  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
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?
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 17th May 2010, 19:02   #4  |  Link
Gser
Registered User
 
Join Date: Apr 2008
Posts: 418
Quote:
Originally Posted by Dark Shikari View Post
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.
Gser is offline   Reply With Quote
Old 17th May 2010, 19:15   #5  |  Link
ajp_anton
Registered User
 
ajp_anton's Avatar
 
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
Is there an avisynth version of it for easier comparison between it and different avisynth filters?
ajp_anton is offline   Reply With Quote
Old 17th May 2010, 19:40   #6  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
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).
burfadel is offline   Reply With Quote
Old 17th May 2010, 19:51   #7  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by Gser View Post
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.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 17th May 2010 at 22:07.
LoRd_MuldeR is offline   Reply With Quote
Old 17th May 2010, 22:03   #8  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
So, why is this feature so little used? We should talk about it...
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 17th May 2010, 22:06   #9  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by tormento View Post
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
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 17th May 2010 at 22:08.
LoRd_MuldeR is offline   Reply With Quote
Old 17th May 2010, 22:07   #10  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
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
__________________
These are all my personal statements, not those of my employer :)

Last edited by Blue_MiSfit; 17th May 2010 at 22:09.
Blue_MiSfit is offline   Reply With Quote
Old 17th May 2010, 22:30   #11  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
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.
burfadel is offline   Reply With Quote
Old 17th May 2010, 22:40   #12  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Quote:
Originally Posted by Blue_MiSfit View Post
Source -> x264 lossless @ NR500 -> x264 CRF23 (analysis)
--nr doesn't work while encoding lossless
so this probably would be:
Source -> x264 CRF23 @ NR500 (analysis)

Last edited by MasterNobody; 17th May 2010 at 22:42.
MasterNobody is offline   Reply With Quote
Old 17th May 2010, 22:44   #13  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
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).
burfadel is offline   Reply With Quote
Old 17th May 2010, 22:52   #14  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
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
__________________
These are all my personal statements, not those of my employer :)
Blue_MiSfit is offline   Reply With Quote
Old 17th May 2010, 23:17   #15  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
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
__________________
These are all my personal statements, not those of my employer :)
Blue_MiSfit is offline   Reply With Quote
Old 18th May 2010, 00:24   #16  |  Link
BigDid
Actually in reserve
 
Join Date: Oct 2004
Posts: 1,605
Quote:
Originally Posted by Blue_MiSfit View Post
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
__________________
Having a problem with AutoGK? Read & use the FAQ & MORE FAQ first
Want to exchange on AutoGK? try doom10.org
In reserve (inactive) for an undefined period of time.
BigDid is offline   Reply With Quote
Old 18th May 2010, 01:08   #17  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
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 )

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
__________________
These are all my personal statements, not those of my employer :)
Blue_MiSfit is offline   Reply With Quote
Old 18th May 2010, 21:09   #18  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
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).
burfadel is offline   Reply With Quote
Old 15th March 2023, 10:11   #19  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Some test results of x264 noise reduction vs denoise-stage block duplication for slow changing parts of a scene: https://forum.doom9.org/showthread.p...88#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:
Code:
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.
DTL is offline   Reply With Quote
Old 16th March 2023, 00:09   #20  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by ajp_anton View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:00.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.