AviSynth+ thread Vol.2

[DTL]

3.7.5 release again missed from first post. Also 3.7.4 dated of 2024 instead of 2025.

[tebasuna51]

Originally Posted by DTL

3.7.5 release again missed from first post. Also 3.7.4 dated of 2024 instead of 2025.

Modified first post (owner pinterf not qyot27), now Current link go always to the last version.

[pinterf]

Originally Posted by tebasuna51

Modified first post (owner pinterf not qyot27), now Current link go always to the last version.

Thanks. I forgot about it. Sometimes I completely disconnect from forums, or else they just suck me in, leaving less time for my actual tasks (this time also Avisynth-related).
By the way, looking at the download counts, the Windows ARM version has more downloads than the XP-specific one. I suppose this is just out of curiosity, since plugin support is quite limited, to say the least.

[FranceBB]

Originally Posted by pinterf

looking at the download counts, the Windows ARM version has more downloads than the XP-specific one. I suppose this is just out of curiosity, since plugin support is quite limited, to say the least.

Speaking of the XP specific version, the installer is installing the "wrong" ImageSeq.dll in plugins+ and DevIL.dll in system32 instead of the XP specific ones. After swapping them with the ones from the "files only" option under the "legacy" subfolder everything worked perfectly again.

About ARM, Windows on ARM has very limited adoption but the laptops are definitely out there. A friend of mine tried it. It's definitely faster than running the x86 version translated on the fly to ARM, but the problem with the ARM version of Avisynth is that you can't have the ARM frameserver run natively and the x86 incompatible plugins run via the translation layer, rather everything has to be ARM (running natively) or x86 (running via the translation layer). You can't mix and match, which is a bummer. By the way, my use case for ARM was different as I was trying to see if I could save some bucks on AWS by running c6g.2xlarge instances (8c/8th 16GB of RAM) powered by a Graviton 2 ARM host instead of using the c6i.2xlarge instances (8c/8th 16GB of RAM) powered by an Intel Xeon 8375C x86_64 host.

$0.3648 (x86) - $0.2918 (ARM) = $0.073 per hour which corresponds to a 20% saving / reduction.

So, if the ARM version manages not not be 20% slower in encoding it will save some pennies on my Avisynth farm.

[qyot27]

Originally Posted by FranceBB

Speaking of the XP specific version, the installer is installing the "wrong" ImageSeq.dll in plugins+ and DevIL.dll in system32 instead of the XP specific ones.

There is no DevIL.dll in the xp installer.

Clearly one of the libraries in the DevIL dependency chain has issues even when you use -T v141_xp to build all of them.

but the problem with the ARM version of Avisynth is that you can't have the ARM frameserver run natively and the x86 incompatible plugins run via the translation layer, rather everything has to be ARM (running natively) or x86 (running via the translation layer). You can't mix and match, which is a bummer.

ARM64X support isn't quite ready in the toolchain. Even when support for ARM64X (aka ARM64EC) lands, I think it's fairly obvious there's a different 800lb. gorilla to contend with there and why you still wouldn't be able to mix and match architectures, with a handful of possible exceptions.

Not to mention whether it applies to a library loading other libraries (like AviSynth+ and its relation to its plugins) vs. an application loading a library (like FFmpeg loading the AviSynth+ core) is something I don't think I've seen a definitive answer to. What I remember of the tests I attempted is that it didn't work in either case, but that was sometime between July-October of last year.

[DTL]

While testing different SIMD versions of processing functions some feature of SetMaxCPU() found with VirtualDub: It does not switch CPU type if 'reload (F2)' script. To really switch CPU type and SIMD functions, full VirtualDub process restart is required.

I do not not know how it works with other editors with avisynth.dll loading like AVSpmod.

Test script:

SetMaxCPU("something")
version
Info()

pinterf reply is normal feature of Windows .dlls loading (and current implementation in AVS+ ?) - https://github.com/AviSynth/AviSynth...ent-2868872022