Avisynth+ plugin modernization efforts

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