FTurn and SangNom2 - plugins for faster antialiasing

[TurboPascal7]

I've been doing lots of antialiasing on HD content and most current implementations are insanely slow. Hence these two plugins.

FTurn
GitHub repo (https://github.com/tp7/fturn) (binaries (https://github.com/tp7/fturn/releases))
This is a simple plugin that contains faster TurnLeft/TurnRight/Turn180 implementations (all with F prefix). Only Y8, YV12 and YV24 are supported.

I wouldn't mind seeing these optimizations in Avisynth core, but since contributing to it is not the easiest task, we're going with a separate plugin for now.

SangNom2
GitHub repo (https://github.com/tp7/SangNom2) (binaries (https://github.com/tp7/SangNom2/releases))
This is a rewrite of the old SangNom (http://avisynth.org/mediawiki/SangNom) filter. Its output is mostly identical to the old version on default settings.

In addition to huge speed improvements thanks to threading, it also supports additional colorspaces (such as Y8) and processes borders in a more correct manner.
SangNom (scaled x2 with PointResize)
http://sadpanda.us/images/1756014-7OZ58NI.png
SangNom2
http://sadpanda.us/images/1756015-CV87NDY.png
Please note that SangNom2 is still in "beta" stage so I might change some parameters and defaults in the future. For instance, I consider migrating to avstp (http://forum.doom9.org/showthread.php?t=164407).

Example usage
line0 wrote a maa mod (https://github.com/line0/avs-scripts/blob/master/maa2.avsi) that uses both these plugins and works on Y8 in some cases for maximum performance.

Note
All plugins work only with Avisynth 2.6 alpha 4. Older versions also support older Avisynth, so get them if you need it. Both plugins require SSE2-compatible CPU.

All binaries and additional info are available on GitHub. All future releases will also be posted there. I might forget to update this thread later so check the repos out if you want the latest version.

[wOxxOm]

Tested on a progressive 1920x1080 video, loaded with FFVideoSource, no other filters except the following:

Original maa(): 4.75 fps
New maa2(): 17 fps - 3.5 times faster
New maa2() with setmtmode(2,4): 24.5 fps - 5.15 times faster - realtime!
Original maa() with setmtmode(2,4): 10 fps

p.s. i7-3770k @ 4.4GHz

[real.finder]

nice, I was waiting for something like this for a long time, I'll try it as soon as possible

Thank you very much :)

[Overdrive80]

Great!! Thanks for your effort.

[TurboPascal7]

I just released a new version of FTurn. It now requires only SSE2 so can be used on older Intel processors and AMDs.

There were no functional changes so you don't have to update if it worked for you to begin with.

[bxyhxyh]

What is the difference between fturn2x-icc.dll and fturn2x.dll ?

[wOxxOm]

What is the difference between fturn2x-icc.dll and fturn2x.dll ?ICC stands for Intel C Compiler, I guess, though I'm more accustomed to -icl suffix.
Well, the difference is that -icc dll should run faster on Intel CPUs. Test both and choose the fastest for you.

[Groucho2004]

ICC stands for Intel C Compiler
Correct but ICC is actually the free version for Linux. Maybe the author does indeed mean ICL...

[TurboPascal7]

From wiki:
Intel C++ Compiler, also known as icc or icl
So I don't really see any problems.
Also apparently it's faster on AMDs too so I'll remove the vc110 build in the future version.

[TheProfileth]

Any plans to add 16bit (stacked) support for either filter?

[TurboPascal7]

I don't think it's reasonable. 16-bit sangnom doesn't make much sense to me, and turning is easier to implement as a script, since plugin would do exactly the same things anyway.
I will add interleaved 16-bit support to FTurn if other plugins' devs switch to it.

[Motenai Yoda]

Any chance to have a x86-64 version too (like for SEt's 2.5.8 MT x64 by JoshyD)?

[TurboPascal7]

Any chance to have a x86-64 version too (like for SEt's 2.5.8 MT x64 by JoshyD)?
No. Avisynt x64 is useless.
It should be possible to compile it for x64 without/with few source modifications though, you can try it yourself.
Oh and do note that SangNom2 doesn't support avisynth 2.5.8, you'll have to replace avisynth.h header and change colorspaces handling a bit.

[Stereodude]

No. Avisynt x64 is useless.It's unfortunate everyone seems to think this. 32-bit AVIsynth has serious issues when handling high resolution content that's got a lot of processing being done on it. Accessing only 2GB of RAM just isn't enough. Just because it's possible to pipe 32bit AVIsynth to a 64-bit encoder doesn't mean there's no need for 64-bit AVIsynth or that it's useless.

Do you think 64-bit encoders like x264 are worthless too?

[TurboPascal7]

It's unfortunate everyone seems to think this. 32-bit AVIsynth has serious issues when handling high resolution content that's got a lot of processing being done on it. Accessing only 2GB of RAM just isn't enough. Just because it's possible to pipe 32bit AVIsynth to a 64-bit encoder doesn't mean there's no need for 64-bit AVIsynth or that it's useless.

Do you think 64-bit encoders like x264 are worthless too?
Where did that x264 line even come from?
x64 is quite useful, but there might be a reason why almost no one uses avs x64, you know (hint: it's slower than x86 as most asm code in both avs core and external plugins is not portable).

[Stereodude]

x64 is quite useful, but there might be a reason why almost no one uses avs x64, you know (hint: it's slower than x86 as most asm code in both avs core and external plugins is not portable).I suspect very few people use it because it's poorly supported by plugin authors like yourself. If you're correct about it being slower, a small speed tradeoff can be well worth it when it actually works and doesn't crash.

[TurboPascal7]

I suspect very few people use it because it's poorly supported by plugin authors like yourself. If you're correct, a small speed tradeoff can be well worth it when it actually works and doesn't crash.
The problem is: most core filters and external plugins use inline MSVC assembly for asm-optimized code paths. This assembly code usually gives, say, 4-10 times better performance than plain C version (number are random). And this assembly path is not portable since MSVC cannot compile inline asm in x64 mode.

So if anyone wants to actually make x64 avisynth useful, he'd need to rewrite insane amount of assembly code to either use a real assembler as YASM, or use intrinsics (like Firesledge's, Chikuzen's, and my plugins do). There is no one crazy enough to do this. So we go without x64 for now and it most likely will never happen.

Anyway, some plugins are not that hard to port to x64, you just need to recompile them yourself (also downgrade most of them to 2.5.8. avisynth, as I explained earlier), because asking people to do something they don't care about is wrong.

[Groucho2004]

I suspect very few people use it because it's poorly supported by plugin authors like yourself.
The Avisynth x64 version floating around is an unreliable hack. Look around, people rarely get it to work properly.
Blaming the plugin author(s) for not supporting this makes no sense.

[Stereodude]

The Avisynth x64 version floating around is an unreliable hack. Look around, people rarely get it to work properly.
Well, that certainly hasn't been my experience with it. Aside from a lack of 64-bit plugins I haven't found it to be any less robust or more problematic than the 32-bit version. Heck, I was even able to get QTGMC working in 64-bit. I pretty much use 64-bit AVIsynth + MP Pipeline (for 32-bit filters that aren't available in 64-bit and enhanced "multithreading") exclusively.

[the_weirdo]

Well, that certainly hasn't been my experience with it. Aside from a lack of 64-bit plugins I haven't found it to be any less robust or more problematic than the 32-bit version.

Then you must be a very lucky person ;)

[Mystery Keeper]

Well, that certainly hasn't been my experience with it. Aside from a lack of 64-bit plugins I haven't found it to be any less robust or more problematic than the 32-bit version. Heck, I was even able to get QTGMC working in 64-bit. I pretty much use 64-bit AVIsynth + MP Pipeline (for 32-bit filters that aren't available in 64-bit and enhanced "multithreading") exclusively.Memory. AVISynth x64 (and most likely its plugins too) problem is memory cap of 4GB. When it reaches this cap - it crashes. That makes it pretty much less useful than x32 version due to the mentioned lack of plugins.

[Groucho2004]

Memory. AVISynth x64 (and most likely its plugins too) problem is memory cap of 4GB. When it reaches this cap - it crashes. That makes it pretty much less useful than x32 version due to the mentioned lack of plugins.
If there were a memory limit of 4 GB in Avisynth 64 there would be no point in using it.

[Mystery Keeper]

If there were a memory limit of 4 GB in Avisynth 64 there would be no point in using it.
That IS the case.

[Groucho2004]

That IS the case.

OK, but then it should probably be named Avisynth 32+1 bit. :D

[Motenai Yoda]

If there were a memory limit of 4 GB in Avisynth 64 there would be no point in using it.

Yep but x86-32 crash when reach 2 GB, I don't know why, but my setup has huge temporary memory leak that reach 2gb very often, especially with setmtmode (adding setmemorymax do nothing).

[the_weirdo]

Avisynth 32-bit can reach 4GB memory (in theory) on Windows 64-bit when piping with applications that compiled with LARGE_ADDRESS_AWARE flag (actually this flag doesn't need to be set at compile time, there're some ultilities can modify binaries to enable it).

[Groucho2004]

Yep but x86-32 crash when reach 2 GB, I don't know why
Makes sense since the user address space for 32 bit apps on 32 bit OS is 2 GB.

[Mystery Keeper]

Yep but x86-32 crash when reach 2 GB, I don't know why, but my setup has huge temporary memory leak that reach 2gb very often, especially with setmtmode (adding setmemorymax do nothing).

As the_weirdo said, you need to use AviSynth with large address aware programs. If yours crashes - try using this program (http://www.techpowerup.com/forums/showthread.php?t=112556) on it.

[Motenai Yoda]

As the_weirdo said, you need to use AviSynth with large address aware programs. If yours crashes - try using this program (http://www.techpowerup.com/forums/showthread.php?t=112556) on it.

I'm using tMod x264, avs4x264mod from Astrataro too, Sherpya mencoder and all of these have laa on true.

[TurboPascal7]

I just released a new version of FTurn (https://github.com/tp7/fturn/releases/tag/1.4). Another optimization (doing things less wrong) release, no interface changes.

In other good news: these optimizations will be integrated into Avisynth+ core in the next version, finally making this plugin obsolete. It will still work though.

[PetitDragon]

Hi TP7,
Please keep updating the FTurn plugin untill it is integrated into Avisynth MT for realtime playing.:thanks:

[wOxxOm]

Please keep updating the FTurn plugin untill it is integrated into Avisynth MT for realtime playing.He's already integrated it in avisynth-PLUS, but avisynth-MT is an area of SEt's expertise, so SEt's the only person who can do it.

[Keiyakusha]

Please keep updating the FTurn plugin untill it is integrated into Avisynth MT for realtime playing.:thanks:
Why you think it will ever be integrated into the Avisynth MT? And how this is related to realtime playing?

TurboPascal7
Can we possibly have RGB support? Since this will be integrated into Avisynth+, support for it will be added too right? So this is just a matter of copy-pasting. Unless with RGB there will be no speed gains...

[TurboPascal7]

Can we possibly have RGB support? Since this will be integrated into Avisynth+, support for it will be added too right? So this is just a matter of copy-pasting. Unless with RGB there will be no speed gains...
I could just redirect it to internal avisynth functions if specified colorspace is not supported or backport optimizations from avs+ to this plugin, but I don't exactly see the point. (since soon enough everyone will be using avs+ anyways, muahahaha)
We'll see how it goes, I guess, but I won't do anything right now.

[PetitDragon]

He's already integrated it in avisynth-PLUS, but avisynth-MT is an area of SEt's expertise, so SEt's the only person who can do it.

Got it. Hope SEt will consider it. I have no problem to keep using plugin version tho.

Why you think it will ever be integrated into the Avisynth MT? And how this is related to realtime playing?...

Please refer to the link:

http://forum.doom9.org/showthread.php?p=1639044#post1639044

[Keiyakusha]

I could just redirect it to internal avisynth functions if specified colorspace is not supported or backport optimizations from avs+ to this plugin, but I don't exactly see the point. (since soon enough everyone will be using avs+ anyways, muahahaha)
We'll see how it goes, I guess, but I won't do anything right now.
I agree that not that often we need to turn RGB, but I just was working with avisynth where I had to re-assemble some fragmented picture, so ended up using turns quite a lot. The reason I asked is that I thought adding RGB support will come essentially for free once it added into avisynth+ (don't see the reason to use avisynth+, maybe after some years when there will be some new awesome avisynthplus-only plugins)

[real.finder]

hi TurboPascal7 :)

Why not putting the original sangnom function together with the existing sangnom2, as SEt did in aWarpSharp2 in order to keep the compatibility in the old scripts with performance improvements

thanks :)

[TurboPascal7]

hi TurboPascal7 :)

Why not putting the original sangnom function together with the existing sangnom2, as SEt did in aWarpSharp2 in order to keep the compatibility in the old scripts with performance improvements

thanks :)
Will probably do with the next version (together with x64 build) some time soon. I'm not sure about the parameters though: should it use one thread? Should it have more parameters than the original sangnom? Do note that threading is going to be removed at some point once avs+ gets internal threading support.

[DrZine]

Since FTurn is now in the core of avs+, making it obsolete, Maa2.avsi needs to be updated to not need the plugin.

[list]

:thanks: Good work.
Now using the 0.2 pre-release in avisynth 2.58, works great.
You forgot to mention the new interface is Sangnom2(int order,int aa). Didn't notice that until looking at the src.

[luke83]

Very good job!

it's faster than of AAA(): the only good Anti-aliaser that I found for anime. Your MAA2 seems to work as good as it. I'll try on a very aliased edge. Any way it's very good until now

[Reel.Deel]

@TurboPascal7

I noticed that the order parameter in SangNom2 has a different mapping than the original SangNom. Is that how you intended to be?
The options are just inverted:SangNom: SangNom2:
0 - bottom field 0 - both*
1 - top field 1 - top field
2 - both* 2 - bottom field

*Both fields are kept but DoubleWeave() must be called beforehand


There's also a couple of typos in your error messages:
line 612 (https://github.com/tp7/SangNom2/blob/master/SangNom2/sangnom.cpp#L612) - required
Line 616 (https://github.com/tp7/SangNom2/blob/master/SangNom2/sangnom.cpp#L616) - width

[TurboPascal7]

SangNom2 doesn't handle order=2 in any specific way, only values 0 and 1 are valid. I don't think original did anything special for mode 2 either.

Typos fixed, thanks.

[killerteengohan]

Is there any particular reason everytime I try to use MAA2 it says

There is no function named "SangNom2"
(MAA2.avsi, line85)
(MAA2.avsi, line57)

I know I have Sangnom2.dll installed correctly and everything it needs to run. It works on my friends computer and my other laptop but wont work on this computer.


EDIT: It turns out it was Microsoft Visual C++ (x86) was needed in order to use the newer 0.35 version of MAA2 with Sangnom2.

[ryrynz]

Since FTurn is now in the core of avs+, making it obsolete, Maa2.avsi needs to be updated to not need the plugin.

Still hasn't been updated. Is it not called fturn any more in Avisynth+? I get an error if it's called. Saw a previous post with a user having a similar issue and stating that turn worked fine, so I renamed all instances to just turn and it's working but unsure if that's correct.

[Groucho2004]

Still hasn't been updated. Is it not called fturn any more in Avisynth+? I get an error if it's called. Saw a previous post with a user having a similar issue and stating that turn worked fine, so I renamed all instances to just turn and it's working but unsure if that's correct.
"fturn" is a plugin function. "turn" is a Avisynth core function. The functionality is the same. In AVS+, the fturn code has been integrated into the core.

[kedautinh12]

SangNom2 0.6.1
Throw error if YUV420 height is not mod4.
https://github.com/Asd-g/AviSynth-SangNom2/releases