JPSDR Avisynth's plugins pack

[jpsdr]

Merge of Avisynth's plugins

Finaly, the All Might, One for All plugin is out, mergin all the avisynth's plugins i've made.

The main purpose of it is to reduce the number of threads created when you use more than one plugin, as in that case there is only one DLL file, so one threadpool created, instead of using several DLLs, creating several threadpools and so more threads.

Current version: 4.3.1

Merge of :
AutoYUY2: 4.1.12
NNEDI3 (http://forum.doom9.org/showthread.php?t=170083): 0.9.4.68
ResampleMT (http://forum.doom9.org/showthread.php?t=173772)/Desample (http://forum.doom9.org/showthread.php?p=1817097#post1817097): 2.11.1
aWarpSharpMT (http://forum.doom9.org/showthread.php?t=175064): 2.1.12
HDRTools (http://forum.doom9.org/showthread.php?t=175488): 1.2.3
JincResizeMT (http://forum.doom9.org/showthread.php?t=173772): 1.2.0

Sources are here (https://github.com/jpsdr/plugins_JPSDR).
Binaries are here (https://github.com/jpsdr/plugins_JPSDR/releases/download/4.3.1/plugins_JPSDR_v4_3_1.7z).

Version history
4.3.1 : Pinterf's fix for AVX512 compute coeff on ResampleMT.
4.3.0 : Update of ResampleMT with new core code.
4.2.0 : Update of ResampleMT with AVX512 core code.
4.1.0 : Update of JincResizeMT, minor changes (more code refactory) on others filters.
4.0.0 : Add JincResizeMT, minor changes (more code refactory) on others filters.
3.9.0 : Revert added ASM on ResampleMT and some fixes, more ASM AVX512 on HDRTools.
3.8.0 : Add ASM AVX/AVX2/AVX512 on ResampleMT, add ASM AVX512 on HDRTools.
3.7.0 : Update NNEDI3 & HDRTools (add AVX512 code), update ResampleMT (update matrix class).
3.6.0 : Update resampler to new SSE code.
3.5.1 : Update resampler to new AVX2 code.
3.5.0 : Add resamplers last updates (chroma fix and filter parameters coeff new calcul).
3.4.0 : New AVS header and update on resampler and NNEDI3.
3.3.5 : Update to new AVS+ headers and fix awarp colorspace issue.
3.3.4 : Update of resample with DTL pull-request.
3.3.3 : Update to new AVS+ headers.
3.3.2 : Fix the value of a BT.1886 parameter in HDRTools.
3.3.1 : Update on threadpool, no user limit (except memory).
3.3.0 : Update of HDRTools with ACES tonemap.
3.2.8 : Fix on threadpool, using prefetch parameter created hang. Add negative prefetch for triming, read Multithreading.txt or Multithreading chapter here. Fix on resample.
3.2.7 : Fix on awarpsharp, fix on threadpool.
3.2.6 : Fix on resampler, fix on awarpsharp, new resamplers added in nnedi3_rpow2, update avs headers.
3.2.5 : Small fix on resampler and new kernel function.
3.2.4 : New resamplers and also added in nnedi3_rpow2 resizers.
3.2.3 : Fix for nnedi3 and new function in resample.
3.2.2 : Fix issue introduced in nnedi3.
3.2.1 : Fix on aWarpSharpMT, update to new avisynth headers.
3.2.0 : Update to HDRTools 0.6.0 (add of BT2446 A & C methods).
3.1.3 : Update HDRTools (add Crosstalk parameter and EOTF for SDR).
3.1.2 : Minor code change after threadpool update, fix in the number of threads,
fix in resampler to perfectly match avs+ output.
3.1.0 : Update in threadpool, add ThreadLevel parameter.
3.0.0 : Add of HDRTools.
2.2.0 : Update Matrix Class, fix bug in nnedi3 for YUY2, add 16 bits support on AutoYUY2.
2.1.1 : Optimized CPU placement if SetAffinity=true for prefetch>1, SetAffinity back to default false.
2.1.0 : 16 bits aWarpasharp, merge of new resample code, some fixes.
2.0.5 : Fix aWarp/aWarp4 default settings.
2.0.4 : Fix (good this once) crash on aBlur x64.
2.0.3 : Fix crash on aBlur and clarify some aWarp4 modes (aWarpSharpMT part).
2.0.2 : Fix on aWarpSharp and Resample.
2.0.1 : Fix on AutoYUY2.
2.0.0 : Add of aWarpSharpMT, small update on the others.
1.2.1 : Update to ResampleMT v2.0.1, fix in Desample functions.
1.2.0 : Update to ResampleMT v2.0.0 with Desample functions.
1.1.10 : Fix resample issue of doing nothing and fix possible deadlock in threadpool.
1.1.9 : Forgot to add AVX path on planarframe of NNEDI3.
1.1.8 : Fix threadpool, add AVX path in AutoYUY2 and NNEDI3.
1.1.7 : Same minor change an all filters.
1.1.6 : Minor update on threadpool and minor fix on NNEDI3.
1.1.5 : Minor update on threadpool.
1.1.4 : Fix YUYV planarframe NNEDI3 crash.
1.1.3 : Fix NNEDI3 x64 crash.
1.1.2 : Update of NNEDI3, and small fix.
1.1.1 : Update of all plugins (most significant is fix of range issue in ResampleMT).
1.1.0 : "Big" update of NNEDI3, and also update of AutoYUY2.
1.0.1 : Update of NNEDI3 and ResampleMT.
1.0.0 : First release.

For more informations on the changes, check each filter thread.

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

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]

New version.

[ChaosKing]

The main purpose of it is to reduce the number of threads created when you use more than one plugin, as in that case there is only one DLL file, so one threadpool created, instead of using several DLLs, creating several threadpools and so more threads.


That are the benefits, less ram consumption?

[jpsdr]

Exactly it's hard to say, but globaly it will use less resources for the same result.

[ChaosKing]

But only when I use (or load) all of the plugins above, right? Because I don't use the auto load feature, so I will not benefit from it at all?

[jpsdr]

If you're using more than one of my plugins in the same script (for exemple both nnedi3 and ResampleMT) you'll benefit.

[dipje]

thread pools? Really? I see 3 plugins merged in one.. So instead of 3 thread pools I now have one. A thread pool of like, 8 threads on a Core i7? Maybe twice that? so _maybe_ I save 16 to 32 threads or something? Of the 1800+ that are normally running on my system? :P.

That can't be the only reason / benefit of merging plugins, right?

[Groucho2004]

thread pools? Really? I see 3 plugins merged in one.. So instead of 3 thread pools I now have one. A thread pool of like, 8 threads on a Core i7? Maybe twice that? so _maybe_ I save 16 to 32 threads or something? Of the 1800+ that are normally running on my system? :P.

That can't be the only reason / benefit of merging plugins, right?
It would be interesting to see some comparisons, i.e. memory usage, speed, efficiency.

Generally, merging functions into one plugin is OK (see RGTools) but they should be in logical groups. jpsdr's merge seems a bit arbitrary.

[jpsdr]

That can't be the only reason / benefit of merging plugins, right?
In that case, it is. It's not a "function/theme merging" but a "resource merging".
If you have a 10 cores broadwell, each pool will have 20 threads, it can easely explode.
Maybe more noticeable when you're using a dedicated PC video where "nothing else" than avisynth is running... Having maybe less than 1800+ threads in that case.
Anyway, you don't want it, you don't have to take it. Isn't life beautifull ? ;)

[Groucho2004]

Of the 1800+ that are normally running on my system? :P.
Wow, 1800+ threads. I just checked on my system, 260 threads.
Task Manager:
https://s6.postimg.org/cfkdn5t35/Image2.png

[TheFluff]

there is nothing that stops you from sharing thread pools with other plugins over DLL borders, you know
actually doesn't avs+ have its own thread pool built in anyway?

[jpsdr]

there is nothing that stops you from sharing thread pools with other plugins over DLL borders,
Alreay tried, noticeable performance loss, little, but begin to be noticeable.


actually doesn't avs+ have its own thread pool built in anyway?
That will make the filter avs+ compatible only, not an option.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

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

[jpsdr]

New version (update of NNEDI3), see first post.

[jpsdr]

New version (update of NNEDI3), see first post.

[jpsdr]

New version, see first post (minor update).

[jpsdr]

New version, see first post (minor update).

[videoh]

Thank you, jp. Much appreciated!

[jpsdr]

New version, minor change, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

New version, minor change, forgot to add AVX path on planarframe of NNEDI3.

[MysteryX]

I guess the main benefit is having the latest version of NNEDI3! It's hard to know what actually changed when the log says "big" and "small" changes.

btw what about fixing the issues corrected by the EDI_RPOW2 script (http://www.mediafire.com/file/pcmkxaauku375xd/edi_rpow2_v1.0.avsi)?

[burfadel]

NNEDI3 and the Resize MT are also updated and provided as separate packages. The real benefit of this package is relating to the threadpools when you are using both nnedi3 and the mt resize functions according to the first post.

[jpsdr]

btw what about fixing the issues corrected by the EDI_RPOW2 script (http://www.mediafire.com/file/pcmkxaauku375xd/edi_rpow2_v1.0.avsi)?

And what issues exactly this script is fixing ?
If it's the chroma shift issue of original nnedi3_rpow2, it's been fixed since the 0.9.4.11.

[hello_hello]

So specifying a resizer for the nnedi3_rpow2 cshift parameter hasn't achieved anything for quite a while?

[jpsdr]

No, it's just that it wasn't doing enough, it was missing a little something, almost unoticeable in 99% of the cases.

[jpsdr]

New version, see first post.

[FranceBB]

It scales perfectly on all my 4 cores 8 threads and works perfectly in XP x86.

Working flawlessly
Spline64ResizeMT(1280, 720, threads=8, logicalCores=true, MaxPhysCore=true, SetAffinity=true)

Working flawlessly
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)

Working
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)
DitherPost()

Working flawlessly
AutoYUY2()


Release_XP SSE4 not working in XP as always (not a big deal).
Release_XP works like a charm.
It would be interesting to have AutoYUY2 working in other colour spaces, something like:
Converttoy8MT() #4:0:0
Converttoyv411MT() #4:1:1
Converttoyv12MT() #4:2:0
ConverttoYUY2MT() #4:2:2 interleaved (Actual AutoYUY2)
ConverttoYV16MT() #4:2:2 planar
ConverttoYV24MT() #4:4:4
ConverttoRGBMT() #RGB

[jpsdr]

AutoYUY2 is an old plugin from videoh, i was using an long time ago, and algorithm is realy dedicated to YV12 -> YV16 chroma upsampling. Even if there is a progressive mode, with progressive video, you'll get better results with actual resamplers. Also for the YV16->YV24, i would not be able to make better than actual resamplers.
Honestly, the only interest AutoYUY2 could have is YV12->YV16 on interlaced video, so, i personnaly don't intend to change anything on it.

[FranceBB]

Oh, ok, got it. Thank you for the explanation.

[jpsdr]

New version, significant update, see first post.

[jpsdr]

New version, fix in Desample.

[jpsdr]

New version, add of aWarpSharpMT.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[Atak_Snajpera]

This multithreaded resizing plugin is really good! Much better than plain Prefetch option in AviSynth+MT
CPU: E5-2690@2.9GHz (8C/16T)
Source: 3840x2160 YUV420P10

Crop(0,280,0,-280) + Spline36Resize(1920,800) + Prefetch(8)
http://i.cubeupload.com/Px4uU7.png

Crop(0,280,0,-280) + Spline36Resize(1920,800) + Prefetch(16)
http://i.cubeupload.com/Fr7VUV.png

Crop(0,280,0,-280) + Spline36ResizeMT(1920,800)
http://i.cubeupload.com/ZyL4dA.png

The fastest,lower memory consumption and cpu usage!

For comparison regular resizer.
Crop(0,280,0,-280) + Spline36Resize(1920,800)
http://i.cubeupload.com/i17UWO.png

[jpsdr]

New version, see first post, and i've also added on it a part about the multi-threading.

[Atak_Snajpera]

SetAffinity=true in latest version works terrible even without prefetch in script. Now it is slower than regular single threaded resizer!
http://i.cubeupload.com/FIc404.png

SetAffinity=false
http://i.cubeupload.com/Qa11Zu.png

BTW. I see that newer version is faster than old one (55 fps vs 52 fps)

[jpsdr]

What's the full script ?

[Atak_Snajpera]

#MT



#VideoSource
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\ffms\ffms_latest\x64\ffms2.dll")
video=FFVideoSource("E:\_Video_Samples\mkv\Passengers_2016_4K.mkv",cachefile = "C:\Temp\RipBot264temp\job1\Passengers_2016_4K.mkv.ffindex")
#Deinterlace



#Decimate



#Crop
video=Crop(video,0,280,-0,-280)



#Resize
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline36ResizeMT(video,1920,800,SetAffinity=true).Sharpen(0.2)



#Levels



#Colours



#Denoise



#Custom



#Prefetch



#Subtitles



#AudioSource
Import("C:\Temp\RipBot264temp\job1\job1_a1.avs")


#Triming



#AVSameLength



#ColorSpace



#Return

[jpsdr]

What CPU do you have, more exactly how many logical cores do you have ? I just want to understand the 49 threads, but totaly expected if you have something like a 20 logical cores CPU.

[Atak_Snajpera]

https://forum.doom9.org/showthread.php?p=1831560#post1831560

[jpsdr]

Ok, there is something odd indeed, thanks reporting. All the other filters seems to behave properly, but the resampler runs only on one core with SetAffinity set to true, which is totaly unexpected. I can't investigate right now, but i will very shortly.
There is a bug somewhere...:sly:
aWarpsharp2 and nnedi3 give me 41 threads on my 20 cores CPU, in both cases true/false.
ResampleMT gives me 41 threads with true, 174 with false !!!
Yes, there is something realy wrong...

[jpsdr]

More fishy !! I'm on my break lunch and made some tests on my PC a work, and everything works fine, but i don't have the same CPU than i have at home (it's a simple 4 cores without HT). The only thing i can't check for now is Intel vs VS. Have you made your tests with VS or Intel version ? If Intel, can you make a test with the VS version ? I'll try also this when back home, but it will not be before several hours.

Edit :
Sometimes i'm very stupid, of course i can test, i just have to download them from my github... :p

Results :
The VS AVX and Intel AVX2 versions work fine with standard avisynth.

The VS AVX version works fine with avs+ (both x86 & x64).
The Intel AVX2 version is working... "fishy" with avs+ (both x86 & x64), but only for the resampler, the other filters work fine.

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]

... Before totaly removing, i'll check if with /O2 instead of /O3 with the Intel compiler, there is still the issue.

[Groucho2004]

Ok, there is something odd indeed, thanks reporting. All the other filters seems to behave properly, but the resampler runs only on one core with SetAffinity set to true, which is totaly unexpected.
I have a rather basic question - What makes you think that messing with Windows' thread scheduler by manipulating thread affinity improves the speed? What if another program does the same? Have you measured the speed in different scenarios (various Windows versions, CPUs with Hyperthreading, software that messes with thread priority)?

[jpsdr]

What makes you think that messing with Windows' thread scheduler by manipulating thread affinity improves the speed?
Image is splitted horizontaly, so, for cache access, it may be better if contiguous zones are on the same physical core, no more, no less. If you don't have HT, less significant. That's what i think, and, yes, it's just a pure theorical thinking, didn't spend time to make all kind of test. (Wrote allready this in the part added in the 1rst post).
And, the threadpool i've used as exemple to make mine was even more restrictive, no choice, put each thread on one CPU only. I've expended that.
Nevertheless, this has nothing to do with Intel compiler messing the code...:sly:
But maybe it's also my fault, using /O3 may be too much experimental.

[TheFluff]

Image is splitted horizontaly, so, for cache access, it may be better if contiguous zones are on the same physical core, no more, no less.

u wot m8

it's random access memory, yeah?

[jpsdr]

LOL... Yes, the "Random" part means that you can directly access randomly to the data if you want, because the memory chipset/componant have an address bus allowing you to choose whatever memory data/case you want. Opposed to different kind of memory, which have for exemple only serial access, meaning that you can't directly access to whatever data you want without accessing to others before.

So... What this has to do with the fact that the memory zone you're working on can eventualy fit in the cache ?

[jpsdr]

Intel version trashed, no difference between /O2 or /O3. File updated, redownload it.

[jpsdr]

Some bench tests :

Script :

Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Spline36ResizeMT(1920,1080,SetAffinity=true)


Result :

[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 1080 | 1315 | 1293
Memory usage (phys | virt): 47 | 44 MiB
Thread count: 41
CPU usage (average): 81%
Efficiency index: 15.96

Time (elapsed): 00:00:07.736


SetAffinity=false, result :

[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 1050 | 1372 | 1173
Memory usage (phys | virt): 47 | 45 MiB
Thread count: 41
CPU usage (average): 69%
Efficiency index: 17.00

Time (elapsed): 00:00:08.527


Script :

Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
aWarpSharp2(SetAffinity=true)


Result :

[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 165.6 | 270.2 | 239.8
Memory usage (phys | virt): 60 | 60 MiB
Thread count: 41
CPU usage (average): 84%
Efficiency index: 2.854

Time (elapsed): 00:00:41.707


SetAffinity=false, result :

[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 170.4 | 271.0 | 207.2
Memory usage (phys | virt): 60 | 60 MiB
Thread count: 41
CPU usage (average): 67%
Efficiency index: 3.092

Time (elapsed): 00:00:48.270


Script :

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


Result :

[Runtime info]
Frames processed: 5 (0 - 4)
FPS (min | max | average): 0.431 | 0.433 | 0.432
Memory usage (phys | virt): 49 | 53 MiB
Thread count: 41
CPU usage (average): 97%
Efficiency index: 0.00446

Time (elapsed): 00:00:11.569


SetAffinity=false, result :

[Runtime info]
Frames processed: 5 (0 - 4)
FPS (min | max | average): 0.379 | 0.403 | 0.392
Memory usage (phys | virt): 49 | 52 MiB
Thread count: 41
CPU usage (average): 87%
Efficiency index: 0.00451

Time (elapsed): 00:00:12.741


Is it what can be called empirical evidence ?

Nevertheless, doesn't mean it will be like this for everybody. This is why everyone can tune according his results.

[Atak_Snajpera]

Still something is not right. I used dll from Release_W7 folder.
SetAffinity=true (it is even slower than before ;)
http://i.cubeupload.com/85WwtN.png

SetAffinity=false
http://i.cubeupload.com/HsGCFa.png

[TheFluff]

LOL... Yes, the "Random" part means that you can directly access randomly to the data if you want, because the memory chipset/componant have an address bus allowing you to choose whatever memory data/case you want. Opposed to different kind of memory, which have for exemple only serial access, meaning that you can't directly access to whatever data you want without accessing to others before.

So... What this has to do with the fact that the memory zone you're working on can eventualy fit in the cache ?

Say that you read a megabyte of framebuffer data from RAM into CPU cache and do some work on it. You then want to read some other megabyte of framebuffer data to CPU cache and do some work on that. What, to you, implies that the second memory-to-cache transfer would be affected by the previous one?

I find "benchmarks are, like, just your opinion, maaaan" to be an exceptionally poor argument, by the way. Your results compared to Atak_Snajpera's ones seem to imply that your implementation doesn't actually work, or at least doesn't do what you think it does. Heavens above know what you're even benchmarking.

e: to just quickly restate the argument about cache locality in resizers: recall that most resizers are separable filters which work by moving a sampling window over the input image one dimension at a time. Where do you see the potential for great time savings in the form of cache hits in this, exactly?

[jpsdr]

@Atak_Snajpera

Can you provide yours results with both true/false for just the following script :


Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Spline36ResizeMT(1920,1080,SetAffinity=true)


No need to bother with pictures, just paste the [Runtime info] from the log file, it should be easier and faster for you.

[jpsdr]

Heavens above know what you're even benchmarking.

The script are provided, so, if looking at them it's impossible to say what is benchmarked, i indeed don't know what to do more.

About cache, i'm just saying that if you have 8 physical CPUs with 8 threads workings each one on 1/8 of 1Mb frame and each thread on a different CPU, there is more chances that the working memory zone of each threads will totaly fit and stay within the cache during the whole process, than if you have 8 threads working each one on a full 1Mb frame.
No more, no less.

[TheFluff]

The script are provided, so, if looking at them it's impossible to say what is benchmarked, i indeed don't know what to do more.
That's not what I mean. You're arguing that your setAffinity thing is improving performance by improving the CPU cache hit ratio. You then provide a measurement that is supposed to be supporting this argument. I can't say what your benchmark is actually measuring since I don't know where the bottleneck actually is, but it's definitely not CPU cache hit ratio, and since your implementation appears to give drastically different results for other people I suspect the implementation doesn't do what you think it does. Even if it did improve performance consistently, the measurement would still not be saying anything about CPU cache hit ratio.

About cache, i'm just saying that if you have 8 physical CPUs with 8 threads workings each one on 1/8 of 1Mb frame and each thread on a different CPU, there is more chances that the working memory zone of each threads will totaly fit and stay within the cache during the whole process, than if you have 8 threads working each one on a full 1Mb frame.
No more, no less.
Again, why do you think this is advantageous? Consider a trivial case: we're downscaling an image 2x in both directions with pointresize. Each destination pixel will only sample two input pixels per pass (horizontal/vertical) and they never get reused after that. Pretty much all you need is to fit a single scanline in cache.

[Atak_Snajpera]

@Atak_Snajpera

Can you provide yours results with both true/false for just the following script :


Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Spline36ResizeMT(1920,1080,SetAffinity=true)


No need to bother with pictures, just paste the [Runtime info] from the log file, it should be easier and faster for you.

true
AVSMeter 2.2.6 (x64)
AviSynth+ 0.1 (r2580, MT, x86_64) (0.1.0.0)
Loading script...

Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 140.6 | 408.9 | 342.0
Memory usage (phys | virt): 35 | 30 MiB
Thread count: 33
CPU usage (average): 81%

Time (elapsed): 00:00:29.236

false
AVSMeter 2.2.6 (x64)
AviSynth+ 0.1 (r2580, MT, x86_64) (0.1.0.0)
Loading script...

Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 214.8 | 412.9 | 362.1
Memory usage (phys | virt): 35 | 30 MiB
Thread count: 33
CPU usage (average): 85%

Time (elapsed): 00:00:27.614

It works with colorbars. I think You should start testing with some real footage like me. (3840x2160 HDR + crop + resize).
Summary. Messing with affinity makes zero sense.

[jpsdr]

Something is strange.
You have here, as expected, 33 threads : 1 + 16 from avs+ + 16 from internal multi-threading.
In your previous posts, you have 49 threads, so 16 more. They could be explained if you have added prefetch(16) in your script, but it's not the case. I'm wondering where they are comming from...
I'll make some tests at home with a file.

[Atak_Snajpera]

You do realize that ffms decoder spawns additional threads? Those extra 16 threads are basically from decoder.

#VideoSource
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\ffms\ffms_latest\x64\ffms2.dll")
video=FFVideoSource("E:\_Video_Samples\mkv\Passengers_2016_4K.mkv",cachefile = "C:\Temp\RipBot264temp\job1\Passengers_2016_4K.mkv.ffindex")

[jpsdr]

Yes, of course !

And i have also the same things in these results :


[Clip info]
Number of frames: 13200
Length (hh:mm:ss.ms): 00:09:10.550
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

[Runtime info]
Frames processed: 13200 (0 - 13199)
FPS (min | max | average): 21.43 | 192.1 | 153.3
Memory usage (phys | virt): 92 | 102 MiB
Thread count: 61
CPU usage (average): 46%

Time (elapsed): 00:01:26.106

[Script]
a=AviSource("Dark_Crystal_HDR.avi",False,"YV12")
b=a+a+a+a+a+a+a+a+a+a+a
c=b+b+b+b+b+b+b+b+b+b+b+b
Spline36ResizeMT(c,1920,1080,SetAffinity=true,threads=0)



[Clip info]
Number of frames: 13200
Length (hh:mm:ss.ms): 00:09:10.550
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

[Runtime info]
Frames processed: 13200 (0 - 13199)
FPS (min | max | average): 21.30 | 185.2 | 149.0
Memory usage (phys | virt): 92 | 102 MiB
Thread count: 61
CPU usage (average): 40%

Time (elapsed): 00:01:28.569

[Script]
#SetMemoryMax(192)
a=AviSource("Dark_Crystal_HDR.avi",False,"YV12")
b=a+a+a+a+a+a+a+a+a+a+a
c=b+b+b+b+b+b+b+b+b+b+b+b
Spline36ResizeMT(c,1920,1080,SetAffinity=false,threads=0)



[Clip info]
Number of frames: 13200
Length (hh:mm:ss.ms): 00:09:10.550
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

[Runtime info]
Frames processed: 13200 (0 - 13199)
FPS (min | max | average): 47.03 | 186.4 | 173.7
Memory usage (phys | virt): 306 | 478 MiB
Thread count: 49
CPU usage (average): 16%

Time (elapsed): 00:01:15.980

[Script]
DGSource("DCrystal.dgi",i420=false,deinterlace=0,fieldop=0).trim(0,13199)
Spline36ResizeMT(1920,1080,SetAffinity=true,threads=0)



[Clip info]
Number of frames: 13200
Length (hh:mm:ss.ms): 00:09:10.550
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

[Runtime info]
Frames processed: 13200 (0 - 13199)
FPS (min | max | average): 54.67 | 180.2 | 172.9
Memory usage (phys | virt): 306 | 478 MiB
Thread count: 49
CPU usage (average): 14%

Time (elapsed): 00:01:16.342

[Script]
DGSource("DCrystal.dgi",i420=false,deinterlace=0,fieldop=0).trim(0,13199)
Spline36ResizeMT(1920,1080,SetAffinity=false,threads=0)

As i've said, it seems that sometimes you need to tune for yourself, what's good for one, is not always good for another.

[jpsdr]

Again, why do you think this is advantageous?
I'll clarify my thought : It may be, not it will be. Also, don't focuss only on resampler, maybe there is different filters on which it could be more efficient.
And again, if what is good for me is not for you, there is no issue, because you can change it. It's not like it's forced and you don't have the choice.
As they are my builds, i set the default settings to what give me the best results for my use case, so i play selfish, to not have to adjust for myself...:p.

[Atak_Snajpera]

As i've said, it seems that sometimes you need to tune for yourself, what's good for one, is not always good for another.
SetAffinity should be disabled by default. There is more trouble than benefit. Speed increase in your example is less than 3%.

[jpsdr]

Sorry, but for now, i'll keep it this way.

[real.finder]

after I update for the last resample I note there are some slow and after I see Atak_Snajpera posts here I decided to test with avsmeter


SetAffinity test

old cpu (2010) on old windows
https://s9.postimg.org/ghr0nsvan/image.png

new cpu (2014 maybe not really new) on new windows
https://s9.postimg.org/g4zmhn067/image.png

both said there are problem in SetAffinity in last update, the previous version was fine https://forum.doom9.org/showpost.php?p=1831560&postcount=41

[jpsdr]

Argh... Two against one...:scared: This is begining to be harder. Why am i the only one where it works differently...:confused:
I know !!! It's a conspiracy ! Ah... I knew the earth was indeed flat !
Out of curiousity, what is your script ?

[Groucho2004]

Why am i the only one where it works differently...:confused:Maybe your Broadwell 10/20 core CPU behaves differently compared to the CPUs that we mere mortals use?

[jpsdr]

Maybe your Broadwell 10/20 core CPU behaves differently compared to the CPUs that we mere mortals use?
Ah... That's it of course... Poor low mortals...:cool:

[Atak_Snajpera]

I can also confirm that previous version 2.0.5 worked ok (or was bugged and was always false) with default setaffinity=true.
SetAffinity is useless because:
1) Unpredictable performance for many users.
2) Extremely tiny speed boost for users with specific CPU (Broadwell). Furthermore that extra 3% will be most likely further "eaten" by other filter or procces (x264/x265)
3) has to be disabled when prefetch is used in script

SetAffinity=true as default setting is NOT optimal. Period!

[real.finder]

Argh... Two against one...:scared: This is begining to be harder. Why am i the only one where it works differently...:confused:
I know !!! It's a conspiracy ! Ah... I knew the earth was indeed flat !
Out of curiousity, what is your script ?

I used this

Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Spline36ResizeMT(1920,1080,SetAffinity=true)

[jpsdr]

New version, see first post, updated also the Multi-treading text part.

[jpsdr]

New version, see first post.

[FranceBB]

Updated, thank you! :D

[jpsdr]

New version, add HDRTools, see first post.

[jpsdr]

Slipstreamed a new build/file. There is no change in the code, so it's not a new version.
I've realised that i didn't put the documentation of the plugins in this package, and if you wanted the documentation you also needed to download each plugin version, which is not very convenient (and not smart from my part). So, i've added in the release file the documentation of each plugin.
I took the opportunuity to make new builds with the last Visual Studio release, and also put back the Intel Compiler builds.

[jpsdr]

New version, see first post.

[FranceBB]

New version, see first post.

Thank you Jean-Philippe, but what does ThreadLevel do and how should we use it?

[ryrynz]

what does ThreadLevel do and how should we use it?

from the readme.

ThreadLevel - This parameter will set the priority level of the threads created for the processing (internal multithreading). No effect if threads=1.

1 : Idle level.
2 : Lowest level.
3 : Below level.
4 : Normal level.
5 : Above level.
6 : Highest level.
7 : Time critical level (WARNING !!! use this level at your own risk)

Default : 6

[FranceBB]

from the readme.

ThreadLevel - This parameter will set the priority level of the threads created for the processing (internal multithreading). No effect if threads=1.

1 : Idle level.
2 : Lowest level.
3 : Below level.
4 : Normal level.
5 : Above level.
6 : Highest level.
7 : Time critical level (WARNING !!! use this level at your own risk)

Default : 6

I see, so now we're also able to set the level for the specific thread used by the plugins like when we manually modify the priority on Windows for a specific process.
That's kinda nice, thank you. :)

Tested and working on Windows XP, however, as the other previous releases, XP SSE4.2 produces a code that is not compatible with Windows XP: Link (https://i.imgur.com/DXZTQEF.png)
It's looking for the function libm_sse2_exp2 inside LIBMMD.DLL for whatever reason and it doesn't work.
As to the SSE2 one, it works, as always: Link (https://i.imgur.com/oZ5wsTA.png)

Thank you again anyway,
Frank.

[jpsdr]

New version, see first post.

[jpsdr]

I've messed-up on resampler my files management between my VS versions, commited but not pushed, result the build was made with only some parts of the fixes (but still the output was not bad or incorrect).
If you see this post and have already downloaded the 3.1.2 version, re-download it, and sorry for the inconvenience.

[dREV]

Hello, I been trying to transition from using megui 32 bit to megui 64 bit with avisynth+ 64 bit in the hopes of seeing a speed increase during encode and slowly looking for the 64+ filters equivalents but having problems with this plugin.

My problem is the debilinear and debicubic and am I reading correct that this is essentially is an update to that plugin with multi-threading and a 64+ version as I don't see any 64 bit version plugin for this filter. As far as I am aware this is the only for that exists.

http://avisynth.nl/index.php/Debilinear
http://avisynth.nl/index.php/Debicubic

The issue I am running into is that it doesn't have the code "bool lsb_inout" and its telling me when I use another script called DebilinearM found here (https://twitter.com/desbreko145/status/492482320079663104). On AvsPmod 64 bit states "script error: DebilinearResizeMT does not have a named argument "lsb_inout" (path DebilinearM_v1.3.1.avsi, line 67) (New File, line 82)".

As another user wrote the nnedi3_resize16 code works just fine with the lsb's for it which I use and need to make the change so I thought maybe this was an oversight. But both Debilinear and Debicubic don't seem to work and are missing the "lsb_inout" argument as I also used DeBilinearResizeMT by itself without the additional script above and it did not work with lsb_inout input. Not sure if DebilinearY and DebicubicY work, can this be confirmed?

I used the one in the x64\Release_W7_AVX2 folder for this as I think I'm suppose to use this for my Ryzen 5 machine.

Also, off topic is there a EdgeCleaner 64 bit version for avisynt+ same for warpsharp? I only been using http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

[jpsdr]

The "Dexxxx" versions are included within the ResampleMT, read the doc of it, and read also here (https://forum.doom9.org/showthread.php?t=174846).

They are not an upgrade/update of the previous version, they do the same thing, but they are totaly rewritten from scratch, and there is no intended link between the parameters with my version and the original version. If some parameters between both version happen to have the same purpose, it's just by luck.
So, yes, there is no lsb_inout parameter in my version.

[dREV]

Thanks for replying. I've read the documentation several times which is why I thought it was strange that the nnedi3_resize16 lsb's work as intended and thought perhaps the Debilinear and Debicubic missing these parameters were simply oversights in addition the documentation advice to work in 16 bit or float. Also, another one using IResize with success.

Maybe I'm just misunderstanding. I'm trying to understand.

Quality improvement tip
There is the accuracy parameter, but another way to eventualy improve the quality is to increase the bit depth if you're using avs+. If you are in 8 bits, the resampler compute using integer rif parameters converted from the float rif parameters. But, if you are in bit depth>8, the resampler uses the float coefficients. In desampling cases, where rif size can easely be of 40 or 50, if you're trying to be the most accurate, i would advise to increase the bitdepth to 16 (or even to float if you're searching for ultra accuracy) just for the desampling filter.

Maybe there's another method to this that I'm not aware of as I use dither_convert_8_to_16() parameter to go into 16 bit. How would this be accomplished without lsb when using Debilinear or Debicubic together with the documentation quote above? I'm enticed about this ultra accurate thing to play around with if it does indeed improve the quality.

Perhaps give an example if you don't mind on how to apply this 16 bit as I am not seeing it. Essentially, I'm trying to get this to work in a 16 bit field using the DebilinearM script as mentioned in my previous post.

Since you mention that you don't have the original code asking if this function could be implemented maybe asking too much. Therefore, I have to ask if you are aware of any other Debilinear plugins available for avisynth+? Maybe I am not looking hard enough but I just do not see them. I might have to give VaporSynth a look if there is none.

[real.finder]

have a look here http://avisynth.nl/index.php/AviSynth%2B#Deep_color

[jpsdr]

It's possible that this :

#For exemple, if the source file is a 1280x720 8 bits video :

Spline36ResizeMT(1920,1080,src_left=-0.2)
# or Spline36Resize(1920,1080,src_left=-0.2)
# To revert :
ConvertBits(16)
# or ConvertBits(32)
DeSpline36ResizeMT(1280,720,src_left=-0.2)
ConvertBits(8) # If you want to revert back to 8 bits video


produces a more accurate result than this :

#For exemple, if the source file is a 1280x720 8 bits video :

Spline36ResizeMT(1920,1080,src_left=-0.2)
# or Spline36Resize(1920,1080,src_left=-0.2)
# To revert :
DeSpline36ResizeMT(1280,720,src_left=-0.2)


I don't see the point of having internal function within the filter to change bit depth, as they allready exist in the core.

[dREV]

have a look here http://avisynth.nl/index.php/AviSynth%2B#Deep_color

Thanks for the link. I had no idea about that I've usually stuck to the articles for original AviSynth. Together with what jpsdr wrote it worked by itself tho and there are issues. Which I will note below.

I don't see the point of having internal function within the filter to change bit depth, as they allready exist in the core.

This is intended to be an upgrade of the actual DeBilinear, working with all data formats of avs+, and having an x64 version. https://forum.doom9.org/showthread.php?p=1817097#post1817097 I thought I did read correctly the intention of this plugin to be an update to 64 bit and the oversight was correct but then I was corrected that it was not the case, so I like to ask if this is truly the case and that opinion from the quote above no longer holds true? The function only has 4 parameters.

The issue I ran into while it did work by itself given the code above I can't do anything about the sharpness of the source. I cannot soften that parameter so it doesn't look like jagged edges (this is with using anti-aliasing filter) and this is where DebilinearM comes into play. Found at the very bottom of http://avisynth.nl/index.php/Debilinear in the mediafire link. Using the thr parameter I can soften the amount of descaling sharpness thing it does on the very same source used in the testing for DebilinearResizeMT. /* DebilinearM v1.3.1

DebilinearM is a wrapper function for the Debilinear and Debicubic plugins that masks parts of the frame that aren't upscaled,
such as text overlays, and uses a regular ResizeX kernel to downscale those areas. It works by downscaling the input
clip to the target resolution with Debilinear or Debicubic, upscaling it again, comparing it to the original clip,
and masking pixels that have a difference greater than the specified threshold.

##### Requirements #####

Plugins:
Debicubic
Debilinear
Dither
MaskTools2

Scripts:
ResizeX

Color formats:
YV12
*/

function DebilinearM(clip input, int target_width, int target_height, int "thr", int "expand", int "inflate",
\ string "kernel", int "taps", float "a1", float "a2", bool "cubic", float "b", float "c",
\ bool "chroma", bool "lsb_inout", int "showmask") {

# Default settings and other variable assignment
thr = Default(thr, 10)
expand = Default(expand, 1)
inflate = Default(inflate, 2)
kernel = Default(kernel, "Spline36")
cubic = Default(cubic, false)
chroma = Default(chroma, true)
lsb_inout = Default(lsb_inout, false)
showmask = Default(showmask, 0)

Assert(target_width > 0, "DebilinearM: target width must be greater than 0")
Assert(target_height > 0, "DebilinearM: target height must be greater than 0")
Assert(thr >= 0 && thr <= 255, "DebilinearM: thr must be in the range 0 to 255")
Assert(showmask > -1 && showmask < 3, "DebilinearM: showmask must be 0, 1, or 2")

w = input.Width()
h = lsb_inout ? input.Height()/2 : input.Height()

uvint = chroma ? 3
\ : 1

# Resizing
input_8bit = lsb_inout ? input.DitherPost(mode=-1) : input

cubic ?
\ Eval("""
dbi = chroma ? input.Debicubic(target_width,target_height, b=b, c=c, lsb_inout=lsb_inout)
\ : input.DebicubicY(target_width,target_height, b=b, c=c, lsb_inout=lsb_inout)
dbi_8bit = chroma ? input_8bit.Debicubic(target_width,target_height, b=b, c=c)
\ : input_8bit.DebicubicY(target_width,target_height, b=b, c=c)
dbi2 = lsb_inout ? dbi_8bit.ResizeX(w,h, kernel="Bicubic", a1=b, a2=c, chroma=chroma)
\ : dbi.ResizeX(w,h, kernel="Bicubic", a1=b, a2=c, chroma=chroma)
""")
\ : Eval("""
dbi = chroma ? input.Debilinear(target_width,target_height, lsb_inout=lsb_inout)
\ : input.DebilinearY(target_width,target_height, lsb_inout=lsb_inout)
dbi_8bit = chroma ? input_8bit.Debilinear(target_width,target_height)
\ : input_8bit.DebilinearY(target_width,target_height)
dbi2 = lsb_inout ? dbi_8bit.ResizeX(w,h, kernel="Bilinear", chroma=chroma)
\ : dbi.ResizeX(w,h, kernel="Bilinear", chroma=chroma)
""")

rs = input.ResizeX(target_width,target_height, kernel=kernel, taps=taps, a1=a1, a2=a2, chroma=chroma, lsb_in=lsb_inout, lsb=lsb_inout)

# Masking
diffmask = mt_lutxy(input_8bit,dbi2, "x y - abs", U=uvint, V=uvint).mt_binarize(threshold=thr, U=uvint, V=uvint)
diffmask = showmask == 2 ? diffmask.DebilinearM_expand(expand=expand, U=uvint, V=uvint)
\ .DebilinearM_inflate(inflate=inflate, U=uvint, V=uvint)
\ : diffmask.ResizeX(target_width,target_height, kernel="Bilinear", chroma=chroma)
\ .mt_binarize(threshold=3, U=uvint, V=uvint)
\ .DebilinearM_expand(expand=expand, U=uvint, V=uvint)
\ .DebilinearM_inflate(inflate=inflate, U=uvint, V=uvint)

merged = lsb_inout ? Dither_merge16_8(dbi,rs,diffmask, u=uvint, v=uvint)
\ : mt_merge(dbi,rs,diffmask, U=uvint, V=uvint)

return showmask > 0 ? diffmask
\ : merged
}

# DebicubicM alias
function DebicubicM(clip input, int target_width, int target_height, int "thr", int "expand", int "inflate",
\ string "kernel", int "taps", float "a1", float "a2", float "b", float "c",
\ bool "chroma", bool "lsb_inout", int "showmask") {

return DebilinearM(input,target_width,target_height,thr,expand,inflate,kernel,taps,a1,a2,true,b,c,chroma,lsb_inout,showmask)
}


# Helper functions
function DebilinearM_expand(clip input, int "expand", int "U", int "V") {
return expand > 0 ? DebilinearM_expand(input.mt_expand(mode="both", U=U, V=V), expand-1)
\ : input
}

function DebilinearM_inflate(clip input, int "inflate", int "U", int "V") {
return inflate > 0 ? DebilinearM_inflate(input.mt_inflate(U=U, V=V), inflate-1)
\ : input
} I've tried to modify the script to use DebilinearResizeMT but I have almost zero knowledge on this and have had zero success.

My script involves the implementations of what's in image 02:

https://i.ibb.co/stQnHgD/Examp01-Debilinear-Resize-MT.jpg https://i.ibb.co/RBJSh3X/Examp02-Debilinear-M-thf0-1.jpg

Image 01 (left)(by itself) via AviSynth+ 64 bit
ConvertBits(32)
DeBilinearResizeMT(1280,720,accuracy=2)

Image 02 (right) via Avisynth+ 32 bit
dither_convert_8_to_16()
ly = DebilinearM(1280,720,thr=01,lsb_inout=true) # Debilinear
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50) #
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out() It don't look so good. Both ConvertBits(16) and ConvertBits(32) I'm not knowledgeable enough on how to go about this method. That along with the problematic result of the jagged edges with DebilinearResizeMT. My ignorance in trying to place it within the YtoUV (on image 02) function turns horrid obviously to those who are more knowledgeable then I may see that.

The above script (at least from what I read from others) allows upscaling the chroma, I don't understand it myself but results on the quality of both the image and colors are better then simply by itself. I've also recently found another script that's even greater that requires both DebilinearM and Debilinear.dll with even more depth to detail, colors, and debanding.

Also, I don't understand why your code had src_left=-0.2 when I used it it did not match the source I had when taking screenshot. The image 02 doesn't do this as if it does it won't match my 1080p source and when I downsize it via avspmod and photoshop (where I do my comparisons from). I had read here on Doom9 that for chroma it's src_left=0.50.

Would it be possible to do the above with this plugin as is? From what I'm perceiving it may not be so. Sorry for having to repeat myself and sorry for the long post. If not I'll give VaporSynth a look as I don't want to waste your time anymore with my questions.

[jpsdr]

The code was just an exemple of what Dexxxx parameters must be, linked to the xxxx parameters.
Don't see any specific sense in the value themselve. I used src_left in the exemple, but it could has been any other src_xxx.

I'll update my post, as it seems it can lead to misunderstanding.

[real.finder]

here an update for DebilinearM https://pastebin.com/bS8s4Chn

ColorBars(width=1280, height=720, pixel_type="yv12")
BilinearResize(1920,1080)
dither_convert_8_to_16()
ly = DebilinearM(1280,720,thr=01,lsb_inout=true, DeResizeMT=true) # Debilinear
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50) #
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()

with this it will use dither resize, use it without lsb things to use DeXXXXXResizeMT

you need update ResizeX https://forum.doom9.org/showthread.php?p=1837361#post1837361

[dREV]

The code was just an exemple of what Dexxxx parameters must be, linked to the xxxx parameters.
Don't see any specific sense in the value themselve. I used src_left in the exemple, but it could has been any other src_xxx.

I'll update my post, as it seems it can lead to misunderstanding.

Oh, alright. I was going on the assumption that it was the default settings for that particular resize and alignment. Thanks for your reply.


here an update for DebilinearM https://pastebin.com/8zNJUDZw

ColorBars(width=1280, height=720, pixel_type="yv12")
dither_convert_8_to_16()
ly = DebilinearM(1280,720,thr=01,lsb_inout=true, DeResizeMT=true) # Debilinear
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50) #
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()

with this it will use dither resize, use it without lsb things to use DeXXXXXResizeMT

you need update ResizeX https://forum.doom9.org/showthread.php?p=1837361#post1837361

Thank you for taking the time and sharing your update with all people and the example script that will help me out :thanks:. I'll test it out over the weekend (I hope) when I get some more time. I'm looking forward to finally using DebilinearResizeMT with DebilinearM. Will I be able to take advantage of the "accuracy" thing by default?

I also read all of the posts after the ResizeX link you gave above and I wanted to ask some questions to clarify if I understood it correct. But I think I should ask it over at your thread instead of here so I don't go off topic.

I also have another script that I briefly mentioned above that maybe you can help me understand why it adds artifact (not sure if that's the term for it) and another issue added with it that requires another color profile that may or may not conflict with one another with the "YV12" I see in your example script. If you don't mind that is once I play around with the filter.

[real.finder]

DebilinearM

new update for speed (in HBD only, will not see speed up in lsb)

[dREV]

Thanks. Made a post on your thread. https://forum.doom9.org/showthread.php?p=1879764#post1879764

[jpsdr]

New version, see first post.

[Patman]

Hi jpsdr,

pls update your plugin pack. I saw that you've updated HDRTools.

[jpsdr]

It's in process...

[Patman]

It's in process...Thx

Gesendet von meinem HMA-L09 mit Tapatalk

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[FranceBB]

New version, see first post.

Yep, I silently lurked the awarpsharp thing on the other topic.
Thank you for the update, it seems to work fine on Windows XP; perhaps I never noticed the error 'cause AVX are not a thing on XP (and I don't encode anime at work where I have Win10), so I never used that part of the code...

Cheers,
Frank. :)

[real.finder]

Yep, I silently lurked the awarpsharp thing on the other topic.
Thank you for the update, it seems to work fine on Windows XP; perhaps I never noticed the error 'cause AVX are not a thing on XP (and I don't encode anime at work where I have Win10), so I never used that part of the code...

Cheers,
Frank. :)

awarpsharp may made for anime, but it used in YAHR by Didée which a general use dehalo

https://web.archive.org/web/20090803132834/https://forum.doom9.org/showthread.php?p=1205653

[SeregaDS]

Hi!
I have an issue with last version of plugins_JPSDR_v3_2_1 (But with the previous version plugins_JPSDR_v3_2_0 - all right).
The next code produce strange video:
TempGaussMC_beta2u (tr0=2,tr1=2,tr2=3,EdiMode="NNEDI3", SLrad=2)
http://i.piccy.info/i9/f3ec96ae2f3670bb9db63c9351551e5d/1588609494/62178/1376488/Annotation_2020_05_04_192103.jpg
(without using NNEDI3 - also all right)

In the same time, the next code produce normal video:
QTGMC(tr0=2,tr1=2,tr2=3,EdiMode="NNEEDI3", SLrad=2)
http://i.piccy.info/i9/c1d372a553cb92f064f781910ab264db/1588609723/68642/1376488/Annotation_2020_05_04_192109.jpg

Win10x64. AviSynth+ 3.5.2 (r3218, neo, x86_64)

[jpsdr]

In VDub, this seems to work :
ColorBars(width=640, height=480, pixel_type="yv12")
#QTGMC().SelectEven()

but this one crash inside avisynth:
QTGMC(preset="Very Slow", InputType=0,sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=1).SelectEven()
The second one involve FFT3DFilter.

Is TempGaussMC_beta2u using FFT3DFilter ?

I'll try to make a version not using the new Pplanar, maybe it was too soon for the new headers... (if it's that).

[SeregaDS]

Is TempGaussMC_beta2u using FFT3DFilter ?
I don't think so...
Search for string "FFT3" inside script didn't find any results...
And if i use EEDIx (not NNEDI3) - script works normal.

[pinterf]

In VDub, this seems to work :
ColorBars(width=640, height=480, pixel_type="yv12")
#QTGMC().SelectEven()

but this one crash inside avisynth:
QTGMC(preset="Very Slow", InputType=0,sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=1).SelectEven()
The second one involve FFT3DFilter.

Is TempGaussMC_beta2u using FFT3DFilter ?

I'll try to make a version not using the new Pplanar, maybe it was too soon for the new headers... (if it's that).
Previous version (0.9.4.53) was staying at 306MB (avsmeter64) and works at 8+fps (whole qtgmc), this last one seems to have a memory leak, shortly reaches 4GB where Avisynth is slowing down since it tries to free up caches.

[jpsdr]

My standard PC (the one i'm writting with here) is under standard avs2.6.1, this is why the second qtgmc script crash, it's probably not working under avs2.6.1.

[SeregaDS]

So, please try to use TempGaussMC_beta2u :)
It works with all versions of Avs...

[jpsdr]

Ok, i've figure out where it's happening, but i'm unable to figure out the proper syntax for transmiting parameters.

Before, the src was created and used inside the copyPad function, called at the begining of the GetFrame function:

void nnedi3::copyPad(int n, int fn, IScriptEnvironment *env)
{
const int off = 1-fn;
PVideoFrame src = child->GetFrame(n, env);

and src wasn't needed outside anymore.

Now, i need the src to create the dst, so, now, instead of:

PVideoFrame __stdcall nnedi3::GetFrame(int n, IScriptEnvironment *env)
{
int field_n;

if (field>1)
{
if (n&1) field_n = field == 3 ? 0 : 1;
else field_n = field == 3 ? 1 : 0;
}
else field_n = field;

copyPad(field>1?(n>>1):n,field_n,env);

i have:

PVideoFrame __stdcall nnedi3::GetFrame(int n, IScriptEnvironment *env)
{
int field_n;

if (field>1)
{
if (n&1) field_n = field == 3 ? 0 : 1;
else field_n = field == 3 ? 1 : 0;
}
else field_n = field;

PVideoFrame src = child->GetFrame(n,env);

copyPad(src,field>1?(n>>1):n,field_n,env);

This is what creating the memory leak and the issues.
I've tried

void copyPad(const PVideoFrame &src,int n,int fn,IScriptEnvironment *env);

and without const and also

void copyPad(PVideoFrame src,int n,int fn,IScriptEnvironment *env);

still the same behavior...
I'll try a mix with previous version, copyPad geting src and return it...

[MeteorRain]

I noticed src was used in both copyPad and NewVideoFrameP. Any chance it's the latter?

[jpsdr]

No... It's the new thing, now i need src for NewVideoFrameP.
I've made my tests by implementing the changes step by step, and kept NewVideoFrameP for the end, so, i've re-created the issue before puting back NewVideoFrameP.
It seems that a mix, creating src inside copyPad and having it return src works, no memory leak anymore and identical speed.

New build soon.

[pinterf]

I noticed src was used in both copyPad and NewVideoFrameP. Any chance it's the latter?
I have tried with an old r2900 avs+, and it still leaks, that is not using the P vesion. For the first sight I cannot tell what is happening.

[pinterf]

No... It's the new thing, now i need src for NewVideoFrameP.
I've made my tests by implementing the changes step by step, and kept NewVideoFrameP for the end, so, i've re-created the issue before puting back NewVideoFrameP.
It seems that a mix, creating src inside copyPad and having it return src works, no memory leak anymore and identical speed.

New build soon.
GetFrame recursively called itself with the same n, but 'n' is different in copyPad.
This one works:
int x = field > 1 ? (n >> 1) : n;
PVideoFrame src = child->GetFrame(x,env);

[jpsdr]

OMFG !!! This is what i've missed !!!
:thanks:

[jpsdr]

New version, see first post, should be fixed.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[DTL]

As an addition to readme.txt about SincLin2Resize:

It designed as workaround to fix edge bugs with SincResize if using too few number of taps. 'Too few' mean about < 60..70 with 8-bit integer samples processing. It gives at least taps/2 full-strike sinc kernel size and last taps are linearly faded to zero (something like 'trapezoidal weighting'). At some testcases it allows to get clean 8-bit result with taps parameter as low as 15. That is significally faster in compare with SincResize(taps=70). With lesser taps parameter it may definetly expose same edge 'ghosting' and 'object griding' bugs as old SincResize. So for high quality work it is recommended to keep taps >15..20. It is a bit sharper in compare with LanczosResize with same number of taps because of less aggressive sinc kernel weighting.

[dREV]

Hi, I wanted to ask about which of the NNEDI's would be best to use on my PC. It's a AMD Ryzen 5 2nd generation I think it's either 6 or 12 cores not sure with 16 GB and on Windows 7 64 bit OS using MeGUI and AviSynth+ 3.6.1 86x version.

I tried reading the readme.txt but not much info there. I been using the folder marked "Release_W7_AVX2" with no issues not sure about the other ones tho.

I was also going to ask a question about the prefetch but it seems really complicated. I've been trying to understand it and more than likely I've been doing it wrong seeing I've had it set to "prefetch=1" according to your multithreading.txt file. I'll just use the default from now on as my fps is a lot faster then when I try the prefetch.

[FranceBB]

Afaik AMD Ryzen have up to AVX2 instructions set, so you're probably already using the best possible build.
Please note, though, that since it's coded in C++, the fact that the compiler is instructed to use up to AVX2 doesn't always reflect in improved speed performance.
This is because it's the compiler that is trying to understand what the programmer is doing and write the corresponding assembly optimizations to use all the available instructions set, so it might not make use of them anyway (it can happen) or even misunderstand and generate a slightly slower code (very rare, but it can happen and if you look at other posts here on Doom9 for other plugins there have been times in which some builds were faster than others while it was supposed to be the other way round).
Anyway, as far as everything is behaving correctly and according to a logic, you're already using the fastest build.

If you want, though, you can benchmark the various builds with AVSMeter and in your case I would benchmark two builds in particular: Clang W7 AVX2 and W7 AVX2 so that you can see whether Visual Studio or clang llvm produced a faster build.
I generally stick with the Visual Studio ones, but many people say that Clang ones are faster on their machines, so I guess it's worth giving them a shot. ;)

[Boulder]

Clang build for various plugins have generally been faster on my Zen (1 & 2) systems.

[jpsdr]

If you're not using the avisynth MT part (so prefetch in your script), no need to set the prefetch.
If you're using prefetch in your script, the best would be to have prefetch*threads=CPU.

[StainlessS]

prefetch*threads=CPU
What exactly might that mean [x*y="AMD Ryzen 5600X", or maybe something else].

[jpsdr]

CPU, core, it's the same...
So, CPU=core number.

[StainlessS]

so physical cores.
Thank you.

[jpsdr]

I think the optimal value is probably between the number of physical and logical cores. But this optimal value will probably never be the same between different peoples...:(

[larisk2]

I have a video card from ATI, please advise some high-quality deinterlace filter / plugin for avisint. I tried different ones, but I didn't like the quality of the result.

[jpsdr]

Deinterlacing is not realy my stuff, so personnaly i can't realy advise (my use of nnedi3 is only nnedi3_rpow for upsampling). Even more if you're already tested the avisynth's classic ones (nnedi3, QTGMC, ... ... ... ... i realise if there is others i don't know them).

[DTL]

It looks like there is somewhere memory corruption bug or buffer overrun if processing too small sized buffers: https://forum.doom9.org/showthread.php?t=182108

If source image is about 1200x720 being down-sized to /10 = 120x72 and then upsized to 8..10x we got buggy blue pixels at the bottom and also non-stable corrupted pixels at bottom (at different runs the pattern of corrupted pixels may vary) and also the progam may crash with memory protection error (like illegal writing to...). Ofcourse processing so small buffers is not commom task but if programmer have time it is good to search the reason of the bug.

I remember there is an assert somewhere in resampler to refuse processing too small buffers with too large 'support' or taps number - may be bug is somewhere close like the limits of assert is too small and processing engine still runs out of the end of buffers and reads from memory with other data content and sometime attempts to write out of reserved pages boundary and finally cautch hardware memory protection error.

[jpsdr]

Is it only on ResampleMT, or also on standard resample ?

[DTL]

Changed resizers to 'standard' GaussResize and BilinearResize - the result is same buggy. So the bug is in the main Avisynth resample engine (used in ResampleMT too) ? I post bug description with simplest reproduction script to main Avisynth+ thread.

[real.finder]

since SincLin2Resize and SinPowResizeMT was added, is they like NoHalo and LoHalo (https://graphicdesign.stackexchange.com/a/138061)?, if not can they be added? and seems there are others (LoBlur and LoJaggy)

edit: there are also JincResize maybe worth adding too

[DTL]

"SincLin2Resize and SinPowResizeMT was added, is they like NoHalo and LoHalo?,"

No. They are small additions to 'linear' signal processing based on sinc and Nyquist theorem. SincLin2 is simply workaround for fixing computational bugs of SincResize with too few taps typically used. They just adds a bit step to complete tools for '1D' linear signals processing. For better 2D image processing it is required step to significally different '2D math' - like that EWA/Jinc and other.

" there are also JincResize maybe worth adding too"

JincResize is from completely different 'true-2D' resizers family. It is based on completely different resampling engine. And all ResampleMT resizers including SincLin2 and SinPow uses the one and the only resampler for V+H 1D+1D processing engine (resampler) taken from standard Avisynth. Just MT added. SincLin2 and SinPow are just very small kernel-generation functions added.

Also the only known here JincResize for Avisynth is unstable and buggy still and need more developer resources to be usable. So it is very hard to add them to ResampleMT with all MT functionality.

[real.finder]

Also the only known here JincResize for Avisynth is unstable and buggy still and need more developer resources to be usable.

even this https://github.com/Asd-g/AviSynth-JincResize ?

[DTL]

even this https://github.com/Asd-g/AviSynth-JincResize ?

This one looks more stable. I test 0.x versions and 1.x ported from VapourSynth looks more stable. Though it outputs significally different results with different 'tap' parameter. And only work with 'planar' formats. And it looks only useful for upsampling (and looks do not have corresponding 'true-2D' downsample function for production work like complentary pair SinPow(downsample)/Sinc(upsample) resizers).
May separate thread at forum exists for this plugin ?

You think it will significally gain up speed from internal multithreading ?

[jpsdr]

From what i've noticed, the more computation there is using data from a small source area (-> fitting in cache), the more you can gain with MT, and the more you can gain increasing the number of core.

[DTL]

For 1-pass Jinc-family resamplers I think the direct 2D convolution of 2D kernel with 2D lines-sampled image buffer may significally suffer from long-stride memory access and cache pollution of unused prefetch. So there may be different shemes of MT task assignment for different cores. May be even many threads processing different but neibour input sample steps of 1 input buffer area (not differend areas of input buffer nor different frames of input sequence) - so there will be less long stride memory reads. But the threads syncing may be harder and time losses on threads syncing may be significant too. The main idea is by some way perform sync of different threads processing neibour input samples - so the processed image buffer area will be cached once and available for many cores.

Like for 2 cores processing:

static void resize_plane_c(EWAPixelCoeff* coeff, const void* src_, void* VS_RESTRICT dst_,
int dst_width, int dst_height, int src_stride, int dst_stride, float peak)
{
EWAPixelCoeffMeta* meta = coeff->meta;

const T* srcp = reinterpret_cast<const T*>(src_);
T* VS_RESTRICT dstp = reinterpret_cast<T*>(dst_);

src_stride /= sizeof(T);
dst_stride /= sizeof(T);

for (int y = 0; y < dst_height; y++)
{
// threads sync start point
//core 1 process
for (int x = 0; x < dst_width; x+=2)
{
const T* src_ptr = srcp + meta->start_y * static_cast<int64_t>(src_stride) + meta->start_x;
const float* coeff_ptr = coeff->factor + meta->coeff_meta;

float result = 0.f;

for (int ly = 0; ly < coeff->filter_size; ly++)
{
for (int lx = 0; lx < coeff->filter_size; lx++)
{
result += src_ptr[lx] * coeff_ptr[lx];
}
coeff_ptr += coeff->coeff_stride;
src_ptr += src_stride;
}

if (!(std::is_same_v<T, float>))
dstp[x] = static_cast<T>(lrintf(clamp(result, 0.f, peak)));
else
dstp[x] = result;

meta+=2;
}
// core 2 process (very close with x-coord to core 1 - so both cores will share almost same src_ptr[lx] memory area)
for (int x = 1; x < dst_width; x+=2)
{
meta++;
const T* src_ptr = srcp + meta->start_y * static_cast<int64_t>(src_stride) + meta->start_x;
const float* coeff_ptr = coeff->factor + meta->coeff_meta;

float result = 0.f;

for (int ly = 0; ly < coeff->filter_size; ly++)
{
for (int lx = 0; lx < coeff->filter_size; lx++)
{
result += src_ptr[lx] * coeff_ptr[lx];
}
coeff_ptr += coeff->coeff_stride;
src_ptr += src_stride;
}

if (!(std::is_same_v<T, float>))
dstp[x] = static_cast<T>(lrintf(clamp(result, 0.f, peak)));
else
dstp[x] = result;

meta+=2;
}
//threads end

dstp += dst_stride;
}
}


We can start profiling to look if current resampler in jincresize cpu-limited or memory-limited.

For mathematics it looks so:

Standard built-it old fast resampler in Avisynth and many other resamplers looks performs 1Dx1D convolution twice. And 'true-2D' resampler performs 2Dx2D convolution once. But 2Dx2D requires more MUL+ADD operations so it significally slower.

[jpsdr]

If i do a MT version, it will be like all the others : splitting image horizontaly.

[DTL]

If the full source plane for process will fit CPU cache it may be better in compare with different_thread_per_different_frame (as may be with MT-avisynth works). If not - it will creates as many memory read streams as threads count and user will see significant speed drop if processing input plane size > CPU cache size.

It looks the whole point of ResampleMT multithreading in compare with Avisynth-level MT is to make thread's processing pieces closer to each other in memory addresses space. The closest possible is neibour-samples processing.

" splitting image horizontaly."

May be an idea - at time of threads planning make compare of plane size against CPU cache size. If plane size < CPU cache size the threads planner may simply split image to N-threads parts. If input plane size is > CPU cache size so at first split input plane into number of parts like plane size / cache size and assign N-threads processing for each part sequentally.
May be because it may be hard to determine CPU cache size via API make separate user-defined parameter like CPU_cache_size (or may be better MAX_BLOCK_SIZE_FOR_MT). Because of different memory managers at different CPUs may be the optimal MT block size may be significally < CPU cache size. So user may determine the optimal size using tests at his hardware.

If user set too small MT block size it will got performance penalty because of too frequent threads start/stop/re-assigning new piece of work. If splitting image buffer horizontally to each thread workunit is measured in processing rows. May be allow user to determine max_thread_rows count. If undefined - threads planner as now calculated each_thread_rows = height/num_threads (i suppose). If defined - threads planner limit each_thread_rows to max_thread_rows and after (all ?) intial threads finishes - start new threads to process the remaining rows (blocks of remaining rows). The waiting for _all_ initial threads finishes before starting threads processing new rows blocks may be required for keeping current cached data unchanged (because new rows blocks required new memory reads). So it is also may be user-defined parameter - wait_for_all_threads_finish=yes/no.

2Dx2D convolution require many reads of input samples (I think as many as kernel_size^2 times) so will definately benefits from cached reads and may perform uncached writes to memory because output samples are never required for processing again (in compare with Avisynth 1Dx1D processing twice for resize). So if possible the ASM 2Dx2D convolution subroutines may be modified to use non-cached hinted write instructions and may be look into WinAPI for caching properties of memory pages.

[DTL]

edit: there are also JincResize maybe worth adding too

The more 'strategic' ideas:

Actually the 'linear math' resizers consists of 3 discrete and interconnected parts:

kernel_base x weighting/windowing x resampler

Typical kernel_base are sinc,gauss,linear,cubic, etc. Jinc is also only kernel_base function defined as 1D f(x)=BesselJ1(x)/x. Sinc is equal to spherical BesslJ0(x) as i wee from wiki.

Typical weighting/windowing is 'non' that is 'rectangular' 1-based window limiting 'width/size' of kernel and many more like 1 lobe of Sinc, Jinc, linear, trapecoidal and any other function typically =1 at zero(start) and fading to =0 at its weighting/windowing end.

The most typical resampler is separated vertical + horizontal processing (1Dx1D twice convolution of weighted kernel with input source), that is fast and gives some acceptable quality with 2D image processing. There is also may be more suitable for 2D image processing resampler as direct of 'full' 2D convolution, but it require more CPU operations and typically not/rarely used because it was too slow on old CPUs and also not very great even on 2020 CPUs. It gives only 'a bit better' quality (may be +20..30% by my taste at some (extreme) tests) in compare with much more faster V+H processing. The main difference is that 2D-convolution resampler allow equally good process all angles spatial frequencies and V+H resampler only good process vertical and horizontal. Though on many real practical (usually and not very sharp) images the difference may be not greatly visible.

So typically 'named' 'linear math' resizers are just named some combination of kernel_base and weighting like:
Lanczos = sinc kernel weighted by sinc
Gauss = gauss kernel non-weighted (rect weighted and with good self-weighting properties)
Sinc = sinc non-weighted
SinPow = sort of 'self-weighted'
And typically processed by V+H resampler.

Jinc as in that pluging is looks jinc weighted by jinc and processed by 2D-convolution resampler. It is because Jinc mostly benefits of 2D-convolution resampler though can also be kernel for V+H resampler (and produce close results to sinc-family resizers I think, especially with small taps value).

So the 'linear' resizer library may use just 'one' resize function (like that in z.lib) and just defines all 3 components of resize like kernel + weighting + resampler as arguments. And also for user-friendly looking may provide named functions like typical Bilinear/Lancsos/etc. Because it is hard to make all possible combinations of 3-parts as named - so for advanced users the one_for_all parametrized function is shorter.

So currently to add Jinc to ResampleMT plugin the 2D-convolution resampler must be added as the most hard part and also some kernel functions like jinc as kernel base and jinc as weighting (may be jinc weighted by jinc for beginning as 1 func). The kernel+weighting is the simpliest part because todays C-programming uses standard math library for both sin(x) and bessel*(x).

As i see image-processing software (advanced enough/for 'geeks') already uses command-line syntax for providing manual-input of kernel_base and weighting functions to resampler - I see it in imagemagic forums.

It is good to have in ResamplerMT to have ability also perform user-defined function calls for required combination of kernel + resampler or even kernel_base + weighting + resampler. Because most kernel functions are good applicable for both V+H and 2D-convolution resamplers with may be small parameters tweaking. 1D kernel for 2D-convolution I think is usually radius/distance-argumented rotation of 1D kernel around center point. i.e. (kernel_2D(x,y) = kernel_1D(sqrt(x^2+y^2))).

[DTL]

even this https://github.com/Asd-g/AviSynth-JincResize ?

There is a sample build of this plugin with internal multithreading by OpenMP https://forum.doom9.org/showthread.php?p=1930687#post1930687 . It MT only main frames processing loop so start time of preparing large full-frame coeff array is the same. And uses full-auto threading without manual control.

From my test it actually uses a bit less multi-core CPU (about 90%) in compare with Avisynth+ MT (100% CPU) and runs a bit slower. So there is not great advance for speed if using newer MT Avisynths. But it uses only one large array of coeffs for all threads processing so require much less memory in compare with Avisynth's frame-based MT. I beleive somedays it will be rewritten for small full cacheable LUT-based additive convolution approach instead of full-frame coeffs array mul+add. At least for integer ratio of scaling. So the large memory requirement for each frame-processing thread will be removed too.

[real.finder]

There is a sample build of this plugin with internal multithreading by OpenMP https://forum.doom9.org/showthread.php?p=1930687#post1930687 . It MT only main frames processing loop so start time of preparing large full-frame coeff array is the same. And uses full-auto threading without manual control.

From my test it actually uses a bit less multi-core CPU (about 90%) in compare with Avisynth+ MT (100% CPU) and runs a bit slower. So there is not great advance for speed if using newer MT Avisynths. But it uses only one large array of coeffs for all threads processing so require much less memory in compare with Avisynth's frame-based MT. I beleive somedays it will be rewritten for small full cacheable LUT-based additive convolution approach instead of full-frame coeffs array mul+add. At least for integer ratio of scaling. So the large memory requirement for each frame-processing thread will be removed too.

maybe jpsdr can make it MT in another way like by frame division "not just splitting image horizontaly" base on resize samples and taps with threads?

[jpsdr]

I don't know if i'll be working on this... For now, i've put an alt to coding in my spare time for others personnal projects.
Isn't "splitting image horizontaly" a "frame division" ?

[real.finder]

I don't know if i'll be working on this... For now, i've put an alt to coding in my spare time for others personnal projects.
Isn't "splitting image horizontaly" a "frame division" ?

it is, but I was mean as blocks, don't know if splitting image horizontaly will work with 2D resizes

[jpsdr]

While there is no feed back (you need some previous results to compute next result), you can divide however you want and do things in whatever order you want. Of course doing in a total random order will not be the most efficient/faster way. But I see no reasons why splitting horizontaly shouldn't work.

BTW, i meant "i've put an halt"...

[jpsdr]

New version, see first post.

[DTL]

it is, but I was mean as blocks, don't know if splitting image horizontaly will work with 2D resizes

As my current progress shows for real (possibly future main) multicores CPUs like 5..10+ cores and current slow progress with memory speed (also even SRAM cache L4..L3..L2) it is required to split task to much smaller blocks in compare with just horizontal stripes.

Splitting horizontaly is currently implemented even with small per-thread temp buf processing but it introduce some overhead in processing for correct align of edges of stripes.

Because the only cache that can feed FMA units at acceptable speed is L1. And because for 2D it is required to have in temp buf the number of rows and columns like taps*mul_ratio*2 it is not possible to fit to L1d even the minimum full rows required for process even FullHD.

Current versions of upsampler uses up to 50% of FMA CPU performance with 4 cores/threads but almost zero scaled in performance when executed on 10..20 cores CPUs.

So I think in the future try to use re-arrangement in memory the scan order of frame buf to significaly shorter lines/rows so several rows may fit in half of L1d cache.

Like 8K frame of 7680 samples per full scanline may be scanned to 10 of 768 samples per line vertical stripes. So each 10 sub-rows of stripe in float32 may fit in L1d cache. And processing core can have access to all required samples in vertical direction from L1d instead of about twice slower L2/L3.

This approach may completely ruine the simple auto-multithreading usind OpenMP and require to write own threads manager because the frame will be divided on a large enough number of workunits - much more in compare with available cores per execution.

Each small step to higher performance significally increases of complexity of program and also changing the scan order of frames in memory raises the global question to Avisynth core design: If the future of current computing hardware is only large number of multicoring with still slow memory it may be better to introduce new memory layout formats in addition to simple 'planar' - like 'multi-blocks' instead of simple full line scans. Or the each plugin will need to spend resources for pre and post re-arrangement in memory for currenlty used full frame line scans. But this require core and plugins to be re-written for support new scan formats.

[FranceBB]

Thanks for the new version! Downloading right now! :D

[guest]

New version, see first post.

So which one do I use for Windows 10, with some cpu's that don't support AVX ?? (eg:- Xeon X5690's)

Also, using RipBot264.

Cheers

[kedautinh12]

If your card don't support avx, avx2. You can use w7 ver

[guest]

If your card don't support avx, avx2. You can use w7 ver

Thanks for the info...but don't you mean cpu, not card ??

Cheers

[kedautinh12]

Sr, it's my mistake

[guest]

Sr, it's my mistake

No worries.

I just wanted to say thanks, your suggestion of which build to use, has solved the problem I was having with RipBot264.

I must have used the wrong one, when I updated this plugin, but since then there's been a newer build :)

Cheers

[jpsdr]

New version, see first post.

[FranceBB]

What a sweet surprise! Thanks! :D

[FranceBB]

Can NNEDI3 use all the cores with its multithreading up to 56c/112th?
Has Jean Philippe made the plugin_JPSDR in a way that it's able to scale enough with its thread pool?
Yes, yes it can! And yes, yes he has!! :D

Image Link (https://i.imgur.com/7EZeXKm.png)

(disclaimer: it's running through a service, triggered by a remote API, which is why you don't see the command line prompt in the picture)

[jpsdr]

It can...????
Ah yes... I've defined 128 as maximum possibles threads in my threadpool code.
The issue is in the "processor mask" part for eventualy attach the threads to processor given by system function is a 32 bits data, so, no idea how it behaves with more than 32 cores...
So, stay with standard default (false) setting for SetAffinity.

Maybe not finaly, i don't remember the size of ULONG_PTR...

I'll have to update my threadpool code, i never thought i see so much core, and if there is too much core (>64), bad things will happend, so, an update is needed before someone begin to test with too much cores... :D

[FranceBB]

It can...????


Eheheh I was surprised too xD



Ah yes... I've defined 128 as maximum possibles threads in my threadpool code.


Cool :D



So, stay with standard default (false) setting for SetAffinity.


Roger that.


I'll have to update my threadpool code, i never thought i see so many cores, and if there are too many cores (>64), bad things will happen, so, an update is needed before someone begin to test with too much cores... :D

Well, I'm afraid I don't have a 64c/128th Xeon even if I work at Sky; the best I can do for tests is 56c/112th, which is pretty remarkable anyway I think xD

[Atak_Snajpera]

Do you plan to add AMD FSR upscaling algorithm. IT is now open source.

[DTL]

AMD FSR is looks for creating more sharper edges for 3D-rendered content. https://gpuopen.com/fidelityfx-superresolution/ It looks GPU-dependent and even more - exact 3D-rendering engine dependent. Can it shows some tests on typical video content and with open-source example on CPU only ? Currently it looks not like open source universal programming-language algorithm but some open API for 3D GPU and dependent on other 3D API.
At 3D samples on that site it looks it may be dependent on 3D mesh and textures data non-existent in video input data for upscaling.

[Atak_Snajpera]

FSR is just another spatial upscaler. It just takes 2D image and upscales to higher resolution just like neddi. It does not require anything from game engine like DLSS.

FidelityFX Super Resolution is a spatial upscaler: it works by taking the current anti-aliased frame and upscaling it to display resolution without relying on other data such as frame history or motion vectors.

https://www.purepc.pl/image/news/2021/07/16_amd_fidelityfx_super_resolution_zostalo_upublicznione_dostep_do_techniki_bedzie_jeszcze_latwiejszy_wkrotce_wsparcie_w_unity_1_b.jpg

[DTL]

Best candidate for adding to Avisynth is software-only platform-independent open-source with appropriate licensing. And inside frame MultiThreading-friendly. If it is based of hardware only shaders execution on some AMD GPU products - it is unlikely.

[Atak_Snajpera]

Best candidate for adding to Avisynth is software-only platform-independent open-source with appropriate licensing. And inside frame MultiThreading-friendly. If it is based of hardware only shaders execution on some AMD GPU products - it is unlikely.

What are you talking about? It works on any GPU with FP32 units.

https://www.purepc.pl/image/news/2021/07/16_amd_fidelityfx_super_resolution_zostalo_upublicznione_dostep_do_techniki_bedzie_jeszcze_latwiejszy_wkrotce_wsparcie_w_unity_3_b.jpg

Besides CAS was also designed for GPU but CPU port for avisynth is available from some time
https://github.com/Asd-g/AviSynth-CAS

[jpsdr]

... Can you create a specific topic discussion instead of here...?

[jpsdr]

New version, see first post.

[FranceBB]

Thanks for the new version. :)

[subterrestrial]

Thank you. Now the crash problem in AVS+ 3.70 cuda version which occured when "SetDeviceOpt(DEV_CUDA_PINNED_HOST)" was put in script is solved.

[jpsdr]

Good to know. Without someone with a proper configuration (who can produce the crash) to confirm the crash doesn't occur anymore, i wasn't 100% sure.

[DTL]

Can you look at idea of linear UV resampling at RGB<->YUV_subsampled processing in https://forum.doom9.org/showthread.php?p=1950287#post1950287 and may be add this as functions to HDRtools or ResampleMT ?

As I understand currently ConvertYUVtoLinearRGB and backward automatically uses chroma upsample if 4:2:0 or 4:2:2 provided as YUV source. So may be add method of linear UV scaling instead of OETFed for ConvertYUVtoLinearRGB and backward. As an option to process.

Current scripting form may work significally slower. The demonstrated in scripting workflow uses both ResampleMT and HDRtools plugins.

[jpsdr]

Doing something like NNEDI3 is a total pain in the ***, it will add dozen of parameters, and will not be faster, because it will just call external resampler functions the exact same way your script is doing.
And it you're using more than one of my DLL, instead of loading each DLL for each filter, use the plugin pack. The way you're using, each DLL will create a threapool, which is a waste of resources.
Replace LoadPlugin("ResampleMT.dll")
LoadPlugin("HDRTools.dll") with LoadPlugin("plugins_JPSDR.dll")

[DTL]

The idea of resampling UV components in linear domain is not to be faster but to be less distortive. It is for perfectionists mostly and definitely will be more slow. It require much more matrix and OETF<->Linear transformations to allow recreation of UV planes in full size (equal to size of Y component) for last YUV->RGB matrix with less distortions. Yes - the decoder of 4:2:0 and 4:2:2 in this method is much more complex in compare with typical 'fast' approach. Though it is full-deterministic 'linear' processing without content/scene dependent like NNEDI.

I think the compiled form will be faster because eliminating 'CombinePlane' planes shuffling as separate function. Or it is very fast in compare with ConvertTo/FromLinear ? So it is better to form this processing as a script functions and put to some script library ?

[Dogway]

I had a look at this 2 months ago, there are several approaches like improved YUV conversions like YUVr (YUV RCT) or sYUV (Sharp YUV). I actually tried the one in this paper (https://norkin.org/pdf/SPIE_2016_HDR_conversion_metrics.pdf) but it looks like geared towards HDR, your approach seems similar. I will check it back again when working with TransformsPack.

[jpsdr]

@DTL
I think you miss my point. By not being faster i mean compiled form will realy not be faster than a script.
In NNEDI3 you can specify the resampler, but doing this add a lot of parameters to the filter, that's just what i meant.
Either HDRTools calls resampling functions, or the other way round. Anyway, it will be done by combining planes and calling external functions with Invoke anyway.
The script is the perfect solution, you can change the resamplers and their parameters, have different resampler for /2 and x2 if you want, change things easely, etc... instead of one filter with 100+ parameters...!
The filters allready have on their own a lot of parameters.

[FranceBB]

Question: would it be possible to make plugins_JPSDR numa nodes aware too? In other words, instead of using 1 CPU only in a multi socket configuration, allow the filters and their thread pool to make use of both CPUs in a multi socket environment.
The reason why I'm asking you this is this:

https://i.imgur.com/34NR70s.png

[kedautinh12]

Question: would it be possible to make plugins_JPSDR numa nodes aware too? In other words, instead of using 1 CPU only in a multi socket configuration, allow the filters and their thread pool to make use of both CPUs in a multi socket environment.
The reason why I'm asking you this is this:

https://i.imgur.com/34NR70s.png

Wow, we have rich boy here :D

[FranceBB]

Wow, we have rich boy here :D

Please, it's not properly "mine". It's a Sky (i.e Comcast) Avisynth Server ehehehehehehe

(check the picture, they're next to me)

https://i.imgur.com/6bfR1Vg.png

[jpsdr]

Sorry, no idea... In fact, i don't even know what this numa node is... :(
If you don't change SetAffinity, the OS will choose itself where to run threads.
But... Once you show us an almost 100% on 112 logical cores with NNEDI3, what changed ?
Anyway, you can try to set threads to 112.

[FranceBB]

Sorry, no idea... In fact, i don't even know what this numa node is... :(


Ah... :(


But... Once you show us an almost 100% on 112 logical cores with NNEDI3, what changed ?


I was setting threads to 112 manually.


Anyway, you can try to set threads to 112.


Yeah, that's what I used to do, however the cache is not shared between the two CPUs, so what happened was that it was indeed using 100% but the performance could be much higher if the program was numa aware.
Have you ever worked with dual socket motherboards?
So basically you have two independent CPUs and the OS assigns tasks to either one or the other CPU, however if the program is numa aware, basically it can make use of both CPUs at the same time. If you force a program to spawn across the two CPUs (so you set more threads than CPU cores of a single CPU), it will make use of the other CPU, but everything will be handled by the OS and the performance will be sub-par, especially during the software syncing part done by the OS.
If you're willing to look into this I can let you play with one of those 5 server.

[DTL]

May be it better to run 2 separated processes with 112/2 threads each. And assign each process to each node. And process 2 files instead of 1.

[FranceBB]

May be it better to run 2 separated processes with 112/2 threads each. And assign each process to each node. And process 2 files instead of 1.

That's also a possibility, but I'd still love to have the filters numa node aware for those times in which I need to encode a single file and I have a short deadline.

[ChaosKing]

Split clip in 2 parts and encode to a lossless video format first. Easy peasy.

[wonkey_monkey]

https://i.imgur.com/6bfR1Vg.png

I had hair like that once...




:(

[FranceBB]

I had hair like that once...

:(

Sorry to hear that, David... but hey, Jimmy Carr had a transplant and still looks ok, so maybe nothing is lost for you either ehehehehe

[jpsdr]

Never worked with several sockets motherboards, and, honestly, i thought that having 2 CPU with 4 cores or one CPU with 8 cores will be the same from OS point of view : The OS report that you have 8 cores...
I don't know very well some system parts, and the only way i know to get informations is what's in Get_CPU_Info in ThreadPool.cpp file. If doing this doesn't allow to have all the informations, unfortunately for now, i don't know what to do.

[tormento]

I don't know very well some system parts, and the only way i know to get informations is what's in Get_CPU_Info in ThreadPool.cpp file. If doing this doesn't allow to have all the informations, unfortunately for now, i don't know what to do.
First result (https://docs.microsoft.com/en-us/windows/win32/procthread/numa-support) on Google :p

[jpsdr]

Thanks.
It seems issue is when there is more than 64 cores... Maybe i'll take a closer look one day in the future, not interested right now to spend time on this.

[hello_hello]

jpsdr,

Did you happen to see my post in the ResampleMT thread?
In case you missed it.
https://forum.doom9.org/showthread.php?p=1954534#post1954534
I did some more testing and so far the "wrong cropping" only seems to apply to RGB24/32.

Cheers.

[jpsdr]

Finaly sooner than expected, new version, see first post.

[Ceppo]

Thanks for the plugin pack! Downloaded!

[FranceBB]

Thanks, as always, Jean Philippe! ;)

[jpsdr]

New version, see first post.

[jpsdr]

You can either see the formula used in the code, or read the pdf, i described the formula used.

[jpsdr]

Color=0,HDRMode=2, first, means it's HLG not normalised.
You have nominal_luminance=800 for avsresize so maybe you should set in my plugin HLGLw=800 as the default 1000 don't match, and check the default value of this parameter for fmtconv.
Also, as i'm not realy an HLG mode master, try also with Color=0,HDRMode=1.
So, my advice would bet to test these 2 settings : Color=0,HDRMode=2,HLGLw=800 and Color=0,HDRMode=1,HLGLw=800 for avsresize compare.

EDIT
Re-read my pdf, and linear RGB is direct E <-> E' by a simple EOTF function, and not affected by the HDRMode or HLGLw, you need HLGLw only for displayed linear, defaut setting of my plugin output scene linear light and scaled by camera exposure, normalized to the range [0.0:1.0]. Maybe the others plugin output the displayed linear...
In that case, try with OOTF=false, it will ouput the displayed linear data.
But in that case you have to put also OOTF=false in ConvertLinearRGBToYUV.

Otherwise, only left, read the code to check formula used.
I don't know what the others plugins output, neither what they expect in input. "linear", but wich one ? scene linear light and scaled by camera exposure or displayed linear ?

EDIT2
Should move eventualy to HDRTools related thread, as it seems specific to it.

[jpsdr]

New version, see first post.

[StainlessS]

Cheers J.

[FranceBB]

Thank you, Jean Philippe! :)
I'll update my farm at work as I get back after Thanksgiving. ;)

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[FranceBB]

Thank you! :D

[kedautinh12]

Thank you! :D

Carefull, some one video remind you increase post count without meaning post :D

[FranceBB]

Carefull, some one video remind you increase post count without meaning post :D

You mean Donald now-water-polo-manager-after-retiring Graft? xD
He knows me and I know him, we're fine considering that long time ago I paid for the DGDecodeNV license ehehehehehehe
Good luck to him and his water polo team, I guess.
I hope that coaching those guys gives him many more rewards than coding for a bunch of virtual users on Doom9 :P

Jokes aside, the only thing that changed in this version might just be a "silly" Avisynth header targeting 3.7.3, but Jean Philippe deserves all the thanks in the world for what he has done 'till now, especially with HDRTools (and to a lesser extent NNEDI3 as he is literally the only one who picked it up and prevented it from dying).

[kedautinh12]

I mean R***D*** :D

[guest]

You mean Donald now-water-polo-manager-after-retiring Graft? xD


So, what does that mean for all his "stuff" ??

[kedautinh12]

So, what does that mean for all his "stuff" ??

He update some stuff from here
http://rationalqm.us/board/viewtopic.php?f=5&t=463&sid=371cac0f28eb38899f583dc8fe9d6181

And his Tools and Utilities (old)
https://www.rationalqm.us/mine.html

[FranceBB]

So, what does that mean for all his "stuff" ??

He still updates his stuff, but only as a home user now, for the fun of it.
When I said "retired" I meant from his real job, not from the community. ;)
His hobby nowadays is coaching a water polo team and I wish him all the best. :)

[jpsdr]

New version, see first post.

[FranceBB]

Thanks to both Jean Philippe and whatever DTL's real name is xD
Looks like I'm gonna have something to try tomorrow morning at work. :)

[jpsdr]

New version, see first post.

[FranceBB]

Thanks for the update! :)
I'll test it tomorrow.

[hello_hello]

After spending forever trying to debug a resizing function, I discovered this...
So far it's the only resolution/cropping combination I've found that produces an incorrect result. I'm using version 3.3.5 of the plugins pack (64 bit).

ColorBars().KillAudio()
Spline36Resize(960,718)
Lanczos4ResizeMT(1280,716, 0,1,960,716)

Output 960x716 (screenshot half size)
https://i.ibb.co/sFV4d1v/Lanczos4-Resize-MT.png


ColorBars().KillAudio()
Spline36Resize(960,718)
Lanczos4Resize(1280,716, 0,1,960,716)

Output 1280x716 (screenshot half size)
https://i.ibb.co/0DRFvpH/Lanczos4-Resize.png

For reasons I don't understand, the ResampleMT result is correct for a YV12 source (but incorrect for YV24, YV16 and Y8).

ColorBars().KillAudio()
ConvertToYUV420()
Spline36Resize(960,718)
Lanczos4ResizeMT(1280,716, 0,1,960,716)

[jpsdr]

I don't have time for now, but i'll look at it when i'll have time.

[hello_hello]

I found another fun one.

The following produces the error message "Crop: you cannot use crop to enlarge or 'shift' a clip"

ColorBars().KillAudio()
Spline36Resize(1210,604)
Spline36ResizeMT(1208,600, 1,2,-1,-2)

[jpsdr]

One day, i'll try to look, but unfortunately right now i absolutely have no time... :(

[Guest]

One day, i'll try to look, but unfortunately right now i absolutely have no time... :(

FYI,

There is something very wrong, here :-

https://github.com/jpsdr/x265/releases/tag/3.50.116

[jpsdr]

Ouuups.... Thanks.

[Guest]

Ouuups.... Thanks.

You're welcome, but I have to ask, are you planning to add the --auto-aq command to a future build ??

I did just read the x265_Help.txt file and there's reference to --aq-auto, but I can't get it to work (process).

You've got --aq-mode 5...

Cheers

[jpsdr]

This is not realy the right place for x265.
Also, about --aq-auto, check here (http://forum.doom9.org/showthread.php?p=1998149#post1998149).

[tormento]

Merge of Avisynth's plugins
I saw that you don't include NNEDI3_weights.bin.

Isn't it necessary for your build?

[jpsdr]

@tormento
No, the neural network weights are included in the DLL, this is why the NNEDI3 dll is "so big".

[jpsdr]

After spending forever trying to debug a resizing function, I discovered this...
So far it's the only resolution/cropping combination I've found that produces an incorrect result. I'm using version 3.3.5 of the plugins pack (64 bit).

ColorBars().KillAudio()
Spline36Resize(960,718)
Lanczos4ResizeMT(1280,716, 0,1,960,716)

Output 960x716 (screenshot half size)
...
Fixed on github, new build soon (or you can make your build).

[StainlessS]

Thanks j, you be the man.
Mucho grassy ass.

[DTL]

Pinterf in the process of preparing big update to the very old AVS resampling engine - expected in the 3.7.4 release or next weeks. It will now have same quality in processing edges of the frame as fmtconv and other (like avsresize) and even finally stop emit errors like 'frame size too small for current resize support'. It is expected for updating in this plugins pack too. Also may be fixed other possible bugs.

[jpsdr]

Argh...
I have some requirements of my own i still keep, it's the fact that my filters can be build with VS 2010. If pinterf's updates don't break my rule, with time, i'll include them, but otherwise, it will stay at it is.

[tormento]

Pinterf in the process of preparing big update to the very old AVS resampling engine - expected in the 3.7.4 release or next weeks. It will now have same quality in processing edges of the frame as fmtconv and other (like avsresize) and even finally stop emit errors like 'frame size too small for current resize support'. It is expected for updating in this plugins pack too. Also may be fixed other possible bugs.
What about chroma position when downscaling? AFAIK AVSResize only is capable of giving good and reliable results, as per Resize8 thread.

[DTL]

What about chroma position when downscaling? AFAIK AVSResize only is capable of giving good and reliable results, as per Resize8 thread.

Can you provide some test scrips to show the difference in processing between AVSresize resampler and AVS+ core resampler for that differences ? And mark or describe where to look for difference.

[jpsdr]

Pinterf in the process of preparing big update to the very old AVS resampling engine - expected in the 3.7.4 release or next weeks. It will now have same quality in processing edges of the frame as fmtconv and other (like avsresize) and even finally stop emit errors like 'frame size too small for current resize support'. It is expected for updating in this plugins pack too. Also may be fixed other possible bugs.

After a little thought, i don't see why there should be any change in the core engine for the edge frame, the structure coefficients (pixel_coefficient[] and pixel_offset[]) and the functions in resample_avx2 and resample_sse shouldn't change.
Only the computation of the coefficients around the edge position in ResamplingFunction::GetResamplingProgram will change to have better result.
If it's only that (and i think it should be), there is a big chance i'll be able to update...;)
If not and everything is redonne, there is a big chance i'll unfortunately not update...:(

[tormento]

Can you provide some test scrips to show the difference in processing between AVSresize resampler and AVS+ core resampler for that differences ? And mark or describe where to look for difference.
The discussion is part of the Resize8 (https://forum.doom9.org/showthread.php?t=183057) thread.

[DTL]

The discussion is part of the Resize8 (https://forum.doom9.org/showthread.php?t=183057) thread.

You may try latest testbuild with different chroma placement options and make report if it solve that issues: https://github.com/AviSynth/AviSynthPlus/issues/431#issuecomment-2745886159

New Parameters:

"placement": Specifies chroma placement, with options such as "auto", "mpeg2", "center", etc.,
similar to ConvertToXXXX and Text. The default is "auto", which reads the frame property
_ChromaLocation for 420, 422, and 411 formats.

"keepc" (boolean, default: true): Determines whether to "keep center".
If true, the chroma shift from "placement" is now considered when resizing chroma.

GaussResize(width3, height3) # keepc=true, placement="auto"
GaussResize(width3, height3, placement="auto") # the new default, read frame props
GaussResize(width3, height3, placement="bottom") #center, top, etc visible differences in chroma
GaussResize(width3, height3, placement="center") #legacy Avisynth worked like this
GaussResize(width3, height3, keepc=false) #dont keep pixel center, not even for the luma

[tormento]

You may try latest testbuild with different chroma placement options and make report if it solve that issues
My fault, I have not explained things clearly.

Resize8 applies different scaling to chroma and luma channels to keep as much data as possibile, i.e. if you resize 1920p to 1280p it's stupid to apply the same ratio to chroma, as you will lose a lot more information than differently resizing chroma (which already is 960p) and luma.

The problem that now arises is to find the correct chroma shift to adapt the differently resized chroma to luma.

The author of Resize8 found that AVSresize is the only resizer that fit that job correctly. That's why I told you to read that thread.

I have not enough knowledge to test and understand if a separate resize produces a correct chroma placement. :p

[DTL]

" if you resize 1920p to 1280p it's stupid to apply the same ratio to chroma, as you will lose a lot more information than differently resizing chroma (which already is 960p) and luma."

It can work good only if you go from typical 4:2:0 broadcast and delivery to the more rare 4:4:4 format. If you keep chroma subsampling mode at the output - typically the chroma downscale ratio must match the luma.

Though chroma-subsampled formats are non-linear and ugly by design and it is required something like neural-network aided rescale to make artifacts lower. Same as we have in NNEDI resize for upsample aliased fields from interlaced frames. The neural network looks like was trained on the typical aliasing artifacts of the fields and now create more pleasing resuilts.

Same way someone need to invest in the neural network traning on the 4:2:0 chroma subsampling artifacts and make finally better and NN-assited decoder of 4:2:0 color into RGB with less distortions. Chroma placement is not the only issue in these color formats.

Also possible unlimited number of non-linear resampling methods for such lossy formats and each may have its strong and weak parts.

[tormento]

It can work good only if you go from typical 4:2:0 broadcast and delivery to the more rare 4:4:4 format.
That is really trivial for 420 to 444 at half resolution.

On other cases, such as resizing 1080p to 720p (with source 420, i.e. y=1080p, u=540p, v=540p), you can have a dumb and a smarter one.

With a "stupid" resizer, it would apply the same ratio to all three planes:

y 1080*2/3 = 720p
u 540*2/3 = 360p ---> to upscaler
v 540*2/3 = 360p ---> to upscaler

leaving to you to increase in some way or another the chroma from 360p (and you have already lost some data) to 720p.

when instead a "smart one" you would apply the full resize to luma only, upscaling proportionally the chroma channels with a different coefficient, losing nothing:

y 1080*2/3 = 720p
u 540p ---> directly to upscaler
v 540p ---> directly to upscaler

There is more data in 540p than starting from 360p.

At least that is the idea behind Resize8 and what I'd like to see applied to general resizers in AVS+.

[DTL]

Core resizers do not change chroma subsampling. To downsize with conversion from 4:2:0 to 4:4:4 you can use a sequence
ConvertToYUV444() (upsize uv from 540p to 1080p - set the kernel and its params as you like more in your workflow, only UVs will be upsized)
Resize(to720p) (downsize yuv 1080p to 720p - also set kernel as you like)

And you will get chroma with better bandwidth without going to 360p.

Other possible way - separate to Y and UV and downsize Y from 1080p to 720p and upsize UVs from 540p to 720p and combine planes. Each plane will be processed only once. It may give better quality. You can compare what way make better yuv 4:4:4 720p for your content.

AVS core do not have single filter call like ResizeAndConvertTo444(). It need at least dual kernel setup params for each operation.

[tormento]

Core resizers do not change chroma subsampling.
I know and that is what I am doing already.

The question about "positioning" is not about chroma subsampling but how much to shift the planes each other not to have a mess.

I once read -0.5,0.5 pixels for half resolution but I have no idea about the value for not half resolutions.

[jpsdr]

New version, see first post, but as said in resampler thread, resamplers are not updated to the new core in this version.

[jpsdr]

New version, see first post.

[jpsdr]

Hi.
New version, see first post.

[FranceBB]

Thank you for the new build.
No issues so far with the new resizers on Windows XP Professional x86 nor Windows 10 Professional x64.
Given that XP is up to SSE4.2 I didn't expect anything to happen anyway, so the real test for the new AVX2 was on Windows 10, but the output was identical. :)


#AVX2
SetMaxCPU("AVX2")
ColorBars(1920, 1080, pixel_type="YV24")
SinPowResizeMT(1024, 576)


https://i.imgur.com/Ncv0TqG.png


#Plain C++
SetMaxCPU("none")
ColorBars(1920, 1080, pixel_type="YV24")
SinPowResizeMT(1024, 576)


https://i.imgur.com/9iJ43ll.png


Testing the results:


plain=ImageSource("A:\MEDIA\temp\New File (1)000001.png")
avx2=ImageSource("A:\MEDIA\temp\New File (1)000000.png")

Subtract(plain, avx2)


https://i.imgur.com/Wmtm8ss.png

And sure enough SSIM says 1.0 for Y, U, and V, thus confirming that they're exactly the same output. Very well done, as always. :)


plain=ImageSource("A:\MEDIA\temp\New File (1)000001.png").Converttoyv12()
avx2=ImageSource("A:\MEDIA\temp\New File (1)000000.png").Converttoyv12()

SSIM(plain, avx2, "A:\MEDIA\temp\results.csv", "A:\MEDIA\temp\globalSSIM.txt", lumimask=2, scaled=1)


https://i.imgur.com/wvjFOXE.png

[jpsdr]

There is also the script of DTL:

Loadplugin("ResampleMT.dll")


Function Diff(clip src1, clip src2)
{
return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

AddBorders(2, 2, 2, 2, r=2, param1=8)

pad=50

std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)

mt=LanczosResizeMT(width*2, height*2, taps=16).Subtitle("ResampleMT 2xLanczosResize taps=16", align=5)

d1 = Diff(mt,std)
d2 = Diff(mt,std)

StackHorizontal(StackVertical(std, mt), Stackvertical(d1, d2))

[StainlessS]

There is also the script of DTL:

Loadplugin("ResampleMT.dll")


Function Diff(clip src1, clip src2)
{
return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

AddBorders(2, 2, 2, 2, r=2, param1=8) # What is this ? Not on Wiki

pad=50 # Un-Used

std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)

mt=LanczosResizeMT(width*2, height*2, taps=16).Subtitle("ResampleMT 2xLanczosResize taps=16", align=5)

d1 = Diff(mt,std)
d2 = Diff(mt,std)

StackHorizontal(StackVertical(std, mt), Stackvertical(d1, d2))


Does "ResampleMT" re-define AddBorders() with extra args r and param1 ?
I have not been following (much) this thread, and it dont look right.

[jpsdr]

This will work both AVS & AVS+.

Function Diff(clip src1, clip src2)
{
# return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
return Subtract(src1,src2).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

#AddBorders(2, 2, 2, 2, r=2, param1=8)
AddBorders(2, 2, 2, 2)

pad=50
Subtitle("Resample test", align=5)

#std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)
std=LanczosResize(width*2, height*2, taps=16)#.Subtitle("Resample test", align=5)

#mt=LanczosResizeMT(width*2, height*2, taps=16).Subtitle("ResampleMT 2xLanczosResize taps=16", align=5)
mt=LanczosResizeMT(width*2, height*2, taps=16)#.Subtitle("Resample test", align=5)

d1 = Diff(mt,std)
d2 = Diff(mt,std)

StackHorizontal(StackVertical(std, mt), Stackvertical(d1, d2))

[tormento]

Could you please add AVX or at least SSE build to EEDI3CL-1.1.0?

As far as I can see from the dll names, they are AVX2 or AVX512 only.

Thank you!

[jpsdr]

EEDI3CL-1.1.0 is not one of my filters, so i can't do anything about it.

[StvG]

Could you please add AVX or at least SSE build to EEDI3CL-1.1.0?

As far as I can see from the dll names, they are AVX2 or AVX512 only.

Thank you!

Did you actually try them? The names are saying which one should be faster for specific CPU instructions not that they require the specific instructions.

[tormento]

EEDI3CL-1.1.0 is not one of my filters, so i can't do anything about it.

LOL, sorry. Don't know what happened to the mess we call brain.

Yesterday, I think I'd better stay in bed. :o

[jpsdr]

New version, see first post.

[FranceBB]

Thank you for the new release.
As always, it works fine on Windows XP. :)

[DTL]

r=2, param1=8) # What is this ? Not on Wiki

Wiki is slow in updates - the latest documentation is https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/addborders.html

[FranceBB]

Wiki is slow in updates

if you don't have an account and you're having issues creating one, ask Wilbert, I'm sure he's gonna help you. By the way, I've seen the updates about the new resizers and I will add them to the wiki, eventually. I just need to find the time.

[jpsdr]

New version, see first post.

[FranceBB]

I love seeing HDRTools_AVX512_asm_x64.asm and nnedi3_asm_AVX512_x64.asm in there.
Manually written assembly in AVX512 for tonemapping and NNEDI3 feels like a dream. :D
I gotta perform some benchmarks now, but thank you so much for this, Jean Philippe!

By the way, I've updated the wiki to reflect the changes http://avisynth.nl/index.php/Nnedi3/nnedi3_rpow2 as int opt = 0 can now go all the way up to 8 rather than 7.


int opt = 0
Sets which CPU optimizations to use. Possible settings:
0 = auto detect
1 = use C
2 = use SSE2
3 = use SSE4.1
4 = use AVX
5 = use AVX2
6 = use FMA3
7 = use FMA4
8 = use AVX512


as per https://github.com/jpsdr/plugins_JPSDR/commit/fce98309da3aa1942852dad7f66e3b115c75934a and https://github.com/jpsdr/plugins_JPSDR/blob/30f87b61016a4c15218e4b507fcd57803b632cd2/Plugins_JPSDR/nnedi3.cpp#L469

[jpsdr]

For tonemapping, i've updated to AVX512 the AVX2 code, and there is very few things finaly in the AVX2.
... I just realized that maybe because a lot of things where either lookup table or float, if there is so few AVX2 maybe it's because a lot of things are AVX, as YMM float registers and functions are AVX not AVX2...
I'll have to check this and maybe the asm AVX512 will grow bigger... :D
For now, there is only Convert_16_RGB64_HLG_OOTF and BT2446C_16_XYZ, almost nothig.
Wait another release if you want to benchmark tonemap, but NNEDI3 is good to go. I've updated everything i could (some are left AVX2 because i didn't understood properly and wasn't sure), but the core and the most important is done.

[jpsdr]

New version, see first post.

[jpsdr]

New version with a newcommer, see first post.

[FranceBB]

The XP build of v4.0 isn't working on Windows XP Professional x86 as it's missing InitializeCriticalSectionEx and LCMapStringEx.
XP has InitializeCriticalSection and LCMapStringA but not the Ex version as those were introduced with Windows Vista.
https://i.imgur.com/YyD8ljf.png


Reverting to version 3.9 works and doesn't show any issues in Dependency Walker.
https://i.imgur.com/b9GdBl2.png
https://i.imgur.com/PshNyOZ.png

[jpsdr]

Ah... I'm not sure i'll be able to fix this, as i didn't change anything in the compiler options... Except maybe allowing C++17... And i'm not even sure about this.
I'll check...

Edit:
I don't have an XP to test, are the following working ?
- The JincResizeMT release.
- The last ResampleMT release.

Edit2:
This feedback may help me to figure out, for now i have no idea why it suddenly changes, as i didn't change the compiler neither the options... :(

[FranceBB]

I've made a few tests and it turns out it's related to JincResize.
I went to asd's repository and re-compiled the original JincResize with v141_xp and /Zc:threadSafeInit- using Visual Studio 2022.
Unfortunately that didn't help and it still didn't run.
In other words, the culprit seems to be JincResize, but I can't figure out *what* in JincResize is causing this. :(

[DTL]

Try to disable OpenMP in compiler settings. Also you need old enough version used OpenMP instead of new C++ multithreading. Or you can test even more old version without internal multithreading (no threads param).

[jpsdr]

@FranceBB
Thanks for testing. I had a guess it could be JincResizeMT as it was the big new change, but without being sure.
I've pushed a small update on JincResizeMT, if you can do the following tests on what i've pushed:

Step 1 :
On both JincResizeMT.cpp and resize_plane_avx2.cpp comment #include <cmath> and #define C17_MATH_ENABLE.
Build, test. If issue is solved, stop here.

Step 2 :
On JincResizeMT.cpp comment #define AVX512_BUILD_POSSIBLE and on resize_plane_avx512.cpp replace #if _MSC_VER >= 1911 with #if 0
Build, test. If issue is solved, stop here.

Step 3 :
On JincResizeMT.cpp comment #define AVX2_BUILD_POSSIBLE and on resize_plane_avx2.cpp replace #if _MSC_VER >= 1800 with #if 0
Build, test.

[DTL]

Also about multithreading settings at C compiler may be tested 2 ways:
C Runtime Library Selection:

/MD (Multi-threaded DLL):
This option links your DLL with the multithread-specific and DLL-specific version of the runtime library (e.g., MSVCRT.lib for release, MSVCRTD.lib for debug). This is generally the recommended approach for DLLs as it allows sharing a single instance of the CRT across multiple modules.
/MT (Multi-threaded):
This option links your DLL with a static version of the multithreaded runtime library (LIBCMT.lib). While possible, it can lead to issues if the executable using the DLL is linked with a different CRT version, potentially causing problems with memory allocation or file handles.

CriticalSections is something around threads synchronization in multithreading and usage these .dlls may depend on the used multithreading options in the executable.

[jpsdr]

/MT locks you with the version of redistributable linked.
/MD allow user to update the version of redistributable, so i'm using it, except for the XP release to be sure the version is XP compatible.

[FranceBB]

Try to disable OpenMP in compiler settings.

Done and tested. By the way, I always build with /MT as I prefer to statically link instead of using whatever C++ Redistributable is installed as I find it easier to debug.

Anyway, this led me to the following test where test 0 is DTL's suggestion while test 1 to 3 are Jean Philippe's suggestions.

Mini spoiler: all of them work on XP. :D
In other words, the culprit was OpenMP, which is why adding /openmp- did the trick. :)

Test 0:
v141_xp /openmp- /Zc:threadSafeInit-
code as is

XP x86 Build: JincResizeMT_Test0_x86.dll (https://github.com/FranceBB/JincResizeMT/releases/download/1.1.0.0/JincResizeMT_Test0_x86.dll)

https://i.imgur.com/RNgP8en.png
https://i.imgur.com/1MoIAyx.png

Test 1:
v141_xp /openmp- /Zc:threadSafeInit-
JincResizeMT.cpp

//#include <cmath>
//#define C17_MATH_ENABLE

resize_plane_avx2.cpp

//#include <cmath>
//#define C17_MATH_ENABLE

XP x86 Build: JincResizeMT_Test1_x86.dll (https://github.com/FranceBB/JincResizeMT/releases/download/1.1.0.0/JincResizeMT_Test1_x86.dll)

https://i.imgur.com/PalRhnW.png
https://i.imgur.com/WQJ3Zx1.png

Test 2:
v141_xp /openmp- /Zc:threadSafeInit-
JincResizeMT.cpp

//#include <cmath>
//#define C17_MATH_ENABLE
//#define AVX512_BUILD_POSSIBLE
resize_plane_avx2.cpp

//#include <cmath>
//#define C17_MATH_ENABLE

resize_plane_avx512.cpp

#if 0


XP x86 Build: JincResizeMT_Test2_x86.dll (https://github.com/FranceBB/JincResizeMT/releases/download/1.1.0.0/JincResizeMT_Test2_x86.dll)

https://i.imgur.com/XvDbTMV.png
https://i.imgur.com/knCcUy6.png

Test 3:
v141_xp /openmp- /Zc:threadSafeInit-
JincResizeMT.cpp

//#include <cmath>
//#define C17_MATH_ENABLE
//#define AVX512_BUILD_POSSIBLE
//#define AVX2_BUILD_POSSIBLE

resize_plane_avx2.cpp
//#include <cmath>
//#define C17_MATH_ENABLE
#if 0
resize_plane_avx512.cpp

#if 0


XP x86 Build: JincResizeMT_Test3_x86.dll (https://github.com/FranceBB/JincResizeMT/releases/download/1.1.0.0/JincResizeMT_Test3_x86.dll)

https://i.imgur.com/EYiEeIb.png
https://i.imgur.com/aKzpNex.png

[jpsdr]

Ok. When back home, I'll check in my project configuration if OpenMP is enabled for XP builds. If it is, i'll disable it, and culprit is found also on my side.

[StainlessS]

@FaBB,

In UK, all I get is "Content Not viewable in you region" for your images [not just in this thread, all over the place recently].

[You still in "Royal Borough of Kensington & Chelsea, UK" ???]

[FranceBB]

Ok. When back home, I'll check in my project configuration if OpenMP is enabled for XP builds. If it is, i'll disable it, and culprit is found also on my side.

Ok, thank you. :)


In UK, all I get is "Content Not viewable in you region" for your images [not just in this thread, all over the place recently].

[You still in "Royal Borough of Kensington & Chelsea, UK" ???]

I am, but I'm using a VPN to "pretend" to be in the U.S.
Until Labours are gonna ban those as well to "protect the children", that is.

I'm gonna quote myself from the other post


p.s for those in the UK, if you can't see the images, it's because of Captain Hindsight's online safety bill as imgur is no longer available and yet another service caught in the crossfire. Say thanks to Labours and Sir Keir Starmer I guess.

This is a problem 'cause I've been using imgur to host all my pictures since 2013. Migrating all of those is gonna be extremely painful. And yes, when I'm at work and I'm using the real IP address I also get the "not available in your region" message of course. At home I've set up a router with OpenWRT (i.e a linux distro for routers) that offers a VPN via Wireguard to all my devices connected to the Wi-Fi. It also exposes a separate Wi-Fi network that uses my real IP when I have to connect to the BBC iPlayer, ITV, Channel 5 etc.

[DTL]

It looks openmp support left enabled from the old times of JincResize plugin in Asd-g repository - https://github.com/jpsdr/JincResizeMT/blob/841f9a78ec55b098927d09aa561745eadff05659/JincResizeMT/JincResizeMT.vcxproj#L144 . New versions do not use it.

[jpsdr]

@FranceBB
It's odd... OpenMP was enabled in my ResampleMT and JincResizeMT projects, but not in plugin_jpsdr project. So either i've build plugin_jpsdr with OpenMP and disabled it since, or there is still something else.
Can you PM me an email address i can send you XP build, to be sure ? The one i have seems to be not working anymore.

[FranceBB]

Can you PM me an email address i can send you XP build, to be sure ?

I sent you a message, but if you want you can just upload the build anywhere on your FTP and I'll grab it from there (my login still works). ;)

[jpsdr]

Done on FTP, forgot you had this one.
Tell me when retrieved and test result.

[FranceBB]

Done on FTP, forgot you had this one.
Tell me when retrieved and test result.

Unfortunately it's not working.
It's complaining about the following two kernel calls missing:

LCMapStringEx
InitializeCriticalSectionEx

same as before.
Are you absolutely sure that you used /openmp- /Zc:threadSafeInit- in v141_xp?


In my other tests:

- HDRTools v1.2.0 -> ok
- NNEDI3 v.0.9.4.67 -> ok
- AutoYUY2 v.4.1.11 -> ok
- aWarpSharpMT v.2.1.11 -> ok
- ResampleMT v.2.9.0 -> error

So it has to be ResampleMT due to JincResize, but we solved JincResize, so...

[jpsdr]

Are you absolutely sure that you used /openmp- /Zc:threadSafeInit- in v141_xp?

Yes, i've checked them before building.
/Zc:threadSafeInit- is present in XP builds since the begining of times, and in "langage" in the projet i have "Disable OpenMP", which produces /openmp-.
I'm not able to figure out what have changed in the project settings since the last build, as I don't remember even doing modifications in the project settings (don't remember doesn't mean not doing...).

And JincResizeMT is not in ResampleMT, but both had OpemMP.

Can you compress/7z your whole (cleaned up before) project and put it on the FTP ? (You have write access, but not delete).
I'll try to open it and check if i can figure out the differences. What Visual Studio version are you using ?

[jpsdr]

@FranceBB
I will, not right now, but soon, make a new release (as there was some JincResizeMT changes), so if you have time within the next days to compress/7z your whole (cleaned up before) project and put it on the FTP, this will allow me to check vs my project, and maybe figure out what setting creates the problem.

[FranceBB]

@FranceBB
I will, not right now, but soon, make a new release (as there was some JincResizeMT changes), so if you have time within the next days to compress/7z your whole (cleaned up before) project and put it on the FTP, this will allow me to check vs my project, and maybe figure out what setting creates the problem.

I've uploaded it to the folder, but that's only JincResizeMT. I've downloaded the latest master of plugins_JPSDR. I'm gonna compile and test in the next few days. If it works, I'll add that one to my folder in the FTP too.

[jpsdr]

Ok, i'll get it when back home this evening. The first thing i'll do, it's just to compile your project without changing anything, to see if it's something related with my PC and not the settings (i hope it's not).
I'll also put my plugins_JPSDR project, for you to check to build without changing anything, to also see if it's related to the settings.
Without changing anything may have an exception, the windows SDK target build, you may have to convert to match your Visual Studio version for the project, but... It shouldn't affect the XP target build, which are to v141_xp, and these shouldn't change even after conversion to match for the rest of the project.

[jpsdr]

@FranceBB
I've tried to build your project, but it failed saying that fabs is not part of std.
I've put on the server, for both plugins_JPSDR and JincResizeMT, my projects.
But i've noticed something.
Can you try to build, in Code generation, with and without QPar ("Parallel code generation") ?

[FranceBB]

I've compiled JincResizeMT with and without QPar and uploaded the .dll to the FTP.
Both builds work and don't have any issues on XP.

[jpsdr]

So, that's not it... :(
Did you use my projects ?

[FranceBB]

Did you use my projects ?

Yep I did. I'll try to compile plugins_JPSDR too next and see how it goes (currently Crowdstrike - yes the bluescreen company - is giving me a hard time on Windows 11 as it keeps blocking random stuff, but I'll try to do it soon).

[jpsdr]

You mean you used my project to build JincResizeMT and it worked ? Good to know ! In that case, this evening when back home i'll put a build of JincResizeMT made by me on the server.
In the meantime, if you can try to build plugins_JPSDR and check, this will allow to assert the following situations :
(a) : Is JincResizeMT working build on your side and on my side ?
(b) : Is plugins_JPSDR working build on your side ?
The "best" case would be that JincResizeMT is working with both build, but plugins_JPSDR don't. That would mean that i've "just" to find the setting there is in one there is not in another which creates the issue.
The worst case would be that when you build my project, it works, and when i build the exact same project, it doesn't. I would have no idea how to solve this case.

[jpsdr]

I've made a build of JincResizeMT on the server for you to test.

[FranceBB]

Unfortunately that didn't work, so we're in the "worst" possible scenario. :(
It's still complaining about InitializeCriticalSectionEx and LCMapStringEx.

Are you also using Visual Studio 2022 to build those or is it an older version?
Perhaps there's some difference in the .sln between the two versions even if the settings are the same?
I really don't know.

[jpsdr]

No, i'm using Visual Studio 2019, my dev PC is Windows 7 x86, so having Visual Studio 2022 is not possible.
What i don't understand also, it's why it "suddenly" stopped to work. I mean, until now, my XP builds were working, and suddenly, they don't.
I'm lost... I'll try chat GPT, without big hope.
Unfortunately for now i don't have a solution, except for you to make your own builds. :(

[jpsdr]

Chat GPT provided me some things to check, i don't know if it will work, i'll check this WE.
In the meantime, when you'll have time, can you do the following when doing your build:
In "Projet property > Linker > Command Line > Additional Options", can you add "/VERBOSE:LIB" ?
Build, and post the result here ?
In the meantime, this evening when back home i'll try (but no big hope) something else.

[DTL]

You may try to install Win XP on a virtual PC software emulation to check builds. Or even try to analyse dependencies with appropriate software.

[jpsdr]

Euh... ... ... ...

[DTL]

It's still complaining about InitializeCriticalSectionEx

Google AI wrote:
Understanding the Issue:
InitializeCriticalSectionEx is a function introduced in later versions of Windows (Vista and newer) as an enhanced version of InitializeCriticalSection. Windows XP does not natively support InitializeCriticalSectionEx. If a Visual Studio project is compiled with a target platform that uses this function, the resulting executable will fail to run on Windows XP, reporting a missing DLL or entry point error related to KERNEL32.dll or similar.

Solution:
To build a Visual Studio project that is compatible with Windows XP and avoids the InitializeCriticalSectionEx error, the following steps are necessary:
Target Windows XP in Project Settings:
Open your project in Visual Studio.
Right-click on the project in Solution Explorer and select "Properties".
Navigate to "Configuration Properties" > "General".
Set "Platform Toolset" to a version that supports Windows XP. For example, v140_xp (Visual Studio 2015) or v120_xp (Visual Studio 2013). If using an older Visual Studio, ensure the target platform is set to Windows XP.
Set "Windows SDK Version" to an older SDK that supports Windows XP, if applicable.
Avoid Modern API Functions:
Review your code for any direct or indirect calls to functions introduced after Windows XP, such as InitializeCriticalSectionEx.
Replace these calls with their older, Windows XP-compatible counterparts. For InitializeCriticalSectionEx, use InitializeCriticalSection instead.
If using third-party libraries, ensure they are also compiled with Windows XP compatibility in mind or use versions that do not rely on newer API functions.

May be current builds uses some other libraries and they try to load that absent function ? But if you dependency check software shows JincResizeMT.dll directly want to load InitializeCriticalSectionEx from kernel32.dll - it mostly probably mean C compiler for some reason really put this call in the JincResizeMT.dll directly.

Also a quick way to check .dll for this function - simply load in the text editor (or better binary file viewer) and check if it have this text string - InitializeCriticalSectionEx .

I download current sources of JincResizeMT and make release builds with VS2019 - x64, x32 Win XP (v141_xp). No one version of .dll have InitializeCriticalSectionEx string and no such string present in the sources. Only InitializeCriticalSectionAndSpinCount.

I download plugins version 4.0.0 and sources and unzip:
InitializeCriticalSectionEx text sequence only found in the Release_XP_XXX folders .dlls . No other builds have it. Strange. Also sources do not have it too. Compiler get somewhere call to (or dependency to load) for InitializeCriticalSectionEx function and add to .dll .

Here is settings for x32 WinXP build in VS2019
https://i.ibb.co/VWcdvbBb/vs2019-settings01.png (https://ibb.co/d0wSQXKX)
Windows SDK for XP builds only available 7.0 or 8.1.

One more possible solution - make a fresh install of VS2019 on a new clean Windows ? In the virtual box PC emulator may be (but it is slow to HDD).

[jpsdr]

Can you do de /VERBOSE:LIB and post your results ?

[FranceBB]

Google AI wrote:


Useless AI slop as always.
One of the good things about Doom9 is that it's free from the slop, I love talking to fellow users like you and Jean Philippe. :)


Compiler get somewhere call to (or dependency to load) for InitializeCriticalSectionEx function and add to .dll .


Yeah, it's definitely the compiler getting it wrong due to some settings 'cause nothing in the actual source code has any issues, which is also why when I made the builds with /openmp- /Zc:threadSafeInit- it worked.


Here is settings for x32 WinXP build in VS2019
https://i.ibb.co/VWcdvbBb/vs2019-settings01.png (https://ibb.co/d0wSQXKX)
Windows SDK for XP builds only available 7.0 or 8.1.


Good idea showing the screen.
Here are mine producing working builds:

https://i.postimg.cc/nzZzKxvZ/2.png

and here's a view of the various menus:

https://i.postimg.cc/sxLsLCZc/1.png



In "Project property > Linker > Command Line > Additional Options", can you add "/VERBOSE:LIB" ?
Build, and post the result here ?


No problem, here:


Build started at 6:37 PM...
1>------ Build started: Project: JincResizeMT, Configuration: Release_XP Win32 ------
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v150\Platforms\Win32\PlatformToolsets\v141_xp\Toolset.targets(39,5)
1>
1>Searching libraries
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1>
1>Finished searching libraries
1> Creating library C:\Users\FranceBB\Desktop\JincResizeMT\JincResizeMT\Build\Release_XP\JincResizeMT.lib and object C:\Users\FranceBB\Desktop\JincResizeMT\JincResizeMT\Build\Release_XP\JincResizeMT.exp
1>
1>Searching libraries
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1>
1>Finished searching libraries
1>Generating code
1>0 of 379 functions ( 0.0%) were compiled, the rest were copied from previous compilation.
1> 0 functions were new in current compilation
1> 0 functions had inline decision re-evaluated but remain unchanged
1>Finished generating code
1>
1>Searching libraries
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1>
1>Finished searching libraries
1>
1>Searching libraries
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1>
1>Finished searching libraries
1>JincResizeMT.vcxproj -> C:\Users\FranceBB\Desktop\JincResizeMT\JincResizeMT\Build\Release_XP\JincResizeMT.dll
1>Done building project "JincResizeMT.vcxproj".
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 6:37 PM and took 05.503 seconds ==========


results also in the FTP.

[jpsdr]

Good tips DTL the hexa search string, it avoid me to bother FranceBB for testing.
Short version, i have multiboot, i tried with the other OS (Win7 x64) having a different VS2019 version, same issue. So a different environment produces the same result. It must be related to my maintenance/update, but don't know which one.

You have like me some .lib not in the 7.1A linked, so it's not this... But maybe...
You have 14.16.27023 when i have 14.29.30133.
And you also have libucrt not from 7.1A, not this one also...

Just made a build with /VERBOSE:LIB of release Windows 7.
This time i see .lib linked to SDK 10, and others to the same 14.29.30133. But the string InitializeCriticalSectionEx is not in the dll, so it's not this.
It's realy odd, and as you build the exact same project than me, it's not something in the settings.
I don't know for now...

[DTL]

Same question at stackoverflow - https://stackoverflow.com/questions/22709094/c-application-built-with-120-xp-toolset-on-windows-xp-initializecriticalsecti But it points to some bugs in some versions of VisualStudio (fixed by Microsoft in some updates). May your VS2019 got some update and it broke compatibility with XP ?

[jpsdr]

It's been several years my VS2019 didn't get an update, and it's just now that suddenly XP builds are not working, on my both OS. So, even if there wasn't a VS2019 update since several years, there is a windows update i've made (redistributable, .NET, ...?) which broke the XP builds on my both OS.
I'm building, recycling old motherboard i have a "Frankeisten" PC, with multi boot Windows 7 x86/x64, Windows 10 x64 and Ubuntu (Ubunto has his own HDD, all the Windows are on another HDD), for spare in case my current PC would have issues.
I had to install VS2022 on the Windows 10 x64, i'll try with it. But as i'm following the same update process on all my PC, there is still a risk i encounter the same issue even on this third option, but maybe not.

[jpsdr]

@FranceBB
Euh... How are you able to build for XP with VS2022 ? It was removed after VS2019...:confused:

Edit:
Maybe i've found it, hidden...

Edit 2:
I don't know what to do, the string InitializeCriticalSectionEx is in the XP DLL i've just build with the VS2022 i just updated... :(.
So, on my third OS, i also have the issue.

[FranceBB]

it's just now that suddenly XP builds are not working

I still think it's somewhat related to the inclusion of JincResize.
Although it can be compiled just fine and it does run on XP, there must be something in the source code that makes your configuration *think* that it needs to call an API in the kernel that it doesn't really need, thus producing non-working builds.

The reason why we haven't seen the issue up until this point is that JincResize wasn't there, so when you were building plugins_JPSDR which grouped together HDRTools, NNEDI3, AutoYUY2, aWarpSharpMT and ResampleMT we didn't have any issues.

I'm sure that if you were to build plugins_JPSDR using HDRTools v1.2.0, NNEDI3 v.0.9.4.67, AutoYUY2 v.4.1.11, aWarpSharpMT v.2.1.11 (i.e the latest for all of them) but an older version of ResampleMT (older than 2.9, so without JincResize) it will produce a working build.

This would prove that the issue has technically always been there but it didn't matter 'cause without JincResize the compiler never produced incompatible builds.

@FranceBB
Euh... How are you able to build for XP with VS2022 ? It was removed after VS2019...:confused:


v141_xp is still there. :)

https://i.postimg.cc/7hcbMC16/image.png

[DTL]

Yes - it is good idea to make test builds of plugins_pack of old version sources before addition of JincResize at current configuration. And if it is working as expected - test addition of JincResize (may be by some parts if possible) to see if it somehow trigger the error with incompatible with WinXP builds. Though support of XP may be dropped long time ago at Microsoft and it may not provide any help with such issues. May be other C compilers can do builds for XP ?

[FranceBB]

May be other C compilers can do builds for XP ?

Maybe, but even MSVC can make XP compatible builds when I made the builds with /openmp- /Zc:threadSafeInit-


I don't know what to do, the string InitializeCriticalSectionEx is in the XP DLL i've just build with the VS2022 i just updated... :(.
So, on my third OS, i also have the issue.

Can you check that in Release_XP when it shows All Options it's set as this:


/MP /GS- /Qpar- /GL /analyze- /W3 /Gy /Zc:wchar_t /Gm-
/O2 /Ob2 /sdl- /Fd"Release_XP\vc141.pdb"
/Zc:inline /fp:precise /D "WIN32" /D "NDEBUG"
/D "_WINDOWS" /D "_USRDLL" /D "JINCRESIZEMT_EXPORTS"
/D "_USING_V110_SDK71_" /D "_WINDLL" /D "_MBCS"
/errorReport:prompt /GF /GT /WX- /Zc:forScope
/GR- /arch:IA32 /Gd /Oy /Oi /MT /openmp- /std:c++17
/FC /Fa"Release_XP" /EHsc /nologo /Fo"Release_XP"
/Ot /Fp"Release_XP\JincResizeMT.pch" /diagnostics:classic


and in Additional Option /Zc:threadSafeInit-

https://i.postimg.cc/tC7VMdjm/image.png

I've uploaded my sln back to the FTP

[jpsdr]

I've just made an XP build of AutoYUY2, the string InitializeCriticalSectionEx is in the DLL produced. I've checked my github, the string is in the 4.1.11, but not in the 4.1.9.
For now, the situation is:
- Should it be Visual Studio 2019 11.31 under Windows 7 x86, Visual Studio 2019 9.26 under Windows 7 x64 or Visual Studio 2022 14.17 under Windows 10 x64, the DLL produced has the string InitializeCriticalSectionEx.
- When FranceBB build the exact same project with Visual Studio 2022, the DLL works (meaning there is not the string).

I've disabled all automatic updates in everything (Windows, Visual Studio, etc...), so all my system updates are manualy done by me. One of them probably broke the XP build between the AutoYUY2 4.1.9 and 4.1.11, but i don't know which one. There had been a few years i didn't update Visual Studio (and Windows 7 also of course), but i regulary update the .NET and redistributables.

I'll check with the pictures.

[jpsdr]

Pictures checked, as i thought, as we are using the exact same project, we have the exact same settings.

Edit:
@FranceBB
You said AutoYUY2 4.1.11 worked in one of your posts... But this one has the string InitializeCriticalSectionEx in it. You are sure it works ? If it is, the presence of the string is not a criteria, as i've checked, it was at least in the DLL since the plugins_JPSDR_v3_5_0 version, didn't go back mre. So if plugins_JPSDR stop working only since 4.0.0, i can't check just using the presence of the string.
As it seems i can't use the presence of the string, i still have to bother you to chek, i've made a v3 JincResizeMT for test, just "in case"...

Also, the same but for the linker, except there is not "Additional Options":

/OUT:"F:\PRG\Visual_2019\JincResizeMT\Build\x64\Release_XP\JincResizeMT.dll" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"F:\PRG\Visual_2019\JincResizeMT\Build\x64\Release_XP\JincResizeMT.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"F:\PRG\Visual_2019\JincResizeMT\Build\x64\Release_XP\JincResizeMT.lib" /DLL /MACHINE:X64 /OPT:REF /INCREMENTAL:NO /PGD:"F:\PRG\Visual_2019\JincResizeMT\Build\x64\Release_XP\JincResizeMT.pgd" /SUBSYSTEM:WINDOWS",5.02" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release_XP\JincResizeMT.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /ASSEMBLYDEBUG:DISABLE /TLBID:1


Edit2:
@FranceBB
I've added on the server several versions for testing, as unfortunately checking the string seems not revelevant.

[FranceBB]

I've added on the server several versions for testing, as unfortunately checking the string seems not revelevant.

Looks like we're going somewhere! :D

JincResizeMT_Test_v3 and JincResizeMT_Test_v4

have the following two entries reported by Dependency Walker
InitializeCriticalSectionEx
LCMapStringEx

as they're missing from the kernel and therefore cause the dll to fail to load with the error:

"Cannot load file JincResizeMT.dll. Platform returned code 127: The specified procedure could not be found"

when using


LoadPlugin("D:\test\JincResizeMT.dll")

ColorBars(1920, 1080, pixel_type="YV24")

JincResizeMT(848, 480)


https://i.postimg.cc/qvq45CxN/image.png


but JincResizeMT_Test_VS2022 is absolutely fine! :D
No errors, no missing kernel calls, everything is green and it loads and executes just fine.

https://i.postimg.cc/NFXpMbtb/image.png


Pictures checked, as i thought, as we are using the exact same project, we have the exact same settings.


Well considering that the builds from Visual Studio 2019 don't work but both you and I produce working builds while compiling with Visual Studio 2022 using the same sln with the same settings, I'd say that this is a bug in Visual Studio 2019. In theory, Visual Studio versions are supported for 10 years of security updates, so 16.11 is still supported until April 2029, however whether they're gonna fix the bug or not is anybody's guess, but I feel like we should report it to MSDN. What do you guys think?



You said AutoYUY2 4.1.11 worked in one of your posts... But this one has the string InitializeCriticalSectionEx in it. You are sure it works ?

Yep, I tested again and it definitely works. As to InitializeCriticalSectionEx, I know that you see it, but when I check with Dependency Walker it says that it's not there, in fact everything is displayed as green.

This is version 4.1.11.0 from August 3rd, 2025.
https://i.postimg.cc/G3DW9xXb/image.png

Checked with CFF Explorer too:
https://i.postimg.cc/J41pmNgH/image.png

No issues in Dependency Walker:
https://i.postimg.cc/Gt99JStt/image.png

No issues loading it and using it in Avisynth via AVSPmod mod:
https://i.postimg.cc/kghCWXKd/image.png

[jpsdr]

I don't know why it suddenly stopped working with VS2019, i've checked back plugins_jpsdr until 3.5.0 (didn't check further), and all the DLLs have the string InitializeCriticalSectionEx in them, but if i remember, you said that it was working until 3.9.0. The VS_2022 DLL version also has the string, but it seems working. So for now, it won't be practical for me to have to use the other PC for the builds, but unless i figure out the "why" (very very unlikely) i'll have to.

And as i'm just searching for the string in the DLL, obviously the fact the string is here doesn't mean the ressource will be called. The only thing sure is that if the string is not here, the ressource won't be called... :D

Edit:
@FranceBB
Everything was build without QPar, when back home this evening, i'll bother you one last time with a VS_2022 build with QPar. I know it changed nothing for you when you tested buiding on your own (both worked), but now, i'm very carefull and want to be sure that my build will work.

[DTL]

"The only thing sure is that if the string is not here, the ressource won't be called..."

Yes - it looks was hidden bug by microsoft in some (many) versions and finally become activated in last versions (or by some other thing). As pointed in the stackoverflow answers - presence of InitializeCriticalSectionEx function in a binary already mean it is not compatible with WinXP.

The question applies not just to v120_xp but to any other _xp toolset (which even VS2017 has), and InitializeCriticalSectionEx is one of the few signature functions that surface whenever a program was compiled without XP support. –
ivan_pozdeev
CommentedDec 1, 2017 at 15:04

But for some time that partial bug of the compiler was not completely activated (by marking this function for connection by binary loader ?).

[jpsdr]

@FranceBB
When you can, i've put on the server a release for what should be the last test.

[FranceBB]

No issues found with JincResizeMT_Test_VS2022_v2

https://i.postimg.cc/d0mhMqsL/image.png

works like a charm too. :)
https://i.postimg.cc/J0qwm2yc/image.png

[jpsdr]

Good, thanks for testing. I hope in the begining of next week make a new release of the actual code.

[DTL]

Yes - JincResizeMT looks like ready for release. I made several encodings of about several hours total runtime and no significant issues found.

"No issues found with JincResizeMT_Test_VS2022_v2"

You may also test its downscaler UserDefined4ResizeSPMT() even with default settings.

[jpsdr]

@FranceBB
I've updated my Visual 2019 to the last version.
I've put on the server an XP build for testing, if you can check it when you have time.

[tormento]

What are the difference between this implementation of jinc and ewa-lanczos in avslibplacebo, beside one running on cpu and the other on gpu?

[jpsdr]

As i absolutely don't know ewa-lanczos, i have no idea.

[DTL]

I hope they are enough equal. This implementation uses kernel quantization table as some LUT for better performance and may be lower in precision. The base kernel as jinc weithged by jinc expected to be the same. And single-pass 2D weighting resampling engine too. The exact implementation may be different - like usage of square or round kernel (it is free to compute square instead of round with striped out some corners in SIMD) and that quantization process (it is adjustable and you can now set quant_x/y to 2048 if 256 precision is not enough).

Better to make your own tests of both jinc resize implementations and to see if any difference visible.

[tormento]

As i absolutely don't know ewa-lanczos, i have no idea.
Found this (https://github.com/mpv-player/mpv/issues/2015).

[DTL]

The most important redesign of filters for better performance we need in 202x for multi-core CPUs with slow host RAM is different plane/frame and partial plane/frame processing modes. See current examples in master-1 branch for filters Invert() and RGBAdjust() (also updated filters API in avisynth.h) - https://github.com/DTL2020/AviSynthPlus/tree/master-1 . I still not received any reply from pinterf or possible other developers of AVS+ core if it is planned for addition to main branch. Also it is not totally finished for all possible scripts versions (currently working for single filterchain without clip splitting and fully implemented only for transform in place filters).

Can you analyse filters in your pack and complexity of addition of plane-separated, partial-plane and may be partial-frame (for interleaved formats) modes ? To make somethin more useful in performance we need filters used in QTGMC script - it is at least NNEDI3 and may be ResampleMT->GaussResizeMT (used in some way of prefiltering blur before motion search). The MCompensate and MDegrainX from pinterf mvtools2 2.7.46 I will try to do.

For resize filters it is easy enough to make at least frame-splitting part of new API (without pass-through of partial processing to previous filters). I.e. new GetPlaneOfFrame() and ProcessPlaneOfFrame() methods without forwarding partial requests to child filters. For non-resize filters it is possible to make full update. For non-transform in place filters I hope to make some solution in future.

As I look in NNEDI3 sources - it is not hard to make at least separated planes output because it is not uses inter-plane dependencies in GetFrame() method ? For partial plane output it may require more complex redesign of plane-processing function. Though parts are H-stripes and they are close to your internal multithreading plane separation ?

[DTL]

Found this (https://github.com/mpv-player/mpv/issues/2015).

About 'blur' value to scale kernel in spatial size (relative to 2D sampling grid) - it is present in JincResizeMT.

About fine control over kernel size/cut-off - it is not present in JincResizeMT currently because it uses internal conversion of integer taps to float jinc zeroes. But it already have 's/support' kernel size control for UserDefined4ResizeMT and if users like - it can be expanded to JincResizeMT (as alternative to taps control argument).

Possible solution: if taps argument is not set and s-argument is set for JincResizeMt filter - use s argument value in the filter size control (radius variable in JincResize sources) instead of LUT of jinc-zeroes.

At the https://github.com/DTL2020/JincResizeMT/blob/5f42a8511efba36d4e9f0660fcb3c913ae3847a3/Src/JincResizeMT.cpp#L1738 equal to
https://github.com/DTL2020/JincResizeMT/blob/5f42a8511efba36d4e9f0660fcb3c913ae3847a3/Src/JincResizeMT.cpp#L1741

It is simply different ways to control jinc kernel size cut-off because it is infinite in size and not self-limited in space. May be users and developers of JincResize not found it useful to have float-precision control and make enough good taps-number size control. But if some other developers found it somehow useful to have float-precision control of filter size it can be easily added.

It looks in libplacebo developers simply make some named presets of jinc resize with somehow different combinations of blur and radius/support size. The JincResize(MT) simply exposes these control params to user script.

Like: "ewa_lanczossharp", 3.2383154841662362, jinc, .blur = 0.9812505644269356
it is equal to JincResize(blur = 0.9812505644269356, support/radius=3.2383154841662362).
From jinc_zeros table - https://github.com/DTL2020/JincResizeMT/blob/5f42a8511efba36d4e9f0660fcb3c913ae3847a3/Src/JincResizeMT.cpp#L181
it is radius of 3rd zero. So equal to tap=2 (?).

[jpsdr]

Made a new version of all my filters, don't have time right now to update the first pages.

[tormento]

Made a new version of all my filters, don't have time right now to update the first pages.
Thank you.

The included plugins_JPSDR - Readme.txt refers to 4.0.0.

[jpsdr]

Ah... Maybe i forgot to update in the .7z. I'll check and update it in a next build when the last 21.1.x LLVM will be out, or if there is an issue to fix wich will produce a new release instead of just a new build.

[jpsdr]

First page updated.

[jpsdr]

The included plugins_JPSDR - Readme.txt refers to 4.0.0.

New build (but not new version), fix the Readme.

[FranceBB]

New build (but not new version), fix the Readme.

Oh... :(
https://images2.imgbox.com/38/45/nZhwAwBD_o.png


Doesn't work on Windows XP Professional x86 for the issue we talked about last time. I'll try to make a build next week with Visual Studio 2026, let's see how it goes.

[Emulgator]

As I seem to gather, also from looking at other compile's problems:
Any function suffixed Ex or 2 seems to give grief in terms of backwards compatibilty. Best to avoid these...?

[jpsdr]

@Emulgator
The problem is that there is NOT such functions used. It complains about functions not in the code !

So, we have :

Last Visual Studio 2019 (11.53) version produces Windows 7 compatible Avisynth and my plugins builds, but not working Windows XP versions of my plugins.
Last Visual Studio 2022 (14.23) probably produces (because of last toolset version from what i read) incompatible Windows 7 Avisynth builds (don't know for my plugins) but working Windows XP from previous test.
Visual Studio 2026 produces incompatible Windows 7 Avisynth builds... This realy begins to become a nightmare !

EDIT:
I've uploaded new XP builds.

[FranceBB]

I've uploaded new XP builds.

They work like a charm. :D

https://images2.imgbox.com/1f/96/BJ3GiHFh_o.png

[FranceBB]

For those curious, here's the actual test script with a picture I took at the pond in Osterley:


ImageSource("D:\PXL_20251226_152608961.jpg")
Converttoyv24(matrix="Rec709")


downscale_point=PointResizeMT(Width/16, Height/16).Subtitle("PointResize")
downscale_gauss=GaussResizeMT(Width/16, Height/16).Subtitle("GaussResize")
downscale_bilinear=BilinearResizeMT(Width/16, Height/16).Subtitle("BilinearResize")
downscale_bicubic=BicubicResizeMT(Width/16, Height/16).Subtitle("BicubicResize")
downscale_sinc=SincResizeMT(Width/16, Height/16).Subtitle("SincResize")
downscale_lanczos=LanczosResizeMT(Width/16, Height/16).Subtitle("LanczosResize")
downscale_blackman=BlackmanResizeMT(Width/16, Height/16).Subtitle("BlackmanResize")
downscale_jinc=JincResizeMT(Width/16, Height/16).Subtitle("JincResize")
downscale_sin=SinPowResizeMT(Width/16, Height/16).Subtitle("SinPowerResize")
downscale_spline=Spline64ResizeMT(Width/16, Height/16).Subtitle("Spline64Resize")

v1=StackHorizontal(downscale_point, downscale_gauss, downscale_bilinear, downscale_bicubic, downscale_sinc)
v2=StackHorizontal(downscale_lanczos, downscale_blackman, downscale_jinc, downscale_sin, downscale_spline)

StackVertical(v1, v2)


https://images2.imgbox.com/62/00/rQ1blF2W_o.png

[tormento]

For those curious, here's the actual test script with a picture I took at the pond in Osterley
Can you share it uncompressed?

[FranceBB]

Sure, here it is: https://photos.app.goo.gl/UW2mWj88zDa3rnok8
That's the original 4080×3072 ƒ/1.85 1/198 6.81mm ISO125 picture.
Please note that it's in the Ultra HDR standard we discussed here https://forum.doom9.org/showpost.php?p=2010083&postcount=9, meaning that if you don't have a proper decoder, it will only decode the SDR version without interpreting the XMP gain map (i.e the HDR metadata).

[tormento]

Sure, here it is
How on hell can I save that photo? ;)
if you don't have a proper decoder
Such as? :)

[FranceBB]

Such as? :)


Any modern version of Google Chrome is gonna be able to read it correctly on Windows 11, however that implies that you have HDR mode enabled.
On Android of course Google Photo also reads it correctly.

[Ingram112]

The consolidation of multiple Avisynth plugins into a single DLL is a significant improvement for multi-threading efficiency. Reducing the number of threadpools can noticeably improve performance on systems with high CPU core counts. It's interesting to see how JPSDR merges AutoYUY2, NNEDI3, ResampleMT, and other filters in one pack.

[jpsdr]

Yes, one DLL to rule them all.

[jpsdr]

New version, see first post.

[DTL]

It looks like you update only plugins_JPSDR repository with new AVX512 resample functions but ResampleMT repository only with header files with new version number.

Also about possible performance optimization of V-stripe scan order H-resamplers (AVX512 and AVX2) there is one more simple idea about meander scan order - see comment https://github.com/pinterf/AviSynthPlus/commit/a37fc225ed7a261a9aa748d08f6bf0a9fd8addd9#r184890431

Also other ideas may be not completely tested is meander scan + software prefetch for read (source bytes) and also software prefetch for write for result storage (next target bytes of the next V-stripe to process). There is a separate instruction PREFETCHW to hint cacheline fetch from RAM to caches to make it 'hot' in cache and allow faster write.

What was tested but did not make significant performance changes is software cache flushing to attempt to flush stored result cache lines to RAM to free cache resources for next source and target bytes.

[jpsdr]

No, both have new AVX512 functions.

[DTL]

Github shows only one commit Commit 360d443
and only 2 files changed
resample.h
resample.rc
in May 2026.

Or the all AVX512 commits were at Mar 2026 ?

[jpsdr]

Yes.
I haven't time until now to build and make a minimal check (the Test_Resample_New.avs you made) on my PC with AVX512.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.