support for nl-means denoise filter

[ponpon]

Dear ffmpeg teams,

i strongly request support for nl-means denoise filter.
the filter is too excellent. even bad source such as vhs video is recovered.
we can see the effect in the below links.
though mr. dirk farin has the fork of ffmpeg, one of handbrake is improved in settings and optimization.
i believe the filter enhances ffmpeg.

​http://www.dirk-farin.net/projects/nlmeans/index.html
​https://forum.handbrake.fr/viewtopic.php?f=4&t=30135&sid=c2d2b10af30b495acb6138e8d5cf8622

[Carl Eugen Hoyos]

Did you ask Dirk Farin why he didn't send his filter to the FFmpeg development mailing list?
Did you consider to send a patch?

[ponpon]

thank you for your reply.

Did you ask Dirk Farin why he didn't send his filter to the FFmpeg development mailing list?

no. because the filter of handbrake is improved in settings and optimization.

Did you consider to send a patch?

regrettably, i don't have such a ability. if i do so, ffmpeg team and users get only confusion.

[Clément Bœsch]

I'm working on it since a while, I need more time.

[dakooga]

I've just tried this filter in handbrake and it works extremely well with older material. Another by product of a the filter is greatly improved compression ratios.

[Clément Bœsch]

The filter is actually pretty simple in theory. I have a working implementation here, but very slow. I'm working on making it usable.

[dakooga]

@ubitux I understand.. The handbrake version costs about 20-25% of the encoding speed when applied.

I'm not sure how I can help but if you manage to submit a patch that makes it to the master then others might be able to contribute too!

[dakooga]

I just added to my snasphot... get about 22 fps on 720p content with 6:3:1. Had it up to 55 fps with 480p content and NVenc going to HEVC...

Do I just submit the patch or something else?

[dakooga]

Patch file for anyone wanting to try it out...

[Elon Musk]

First it is GPL.
Second it uses intrinsic and thus is unacceptable in such form.

[Carl Eugen Hoyos]

Replying to dakooga:

Do I just submit the patch or something else?

You also have to port Dirk's change to configure (line 2589) to make sure LGPL builds do not contain the filter.
Then please remove the whole x86 optimizations: It cannot be committed as-is and it is not needed for the initial commit. I would also suggest to remove the pragma directives, they will just cause fruitless discussions. Finally, please send your patch to the development mailing list, no review is done on this bug tracker.

[Clément Bœsch]

Replying to richardpl:

First it is GPL.
Second it uses intrinsic and thus is unacceptable in such form.

3rd: it's not the final version; Handbrake improved it in various ways, this version is inferior.

Note: if people don't want to wait until I'm done with the filter and prefer to port it themselves, I can stop right now, but please say so.

[dakooga]

4th I don't want to step on anyone toes. You guys do whatever you like.

I merely put it up in case others wanted to try it. I'm not good enough and knowledgeable enough to do a proper commit. But some people do want to try it and see what it does even if it takes a bit longer. It doesn't have to be perfect just to see...

[ponpon]

Replying to ubitux:
i am rooting for you and looking forward to your work.
do you know when your work is completed?

[Clément Bœsch]

Sorry I got delayed in my progress for various reasons. I have a working version locally, but it's so damn slow it's unusable, so that I'm studying the different existing ways of improving speed.

[ponpon]

is the present ubitux version slower than the dirk farin one?

or do you aim at faster one than handbrake one?

[Clément Bœsch]

WIP patch available for testing: ​https://patchwork.ffmpeg.org/patch/613/

Replying to ponpon:

is the present ubitux version slower than the dirk farin one?

I don't know I haven't compared. Probably since there is no ASM for now.

or do you aim at faster one than handbrake one?

The code is ready for some fast SIMD, but won't be present in the first version.

[Clément Bœsch]

Implemented in c29b532a942233b5c804e620d475b3b888fe6e72

SIMD will be the next iteration, but the filter is already "fast enough" for normal use.

[ponpon]

Replying to ubitux:
goood!
thank you for your work.
It's got for everyone tol enjoy it!

[ponpon]

Replying to ubitux:
i think the default value is too strong for SD video and slow for HD.
i try to change them in source from

static const AVOption nlmeans_options[] = {
    { "s",  "denoising strength", OFFSET(sigma), AV_OPT_TYPE_DOUBLE, { .dbl = 1.0 }, 1.0, 30.0, FLAGS },
    { "r",  "research window",                   OFFSET(research_size),    AV_OPT_TYPE_INT, { .i64 = 7*2+1 }, 0, 99, FLAGS },

to

static const AVOption nlmeans_options[] = {
    { "s",  "denoising strength", OFFSET(sigma), AV_OPT_TYPE_DOUBLE, { .dbl = 0.85 }, 0.000001, 30.0, FLAGS },
    { "r",  "research window",                   OFFSET(research_size),    AV_OPT_TYPE_INT, { .i64 = 3*2+1 }, 0, 99, FLAGS },

doesn't this brake the work of nlmeans?

is support for SIMD completed?

i have requests for nlmeans. should i write them here or open a new ticket?

[Elon Musk]

Can you show cases when this numbers helps?