Log in

View Full Version : Port of NNEDI under new v2.6 AVS API

Pages : [1] 2 3 4 5 6 7 8 9 10 11 12 13
jpsdr
15th January 2014, 16:27
As sugested, i'll open a specific thread for this.

All credit goes of course to Tritical, original creator of the plugin.
The main purpose for what i've done this, was to have an x64 version of the plugin.
The work mainly consisted on putting outside inline ASM, creating an x64 compliant C code, and port ASM function to x64.
Doing this, the API has also be updated to the v2.6, allowing other updates of the plugin, like more input format supported.

This port is made from NNEDI3 v0.9.4, so i've decided to use 0.9.4.x for version numbers.

Current version : 0.9.4.68

Sources are here (https://github.com/jpsdr/NNEDI3).
Binaries are here (https://github.com/jpsdr/NNEDI3/releases/download/0.9.4.68/NNEDI3_v0_9_4_68.7z).

Change list:
04/09/2025 v0.9.4.68
* Use nullptr instead of NULL.

24/07/2025 v0.9.4.67
+ Add more AVX512 code path, some fixes on asm and a long existing crash.

18/07/2025 v0.9.4.66
+ Add AVX512 code path.

13/03/2025 v0.9.4.65
+ Update for new parameters on some resamplers.

08/01/2025 v0.9.4.64
+ Update to new AviSynth+ header.

19/11/2023 v0.9.4.63
+ Update to new AviSynth+ header.

23/02/2023 v0.9.4.62
+ Update to new AviSynth+ header.

20/11/2022 v0.9.4.61
+ Update on threadpool, no user limit (except memory).

06/02/2022 v0.9.4.60
* Fix in threadpool when using prefetch, Add negative prefetch for triming, read Multithreading.txt or Multithreading chapter here.

30/06/2021 v0.9.4.59
* Fix in threadpool if you have too much cores.

30/04/2021 v0.9.4.58
+ Add new resampler in nnedi3_rpow2 internal resizers.
+ Update to the new avisynth headers.
* Minor code change for threadpool update.

02/08/2020 v0.9.4.57
+ Add new resamplers in nnedi3_rpow2 internal resizers.

17/07/2020 v0.9.4.56
* Fix issue in 4:2:0 when dh=false and height not mod 4.

05/05/2020 v0.9.4.55
* Fix issue introduced in previous version.

27/04/2020 v0.9.4.54
+ Update to the new avisynth headers.
* Minor code change for threadpool update.
* Some cleanup.

31/05/2019 v0.9.4.53
* Minor code change for threadpool update.

30/05/2019 v0.9.4.52
+ Update in the threadpool, add ThreadLevel parameter.

27/05/2018 v0.9.4.51
* Fix bug in asm PlanarFrame YUY2to422.

05/04/2018 v0.9.4.50
+ Optimized CPU placement if SetAffinity=true for prefetch>1 and prefetch<=number of physical cores.
* SetAffinity back to default false.

08/03/2018 v0.9.4.49
* Fix AVX2 path code.
* Fix some potential issue with range modes.
* Change some default value setting.

23/11/2017 v0.9.4.48
* Put back process whole plane by whole plane.
* Minor change in threadpool interface.

23/08/2017 v0.9.4.47
+ Fix possible deadlock on threadpool destructor.

10/08/2017 v0.9.4.46
+ Forgot to add AVX path code on planarframe.

09/08/2017 v0.9.4.45
+ Fix Threadpool.
+ Add AVX path code.
* Revert to original MT multi-planar mode, may improve MT efficiency.

14/06/2017 v0.9.4.44
* Minor fix.

02/06/2017 v0.9.4.43
* Few changes in the threadpool and small fix.

19/05/2017 v0.9.4.42
* Minor change in the threadpool.

10/05/2017 v0.9.4.41
* Fix crash in PlanarFrame for YUYV.

11/01/2017 v0.9.4.40
* Fix bug in x64 AVX2 asm code.

28/03/2017 v0.9.4.39
* Some small optimizations on PlanarFrame asm for YUYV.

20/03/2017 v0.9.4.38
* Some cleanup and small modifications on PlanarFrame.
* Update AVS+ header.

05/03/2017 v0.9.4.37
* Remove the use of asmlib.
* Some little bug fixes.
+ Add an opt intermediate value (4 for AVX).
+ Use of YMM registers in case of AVX2 (or more) CPU, and some little others cleanup/speedup.

24/01/2017 v0.9.4.36
* Set range mode default to 1. Apply range only on last step.
+ Add range mode 4.

20/01/2017 v0.9.4.35
+ Fix crash on x64 version introduced in v0.9.4.34.
+ Fix prescreener issue on flat area with value of 255.

17/01/2017 v0.9.4.34
+ Add range parameter.

07/01/2017 v0.9.4.33

+ Add support for 9..16 bits and float data formats (thanks to vapoursynth port).
+ Add FMA3 and FMA4 functions on some parts (thanks to vapoursynth port).
+ Add sleep and prefetch paremeters.
+ Fix bug in YUY2 x64 ASM code.

05/12/2016 v0.9.4.32

+ Update to new avisynth header and add support for RGB32, RGBPlanar and alpha channel on avs+.
+ Add A paremeter (for alpha channel) on nnedi3.
* Update asmlib to 2.50
* Use /MD (dynamic link) instead of /MT (static link) for building.

14/10/2016 v0.9.4.31

* Use Mutex instead of CriticalSection on some places and some changes in the threadpool interface.

12/10/2016 v0.9.4.30

* Remove CACHE_DONT_CACHE_ME and small changes in the threadpool interface.

11/10/2016 v0.9.4.29

+ Fix deadlock case in Threadpool interface.

06/10/2016 v0.9.4.28

+ Attempt to fix deadlock with MT of avisynth.

02/09/2016 v0.9.4.27

* Minor fixes and don't use the threadpool if number of threads=1.
+ Add several parameters to control and tune the creation of the threadpool.

30/08/2016 v0.9.4.26

* Update to my threadpool interface.
+ Add a thread parameter for the resampler if use of the MT resamplers.

12/08/2016 v0.9.4.25

* Use Spline36ResizeMT if available.

21/07/2016 v0.9.4.24

* Don't use SetMTMode for now to set MT mode
* Update to new avisynth header.

15/07/2016 v0.9.4.23

* Update to new avisynth header.

30/05/2016 v0.9.4.22

+ Fix for MT version of avisynth.

17/04/2016 v0.9.4.21

* Update to asmlib 3.26.
+ Fix XP build with VS2015.

05/09/2015 v0.9.4.20

* Minor changes, should handle negative pitch properly.

26/08/2015 v0.9.4.19

+ Implement use of asmlib.

25/08/2015 v0.9.4.18

* Fix 4:1:1 chroma shift.
* Modification of the memory transfer functions.

11/08/2015 v0.9.4.17

* Change the order between turnl/r and nnedi3 calls in nnedi3_rpow2 to optimize speed.
* Remove memcpy_amd and use memcpy instead.

10/08/2015 v0.9.4.16

+ Add csresize parameter, and chroma shift adjustment according resize is enabled by default.
* Fix regression on center adjustment.

09/08/2015 v0.9.4.15

* Change default value of mpeg2 to false, and keep exact
previous behavior in that case (but doesn't put back chroma shift issue ^_^).

09/08/2015 v0.9.4.14

+ Add resize adjustment chroma shift in case of MPEG-2 subsampling.
* Faster RGB24 mode always.
+ Add mpeg2 parameter.

08/08/2015 v0.9.4.13

* Correction of chroma shift once for all this time.
* Faster RGB24 mode if FTurn is usable.
* Fix YV411 support.

06/08/2015 v0.9.4.12

* More checks on use of FTurn.
* Fix regression on YUY2 introduced in previous release.

31/07/2015 v0.9.4.11

+ Correction of chroma shift value for 4:2:x color modes.
+ Add YV411 support.

25/05/2015 v0.9.4.10

* Integration of commits coming from Vapoursynth version, thanks to Myrsloik.

10/05/2015 v0.9.4.9

* Bug correction in x64 ASM file, thanks to jackoneill and HolyWu.

13/03/2015 v0.9.4.8

* Update to last AVS+ header files.

26/01/2014 v0.9.4.7

* Little correction in YV24 and Y8 support for nnedi3_rpow2.

17/01/2014 v0.9.4.6

* Little YV16 optimization.

16/01/2014 v0.9.4.5

* Updated YV16 support for nnedi3_rpow2, now fast and direct, not tweaked by going to YUY2.

15/01/2014 v0.9.4.4

* Some few little optimizations.
* Trick YV16 support in nnedi3_rpow2 by working internaly in YUY2 mode to speed-up.

14/01/2014 v0.9.4.3

+ Add fturn support.

13/01/2014 v0.9.4.2

+ Add Y8, YV16 and YV24 support.

03/01/2014 v0.9.4.1

* Move out all inline ASM code in external files, update code to build x64 version.
* Update interface to new avisynth 2.6 API.
- Avisynth 2.5.x not supported anymore.

Original version 0.9.4

==================================================================

Multi-threading information

CPU example case : 4 cores with hyper-threading.

If you leave all the multi-threading parameters to their default value, it's set to be "optimal" when you're not using prefetch or if you are under standard avisynth, all the logical CPU will be used.
If you put SetAffinity to true it will allocate the threads on the CPU contiguously. Physical CPU 1 will have threads (0,1), ... physical CPU 4 will have threads (6,7), allowing optimal cache use. Make test to see what's best for you.

Now, if you are using prefetch on your script, things are different !
If you're using it with the max number of CPUs (8 in our exemple case), you still can make tests, but i would strongly advise to disable the internal multi-threading by using threads=1. In this case, there is no threadpool created, and all the other multi-threading related filter parameters have no effect, even prefetch.
If you're using prefetch on your script, with less than your CPU number, you may want to try to mix the external and internal mutli-threading, setting the internal multi-threading to a lower number of threads, and setting the prefetch parameter of the filter. This parameter will set the number of internal threadpool created, the best is to match the prefetch script value. If you don't set it (leave it to 1) or set a lower value than prefetch on your script, you'll have several instances (or GetFrame) created, but they'll not be running efficiently, because each instance (or GetFrame) will spend time waiting for a threadpool to be avaible, if not enough were created.
Unfortunately, as things are now, i have no way of knowing the prefetch value used in the avisynth script at the time i need the information, this is why you have to use the prefetch parameter in the filter.
In our CPU exemple case, you can have things like :

filter(...,threads=1)
prefetch(8)

or

filter(...,threads=2,prefetch=4)
prefetch(4)

or

filter(...,threads=4,prefetch=2)
prefetch(2)

or even

filter(...,threads=3,prefetch=4)
prefetch(4)

if you want to boost and go a little over your total CPU number.

Also, if your prefetch is not higher than your number of physical cores, you can try to put SetAffinity to true, but in that case, you have to set MaxPhysCore to false. The threads of each pool will be set on CPUs by steps.
For exemple, in our case :

filter(...,threads=2,prefetch=4,SetAffinity=true,MaxPhysCore=false)
prefetch(4)

Will create 4 pool of 2 threads, with the following :
pool[0] : threads(0 -> 1) on CPU 1.
pool[1] : threads(0 -> 1) on CPU 2.
pool[2] : threads(0 -> 1) on CPU 3.
pool[3] : threads(0 -> 1) on CPU 4.

filter(...,threads=4,prefetch=2,SetAffinity=true,MaxPhysCore=false)
prefetch(2)
Will create 2 pool of 4 threads, with the following :
pool[0] : threads(0 -> 1) on CPU 1.
pool[0] : threads(2 -> 3) on CPU 2.
pool[1] : threads(0 -> 1) on CPU 3.
pool[1] : threads(2 -> 3) on CPU 4.

Negative prefetch
The possibility to put negative prefecth to tune the prefetch parameter to optimal value has been added. The filter will throw an error if the number is not high enough to avoid waiting when requesting internal threadpool. For this to work properly, you have to put negative prefetch on ALL the filters of your script, and also ALL instances of the same filter.

Exemple :
filter(...,threads=2,prefetch=-2)
prefetch(2)
You'll see an error.

But with :
filter(...,threads=2,prefetch=-3)
prefetch(2)

You'll see no error, so the optimal is :
filter(...,threads=2,prefetch=3)
prefetch(2)

Once you've tune, put back a positive value.
jpsdr
15th January 2014, 18:17
Despite all my researches in the code, and some tests, YV16 of nnedi3_rpow2 is slow........ even YV24 is way faster ! And YUY2 is also fast. No idea why, so, for now, i'll trick the YV16 support for nnedi3_rpow2 by converting internaly to YUY2 (and back to YV16 in output). It's actualy a way faster than working directly with YV16.
jpsdr
15th January 2014, 20:38
Ok, i've made tests.
Test were made using an YV12 640x480 avi file.

Script used is the following :

SetMemoryMax(64)
AVISource("Test.avi",False,"YV12")
SetPlanarLegacyAlignment(True)
#ConvertToYUY2()
#ConvertToYV16()
#ConvertToYV24()
#ConvertToY8()
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=960,fheight=720,nsize=0,nns=3,qual=2)

It allows me to quick change ouput format for testing.

Results with v0.9.4.3 :
Y8,YV12,YUY2,YV24 : fast.
YV16 : Very slow !

So, i've made modifications to my code to test several cases :
Converting internaly YV16->YUY2(process)->YV16 either in nnedi3 or nnedi3_rpow2.

If YV16->YUY2(process)->YV16 is made in nnedi3, and nnedi3_rpow2 process YV16 without change, result is slow. First hint : Slowness is not because of nnedi3 code.

If YV16->YUY2(process)->YV16 is made in nnedi3_rpow2, and nnedi3 process YV16 without change, result is fast.

Issue is within the YV16 process code of nnedi3_rpow2. Code is :

for (int i=0; i<ct; ++i)
{
v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
v = env->Invoke(turnRightFunction,v).AsClip();
// always use field=1 to keep chroma/luma horizontal alignment
v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
v = env->Invoke(turnLeftFunction,v).AsClip();
}

I've first removed both turn : Result was fast.
If i put back either one of the turn, result is still fast, but... it seems a little slower, not realy obvious. If i put back both, result is very slow.

So, here i'm at a point i don't know what to do to solve this issue, i'm totaly :confused: !!
I need help from someone who master avisynth a looot better than me for solving this case, better than what i've done for now (doing YV16->YUY2(process)->YV16).
TurboPascal7
15th January 2014, 21:20
Turning YV16 internally requires full chroma resampling, i.e. a call to internal resizer (most likely two, but I don't remember how exactly it's implemented). Of course it's slower than not calling resizer.
You can try processing planes separately, either by converting to Y8 or using that internal PlanarFrame thingy. YUY2 is fast because it's doing exactly that, if my memory doesn't lie.
PetitDragon
15th January 2014, 22:47
Change list:
15/01/2014 v0.9.4.4
+ Some few little optimizations.
* Trick YV16 support in nnedi3_rpow2 by working internaly in YUY2 mode to speed-up.

14/01/2014 v0.9.4.3

+ Add fturn support.

13/01/2014 v0.9.4.2

+ Add Y8, YV16 and YV24 support.

03/01/2014 v0.9.4.1

+ Move out all inline ASM code in external files, update code to build x64 version.
+ Update interface to new avisynth 2.6 API.
- Avisynth 2.5.x not supported anymore.

Original version 0.9.4

Formidable!:thanks:
jpsdr
15th January 2014, 23:17
Turning YV16 internally requires full chroma resampling
... Ok. YV12 and YV24 are fast because chroma planes are square, and not YV16, wich requires resampling...
I didn't see that indeed. I was wondering why YV24 whith more data than YV16 was a lot faster !!
I see, thanks. I'll have to do something similar to what is done with YUY2 : extract each plane... I'll try that.
Gavino
16th January 2014, 00:03
As well as the performance hit, there is also a quality loss if staying in YV16 as TurnRight and TurnLeft are not lossless for YV16 chroma. So extracting chroma to Y8 is better for both speed and quality.
jpsdr
16th January 2014, 00:47
Updated YV16 support, now better, and created a stable and final (i hope) release.
jpsdr
16th January 2014, 18:23
I have a little question.
For now, i'm doing this :

AVSValue vy = env->Invoke("ConvertToY8",v).AsClip();
AVSValue vu = env->Invoke("UtoY",v).AsClip();
vu = env->Invoke("ConvertToY8",vu).AsClip();
AVSValue vv = env->Invoke("VtoY",v).AsClip();
vv = env->Invoke("ConvertToY8",vv).AsClip();

If i'm doing the code below, will it be faster ?

AVSValue vu = env->Invoke("UtoY",v).AsClip();
vu = env->Invoke("ConvertToY8",vu).AsClip();
AVSValue vv = env->Invoke("VtoY",v).AsClip();
vv = env->Invoke("ConvertToY8",vv).AsClip();
v = env->Invoke("ConvertToY8",v).AsClip();

In that last case, vy doesn't exist anymore, and i'll use v instead.
Question asked differently : Is there a better way to convert/transform v directly in Y8 ?
Because transforming an YV16 data to Y8 is instantaneous. I want if possible avoid an unecessary memory transfer of planar Y. And i have the feeling (but maybe totaly wrong), that doing something like "v = v(converted)" will create a transfer. If there was something like "v.convert", i'll had no wories...
DarkSpace
16th January 2014, 19:18
I have a little question.
For now, i'm doing this :

AVSValue vy = env->Invoke("ConvertToY8",v).AsClip();
AVSValue vu = env->Invoke("UtoY",v).AsClip();
vu = env->Invoke("ConvertToY8",vu).AsClip();
AVSValue vv = env->Invoke("VtoY",v).AsClip();
vv = env->Invoke("ConvertToY8",vv).AsClip();

If i'm doing the code below, will it be faster ?

AVSValue vu = env->Invoke("UtoY",v).AsClip();
vu = env->Invoke("ConvertToY8",vu).AsClip();
AVSValue vv = env->Invoke("VtoY",v).AsClip();
vv = env->Invoke("ConvertToY8",vv).AsClip();
v = env->Invoke("ConvertToY8",v).AsClip();

In that last case, vy doesn't exist anymore, and i'll use v instead.
Question asked differently : Is there a better way to convert/transform v directly in Y8 ?
Because transforming an YV16 data to Y8 is instantaneous. I want if possible avoid an unecessary memory transfer of planar Y. And i have the feeling (but maybe totaly wrong), that doing something like "v = v(converted)" will create a transfer. If there was something like "v.convert", i'll had no wories...

Why not use UToY8() / VToY8() directly instead, if your filter can handle Y8 and you require AVS 2.6 anyway?
The wiki page (http://avisynth.nl/index.php/UToY) also mentions that UToY8() is faster than UToY().ConvertToY8().
jpsdr
16th January 2014, 20:41
Because i didn't know them. The HTML doc installed with avisynth is apparently not up to date. I'll change that in next release, thanks for the information. Question of directly converting (like "v.convert" instead of "v = convert(v)") is still open.
DarkSpace
16th January 2014, 21:28
Well, I don't know much about this, but you have

AVSValue vy = env->Invoke("ConvertToY8",v).AsClip();
AVSValue vu = env->Invoke("UtoY8",v).AsClip();
AVSValue vv = env->Invoke("VtoY8",v).AsClip();

versus

AVSValue vu = env->Invoke("UtoY8",v).AsClip();
AVSValue vv = env->Invoke("VtoY8",v).AsClip();
v = env->Invoke("ConvertToY8",v).AsClip();

here. Now as I see it (I'm not an AviSynth developer at all and I may be totally wrong, I'm just using logic without knowledge), you have the choice between
1) certainly copying the y plane of the clip in memory, which leads to more memory consumption (because clip v is still assigned) and
2) perhaps copying the y plane of the clip in memory, without increased memory consumption (because clip v is reassigned).
(By the way, if it was me, I'd call the input clip "y" in the second example, so I can call the other two clips "u" and "v".)

I do hope that someone who knows more about this subject will be able to give you a better answer.
jpsdr
16th January 2014, 21:38
Actually, the second is at worst identical to first, or with luck beter, but i don't think it can be worse. It's exactly what i intended to do, unless i found something like "v.convert", to replace " v =...", or a syntax case specific where input and output are the same, if it's possible.
DarkSpace
16th January 2014, 23:45
Actually, the second is at worst identical to first, or with luck beter, but i don't think it can be worse.
Nice, then my deduction was actually correct!
As for a Convert(v, "Y8") function, I have no idea if something like this exists. Maybe someone qualified can answer that...
Gavino
17th January 2014, 00:47
ConvertToY8(), for planar input, does not copy the Y plane contents - it simply creates a new frame sharing the original frame buffer (similar to what Crop() does).

Whether you assign the result to a new variable or the same one makes no difference.
jpsdr
17th January 2014, 09:33
Ok, thanks for these informations.
jpsdr
17th January 2014, 18:05
A new version with a little update on YV16 format. Finaly a good probability of "final" release.
hydra3333
19th January 2014, 07:37
a couple of end-user questions.
- is it compatible with TSP's avisynth MT 2.5.7 32 bit ?
- if not, is there any chance of a version which is compatible ? :)
jpsdr
19th January 2014, 10:27
@hydra3333
No, the use of new avs v2.6 API (which allow support of new color formats) make it not compatible, and no chance.
But if it's to use with v2.5.7, just use the original v0.9.4, there is no point in using this version. There is no change and so neither improvement in the algorithm itself, so result is exactly the same. And also there is no speed improvement in the orignal supported color formats.
sqrt(9801)
25th January 2014, 16:47
Hi.

It seems that there's some kind of horizontal shift (if that's the correct term) when using nned3_rpow2 with rfactor>2 on Y8 or YV24 clips.
Not sure whether it has anything to do with the chroma shift issue present in Tritical's latest version.

Tested with the VS2010 build on AviSynth 2.6a5 (Groucho2004's ICL10 build), Win7 x86.
SEt
25th January 2014, 21:36
Shift compensation in original nned3_rpow2 is wrong. I hope my transform in latest nnedi3x_rpow2 is correct – try it.
jpsdr
26th January 2014, 00:05
I've kept original code, if something was incorect in it, it's still here. If you know what to fix, you can tell me. I think you're probably talking about the vshift and hshift value. If there is better values than actual ones, i'm all ears.
SEt
26th January 2014, 00:09
As I said, my version of shift compensation can be found in nnedi3x_rpow2. Feel free to check the changes.
jpsdr
26th January 2014, 09:45
@SEt
Ok, i've tried, but i don't understand your code and how it's working, i'm unable to connect/relate it with the existing C code, so, i've no idea what the changes are...
Just a little question, out of curiosity. How have you been able to reduce the size of the weights trained datas to a so small value ? The datas are 12,9MB, and compression with zip, rar or 7zip is not very efficient, size stay at leat at 8MB, and your dll file is only 790kB. Where have you put the neural network weights trained datas ?
Unless... of course, i didn't get the right file. I've downloaded the nnedi3ocl_20131208.zip file.

Edit : I think i begin to understand a very little. If i understand properly, all this part is done in the .avsi file. It seems that you're working with Y/C planar separately, during all the process, even the resize if cshift is asked, contrary to original, where cshift is not made sperately for Y/C. I'll try to dig more and to understand more.
jpsdr
26th January 2014, 10:58
@sqrt(9801)
Original code has a fixed shift, independant of rfactor, for RGB24. I've applied the same for YV24 and Y8.
But, maybe it's related to something else as you said changes are dependant of rfactor. I'll put a 0.9.4.7 later, i think i may have done a little thing improperly with YV24 and Y8. Well, indeed, i didn't realy know how to do, but you may have given me the answer. When avaible, try the new version and tell me if things changes. And, it's probably not related to the chroma shift.
sqrt(9801)
27th January 2014, 00:01
I just gave it a shot. The issue seems to have been resolved.

Nice job. :)
jpsdr
27th January 2014, 09:28
Good, otherwise, i would have no idea what to do...
lansing
28th January 2014, 09:50
what's with the intel compiled version? Is it faster compares to other if I have a intel cpu?
jpsdr
28th January 2014, 12:59
As said in txt, it's compiled with Intel compiler, targeting a specific cpu. Intel compiler is theoricaly better, but i've not made benchmark, so i don't realy know if there is real improvement in this case.
jpsdr
2nd February 2014, 12:48
I've made a little benchmark with v0.9.4.7, out of curiosity.
Input video : 720x480 YV12 Ut Video codec.
CPU : i7@980
OS :
- Windows XP SP3 for x86.
- Windows XP64 SP2 for x64.

Results :

[General info]
Log file created with: AVSMeter 1.7.5 (AVS 2.6, x64)
Avisynth version: AviSynth+ 0.1 (r1576, x64)


[Clip info]
Number of frames: 4077
Length (hhh:mm:ss.ms): 000:02:50.045
Frame width: 960
Frame height: 720
Framerate: 23.976 (24000/1001)
Interlaced: No
Colorspace: YV12


[Runtime info]
Frames processed: 4077 (0 - 4076)
FPS (min | max | average): 32.14 | 99.02 | 59.54
CPU usage (average): 50%
Thread count: 38
Physical Memory usage (peak): 92 MB
Virtual Memory usage (peak): 93 MB
Time (elapsed): 000:01:08.476


[Script]
SetMemoryMax(64)
AVISource("Ken - 101.avi",False,"YV12").SetPlanarLegacyAlignment(True)
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=960,fheight=720,nsize=0,nns=3,qual=2)


[General info]
Log file created with: AVSMeter 1.7.5 (AVS 2.6, x86)
Avisynth version: AviSynth 2.60, build:Sep 18 2013 [17:36:36]


[Clip info]
Number of frames: 4077
Length (hhh:mm:ss.ms): 000:02:50.045
Frame width: 960
Frame height: 720
Framerate: 23.976 (24000/1001)
Interlaced: No
Colorspace: YV12


[Runtime info]
Frames processed: 4077 (0 - 4076)
FPS (min | max | average): 27.97 | 65.55 | 45.79
CPU usage (average): 40%
Thread count: 37
Physical Memory usage (peak): 76 MB
Virtual Memory usage (peak): 79 MB
Time (elapsed): 000:01:29.034


[Script]
SetMemoryMax(64)
AVISource("Ken - 101.avi",False,"YV12").SetPlanarLegacyAlignment(True)
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=960,fheight=720,nsize=0,nns=3,qual=2)
Groucho2004
2nd February 2014, 13:01
[Script]
SetMemoryMax(64)

Just curious - Why did you choose this value?
TurboPascal7
2nd February 2014, 13:03
I'm not sure what you're benchmarking there. nnedi3_rpow2 uses some built-in functions internally that got faster in avs+. If you want to compare performance on x64 vs x86, you need to use same avisynth versions.
jpsdr
2nd February 2014, 16:39
@Groucho2004
720x480 in YV12 => 1 frame = 506k.
64MB cache max => cache for around 128 frames.
I think it's big enough for what the script is doing.
(But, maybe i'm wrong).

@TurboPascal7
Ok.
Reel.Deel
7th June 2014, 03:09
Hi jpsdr,

I was wondering if your updated nnedi3 contains -Vit-'s threading fixes (http://forum.doom9.org/showpost.php?p=1503034&postcount=691)? For QTGMC I use his modded plugins almost exclusively and have not had any problems so far. He also compiled some for Avisynth 2.6 (http://forum.doom9.org/showpost.php?p=1568142&postcount=1126) but they're no longer compatible with Avisynth 2.6 Alpha4/5. Anyways I'm just curious, if this is no longer a relevant issue please excuse me.
jpsdr
7th June 2014, 10:28
Unfortunately i've no idea. I didn't change the code of the threading part of nnedi3, fortunately for me there was no issue with x64, because for now, threading is still an unknow field for me... All i can say is to try.
When i decided to try to port, i was lucky there was just some asm internal functions to put external and addapt to x64 masm, because that was a field not unknow to me.
Reel.Deel
7th June 2014, 14:44
I checked the difference between vanilla nnedi3 and -Vit-'s mod and the only thing that changed was the 'avisynth.h' and 'nnedi3.vcxproj' files.
For convenience I've uploaded the differences:

avisynth.h (https://dl.dropboxusercontent.com/s/l50ovgsuw44gcfk/nnedi3_avisynth.h%20difference.htm)
vcxproj (https://dl.dropbox.com/s/zyxjxsnym87cjit/nnedi3_vcxproj difference.htm)

I'm not a programmer so I don't know anymore than that. Maybe someone in the know can shed some light on this...
jpsdr
8th June 2014, 10:55
Ok, i've take a quick look. My port use the new 2.6 API, so a total different avisynth.h, in a way...
I don't know for sure, but i think there is a good chance that the issue you're talking about is not here anymore.
Reel.Deel
8th June 2014, 14:04
yeah, you're most likely right. -Vit- did mention this for his 2.6 modded plugins:

The new interface removes some code that was embedded in every plugin that could cause multi-threading problems. So these plugins may be more stable.....
....these plugins are no longer "modded", they're just up to date...
In any case I've updated nnedi3 to your version and will let you know if I encounter any problems. Thanks for your input jpsdr.
jpsdr
14th March 2015, 13:13
A very little update to 0.9.4.8.
stax76
27th April 2015, 02:50
It seems the 64-Bit version is working fine on Win7 but crashes on Win8/Win10.
jpsdr
27th April 2015, 09:30
I don't have Win8/Win10, and frankly don't intent to. Does the crash happens with all versions ? Are you using the last build (check the date on my github release) ?
If yes to, both, eventualy you can provide a VirtualDub crash log file, and i'll see if it's happening in one of the ASM part code, in that case, it may be possible that i can fix it if it's a bug in the ASM. But don't get too much hope, there is unfortunately a high possibilty that fixing this may be out of my field skills, as it seems more to be OS dependant, and in that case unfortunately it's totaly out of my knowledge.
stax76
27th April 2015, 09:47
I'm on Win7 too, I ported StaxRip to 64-Bit, Win8 users had crashes I didn't had so I installed Win10 preview in vmware player, I saw the crashes then and installed Visual Studio 2015 preview and debugged it, there were 4-5 occurrences where interop code was bad. The only small problem was that the IDE was very slow due to the virtual environment. You could setup multi boot, it's not very difficult. Win10 isn't bad, potentially Windows will be much more expensive in the future, if that wouldn't be likely I would switch to Win10 right now, many people here switched already, I hope there are more news on Build conference starting tomorrow.
stax76
27th April 2015, 14:13
A user reported nnedi3 works on Win8, could the crash I got be because I was using vmware?
jpsdr
28th April 2015, 00:38
I don't even know what vmware is...
captainadamo
28th April 2015, 01:46
I don't even know what vmware is...

It's a company that makes some of the most widely-used virtualization software.
jpsdr
28th April 2015, 09:08
Ok. It's possible it may be the cause.
The only thing i can do for now, as i've said, is to check a Virtuabldub crash log, and see if it's happening in one of the ASM code i've ported out, it's the only place with bug introduced risk. If it's not here, this is totaly out of my field knowledge.
I've been very lucky that port worked almost only with putting ASM functions in outside files.
jpsdr
29th April 2015, 08:49
Out of curiosity, try with opt=1 in nnedi.
stax76
29th April 2015, 09:29
opt=1 is working with vmware!

edit:

what makes the file size that large (13,1 MB)?
jpsdr
29th April 2015, 19:08
The neural network datas.
Id opt=1 is working, it means it crashes in the ASM functions. Providing me a Virtualdub crash log file have higher chances to help figure out what is wrong. With it, there is a little hope.
stax76
29th April 2015, 20:24
It crashes StaxRip and MPC-BE but not VirtualDub!