Why are MC denoisers so slow?

[Dreadkillz]

It's just not fair! MC denoisers just do so well compared to conventional filters, but I can't use use any of them!

[stax76]

I'm not sure what MC is but if it is what I think then the reason is avs instead of asm implementation.

[shoopdabloop]

accurate motion compensation is slow.

[Dreadkillz]

Well I guess it's just me then. I'm playing around with mvtools and other scripts like temporaldegrain and mctemporaldenoise, and its slow as heck on my t2300.

[Didée]

You're a joker. Those scripts never were meant for realtime usage at all. They're rather of the "if it takes days to get some more quality, then so shall it be" department.

For realtime usage, stick with MDegrain1/2. Most (or all) of the "more sophisticated" MC-denoisers are doing buckloads of additional internal stuff, way, way too much to run in realtime.

(For a more eloquent answer, go to the AVC forum, ask for "why x264 dont run realtime with preset 'placebo' ", and wait for Dark Shikari's answer.)

[Sagekilla]

Not to mention the fact that TemporalDegrain came about because of the need to get rid of excessive grain (Read: 300) with only minor smearing artifacts. MCTD came about as a means to improve on that idea and provide more variability in the speed vs quality department. But when it comes down to it, using plain MDegrain1 (with overlapping) on most sources will provide sufficient denoising without taking days to encode. IIRC, it took me 2.5 days to encode 300 (at 720x480) with TD. But when I went back to do it again on the Blu-ray version, I only used MDegrain3 and it ended up taking about the same time, while still retaining the majority of the benefits that TD had.

tl;dr: Stick with MDegrain1/2 unless you have excessive noise/grain.

[Undead Sega]

it took me 2.5 days to encode 300 (at 720x480) with TD

Why would you want to denoise '300'? i thought the grain structure was not too overly done, although i could be wrong in this matter.