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. |
17th May 2010, 19:51 | #7 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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. |
17th May 2010, 22:06 | #9 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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. |
|
17th May 2010, 22:07 | #10 | Link |
Derek Prestegard IRL
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. |
17th May 2010, 22:30 | #11 | Link |
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. |
17th May 2010, 22:44 | #13 | Link |
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).
|
17th May 2010, 22:52 | #14 | Link |
Derek Prestegard IRL
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 :) |
17th May 2010, 23:17 | #15 | Link |
Derek Prestegard IRL
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 :) |
18th May 2010, 00:24 | #16 | Link | |
Actually in reserve
Join Date: Oct 2004
Posts: 1,605
|
Quote:
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. |
|
18th May 2010, 01:08 | #17 | Link |
Derek Prestegard IRL
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 :) |
18th May 2010, 21:09 | #18 | Link |
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).
|
15th March 2023, 10:11 | #19 | Link |
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) 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. |
16th March 2023, 00:09 | #20 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
|
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.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|