Port of NNEDI under new v2.6 AVS API [Archive]

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

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!

jpsdr

30th April 2015, 08:37

Argh....:confused:
Virtualdub provides disassembled code where crash occured, which could have told me on what part was the crash. But without this...
In that case, i must sadly confess that i have no clue of what to do... :(

Does crash also happen with 32 bit version (under vmware) ?

Edit : And on the 13.1MB, 12.9MB are the neural network datas.;)

jpsdr

6th May 2015, 09:04

@stax76
I'm using the last stable release of AVS+, r1576. Do you use this version ? If not, can you test with r1576 ?

stax76

6th May 2015, 09:44

I did test r1576 and also Win10 natively (without vmware), problem persist.

jpsdr

6th May 2015, 12:21

I don't have time these days, but later, i'll check the ASM code in case in see something.
Can you try the "old" Tritical's build just out of curiosity : http://forum.doom9.org/showthread.php?t=147695 ?

stax76

6th May 2015, 12:36

Can you try the "old" Tritical's build just out of curiosity

Same result, without opt=1 mpc-be x64 crashes on Win10.

jpsdr

6th May 2015, 13:06

Are you using the "vectorcall_" instead of standard "fastcall_" for compiling your StaxRip 64b port ?

stax76

6th May 2015, 13:19

I use VB.NET and interface with AviSynth using the avifile API, only thing I saw was win32exception, I tried to attach a debugger but it didn't yield to anything, in the system log I found some info:

Fehlerbucket 86074866829, Typ 4
Ereignisname: APPCRASH
Antwort: Nicht verfügbar
CAB-Datei-ID: 85948023432

Problemsignatur:
P1: StaxRip.exe
P2: 1.3.1.1
P3: 554a041b
P4: nnedi3.dll
P5: 0.9.4.7
P6: 550421cb
P7: c0000005
P8: 000000000000fede
P9:
P10:

Angefügte Dateien:
C:\Users\frank\AppData\Local\Temp\WERFA59.tmp.WERInternalMetadata.xml
C:\Users\frank\AppData\Local\Temp\WER622.tmp.appcompat.txt
C:\Users\frank\AppData\Local\Temp\WER6CF.tmp.hdmp
C:\Users\frank\AppData\Local\Temp\WER2535.tmp.WERDataCollectionFailure.txt

Diese Dateien befinden sich möglicherweise hier:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_StaxRip.exe_b72abc897b1e0ecd8d22d975322fdbcbd313f93_a07971f2_cab_20277c46

Analysesymbol:
Es wird erneut nach einer Lösung gesucht: 0
Berichts-ID: d0f7bfad-401a-4a32-9ee9-89b9afdcde02
Berichtstatus: 8
Bucket mit Hash: d59ed2b9785e003d6467e1e13724dc70

Name der fehlerhaften Anwendung: StaxRip.exe, Version: 1.3.1.1, Zeitstempel: 0x554a041b
Name des fehlerhaften Moduls: nnedi3.dll, Version: 0.9.4.7, Zeitstempel: 0x550421cb
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000000000000fede
ID des fehlerhaften Prozesses: 0x21ec
Startzeit der fehlerhaften Anwendung: 0x01d087f647effd06
Pfad der fehlerhaften Anwendung: D:\Projekte\GitHub\staxrip\bin\StaxRip.exe
Pfad des fehlerhaften Moduls: D:\Projekte\GitHub\staxrip\bin\Tools\Plugins\nnedi3\nnedi3.dll
Berichtskennung: 429aaf55-ee38-40c4-aec7-6dc86532b124
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

jpsdr

7th May 2015, 12:23

Unfortunately, i'm not able to get informations from this. I'm concerned by the fact that also the old Tritical's version is crashing. It's realy more troublesome, meaning that maybe issue is in the ASM code itself, and not caused by an error i could have done during the port.
You have no issues with the 32 bit version ?
And VDub working perfectly fine...!!
I think in two weeks i may have time to recheck the ASM code, in case there is errors in my port.
But at first glance, it's not looking good... :(
VDub works fine, old Tritical's version also crashing... bad... very bad...

stax76

7th May 2015, 12:54

jpsdr

7th May 2015, 13:25

I don't have benchmark, and can't do for now, my video dedicated PC is encoding, and there is at least one day left. But as i remember when i've done test, performance issue is noticeable i think just sliding a file with VDub (or is it disabling internal mutli-threading... i have doubts finaly...) with an avs script with only one line using only nnedi3_rpow2.

Groucho2004

7th May 2015, 17:34

I did test r1576 and also Win10 natively (without vmware), problem persist.
I already asked you over at Don's forum - What client programs do you feed the script to? I don't think MPC-BE is a good choice for testing.
If the script works with VDub64, x264_64, AVSMeter64, I'd say your problem is not the plugin.

videoh

7th May 2015, 22:00

If the script works with VDub64, x264_64, AVSMeter64, I'd say your problem is not the plugin. + 1 Post of the day.

stax76

8th May 2015, 08:23

Groucho2004

8th May 2015, 09:34

Just because a bug does not surface doesn't mean that the bug does not exist
I can't quite imagine how the bug you reported (crash) can be concealed by other programs.

DGMPGDec
When you search the forum, you'll find that there are all sorts of problems with the 64 Bit version of DGDecode.dll, missing IDCT modes, "green" frames, ...

stax76

8th May 2015, 10:10

When MediaInfo was new it wasn't working with any .NET application, I don't know what it was, it could be a bad pointer pointing into managed space I believe.

videoh

8th May 2015, 11:04

The 64-bit version of DGMPGDec's DGDecode is not made by Graft and is known to be buggy, as Groucho2004 pointed out. There are no known issues with 64-bit DGDecNV, so please demonstrate one if you can. Graft is always keen to fix issues in his code.

None of Graft's tools contain any "pointers pointing into managed space".

jpsdr

8th May 2015, 11:19

If the script works with VDub64, x264_64, AVSMeter64, I'd say your problem is not the plugin.
I personnaly would said "It may not be the pluggin, or don't focus only on pluggin".

Just because a bug does not surface doesn't mean that the bug does not exist.
I also agree.

The fact also that's it's not crashing with opt=1 means that it's crashing only when using the ASM part code, meaning that something broke the register presevation rules.
If it was a bug in the ASM like a loop going too far or something like that, issue would have poped up earlier and on any system (i think).
This is why within a week or two, i'll take a long time to properly check that the ASM code is not breaking the x64 register preservation rules, according the standard fastcall_ calling procedures. I'll also check code itself, but this is the only thing i think for now.

stax76
You've asked benchmarks :

[General info]
Log file created with: AVSMeter 2.0.1 (x64)
Avisynth version: AviSynth+ 0.1 (r1576, x64) (2.6.0.5)
Avisynth DLL location: C:\Windows\System32\AviSynth.dll

[Clip info]
Number of frames: 4077
Length (hh:mm:ss.ms): 00:02:50.045
Frame width: 960
Frame height: 720
Framerate: 23.976 (24000/1001)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

[Runtime info]
Frames processed: 4077 (0 - 4076)
FPS (min | max | average): 17.08 | 99.95 | 55.80
Memory usage (phys | virt): 93 | 91 MB
Thread count: 37
CPU usage (average): 38%
Time (elapsed): 00:01:13.060

[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 2.0.1 (x64)
Avisynth version: AviSynth+ 0.1 (r1576, x64) (2.6.0.5)
Avisynth DLL location: C:\Windows\System32\AviSynth.dll

[Clip info]
Number of frames: 4077
Length (hh:mm:ss.ms): 00:02:50.045
Frame width: 960
Frame height: 720
Framerate: 23.976 (24000/1001)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

[Runtime info]
Frames processed: 1903 (0 - 1902)
FPS (min | max | average): 15.32 | 36.55 | 26.79
Memory usage (phys | virt): 92 | 91 MB
Thread count: 37
CPU usage (average): 74%
Time (elapsed): 00:01:11.047

[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,opt=1)

Input video is encoded with UT Video codec.

foxyshadis

8th May 2015, 21:16

Just because a bug does not surface doesn't mean that the bug does not exist, the only thing that it sure at this point is that the bug exists, it can be in the avs plugin, it can be in the avs core, it can be in the client interop layer, it can be even in the CLR. I tested 15 plugins and only nnedi3, DGMPGDec and DGDecNV have a problem, chances are good we will find it, wherever it is.

Can you capture a crash dump in WinDbg, or install VS on the VM to debug it realtime? That might help a lot more. Access Violation on its own doesn't really tell a lot.

stax76

8th May 2015, 23:14

I already migrated to Win10 and Visual Studio 2015 Community Edition RC, I can try things but would need some hints because my C++ knowledge is only very basic.

jackoneill

9th May 2015, 08:17

I use x64 exclusively everywhere so it's difficult for me to test. I would have to download and setup everything. Is there a big performance difference between c and asm path? QTGMC uses nnedi3 and still works.

The ASM is something like 10 times faster, if I remember correctly (with default parameters).

jpsdr: I noticed this while perusing your ASM: https://github.com/jpsdr/NNEDI3/blob/master/nnedi3/nnedi3_asm_x64.asm#L1414 I don't know if that function is even used when it crashes, since stax76 hasn't provided the parameters passed to nnedi3... :(

jpsdr

9th May 2015, 09:42

Good !!! And :thanks: I don't know if it's related or the cause (there a good chance), but it's clearly a miss from my part wich need to be corrected.
Even with stax76 parameters, i don't know if i can say if this function is called or not.
I'll try to make a new build as soon as i can.

jpsdr

9th May 2015, 10:52

New buid avaible for test. :cool:

stax76

9th May 2015, 16:38

It still crashes, I'm trying to build the solution now with VS 2015 RC, it says /ZI and /O2 are incompatible.

Groucho2004

9th May 2015, 16:51

it says /ZI and /O2 are incompatible.
Optimizations have to be turned off for debug builds.

stax76

9th May 2015, 16:58

Thanks, I turned off optimizations and replaced

this line:

#include "afxres.h"

with:

#include "WinResrc.h"
#define IDC_STATIC -1

I thought MFC is included with Community Edition?

The build succeeds now but why doesn't it output any DLLs?

stax76

10th May 2015, 01:03

It's always breaking as access violation in this line:

https://github.com/jpsdr/NNEDI3/blob/19a21726b8747cd691b33297b5e24615d55ab86d/nnedi3/nnedi3.cpp#L1258

There is however something in my code because I just noticed it only happens in the preview dialog and it loads in the crop dialog fine, I didn't expect that. I don't remember I do threading or something special. At least we have some hints now.

edit:

crop dialog does not use any other filters than the source I was forgetting

Groucho2004

10th May 2015, 01:49

stax76

10th May 2015, 01:57

Have you tried "threads=1" with nnedi?

does not make a difference, it works fine with opt=1

jpsdr

10th May 2015, 10:14

Picture information is interesting. If registers value are correct, RAX & RCX at 0, crash is expected. But issue is that RAX shouldn't be at 0, it's the source pointer. As this crash occur during the y loop, is the crash occuring at the first occurence of the loop, or after several ?

jpsdr

10th May 2015, 10:32

I think i found another miss from my part, i'll do another build ASAP (but stay with same version).

jpsdr

10th May 2015, 11:00

New build avaible. With a little luck, maybe the good one...:rolleyes:

stax76

10th May 2015, 11:10

You made it, this is a great day for AviSynth x64, for StaxRip x64 and for people using different languages working together, it has been a pleasure to work with you on this, thanks! :thanks:

jpsdr

10th May 2015, 12:01

Wonderful. It's also a good thing to get ridance of lefting bugs. The only surprising thing, it's that these bugs left could have been trigged by anything. It was clearly not a specific issue to Win8.1/Win10. Well, everything ends well, it's what matters.
Thanks also at the others who have helped, providing information and running debug builds.

stax76

10th May 2015, 12:01

@jpsdr

DGDecNV and mvtools2 behave the same as nnedi3 before you fixed it. They work in VirtualDub but cause a access violation and crash in managed applications and in MPC-BE. Is there anything I can tell the authors how to find the problem? Did the line I showed you help/relate?

jpsdr

10th May 2015, 12:40

Unfortunately i don't think so. My issue was clealy a bug in the ASM file, some registers where kept with their 32bit versions when they should have been their 64bits versions. What helped me more (and that was what i needed) was the screenshot of HolyWu with disassembled part of the crash, and the status of the registers when crash occured.

videoh

10th May 2015, 15:14

They work in VirtualDub but cause a access violation and crash in managed applications Let's be precise: they crash in your managed applicaton. There is no problem in DGDecNV. And the threads here show that you refuse to answer questions or perform any straightforward debugging to actually try to locate the problem. I stand ready to assist if you are actually interested in solving the problem, but it seems that you are more interested in insulting people because they do not use .NET. That is my reward for trying to help you.

stax76

10th May 2015, 15:29

I told you about 15 times that all you need is loading a DGDecNV avs script with MPC-BE x64 or StaxRip x64 and you will see a access violation happening in YOUR native code, you were wrong, accept it, let it go, fix your code.

videoh

10th May 2015, 15:52

I don't have the environment setup for opening avs scripts in the DirectShow-based players (they can't open AVS on my system and I never figured out why), so I can't currently test MPC-BE. Can you please show me the crash screen?

burfadel

23rd May 2015, 18:20

I see there is someone doing active work on NNEDI3 for Vapoursynth. Are any of those commits compatible with NNEDI3 for Avisynth, and if so can they be ported if they haven't already been done so?

https://github.com/dubhater/vapoursynth-nnedi3/commits/master

jpsdr

24th May 2015, 10:22

Projects are too different, and so very very unlikely.

burfadel

24th May 2015, 11:19

Fair enough :). I just wasn't sure to what extent that the two were different.

Myrsloik

24th May 2015, 11:56

Projects are too different, and so very very unlikely.

I think this commit may be of interest to you:
https://github.com/dubhater/vapoursynth-nnedi3/commit/89819db62fafcc147fa5bc9d02c20812b761cfee

Equivalent line probably here:
https://github.com/jpsdr/NNEDI3/blob/master/nnedi3/nnedi3.cpp#L471

Not sure if this commit is also relevant but maybe it should be checked:
https://github.com/dubhater/vapoursynth-nnedi3/commit/8e97772face212a950f04380581bd554d4ec00d4

jpsdr

25th May 2015, 09:08

Thanks, i'll take a look.

jpsdr

25th May 2015, 19:40

New version avaible.

burfadel

25th May 2015, 20:08

New version avaible.

Thanks :)

hello_hello

26th May 2015, 00:27

If anyone cares, the right click explorer file/properties menu shows version 0.9.4.10 of the various nnedi3.dlls as being version 0.9.4.7. It was the same for 0.9.4.9.

Cheers.

jpsdr

26th May 2015, 09:51

Ah... Thanks for the information, i totaly forgot this in the compiler settings. And i have to find out where it was again... I'll do a new build very soon, even if not critical, it's always usefull.

jpsdr

26th May 2015, 19:27

New build avaible with correct version in properties file.

jpsdr

9th June 2015, 12:06

If anyone have any idea of how correct nnedi3 according the informations here :
http://forum.doom9.org/showthread.php?p=1660744#post1660744

I personnaly don't know how to "fix" the actual code.
I know the opencl version is corrected, but code is too much different, i don't know how to implement it in the actual code.

I don't know if the Vapoursynth version is "fixed".

Any information or even pull request are welcomed. :D

jpsdr

31st July 2015, 21:15

New version, i've tried to fix the chroma shift according the informations on this thread :
http://forum.doom9.org/showthread.php?t=170029

Test and report any issue, any feedback is welcomed.

luquinhas0021

31st July 2015, 22:51

Do you think to make some improvement on algorithm itself? I know that nnedi3 is a neural network trained for minimize absolute and squared error, however can you explain detailed the nnedi3's work?

jpsdr

1st August 2015, 07:41

To make the port, i didn't have to know how the core is working. What you're asking for as nothing to do with what i've done.
So i can't explain because i don't know how the core is working, and i don't intend to make improvement on the algorithm itself.

GMJCZP

3rd August 2015, 13:42

I tested the latest version with a brief coding (two times for verify) of a short video of 1 min and resizing with nnedi3:

nnedi3 0.9.4.0: 131s
nnedi3 0.9.4.11 (XP version only): 122s

Good job jpsdr!

luquinhas0021

3rd August 2015, 18:26

jpsdr, is kinda strange you modify a thing you don`t know entirely, not? If you don`t what system color nnedi3 was made for, if it was made for only one color system, how do you did it compatible with YUV 411 and others? Unless you interpolate for YUV 444 and then convert for RGB 888.
GMJCZP, what is your machine? what it hardware?

jpsdr

3rd August 2015, 19:14

jpsdr, is kinda strange you modify a thing you don`t know entirely, not?

Not if what you're modifying it's not in the part you don't know.

You don't have to know all the theory of how a car engine is working if you want to paint your car of another color, change the seats or the tyres.
Here it's somehow the same thing.

GMJCZP

3rd August 2015, 20:55

gmjczp, what is your machine? What it hardware?

C2d e4400

real.finder

5th August 2015, 17:20

hi, about fturn support, it not work with all color formats, so it willl show error with rgb and yuy2 in nnedi3_rpow2

I suggest make fturn support be in color formats that fturn support it only, or use try as Nnedi3_resize16 did

Desbreko

5th August 2015, 18:27

real.finder

5th August 2015, 18:38

YUY2 works fine because it gets split into separate Y8 clips before the turning happens.

For RGB, you can get around FTurn's limitations by doing this:
# RGB source
Interleave(ShowRed(pixel_type="Y8"),ShowGreen(pixel_type="Y8"),ShowBlue(pixel_type="Y8"))
nnedi3_rpow2(rfactor=2)
MergeRGB(SelectEvery(3,0),SelectEvery(3,1),SelectEvery(3,2))
It would be nice to have nnedi3_rpow2 do it internally, though.

I just note that the new one work with yuy2, unlike the old one that show error message

but the output is yv16 not yuy2, and this has an effect on AnimeIVTC and SMDegrain and maybe others

real.finder

5th August 2015, 23:04

New version, i've tried to fix the chroma shift according the informations on this thread :
http://forum.doom9.org/showthread.php?t=170029

Test and report any issue, any feedback is welcomed.

it's still there, you can test with this http://forum.doom9.org/showpost.php?p=1500031&postcount=377

and this can help too http://forum.doom9.org/showpost.php?p=1506532&postcount=388

jpsdr

6th August 2015, 14:37

Ok, i'll try to work further again latter...
I've re-organised the code, it should be easier to read and understand, so, for this specific issue, anyone who want to take a look is and comment is welcomed.
The "difficult" part is that allmost all post give information of offset applied on the resize filter. This offset is applied on the picture before resizing.
nnedi3 is first doing the whole x2 resize(s) parts, and eventualy after a standard resize filter is applied.
So, compensation has to be done first for the x2 parts which were made without the correction, and also eventualy for the final resize (if any) made by standard resizer.

jpsdr

6th August 2015, 14:42

real.finder

6th August 2015, 14:55

... Are you talking to me ?
I've tested all the color formats, and don't remember any error...

you have fturn.dll in your autoload folder?

Desbreko confirm that too, and fturn itself didn't support all color formats, now your Nnedi3 + fturn work with all color formats except rgb

jpsdr

6th August 2015, 15:12

Ok, no, i don't, i thought it was something internal to avs. Thanks for the information, i'll fix this for next release and don't use it if color is RGB.
Where this dll can be found ? Code source ?

real.finder

6th August 2015, 15:23

Ok, no, i don't, i thought it was something internal to avs. Thanks for the information, i'll fix this for next release and don't use it if color is RGB.
Where this dll can be found ? Code source ?

here http://forum.doom9.org/showthread.php?t=168315

but it better to do turn in y8 in all color formats, your Nnedi3 do this now as Desbreko say, but not in rgb, in rgb you can use the code that Desbreko put it here http://forum.doom9.org/showpost.php?p=1733098&postcount=109

and for yuy2 now the output is yv16, and this because YToUV() I think, so it must be convert to yuy2 before output if the source is yuy2

:thanks:

jpsdr

6th August 2015, 15:39

I've allready try to split RGB using something like this :

YToUV(a.ShowBlue("Y8"), a.ShowRed("Y8"), a.ShowGreen("Y8"))
Split planes and process
MergeRGB(V,U,Y)

It's a hell lot slower !!

About YUY2, you're right, it's a miss from my part !

Desbreko

6th August 2015, 16:20

The Y8 workaround for RGB is slower if you don't have FTurn, but it's faster if you do. Optimally, nnedi3_rpow2 would use the workaround only when FTurn is available, but it's not that big a deal since you can always do it externally.

ColorBarsHD()
KillAudio()
Trim(0,499)
ConvertToRGB24()
Interleave(ShowRed("Y8"),ShowGreen("Y8"),ShowBlue("Y8"))
nnedi3_rpow2(rfactor=2)
MergeRGB(SelectEvery(3,0),SelectEvery(3,1),SelectEvery(3,2),"RGB24")

AVSMeter 2.1.0 (x86)
AviSynth 2.60 (ICL10) (2.6.0.6)
Number of frames: 500
Length (hh:mm:ss.ms): 00:00:16.683
Frame width: 2576
Frame height: 1440
Framerate: 29.970 (30000/1001)
Colorspace: RGB24

No FTurn, RGB24
Frames processed: 500 (0 - 499)
FPS (min | max | average): 8.490 | 10.58 | 9.897
Memory usage (phys | virt): 85 | 81 MB
Thread count: 21
CPU usage (average): 39%
Time (elapsed): 00:00:50.520

No FTurn, Y8 workaround
Frames processed: 500 (0 - 499)
FPS (min | max | average): 7.329 | 8.073 | 7.852
Memory usage (phys | virt): 533 | 534 MB
Thread count: 21
CPU usage (average): 25%
Time (elapsed): 00:01:03.677

With FTurn, Y8 workaround
Frames processed: 500 (0 - 499)
FPS (min | max | average): 11.79 | 14.02 | 13.25
Memory usage (phys | virt): 534 | 534 MB
Thread count: 21
CPU usage (average): 47%
Time (elapsed): 00:00:37.732

Regarding the chroma shift, I think you'd just need to add the appropriate src_left offset to compensate for it when correcting the center shift of the chroma planes. That's what Resize8 (https://www.nmm-hd.org/newbbs/viewtopic.php?t=1323) does to avoid chroma shift from Avs's resizers, so looking at it will probably be helpful.

jpsdr

6th August 2015, 18:56

jpsdr

6th August 2015, 21:39

I have implemented internaly the RGB convertion in case FTurn is present, and indeed there is a speedup.
Nice tip, thanks.
Now, just to find out the chroma shift and NNEDI will be perfect ! :cool:

real.finder

6th August 2015, 22:29

New version.

As said, the chroma shift is not "so easy", because the shift resizer parametters are applied on the picture before doing the resize, and formulas in Resize8 or the thread i've linked previously are all for this case.
But, NNEDI is first doing one (or several) x2 steps using its algorithm. Then, after, we are trying to compensate the chroma shift. Formulas are not the same.

I've made tests, and doing :

video=AviSource("Test.avi").ConvertToY8()
Spline36Resize(video,100,Height(video),src_left=100)

is exactly the same as doing :

video=AviSource("Test.avi").ConvertToY8()
a=Spline36Resize(video,Width(video),Height(video),src_left=100)
Spline36Resize(a,100,Height(video))

But we are trying to reproduce :

video=AviSource("Test.avi").ConvertToY8()
Spline36Resize(video,100,Height(video),src_left=100)

when we are at the step :

video=AviSource("Test.avi").ConvertToY8()
Spline36Resize(video,100,Height(video))

so, after the resize.
It seems that the closest is :

video=AviSource("Test.avi").ConvertToY8()
a=Spline36Resize(video,100,Height(video))
Spline36Resize(a,100,Height(video),src_left=100.0*float(100.0/Width(video)))

But it's too late, it's impossible to get the exact same result than

video=AviSource("Test.avi").ConvertToY8()
Spline36Resize(video,100,Height(video),src_left=100)

According all these tests and the formulas in the thread, i've deduced the formula i've tried in the pluggin.

thank you for new version

about the shifting

it seems ok with this

r = blankclip(width=64,height=64,pixel_type="YV12",color_yuv=$FF0000)
g = blankclip(width=64,height=64,pixel_type="YV12",color_yuv=$00FF00)

stackhorizontal(r,g)
stackvertical(last,last.fliphorizontal())
o=last

rfactor=2
nWidth=200
nHeight=200

ncWidth=nWidth/2
ncHeight=nHeight/2

fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))

full test

r = blankclip(width=64,height=64,pixel_type="YV12",color_yuv=$FF0000)
g = blankclip(width=64,height=64,pixel_type="YV12",color_yuv=$00FF00)

stackhorizontal(r,g)
stackvertical(last,last.fliphorizontal())
o=last

rfactor=2
nWidth=200
nHeight=200

ncWidth=nWidth/2
ncHeight=nHeight/2

fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))

Import(AviSynthPluginsDir + "New Folder (2)/nnedi3_resize16_v3.3.avsi")
interleave(o.nnedi3_resize16(nWidth,nHeight),last)

return(last)

but not sure about rfactor

and it seems that yv411 in nnedi3 is broken, it will show white horizontal lines, and crash after some time

jpsdr

7th August 2015, 12:55

Thanks to everyone, i've now my weapon :

function ResizeUnderTest1(clip clp, int SizeX, int SizeY){
return nnedi3_rpow2(clp,2,cshift="spline36resize",fwidth=SizeX,fheight=SizeY)
}

function ResizeUnderTest2(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,2,cshift="spline36resize")
return Spline16Resize(video, SizeX, SizeY)
}

function ResizeUnderTest3(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,2,cshift="spline36resize")
Y = ConvertToY8(video).Spline36Resize(SizeX, SizeY)
U = UToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
V = VToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
return YToUV(U, V, Y)
}

function ResizeUnderTest4(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,2)
return Spline36Resize(video, SizeX, SizeY)
}

function ResizeUnderTest5(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,2)
Y = ConvertToY8(video).Spline36Resize(SizeX, SizeY)
U = UToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
V = VToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
return YToUV(U, V, Y)
}

function ResizeUnderTest6(clip clp, int SizeX, int SizeY){
Y = ConvertToY8(clp).Spline36Resize(2*SizeX,2*SizeY)
U = UToY8(clp).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(clp))/Width(Y)))
V = VToY8(clp).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(clp))/Width(Y)))
video=YToUV(U, V, Y)
Y = ConvertToY8(video).Spline36Resize(SizeX, SizeY)
U = UToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
V = VToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
return YToUV(U, V, Y)
}

function ResizeUnderTest7(clip clp, int SizeX, int SizeY){
Spline36Resize(clip,2*SizeX,2*SizeY)
return Spline36Resize(last, SizeX, SizeY)
}

function ResizeTest(clip clp, int SizeX, int SizeY, int p, int n){
Assert (n>=0)
return (n==1)
\ ? (p==1) ? ResizeUnderTest1(clp,SizeX,SizeY)
\ : (p==2) ? ResizeUnderTest2(clp,SizeX,SizeY)
\ : (p==3) ? ResizeUnderTest3(clp,SizeX,SizeY)
\ : (p==4) ? ResizeUnderTest4(clp,SizeX,SizeY)
\ : (p==5) ? ResizeUnderTest5(clp,SizeX,SizeY)
\ : (p==6) ? ResizeUnderTest6(clp,SizeX,SizeY)
\ : (p==7) ? ResizeUnderTest7(clp,SizeX,SizeY) : ResizeUnderTest1(clp,SizeX,SizeY)
\ : (p==1) ? ResizeUnderTest1(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==2) ? ResizeUnderTest2(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==3) ? ResizeUnderTest3(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==4) ? ResizeUnderTest4(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==5) ? ResizeUnderTest5(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==6) ? ResizeUnderTest6(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==7) ? ResizeUnderTest7(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY) : ResizeUnderTest1(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
}

r = blankclip(width=128,height=128,pixel_type="YV12",color_yuv=$FF0000)
g = blankclip(width=128,height=128,pixel_type="YV12",color_yuv=$00FF00)

stackhorizontal(r,g)
stackvertical(last,last.fliphorizontal())
o=last

a=ResizeTest(o,256,256,1,32)
b=ResizeTest(o,256,256,2,32)
c=ResizeTest(o,256,256,3,32)
ResizeTest(o,256,256,4,32)

interleave(o,a,b,c,last)

return(last)

Test in progress...:D

Reel.Deel

7th August 2015, 13:14

Desbreko

7th August 2015, 15:00

As said, the chroma shift is not "so easy", because the shift resizer parametters are applied on the picture before doing the resize, and formulas in Resize8 or the thread i've linked previously are all for this case.
But, NNEDI is first doing one (or several) x2 steps using its algorithm. Then, after, we are trying to compensate the chroma shift. Formulas are not the same.

Seems to work fine for me, at least on YV12.

ColorBars(pixel_type="YV12")

# The rfactor and output width and height values we want to use for testing
rfac = 2
ow = 800
oh = 600

w = Width()
h = Height()

# For the ratio of the output and input chroma widths used in the chroma shift correction formula, the input width is the
# width after all doubling by nnedi3 is done, so we have to multiply the original clip's chroma width by the rfactor value.
w_c = w/2
ow_c = ow/2
dblw_c = w_c*rfac
c_ratio = Float(ow_c)/Float(dblw_c)

# Center shift correction src_left and src_top values for YV12
hshift_y = Float(-rfac)/2.0+0.5
vshift_y = -0.5
hshift_c = hshift_y/2.0
vshift_c = vshift_y/2.0

# Add the chroma shift correction to the center shift correction to get the final src_left value
hshift_c_fix = 0.25-0.25/c_ratio
vshift_c_yv12 = -0.25
hshift_c_final = hshift_c+hshift_c_fix
vshift_c_final = vshift_c+vshift_c_yv12

# Dither_resize16 doesn't cause chroma shift, so we can check our results against it.
r16 = Dither_convert_8_to_16().Dither_resize16(ow,oh).DitherPost(mode=-1)

# No center shift correction
rpow2 = nnedi3_rpow2(rfac)

# Internal center shift correction that causes chroma shift
rpow2cs = nnedi3_rpow2(rfac, cshift="Spline36Resize", fwidth=ow, fheight=oh)

# External center shift correction with Resize8 to avoid chroma shift, but this causes the chroma to be resized twice
rpow2r8 = rpow2.Resize8(ow,oh,hshift_y,vshift_y, kernel="Spline36", kernel_c="Spline36", noring=false, noring_c=false)

# No center shift correction
y1 = ConvertToY8().nnedi3double(rfac)
u1 = UToY8().nnedi3double(rfac).Spline36Resize(w/2*rfac,h/2*rfac,0,vshift_c_yv12)
v1 = VToY8().nnedi3double(rfac).Spline36Resize(w/2*rfac,h/2*rfac,0,vshift_c_yv12)
dbl1 = YToUV(u1,v1,y1)

# Center shift correction without chroma shift and only one chroma resize
y2 = ConvertToY8().nnedi3double(rfac).Spline36Resize(ow,oh,hshift_y,vshift_y)
u2 = UToY8().nnedi3double(rfac).Spline36Resize(ow/2,oh/2,hshift_c_final,vshift_c_final)
v2 = VToY8().nnedi3double(rfac).Spline36Resize(ow/2,oh/2,hshift_c_final,vshift_c_final)
dbl2 = YToUV(u2,v2,y2)

Interleave(r16,dbl2)#.UToY8()

function nnedi3double(clip input, int rfactor) {
return rfactor == 2 ? input.nnedi3(1,dh=true,nsize=0,nns=3,U=false,V=false).FTurnRight().nnedi3(1,dh=true,nsize=0,nns=3,U=false,V=false).FTurnLeft()
\ : rfactor == 4 ? input.nnedi3(1,dh=true,nsize=0,nns=3,U=false,V=false).FTurnRight().nnedi3(1,dh=true,nsize=0,nns=3,U=false,V=false).FTurnLeft()
\ .nnedi3(0,dh=true,nsize=0,nns=3,U=false,V=false).FTurnRight().nnedi3(1,dh=true,nsize=0,nns=3,U=false,V=false).FTurnLeft()
\ : Assert(false, "nnedi3double: Too lazy to support more than rfactor 2 and 4 for this test")
}

real.finder

7th August 2015, 16:29

@jpsdr

Thanks for all your efforts in trying to fix this long standing issue with nnedi3_rpow2. One suggestion, can you add a chroma placement parameter to choose "MPEG1" or "MPEG2"? I assume right now it is (or will be) hardcoded for MPEG2 but I sometimes use it on Jpegs with MPEG1 chroma placement.

I always like to be safe so I would do something like this in your script above:

r = blankclip(width=128,height=128,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG2")
g = blankclip(width=128,height=128,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG2")

r = blankclip(width=64,height=64,pixel_type="rgb24",color=$FF0000)
g = blankclip(width=64,height=64,pixel_type="rgb24",color=$00FF00)

stackhorizontal(r,g)
stackvertical(last,last.fliphorizontal())
ConvertToYV12(ChromaOutPlacement="MPEG2") #or ConvertToYV12(ChromaOutPlacement="MPEG1") for mpeg1 (jpeg)
o=last

rfactor=2
nWidth=200
nHeight=200

ncWidth=nWidth/2
ncHeight=nHeight/2

fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))
fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))

Import(AviSynthPluginsDir + "New Folder (2)/nnedi3_resize16_v3.3.avsi")
interleave(o.nnedi3_resize16(nWidth,nHeight,cplace="MPEG2"),last)

return(last)

seems ok

edit: but here not

ImageSource("E:\PM5544_with_non-PAL_signals.png") #http://forum.doom9.org/showthread.php?p=1706504#post1706504

ConvertToYV12(ChromaOutPlacement="MPEG2") #or ConvertToYV12(ChromaOutPlacement="MPEG1") for mpeg1 (jpeg)
o=last

rfactor=2
nWidth=Width*32
nHeight=576

ncWidth=nWidth/2
ncHeight=nHeight/2

fturnright().nnedi3(1, dh=true,nns=2,nsize=3).fturnleft().nnedi3(1, dh=true,nns=2,nsize=3) #rfactor=2
YToUV(utoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),vtoy8().Spline36Resize(ncWidth,ncHeight,-0.25*rfactor,-0.25*rfactor),ConvertToY8().Spline36Resize(nWidth,nHeight,-0.25*rfactor,-0.25*rfactor))

Import(AviSynthPluginsDir + "New Folder (2)/nnedi3_resize16_v3.3.avsi")
interleave(o.nnedi3_resize16(nWidth,nHeight,cplace="MPEG2"),last)

ConvertToRGB(ChromaInPlacement="MPEG2")
Spline36Resize(Width/32, height)
Crop(240,460,-240,-30)
PointResize(Width*2, Height*2) #for better visibility

jpsdr

7th August 2015, 20:21

I'm still struggling, it may take a lot longer than i thought...

For adding a parameter, i'll see. If i do, it will be on the end of list, to not broke existing scripts.

Find out the issue of YV411, fix in next release.

Reel.Deel

8th August 2015, 01:11

For adding a parameter, i'll see. If i do, it will be on the end of list, to not broke existing scripts.

That would be the correct thing to do.

jpsdr

8th August 2015, 12:02

real.finder

8th August 2015, 12:28

New version.

Chroma shift issue is now totaly gone. You can torture it as you want, it will not fail ! :cool:
(I hope... :p)

Otherwise, i've out of curiosity made some benchmark.

Without FTurn
YV12 : 35.946
YV411 : 37.768
YYU2 : 44.071
YV16 : 43.417
YV24 : 59.304
RGB24 : 01:55.424

With FTurn
YV12 : 36.013
YV411 : 37.797
YUY2 : 43.781
YV16 : 43.379
YV24 : 59.102
RGB24 : 01:37.585

Well... Except RGB24, there is not realy big difference.
This make me wondering if the trick for RGB24 will also be faster even without FTurn... I'll check this later, but not today.

Oh... And it seems that there is no need for an MPEG1/MPEG2 parameter, not being able to see any difference.

thanks for the new ver

but seems you didn't take the yv411 spec into account

ImageSource("E:\PM5544_with_non-PAL_signals.png")

ConvertToYV411()
#~ ConvertToYV12(ChromaOutPlacement="MPEG2") #for mpeg2 (dvd bd)
#~ ConvertToYV12(ChromaOutPlacement="MPEG1") #for mpeg1 (jpeg)

o=last

nWidth=Width*32
nHeight=576

nnedi3_rpow2(2,cshift="spline36resize",fwidth=nWidth,fheight=nHeight)

fixresize=o.Dither_convert_8_to_16().Dither_Resize16(nWidth, nHeight, kernel="Spline36").Ditherpost(mode=-1)

interleave(fixresize,last)

ConvertToRGB()
#~ ConvertToRGB(ChromaInPlacement="MPEG2") #if you test yv12 only

Spline36Resize(Width/32, height)
Crop(240,460,-240,-30)
PointResize(Width*2, Height*2) #for better visibility

almost same thing for yv12 in mpeg2, more details http://www.mir.com/DMG/chroma.html

jpsdr

8th August 2015, 12:49

real.finder

8th August 2015, 12:57

I allready know the chroma link, very interesting.
But actualy, it passes the test : http://forum.doom9.org/showpost.php?p=1500031&postcount=377
If you change of any little value the actual chroma shift, the test fails.
So, i don't understand what's still wrong, or finaly the test you've provided link is not good ? :confused:

this http://forum.doom9.org/showpost.php?p=1500031&postcount=377 was for the shift issue in nnedi3_rpow2

this http://forum.doom9.org/showthread.php?p=1733493#post1733493 is caused by the avs resizer for treats everything as mpeg1

Groucho2004

8th August 2015, 13:00

Otherwise, i've out of curiosity made some benchmark.

Without FTurn
YV12 : 35.946
YV411 : 37.768
YYU2 : 44.071
YV16 : 43.417
YV24 : 59.304
RGB24 : 01:55.424

With FTurn
YV12 : 36.013
YV411 : 37.797
YUY2 : 43.781
YV16 : 43.379
YV24 : 59.102
RGB24 : 01:37.585

Well... Except RGB24, there is not realy big difference.
This make me wondering if the trick for RGB24 will also be faster even without FTurn... I'll check this later, but not today.
Which version of Avisynth did you use for the benchmark?

jpsdr

8th August 2015, 13:13

Groucho2004

8th August 2015, 13:15

@Grouncho
avs+ r1576 x64
You're aware that AVS+ has FTurn already built in, right? Therefore the performance with or without the FTurn plugin will be more or less identical.

jpsdr

8th August 2015, 13:19

Groucho2004

8th August 2015, 13:28

real.finder

8th August 2015, 13:29

@Grouncho
avs+ r1576 x64

@real.finder
If i implement indeed the chroma correction shift of the resize explained here (http://forum.doom9.org/showthread.php?t=170029), the test will fail for output size different than rf*original size. Is it intended to ?
By the way, from what i've understood on the thread, 4:1:1 don't need the correction, so my actual code should be correct... (unless i've misunderstood something).

see this http://forum.doom9.org/showthread.php?p=1706504#post1706504

and about 4:1:1, if the yv12 need src_left=-0.5 the yv411 will need src_left=-1.5

see here http://avisynth.nl/index.php/Known_Issues#Resizers:_Chroma_Positioning_Bugs and http://forum.doom9.org/showthread.php?p=1506374#post1506374

real.finder

8th August 2015, 13:33

jpsdr

8th August 2015, 13:37

@real.finder
Thanks for these informations, i'll check them later, not this WE. I've the feeling that i'll lose my hairs again.

@Grouncho
Ah... You mean that the internal turn use the code of fturn, not that fturn exist internally... Ok.
Well... It means i'll have to test with avs 2.60...

Edit
... In that case, it will be difficult to create a code specific when fturn is avaible. I'll end up bold...

Reel.Deel

8th August 2015, 13:38

Euh... No... But in that case, why when i remove the Fturn dll, i should have the same behavior, because in both cases the function should be detected, and clearly on RGB24, it can be seen it's not... So...?

It makes sense that RGB24 is slower when FTurn is not available, according to this post by tp7 it sounds like there no optimized turning function for RGB24.

7) Code from FTurn (http://forum.doom9.org/showthread.php?t=168315) is now integrated into the core (with some additional optimizations and new RGB32 routines).

So when FTurn is not available your using the regular TurnRight/Left but when FTurn is available, RGB24 gets split into separate channels (Y8 in this case) and processed with the optimized turning functions.

Oh... And it seems that there is no need for an MPEG1/MPEG2 parameter, not being able to see any difference.

Hmm, that's odd. If everything's correct there should a small difference between the two. I'll do some testing and report back. What method did you use to test this?

Groucho2004

8th August 2015, 13:40

It makes sense that RGB24 is slower when FTurn is not available, according to this post by tp7 it sounds like there no optimized turning function for RGB24.

So when FTurn is not available your using the regular TurnRight/Left but when FTurn is available, RGB24 gets split into separate channels (Y8 in this case) and processed with the optimized turning functions.
Thanks for digging these posts up. :)

jpsdr

8th August 2015, 13:53

But, if i'm under avs+, fturn is avaible without knowing...

My script test :

function ResizeUnderTest1(clip clp, int SizeX, int SizeY){
return nnedi3_rpow2(clp,2,cshift="spline36resize",fwidth=SizeX,fheight=SizeY)
}

function ResizeUnderTest2(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,2,cshift="spline36resize")
return Spline36Resize(video, SizeX, SizeY)
}

function ResizeUnderTest3_(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,4,cshift="spline36resize")
Y = ConvertToY8(video).Spline36Resize(SizeX, SizeY)
U = UToY8(video).Spline36Resize(Width(Y)/4, Height(Y), src_left=0.25*(1-Float(Width(video))/Width(Y)))
V = VToY8(video).Spline36Resize(Width(Y)/4, Height(Y), src_left=0.25*(1-Float(Width(video))/Width(Y)))
return YToUV(U, V, Y)
}

function ResizeUnderTest3(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,4,cshift="spline36resize")
Y = ConvertToY8(video).Spline36Resize(SizeX, SizeY)
U = UToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.5*(1-Float(Width(video))/Width(Y)))
V = VToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.5*(1-Float(Width(video))/Width(Y)))
return YToUV(U, V, Y)
}

function ResizeUnderTest4_(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,2)
return Spline36Resize(video, SizeX, SizeY)
}

function ResizeUnderTest4(clip clp, int SizeX, int SizeY){
return nnedi3_rpow2(clp,2,cshift="spline36resize")
}

function ResizeUnderTest5(clip clp, int SizeX, int SizeY){
return nnedi3_rpow2(clp,2)
}

#YV12
function ResizeUnderTest6_(clip clp, int SizeX, int SizeY){
rf=16
video=nnedi3_rpow2(clp,rf)

Y_hshift = -0.5
Y_vshift = -0.5
C_hshift = Y_hshift
C_vshift = Y_vshift

# YV12 seulement
C_vshift = C_vshift-0.5
C_vshift = C_vshift/2.0
C_hshift = C_hshift/2.0

#Correct ressampling chroma shift
#First correct the first past increasing of rf
C_hshift = C_hshift-0.25*(rf-1)
#Correct for the final resolution
#C_hshift = C_hshift+0.25*(1.0-(Float(Width(video))/Float(SizeX)))

#Y = ConvertToY8(video).Spline36Resize(Width(video), Height(video), src_left=Y_hshift, src_top=Y_vshift)
Y = ConvertToY8(video).Spline36Resize(SizeX,SizeY, src_left=Y_hshift, src_top=Y_vshift)
U = UToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=C_hshift, src_top=C_vshift)
V = VToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=C_hshift, src_top=C_vshift)
return YToUV(U, V, Y)
}

#YV16
function ResizeUnderTest6_(clip clp, int SizeX, int SizeY){
rf=16
video=nnedi3_rpow2(clp,rf)

Y_hshift = -0.5
Y_vshift = -0.5
C_hshift = Y_hshift
C_vshift = Y_vshift

C_hshift = C_hshift/2.0

#Correct ressampling chroma shift
#First correct the first past increasing of rf
C_hshift = C_hshift-0.25*(rf-1)
#Correct for the final resolution
#C_hshift = C_hshift+0.25*(1.0-(Float(Width(video))/Float(SizeX)))

#Y = ConvertToY8(video).Spline36Resize(Width(video), Height(video), src_left=Y_hshift, src_top=Y_vshift)
Y = ConvertToY8(video).Spline36Resize(SizeX,SizeY, src_left=Y_hshift, src_top=Y_vshift)
U = UToY8(video).Spline36Resize(Width(Y)/2, Height(Y), src_left=C_hshift, src_top=C_vshift)
V = VToY8(video).Spline36Resize(Width(Y)/2, Height(Y), src_left=C_hshift, src_top=C_vshift)
return YToUV(U, V, Y)
}

#YV24
function ResizeUnderTest6_(clip clp, int SizeX, int SizeY){
rf=2
video=nnedi3_rpow2(clp,rf)

Y_hshift = -0.5
Y_vshift = -0.5
C_hshift = Y_hshift
C_vshift = Y_vshift

C_hshift = C_hshift

#Correct ressampling chroma shift
#First correct the first past increasing of rf
#C_hshift = C_hshift-0.25*(rf-1)
#Correct for the final resolution
#C_hshift = C_hshift+0.25*(1.0-(Float(Width(video))/Float(SizeX)))

#Y = ConvertToY8(video).Spline36Resize(Width(video), Height(video), src_left=Y_hshift, src_top=Y_vshift)
Y = ConvertToY8(video).Spline36Resize(SizeX,SizeY, src_left=Y_hshift, src_top=Y_vshift)
U = UToY8(video).Spline36Resize(Width(Y), Height(Y), src_left=C_hshift, src_top=C_vshift)
V = VToY8(video).Spline36Resize(Width(Y), Height(Y), src_left=C_hshift, src_top=C_vshift)
return YToUV(U, V, Y)
}

#YV411
function ResizeUnderTest6(clip clp, int SizeX, int SizeY){
rf=16
video=nnedi3_rpow2(clp,rf)

Y_hshift = -0.5
Y_vshift = -0.5
C_hshift = Y_hshift
C_vshift = Y_vshift

#C_hshift = C_hshift/4.0
C_hshift = 0

#Correct ressampling chroma shift
#First correct the first past increasing of rf
C_hshift = C_hshift-0.5*(rf-1)
#Correct for the final resolution
#C_hshift = C_hshift+0.25*(1.0-(Float(Width(video))/Float(SizeX)))

#Y = ConvertToY8(video).Spline36Resize(Width(video), Height(video), src_left=Y_hshift, src_top=Y_vshift)
Y = ConvertToY8(video).Spline36Resize(SizeX,SizeY, src_left=Y_hshift, src_top=Y_vshift)
U = UToY8(video).Spline36Resize(Width(Y)/4, Height(Y), src_left=C_hshift, src_top=C_vshift)
V = VToY8(video).Spline36Resize(Width(Y)/4, Height(Y), src_left=C_hshift, src_top=C_vshift)
return YToUV(U, V, Y)
}

function ResizeUnderTest5_(clip clp, int SizeX, int SizeY){
video=nnedi3_rpow2(clp,2)
Y = ConvertToY8(video).Spline36Resize(SizeX, SizeY)
U = UToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
V = VToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
return YToUV(U, V, Y)
}

function ResizeUnderTest6_(clip clp, int SizeX, int SizeY){
Y = ConvertToY8(clp).Spline36Resize(2*SizeX,2*SizeY)
U = UToY8(clp).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(clp))/Width(Y)))
V = VToY8(clp).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(clp))/Width(Y)))
video=YToUV(U, V, Y)
Y = ConvertToY8(video).Spline36Resize(SizeX, SizeY)
U = UToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
V = VToY8(video).Spline36Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
return YToUV(U, V, Y)
}

function ResizeUnderTest7(clip clp, int SizeX, int SizeY){
Spline36Resize(clip,2*SizeX,2*SizeY)
return Spline36Resize(last, SizeX, SizeY)
}

function ResizeUnderTest(clip clp, int SizeX, int SizeY){

#return nnedi3_rpow2(clp,2,cshift="spline36resize",fwidth=SizeX,fheight=SizeY)

video=nnedi3_rpow2(clp,2,cshift="spline36resize")
#video=nnedi3_rpow2(clp,2)
#Y = ConvertToY8(video).spline36resize(SizeX, SizeY)
#U = UToY8(video).spline36resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
#V = VToY8(video).spline36resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(video))/Width(Y)))
#return YToUV(U, V, Y)
return spline36resize(video, SizeX, SizeY)

#Y = ConvertToY8(clp).spline36resize(SizeX, SizeY)
#U = UToY8(clp).spline36resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(clp))/Width(Y)))
#V = VToY8(clp).spline36resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(clp))/Width(Y)))
#return YToUV(U, V, Y)

#return spline36resize(clp, SizeX, SizeY)
}

function ResizeTest(clip clp, int SizeX, int SizeY, int p, int n){
Assert (n>=0)
return (n==1)
\ ? (p==1) ? ResizeUnderTest1(clp,SizeX,SizeY)
\ : (p==2) ? ResizeUnderTest2(clp,SizeX,SizeY)
\ : (p==3) ? ResizeUnderTest3(clp,SizeX,SizeY)
\ : (p==4) ? ResizeUnderTest4(clp,SizeX,SizeY)
\ : (p==5) ? ResizeUnderTest5(clp,SizeX,SizeY)
\ : (p==6) ? ResizeUnderTest6(clp,SizeX,SizeY)
\ : (p==7) ? ResizeUnderTest7(clp,SizeX,SizeY) : ResizeUnderTest1(clp,SizeX,SizeY)
\ : (p==1) ? ResizeUnderTest1(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==2) ? ResizeUnderTest2(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==3) ? ResizeUnderTest3(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==4) ? ResizeUnderTest4(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==5) ? ResizeUnderTest5(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==6) ? ResizeUnderTest6(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
\ : (p==7) ? ResizeUnderTest7(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY) : ResizeUnderTest1(ResizeTest(clp,SizeX,SizeY,p,n-1),SizeX,SizeY)
}

o_Size=152
#r1 = blankclip(width=o_Size,height=o_Size,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG2")
#g1 = blankclip(width=o_Size,height=o_Size,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG2")

#r = blankclip(width=o_Size,height=o_Size,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG1")
#g = blankclip(width=o_Size,height=o_Size,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG1")

r = blankclip(width=o_Size,height=o_Size,pixel_type="YV411",color_yuv=$FF0000)
g = blankclip(width=o_Size,height=o_Size,pixel_type="YV411",color_yuv=$00FF00)

#r = blankclip(width=4,height=4,pixel_type="YV411",color_yuv=$FF0000)
#g = blankclip(width=4,height=4,pixel_type="YV411",color_yuv=$00FF00)

#stackhorizontal(r1,g1)
#stackvertical(last,last.fliphorizontal())
#o1=last

stackhorizontal(r,g)
stackvertical(last,last.fliphorizontal())
o=last

#a=ResizeTest(o,512,512,1,8)
#b=ResizeTest(o,512,512,2,8)
ResizeTest(o,500,500,6,8)
#b=ResizeTest(o,128,128,3,8)

#interleave(a,b,c)

#Spline36Resize(512,512)

ConvertToYV24()

I adjusted it/changed it to test several cases :
- Using at start a 4x4, with succesives calls (with rf=2 or 8) without changing the output (=> each call increase size).
- Using a "normal" video size with output resize, testing a lot (32) of succesive calls with rf=2, or less succesive (around 8) calls with rf=16.

But for this, i've used a special build, where i've removed the code of when there is no cshift srting, in YV12 some vertical shift is nevertheless made with Spline36Resize, allowing me to have a "pure" output without cshfit. On the other hand, as it's only vertical, it shouldn't affect the horizontal issues, so you can still made tests on YV12, but in that case remove the [C_vshift = C_vshift-0.5] in the code specific to the YV12 part.

luquinhas0021

8th August 2015, 14:18

jpsdr, what about you make a port of eedi3 for Avisynth 2.6? The port that already exist sucks: it doesn' add support to bunch of colorspaces that you've added to nnedi3.

jpsdr

8th August 2015, 14:39

I don't use eedi3, so sorry, i will not work on this.

jpsdr

8th August 2015, 14:46

After a little thought, my mistake. Implementing the chroma resize shift will not make the test fail, because after the 1rst call of resize, input/ouput will have the same size => no shift add to chroma.
In that case, and only for 4:2:x (and not 4:1:1 according the thread) formula should be :
src_left=0.25*(1.0-Input/Ouput)
but... only if shift was applyed before the rf resize.

X0,Y0 : Input size, X1,Y1 : Output size, c=0.25*(1.0-X0/X1)
Resize(X1,Y1,src_left=c) is the same than :
Resize(X0,Y0,src_left=c)
Resize(X1,Y1)
or :
Resize(X1,Y1)
Resize(X1,Y1,src_left=c*X1/X0)

So 2 solutions :
call a resize without changing the resolution with only a shift before applying the rf change,
or after calcultate all the chroma compensation for the rf, which i think is better and avoid an extra resize call.
First : Compensate for the rf increase not done :
add : 0.25*(1-In/(rf*in))*((rf*In)/In)=0.25*(rf-1).
Now, we have again a good 4:2:0 chroma placement. This one will be resized again, but this time, the shift will be applied properly (before the next resize). We are now changing size from In*rf to out.
We have to add again : 0.25*(1-(rf*In)/out)
So, finaly it will result on : 0.25*rf*(1-In/Out)
Test will not fail, because after the 1rst call, In=Out.
I'll check this tomorrow.

cretindesalpes

8th August 2015, 16:25

what about you make a port of eedi3 for Avisynth 2.6?
I started working on an eedi3 (and dfttest as well because they share the same kind of planar input) port for Avs(+) 32/64 bits and Vapoursynth, including all the new colorspaces, but since there is already a decent VS port for these plug-ins I somewhat gave up.

jpsdr

8th August 2015, 18:33

Some benchs under avs 2.60

RGB24
Original method : 47.87
New method without FTurn : 43.16
New method with Fturn : 35.88
=> Don't bother anymore, always use new method.

YV12
Without FTurn : 17.44
With Fturn : 14.19

YV24
Without FTurn : 26.95
With Fturn : 19.66

Ok, this time, it's significant.

jpsdr

8th August 2015, 22:33

New version. Add chroma resize shif correction and mpeg2 parameter.

kuchikirukia

9th August 2015, 00:38

New version. Add chroma resize shif correction and mpeg2 parameter.

No.
No.
Don't tell me it was wrong.
This DVD.
Interlaced.
Telecined.
Progressive.
Film
Video
So much trimming.
So much splicing.
And... I just finished.

Or did this only affect resize and not QTGMC?

How does this interact with Santiag (http://forum.doom9.org/showthread.php?t=153835#post1393006)? Santiag does a Spline36resize with a chroma shift to fix... something, but with the chroma shift bug in Spline36resize and now no bug in nnedi3, I have no idea if it's still fixing what it's supposed to fix or if it's now introducing an error.

But thank you! I use nnedi3 in so much.

Reel.Deel

9th August 2015, 01:40

The chroma shift only affects nnedi3_rpow2() since it uses AviSynth's internal resizers. So this does not effect nnedi3() nor QTGMC().

On the bright side the chroma shift is for the most part hardly noticeable, so you should be fine. I guess that's one of the reasons this issue has been around for some time now...

kuchikirukia

9th August 2015, 01:50

The chroma shift only affects nnedi3_rpow2() since it uses AviSynth's internal resizers. So this does not effect nnedi3() nor QTGMC().

Phew, good to know.
Though does that mean when they finally get around to fixing the internal resizers that nnedi3 is going to be wrong again?

Reel.Deel

9th August 2015, 02:08

Though does that mean when they finally get around to fixing the internal resizers that nnedi3 is going to be wrong again?

Not necessarily, a chroma placement parameter can be added, "MPEG1" would have to be the default in order to keep backward compatibly with the current behavior.

Desbreko

9th August 2015, 02:30

This fix doesn't affect santiag since it uses nnedi3 directly with dh=true rather than nnedi3_rpow2.

That said, santiag does cause chroma shift because it uses AviSynth's resizers. I think it also doesn't correct the vertical chroma shift caused by nnedi3 doubling YV12.

And yes, if/when AviSynth's resizers get fixed, nnedi3_rpow2 will need to be updated or else it will be wrong again, at least by default. With the current workaround, you'd have to set mpeg2=false when the chroma placement actually is MPEG2.

jpsdr

9th August 2015, 09:23

Not necessarily, a chroma placement parameter can be added, "MPEG1" would have to be the default in order to keep backward compatibly with the current behavior.

You're right indeed. I'll change that.

jpsdr

9th August 2015, 11:20

New version, with default value of mpeg2 parameter to false, to keep previous behavior (but don't put back chroma shift issue... ;) )

Reel.Deel

9th August 2015, 11:35

You're right indeed. I'll change that.

I was hypothetically speaking about AviSynth's internal resizers if the chroma placement issue ever gets fixed.

Regardless, thanks for the updated version!

---

Anyone have any toughs on this?

Since we're on the subject of speed and turning...

Currently nnedi3_rpow2() does this internally:
nnedi3()
turnright()
nnedi3()
turnleft()

It should in theory be slightly faster if rearranged to:
turnright()
nnedi3()
turnleft()
nnedi3()

I didn't bother to test it myself but you'll be turning half the number of pixels so maybe it'll be a noticable improvement. Or maybe it'll look a lot different... who knows...

jpsdr

9th August 2015, 12:35

Out of curiosity, i've wanted to test what's explained here (http://forum.doom9.org/showthread.php?t=170029), with the recap here (http://forum.doom9.org/showpost.php?p=1705237&postcount=34) and it's what i've used in the NNEDI version.

My script test is :

function ResizeUnderTest1(clip clp, int rf, int SizeX, int SizeY, bool chroma){
return nnedi3_rpow2(clp,rf,cshift="spline36resize",fwidth=SizeX,fheight=SizeY,mpeg2=chroma)
}

function ResizeUnderTest4(clip clp, int rf, int SizeX, int SizeY, bool chroma){
return nnedi3_rpow2(clp,rf,cshift="spline36resize",mpeg2=chroma)
}

function ResizeTest(clip clp, int rf, int SizeX, int SizeY, int p, int n, bool chroma){
Assert (n>=0)
return (n==1)
\ ? (p==1) ? ResizeUnderTest1(clp,rf,SizeX,SizeY,chroma)
\ : (p==2) ? ResizeUnderTest2(clp,rf,SizeX,SizeY,chroma)
\ : (p==3) ? ResizeUnderTest3(clp,rf,SizeX,SizeY,chroma)
\ : (p==4) ? ResizeUnderTest4(clp,rf,SizeX,SizeY,chroma)
\ : (p==5) ? ResizeUnderTest5(clp,rf,SizeX,SizeY,chroma)
\ : (p==6) ? ResizeUnderTest6(clp,rf,SizeX,SizeY,chroma)
\ : (p==7) ? ResizeUnderTest7(clp,rf,SizeX,SizeY,chroma) : ResizeUnderTest1(clp,rf,SizeX,SizeY,chroma)
\ : (p==1) ? ResizeUnderTest1(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==2) ? ResizeUnderTest2(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==3) ? ResizeUnderTest3(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==4) ? ResizeUnderTest4(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==5) ? ResizeUnderTest5(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==6) ? ResizeUnderTest6(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==7) ? ResizeUnderTest7(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma) : ResizeUnderTest1(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
}

r = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG2")
g = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG2")

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal())
X0=Width(o)
Y0=Height(o)

a=ResizeTest(o,16,500,500,4,2,true)
X1=Width(a)
Y1=Height(a)

shift=0.25*(1.0-(Float(X0)/Float(X1)))
Y = ConvertToY8(o).Spline36Resize(X1, Y1)
U = UToY8(o).Spline36Resize(X1/2,Y1/2, src_left=shift)
V = VToY8(o).Spline36Resize(X1/2,Y1/2, src_left=shift)
b = YToUV(U, V, Y)

c=Spline36Resize(o,X1,Y1)

video=interleave(a,b,c)

# Change final resolution to be watchable under VDub

#shift=0.25*(1.0-(Float(X1)/512.0))
shift=0
Y = ConvertToY8(video).Spline36Resize(512, 512)
U = UToY8(video).Spline36Resize(256,256, src_left=shift)
V = VToY8(video).Spline36Resize(256,256, src_left=shift)
YToUV(U, V, Y)

I've played a lot with it, but result is always the same : If you apply the formula of the chroma shift resize, it end up bads... :(
So, i begin to have big second thoughts about this... :confused:

Unless i'm doing something wrong, i'll welcome any feeback and even more feedback about thouse who apparently master the subject...

My purpose was of course to check the rightness of this on cases shift may produce several pixels shift.

jpsdr

9th August 2015, 13:16

I was hypothetically speaking about AviSynth's internal resizers if the chroma placement issue ever gets fixed.

Ah... I misunderstood your comment.

Personnaly, i would rather stay with my first choice :
Make mpeg2=true default value, and mpeg2=false affect only 4:2:0 and not 4:2:2, because 4:2:2 is always MPEG-2 aligned.

But, what the other users think, want, prefer ?

real.finder

9th August 2015, 13:50

Ah... I misunderstood your comment.

Personnaly, i would rather stay with my first choice :
Make mpeg2=true default value, and mpeg2=false affect only 4:2:0 and not 4:2:2, because 4:2:2 is always MPEG-2 aligned.

But, what the other users think, want, prefer ?

I think mpeg2 should be the default as dither_resize and others, and peoples encode yv12 mpeg2 almost all the time, not mpeg1 and jpeg

Desbreko

9th August 2015, 19:39

I also think it would be better to make mpeg2=true default for the time being and then just remove the workaround if AviSynth's resizers get fixed. That way, the majority of users will get correct behavior without having to set any new parameters since MPEG2 chroma siting is much more common, and it won't break existing scripts when it's removed later.

jpsdr

10th August 2015, 08:50

Ok, for now i'll add another parameter to anable or not the workaround, with a default value of true, and put back mpeg2=true the default.

jpsdr

10th August 2015, 10:17

I've used this script test :

function ResizeUnderTest1(clip clp, int rf, int SizeX, int SizeY, bool chroma){
return nnedi3_rpow2(clp,rf,cshift="spline36resize",fwidth=SizeX,fheight=SizeY,mpeg2=chroma)
}

function ResizeUnderTest4(clip clp, int rf, int SizeX, int SizeY, bool chroma){
return nnedi3_rpow2(clp,rf,cshift="spline36resize",mpeg2=chroma)
}

function ResizeTest(clip clp, int rf, int SizeX, int SizeY, int p, int n, bool chroma){
Assert (n>=0)
return (n==1)
\ ? (p==1) ? ResizeUnderTest1(clp,rf,SizeX,SizeY,chroma)
\ : (p==2) ? ResizeUnderTest2(clp,rf,SizeX,SizeY,chroma)
\ : (p==3) ? ResizeUnderTest3(clp,rf,SizeX,SizeY,chroma)
\ : (p==4) ? ResizeUnderTest4(clp,rf,SizeX,SizeY,chroma)
\ : (p==5) ? ResizeUnderTest5(clp,rf,SizeX,SizeY,chroma)
\ : (p==6) ? ResizeUnderTest6(clp,rf,SizeX,SizeY,chroma)
\ : (p==7) ? ResizeUnderTest7(clp,rf,SizeX,SizeY,chroma) : ResizeUnderTest1(clp,rf,SizeX,SizeY,chroma)
\ : (p==1) ? ResizeUnderTest1(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==2) ? ResizeUnderTest2(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==3) ? ResizeUnderTest3(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==4) ? ResizeUnderTest4(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==5) ? ResizeUnderTest5(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==6) ? ResizeUnderTest6(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
\ : (p==7) ? ResizeUnderTest7(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma) : ResizeUnderTest1(ResizeTest(clp,rf,SizeX,SizeY,p,n-1,chroma),rf,SizeX,SizeY,chroma)
}

r = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG2")
g = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG2")

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal())
X0=Width(o)
Y0=Height(o)

a=ResizeTest(o,32,500,500,4,1,true)
X1=Width(a)
Y1=Height(a)

shift=0.25*(1.0-(Float(X0)/Float(X1)))
Y = ConvertToY8(o).Spline36Resize(X1, Y1)
U = UToY8(o).Spline36Resize(X1/2,Y1/2, src_left=shift)
V = VToY8(o).Spline36Resize(X1/2,Y1/2, src_left=shift)
b = YToUV(U, V, Y)

c=Spline36Resize(o,X1,Y1)

d=Resize8(o,X1,Y1,kernel="Spline36Resize",kernel_c="Spline36Resize")

interleave(a,b,c,d)

Results still show that compensate the chroma according the resize don't produce good result.
Or again, i'm doing something wrong :confused:

BTW, i'm very surprised by the Resize8 result !
Never tested before, i should have....

Desbreko

10th August 2015, 17:39

.14 and .15's horizontal center shift correction for YV12 seems to be using a constant -0.5 luma pixel shift instead of increasing with rfactor like it should.

Edit: Looking at the source code history, I think this bug might've actually been introduced in .13, but I don't have the dll anymore to test it and only the latest release is on GitHub.

real.finder

10th August 2015, 18:01

I was hypothetically speaking about AviSynth's internal resizers if the chroma placement issue ever gets fixed.

Regardless, thanks for the updated version!

---

Anyone have any toughs on this?

Since we're on the subject of speed and turning...

Currently nnedi3_rpow2() does this internally:
nnedi3(dh=true)
turnright()
nnedi3(dh=true)
turnleft()

It should in theory be slightly faster if rearranged to:
turnright()
nnedi3(dh=true)
turnleft()
nnedi3(dh=true)

I didn't bother to test it myself but you'll be turning half the number of pixels so maybe it'll be a noticable improvement. Or maybe it'll look a lot different... who knows...

yes, it faster, Especially in long time encoded

jpsdr

10th August 2015, 22:01

.14 and .15's horizontal center shift correction for YV12 seems to be using a constant -0.5 luma pixel shift instead of increasing with rfactor like it should.

Chroma resize ajustment compensate.
It's not a bug, it is how it's supposed to be, even if i begin to wonder.

Read my post just before yours, #162...

About Turning, i'll not try changing order, it will probably mess again with the chroma shift, and if you look at the code, you'll see field parameter not allways the same, and i think it's intended to be done in the order it's done, things are not allways swapables, and i think here it's not. So, i'll not touch this.

Desbreko

10th August 2015, 22:40

No, it's not how it's supposed to be. It breaks the center shift correction not just for the chroma channels but for the luma as well.

g = BlankClip(width=8, height=8, pixel_type="YV12", color_yuv=$FF0000).KillAudio()
b = BlankClip(width=8, height=8, pixel_type="YV12", color_yuv=$00FF00).KillAudio()
StackVertical(StackHorizontal(g,b,g,b),StackHorizontal(b,g,b,g),StackHorizontal(g,b,g,b),StackHorizontal(b,g,b,g))

w = Width()
h = Height()

rfac = 16

r16 = Dither_convert_8_to_16().Dither_resize16(w*rfac,h*rfac).DitherPost(mode=-1)
rpow2cs = nnedi3_rpow2(rfac, cshift="Spline36Resize")
Interleave(r16,rpow2cs)
ConvertToY8()# Get rid of the chroma to avoid any possible chroma shift differences while comparing

jpsdr

10th August 2015, 23:21

Ok, i think i see what you mean, i thought you were talking of another thing.

jpsdr

11th August 2015, 00:47

New version, center & chroma should be fine this time. Add a parameter to disable the resize chroma shift adjustment.

jpsdr

11th August 2015, 12:10

Since we're on the subject of speed and turning...

Currently nnedi3_rpow2() does this internally:
nnedi3()
turnright()
nnedi3()
turnleft()

It should in theory be slightly faster if rearranged to:
turnright()
nnedi3()
turnleft()
nnedi3()

Finaly, i've been able to implement this properly, tested, it works, so new version in a few hours.

ryrynz

11th August 2015, 15:19

is it likely that nnedi3 can or would extend beyond 256 neurons?

jpsdr

11th August 2015, 15:49

You're talking here of something related to the core of the programm, i absolutely don't touch at that, so, it will stay the way it is.

jpsdr

11th August 2015, 18:45

New version up, as usual, everything is on the first post.

Groucho2004

11th August 2015, 21:08

11/08/2015 v0.9.4.17
+ Change the order between turnl/r and nnedi3 calls in nnedi3_rpow2 to optimize speed.
I tried this as well a few days ago, following Myrsloik's suggestion. The result was that the output is different from the original.

I just ran a test with your v0.9.4.16 vs. v0.9.4.17, the problem is the same.
Script for both versions:
colorbars(width = 320, height = 240, pixel_type = "yv12").killaudio().assumefps(50, 1).trim(0, 19)
nnedi3_rpow2(2)

Then loaded the script in VDub and created a lossless AVI (UTVideo) for each nnedi3 version.

After that, compare the two versions with this script:
a = avisource("test_pattern1.avi")
b = avisource("test_pattern2.avi")
subtract(a, b).levels(127, 1, 129, 0, 255)

Source frame:
http://s29.postimg.org/obhm0x0tj/test_src.png

Result of the diff script:
http://s12.postimg.org/nsvsvo0l9/test_diff.png

jpsdr

11th August 2015, 22:48

The fact that output is different doesn't realy surprise me, as we have somehow a non-linear and a non bijective transformation, and honestly i didn't expect an identical pixel result.
It doesn't mean that the result is incorrect or bad. It's different, yes, but both results are equaly good. And if one is faster than the other, he's not better, but only more advantageous.

Out of curiosity, i'm more interest to see an histogram of the subtract instead of just the Level thing.

Desbreko

11th August 2015, 23:14

I did a bit of testing with both methods, and while the output is different, I wouldn't call it better or worse from what I saw. For as many places where it looked worse, there were also places it looked better.

Groucho2004

11th August 2015, 23:37

The fact that output is different doesn't realy surprise me, as we have somehow a non-linear and a non bijective transformation, and honestly i didn't expect an identical pixel result.
It doesn't mean that the result is incorrect or bad. It's different, yes, but both results are equaly good. And if one is faster than the other, he's not better, but only more advantageous.
My point is simply that people should be aware that the output is different to the original (i.e. Tritical's 0.9.4).

jpsdr

12th August 2015, 09:40

Having corrected the chroma shift bug, only with that output is different from the original. Add the chroma resize adjustment for MPEG-2 subsampling, you add another differences.

All resizer work by resizing one side, and after the other. Whatever you chose to do first is irrelevant, there is no right order.
Only doing that :

Spline36Resize(video,Width(video),SizeY).Spline36Resize(SizeX,SizeY)

or

Spline36Resize(video,SizeX,Height(video)).Spline36Resize(SizeX,SizeY)

produce different results, and Spline36Resize(SizeX,SizeY) is one of the two, don't remember wicho one, but it could have been any of the two.

My point is :
Eventualy notify that because of the chroma shift bug corrected, and the MPEG-2 subsampling taking care of, output is different, eventualy.

But talking about the order the resize is done, producing slighty different result, absolutely not. Because either you have video/image processing knowledge, and in that case you know that's it's irrelevant and result is different but as good as the other, either you don't have knowledge, and in that case, people can be "frigthen" for nothing.

About the MPEG-2 thing, until now all the tests i've done showed that formula produce bad result, unless i'm doing somethig wrong i was saying.
It was the case !
Doing this :

r = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG2")
g = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG2")

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal())

or this

r = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV16()
g = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV16()

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal())

was wrong !
The correct way was this :

r = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$FF0000)
g = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$00FF00)

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal()).ConvertToYV12(ChromaOutPlacement="MPEG2")

and with this correct way, finaly i've been able to verify the rigthness of the formula.

PetitDragon

12th August 2015, 11:57

:D:D:DNew version up, as usual, everything is on the first post.

Thanks jpsdr (and Myrsloik too:D). You are one.:thanks:

Reel.Deel

13th August 2015, 04:22

@jpsdr

What's your thoughts on releasing two binaries (x86/x64) that work with Windows XP and greater and do not require a specific instruction set (similar to tritical's version). I ask this because I think it could be a bit overwhelming to novice users. A friend of mine started using AviSynth not too long, he's a bit computer savvy but he's used to program installers doing all the work. Anyways, I told him to use your version of nnedi3, he got it to work but he was a bit confused due to all the binaries (7 for each platform :eek:). I helped him out and he now knows what instructions sets are. I'm not saying to get rid of the optimized binaries, more like have 2 downloads, the regular binaries for general users, and the optimized binaries for advanced users. Just some food for thought :).

One last thing, there's a tiny issue concerning the readme, csresize is not included in the syntax.

jpsdr

13th August 2015, 08:42

@jpsdr
What's your thoughts on releasing two binaries (x86/x64) that work with Windows XP and greater and do not require a specific instruction set (similar to tritical's version)

That's what you allready found in ReleaseXP directory. I'll check the readme, and if necessary, make it more clear.

@jpsdr
One last thing, there's a tiny issue concerning the readme, csresize is not included in the syntax.

Ah... Ok, i see, i'll update this later.

feisty2

21st August 2015, 15:19

I'm writing a floating point nnedi3 for vaporsynth, and I'm using your asm file for optimization
it works out pretty good, I failed to get the one coming with the original vaporsynth port to work, cuz that one is like, gcc style asm and I'm just NO GOOD at that kinda stuff
but still... I got a tiny little problem here :D
your "dotProd_SSE2" functions won't work here
I see you got "dotProd_m32_m16_SSE2" and "dotProd_m48_m16_SSE2", 2 things to replace "dotProd_C"
and I tried to replace "dotProd_C" with them "asize"-wise, like what you did, and the program gave me corrupted results
then I replaced "dotProd_C" with simply "dotProd_m48_m16_SSE2" and the program crashed.

any idea why? and how to fix?

jpsdr

21st August 2015, 17:35

First, just to be precise, technicaly it's not my functions, i've just put in outside files inline asm, to be able to make an x64 version, so, i personnaly didn't make them, and personnaly didn't do anything, it was allready like this.
If i can look at your code, i can check if maybe (a big "maybe") i see something odd.

Personnaly, i don't do things like Tritical has, playing with functions pointer or anything, i made different fonctions, and call them in different part of code.
If you go to my github and take a look at the code of my VDub filter, you'll see what i mean.

feisty2

21st August 2015, 17:49

Okay, and thx anyways, at least I can enjoy some of the SSE2 stuff from that file :)
Guess I'll have to mess with "dotprod" some more and try to figure out what is going wrong

jpsdr

21st August 2015, 17:58

As you wish, but you can understand that without even being able to look at the code, i obviously can't tell you what may be wrong...

feisty2

21st August 2015, 18:05

Source code?, ooh, here https://github.com/IFeelBloated/NNEDI3SF/blob/master/NNEDI3SF_SSE2.cpp
I'd really appreciate your help :D

jpsdr

21st August 2015, 18:46

Stupid question : You are aware of these ?
https://github.com/jpsdr/NNEDI3/commit/19a21726b8747cd691b33297b5e24615d55ab86d
https://github.com/jpsdr/NNEDI3/commit/948a177fe197bf0284977c42a195d6d6411f9190

feisty2

21st August 2015, 18:51

Not sure if my asm file is outdated or not actually...
Checking it right now

feisty2

22nd August 2015, 04:54

@jpsdr
I got the latest x64 asm file and got results like this
http://i.imgur.com/ismYhdP.png

and how I call those 2 dotprod functions

static void selectFunctions(nnedi3sfData *d) {
const int asize = d->asize;
d->copyPad = copyPad<float>;
d->evalFunc_0 = evalFunc_0<float>;
d->evalFunc_1 = evalFunc_1<float>;

// evalFunc_0
d->processLine0 = processLine0_C<float>;

d->readPixels = pixel2float48_C<float>;
d->computeNetwork0 = computeNetwork0_SSE2;

// evalFunc_1
d->wae5 = weightedAvgElliottMul5_m16_SSE2;

d->extract = extract_m8_C<float, double, double>;
d->dotProd = (asize % 48) ? dotProd_m32_m16_SSE2 : dotProd_m48_m16_SSE2;

if ((d->fapprox & 12) == 0) { // use slow exp
d->expfunc = e2_m16_SSE2;
}
else if ((d->fapprox & 12) == 4) { // use faster exp
d->expfunc = e1_m16_SSE2;
}
else { // use fastest exp
d->expfunc = e0_m16_SSE2;
}
}

I'm doing it right... right?
then maybe the asm code is buggy?

jpsdr

22nd August 2015, 08:24

then maybe the asm code is buggy?
That's not impossible, but on the other hand, since the time i've made the release, it should have poped up since, but maybe no one used this specific mode.
I don't have time right now, but first the pluggin i've made should be checked, playing with fapprox to be sure. If issues occure, original pluggin should be also tested, to see if error has been introduced.

feisty2

22nd August 2015, 14:12

playing with fapprox to be sure. If issues occure, original pluggin should be also tested, to see if error has been introduced.

fapprox works fine (e0/1/2_m16_SSE2 all work out okay)
and I'm 85% sure they (dotprod_sse2 stuff) are broken, everything worked perfectly before I got them in.

but maybe no one used this specific mode.
seems so, dotProd_i16 is preferred over dotProd at int8 process, I removed dotProd_i16 cuz it won't work at higher precision. (0,4,8,12 are the only available fapprox values and 0,4,8,12 & 2 = 0, which means dotProd_i16 is disabled)

Desbreko

22nd August 2015, 22:29

Seems the chroma shift doesn't get corrected with YV411.

g = BlankClip(length=1, width=16, height=16, pixel_type="YV24", color_yuv=$FF0000).KillAudio()
b = BlankClip(length=1, width=16, height=16, pixel_type="YV24", color_yuv=$00FF00).KillAudio()
StackVertical(StackHorizontal(g,b,g,b),StackHorizontal(b,g,b,g),StackHorizontal(g,b,g,b),StackHorizontal(b,g,b,g))
ConvertToYV411()
r16 = Dither_convert_8_to_16().Dither_resize16(Width()*2,Height()*2).DitherPost(mode=-1)
nn3 = nnedi3_rpow2(2, cshift="Spline36Resize")
Interleave(r16,nn3)

jpsdr

23rd August 2015, 10:08

@Desbreko
According the thread talking about 420/444 convertion, i've allready linked several time in this thread, Y411 musn't be chroma shifted when resized according explaination from it, but the chroma shift from nnedi3 is corrected, try with and without cshift, and you'll see. So, i don't have the "16" stuff, but if the resize16 also shift chroma in YV411, according the information from the other thread, it shouldn't.
Edit : here (http://forum.doom9.org/showthread.php?p=1705237#post1705237).
Edit 2 : My mistake...
Edit 3 : Finaly, after re-checking again, no, the chroma shift of YV411 is correct, at least, according what explained in the link up.
Edit 4 : .... Ok, triple, quadruple, etc... check before i fall back on my feets again.

@feisty2
Original code is

if (fapprox&2) // use int16 dot products
{
if (opt==1) extract=extract_m8_i16_C;
else extract=extract_m8_i16_SSE2;
if (opt==1) dotProd=dotProdS_C;
else dotProd= (asize%48) ? dotProd_m32_m16_i16_SSE2 : dotProd_m48_m16_i16_SSE2;
}
else // use float dot products
{
if (opt==1) extract=extract_m8_C;
else extract=extract_m8_SSE2;
if (opt==1) dotProd=dotProd_C;
else dotProd= (asize%48) ? dotProd_m32_m16_SSE2 : dotProd_m48_m16_SSE2;
}

so playing with fapprox is necessary to switch the dotProd, after, i have no idea how to trig or not tne %48. I'm not and will not until a long time be under a 64 bit OS, so i can't make tests on the x64 pluggin for now, to see if problems occurs also. After, it's a standard chain of process, if problems occurs on the x64, test the x86, and if occurs also on the x86, test the original.

feisty2

23rd August 2015, 10:17

okay, I'll install an x86 avs+ and report back :)

Desbreko

23rd August 2015, 13:40

That post is saying the formula for correcting the chroma shift isn't the same for 4:1:1, not that it shouldn't be corrected at all. 4:1:1 is 1/4 horizontally subsampled, so instead of the 0.25*(1-Width_in/Width_out) formula for correcting 1/2 horizontally subsampled formats like YV12 and YV16, you have to use the formula 0.375*(1-Width_in/Width_out).

And nnedi3 itself doesn't cause horizontal chroma shift, provided it's used correctly. What's corrected when you set the cshift parameter is the center shift, which is a shift in both luma and chroma together. It's the resizing used to correct the center shift that causes the chroma shift. So of course there's no chroma shift without setting cshift.

jpsdr

23rd August 2015, 13:52

That post is saying the formula for correcting the chroma shift isn't the same for 4:1:1, not that it shouldn't be corrected at all.

That's what i've begin to wonder, and finaly i've got the same conclusion, you're right.

Will modify this in the next release.

I'll wait for feisty2 results before doing a next release.

@feisty2
If you can provide the avisynth script of the post #188, it may help.

feisty2

23rd August 2015, 17:06

weird, I got avs+ x64 and nnedi3.dll from NNEDI3_v0_9_4_17.7z/x64/Release_W7 and tried this

# Y8 clip #
nnedi3 (field=0,dh=True,fapprox=12,pscrn=1,nsize=3,nns=4,qual=2,etype=1)

and things seemed, pretty normal, nothing crappy happened

and this gave shits like #188

import vapoursynth as vs
core = vs.get_core()
#clp = GRAYS whatever
clp = core.nnedi3sf.nnedi3 (clp,field=0,dh=True,fapprox=12,pscrn=1,nsize=3,nns=4,qual=2,etype=1)
clp.set_output ()

guess I'll investigate dotProd more thoroughly and try to trace the problem...

jpsdr

25th August 2015, 21:08

New version, see first post.

jpsdr

26th August 2015, 18:33

New new version again... :D

Groucho2004

28th August 2015, 13:28

A couple of things about your builds that seem peculiar:

Since XP does not support AVX, I'm a bit puzzled about this version:
Release_Intel_XP_Core2_AVX2

Similarly in your VDub Filters:
Release_Intel_XP_Core2_AVX
Release_Intel_XP_Core2_AVX2

And, as expected, these versions crash on XP => "Illegal instruction"

Also, why do you create "XP" and "W7" versions although there is no code in nnedi3 (as far as I know) that uses APIs exclusive to Windows 6.x?

jpsdr

28th August 2015, 18:03

First, i've always thought than support of instruction was CPU only, it's the first time i see it can be OS dependant, and having an "illegall instruction" is possible even on a CPU which is capable of doing it, so on which it's not normaly/theorically illegal. Well, you can learn all the time.

For the "XP"/"W7", i just compile with "v120" or "v120_xp", no more, no less, to be sure, just in case it may have an effect, of compiling with "v120" produce something not working under XP.

I'll remove XP/AVX in future releases, if not working (i don't have CPU with AVX, even less AVX2, my best is SSE4.2, so never been able to test...).

jpsdr

5th September 2015, 10:58

New version.

luquinhas0021

29th December 2015, 16:06

jpsdr, can you make the modification on nnedi3 algorithm, which tritical never did? Here will go the change, speaked by tritical: replace L1 and L2 by L0.5 (sqrt(abs(error)).

feisty2

29th December 2015, 16:16

Not possible

luquinhas0021

29th December 2015, 16:43

why isn`t?

feisty2

29th December 2015, 23:45

Go retrain nnedi and you could have any new feature you want, mr daydreamer

jpsdr

30th December 2015, 12:56

Not possible, because this is a part of the training wich produces the neural network datas, not a part of the algorithm itself. In the filter, when you choose L1 or L2, it just changes what data package will be used.

Groucho2004

5th March 2016, 11:14

The latest build crashes with Evaluate: System exception - Access Violation.

I took the DLL from "NNEDI3_v0_9_4_20.7z", x86, Release_XP (the other XP builds crash as well).

Script:
colorbars(width = 1920, height = 540, pixel_type = "yv12").killaudio().assumefps(25, 1)
NNEDI3(dh = true)

This is on XP32SP3, any Avisynth version.

I seem to recall that previous builds worked. However, I can't find them on your github page, there is only the latest release.

SEt's Avisynth MT returns this (probably because it has better exception handling):
Avisynth: access violation at 0x00011C0D in E:\Apps\VideoTools\AVSPlugins\AutoLoad\nnedi3.dll,
attempting to read from 0x00000000

It crashes with mpc-hc and AVSMeter but not with VirtualDub.

jpsdr

5th March 2016, 12:31

Groucho2004

5th March 2016, 13:20

Argh.... Not crashing with VDub is annoying, can't have disassembled code.
Nevertheless, it's not something related/specific to x64, so it's probably not an issue with the ASM code.
Is it XP specific ? Do you have tihs issue on others OS (if you have others OS) ?
I think the last version is the first version compiled with VS2015. If you recall previous build worked, maybe this is a clue.
Now i have VS2015Updt1. I'll PM you a link with a new build for test, just in case.
Otherwise, I'll do more tests after WE, at work i have XP32SP3, with VS2010.
VS2015 is compatible with XP but you probably have to set a target platform flag in your project properties. You should also not link statically, with newer versions of VS and DLLs it is not advisable (source (https://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.140%29.aspx)).

Reel.Deel

5th March 2016, 13:24

I seem to recall that previous builds worked. However, I can't find them on your github page, there is only the latest release.

Do you remember which version? I have v0.9.4.7 through v0.9.4.18.

Groucho2004

5th March 2016, 13:29

Do you remember which version? I have v0.9.4.7 through v0.9.4.18.
No, I don't remember. The problem is most likely the switch to the VC14 compiler.

jpsdr

6th March 2016, 11:18

VS2015 is compatible with XP but you probably have to set a target platform flag in your project properties.
Even that seems not enough. I think i'll try to install back VS2013. Once done, i'll probably make a new release, but don't expect things too soon.
I think only the last (.20) is compiled with VS2015.

Groucho2004

6th March 2016, 11:24

Even that seems not enough. I think i'll try to install back VS2013. Once done, i'll probably make a new release, but don't expect things too soon.
I think only the last (.20) is compiled with VS2015.
Don't change anything just on my account. The "original" nnedi3, (or rather my fturn mod) suits my needs.

Groucho2004

6th March 2016, 18:13

Even that seems not enough. I think i'll try to install back VS2013. Once done, i'll probably make a new release, but don't expect things too soon.
I think only the last (.20) is compiled with VS2015.
This (https://connect.microsoft.com/VisualStudio/feedback/details/1789709/visual-c-2015-runtime-broken-on-windows-server-2003-c-11-magic-statics) may be a potential cause.

TheFluff

7th March 2016, 02:49

hello_hello

7th March 2016, 06:20

encouraging people to upgrade to an os from this decade isn't going to kill anyone, and the people who are determined to be stuck in 2001 for as long as possible are kind of a lost cause anyway

You seem to be confusing "determination" with Microsoft's inability to produce a better OS, while assuming everyone only owns a single PC. Not to mention the fact Microsoft decided to exclude XP from the free upgrade to Win10 offer, which is more about opportunity than determination.

jpsdr

7th March 2016, 10:21

@Groucho2004
Issue has been reported around 5 months ago, i don't remember when the Update 1 of VS2015 was out.
Thanks for this information.

Groucho2004

7th March 2016, 13:12

just drop support for xp already, jeez

encouraging people to upgrade to an os from this decade isn't going to kill anyone, and the people who are determined to be stuck in 2001 for as long as possible are kind of a lost cause anyway
Dropping support for XP (or even Win2K for that matter) just for the heck of it seems rather silly. If the code doesn't use APIs that are only supported in Win7/8/10 I can't find a reason to deliberately break compatibility with earlier OS versions.

Your post is yet another predictable rant, I find it peculiar that you get so upset about people's personal choices.

Daemon404

7th March 2016, 18:18

Dropping support for XP (or even Win2K for that matter) just for the heck of it seems rather silly. If the code doesn't use APIs that are only supported in Win7/8/10 I can't find a reason to deliberately break compatibility with earlier OS versions.

I don't know where you saw this was deliberate. New tools, shockingly, do not support old OSes which have not been supported by their maker since before the release of said tools.

I think it's somewhat unreasonable to use an OS that has no support from its make, and is EOL'd, yet to expect things written/compiled in 2016 still work on them.

Groucho2004

7th March 2016, 19:54

New tools, shockingly, do not support old OSes which have not been supported by their maker since before the release of said tools.I was referring to VS2013/2015 which, according to MS, do support XP. Besides, there is nothing in the code of nnedi3 that would prevent it from running on XP and jpsdr even provides binaries targeted for XP.

I think it's somewhat unreasonable to use an OS that has no support from its make, and is EOL'd, yet to expect things written/compiled in 2016 still work on them.I'm not sure why the year in which something was written/compiled is relevant. If something is written using APIs exclusive to WinNT 6.x I do of course not expect it to run on WinNT 5.x. However, if the code and the compiler support NT 5.x, why drop support for it?

hello_hello

6th April 2016, 02:00

Regarding the problem with the XP flavour of NNEDI3 0.9.4.20....

Is it possible the XP and Win7 versions in the 7z package are the same file? There's differences.... the modified times are 10 seconds apart and they have a different MD5 Hash, but they appear to be exactly the same in size. They also behave the same way for me (running XP).

QTGMC 3.33 results in an access violation error message at lines 729 and 510 (in QTGMC script) when opening a script with MPC-HC and MeGUI. That applies to both the XP and Win7 versions of NNEDI3.
The same script opens fine in VirtualDubMod when using either version.
Not that I know if it means anything, but it seems a little co-incidental.

Groucho2004

6th April 2016, 08:31

Regarding the problem with the XP flavour of NNEDI3 0.9.4.20....
It appears that this (http://forum.doom9.org/showthread.php?p=1759707#post1759707) was the cause of the VS2015 builds crashing on XP.

Is it possible the XP and Win7 versions in the 7z package are the same file?
...
they have a different MD5 Hash
I don't know how to respond to this...

jpsdr

6th April 2016, 08:44

Is it possible the XP and Win7 versions in the 7z package are the same file?
No.

the modified times are 10 seconds apart
I build them one after another, so the difference in time is the time to build, change the profile in VS, build the next, etc...
So, of course, expect several seconds between them.

Soon (within less than 2 weeks i hope) i'll release a .21 version, with build fix for XP, thanks to Groucho2004 who provides me the links about the issue, and was nice to test...;)

hello_hello

7th April 2016, 04:25

"Is it possible the XP and Win7 versions in the 7z package are the same file?"

I don't know how to respond to this...

I mentioned the difference in modified time and MD5 Hash because I thought it might indicate the two files were created using the same settings rather than one literally being a copy of the other. I don't know if that'd result in a different MD5 Hash, but simply copying a file doesn't change it's modified time either.

Try again with a bit more context.

"There are differences ...the modified times are 10 seconds apart and they have a different MD5 Hash"

Apparently I should have explained why I mentioned it, although in hindsight I'll admit describing them as "the same file" rather than "the same" was a newbee mistake and an open invitation for someone to be "clever".

StainlessS

7th April 2016, 04:30

Different MD5 is different file (Time and other attributes make no difference).

hello_hello

7th April 2016, 04:33

Soon (within less than 2 weeks i hope) i'll release a .21 version, with build fix for XP

Thanks.
Admittedly I thought it was unlikely they were the same file or accidentally created using the same settings because it seemed a little too obvious, but you never know, so I thought I'd ask.
I'll look forward to the new version.
Thanks again.

jpsdr

7th April 2016, 08:43

but they appear to be exactly the same in size.

Just for the record, i've noticed that very often final builds have exactly the same size, even when between them there is code change. Only case of realy minor code change, of course.

Groucho2004

7th April 2016, 09:08

"Is it possible the XP and Win7 versions in the 7z package are the same file?"

I mentioned the difference in modified time and MD5 Hash because I thought it might indicate the two files were created using the same settings rather than one literally being a copy of the other. I don't know if that'd result in a different MD5 Hash, but simply copying a file doesn't change it's modified time either.

Try again with a bit more context.

"There are differences ...the modified times are 10 seconds apart and they have a different MD5 Hash"
The context makes no difference. The time stamp of the files has nothing to do with their content.

"the same file" rather than "the same"
:confused::confused:

Apparently I should have explained why I mentioned it, although in hindsight I'll admit describing them as "the same file" rather than "the same" was a newbee mistake and an open invitation for someone to be "clever".
I was not trying to be clever, I was simply stumped that a member who's been around here for 5 years and has posted ~2500 messages doesn't know what a MD5 hash is.

ryrynz

7th April 2016, 13:49

"Is it possible the XP and Win7 versions in the 7z package are the same file?"

Yeah not to drag this out, but if a programmer smart enough to create a port of NNEDI3 for Avisynth releases & multiple versions of it, you can be sure there's a difference.
And if for some reason a mistake was made, you'd be sure one of the doom9 members here would've picked up on it a long time ago.
Give people the benefit of the doubt, especially when you don't understand the technical aspects. This should hopefully close the topic.

hello_hello

7th April 2016, 16:56

The context makes no difference. The time stamp of the files has nothing to do with their content.

If a file was simply a copy of another they'd have the same modified time. Once again, I mentioned the difference in MD5 Hash and modified time to indicate I thought rather than one file being a direct copy of another they might be the same file created twice with identical settings. Open an MKV with MKVMergeGUI and remux it. Remux it again. The resulting MKVs are essentially the same file but they'll have a different MD5 Hash, and believe it or not, a different modified time. I thought it'd be obvious that's what I was referring to. I thought I'd adequately explained it in my last post but apparently it didn't help, even after admitting I probably should have said "the same" rather than "the same file" for those easily stumped. Third time lucky, maybe?

Yeah not to drag this out, but if a programmer smart enough to create a port of NNEDI3 for Avisynth releases & multiple versions of it, you can be sure there's a difference.
And if for some reason a mistake was made, you'd be sure one of the doom9 members here would've picked up on it a long time ago.
Give people the benefit of the doubt, especially when you don't understand the technical aspects. This should hopefully close the topic.

I already admitted it was unlikely the files were the same or they were created with the same settings, but I thought I'd ask just in case. Thanks for dragging out a topic that should have been closed already.
Just to be clarify though.... I can be sure someone else would pick up a mistake that I can be sure wouldn't be made in the first place. Is that how it works?

StainlessS

7th April 2016, 21:53

It is quite understandable that someone who has never had cause, to not know that file/dir attributes are not part of the file.
Hello_Hello, for instance on Fat FileSys, the times stamps, file size, read/write status, etc are stored in the directory for the
file, and if copy is done, then attributes (where appropriate) are duplicated to the target directory for the copy.
I have no idea how NTFS stores general attributes, but expect that it is pretty much the same.

EDIT: Further to FAT: Fat only stores data on where clusters are located. Cluster being a group of consecutive sectors,
to reduce the amount of 'tracking' data, so a file even if it only occupies a single byte will occupy at least a single cluster (normally 8
512 byte sectors, especially if standard compression/encryption is involved [standard compression/encryption only works on 8 sector
clusters ie 4KB, unless things have changed]). The file itself consists of a number of bytes [spread out over a number of clusters], the only
way the filesystem can determine size, is to view the directory information, and to curtail any additional data after that [rest is rubbish]).
FAT: has no Access Control Lists, which are additional attributes to the file in NTFS, and I have no real idea on how that is accomplished.
(I have in past [2 decades ago] written equivalent to FAT ChkDisk software, but running upon non PC equipment, so I [at least at one time]
had some general idea of how that stuff works).

hello_hello

8th April 2016, 01:09

I'll confess I don't understand how the file attributes not being part of the file affect anything I said. Mind you I hadn't really thought about it until now, but if a copy of a file has exactly the same MD5 Hash as the original, it seems logical they can't be.
I pointed out the difference in MD5 Hash and modified time to indicate I realised one file wasn't likely to be a direct copy of another but possibly created using the same settings, although it's not impossible for a file to be a copy that's altered in some way so it has a different modified time and MD5 Hash as a result. An example might be opening an MKV with MKVToolNix's header editor and changing an attribute. It wouldn't necessarily change the functionality of the MKV, or it's file size. Unfortunately though, not explaining that in detail led to the assumption I don't know what an MD5 Hash is, while I assumed mentioning the different MD5 Hash meant I wouldn't have to explain it.

StainlessS

8th April 2016, 01:23

An MD5 (or similar) is a numerical 'Fingerprint' which identifies (with almost 100.0% certainty) that two files are the same.
(MD5 is calculated from the numbers/bytes within the file, the how does not matter but you can look it up).
Even a small change in a file (1 byte, 1 bit) results in a big difference in MD5, making it very difficult to forge the same MD5.
It is possible for more than a one single unique content file to produce that same checksum (MD5) but in almost all circumstances the
two files would be completely different, and same MD5 can occur just by accident, ie obvious that it is not a forgery
because content is totally different. [eg a 500 bytes text file COULD have exact same MD5 as a 2GB Movie file,
but it would be obvious that they are not the same file, it would take an exceptional amount of computer power to
change a small text file to be different and still make sense (ie make forgery by changing original a little)].

EDIT: MD5 is calculated from the file contents, a number/fingerprint calculated from the contents, not the Timestamp etc.
You can change time/date read/write status hidden attribute etc without it affecting the MD5. There would be no point to MD5 if it
changed for everybody that eg saved it at different times (timestamp, there are 3 different timestamps for a FAT file,
Creation, Modification and Last Access).

EDIT: An MD5 CAN with 100% certainty make it clear that two files are different.

hello_hello

8th April 2016, 04:40

Thanks for the info, although to be honest I can't see anything I've written that implies I don't know what an MD5 is, and I did state it's logical that timestamps and attributes wouldn't effect the MD5. I honestly thought I was originally implying I knew the two files couldn't be exact copies due to the different MD5, because that's the main reason I specifically mentioned it, but the possibility the two files were created independently using the same settings crossed my mind, as did the possibility one was initially a copy of the other, but later modified in some way. The latter didn't seem likely, but I had no idea I was giving the impression I didn't understand what an MD5 was or that I mentioned the different modified date for any other reason than it also indicated the files aren't exact copies.
In hindsight I probably could have phrased the question a little less literally so as not to upset the pedantic police, but at the time it didn't seem necessary.

jpsdr

17th April 2016, 14:16

New build, see first page.

bxyhxyh

17th April 2016, 19:34

I've been wondering since I started to use it.
What is core2 builds for?
For core2duo processor or any Intel processor with 2 cores?

ryrynz

18th April 2016, 02:53

I've been wondering since I started to use it.
What is core2 builds for?
For core2duo processor or any Intel processor with 2 cores?
You don't have optimised builds for dual cores.. Only instruction sets. First guess is correct.

hello_hello

20th April 2016, 23:18

New build, see first page.

I haven't used it yet, but thank you!

DJ-1

25th April 2016, 07:53

So if im using the x64 version with a 3770K the Release_W7 version is the right one to use?

Sent from my LG-H815 using Tapatalk

ryrynz

25th April 2016, 08:24

So if im using the x64 version with a 3770K the Release_W7 version is the right one to use?

W7_Core2_SSE4.2

DJ-1

25th April 2016, 08:37

Thanks...just need to find the update 2 runtime it mentions....

Sent from my LG-H815 using Tapatalk

jpsdr

20th May 2016, 08:49

Switching discuss here about MT.
Don't want to mess with the core structure, i also want it continue working on any avisynth version, i'm working on something which should make the filter "NICE" (i think.. hope), with the less code change in the core structure.
Just have to find/gather some informations of how doing some things with Visual Studio. Allready find how to use mutex, just have to find how i can do something similar to mutex, but not exactly a mutex. In fact, something that will wait for a change of state of some "mutex like" object. I'll probably find what i'm looking for in searching on google something like "thread synchronization visual studio"...

MysteryX

20th May 2016, 10:39

jpsdr

20th May 2016, 11:30

shekh

20th May 2016, 11:31

Look for winapi documentation for synchronization primitives (msdn). "mutex like".. are you looking for critical section?

jpsdr

20th May 2016, 13:08

Ok MT guys ! ;)

You can test, benchmark, MT_NICE, torture this (https://github.com/jpsdr/NNEDI3/releases/tag/beta) version.

It's for now only x86, and compiled with VS2010 (so, should also work on XP...).

EDIT : I've add on the release page the modified files (nnedi3.cpp and nnedi3.h) in nnedi3_src_beta.7z.

GMJCZP

21st May 2016, 01:38

Thank you for your effort, jpsdr!
Still I am a XP user, lol.

EDIT: MT is about SEt MT?

jpsdr

21st May 2016, 10:24

Yes, but also avs+ MT.

MysteryX

21st May 2016, 11:59

Question for avisynth masters.
In the nnedi3 constructor, there is :

child->SetCacheHints(CACHE_GET_WINDOW,3);

What does this do ?
Is it still necessary ?
Or is it interesting to keep this on not MT mode, but remove it on MT mode ?

If I remember correctly, someone mentioned recently that SetCacheHints is a hack that could be used for the filter to define its MT compatibility modes without having to configure it manually.

It's not intuitive but it's the only place that they could put the extra information without needing to change the API.

Chikuzen

21st May 2016, 16:03

Question for avisynth masters.
In the nnedi3 constructor, there is :

child->SetCacheHints(CACHE_GET_WINDOW,3);

What does this do ?
Is it still necessary ?
Or is it interesting to keep this on not MT mode, but remove it on MT mode ?

Otherwise, i think i've found what i was looking for in my previous post.

child->SetCacheHints(CACHE_GET_WINDOW, any_int_value) do nothing and just returns cache filter's current h_span value of window if cache is inserted.
on avisynth2.6, it will always return 0 (default value of LRU cache).
on avisynh+MT, it always returns 2 (hard coded value).

anyway, I think that the code is not necessary because the return value is not used at all.

Wilbert

22nd May 2016, 15:55

Looking at the 0.94 sources it should be SetCacheHints(CACHE_WINDOW, frame_range), but i have no idea whether it is necessary.

jpsdr

23rd May 2016, 08:56

No news, good news ? MT version is working perfectly fine ?

pinterf

23rd May 2016, 10:42

Immediate crash in avs+

LoadPlugin(".\nnedi3.dll")
SetFilterMTMode("DEFAULT_MT_MODE", 3)
Avisource("dv_Hi8.avi",audio=false).trim(0, 499)
ConvertToYV12()
nnedi3_rpow2(2, Threads=1)
Prefetch(2)

without MT it works fine.

December 23, 2015 version did not crash (but is showing garbage as we know).

Reel.Deel

23rd May 2016, 13:15

I had a similar experience to pinterf. Instantly crashed VDub and AVSMeter. VDub error message: "The instruction at 0x5d76a138 referenced memory at 0x484c29e0. The memory could not be written."

LoadPlugin("nnedi3.dll")

SetFilterMTMode("nnedi3", 1)
SetFilterMTMode("nnedi3_rpow2", 1)

ColorBars(pixel_type="YV12")
nnedi3_rpow2(2)
Prefetch(4)

jpsdr

23rd May 2016, 13:28

Ok... :(
... First thought is the fact that some threads can't change mutex status... Will try to see...
Edit :
Hum... Forcing an MT statuts on not MT avs to force the use of the code using mutex and event works, so, my first thought seems right, the LPSECURITY_ATTRIBUTES probably doesn't allow some threads to acces mutex and/or event...

MysteryX

23rd May 2016, 15:57

I will point out, however, that calling NNEDI3 through edi_rpow2 script does work in MT... somehow.

Reel.Deel

23rd May 2016, 16:14

I will point out, however, that calling NNEDI3 through edi_rpow2 script does work in MT... somehow.

That's because edi_rpow2 is a script function. If nnedi3_rpow2 was an actual script it would also work. Currently nnedi3_rpow2 is a script written in C++. This creates problems in AviSynth+ MT, read here (http://forum.doom9.org/showthread.php?p=1768086#post1768086) and subsequent posts.

jpsdr

30th May 2016, 20:32

After several unsuccesfull tries, i've gone to very basic.
nnedi3 and nnedi3_rpow2 report themselves as MT_MULTI_INSTANCE if an MT version of avisynth is detected, and in case it wouldn't be enough, i've add a mutex preventing several getframe running from the same instance filter for safety.
New version on first page.

MysteryX

12th July 2016, 05:48

This build is not compatible with the latest Avisynth+. A new build is required.

jpsdr

12th July 2016, 08:49

I know, but i want to build "once for all", so i still have to update VS2015 to Updt 3, and with each new update of VS, comes a new version of Intel Compiler (well, most of the time). So, i'll wait a little to see if a new IC pops up or not before doing anything. Dont want to waste time installing/uninstalling several times, and don't want to build to see a new IC poping just a few days after posting it. If within a few weeks nothing pops, i'll update my VS2015 to Updt3 and make a new build. if something pops before, i'll do it at this time.

MysteryX

12th July 2016, 13:13

You could just change the headers file and recompile with what you have.

There might also be another version of AVS+ coming, with possibly new headers, and it might become possible to register the MT mode without using env2. There are several things to wait for. Just doing a quick recompile would allow people to keep using NNEDI3 in the mean-time and not have to rush for doing a proper compile.

jpsdr

12th July 2016, 13:27

I've tried to build a new version at work (under VS2010), and now i have something i didn't have before :

1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(115): error C2059: erreur de syntaxe*: ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(115): error C2238: jetons inattendus avant ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(570): error C2059: erreur de syntaxe*: ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(570): error C2238: jetons inattendus avant ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(624): error C2059: erreur de syntaxe*: ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(624): error C2238: jetons inattendus avant ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(115): error C2059: erreur de syntaxe*: ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(115): error C2238: jetons inattendus avant ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(570): error C2059: erreur de syntaxe*: ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(570): error C2238: jetons inattendus avant ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(624): error C2059: erreur de syntaxe*: ';'
1>c:\documents and settings\jean-philippe.scotto\mes documents\perso\vs2010\nnedi3\nnedi3\avisynth.h(624): error C2238: jetons inattendus avant ';'

"erreur de syntaxe" means "syntax error"....:(
Out of question for me to use something which can't be compiled under at least VS2010. While the avisynth header is not fixed, i'll use my previous one.

EDIT : removing delete and replacing by {return(*this);} fixed the issue.

jpsdr

14th July 2016, 11:14

Reel.Deel

14th July 2016, 14:32

I've updated from r1858 to r2043, but still haven't re-compiled my filters (including nnedi), and everything works fine. Avsmeter report that i'm indeed with r2043. I'm under Win7x64, and opening the avs file with VDubx64 works fine. I expected a crash according what i've read, but not... Strange.

I reported the same thing (http://forum.doom9.org/showthread.php?p=1772768#post1772768), for some strange reason X64 plugins using IScriptEnv2 work. I asked ultim about it:

<Reel_Deal> ultim, why is that only 32-bit is affected?
<ultim> the manifestation of the problem depends partially on the how internal memory layout of IScriptEnv2 is changed by the compiler after GetVarDef was added to IScriptEnv. it might be that due to some kind of padding the offsets of the vtable in IScriptEnv2 do not change at all for x64 builds.
<ultim> it is also possible though that the interface is equally broken in x64, but you'd only see it later due to internal state corruption
<ultim> to know which of these is the case, someone with deep knowledge of MSVC++ compiler internals would be necessary
<ultim> this means i wouldn't rely on x64 being correct until testing for days and tens of thousands of frames

jpsdr

15th July 2016, 12:49

New version, see first post.

Magik Mark

18th July 2016, 08:06

May I ask a good parameter for chroma upscaling? Similar to madvr

jpsdr

23rd July 2016, 12:12

New version, see first post.

jpsdr

12th August 2016, 20:01

New version, minor update.

jpsdr

30th August 2016, 20:39

Reel.Deel

30th August 2016, 20:53

New version, see first page.
Update to use my threadpool. I've made a few bench, speed seems similar, but the number of threads is reduced. Of course, the more cores you have, the more it's noticeable.

Just out of curiosity, why do you delete the previous releases? Sometimes it comes in handy to have them.

bilditup1

31st August 2016, 04:49

Any reason why the XP builds would perform faster than the W7 builds on a W10 machine using avs+ mt r2172? I tried this a few times by accident. The first two times I got an increase in speed of 1.5fps, the last time of .6fps. In between, there was some instability - it would either quit after one frame or come to a complete halt (stops processing frames, but doesn't quit or become unresponsive). The instability I expected, but the increase in speed of the XP_Core2_SSE4.2 build relative to the W7_Core2_SSE4.2 build was not.

ryrynz

31st August 2016, 06:52

Any reason why the XP builds would perform faster than the W7 builds on a W10 machine using avs+ mt r2172?

If it's that unstable what's the point in asking? It's obviously not working right.

+ Add a thread parameter for the resampler if use of the MT resamplers.

Can you provide some additional information about this? Examples?

Groucho2004

31st August 2016, 08:34

In between, there was some instability - it would either quit after one frame or come to a complete halt (stops processing frames, but doesn't quit or become unresponsive).
If you're referring to this (http://forum.doom9.org/showthread.php?p=1779369#post1779369) script, you have to consider that you're running a complex script (QTGMC) and combining two different multi-threading systems. This is usually not a good idea, you should stick with just using "Prefetch()" and disable the internal multi-threading of plugins (EdiThreads = 0, DftThreads = 0).

jpsdr

31st August 2016, 08:43

Can you provide some additional information about this? Examples?
It's in the readme of the release.

And, consider my release for people like me, who are not using the internal multi-threading of avs+ (or Set version). If you want to use the internal multi-threading of avisynth, stays with standard resamplers, and set nnedi threads to 1.

I'll even check if i can make another step/modification to nnedi, to not use at all the threadpool if the number of threads is 1. For now, it's still like the original version, always using the threadpool, whatever the number of threads.
I advance one step at the time.

bilditup1

31st August 2016, 11:46

If it's that unstable what's the point in asking? It's obviously not working right.

Eh, so sue me for being curious.

If you're referring to this (http://forum.doom9.org/showthread.php?p=1779369#post1779369) script, you have to consider that you're running a complex script (QTGMC) and combining two different multi-threading systems. This is usually not a good idea, you should stick with just using "Prefetch()" and disable the internal multi-threading of plugins (EdiThreads = 0, DftThreads = 0).

Thanks for the tip.

ED: Looking at the wiki, it appears both that 0 is the default for each of those settings, and that 0 denotes 'set amount of threads equal to logical cores'. Has this changed?

jpsdr

31st August 2016, 12:32

A little, it's now equal to the number of physical cores, because after some testbench, i realised that it was what produced the best result.

BTW, when i said that my release "are not" for those who use internal MT, it doesn't mean it's not working. It's intended to work, it's designed to work with, it must work with, but it's just that it may not be the optimal result, and will probably not be. All my release are only MT_MULTI_INSTANCE, not MT_NICE_FILTER, because not intended to and not compatible with.

A new release with minor fix and not use of poolthread when threads=1 in a few hours.

jpsdr

31st August 2016, 18:49

Finaly, new release is delayed, i've think of something i want to add. Expect more this WE.

ryrynz

1st September 2016, 04:00

I'm getting a no function named error with nnedi3_rpow2, when running through ffdshow with both W7 releases. No issues with .24.

jpsdr

1st September 2016, 07:53

Euh... Sorry, absolutely no idea, as i'm not using ffdshow at all (and have no idea how it works)... I'm only using VDub (and avsmeter to check sometimes).
If something goes wrong, there should be a message throw by env->ThrowError. Do you have any ? The nnedi3_rpow2 is still properly added to avisynth, because otherwise it wouldn't work at all.
The only other option i can see should be if some dll (but i don't require any specific) would be missing. But i think you're up to date to all the redustribuable.

Groucho2004

1st September 2016, 07:59

I'm getting a no function named error with nnedi3_rpow2
The most common causes for this error are:

Wrong bittage (32 bit process loading 64 bit DLL and vice versa)
MS runtime missing

ryrynz

1st September 2016, 09:52

The most common causes for this error are:

Wrong bittage (32 bit process loading 64 bit DLL and vice versa)
MS runtime missing

I updated the redistributables with the AIO only a month ago.. guess I'll run the latest release..
..
And yeah that fixed it.. surprisingly the AIO gives you no info about it not updating any redistributable to the latest version, it just says it's already installed. Only by uninstalling those packages not stamped with latest date and then running the AIO again do I see that there were updates that were not applied.

If these are so critical to apps working right and are updated reasonably often it's a wonder that Windows doesn't do a better job of keeping them up to date. Anyway thanks, that made me go through and make sure everything's up to date.

But i think you're up to date to all the redustribuable.

Yeah I thought I was too. =/

Groucho2004

1st September 2016, 10:52

I updated the redistributables with the AIO only a month ago.. guess I'll run the latest release..
..
And yeah that fixed it.. surprisingly the AIO gives you no info about it not updating any redistributable to the latest version, it just says it's already installed. Only by uninstalling those packaging not stamped with latest date and then running the AIO again do I see that there were updates that were not applied.

If these are so critical to apps working right and are updated reasonably often it's a wonder that Windows doesn't do a better job of keeping them up to date.
The frequent runtime updates can be a pain in the butt. Usually the developer distributes the correct runtimes with the software (as for example ultim does with his avisynth builds). At the very least the developer should write a note which runtimes including the exact version number are required.

ryrynz

1st September 2016, 11:58

At the very least the developer should write a note which runtimes including the exact version number are required.

Are runtime version errors even something Avisynth can display? Surprised there isn't some logging of this error TBH.

BTW jpsdr, do you know how much of an impact the AVX512 instructions make with this? Anyone with a Xeon? General mainstream users gotta wait until Cannonlake or newer before we can try it,
I'm curious what it brings to the table.

jpsdr

1st September 2016, 15:31

BTW jpsdr, do you know how much of an impact the AVX512 instructions make with this?
Not realy, i have a lot of cores ;), but i don't have AVX512 neither. I just make the build in case someone would be interested with.
In one of the ReadMe, i say with what version exactly it's build.

jackoneill

1st September 2016, 20:27

None at all, considering that the AVX512 instructions, if any are actually used, end up in functions where barely any CPU time is spent. The functions that matter are all written in asm, and the compiler never touches them.

This applies to the SSE4.2 and AVX2 binaries as well.

jpsdr

2nd September 2016, 17:23

New version, see first post.
I've added several parameter to allow to tune the created threadpool. I've made several testbench, and set the default settings correspond to the best result i have on my PC. But, it doesn't mean it will be also what produce the best result on others PC, so, the parameters added will allow to eventualy each one tune according his hardware configuration.

Check the ReadMe file for precise information.

Sm3n

25th September 2016, 10:13

Hi,

I'm having issues with this plugin. I'm using AVS+r1858-pfmod both x86 and x64 can I load it into this mod? I assume I do.

The error are the next: avspmod is freezing or "System exception - Illegal Instruction".

I have to go back with the old nnedi3.

jpsdr

25th September 2016, 10:50

I think you're using a "wrong" Intel version build, using instructions not supported by your CPU. In that case, first begin by using just the standard version, not the Intel.

Sm3n

25th September 2016, 11:27

I think you're using a "wrong" Intel version build, using instructions not supported by your CPU. In that case, first begin by using just the standard version, not the Intel.

That was my first guess ^^ and based on what x264 says "cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX" I tried all intel.

I'll check the standard.

thx for your support

Edit: OK I found the good one: "Release_Intel_W7_Core2_SSE4.2"

dandyclubs

28th September 2016, 09:27

D:\Worker\AVSMeter>AVSMeter.exe -avsinfo

AVSMeter 2.4.1 (x86) - Copyright (c) 2012-2016, Groucho2004

VersionString: AviSynth+ 0.1 (r2172, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth.dll time stamp: 2016-08-19, 15:51:34
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins

[CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\EEDI2.dll [0.9.2.0]

[CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll [2.1.0.0]
C:\Program Files (x86)\AviSynth+\plugins+\mvtools2.dll [2.7.0.22]
C:\Program Files (x86)\AviSynth+\plugins+\nnedi3.dll [0.9.4.27]
C:\Program Files (x86)\AviSynth+\plugins+\RgTools.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll [n/a]

[Plugin errors/warnings]
----------------------------------------------------------------------------------------------------------------------

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/nnedi3.dll'. Platform returned code 126:
지정된 모듈을 찾을 수 없습니다.

Dependencies that could not be loaded:
libiomp5md.dll

----------------------------------------------------------------------------------------------------------------------

so i get libiomp5md.dll file form Linx

copy to C:\Windows\SysWOW64

i have Intel 5820k

so copy nnedi3.dll from Release_Intel_W7_Core2_AVX2

but not work.

i add EdiThreads = 0, DftThreads = 0

QTGMC( Preset="Faster" , EdiThreads = 0, DftThreads=EdiThreads )

run AVSMeter test.avs

avx2 build is not work.

i change nnedi3.dll from Release_Intel_W7_Core2_SSE4.2

sse4.2 build is work...

i want NNEDI3 0.9.4.24 or 23

old NEEDI upload plz

ryrynz

28th September 2016, 10:11

I can't get .27 or .26 to work, I just get a black screen unless I remove prefetch or set it to 1. Tested .27 W7 and W7 SSE & AVX512 releases.

ffdshow_source()
nnedi3_rpow2(rfactor=2, nsize=4, nns=1,cshift="Spline36Resize")
Prefetch(4)

.25 works as expected.

old NEEDI upload plz

.24
https://uploadfiles.io/b2057
.25
https://uploadfiles.io/0b059

dandyclubs

28th September 2016, 10:45

.24 & .25

https://ufile.io/bf71111

this bf71111-writing---andrea-a-lunsford---the-st.-martins-handbook-with-2009-mla.PDF file

ryrynz

28th September 2016, 11:58

this bf71111-writing---andrea-a-lunsford---the-st.-martins-handbook-with-2009-mla.PDF file

Dunno what happened there. Fixed link.

dandyclubs

28th September 2016, 12:31

.25
https://uploadfiles.io/0b059

25 avx2 build fine work.

thanks!!

jpsdr

28th September 2016, 18:54

... It seems there is something between my threadpool and the core multithreading, even if theoricaly it shouldn't, as the version match the introduction of it.
I will not have the possibility to take a look before a long time... And when i think about it, not before next year indeed...

jpsdr

6th October 2016, 19:19

I thought of a little something, so new version, give it a try to see if prefetch is working again or not.

ryrynz

7th October 2016, 14:09

SetFilterMTMode("DEFAULT_MT_MODE", 2)
ffdshow_source()
nnedi3_rpow2(rfactor=2, nsize=4, nns=1,cshift="Spline36Resize")
Prefetch(4)

Gives me a black screen. Removing prefetch makes it work.

jpsdr

7th October 2016, 15:56

So, it wasn't the little something... Ok.

jpsdr

11th October 2016, 18:21

New version, fix a deadlock possible case. I've tried to test Prefetch, but i had an error message saying that only one Prefetch is allowed by script, even if my script has only one Prefetch line, so... Those who have a working MT version, feel free to test this new release.

pinterf

11th October 2016, 19:43

ryrynz

11th October 2016, 23:42

64 bit AVX2 release is working fine for me.

jpsdr

12th October 2016, 08:52

There is a missing dll:

32 bit W7 Core2 SSE4.2:
Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/nnedi3.dll'. Platform returned code 126:

Dependencies that couldn't be loaded:
libiomp5md.dll

Install the Intel Redistribuable as said in the ReadMe here (https://software.intel.com/sites/default/files/managed/05/a4/ww_icl_redist_msi_2016.4.246.zip).

It's working fine, nice, my threadpool is finaly good... ;)

pinterf

12th October 2016, 09:03

Install the Intel Redistribuable as said in the ReadMe here (https://software.intel.com/sites/default/files/managed/05/a4/ww_icl_redist_msi_2016.4.246.zip).

It's working fine, nice, my threadpool is finaly good... ;)
Thanks, stupid (read)me :)
Yesterday I was working on the prefetch problem (I was glad that it was finally easily reproducible), but could not fix it so far.

jpsdr

12th October 2016, 13:53

On what release version prefetch is still working properly ? I've made some little modifications on my threadpool, which theoricaly shouldn't have effect on actual situation (but everyone know the "theoricaly" and "shouldn't" ;) ), and i would like to be able to test.

pinterf

12th October 2016, 14:05

I will send you soon a link for a build, that seem to be OK.

Question:
Why are the filters specified as CACHE_DONT_CACHE_ME?

jpsdr

12th October 2016, 15:54

Are you talking about this :

int __stdcall nnedi3::SetCacheHints(int cachehints,int frame_range)
{
switch (cachehints)
{
case CACHE_DONT_CACHE_ME:
return 1;
case CACHE_GET_MTMODE:
return MT_MULTI_INSTANCE;
default:
return 0;
}
}

I've got this exemple from Ultim, it said it's the proper way to define the filter mode (and to not use SetFilterMode).
Now, i've just copied the code. I have no idea what the CACHE_DONT_CACHE_ME line is doing, neither why the exemple code of Ultim was like this. If you said that it's better to remove this line, i will.
(I'm not at home yet, so can't test the build yet).

pinterf

12th October 2016, 16:11

Remove it.
It's mainly for those filters that somehow manipulate the order or frames and do not filter the video itself.
(e.g. Trim, Reverse, SelectEvery, SeparateFields, AssumeFPS, DeleteFrame, DuplicateFrame, Loop, KillAudio)
If the frame is not cached, it will be recalculated for each getframe request if needed again. So removing that hint from the plugin will make the scripts faster (e.g. if a filter is looking back N frames)

jpsdr

12th October 2016, 19:16

New version. Issue with prefetch is solved, and you can also use with this version the last version of my internaly resampler filters, and you can also use prefetch with all of these...!

real.finder

14th October 2016, 13:53

Install the Intel Redistribuable as said in the ReadMe here (https://software.intel.com/sites/default/files/managed/05/a4/ww_icl_redist_msi_2016.4.246.zip).

It's working fine, nice, my threadpool is finaly good... ;)

test it with both NNEDI3 and ResampleMT Release_Intel_XP_Core2_SSE4.2 in winxp in VirtualBox and not work

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

and before that I test in windows server 2008 r2 and not work too, the NNEDI3_v0_9_4_24 (Release_Intel_XP_Core2_SSE4.2) work fine

for ResampleMT I currently use Release_XP and work fine

jpsdr

15th October 2016, 09:57

Do you have up to date redistribuables installed ? 14.0.24215 for VS2015 and 2016.4.246 for Intel version ?

real.finder

15th October 2016, 12:12

Do you have up to date redistribuables installed ? 14.0.24215 for VS2015 and 2016.4.246 for Intel version ?

yes, I have them

jpsdr

15th October 2016, 14:32

No idea for now... :(

jpsdr

16th October 2016, 14:40

New version, see first post.

jpsdr

5th December 2016, 14:18

New version, see first post.

real.finder

5th December 2016, 16:45

Install the Intel Redistribuable as said in the ReadMe here (https://software.intel.com/sites/default/files/managed/05/a4/ww_icl_redist_msi_2016.4.246.zip).

It's working fine, nice, my threadpool is finaly good... ;)

I do it without it :rolleyes:

http://www.mediafire.com/file/3d536zh43m193po/icl.rar

work fine now in xp and windows server 2008 r2 ;)

jpsdr

6th December 2016, 11:09

work fine now in xp and windows server 2008 r2 ;)
Good to know.
The only thing i can see wich may has solved the issue is building with /MD instead of /MT...

real.finder

7th December 2016, 00:40

Good to know.
The only thing i can see wich may has solved the issue is building with /MD instead of /MT...
I did some changed now in the icl.rar

maybe, but I think intel dropped xp

in the first time I use libiomp5md.dll from Update 1 with svml_dispmd.dll from Update 4, but I feel there is something wrong with this mix, so I change 32 folder content now to xp and no xp

Groucho2004

7th December 2016, 01:21

I did some changed now in the icl.rar

maybe, but I think intel dropped xp

in the first time I use libiomp5md.dll from Update 1 with svml_dispmd.dll from Update 4, but I feel there is something wrong with this mix, so I change 32 folder content now to xp and no xp
It's a bit of a mystery that jpsdr creates binaries that need the MS and/or Intel support libraries but neither provides download links nor re-distributes them.

jpsdr

7th December 2016, 10:44

but neither provides download links nor re-distributes them.
I know by experience that links may change and/or disapear, making the link provided useless. Also binaries can evolved, for VS2015, we are now at leat at the second or third version of redistribuable only for the Update 3.
So, i rather put a comment on the readme saying to the people to get the redistribuable, this way they get the last up to date, and there is no "not working" link provided.

Groucho2004

7th December 2016, 11:01

I know by experience that links may change and/or disapear, making the link provided useless. Also binaries can evolved, for VS2015, we are now at leat at the second or third version of redistribuable only for the Update 3.
So, i rather put a comment on the readme saying to the people to get the redistribuable, this way they get the last up to date, and there is no "not working" link provided.
Fair enough. It's up to you.
By the way, the DLL from Release_Intel_XP_Core2_SSE4.2" does not work on XP. I installed the latest Intel redist package but Dependency Walker reveals that LIBIOMP5MD.DLL is looking for a function in kernel32.dll that does not exist on XP.

jpsdr

7th December 2016, 13:21

This seems to confirm what real.finder said.
Several possibility :
- Intel Droped XP support with last Intel redist release (strange, because in the IDE of ICL you can still choose "v140_xp").
- Intel messed up the last Intel redist release.
- There still XP support, but there is another "hidden" compiler (or linker) command to add in the build, as there is in VS2015 to still have an XP compatible build.
For now, i must said that i don't know. The workaround is to use the MS version under XP.

real.finder

7th December 2016, 23:34

By the way, the DLL from Release_Intel_XP_Core2_SSE4.2" does not work on XP. I installed the latest Intel redist package but Dependency Walker reveals that LIBIOMP5MD.DLL is looking for a function in kernel32.dll that does not exist on XP.

it's work here if you use this trick http://www.mediafire.com/file/5rp8jtv78otxxku/icl+-+xp.rar

tested in winxp sp3 32bit in VirtualBox

the last Intel redist package is the problem, use this https://software.intel.com/sites/default/files/managed/b4/98/ww_icl_redist_msi_2016.1.146.zip

FranceBB

8th December 2016, 01:03

Thanks for the "trick".
With that, it works just fine.
Tested a few minutes ago with:

nnedi3_resize16(target_width=1280, target_height=720, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, kernel_d="Spline", kernel_u="Spline", taps=12, f_d=1.0, f_u=2.0, sharp=0)

to downscale from 1080p to 720p.
Thanks for the update! ;)

jpsdr

19th December 2016, 14:34

I found something odd in the nnedi3 code, and i think there is an error :

for (int y=0; y<ydia; ++y)
{
const uint8_t *srcpT = srcp+y_stride;

for (int x=0; x<xdia; ++x, ++input)
{
sum += srcpT[x];
sumsq += srcpT[x]*srcpT[x];
input[0] = srcpT[x];
}
y_stride+=stride2;
}
const float scale = 1.0f/(float)(xdia*ydia);
mstd[0] = sum*scale;
mstd[1] = sumsq*scale-mstd[0]*mstd[0];

If think we should have this instead :

mstd[1] = sumsq*scale*scale-mstd[0]*mstd[0];

Anyone is welcomed to comment.

feisty2

19th December 2016, 15:12

well, you could have a try and see if it still works..
only tritical will ever know the exact answer

jpsdr

19th December 2016, 19:43

It's too bad he's not on doom9 anymore... :(

ajp_anton

19th December 2016, 22:30

Not knowing exactly what that part is for, but yeah, it sure looks odd.

Breaking it down, if
- sum is just the sum of srcpT's, whatever those are.
- sumsq is the sum of the squared srcpT's.
- "sqsum" is the square of the sum (introducing my own variable).
then
- mstd[1] = (sumsq - sqsum*scale)*scale
which looks weirdly unbalanced. Either
- mstd[1] = (sumsq - sqsum)*scale
or
- mstd[1] = (sumsq - sqsum)*scale*scale
would look better. I guess it's the latter (same as your suggested edit) because mstd[0] already has one scale, so squaring that has two.

Edit:
Then again, squaring scale is also weird, becase it's basically (the number of elements in the sum)^-1, so it's a normalization factor. Maybe it's supposed to be (sumsq - sqsum)*scale ?
Like feisty said, try and see the results.

Wilbert

20th December 2016, 00:33

There's definitely something wrong, but you should look at entire source to figure out how to correct it.

Sadly any documentation in the source is missing. Here is my take. Disclaimer i understand nothing of the source.

Most of the fun seems to be happing in the function evalFunc_2 in nnedi3.cpp. The code:

void evalFunc_2(void *ps)
{
...
const int qual = pss->qual;
const float scale = 1.0f/(float)qual;
void (*extract)(const uint8_t*,const int,const int,const int,float*,float*);
void (*wae5)(const float*,const int,float*);

if (opt==1) wae5=weightedAvgElliottMul5_m16_C;
else wae5=weightedAvgElliottMul5_m16_SSE2;
...
if (fapprox&2) // use int16 dot products
{
if (opt==1) extract=extract_m8_i16_C;
else extract=extract_m8_i16_SSE2;
...
}
else // use float dot products
{
if (opt==1) extract=extract_m8_C;
else extract=extract_m8_SSE2;
...
}
...
extract(srcpp+x,src_pitch,xdia,ydia,mstd,input);
...
wae5(temp,nns,mstd);
...
if (opt>1) castScale_SSE(mstd,&scale,dstp+x);
else dstp[x]=min(max((int)(mstd[3]*scale+0.5f),0),255);
...
}

Looking at the last line, it implies that mstd[3] and the destination pixels differ a factor scale (since dstp[x]=mstd[3]*scale, removing the rounding).
castScale_SSE is defined nnedi3_asm.asm, but i don't know how to read asm.

The function weightedAvgElliottMul5_m16_C which is called in evalFunc_2 (and is set to wae5) gives another clue:

void weightedAvgElliottMul5_m16_C(const float *w,const int n,float *mstd)
{
...
if (wsum>min_weight_sum[0]) mstd[3]+=((5.0f*vsum)/wsum)*mstd[1]+mstd[0];
else mstd[3]+=mstd[0];
}

This implies that mstd[3], mstd[1] and mst[0] should be of the same scale.

Later on in the code, extract_m8_i16_C/extract_m8_i16_SSE2/extract_m8_C/extract_m8_SSE2, is set to extract. The function extract is called as

extract(srcpp+x,src_pitch,xdia,ydia,mstd,input);

Here mstd is defined. jspdr pasted some code of the function extract_m8_C, but the issue is there in all of these four functions. In extract_m8_C we see

void extract_m8_C(const uint8_t *srcp,const int stride,const int xdia,const int ydia,float *mstd,float *input)
{
...
const float scale = 1.0f/(float)(xdia*ydia);

mstd[0] = sum*scale;
mstd[1] = sumsq*scale-mstd[0]*mstd[0];
mstd[3] = 0.0f;
if (mstd[1]<=FLT_EPSILON) mstd[1]=mstd[2]=0.0f;
else
{
mstd[1]=sqrtf(mstd[1]);
mstd[2]=1.0f/mstd[1];
}
...
}

mstd[0] and sum (the source pixels) differ a factor scale which is consistent with the above. That is, if the value of scale in extract_m8_C is the same as scale in evalFunc_2. I have no idea if that's the case.
If we change 'mstd[1] = sumsq*scale-mstd[0]*mstd[0];' to 'mstd[1] = sumsq*scale*scale-mstd[0]*mstd[0];', it implies that mstd[1] and mstd[0] differ a factor scale, but mstd[1] is overwritten by its square root later on, so 'mstd[1]=sqrtf(mstd[1]);'. So now mstd[1] and mstd[0] have the same scale which is consistent with the above.
So you need to change that in all four functions.

What i don't understand what mstd[2] is supposed to do. It has scale^(-1) compared to mstd[1]. I don't see where mstd[2] is used, and thus if its scaling is correct.

Wilbert

20th December 2016, 00:45

mmm scale in evalFunc_2 is set to '1.0f/(float)qual;' with qual being an input parameter (being 1 or 2). While scale in extract_m8_C is equal to '1.0f/(float)(xdia*ydia);'.

qual doesn't seem equal to xdia*ydia to me?? xdia and ydia are set by

pssInfo[i].xdia = xdiaTable[nsize];
pssInfo[i].ydia = ydiaTable[nsize];

and these tables by (see header file):

const int xdiaTable[NUM_NSIZE] = {8,16,32,48,8,16,32};
const int ydiaTable[NUM_NSIZE] = {6,6,6,6,4,4,4};

jpsdr

20th December 2016, 10:09

Wilbert

20th December 2016, 12:43

Finaly, after viewing things in statistic way, it's good. mstd : probably Mean STandard Deviation.
mstd[0] is mean, mstd[1] is mean standard deviation, which is the square root of : mean of the sum of the squares, less the square of the mean.
Yes indeed.

Your post is a bit cryptic. I think you are right that it should be

mstd[1] = sumsq*scale*scale-mstd[0]*mstd[0];

But i also think that the scale variables in evalFunc_2 and in the extract functions should be the same. I don't understand why they are different.

jpsdr

20th December 2016, 14:42

Again error from my side, the mean standard deviations is not what i've said after checking (my memory was not exactly right). We are not far, but it's not exactly what is calculated here.
But, what is done here is the mean of the squares less the square of the mean, and viewing like this, it can somehow make sense. So, maybe the formula is correct.

Wilbert

20th December 2016, 17:27

I give up. Leave the bugs in.
But, what is done here is the mean of the squares less the square of the mean
This is called the variance, and if you take the square of it you will get the standard deviation. Thus

VAR[X] = E[(X-E[X])^2] = E[x^2]-E[X^2], SD[X] = sqrt(VAR[X])

feisty2

20th December 2016, 17:51

I give up. Leave the bugs in.

This is called the variance, and if you take the square of it you will get the standard deviation. Thus

VAR[X] = E[(X-E[X])^2] = E[x^2]-E[X^2], SD[X] = sqrt(VAR[X])

should be E(x^2) - E(x)^2

EDIT: Var(x) = E((x-E(x))^2) = E(x^2 - 2xE(x) + E(x)^2) = E(x^2) - 2E(x)E(x) + E(x)^2 = E(x^2) - E(x)^2

jpsdr

20th December 2016, 19:37

Wilbert

20th December 2016, 22:45

So, finaly there is probably no bug, sumsq*scale-mstd[0]*mstd[0] produce the variance.
E(x^2)=sumsq*scale
E(x)^2=mstd[0]*mstd[0]
No...?

Still not been able to get 16bits working, and i can't figure out where it's going wrong.... :angry:
E(x^2)=sumsq*scale^2 as i see it, but i guess i can't convince anyone.

Anyway. This scale factor is 1 by default (= qual input parameter). Could you make some screenshots voor qual=1 and qual=2 and compare them?

StainlessS

20th December 2016, 23:59

Could you make some screenshots voor qual=1 and qual=2 and compare them?

This is an English only forum, please don't post in foreign language here, I don't want to have to draw an administrators attention to this. Thank you for your compliance. :)

Merry Xmas Wilbert et al. :) [Latin dont count as a foreign language as only dead Romans speak it + a few Swiss Romansch nearly Roman speakers [bout 10,000 I believe]]

jpsdr

21st December 2016, 18:22

After a bloody and painfull struggle, i've been able to make the 16bits working.
Can someone explain to me why this is working :

const uint8_t *srcp = pss->srcp[b];
const uint8_t *srcpp = srcp-(ydia-1)*src_pitch-xdiad2m1;

and why this is not (at least with VS2015 community) :

const uint8_t *srcp = pss->srcp[b];
const uint8_t *srcpp = srcp-((ydia-1)*src_pitch-xdiad2m1);

???????????

Thanks again again to feisty2 for the code, it was very usefull, especialy for the init part and weight calcul adjustment.
And future thanks also for the part i'll begin to work in : the ASM ! The code will be helpfull.

Groucho2004

21st December 2016, 18:44

Can someone explain to me why this is working :

const uint8_t *srcp = pss->srcp;
const uint8_t *srcpp = srcp-(ydia-1)*src_pitch-xdiad2m1;

and why this is not (at least with VS2015 community) :

const uint8_t *srcp = pss->srcp[b];
const uint8_t *srcpp = srcp-[B]((ydia-1)*src_pitch-xdiad2m1);

???????????
Because the additional braces in the second statement change the precedence in which the variables are evaluated.

jpsdr

21st December 2016, 19:34

Argh... Back home too late to delete my stupid question after i've realised it... :(

pinterf

21st December 2016, 19:42

Great news, I suppose the hard thing was having uint16_t instead of a byte, does it automatically work for e.g. 10 bit videos? (Ideally all filters that work for 16 bits should also support 10, 12 and 14 bit videos)

jpsdr

21st December 2016, 20:02

Yes, thanks to code of the vapoursynth part done with trictical apparently, the hardest part (adjust the value of the weight coefficients) was allready done, and the values are adjusted according bit depth (and the float part is also done for the weight coefficients). The code automaticaly works with 10,12,14 and 16, with the fiew tests i've made.

My most struggle was with my stupid mistake from my previous post, i was stuck and i've been loosing hairs for several days because of it... Big step for me, but still work in progress. Once the pure C part will be done and fully tested, the next chalange: the ASM.
But again, i've help from the vapoursynth code.

pinterf

21st December 2016, 20:09

Once the pure C part will be done and fully tested, the next chalange: the ASM.
But again, i've help from the vapoursynth code.
Yes, it became more and more sophisticated over time in VS, I've seen there nice FMA3 parts, I'm not saying that those lines are just a relaxing afternoon read :)

real.finder

27th December 2016, 11:38

hi jpsdr

YUY2 is broken in x64 http://forum.doom9.org/showpost.php?p=1791047&postcount=17

feisty2

27th December 2016, 12:34

yuy2 is bullshit, convert whatever you got to yv16.

jackoneill

27th December 2016, 20:15

jpsdr

28th December 2016, 09:51

@real.finder Thanks for report, i'll look into it after i've finished my actual work.
@jackoneill According the vapoursynth code (if i've understood properly), the same asm prescreener functions are used for both 8 and 16 (or values between) bits. But, my tests until now (if i've not made errors) show me they are not working for more than 8 bits. Are you sure they should realy work ?

Edit : Finaly, i took a quick look out of curiosity, because something working in x86 but not in x64, make 100% sure it's in the asm code. Finaly i've quickly fond something. If i've not seen it, it's because i've only tested nnedi3_rpow2 for now, and within it, YUY2 is splitted in planar mode, so nnedi3 was never directly called with YUY2 format in my tests.

jackoneill

28th December 2016, 16:33

@jackoneill According the vapoursynth code (if i've understood properly), the same asm prescreener functions are used for both 8 and 16 (or values between) bits. But, my tests until now (if i've not made errors) show me they are not working for more than 8 bits. Are you sure they should realy work ?

There are three prescreener functions:
1) computeNetwork0 - "old" prescreener (pscrn=1), float dot products. This one you can use for all bit depths, including 32 bit float, after you adjust the prescreener weights. It is slow.

2) computeNetwork0_i16 - "old" prescreener (pscrn=1), int16 dot products. This one uses pmaddwd, which means that it can be used as is only for 8..15 bit pixels. (You still need to adjust the prescreener weights.) It's supposed to be faster than the float version, but who knows.

3) computerNetwork0new - "new" prescreener (pscrn=2..4), int16 dot products. It has no float version. This one also uses pmaddwd, so it also can be used as is only for 8..15 bit pixels. This one makes nnedi3 considerably faster, because more pixels end up processed with the fast bicubic method.

If you want to process 16 bit pixels with the faster prescreener, you could cheat and shift the pixels by one bit.

jpsdr

29th December 2016, 09:48

jackoneill

30th December 2016, 22:27

For now, only the C version of computeNetwork0_i16 and computerNetwork0new produce correct result, the ASM version produce incorrect results with bits>8. I'll have to continue testing/investigating, but actualy, that's the result i have.

Remember that the weights need to be arranged differently for the ASM functions. You can't just use opt=1 (C functions only) and plug in one ASM function for testing, or vice versa.

jpsdr

31st December 2016, 17:49

Yes i know, and i have to be sure of everything, that's why for now i'm still under testing/checking.
Float is i think working properly, i'm still working on the 9..16 bits part.

jpsdr

7th January 2017, 15:37

A little late, but here is a Christmass present with a big step features new version (see 1rst post).
(My CPU hasn't FMA4, so the FMA4 functions are not tested).

real.finder

7th January 2017, 20:51

A little late, but here is a Christmass present with a big step features new version (see 1rst post).
(My CPU hasn't FMA4, so the FMA4 functions are not tested).

thanks, and about 10-14 bit?

jpsdr

8th January 2017, 10:25

It seems that i should have been more specific that with 16bits i mean everything <=16 bits.
I'll change the post.

jpsdr

17th January 2017, 22:24

Add new version, check first post.

edcrfv94

18th January 2017, 03:27

If add mclip parameter like eedi3 can speed up anti-aliasing script with pscrn = 0 so much.

FranceBB

18th January 2017, 05:55

Thanks for the update, once again! :)

jpsdr

18th January 2017, 19:52

Ouupss !!!! The last version crash on x64 (except with opt=1), no issue with x86. I'll fix it soon.

TheSkiller

18th January 2017, 20:18

I noticed on white (255, 255, 255) surfaces nnedi3_rpow2 produces this "jailbar" pattern.

BlankClip(pixel_type="RGB24", width=200, height=100, color=$FFFFFF)

nnedi3_rpow2(rfactor=2, cshift="Spline16Resize")

Levels(254,1,255, 0,255, false) #to make the pattern visible

https://picload.org/image/rodgddlg/nnedi3_jailbars.png

Should be a plain white surface.
Happens with all kinds of versions, even with the old nnedi2. Happens in YUV as well as RGB24.

I noticed it while enlarging an image that uses an alpha channel. The resulting enlarged image had quite visible jailbars in those parts where the alpha channel is white (opaque), so it can be seen in real world scenarios.

jpsdr

18th January 2017, 20:28

I'll try to see if i can figure something out, but not sure at all.

Edit :
I've figure out... You may probably not have the issue if you set prscrn=0.
When prescreener is used, 255 is used as a "special" value by the code, to "mark" pixel which should be processed by the neural network. If a pixel is not to be processed by the neural network, it's value will be a simple interpolation, but clamped at 254, to keep the 255 only for marked pixels.
But, on your whole blank clip, no pixel is neural network, so, every pixel will be interpoled and clamped at 254. As nnedi is a deinterlacer, and only half the lines are processed (or double), anyway, the untouched lines stays at 255, producing output at 254 and 255.
I'll see if something can be made to solve this, but it may take a little time, it will have a not small impact on the code, but shouldn't be too hard.

The x64 fix will be delayed until i fix this. Thanks to pointing this, strange that this wasn't realized before. I also should have been to realize it, having understood a little more the code core to add the 16bits/float datas.

real.finder

18th January 2017, 20:45

jpsdr

18th January 2017, 20:52

The only way to fix this will be to create a "boolean" memory plan of the same size of the plane processed, to mark pixels to be processed on this plane, instead of using the value 255, this will keep the value 255 usable in the prescreener. It will increase a little the memory used, but shouldn't affect the speed noticeably.

TheSkiller

18th January 2017, 20:57

Thank you for your fast reply. pscrn=0 does indeed fix it for now.
The explanation makes sense. It's a bit of a "hacky" way reserving 255 for the prescreener. :)

edcrfv94

22nd January 2017, 06:33

It will be useful if nnedi3 can show which pixels are processed by the neural network into a edge mask.
Also add mclip parameter to use neural network only on specified pixels can improve anti-aliasing script speed.

Thanks

jpsdr

22nd January 2017, 10:18

This is not in my todo list for now, and i've never done this kind of thing (having extra intput/output clip parameters). This may probably needs a specific (or another) nnedi3 function, because i don't know if you can put "no value" and switching to "default" value on this kind of parameters if you don't need/use them. I'll think about it, but not in the near future, and no promises.

jpsdr

22nd January 2017, 15:42

New version, both issues are fixed, check first post.

jpsdr

24th January 2017, 20:59

New version, see first post.

kuchikirukia

26th January 2017, 10:42

I'm getting "module not found" for the x86 W7 SSE4.1, AVX, and AVX2. Win10 with Haswell.

E: fixed it. Did it need the Intel 2016 too? I forget if I restarted MeGUI after installing 2017. I did after erroring out and trying 2016 too.

jpsdr

26th January 2017, 15:01

No, the 2017 is enough (at least, it's the case for me).

jpsdr

5th March 2017, 15:40

New version see first post.
Some quick speed tests showed these results (at least on my CPU) :
Speed improvement from opt=2 to opt=4 on nnedi3 8bits data, not nnedi3_rpow (this last having several others image manipulation which will alter the test speed) :
prscrn=1, fapprox=12 : around +25%
prscrn=1, fapprox=15 : around +10%
prscrn=2, fapprox=15 : around +40%

pinterf

10th March 2017, 17:34

Nice speedup. You mentioned AVX512 in the vdub thread, are you interested on a 64 byte aligned build from avs+?

jpsdr

11th March 2017, 08:32

Not for now, i haven't anything yet to use it. I was just saying that it could be interesting to just have a 64bits default alignment, this will ensure a long future, and don't have to worry about it for a looong time... ;)

burfadel

11th March 2017, 13:26

No desktop processors support hose instructions yet. When they do, Intel have dividied them up into different sets and desktop variants may not necessarily get those sets most beneficial for encoding etc.

jpsdr

23rd March 2017, 09:29

New version, see first post.

jpsdr

2nd April 2017, 10:08

New version, see first post (nothing big this time).

burfadel

9th April 2017, 16:10

I just upgraded to a Ryzen 1700x. Everything is working brilliantly apart from NNEDI3 x64! The latest version makes an instant crash, and this is with the latest redists installed. I even tried the intel redists for the AVX builds etc, no luck, all compiled files causes an instant crash. I went back through the versions and found that Version v0.9.4.36 is the last one that worked correctly. With this version, the Intel AVX2 etc versions all work fine.

So somewhere in the code change between 0.9.4.36 (works) and 0.9.4.37 (doesn't work) there is an issue that causes it to crash.

ryrynz

10th April 2017, 07:32

I have no crash here. Ryzen 1700 using nnedi3_rpow2 through ffdshow with x64 .38 Core 2 AVX2 build.
I have the Intel 64 c++ redistributables 16.9.246 installed.

jpsdr

10th April 2017, 08:59

Oh yes !!! A LOT of things changed between .36 and .37, all the AVX2/YMM use code has been added. What command exactly are you using within your script ? Are the not Intel version also crash ?

burfadel

10th April 2017, 09:59

Oh yes !!! A LOT of things changed between .36 and .37, all the AVX2/YMM use code has been added. What command exactly are you using within your script ? Are the not Intel version also crash ?

Regardless of the command line, even just nnedi3(). However, opt=3 works fine, but would rather no disalbe those AVX2 speedups.

ryrynz

10th April 2017, 11:45

Well that's an issue with your system by the sounds as I'm using the same build, are you using the latest BIOS for your board? Could be a Ryzen bug.

jpsdr

10th April 2017, 11:55

What is your color input format ? I've made a lot of tests, but it's not impossible that i've missed something.
Are opt=5 or opt=6 also crash ?

Btw, Ryzen users, if you could benchmark nnedi3 (not rpow) between opt=4,5 and 6, i'm curious.

ryrynz

10th April 2017, 12:47

I did a quick test earlier tonight between auto (4?), 5 & 6 and there was sweet F all difference. Honestly I couldn't pick a winner by CPU frequency or CPU utilization.
Would need to do a proper AVS bench to know which is faster but the differences are so small I don't care to waste my time to know, this is in real time so perhaps a far more demanding script with this would highlight what's best for Ryzen.

burfadel

10th April 2017, 15:58

I don't know how FMA4 could work on Ryzen, but opt=5 works for me as well. So ryrynz, the nnedi3 being used is definitely 0.9.4.39? I tested a whole heap of other AVX2 stuff, no issues (including a whole day of parallel encodes of x265), only AVX2 in 0.9.4.37 onwards doesn't work for me.

ryrynz

11th April 2017, 08:25

Definitely, I just updated from .38. Double checked by moving the file too. Does it work for you through ffdshow raw by any chance?
I'm using Avisnth+ build 2455.

jpsdr

11th April 2017, 09:54

@burfadel : Do you mean that AVX2 crash in .37 but not in .39 ?
I don't know which CPU uses FMA4. As it seems it's not Intel, i thought it would be AMD, so maybe the Ryzen.

ryrynz

11th April 2017, 10:13

Ryzen apparently doesn't have FM4 implemented, which makes why that optimization works somewhat of a mystery.

pinterf

11th April 2017, 10:23

Perhaps this one? Ryzen FMA3 bug.
http://techreport.com/news/31621/amd-readies-a-fix-for-ryzen-fma3-bug

Groucho2004

11th April 2017, 10:26

I don't know which CPU uses FMA4. As it seems it's not Intel, i thought it would be AMD, so maybe the Ryzen.
Ryzen does not support FMA4. Bulldozer and Piledriver do.

burfadel

11th April 2017, 12:18

In which case manually specifying FMA4 it shouldn't work. I guess it automatically disabled it anyway? For the crashing, it's only AVX2 that causes it, and only versions .37 and above. This is for any of the builds provided, and any of the colourspaces, using Avisynth+ 2455 x64 version (and NNEDI x64 of course). It also crashes when placing the .avs file through MPC, but fine on .36. The AVS file just contains the source filter (using DSS2mod), and NNEDI3.

I just did a little test, I downloaded MPC-HC 32-bit, copied the relevant 32-bit avisynth files to the respective locations, and changed the script to point to the 32-bit source and NNEDI files, and it worked! The video played perfectly and could seek etc, unlike with any usage of the x64 version that crashes instanstly without displaying a picture using any method.
NNEDI3 0.9.4.39 x64 version doesn't work with AVX2
NNEDI3 0.9.4.39 x86 version works with AVX2

@ryrynz are you using 32-bit (that works for me) or 64-bit?

ryrynz

11th April 2017, 12:24

Full 64 bit chain, MPC, ffdshow, Avisynth and NNEDI3.

Groucho2004

11th April 2017, 13:49

jpsdr

11th April 2017, 14:18

@burfadel : Does the FMA3 (opt=5) work with x64 ? This may help me to locate were the issue could be. x86 working and x64 not, very very likely an issue in the asm files. If FMA3 works, it means the issue is somewhere in a function which have duplicate AVX/FMA. If FMA3 doesn't work, it means the issue is in a function both used in FMA/AVX. There is probably an issue in the asm code, i don't trig, neither ryrynz. It happened allready a while ago, someone had an issue, and it was trigged only in specific situation. The more likeky a pointer register i've missed to pass in 64bits version.

Groucho2004

11th April 2017, 14:18

One thing I find puzzling about the documentation:

opt -

Sets which cpu optimizations to use. Possible settings:

0 = auto detect
1 = use c
2 = use sse2
3 = use sse4.1
4 = use AVX2
5 = use FMA3 [Manual set only, not in auto-detect]
6 = use FMA4 [Manual set only, not in auto-detect]

The available builds are:
Release_Intel_W7_Core2_AVX
Release_Intel_W7_Core2_AVX2
Release_Intel_W7_Core2_AVX2_Broadwell
Release_Intel_W7_Core2_SSE4.2
Release_Intel_W7_Xeon_AVX512
Release_Intel_XP_Core2_SSE4.2
Release_W7
Release_XP

I can't figure out which build does what when using any of the "opt" parameters. For example, what build supports SSE4.1? Maybe I'm just missing something obvious...

jpsdr

11th April 2017, 14:22

Groucho2004

11th April 2017, 14:32

All the builds do the same thing with "opt". It's just the compiler option which are differents. The Core2_AVX is build with "AVX instruction" on the compiler, Core2_AVX2_Broadwell is build with "AVX2 Instructions" + "Broadwell micro code" in the compiler, etc...OK, but what's the point of all these builds if they don't bring any speed benefit? Or, in case of the AVX test above, are even slower?

jpsdr

11th April 2017, 15:45

Theoricaly, i thought they should have an effect. Strange thing is the fact that there is 4 more threads on the Intel version. Well...

burfadel

11th April 2017, 16:33

jpsdr

11th April 2017, 17:56

Sorry, last question, to help me to locate the issue.
Can you tell me if it happens with :
8bits, 10bits, 14bits, 16bits and 32bits (float) ?
A script like this will do the trick (YV12 data will be good):

ConvertBits(x)
nnedi3()
ConvertBits(8) # If needed for your output.

with x=10,14,16,32 assuming your input is 8bits.

EDIT
Never mind, i've just made a search on "eax" (and similar) on the x64 asm file, and find something which may explain the crash issue. Can you pm me an email i can send you a build test ?

jpsdr

11th April 2017, 18:38

x86 working, x64 crashing => 99.999% chance it's in the asm code.
It's working for me and a lot of people, and suddenly someone has a crash => 99.999% chance i've missed an address register and kept it on its 32bits version instead of changing it to its 64bits version (keeping a mov xxx,[esi] instead of changing to mov xxx,[rsi] for exemple).
And of course, it's what i've found out, searching for occurance of 32bits registers in the x64 asm code.
I should have thought doing this kind of search before...
Note for myself : Always doing this on x64 asm code for now... ;)

jackoneill

12th April 2017, 21:30

burfadel

12th April 2017, 23:12

A test version sent to me works perfectly! The issue jpsdr found in the code is what was causing the issue, it's interesting how it affects some people and not others with seemingly similarish systems.

jpsdr

13th April 2017, 08:55

Or you could just use one of the solutions that allow you to write and maintain only one copy of this code...

I know that's an option, i don't say it's bad, but for now i'm not interested in.

If possible (and it's the case here) i want my project to need only Visual Studio to build, without needed to install third party things.
After, the x64 code can differ because of the extra registers (and sometimes maybe differ greatly). Maybe there is possibilty to have something similar to a #define and have different build path, but for now, i rather stay like this. I'm not realy in the mood to learn (even if very similar) another asm syntax.

BTW, not related, but does anyone have any idea why the FMA3 is realy slower than AVX2 "only" on Intel ?
I expected something like this :

vmovaps ymm4,YMMWORD ptr [rcx+64]

vfmadd231ps ymm0,ymm4,YMMWORD ptr [rdx+256]
vfmadd231ps ymm1,ymm4,YMMWORD ptr [rdx+288]
vfmadd231ps ymm2,ymm4,YMMWORD ptr [rdx+320]
vfmadd231ps ymm3,ymm4,YMMWORD ptr [rdx+352]

would be faster than :

vmovaps ymm7,YMMWORD ptr [rcx+64]
vmulps ymm4,ymm7,YMMWORD ptr [rdx+256]
vmulps ymm5,ymm7,YMMWORD ptr [rdx+288]
vmulps ymm6,ymm7,YMMWORD ptr [rdx+320]
vmulps ymm7,ymm7,YMMWORD ptr [rdx+352]
vaddps ymm0,ymm0,ymm4
vaddps ymm1,ymm1,ymm5
vaddps ymm2,ymm2,ymm6
vaddps ymm3,ymm3,ymm7

because less instructions (basicaly, it's the code difference between all AVX2/FMA3 functions), but FM3 is almost twice slower than AVX2...:confused:

pinterf

13th April 2017, 10:01

FMA3 works with higher internal precision, but I don't think it is the real reason.
Less instructions does not mean less cycles.

You have to check the features of the specific architecture, which internal ports can be used parallel.
Manually optimized code (and the well compiled instrisics) leave the strict order of the simd commands, e.g. interleave the mutually parallelizable instructions.
load, load, load, mul, mul, add, add can be reordered as load mul load add mul add, if necessary (just an example)

For the same reason, AVX/AVX2 256 bit instructions are not necessarily faster than processing with two 128 bits chunks.
For example my Ivy Bridge is not full 256 bit internally, working with 2x128 bit XMM registers parallel (two internal ports) is sometimes faster that processing data on a single 256 bits.
My architecture can load 2x128 bit XMM registers parallel but 256 bit load has penalty (queued on the same port).

When you compiler cpp code and specify the architecture (not the instruction set), a good compiler can take the internal differences into account at optimizations.

jpsdr

17th April 2017, 10:53

New version with x64 crash fix, see first post.

jpsdr

10th May 2017, 12:39

New version, see first post.

FranceBB

10th May 2017, 23:50

Tested the new version: XP SP3 x86 SSE4.2; works flawlessly.

Tested both: nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=1280,fheight=720,nsize=0,nns=3,qual=2,opt=1)
and: nnedi3_resize16(target_width=1280, target_height=720, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, kernel_d="Spline", kernel_u="Spline", taps=12, f_d=1.0, f_u=2.0, sharp=0)

Spline with 12 taps is my favorite upscale for old sources. :)

jpsdr

11th May 2017, 09:39

opt=1...? Is there any reason to choose the slowest "only C" version vs the optimised ones ?

FranceBB

18th May 2017, 01:41

Nope, but I did the very first test in a VM and I didn't want to mess with istructions ('cause I didn't know which ones were emulated by the virtual machine). When I did the second test in my real XP machine, I just copied and pasted the first code (including opt=1) 'cause I forgot about disabling optimisations.
As to the second code (nnedi_resize16) that's what I generally use. I even have it saved in a folder in my desktop that contains that line xD

jpsdr

20th May 2017, 15:49

New version, see first post (minor update).

FranceBB

1st June 2017, 16:53

Tested in Windows XP SP3 x86.
Works flawlessly. Thanks! ^_^

jpsdr

3rd June 2017, 19:35

New version, see first post (minor update and small fix).

Dreamland

3rd June 2017, 21:38

crash in my system ( win 10 64 bit ) version AVX2 - 32 bit ( CPU I5 4690K)
NNEDI3 0.9.4.42 AVX2 works very well

thx a lot for your hard work!

jpsdr

4th June 2017, 08:11

Do the others 32 bits versions crash (the AVX or the standard Release_W7) ? If not, i would in that case advise to switch to another version, because unfortunately in that case i don't know what to do. The differences are minimal, because the critical code is in ASM, so it will not have a critical impact.

jpsdr

4th June 2017, 08:23

I ran some performance tests with the various builds on Win7 with AVSMeter64 on my i5 2500K @ 4GHz (no AVX2 since the CPU doesn't support it):
....
The efficiency (FPS/CPU usage) of jpsdr's builds is quite good but the multi-threading could be better.
:thanks: ;)
But i've runned some tests also, and noticed that CPU has critical effect, so you have to tune according your CPU to reach optimal result.
At work, i have a "standard" CPU, 4 cores, without hyper-threading.
On my version, with standard settings, i have around 90% CPU, with a 100% CPU around... 90% of the time. :D
On my personnal PC, a 10 cores broadwell (giving me 20 logical cores) the same test gives me a 35% - 40% CPU.
To achieve on my PC 93% CPU, i have to use the followig :

ColorBars(width=1920*2,height=1080*2,pixel_type=yv12).killaudio().assumefps(25,1).trim(0,999)
nnedi3(...,threads=10,prefetch=4)
Prefetch(4)

Which gave me, theoricaly, 40 threads.

This:

ColorBars(width=1920*2,height=1080*2,pixel_type=yv12).killaudio().assumefps(25,1).trim(0,999)
nnedi3(...,threads=20,prefetch=2)
Prefetch(2)

Gives me only 77% CPU.

My question is how exactly is your CPU ? How physical and logical cores have you ?

Groucho2004

4th June 2017, 08:53

My question is how exactly is your CPU ? How physical and logical cores have you ?i5-2500K @4GHz (Sandy Bridge), 4/4 cores.

Groucho2004

4th June 2017, 11:14

At work, i have a "standard" CPU, 4 cores, without hyper-threading.
On my version, with standard settings, i have around 90% CPU, with a 100% CPU around... 90% of the time. :D
On my personnal PC, a 10 cores broadwell (giving me 20 logical cores) the same test gives me a 35% - 40% CPU.
To achieve on my PC 93% CPU, i have to use the followig :

ColorBars(width=1920*2,height=1080*2,pixel_type=yv12).killaudio().assumefps(25,1).trim(0,999)
nnedi3(...,threads=10,prefetch=4)
Prefetch(4)

Which gave me, theoricaly, 40 threads.

This:

ColorBars(width=1920*2,height=1080*2,pixel_type=yv12).killaudio().assumefps(25,1).trim(0,999)
nnedi3(...,threads=20,prefetch=2)
Prefetch(2)

Gives me only 77% CPU.
I'm sure you know this - the CPU usage alone is quite meaningless. You have to look at the ratio of FPS/CPU usage to properly judge the results and to see if you are not just creating heat. AVSMeter has an INI setting "DisplayEfficiencyIndex" which is useful to compare the impact of different parameters on efficiency.

TheFluff

4th June 2017, 17:51

That's a better measure, but I think what you usually want to measure to find out how good the parallelism is, is simply how well it scales. Compare the single threaded implementation (or the multithreaded one set to one thread) to two, four or eight threads - assuming you have enough CPU cores. If it scales linearly (two threads = twice the fps), it's good. If it doesn't, it's bad and you should figure out why. Once you know you've managed to actually get the parallelism working, you can start comparing things like memory usage, extra CPU overhead, etc.

Groucho2004

4th June 2017, 18:17

That's a better measure, but I think what you usually want to measure to find out how good the parallelism is, is simply how well it scales.That's exactly what you get when you divide fps/cpu usage. If the quotient stays more or less the same with two or more threads, it scales well.

jpsdr

5th June 2017, 08:39

On my personnal PC, i'll test this evening when back home if i've time, but my guess is it will probly be linear only at the begining (like 1,2,3), to begin to being linear after... that will be the surprise... I'll made a little later some tests with the PC at work, using this DisplayEfficiencyIndex.

jpsdr

5th June 2017, 12:35

Ok, some tests on my PC at work.

Configuration :

[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1.0 (Build 7601)
CPU brand string: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
CPU features: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, FMA3, MOVBE, POPCNT, AES, F16C

[Avisynth info]
VersionString: AviSynth+ 0.1 (r2504, MT, x86_64)
VersionNumber: 2.60000
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes

It's a 4 cores, without hyper-threading.

First serie of tests :

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=1)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 7.257 | 7.562 | 7.499
Memory usage (phys | virt): 52 | 60 MiB
Thread count: 5
CPU usage (average): 25%
Efficiency index: 0.3000

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=2)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 13.32 | 14.20 | 14.02
Memory usage (phys | virt): 52 | 60 MiB
Thread count: 7
CPU usage (average): 47%
Efficiency index: 0.2982

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=3)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 18.18 | 19.99 | 19.82
Memory usage (phys | virt): 52 | 60 MiB
Thread count: 8
CPU usage (average): 67%
Efficiency index: 0.2958

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=0)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 20.86 | 23.04 | 22.84
Memory usage (phys | virt): 52 | 60 MiB
Thread count: 9
CPU usage (average): 79%
Efficiency index: 0.2892

Now, if i change the parameters used:

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(pscrn=1,dh=true,threads=1)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 3.343 | 3.500 | 3.482
Memory usage (phys | virt): 52 | 60 MiB
Thread count: 5
CPU usage (average): 25%
Efficiency index: 0.1393

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(pscrn=1,dh=true,threads=2)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 6.597 | 6.990 | 6.855
Memory usage (phys | virt): 52 | 60 MiB
Thread count: 7
CPU usage (average): 49%
Efficiency index: 0.1399

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(pscrn=1,dh=true,threads=0)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 12.04 | 13.17 | 13.10
Memory usage (phys | virt): 52 | 60 MiB
Thread count: 9
CPU usage (average): 98%
Efficiency index: 0.1337

Now, i'ill try to optimize the first test command :

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=2,prefetch=2)
Prefetch(2)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 12.22 | 311783 | 27.45
Memory usage (phys | virt): 197 | 230 MiB
Thread count: 11
CPU usage (average): 94%
Efficiency index: 0.2920

Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=1)
Prefetch(4)

Frames processed: 200 (0 - 199)
FPS (min | max | average): 4.429 | 623566 | 27.36
Memory usage (phys | virt): 342 | 399 MiB
Thread count: 9
CPU usage (average): 88%
Efficiency index: 0.3109

Finaly, it's a total mess...:p

On this CPU, if you're using nnedi3(dh = true, nsize = 0, nns = 4, qual = 2), the best result is with :

nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=2,prefetch=2)
Prefetch(2)

but if you're just using nnedi3(pscrn=1,dh=true), the best result is with :

nnedi3(pscrn=1,dh=true)

as default value for threads if 0.

I'll made some tests on my personnal PC when back home.

Groucho2004

5th June 2017, 13:07

Finaly, it's a total mess...:p
I think you're interpreting the "efficiency index" wrong. It's simply FPS/CPU usage. If the value stays the same with more threads your thread scheduler works well. It doesn't matter that much if you're not getting 100% CPU usage because the unused CPU cycles can be used by the encoder.

Your numbers show once again that mixing two multi-threading mechanisms results in less efficient processing which makes sense since the scheduling overhead is bigger.
Also, if you're comparing the efficiency, the only variable you should change is the number of threads, not other filter parameters.

jpsdr

6th June 2017, 08:51

Also, if you're comparing the efficiency, the only variable you should change is the number of threads, not other filter parameters.
In that case, how do you interpret the fact that :
nnedi3(pscrn=1,dh=true,threads=x) has a linear progression and a stable coeff efficiency with x from 1 to 4, and that nnedi3(dh=true,nsize=0,nns=4,qual=2,threads=x) doesn't have a linear progression, and the coeff efficiency is dropping ?
For me, it shows that the parameters themselves have an effect on the efficiency, and according the parameters you choose, you can produce different results with the same threads settings.

After the reasons of this difference, personnaly i have only light guess (like more internal computation vs more memory access resulting in bus access "colision" so less efficiency, or... gremlins...:D).

Groucho2004

6th June 2017, 09:11

After the reasons of this difference, personnaly i have only light guess (like more internal computation vs more memory access resulting in bus access "colision" so less efficiency, or... gremlins...:D).Something like that, I suppose. :)

Dreamland

8th June 2017, 19:49

Do the others 32 bits versions crash (the AVX or the standard Release_W7)
same issues, I return to v.0.9.4.42
thx anyway

jpsdr

9th June 2017, 09:44

Wait... Do you mean for you even the standard Release_W7 x86 crash ? In that case it's more troublesome. Does the x64 version also crash ?
Can you tell me exactly what you're doing, and provide the full script you're using, and the video information you're feeding it (something like for exemple 1280x720 in YV24), and what avisynth version you're using.

kuchikirukia

13th June 2017, 05:37

On this CPU, if you're using nnedi3(dh = true, nsize = 0, nns = 4, qual = 2), the best result is with :

nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=2,prefetch=2)
Prefetch(2)

No, that was just the fastest. The best was:
Colorbars(width=1920*2,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,199)
nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=1)
Prefetch(4)

99.6% of the speed for 6% less CPU util.
Somehow you managed to get more efficiency than single-threaded.

jpsdr

18th June 2017, 13:20

New version, minor change, see first post.

yup

8th July 2017, 09:42

HI all!
Please advise how organizing hi bit upscale?
Plug-in support only 8 bit.
yup.

FranceBB

8th July 2017, 17:49

HI all!
Please advise how organizing hi bit upscale?
Plug-in support only 8 bit.
yup.

Dither_convert_8_to_16()

nnedi3_resize16(target_width=1920, target_height=1080, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

16bit upscaling using NNEDI and Dither Tool. There you go ;)
(Tweak parameters according to your source ;))

jpsdr

11th July 2017, 07:56

HI all!
Plug-in support only 8 bit.
yup.
....? What do you mean by that ?
I've updated the pluggin, it now supports all formats (8,10,12,14,16 and 32 bits).

yup

11th July 2017, 10:25

....? What do you mean by that ?
I've updated the pluggin, it now supports all formats (8,10,12,14,16 and 32 bits).
Hi jpsdr!
I read doc included to archive. If now support hi bit depth it very nice.
:thanks: for support.
yup.

edcrfv94

29th July 2017, 16:56

AvsPmod 32bit/64bit open two tab, if F5(fefresh) 2.nnedi3 tab will no respond.

NNEDI3 v0.9.4.42 Release_W7 / JPSDR Avisynth's plugins pack 1.1.5 Release_W7: work fine

NNEDI3 v0.9.4.43/v0.9.4.44 Release_W7 / JPSDR Avisynth's plugins pack 1.1.6/1.1.7 Release_W7: no respond

1.

SetMemoryMax(1000)

colorbars(width = 1920, height = 1080, pixel_type = "yv12")

2.nnedi3

SetMemoryMax(1000)

colorbars(width = 1920, height = 1080, pixel_type = "yv12")

nnedi3(field=1)

jpsdr

30th July 2017, 09:37

edcrfv94

30th July 2017, 14:45

Don't have avspmod, and it's not running standalone, don't want to install python and all others stuff.

The big difference after 42 is that threadpool is created in "create" function instead of constructor instance. And the last destructor called if there is several instances of the filter will "destroy" the threadpool. If filter is re-used after that, there is no threadpool anymore, but it shouldn't be possible, because when the last destructor is called, it means that you've ended/closed/finished your script, so filter will not be re-used.
Is there a part where i'm wrong, or am i missing some unexpected use case situation ???

Does it also happen if you add threads=1 in the nnedi3 command line ?

threads=0: no respond
threads=1: work fine

IsCombedTIVTC/Runtime Functions same problem.

SetMemoryMax(1000)

colorbars(width = 1920, height = 1080, pixel_type = "yv12")
ConvertToY8()
src = last
bc = src .mt_lut("0", y=3, u=1, v=1)
wc = src .mt_lut("255", y=3, u=1, v=1)

bcwc = Interleave(bc, wc)

ScriptClip("AverageLuma(bcwc) > 128 ? bcwc.nnedi3(field=1, threads=0) : bcwc")

Also can you give some hint how to add mclip option?*my programming skills are not that good.

tcannyMod+prewitt much accurate than pscrn=4.

aa_in= last
em1 = aa_in.tcannyMod(sigma=1.50, t_h=8.0, t_l=1.0, sobel=true, mode=0)
\ .mt_expand_multi(mode="losange", sw=5, sh=5, u=1, v=1).mt_inpand_multi(mode="losange", sw=3, sh=3, u=1, v=1)
em2 = aa_in.mt_edge("prewitt", thY1=0, thY2=255).mt_inflate(u=1, v=1).mt_lut("x 4 - 3 *", u=1, v=1).mt_lut("x 8 - 3 *", u=1, v=1).tmaskcleaner(1)
\ .mt_inpand_multi(mode="losange", sw=1, sh=1, u=1, v=1).mt_expand_multi(mode="losange", sw=1, sh=1, u=1, v=1)
aamask = mt_logic(em1, em2, "max", y=3, u=1, v=1)

jpsdr

31st July 2017, 08:42

edcrfv94

31st July 2017, 16:34

Unfortunately, i think adding mclip option will not be so easy (if your option is what i think), even more difficult if the clip added is not aligned properly for functions that require aligned data (which is not an issue with internal data for it because i create the alignment i need).
Have you tried others prescreeners value ?

I don't understand what trig your issue, maybe Avspmod has a different behavior than other software (something i didn't think of). When i do a next release, i'll put back the threadpool creation in the constructor instead of the create function... :( It'll a little less efficient, but if it solves the issue.

Run AVSMeter/Encoding:no respond
*NNEDI3 v0.9.4.43/v0.9.4.44 Release_W7 / JPSDR Avisynth's plugins pack 1.1.6/1.1.7 Release_W7

Also NNEDI3 v0.9.4.42 Release_W7 / JPSDR Avisynth's plugins pack 1.1.5 Release_W7 Run AVSMeter: after 4000 frame from 300 fps drop to 50 fps.

SetMemoryMax(1000)

colorbars(width = 1920, height = 1080, pixel_type = "yv12")
ConvertToY8()
src = last
bc = src.mt_lut("0", y=3, u=1, v=1)
wc = src.mt_lut("255", y=3, u=1, v=1)

bcwc = Interleave(bc, wc)

ScriptClip("AverageLuma(bcwc) > 128 ? bcwc.nnedi3(field=1, threads=0) : bcwc")

tcannyMod+prewitt much accurate than pscrn 1-4.
pscrn = 0 with mclip option at least additional 2.0× speedup, depend the edge mask.

aa_in= last

em1 = aa_in.tcannyMod(sigma=1.50, t_h=8.0, t_l=1.0, sobel=true, mode=0)
\ .mt_expand_multi(mode="losange", sw=5, sh=5, u=1, v=1).mt_inpand_multi(mode="losange", sw=3, sh=3, u=1, v=1)
em2 = aa_in.mt_edge("prewitt", thY1=0, thY2=255).mt_inflate(u=1, v=1).mt_lut("x 4 - 3 *", u=1, v=1).mt_lut("x 8 - 3 *", u=1, v=1).tmaskcleaner(1)
\ .mt_inpand_multi(mode="losange", sw=1, sh=1, u=1, v=1).mt_expand_multi(mode="losange", sw=1, sh=1, u=1, v=1)
aamask = mt_logic(em1, em2, "max", y=3, u=1, v=1).kf_YtoYUV()

aa1 = aa_in.nnedi3(field=-2, pscrn=0)
aa1 = mt_average(selecteven(aa1), selectodd(aa1), y=3, u=3, v=3)

aa_clip = mt_merge(aa_in, aa1, aamask1, y=3, u=3, v=3)

Function kf_YtoYUV(clip inputl, string "colorspace")
{
sw = inputl.Width()
sh = inputl.Height()
wmod4 = sw/4*4 == sw ? True : False
hmod4 = sh/4*4 == sh ? True : False

icolorspace = inputl.kf_GetCSP()
ocolorspace = Defined(colorspace) ? colorspace : icolorspace

try {
inputp = inputl.ConvertToY8()
inputc = ocolorspace == "YV24" ? inputp
\ : ocolorspace == "YV16" ? inputp.BilinearResizeMT(sw/2, sh , -0.50)
\ : inputp.BilinearResizeMT(sw/2, sh/2, -0.50)

output = YtoUV(inputc, inputc, inputp)
} catch (error_msg) {
inputp = wmod4&&hmod4 ? inputl : inputl.PointResizeMT(wmod4?sw:sw+2, hmod4?sh:sh+2, 0, 0, wmod4?sw:sw+2, hmod4?sh:sh+2)
inputc = inputp.BilinearResizeMT(wmod4?sw/2:sw/2+1, hmod4?sh/2:sh/2+1, -0.50)

output = YtoUV(inputc, inputc, inputp)
output = wmod4&&hmod4 ? output : output.Crop(0, 0, wmod4?0:-2, hmod4?0:-2)
}

return output
}

Function kf_GetCSP(clip c)
{
return c.IsPlanar ? c.IsYV12 ? "YV12" :
\ c.IsYV16 ? "YV16" :
\ c.IsYV24 ? "YV24" : c.kf_GetCSP_Y8_YV411() :
\ c.IsYUY2 ? "YUY2" :
\ c.IsRGB32 ? "RGB32" :
\ c.IsRGB24 ? "RGB24" : "Unknown"

Function kf_GetCSP_Y8_YV411(clip c) {
try {
c.UtoY
csp = "YV411"
} catch (error_msg) {
csp = "Y8"
}
return csp
}
}

jpsdr

31st July 2017, 18:06

Run AVSMeter/Encoding:no respond
*NNEDI3 v0.9.4.43/v0.9.4.44 Release_W7 / JPSDR Avisynth's plugins pack 1.1.6/1.1.7 Release_W7

Ok, i'll investigate when i have time.

jpsdr

2nd August 2017, 15:30

When you open a script in VirtualDub, with a standard use, and do step by step frame, you have the following functions called :
Create, Constructor, GetFrame(n=0), GetFrame(n=1), ..... and destructor called when closing the script.
The ScriptClip (and probably Avspmod), you have a total different behavior, like this :
Create, Constructor, GetFrame(n=0), destructor, Create, Constructor, GetFrame(n=1), destructor, Create, Constructor, GetFrame(n=2), destructor, etc...
It was very difficult to find out the issue, and it's almost "a luck"/"random try" that finaly worked. It will be in a next release, but it will not be done in a short time, i have others things to finalise before.
BTW, the isssue is probably not specific to nnedi3, but may also occurs on the others MT filters.

Also, this "not standard" behavior of calling Create/Constructor/GetFrame/destructor on each frame could explain the slowdown after several hundred of frames... Honestly, it's not the best way...

jpsdr

9th August 2017, 21:06

New version, see first post. AVX path added, so opt parameters values change a little (see the Readme file included in the release).

`Orum

10th August 2017, 15:44

So I've finally come across a need for this filter again, and was wondering, what's the difference between the two different AVX2 builds (the vanilla and the "Broadwell" one)? I'm guessing the Broadwell build is either for Broadwell and later CPUs, or Broadwell and earlier, but which one? Lastly, which build should AMD users be using (assuming they have AVX2 support)?

burfadel

10th August 2017, 17:07

The AVX2 and other compiles are done with Intel Compiler. This allows full optimisation on Intel CPUs. The Broadwell compile would be more optimised for the latest Intel CPUs, the other AVX2 build for Haswell. As long as the CPU supports the instruction set it should work. Now for AMD, a few years ago Intel was found to have a different optimisation for non-Intel processors that ran slower than the non-optimised versions.

Someone would need to do some testing on Ryzen with the different builds, including speed and cpu use comparison. Programs can benefit from AMD compiler tools et. http://developer.amd.com/tools-and-sdks/cpu-development/

jpsdr

10th August 2017, 18:37

New version. Minor change, forgot to add AVX path on planarframe.

FranceBB

11th August 2017, 02:07

Version v0.9.4.46 and v0.9.4.45 XP x86 don't seem to work in Windows XP. When I try to open AVSPmod or Virtual Dub with NNEDI it crashes without reporting any specific error. v0.9.4.44 works fine. I don't know why. The latest version of ResizeMT works fine in XP, though.

FFVideoSource("test.mp4")

nnedi3_resize16(target_width=1920, target_height=1080, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=false, lsb=false)

The preview doesn't appear, but AVSPmod reports the correct resolution, framerate and color space. For instance, if I try to upscale to 1920, 1080, it correctly reports the upscale but it crashes before displaying any images. I also tried to use DirectShowSource, 'cause it thought it might be an incompatibility with ffms2000, but nothing changed; same behaviour. I also tried with different resolutions, settings and sources, but I got the same behaviour every time, I don't know why.

Avisynth 2.6.1 SSE2
Windows XP Professional x86
Intel C++ Redistributable 2016-2017 installed.

jpsdr

11th August 2017, 07:21

It seems that sometimes the Intel XP version crash. I don't know why, maybe the compiler uses instructions it shouldn't have. Is the standard "Release_XP" also crahsing ? If not, uses this one.
I don't have XP anymore, i maintain these builds which should work, but can't test anymore.
So, first try the standard "Release XP".
Maybe, just for crash testing, try with opt=1 and opt=2, even if i doubt it would do something.

FranceBB

14th August 2017, 02:06

Release_XP works but not always (nasty behaviour with nnedi3_resize16):

Test1 (works):
nnedi3(field=-1, dh=false, Y=true, U=true, V=true, nsize=6, nns=1, qual=1, etype=0, pscrn=2, threads=0, opt=0, fapprox=15)

Test2 (works):
nnedi3(dh = true, nsize = 0, nns = 4, qual = 2,threads=1)

Test3 (works):
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=1920,fheight=1080,nsize=0,nns=3,qual=2,opt=1)

Test4 (works):
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=1920,fheight=1080,nsize=0,nns=3,qual=2,opt=2)

Test5 (works):
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=1920,fheight=1080,nsize=0,nns=3,qual=2)

Test6 (works):
nnedi3_rpow2(rfactor=2,cshift="Spline36ResizeMT",fwidth=1920,fheight=1080,nsize=0,nns=3,qual=2)

Test7 (works only because source it's already 720p):
nnedi3_resize16(target_width=1280, target_height=720)

Test8 (does not work and crash):
nnedi3_resize16(target_width=1920, target_height=1080)

Test9 (does not work and crash):
nnedi3_resize16(target_width=848, target_height=480)

It seems that the problem is nnedi3_resize16, but I don't know why. I tried both the NNEDI3 Release_XP and the JPSDR Pack and both behaves the same.
With the JPSDR Pack I don't have any problem with the MT as you can see from the test.
As to Windows XP, well, thanks for maintaining its support, it means a lot, and don't worry if you can't test builds, I'll test every release and I'll let you know ;)

jpsdr

14th August 2017, 09:28

What exactly is nnedi3_resize16 for ? If it's for working on 16 bits data, i've allready update the nnedi3 to work with 10,12,14,16 and 32 bits data.

FranceBB

14th August 2017, 21:52

What exactly is nnedi3_resize16 for ? If it's for working on 16 bits data, i've allready update the nnedi3 to work with 10,12,14,16 and 32 bits data.

Well, yes, it makes me use NNEDI3 to upscale using 16bit precision.
According to the updated documentation: https://github.com/jpsdr/NNEDI3/blob/master/nnedi3%20-%20Readme.txt it says "Note : Only 8 bits input is supported." (line 15). In fact, in nnedi3_resize16 I have two parameters to take a 16bit input and output at 16bit lsb_in=true, lsb=true but I don't see anything similar in the NNEDI3 documentation.

Dither_convert_8_to_16()

nnedi3_rpow2(cshift="Spline64ResizeMT", rfactor=2, fwidth=1920, fheight=1080, nsize=4, nns=4, qual=1, etype=0, pscrn=2, threads=0, csresize=true, mpeg2=true, threads_rs=0, logicalCores_rs=true, MaxPhysCore_rs=true, SetAffinity_rs=false, opt=3)

f3kdb(range=15, Y=80, Cb=60, Cr=60, grainY=0, grainC=0, keep_tv_range=True, input_depth=16, output_depth=8)

The above code, doesn't work in 16bit stacked.
If I use lsb_in=true, lsb=true, it says that these parameters don't exist in nnedi3_rpow2.

I tried to feed nnedi3 with 16bit interleave, but it doesn't work either:

Bitdepth(from=8, to=16)

nnedi3_rpow2(cshift="Spline64ResizeMT", rfactor=2, fwidth=1920, fheight=1080, nsize=4, nns=4, qual=1, etype=0, pscrn=2, threads=0, csresize=true, mpeg2=true, threads_rs=0, logicalCores_rs=true, MaxPhysCore_rs=true, SetAffinity_rs=false, opt=3)

Bitdepth(from=16, to=8)

What's the parameter to use nnedi3_rpow2 with a 16bit input, and output 8/10/16 bit?
Does your version work with 16bit stacked or interleaved or both?

jpsdr

15th August 2017, 09:45

Ah... I'm forgetting sometimes...
It works with the new natives format from avs+ automaticaly, there is no parameters. If you feed it with 12 bits, it will detect it's 12 bits, and ouput 12 bits results. But of course, it's only if you're using avs+. ;)
As these new natives format were introduced in avs+, i don't intend to bother to support others... "hacked" formats. I'm not interested in.
So, if you're not with avs+, it's true, unfortunately 8 bits only.

FranceBB

15th August 2017, 17:55

DJATOM

15th August 2017, 21:47

I see... That's a shame...
I've never used AVS+,
so don't know if the Avisynth+ 16bit internal format is any different than 16bit stacked or 16bit interleave in AVS,
but if it's 16bit stacked, we could manually trigger the detection of 16bit in avisynth via a parameter, and let the filter work as if it was in AVS+, for instance.

I really don't see a point to not use AVS+. At least it's possible to run it without installation (just download avisynth.dll, put it in avspmod folder, put plugins into desirable folder, call AddAutoloadDir("your plugins dir") at the begin of your script and enjoy it). It looks pretty simple for me. So if you afraid of breaking things on your OS, that's an option.

FranceBB

15th August 2017, 23:40

Good news!
It works in Avisynth (and Windows XP) in 16bit stacked (dither tool).
16bit interleave is not supported, but it's not very common, though.
Thanks to mawen1250 and jpsdr.

burfadel

22nd August 2017, 16:38

Apologies for the thread mixup :).

The only thing required for the script I listed that doesn't work with nnedi3() before it (but works if prefetch(4) is place in between) is the latest MVTools:
https://github.com/pinterf/mvtools/releases

jpsdr

22nd August 2017, 18:14

I've been able to reproduce with the following script (script working but freeze on exit) :

nnedi3()
super = MSuper (hpad=16, vpad=16)
bvec2 = MAnalyse (super, isb = true, delta = 2)
bvec1 = MAnalyse (super, isb = true, delta = 1)
fvec1 = MAnalyse (super, isb = false, delta = 1)
fvec2 = MAnalyse (super, isb = false, delta = 2)
MDegrain2 (super, bvec1, fvec1, bvec2, fvec2)

I'll investigate tomorrow. I hope i'll find something, because it's even more odd than the resample issue...

jpsdr

22nd August 2017, 19:26

When you have eliminated the impossible, whatever remains, however improbable, must be the truth.
I've made a little test, i have a little idea, but i was saying "no, impossible"...
When you add MDegrain2, i don't know why, but when closing the file, the destructor of nnedi3 is not called anymore !!!!
WTF is happening ??????

jpsdr

23rd August 2017, 08:01

I've tested with all my filters, it's not specific to nnedi3, i don't know how it's possible, but MDegrain2 clearly mess-up things, and the destructor of the filters is not called anymore when closing the script.
There is nothing i can do about it. I can try to find a workaround for avoiding the freeze, but there is nothing i can do for the resources allocated by the filters and not free properply because when the dll is unloaded, the destructor of the filters have not been called.

DJATOM

23rd August 2017, 08:40

jpsdr
If you think that's MVTools bug, you should open new issue on pinterf's repo :)

pinterf

23rd August 2017, 13:54

I wonder whether it happens with the old 2.6.0.5 mvtools2 version, which was the base of my current mod.

jpsdr

23rd August 2017, 15:52

No it doesn't, i see the destructor called properly with 2.6.0.5.

jpsdr

27th August 2017, 12:17

New version, see first post, should work as partial workaround the the MDgrain2 issue.

pinterf

28th August 2017, 10:24

Now I'm really back from holiday, I hope things will be solved soon. The problems first occured in mvtools2 2.7.1.22, I'll check those modifications, I already have a suspect.

jpsdr

28th August 2017, 11:49

When fixed, i'll take a look at the commit, because i'm realy curious to know how you can make possible to break the destructor call... ;)

TheFluff

28th August 2017, 16:38

I dunno what might be up in this case but C++ certainly has no shortage of ways to shoot yourself in the foot. One easy way to create a similar problem is by deleting an instance of a derived class through a pointer typed for the base class without declaring the base class destructor as virtual (https://stackoverflow.com/questions/461203/when-to-use-virtual-destructors).

jpsdr

28th August 2017, 16:48

Well, all my destructors are virtual, and all filters are derivated from GenericVideoFilter. But if it was this, i think the issue would be all the time, it seems more tricky.

Dreamland

20th October 2017, 08:23

Help me!! I have just installed win 10 fall creator update 64 bit (fresh installation) and
and i have this error
https://t14.pixhost.org/thumbs/59/54587993_2017-10-20_090756.png (https://pixhost.org/show/59/54587993_2017-10-20_090756.png)
usually installation..usually plugins ,usually dependence installed, but now, with FCU i have this issue !

why?

NNEDI3 V 0.9.4.47 (same error with older versions)

I'm getting crazy! :(

thx for helps :)

jpsdr

20th October 2017, 09:59

Dreamland

20th October 2017, 10:13

I don't have Windows 10, and have no idea what "Win 10 fall creator" or "FCU" are...

The only basic "stupid" questions i can see for now are :
- What DLL version are you using ? Be sure to not use a 32bits DLL for 64Bits and reverse.
- Have you installed the Visual Studio redistribuable required ? And the Intel redistribuable if you're using the Intel version ?

If everything for these two are correct, i personnaly have no further idea.

DLL=NNEDI3_v0_9_4_47/x86/Release_Intel_W7_Core2_AVX2 for avisinth 2.6

VBCRedist_AIO_x86_x64.exe
15/10/2017
http://repacks.net/forum/viewtopic.php?t=125

intel redistribuable: icl_redist_intel64_2016.4.246.msi

https://software.intel.com/en-us/articles/redistributables-for-intel-parallel-studio-xe-2016-composer-edition-for-windows

thx a lot

jpsdr

20th October 2017, 10:20

The readme said :

Release_Intel versions are compiled with Intel Parallel Studio 2017 (icl 17.0.4.210)

So maybe you need icl_redist_intel64_2017.4.210.msi instead. Useless of course if you're not using an Intel release version.
As for the "All in One package", i don't know, i don't use this kind of thing, so, if it provides the same redistribuable than provided in the readme link, it should be fine.

Euh... Just noticed... You're using an x86 DLL, and install the x64 Intel, and with x64 things...? I don't understand this mess. Either you need to use the x64 DLL, either you need to install icl_redist_ia32_2017.4.210.msi

Groucho2004

20th October 2017, 10:35

FYI - error 0X3E6 = ERROR_NOACCESS
Possible cause:
https://support.microsoft.com/en-us/help/196069/prb-loadlibrary-api-fails-with-998-error-noaccess-error

Dreamland

20th October 2017, 10:39

no works icl_redist_intel64_2017.4.210.msi

jpsdr

20th October 2017, 11:07

Apparently you use an x86 DLL, so as i said, you may probably need icl_redist_ia32_2017.4.210.msi instead.

Dreamland

20th October 2017, 13:15

icl_redist_ia32_2017.4.210.msi

same error..
before, with win 10 creator update, (the same plugins and nnedi3 ) worked 100%
i don't know where is the issue

thx a lot for you help

Groucho2004

20th October 2017, 13:30

icl_redist_ia32_2017.4.210.msi

same error..
before, with win 10 creator update, (the same plugins and nnedi3 ) worked 100%
i don't know where is the issue
A couple of things you could try:
1. Use the original 0.9.4 version of nnedi3, download from here (https://www.dropbox.com/s/zinhar4jru6u1p7/nnedi3.7z?dl=1).
2. Run "AVSMeter -avsinfo" and check if there are any errors.

Dreamland

20th October 2017, 13:43

ok ..give me time ...thanks

Dreamland

20th October 2017, 13:59

now works
https://forum.doom9.org/showthread.php?p=1788850#post1788850
http://www.mediafire.com/file/5rp8jtv78otxxku/icl+-+xp.rar
this was my problem : My old DLL was corrupted (i think) :sly:...overwrite with new DLL and now works

jpsdr

20th October 2017, 17:17

Why do you need Windows XP things when you are under Windows 10 ???

Dreamland

20th October 2017, 20:25

I know it's so strange..but putting and overwriting in system32/ syswow64 this DLL for XP, i have no error in my NNEDI3

https://t14.pixhost.org/thumbs/67/54634829_appunti01.jpg (https://pixhost.org/show/67/54634829_appunti01.jpg)

(excuse me for my bad english)

jpsdr

24th November 2017, 12:50

New version, see first post.

monohouse

28th January 2018, 12:02

is there no build of NNEDI3 for AMD ? I am using latest version and my script on core 2 duo give 0.03 fps/core but on my thuban 1090T I have only 0.01 fps/core

your version has SSE2 but the thuban has newer instructions that nnedi3 doesn't appear to use (SSE3, SSE4A, 3DNow!, 3DNow+!) and there is no AVX in thuban :x

jpsdr

28th January 2018, 14:09

No, sorry, and i don't think there would great step with the instructions sets you list.

monohouse

28th January 2018, 16:06

so 0.01 in thuban is normal when core 2 duo have 0.03 ? I thought they supposed to be same performance per core

Groucho2004

28th January 2018, 16:18

so 0.01 in thuban is normal when core 2 duo have 0.03 ? I thought they supposed to be same performance per coreHow are you measuring the speed? Can you post the script you used for your test?

monohouse

28th January 2018, 17:10

MCTD(radius=2, twopass=false, refine=true, useTTmpSm=true, limit=1, limit2=1, stabilize=true, maxr=1, TTstr=1, chroma=true, sharp=false, adapt=false, strength=1000, sigma=0, pMode=0,fixband=false,pp=false,search=3, searchparam=4, pel=4, pelsearch=4, bwbh=512, owoh=256, blksize=4, overlap=2, edgeclean=false, ECrad=1, ECthr=32, ECmode="Removegrain(2,0)",protect=false,AA=false,deblock=false,post=0,interlaced=true,GPU=true,precision=2,bt=4,enhance=false)
daa3(nthreads=1)
LSFmod(defaults="slow",strength=20,Smode=3,Smethod=3,Lmode=0,overshoot=0,preblur="ON",secure=false,edgemode=0,soft=0,soothe=false,ss_x=1.00,ss_y=1.00)

Groucho2004

28th January 2018, 18:12

You did not answer my first question. Also, do you realize how many plugins are used in your script? How do you single out nnedi3 as the bottleneck?

monohouse

29th January 2018, 01:26

x264 is writing the encoding speed, I tested with nthreads=6 on the thuban using all 6 cores and got 0.04 fps, nthreads parameter of the daa3 is only giving nnedi3 the number of threads :)

I tested:
with linux in wine32 version 3-rc6
linux wine64-rc6
windows 7 WOW64 (virtualbox)
windows7 x64 (virtualbox)

they all give the same speed :x

avs2yuv.exe -raw "A:\test.avs" -o - | x264.x86.exe --input-res 720x480 --fps 30000/1001 --qp 0 --level 6.2 --ref 16 --bframes 16 --b-adapt 2 --8x8dct --mixed-refs --direct auto --slow-firstpass --no-fast-pskip --me tesa --merange 24 --partitions all --rc-lookahead 60 --subme 11 --trellis 2 - -o "W:\test.264"

jpsdr

29th January 2018, 10:06

Seriously...? You have a lot of plugin and running x264 and think that the difference of fps comes only from nnedi3...??!! And more, you seems to use wine/virtualbox kind of things, which also doesn't help !
How can you be so sure ?
I don't say it's not possible, but personnaly, i also think of x264, which is more optimised for Intel CPU than for AMD.

Andouille

29th January 2018, 20:25

avs2yuv.exe -raw "A:\test.avs" -o - | x264.x86.exe --input-res 720x480 --fps 30000/1001 --qp 0 --level 6.2 --ref 16 --bframes 16 --b-adapt 2 --8x8dct --mixed-refs --direct auto --slow-firstpass --no-fast-pskip --me tesa --merange 24 --partitions all --rc-lookahead 60 --subme 11 --trellis 2 - -o "W:\test.264"

Are you aware that most your "placebo" and ultramegagigaslow settings are not even used when lossless encoding ?

And Groucho also pointed out that a LOT of plugins are used for your filtering.

monohouse

30th January 2018, 10:58

I am sure it is nnedi3 because when nnedi3 plugin threads increase to 6 the speedup is linear from 0.01 to 0.04, and the reason that it is 0.04 (and not 0.06) is because nnedi3 with threads=6 is not consistently using all 6 cores to 100%. you don't wanne help ? that's fine, at least have the decency to admit it, instead of trying to "drop the bag on something else" claiming that I am wrong or something else is wrong in the way that I do it.

WTF is the problem with wine/virtualbox ? do you even know these systems that you claim them to have effect on the performance ?!

what do all the other plugins have to do with anything when there is almost linear scaling in performance when nnedi3 threads increase ?!

you think you are the only one who can use question marks with inclamations ?! well guess what - so can I

if you would have simply said "no, we will not help you" you would have attained a little respect, now the community will look at you like fools trying to hide the true and the facts and for being snakes trying to make me look bad as if I don't know what I am doing. now that you got pwned - you ruined your reputation, instead of being honest and say things for what they are. but now that problem is your problem not my - it out of my hands now, I wasn't looking to hurt you - I was looking to get help.

real.finder

30th January 2018, 12:27

I am sure it is nnedi3 because when nnedi3 plugin threads increase to 6 the speedup is linear from 0.01 to 0.04

as they told you, you can make sure by that

use this to test

ColorBars(pixel_type="yv12")
nnedi3

using avsmeter not x264

edit: and try to not use Release_Intel_XXXXXX dlls

monohouse

30th January 2018, 13:16

jpsdr

30th January 2018, 15:24

I like this kind of results more.
If you want to compare the speed of the same code path, in the Haswell test, add opt=2 (force not more than SSE2) or opt=3 (force not more than SSE4.1), i don't know between both, what your thuban can do.
If you want to be 200% sure, put the same on the thuban test, this way, you will be sure that both are using the same code path, and maybe you can compare speed more accurate.

I don't know the default size for colorbar, but using pscrn=0 to bench is in a way a good thing. Why...?
Because colorbar is probably around 95% of flat area, meaning 95% of the process will be the simple bilinear upscale with default pscrn=2, not the neural network. Meaning, very few computation versus a lot of memory access, so, the increase speed and CPU usage will be not linear with threads increase (and be very poor) with this specific test case.
Puting pscrn=0 will force the neural network computation on all pixels, and you've also changes the parameters to put the maximum neural network size. This way, you have a lot of computation and less memory access. This way, you can more accurately check the increase speed and CPU usage with threads increase.

Warning ! : Doing this kind of test, i've noticed that if you're doing this most stressfull configuration, and if you have AVX2, you'll skyrock the CPU usage and the T° increase of the CPU, almost the same way the most stressfull test of Prime95 on AVX2 is overheating your CPU.

monohouse

30th January 2018, 16:41

yhe, thank to intel for put shit for grease in the CPU

TheFluff

30th January 2018, 18:13

if you would have simply said "no, we will not help you" you would have attained a little respect, now the community will look at you like fools trying to hide the true and the facts and for being snakes trying to make me look bad as if I don't know what I am doing. now that you got pwned - you ruined your reputation, instead of being honest and say things for what they are. but now that problem is your problem not my - it out of my hands now, I wasn't looking to hurt you - I was looking to get help.

First, and most importantly: lol

it looks like under synthetic load the haswell is 3 times more fast, under real load it's more than 5 times more fast, neither are correct: the thuban is supposed to be only half as fast as a haswell

when adjusted for clock rate difference between 4200 and 3000, the haswell under real load is still 4.07 times faster than the thuban

notice that on haswell, between default and proper load the difference is a factor of 1906.8, but on the thuban it is 3196.9 (1300 times slower than it should be)

NNEDI3 on colorbars with the prescreener on is almost certainly memory bound, so that one is completely irrelevant unless you really want to benchmark your memory speed. You'll most likely get essentially the same fps from bicubicresize.
(edit: sources tell me the prescreener is actually not that fast so the above might not actually be completely true)

Moving on, by what metric exactly is Thuban supposed to be half as fast as Haswell? cpubenchmark.net numbers, or what? Those are pretty much meaningless in this context. NNEDI3 is full of 128-bit SSE operations which (IIRC) took two uops on K10 (since it was implemented as two 64-bit ops) but only one on Intel CPU's starting with the... man I don't even know, Core 2? Well before Haswell at any rate. K10 could also only use two floating point execution units - FADD and FMUL - for a lot of the SSE stuff, with a third (FMISC) also being usable for loads and stores. It's hard to compare directly with Haswell's more complex fused architecture which has eight execution units with different capabilities, but in general you should expect Haswell to have at least twice the SSE throughput per clock cycle compared to the K10.

To verify I wasn't talking completely out of my butt, I went to take a quick look at Agner Fog's instruction reference, and sure enough, on Haswell you can get two XMM multiplies (addps/mulps) per clock cycle compared to one on K10.

tl;dr: don't expect much of an almost 10 year old CPU

edit: Addendum: I misremembered, the "128-bit uops implemented as two 64-bit uops" thing was only on K8, not K10. Nevertheless, the K10 has other issues, particularly with scheduling, and the general statement that Haswell should have at least twice the SSE throughput per clock cycle stands. In fact it's probably reasonable to expect better than that; it should be realistically possible to get an average throughput of four instructions per clock cycle.

monohouse

31st January 2018, 04:42

thank, that is most informative, I was not using such detailed analyse of the architectural differences, I was expecting half as fast based on the timeframe of the cpu (nehaylem timeframe), and yes, something like cpubenchmark.net.

so SSE is crap on thuban and combined with scheduling problems it get worse :x
that explain why core 2 duo is so mutch better
what you say it make sense on haswell and sits well with the results: 4 times faster: twice faster from SSE architecture and twice more for the rest (scheduling)
what do I do now :x
I should buy a xeon or something...

does anyone of you guys have a ryzen AM4, could anyone test if the performance of nnedi per core is good ?

feisty2

31st January 2018, 05:02

what do I do now :x
I should buy a xeon or something...

if u do plan to spend some money, get a GPU, 1080Ti or something, most image/video processing algorithms are like a zillion times faster on gpu, primitive algorithm like nnedi3 could even run faster than real time on GPUs far from nearly as fast as 1080Ti, and a lot of filters are moving on to GPU implementations, like
knlmeanscl (https://forum.doom9.org/showthread.php?t=171379)
nnedi3cl (https://forum.doom9.org/showthread.php?t=174902)
eedi3cl (https://forum.doom9.org/showthread.php?t=174845)
and more

monohouse

31st January 2018, 05:09

I whant faster than real time :) but there is some problems...
I tested knl-CL, the problem with him is that he make stains in the video :x
I don't think I can do vaporsynth because MCTD and daa3 not available on vaporsynth :x and I think neither is LSFmod (but that I could give up and find something else)
I also tested nnedi3ocl from 2013 - his output is very bad with -2 (which daa3 is using) (I tested him on both nvidea and radeon) :x

leeeeeel: i7-6700k at 4.0 GHz vs GTX 1060: 1060 2x more fast

if only the original didee daa3 was available on vaporsynth, I could do the nnedi3/deinterlacing on vaporsynth separate from avisynth and then combine both - mybe even on the same command line if there is the tools

daa3 looks like this:
nn = c.nnedi3(field=-2,nsize=size,nns=neurons,qual=2,pscrn=0,fapprox=0,threads=nthreads)
dbl = mt_average(selecteven(nn),selectodd(nn),U=3,V=3)

I wonder if it's possible to have the nnedi3 process done in vaporsynth and the clip output to avisynth if the selecteven(nn)/selectodd(nn) functions will work from an external clip...

Aktan

31st January 2018, 05:49

Hello there! I'm just curious if this could be explained. I am on a Ryzen 1700X overclocked to 3.8 Ghz. I am running Avisynth+ Revision 2574-MT 64-bit. I use the following line in the AVS:

AVISource("deint.avi")
nnedi3_rpow2(rfactor=4, cshift="lanczosresize", fwidth=2880, fheight=1920, ep0=2, nsize=0, nns=4, qual=2, pscrn=4, opt=0)

It should be noted that the original resolution is 720x480 and that it's just a clip I capture from my capture card of a VHS tape. I also know that Ryzen support of AVX2 is emulated since there is no 256bit register in Ryzen. I've read that it will be half the speed of Intel, but I didn't think it be this bad. Anyway, testing out opt 0 - 7 gave the following results:

opt FPS
0 0.56
1 5.89
2 14.6
3 14.48
4 14.7
5 0.57
6 0.57
7 0.56

Can Ryzen AVX2 be that bad? I also noticed opt 0, 5-7 uses all 16 logical cores while opt 1-4 barely hits 50% while being so much faster. I am using Release_Intel_W7_Core2_AVX2 version of the DLL.

Edit: FMA4 is not officially support, but varies people said it still works on Ryzen with bugs, I tested it for fun.

monohouse

31st January 2018, 05:57

I suspect that you need this: https://github.com/jimenezrick/patch-AuthenticAMD
it a program that patch intel-compiled binary that use intel cpu detection to detect an AMD cpu

jpsdr

31st January 2018, 10:24

@Aktan
It seems at "0" it detects AVX2 (same has 5), but unfortunately results are not good, but ten time slower than "only C"... Ouuah !!!
At one moment, you'll see why there is a price differences.
After, on Intel CPU, there is not so much differences between AVX and AVX2, so, the speed gain can't worth the price difference for a lot of people.
Set manualy opt to 4 (AVX).
Issue is that if you stick to CPU possibility, you're screwed with AVX2, and on some program may have bad surprises.
Probably some program like x264 are a little clever, and detect Intel/AMD, and don't go over AVX on AMD, because they know AVX2 is slow as hell.
What should be done, is to detect if CPU is AMD or Intel, and don't allow AVX2 on AMD on automatic detection, but i don't know how to detect AMD with the parameters avaible on avs...

Aktan

31st January 2018, 14:52

I suspect that you need this: https://github.com/jimenezrick/patch-AuthenticAMD
it a program that patch intel-compiled binary that use intel cpu detection to detect an AMD cpu

Thanks for the link, though it doesn't seem easy to compile, lol.

@Aktan
It seems at "0" it detects AVX2 (same has 5), but unfortunately results are not good, but ten time slower than "only C"... Ouuah !!!
At one moment, you'll see why there is a price differences.
After, on Intel CPU, there is not so much differences between AVX and AVX2, so, the speed gain can't worth the price difference for a lot of people.
Set manualy opt to 4 (AVX).
Issue is that if you stick to CPU possibility, you're screwed with AVX2, and on some program may have bad surprises.
Probably some program like x264 are a little clever, and detect Intel/AMD, and don't go over AVX on AMD, because they know AVX2 is slow as hell.
What should be done, is to detect if CPU is AMD or Intel, and don't allow AVX2 on AMD on automatic detection, but i don't know how to detect AMD with the parameters avaible on avs...

I'm still surprise it is that much slower. So you don't think it is something with the compiler, instead it really is that slow on AMD? I should mention doing a longer test, on AVX it does hit near 100% sometimes and the FPS does go down to 8 FPS sometimes. The beginning frames were basically a blank blue screen (no signal screen) and AVX2 is still that slow.

TheFluff

31st January 2018, 15:20

AVX2 shouldn't be that slow on Ryzen, I don't think. There's probably something weird going on.

x264 has a "slow SSE2" flag for Athlon 64/K8, but no "slow AVX2" equivalent.

Aktan

31st January 2018, 15:26

I was doing some research on benchmarks for Ryzen and AVX2, and it seems in general while not as fast as Intel, AVX2 should still be faster than AVX. For example I found this:

http://www.numberworld.org/y-cruncher/internals/arch-optimizations.html

I do admit they manually tune though. I think it is still related to Intel compiler. I wonder how hard is it to compile the DLL on VS. I'll try it out later today.

TheFluff

31st January 2018, 15:31

I think it is still related to Intel compiler.

What do you base that on? Most of the NNEDI3 performance-critical code is in hand-written assembler in this version. In the Vapoursynth version (which uses mostly compiler intrinsics in C++ rather than pure asm) you could argue that the compiler could have a big impact, but not in this version. In fact it's been repeatedly pointed out in this very thread that having a special DLL with compiler optimizations for AVX2 enabled is completely pointless - it has essentially no performance impact at all, since there's nothing performance critical that the compiler can actually optimize.

Aktan

31st January 2018, 15:34

What do you base that on? Most of the NNEDI3 performance-critical code is in hand-written assembler in this version. In the Vapoursynth version (which uses mostly compiler intrinsics in C++ rather than pure asm) you could argue that the compiler could have a big impact, but not in this version. In fact it's been repeatedly pointed out in this very thread that having a special DLL with compiler optimizations for AVX2 enabled is completely pointless - it has essentially no performance impact at all, since there's nothing performance critical that the compiler can actually optimize.

I will admit it was just a bad guess as I'm not that familiar with compilers. I guess I won't be able to compile it then since there was hand written ASM. I based it on the fact that in the past Intel did selectively optimize to only Intel chips in their compiler.

Edit: Just curious, if I use the Release_Intel_W7_Core2_AVX DLL or even the Release_Intel_W7_Core2_SSE4.2 DLL and set opt to 5, would AVX2 still be used? I tried that and I still get the same slow speed. I was expecting it to throw an error like invalid opt mode, but I was just guessing.

TheFluff

31st January 2018, 15:50

What happens if you use threads=1?

BTW, if you're willing to try Vapoursynth, you can try znedi3 (https://github.com/sekrit-twc/znedi3), an attempt at making NNEDI3 on the CPU competitive with the OpenCL version running on the GPU. IIRC it was something like 50-100% faster than the original VS NNEDI3 on 8-bit input, but I don't know if anyone ever tested it on Ryzen.

Aktan

31st January 2018, 15:53

What happens if you use threads=1?

BTW, if you're willing to try Vapoursynth, you can try znedi3 (https://github.com/sekrit-twc/znedi3), an attempt at making NNEDI3 on the CPU competitive with the OpenCL version running on the GPU. IIRC it was something like 50-100% faster than the original VS NNEDI3 on 8-bit input.

I'll try both in a bit.

Edit: threads=1:

opt FPS
4 ~4
5 0.11 (~1 frame every 9 seconds)

pinterf

31st January 2018, 16:59

It's not Ryzen. This one:
nnedi3_rpow2(rfactor=4, cshift="lanczosresize", fwidth=2880, fheight=1920, ep0=2, nsize=0, nns=4, qual=2, pscrn=4, opt=5)
is giving me 0.03 fps for the first 3-4 frames with opt=0 or opt=5
and >3 fps with opt=4

x64 version freshly recompiled with VS2017 15.5
Intel i7-7700 (AVX2), Win10 x64, Avisynth+ 2591 (dev)

Aktan

31st January 2018, 17:02

That's interesting, I guess now to figure out which of the param is actually causing it.

jpsdr

31st January 2018, 17:05

Edit: Just curious, if I use the Release_Intel_W7_Core2_AVX DLL or even the Release_Intel_W7_Core2_SSE4.2 DLL and set opt to 5, would AVX2 still be used?
No differences in the code, just compiler options, all versions will behave the same.

jpsdr

31st January 2018, 17:10

Odd... I don't remember so much differences when testing... But on my tests, i've never changed ep0 and always tested pscrn with 2 or 0.
Btw, with 0, very small frames (480p) to have some frames without having to wait hours... ;)
Don't have time for now, but will redo tests later.

pinterf

31st January 2018, 17:11

Missing else

https://github.com/jpsdr/NNEDI3/blob/master/nnedi3/nnedi3.cpp#L1725

https://github.com/jpsdr/NNEDI3/blob/master/nnedi3/nnedi3.cpp#L1734

fps is OK again for AVX2

(And a request: the AVX2 asm files were missing from the sln file had to add them manually)

jpsdr

31st January 2018, 17:16

I was about to said that i'll check if i didn't messed-up something, but you beats me... :p
:thanks:
About ASM files :
Yes it's normal they are missing, because i want to keep the project on github on VS2010 (if you want to use more than VS2010, you can just upgrade the project), but VS2010 will not be able to to compile the AVX2 asm files, so it will result on a incorrect project if they were included. This is why the AVX2 asm are on others files.

Aktan

31st January 2018, 17:31

Awesome catch! Yep, changing prescreen to original (1) where the bug doesn't exist gave me results comparable to AVX.

jpsdr

31st March 2018, 10:11

New version, see first post, and i've also added on it a part about the multi-threading.

jpsdr

3rd April 2018, 12:10

There is issue with the Intel versions.

I'll update the release files on github, removing the Intel versions, and keeping only VS version, and adding an VS AVX2 version. Wait at least 24h to check/re-download the files.

jpsdr

3rd April 2018, 20:30

Trashed Intel version, file updated, redownload it.

jpsdr

7th April 2018, 12:47

New version, see first post, updated also the Multi-treading text part.

mp3dom

25th May 2018, 15:32

Taurus

25th May 2018, 20:13

It seems there's a bug in YUY2 colorspace that create a green vertical bar on the right side of the image under some circumstances (both x86 and x64):

colorbars(width=1416,height=1080,pixel_type="yuy2")
nnedi3(0)

But only if the width is at some "odd" resolutions...not devidable with mod16.
Older versions show the same behaviour.
Just a short test..

jpsdr

25th May 2018, 20:58

Thanks for reporting, i've found what was wrong.
I want to finish something else i'm working on before making new releases of some filters. So, several days before i'll make new builds, but it's fixed on Github.

mp3dom

26th May 2018, 12:35

So, several days before i'll make new builds, but it's fixed on Github.
Thanks

jpsdr

1st June 2018, 10:01

New version, see first post.

LouieChuckyMerry

20th May 2019, 15:41

Hello, and thank you jpsdr for your hard work :) . I'm preparing to upscale my PAL Futurama DVD's to 960x720 and found this:

### Resize ###
NNEDI3_RPow2(RFactor=2,CShift="Spline64Resize",FWidth=960,FHeight=720)
aWarpSharp2(Depth=5)
Sharpen(0.2)

to do a very nice job. I'm having some trouble, though, fitting this into my 16-bit pipeline and was hoping you could help. Here's the part of the script that's causing trouble:

### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,LSB=True,LSB_Out=True)### Resize ###
NNEDI3_RPow2(RFactor=2,CShift="Spline64Resize",FWidth=960,FHeight=720)
aWarpSharp2(Depth=5)
Sharpen(0.2)

This outputs video with a resolution of 960x360 and for the life of me I can't figure out why. SMDegrain is sending 16-bits to NNEDI3, which I know from reading the thread should be OK. Please, do you have any ideas? Thanks for your time.

Edit: I just noticed that this thread hasn't seen action in almost a year; however, if anyone can answer my question I'd be very appreciative.

gonca

20th May 2019, 17:07

Your source filter might be stacking in order to give you a 16 bit pipeline.
At conclusion of workflow when the "8 over 8" is undone you get half height resolution
Try a quick sample with resize of 960 x 1440 or get a better source filter if possible

LouieChuckyMerry

20th May 2019, 19:26

Thanks for your reply, gonca. My source filter is DGIndexNV for the .m2v video. I know that SMDegrain stacks the video then sends stacked 16-bit to NNEDI3, but it seems NNEDI3 isn't happy about this. I'm using the latest AviSynth+. Let me try a quick resize... That actually worked, but is it the correct way or is there some AviSynth+ syntax I'm missing?

Edit: I indexed with LSMASH and it's the same story, 960x360 output. Hmmm...

gonca

20th May 2019, 21:34

DGIndexNV is fine and not the problem
Can you give DGDenoise a try instead of using SMDegrain
or use
ConvertFromStacked(clip clip, int bits )
http://avisynth.nl/index.php/ConvertStacked
after SMDegrain

LouieChuckyMerry

20th May 2019, 23:16

DGIndexNV is fine and not the problem
Can you give DGDenoise a try instead of using SMDegrain

I searched about for DGDenoise but couldn't find anything, yet it seems familiar. Could you please give me a hint.

http://avisynth.nl/index.php/ConvertStacked
after SMDegrain

I actually tried this some days ago but received the error message "ConvertFromStacked: Input stacked clip must be YV12, YV16, YV24 or YV8". At the time I wondered how this could be, given that the final line of my functional script is "ConvertFromStacked", but then I went about my business. Here's my script starting from the SMDegrain call (where the high bit depth begins); the earlier calls are deinterlacing, color conversion, Gibbs noise block, etc, all done in 8-bit:

### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,LSB=True,LSB_Out=True)
### Resize ###
NNEDI3_RPow2(RFactor=2,CShift="Spline64Resize",FWidth=960,FHeight=720)
aWarpSharp2(Depth=5)
Sharpen(0.2)
### Darken-Thin Lines ###
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=8,Chroma=2)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
### Deband ###
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=1,Input_Depth=16,Output_Mode=1,Output_Depth=16)
ConvertFromStacked

If I reverse the Overall Temporal Denoise and Resize lines, then the script runs fine and outputs 960x720 video; however, everything I've ever read regarding video encoding states that denoising should come before resizing (which makes perfect sense). I know the issue begins with the resizing because removing everything but "ConvertFromStacked" after the Resize section still results in the above error message.

I guess now I'm wondering why SMDegrain outputs seemingly different 16-bit than F3KDB, since the F3KDB output has no issue with the "ConvertFromStacked" call. Anyway, thanks again for your help.

gonca

20th May 2019, 23:31

As for DGDenoise, look in the DGDecodeNV manual

Re
ConvertFromStacked(16)
Try it after SMDegrain and before NNEDI3

jpsdr

21st May 2019, 09:12

What do you mean "stack" ? I support 16 bits, but only "true" 16 bits, so only on avs+ for more than 8 bits data. I don't support "hacked" format.

gonca

21st May 2019, 10:55

What do you mean "stack" ? I support 16 bits, but only "true" 16 bits, so only on avs+ for more than 8 bits data. I don't support "hacked" format.
If this is meant for me, I don't know what source filter is being used or how the 8 bit DVD got to be 16 bit
And there is no mention of NNEDI3 not handling 16 bits

FranceBB

21st May 2019, 12:36

@LouieChuckyMerry... You are feeding NNEDI3_RPow2 with 16bit stacked data while it's expecting 8bit.
Please note that the Jean-Philippe mod of NNEDI3 works in planar only, so it expects 8bit/10bit/12bit/14bit/16bit planar, not stacked nor interleaved, however SMDegrain with lsb=true is working in 16bit stacked.

This is what you gotta do:

#Indexing your 8bit source using your preferred indexer
FFMpegSource2("video.ts")

#Bring everything up to 16bit stacked
Dither_Convert_8_To_16()

#Denoise with 16bit stacked precision
SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,LSB=True,LSB_Out=True)

#Upscale with 16bit stacked precision
nnedi3_resize16(target_width=960, target_height=720, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

#Sharpening
#please note that you can't use awarpsharp2 as you did
#because awarpsharp is expecting 8bit planar
#while you are feeding it with 16bit stacked
#so you need to use aWarpSharp4xx
aWarpSharp4xx(depth=5, lsb=true)

#Do not use Sharpen(0.2)
#not only you can't use it with 16bit stacked
#but it's also a very basic and simple sharpening
#which does not work well;
#if you really have to use something else

#Line Darkening
#You did everything correctly this time
#as you brought everything back to 8bit
#you filtered with FastLineDarkenMod and awarpsharp2
#two filters that work in 8bit planar
#then you brought the result back to 16bit stacked
#and you applied the differences to the original 16bit stacked
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=8,Chroma=2)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)

#Debanding with 16bit stacked precision
#You did everything correctly this time as well
#as you specifically told f3kdb that it's getting 16bit stacked
#as input and that it should work internally at 16bit
#and output 16bit stacked
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=1,Input_Depth=16,Output_Mode=1,Output_Depth=16)

I hope it helps.

LouieChuckyMerry

21st May 2019, 14:14

As for DGDenoise, look in the DGDecodeNV manual

Re
ConvertFromStacked(16)
Try it after SMDegrain and before NNEDI3

gonca: Again, thank you for your help :) . I tried the above but to no avail, although now we know why:

What do you mean "stack" ? I support 16 bits, but only "true" 16 bits, so only on avs+ for more than 8 bits data. I don't support "hacked" format.

jpsdr: Thank you for solving the mystery (and for your port of NNEDI3 :) ).

FranceBB: Thank you very much for your educational explanations; they're really helpful to an AviSynth hobbyist such as myself :) .

1) After perusing this entire thread I eventually came to understand that jpsdr's port of NNEDI3 doesn't work with stacked 16-bit. What I wonder is, would this:

### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,LSB=True,LSB_Out=False)
### Resize ###
NNEDI3_RPow2(RFactor=2,CShift="Spline64Resize",FWidth=960,FHeight=1440)
aWarpSharp2(Depth=5)
Sharpen(0.2)
### Darken-Thin Lines ###
Dither_Convert_8_To_16()
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=8,Chroma=2)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)

be the "correct" way to use NNEDI3_RPow2 in my original script? Not that I would use this, though, because...

2) I encountered your NNEDI3_Resize16 line in this thread and was able to make it work after some effort. Thank you. I reckon it's better to upscale in 16-bits, no?

3) I did some searching, with two different engines, for aWarpSharp4 and found, literally, nothing. Do you know where I might find a copy?

4) Please, any suggestions to replace Sharpen(0.2)?

5) Thanks for your kind help :) .

FranceBB

21st May 2019, 15:29

1) Yes, that would be the correct way as you are feeding it with 8bit planar data.

2) Yep, definitely better to have more precision whenever you can (at the expense of speed).

3) Sure, there you go: https://forum.doom9.org/showthread.php?p=1715287#post1715287

4) If you are working in 8bit planar: LSFMod. If you are working in 16bit interleaved, either MCLS_16 or BicubicSharp. For 16bit stacked, I'm using RKS but it's closed source and I can't share it as it has been developed years ago by the engineer who taught me encoding.

Thank you very much for your educational explanations; they're really helpful to an AviSynth hobbyist such as myself

The whole 16bit stacked, interleaved, planar is kinda tricky for me as well sometimes, so I'm not surprised that it's confusing for people who don't use Avisynth everyday for work and for people who didn't really went through the "evolution" of Avisynth through the years 'till the "normal" high bit depth arrived.
Honestly, if planar was introduced years ago in "vanilla" Avisynth, we wouldn't have had this "mess" of filters supporting stacked, some others supporting interleaved, some others supporting both (like f3kdb) but not planar > 8bit, some others supporting planar only 8bit, some others supporting planar high bit depth (8bit/10bit/12bit/14bit/16bit/32bit) but not stacked nor interleaved ecc.

LouieChuckyMerry

22nd May 2019, 01:45

1) Yes, that would be the correct way as you are feeding it with 8bit planar data.

Thanks for scratching a brain itch; I've been wondering about this for a couple weeks.

2) Yep, definitely better to have more precision whenever you can (at the expense of speed).

For Futurama speed is no issue ;) .

3) Sure, there you go: https://forum.doom9.org/showthread.php?p=1715287#post1715287

:thanks: It's been tested and added to the script.

4) If you are working in 8bit planar: LSFMod. If you are working in 16bit interleaved, either MCLS_16 or BicubicSharp. For 16bit stacked, I'm using RKS but it's closed source and I can't share it as it has been developed years ago by the engineer who taught me encoding.

Any suggestions for 16-bit stacked that's not closed source, or is there no longer a reason to add extra sharpening after aWarpSharp4xx given the new, improved script? I stole, er, borrowed the original NNEDI3_RPow2-aWarpSharp2-Sharpen upscale block and figured that the "Sharpen(0.2)" call was like a final touch-up to the upscaling.

The whole 16bit stacked, interleaved, planar is kinda tricky for me as well sometimes, so I'm not surprised that it's confusing for people who don't use Avisynth everyday for work and for people who didn't really went through the "evolution" of Avisynth through the years 'till the "normal" high bit depth arrived.
Honestly, if planar was introduced years ago in "vanilla" Avisynth, we wouldn't have had this "mess" of filters supporting stacked, some others supporting interleaved, some others supporting both (like f3kdb) but not planar > 8bit, some others supporting planar only 8bit, some others supporting planar high bit depth (8bit/10bit/12bit/14bit/16bit/32bit) but not stacked nor interleaved ecc.

It does get quite confusing, with almost too may possibilities to understand. I love videos, and the ability to "improve" them--at least to my eyes--makes me happy. Kind people such as yourself are especially appreciated. Danke schön!

FranceBB

22nd May 2019, 04:42

is there no longer a reason to add extra sharpening after aWarpSharp4xx given the new, improved script? I stole, er, borrowed the original NNEDI3_RPow2-aWarpSharp2-Sharpen upscale block and figured that the "Sharpen(0.2)" call was like a final touch-up to the upscaling.

I don't think it's needed. Spline is a very sharp resizing kernel due to the nature of its implementation and if you need it to be sharper, try raising the "taps" number in NNEDI 'till you'll find the "sweet spot". As you probably know, internally, Spline is limited to Spline16Resize, Spline36Resize and Spline64Resize, however in NNEDI you can choose the number of taps yourself, so you can go above and get Spline144Resize using 12 sampling points and so on. Please note though that a very high number of taps won't be as beneficial as you might expect, which is why people are generally using Spline36 or Spline64... except Katie... She loves Spline144Resize.

videoh

22nd May 2019, 05:13

If you are using Avisynth+ and DGDecNV, then you have DGSharpen(), which is a very fast CUDA implementation with functionality like LSFmod. It works in 8 or 16-bit depth.

You really should get away from all the high-bit-depth hacks, IMHO, and go for native support.

LouieChuckyMerry

22nd May 2019, 14:42

I don't think it's needed. Spline is a very sharp resizing kernel due to the nature of its implementation and if you need it to be sharper, try raising the "taps" number in NNEDI 'till you'll find the "sweet spot". As you probably know, internally, Spline is limited to Spline16Resize, Spline36Resize and Spline64Resize, however in NNEDI you can choose the number of taps yourself, so you can go above and get Spline144Resize using 12 sampling points and so on. Please note though that a very high number of taps won't be as beneficial as you might expect, which is why people are generally using Spline36 or Spline64... except Katie... She loves Spline144Resize.

Thanks for the very informative answer--I didn't know that about Spline--and thank you so much for all your instructive help :) .

If you are using Avisynth+ and DGDecNV, then you have DGSharpen(), which is a very fast CUDA implementation with functionality like LSFmod. It works in 8 or 16-bit depth.

You really should get away from all the high-bit-depth hacks, IMHO, and go for native support.

Thanks for letting me know about DGSharpen; I'll definitely check it out. As for the hacks I know that you're right, but when I began trying to learn AviSynth some years ago I tested a dozen different denoisers and found SMDegrain to be by far the best for my needs and, as far as I know, there isn't yet a version available with native 16-bit support. Please correct me if I'm wrong, though. Also, could you point me to a site (or thread, or any place) where filters-plugins with native support are gathered? Thank you.

videoh

22nd May 2019, 15:14

Thanks for letting me know about DGSharpen; I'll definitely check it out. As for the hacks I know that you're right, but when I began trying to learn AviSynth some years ago I tested a dozen different denoisers and found SMDegrain to be by far the best for my needs and, as far as I know, there isn't yet a version available with native 16-bit support. Please correct me if I'm wrong, though. Also, could you point me to a site (or thread, or any place) where filters-plugins with native support are gathered? Thank you. Hard to say you are wrong about what you find best, although I am a little confused why you are comparing a denoiser to a sharpener. I'm not aware of any gathering like you mentioned.

real.finder

22nd May 2019, 17:26

like videoh said, go for native HBD

SMDegrain already work with native HBD in many settings included the Default setting for now, other settings waiting for updates for dll's to support HBD, LSFmod work with HBD too

and aside form that, aWarpSharp4 link is not last update, the last one in my signature

LouieChuckyMerry

23rd May 2019, 02:35

Hard to say you are wrong about what you find best, although I am a little confused why you are comparing a denoiser to a sharpener. I'm not aware of any gathering like you mentioned.

Sorry for the confusion. I wasn't comparing a denoiser to a sharpener, just lamenting the fact that SMDegrain doesn't natively support high bit depth (although real.finder's below post gives me great hope). I'll certainly add DGSharpen to my toolbag, though, and in native high bit depth (which I should find time to understand better). Thanks again :) .

like videoh said, go for native HBD

SMDegrain already work with native HBD in many settings included the Default setting for now, other settings waiting for updates for dll's to support HBD, LSFmod work with HBD too

and aside form that, aWarpSharp4 link is not last update, the last one in my signature

Thank you for the information :) . Would my usual SMDegrain call:

SMDegrain(TR=3,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)

work with native HDB? I'll update my aWarpSharp4 and check out LSFMod. How does LSFMod compare to FastLineDarkenMod?

videoh

23rd May 2019, 02:46

Thanks for the clarification, LCM. It's all clear to me now. Good luck for your projects! You're in good hands with real.finder.

real.finder

23rd May 2019, 14:29

Thank you for the information :) . Would my usual SMDegrain call:

SMDegrain(TR=3,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)

work with native HDB?

you need to remove ,LSB=True,LSB_Out=True first since they are for lsb hack

there are many ways, the standard way is just use the SMDegrain with any avs+ HBD

ConvertBits(16) #if your source not HBD already
SMDegrain(tr=4,thSAD=600,contrasharp=false,refinemotion=false,truemotion=true,plane=4)
ConvertBits(8,dither=1) #if you want to get back to 8bit

but this way not as fast as lsb one, why? pinterf and I already talk about this many times in both MVTools-pfmod (https://forum.doom9.org/showthread.php?t=173356) and real.finder's Avisynth Stuff (https://forum.doom9.org/showthread.php?t=174121) replies

so back then pinterf came with another method (https://forum.doom9.org/showthread.php?p=1826390#post1826390)

with SMDegrain it will be like this

#8bit source
c=last

SMDegrain(globals=3,tr=4,PreFilter=4)
global fv1 = fv1.MScalevect(bits=16)
global fv2 = fv2.MScalevect(bits=16)
global fv3 = fv3.MScalevect(bits=16)
global fv4 = fv4.MScalevect(bits=16)
global bv1 = bv1.MScalevect(bits=16)
global bv2 = bv2.MScalevect(bits=16)
global bv3 = bv3.MScalevect(bits=16)
global bv4 = bv4.MScalevect(bits=16)

c
ConvertBits(16)
SMDegrain(globals=1,tr=4,thSAD=600,contrasharp=false,refinemotion=false,truemotion=true,plane=4)
ConvertBits(8,dither=1)

which is faster but still not fast as lsb one, and there are another implementation (https://forum.doom9.org/showthread.php?p=1827085#post1827085) for it

then for more speed pinterf allow MDegrainX passing 8/16/32bit clip and super with 8bit vectors https://forum.doom9.org/showthread.php?p=1834939#post1834939

simply just use SMDegrain with HBD but with 8bit prefilter, but it's still not fast enough https://forum.doom9.org/showthread.php?p=1835018#post1835018

so the last one is using n16=True,n16_Out=True instead of lsb and you will get native 16 HBD clip from your 8bit source with more speed than lsb without hacks

but keep in mind that even if n16 is lsb alternative, it not 100% same (https://forum.doom9.org/showthread.php?p=1837161#post1837161)

LouieChuckyMerry

26th May 2019, 17:52

Thank you so much for the information, real.finder :) .

I finally had some time to test things. I've updated all necessary plugins-filters and am using the latest AviSynth+, but I'm struggling to solve the riddle. Here's my original script:

DGIndexNV INFORMATION HERE
### Deinterlace ###
TFM(Mode=7,UBSCO=False)
### Color Conversion ###
ColorMatrix(Mode="Rec.601->Rec.709")
### Adjust Color ###
MergeChroma(aWarpSharp2(Depth=16))
### Crop ###
Crop(8,0,-8,0)
### Fix Frame Borders ###
BorderControl(YTS=1,YTSF=1,YBS=1,YBSF=1)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor").Blur(1.0)
MT_Merge(Minblur(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,LSB=True,LSB_Out=True)
### Resize ###
NNEDI3_Resize16(Target_Width=960,Target_Height=720,Mixed=True,ThR=1.0,Elast=1.5,NNS=4,Qual=2,EType=0,PScrn=4,Threads=0,Kernel_D="Spline",Kernel_U="Spline",Taps=6,F_D=1.0,F_U=2.0,Sharp=0,LSB_In=True,LSB=True)
aWarpSharp4xx(Depth=5,LSB=True)
### Darken-Thin Lines ###
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod4(Strength=24,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=8,Chroma=2)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
### Deband ###
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=1,Input_Depth=16,Output_Mode=1,Output_Depth=16)
## Trim()
# SelectRangeEvery(1000,66)
ConvertFromStacked

To test I started with a default SMDegrain call:

DGIndexNV INFORMATION HERE
SMDegrain(n16=True,n16_Out=True)

which output proper, if interlaced, video. Then I inserted the 8-bit lines:

DGIndexNV INFORMATION HERE
### Deinterlace ###
TFM(Mode=7,UBSCO=False)
### Color Conversion ###
ColorMatrix(Mode="Rec.601->Rec.709")
### Adjust Color ###
MergeChroma(aWarpSharp2(Depth=16))
### Crop ###
Crop(8,0,-8,0)
### Fix Frame Borders ###
BorderControl(YTS=1,YTSF=1,YBS=1,YBSF=1)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor").Blur(1.0)
MT_Merge(Minblur(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(n16=True,n16_Out=True)

which outputs proper deinterlaced video. The trouble begins when I try to resize:

DGIndexNV INFORMATION HERE
### Deinterlace ###
TFM(Mode=7,UBSCO=False)
### Color Conversion ###
ColorMatrix(Mode="Rec.601->Rec.709")
### Adjust Color ###
MergeChroma(aWarpSharp2(Depth=16))
### Crop ###
Crop(8,0,-8,0)
### Fix Frame Borders ###
BorderControl(YTS=1,YTSF=1,YBS=1,YBSF=1)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor").Blur(1.0)
MT_Merge(Minblur(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(n16=True,n16_Out=True)
### Resize ###
NNEDI3_Resize16(Target_Width=960,Target_Height=720,Mixed=True,ThR=1.0,Elast=1.5,NNS=4,Qual=2,EType=0,PScrn=4,Threads=0,Kernel_D="Spline",Kernel_U="Spline",Taps=6,F_D=1.0,F_U=2.0,Sharp=0,LSB_In=True,LSB=True)
aWarpSharp4xx(Depth=5,LSB=True)

I receive the error message "needi3_resize16: only accept Y8, YV12, YV16, YV24 input". If I add "ConvertToYV16()" after the SMDegrain call, then I still receive the same error message. I've searched a lot and tried many things--to many to actually remember them all--but I can't find a solution. Thanks for any help.

videoh

26th May 2019, 18:45

Temporally replace the last two lines with Info() to see what color space the SMDegrain call is delivering.

LouieChuckyMerry

27th May 2019, 02:57

Temporally replace the last two lines with Info() to see what color space the SMDegrain call is delivering.

That's so cool. As I was trying to find a solution I, literally, wondered how to know what colorspace SMDegrain was outputing. And the answer is "ColorSpace: YUV420P16, BitsPerComponent: 16". A screenshot (http://www.mediafire.com/file/aydabb5yf8fqu8a/S1.E1-[PAL]-TrimTest[SMD%28n16%29][Info].7z).

Groucho2004

27th May 2019, 03:18

As I was trying to find a solution I, literally, wondered how to know what colorspace SMDegrain was outputing.Just for reference:
"AVSMeter script -i" will also provide that info.
[Clip info]
Number of frames: 10000000
Length (hh:mm:ss.ms): 111:06:40.000
Frame width: 32
Frame height: 16
Framerate: 25.000 (25/1)
Colorspace: YUV420P16

LouieChuckyMerry

27th May 2019, 16:15

Just for reference:
"AVSMeter script -i" will also provide that info.
[Clip info]
Number of frames: 10000000
Length (hh:mm:ss.ms): 111:06:40.000
Frame width: 32
Frame height: 16
Framerate: 25.000 (25/1)
Colorspace: YUV420P16

Thanks for that, Groucho2004; I actually forgot that I'd added an AVSMeter shortcut to my "Send to" menu. Sadly, my understanding of the Windows cmd line is even less than my understanding of AviSynth. Much much much less. So I can right-click on a script and send it to AVSMeter, but it's going to want to run the whole script. Rather than take the time to make a special script, how would you process "AVSMeter script -i"?

real.finder

27th May 2019, 16:24

DGIndexNV INFORMATION HERE
### Deinterlace ###
TFM(Mode=7,UBSCO=False)
### Color Conversion ###
ColorMatrix(Mode="Rec.601->Rec.709")
### Adjust Color ###
MergeChroma(aWarpSharp2(Depth=16))
### Crop ###
Crop(8,0,-8,0)
### Fix Frame Borders ###
BorderControl(YTS=1,YTSF=1,YBS=1,YBSF=1)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor").Blur(1.0)
MT_Merge(Minblur(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(n16=True,n16_Out=True)
### Resize ###
NNEDI3_Resize16(Target_Width=960,Target_Height=720,Mixed=True,ThR=1.0,Elast=1.5,NNS=4,Qual=2,EType=0,PScrn=4,Threads=0,Kernel_D="Spline",Kernel_U="Spline",Taps=6,F_D=1.0,F_U=2.0,Sharp=0,LSB_In=True,LSB=True)
aWarpSharp4xx(Depth=5,LSB=True)

I receive the error message "needi3_resize16: only accept Y8, YV12, YV16, YV24 input". If I add "ConvertToYV16()" after the SMDegrain call, then I still receive the same error message. I've searched a lot and tried many things--too many to actually remember them all--but I can't find a solution. Thanks for any help.

P.S.--Sorry about the width of the post; this happens sometimes and I'm not sure why :( .

you must not use any lsb filter with HBD, look for alternative filters (or updated ver.) that work with HBD, if you didn't find then you can use this http://avisynth.nl/index.php/ConvertStacked

LouieChuckyMerry

27th May 2019, 16:41

you must not use any lsb filter with HBD, look for alternative filters (or updated ver.) that work with HBD, if you didn't find then you can use this http://avisynth.nl/index.php/ConvertStacked

Which filter is LSB? I thought that the latest SMDegrain with "n16=True,n16_Out=True" was OK:

so the last one is using n16=True,n16_Out=True instead of lsb and you will get native 16 HBD clip from your 8bit source with more speed than lsb without hacks

real.finder

27th May 2019, 17:59

Which filter is LSB? I thought that the latest SMDegrain with "n16=True,n16_Out=True" was OK:

the problem in the next filters, NNEDI3_Resize16 and aWarpSharp4xx (but this one work with both since I did update it, did also some update to NNEDI3_Resize16 but not for HBD since I chose edi_rpow2)

LouieChuckyMerry

27th May 2019, 18:19

Ahhh, I didn't realize NNEDI3_Resize16 was such, thanks for the information (and for updating aWarpSharp4xx). Do you have a recommendation for a resizer that works in native HBD? And, would this then be the correct way to work with SMDegrain-NNEDI3_Resize16:

### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,LSB=True,LSB_Out=True)
### Resize ###
NNEDI3_Resize16(Target_Width=960,Target_Height=720,Mixed=True,ThR=1.0,Elast=1.5,NNS=4,Qual=2,EType=0,PScrn=4,Threads=0,Kernel_D="Spline",Kernel_U="Spline",Taps=6,F_D=1.0,F_U=2.0,Sharp=0,LSB_In=True,LSB=True)
aWarpSharp4xx(Depth=5,LSB=True)
### Darken-Thin Lines ###
FastLineDarkenMod4(Strength=24,Prot=6) # Is this working in 16-bits? I couldn't find any info on LSB for FastLineDarkenMod4.
aWarpSharp4xx(Blur=4,Type=1,Depth=8,Chroma=2)
### Deband ###
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=1,Input_Depth=16,Output_Mode=1,Output_Depth=16)
Trim(17666,17777)
# SelectRangeEvery(1000,66)
ConvertFromStacked

Thanks again for your time :) .

Groucho2004

27th May 2019, 18:48

Rather than take the time to make a special script, how would you process "AVSMeter script -i"?Add "-i" to your "Target" in the shortcut properties and change the AVSMeter.ini setting "PauseBeforeExit=0" to "PauseBeforeExit=1".

real.finder

27th May 2019, 22:26

Ahhh, I didn't realize NNEDI3_Resize16 was such, thanks for the information (and for updating aWarpSharp4xx). Do you have a recommendation for a resizer that works in native HBD?
.

edi_rpow2 is like NNEDI3_Resize16 but it work with HBD

And, would this then be the correct way to work with SMDegrain-NNEDI3_Resize16:

### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,LSB=True,LSB_Out=True)
### Resize ###
NNEDI3_Resize16(Target_Width=960,Target_Height=720,Mixed=True,ThR=1.0,Elast=1.5,NNS=4,Qual=2,EType=0,PScrn=4,Threads=0,Kernel_D="Spline",Kernel_U="Spline",Taps=6,F_D=1.0,F_U=2.0,Sharp=0,LSB_In=True,LSB=True)
aWarpSharp4xx(Depth=5,LSB=True)
### Darken-Thin Lines ###
FastLineDarkenMod4(Strength=24,Prot=6) # Is this working in 16-bits? I couldn't find any info on LSB for FastLineDarkenMod4.
aWarpSharp4xx(Blur=4,Type=1,Depth=8,Chroma=2)
### Deband ###
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=1,Input_Depth=16,Output_Mode=1,Output_Depth=16)
Trim(17666,17777)
# SelectRangeEvery(1000,66)
ConvertFromStacked

Thanks again for your time :) .

FastLineDarkenMod4 work with HBD, for F3KDB see this (https://forum.doom9.org/showthread.php?p=1864929&highlight=F3KDB#post1864929)

LouieChuckyMerry

28th May 2019, 05:28

Add "-i" to your "Target" in the shortcut properties and change the AVSMeter.ini setting "PauseBeforeExit=0" to "PauseBeforeExit=1".

Thank you. I've always had "PauseBeforeExit=1" set--I need time to read ;) --but never would've conceived of adding "-i" to the shortcut properties "Target", which works perfectly.

edi_rpow2 is like NNEDI3_Resize16 but it work with HBD

Ooh wee! Getting EDI_RPow2 to work took some effort, and thanks for the challenge. I received a couple error messages about "what 'color_gray' means"--I've attached snips in order of appearance (http://www.mediafire.com/file/lo391zm39jh8o9o/EDI_RPow2ErrorMessages.7z/file)--and after hashing out (#) the offensive lines in ResizeX.avsi and EDI_RPow2.avsi I was eventually, I think, because "ConvertFromStacked" and my x264 custom cmd line "--demuxer raw --input-depth 16 --sar 1:1" were no longer necessary, able to send native 16-bit video to 10-bit x264 with this script:

### Deinterlace ###
TFM(Mode=7,UBSCO=False)
### Color Conversion ###
ColorMatrix(Mode="Rec.601->Rec.709")
### Adjust Color ###
MergeChroma(aWarpSharp2(Depth=16))
### Crop ###
Crop(8,0,-8,0)
### Fix Frame Borders ###
BorderControl(YTS=1,YTSF=1,YBS=1,YBSF=1)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor").Blur(1.0)
MT_Merge(Minblur(),Mask,Luma=True)
### Overall Temporal Denoise ###
# SMDegrain(n16=True,n16_Out=True)
SMDegrain(n16=True,n16_Out=True)
### Resize ###
EDI_RPow2(CShift="Spline64Resize",FWidth=960,FHeight=720)
aWarpSharp4xx(Depth=5)
### Darken-Thin Lines ###
FastLineDarkenMod4(Strength=24,Prot=6)
aWarpSharp4xx(Blur=4,Type=1,Depth=8,Chroma=2)
### Deband ###
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=2,Input_Depth=16,Output_Mode=2,Output_Depth=16)

Now I need to fine-tune my native HBD SMDegrain call....

FastLineDarkenMod4 work with HBD, for F3KDB see this (https://forum.doom9.org/showthread.php?p=1864929&highlight=F3KDB#post1864929)

Thanks for the reminder. Changing the input and output modes from 1 to 2 made it work correctly.

StainlessS

28th May 2019, 12:50

Color_Gray ($808080) comes from the avisynth default supplied colors_rgb.avsi file which should be in plugins.
(I usually remove from there unless I need it).

Colors_rgb.avsi Demo:- https://forum.doom9.org/showthread.php?p=1741775#post1741775
https://dl.dropboxusercontent.com/s/akrph1tq1tszmsi/hexyuv.gif

LouieChuckyMerry

28th May 2019, 14:41

I'd ignorantly removed the Colors_RGB.avsi from my Plugins folder years ago. After digging up a copy and running a quick test, all is well with unedited versions of ResizeX and Edi_RPow2. Thanks StainlessS :thanks:

real.finder

28th May 2019, 14:45

Thanks for the reminder. Changing the input and output modes from 1 to 2 made it work correctly.

you need also ConvertToDoubleWidth() ConvertFromDoubleWidth() to made it work correctly

edit: I did some changes to the wiki http://avisynth.nl/index.php/ConvertStacked

StainlessS

28th May 2019, 17:42

LCM, Older version of Colors_rgb.avsi had two entries for Color_PaleGoldenrod, in graphic above, is in 11th page after Gray set, in third and forth rows.
I discovered it after doing the avs to create animated GIF, and whilst watching it.
If you are using old version script, then maybe yours has the double entry, no real problem if it does.

LouieChuckyMerry

28th May 2019, 19:24

you need also ConvertToDoubleWidth() ConvertFromDoubleWidth() to made it work correctly

edit: I did some changes to the wiki http://avisynth.nl/index.php/ConvertStacked

Ahhh, thanks for that :) .

I've had some time to tweak my SMDegrain settings with "n16=True,n16_Out=True" and have gotten everything to work but "ContraSharp=True". This runs fine:

SMDegrain(TR=2,ThSAD=200,ContraSharp=False,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,n16=True,n16_Out=True)

but this:

SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,n16=True,n16_Out=True)

gives the error message:

Both clips should have the same colorspace!
([File Path]...SMDegrainMod_rf_3.1.2.101s.avsi, Line 591)
([File Path]...SMDegrainMod_rf_3.1.2.101s.avsi, Line 545)
([File Path]...TrimTest.avs Line 18)

Line 591: ssDD = ssD.repair(HD?ssD.repair(allD,1,planar=planar):allD,HD?12:1,planar=planar) # Limit the difference to the max of what the denoising removed locally.

Line 545: lsb_out ? StackVertical (last, BlankClip (last, pixel_type=type, color_yuv=0,length=1)) : last""")}

LCM, Older version of Colors_rgb.avsi had two entries for Color_PaleGoldenrod, in graphic above, is in 11th page after Gray set, in third and forth rows.
I discovered it after doing the avs to create animated GIF, and whilst watching it.
If you are using old version script, then maybe yours has the double entry, no real problem if it does.

As far as I can tell it's from 8 July 2005 and it does, in fact, have two "global color_palegoldenrod = $EEE8AA" entries, lines 110 and 111. Well, had...

real.finder

28th May 2019, 21:09

Ahhh, thanks for that :) .

I've had some time to tweak my SMDegrain settings with "n16=True,n16_Out=True" and have gotten everything to work but "ContraSharp=True". This runs fine:

SMDegrain(TR=2,ThSAD=200,ContraSharp=False,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,n16=True,n16_Out=True)

but this:

SMDegrain(TR=2,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,n16=True,n16_Out=True)

gives the error message:

Line 591:

Line 545:

try this https://pastebin.com/1HUc33kX

not 100% sure about it, will wait for the answer of this (https://forum.doom9.org/showthread.php?p=1875572#post1875572)

LouieChuckyMerry

28th May 2019, 23:27

It works fine, :thanks: .

StvG

29th May 2019, 05:55

you need also ConvertToDoubleWidth() ConvertFromDoubleWidth() to made it work correctly

edit: I did some changes to the wiki http://avisynth.nl/index.php/ConvertStacked
Both ConvertToStacked() and ConvertToDoubleWidth() need 16-bit input video. So:## 10bit clip here
ConvertToDoubleWidth()
F3KDB(Input_Mode=2,Input_Depth=10,Output_Mode=2,Output_Depth=10)
ConvertFromDoubleWidth(bits=10)should be ## 10bit clip here
ConvertBits16()
ConvertToDoubleWidth()
F3KDB(Input_Mode=2,Input_Depth=16,Output_Mode=2,Output_Depth=10)
ConvertFromDoubleWidth(bits=10)

LouieChuckyMerry

29th May 2019, 13:52

StvG: If input is 16-bit, then would

ConvertToDoubleWidth()
F3KDB(Input_Mode=2,Output_Mode=2)
ConvertFromDoubleWidth()

be correct?

LouieChuckyMerry

29th May 2019, 14:21

real.finder: I was wanting to compare my 16-bit native HBD script with it's 16-bit LSB counterpart, but encountered a problem.

Using the latest SMDegrain (it also happens with the "fixed" version from your last post, so I don't think that's the problem), latest NNEDI_Resize16, and latest EDI_RPow2, this scipt:

SMDegrain(LSB=True,LSB_Out=True)
NNEDI3_Resize16(Target_Width=960,Target_Height=720,LSB_In=True,LSB=True)
ConvertFromStacked

outputs proper 960x720 video. However, this script

SMDegrain(LSB=True,LSB_Out=True)
EDI_RPow2(CShift="Spline",FWidth=960,FHeight=720,LSB=True,LSB_Out=True)
ConvertFromStacked

outputs 960x720 video that's still stacked, with the top half stretched out proper video and the bottom half green-acid-flashback.

I'm probably doing something wrong, but I read the EDI_RPow2 .avsi and I think the LSB calls are correct.

real.finder

29th May 2019, 18:20

StvG

29th May 2019, 18:32

StvG: If input is 16-bit, then would

ConvertToDoubleWidth()
F3KDB(Input_Mode=2,Output_Mode=2)
ConvertFromDoubleWidth()

be correct?

Yes, If you want 16-bit output.

real.finder, in wiki input_depth=10 should be input_depth=16 or it can be omitted (input_depth=16 is default).

real.finder

29th May 2019, 18:48

real.finder, in wiki input_depth=10 should be input_depth=16 or it can be omitted (input_depth=16 is default).

I fix it with faster way

StvG

30th May 2019, 04:50

Thanks.

LouieChuckyMerry

30th May 2019, 22:35

EDI_RPow2 don't has lsb_in that why, and that why using lsb hack is so annoying and you should avoid it, that aside from most lsb_in things are not real 16bit

OK, thanks, I must've misunderstood the .avsi.

Yes, If you want 16-bit output.

I do want 16-bit output (I should've indicated that when I asked my question), thank you very much for your answer :) .

jpsdr

1st June 2019, 11:58

Going back to original topic after some long off-topic... (from what i've seen, it's been a lot of post not related anymore to the thread topic... :D).
New version, see first post.

LouieChuckyMerry

2nd June 2019, 16:49

Going back to original topic after some long off-topic... (from what i've seen, it's been a lot of post not related anymore to the thread topic... :D).
New version, see first post.

Sorry about that, jpsdr :o . Thanks for the update :thanks:

StainlessS

2nd June 2019, 16:52

Sorry about that, jpsdr :o . Thanks for the update :thanks:

What he said +1,
Thanks also LCM, I missed the update post.

real.finder

3rd June 2019, 00:12

Going back to original topic after some long off-topic... (from what i've seen, it's been a lot of post not related anymore to the thread topic... :D).
New version, see first post.

:thanks:

and I suggest Moderators move those posts to my Thread http://forum.doom9.org/showthread.php?t=174121

Taurus

4th June 2019, 19:04

Let me chime in...
Thanks for the update, jpsdr!
:thanks:

Forteen88

5th June 2019, 11:09

Thanks!
Change list:
30/05/2018 v0.9.4.52

Shouldn't it be the year 2019?!

jpsdr

6th June 2019, 09:32

Yes, i've noticed it for the readme, forget the first page here.

jpsdr

7th June 2019, 11:59

New version, see first post.

StainlessS

7th June 2019, 12:07

OOOooooh lovely, thanks again.

jpsdr

28th April 2020, 23:41

New version, see first post.

ChaosKing

30th April 2020, 10:05

Hmm the link works on the first page, but there is no binary linked in the latest release on github?
https://github.com/jpsdr/NNEDI3/releases

jpsdr

30th April 2020, 10:11

It seems that something gone wrong with github when i've uploaded the binary, but i didn't notice. It should be fine now.

mp3dom

4th May 2020, 17:54

Am I the only one to have problems with the latest version (.54)? Especially with qtgmc, I get lots of black frames at the end of a video (that doesn't have black frames) that I'm going to deinterlace, and lots of ghosting. Keeping all the other plugins the same (mvtools, masktools) and reverting back to version .53 seems to fix everything.

Edit: Ok, I'm not the only one... It's exactly this:
https://forum.doom9.org/showthread.php?p=1910416#post1910416

jpsdr

5th May 2020, 19:36

New version, see first post, should be fixed.

jpsdr

22nd July 2020, 06:09

New version, see first post.

jpsdr

2nd August 2020, 08:49

New version, see first post.

jpsdr

30th April 2021, 15:27

New version, see first post.

StainlessS

30th April 2021, 16:20

Cheers jpsdr :)

kedautinh12

5th May 2021, 00:50

I wonder why do you add avx and avx2 in one w7 ver and use parameter opt=0 (auto detect) with all your plugins??

jpsdr

5th May 2021, 16:47

It's the instruction set the compiler is configured with, but build the same code. Will not make a specific code for each specific instruction set of the compiler. The same code is just build with different cpu instruction set.

jpsdr

20th July 2021, 18:09

New version, see first post.

FranceBB

20th July 2021, 22:08

Thanks! I'll let you know how it behaves on the 56c/112th Xeon! :D

servese43

23rd July 2021, 09:28

Hi everyone,
How difficult would it be to port NNEDI3 to linux for use with Avisynth+? (already know there's a vapoursynth port but I'd like to use avisynth+ for its multithreading and audio support.)

Edit: Never mind. Just around the time I posted this it was announced that audio support has been added to vapoursynth anyway.

jpsdr

23rd February 2022, 18:45

Finaly sooner than expected, new version, see first post.

tormento

3rd May 2022, 23:43

Finaly sooner than expected, new version, see first post.
I am getting interested into neural resizing.

What about incorporating OpenCL code (https://forum.doom9.org/showthread.php?t=169766)?

AFAIK madVR too uses a OpenCL version of it.

Perhaps even VS version (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-NNEDI3CL) could be of some help.

jpsdr

4th May 2022, 17:48

Sorry, not interested in learning and doing OpenCL.

StainlessS

18th October 2022, 22:48

Is there any known workaround for this error,
"nnedi3: Error with the Threadpool while getting UserID!"
nnedi3_rpow2 is being called quite a few times (previous successful was 127th call EDIT: Actually 128th call, index was 0 relative).

EDIT: Used in my DBSC script [just added nnedi3 to it], is called once for each scene cut, so can be called many times.
EDIT: v0.9.4.60. Same problem in v0.9.4.56

Actual code used, (_W_ and _H_ will be altered to actual size)

Resizer=Default(Resizer,"""nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=_W_,fheight=_H_)""") # Resizer to use

The total count for clip I'm procesing is 873 scene cuts. (about 55 mins clip)

I guess its not a big deal if cannot be fixed, can go back to previous resizer, ie

Resizer=Default(Resizer,"Spline36Resize(_W_,_H_)") # Resizer to use

EDIT: 873 scene cuts.

00009214 1.42599630 DBSC_DynaSplice: 0) Start=0 End=284 Length=285 Crop( 11, 2,696,572) WWR=-13 HHR=-2
00009215 1.50341260 DBSC_DynaSplice: 1) Start=285 End=301 Length=17 Crop( 11, 2,696,572) WWR=-13 HHR=-2
00009216 1.50465596 DBSC_DynaSplice: 2) Start=302 End=313 Length=12 Crop( 11, 2,696,572) WWR=-13 HHR=-2

# ...

00010084 42.17188644 DBSC_DynaSplice: 870) Start=86687 End=86823 Length=137 Crop( 11, 2,696,570) WWR=-13 HHR=-4
00010085 42.22408295 DBSC_DynaSplice: 871) Start=86824 End=86951 Length=128 Crop( 16, 4,684,568) WWR=-20 HHR=-4
00010086 42.27487183 DBSC_DynaSplice: 872) Start=86952 End=87350 Length=399 Crop( 11, 2,696,572) WWR=-13 HHR=-2

jpsdr

19th October 2022, 18:32

This message is at the constructor of nnedi3, it faills probably because you reached the limit of 2000 users...
Quick fix, you can rebuild increasing MAX_USERS in ThreadPoolDef.h.
I'll put in my todo list to change some static size arrays with the <vector> class in my threadpool... ;)
It will remove several possible limits, but it will take time, so, not for soon.

StainlessS

19th October 2022, 20:01

No sweat right now, I've gone back to Spline36Resize.
I'll keep my eyes out for updates and re-try again later.

Thanks.

jpsdr

20th October 2022, 18:36

I'll probably during my holydays next week take the time to make new build increasing the number of max users.
Do you know at how many scene cuts it fails ? Is it 128 to 873 ? (Meaning you need at lest 8 times more users possibles ?)

StainlessS

20th October 2022, 20:57

Fails at cut 128, 873 is from when I went back to ordinary Spline36Resize().
Last frame for that clip (bout 55 mins) was about 87,000, so a movie could easily have many more cuts than that [eg Cleopatra, Lizzy Taylor, Dickie Burton].

Enjoy your holiday, no urgency here :)

jpsdr

21st October 2022, 19:15

Are you using the jpsdr.dll package with all the filters, or are you using just nnedi3.dll ?

StainlessS

22nd October 2022, 03:52

or are you using just nnedi3.dll
Just nnedi3.dll,
(I think I may have full package somewhere, but not installed, in a MASSIVE folder of things I gotta do/install/test/plusmore, it goes back years and years :( ).

jpsdr

23rd October 2022, 14:16

Ah, ok... If you where using the whole package AND several of my filters, you'll reach the user limit sooner as there is only one threadpool for everyone (but it's the purpose to avoid creating a lot of thread), and using the dll of each filter instead, each filter having its onw threadpool, the limit is reached leater because there is one threadpool/filter, and the limit is by threadpool, but it will produce more threads.

StainlessS

23rd October 2022, 15:08

In DBSC script, I am usually quite happy to use Spline36Resize(), however for a particular case I wanted to use Nnedi3.
We find scene cuts and for each one, trim() and find current border and crop it, then resize that to input size (only a bit bigger).
However, for this job I also was wanting to resize to 1:1 SAR at some later point (after DBSC) so thought maybe best to do a single resize
inside of the DBSC script instead of having two upsize steps.
(Src = DVD PAL 4:3, resize wider for 1:1 SAR, eg 768x576)

Spline36Resize is ok for the smaller upsize, I guess a man on a galloping horse could not spot the difference. :)

agressiv

31st October 2022, 03:06

I'm having corruption using nnedi_rpow2 when any sort of Prefetch command is enabled on my 16-core Ryzen 5950x. My 6-core Intel never has a problem no matter what I set Prefetch to.

* Symptom: Stuttering/sync loss for an encode (first 30 frames or so - basically about 5-10 frames will "repeat" themselves
* Remove nnedi_rpow2, problem never occurs
* Tried removing all other filters
* Even setting AVS Prefetch to "2" has same behavior.
* Tried combinations of threads=1, prefetch=1 etc in the nnedi_rpow2 parameters
* Tried changing to MT_SERIALIZED, MT_NICE_FILTER, no effect
* If I remove Prefetch from the Avisynth script itself, it works fine (but obviously much slower because I'm using McDegrainSharp as well)

I'm not sure if it's the high core count or just AMD itself, anyone else ever see this?

Edit: AviSynth+ 3.7.2 64-bit

Boulder

31st October 2022, 06:32

FranceBB

31st October 2022, 06:42

Just FYI, the whole point of having plugins_JPSDR.dll is for them to create their own optimised and multithreaded theadpool. TL;DR you guys don't really need Prefetch() with Jean Philippe's plugins. Heck, you'll get better performances without it than with it. ;)

agressiv

31st October 2022, 14:20

Thanks! This RequestLinear() bit seems to fix it. I'll mess with it some more.

I'd love to not have to use Prefetch at all, but most of the MvTools (McDegrainSharp) stuff needs it or it's a huge performance hit - unless you know of a way around that?

FranceBB

31st October 2022, 14:49

most of the MvTools (McDegrainSharp) stuff needs it or it's a huge performance hit - unless you know of a way around that?

Unfortunately there's no way around MVTools.
There used to be a way with avstp.dll but it ended up being buggy and causing freezes, so now that it has been removed, MVTools will run single-threaded unless you use Prefetch, which is really a shame...
Ferenc is trying to fix it, but none of us seem to understand what is going on... (and if even the Supreme Grandmaster Ferenc Pinter can't properly get what's causing it, no one can).

Here: https://github.com/pinterf/mvtools/issues/46

kedautinh12

31st October 2022, 15:00

Maybe next gen handsome FranceBB can :D

StainlessS

31st October 2022, 15:06

I dont have problems using nnedi_rpow2("Spline36Resize") and McDegrainSharp(). [maybe a bit stutter on start only in player <eg VD2>, not encode]
I do use SetMTMode.avsi in Plugins.

last few lines

#########################################
# Filters from MVTools v2.6.0.5 (from http://forum.doom9.org/showthread.php?p=1386559#post1386559 ) Tested On 2016/03/06
SetFilterMTMode("MSuper", MT_MULTI_INSTANCE)
SetFilterMTMode("MAnalyse", MT_MULTI_INSTANCE)
SetFilterMTMode("MFlowFps", MT_MULTI_INSTANCE)
SetFilterMTMode("MRecalculate", MT_MULTI_INSTANCE)
#########################################
#Filters from EEDI2 v0.9.2 (from http://forum.doom9.org/showthread.php?t=173238 ) Tested On 2016/03/06
SetFilterMTMode("EEDI2", MT_MULTI_INSTANCE)

########################################
SetFilterMTMode("MPP_SharedMemoryClient", 2) # real.finder
SetFilterMTMode("MPP_SharedMemoryServer", 3) # real.finder

########################################
SetFilterMTMode("RoboCrop", MT_SERIALIZED) # ADDED by me (always used close to source filter)
SetFilterMTMode("AutoLevels", MT_SERIALIZED)

#########################################
#keep it the last line please
if (FunctionExists("avstp_set_threads")) {
# this isn't actually optimal, because it will also disable avstp threads if running
# on a single-threaded filter chain
avstp_set_threads(0, 1) #disable threading in dither
}

However, in my usual render script I detect if upsize [where we would use nnedi_rpow2] and also McDegrainSharp, and if so then
I use McDegrainSharp before upsize and after Spline36Resize if downsizing.

EDIT:
In my SetMTMode.avsi there is this line below [but no entry for nnedi_rpow2()]

SetFilterMTMode("NNEDI3", MT_MULTI_INSTANCE)

EDIT: "in my usual render script",
a BIG script function that takes a LOT of Global vars [with defaults if not existing] to configure the outcome.
We use Avisynthesizer_Mod / DGIndex / DGIndexNV templates to create scripts with default config Globals, and tweak
a few globals where required.

EDIT:
First few lines of a DGIndex / DGIndxNV template (can work Ok for both dgindex and dgindexNV)

#ASYNTHER Progressive_169_Robo

VideoFileName ="__vid__"
AudioFileName =LCase("__aud__")
AudioDelay =Value("__del__")

###############

vExt = GetFilenameExtension(VideoFileName)

If(vExt == ".dgi") { DGSource(VideoFileName) } # DGIndexNV
Else { Mpeg2Source(VideoFileName).TFM(d2v=VideoFileName) } # DGIndex : Auto check via TFM illegal transitions

AudioExt = GetFilenameExtension(AudioFileName)

Audio= (AudioExt==".ac3") ? NICAC3Source(AudioFileName,channels=2,DRC=0)
\ : (AudioExt==".mpa"||AudioExt=="mp1"||AudioExt==".mp2"||AudioExt==".mp3") ? NicMPG123Source(AudioFileName,Normalize=False)
\ : (AudioExt==".wav") ? RaWavSource(AudioFileName)
\ : (AudioExt==".dts") ? NicDTSSource(AudioFileName)
\ : (AudioExt==".w64") ? RaWavSource(AudioFileName,samplerate=6)
\ : 0

Assert(!isInt(Audio),"NO AUDIO")

(!isInt(Audio)) ? AudioDub(Audio).DelayAudio(AudioDelay).Trim(0,0) : NOP # Trim, chop/add audio to length

(!isInt(Audio) && AudioRate() <> 44100) ? ResampleAudio(44100) : NOP

#AssumeTFF # not needed, both DGIndexNV and DGIndex set field order
#ConvertToYV24(Interlaced=False) # Optional

###########################
#Return last
###########################

### Status
Global G_FILECOUNT=1

### Debugging
Global G_DEBUG=True

### DeBlock(G_DEBLOCK)
Global G_DEBLOCK=0 # Debloock setting

### QueryBorderCrop AND AutoContrast
Global G_SAMPLES=40

### QueryBorderCrop
Global G_QBC=True # Switch On Border Cropping
Global G_QBC_THRESH=-40.0 Global G_QBC_IGNORE = 0.2
Global G_QBC_LEFTADD=0 Global G_QBC_TOPADD=0 Global G_QBC_RIGHTADD=0 Global G_QBC_BOTADD=0 # Additional cropping if still some border
Global G_QBC_WMOD=2 Global G_QBC_HMOD=2 # Width/height multiple of these
Global G_QBC_RLBT=$F # Bits left to right, R,L,B,T # Edges to crop
Global G_QBC_LACED=False
Global G_QBC_SHOW=false

### AutoLevels
Global G_AL_AUTOALEVELS=False
Global G_AL_IGNORE_LO = 100.0/512
Global G_AL_IGNORE_HI = G_AL_IGNORE_LO
Global G_AL_RADIUS = 30
Global G_AL_SC2TH = 8
Global G_AL_SC2PERC = 100.0/3
Global G_AL_MINRNG = 110
Global G_AL_INPUTLO = RT_UNDEFINED
Global G_AL_INPUTHI = RT_UNDEFINED
Global G_AL_AUTOGAMMA = 1 # 1 = NO Change, 0=Auto, else Gamma
Global G_AL_MIDPOINT = 0.5
Global G_AL_GAMMAX = 1.5 Global G_AL_GAMMIN=1.0/G_AL_GAMMAX
Global G_AL_BORD_L = 16 Global G_AL_BORD_T=16 Global G_AL_BORD_R=16 Global G_AL_BORD_B=16
Global G_AL_DEBUG = False
Global G_AL_PRELIMITER = True
Global G_AL_MERGE = 0.3