AviSynth+ thread Vol.2

[pinterf]

Originally Posted by Emulgator

Win10P64 i9-11900K Avs r4356 x86_64 runs ok.
Win10P64 i9-11900K Avs r4356 x86 STATUS_ACCESS_VIOLATION in C:\Windows\SysWOW64\MSVCP140.dll immediately within Groucho's AviSynth Installer.
Did only copy the AviSynth.dll, not the 6 base plugins.
The previous Win10P64 i9-11900K AviSynth.dll (4289.375) x86 runs ok.

Win7U64, WinXP32 testing soonish.

Thank you for the feedback.

My version (I'm on Win11) is 14.50.35719.0

Theoretically, the "Latest supported v14 (for Visual Studio 2017–2026)" redist pack is still OK for Windows 10, maybe an update needed. If it works, for the record, it would be interesting to know which version did not work for you.

Also (quotation):
Support for Visual C++ 2015 Redistributable (version 14.0.24212) ended October 15, 2025.

Link:
https://learn.microsoft.com/en-us/cp...utable-version

[aarv]

Found an funny issue, the example script Authors.avs no longer output the text on r4356

[pinterf]

Originally Posted by aarv

Found an funny issue, the example script Authors.avs no longer output the text on r4356

Thanks, investigating, something went astray around the changed MessageClip.

[pinterf]

New build, Merry Christmas!

https://github.com/pinterf/AviSynthP...3.7.6pre-r4392

EDIT:
May need a 14.50.xxx Visual C++ redistributable. Latest V14 redist is from here (permalink to the .exe):
https://aka.ms/vc14/vc_redist.x64.exe
__________________

This is what had happened in the last weeks:

1.) A tremendous amount of time was spent with experimenting with DTL on basic 32 bit float
resampler ideas. The effort involved was measured in man-weeks on my side, and I believe even
more on his. I can say it was good entertainment.

2.) Now that AVX512 is practically killed by Intel on consumer PCs and AVX10 is not yet available,
CPU flags were both simplified and extended. I'm happy, I have i7-11700, so this was like a toy for me.

3.) Compiling ARM64 on Windows with Visual Studio now is as easy as doing an Intel compilation. Since I
tried experimenting with Raspberry Pi 5, I wanted to add ARM64 CPU feature flags - done. This was done
as blind development.

4.) For other changes, see the change log.

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

Actual changelog since last official release:
https://avisynthplus.readthedocs.io/...gelist376.html

20251220 3.7.5.r4392 (pre 3.7.6)
--------------------------------
- "Info": Optimize AVX512 features display, group features, make a bit more compact
- "Info": add L2 cache size display
- "SetMaxCPU": add "avx512base" and "avx512fast" options to enable/disable AVX512 grouped features. see SetMaxCPU .
- ARM64 (aarch64) area:
  - "Info": add ARMV8-A features display (NEON, DOTPROD, SVE2)
  - Add ArmV8-A cpu feature detection (NEON, DOTPROD, SVE2) on ARM64 Windows/Linux/macOS builds. On Windows, 
    only up-to DOTPROD can be detected due to OS limitations.
  - New CPU flags in cpuid.h and avisynth_c.h: CPUF_ARM_NEON, CPUF_ARM_DOTPROD, CPUF_ARM_SVE2
  - "SetMaxCPU": add "neon", "dotprod", "sve2" options to enable/disable ARM64 (aarch64) features.
- New CPU flags: cpuid.h and ``avisynth_c.h - added AVX512 group feature flags CPUF_AVX512_BASE and 
  CPUF_AVX512_FAST (Ice Lake, usable AVX-512 since that point). - added many new AVX512 individual feature 
  flags - added ARM64 feature flags CPUF_ARM_NEON, CPUF_ARM_DOTPROD, CPUF_ARM_SVE2 - CPUF_xxxxx 
  flags are now 64 bit, replace enum with constexpr.
- CMakeLists.txt: avx512 compile flag support for gcc/clang ("fast" Ice Lake-like feature set).
- V12 interface: GetCPUFlagsEx returning 64 bit flags (too many AVX512 subfeatures to fit in 32 bit). C interface: 
  avs_get_cpu_flags_ex. see GetCPUFlagsEx and GetCPUFlags
- V12 interface: L2 cache size query support. New entry in AvsEnvProperty: AEP_CACHESIZE_L2 (C++), AVS_AEP_CACHESIZE_L2 (C) 
  to query L2 cache size in bytes with IScriptEnvironment->GetEnvProperty(). x86/x64 architecture only for now. 
  See AvsEnvProperty .
- Refactor CMakeLists.txt:
  - Correct default of ENABLE_INTEL_SIMD for cross-compiling scenarios (e.g. ARM64 target on x86_64 host) Old logic relied 
    on the host processor: ${CMAKE_SYSTEM_PROCESSOR}
  - Add back option to compile ARM64 builds with Visual Studio on Windows. On VS2026 even clangcl (LLVM) is supported 
    out-of-box for ARM64 platform, easily cross-compilable way from an x64 machine.
  - VDubFilter: allow building on Windows only x86/x64 targets (and not for ARM64).
  - Fix LLVM/clangcl/Intel ICX compile warning: 'WIN32' macro redefined as "#define WIN32 /D_WINDOWS /W3 /GR /EHsc 1 ", 
    when CMake injects a command-line macro wrongly and thus redefines WIN32 . The fix: converts global add_definitions("/D ...") 
    and other option string magics into per-target target_compile_definitions() and target_compile_options(). Thus removing 
    the accidental injection of ${CMAKE_CXX_FLAGS} into add_compile_options(), and prevents the WIN32 macro redefinition.
- Change video-framebuffer over-allocation from 16 to 64 bytes. Allocate 64 bytes more than needed for video frame buffer 
  in order to be able to read 64 bytes safely with AVX512 without risking access violation on the last pixels of the frame.
- rst docs
  - Update GetCPUFlags, add GetCPUFlagsEx
  - Update CPU Feature Flags with AVX512 and ARM64 features
  - Update SetMaxCPU with AVX512 and ARM64 features
  - Update AvsEnvProperty with L2 cache size entry
  - Update Russian GPL notice in UTF-8 format

[tormento]

Originally Posted by pinterf

New build, Merry Christmas!

Likewise!

Originally Posted by pinterf

experimenting with DTL on basic 32 bit float resampler ideas

Any plan about having internals descale routines too? I miss border_handling option from Descale.

Originally Posted by pinterf

AVX10 is not yet available

Luckily Nova Lake is not so far and AVX10.2 support has been confirmed. Eagerly waiting for it to upgrade my ancient i7-2600k

[StainlessS]

And a Merry XMas to you P, and all D9'ers.

[StainlessS]

Hi P, would latest update make it necessary to have a new AvisynthWrapper for MeGUI,
all my MeGUI instances (across machines that I've updated with new AVS+) just disappear in a puff of smoke.
Well actually, no smoke, but MeGUI instance crashes and leaves all of the expanded runtimes in-situ.
(they are usually expanded on running MeGUI, then deleted on close)

[pinterf]

Originally Posted by StainlessS

Hi P, would latest update make it necessary to have a new AvisynthWrapper for MeGUI,
all my MeGUI instances (across machines that I've updated with new AVS+) just disappear in a puff of smoke.
Well actually, no smoke, but MeGUI instance crashes and leaves all of the expanded runtimes in-situ.
(they are usually expanded on running MeGUI, then deleted on close)

Only this one, or the previous build as well?

The XP version was built with VS2026 + MSVC.
Non-XP is VS2026 + clang-cl (LLVM 20.1.8 in present state).

However this had not changed since the previous test.

[StainlessS]

I did not install previous built,
I dont remember why but something made me think that I should not. [EDIT: I think that I had not updated for several versions]

MeGUI log,

Preliminary log file only. During closing of MeGUI the well formed log file will be written.

-[Information] Versions
--[Information] MeGUI: 6.6.6.6 20251116 x64
--[Information] MeGUI Debug Data: available
--[Information] Update Check: Disabled
-[Information] Operating System: Windows 10 Home 22H2 x64 (10.0.19045.6456)
-[Information] .NET Framework: 4.8.1
-[Information] Microsoft Visual C++ 2008 x86:  9.0.21022
-[Information] Microsoft Visual C++ 2010 x64:  10.0.40219
-[Information] Microsoft Visual C++ 2010 x86:  10.0.40219
-[Information] Microsoft Visual C++ 2015-2022 x86:  14.42.34438
-[Information] Redistributables
-[Information] DPI: 100% (96/96)
-[Information] Resolution: 1920x1080
-[Information] Primary Screen: True
-[Information] Monitor 1
-[Information] Resolution: 1920x1080
-[Information] Primary Screen: False
-[Information] Monitor 2
--[Information] System Information
-[Information] Update detection
--[Information] [20/12/2025 19:07:04] Automatic update is disabled
-[Information] Haali Media Splitter: 1.13.138.14 (14-04-2013)
-[Information] Haali DSS2:  (14-04-2013)
-[Information] ICSharpCode.SharpZipLib: 0.85.5.452 (24-03-2024)
-[Information] MediaInfo: 25.10.0.0 (05-11-2025)
-[Information] SevenZipSharp: 0.64.3890.29348 (24-03-2024)
--[Information] [20/12/2025 19:07:04] Using cached update config and server: http://megui.org/auto/fork/
-[Information] 7z: 9.20 (24-03-2024)
--[Information] Component Information
-[Information] Version: 1.0.3000.1
-[Information] Date: 25-11-2024
-[Information] Interface: 6
-[Information] AviSynth Wrapper
--[Information] [20/12/2025 19:07:04] No package requires an update
--[Information] [20/12/2025 19:07:04] redist files copied: 2019_x64

[StainlessS]

I re-installed older version that I had been using,

64 Bit Avisynth+ 3.7.5 (r4289, 3.7, x86_64) (3.7.5.0)

as shown by Groucho "setavs.cmd".

Now working OK again.

EDIT: I installed only (the broken instance) the normal one, no clang, no XP.

EDIT: And my i5-11400T shows the same AVX512 flags as my i7-11700. (I was curious if different, but not)

[pinterf]

This one seems a bit outdated: Microsoft Visual C++ 2015-2022 x86: 14.42.34438.
but it's for x86, your MEGUI is x64.
The x64 redist file - if the '2019_x64' line is valid, then it is also very-very old.
Its name is no longer 2015- but 2017-. I'd try to download the latest one.

[pinterf]

The "normal" one is the clang version. But it's just the compiler, the redistributable is the same as of the MSVC version.
Maybe it needs a newer one. Maybe.
EDIT: Yes, it is probably hungry for a newer one. You have 14.25.28508, which seems to be not good for the new dll.

It's crashing in MEGUI's copy of that almost 6 year old redistributable: msvcp140_1.dll

'MeGUI.exe' (Win32): Loaded 'C:\MeGUI\AviSynth.dll'. Symbols loaded.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\winmm.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\msvfw32.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\avifil32.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\MeGUI\vcruntime140.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\MeGUI\msvcp140.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\MeGUI\vcruntime140_1.dll'. Symbol loading disabled by Include/Exclude setting.
Exception thrown at 0x00007FFEA5EB2EB0 (msvcp140.dll) in MeGUI.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

msvcp140_1.dll 31 728 2020.01.08 01:09 -a--

EDIT2:
Latest V14 redist is from here (permalink to the .exe)
https://aka.ms/vc14/vc_redist.x64.exe

EDIT3:
By copying the newer msvc*.dll files from my System32 folder to the local MeGUI folder, MEGUI stopped crashing.

[StainlessS]

Well sussed out P, I'll point Kurt over here.

[qyot27]

Originally Posted by pinterf

3.) Compiling ARM64 on Windows with Visual Studio now is as easy as doing an Intel compilation. Since I
tried experimenting with Raspberry Pi 5, I wanted to add ARM64 CPU feature flags - done. This was done
as blind development.

- Refactor CMakeLists.txt:
- Add back option to compile ARM64 builds with Visual Studio on Windows. On VS2026 even clangcl (LLVM) is supported
out-of-box for ARM64 platform, easily cross-compilable way from an x64 machine.

It was always easy to build for ARM64 from Visual Studio. That wasn't the point.

The restriction was there to stop the core/plugin C++ ABI madness and only support MinGW and the Itanium C++ ABI on non-x86 platforms. ClangCL uses MSVC's ABI, which means it only perpetuates the problem we had on x86.

[pinterf]

Originally Posted by qyot27

It was always easy to build for ARM64 from Visual Studio. That wasn't the point.

The restriction was there to stop the core/plugin C++ ABI madness and only support MinGW and the Itanium C++ ABI on non-x86 platforms. ClangCL uses MSVC's ABI, which means it only perpetuates the problem we had on x86.

Yes, I wanted you to ask about Windows case, and if the initial reasons still apply.


Using MinGW is a pain from plugin developers' point of view, I guess that 98% of the lazy developers (including me) will always have troubles and extra efforts compiling and providing their plugins on the ARM64 platform.

This is the practical reality of c++ development on Windows. The MSVC ABI is de-facto standard. So the path of least resistance for an unknown (I mentioned 98% but I'm sure it's something like that) percent of plugin developers on Windows is Visual Studio and the MSVC toolchain.

I rarely use MinGW, so rarely that I always have to restart the learning curve. Not counting the cross compiling madness (which is a little be less madness once you dig into it, but still is). Most developers use Visual Studio from which it is the same effort to build an ARM64 version as having a Win32 bit output.

2.) Forget what I wrote so far. You may be right. Right now I recalled my Raspberry Pi 5 project - I realized that there are many other platforms which is not Windows but still ARM64. So if I compile and publish an aarch64 plugin, it would work i non-Windows env.

You've made a huge step on creating the rst's.
I'm going to re-read it and update with real-lazy-developers mind-stopping steps. This should workd with practically zero pre-knowledge of MinGW (see my ever-restarting learning curve) - i can make it more detailed ("for dummies") step by step intructions if I find troubles. The most ideal case is a single batch file on my Windows machine which refreshes everything, creates the dll which I can put that into the release pack. Avisynth or plugins or whatever.

[StainlessS]

("for dummies")

Yep, lots of us stupid people out here, the dummier the better.

[DTL]

"I miss border_handling option from Descale."

AVS resizers also do not support different user-defined border handling processing. Only one fixed way.

I found very promising comment about great future of AVS+ filtergraphs performance - https://github.com/pinterf/AviSynthP...avx2.cpp#L1806 . May be already some implementations in 2026.

[tormento]

Originally Posted by DTL

AVS resizers also do not support different user-defined border handling processing.

That's why I "miss" them

[qyot27]

Originally Posted by pinterf

Yes, I wanted you to ask about Windows case, and if the initial reasons still apply.


Using MinGW is a pain from plugin developers' point of view, I guess that 98% of the lazy developers (including me) will always have troubles and extra efforts compiling and providing their plugins on the ARM64 platform.

This is the practical reality of c++ development on Windows. The MSVC ABI is de-facto standard. So the path of least resistance for an unknown (I mentioned 98% but I'm sure it's something like that) percent of plugin developers on Windows is Visual Studio and the MSVC toolchain.

I rarely use MinGW, so rarely that I always have to restart the learning curve. Not counting the cross compiling madness (which is a little be less madness once you dig into it, but still is). Most developers use Visual Studio from which it is the same effort to build an ARM64 version as having a Win32 bit output.

2.) Forget what I wrote so far. You may be right. Right now I recalled my Raspberry Pi 5 project - I realized that there are many other platforms which is not Windows but still ARM64. So if I compile and publish an aarch64 plugin, it would work i non-Windows env.

You've made a huge step on creating the rst's.
I'm going to re-read it and update with real-lazy-developers mind-stopping steps. This should workd with practically zero pre-knowledge of MinGW (see my ever-restarting learning curve) - i can make it more detailed ("for dummies") step by step intructions if I find troubles. The most ideal case is a single batch file on my Windows machine which refreshes everything, creates the dll which I can put that into the release pack. Avisynth or plugins or whatever.

I never try to do any compiling all from memory. I know the basic shape of it due to familiarity, but the Windows/MSVC build commands for AviSynth+ or anything else...nope. I just copy and paste from a text file I first wrote up over ten years ago, modifying it as necessary. I do the exact same thing when building stuff on Linux. Only with the absolute simplest things (like the AviSynth+ core without plugins or letting it autodetect) do I not bother just copy/pasting. It's why the tedious FFmpeg/mpv crosscompile build guide exists in the first place.

I can't say because I don't use an IDE, but VSCode/VSCodium can work with MinGW-w64 GCC (or Clang, if this thread is as straightforward as it seems). I would assume that using it that way wouldn't be *too* different from using Visual Studio, just that it's using standard Clang instead of ClangCL.

As that thread notes, integrating it properly still can be done by pulling in Clang and its tools using MSys2. The last time I looked at it, MSys2 still doesn't have a native ARM version, but Windows 11 resolves that by using an emulator (same as Rosetta on macOS, or FEX - or qemu-user or box86 - on Linux). I eventually just relented and installed the normal x86-64 version on W11 to get access to the MSys2 environment instead of waiting around for a fully ARM-native version, even though the builds were still done in WSL2 using llvm-mingw as detailed below.

MSys2's clang packages for winarm64 would be pulled from llvm-mingw anyway, and WSL2 users can actually just git clone the llvm-mingw repository and run the build script to set up the compiler (which is exactly what I did when creating the ARM64 releases for 3.7.4 and 3.7.5). It also means that cross-compilation from OtherOS->Windows works, so long as you can build llvm-mingw on it (ClangCL can't be used outside of Windows unless you go through possibly convoluted steps to install Visual Studio under Wine or extract the SDK out of it and then rebuild everything).

The Windows on ARM guide in the AviSynth+ docs covers the entire environment setup and build process. I actually just copied the instructions directly out of the aforementioned tedious crosscompile guide, which is why some of the directory names are a little strange (read: this is why all the source code downloads/git clones go into a directory named mpv-build-deps or why it refers to NASM even though NASM is irrelevant for ARM).

Soundtouch and DevIL both exist as MSys2 packages, and are enabled for the clangarm64 target.

[pinterf]

I'm just talking to diffent Mr. AIs. Gemini at the moment.

It started like this: "Navigate to a well-known resource for pre-built GNU toolchains. For AArch64 Linux." This is my problem. Well known. Yes, surely for those who are doing this on a daily base. Then I asked and it helped a little more detailed. So this way of development is simply not that intuitive.

An average plugin developer - I'm not sure that there are many left - will better go running on a 100k trail running event than copy-paste and issue miriads of command lines. Right-click, choose ARM - build, this is what I'd like to achieve.

Some days ago when I wanted to check my commits (which accidentally failed because of committing an orphan "(" ), I made gcc build tests on my old 20.04 WSL. I spent five minutes on a Url not found message, until I figured out the right command line magic: sudo apt-get update

Back to the ARM64 and DLLs world. It turned out that Windows is still different, I though I can make dlls (or .so) for non-Microsoft ABI almost universally. But not (of course, how could I think differently). For Targeting Linux (like my Raspberry Pi 5) I have to install one kind of cross compiler (runs on my x64 Windows, targets RPi5).

And for Windows I need another type of cross compiler. If building build a Windows ARM64 dll, which must be treated and compiled specially, then what is the point of not using Visual Studio and Microsoft tools for that?

Anyway, Gemini (AI) says, that Visual Studio integration is somehow possible though CMake Toolchain files. After installing the toolchain (MinGW-whatever). Something like this, even remote debugging is possible.

# --- aarch64-pi5-toolchain.cmake ---

# Specify the target operating system and architecture
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)

# --- Toolchain Path Configuration ---
# !!! REPLACE THIS WITH YOUR ACTUAL PATH !!!
set(TOOLCHAIN_ROOT "C:/Toolchains/aarch64-linux-gnu")

# The prefix used by the compiler executables (e.g., aarch64-linux-gnu-)
set(TOOLCHAIN_PREFIX aarch64-linux-gnu)

# Specify the C and C++ cross-compilers
set(CMAKE_C_COMPILER   ${TOOLCHAIN_ROOT}/bin/${TOOLCHAIN_PREFIX}-gcc.exe)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_ROOT}/bin/${TOOLCHAIN_PREFIX}-g++.exe)

# Search for programs (like target tools) in the host path
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# Search for libraries and headers only in the target path
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

# Optional: Set Raspberry Pi 5 specific flags for optimization
set(CORTEX_FLAGS "-mcpu=cortex-a76 -mtune=cortex-a76")
set(CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} ${CORTEX_FLAGS}" CACHE STRING "")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CORTEX_FLAGS}" CACHE STRING "")

"Your next step will be to open Visual Studio 2026 and configure a CMake project to use this file. Would you like to proceed with setting up the CMake project in Visual Studio?"

I'm just reading now a lot and try to summarize to myself these steps, then I will compare with yours. But it will take weeks, the holidays are always busy for me.

Or this is its recommendation for ARM64 on Windows:

# --- aarch64-windows-toolchain.cmake ---

# Specify the target operating system and architecture
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR AARCH64)

# Set the C and C++ cross-compilers
set(TOOLCHAIN_ROOT "C:/Toolchains/aarch64-windows-gnu") # Must be different folder!
set(TOOLCHAIN_PREFIX aarch64-w64-mingw32) # Common prefix for Windows target

set(CMAKE_C_COMPILER   ${TOOLCHAIN_ROOT}/bin/${TOOLCHAIN_PREFIX}-gcc.exe)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_ROOT}/bin/${TOOLCHAIN_PREFIX}-g++.exe)

# Search rules are often simpler for MinGW-w64 on Windows hosts
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)