Dfftest so slow.

[mirkosp]

So, in other words, if you've got the latest AMVapp, you already have them, as the AMVapp includes AnimeIVTC, if I remember correctly.

It actually doesn't and won't, since Alan is too lazy to put 9001 filters in the AMVApp (AnimeIVTC requires a shitload of things).
He said he'll put them in the filter collection as another avsi, tho.

Anyways, I copied the scripts of daa and maa (and ediaa too) from the animeivtc avsi and put them on pastebin, so you can just copy and paste into a file, rename it with the extension .avsi, place it in the plugin folder of avisynth, and you're good to go. Here it is.

[BasharOfTheAges]

I don't feel so bad about the 1-month necro because this sub-forum gets no traffic, but I just wanted to publicly lol at 30 minutes being considered long. I'm running dfttest() followed by LSFmod() and the thing's taking 74hours.

[mirkosp]

I'm running dfttest() followed by LSFmod() and the thing's taking 74hours.

It's more your pc than the filters, I guess... while those filters are slow, 74hours does sound like too much.

[Qyot27]

I'm running dfttest() followed by LSFmod() and the thing's taking 74hours.

It's more your pc than the filters, I guess... while those filters are slow, 74hours does sound like too much.

It may not, though, at least not completely. The amount of time chained filters require doesn't scale linearly, and while for a 4-minute video filter A and filter B might only take 10 minutes on their own, when combined that can inflate to over - or in mass surplus to - an hour. That particular example is pretty much what happens with DFMDeRainbow and LUTDeRainbow on my computer.

[BasharOfTheAges]

I'm running dfttest() followed by LSFmod() and the thing's taking 74hours.

It's more your pc than the filters, I guess... while those filters are slow, 74hours does sound like too much.

It may not, though, at least not completely. The amount of time chained filters require doesn't scale linearly, and while for a 4-minute video filter A and filter B might only take 10 minutes on their own, when combined that can inflate to over - or in mass surplus to - an hour. That particular example is pretty much what happens with DFMDeRainbow and LUTDeRainbow on my computer.

1) I pre-proces;, this is 90min worth of video.
2) The video is down-scaled to 720p24 from 1080p24.
3) Core2duo Conroe @2.13GHz (2M L2) w/ 8GB DDR2 (processor is by far the bottleneck).

[Caroliano]

This thread is a bit old, but I will post here anyway.

I always use Dfttest(sigma=x, tbsize=3). This will be quite a bit faster than the default that is tbsize=5, and almost eliminate the ghosting artfacts that this filter can make. And it is still temporal and very effective. You might want to drop the sigma a bit, as the filter is more agressive with smaller tbsizes. The next step, tbsize=1, would turn the filter in a pure spatial filter, and I don't like it that way.

But still, I want something faster when I'm just re-encoding for a mobile device or something. Deen() is very fast and generaly good for anime, but the result is very different from dfttest() and usually generates banding/blocking in the encode...

Any other ideas?

[Phantasmagoriat]

A lot of filters can be run multithreaded, which can speed things up immensely:
http://avisynth.org/mediawiki/MT

I certainly couldn't frame interpolate 720p movies on the fly without multithreading

[mirkosp]

Be aware that mt is risky as it's far from perfectly stable. Depending on the mode you set, your encode might get garbage or just crash on you.
It also is a bad idea to use MT modes on the whole script when you have IVTC in it.
If you want filters faster than dfttest, aside from the vaguedenoiser I suggested earlier on, I think that ttempsmooth and HQDN3D are pretty fast and good.

[Phantasmagoriat]

Right, I should have mentioned that MT can output weird stuff, but it depends on the type of filter you are using (any temporal filter can be risky). Problems can usually be avoided by putting mt() around the single filter you want to multithread like: mt("Dfttest()", 2, 0)

putting setmtmode(2,0) at the beginning of your script can be tempting, and sometimes works. But it can also make things crash and burn. So yeah, use with caution.

[Mister Hatt]

DFTTest is a spatio-temporal filter, if you're using it temporally then MT will break it. That said, you don't need to use DFTTest. No matter what you say, your video does not need it. Use a faster filter like FFT3D and you'll get the same results with more speed, vastly superior frequency selection, and considerably less destruction.