Port of NNEDI under new v2.6 AVS API

[jpsdr]

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]

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]

New version with x64 crash fix, see first post.

[jpsdr]

New version, see first post.

[FranceBB]

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]

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

[FranceBB]

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]

New version, see first post (minor update).

[FranceBB]

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

[jpsdr]

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

[Dreamland]

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]

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]

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]

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

[Groucho2004]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

New version, minor change, see first post.

[yup]

HI all!
Please advise how organizing hi bit upscale?
Plug-in support only 8 bit.
yup.

[FranceBB]

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]

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]

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

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]

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 ?

[edcrfv94]

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]

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.

[edcrfv94]

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]

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]

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]

New version, see first post. AVX path added, so opt parameters values change a little (see the Readme file included in the release).

[`Orum]

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]

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]

New version. Minor change, forgot to add AVX path on planarframe.

[FranceBB]

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]

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]

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]

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]

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]

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]

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.

[DJATOM]

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]

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.