Avisynth+ plugin modernization efforts

[TurboPascal7]

As you might know, a part of Avisynth+ (http://forum.doom9.org/showthread.php?t=168856) core team is working on plugins modernization, adding x64 support and other features. This thread is dedicated to discussion of those plugins. Some new plugins are also included.

General changes/rules
MMX/ISSE optimization paths are removed everywhere, replaced with SSE2/newer routines. C versions are added too unless specified otherwise.

YUY2 support is also removed if any work is required to support it. You can still use these plugins by converting your YUY2 clip to YV16, processing it with planar-only filters and converting back to YUY2 if you need. This conversion is lossless and fast.

Right now both Avisynth+ and Avisynth 2.6 are supported. Avisynth 2.6 support will be dropped at some point when Avs+ specific features are added - multithreading and >8bit colorspaces being obvious examples. Avisynth 2.5.8 is not supported.

All plugins are dynamically linked to vc110 runtime. Avisynth+ installer provides it for you.

VapourSynth, maybe?
Right now the answer is no. VapourSynth support is considered and might be added at some point in the future. For now - feel free to fork/take the code from anything you want, most plugins are/will be licensed under MIT.

How can I help?
Usual stuff - testing, discussing, updating some plugins that aren't included yet. Feel free to join our IRC channel (irc://irc.rizon.net/avs-plus) for faster communication. Writing documentation would be very helpful too, especially for RgTools.

What's next?
Current "roadmap" can be found here (http://goo.gl/kPywxZ). It's somewhat messy and does not mean that these plugins will be ported in any particular order, but it does show what's considered right now and what's not.


Plugins listed in random order. Only those hosted under the AviSynth organization on GitHub (https://github.com/AviSynth) are included.

Vinverse
Source (https://github.com/AviSynth/vinverse) / binaries (https://github.com/AviSynth/vinverse/releases). Opt parameter is removed. New Vinverse2 function provides a fast implementation of this script (http://forum.doom9.org/showthread.php?p=1584186).

TMaskCleaner
Source (https://github.com/AviSynth/tmaskcleaner) / binaries (https://github.com/AviSynth/tmaskcleaner/releases). A really simple plugin, never released before. It is basically mt_hysteresis with all areas less than length pixel discarded. Useful for some mask cleaning.

TColorMask
Source (https://github.com/AviSynth/tcolormask) / binaries (https://github.com/AviSynth/tcolormask/releases). A really fast implementation of ColorKeyMask for YUV colorspaces. Never released before.

SangNom2
Source (https://github.com/AviSynth/SangNom2) / binaries (https://github.com/AviSynth/SangNom2/releases) / thread (http://forum.doom9.org/showthread.php?t=168315). Same "old" SangNom2. Additional info can be found in its thread. Does not have a C version yet.

MSharpen
Source (https://github.com/AviSynth/msharpen) / binaries (https://github.com/AviSynth/msharpen/releases). Same old MSharpen. Output for planar colorspaces is not exactly identical because of a bit different blurring routine. YUY2 support removed, all planar routines optimized for SSE2, a few old bugs fixed. External file configuration is no longer supported.

RgTools
Source (https://github.com/AviSynth/RgTools) / binaries (https://github.com/AviSynth/RgTools/releases). Replacement of some kassandro's plugins. 24 modes of Removegrain, 24 modes of Repair, both modes of VerticalCleaner and all variations of Clense are implemented. No more dlls mess - a single dll with dynamic dispatch is provided. Some routines might be slightly less efficient than original, some are faster. Output of some modes of RemoveGrain is not exactly identical to the original because of some rounding difference. Other functions should be identical.

Deblock
Source (https://github.com/AviSynth/Deblock) / binaries (https://github.com/AviSynth/Deblock/releases). Simple deblocking filter. No significant changes, simple refactoring. Should still be noticeably faster thanks to better compilers. YUY2 support removed, useless mmx and isse parameters too. This filter is licensed under GPL.

MedianBlur2
Source (https://github.com/AviSynth/MedianBlur2) / binaries (https://github.com/AviSynth/MedianBlur2/releases). Simple median filter similar to MedianBlur (function name is still MedianBlur). Theoretical runtime complexity per pixel is constant, meaning that the filter has same performance on any radius. Additional info here (http://forum.doom9.org/showpost.php?p=1656988&postcount=19).

Checkmate
Source (https://github.com/AviSynth/checkmate) / binaries (https://github.com/AviSynth/checkmate/releases). Update of the old checkmate plugin, used for dot crawl removal. Better performance, less bugs, a bit lower precision. The difference is hardly noticeable when you're looking for it.

Masktools2
Source (https://github.com/AviSynth/masktools) / binaries (https://github.com/AviSynth/masktools/releases). A fork of masktools2. The only plugin compatible with avisynth 2.5.8 for now. More info in this (http://forum.doom9.org/showthread.php?p=1658580#post1658580) post.

Average
Source (https://github.com/AviSynth/Average) / binaries (https://github.com/AviSynth/Average/releases). The good old Average plugin but a bit faster and with some additional sanity checks.

[TurboPascal7]

Reserved

[innocenat]

As mentioned in roadmap above, I am currently working on tivtc/tdeint port.

[Guest]

MSharpen
Source (https://github.com/AviSynth/msharpen) / binaries (https://github.com/AviSynth/msharpen/releases). Same old MSharpen. Output for planar colorspaces is not exactly identical because of a bit different blurring routine. YUY2 support removed, all planar routines optimized for SSE2, a few old bugs fixed. External file configuration is no longer supported. The only plugin currently licensed under GPL, but that will most likely change in the near future. I can't see any reference/credit to the original author. Do you think that is appropriate? And for the other plugins?

[TurboPascal7]

I can't see any reference/credit to the original author. Do you think that is appropriate? And for the other plugins?

It will be added in the readme in a few days.
EDIT: here, done for msharpen.

[real.finder]

I downloaded all of them, I'll try them nearest opportunity

Waiting for the rest

Thank you :)

[Keiyakusha]

RgTools breaks existing scripts
Avisynth open failure:
Script error: RemoveGrain does not have a named argument "planar"

[TurboPascal7]

RgTools breaks existing scripts
Avisynth open failure:
Script error: RemoveGrain does not have a named argument "planar"

Yes, that parameter is removed because it does not make sense.

[Keiyakusha]

Yes, that parameter is removed because it does not make sense.
Okay, I'll stick to kassandro's plugins. :thanks:

[TurboPascal7]

Okay, I'll stick to kassandro's plugins. :thanks:

Just for reference: can you provide an example where this parameter is actually useful?

[Keiyakusha]

Just for reference: can you provide an example where this parameter is actually useful?

No. Until now I never knew this parameter existed at all and can only guess what it does by it's name. Perhaps those who use it in complex scripts can answer that.
If you want some example, I guess QTGMC will be one of the more or less known ones.

[Sapo84]

Now, in order to prohibit unexperienced users from applying the above filters to interleaved color spaces, we have added the boolean variable planar to RemoveGrain, Repair and TemporalRepair. If planar=false (the default value), then these filters reject YUY2, RGB24 and RGB32 frames. Only if planar=true, then these filters accept YUY2, RGB24 and RGB32 input, but always assume that the data are organised in a planar way. If you use planar=true with ordinary interleaved input, you get garbage.

I'd say it's never actually useful and I agree with tp7 decision of removing it entirely.
If I set planar=false I'm expecting the filter to work with non planar color spaces, not rejecting YUY2, RGB24 and RGB32.

[Stephen R. Savage]

"Planar" is required to work on YUY2 inputs. You repack the image to YV16-in-YUY2 by using the Interleaved2Planar function. MaskTools also has support for this hack. In AVS 2.6, this hack should be replaced with YV16.

[TurboPascal7]

Mkay, I just released a new version of RgTools. Planar parameter is added, should work as before now. You should feel really bad if you use this feature though and I do hope to remove it at some point in the future.

[Guest]

MSharpen ... The only plugin currently licensed under GPL, but that will most likely change in the near future. Please feel free to re-license it with any suitable less restrictive license.

[TurboPascal7]

Please feel free to re-license it with any suitable less restrictive license.
Thanks.

[foxyshadis]

Nooooo, now how am I going to use my dusty old Athlon XP without ISSE!? Haha.

Thank you so much for rewriting RgTools. It's always been a bit of a pain setting up the whole suite of DLLs since the 1.0pre split. It looks like the T versions aren't included, is that on the roadmap? With any luck a rewrite might not require avsrecursion functionality.

[TurboPascal7]

It looks like the T versions aren't included, is that on the roadmap? With any luck a rewrite might not require avsrecursion functionality.
Not right now. Kassandro's stuff takes a lot of effort and time since it's essentially reverse-engineering and I'd like to get some other more useful plugins done first.

[TurboPascal7]

New filter: MedianBlur2 (function is called MedianBlur).
It's really similar to the old MedianBlur. Has only 3 arguments: radii of Y, U and V plane filters. No other functions from original MedianBlur are implemented and most likely won't. Maximum radius is limited to 127. It can be changed but I'm not sure anyone uses too large medians.

Unlike the old MedianBlur, this implementation has constant runtime complexity, meaning that theoretical performance is same for any radius. Implementation is based on this (http://nomis80.org/ctmf.html) paper, but includes some additional optimizations.
1) When SSE2 is available and radius is 1 or 2, special routines are used. They're a lot faster than the generic one for these radii.
2) For 2 < radius < 8, generic approach with 8-bit bin size is used. Using 8-bit bins makes histogram addition/subtraction faster with SSE2.
3) For large radii, 16-bit bins are used, as described in the paper.

In other words, you can expect huge performance drop when going from 1 to 2, not so huge but still large from 2 to 3 and a noticeable slowdown from 7 to 8. Between them the fps should be constant and it actually might get a bit faster with larger radius.
Performance with radius > 2 also depends on the actual frame content. Processing colorbars() is a lot faster than addgrainc(10000).
It is quite possible that you'll get worse performance for radius = 3 with this plugin compared to the original MedianBlur. All other radii should be (a lot) faster.

P.S. A few days ago I also added Deblock but forgot to mention it. No significant changes in there though.

[TurboPascal7]

A small update to MedianBlur2: new function called MedianBlurTemp. Requested by Tempter57.

It partially implements the old MedianBlurT function but doesn't have MVTools-related parameters (hance the function name change). If you don't use mo-comp part of it, you should be able to just change the name used without any other changes. I might implement MedianBlurT as a script wrapper around MVTools/Masktools/MedianBlurTemp later.

Please do note that for temporal-only processing this filter is extremely inefficient (just like the original). For any reasonable radius (<= 15) pure-temporal median can be calculated a lot faster in SIMD. If the demand for a function like this is high, I might add it later.

Meanings of some parameters between two modes are different, just like they were in original filter. Setting spatial radius to 0 will just disable spatial filtering, setting it to -1 will copy the plane and all other values will set the plane to absolute value of radius. Yes, there is no way to set the plane to 1.

Two questions:
1) I don't really like the MedianBlurTemp name. Any better ideas? MedianBlurT is a no-go because of the reasons described above.
2) Better interface ideas? I.e. something that would allow you to set the plane to 1 and maybe be more consistent with the pure-spatial version of the filter.

Get the binaries in the usual place. And stay tuned. :)

[jmac698]

I would like the temporal only version, this is a very important operation for a technique which uses 3+ passes of a VHS to reduce "comet" noise effect.

Btw, the original medianblurT is described here:
http://forum.doom9.org/showthread.php?t=84636

The temporal median is a very slow operation currently but I use it a lot. Also used for astronomy pictures.

[ajp_anton]

2) Have never used this function, just going by the name "median" to guess what it does... what's the difference between -1=copy and setting all radiuses to 0? Also, what about setting the plane to 0?
Anyway, to try to give a suggestion to this question, you could allow other types of input than just ints. False could be used to disable spatial filtering. Not sure what true would do, but maybe it's not even needed.

[mountiedm]

I'd love an autocrop plugin/script :)

[TurboPascal7]

New filter: checkmate (https://github.com/AviSynth/checkmate)!
It now has correct border processing, a bit more checking for arguments (doesn't crash with max=0 for example), and should be a lot faster when SSE2 is available. As usual, x64 version is also included.
This version has a bit lower precision so you might get +-1 difference on random pixels. This difference is hardly important.

[TurboPascal7]

Not like anyone cares, but here's another "new" filter: masktools2 (https://github.com/AviSynth/masktools).
This is the most controversial plugin update so far, considering that original masktools already worked fine on both x64 and x86. I still had my fun and started this thing way before avs+ was born.

You can read what got changed in this wiki post (https://github.com/AviSynth/masktools/wiki/Difference-to-masktools2-a48). In short: some filters got less bad, some bugs fixed, a lot easier to understand codebase. This had to be done if we ever want to add 16-bit support and AVX2 (which I will do at some point). Yes, I'm fully aware that some filters got slower on some CPUs. I'm not gonna change that and you most likely won't notice the difference, since it's usually something like "omg 1000 fps instead of 1050". MMX optimization is also dropped because come on, it's almost 2014.

This branch will be called b* as opposed to a* of original masktools. Three builds are published: x86 avs 2.5 version called masktools2-25.dll plus x86 and x64 avs+/avs2.6 version called masktools2.dll. 2.6. doesn't have any postfix because it won't make sense in the future since I'll be dropping 2.5.8 support. 2.5 version is statically linked, 2.6/avs+ reguires vs2012 runtime as usual.

[zero9999]

Not like anyone cares, but here's another "new" filter: masktools2 (https://github.com/AviSynth/masktools).
This is the most controversial plugin update so far, considering that original masktools already worked fine on both x64 and x86. I still had my fun and started this thing way before avs+ was born.

I care and it's a substantial improvement. Thanks a lot!

[Reel.Deel]

Not like anyone cares, but here's another "new" filter: masktools2 (https://github.com/AviSynth/masktools).

I also care and thank you for all your efforts. My newly built computer [i7-4930K] seems to like your filters. Nice performance increase over the "official" versions. :)

[real.finder]

I also care, for first experience seems to be best than Previous versions :)

next is mvtool2, right?

[TurboPascal7]

next is mvtools2, right?
No, mvtools2 is a major challenge that I'm not prepared to take up yet. I also hope Myrsloik will rewrite it for vsynth before I start.

As for what's next - I don't know. I have a few filters in works like VariableBlur and TTempSmooth but if something simple/fun comes up, I'll be doing that instead.

[mastrboy]

MMX optimization is also dropped because come on, it's almost 2014.


Wish more developers had your mindset about CPU instructions...

And thanks for all the plugin updates :)

Btw, how did you manage to "modernize" checkmate? I thought the source code was never published?

[jpsdr]

Thanks for this update.

Edit :
Need a little help. When i try to compile filters putting the new version of avisynth.h,
i have the following error (translated) :

1>RawSource.obj : error LNK2001: external symbol not solved "struct AVS_Linkage const * const AVS_linkage" (?AVS_linkage@@3PEBUAVS_Linkage@@EB)

Help... Thanks...

[turbojet]

Thanks for masktools, I care about this effort but this was the first filter released that I use albeit rarely. Looking forward to tivtc, I think there's a lot to be gained from it, especially tfm() which acts as if it's single-threaded the only other common filters I use is:
- nnedi3, already multithreaded, not sure there's much, if any, to be gained
- colormatrix, maybe could see some gain but already fast
- autocrop, gain would be minimal, might reduce time by 500ms
- decomb, already well multi-threaded but would be much more useful if decimate had y0/y1 that functioned like it does in telecide/tfm, x0/x1 would also be of benefit.
- resizers which is avisynth+ related, its unfortunate they are ~4% slower in most cases, in rare cases much slower but maybe that will change some day.

[TurboPascal7]

jpsdr
Here's an example (https://github.com/AviSynth/Deblock/blob/master/Deblock/deblock.cpp#L205) of how you register a filter with new 2.6 header. Yes, the AVS_linkage thing is required.

turbojet
You probably shouldn't expect any performance gains on tritical's filters (TIVTC, nnedi3). In fact, some might get a bit slower in singlethreaded mode. We'll see how it goes when avs+ gets multithreading.

[turbojet]

Don't TFM() and Telecide() basically do the same thing? If so, I can't figure out why the former is almost twice as slow as the latter. Even the fastest tfm settings are significantly slower then the slowest telecide settings. Isn't this a signal of some flawed code?

TDecimate which is often seen as slow is actually a little faster than decimate, it just has a very slow filter, tfm, feeding it.

[TurboPascal7]

Don't TFM() and Telecide() basically do the same thing? If so, I can't figure out why the former is almost twice as slow as the latter. Even the fastest tfm settings are significantly slower then the slowest telecide settings. Isn't this a signal of some flawed code?
No idea, I have never looked at the source code of both. But in general tritical's filters are optimized to the extent where you can't do much about them, other than maybe rewriting the whole algorithm from scratch which is "a bit" time-consuming.
Also, if telecide works for you fine, why don't you just use it over tfm? Not to mention tfm is way beyond realtime anyway.

[jpsdr]

@TurboPasal7
Where can i get the right avisynth.h to use ?
I've took it from one of your ported filter, but i'm having the following (translated) error :

1>RawSource.cpp(541): error C2259: 'RawSource'*: impossible to [don't know how to translate "instance"...?] an abstract class
1> because of following mebers*:
1> 'int IClip::SetCacheHints(int,int)'*: is abstract
1> f:\prg\visual_2010\rawsource\rawsource\../avs2x/avisynth-2_6.h(671)*: see declaration of 'IClip::SetCacheHints'


In the file i've took from your's ported filter, there is :

int __stdcall SetCacheHints(int cachehints,int frame_range) { return 0; } ; // We do not pass cache requests upwards, only to the next filter.


In the exemple you've linked there is :

int __stdcall SetCacheHints(int cachehints,int frame_range); // We do pass cache requests upwards, to the cache!

And in this exemple, the .cpp code don't have any SetCacheHints declaration.

If in the project i'm trying to compile i remove any SetCacheHints declaration in the .cpp, i have the error described (with both cases of SetCacheHints in avisynth.h). I must put the following code in the .cpp to compile :

int __stdcall SetCacheHints(int cachehints,int frame_range) {return 0;} ;

Don't know if it's the correct thing, and don't know how this is supposed to be.

Thanks for your help already provided.

Note : NNEDI3 is still advancing, i've put out all the asm functions from core file, it's compiling and seems working (no crash and a picture is displayed... :D).

[Plorkyeran]

Don't TFM() and Telecide() basically do the same thing?
No. Completely different algorithms and different metrics for deciding when a frame is combed.

[TurboPascal7]

jpsdr
Avisynth.h from any of the updated filters should work as they should use the same header anyway. Do not touch it. Don't modify anything there. If it doesn't compile - it's a problem in your code. As for RawSource, there's already a 2.6 version (https://github.com/chikuzen/RawSource_2.6x/tree/master/src).

Ok, found your problem:
class RawSource: public IClip {
Filters should inherit GenericVideoFilter rather than IClip. Or define all abstract methods like Chikuzen did in the linked plugin.

[turbojet]

No idea, I have never looked at the source code of both. But in general tritical's filters are optimized to the extent where you can't do much about them, other than maybe rewriting the whole algorithm from scratch which is "a bit" time-consuming.
Also, if telecide works for you fine, why don't you just use it over tfm? Not to mention tfm is way beyond realtime anyway.

I need to use TDecimate because this (http://forum.doom9.org/showthread.php?t=169106) is pretty common in most tv caps. Telecide().TDecimate() works most of the time but at times it picks the wrong frames, switching to TFM().TDecimate() fixes it. TFM is on the borderline of realtime here on a 1080i clip:
-TFM() 52 fps (below sources 60 fps)
-TFM(clip2=nnedi3(),pp=1,mchroma=false,slow=0) 67 fps, complex nnedi3 is faster than all of the tfm simpler deinterlacers.
-TFM(clip2=nnedi3(),pp=1,mchroma=false,slow=0,micmatching=0) 74 fps, any way it's faster?
-Telecide() 110 fps, deinterlacing complexity is about in the middle of tfm's.

No. Completely different algorithms and different metrics for deciding when a frame is combed.

Right but the output is very similar, most of the time, shouldn't an improved algorithm that's performing the same task be faster?

[jpsdr]

jpsdr
As for RawSource, there's already a 2.6 version (https://github.com/chikuzen/RawSource_2.6x/tree/master/src).

Ok, didn't know, i've taken this one. I just had to update the avisynth.h to compile in x64.

Thanks.

[Gavino]

Ok, found your problem:
class RawSource: public IClip {
Filters should inherit GenericVideoFilter rather than IClip. Or define all abstract methods like Chikuzen did in the linked plugin.
Source filters cannot inherit GenericVideoFilter as they have no 'child'. So they need to define all the abstract IClip methods themselves.

[jpsdr]

I've finished to put all asm in external, and filter seems to work.

I've tried to compile using new header.
I have to change the 2 following lines : Is it the correct way ?

child->SetCacheHints(CACHE_RANGE,3);

v.AsClip()->SetCacheHints(CACHE_RANGE,2);

changed to :

child->SetCacheHints(CACHE_25_RANGE,3);

v.AsClip()->SetCacheHints(CACHE_25_RANGE,2);


It compiles, but when tested (with 2.6a4, not avs+), i've got an error saying that arg0 must be a clip...

[TurboPascal7]

And another simple filter: average (https://github.com/AviSynth/Average). It is a new and extremely simple implementation of the old Average plugin. All internal operations are done in float so we won't have any troubles adding 16-bit support later or anything. It should be a bit faster than the old filter in most common cases and a lot faster when one of the weights is greater than 1.

Do note that Average != RedAverage. The latter won't be implemented by me any time soon if ever. Feel free to propose some new features but I won't optimize it to hell and want to keep the plugin simple.

[SEt]

I'm not really following the AVS+ design specifics, but reading this thread obvious question arises: why are you using incompatible and ugly 2.6 interfaces instead of standard 2.5 ones?

[TurboPascal7]

I'm not really following the AVS+ design specifics, but reading this thread obvious question arises: why are you using incompatible and ugly 2.6 interfaces instead of standard 2.5 ones?

Mainly because 2.5 doesn't know about newer colorspaces. I could hack it like some authors do but what for? All plugins will be migrated to the new avs+ interface when it's ready.

[Plorkyeran]

Right but the output is very similar, most of the time, shouldn't an improved algorithm that's performing the same task be faster?
TFM does a much better job of matching any time it's nontrivial to do so (i.e. not full-screen motion or entirely static).

[SEt]

The hack is trivial and way more compatible than trying to port plugins to 2.6. I've did this for nnedi3ocl and can say it required minimal effort. I can probably assemble such "extended" 2.5 avisynth.h if you want.
If some kind of compatibility is desired - it should be with 2.5, not 2.6.

[TurboPascal7]

The hack is trivial and way more compatible than trying to port plugins to 2.6. I've did this for nnedi3ocl and can say it required minimal effort. I can probably assemble such "extended" 2.5 avisynth.h if you want.

What for? To support 2.5.8 avisynth? Face it - it's dying (http://forum.doom9.org/showthread.php?t=168478). To add baked code to the plugins? I don't get it. All plugins are perfectly compatible with 2.6 and avs+.

Yes, the header is quite ugly but the usage is identical to 2.5.8 anyways and I know the API well enough to not care how the header looks.

[SEt]

To just work with any used now Avisynth version from end user point of view. And not produce cryptic errors because user used wrong alpha of 2.6. Rather than doing poll of "version of Avisynth" it would be way more relevant to do poll "version of plugins" people use.

To my taste AVS_Linkage hack is more ugly: it's still "baked" even though less "baked". I'd prefer to stick to compatibility or break it once for clean new way. Intermediate solutions like 2.6 only stall the progress: it's still ugly and should not be considered "good enough for now".

[ultim]

To just work with any used now Avisynth version from end user point of view. And not produce cryptic errors because user used wrong alpha of 2.6. Rather than doing poll of "version of Avisynth" it would be way more relevant to do poll "version of plugins" people use.

To my taste AVS_Linkage hack is more ugly: it's still "baked" even though less "baked". I'd prefer to stick to compatibility or break it once for clean new way. Intermediate solutions like 2.6 only stall the progress: it's still ugly and should not be considered "good enough for now".

There will be a new interface where we'll start with a clean slate. But I felt (and still feel) it is of lower priority than the features we have been working on.