AviSynth+ thread Vol.2

[real.finder]

is Avisynth Interface v12 plugin compatibility with avs 2.6 gone? https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest/issues/9 or it has something to do with "thread safe global lock"?

[DTL]

Yes, see the online docs for setting max CPU level.

Documentation is not very clear:

"When "feature" is ended by '+', relevant processor feature flag will be switched on"

Does it mean it can force also any feature not detected in CPU by hardware CPU flags ? (And it will cause crash if instructions are not present).

Tested with
SetMaxCPU("AVX512fast") (without +)
- it really cause crash with illegal instruction at i5-9600K. May be + is no more required ? Or + must mean forcing and without + it need auto-detect (not enable not present features ?).

At i5-9600K:

SetMaxCPU("AVX512fast-") - working
SetMaxCPU("AVX512fast") - crash (a bug ? auto-detect must disable AVX512 ?)
SetMaxCPU("AVX512fast+") - crash

[pinterf]

Documentation is not very clear:

"When "feature" is ended by '+', relevant processor feature flag will be switched on"

Does it mean it can force also any feature not detected in CPU by hardware CPU flags ? (And it will cause crash if instructions are not present).

Tested with
SetMaxCPU("AVX512fast") (without +)
- it really cause crash with illegal instruction at i5-9600K. May be + is no more required ? Or + must mean forcing and without + it need auto-detect (not enable not present features ?).

At i5-9600K:

SetMaxCPU("AVX512fast-") - working
SetMaxCPU("AVX512fast") - crash (a bug ? auto-detect must disable AVX512 ?)
SetMaxCPU("AVX512fast+") - crash
Without the + it enables all flags up to the feature, including that. The + would only enable that individual flag, if your cpu is sse4.2 only, it leaves avx2 flag off.
Theoretical max is not checked, this is a debug function, you can switch on things whicb you don't have.
Edit: you can check it in Info()

[pinterf]

is Avisynth Interface v12 plugin compatibility with avs 2.6 gone? https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest/issues/9 or it has something to do with "thread safe global lock"?
It would only crash if the interface version check would not work, it is only used when v12 is checked, even the version check has version check, at least this is, how it is intended to work.
EDIT: fixed here
https://github.com/pinterf/fft3dfilter/commit/682a6182281a050b10ad40d4ac0bd44b1524b4c6

[pinterf]

It would only crash if the interface version check would not work, it is only used when v12 is checked, even the version check has version check, at least this is, how it is intended to work.
Edit: yes, I can see the problem and will fix it in the holidays.

[StainlessS]

@StainlessS - before I install Microsoft Debugview and pursue that avenue, first could I confirm if am I correct in understanding that if cachetest() reports the request is NOT previous_frame+1 , then this means it WAS gotten from the cache?
Best look at sequence around a particular point, ie install DebugView and look at sequence. (ALWAYS will show all requests, not just Repeat requests and Out-Of-Sync requests).
If not getting "Cache_SOURCE_A" double outputs (two in a row), then 2nd was gotten from cache.

[ EDIT: Cachetest also has a cache following it. If no double output at "Cache_SOURCE_A" then was gotten from CacheTest cache, if CacheTest was not there then would have been gotten from Source filter cache,
behaviour for cachetest cache would be same as for sourcefilter cache so can just consider them to be the same cache]

You need to follow the sequence of requests (when ALWAYS=true).

EDIT:

A Repeat request, is where same frame was requested twice in a row and 2nd instance was NOT gotten from cache, ie cache failure.

Out-Of-Sequence request could be because user jumped about on timeline.
Or eg,
Some filter that eg samples one frame either side of target frame, but does so T+1, T, T-1,
then that would show out of sequence requests, and also mean that filter was not well written, should really be in ascending order of requests for optimum cache usage and processing speed.

EDIT: And you should always have DebugView installed. Can solve loads of problems, is of incredible use to be able to output debug messages from eg RT_DebugF or RT_Debug, or filter builtin
debug messages. (Not sure if recent AVS+ added debug logging or not, if not then could be something to desire).
EDIT: RT_Stats functions RT_Debug/RT_DebugF are of use during 'Compile time', when filter chain is being created before frame serving commences, and also from Runtime scripts eg ScriptClip.

Untested

Last ="..."
filterA()
RT_Debug("FilterA succeeded link into processing chain") # Only outputs once during compile time filter linking
filterB()
SSS="""RT_DebugF("Requesting frame %d from FilterB",current_frame,name="FilterB_Request: ")"""
ScriptClip(Last,SSS) # Output EVERY FRAME during frameserving
RT_Debug("ScriptClip Script succeeded link into processing chain") # Only outputs once during compile time filter linking
filterC()
Return Last

[pinterf]

Avisynth r4403.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4403

Fixed Animate, which has a glitch preventing running Xmas scripts.

20251225 3.7.5.r4403 (pre 3.7.6)

Fix: The Animate() function now explicitly clamps interpolated values to ensure they remain
strictly between the start and end range. Due to the high precision of 64-bit double introduced
in v3.7.5, intermediate calculations could slightly exceed the boundary (e.g., 360.00000000000006
when interpolating from 0 to 360.0 in 564 steps), requiring this clamp to prevent out-of-range errors.

[StainlessS]

Thank you Santa. :)

EDIT:
Checked new AVS+ Animate fixed OK, Hanfrunz_XMas_Extravaganza_Emulgator_PortalScope_2024.avs now working just fine.
see this post to test it out:-
https://forum.doom9.org/showthread.php?p=2012080#post2012080

looks something like this [All Hanfunz xmas goodies 2010 to 2023 + Emulgator PortalScope 2024, Total Play Duration, 5:12.24]

ClickMe [twice for original size]
https://i.postimg.cc/mPZ8bty0/Hanfrunz-XMas-Extravaganza-Emulgator-Portal-Scope-2024-00.jpg (https://postimg.cc/mPZ8bty0)

[jpsdr]

Thanks, we'll register it, just like the latest XP compatible one.


Is it 10.0.40219.325 the latest XP ?

Are people interested that i'll add to my github Windows 7 compatible builds ?

[Jamaika]

Thank you Santa. :)

EDIT:
Checked new AVS+ Animate fixed OK, Hanfrunz_XMas_Extravaganza_Emulgator_PortalScope_2024.avs now working just fine.
see this post to test it out:-
https://forum.doom9.org/showthread.php?p=2012080#post2012080

looks something like this [All Hanfunz xmas goodies 2010 to 2023 + Emulgator PortalScope 2024, Total Play Duration, 5:12.24]

ClickMe [twice for original size]
https://i.postimg.cc/mPZ8bty0/Hanfrunz-XMas-Extravaganza-Emulgator-Portal-Scope-2024-00.jpg (https://postimg.cc/mPZ8bty0)
What does error mean?
ffplay_avx2.exe 2023.avs
Avisynth function: Animate [0, 576, Bicubicresize, function, 576, 576, 0.333333, 0.333333, 192, 680, 576, 576, function, 576, 576, 0.333333, 0.333333, 0, 0, 576, 576]
Avisynth function: Animate [0, 576, Bicubicresize, function, 576, 576, 0.333333, 0.333333, 192, 680, 576, 576, function, 576, 576, 0.333333, 0.333333, 0, 0, 576, 576]
Avisynth function: Animate [0, 576, Bicubicresize, function, 576, 576, 0.333333, 0.333333, 192, 680, 576, 576, function, 576, 576, 0.333333, 0.333333, 0, 0, 576, 576]
Avisynth function: Animate [0, 576, Bicubicresize, function, 576, 576, 0.333333, 0.333333, 192, 680, 576, 576, function, 576, 576, 0.333333, 0.333333, 0, 0, 576, 576]
[avisynth @ 0000021B6ED33600] Filter error: GetPlaneWidthSubsampling called with unsupported pixel type.
(2023.avs, line 13)
2023.avs: Unknown error occurred

[StainlessS]

I imagine that it means you need the Avisynth+ r4403 update posted in post #3557, a few posts before this one.
The reason for the update is Hanfrunz xmas script 2023.

ie,
Avisynth r4403.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4403

Fixed Animate, which has a glitch preventing running Xmas scripts.

20251225 3.7.5.r4403 (pre 3.7.6)

Fix: The Animate() function now explicitly clamps interpolated values to ensure they remain
strictly between the start and end range. Due to the high precision of 64-bit double introduced
in v3.7.5, intermediate calculations could slightly exceed the boundary (e.g., 360.00000000000006
when interpolating from 0 to 360.0 in 564 steps), requiring this clamp to prevent out-of-range errors.

[Emulgator]

Is it 10.0.40219.325 the latest XP ?
Just checked in my repos and found a folder 14.27.29112 designated as "last XP", don't know if that is correct, can not countercheck ATM.

[jpsdr]

Ahh... I don't have this one. I jump from 14.16.27033.0 (last Visual 2017 version) to 14.29.31030.2, the last Visual 2019 version. So it must be an intermediate 2019 version.
I have in Visual 2010 version a directory i named "Windows XP", with the version i stated, wich is not of course the last Visual 2010 version (but very close...).

[pinterf]

This is what I have collected:

OS, versions, toolsets

Windows XP, toolset=v141_xp (VS 2017), redistributable: 14.27.29112.0

Windows 7, toolset=v143 (VS 2022) CXX version 19.39.33523.0 (Its redistributable: 14.38.33130) and not 17.9/19.39.33523.0/14.39.33523.
Windows 8/10/11, toolset=v143 (VS 2022) redistributable 14.40.xxxx+
Windows 10 / 11 v145 (VS 2026) redistributable 14.50+
"mutex crash incompatibility": machines with old redistibutable before 14.39.32551.0 would crash if VS is later than ~July 2024

Building for Win7 in VS2026 (v143 - compiler at most 17.9 - 14.39.xxxx toolset)

Prerequisites in VS2022/VS2026 installation

Project properties|General|Platform Toolset: v143
Project properties|Advanced|MSVC Toolset: 14.38.33130
Important: do not use "MSVC Build Tools (Latest)" since it may pull in latest runtimes which are not Win7 friendly. Even on VS 2022 a non-Win7 compatible 14.44.35207 (Latest) exists (as of December 2025), and the 14.39.33519 seems to be buggy.

You have to install this specific toolset (14.38.33130) by selecting it manually from VS installer.
Open the VS Installer, go to Individual Components, and explicitly select this older v143 toolset version.

Individual components: search for 14.38
Enable CLI/C++ Support for v143 build tools (v14.38-17.8) (Out of support)
Enable MSVC v143 - VS2022 c++ x64/x86 build tools (v14.38-17.8) (Out of support)
Check 17.8 ATL and MFC (x64/x86) if needed.

After this update, we are still not happy.

Building Avisynth for Win7
The logical way does not work

Providing the exact minor version does not work
@rem cd avisynth-build
del .\CMakeCache.txt
del ..\CMakeCache.txt
cmake .. -G "Visual Studio 17 2022" -T "v143,version=14.38.33130" -DENABLE_PLUGINS:bool=on -DENABLE_INTEL_SIMD:bool=ON
cmake --build . --config Release --clean-first


This did not works, either: setting environment variables and pass only v143 as toolset. Contrary I gave here later 14.44, it still used 14.39.
@rem cd avisynth-build
del .\CMakeCache.txt
del ..\CMakeCache.txt
:: 1) Open a Developer Command Prompt
set VSROOT="C:\Program Files\Microsoft Visual Studio\2022\Community"
call %VSROOT%\VC\Auxiliary\Build\vcvarsall.bat x64 -vcvars_ver=14.38

cmake .. -G "Visual Studio 17 2022" -T "v143" -DENABLE_PLUGINS:bool=on -DENABLE_INTEL_SIMD:bool=ON
cmake --build . --config Release --clean-first



So on VS2022 passing v143,version=14.39.33519 or version=14.38.33130
(from command line -T "v143,version=14.39.33519") won't work. In reality, neither version=xxxx, nor setting the environment worked.

I had then the opposite problem: after installing both "Latest" (which is 14.44) and the stable 14.39.33519 (17.9 toolset), I was unable to reach the latest 14.44.35207 (17.14 toolset). I was instead locked to 14.39.

This phenomenon is probably caused by Microsoft's attempt to maintain stability, because the file Microsoft.VCToolsVersion.v143.default.props hardcodes the default compiler toolset to 14.39.33519, effectively overriding all generic requests (-T "v143"). Perhaps they (MS) did not want more issues on their customer support :)

I was unable to tell CMake to use VS2022 with a different v143 version, if there are multiple v143 versions are installed.

A solution can be that we uninstall every other v143 toolset and only leave 14.38.33130. This is a guaranteed, brute force solution. If only 14.38 is installed, it becomes the only toolset available, thus overriding any default logic. Our VS2022 project is surely Win7 compatible.

When I uninstalled 14.39 (17.9) compiler set and installed 14.38 (17.8), my Microsoft.VCToolsVersion.v143.default.props file has been changed, and contained the link to VcToolsVersion 14.38.33130.

(One other hint I found is using CMakePreset but it's over my mood.
Anyway, it seems we might have to give a compilation description, because the Win7 will probably replace WinXP in the troublesome ancient OS list.

Interesting finding:
"UnrealBuildTool has banned the MSVC 14.39.33519-14.39.99999 toolchains due to compiler issues. Please install a different toolchain such as 14.38.33130 by opening the generated solution and installing recommended components or from the Visual Studio installer."

So it would be fine to stick with 14.38.33130?

If so, this is what has to be done

- Use 14.38.33130 (compiler 17.8)
- Ship its redistributable from %VCINSTALLDIR%\Redist\MSVC\14.38.33130\
(no installer, just files!)

Note#2
I was not able to use v143 toolset in VS2026 until I manually copied the
Microsoft.VCRedistVersion.v143.default.props file from my VS2022 installation. This must be a VS installer bug, despite I chose v143 latest, it did not copy its redist.

EDIT:
**More versions**

14.37.32822 Compiler 17.7
(this is too early, we have better choice)

14.38.33130 Compiler 17.8
This is whose redistributable DLLs I found on my system, though I installed 17.9 (14.39.33519) which is a newer one.
You can obtain x64 and x86 redistributables from your VS2022 installation:
%VCINSTALLDIR%\Redist\MSVC\14.38.33130\
(So no Redist\MSVC\14.39.33519\ exists on my VS2022 system, but maybe it's the better, see the Unreal warning above)


14.39.33519.0 Compiler 17.9
Most commonly referenced pre‑VS2026 build, also the latest win7 compatible VS 2022/v143 combo.
14.39.33523 (Compiler 17.9, CXX version 19.39.33523.0)
For some reason, we'd better use 19.38, see earlier comments.
And finally, there is a newer Win7 compatible one, but let's stick with the official v143 versions. This newer-than-the-latest version is:

14.39.33600.x – Developer preview branch
Some VS 17.10 preview builds shipped 14.39.33600. These were also Win7‑safe before Microsoft officially dropped support in 14.50+.

EDIT:
Find direct links source later, in qyot27's post.

So it seems that the compiler toolsets up to 17.9 (14.39) continue to generate binaries compatible with Windows 7.

[jpsdr]

Do you have some place we can get redistributable 14.27.29112.0 and 14.37.32822 (both x86 & x64) ?
BTW, installing redistributable 14.44.35211 works on Windows 7, why the 14.37.32822 ? Is there some things not working i didn't notice with 14.44.35211 ?

[pinterf]

Do you have some place we can get redistributable 14.27.29112.0 and 14.37.32822 (both x86 & x64) ?
BTW, installing redistributable 14.44.35211 works on Windows 7, why the 14.37.32822 ? Is there some things not working i didn't notice with 14.44.35211 ?
Search results told this was the version belonging to vs 17.7 which was the latest win7 compatible one. The vs 2022 and 2026 installer is also providing this specific version from the historical unsupported but still choosable toolsets.

[pinterf]

Do you have some place we can get redistributable 14.27.29112.0 and 14.37.32822 (both x86 & x64) ?
BTW, installing redistributable 14.44.35211 works on Windows 7, why the 14.37.32822 ? Is there some things not working i didn't notice with 14.44.35211 ?

I don't know. I'm confused now. Copilot says:

- Redistributable 14.44.35211 does work on Windows 7 if KB2999226 is installed:
https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c
- 14.37/14.38 are preferred because the toolset compiler is stable.
- 14.39 was buggy, which is why Unreal banned it and why no redistributable exists.
- Using toolset 14.38 + redist 14.44 is totally safe and recommended.

As a convenient redistributable installer download source, visit:
https://www.techpowerup.com/download/visual-c-redistributable-runtime-package-all-in-one/
This site have historical downloads, for a specific version like 14.38.33130, find the November 15th, 2023 download. extract the zip.
The files vcredist2015_2017_2019_2022_x86.exe and vcredist2015_2017_2019_2022_x64.exe are the two installers of that specific 14.38.33130 version.

But if you find the latest 14.44.35211.0 stable, use it, its at the July 10th, 2025 entry in the list.

[qyot27]

Do you have some place we can get redistributable 14.27.29112.0 and 14.37.32822 (both x86 & x64) ?
BTW, installing redistributable 14.44.35211 works on Windows 7, why the 14.37.32822 ? Is there some things not working i didn't notice with 14.44.35211 ?

https://github.com/abbodi1406/vcredist/tree/master/source_links
has the exhaustive list of versions with their download locations on Microsoft's servers.

14.28.29213.0 - last version compatible with Windows XP (or so that page claims?)
wget https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/B75590149FA14B37997C35724BC93776F67E08BFF9BD5A69FACBF41B3846D084/VC_redist.x64.exe -O VC_redist_14.28.29213.0.x64.exe
wget https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/0D59EC7FDBF05DE813736BF875CEA5C894FFF4769F60E32E87BD48406BBF0A3A/VC_redist.x86.exe -O VC_redist_14.28.29213.0.x86.exe

14.27.29114.0 (the one used for the last few XP-friendly release builds of avsplus)
wget https://download.visualstudio.microsoft.com/download/pr/722d59e4-0671-477e-b9b1-b8da7d4bd60b/591CBE3A269AFBCC025681B968A29CD191DF3C6204712CBDC9BA1CB632BA6068/VC_redist.x64.exe -O VC_redist_14.27.29114.0.x64.exe
wget https://download.visualstudio.microsoft.com/download/pr/56f631e5-4252-4f28-8ecc-257c7bf412b8/D305BAA965C9CD1B44EBCD53635EE9ECC6D85B54210E2764C8836F4E9DEFA345/VC_redist.x86.exe -O VC_redist_14.27.29114.0.x86.exe


14.27.29112.0 (the one requested above)
wget https://download.visualstudio.microsoft.com/download/pr/c61fa35d-a027-4901-aa8e-9993ae4f4fbe/4B5890EB1AEFDF8DFA3234B5032147EB90F050C5758A80901B201AE969780107/VC_redist.x64.exe -O VC_redist_14.27.29112.0.x64.exe
wget https://download.visualstudio.microsoft.com/download/pr/c61fa35d-a027-4901-aa8e-9993ae4f4fbe/CAA38FD474164A38AB47AC1755C8CCCA5CCFACFA9A874F62609E6439924E87EC/VC_redist.x86.exe -O VC_redist_14.27.29112.0.x86.exe

Or so on.

[pinterf]

https://github.com/abbodi1406/vcredist/tree/master/source_links
has the exhaustive list of versions with their download locations on Microsoft's servers.

14.28.29213.0 - last version compatible with Windows XP (or so that page claims?)
wget https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/B75590149FA14B37997C35724BC93776F67E08BFF9BD5A69FACBF41B3846D084/VC_redist.x64.exe -O VC_redist_14.28.29213.0.x64.exe
wget https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/0D59EC7FDBF05DE813736BF875CEA5C894FFF4769F60E32E87BD48406BBF0A3A/VC_redist.x86.exe -O VC_redist_14.28.29213.0.x86.exe

14.27.29114.0 (the one used for the last few XP-friendly release builds of avsplus)
wget https://download.visualstudio.microsoft.com/download/pr/722d59e4-0671-477e-b9b1-b8da7d4bd60b/591CBE3A269AFBCC025681B968A29CD191DF3C6204712CBDC9BA1CB632BA6068/VC_redist.x64.exe -O VC_redist_14.27.29114.0.x64.exe
wget https://download.visualstudio.microsoft.com/download/pr/56f631e5-4252-4f28-8ecc-257c7bf412b8/D305BAA965C9CD1B44EBCD53635EE9ECC6D85B54210E2764C8836F4E9DEFA345/VC_redist.x86.exe -O VC_redist_14.27.29114.0.x86.exe


14.27.29112.0 (the one requested above)
wget https://download.visualstudio.microsoft.com/download/pr/c61fa35d-a027-4901-aa8e-9993ae4f4fbe/4B5890EB1AEFDF8DFA3234B5032147EB90F050C5758A80901B201AE969780107/VC_redist.x64.exe -O VC_redist_14.27.29112.0.x64.exe
wget https://download.visualstudio.microsoft.com/download/pr/c61fa35d-a027-4901-aa8e-9993ae4f4fbe/CAA38FD474164A38AB47AC1755C8CCCA5CCFACFA9A874F62609E6439924E87EC/VC_redist.x86.exe -O VC_redist_14.27.29112.0.x86.exe

Or so on.
Thanks, I had the paths, but I missed the wget!

[jpsdr]

Thanks for all these links.

I've added Avs+ on my github with Windows 7 compatible builds.

[pinterf]

Thanks for all these links.

I've added Avs+ on my github with Windows 7 compatible builds.

Finally you did it with 14.44.xx you mentioned, so simply with latest v143?

[jpsdr]

It's build with VS2019, so it's 142.

[FranceBB]

I've tested the new 20251225 3.7.5.r4403 (pre 3.7.6) build on Windows XP Professional x86 and so far so good.

https://images2.imgbox.com/20/7e/9DTkwcIs_o.png

Windows XP lives (even if just for a little bit more). :)


ImageSource("D:\154312983.jpg")

SinPowerResize(Width/8, Height/8)

Info()


https://images2.imgbox.com/cb/7a/pKAsQAzW_o.png

I'm pleased to see that the new L2 Cache detection works like a charm over here as well.

[TR-9970X]

I've tested the new 20251225 3.7.5.r4403 (pre 3.7.6) build on Windows XP Professional x86 and so far so good.


Interesting, I'm using this build :-

https://gitlab.com/uvz/AviSynthPlus-Builds/ r4405

PS:- And yet another build already...soon to be 3.7.6.

[pinterf]

Happy New Year!
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4430
Avisynth+ v3.7.6pre-r4430 test build - incl. Win7 compatibility-test versions
20260105 3.7.5.r4430 (pre 3.7.6)

- add AVX512 code path to 8-16-bit horizontal resamplers, having kernel size <= 4 and specific ratios (DTL) 300%+ !!
- More Aarch64 (ARM64) NEON:
- add I8MM and SVE2_1 feature flags
- add NEON optimization to TurnLeft/Right/180

[DTL]

filter_size of 4 for upsampling also used in 4:2:x ->4:4:4 colour transforms (default resampler is BicubicResize if not changed manually -
chromaresample
string chromaresample = "bicubic"
) so making H-resize for this filter_size faster expected to speedup also many colour transforms filters in many complex scripts (like Convert from subsampled chroma to RGB or YUV444). So users of AVX512 CPUs may try to test if any visible performance boost happen with this core resampler upgrade for AVX512. Mostly visible performance boost expected with a scripts with many ConvertX() filters. Also with simple upsize resizing like Bilinear of Bicubic (also Lanczos(taps=1) but it may be very rarely used).

8bit formats for faster H-resize with AVX512 uses AVX512VBMI instruction - sadly not present in Xeon Golds 613x in some good enough workstations of the end of 201x so if AVX512FAST forced manually it will crash. But 16bit (10-16) uses AVX512BW and it is present at medium-old Xeons.

New AMD CPUs with Zen5 (and Zen4 half-blood AVX512) expected to have both VBMI and BW instructions sets and expected to work.

The back transform 4:4:4->4:2:x with faster AVX512 H-resize is also possible and in the progress but is more complex in design because requires filter_size of 8 and more complex source samples gathering (expected to be somehow slower).

[FranceBB]

Happy New Year!
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4430
Avisynth+ v3.7.6pre-r4430 test build - incl. Win7 compatibility-test versions
[CODE]20260105 3.7.5.r4430 (pre 3.7.6)



Happy 2026! :)
I downloaded and installed Windows6.1-KB2999226-x64.msu on Windows Server 2008 R2 Standard x64 (which is basically Windows 7) on an old Intel Xeon x5570 and I tried the build

Avisynth_3.7.6_20260105_VS2026tst_r4430

Unfortunately, version

x64-win7-19.44.35221-17.14

ended up with



AvsMeter64.exe -Avsinfo -lf -log

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\windows\system32\MSVCP140.dll
Address: 0x000007FED2D82AA0



while version x64-win7-19.38.33145-17.8 worked like a charm.


Command line switches: -Avsinfo -lf -log

[OS/Hardware info]
Operating system: Windows Server 2008 R2 (x64) Service Pack 1.0 (Build 7601)

CPU: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz / Gainestown 8M (Xeon)
MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2
4 physical cores / 8 logical cores


[Avisynth info]
VersionString: AviSynth+ 3.7.5 (r4430, master, x86_64)
VersionNumber: 3.75
File / Product version: 3.7.5.0 / 3.7.5.0
Interface Version: 12
Multi-threading support: Yes
Avisynth.dll location: C:\windows\system32\avisynth.dll
Avisynth.dll time stamp: 2026-01-05, 12:26:23 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


https://images2.imgbox.com/c5/cf/qI3uTUWL_o.png

so it looks like x64-win7-19.38.33145-17.8 is the way to go for Windows 7 & Windows Server 2008 R2.

[pinterf]

Thanks, this is what I wanted to know. A final question: what is the version of your msvcp140.dll. jpsdr mentioned that the latest 19.44 works for him fine. I wonder that a 19.44 redistributable with a 19.44-built Avisynth fails or not.

[FranceBB]

Interestingly, when I downloaded and installed Windows6.1-KB2999226-x64.msu from the Microsoft website I thought it was gonna install the latest compatible version, but actually when I looked at C:\Windows\System32 I can see that it's actually still 14.22.27821.0.

https://images2.imgbox.com/e3/61/ORPmqd9n_o.png

[jpsdr]

Unfortunately I don't know.
I made my avisynth builds with VS2019 Update 11.53 for MSVC versions, and under Visual Studio 2019 Update 9.26 for LLMV versions, as VS2019 v9 is the last version working with LLVM installed externaly.
You can test them on my github.
Redistributable installed 14.44.35211.

[pinterf]

That's too old, see alsk the so-called mutex-crash, which I mentioned earlier, in 2024 the mutex ABI has been changed, but I expected it that the 14.38 was also crashing on that reason.
EDIT: my earlier finding on mutex crash incompatibility": machines with old redistibutable before 14.39.32551.0 would crash if VS is later than ~July 2024
Based on this: FranceBB had pre-14.39.32551 redist and when using 14.44 compiled avisynth dll --> crash (I bet it crashed on the infamous mutex lock).

[FranceBB]

yeah I saw the posts, but I thought that installing Windows6.1-KB2999226-x64.msu from the link you were suggesting was gonna be enough.


- Redistributable 14.44.35211 does work on Windows 7 if KB2999226 is installed:
https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c

Unfortunately it wasn't. I'll try the AIO package from here https://github.com/abbodi1406/vcredist/releases on Windows Server 2008 R2 Standard x64 and see whether it actually updates the file in System32. If it does, I'll try again x64-win7-19.44.35221-17.14. In any case, x64-win7-19.38.33145-17.8 works even with an older version of the redistributable.


In the meantime, I've tested Avisynth_3.7.6_20260105_VS2026tst_r4430 on Windows XP Professional x86 and it works like a charm on the usual XP build. :)

https://images2.imgbox.com/27/37/aLUW5VAZ_o.png

[FranceBB]

Alright, so, take 2.
I've installed VisualCppRedist_AIO_x86_x64.exe which updated msvcp140.dll to 14.44.35211.0 on Windows Server 2008 R2.

https://images2.imgbox.com/4a/cc/tQzcerIj_o.png

I then tried Avisynth_3.7.6_20260105_VS2026tst_r4430 version x64-win7-19.44.35221-17.14

And sure enough this time it worked with this new version as well. :D


Log file created with: AVSMeter 3.0.9.0 (x64)
Command line switches: -Avsinfo -lf -log

[OS/Hardware info]
Operating system: Windows Server 2008 R2 (x64) Service Pack 1.0 (Build 7601)

CPU: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz / Gainestown 8M (Xeon)
MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2
4 physical cores / 8 logical cores


[Avisynth info]
VersionString: AviSynth+ 3.7.5 (r4430, master, x86_64)
VersionNumber: 3.75
File / Product version: 3.7.5.0 / 3.7.5.0
Interface Version: 12
Multi-threading support: Yes
Avisynth.dll location: C:\windows\system32\avisynth.dll
Avisynth.dll time stamp: 2026-01-05, 12:26:24 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


FranceBB had pre-14.39.32551 redist and when using 14.44 compiled avisynth dll --> crash (I bet it crashed on the infamous mutex lock).

Yep. Bingo. Now it works.

https://images2.imgbox.com/16/f8/s1UdL8aZ_o.png

[pinterf]

FranceBB, thanks for testing it.

New build: Avisynth r4439
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4439

We have even more AVX512 resampler specializations, big thanks to DTL2020's innovation.

As usual, I include two main build types. Now the pack comes with a Win7 compatible build as well.

1.) XP builds (v141_xp toolset + special compile flags)
2.) modern (clang-cl - LLVM 20.1.8) well optimized builds. VS2026 v145 toolset
3.) a Windows 7 compatible - medium-modern build (x64 only) v143 toolset

Note for Windows 7 compatibility build:

- I used the usual VS2022 v143 toolset: 14.44.35221. (v143 is selectable from Visual Studio 2026 as well)
- Avisynth.dll requires an up-to-date Win7 compatible Visual C++ redistributable pack.
Pre-14.39 VC redistributable versions will crash with Access Violation ("mutex-lock" issue)
When in doubt which version you have, check your c:\windows\system32\msvcp140.dll properties.
Download 14.44.35221 from: https://github.com/abbodi1406/vcredist/releases/tag/v0.92.0
- Redistributable 14.44.35211 does work on Windows 7 if KB2999226 is installed:
Get the update from:
https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c

20260107 3.7.5.r4439 (pre 3.7.6)
--------------------------------
* add AVX512 code path (tuning by DTL2020)

- 32-bit float resamplers, verticals; horizontals up to kernel size 16.
- 8-16-bit horizontal resamplers,

- kernel size <= 4 and specific ratios; 300%+ !!
- kernel sizes up to 8 and 16 and specific ratios.
- 8-16-bit vertical resamplers

For online documentation, please check https://avisynthplus.readthedocs.io/en/latest/

Full change log:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

[FranceBB]

FranceBB, thanks for testing it.

No problem, it's literally the least I can do, master Ferenc. :)


New build: Avisynth r4439

1.) XP builds (v141_xp toolset + special compile flags)


Works on Windows XP Professional x86

https://images2.imgbox.com/89/b0/x6AuUyZh_o.png


3.) a Windows 7 compatible - medium-modern build (x64 only) v143 toolset


Works on Windows Server 2008 R2 Standard x64

https://images2.imgbox.com/18/de/yLx8N96S_o.png

[Emulgator]

jpsdr, many thanks ! Your builds saved the day for my Win7 rigs.
I've added Avs+ on my github with Windows 7 compatible builds.

The oldest Win7U64 i940XM 8GB from 2010:
Both your builds r4449 x86 and x64 run well, just a quick test. AvsPmod 2.7.9.5 with the christmas script.

Two newer Win7U64 i7-4960X 32GB from 2014 are in the dock under repair, to be tested later.

[manolito]

1.) XP builds (v141_xp toolset + special compile flags)
2.) modern (clang-cl - LLVM 20.1.8) well optimized builds. VS2026 v145 toolset
3.) a Windows 7 compatible - medium-modern build (x64 only) v143 toolset



Quick request for clarification:

I am under Win7 64, so far I use the latest stable version of AVS+ Avisynth 3.7.5 (20250420)
I only use the 32bit version of AVS+, I have no use for the 64bit version. This probably means that Option 3.) will not work for me, because I only use 32bit plagins. Is this assumption correct?


Cheers
manolto

[pinterf]

1.) XP builds (v141_xp toolset + special compile flags)
2.) modern (clang-cl - LLVM 20.1.8) well optimized builds. VS2026 v145 toolset
3.) a Windows 7 compatible - medium-modern build (x64 only) v143 toolset



Quick request for clarification:

I am under Win7 64, so far I use the latest stable version of AVS+ Avisynth 3.7.5 (20250420)
I only use the 32bit version of AVS+, I have no use for the 64bit version. This probably means that Option 3.) will not work for me, because I only use 32bit plagins. Is this assumption correct?


Cheers
manolto
Omitting the win7 32-bit was just a time-saving option for me, since assembling such a release pack is ~3 hours, I was in short of time.

At least it turned out that someone is still using 32 bit. Next time, you can expect such a test build.

[jpsdr]

jpsdr, many thanks ! Your builds saved the day for my Win7 rigs.
Nice it was usefull for someone.
As it takes hours for me to make all these builds, don't expect frequent updates... ;)

[FranceBB]

Is this assumption correct?


option 1 will work just fine as the XP x86 builds work on everything else as well, so Vista, 7, 8, 8.1 and 10 x86 will all happily run those. :)

[manolito]

I am under Win7 64, so far I use the latest stable version of AVS+ Avisynth 3.7.5 (20250420)

Thanks FranceBB, this makes it perfectly clear... :)

OTOH I am unsure why I should upgrade from version 3.7.5 at all. I will certainly not abandon Win7 64, so I wonder which real advantages the upcoming new version will offer under Win7 for the 32bit version of AVS+. Let's wait and see...


Cheers
manolito

[FranceBB]

I wonder which real advantages the upcoming new version will offer

Well, the changelog is currently here https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

I still think you should keep it updated once it comes out as "Stable" and is released by Stephen and Master Ferenc as it's always a nice thing.

Sure, older systems and CPUs won't benefit from things like the AVX512 assembly speed bump for the resizers (and the same goes for other architectures like ARM which have their own intrinsics in NEON, DOTPROD and CPUF), but every system still benefits from the updated core and the improvements and fixes the come with it.

I'm talking about things like "add" and "subtract" in Overlay to support 32bit float, utf8 parameter for AddAutoLoadDir, AddAutoLoadDir, LoadPlugin, DumpFilterGraph, L2 cache size being displayed when using Info(), as well as a bunch of bug fixes like "reverse" properly handling 24bit audio or the one for Animate and 64bit double that caused StainlessS Christmas celebration to be ruined (I'm joking, I'm joking XD) and so on.

In other words, it's always a nice thing to keep the frameserver updated, but ultimately it's for you to decide, just look at the changelogs and see if there's something that makes you consider the release worth upgrading once the stable version is available. :)

[manolito]

Thanks FranceBB for your suggestions... :thanks:

Especially the link to the changelog is very helpful. But for my use cases I cannot find any new features which would make my life easier. Of course I may have overlooked something.

After my stroke about 4 years ago I did switch from the old standard Avisynth to Avisynth+ for the only reason to be able to use DGHDRToSDR. Works much better for me than the FFmpeg based options I have (My hardware cannot use LibPlacebo). But I did not install the 64bit version of Avisynth+, simply because I was very happy with my proven and trusted 32bit plugins, and because I did not want to have 2 completely different Avisynth installations on my machine (with all the switching between the different versions).

So for me it will be Avisynth+ 32bit exclusively, and so far I have not missed a 64bit version. Since my stroke I mainly use FFmpeg for most of my conversion needs. Luckily my old Thinkpad T530 (running Win7 64bit) is still happy with the special FFmpeg versions made by autodidact. I still have a love-hate relationship with FFmpeg, but over time I mostly got used to it, and I know how to work around FFmpeg's limitations.


So thanks again for your help. I guess we will talk again after the stable version 3.7.6 comes out.

Cheers
manolito

[FranceBB]

Wow it's been 4 years already...! I remember when you showed as offline for a while and we were all a bit concerned 'cause unlike real life, when online people disappear there's often no way of knowing what happened. Obviously I hope that they just got tired and wanted to enjoy life, so I'm glad when I see them come back every once in a while to say hi (like Didée, vcmohan, Chikuzen etc), but I always wonder "what if". For instance, I still remember when Groucho left and every time I open AVSMeter to test a script or to test the plugins on a new server etc I keep wondering...

Anyway, let me just say that we're all glad to see you around and still encoding. :)

[v0lt]

I have a question about the names of the changed functions in the plugins.
The MPC-BE project includes VSFilter, which is also a plugin for AviSynth 2.5 and later. The plugin implements four functions.

In the original VSFilter, the functions were described as follows:
VobSub (clip, string)
TextSub (clip, string "file", int "charset", float "fps", string "vfr")
TextSubSwapUV (bool)
MaskSub (string "file", int "width", int "height", float "fps", int "length", int "charset", string "vfr", string "pixel_type")
But currently, "charset" has been replaced with "defcodepage."

Am I correct in thinking that in this case, TextSub and MaskSub should be renamed? For example, adding the number 2 to the function names.

[pinterf]

I checked xy-VSFilter which I used to maintain, it has "charset" in both functions. I don't know the rest of VSFilter history.

[v0lt]

I checked xy-VSFilter which I used to maintain, it has "charset" in both functions. I don't know the rest of VSFilter history.
The replacement of "charset" with "defcodepage" occurred only in VSFilter (MPC-BE project) (https://github.com/v0lt/VSFilter).

[qyot27]

VSFilter_VSFilter(<options>, charset="")

VSFilterBE_VSFilter(<options>, defcodepage="")

would work inside of the same script so long as the .dll filenames are different (per the example, VSFilter.dll and VSFilterBE.dll). AviSynth's pseudo-namespacing ability isn't something that's brought up regularly (most famously it usually gets mentioned in tandem with the variety of plugins providing a function named MPEG2Source), but it's existed since probably sometime in the 2.5 series at least, if not earlier.

Ultimately, it's up to you whether it's important enough of a difference to iterate the function names the MPC-BE VSFilter.dll provides.

[v0lt]

Okay. I renamed it to VSFilterBE.dll (https://disk.yandex.ru/d/uzudUC9C3d0JsA). I've left the function names the same for now.

[DTL]

It looks documentation for ConvertToPlanarRGB missed chromaresample params:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html
RGB planar

ConvertToPlanarRGB(clip, [ string matrix, bool interlaced,
string ChromaInPlacement,
string chromaresample ] )
ConvertToPlanarRGBA(clip, [ string matrix, bool interlaced,
string ChromaInPlacement,
string chromaresample,
float param1, float param2, float param3 ] )

But sources for ConvertToPlanarRGB also lists param1,2,3 - https://github.com/AviSynth/AviSynthPlus/blob/620bb9401a798aba883adbbcb96f37a60e655c91/avs_core/convert/convert.cpp#L72
{ "ConvertToPlanarRGB", BUILTIN_FUNC_PREFIX, "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f", ConvertToRGB::Create, (void *)-1 },
{ "ConvertToPlanarRGBA", BUILTIN_FUNC_PREFIX, "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f", ConvertToRGB::Create, (void *)-2 },