AviSynth+ thread Vol.2

[tormento]

What kind of script could be used as "synthetic benchmark" to measure AVS+ performance on different CPU/GPU/versions/compilers?

It could be useful to have a standard one including the major possible operations on a video / colorbar and heavy enough to show differences in meaningful terms.

Thanks in advance for all your efforts.

[Stereodude]

Originally Posted by qyot27

Presence or lack of a manifest that launches the application in UTF-8 mode?

It's far easier in many cases to just turn on UTF-8 system-wide and forget about it, as AviSynth just uses whatever the system locale is (even 2.6 is fine with UTF-8 in this scenario; it's not exclusive to Plus). Notepad has defaulted to saving in UTF-8 without BOM for several years now.

Thanks for the tip about UTF-8. It looks like it was an issue with how PowerShell (that I bypassed before posting) and cmd were launching x265, though I don't fully understand it.

I was launching x265 from a Powershell script using Windows PowerShell 5.x (W10 22H2), which had it's own issues with the é in the path and passing a viable command line to x265. I took the é out of the path, so the command line was correct/valid, but I got the error I posted. Installing PowerShell 7.5 and using it instead of 5.x seems to have fixed the script issues with the é in the path and now the same exact command line to jpsdr's x265 build works from PowerShell 7.5 (but didn't in 5.x) and x265 can open the .avs file

[hello_hello]

pinterf,

Thank you very much for the official 3.7.4 release. I have two questions though....
What was the logic behind the resizers defaulting to center chroma placement when (as far as I know) all the other chroma placement aware functions in Avisynth+ such as ConvertToYUV420 default to left.

I've also failed miserably to get either of the Intel 2025 ICX builds you uploaded here to work. I've tried them with Wine on Linux and Windows 11 in VirtualBox, but the result is the same either way and AvsPmod complains it can't find Avisynth.dll. I didn't have a problem with the Intel ICX version from r4246. For the record, I installed AviSynth+ 3.7.4 with vcredist.exe first, then replaced Avisynth.dll in the system32 folder.

Thanks again!

[tebasuna51]

Please explain me that info:

"Use system installs of DevIL and SoundTouch on all platforms, remove in-tree binaries/code"

1) Avs+ 3.7.4 need DevIL.dll in system forder? Or Avs+ 3.7.4 not need it at all ?

Because the Groucho Universal Avisynth Installer delete always devil.dll from system folder when uninstall, and show error when install a Avs version without a devil.dll file.

2) What about SoundTouch? In Avs+ there are always a TimeStretch.dll plugin, and it still are there, with the SoundTouch library.

It is a info only to compile new versions, usseless for final users?

[TR-7970X]

Originally Posted by tebasuna51

Please explain me that info:

"Use system installs of DevIL and SoundTouch on all platforms, remove in-tree binaries/code"

1) Avs+ 3.7.4 need DevIL.dll in system forder? Or Avs+ 3.7.4 not need it at all ?

Because the Groucho Universal Avisynth Installer delete always devil.dll from system folder when uninstall, and show error when install a Avs version without a devil.dll file.

2) What about SoundTouch? In Avs+ there are always a TimeStretch.dll plugin, and it still are there, with the SoundTouch library.

It is a info only to compile new versions, useless for final users?

And there's this, that has a newer build # of devil.dll

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

[hello_hello]

Originally Posted by qyot27

AviSynth+ 3.7.4 has been released. Full changelog on the Github release page. The macOS installer will come later.

When I try to extract AviSynthPlus_3.7.4_20250324-filesonly.7z from here:
https://github.com/AviSynth/AviSynthPlus/releases
The MX Linux archive manager reports an extraction error. 7-Zip on Windows is a bit more informative and reports an unsupported compression method, although in both cases it appears only to be the files in the arm64 folder that won't extract.

Cheers.

[qyot27]

Originally Posted by tebasuna51

Please explain me that info:

"Use system installs of DevIL and SoundTouch on all platforms, remove in-tree binaries/code"

1) Avs+ 3.7.4 need DevIL.dll in system forder? Or Avs+ 3.7.4 not need it at all ?

Because the Groucho Universal Avisynth Installer delete always devil.dll from system folder when uninstall, and show error when install a Avs version without a devil.dll file.

2) What about SoundTouch? In Avs+ there are always a TimeStretch.dll plugin, and it still are there, with the SoundTouch library.

It is a info only to compile new versions, usseless for final users?

tl;dr: it matters for those building it from source, end users will notice only if DevIL was built as a static library, in which case ImageSeq.dll will be significantly larger in size.

Prior to that change it looked like this:

• Windows: several years old build of DevIL 1.7.8 manually checked into the git tree; even if the user could swap out a newer 1.8.0 build in its place afterward (and yes, you could), you're not actually supposed to commit binaries into git
• Linux, macOS, BSD, Haiku: the configure process checks if the DevIL development package is installed (which also typically means the package is up to date using whichever repository system is in use), and enables the plugin if it is

After the change, the checked in binaries are gone and the configure process on Windows checks for the libraries/headers in order to choose whether to build the plugin or not. This also allows for building DevIL as a static library instead, in which case it gets linked into ImageSeq and DevIL.dll is not needed.

AviSynth.dll never needed DevIL.dll, at least as long as AviSynth+ has been around with ImageSource as a separate plugin. Look at the -filesonly package, and it should be immediately clear (DevIL.dll is shipped alongside ImageSeq.dll in the imageseq_xp-legacy directory, while the ImageSeq.dll in the main plugins area is significantly larger in size...because DevIL was linked into it statically). Having a DevIL.dll sitting around in system32 won't impact an ImageSeq that's been linked against a static build of DevIL.

SoundTouch was different in that it wasn't a checked-in binary, it was vendored source code copied over from the actual SoundTouch repository. But it had the similar issue of having to be manually updated by us whenever the actual upstream version of SoundTouch changed, which often would not happen unless we were aware of it (in fact, there was a period where it was extremely out of date, shipping an old 1.x version of the source while upstream was well into the 2.1 or 2.2 area, but I can't remember when precisely that was).

In either case, it means that having up-to-date versions of ImageSeq's and TimeStretch's dependencies don't rely on how things get committed into the AviSynth+ core source repository, and literally anyone building from source can do it. This also means the flexibility to build against either the DevIL SDK that ships as a dynamic .dll or building the entire thing as a static library and making ImageSeq.dll a monolithic file. The same is true of SoundTouch, but vendoring the source code means it was always static; now there is the option of building it as a .dll if you want.

Originally Posted by hello_hello

When I try to extract AviSynthPlus_3.7.4_20250324-filesonly.7z from here:
https://github.com/AviSynth/AviSynthPlus/releases
The MX Linux archive manager reports an extraction error. 7-Zip on Windows is a bit more informative and reports an unsupported compression method, although in both cases it appears only to be the files in the arm64 folder that won't extract.

Cheers.

Use a newer version of 7zip. Presuming that you're on 22.01 because that's what's in Debian stable and MX doesn't seem to provide a portal to check its package versions (so again, I assume it's just using the upstream Debian repos). Debian testing has 24.09; Ubuntu 24.10 has 24.08 (plucky has 24.09), which can extract the arm64 files without spitting back errors about the compression.

7zip upstream does have standalone Linux binaries on their download page, if you'd rather get it directly from them instead of waiting.

[LigH]

Originally Posted by hello_hello

7-Zip on Windows is a bit more informative and reports an unsupported compression method, although in both cases it appears only to be the files in the arm64 folder that won't extract.

I got this issue with an outdated 7-zip version shipped in the Far manager once, months ago. Try to update, v24.09 is the most recent on https://7-zip.org/

[pinterf]

Originally Posted by jpsdr

Hi.
In current AVS+, is faste crop like this crop(1,0,0,0,align=false) still possible, and so creating a non aligned frame after, or is the parameter align just kept for not breaking compatibility but ignored ?
More globaly, is there a minimal alignment value guaranteed whatever you do ? Even using something like env->NewVideoFrame(vi,8) in a plugin code ?

align is just a compatibility parameter, ignored.
Alignment is 64, if the passed parameter (8) is smaller than that, it is ignored.

[pinterf]

Originally Posted by hello_hello

pinterf,

Thank you very much for the official 3.7.4 release. I have two questions though....
What was the logic behind the resizers defaulting to center chroma placement when (as far as I know) all the other chroma placement aware functions in Avisynth+ such as ConvertToYUV420 default to left.

Probably it was created as such in the early 2000s.

[DTL]

It looks the first post in the thread still missed the 3.7.4 release information update.

[DTL]

Originally Posted by pinterf

Alignment is 64, if the passed parameter (8) is smaller than that, it is ignored.

I think alignment of 64 is back-compatible with all previous SIMD from MMX 8bytes via SSE 16 bytes and AVX 32bytes.

If it is requested alignment and it can be > 64 - it will also make row length mod of alignment so plugin can at least make stream-store of several AVX512 64bytes datawords in a single burst up to the very end of row processing loop ?

[DTL]

Originally Posted by LigH

I got this issue with an outdated 7-zip version shipped in the Far manager once, months ago. Try to update, v24.09 is the most recent on https://7-zip.org/

Some not very new WinRAR version also throws some errors about not supported method. But avisynth.dll for windows extracted without errors.

[Jamaika]

Originally Posted by DTL

I think alignment of 64 is back-compatible with all previous SIMD from MMX 8bytes via SSE 16 bytes and AVX 32bytes.

If it is requested alignment and it can be > 64 - it will also make row length mod of alignment so plugin can at least make stream-store of several AVX512 64bytes datawords in a single burst up to the very end of row processing loop ?

For old plugins adapted only to alignment 64 this may be a problem. I am not talking about .dll files. There is no alignment with technological developments.

[DTL]

Alignment > 64 is back compatible with 64 and less. It only waste more RAM with small sizes of frame.

[jpsdr]

Has something changed in the Directshow plugins build settings ? I was able to build the plugin a while ago, now i have compiler errors i didn't have before (Windows 7 x86 environment)...
I also don't understand why the VDub plugin is not showing anymore when i run cmake under my Windows 7 x86 environment (1) (VS2019 11.31) , but it appears magicaly under my Windows 7 x64 environment (VS2019 9.26 + last version of LLVM)...
BAT file for (1) :

@mkdir x64
@mkdir x86

@cd x86
G:\CMakex86\bin\cmake -G "Visual Studio 16" -A Win32 ../../../Visual_2010/AviSynthPlus -DENABLE_PLUGINS=ON -DBUILD_DIRECTSHOWSOURCE=ON -DENABLE_INTEL_SIMD=ON -DBUILD_SHARED_LIBS=ON -DENABLE_CUDA=OFF -DWINXP_SUPPORT=OFF -DCMAKE_CXX_FLAGS_RELEASE="/sdl- /MP /Ob2 /O2 /Oi /Ot /Oy /GT /GL /GF /GS- /Gy /Qpar /openmp /arch:SSE2 /MD" -DIL_LIBRARIES="F:\PRG\Visual_2019\AviSynth\Deps\DevIL\lib\x86\Release\DevIL.lib" -DILU_LIBRARIES="F:\PRG\Visual_2019\AviSynth\Deps\DevIL\lib\x86\Release\ILU.lib" -DCMAKE_PREFIX_PATH="F:\PRG\Visual_2019\AviSynth\Deps\Soundtouch\x86;F:\PRG\Visual_2019\AviSynth\Deps\DevIL" -DPKG_CONFIG_EXECUTABLE="G:\PKGConfig\pkg-config.exe"

@cd ..\x64
G:\CMakex86\bin\cmake -G "Visual Studio 16" -A x64 ../../../Visual_2010/AviSynthPlus -DENABLE_PLUGINS=ON -DBUILD_DIRECTSHOWSOURCE=ON -DENABLE_INTEL_SIMD=ON -DBUILD_SHARED_LIBS=ON -DENABLE_CUDA=OFF -DWINXP_SUPPORT=OFF -DCMAKE_CXX_FLAGS_RELEASE="/sdl- /MP /Ob2 /O2 /Oi /Ot /Oy /GT /GL /GF /GS- /Gy /Qpar /openmp /arch:SSE2 /MD" -DIL_LIBRARIES="F:\PRG\Visual_2019\AviSynth\Deps\DevIL\lib\x64\Release\DevIL.lib" -DILU_LIBRARIES="F:\PRG\Visual_2019\AviSynth\Deps\DevIL\lib\x64\Release\ILU.lib" -DCMAKE_PREFIX_PATH="F:\PRG\Visual_2019\AviSynth\Deps\Soundtouch\x64;F:\PRG\Visual_2019\AviSynth\Deps\DevIL" -DPKG_CONFIG_EXECUTABLE="G:\PKGConfig\pkg-config.exe"

pause

BAT file for (2) :

@mkdir x64_Broadwell
@mkdir x86_Broadwell

@cd x86_Broadwell
G:\CMakex64\bin\cmake -G "Visual Studio 16" -A Win32 ../../../Visual_2010/AviSynthPlus -DENABLE_PLUGINS=ON -DBUILD_DIRECTSHOWSOURCE=ON -DENABLE_INTEL_SIMD=ON -DBUILD_SHARED_LIBS=ON -DENABLE_CUDA=OFF -DWINXP_SUPPORT=OFF -DCMAKE_CXX_FLAGS_RELEASE="/sdl- /MP /Ob2 /Oi /Ot /Oy /GT /GL /GF /GS- /Gy /Qpar /arch:AVX2 /MD" -DIL_LIBRARIES="C:\PRG\Visual_2019\AviSynth\Deps\DevIL\lib\x86\Release\DevIL.lib" -DILU_LIBRARIES="C:\PRG\Visual_2019\AviSynth\Deps\DevIL\lib\x86\Release\ILU.lib" -DCMAKE_PREFIX_PATH="C:\PRG\Visual_2019\AviSynth\Deps\Soundtouch\x86;C:\PRG\Visual_2019\AviSynth\Deps\DevIL" -DPKG_CONFIG_EXECUTABLE="G:\PKGConfig\pkg-config.exe"

@cd ..\x64_Broadwell
G:\CMakex64\bin\cmake -G "Visual Studio 16" -A x64 ../../../Visual_2010/AviSynthPlus -DENABLE_PLUGINS=ON -DBUILD_DIRECTSHOWSOURCE=ON -DENABLE_INTEL_SIMD=ON -DBUILD_SHARED_LIBS=ON -DENABLE_CUDA=OFF -DWINXP_SUPPORT=OFF -DCMAKE_CXX_FLAGS_RELEASE="/sdl- /MP /Ob2 /Oi /Ot /Oy /GT /GL /GF /GS- /Gy /Qpar /arch:AVX2 /MD" -DIL_LIBRARIES="C:\PRG\Visual_2019\AviSynth\Deps\DevIL\lib\x64\Release\DevIL.lib" -DILU_LIBRARIES="C:\PRG\Visual_2019\AviSynth\Deps\DevIL\lib\x64\Release\ILU.lib" -DCMAKE_PREFIX_PATH="C:\PRG\Visual_2019\AviSynth\Deps\Soundtouch\x64;C:\PRG\Visual_2019\AviSynth\Deps\DevIL" -DPKG_CONFIG_EXECUTABLE="G:\PKGConfig\pkg-config.exe"

pause

[qyot27]

There was something strange with DSS during the release process, but when I looked at the commit history either nothing had touched that part of the code or it wasn't immediately obvious it had anything to do with the errors I was seeing. For whatever reason, only v141_xp/WINXP_SUPPORT=ON is able to build DirectShowSource. Regular v141 as well as the current VS2019 toolset (v142 or v143, not sure which it is) was not able to. It was erroring out over problems in the baseclasses headers which hadn't been touched (something about {dtor}), as well as some const array things in DSS itself that I figured were probably failing only because of the baseclasses error. If it was something in DSS itself that caused it, the only thing recent enough to have modified anything deeper than just some boilerplate was when the utf8 parameter support was added in late 2023; but I don't see how that would still compile with v141_xp and not with the others.

So yeah, due to that, the DirectShowSource.dll in all of the x86/x64 variants is actually the XP one, because that's the only one that would build. My guess is that it's something in VS2019 itself, because it was fine when I built the release for 3.7.3.

With VDubFilter, that's probably due to the architecture check at https://github.com/AviSynth/AviSynth...eLists.txt#L57 ; that seems to be a partial mistake, as it can recognize AMD64 but it doesn't recognize X86, even though I thought the value of CMAKE_SYSTEM_PROCESSOR derives from what the system's PROCESSOR_ARCHITECTURE variable sets, not what exists in, for example, TargetArch.cmake. Change that from X86 to i386 and see if it builds on 32-bit.