Add pre-processing denoising

[shssoichiro]

This changeset adds a --denoise CLI option which enables denoising prior to encoding. This takes a strength value from 0-50, where 0 disables denoising. The default is 0, or half of the --photon-noise setting if --photon-noise is enabled. --denoise can be set manually and will override the denoise strength chosen by --photon-noise.

The denoiser implemented is a FFT-based spatio-temporal denoiser based on the DFTTest plugin from Vapoursynth. This was chosen because it provides a reasonable balance of speed and quality.

This also moves the --photon-noise and --photon-noise-table args into the stable feature set, as was discussed in #2924.

Denoising performance at this time is currently rather slow. Per @tdaede on IRC, we're thinking it makes sense to open this up for merging and improve performance in a followup changeset, given that denoising is not turned on by default.

[coveralls]

Coverage decreased (-3.6%) to 81.947% when pulling a65797a4c22ec85964d9081a9784c97c6a55bffb on shssoichiro:denoising into d8ebb60bea2170feb00fcb1385280c56f583fab7 on xiph:master.

[codecov-commenter]

Codecov Report

Base: 86.44% // Head: 85.22% // Decreases project coverage by -1.22% :warning:

Coverage data is based on head (021bfab) compared to base (d56fe64). Patch coverage: 1.98% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2931      +/-   ##
==========================================
- Coverage   86.44%   85.22%   -1.23%     
==========================================
  Files          89       90       +1     
  Lines       34094    34597     +503     
==========================================
+ Hits        29473    29485      +12     
- Misses       4621     5112     +491     

Impacted Files	Coverage Δ
src/denoise.rs	0.00% <0.00%> (ø)
src/lib.rs	41.93% <ø> (ø)
src/util/align.rs	87.67% <0.00%> (-7.86%)	:arrow_down:
src/api/internal.rs	96.08% <17.39%> (-1.39%)	:arrow_down:
src/bin/common.rs	53.56% <23.07%> (-0.94%)	:arrow_down:
src/api/config/encoder.rs	89.30% <100.00%> (+0.05%)	:arrow_up:
src/api/test.rs	99.23% <100.00%> (+<0.01%)	:arrow_up:
src/me.rs	95.20% <0.00%> (-0.40%)	:arrow_down:
src/encoder.rs	87.09% <0.00%> (-0.04%)	:arrow_down:
src/rdo.rs	85.74% <0.00%> (+0.04%)	:arrow_up:
... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[NSQY]

Have you seen this implementation? https://github.com/AmusementClub/vs-dfttest2

On my 3900X, with AVX2 enabled, it is more than twice as fast as https://github.com/HomeOfVapourSynthEvolution/VapourSynth-DFTTest in a synthetic VS script.

Output 1000 frames in 3.39 seconds (294.74 fps)
vspipe -p dft.vpy -o $x . | 79.68s user | 0.47s system | 2225% cpu | 3.602 total
max memory:                425 MB
page faults from disk:     6
other page faults:         101695

Output 1000 frames in 1.52 seconds (658.97 fps)
vspipe -p dft.vpy -o $x . | 35.31s user | 0.44s system | 2074% cpu | 1.723 total
max memory:                508 MB
page faults from disk:     17
other page faults:         108478

[shssoichiro]

I have, come to think of it, it is an option... Since it seems to roll its own fft code instead of using fftw. The issue with this current PR, and something I want to keep in consideration for future PRs, is that currently rav1e has no dependencies on C libraries with the exception of nasm. To keep it simple to build, we'd prefer to keep it that way. However, the best available library for doing multi-dimensional FFTs in Rust at the moment is 10-20x slower than fftw, which by extension makes this implementation 10-20x slower than the Vapoursynth version of dfttest (which uses fftw). But porting dfttest2 to Rust may be a possibility... 🤔