New beta of 2d cleaner

[Walrus]

I'm posting this message to let those of you who have asked me to let you know when I release a new beta of 2d cleaner, that I have in fact done so. The new beta is a fair amount faster than the old one, and I have released the source code as well under the GPL. For those of you who don't know 2d cleaner is an adaptive averaging noise reduction video filter for VirtualDub.
You can download it at http://home.earthlink.net/~casaburi/download/

[Prospero]

Thanks Walrus!
I'll let you know how it works for me.
Prospero

[Walrus]

Prospero: Just so you know, I've recently come up with another strategy that could potentially yield much faster speeds. I'm working on implementing it.. As soon as I get it working and prove that it works well, I'll get it out as well.

[Prospero]

With the following settings, from MJPEG
MPEG4V2 1800kbs 704X480
Audio MP3
Temporal Cleaner (default)
Smart Deinterlace (default)
2d Cleaner (default)

With old 2d cleaner framerate would jump between 1.7 and 2.7fps. With new 2d cleaner, framrate stays at 2.7fps with minor jumps on the occasion frame. A definite improvement. Thanks for your time on this Walrus.

[Prospero]

Looks like it cut three hours off a ten hour render time. That's nice coding no matter how you look at it. Thanks Walrus.

[Walrus]

Prospero: Thank you for the feedback and the kind words! Just to let you know, Avery Lee (VirtualDub's author) is working on MMX optimizations of the code right now, and he claims he already has it 2X as fast (though his optimizations only work for a 3x3 averaging area) I am also still working on a potential analog for the pixel locking feature of Temporal Filter, which would speed up 2d cleaner dramatically and would also mean that the averaging areas would become largely irrelevant.. but could also end up destroying gradient information in the image. (trying to figure out an elegant way of getting around that)

[Prospero]

Cool, faster is always better. I'm wondering, how L1 cache dependant is this software? I'm considering updating one of my systems to an o/c celleron 2 at 850, and wonder at it's speed potential. I'm curious if it would be faster than my athlon 700. Thanks for all your help.
Prospero

[Walrus]

Prospero: By my calculations, the frames you are processing are quite big (~1.4MB/frame), so there's no chip that will fit the frames totally within cache out today. My guess is it will largely be a wash between the Celeron 2 @ 850 and the Athlon 700. The Athlon has more L1 cache, more L2 cache (though slower) and a faster bus speed which will speed delivery of data to and from the RAM (unless your Celeron's bus speed is upped to 100mhz), but the Celeron has faster L2 cache and a slightly faster clock speed. This is an alogrithm that's largely based on RAM speed (and it will be moreso with Avery Lee's optimizations), so it's concievable at some point your Athlon 700 may outperform the Celeron 850. I should also probably take a look around AMD.com to see if there's any important 3dnow! optimizations available that would be a step up from MMX. (though I think 3dnow! is pretty much only for floating point ops, and I don't have any AMD based systems right now =(

Anyways, the best way to find out is to benchmark on both of your systems.

Right now my only systems are a Pentium 233 MMX laptop (which I do development on) and a dual Celeron 366->550 multimedia station. Needless to say the latter system is faster.

[Prospero]

Thanks,
Was kind of curious on that one. Maybe when we get DDRDSRAM we can speed things up a bit.

[Walrus]

Well any faster RAM bus (pun not intended) would give 2d cleaner a nice boost, though larger L2 caches that run at full speed would be a bigger boost. For instance, the new Athlons with built on 256K of L2 Cache (aka Thunderbirds) will probably be even faster than anything available right now. (they have more L1 cache than a P3) Of course it also depends on the caching model. Under some, the speed of 2d cleaner would be almost entirely based on L1 & L2 cache size and speed, but if it does a random throw-away model (as I think most do use) then it would do many more accesses to actual RAM as opposed to staying within the cache, so RAM speed matters more. Then again, caching models was not my best subject when I took a course in machine architecture.