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.

[SEt]

That's why supporting 2.6 interfaces instead of 2.5 looks strange to me. 2.5 would require no recompilation unless you want new colorspaces and then you have to recompile anyway.

[ultim]

Avs 2.6's backwards compatibility isn't perfect, but many/most 2.5 plugins do work with it without recompilation.

[huhn]

>8bit colorspaces

can't wait for this and the plugins...

[jpsdr]

I've finished puting out all the asm functions in my attempt to port to x64 NNEDI3.
You can found it here (https://github.com/jpsdr/NNEDI3).

Actual status :
- x86 version seems to work.
- x64 version compile but crashes.
I've (try to) removed CPU optimizations to bypass all asm functions, by commenting the line 170 of PlanarFrame.cpp
//cput=checkCPU_ASM();
this way the checkCPU function will always return 0, this way only the C functions, and almost no asm functions will be called. It's still crashing. I can't debug because the PC i'm compiling is under XP32.
And more, if issue is not because of the the asm functions, but more higher level issue, i don't have the knowledge.
I'll retake a look on the asm functions, but if someone else is motivated enough to take a look, fell free, because if i don't find anything in the asm, it will stop here for me.

[TurboPascal7]

jpsdr
Sorry if this sounds rude, but what's the point of doing something that someone else already did better than you (http://forum.doom9.org/showpost.php?p=1658589&postcount=450)? Backporting that to avisynth or simply reusing the asm parts sounds a lot more reasonable to me than what you're doing.

[jpsdr]

Unless i've misunderstood something, this code is for vapoursynth, so i can't just compile the project and directly use it for avisynth...

And, as i said, forcing the check cpu to 0 result in deactivating the use of any asm functions, so issue is not related to the asm part. If i compile the dll in release, there a crash, if i compile in debug mode, it says that function nnedi3_rpow2 doesn't exist.
Backporting the C code to avisynth... It may be more difficult to me than doing what i've done, that's why i've directly try what i've done. From the few i've quickly seen, there is no trace of the PlanarFrame part (but maybe it's somehow integrated differently).
What i'm doing may not sounds reasonable, but it's what i was more capable of and using the less time (In don't know and don't have yasm), as using directly what was already done was not something i felt able to.
I thought that just puting out the asm file and re-compiling would work, and doing that, was something i could do quickly. Well, it worked indeed for x86, but it didn't for x64, and for now, it's not apparently related to asm, but somehow to the C++ code part. So, not related to the part i've done. So, the most probalby is that there is something not compatible with x64 in the actual C++ code...

I've tried, only a partial success, maybe what's missing is just a very little something, probably too much related to the "++" part of the C++ for me, or maybe it needs a total rewrite of the filter. At this point, i don't know anymore. So, i've put what i've done on github here (https://github.com/jpsdr/NNEDI3), like this, if by any luck somehow want to take a look, very good, otherwise, it can't be helped.

[TurboPascal7]

I was hoping that we won't go the old avs64 route of randomly throwing things together hoping it will work. x64 support is nice but it's not the only point. Cleaner codebase, support for non-windows (and non-x86) platforms, new colorspaces and simply Doing Less Dumb Stuff- all of this is very important for future plugin updates and general maintenance. Just looking at needi3, you most likely can get rid of PlanarFrame and memcpy_amd parts entirely. That is - not porting but removing them. Same goes for YUY2 support - having it in nnedi the way it works now doesn't make any sense. It's bad both for developers and for users.

So yeah, you have to have some knowledge of C/C++ to be able to "update" stuff. Otherwise you're just making things worse.

Of course, this is only my idealistic opinion, feel free to disagree. But I really don't want us to make avisynth legacy more awful than it already is.

[jpsdr]

I've take a quick look at what have already done for vapoursynth, unfortunately, he removed the most important point (for me) that i absolutely want to keep, the internal multi-threading...
Because, in my opinion, mt is better to be done internaly.

[TurboPascal7]

Because, in my opinion, mt is better to be done internaly.

Internal multithreading is almost always worse than frame-level threading though. It is strongly discouraged in avs+ world unless your filter cannot use frame-level threading at all because it requires some certain frame order or w/e.

[jpsdr]

The interest i see in internal MT vs frame is than working memory space of each thread is very lower (n threads working on 1/n of picture size vs n thread working on 1 picture size) => probability of cache misses very lower.*
But, i think issue is not here, i'll post my investigation results in avs+ thread.

[jackoneill]

I removed the internal threading because VapourSynth does it for me (and it's probably specific to Windows).

If I remember correctly, I did not change the signatures of any of the asm functions, so taking only the asm (+ the "extern blah" declarations) should Just Work™.

yasm is the x86 assembler used by x264. It's really simple:
yasm -DARCH_X86_64=1 -DPIC -f win64 -o nnedi3-asm.o nnedi.asm
yasm -DARCH_X86_64=0 -f win32 -DPREFIX -o nnedi3-asm.o nnedi3.asm
Something like that.

If you want it to use only the C++ code, isn't it easier to invoke nnedi3 with opt=1 in the Avisynth script?

[TurboPascal7]

Updates, updates.
New version of tmaskcleaner (https://github.com/AviSynth/tmaskcleaner) released. 'Fade' parameter added to make mask non-binary in certain cases. More info here (https://github.com/AviSynth/tmaskcleaner/pull/1). Contributed by tophf.

New version of Average (https://github.com/AviSynth/Average). Apparently people get upset when you don't OPTIMIZE enough, so this version has about two times faster performance when less than 256 clips passed and absolute values of all weights are lower or equal to one. This is the most common usecase I've seen. Still not as fast as the RedAverage thing but this is as far as I will go today. Current performance should be enough for everything.

And we're continuing our "going permissive" policy - masktools2 is now licensed under MIT.

As usual, please remember that only a handful of people (3 maybe?) test these plugins. So always check the output before using anything "in production".

Stay tuned.

[jpsdr]

If you want it to use only the C++ code, isn't it easier to invoke nnedi3 with opt=1 in the Avisynth script?
I didn't think about it... But, not totaly, because it'll not prevent the call of ASM part testing the CPU.

But, thanks telling me that, because i've totaly zapped this, and when back home, i'll have to check in my avisynth file that i don't force opt to 2, otherwise, what i've done was meaningless... I have a big doubt....

[jpsdr]

Checked, my script didn't force the opt arg.

[TurboPascal7]

New versions of MedianBlur (https://github.com/AviSynth/MedianBlur2/releases/tag/0.93) and Average (https://github.com/AviSynth/Average/releases/tag/0.92). Both fix one giant memory leak and make the plugins actually usable in complex scripts. Only MedianBlurTemp is affected (which is also now renamed to MedianBlurTemporal to make you type more).

[jpsdr]

Finaly, it seems to work !!
Ported version of NNEDI3 v0.9.4 to x64. API updated to v2.6, so, it's not working with avisynth 2.5.8.
I'ne name this version v0.9.4.1.
For those interested in testing :
Sources are here (https://github.com/jpsdr/NNEDI3).
Binaries are here (https://github.com/jpsdr/NNEDI3/releases/download/v0.9.4.1/NNEDI3_v0_9_4_1.7z).

[jpsdr]

Ported version of AutoYUY2, based on neuron2's pluggin, updated to API v2.6 and x64 version, so, not working with avisynth 2.5.8.
Sources are here (https://github.com/jpsdr/AutoYUY2).
Binaries are here (https://github.com/jpsdr/AutoYUY2/releases/download/Release_20140117/AutoYUY2_20140107.7z).

[Guest]

Please add original license and copyright. You can't just take my work like that. Thank you.

I would appreciate a notification when it is done.

[TheFluff]

Please add original license and copyright. You can't just take my work like that. Thank you.

I would appreciate a notification when it is done.

It's GPL and if you look in the source files the original license is right there with your name on it so I'm pretty sure he's free to "take" (that's a funny way to refer to open source peer improvement) whatever he wants. I guess if you wanted to be technical you could make the case that he hasn't redistributed a complete copy of the GPL, but nobody complies with that part of the license anyway so who cares.

It would also seem from your homepage that this same person has contributed some rather significant improvements to this plugin in the past and that you were okay with him "taking" your work then, since you hosted the result on our own webpage.

All of that being said I do find this a rather weird choice of plugin to port to Avisynth 2.6 considering how few things support YUY2 and that you have access to both YV16 and YV24.

[jpsdr]

I do find this a rather weird choice of plugin to port to Avisynth 2.6

Basicaly because of the very very little time needed...
And the most interest is not realy the 2.6 port, but more the x64 version.

[Guest]

I don't mind you using my stuff as long as you adhere to licensing requirements. The binary package totally lacks GPL compliance and the COPYING file needs to be included in both source and binary packages, as long as they remain separately downloadable. Thank you.

This is nothing to do with JPSDR personally and I have credited his fine contributions quite prominently as you noticed, so please don't try to turn this into some kind of vendetta. I very politely asked for the additions, made no threats, and deleted no links.

I've also generously allowed MSHARPEN to be re-licensed for your use and would be happy to do so here if you only ask, as well as for any other of my stuff. On the other hand if you don't want to use it because you think it's useless, then I will not be offended. Certain circles have been saying for a long time that everything I do is useless. :)

[TurboPascal7]

As a general rule you always should have a license file in your repo. It helps avoiding situations like we have here and keeps everyone happy. So jpsdr, I strongly advice you to add the file and be done with it.

[Guest]

Thanks, TurboPascal7. It's not a big deal. jpsdr has been offline since my last post and I'm sure harmony will reign. :)

Actually, I should have asked jpsdr privately and for that I apologize. Just didn't think.

[DrZine]

Any chance of adding RemoveGrainHD functions to RGTools? RemoveGrainHD is still needed in scripts like contrasharpening.

[TurboPascal7]

Not in the near future.

[real.finder]

hi tp7

MedianBlur2 not compatible with YAHR (http://avisynth.nl/images/YAHR.avsi)

http://i.imgur.com/nQyHQlJ.png

[jpsdr]

Updated version of NNEDI3 v0.9.4, so now version is v0.9.4.2.
Add Y8, YV16 and YV24 support.
But... There something odd !!
YV16 is slow as hell !!! I've been searching again and again, i still didn't find why in the code...:(
For those interested in testing :
Sources are here (https://github.com/jpsdr/NNEDI3).
Binaries are here (https://github.com/jpsdr/NNEDI3/releases/download/v0.9.4.2/NNEDI3_v0_9_4_2.7z).

[TurboPascal7]

real.finder
I can't check right now but I'm pretty sure the source of incompatibility is incorrect chroma radius passed in MinBlur when uv=1. With medf=-200, actual passed values are -400 and -600, which do not make sense. In this case the behavior is intentional and fixing the obviously broken script is a better idea. I have no idea why the old plugin worked as I don't have access to its source code right now.

EDIT: apparently the values outside of the range used to silently set the value of output planes to 0. I can't say I'm very fond of this idea so for now I won't "fix" anything.

[Bloax]

Just wanted to drop in to say that it's a great thing that you're doing this, it's been getting annoying to butcher RGB footage down to YV12 to use some specific filters.

[real.finder]

Updated version of NNEDI3 v0.9.4.
Add Y8, YV16 and YV24 support.
But... There something odd !!
YV16 is slow as hell !!! I've been searching again and again, i still didn't find why in the code...:(
For those interested in testing :
Sources are here (https://github.com/jpsdr/NNEDI3).
Binaries are here (https://github.com/jpsdr/NNEDI3/releases/download/v0.9.4.2/NNEDI3_v0_9_4_2.7z).

does it support fturn?

http://forum.doom9.org/showthread.php?p=1639017#post1639017

[jpsdr]

No, because i didn't know this one. Will try/test and eventualy update to use it, it seems not too much work, and tp7 (thanks) even provided a very quick easy code to implement !
Bloax : I don't know who your message is for, but NNEDI3 already supported RGB24 input.

[jpsdr]

Updated version of NNEDI3 v0.9.4, so now version is v0.9.4.3.
Add fturn support.
While i haven't discovered why YV16 is so slow, i suggest still using YUY2. Of course, anyone who want to help is welcomed ! :D
For those interested in testing :
Sources are here (https://github.com/jpsdr/NNEDI3).
Binaries are here (https://github.com/jpsdr/NNEDI3/releases/download/v0.9.4.3/NNEDI3_v0_9_4_3.7z).

[Sparktank]

Updated version of NNEDI3 v0.9.4.
Add Y8, YV16 and YV24 support.

Updated version of NNEDI3 v0.9.4.
Add fturn support.

Are these two different from each other? or is the latter an update of the former?
Is the update so small why there wasn't a change in the version number? :confused:

I've ported NNEDI3 v0.9.4 to x64.

Updated version (Add Y8, YV16 and YV24) of my ported NNEDI3. More here (http://forum.doom9.org/showthread.php?p=1661944#post1661944).

EDIT :
Another updated version (add fturn support). More here (http://forum.doom9.org/showthread.php?p=1662012#post1662012).

It's getting really confusing. :confused:
You should have your own thread with details.

[jpsdr]

If you look at the links, you'll have your answer.
But i agree my posts may be a little confused, i'll change them.

[ajp_anton]

In masktools, could you add:
- "swap" and "dup" operators.
- Real-time calculation instead of LUTs. Less memory used if multiple input clips (maybe increase to >3), and IIRC also faster for very simple expressions.

[TurboPascal7]

Expr filter with runtime calculation is planned when avs+ gets 16-bit support.
I will not add those operators to regular luts for now. And I don't plan to increase maximum number of input clips.

[TurboPascal7]

It's been a while. :) Two updates today.
New version of RgTools (https://github.com/AviSynth/RgTools/releases/tag/0.92). Planar parameter added, for compatibility with qtgmc. Thanks to Reel.Deel and torchlight for reporting.
New version of MedianBlur2 (https://github.com/AviSynth/MedianBlur2/releases/tag/0.94). MedianBlurTemporal fixed - it used to produce somewhat broken results around the beginning and end of the clip. Issue reported by real.finder here (http://forum.doom9.org/showpost.php?p=1661907&postcount=76) is also fixed.

Also, this is probably the last version of MedianBlur2 compatible with Avisynth 2.6, unless some very critical bug is found. Starting with the next version Vinverse, TMaskCleaner, SangNom2, MSharpen, MedianBlur2 and at some point later masktools2 will only be compatible with newer versions of Avisynth+ (with MT). TColorMask will lose internal threading. All other plugins should not be affected.

[no1d]

New version of RgTools (https://github.com/AviSynth/RgTools/releases/tag/0.92).

It seems you forgot to change AvisynthPluginInit3.

[TurboPascal7]

It seems you forgot to change AvisynthPluginInit3.
Yeah, thanks. It still works here though.

[jpsdr]

TColorMask will lose internal threading.
Is it possible to keep it, and check if a prefetch function with more than 1 thread is used, and disabling it (or fixing the number of internal thread to 1) only in this case ?

[TurboPascal7]

Is it possible to keep it, and check if a prefetch function with more than 1 thread is used, and disabling it only in this case ?
It kinda is but I won't bother.

[TurboPascal7]

Okay, here are some test versions. They're even more test than usually. Avisynth+ API is not really stable yet so all these plugins can break without any special notice. They also can format your harddrive and kill your cat if you aren't careful. I do hope nothing like this happens of course but use it on your own risk.

Masktool2 (https://dl.dropboxusercontent.com/u/54253260/avs/mt/masktools2%2B.dll) - doesn't require avs+, probably works better than regular versions with SEt's MT.
MedianBlur2 (https://dl.dropboxusercontent.com/u/54253260/avs/mt/MedianBlur2%2B.dll) - requires avs+.
MSharpen (https://dl.dropboxusercontent.com/u/54253260/avs/mt/msharpen%2B.dll) - requires avs+.
SangNom2 (https://dl.dropboxusercontent.com/u/54253260/avs/mt/SangNom2%2B.dll) - requires avs+, internal threading removed. Will be insanely slow without MT enabled.
TColorMask (https://dl.dropboxusercontent.com/u/54253260/avs/mt/tcolormask%2B.dll) - doesn't require avs+, internal threading disabled by default. You can enable it back by setting mt=true.
TMaskCleaner (https://dl.dropboxusercontent.com/u/54253260/avs/mt/tmaskcleaner%2B.dll) - requires avs+.
Vinverse (https://dl.dropboxusercontent.com/u/54253260/avs/mt/vinverse%2B.dll) - requires avs+.

All filters register themselves with avs+ MT as NICE filters (mt mode 1), you don't need to do anything special for that. All filters have the + postfix in the filename to distinguish them from stable versions. All plugins are x86 only, you can build it yourself (avs-mt branch on github in all repos) if you want x64. For that you need to define AVISYNTH_SDK_PATH environment variable and point it to avs+ SDK directory (with include folder inside). Be sure to use the latest avs+ headers.

Again: use only for testing.

[jpsdr]

It kinda is but I won't bother.

Or add at the end of the parameters a new parameter to enable/disable internal MT if this parameter doesn't exist in the first place, like this, you don't break compatibility with existing scripts.

[TurboPascal7]

Or add at the end of the parameters a new parameter to enable/disable internal MT if this parameter doesn't exist in the first place, like this, you don't break compatibility with existing scripts.
That's what I did in tmaskcleaner. With sangnom2 it'll be a bit harder. Two conditions for internal threading to be kept:
1) More important: avs+ MT fails, i.e. most users (including myself) continue to run scripts singlethreaded.
2) Less important: avs+ internal thread pool API accepts lambda expressions. I'm not a C++ expert so I'm not sure it's possible/reasonably easy to do this while keeping compatibility with C++98.

Otherwise: no, it's very unlikely I'll bother.

[tormento]

Is it possible to implement the Quantile function of RemoveGrainHD?

SMDegrain can't work without it.

Thanks!

[TurboPascal7]

Is it possible to implement the Quantile function of RemoveGrainHD?
RemoveGrainHD is a separate plugin that I didn't touch yet at all. Maybe one day...

[tormento]

Quantile just works the same as MedianBlur, unless you really need to use "planar" parameter.

How would you rewrite the following:

function MinBlur(clip clp, int "r", int "uv", bool "planar"){

r = default(r,1)
uv = default(uv,3)
planar = default(planar,false)

uv2 = (uv==2) ? 1 : uv
rg4 = (uv==3) ? 4 : -1
rg11 = (uv==3) ? 11 : -1
rg20 = (uv==3) ? 20 : -1
uvm2 = r==2 ? (uv==3?2:uv==2?0:-1) : nop()
uvm3 = r==3 ? (uv==3?3:uv==2?0:-1) : nop()

RG11D = (r==0) ? mt_makediff(clp,clp.sbr(),U=uv2,V=uv2)
\ : (r==1) ? mt_makediff(clp,clp.removegrain(11,rg11,planar=planar),U=uv2,V=uv2)
\ : (r==2) ? mt_makediff(clp,clp.removegrain(11,rg11,planar=planar).removegrain(20,rg20,planar=planar),U=uv2,V=uv2)
\ : mt_makediff(clp,clp.removegrain(11,rg11,planar=planar).removegrain(20,rg20,planar=planar).removegrain(20,rg20,planar=planar),U=uv2,V=uv2)
RG4D = (r<=1) ? mt_makediff(clp,clp.removegrain(4,rg4,planar=planar),U=uv2,V=uv2)
\ : (r==2) ? mt_makediff(clp,clp.Quantile(radius_y=2, radius_u=uvm2, radius_v=uvm2 ,planar=planar), U=uv2,V=uv2)
\ : mt_makediff(clp,clp.Quantile(radius_y=3, radius_u=uvm3, radius_v=uvm3, planar=planar), U=uv2,V=uv2)
DD = mt_lutxy(RG11D,RG4D,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?",U=uv2,V=uv2)
clp.mt_makediff(DD,U=uv,V=uv) }

[tormento]

RemoveGrainHD is a separate plugin that I didn't touch yet at all. Maybe one day...
Yes, please... :D

[tormento]

I remind you that it won't work for YUY2 source when r>=2 for obvious reason. Otherwise everything should work as expected.
I'll try that.

Thank you.

[TurboPascal7]

Okay, I took a look at RemoveGrainHD and the code is just as horrible as one could expect from Kassandro. Don't think I'll be touching that very soon.
Still, an important question: what are the most common uses of the filters this package? I highly doubt I'll be ever "porting" all of it so I'd like to know what is actually useful and what's not. I don't use the plugin myself so I need your help on this one.

[tormento]

Still, an important question: what are the most common uses of the filters this package?
Get a look at SMDegrain on Doom10, however AFAIK the quantile part.

[cretindesalpes]

You can replace Quantile used in the modified MinBlur function by any 5x5 and 7x7 spatial median filter.

[tormento]

You can replace Quantile used in the modified MinBlur function by any 5x5 and 7x7 spatial median filter.

Such as?

You know I am an evergreen newbie ;)

[cretindesalpes]

medianblur for example.

[tormento]

\ : (r==2) ? mt_makediff(clp,clp.MedianBlur(2,2*medf,2*medf), U=uv2,V=uv2)
\ : mt_makediff(clp,clp.MedianBlur(3,3*medf,3*medf), U=uv2,V=uv2)
Tried: medf is not defined.

[tormento]

That's bacause you only copy-pasted these two lines, and did not compare the entire function to see there is any other difference.
You are right. :o

[mawen1250]

A small problem in MedianBlur2 0.94:
When setting -255 for radius, the plane is set to 0 instead of 255.

[TurboPascal7]

Okay, due to popular demand of exactly zero people, new test version of SangNom2 (https://dl.dropboxusercontent.com/u/54253260/avs/mt/SangNom2%2B.dll).
Unlike the previous one, this version will use internal threading when frame-level threading in avs+ is disabled (no prefetch(x) call). In this aspect it should be same or a bit more efficient than the stable version. As usual, avs+ is required.
If nothing bad happens, this will become the next "stable" version.

A small problem in MedianBlur2 0.94:
When setting -255 for radius, the plane is set to 0 instead of 255.
Will be fixed in the next build (whenever that happens). Thanks for the report.

[tormento]

Okay, due to popular demand of exactly zero people, new test version of SangNom2 (https://dl.dropboxusercontent.com/u/54253260/avs/mt/SangNom2%2B.dll).
Quantile is still waiting you ;)

[TurboPascal7]

Quantile is still waiting you ;)
As multiple people already told you, it's possible to replace it with MedianBlur in most cases. I won't touch it.

[jpsdr]

Okay, due to popular demand of exactly zero people, new test version of SangNom2 (https://dl.dropboxusercontent.com/u/54253260/avs/mt/SangNom2%2B.dll).
Unlike the previous one, this version will use internal threading when frame-level threading in avs+ is disabled (no prefetch(x) call).
Is it possible to have a link to the source ?
I only want to see how it's done to check if frame-level threading is enabled or not.

Thanks.

[TurboPascal7]

Is it possible to have a link to the source ?
I only want to see how it's done to check if frame-level threading is enabled or not.

Thanks.
Source code is always linked on the first page. Here's a link (https://github.com/AviSynth/SangNom2/tree/avs-mt) to the branch.

[ultim]

Source code is always linked on the first page. Here's a link (https://github.com/AviSynth/SangNom2/tree/avs-mt) to the branch.

The API will only be frozen when AviSynth+MT is released as stable. Publishing plugins that use anything from IScriptEnvironment2 earlier than that is at your user's risk if it breaks.

[mark0077]

What has to happen for plugins like SVP to work with avisynth+. Do the SVP developers explicitly add support? Do you think it would increase performance for a plugin like svp

[TurboPascal7]

Okay, here's something a bit more fun for you to play.

CLExpr (https://github.com/tp7/CLExpr) filter - avs expr filter, implemented in OpenCL.
Provided interface is almost identical to that of masktools2. Functions are called cl_expr, cl_exprxy and cl_exprxyz (try to guess which masktools functions they map to). In theory, you can use all expressions and functions that worked with masktools. Offx/offy/w/h parameters aren't implemented - if people are interested in those, I could add them of course.

16-bit support is provided with the common lsb parameter. Set it to true to process stacked 16-bit clips.

This plugin is highly experimental and could easily kill your GPU driver like it's the most natural thing to do. Drivers usually can restart themselves but I warned you.

There's very little point in threading this plugin.

Why expr?
For most common uses on 8-bit clips this filter will be slower than masktools (especially the b branch in this thread). Unless you have a very good video card/motherboard and a very bad CPU. On-board GPUs might probably provide a bit better performance, I never tried. Dunno about performance on CPU either, right now it searches only for GPU devices.
But you can process 16-bit clips with it, which you obviously can't with mt_lutxy and mt_lutxyz.

Performance is mostly limited by memory transfer and hardly depends on complexity of the expression you pass to it. For example on my system cl_expr("x log log log log log",u=3,v=3) has the same performance as cl_expr("x 1 +",u=3,v=3). No dup/swap functions provided.

Why OpenCL?
Two reasons:
1. It was very fun.
2. It's a lot easier to implement with OpenCL than with regular C/C++ (vsynth). Basically it works by calling mt_infix() on the expression and feeding that to OpenCL compilation engine. Done.

That said, my experience with OpenCL is limited to ~10 hours, so I'm probably doing something very dumb in there. Please feel free to tell me how to improve memory transfer rates, device detection etc.

Binary
Here (https://dl.dropboxusercontent.com/u/54253260/avs/test/CLExpr.dll). Only x86 version for now, but it works on x64 without problems.

EDIT: reuploaded the binary because NVIDIA apparently doesn't like long/ulong types and e.g. (ulong)(round(3.0f)) is suddenly equal to zero, while (uint)(round(3.0f)) is 3.

[Mystery Keeper]

Drivers usually can restart themselves but I warned you.Only after Windows 7. On XP overloaded (caught in eternal loop, for example) video driver will cause major hanging.

[Rumbah]

EDIT: reuploaded the binary because NVIDIA apparently doesn't like long/ulong types and e.g. (ulong)(round(3.0f)) is suddenly equal to zero, while (uint)(round(3.0f)) is 3.

Yeah, if I remember correctly rounding in a shader does not have to mean rounding to the next integer. It's something that the hardware can decide. I remember problems because a nvidia card always rounded to the next even integer.

[SEt]

TurboPascal7, I haven't looked at code or filter at all, but maybe instead of (uint)(round(3.0f)) you actually wanted something like convert_uchar_sat_rte(3.0f) ?

[TurboPascal7]

TurboPascal7, I haven't looked at code or filter at all, but maybe instead of (uint)(round(3.0f)) you actually wanted something like convert_uchar_sat_rte(3.0f) ?
Yeah that would work (except uint instead of uchar). I ended up using size_t and ptrdiff_t though and they work but don't provide the manual convert functions.

[SEt]

It should work with uint, ulong or any other standard OpenCL type, even vector ones.
As for converting floating point value to size_t... is a very strange operation. Also, I think they "work" because they are actually "uint" for 32-bit code and the bug you encountered was converting to ulong.

[TurboPascal7]

It should work with uint, ulong or any other standard OpenCL type, even vector ones.
As for converting floating point value to size_t... is a very strange operation. Also, I think they "work" because they are actually "uint" for 32-bit code and the bug you encountered was converting to ulong.
Yeah of course it should work, it just doesn't. I blame NVIDIA for that. Never tried it on AMD cards.

And yes, size_t most likely works because it's uint, I never actually checked the behaviour. I will probably change it to uint later because getting values outside of uint range on any stage of expression calculation is almost impossible in real world.

Converting is required for doing stuff like bitshifts and other binary operations supported by masktools.

[SEt]

In terms of correctness I recommend testing also against CPU implementations, especially Intel one as something totally different. Not just to get peace of the mind that it is NV bug, but because different implementations forgive some deviations from the standard that you might be used to after some time coding for specific implementation and don't even notice (like mixing pointers to different memory types on NV or unaligned shared memory access on AMD).

[DeathAngelBR]

I'm getting this error with x86 masktools2.dll and avs+ installed.

http://i.imgur.com/7qpU021.png

LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\removegrain\RemoveGrainSSE2.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\removegrain\RepairSSE2.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\removegrain\RSharpenSSE2.dll")
#LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\mt_masktools-26.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\masktools2.dll")
#LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\mvtools2.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\AddGrainC.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\dither.dll")
Import("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\dither.avs")

LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\LSMASHSource.dll")

src = "I:\BDMV Symphogear G Vol. 1\BDMV\STREAM\00003.m2ts"
src2 = "I:\BDMV Symphogear G Vol. 1\BDMV\STREAM\00009.m2ts"

video_ep01 = LWLibavVideoSource(src,cache=true)
video_ep02preview = LWLibavVideoSource(src2,cache=true)

video_ep01 ++ video_ep02preview

#super = MSuper(pel=2, sharp=1)
#backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
#forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
#MDegrain1(super, backward_vec1,forward_vec1,thSAD=64)
#dither_convert_8_to_16().dither_resize16(1280,720,kernel="spline64").smoothgrad().gradfun3(lsb_in=true,lsb=true,smode=2,mask=3).dither_out()

[TurboPascal7]

Try loading it with some other program maybe? It's a bit hard to extract much useful info from that error message.

[DeathAngelBR]

Try loading it with some other program maybe? It's a bit hard to extract much useful info from that error message.

Same error (messed up symbols) with megui.

avs4x264mod CLI also crashes.

"avs4x264mod.exe" --seek-mode safe --x264-binary "x264tMod10bit.exe" --preset veryslow --tune animation --crf 13.0 --deblock -1:-1
--keyint 240 --qcomp 0.8 --fade-compensate 0.8 --aq-mode 3 --aq-strength 0.85 --merange 16 --psy-rd 0.60:0.00 --no-dct-decimate
--no-fast-pskip --colorprim bt709 --transfer bt709 --colormatrix bt709 --fps 24000/1001 --force-cfr --input-res 1280x720 --frames 35030
--input-depth 16 --opts 3 --output "E:\SYMPHOGEAR\Symphogear G EP01 video tmod.264" "SymphogearG01.avs"

[TurboPascal7]

Well, I'm no wizard. If you have the appropriate runtime installed (if you installed avs+ using the installer) there's no reason why it shouldn't work for you.

[DeathAngelBR]

Well, I'm no wizard. If you have the appropriate runtime installed (if you installed avs+ using the installer) there's no reason why it shouldn't work for you.

I *might* have ruled out what's causing it.

Commenting the removegrain dll lines makes the error go away.

Does avs+ have built-in multithreading? avstp.dll also causes that error.

VirtualDub 1.10.4 is also crashing with avs+:

An out-of-bounds memory access (access violation) occurred in module 'kernel32'...
...writing address 0AB749B4.

RgTools.dll = same error as with removegrain dlls.

[cretindesalpes]

avstp.dll also causes that error.
avstp.dll is not a plug-in and must not be loaded with LoadPlugin().

[Lenchik]

Put it in the usual AviSynth 2.5\plugins\ directory, or load it manually with LoadPlugin("path\avstp.dll") in your script.
Put it in the usual AviSynth 2.5\plugins\ directory, or load it manually with LoadPlugin("path\avstp.dll") in your script.
Update manuals maybe?

[cretindesalpes]

Uh no just discard my previous message, I was completely absent-minded… Yes, you can load it with LoadPlugin().

[aldix]

Sorry if that's the wrong spot, but how to set the threads in a script with tfm().tdecimate()?

I put just SetFilterMTMode("DGDecode_mpeg2source", 3) at front & Prefetch(4) in the end and it locked in at 3+GB RAM.

What must I do?

[turbojet]

Prefetch(4) defines 4 threads, if you have the avsi that set's filtermode then you are using 4 threads with tfm().tdecimate() otherwise you'll have to setfiltermtmode.

If this is all that's in your script, in my limited tests it's slower and uses more cpu with mt then without unfortunately. TFM is suspected.

[aldix]

Here's the relevant script snippet:


SetFilterMTMode("DGDecode_mpeg2source", 3)
MPEG2Source("c:\users\admin\desktop\stuff.d2v")

tfm().tdecimate().colormatrix()

Crop(0, 6, -0, -0)

# denoise

# sharpen

# resize

Prefetch(4)


What am I doing wrong here? Source is TS made indexed with DGSource.

AvspMod (the version allowed for Avisynth+ MT) hangs at ~4GB memory and program shuts down with "run out of memory" error.

x264 encoding (with Mulder's GUI) stops with "potential deadlock". Doesn't even start.

[Evil_Burrito]

This could be a bug or I could be doing something wrong.

When I use the test test version of masktools2+ with the maa2 script (v0.41), the encoded output (tried x264, utvideo, and magicyuv) has white over the anti-aliased areas. The white doesn't appear when using the test version with avspmod or when I encode using the pre-release version from the first post.

[bxyhxyh]

When I use Film Restore package by videoFred, there appears "Clense doesn't have a named argument cache" error.
Can you implement it for compatibility?

[TurboPascal7]

When I use Film Restore package by videoFred, there appears "Clense doesn't have a named argument cache" error.
Can you implement it for compatibility?

You can try creating a wrapper function that would have all parameters like clense plus the "cache" parameter, which would be simply ignored. I'm not interested in adding a useless parameter to the plugin.

[GMJCZP]

I thank you deeply for your crusade, TurboPascal7.

I don't know if this is the correct thread to ask other plugins updates. Otherwise, if you could tell me how to do. :)

[DARKAN]

Help! I checkmate plugin fails to boot. Gives an error:
http://i58.fastpic.ru/big/2015/0326/7d/16ce8fe6310a7d1b4429fc06f3b15c7d.png
In the script prescribed this command:
checkmate(100).DFMDeRainbow(maskthresh=3,mask=false, interlaced=false)
Resetting the system did not help. Using Windows 7 Enterprise x64. Probably the thing in a processor that I use. I have a processor AMD, in others, who say that they have the plug-worth processor Intel.
This plugin checkmate x86 from this topic does not work, but the plugin works checkmate here (http://forum.doom9.org/showpost.php?p=1571520&postcount=20).

[TurboPascal7]

It appears I accidentally used SSE4.1 there while checking only for SSE2. The offending intrinsic is _mm_min_epu16. If anybody is willing to verify that it's save to replace it with _mm_min_epi16 or keep SSE2 compatibility in some other way it'd be nice.

Until then - yeah, some older AMD CPUs are out of luck.

EDIT: innocenat just built a version with replaced intrinsics (https://dl.dropboxusercontent.com/u/54253260/avs/checkmate.dll), if it works properly for you I'll add it to github releases.

[DARKAN]

innocenat just built a version with replaced intrinsics (https://dl.dropboxusercontent.com/u/54253260/avs/checkmate.dll), if it works properly for you I'll add it to github releases.
Yes, it works. I have a processor AMD A6-3650 APU with Radeon (tm) HD Graphics (~ 2593). Thank you! :)

[DeathAngelBR]

Well, I'm no wizard. If you have the appropriate runtime installed (if you installed avs+ using the installer) there's no reason why it shouldn't work for you.

Ok this is odd...

I gave rgtools another try - uninstalled/reinstalled visual studio and avisynth -, but it still refused to work... until I moved it to the autoload plugin (default) folder. Any reason it won't load from, let's say, avisynth\plugins\extrasorwhatever\ folder?

[TurboPascal7]

No it should load (manually with LoadPlugin, of course) just fine from any folder whatsoever - in fact for debugging purposes I usually loaded libraries from some obscure debug folders. Does it show an error or anything?

[DeathAngelBR]

No it should load (manually with LoadPlugin, of course) just fine from any folder whatsoever - in fact for debugging purposes I usually loaded libraries from some obscure debug folders. Does it show an error or anything?

Yea, it's that one >>>> http://forum.doom9.org/showthread.php?p=1673689#post1673689

I guess I should format considering I can't encode anything 720p/1080p without random crashes and reboots.

[Wilbert]

I'm trying the updated MaskTools (link: http://github.com/tp7/masktools/releases/download/b1/masktools2-25-x86.zip). The script


(...)
mt_xxpand() # or mt_expand()


results in 'there is no function named mt_xxpand' (or mt_expand). Is it still available or is it called differently?

[Groucho2004]

I'm trying the updated MaskTools (link: http://github.com/tp7/masktools/releases/download/b1/masktools2-25-x86.zip). The script


(...)
mt_xxpand() # or mt_expand()


results in 'there is no function named mt_xxpand' (or mt_expand). Is it still available or is it called differently?
This may not be related to your problem but why are you using the 2.5.8 version? There is a version for 2.6.

Do you have the correct MS runtimes installed (msv*110.dll)?

[Reel.Deel]

mt_expand() / mt_inpand() work for me, mt_xxpand does not exist. I tried the 2.5 version just to make sure but I'm also wondering the same thing as Groucho2004.

[Groucho2004]

mt_expand() / mt_inpand() work for me, mt_xxpand does not exist. I tried the 2.5 version just to make sure but I'm also wondering the same thing as Groucho2004.
mt_expand also works for me, "mt_xxpand_multi.avsi" is part of the Dither package. Not sure if Wilbert was referring to that.

[Wilbert]

I posted the wrong link ;( I'm using this one: http://github.com/tp7/masktools/releases/download/b1/masktools2-x86.zip. But you are right i needed to install the runtimes libs for 2012. It works now thanks.

[StainlessS]

mt_expand(u=3,v=3) works for me using Wilbert 2nd link (avs v2.6 official, v2.58 will not see v2.6 dll).

EDIT: Oh good, you got it working :)

[jpsdr]

Ported version of AutoYUY2, based on neuron2's pluggin, updated to API v2.6 and x64 version, so, not working with avisynth 2.5.8.
Sources are here (https://github.com/jpsdr/AutoYUY2).
Binaries are here (https://github.com/jpsdr/AutoYUY2/releases/download/20150902/AutoYUY2_20150902.7z).

New version, with YV16 ouput support.

EDIT : Corretion of a typo/bug.

[jpsdr]

Ported version of AutoYUY2, based on neuron2's pluggin, updated to API v2.6 and x64 version, so, not working with avisynth 2.5.8.
Sources are here (https://github.com/jpsdr/AutoYUY2).
Binaries are here (https://github.com/jpsdr/AutoYUY2/releases/download/20150905/AutoYUY2_20150905.7z).

New version.

[jpsdr]

Ported version of AutoYUY2, based on neuron2's pluggin, updated to API v2.6 and x64 version, so, not working with avisynth 2.5.8.
Sources are here (https://github.com/jpsdr/AutoYUY2).
Binaries are here (https://github.com/jpsdr/AutoYUY2/releases/download/20160607/AutoYUY2_20160607.7z).

New version, add multi-threading.

[jpsdr]

Ported version of AutoYUY2, based on neuron2's pluggin, updated to API v2.6 and x64 version, so, not working with avisynth 2.5.8.
Sources are here (https://github.com/jpsdr/AutoYUY2).
Binaries are here (https://github.com/jpsdr/AutoYUY2/releases/download/20160608/AutoYUY2_20160608.7z).

New version, some fixes.

[pinterf]

RgTools v0.93 released (x86/x64)

https://github.com/pinterf/RgTools/releases/tag/0.93


Same functionality as 0.92.1
New bit depths 10, 12, 14, 16 bits and 32 bit float
New formats: Planar RGB, Planar RGBA and YUVA support
Use aligned loads if possible, internally
10+ bit formats require SSE4 for fast processing
XP Support
Built with VS2015, requires Visual Studio Redistributable
Update 3 or newer
Of course it works with classic Avisynth for 8 bit videos.


todo: AVX2

Big thanks to tp7 for the nice code.

[tormento]

RgTools v0.93 released (x86/x64)
:thanks:
MaskTools is the next I hope :)

[real.finder]

RgTools v0.93 released (x86/x64)


just tried with complex script

I get CRASH

Fault Module Name: RgTools.dll
Fault Module Version: 0.93.0.0
Fault Module Timestamp: 583a9af0
Exception Code: c0000005
Exception Offset: 000300d3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


0.92.1 work fine

and about todo, there are others mode of RemoveGrain (more than 24), there are some scripts use them, and there are RemoveGrainHD and RemoveGrainT too, or it's hard to add them as tp7 said?

[burfadel]

just tried with complex script

I get CRASH

Fault Module Name: RgTools.dll
Fault Module Version: 0.93.0.0
Fault Module Timestamp: 583a9af0
Exception Code: c0000005
Exception Offset: 000300d3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


0.92.1 work fine

and about todo, there are others mode of RemoveGrain (more than 24), there are some scripts use them, and there are RemoveGrainHD and RemoveGrainT too, or it's hard to add them as tp7 said?

What CPU and OS are you using?

[pinterf]

Do you know, which filter/mode/frame dimensions were you using?

[real.finder]

What CPU and OS are you using?

i7 X 980 with windows server 2008 r2

[real.finder]

Do you know, which filter/mode/frame dimensions were you using?

I will try make a simple sample then, but not now, few hrs later maybe

[pinterf]

I will try make a simple sample then, but not now, few hrs later maybe
And I wonder that you are using unaligned crop or something that can result in unaligned (non-mod16) frames somewhere?

[real.finder]

And I wonder that you are using unaligned crop

yes, that is, with align=true in crop it work fine, but why the old RGtools was fine then?

and you didn't say something about

and about todo, there are others mode of RemoveGrain (more than 24), there are some scripts use them, and there are RemoveGrainHD and RemoveGrainT too, or it's hard to add them as tp7 said?

[pinterf]

RgTools 0.92 used only unaligned loads in RemoveGrain, thus did not check for it. My version uses aligned loads (six unaligned, three aligned one in a 3x3 pixel block). I wanted to get nearer to the speed of tp7's version with my VS2015 build (but could not reach it, 32 bit dll is a bit slower but 64 bit DLL is faster on my machine i7-3770).

#mode x86 (0.93/0.92) x64 (0.93/0.92)
#mode=2 32.7 37.1 40.3 39.2
#mode=4 32.7 36.6 43.3 41.0
#mode=12 74.0 73.7 79.2 78.1
#mode=19 79.5 82.7 84.6 85.1
#mode=20 33.7 34.6 37.8 37.1
#mode=21 35.5 43.1 46.8 43.4


In Clense for example there is an explicite check against this:
if (!is_16byte_aligned(pSrc) || !is_16byte_aligned(pRef1) || !is_16byte_aligned(pRef2)) {
env->ThrowError("Invalid memory alignment. Used unaligned crop?"); //omg I feel so dumb
}
But I forgot to apply this check into RemoveGrain.
(One note: unaligned crop may seem to be fast, but would result in speed loss in the next filter because that filter is ordered to use slow C path)

I had a look at the source code of modes 25-30, well, it would take time to reverse engineer the assembly code, and I'm not surprised that tp7 did not update rgtools.

[Reel.Deel]

I had a look at the source code of modes 25-30, well, it would take time to reverse engineer the assembly code, and I'm not surprised that tp7 did not update rgtools.

Considering the original author never documented these modes, I doubt anyone uses them.

On a side note, RgTools is based on RemoveGrain v1.0 which means that Clense is missing the reduceflicker parameter which breaks compatibility with some scripts that used the more popular RemoveGrain v0.9. Colours provided me with a script workaround but it's slower than the plugin and can only be used once per script. If it's not too difficult can you please add the reduceflicker parameter to Clense?

Edit: RgTools' Clense is also missing parameters that were added in RemoveGrain V1.0, see here: http://videoprocessing.fr.yuku.com/reply/638/Can-use-quantile-like-vertical-median-filter#reply-638

LoadPlugin("D:\RemoveGrainSSE2.dll")
LoadPlugin("D:\RemoveGrainTSSE2.dll")

blankclip( pixel_type = "YV12" )

clense( reduceflicker = false )

==> " clense does not have a named argument 'reduceflicker' "


Per default, clense always uses *not* the original previous frame, but the already clense'd previous frame (recursive operation). This kind of operation is

a) not a "true" temporal median

b) perfectly un-suited for e.g. MVTools-scripts, Interleave/SelectEvery solutions, etc.

With all the older RemoveGrain versions, the recursive operation could be simply switched off with "reduceflicker=false".

In the actual v1.0, this parameter does not exist anymore. Instead, you're faced with "previous/next" clip parameters (easy), with "recursion slots" (harder), and whatnotelse.



RemoveGrain-1.0.rar SSE3 works fine with the spline36 version of LSF here :)

Yeah, but it breaks compatibility with most (if not all) scripts that make use of the temporal filters (clense, temporalrepair). For these you need the new package RemoveGrainT. But then, it still breaks those scripts, because the framework of those filters was changed majorly.

That's the reason why I don't blindly recommend the actual RemoveGrain v1.0 package. If you tell "that's the version to use", then lots of older scripts will not work anymore.

[pinterf]

Considering the original author never documented these modes, I doubt anyone uses them.

On a side note, RgTools is based on RemoveGrain v1.0 which means that Clense is missing the reduceflicker parameter which breaks compatibility with some scripts that used the more popular RemoveGrain v0.9. Colours provided me with a script workaround but it's slower than the plugin and can only be used once per script. If it's not too difficult can you please add the reduceflicker parameter to Clense?

Edit: RgTools' Clense is also missing parameters that were added in RemoveGrain V1.0, see here: http://videoprocessing.fr.yuku.com/reply/638/Can-use-quantile-like-vertical-median-filter#reply-638

Clense is working 'recursively' if it can do, that is, one of the input clips of the Nth clense session is retrieved from the previous (N-1)th clensed frame. This frame (named lframe) and the frame number (name lnr) is saved internally in the class after each Clense. Why? Because it can only work properly, if Clense is getting the frame requests strictly sequentally.
If this condition does not get fulfilled it falls back to getting the (N-1)th child frame, the same behaviour as with reduceflicker=false.

Clense checks if lnr==n-1 (where lnr the last clensed frame number, that the class processed; n is the currently requested frame number in GetFrame()). Thus when Clense gets its request out of order, reduceflicker is ineffective.

So I suppose Clense can hardly work multithreaded properly when reduceflicker==true. And even if the filter is set to "serialized" in MT mode, nothing ensures that it gets the requests in a linear way.

So I can probably add the parameter but cannot ensure that is works. Or I can add 'reduceflicker' just for compatibility (like tp7 added 'planar') and won't use.

[real.finder]

Considering the original author never documented these modes, I doubt anyone uses them.


softsharp (web.archive.org/web/20160608111758/http://leon1789.perso.sfr.fr/avisynth/SoftSharpen-8.8.zip) for instance use 27

here 26 and 27 http://videoprocessing.fr.yuku.com/sreply/143/RemoveGrain-10-prerelease#.WIj5HGX-vIU

[real.finder]

RgTools 0.92 used only unaligned loads in RemoveGrain, thus did not check for it. My version uses aligned loads (six unaligned, three aligned one in a 3x3 pixel block). I wanted to get nearer to the speed of tp7's version with my VS2015 build (but could not reach it, 32 bit dll is a bit slower but 64 bit DLL is faster on my machine i7-3770).

#mode x86 (0.93/0.92) x64 (0.93/0.92)
#mode=2 32.7 37.1 40.3 39.2
#mode=4 32.7 36.6 43.3 41.0
#mode=12 74.0 73.7 79.2 78.1
#mode=19 79.5 82.7 84.6 85.1
#mode=20 33.7 34.6 37.8 37.1
#mode=21 35.5 43.1 46.8 43.4



tp7 was using vs2012, that mean new c++ is slower? he say that x64 can be slower in IRC back then, so what about build x86 with 2012 or 2010 for speed and x64 with 2015?

[DJATOM]

Guess I found a bug in Average. Look at this comparison: http://screenshotcomparison.com/comparison/198383. It seems Average produce lower values than RAverageW.
After some investigation I found that problem is here: http://i.imgur.com/VhmTOVN.png
Can someone fix it?

[real.finder]

about reduceflicker, it's in 0.9 or 1.0pre? http://videoprocessing.fr.yuku.com/reply/40/RemoveGrain-10-prerelease#reply-40

I think it's the "Beta" release | Recommended here http://avisynth.nl/index.php/RemoveGrain

[real.finder]

Guess I found a bug in Average. Look at this comparison: http://screenshotcomparison.com/comparison/198383. It seems Average produce lower values than RAverageW.
After some investigation I found that problem is here: http://i.imgur.com/VhmTOVN.png
Can someone fix it?

it's same in old Average too? http://avisynth.nl/index.php/Average#Average_for_AviSynth_2.5

[DJATOM]

it's same in old Average too? http://avisynth.nl/index.php/Average#Average_for_AviSynth_2.5
http://diff.pics/RL4g7UYPkxYl/1

[pinterf]

tp7 was using vs2012, that mean new c++ is slower? he say that x64 can be slower in IRC back then, so what about build x86 with 2012 or 2010 for speed and x64 with 2015?
I can try it.
But I suspect Intel, in the vcproj (https://github.com/tp7/RgTools/blob/master/RgTools/RgTools.vcxproj) file this setting was active: <PlatformToolset> Intel C++ Compiler XE 14.0

I spent a whole day with optimizing and understanding why mode 21 is that much slower. Tried VS2017RC but it is not better. Intel must handle XMM register usage and command reordering brilliantly. RemoveGrain mode21 - that has the largest difference on x86 - wants to use just one more XMM register (of the 8) that is available on x86, I think Intel can solve it w/o using extra memory access. I really wonder what code did it generate. But for x64, there are twice as much XMM registers, and the code is much faster indeed.

[pinterf]

Guess I found a bug in Average. Look at this comparison: http://screenshotcomparison.com/comparison/198383. It seems Average produce lower values than RAverageW.
After some investigation I found that problem is here: http://i.imgur.com/VhmTOVN.png
Can someone fix it?
What's wrong with that section? (I was planning porting Average for high bitdepth, it is not a difficult filter)

[DJATOM]

What's wrong with that section? (I was planning porting Average for high bitdepth, it is not a difficult filter)

First I tried to modify plugin's code to use "weighted_average_c". It works fine.
Next I tried to use "weighted_average_sse2" for processing. Result is identical to RAverageW, fine.
Next I commented
for (int i = 0; i < frames_count-1; i+=2) {
__m128i src = _mm_loadl_epi64(reinterpret_cast<const __m128i*>(src_pointers[i]+x));
__m128i src2 = _mm_loadl_epi64(reinterpret_cast<const __m128i*>(src_pointers[i+1]+x));
__m128i weight = _mm_set1_epi32(*reinterpret_cast<int*>(int_weights + i));

src = _mm_unpacklo_epi8(src, zero);
src2 = _mm_unpacklo_epi8(src2, zero);
__m128i src_lo = _mm_unpacklo_epi16(src, src2);
__m128i src_hi = _mm_unpackhi_epi16(src, src2);

__m128i weighted_lo = _mm_madd_epi16(src_lo, weight);
__m128i weighted_hi = _mm_madd_epi16(src_hi, weight);

acc_lo = _mm_add_epi32(acc_lo, weighted_lo);
acc_hi = _mm_add_epi32(acc_hi, weighted_hi);
}
in the "weighted_average_int_sse2" and got green frames. So I assume the pointed section is a culprit since it actually does some processing in my case. If it isn't, okay, but problem is still remain.
I decided to live with "weighted_average_sse2" for now, since it works for me, but isn't it better to have that bug fixed? ;)

[pinterf]

What weights were you using and how many frames? Maybe there is difference in rounding

[DJATOM]

Average(resize1(x,y), 0.3, resize2(x,y), 0.7)
Filter works as expected if weights are 0.5 for both clips.

[pinterf]

If one of the weights is over 1.0 then the internal calculation is using float instead of integer. C path is also using float calculation. But the default average method uses integer arithmetic, with weights scaled to 14 bits precision, and here we have the difference. Internal integer weights are calculated as (1 << 14) * weights[i] where weights[i] are 0.3 and 0.7 in your case. In Merge filter in avisynth core, there is rounding in the integer arithmetic after the multiplication, and here it is obviously missing.

You can try replace this
__m128i weighted_lo = _mm_madd_epi16(src_lo, weight);
__m128i weighted_hi = _mm_madd_epi16(src_hi, weight);

acc_lo = _mm_add_epi32(acc_lo, weighted_lo);
acc_hi = _mm_add_epi32(acc_hi, weighted_hi);


with this (not tried)

__m128i weighted_lo = _mm_madd_epi16(src_lo, weight);
__m128i weighted_hi = _mm_madd_epi16(src_hi, weight);

__m128i round_mask = _mm_set1_epi32(0x2000);
weighted_lo = _mm_add_epi32(weighted_lo, round_mask);
weighted_hi = _mm_add_epi32(weighted_hi, round_mask);

acc_lo = _mm_add_epi32(acc_lo, weighted_lo);
acc_hi = _mm_add_epi32(acc_hi, weighted_hi);

[DJATOM]

Yeah, output now is identical to RAverageW. Thank you.

[pinterf]

Yeah, output now is identical to RAverageW. Thank you.
O.K. forked the project, I make it right (even number of frames need another addition, plus high bit depth)

[Reel.Deel]

Clense is working 'recursively' if it can do, that is, one of the input clips of the Nth clense session is retrieved from the previous (N-1)th clensed frame. This frame (named lframe) and the frame number (name lnr) is saved internally in the class after each Clense. Why? Because it can only work properly, if Clense is getting the frame requests strictly sequentally.
If this condition does not get fulfilled it falls back to getting the (N-1)th child frame, the same behaviour as with reduceflicker=false.

Clense checks if lnr==n-1 (where lnr the last clensed frame number, that the class processed; n is the currently requested frame number in GetFrame()). Thus when Clense gets its request out of order, reduceflicker is ineffective.

So I suppose Clense can hardly work multithreaded properly when reduceflicker==true. And even if the filter is set to "serialized" in MT mode, nothing ensures that it gets the requests in a linear way.

So I can probably add the parameter but cannot ensure that is works. Or I can add 'reduceflicker' just for compatibility (like tp7 added 'planar') and won't use.

I searched around to see if people actually use reduceflicker=true and I only found 2 instances so I guess it's safe just to add a dummy parameter to keep compatibility. To be truly backward compatible, it needs to be before the previous and next parameters though. Clense is also missing the planar parameter.

Here's the script workaround for Clense(reduceflicker=true) (courtesy of Colours). As it was mentioned earlier, this script can only be used once per script and probably does not work with MT.

function clense3(clip c)
{
# I have never had a need to use global variables before so idk if this is correct
global clense_reference = c.trim(0,-1)
c
scriptclip("""
i = current_frame
a = i > 0 ? c.trim(0,length=i-1) + clense_reference + c.trim(i,end="""+string(c.framecount()-1)+""") : c
a.clense()
global clense_reference = last.trim(i,length=1)
return last
""")
}

On another topic, the default for the original VerticalCleaner is 2, in RgTools the default is 1.

Can you make RgTools self-register the MT mode?

softsharp (web.archive.org/web/20160608111758/http://leon1789.perso.sfr.fr/avisynth/SoftSharpen-8.8.zip) for instance use 27

here 26 and 27 http://videoprocessing.fr.yuku.com/sreply/143/RemoveGrain-10-prerelease#.WIj5HGX-vIU

So a total on one script uses mode 27. :rolleyes:
Even though I added all those links to the wiki I completely forgot he documented some of those modes. Regardless, I don't think any of them are really useful, hence why DitherTools nor RgTools included them.

about reduceflicker, it's in 0.9 or 1.0pre? http://videoprocessing.fr.yuku.com/reply/40/RemoveGrain-10-prerelease#reply-40

I think it's the "Beta" release | Recommended here http://avisynth.nl/index.php/RemoveGrain

The redcuceflicker parameter is included in RemoveGrain v0.9 and v1.0beta. v1.0pre is where Kassandro split the spatial and temporal filters into 2 different packages and broke backward compatibility with some of the filters (mainly the temporal ones). This is why the most popular and most compatible version is RemoveGrain v1.0beta.

Earlier I mentioned RgTools is based on RemoveGrain v1.0, I should of been more clear. RgTools is based on RemoveGrain v1.0pre, the Clense family is based on RemoveGrainT v1.0pre.

[pinterf]

New build.

Average v0.93 (https://github.com/pinterf/Average/releases/)
v0.93 (20170126 - pinterf)
Fix: rounding of intermediate results in fast integer average of 8 bit clips
Mod: faster results for two or three clips (8 bit)
New: Support for Avisynth+ color spaces: 10-16 bit and float YUV(A)/Planar RGB(A), RGB48 and RGB64
10+ bits are calculated in float precision internally.
New: auto register as NICE_FILTER for Avisynth+
New: add version resource
Info: built with VS2015 Update 3, may require Visual Studio 2015 Redistributable update 3


please test it

[pinterf]

@Reel.Deel:
This is already done, will appear in next release: "Can you make RgTools self-register the MT mode?"
Todo: add dummy reduceflicker and planar parameters for Clense for compatibility and easy transition of old scripts
Do you need unaligned crop support? (Done, but makes the DLL more huge - each version of each mode of each filter is forceinlined for speed reasons)

[real.finder]

Todo: add dummy reduceflicker and planar parameters for Clense for compatibility and easy transition of old scripts
Do you need unaligned crop support? (Done, but makes the DLL more huge - each version of each mode of each filter is forceinlined for speed reasons)

I think real reduceflicker will be better but with reduceflicker=false by default

and Clense has cache parameters too, but not in RGtools, so dummy cache parameters is needed too

unaligned crop support is not something important, but it's better to check against this by ThrowError("Invalid memory alignment. Used unaligned crop?"), but anyway dll size does not matter :) so do what you see is the best

and it will be great if you add RemoveGrain modes 25-27 (28-30 not needed at all cuz they not documented anywhere)

[pinterf]

Until I gain strength for modes 25-27 (which could be days or weeks), here is a
new RgTools 0.94 (https://github.com/pinterf/RgTools/releases) build.

RgTools 0.94
Clense: new parameter (from v0.9): bool reduceflicker (default false)
Clense: dummy compatibility parameters: bool planar, int cache
Autoregister filter MT modes as NICE_FILTER for Avisynth+
(except for Clense: when reduceflicker is true, MULTI_INSTANCE MT mode is reported)
Alignment check in Repair and RemoveGrain (anti-unaligned crop measures)

Play with it, especially with that Clense reduceflicker thingy. You have to test it, anything can happen. Try it in multithreading mode and report.

[real.finder]

RgTools 0.94 (https://github.com/pinterf/RgTools/releases) build.


:thanks:

seems you forget this little thing


On another topic, the default for the original VerticalCleaner is 2, in RgTools the default is 1.


not so important, so you can include it in the next release

[pinterf]

And here is a fresh
Average v0.94 (https://github.com/pinterf/Average/releases)

v0.94 (20170127)
Fix: fix the fix: rounding of intermediate results was ok for two clips
New: AVX for 10-16bit (+20-30%) and float (+50-60%) compared to v0.93
AVX for 8 bit non-integer path (+20% gain), e.g. when one of the weights is over 1.0
Note 1: AVX needs 32 byte frame alignment (Avisynth+ default)
Note 2: AVX CPU flag is reported by recent Avisynth+ version
Note 3: AVX is reported only on approriate OS (from Windows 7 SP1 on)

v0.93 (20170126 - pinterf)
Fix: rounding of intermediate results in fast integer average of 8 bit clips
Mod: faster results for two or three clips
New: Support for Avisynth+ color spaces: 10-16 bit and float YUV(A)/Planar RGB(A), RGB48 and RGB64
10+ bits are calculated in float precision internally.
New: auto register as NICE_FILTER for Avisynth+
New: add version resource
Info: built with VS2015 Update 3, may require Visual Studio 2015 Redistributable update 3

[fAy01]

Until I gain strength for modes 25-27 (which could be days or weeks), here is a
new RgTools 0.94 (https://github.com/pinterf/RgTools/releases) build.

RgTools 0.94
Clense: new parameter (from v0.9): bool reduceflicker (default false)
Clense: dummy compatibility parameters: bool planar, int cache
Autoregister filter MT modes as NICE_FILTER for Avisynth+
(except for Clense: when reduceflicker is true, MULTI_INSTANCE MT mode is reported)
Alignment check in Repair and RemoveGrain (anti-unaligned crop measures)

Play with it, especially with that Clense reduceflicker thingy. You have to test it, anything can happen. Try it in multithreading mode and report.

Build v0.93 worked fine but the latest build doesn't work with edgecleaner.
http://avisynth.nl/index.php/EdgeCleaner

[real.finder]

Build v0.93 worked fine but the latest build doesn't work with edgecleaner.
http://avisynth.nl/index.php/EdgeCleaner

what you get? I test it now and it seems work

[fAy01]

what you get? I test it now and it seems work

It seems there was a glitch with my pc. My bad.

[yup]

I am try shift from YUY2 to YV16, but it is not easy.
For example masktools do not support
mt_merge(,,,luma=true)
for YV16.
Also not all plugin which support YUY2 work with YV16.
yup.

[Dreamland]

Doesn't work with EdgeCleaner (with some crop parameters)

RGTools v 0.94 (with error)


https://t8.pixhost.org/thumbs/1485/37682966_appunti01.jpg (https://pixhost.org/show/1485/37682966_appunti01.jpg)


(Identical crop parameters) works with RGTools v0.92.1

:thanks:

[pinterf]

Doesn't work with EdgeCleaner (with some crop parameters)

RGTools v 0.94 (with error)

(Identical crop parameters) works with RGTools v0.92.1

:thanks:
RgTools 0.93 and 0.94 does not support unaligned frames, that are the result of an unaligned crop for example. In 0.93 the Repair would result in an exception but in 0.94 it presented an error message, at least that was my intention.

Unfortunately in function Repair, only one of the two clips is checked against the alignment errors, thus you got an access violation instead of the error message. (Alignment is required in this build)

Please, modify your script with a Crop parameter align=true.

(I would recommend everyone to stop using unaligned crops, because the speed gain would be neglible, and the next filter after crop would either fail or fall-back to an unoptimized ultra-slow C instead of optimized SIMD assembly.)

Thanks for the report, anyway.

[ajp_anton]

So shouldn't align=true be the default in Avisynth then?

[pinterf]

Avisynth+ has only aligned crop. If the alignment rules (32 bytes in AVS+) will not be broken, the faster SubFrame mode is automatically used, otherwise it copies the cropped area to a new frame.
The align parameter in Crop exists only for the backward compatibility, has no effect.

[pinterf]

New RgTools 0.95 (https://github.com/pinterf/RgTools/releases)

RgTools 0.95 (20170314)
Fix: RemoveGrain Mode 20: overflow at 14 and 16 bit depths in SSE4 (stripes)
"Repair": error on unaligned frames (unaligned crop) instead of access violation error

[tormento]

MedianBlur is used for MinBlur, that is used inside SMDegrainMOD, now available in 16 bit flavour.

I made some tests and here (https://forum.doom9.org/showthread.php?p=1806431#post1806431) MysteryX suggested me that the arisen problems could be caused by no high bit aware MedianBlur.

@pinterf (others too): can we get a 16 bit build to play with? With MinBlur functionality too perhaps? ;)

[real.finder]

MedianBlur is used for MinBlur, that is used inside SMDegrainMOD, now available in 16 bit flavour.

I made some tests and here (https://forum.doom9.org/showthread.php?p=1806431#post1806431) MysteryX suggested me that the arisen problems could be caused by no high bit aware MedianBlur.

@pinterf (others too): can we get a 16 bit build to play with? With MinBlur functionality too perhaps? ;)

MedianBlur is not always used, if you don't use prefilter mode 0 or 1 or 2 in SMDegrain and don't use contrasharp then no MinBlur is used

[tormento]

MedianBlur is not always used, if you don't use prefilter mode 0 or 1 or 2 in SMDegrain and don't use contrasharp then no MinBlur is used



Ok.. I had suspects. So, no idea why so different results for speed and size [emoji24]

[pinterf]

For speed: if a script is using mt_lutxy, it cannot always use fast lookup tables for memory reasons.
Above 12 bits mt_lutxy calculates the expression realtime, pixel-by-pixel, which is slooooow (unlike Expr in VapourSynth).
For the specific bit depths at which realtime expression evaluation kicks in, see masktools2 readme ("feature matrix" section) or the wiki.

[MysteryX]

If we call SMDegrain with default parameters (no prefilter, no contrasharp), performance is fine.

8-bit

FPS (min | max | average): 2.367 | 137556 | 56.36
Memory usage (phys | virt): 115 | 113 MiB
Thread count: 29
CPU usage (average): 62%


16-bit

FPS (min | max | average): 1.745 | 155894 | 41.05
Memory usage (phys | virt): 120 | 117 MiB
Thread count: 29
CPU usage (average): 62%


In practice, we generally want to use a prefilter and contrasharp. MedianBlur causes problems.

[tormento]

For speed: if a script is using mt_lutxy, it cannot always use fast lookup tables for memory reasons.
Above 12 bits mt_lutxy calculates the expression realtime, pixel-by-pixel, which is slooooow (unlike Expr in VapourSynth).
For the specific bit depths at which realtime expression evaluation kicks in, see masktools2 readme ("feature matrix" section) or the wiki.


Memory? On modern computer, x64 enabled, it shouldn't be a problem anymore. As I am a programming ignorant, could you explain more?

Size... that matter has no answer yet. [emoji55]

[pinterf]

Set realtime=false manually for a 16 bit lutxy. On x64 it can work with plenty of memory. Lut size is 8 gbyte, even the initial lut calc is a minute I guess. Over a specific clip length it would be faster however.

[wonkey_monkey]

Set realtime=false manually for a 16 bit lutxy. On x64 it can work with plenty of memory. Lut size is 8 gbyte, even the initial lut calc is a minute I guess. Over a specific clip length it would be faster however.

How about calculating each term when required, then putting it in the lut for the next time those x and y values crop up?

Of course you'd need more memory to store whether or not a particular value was already in the lut, unless you can determine an "illegal" value beforehand. The additional checks would make it slightly slower than a full lut, but at least you wouldn't have to wait for the whole table to be generated before you got results.

[Myrsloik]

How about calculating each term when required, then putting it in the lut for the next time those x and y values crop up?

Of course you'd need more memory to store whether or not a particular value was already in the lut, unless you can determine an "illegal" value beforehand. The additional checks would make it slightly slower than a full lut, but at least you wouldn't have to wait for the whole table to be generated before you got results.

Now we need 8.5GB per lut.

[MysteryX]

Now we need 8.5GB per lut.
That's why your computer has 4 memory slots

[tormento]

Let's for a moment forget speed. There is an explanation for that. Size i.e. noise reduction in the culprit of issue. Why 16 bit is so inefficient?

[dlnm]

Sorry if I post in the wrong thread.
May I ask where I can find the x64 version of RemapFrames 0.4.1?
It seems the link in the wiki (http://avisynth.nl/index.php/AviSynth%2B) is not valid anymore.
Thank you.

[MysteryX]

Let's for a moment forget speed. There is an explanation for that. Size i.e. noise reduction in the culprit of issue. Why 16 bit is so inefficient?
If you're using prefilter, I'm pretty sure MinMax isn't doing what it's supposed to do -- which will result in weird results. It hasn't been ported to 16-bit. It doesn't crash but threats the data as 8-bit.

That could explain what you're seeing in terms of high bit-rate.

[tormento]

If you're using prefilter, I'm pretty sure MinMax isn't doing what it's supposed to do -- which will result in weird results. It hasn't been ported to 16-bit. It doesn't crash but threats the data as 8-bit.

That could explain what you're seeing in terms of high bit-rate.



I use prefilter=4

[Motenai Yoda]

I'm pretty sure smdegrain (at least the current one) feed minblur with an 8bit clip.

[real.finder]

Let's for a moment forget speed. There is an explanation for that. Size i.e. noise reduction in the culprit of issue. Why 16 bit is so inefficient?

this is what pinterf said back then

There's no reason to get identical results.
For 16 bit input, even if the original clip is 8 bits and its straight 16 bit conversion has zero lsb, the lower resolution subclips in Super are already interpolated and have meaningful lsb parts.
So the vectors after MAnalyze are possibly different than it would be estimated from a single 8 bit source.
Then the weighting and blending inside MDegrain works with higher precision than for a 8 bit input. That is a difference, too.

and this

Indeed, when I alt-tabbed the 8 bit and 10+ bit result, the 10+ bit version possibly found better motion vectors than 8 bits, I saw less orphaned countour lines and remnants from previous frames.

[Groucho2004]

Sorry if I post in the wrong thread.
May I ask where I can find the x64 version of RemapFrames 0.4.1?
It seems the link in the wiki (http://avisynth.nl/index.php/AviSynth%2B) is not valid anymore.
Thank you.Yes, link is dead and I couldn't find the file anywhere else. So, I have taken cretindesalpes' last update to the code of RemapFrames from here (https://forum.doom9.org/showthread.php?p=1644971#post1644971), updated it to AVS2.6 interface and built 32 and 64 bit versions. I tested them very briefly, let me know how it goes.

Link is in my signature.

[ajp_anton]

For speed: if a script is using mt_lutxy, it cannot always use fast lookup tables for memory reasons.
Above 12 bits mt_lutxy calculates the expression realtime, pixel-by-pixel, which is slooooow (unlike Expr in VapourSynth).
For the specific bit depths at which realtime expression evaluation kicks in, see masktools2 readme ("feature matrix" section) or the wiki.Why is the VapourSynth-version faster?

Set realtime=false manually for a 16 bit lutxy. On x64 it can work with plenty of memory. Lut size is 8 gbyte, even the initial lut calc is a minute I guess. Over a specific clip length it would be faster however.Don't know if it already is, but couldn't the LUT calculation be quite easily multithreaded?

[Myrsloik]

Why is the VapourSynth-version faster?

Don't know if it already is, but couldn't the LUT calculation be quite easily multithreaded?

1. Because on x86 it converts the expression to native SSE2 code and does all calculations in floating point. Including some optimizations like pre-calculating constant parts of the expression and other fun stuff.

2. If your LUT has that many values a LUT is a generally bad idea.

[TheFluff]

1. Because on x86 it converts the expression to native SSE2 code and does all calculations in floating point. Including some optimizations like pre-calculating constant parts of the expression and other fun stuff.

Or, to explain it with a few more words: writing a runtime RPN expression evaluator in C++ is pretty trivial and a ton of CS undergrad students have been subjected to it as an exercise. It's easy to write but if you want to put it in a video filter it gets really slow since the expression has to be re-evaluated for every pixel value, and the runtime expression evaluator is a pretty hefty bit of code compared to the tiny bits of math that you're actually writing in the RPN expression.

The expr filter in VS isn't like that. The expr filter in VS is (on x86) a fully-fledged, optimizing just-in-time compiler that takes your RPN expression and compiles it to SSE2-optimized native code. When I say "optimizing" I mean it does things like optimize out constant parts of the expression so they don't have to be re-calculated for each pixel, including optimizing out immutable conditionals so you can avoid branching where possible. It also does auto-vectorization, so the compiled code loads, processes and stores four pixels at a time (since XMM registers are 128 bits wide and it works with 32-bit floats internally). In other words, its performance is on the same level as if you had written the equivalent of your RPN expression in C, compiled it as a plugin and used that instead of mt_lut.

8 GB LUT's are almost definitely slow as molasses in comparison. Memory bandwidth isn't free.

[wonkey_monkey]

The expr filter in VS isn't like that. The expr filter in VS is (on x86)

Why not on x64 as well?

a fully-fledged, optimizing just-in-time compiler that takes your RPN expression and compiles it to SSE2-optimized native code.

Is it based on some other piece of open-source software?

My rgba_rpn plugin does something similar, but using the x87 FPU. I'm wondering now if I should move to SSE2 instead. It certainly isn't crazy-optimal, although I've done my best, and it can do a lot more than expr can.

It's too complex to warrant vectorization, but if there's any interest/need I'd be willing to look into crafting something similar to VS's expr - I was going to provide it as an alias, anyway, but if people would find it really useful it might be worth writing something more optimal for those specific requirements.

[TheFluff]

By x86 I meant x86_64 too. VS can be compiled for other archs as well though, but for those there's no JIT compilation.

It uses jitasm (https://github.com/hlide/jitasm) to actually do the compilation but all the code generation/optimization is mainly Myrsloik's and dubhater's work AFAIK.

[ajp_anton]

What I meant was: why can't the Avisynth version be as fast as VS? Anything preventing the use of the same code?

[TheFluff]

I... don't think so? It's a fairly simple filter, so feel free to go hog wild (https://github.com/vapoursynth/vapoursynth/blob/master/src/core/exprfilter.cpp)

[wonkey_monkey]

I'm trying to think about updating my plugin to handle all the new colour spaces. I've been reading this:

https://forum.doom9.org/showpost.php?p=1783714&postcount=2484

as a reference and I'm wondering about using the new stuff like ComponentCount() - what happens if I make use of that in my code, but then someone still runing AviSynth 2.6 tries to use it? Will it fail? Is there a "best way" to code for this to maintain compatability?

[MysteryX]

I'm trying to think about updating my plugin to handle all the new colour spaces. I've been reading this:

https://forum.doom9.org/showpost.php?p=1783714&postcount=2484

as a reference and I'm wondering about using the new stuff like ComponentCount() - what happens if I make use of that in my code, but then someone still runing AviSynth 2.6 tries to use it? Will it fail? Is there a "best way" to code for this to maintain compatability?

It's implemented in the header and maintains compatibility.

as long as you don't use env2, of course.

[wonkey_monkey]

Ohhh, I see. That makes much more sense than whatever stupid thing I was thinking of. I've still never really gotten the hang of C++...

:stupid::thanks:

[jpsdr]

Even if it took me a long time, but stupid queston...:eek:

Should i do this :

class XXX : public GenericVideoFilter
{
public:
XXX(PClip _child, ..., IScriptEnvironment* env);
~XXX();
....

or this :

class XXX : public GenericVideoFilter
{
public:
XXX(PClip _child, ..., IScriptEnvironment* env);
virtual ~XXX();
....

It suddenly came to my mind, as i remember destructors are very often very strongly suggested being virtual.
:confused:

[Groucho2004]

For derived classes you should always use virtual. Have a look at this (https://stackoverflow.com/questions/461203/when-to-use-virtual-destructors) thread.

[shekh]

No difference. Because destructor is virtual in base class, it is also implicitly virtual in XXX.

[Groucho2004]

Because destructor is virtual in base class, it is also implicitly virtual in XXX.
Do you mean "GenericVideoFilter" specifically?

[shekh]

Do you mean "GenericVideoFilter" specifically?

Yes. GenericVideoFilter here.

[Groucho2004]

Yes. GenericVideoFilter here.I see, I understand it more like a general question about destructors.

[jpsdr]

Thanks for all the informations, even if it was more a specific question for avs plugins, the link was interesting nevertheless. I've noticed that in some plugin destructor wasn't virtual (nnedi3 for exemple), and in others it was, so i was wondering which one was good, even if i thought it was more with virtual than without.
Finaly, it seems it doesn'r matter, but i've nevertheless put virtual where it was not.

[real.finder]

hi pinterf

some plugins need some hot changes

1st is RGTools

RemoveDirtMC_SE(gpu=false,twopass=false) (http://pastebin.com/uNUbMQEh) in YUY2

will give me "Clense wrok with planar only" (Planar=true in Clense is not doing anything unlike the one in removegrain or Repair)

2nd is masktools here (https://forum.doom9.org/showthread.php?p=1808574#post1808574)

[pinterf]

hi pinterf

some plugins need some hot changes

1st is RGTools

RemoveDirtMC_SE(gpu=false,twopass=false) (http://pastebin.com/uNUbMQEh) in YUY2

will give me "Clense wrok with planar only" (Planar=true in Clense is not doing anything unlike the one in removegrain or Repair).
That was easy, basically I'm ready with it, if mimicing RemoveGrain and Repair is enough.

Yes. tp7 has put planar parameter usage back to the other two, but omitted from Clense.


2nd is masktools here (https://forum.doom9.org/showthread.php?p=1808574#post1808574)
I've seen this one, the request is that masktools should handle undocumented chroma="ignore" again?

[real.finder]

I've seen this one, the request is that masktools should handle undocumented chroma="ignore" again?

yes, I just write this there https://forum.doom9.org/showthread.php?p=1809060#post1809060

[MysteryX]

Is it possible to do this in native 16-bit yet?


Function Dither_resize16nr (clip src, int width, int height,
\ float "src_left",
\ float "src_top",
\ float "src_width",
\ float "src_height",
\ string "kernel",
\ float "fh",
\ float "fv",
\ int "taps",
\ float "a1",
\ float "a2",
\ float "a3",
\ int "kovrspl",
\ bool "cnorm",
\ bool "center",
\ string "cplace",
\ int "y",
\ int "u",
\ int "v",
\ string "kernelh",
\ string "kernelv",
\ float "totalh",
\ float "totalv",
\ bool "invks",
\ bool "invksh",
\ bool "invksv",
\ int "invkstaps",
\ string "cplaces",
\ string "cplaced",
\ string "csp",
\ bool "noring")
{
noring = Default (noring, true)

Assert (width > 0 && height > 0, "Dither_resize16nr: width and height must be > 0.")

sr_h = Float (width ) / Float (src.width () )
sr_v = Float (height) / Float (src.height ())
sr_up = Dither_max (sr_h, sr_v)
sr_dw = 1.0 / Dither_min (sr_h, sr_v)
sr = Dither_max (sr_up, sr_dw)
Assert (sr >= 1.0)

# Depending on the scale ratio, we may blend or totally disable
# the ringing cancellation
thr = 2.5
nrb = (sr > thr)
nrf = (sr < thr + 1.0 && noring)
nrr = (nrb) ? Dither_min (sr - thr, 1.0) : 1.0
nrv = (nrb) ? Round ((1.0 - nrr) * 255) * $010101 : 0

main = src.Dither_resize16 (width, height,
\ src_left =src_left,
\ src_top =src_top,
\ src_width =src_width,
\ src_height=src_height,
\ kernel =kernel,
\ fh =fh,
\ fv =fv,
\ taps =taps,
\ a1 =a1,
\ a2 =a2,
\ a3 =a3,
\ kovrspl =kovrspl,
\ cnorm =cnorm,
\ center =center,
\ cplace =cplace,
\ y =y,
\ u =u,
\ v =v,
\ kernelh =kernelh,
\ kernelv =kernelv,
\ totalh =totalh,
\ totalv =totalv,
\ invks =invks,
\ invksh =invksh,
\ invksv =invksv,
\ invkstaps =invkstaps,
\ cplaces =cplaces,
\ cplaced =cplaced,
\ csp =csp
\ )

nrng = (nrf) ? src.Dither_resize16 (width, height,
\ src_left =src_left,
\ src_top =src_top,
\ src_width =src_width,
\ src_height=src_height,
\ kernel ="gauss",
\ a1 =100,
\ center =center,
\ cplace =cplace,
\ cplaces =cplaces,
\ cplaced =cplaced,
\ csp =csp,
\ y =y,
\ u =u,
\ v =v
\ ) : main

nrm = (nrb && nrf) ? main.BlankClip (color_yuv=nrv, height=main.Height()/2) : main

# To do: use a simple frame blending instead of Dither_merge16
rgm = 1
rgc = (nrb) ? -1 : 0
rgy = Defined (y) ? ((y == 3) ? rgm : rgc) : rgm
rgu = Defined (u) ? ((u == 3) ? rgm : rgc) : rgm
rgv = Defined (v) ? ((v == 3) ? rgm : rgc) : rgm
rguv = Dither_max (rgu, rgv)
(nrf ) ? main.Dither_repair16 (nrng, rgy, rguv) : main
(nrf && nrb) ? Dither_merge16_8 (main, last, nrm, y=y, u=u, v=v) : last
}

[real.finder]

Is it possible to do this in native 16-bit yet?


Function Dither_resize16nr (clip src, int width, int height,
>>>


well, there are ResizeX by Desbreko and I port it from some time ago https://forum.doom9.org/showpost.php?p=1782612&postcount=65

it do the most things that Dither_resize16 do

[MysteryX]

This function is to add no-ringing to the resize, it's different.

[pinterf]

New version for RgTools.
I touched it originally because of a request of working planar parameter in Clense.
But decided to implement AVX2 support, though only in RemoveGrain.

Download RgTools 0.96 (https://github.com/pinterf/RgTools/releases/tag/0.96)

Changes
v0.96 (20170609)
- RemoveGrain: AVX2. Available when Avisynth+ reports AVX2 usability
Can be disabled with new parameter: optAvx2=false
- Clense, ForwardClense, BackwardClense: ignore planar colorspace checking when planar=true. Like in RemoveGrain and Repair.
- Fix: Mode 11 and 13 for 32 bit float colorspaces (which worked like mode 10 and 12)

I'd appreciate when someone would test how much AVX2 is faster in RemoveGrain, than previous SSE2/SSE4 code. I could test it (all modes in all bit depth) only with the painfully slow SDE emulator. Thanks.

[Motenai Yoda]

It's me or dgdecode's deblock/dering doesn't work?
I'm using groucho's dgdecode icl, tp7's deblock and avs+ 2504

[videoh]

It's you.

[real.finder]

any plan for support HBD in MedianBlur?

it used by MinBlur function by Didée that used in many scripts

[TheFluff]

you could backport VS-CTMF (https://forum.doom9.org/showthread.php?t=171213), I guess?

[LigH]

Would a plugin like DSS2Mod from the Xvid4PSP project (with native LAV Filters API) have a chance to get ported? It will probably cause larger efforts, supporting new colorspaces and even audio, so it may not be a serious alternative to FFMS2(000) and LSW anymore.

[burfadel]

Would a plugin like DSS2Mod from the Xvid4PSP project (with native LAV Filters API) have a chance to get ported? It will probably cause larger efforts, supporting new colorspaces and even audio, so it may not be a serious alternative to FFMS2(000) and LSW anymore.

Already has, check here:
http://avisynth.nl/index.php/AviSynth%2B

Could possibly benefit from updating though.

[LigH]

Well, yes, "The Web Archive" is not a very prominent location... :o

[Reel.Deel]

Well, yes, "The Web Archive" is not a very prominent location... :o

Do you have a suggestion? Archive.org is one of the few places I trust for longevity.

[LigH]

Unfortunately, it is also a cemetery of dead projects... so I have to assume there is no more active mirror.

[pinterf]

New version for RgTools.

The biggest change is that I added "TemporalRepair" from the old RemoveGrainT package. I spent quite a few weeks on it during the spring, reverse engineering pure inline assembly and rewrite them in C and simd intrinsics. Of course new planar yuv, rgb and high bit depth colorspaces were all added, but YUY2 was dropped (of course, again).
Now I included builds using LLVM 9.0 snapshot build, some modes are quicker, others are slower than MS builds. Try and decide.

Download RgTools 0.98 (https://github.com/pinterf/RgTools/releases)

Changes
v0.98 (20190814)
- Include "TemporalRepair" filter from old RemoveGrainT package (rewritten C and SIMD intrinsics from pure inline asm)
Add Y8, YV16, YV24 besides YV12, drop YUY2 support.
Add 10-32 bit support for Y, YUV and planar RGB formats
Add int "opt" parameter (mainly for debug: 0=C 1=SSE2 2=SSE4.1) for testing specific code paths
- Codes for different processor targets (SSSE3 and SSE4.1) are now separated and are compiled using function attributes (clang, gcc).
- Other source changes for errorless gcc and clang build
- LLVM support, see howto in RgTools.txt
Note: use at least LLVM 9.0 build 21 June 2019 due to a clang compiler bug (_mm_avg_epu8 related, fixed on April 14 2019) older versions are up-to 1/3 slower than the Microsoft build.
See latest snapshot builds at https://llvm.org/builds/
- GCC 8.3 support, CMakeFiles.txt, see howto in RgTools.txt
- RemoveGrain/Repair different code paths for SSE2/SSE4.1/AVX2 instead of SSE2/SSE3/AVX2.
- Add documentation (from old docs, new part: gcc/clang howto)

[Groucho2004]

Thanks, you da man.

[real.finder]

New version for RgTools.


:thanks: it's seems work fine with RemoveDirtMC_SE

since it's Avisynth+ plugin modernization efforts Thread

I think there are some basic plug-ins need HBD port such as AddGrainC, MedianBlur2 and dfttest

[FranceBB]

Thank you, again, Ferenc! :)

:thanks: it's seems work fine with RemoveDirtMC_SE

since it's Avisynth+ plugin modernization efforts Thread

I think there are some basic plug-ins need HBD port such as AddGrainC, MedianBlur2 and dfttest

+1 for DFTTest. It's my favorite filter when it comes to Denoise and it's a shame that it only supports 16bit stacked.
Now that f3kdb has been updated to support 16bit planar, all my filter-chain is on native high bit depth... except for DFTTest.
As a side note, if you are actually going to port it, or if someone is gonna port it, please please please just add High Bit Depth but don't remove 16bit stacked support for compatibility reasons.

[DJATOM]

Yeah, feel free to clone my repo and modernize it. I'm using Vapoursynth nowadays and lost interest in avs stuff.

[real.finder]

Thank you, again, Ferenc! :)



+1 for DFTTest. It's my favorite filter when it comes to Denoise and it's a shame that it only supports 16bit stacked.
Now that f3kdb has been updated to support 16bit planar, all my filter-chain is on native high bit depth... except for DFTTest.
As a side note, if you are actually going to port it, or if someone is gonna port it, please please please just add High Bit Depth but don't remove 16bit stacked support for compatibility reasons.

I can't do these things (like c++ coding)

if pinterf did it I think he will keep it as he keep it in mvtools

[StainlessS]

R.F.
Methinks you would make a pretty damn good C coder, why not give it a bash, really, steep hill at first but not so much later.
(You dont really need CPP, some of us get by reasonably well without).
Please, at least have a play with it, nowt to lose.
EDIT: I found that the hardest part about "C" stuff, was to figure out where to scatter the semi-colons, apart from that, not much different to avs script.

[Sparktank]

What a nice summer this is :) Thanks for the update.

[real.finder]

R.F.
Methinks you would make a pretty damn good C coder, why not give it a bash, really, steep hill at first but not so much later.
(You dont really need CPP, some of us get by reasonably well without).
Please, at least have a play with it, nowt to lose.
EDIT: I found that the hardest part about "C" stuff, was to figure out where to scatter the semi-colons, apart from that, not much different to avs script.

I already tried years ago with libass (C) and mp_pipeline (C++) but with no luck so I give up

[FranceBB]

and mp_pipline (C++) but with no luck so I give up

As a side note, speaking of MPPipeline, development stopped years ago and it has been lacking audio support since then... and on top of it, sometimes it fails spectacularly with modern Avisynth+ high bit depth and colorspace.

[real.finder]

- Add documentation (from old docs, new part: gcc/clang howto)[/CODE]

in RgTools.txt
removegrain modes:

-1= bypass (output=0) faster than mode=0 (copy)

0 = copy

1 = medianblur. Same as Undot, but faster. (single dots)
2 = medianblur. Round up to the second closest minimum luma value in a 3x3 window matrix, if this second lowest value is lower than X pixel value, then leave unchanged. (1x2 spots)
3 = medianblur. Sames as mode 2 but rounded up to third minimum value (but artifact risky). (3pixel-clusters)
4 = medianblur. Sames as mode 2 but rounded up to fourth minimum value (but artifact risky). (up to 2x2-pixel-clusters)

5 = medianblur. Edge sensitive. Only line pairs are used. Strong edge protection.
6 = medianblur. Edge sensitive. Only line pairs are used. Fairly edge protection.
7 = medianblur. Edge sensitive. Only line pairs are used. Mild edge protection.
8 = medianblur. Edge sensitive. Only line pairs are used. Faint edge protection.
9 = medianblur. Edge sensitive. Only line pairs are used. Barely edge protection. Practically a spatial variant of trbarry's ST Median filter.

10 = Minimal sharpening. Replaces center pixel by its nearest neighbour. "Very poor denoise sharpener"

11 = Blur. 3x3 kernel convolution blur. Better than its counterpart internal Blur(1) (and faster)
12 = Blur. Same as 11 but fastest and only <= 1% less precise (still better than Blur(1))

13 = Smart bob (for interlaced content). Interpolates the top field. Similar to Trbarry's weird bob (Tomsmocomp).
14 = Smart bob (for interlaced content). Interpolates the bottom field. Similar to Trbarry's weird bob (Tomsmocomp).
15 = Smart bob (for interlaced content). Same as mode 13 but more quality and slightly slower.
16 = Smart bob (for interlaced content). Same as mode 14 but more quality and slightly slower.

17 = medianblur. Same as mode 4 but better edge protection (similar to near artifact free mode 2). Probably best mode of all.
18 = medianblur. Same as mode 9 but better edge protection (Same as what mode 17 was to mode 4, but in this case to mode 9, and far less denoising than mode 17)

19 = Blur. Average of its 8 neighbours.
20 = Blur. Uniform average of its 8 neighbours. Better than 19 but slower. Very similar to blur(1.58) but faster.

21 = medianblur. Clipping is done with respect to averages of neighbours. Best for cartoons.
22 = medianblur. Same as mode 21 but much faster (fastest mode of all)

23 = Dehalo. Fixes small (as one pixel wide) haloes.
24 = Dehalo. Same as 23 but considerably more conservative and slightly slower. Preferred.

25 = Minimal sharpening.

26 = medianblur. Based off mode 17, but preserves corners, but not thin lines.
27 = medianblur. Same as mode 26 but preserves thin lines.

but if I use 25 or up I will get error message :rolleyes:

[StainlessS]

but if I use 25 or up I will get error message

RemoveGrain.cpp

RemoveGrain::RemoveGrain(PClip child, int mode, int modeU, int modeV, bool skip_cs_check, bool use_avx2, IScriptEnvironment* env)
: GenericVideoFilter(child), mode_(mode), modeU_(modeU), modeV_(modeV), functions(nullptr) {
if (!(vi.IsPlanar() || skip_cs_check)) {
env->ThrowError("RemoveGrain works only with planar colorspaces");
}

if (mode <= UNDEFINED_MODE || mode_ > 24 || modeU_ > 24 || modeV_ > 24) {
env->ThrowError("RemoveGrain mode should be between -1 and 24!");
}

[pinterf]

in RgTools.txt
but if I use 25 or up I will get error message :rolleyes:
"Add documentation (from old docs,..."

Yep, copied there, as-is. As a first step.
@Anyone: feel free to revise (correctness) and update it :)

When someone is bored, likes challenges in general (ice bucket, bottle cap, etc.) and reverse engineers the assembler codes for modes over 25 and give me a C (or any pseudo) code than I'll include it. I don't have those free days or weeks at the moment.

[LigH]

When someone is boring...

:o When someone is bored... boring people would drag you down.

[real.finder]

how many temporal dimension frames checkmate use? since it even with tthr2=0 it's still cause some artifacts in motion, so maybe using it with MC will make better

[real.finder]

any idea of porting BlindPP to new plugin with HBD? or if we can replace it with something else that give at least similar if not 100% identical output? I tried with deblock and aside from the parameters are not similar I didn't get to make the output the same or similar

I need BlindPP since some scripts use it like FunkyDeBlock and SoftSharpen

[real.finder]

is it possible to have http://avisynth.nl/index.php/IT add edeint parameter like TDeint and tfm do? since there are some Japanese sources only work better with IT and the internal deinterlace is not that good

there are https://github.com/HomeOfVapourSynthEvolution/VapourSynth-IT to backport if updating original avs one is hard

[LigH]

Are there any image stabilizer plugins available yet? I read a question about VDub DeShaker today, which may not yet be available for VDub2 x64, and looking through the Wiki page for AviSynth+ x64 plugins, I could not find anything related to DePan or Stab ...

[Reel.Deel]

Are there any image stabilizer plugins available yet? I read a question about VDub DeShaker today, which may not yet be available for VDub2 x64, and looking through the Wiki page for AviSynth+ x64 plugins, I could not find anything related to DePan or Stab ...

Update Depan is distributed with MVTools: https://github.com/pinterf/mvtools/releases

Here's a full list of plugins that are available in x64: http://avisynth.nl/index.php/Category:Plugins_x64

Deshaker is available in x64, although I've have not tried it with VDub2.

[real.finder]

I did update some old posts (https://forum.doom9.org/showpost.php?p=1923877&postcount=656) with this Reply (note the colors)
ok, so I will mention what not has HBD yet

1st is plugins that has VS ports with HBD:-
1 - EEDI3 (https://github.com/pinterf/EEDI3) (no HBD yet (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-EEDI3))
2 - Dither_resize16/fmtconv (no yet) here https://github.com/EleonoreMizo/fmtconv the vs port
3 - SangNom2/SangNomMod (done by Asd (https://github.com/Asd-g/AviSynth-SangNom2))
4 - TTempSmooth (done by Asd (https://github.com/Asd-g/AviSynth-vsTTempSmooth))
5 - EEDI2 (done by Asd (https://github.com/Asd-g/AviSynth-EEDI2))
6 - TCanny (there are TCannymod by chikuzen but I think with no HBD) (done by Asd (https://github.com/Asd-g/AviSynth-vsTCanny))
7 - Yadifmod (there are Yadifmod2 by chikuzen with not completed HBD) (done by Asd (https://github.com/Asd-g/yadifmod2))
8 - DeblockPP7 (done by Asd (https://github.com/Asd-g/AviSynth-vsDeblockPP7))
9 - median (not yet) here https://github.com/dubhater/vapoursynth-median the VS port
10 - tbilateral (done by Asd (https://github.com/Asd-g/AviSynth-vsTBilateral))
11 - tedgemask (done by Asd (https://github.com/Asd-g/AviSynth-vsTEdgeMask))
12 - MSmooth (done by Asd (https://github.com/Asd-g/AviSynth-vsMSmooth))
13 - ASharp (done by Asd (https://github.com/Asd-g/AviSynth-ASharp))
14 - degrainmedian (no yet) here https://github.com/dubhater/vapoursynth-degrainmedian the VS port
15 - TDeint (done by pinterf (https://github.com/pinterf/TIVTC))

plugins that has VS ports but no HBD:-
1 - scxvid (there are no x64 in avs yet)
2 - hqdn3d (there are avs port but with 16bit hack)
3 - ssiq (there are no x64 in avs yet)

and there are some filters seems has no VS ports

1 - VariableBlur (it was planed by tp7 (https://forum.doom9.org/showthread.php?p=1658610&highlight=VariableBlur#post1658610))
2 - frfun7 (useful for Dot Crawl Removal, used in DDComb)
3 - GradFun2db (maybe it can be replaced with f3kdb?)
4 - LGhost (HolyWu Recently did the VS port, avs+ done by Asd (https://github.com/Asd-g/AviSynthPlus-vsLGhost))

so a lot of those are done now by Asd here https://github.com/Asd-g?tab=repositories and there are some that I didn't mention like https://github.com/Asd-g/AviSynth-CAS and https://github.com/Asd-g/AviSynth-FillBorders and https://github.com/Asd-g/AviSynth-vsTMM and https://github.com/Asd-g/AviSynth-BWDIF and https://github.com/Asd-g/AviSynth-JincResize and https://github.com/Asd-g/RawSource_2.6x and https://github.com/Asd-g/MTCombMask and https://github.com/Asd-g/ReduceFlicker and there are many others!

note: the ones that has "vs" in their names because they are not same as old avs one (Missing things from avs old one or different parameters)

[tormento]

I did update
:thanks:

I really would like to have HBD dither.

[Boulder]

:thanks:

I really would like to have HBD dither.

What functionalities of Dither you are looking for? It already has the 16bit hack implemented, but it could be that the functionality can be achieved by some other tool.

[tormento]

What functionalities of Dither you are looking for? It already has the 16bit hack implemented, but it could be that the functionality can be achieved by some other tool.
I'd like to see how good and how fast it dithers from 16 bit to 8-12 bit / deband with proper HBD support.

[pinterf]

z_ConvertFormat probably dithers using AVX2 as well, maybe even utilizes AVX512.

[Boulder]

z_ConvertFormat probably dithers using AVX2 as well, maybe even utilizes AVX512.

At least according to the docs, it does.

http://avisynth.nl/index.php/Avsresize

[real.finder]

z_ConvertFormat is good, but it's not a full replace for dither tools, there are https://github.com/EleonoreMizo/fmtconv as dither tools vs port, so it's better to back port it than update the old dither tools

edit: even fmtconv can't be a full replacement for dither tools, since the functions in dither tools has additional features like soft and maxts in Dither_add_grain16 (addgrainc alternative) and fmtconv don't has Dither_add_grain16 alternative edit: https://forum.doom9.org/showthread.php?p=1937771#post1937771

[Arx1meD]

Good day to all.
Has anyone found Convolution3D (http://hellninjacommando.com/con3d/beta/index.html) for Windows 64-bit?
I know MipSmooth exists, but it works a little differently and slower.

[pinterf]

Good day to all.
Has anyone found [suspicious_url] for Windows 64-bit?
I know MipSmooth exists, but it works a little differently and slower.
Hi, are you aware of the link you put behind "Convolution3D" link to redirect?

[LigH]

That was indeed the homepage of the author once. But it vanished. The AviSynth Wiki links to a WebArchive of this domain for the 32-bit version.

I guess you can simulate such a generic plugin with MaskTools etc. but an optimized plugin will probably be more efficient, especially with a variety of color spaces...

[Arx1meD]

Hi, are you aware of the link you put behind "Convolution3D" link to redirect?

This is a link from the http://avisynth.nl
I found the source code on another site, but I don’t know what to do with it. I am not a software developer.

[pinterf]

After looking the code:
From coder's point of view its internal asm is incompatible with x64 (e.g. using 32 bit registers for pointers).
Instead of hacking that it would need a SIMD intrinsic rewrite: asm{} block syntax is not valid for x64. And one should use SSE2 instead of MMX. Surely it needs some hours of working time.

Webarchive source:
http://web.archive.org/web/20130118045049/http://hellninjacommando.com/con3d/beta/con3d-yv12-beta5.zip

[Arx1meD]

pinterf thanks for the answer. Excuse me, but I do not understand what you are talking about. :confused: Sorry.

[wonkey_monkey]

Could it be emulated with Expr?

[pinterf]

pinterf thanks for the answer. Excuse me, but I do not understand what you are talking about. :confused: Sorry.
Sorry, there was a first - non-technical - sentence there which I deleted.

Really, the last sentence was for you:
"Surely it needs some hours of working time."

The rest is just a note for those (incl. me) who are considering touching the plugin. Interesting and not so hard task, but when someone starts working on it, please note it here and I'll then not spend time on that.

[pinterf]

Could it be emulated with Expr?
Looking into the description (Convolution3d.txt) it is not that straightforward doing it with Expr.
Unfortunately there is no C version - so at least the code has to be reverse-engineered if it's doing the same as stated in the description. So strange that old coders are starting immediately with coding assembler. A huge contrast to present coding standards where there must be a working C prototype to understand and simulate the basic behaviour even if it is optimized later for a specific processor and thus the code written in C won't not run at all. (until someone recognizes that the compiler sometimes generate quicker code than the hand-written assembler :) and drop old assembler routines)

[Arx1meD]

pinterf thanks for the explanation. I cannot ask to redo something.
:thanks:

[pinterf]

Never mind, tidying up ugly or ancient codes is my daily adrenaline. Almost done. Anyway, original source was a bit buggy and gave artifacts, no wonder it was called 'beta'. Sooner or later you'll get it.

[ChaosKing]

Never mind, tidying up ugly or ancient codes is my daily adrenaline.

You should change your user title to "Avisynth plugin archaeologist" or something like that :D

[StainlessS]

Yeah, better than current "Registered User", you aint just anybody, fluff it up a bit.

[pinterf]

Check it please. Convolution 3D v1.1 as-is.
https://github.com/pinterf/Convolution3D/releases

[Arx1meD]

pinterf thank you so much! I never even dreamed of such a thing.
I still used all 32-bit plugins for AviSynth because I couldn't find Convolution3d in 64-bit. Yes, I really like how Convolution3d works.
I need some time to test it.

[Reel.Deel]

Check it please. Convolution 3D v1.1 as-is.
https://github.com/pinterf/Convolution3D/releases

Thanks pinterf.

WIP: http://avisynth.nl/index.php/Convolution3D

[kedautinh12]

Asd was port vapoursynth-tedgemask: https://github.com/Asd-g/AviSynth-vsTEdgeMask

[kedautinh12]

Thanks pinterf.

WIP: http://avisynth.nl/index.php/Convolution3D

I seen mistake:


Examples
hqdn3d with all default values:

AviSource("Blah.avi")
Convolution3D (matrix=0, ythresh=3, cthresh=4, t_ythresh=3, t_cthresh=4, influence=3.0)

[FranceBB]

Wow! Another one to add to the collection.
When I replaced the DLL inside the plugins folder I didn't believe my eyes: I put it there in 2003!

Yeah, better than current "Registered User", you aint just anybody, fluff it up a bit.

Yeah, he's is right. You have done so much for the community by taking care of lots and lots of plugins and also (and most importantly) developing the core that you should have a big fat title in there, you deserve it!
After all, you're the current Avisynth maintainer, without you updating the core we're lost... (I mean it).

[StainlessS]

I seen mistake:

What would that mistake be then ?

I suspect you think that this

Examples
hqdn3d with all default values:

is some kind of Copy/Paste error, maybe it just means that with those Convolution3D args, it does the same job as hqdn3d().

Yeah, he's is right.

Hows bout "Avisynth Authoritarian",
Adjective: authoritarian
1) Characteristic of an absolute ruler or absolute rule; having absolute sovereignty.
2) Expecting unquestioning obedience.

or "Avisynth Autocrat"
Noun: autocrat
A cruel and oppressive dictator.


Both pretty tasty :)

EDIT: Your "Custom User Title" is set in your user Control Panel, "Edit Your Details" / "Custom User Title",
And appears under your User Name and above your Avatar (if you had one), where mine says ""HeartlessS Usurer".

Noun: Usurer
1) Someone who lends money at excessive rates of interest. [loan shark, moneylender, shylock]
and TinMan aint got no heart, and Userer instead of User, fiendishly clever huh! :)

[Boulder]

Curator of Avisynth ;)

[pinterf]

New (final) release.
Convolution3D v1.2
https://github.com/pinterf/Convolution3D/releases
Enjoy the life.
2021/03/12 v1.2 (pinterf)
- Implement routines in pure C
- Fix left/right edge buffer overread (theoretical crash)
- Add Y8 format
- parameter 'opt' when 0 it forces the C-only routines (disable SSE2)
- Add CMake build environment - linux/gcc compatible.
- Support INTEL_INTRINSIC define in code + CMake (non-x64 linux architecture support)
- Update README.md with build instructions
- Update documenation

[real.finder]

Asd was port vapoursynth-tedgemask: https://github.com/Asd-g/AviSynth-vsTEdgeMask

so I did update the list https://forum.doom9.org/showthread.php?p=1937480#post1937480 for this

tidying up ugly or ancient codes is my daily adrenaline.

if you have time, can you have a look on BlindPP? https://github.com/chikuzen/MPEG2DecPlus/blob/mpeg2decplus/src/dgdecode/BlindPP.cpp (it was part of MPEG2Dec, better to be moved as standalone plugin since Asd-g remove it from D2VSource/previously aka MPEG2Dec)

[tormento]

if you have time, can you have a look on BlindPP?
We should get a queue number. Poor Pinterf.

[emoji23]

[LigH]

And I'm still hoping for a new VDub2 with recent ffmpeg plugin ... okay, different thread.

[Reel.Deel]

What would that mistake be then ?

I suspect you think that this

Examples
hqdn3d with all default values:

is some kind of Copy/Paste error, maybe it just means that with those Convolution3D args, it does the same job as hqdn3d().


Just a copy paste error, when making a new page I usually just take another page from the same category and edit that.

[tormento]

You should change your user title to "Avisynth plugin archaeologist" or something like that :D
Given his passion for Ferenc Pinter (pinterf, are you italian?), perhaps "Avisynth visionary". And, at least, have one of his most iconic job as avatar.

https://i2.lensdump.com/i/IQgqQZ.md.jpg (https://lensdump.com/i/IQgqQZ)

[StainlessS]

OK, thanks R.D. looks like my guess was totally wrong


Convolution3D (matrix=0, ythresh=3, cthresh=4, t_ythresh=3, t_cthresh=4, influence=3.0)


is not about same as


hqdn3d(ls=4.0, cs=3.0, lt=6.0, ct=4.5, restart=7)


All defaults for both.

EDIT:

are you italian?
Methinks, Hungarian, igan ?.

Hows bout,

"Avisynth Ambassador"
Noun: ambassador:
1) A diplomat of the highest rank; accredited as representative from one country to another.
2) An informal representative. ""an ambassador of good will"".


"Avisynth Armourer", [ Noun: Armourer: A worker/craftsman skilled in making armour or arms. ]

"Avisynth Artisan", [ Noun: Artisan: A skilled worker/craftsman who practices some trade or handicraft. ]

"Avisynth Artificer",
Noun: Artificer:
1) Someone who is the first to think of or make something.
2) A skilled worker/craftsman who practices some trade or handicraft
3) An enlisted man responsible for the upkeep of small arms and machine guns etc.

[FranceBB]

Methinks, Hungarian, igan ?.

Given the famous Hungarian footballer Ferenc Puskás, it looks like "Ferenc" is an Hungarian name, so thinking that our Ferenc (Pinter) is Hungarian is a pretty safe guess.



hqdn3d(ls=4.0, cs=3.0, lt=6.0, ct=4.5, restart=7)



Uhm... HQDN3D? Is that the one from HDRCore, so 16bit interleaved only?

[tormento]

Methinks, Hungarian, igan ?.
Ferenc Pinterf was born in Italy (Alassio) from Hungarian father and Italian mother.

He worked the greatest part of his life in Italy as painter and designer.

Curiosity for italian readers: se avete in casa un giallo Mondadori, con ogni probabilità la copertina l'ha disegnata lui :)

[ChaosKing]

Just look at his gtithub page...

[StainlessS]

Uhm... HQDN3D? Is that the one from HDRCore, so 16bit interleaved only?
I've only ever used the 8 bit hqdn3d.dll.

Ferenc Pinterf was born in Italy (Alassio) from Hungarian father and Italian mother. He worked the greatest parto of his life in Italy as painter and designer.
Damn, and he's still got oodles of time for avisynth.

EDIT:
I think P said somewhere that he/she/they/it is Hungarian :)

[tormento]

Damn, and he's still got oodles of time for avisynth.
I am talking about the original one :p

[StainlessS]

P is the real original [not an imposter].

EDIT: Or maybe "Avisynth Imposter" :)

EDIT: Just look at his gtithub page...
Yeah thats where I musta seen it. [ https://github.com/pinterf ]

Hungarian is a pretty safe guess.
I'm more into Tiddlywinks than Football.
https://www.youtube.com/watch?v=t_UIukfzPXo

[FranceBB]

I've only ever used the 8 bit hqdn3d.dll.

I double checked, yes, the original version was yv12 8bit planar only and what's worse is that I can't really find the 4:2:0 16bit interleaved modded version, but I used to have it somewhere, I swear... I just don't remember who made it years ago... :(
But anyway, I guess this is yet another plugin to add on the list of those that need to be updated in the future...

[real.finder]

what's worse is that I can't really find the 4:2:0 16bit interleaved modded version, but I used to have it somewhere, I swear... I just don't remember who made it years ago... :(
But anyway, I guess this is yet another plugin to add on the list of those that need to be updated in the future...

it is Hqdn3dY http://avisynth.nl/index.php/Hqdn3dY

[FranceBB]

it is Hqdn3dY http://avisynth.nl/index.php/Hqdn3dY

Ah, yes! There it is! :)

[pinterf]

I'm sure I'm bad at painting :)

[Arx1meD]

pinterf, thanks again for Convolution3D.
After many hours of testing, everything works fine. But I noticed strange behavior of the filter when changing scenes in the movie. In the last frame of the scene, the color of parts of the objects changes. And for moving objects too. The original version of the filter does the same, but not as much as the new version. To fix this, I turned off chroma processing (t_cthresh=0).

Here's an example:
https://thumbs2.imgbox.com/97/7f/yQr0gbyu_t.png (https://imgbox.com/yQr0gbyu) https://thumbs2.imgbox.com/03/34/E0i6SLPc_t.png (https://imgbox.com/E0i6SLPc)

[kedautinh12]

asd-g was port from vapoursynth degrain median: https://github.com/Asd-g/AviSynth-vsDeGrainMedian

[real.finder]

I did update

another update (note the colors)
ok, so I will mention what not has HBD yet

1st is plugins that has VS ports with HBD:-
1 - EEDI3 (https://github.com/pinterf/EEDI3) (no HBD yet (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-EEDI3))
2 - Dither_resize16/fmtconv (no yet) here https://github.com/EleonoreMizo/fmtconv the vs port
3 - SangNom2/SangNomMod (done by Asd (https://github.com/Asd-g/AviSynth-SangNom2))
4 - TTempSmooth (done by Asd (https://github.com/Asd-g/AviSynth-vsTTempSmooth))
5 - EEDI2 (done by Asd (https://github.com/Asd-g/AviSynth-EEDI2))
6 - TCanny (there are TCannymod by chikuzen but I think with no HBD) (done by Asd (https://github.com/Asd-g/AviSynth-vsTCanny))
7 - Yadifmod (there are Yadifmod2 by chikuzen with not completed HBD) (done by Asd (https://github.com/Asd-g/yadifmod2))
8 - DeblockPP7 (done by Asd (https://github.com/Asd-g/AviSynth-vsDeblockPP7))
9 - median (not yet) here https://github.com/dubhater/vapoursynth-median the VS port
10 - tbilateral (done by Asd (https://github.com/Asd-g/AviSynth-vsTBilateral))
11 - tedgemask (done by Asd (https://github.com/Asd-g/AviSynth-vsTEdgeMask))
12 - MSmooth (done by Asd (https://github.com/Asd-g/AviSynth-vsMSmooth))
13 - ASharp (done by Asd (https://github.com/Asd-g/AviSynth-ASharp))
14 - degrainmedian (done by Asd (https://github.com/Asd-g/AviSynth-vsDeGrainMedian))
15 - TDeint (done by pinterf (https://github.com/pinterf/TIVTC))

plugins that has VS ports but no HBD:-
1 - scxvid (there are no x64 in avs yet)
2 - hqdn3d (there are avs port but with 16bit hack) (done by Asd (https://github.com/Asd-g/AviSynth-hqdn3d))
3 - ssiq (there are no x64 in avs yet)

and there are some filters seems has no VS ports

1 - VariableBlur (it was planed by tp7 (https://forum.doom9.org/showthread.php?p=1658610&highlight=VariableBlur#post1658610))
2 - frfun7 (useful for Dot Crawl Removal, used in DDComb)
3 - GradFun2db (maybe it can be replaced with f3kdb?)
4 - LGhost (HolyWu Recently did the VS port, avs+ done by Asd (https://github.com/Asd-g/AviSynthPlus-vsLGhost))

[tormento]

another update
Thanks!

Shouldn't you include dither? It's AVS25 plus lot of limitations.

[real.finder]

Thanks!

Shouldn't you include dither? It's AVS25 plus lot of limitations.

well, most dither things can done in another plugins, that why I only mentioned fmtconv which is kinda vs dithertools port, maybe the only one that left in dithertools is SmoothGrad which can also replace GradFun2db as I did MCTemporalDenoise/GradFun2DBmod

[real.finder]

Shouldn't you include dither? It's AVS25 plus lot of limitations.

well, most dither things can done in another plugins, that why I only mentioned fmtconv which is kinda vs dithertools port, maybe the only one that left in dithertools is SmoothGrad which can also replace GradFun2db as I did MCTemporalDenoise/GradFun2DBmod

seems I forget box_filter16 in dithertools I think we need someone port this from vapoursynth https://github.com/vapoursynth/vapoursynth/blob/db25018fafef612185f79f0f86164430b0bbf6f6/src/core/boxblurfilter.cpp

[mp3dom]

I know it may sound weird, but were (old) plugins like TelecideHints and FieldHint ever gets the avs+ colorspaces with hbd support? I know these are very old plugins, but they're still both used in tools like YATTA and original versions are also limited to YV12 only (FieldHint). Hbd and avs+ colorspaces support could also allow them to be used with YATTA while keeping the 8+bit chain.

[StainlessS]

For anybody wondering what mp3dom is talking about, theres a little but about it here (Hinting, take anything I say there with a pinch of salt)
https://forum.doom9.org/showthread.php?p=1862012#post1862012

Not sure how likely it is to happen for Float colorspace.

EDIT: With Frame Properties, could maybe totally replace the hinting.

[kedautinh12]

New plugin fork from vapoursynth-dotkill
https://github.com/Asd-g/AviSynth-DotKill

[kedautinh12]

New plugin port from vapoursynth-cnr2
https://github.com/Asd-g/AviSynth-vsCnr2

[kedautinh12]

Dedup with x64, avs 2.6
http://avisynth.nl/index.php/DeDup

[Dogway]

Does anyone know what kind of convolution this theory applies to? It sounds to me as repair(mode=2) but I don't know, he also talks about a 2x2 window, how is that, should conv kernels be odd?

First of all the contributors need to be sorted. The contributor which is nearest to the "center" (usually gets the highest weight) should be first in the list etc. The list should be sorted for distance to the center and not for weight. The sorted contributor list makes it easy to apply special processing to the "main contributors".
(...)
Hmmmmm... I didn't know the "Repair" filter. Seems that it uses the same concept, but it's not as well optimized for the specific case, I think. E.g. from what I've just read, "Repair" always compares 3x3 pixels. From my tests that's a good general purpose solution, but maybe not the best solution specifically for scaling. For upscaling I'm only comparing 2x2 pixels (those which are nearer to the "center"). For downscaling it can be more than 3x3 pixels, depending on the scale factor.

Or in short: The algorithm I described is custom tailored to "contributor" based resampling algorithms, by making use of the information in the contributor list. I think this should result in slightly superior quality because exactly those pixels are compared which are the main contributors to the final destination pixel. If we compare too many or not enough pixels, the algorithm should get a bit less effective (e.g. miss some ringing or misdetect ringing).

Here my attempt:

str = Format("y[-1,1] A^ y[0,1] B^ y[1,1] C^ y[-1,0] D^ y[1,0] F^ y[-1,-1] G^ y[0,-1] H^ y[1,-1] I^ x[0,0] J^" \
+" J 1 - K^ K A - abs K B - abs < A B ? L^ K C - abs K D - abs < C D ? M^ K F - abs K G - abs < F G ? N^ K H - abs K I - abs < H I ? O^" \
+" K L - abs K M - abs < L M ? P^ K N - abs K O - abs < N O ? Q^ " \
+" K P - abs K Q - abs < P Q ? R^ " \
+" J 1 + K^ K A - abs K B - abs < A B ? L^ K C - abs K D - abs < C D ? M^ K F - abs K G - abs < F G ? N^ K H - abs K I - abs < H I ? O^" \
+" K L - abs K M - abs < L M ? P^ K N - abs K O - abs < N O ? Q^ " \
+" K P - abs K Q - abs < P Q ? S^ " \
+" J R S clip " )

[Dogway]

Also is there any jpeg source filter for avs+ x64 like jpegsource that lets you load the image in original format (YUV) rather than convert it to RGB?

[zorr]

he also talks about a 2x2 window, how is that, should conv kernels be odd?

Not sure but 2x2 and scaling reminds me of bilinear interpolation (http://tech-algorithm.com/articles/bilinear-image-scaling/).

[Reel.Deel]

Also is there any jpeg source filter for avs+ x64 like jpegsource that lets you load the image in original format (YUV) rather than convert it to RGB?

FFImageSource and LWLibavVideoSource can.

[kedautinh12]

SmoothUV2 now add back SSHiQ from old SmoothUV
https://github.com/Asd-g/AviSynth-SmoothUV2/releases

[GMJCZP]

Hello, the tritical's TUnsharp plugin does not work in HBD, is there a possibility to solve this situation?

[kedautinh12]

TUnsharp now don't support HBD. Need some one add support HBD

[Dogway]

I'm not sure that TemporalRepair is working as expected. modes 1, 2, and 3 barely do anything. I ported them to ex_repair and visually they clearly try to recover detail, unless I got the source code wrong.

RG_FORCEINLINE void get_lu_c(int& lower, int& upper, int src_prev, int src_curr, int src_next)
{
auto max_np = std::max(src_next, src_prev);
auto min_np = std::min(src_next, src_prev);
upper = subs_c(max_np, src_curr);
lower = subs_c(src_curr, min_np);
}

RG_FORCEINLINE int SmoothTRepair1_c(int dest, int lower, int upper, const int src_prev, const int src_curr, const int src_next)
{
auto src_dest = dest;

auto tmp_u = adds_c(upper, src_curr);
auto tmp_l = subs_c(src_curr, lower);

auto tmp_max = std::max(std::max(tmp_u, src_prev), src_next);
auto tmp_min = std::min(std::min(tmp_l, src_prev), src_next);

auto result = clip(src_dest, tmp_min, tmp_max);

return result;
}

RG_FORCEINLINE int temporal_repair_processor_mode1_8_c(
BYTE* dp,
const BYTE* previous, const intptr_t pfpitch,
const BYTE* sp, const intptr_t ofpitch,
const BYTE* next, const intptr_t nfpitch
)
{
int lowermax, uppermax;
int lower, upper;
get_lu_c(lowermax, uppermax, previous[-1 * pfpitch - 1], sp[-1 * ofpitch - 1], next[-1 * nfpitch - 1]);
get_lu_c(lower, upper, previous[-1 * pfpitch + 0], sp[-1 * ofpitch + 0], next[-1 * nfpitch + 0]);
uppermax = std::max(uppermax, upper);
lowermax = std::max(lowermax, lower);
get_lu_c(lower, upper, previous[-1 * pfpitch + 1], sp[-1 * ofpitch + 1], next[-1 * nfpitch + 1]);
uppermax = std::max(uppermax, upper);
lowermax = std::max(lowermax, lower);
get_lu_c(lower, upper, previous[1 * pfpitch - 1], sp[1 * ofpitch - 1], next[1 * nfpitch - 1]);
uppermax = std::max(uppermax, upper);
lowermax = std::max(lowermax, lower);
get_lu_c(lower, upper, previous[1 * pfpitch + 0], sp[1 * ofpitch + 0], next[1 * nfpitch + 0]);
uppermax = std::max(uppermax, upper);
lowermax = std::max(lowermax, lower);
get_lu_c(lower, upper, previous[1 * pfpitch + 1], sp[1 * ofpitch + 1], next[1 * nfpitch + 1]);
uppermax = std::max(uppermax, upper);
lowermax = std::max(lowermax, lower);
get_lu_c(lower, upper, previous[0 * pfpitch - 1], sp[0 * ofpitch - 1], next[0 * nfpitch - 1]);
uppermax = std::max(uppermax, upper);
lowermax = std::max(lowermax, lower);
get_lu_c(lower, upper, previous[0 * pfpitch + 1], sp[0 * ofpitch + 1], next[0 * nfpitch + 1]);
uppermax = std::max(uppermax, upper);
lowermax = std::max(lowermax, lower);
return SmoothTRepair1_c(dp[0], lowermax, uppermax, previous[0 * pfpitch + 0], sp[0 * ofpitch + 0], next[0 * nfpitch + 0]);

I understand that "sp[-1 * ofpitch - 1]" means "x[-1,-1]" otherwise my (unoptimized) expression is wrong:
y[-1,-1] z[-1,-1] max x[-1,-1] - U^
x[-1,-1] y[-1,-1] z[-1,-1] min - L^
y[-1,0] z[-1,0] max x[-1,0] - V^
x[-1,0] y[-1,0] z[-1,0] min - M^
U V max U^ L M max L^
y[-1,1] z[-1,1] max x[-1,1] - V^
x[-1,1] y[-1,1] z[-1,1] min - M^
U V max U^ L M max L^
y[1,-1] z[-1,-1] max x[1,-1] - V^
x[1,-1] y[-1,-1] z[1,-1] min - M^
U V max U^ L M max L^
y[1,0] z[1,0] max x[1,0] - V^
x[1,0] y[1,0] z[1,0] min - M^
U V max U^ L M max L^
y[1,1] z[1,1] max x[1,1] - V^
x[1,1] y[1,1] z[1,1] min - M^
U V max U^ L M max L^
y[0,-1] z[0,-1] max x[0,-1] - V^
x[0,-1] y[0,-1] z[0,-1] min - M^
U V max U^ L M max L^
y[0,1] z[0,1] max x[0,1] - V^
x[0,1] y[0,1] z[0,1] min - M^
U V max U^ L M max L^

x[0,0] U + y[0,0] max z[0,0] max
x[0,0] L - y[0,0] min z[0,0] min
a swap2 clip

[kedautinh12]

EEDI2CUDA ported from Vapoursynth
https://github.com/AmusementClub/VapourSynth-EEDI2CUDA/issues/3#issuecomment-899069883

[kedautinh12]

EEDI2CUDA now have x86 ver
https://github.com/AmusementClub/VapourSynth-EEDI2CUDA/actions/runs/1135300628

[kedautinh12]

New fork frfun7 from pinterf, but still don't have HBD
https://github.com/pinterf/Frfun7/releases

[real.finder]

since there are no issues tab in https://github.com/pinterf/Average I will report it here

as said here (https://github.com/AviSynth/AviSynthPlus/issues/226#issuecomment-910076325), Average seems not work with avs+ native array
https://i.postimg.cc/4ddwGBQK/Untitled.png (https://postimages.org/)

don't know if it can be updated without break compatibility

[pinterf]

New version: Average.
https://github.com/pinterf/Average/releases/tag/0.95
v0.95 (20211008)
- add AVX2 routines
- accept parameter as a nested array stuffed into the first parameter (AVS 3.7.1)
- pass over frame properties if any
- Source: update to VS2019, clang-cl option, gcc friendly
- add CMake build environment, linux build instructions

[real.finder]

New version: Average.
https://github.com/pinterf/Average/releases/tag/0.95


thanks! seems work fine

[Julek]

About Checkmate plugin: I wanted to point out that the wiki shows 5 (http://avisynth.nl/index.php/Checkmate) as the default tthr2 but it seems that the correct is 0 (https://github.com/tp7/checkmate/blob/master/checkmate/checkmate.cpp#L293).

[LigH]

Unimportant suggestion: I noticed that ResampleHQ has a few ToDo's left. Just in case of extreme boredom.

Possibly last sources (without binary) mentioned here (https://forum.doom9.org/showthread.php?p=1952217#post1952217).

[LigH]

More interesting for me: AudioLimiter (http://avisynth.nl/index.php/AudioLimiter) by dimzon is Closed Source but well documented so could possibly be recreated from scratch.

In addition to the surely useful hyperbolic tangent as sigmoid function (which can be calculated as ratio of difference and sum of powers to base e (https://en.wikipedia.org/wiki/Hyperbolic_functions#Exponential_definitions)), in my own Booster application I also used a scaled arcus tangent and very quick and simple sigmoid x/|x+1|.

[LigH]

Does anyone know a source template for an AviSynth audio plugin that I might try to implement it myself, despite having hardly any practical experience in C/C++ coding? For someone with experience, I guess it might only take a weekend...

[tormento]

Unimportant suggestion: I noticed that ResampleHQ has a few ToDo's left. Just in case of extreme boredom
I tried the x64 version and doesn't actually work too, at least on my computer (no AVX2).

[Emulgator]

Does anyone know a source template for an AviSynth audio plugin that I might try to implement it myself...
I was thinking about SoundOut(), but the source has moved:
https://forum.doom9.org/showthread.php?p=925907#post925907
And Wilbert's update for 2.6:
https://forum.doom9.org/showthread.php?p=1654982#post1654982
Wilbert is around, you may ask him.
BTW SoundOut 1.1.1 .wav out collapses for me now using a recent AvsPmod32 2.7.7.9,
.flac is fine, .wv seems fine... and a 64bit-version would be nice too.

[ChaosKing]

Does anyone know a source template for an AviSynth audio plugin that I might try to implement it myself, despite having hardly any practical experience in C/C++ coding? For someone with experience, I guess it might only take a weekend...

Is Vapoursynth, but maybe it can be helpfull too (not much code) https://github.com/dubhater/vapoursynth-damb

[LigH]

Sorry, no, VapourSynth is based on Python, which I know even less than C.

[ChaosKing]

Sorry, no, VapourSynth is based on Python, which I know even less than C.

But the plugin is written in cpp...

[LigH]

But it is for a VapourSynth plugin interface. The AviSynth plugin interface is probably different, I would assume.

I saw that the AviSynthPlus repo comes with sources of the Shibatch Sampling Rate Converter (SSRC), that might be a convenient base to derive from.
But I also noticed that I won't be able to do that, with all the C++ interface syntax I am not used to, and related compiler control files...

[Jamaika]

But it is for a VapourSynth plugin interface. The AviSynth plugin interface is probably different, I would assume.

AviSynth in VapourSynt is a mod of old version V3.
I am annoyed by plugins in ffmpeg AviSynth/VapourSynt opened as shared AviSynth/VapourSynt DLL.
In AviSynth_c you have all the functions you can open but warmigs are.
avisynth_c.cpp: In function 'int avs_is_yv24(const AVS_VideoInfo*)':
avisynth_c.cpp:66:63: warning: bitwise operation between different enumeration types '<unnamed enum>' and '<unnamed enum>' is deprecated [-Wdeprecated-enum-enum-conversion]
66 | return (p->pixel_type & AVS_CS_PLANAR_MASK) == (AVS_CS_YV24 & AVS_CS_PLANAR_FILTER);
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
Stream audio
static int avisynth_create_stream_audio(AVFormatContext *s, AVStream *st)
{
AviSynthContext *avs = (AviSynthContext *)s->priv_data;

st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
st->codecpar->sample_rate = avs->vi->audio_samples_per_second;
st->codecpar->ch_layout.nb_channels = avs->vi->nchannels;
st->duration = avs->vi->num_audio_samples;
avpriv_set_pts_info(st, 64, 1, avs->vi->audio_samples_per_second);

if (avs_get_version(avs->clip) >= 10)
av_channel_layout_from_mask(&st->codecpar->ch_layout,
avs_get_channel_mask(avs->vi));

switch (avs->vi->sample_type) {
case AVS_SAMPLE_INT8:
st->codecpar->codec_id = AV_CODEC_ID_PCM_U8;
break;
case AVS_SAMPLE_INT16:
st->codecpar->codec_id = PCM(S16);
break;
case AVS_SAMPLE_INT24:
st->codecpar->codec_id = PCM(S24);
break;
case AVS_SAMPLE_INT32:
st->codecpar->codec_id = PCM(S32);
break;
case AVS_SAMPLE_FLOAT:
st->codecpar->codec_id = PCM(F32);
break;
default:
av_log(s, AV_LOG_ERROR,
"unknown AviSynth sample type %d\n", avs->vi->sample_type);
avs->error = 1;
return AVERROR_UNKNOWN;
}
return 0;
}

Modyfity cpp plugin ffmpeg static avisynth
https://www.sendspace.com/file/znalx3

[LigH]

Would you be able to help me building an audio plugin?

So far I already asked 3 people and did not get one reply yet.

[LigH]

A little teaser of what I would like to get implemented as AviSynth audio plugin; it already works as CLI application:

https://www.ligh.de/pics/BoostV_curves.png

I wrote that in FreePascal (Lazarus). I cannot write it in C++.

[LigH]

I am now halfway successful. Could build plugins in MSYS2/MinGW and GCC 14.2 (M-AB-S interactive shell).

Only flaw: Despite linker flags containing parameters to statically link some GCC libs, the resulting plugins still depend on them.

CMakeCache contains
CMAKE_MODULE_LINKER_FLAGS:STRING=-D_FORTIFY_SOURCE=2 -fstack-protector-strong -mtune=generic -O2 -pipe -D__USE_MINGW_ANSI_STDIO=1 -static-libgcc -static-libstdc++
CMAKE_SHARED_LINKER_FLAGS:STRING=-D_FORTIFY_SOURCE=2 -fstack-protector-strong -mtune=generic -O2 -pipe -D__USE_MINGW_ANSI_STDIO=1 -static-libgcc -static-libstdc++

According to AVSmeter, the 32-bit plugin misses libgcc_s_dw2-1.dll, the 64-bit plugin misses libgcc_s_seh-1.dll
_

PS: Even when adding those (and libwinpthread-1.dll) to the plugins directory, it is still not useable as AviSynth plugin.

[LigH]

It has been done. In MSVC it worked.

AudioBoost plugin: binaries (https://www.ligh.de/software/AudioBoost.7z) / min. docs (https://www.ligh.de/software/AudioBoost.html) / repo (https://github.com/LigH-de/AudioBoost)

Might replace dimzon's AudioLimiter.

[Emulgator]

Hi LigH, congrats !

I did not test it yet, so just a tip about the wording to avoid ambiguities:
In audio the terms "Limiter, Compressor" are reserved for devices/algorithms which regulate gain and avoid distortion at any cost
(the regulation phase excluded, here a carefully chosen lookahead/time constant combo may serve to make distortion unnoticeable)

Going from the graphs you published I would guess that your algo remaps sample values, not gain,
so can be seen now as a soft clipper with selectable curves which is in any case nice to have.

I see arbitrary curves coming, or introduction of a sidechain input.
In the end you will be on the way to LigH's Arbitrary Audio Modulator allowing stranger audio FX like ring modulation etc.

[Jamaika]

What does it mean?
[avisynth @ 0000023dbcab78e0] Input audio sample format must be float.
I have no idea how to use it.
AudioBoost(4.0, 0.95, 1, true)

#define SAMPLE_FLOAT ???

[LigH]

http://avisynth.nl/index.php/ConvertAudio
ConvertAudioToFloat()
AudioBoost()

[Jamaika]

I don't know if it works correctly but you can test it. :D
https://www.sendspace.com/file/1vnpbw

AVISource("AudioBoost.avi")

# resize the dimensions of the video frame to 320x240
LanczosResize(320, 240)
ConvertAudioToFloat()
AudioBoost(4.0, 0.95, 1, true)

[tormento]

Is there any modern filter to dehalo properly?

I have tried many and some don't accept YV24 or they simply work so and so.

Any help is welcome.

P.S: Tried FineDehalo and DeHaloAlpha and, oh my god, parameters are such a mess for me.

[takla]

Is there any modern filter to dehalo properly?


FFT3DFilter(sigma=0, bt=-1, dehalo=0.5)

If bt=-1 doesn't work use bt=1

[Selur]

LOL, I never noticed that ff3dfilter has a dehalo option. :D (okay, at least on it's own without masking it does not seem that useful)

[takla]

(okay, at least on it's own without masking it does not seem that useful)

🤷 I found it useful when I used it in the past, where every other DeHalo overcomplicated things for a worse result.

[Selur]

Did a few tests and to me DeHalo_alpha and FineDeHalo both worked better on my sources.
Did you use some masking? Or did you use cartoon/anime content, where fine details are often a rare thing?

[takla]

Did you use some masking? Or did you use cartoon/anime content, where fine details are often a rare thing?

No masking. The source was real world camera footage of a PAL TV show. The ringing was very bad. I think they used early digital cameras. The dehalo from FFT3DFilter produced a gloomy like image which I much preferred.

I think I also denoised chroma (for DeRainbow) so FFT3D really came in handy here.

I'd share a clip, but I need to rebuild my desktop, which will take me some months. (Waiting for Black Friday or similar good deal on some parts)

[LigH]

AudioBoost 0.2 (https://github.com/LigH-de/AudioBoost/releases/tag/0.2) is now available with both interfaces (C++/2.6-MSVC and C/2.5).

[Jamaika]

FFT3DFilter(sigma=0, bt=-1, dehalo=0.5)

If bt=-1 doesn't work use bt=1
How to test FFT3DFilter functions for gcc with ffmpeg? Is it possible with win64?
I`m testing:
https://github.com/Klimax/FFT3DFilter
https://github.com/HomeOfAviSynthPlusEvolution/neo_FFT3D
https://github.com/pinterf/fft3dfilter

No success:
AviSource("input_yuv420p.avi", audio=false)
neo_fft3d(sigma=0, bt=1, dehalo=0.5) or
FFT3DFilter(sigma=0, bt=1, dehalo=0.5) <-- Klimax

ffplay + plugins
https://www.sendspace.com/file/tuoe6w