Avisynth+ plugin modernization efforts

[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!
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.
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. 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]

Originally Posted by TurboPascal7

Not like anyone cares, but here's another "new" filter: masktools2.
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]

Originally Posted by TurboPascal7

Not like anyone cares, but here's another "new" filter: masktools2.

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]

Originally Posted by real.finder

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]

Originally Posted by TurboPascal7

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 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]

Originally Posted by 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?

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... ).

[Plorkyeran]

Originally Posted by turbojet

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.

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]

Originally Posted by TurboPascal7

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 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.

Originally Posted by Plorkyeran

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]

Originally Posted by TurboPascal7

jpsdr
As for RawSource, there's already a 2.6 version.

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

Thanks.