AviSynth+ thread Vol.2

[gispos]

Yep, I'm looking into the Avspmod issue.
(for myself: Avspmod is calling avs_release_value on an array, I don't understand why. The array has two elements, the first is a string containing the whole text of the script, the second is the full path with filename of the script.)
EDIT:
the array [script, filename] on which avs_release_value is called is assembled here:
self.clip = self.env.invoke('Eval', [script, filename])
EDIT2:
Issues are not enabled on AvsPMod repo, so I started a discussion:
https://github.com/gispos/AvsPmod/discussions/16

No, not to an array, the parameters are passed with a Python list and the return is a clip which is then released at some point.
The error occurs when releasing the AVS_Value, which I cannot understand.

If I remember correctly, at least in older Avisynth versions it even indicates that the AVS_Value should be released.
Python is probably stubborn, I have no problems with Delphi and the new Avisynth r4176

The new AvsPmod version should work. I hope. ;)

[pinterf]

Thank you very much for the quick reaction!

[pinterf]

Testing further news.
The latest version of avisynth does not like the latest version of l-smach.
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/7dc8ba9295aafa5e99a59903cdd62c4fffc512a5
https://github.com/AviSynth/AviSynthPlus/commit/528b67805ae218c08703ef71dd0cbce5bd7335b2

LWLibavAudioSource("input.mp4")
Assertion failed: IsArray() && index>=0 && index<array_size, file interface.cpp, line 975

Asserts are our friends. If Avisynth is built in debug configuration, they are live, otherwise do nothing.
I get asserts for fmtconv bit depth conversion plugin, which shows that the plugin writer may not check the parameter validity or type before getting its value. Though the assert is given by Avisynth, it signals to the plugin writer to do some more serious check, before using AsBool, AsInt, or indexing an array (in your present example) which is probably Undefined.

For example, from tormento's script I got assertion on each debug run, because of this line:
https://github.com/EleonoreMizo/fmtconv/blob/master/src/fmtcavs/Bitdepth_avs.cpp#L65
Calling AsBool() on an undefined value.
(Then I commented the bit depth conversion out from the script because if didn't let me debug the other stuff, always stopped at this point at each run.)

Assert exists in Avisynth script syntax as well, script writers are using that for checking compulsory parameters or parameter value ranges.
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_internal_functions_control.html#assert

[pinterf]

In 2023 we had some issue with not very nice conversion YUV <-> RGB with narrow range and pinterf wrote some fix was made but not applied to AVS. Was it finally added to the latest release (or some previous tests) ? Last note about some work in progress I found https://github.com/AviSynth/AviSynth...ent-1587607946

Test script to check

ColorBarsHD(640, 480, pixel_type="YV24")
ConvertToRGB32(matrix="PC.709")

If issue is present - it creates RGB with > +-1 LSB errors.

In r4173 it looks fixed. But where to find its note in the change log ?
Looking at the list,
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html

either this
"Studio RGB (narrow, limited) range will now be recognized (through _ColorRange=1) and utilized in conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx"
or
"Leave _ColorRange frame property as-is, when using matrix names "PC.709" or "PC.601", for example in ConvertToRGB32."
fixed it.
On second sight, the second one must have been do the fix, since the first is for converting _from_ rgb (ColorBars creates studio rgb) .

[pinterf]

New build, involving qyot27's fix on C interface header.
Download Avisynth+ 3.7.3+ r4177 (Win x86, x64, xp friendly)
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4177

As always, I link the changes since the latest official release.
https://avisynthplus.readthedocs.io/...gelist374.html
and
https://avisynthplus.readthedocs.io/...in-the-api-v11

[Jamaika]

Thanks for the answer. That means there's a bug on my end :D. I found it. I didn't add [fill_audio_gaps]b. How did it compile in gcc?
Now l-smash works. My oversight.

Improved version of avisynth.
https://github.com/AviSynth/AviSynthPlus/commit/afa0ec7fae3591e73ca430cadff9b6b31b791336
Added:
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/pull/83

https://www.sendspace.com/file/eegb0x

The intricacies of amateur Jamaica.
ColorBars(width=640, height=480, pixel_type="yv24")
KNLMeansCL(device_type="cpu",device_id=0,info=true)
Sound problem. For GPU option it works. Of course once the latest Intel OpenCL drivers are installed.

Problem with Asd-g plugins or I don't know how to use it. Since I've already taken it for testing, the question is, are these add-ons necessary and valuable?
There is little information on the wiki or doom9.
It's about options.
y, u, v
Planes to process.
1: Return garbage.
2: Copy plane.
3: Process plane.
Default: y = u = v = 3.
What does return garbage mean? How visually should the effects look on the screen. The same applies to 'Process plane.' Is the displayed effect correct for me?
https://github.com/Asd-g/AviSynth-vsTMM
https://github.com/Asd-g/AviSynth-vsCnr2
https://github.com/Asd-g/AviSynth-vsTTempSmooth
https://github.com/Asd-g/AviSynth-vsTEdgeMask
https://github.com/Asd-g/AviSynth-vsTCanny
https://github.com/Asd-g/AviSynth-vsDeGrainMedian
https://github.com/Asd-g/AviSynth-vsDeblockPP7
https://github.com/Asd-g/AviSynthPlus-vsLGhost
https://github.com/Asd-g/AviSynth-vsTBilateral
https://github.com/Asd-g/AviSynth-vsMSmooth
https://github.com/Asd-g/AviSynth-vsMSharpen

Where is the error?
vsTBilateral(diameterY=5, diameterU=5, diameterV=5, sdevY=1.4, sdevU=1.4, sdevV=1.4, idevY=7.0, idevU=7.0, idevV=7.0, csY=1.0, csU=1.0, csV=1.0, d2=false, kerns=2, kerni=2, restype=0, y=3, u=3, v=3)
Assertion failed: IsClip(), file interface.cpp, line 871

[pinterf]

Thanks for the answer. That means there's a bug on my end :D. I found it. I didn't add [fill_audio_gaps]b. How did it compile in gcc?
Where is the error?
vsTBilateral(diameterY=5, diameterU=5, diameterV=5, sdevY=1.4, sdevU=1.4, sdevV=1.4, idevY=7.0, idevU=7.0, idevV=7.0, csY=1.0, csU=1.0, csV=1.0, d2=false, kerns=2, kerni=2, restype=0, y=3, u=3, v=3)
Assertion failed: IsClip(), file interface.cpp, line 871

I recommend reading the docs.
https://github.com/Asd-g/AviSynth-vsTBilateral/blob/master/README.md
It requires two clip parameters, one is "last", the second clip is missing.
The actual line which is giving you the assertion is
https://github.com/Asd-g/AviSynth-vsTBilateral/blob/master/src/vsTBilateral.cpp#L3208
AsClip is called on an empty (=non-Clip) content.
Provide it by name or as an unnamed starting parameter.

[tebasuna51]

New build, involving qyot27's fix on C interface header.
Download Avisynth+ 3.7.3+ r4177 (Win x86, x64, xp friendly)
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4177


The AviSynth.dll in x64_xp folder is the 32 bits version, identical to the x86_xp folder.

Installed Avisynth version(s):

32 Bit: AviSynth+ 3.7.3 (r4066, master, i386) (3.7.3.0)
64 Bit: Attempt to load 32 bit avisynth.dll with 64 bit client

[pinterf]

The AviSynth.dll in x64_xp folder is the 32 bits version, identical to the x86_xp folder.
Oops, big thanks, reuploaded.

[Jamaika]

I recommend reading the docs.
https://github.com/Asd-g/AviSynth-vsTBilateral/blob/master/README.md
It requires two clip parameters, one is "last", the second clip is missing.
The actual line which is giving you the assertion is
https://github.com/Asd-g/AviSynth-vsTBilateral/blob/master/src/vsTBilateral.cpp#L3208
AsClip is called on an empty (=non-Clip) content.
Provide it by name or as an unnamed starting parameter.
Maybe I'm stupid, but I don't see it from the examples on doom9.
https://forum.doom9.org/showthread.php?t=107910
https://forum.doom9.org/showthread.php?t=77856
https://forum.doom9.org/showthread.php?t=174904
https://forum.doom9.org/showthread.php?t=181549
What should the test .avsi file look like?

[pinterf]

Maybe I'm stupid, but I don't see it from the examples on doom9.
https://forum.doom9.org/showthread.php?t=107910
https://forum.doom9.org/showthread.php?t=77856
https://forum.doom9.org/showthread.php?t=174904
https://forum.doom9.org/showthread.php?t=181549
What should the test .avsi file look like?
Clicked on the first topic you linked, it was 19 years ago. Haven't clicked any further. I recommend you asking such problems in their relevant topic.

[DTL]

Looking at the list,
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html

either this
"Studio RGB (narrow, limited) range will now be recognized (through _ColorRange=1) and utilized in conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx"
or
"Leave _ColorRange frame property as-is, when using matrix names "PC.709" or "PC.601", for example in ConvertToRGB32."
fixed it.
On second sight, the second one must have been do the fix, since the first is for converting _from_ rgb (ColorBars creates studio rgb) .

There are many words around (about some additions of new features) but no about fixing old bug with missing 224/219 scaling and increased error of YUV <-> RGB conversions. The error was reversible inside AVS conversions so not greatly visible. But if attempt to mix AVS and external conversions the error may accumulated to high values.

The note about finally implemented and applied to release build fix expected in "Bugfixes" section. Something like 'Fixed (old, initial ?) error with YUV to RGB (and back) matrix operations/conversions resulting in decreased precision and higher compute errors". Or may be different text. Now the core computing of matrix is fixed and result better fit the industry ITU Recs 601/709/2020.

Looks like link to github discussion was truncated. This expected to work https://github.com/AviSynth/AviSynthPlus/issues/354#issuecomment-1586932009

[Emulgator]

Thank You Ferenc!
AviSynth64 r4177: filename parsing solved, some simpler scripts do run.
More complicated stuff: 3 subscripts give me access violations, digging as we speak.

TransformsPack Main 2.2.1i.avsi line 175:
#174 fs = propNumElements(a,"_ColorRange") > 0 ? \
#175 propGetInt (a,"_ColorRange") == 0 : rgba

ResizersPack 12.2.avsi line 670:
#669 isy ? ExtractR().ConvertBits(bi, dither=1, fulls=true, fulld=!tv) : \
#670 !rgb ? MatchClip (a,matrix=pri,size=false,props=false) : last

RIFE-based Interpolation line261
#261 fold2blank = RIFEwrap(Interpolsource, framenum=2*Round(framerate(Interpolsource)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)

[DTL]

"What does return garbage mean? How visually should the effects look on the screen. The same applies to 'Process plane.' Is the displayed effect correct for me?"

Current ideas:
1 - do nothing (fastest mode) but you got undefined RAM content (any old data in the allocated RAM pages not changed). AVS allocates RAM for the output plane (so output format is valid) - but the plugin does not write anything.
2 - make a copy of input plane to output (slower)
3 - make full plugin process the plane and write processed result to output (may be slowest).

If AVS runs on Windows only (or in the case of Windows) - there are Windows API RAM allocations returning zeroed RAM pages (by some idle background CPU thread if possible). But as AVS is C-only and non-Windows API using (even if running on Windows host) - it mostly probably uses C-API memory allocations so got RAM pages non-initialized.

[pinterf]

Thank You Ferenc!
AviSynth64 r4177: filename parsing solved, some simpler scripts do run.
More complicated stuff: 3 subscripts give me access violations, digging as we speak.

TransformsPack Main 2.2.1i.avsi line 175:
#174 fs = propNumElements(a,"_ColorRange") > 0 ? \
#175 propGetInt (a,"_ColorRange") == 0 : rgba

ResizersPack 12.2.avsi line 670:
#669 isy ? ExtractR().ConvertBits(bi, dither=1, fulls=true, fulld=!tv) : \
#670 !rgb ? MatchClip (a,matrix=pri,size=false,props=false) : last

RIFE-based Interpolation line261
#261 fold2blank = RIFEwrap(Interpolsource, framenum=2*Round(framerate(Interpolsource)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)
Using the functions above did not show any problem, so I'd need a little bit more of your scripts. I suppose, I have to get these packs from Dogway repo? Then I need only a smaller script that crashes.

[Jamaika]

"What does return garbage mean? How visually should the effects look on the screen. The same applies to 'Process plane.' Is the displayed effect correct for me?"

Current ideas:
1 - do nothing (fastest mode) but you got undefined RAM content (any old data in the allocated RAM pages not changed). AVS allocates RAM for the output plane (so output format is valid) - but the plugin does not write anything.
2 - make a copy of input plane to output (slower)
3 - make full plugin process the plane and write processed result to output (may be slowest).

If AVS runs on Windows only (or in the case of Windows) - there are Windows API RAM allocations returning zeroed RAM pages (by some idle background CPU thread if possible). But as AVS is C-only and non-Windows API using (even if running on Windows host) - it mostly probably uses C-API memory allocations so got RAM pages non-initialized.
Thanks for answer. I will answer what don't like for ffmpeg/avisynth.
Test: vsTCanny(sigmaY=1.50, sigmaU=1.50, sigmaV=1.50, sigma_vY=1.50, sigma_vU=1.50, sigma_vV=1.50, t_h=8.0, t_l=1.0, mode=1, op=1, scale=1.0, y=1, u=1, v=1, opt=-1)
Video doesn't play and starts convulsing. The screenshot looks weird.
ffmpeg_avx2.exe -i AudioBoost.avs -s 640x360 -t 1.000 -v:frames 1 frame001_1.png
https://i.postimg.cc/XvYGCWcT/frame001-1.png
Test: vsTCanny(sigmaY=1.50, sigmaU=1.50, sigmaV=1.50, sigma_vY=1.50, sigma_vU=1.50, sigma_vV=1.50, t_h=8.0, t_l=1.0, mode=1, op=1, scale=1.0, y=2, u=2, v=2, opt=-1)
It looks like the movie is being played without any effects.
https://i.postimg.cc/59zB1w4T/frame001-2.png
Test: vsTCanny(sigmaY=1.50, sigmaU=1.50, sigmaV=1.50, sigma_vY=1.50, sigma_vU=1.50, sigma_vV=1.50, t_h=8.0, t_l=1.0, mode=1, op=1, scale=1.0, y=3, u=3, v=3, opt=-1)
Screenshot with effect. The question is, should this be final effect?
https://i.postimg.cc/CK7HqYB8/frame001-3.png

Test: vsTEdgeMask (threshY=15.0, threshU=15.0, threshV=15.0, type=5, link=0, scale=1.0, y=1, u=1, v=1, opt=-1)
Video doesn't play and starts convulsing. The screenshot looks weird.
https://i.postimg.cc/TwSYP7xb/frame001-1.png
Test: vsTEdgeMask (threshY=15.0, threshU=15.0, threshV=15.0, type=5, link=0, scale=1.0, y=2, u=2, v=2, opt=-1)
It looks like the movie is being played without any effects.
https://i.postimg.cc/59zB1w4T/frame001-2.png
Test: vsTEdgeMask (threshY=15.0, threshU=15.0, threshV=15.0, type=5, link=0, scale=1.0, y=3, u=3, v=3, opt=-1)
Screenshot with effect. The question is, should this be final effect?
https://i.postimg.cc/0yW3s4Dd/frame001-3.png

Test: vsMSmooth(threshold=6.0, strength=3.0, mask=false, luma=true, chroma=true)
The size of the png file varies.
https://i.postimg.cc/XvjSgF3X/frame001-4.png

Test: vsLGhost(mode=[2, 2, 1, 1], shift=[4, 7, -4, -7], intensity=[20, 10, -15, -5])
The changes are visible. The size of the png file varies.
https://i.postimg.cc/2SV2N7YP/frame001-4.png

Test: vsDeGrainMedian(limitY=4, limitU=4, limitV=4, modeY=1, modeU=1, modeV=1, interlaced=false, norow=false, opt=-1)
The size of the png file varies.
https://i.postimg.cc/9MgFq248/frame001-4.png

Test: vsDeblockPP7(mode=0, y=1, u=1, v=1)
Error: The specified filename 'frame001_1.png' does not contain an image sequence pattern or a pattern is invalid.

Test: vsDeblockPP7(mode=0, y=2, u=2, v=2)
It looks like the movie is being played without any effects.
https://i.postimg.cc/59zB1w4T/frame001-2.png

Test: vsDeblockPP7(mode=0, y=3, u=3, v=3)
The size of the png file varies. I don't know why there is slow motion.
https://i.postimg.cc/T3bQPj7F/frame001-3.png

Test: vsCnr2(mode="oxx", scdthr=10.0, ln=35, lm=192, un=47, um=255, vn=47, vm=255, sceneChroma=true)
No effects. PNG file sizes are the same as the original.
https://i.postimg.cc/59zB1w4T/frame001-2.png

Test: vsTTempSmooth(maxr=5, ythresh=4, uthresh=5, vthresh=5, ymdiff=2, umdiff=3, vmdiff=3, strength=3, scthresh=75.0, fp=true, y=1, u=1, v=1, opt=-1)
Video doesn't play and starts convulsing. The screenshot looks weird.
https://i.postimg.cc/XvYGCWcT/frame001-1.png

Test: vsTTempSmooth(maxr=5, ythresh=4, uthresh=5, vthresh=5, ymdiff=2, umdiff=3, vmdiff=3, strength=3, scthresh=75.0, fp=true, y=2, u=2, v=2, opt=-1)
It looks like the movie is being played without any effects.
https://i.postimg.cc/15sw2Jt5/frame001-2.png

Test: vsTTempSmooth(maxr=5, ythresh=4, uthresh=5, vthresh=5, ymdiff=2, umdiff=3, vmdiff=3, strength=3, scthresh=75.0, fp=true, y=3, u=3, v=3, opt=-1)
The size of the png file varies.
https://i.postimg.cc/hjbTt5Pj/frame001-3.png

Test: tfm(pp=7,tdeint(mode=2,type=3)).tdecimate(mode=1)
Slow motion visible. Framerate changed from 60fps to 48fps. Unwanted ugly frames visible.
https://i.postimg.cc/ZnGqPGG2/frame-016.png

[Emulgator]

Then I need only a smaller script that crashes.
I will reduce until I find something reproducible.
For now the roadblock seems to be that my RIFE interpolation script calls RIFEWrap within Dogway's Resizer's pack 12.2 avsi
which seems to fail while deriving properties. YUV420P16 goes in there.
Just calling RIFE directly works fine:
#[*# +++++ Start of Block "AI-based fps-Upconversion" +++++
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:l=>rgb:709:709:f", cpu_type="avx512_snc") # RIFE only works with RGB floats
Rife(gpu_thread=1, model=48, fps_num=60000, fps_den=1001, sc=true, sc_threshold=0.12) # motion interpolate to 59.94 fps
z_ConvertFormat(pixel_type="YUV422P10", colorspace_op="rgb:709:709:f=>709:709:709:l", cpu_type="avx512_snc")
#*]# -------- End of Block "AI-based fps-Upconversion" --------
Reducing my script further...
Baaah. My fault ! I must not assign last (anymore, it was legal in earlier AviSynth versions) !
Notworking:
last=s1++s2++s3++s4++s5++s6++s7++s8++s9++s10++s11++s12++s13++s14++s15++s16++s17++s18++s19++s20++s21
Working:
s1++s2++s3++s4++s5++s6++s7++s8++s9++s10++s11++s12++s13++s14++s15++s16++s17++s18++s19++s20++s21
Seems solved so far, sorry for the incontinence ;-)
P.S. No, not. Does not solve it. Just a small inbetweenie. I had a Smooth16() conversion commented out in that go.
The fault seems to stay with YUV420P16.
No. Its murkier. I simplify, comment script sections out and what loaded before does not load anymore, just CPU blowing warm air.
Nevermind, something sticks here.
RIFEWrap needs attention.

[DTL]

Thanks for answer. I will answer what don't like for ffmpeg/avisynth.
Test: vsTCanny(sigmaY=1.50, sigmaU=1.50, sigmaV=1.50, sigma_vY=1.50, sigma_vU=1.50, sigma_vV=1.50, t_h=8.0, t_l=1.0, mode=1, op=1, scale=1.0, y=1, u=1, v=1, opt=-1)
Video doesn't play and starts convulsing. The screenshot looks weird.


It is expected user can set plane mode =1 if this plane is not used in the later processing (skipped or fully overwritten). So it is non-production mode for the plane.
Example - for YUV format and processing only Y plane:
Process(y=3, u=1, v=1)
ExtractY()

Mode 2 is pass-through unchanged - in some scripts it may be used (like degrain only luma or only chroma and skip scripting planes extracting-combining and also it is faster).

Mode 3 is normal processing mode and you need to learn how to control plugin and/or look for normal processing examples.

[Jamaika]

Mode 2 is pass-through unchanged - in some scripts it may be used (like degrain only luma or only chroma and skip scripting planes extracting-combining and also it is faster).

Mode 3 is normal processing mode and you need to learn how to control plugin and/or look for normal processing examples.
Error: [avisynth @ 0000024e284851a0] vsTCanny: mode must be -1, 0, or 1.

[Emulgator]

Cut down to simplest: Reloading fails, RIFEWrap within Dogway's Resizer's pack 12.2 avsi
ColorBars(width=640, height=480, pixel_type="YUV444P8") #first loading works, reloading fails
#ColorBars(width=640, height=480, pixel_type="YUV422P8") #first loading works, reloading fails
#ColorBars(width=640, height=480, pixel_type="YUV420P8") #first loading works, reloading fails
#ColorBars(width=640, height=480, pixel_type="RGB32") #fails
#-------- Start of Function Preparation: Loading Function defaults ----------
sourcefps=framerate(last)
RIFEsc=true
aimodel=46
gpunumber=0 # ID for the GPU to use.
#-------- End of Function Preparation: Loading Function defaults ----------
RIFEwrap(last, framenum=2*Round(framerate(last)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)

[DTL]

Mode mean mode of the plane' processing: https://github.com/Asd-g/AviSynth-vsTCanny
y, u, v
Planes to process.
1: Return garbage.
2: Copy plane.
3: Process plane. Always process planes when the clip is RGB.

So you can set each y and u and v to any of the supported modes from 1 to 3 (if input format is not RGB). The documentation is not very nice - you can ask Asd-g to add some more text to explain.

[Jamaika]

It is expected user can set plane mode =1 if this plane is not used in the later processing (skipped or fully overwritten). So it is non-production mode for the plane.
Example - for YUV format and processing only Y plane:
Process(y=3, u=1, v=1)
ExtractY()
Test: vsTCanny(sigmaY=1.50, sigmaU=1.50, sigmaV=1.50, sigma_vY=1.50, sigma_vU=1.50, sigma_vV=1.50, t_h=8.0, t_l=1.0, mode=-1, op=1, scale=1.0, y=3, u=1, v=1, opt=-1)
https://i.postimg.cc/639GbNYC/frame001-4.png
Test: vsTCanny(sigmaY=1.50, sigmaU=1.50, sigmaV=1.50, sigma_vY=1.50, sigma_vU=1.50, sigma_vV=1.50, t_h=8.0, t_l=1.0, mode=0, op=1, scale=1.0, y=3, u=1, v=1, opt=-1)
https://i.postimg.cc/GpzS5bbC/frame001-4.png
Test: vsTCanny(sigmaY=1.50, sigmaU=1.50, sigmaV=1.50, sigma_vY=1.50, sigma_vU=1.50, sigma_vV=1.50, t_h=8.0, t_l=1.0, mode=1, op=1, scale=1.0, y=3, u=1, v=1, opt=-1)
There is some effect. Is this effect correct?
https://i.postimg.cc/CKTTYrVP/frame001-4.png

What about features that don't have a mode option or vsDeblockPP7?

[pinterf]

Cut down to simplest: Reloading fails, RIFEWrap within Dogway's Resizer's pack 12.2 avsi
ColorBars(width=640, height=480, pixel_type="YUV444P8") #first loading works, reloading fails
#ColorBars(width=640, height=480, pixel_type="YUV422P8") #first loading works, reloading fails
#ColorBars(width=640, height=480, pixel_type="YUV420P8") #first loading works, reloading fails
#ColorBars(width=640, height=480, pixel_type="RGB32") #fails
#-------- Start of Function Preparation: Loading Function defaults ----------
sourcefps=framerate(last)
RIFEsc=true
aimodel=46
gpunumber=0 # ID for the GPU to use.
#-------- End of Function Preparation: Loading Function defaults ----------
RIFEwrap(last, framenum=2*Round(framerate(last)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)
Yeah, thank you, will return to it in the evening.

[tormento]

Anyway, I plan to update AVSMeter (I use it frequently).
Thanks for all your efforts.

[tormento]

Download Avisynth+ 3.7.3+ r4177 (Win x86, x64, xp friendly)

LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\DehaloAlpha\Dehalo_alpha.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\Dither\mt_xxpand_multi.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\FineDehalo\FineDehalo.avsi")
DGSource("M:\In\Attack on titan ~858p Dynit\3-15.dgi")
z_ConvertFormat(resample_filter="Bicubic", pixel_type="yuv420p16")
Resize8(1526,858, kernel="z_Spline36Resize", kernel_c="z_Spline36Resize", noring=true, noring_c=true, fullc=true)
z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv444ps")
BM3D_CUDA(sigma=4, radius=3, chroma=true)
BM3D_VAggregate(radius=3)
z_ConvertFormat(resample_filter="spline64",dither_type="error_diffusion",pixel_type="YUV420P16")
FineDehalo(rx=2.2, ry=2.2, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=0.6, brightstr=1.0, showmask=0, contra=0.0, excl=true)
libplacebo_Deband(iterations=5,temporal=false, planes=[3,3,3], threshold=6.0)
fmtc_bitdepth (bits=10,dmode=8)
Prefetch(2,6)

gives me the error:

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4177, master, x86_64) (3.7.3.0)

Resize8
"YUV420P16" is an unsupported color format

(D:/Programmi/Media/AviSynth+/plugins64/Resize8-2024_1101~hello_hello.avsi, line 86)
(M:\In\Attack on titan ~858p Dynit\3-15.avs, line 9)

while 4173 works fine.

[Emulgator]

That would fit my assumptions about a possible properties passing failure.

[pinterf]

That would fit my assumptions about a possible properties passing failure.
Assumption is probably right, I have to understand the reason. Stay tuned.

[jpsdr]

Hi, little question.
Is the DevIL.dll still necessary even with the new build system ?

[qyot27]

Hi, little question.
Is the DevIL.dll still necessary even with the new build system ?
It depends.

What the change did was make the inclusion more flexible, so that it was no longer tethered to the checked-in binaries in the git repo. That's all.

If you build against the DevIL SDK distributed through https://openil.sourceforge.net/, yes, DevIL.dll is still linked to ImageSeq as a separate library.

But you now also have the option to compile DevIL yourself in whatever way you choose, so you could build all of it static and then when it's detected/linked by us, it's included inside ImageSeq and DevIL.dll isn't required. You could also build it just like the SDK did and still require DevIL.dll. Or go further than that and even have the libraries DevIL links to as shared, and you'd end up with many more .dlls required than simply DevIL.dll.

[pinterf]

Resize8
"YUV420P16" is an unsupported color format

This one is solved.
I stupidly called Uppercase from Lowercase as well. This one is fixed.
Now comes Emulgator's problem, maybe it is fixed as well, but dunno. I'm just figuring out what RIFE is how is wrapped and finally, where are the models. (In progress)

[pinterf]

This one is solved.
I stupidly called Uppercase from Lowercase as well. This one is fixed.
Now comes Emulgator's problem, maybe it is fixed as well, but dunno. I'm just figuring out what RIFE is how is wrapped and finally, where are the models. (In progress)
I build new test Avisynth after I tested RIFE.

[Emulgator]

path looks like C:\_PROG\! Video Tools\AVSPLUS373_x64\plugins\models\rife-v4.16_lite_ensembleTrue

[pinterf]

path looks like C:\_PROG\! Video Tools\AVSPLUS373_x64\plugins\models\rife-v4.16_lite_ensembleTrue
Thanks. The knowledge about existance of "models" folder was missing on my part. Unfortunately RIFE with the above short script is just doing fine on my machine, even with the 4177 DLL.
Perhaps the mentioned lowercase bug was affecting other parts, anyway, r4178 is being prepared.

You commented "reloading fails". Reloading to what? (I tried both AvsPMod and Virtualdub2). What is the sign of failure? Message, or simple freeze?

[pinterf]

Test build v4178. The end of lowercase saga. I hope.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4178

[Emulgator]

RIFE alone is doing fine here as well. It is RIFEwrap which fails in r417x, but works in r4066, so might be partly on Dogway's side as well.
Reloading abovementioned ColorBars script in AvsPmod64 2.7.9.0: freeze, some 15% CPU and never returning a frame. Can be killed by hitting close and confirm abort.
Köszönöm szépen (Big Thanks) for r4178, testing...

Ha. I still get the same access violation with my Interpolation script.
I am calling RIFEwrap within ScriptClip. RIFEwrap seems to fail only within ScriptClip.

Reloading fails still, outside Scriptclip. Hm, well, Scriptclip does reload too !
Will reduce my Interpolation script to narrow that down.

What works: Single call RIFEwrap(FrameDouble=true)

[qyot27]

This one isn't new build related:

I'm trying to diagnose a crash ("CAVIStreamSynth: unhandled C++ exception") that's happening when I play back a script through VirtualDub2 (but not in ffplay.exe or AvsPmod). It's completely repeatable and always happens at around the same frame (not always exactly the same frame) and at the crash point VirtualDub is always requesting more than one frame's worth of audio (I've seen between 3 and 10 frames being requested). What I'm seeing, using an intermediate debugging filter, is that the buffer pointer that's passed between GetAudio calls seems to be changing between the filter calling GetAudio and the debugging filter (which then passes the call on to an FFmpegsource2 filter instance). Is that something audio caching does? Is it like an automatically inserted extra filter that will intercept GetAudio calls and may occasionally change the buffer pointer for its own reasons?

It seems to change the pointer often when getting to the source filter, if not every time, but only ever crashes at this particular point (even after hundreds of previous similar splices of clips, done with my own filter). It's quite a complicated script and set of filters so I'm wondering if there's something about this particular combination of calls for audio that is confusing ffmpegsource2 (or, perhaps, confusing AviSynth's audio cache?).
Does it happen with the C-plugin?
https://forum.doom9.org/showthread.php?t=175173

[wonkey_monkey]

Just realised I overlooked something, although the problem remains. I'll try the C plugin.

[pinterf]

"What does return garbage mean? How visually should the effects look on the screen. The same applies to 'Process plane.' Is the displayed effect correct for me?"

Current ideas:
1 - do nothing (fastest mode) but you got undefined RAM content (any old data in the allocated RAM pages not changed). AVS allocates RAM for the output plane (so output format is valid) - but the plugin does not write anything.
2 - make a copy of input plane to output (slower)
3 - make full plugin process the plane and write processed result to output (may be slowest).

If AVS runs on Windows only (or in the case of Windows) - there are Windows API RAM allocations returning zeroed RAM pages (by some idle background CPU thread if possible). But as AVS is C-only and non-Windows API using (even if running on Windows host) - it mostly probably uses C-API memory allocations so got RAM pages non-initialized.
Due to the heavy internal cache usage, physical allocations are rare. Most probably, when a plugin requests a new video frame, it gets an unused, but already allocated buffer area.

When a plane is left unprocessed, this is why you can see the remnants of data from an earlier processed frame.

[pinterf]

RIFE alone is doing fine here as well. It is RIFEwrap which fails in r417x, but works in r4066, so might be partly on Dogway's side as well.
Reloading abovementioned ColorBars script in AvsPmod64 2.7.9.0: freeze, some 15% CPU and never returning a frame. Can be killed by hitting close and confirm abort.
Köszönöm szépen (Big Thanks) for r4178, testing...

Ha. I still get the same access violation with my Interpolation script.
I am calling RIFEwrap within ScriptClip. RIFEwrap seems to fail only within ScriptClip.

Reloading fails still, outside Scriptclip. Hm, well, Scriptclip does reload too !
Will reduce my Interpolation script to narrow that down.

What works: Single call RIFEwrap(FrameDouble=true)
It is reproduced but I don't even know in which module does it hang.

Start AvsPMod
Open script
ColorBars(width=640, height=480, pixel_type="YUV420P8") #first loading works, reloading fails
KillAudio()
LoadPlugin("c:\RIFE\RIFE.DLL")
sourcefps=framerate(last)
RIFEsc=true
aimodel="4.17"
gpunumber=0 # ID for the GPU to use.
RIFEwrap(last, framenum=2*Round(framerate(last)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)

Toggle Preview
Reload Script (ctrl-f5)

Stalls forever. And this is not related to the actual new Avisynth, factory 3.7.3 is doing the same. It can be at any place, on the resource free-allocation, either in Vulkan API or RIFE, or of course it can be Avisynth as well, but we'd have to know what happens on "Reload" under preview. Does RIFE get closed and reinitialized, etc.

[gispos]

It is reproduced but I don't even know in which module does it hang.

Start AvsPMod
Open script
ColorBars(width=640, height=480, pixel_type="YUV420P8") #first loading works, reloading fails
KillAudio()
LoadPlugin("c:\RIFE\RIFE.DLL")
sourcefps=framerate(last)
RIFEsc=true
aimodel="4.17"
gpunumber=0 # ID for the GPU to use.
RIFEwrap(last, framenum=2*Round(framerate(last)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)

Toggle Preview
Reload Script (ctrl-f5)

Stalls forever. And this is not related to the actual new Avisynth, factory 3.7.3 is doing the same. It can be at any place, on the resource free-allocation, either in Vulkan API or RIFE, or of course it can be Avisynth as well, but we'd have to know what happens on "Reload" under preview. Does RIFE get closed and reinitialized, etc.

It hangs when releasing the clip.
Test:
Not F5 but in the context menu tab, 'Release video memory'
It then hangs forever.

Test 2:
Restart AvsPmod do not open the script yet, under Options select 'AvsPmod & Avisynth test'
Then I no longer have any problems, which indicates that it could be due to the Avisynth C interface.

I will take a closer look at it though.

ColorBars(width=640, height=480, pixel_type="YUV420P8") #first loading works, reloading fails
KillAudio()
LoadPlugin("D:\Tools\AviSynth\plugins64\RIFE\RIFE.dll")

sourcefps=framerate(last)
RIFEsc=true
aimodel=46
gpunumber=0 # ID for the GPU to use.
RIFEwrap(last, framenum=2*Round(framerate(last)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)


Test 3, what I noticed:
If the 'Test Option' is turned off again, there are still no problems. Not even with F5.

It is as if something was activated in Avisynth or AvsPmod (but I think less in AvsPmod) that there are no more problems as long as Avisynth is not completely shut down by restarting AvsPmod.

[jpsdr]

@qyot27
As i'm not a masochist, i didn't choose the masochist path, and used the SDK provided. So i need the DLL.
:thanks:

------------------------------

Otherwise, i tried to build soundtouch with LLVM, but it fails.
LLVM is integrated to Visual Studio. I use Visual Studio 2019 Update 9.26 because it's the last one (at leat with 2019, no idea about 2022) on which you can just install "clang option" without installing the compiler, and install manualy (and so update the version) the compiler using the "LLVM-xx.x.x-win64.exe" (or "LLVM-xx.x.x-win32.exe") provided on the LLVM github.
So i create the VS project with CMake, and in the project property, switch the compiler from "Visual Studio" to "clang-LLVM".
It has always worked, but not for soundtouch. Build works fine with MSVC compiler.

[gispos]

It is reproduced but I don't even know in which module does it hang.

Start AvsPMod
Open script
ColorBars(width=640, height=480, pixel_type="YUV420P8") #first loading works, reloading fails
KillAudio()
LoadPlugin("c:\RIFE\RIFE.DLL")
sourcefps=framerate(last)
RIFEsc=true
aimodel="4.17"
gpunumber=0 # ID for the GPU to use.
RIFEwrap(last, framenum=2*Round(framerate(last)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)

Toggle Preview
Reload Script (ctrl-f5)

Stalls forever. And this is not related to the actual new Avisynth, factory 3.7.3 is doing the same. It can be at any place, on the resource free-allocation, either in Vulkan API or RIFE, or of course it can be Avisynth as well, but we'd have to know what happens on "Reload" under preview. Does RIFE get closed and reinitialized, etc.

It hangs when releasing the clip.
Test:
Not F5 but in the context menu tab, 'Release video memory'
It then hangs forever.

Test 2:
Restart AvsPmod do not open the script yet, under Options select 'AvsPmod & Avisynth test'
Then I no longer have any problems, which indicates that it could be due to the Avisynth C interface.

I will take a closer look at it though.

ColorBars(width=640, height=480, pixel_type="YUV420P8") #first loading works, reloading fails
KillAudio()
LoadPlugin("D:\Tools\AviSynth\plugins64\RIFE\RIFE.dll")

sourcefps=framerate(last)
RIFEsc=true
aimodel=46
gpunumber=0 # ID for the GPU to use.
RIFEwrap(last, framenum=2*Round(framerate(last)), frameden=1, model=aimodel, sc=RIFEsc, gpuid=gpunumber)


Test 3, what I noticed:
If the 'Test Option' is turned off again, there are still no problems. Not even with F5.

It is as if something was activated in Avisynth or AvsPmod (but I think less in AvsPmod) that there are no more problems as long as Avisynth is not completely shut down by restarting AvsPmod.

This happens if the test option in AvsPmod is not used and the clip is released.

* release all frames, OK
print('frames released')
time.sleep(1)

* release all clips, OK
print('clips released')
time.sleep(1)

* release the ScriptEnvironment, Failed
self.env = None # it hangs here, but when it is commented out it runs to the end of the procedure and hangs then for ever.
print('env released')
time.sleep(1)

print('release finished')
time.sleep(1)
# at this point all has been released and AvsPmod should do nothing, but the procedure doesn't return, so avisynth doesn't return.


Next test using AviSource for the same script:
AviSource("C:\Users\GPo\Desktop\preview_test.avs")

If I open the same script just once, not directly but with AviSource, there are no more problems with other tabs (scripts) that are loaded directly.
Nothing has changed in AvsPmod, it works just as before and releasing the env works also, theoretically it can only be the Avisynth C interface that has changed something after using it once with AviSource.

[pinterf]

* release the ScriptEnvironment, Failed
self.env = None # it hangs here, but when it is commented out it runs to the end of the procedure and hangs then for ever.


Well, this is easier (for us) than we thought.

avs_delete_script_environment is called.
It deletes all functions.
Deletes all manually and autoloaded plugins.

And when it calls FreeLibrary("RIFE.DLL") it never returns.

[pinterf]

@qyot27
As i'm not a masochist, i didn't choose the masochist path, and used the SDK provided. So i need the DLL.

:)


Otherwise, i tried to build soundtouch with LLVM, but it fails.
LLVM is integrated to Visual Studio. I use Visual Studio 2019 Update 9.26 because it's the last one (at leat with 2019, no idea about 2022) on which you can just install "clang option" without installing the compiler
In Visual Studio 2022 feature installer GUI, this is just two options:

[X] C++ Clang Compiler for Windows (18.1.8)
[X] MSBuild Support for LLVM (clang-cl) toolset

But Asd-g for example is using the latest one, which must be installed and integrated into VS 2022 separately, there was a discussion on github about it.

[wonkey_monkey]

Does it happen with the C-plugin?
https://forum.doom9.org/showthread.php?t=175173

It does. It's all very odd. It's seem like it's something to do with jumping from the start of the source to near the end - if I change the jump to nearer the middle it doesn't happen, and if I skip (in VirtualDub2) to the end of the output (which is just two short segments of the video spliced together with my own filter) before playing from the start, it doesn't happen. Plus I can't seem to get coherent reports from my debugging plugin.

Obviously my splicing filter should be the first suspect, but the crash only seems to happen at the point where GetAudio is being called on the source.

Anyway it's all far too complicated to expect anyone to be able to figure it out at this stage, but I just wanted to check about the audio buffer pointer changing, and whether that might be something audio caching in Avisynth+ is doing. But actually that only seems to happen when there's a GetChannels call changing the number of channels, and the crash happens either way.

[pinterf]

Anyway it's all far too complicated to expect anyone to be able to figure it out at this stage, but I just wanted to check about the audio buffer pointer changing, and whether that might be something audio caching in Avisynth+ is doing. But actually that only seems to happen when there's a GetChannels call changing the number of channels, and the crash happens either way.
Regarding whether it's cache-related or not: Avisynth 3.7.2 did not have audio cache. Version 3.7.3 reintroduced it, essentially using the audio cache code from Avisynth 2.6.

Give 3.7.2 a try.

[gispos]

Well, this is easier (for us) than we thought.

avs_delete_script_environment is called.
It deletes all functions.
Deletes all manually and autoloaded plugins.

And when it calls FreeLibrary("RIFE.DLL") it never returns.

Even if I don't kill the env, avisynth hangs !

#self.env = None # it is commented out !!

print('release finished')
# at this point all has been released and AvsPmod should do nothing, but the procedure doesn't return, so avisynth doesn't return.

Please note that:
Next test using AviSource for the same script:
AviSource("C:\Users\GPo\Desktop\preview_test.avs")

If I open the same script just once, not directly but with AviSource, there are no more problems with other tabs (scripts) that are loaded directly.
Nothing has changed in AvsPmod, it works just as before and releasing the env works also, theoretically it can only be the Avisynth C interface that has changed something after using it once with AviSource.

Video in Archive 7z: https://drive.google.com/file/d/1KgZ2h2uN6X5mFxtY2B38R_Qtk7efvbGQ/view?usp=sharing

And here Test 2: https://forum.doom9.org/showthread.php?p=2014491#post2014491

[wonkey_monkey]

Regarding whether it's cache-related or not: Avisynth 3.7.2 did not have audio cache. Version 3.7.3 reintroduced it, essentially using the audio cache code from Avisynth 2.6.

Give 3.7.2 a try.

Just got a little further ahead and have establised that it's definitely cache.cpp throwing bad_alloc at line 554.

For some reason, frame_range is negative (-1994645504), presumably an overflow.

I'll keep digging.

[pinterf]

Just got a little further ahead and have establised that it's definitely cache.cpp throwing bad_alloc at line 554.

For some reason, frame_range is negative (-1994645504), presumably an overflow.

I'll keep digging.
And is probably set and overflow here in Line 351:
int new_size = (int)(_pimpl->vi.BytesFromAudioSamples(count) + 8191) & -8192;

[wonkey_monkey]

And is probably set and overflow here in Line 351:
int new_size = (int)(_pimpl->vi.BytesFromAudioSamples(count) + 8191) & -8192;

Nope, line 380:

int new_size = (int)(_pimpl->vi.BytesFromAudioSamples(std::max(count, _pimpl->AudioCacheStart + (int64_t)_pimpl->CacheCount - start)) + 8192) & -8192; // Yes +1 to +8192 bytes


GetAudio is being called with start = 240000 and count = 24000.

Edit: _pimpl->MaxSampleCount = 96084352

[pinterf]

Nope, line 380:

int new_size = (int)(_pimpl->vi.BytesFromAudioSamples(std::max(count, _pimpl->AudioCacheStart + (int64_t)_pimpl->CacheCount - start)) + 8192) & -8192; // Yes +1 to +8192 bytes


GetAudio is being called with start = 240000 and count = 24000.

Edit: _pimpl->MaxSampleCount = 96084352
Good catch, I searched only for explicite CACHE_AUDIO_AUTO_START_ON text.
Fix? Something like this:
int64_t new_size = (_pimpl->vi.BytesFromAudioSamples(std::max(count, _pimpl->AudioCacheStart + _pimpl->CacheCount - start)) + 8192) & -8192; // Yes +1 to +8192 bytes
new_size = std::min((int64_t)8192 * 1024, new_size);
_RPT2(0, "CA:%x: Autoupsizing buffer to %d bytes!\n", this, (int)new_size);
SetCacheHints(_pimpl->AudioPolicy, (int)new_size); // updates maxsamplecount!!

[wonkey_monkey]

Yay, bug squished! Thanks pinterf.

Is it of any concern that the logic should come close to allocating such a large cache (if not for the std::min)? Is it just because I jumped 40 minutes ahead in the same clip?

[pinterf]

Yay, bug squished! Thanks pinterf.

Is it of any concern that the logic should come close to allocating such a large cache (if not for the std::min)? Is it just because I jumped 40 minutes ahead in the same clip?
I think the 8 MB size I see in the code is just a logical limit. And yes, simply jumping 40 minutes triggered the overflow.

[pinterf]

Even if I don't kill the env, avisynth hangs !

#self.env = None # it is commented out !!

print('release finished')
# at this point all has been released and AvsPmod should do nothing, but the procedure doesn't return, so avisynth doesn't return.

Please note that:
Next test using AviSource for the same script:
AviSource("C:\Users\GPo\Desktop\preview_test.avs")

If I open the same script just once, not directly but with AviSource, there are no more problems with other tabs (scripts) that are loaded directly.
Nothing has changed in AvsPmod, it works just as before and releasing the env works also, theoretically it can only be the Avisynth C interface that has changed something after using it once with AviSource.

Video in Archive 7z: https://drive.google.com/file/d/1KgZ2h2uN6X5mFxtY2B38R_Qtk7efvbGQ/view?usp=sharing

And here Test 2: https://forum.doom9.org/showthread.php?p=2014491#post2014491
Thanks for the video. I see. I couldn't find those points in the source, are they private? Another question: which line's "env = None" did you comment out?
Edit1: I found the place, I think, putting there printfs I got similar debug window like you had.

Edit2:

New finding.

The reference count of the main clip (script containing RIFE) never reaches zero. As a result, the clip is not destroyed, and the RIFE plugin's "free_filter" is not called.

Clip objects are reference-counted, and their destructor is invoked only when the counter reaches zero. The function avs_take_clip (as_clip) increases the count by one. Copying with avs_copy_value also increases it by one. Conversely, avs_release_clip decreases the count by one, and avs_release_value on a 'clip' type AVS_Value also decreases it.

Each copy_value must have a corresponding release_value pair. Similarly, each take_clip must have a corresponding release_clip pair.

I see that this is handled correctly throughout the code, invoke is ok, copy and release_on_del flags usages, but still, somehow somewhere it misses a clip release.

Since the free_filter callback event is not triggered, RIFE does not clean up and destroy its GPU instance objects. This is likely why simply unloading the DLL causes internal issues.

[VoodooFX]

@pinterf Will the new version require the wrapper to be updated for MeGUI?

[Kurt.noise]

@pinterf Will the new version require the wrapper to be updated for MeGUI?
I tested rev 4178, and the last bundle provided in my releases was ok.

[Emulgator]

Congrats, pinterf and gispos, and many thanks for the effort !
Now further regression testing... Win10P64, i9-11900K+128GB, dGPU RTX3080+16GB, iGPU Intel UHD750
Yes, AvsPmod64 2.7.9.2 can handle AviSynth64+ r4066 and r4178 nicely, releasing works, no stalls on my few attempts.

Still AviSynth64+ r4178 crashes if I call RIFE instances within Scriptclip while r4066 performs nicely.
To exclude any sidesuckers I rewrote my interpolation .avsis to get rid of RIFEwrap.
I am calling RIFE directly now: Much better, huge speed gain !

With which Avs+ version the regression came in ? It seems to be the r41xy versions.

AviSynth64+ r4066: 1 RIFE instance within Scriptclip: Playable in AvsPmod64/Encoders64. Topaz 2.6.4 loads script, sees and processes all frames. Ok.
AviSynth64+ r4073: 1 RIFE instance within Scriptclip: Playable in AvsPmod64. Topaz 2.6.4 immediately sees no frame, range 0..-1. Unusable for Topaz.
AviSynth64+ r4096 Clang: 1 RIFE instance within Scriptclip: Playable in AvsPmod64. Topaz 2.6.4 immediately sees no frame, range 0..-1. Unusable for Topaz.
AviSynth64+ r4096 LLVM: 1 RIFE instance within Scriptclip: Playable in AvsPmod64. Topaz 2.6.4 immediately sees no frame, range 0..-1. Unusable for Topaz.

AviSynth64+ r4173: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod64 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod64 aborts.
Topaz 2.6.4 crashes immediately on script loading.

AviSynth64+ r4177: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod64 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod64 aborts.
Topaz 2.6.4 crashes immediately on script loading.

AviSynth64+ r4178: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod64 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod64 aborts.
Topaz 2.6.4 crashes immediately on script loading.

P.S. I have to repeat those tests.
I found a repeatable race condition which leads to stalled processing, under same hovering CPU/GPU load, even with r4066.
After around ~83% progress rendering slows down sharply until the very same frame seems to be served forever,
sometimes advancing, then stalling, downstream forcing a reloading, but AviSynth+ delivers no more frames
and downstream is waiting forever.

AviSynth64+ r4066 serving a restoration script for frameskipped 29.97->25fps footage.
The sequence is: Skippy 25p -> periodically/manually insert dup-before-skip, obtaining duppy-skippy 29,97p ->
Interpolate over each dup -> obtain smooth moving 29.97p -> Interpolate 2x fps -> 59.94p
The script concatenates various trimmed segments of SelectEvery(5,0,0,1,2,3,4).Assumefps("ntsc_video"),
then calling an Interpolation .avsi which contains ScriptClip loops containing RIFE procedures which are auto-triggered by consecutive dups.
If the SelectEvery() section is commented out (because the source contains no frameskips), all is well, no stalling.
Happens the same on 2 identical machines, System SSDs not exact mirrors, but similar environment.

P.P.S. It just hits me that the rendering getting stuck around 83% progress (5/6) matches the frame ratio (5in/6out) !
Non-matching framecount/current_frame calculation/reporting along SelectEvery/ScriptClip/RIFE?

PPPS. Took SelectEvery() out of the chain.
Played that reduced script in AvsPmod: No problem, plays until the end 100%.
Fed that reduced script to Topaz: 83% stuck.
SelectEvery back in, played the full script in AvsPmod: No problem, plays until the end 100%.
Fed the full script to Topaz: 83% stuck.
It might have to do with how frames are reported to Topaz, I guess; the no frames (0,-1) could point into such direction as well.

Ok, back to intermediates then for such corner cases.

PPPPS: The 83% stuck was Topaz fault choking on audio stream shorter than video.
As I exported a test clip from AvsPmod and threw it into Vegas it beame obvious:
My 25->29 procedures within AviSynth+ led to audio being only 83% of video length.
Workaround: KillAudio() at the start, AudioDub() at the end after all trickery is done.

[pinterf]

AviSynth64+ r4066: 1 RIFE instance within Scriptclip: Playable in AvsPmod64/Encoders64. Topaz 2.6.4 loads script, sees and processes all frames. Ok.
AviSynth64+ r4073: 1 RIFE instance within Scriptclip: Playable in AvsPmod64. Topaz 2.6.4 immediately sees no frame, range 0..-1. Unusable for Topaz.
[...]
If the SelectEvery() section is commented out (because the source contains no frameskips), all is well, no stalling.
Happens the same on 2 identical machines, System SSDs not exact mirrors, but similar environment.

PPPS. Took SelectEvery() out of the chain.
Played that reduced script in AvsPmod: No problem, plays until the end 100%.

Fantastic job on the bug report!
These helped a lot.
There indeed was a commit related to Interleave (which is called by SelectEvery). I'm gonna look at it.

EDIT: Please try with this test build.
EDIT 2: Found the cause of the crash. Test build removed and currently under construction.
EDIT3: The access violation occurred when AviSynth was inside a ScriptClip with a C plugin and getPropInt (or any other runtime getter).
Please try this build (find the 4182-uncommitted version):
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4178

One less bug. Let's see how it is working for you. I had successful reloads and parallel scripts open in the new AvsPMod. Thanks.

[Jamaika]

YUV420P8 doesn't work for me.
if (!vi.IsPlanar() || !vi.IsPlanarRGB() || !vi.IsPlanarRGBA())
throw_error("clip must be planar");

[StainlessS]

Jamaika, is that YOUR code, or Avs+ code ?

If yours (where post is Off Topic in this thread), then how about


if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");

[Jamaika]

Jamaika, is that YOUR code, or Avs+ code ?

If yours (where post is Off Topic in this thread), then how about


if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");

This is of e.g. avsresize but IsPlanar() is present in many add-ons to AVS+.

[StainlessS]

... but IsPlanar() is present in many add-ons to AVS+.
Yep, but you have to use it correctly.

if (!vi.IsPlanar() || !vi.IsPlanarRGB() || !vi.IsPlanarRGBA())
throw_error("clip must be planar");

Your code says, if any one of (IsPlanar, IsPlanarRGB, IsPlanarRGBA) is false then throw error,
so, as at least one of them (actually at least 2 of them) is always false, so will always throw an error.

Mine

if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");

says, if all of (IsPlanar, IsPlanarRGB, IsPlanarRGBA) are false then throw error.

EDIT: This would also work (if all isPlanarXXX false)

if (!vi.IsPlanar() && !vi.IsPlanarRGB() && !vi.IsPlanarRGBA())
throw_error("clip must be planar");

[Jamaika]

So I open the planar documentation. I assume that YUV420P8 is planar so the codec should work but it doesn't for gcc 14.2.0. I'm testing 11.5.0 now. I'll know soon.
http://avisynth.nl/index.php/Planar

[StainlessS]

Just use either of the code snippets I gave in post #3062, it will work, It is your logic that is wrong.

either,


if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");


OR

if (!vi.IsPlanar() && !vi.IsPlanarRGB() && !vi.IsPlanarRGBA())
throw_error("clip must be planar");

[Jamaika]

if (!vi.IsPlanar() && !vi.IsPlanarRGB() && !vi.IsPlanarRGBA())
throw_error("clip must be planar");

I simply deleted it and it worked, but I wonder what IsPlanar() does.

For me, this entry is incorrect.
What is the meaning of writing for the value if (1 and 0 and 0) it will be zero.

[pinterf]

I simply deleted it and it worked, but I wonder what IsPlanar() does.

For me, this entry is incorrect.
What is the meaning of writing for the value if (1 and 0 and 0) it will be zero.
If you read your problematic expression aloud in your native language, you'll likely start to sense what's wrong with it.

[Jamaika]

If you read your problematic expression aloud in your native language, you'll likely start to sense what's wrong with it.
I'm not going to think about it.

It doesn't work. when I delete the record it works.
z_ConvertFormat(pixel_type="YUV420P8", colorspace_op="709:709:709:full=>709:709:709:limited", dither_type="none")

Saved by fastblur
for (int pid = 0; pid < vi.NumComponents(); pid++) {
bool uv = _planes[pid] == PLANAR_U || _planes[pid] == PLANAR_V;
planes.push_back({
vi.IsPlanar() ? _planes[pid] : 0,
vi.IsPlanar() ? 0 : pid,
vi.IsPlanar() ? 0 : vi.NumComponents(),
!(uv || _planes[pid] == PLANAR_A), uv,
uv ? uv_pyramid : y_pyramid,
uv ? sub_w : 0,
uv ? sub_h : 0
});
}

Edit: For gcc 11.5.0 IsPlanar() doesn't work. So my previous arguments are worthless since the basic function doesn't work.
https://www.sendspace.com/file/16t0ja

[StainlessS]

Again, your logic is wrong.
One of the correct ones given

if (!vi.IsPlanar() && !vi.IsPlanarRGB() && !vi.IsPlanarRGBA())
throw_error("clip must be planar");


!IsPlanar !IsPlanarRGB !IsPlanarRGBA AND
0 0 0 0
0 0 1 0
0 1 0 0
0 1 1 0
1 0 0 0
1 0 1 0
1 1 0 0
1 1 1 1 NOT Planar && NOT PlanarRGB && NOT PlanarRGBA, then ThrowError


EDIT: OR,

if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");




IsPlanar IsPlanarRGB IsPlanarRGBA OR NOT
0 0 0 0 1 ! (Planar || PlanarRGB || PlanarRGBA), then ThrowError
0 0 1 1 0
0 1 0 1 0
0 1 1 1 0
1 0 0 1 0
1 0 1 1 0
1 1 0 1 0
1 1 1 1 0

[Jamaika]

!IsPlanar !IsPlanarRGB !IsPlanarRGBA AND
0 0 0 0
0 0 1 0
0 1 0 0
0 1 1 0
1 0 0 0
1 0 1 0
1 1 0 0
1 1 1 1 NOT Planar && NOT PlanarRGB && NOT PlanarRGBA, then ThrowError

Correct train of thought, but it would mean that videos for avsresize must always be interlaced. I don't know anything about that.
http://avisynth.nl/index.php/Avsresize

[StainlessS]

What has interlaced got to do with your assertion about IsPlanar being wrong ???
EDIT: Planar has nothing to do with being interlaced, it is the color format in memory [being in planes, rather than interleaved eg RGB24 or YUY2]
[ Planar can be interlaced or not (ie Progressive), Interleaved color formats can be interlaced or not (ie Progressive) ]

Planar means storage for each color channel is stored separately and contiguously, eg
RGB planar, stored as RRRRRRRRRR, GGGGGGGGGG, BBBBBBBBBB. Each channels pixel values stored together, in planes.
RGB24, RGB Interleaved stored as RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB. Each pixel channels stored together Interleaved (although usually as BGR, I think).

EDIT: Wiki Color Format:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html#color-formats
EDIT: The color formats: RGB, YUY2 and YV12:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/advancedtopics/sampling.html#the-color-formats-rgb-yuy2-and-yv12
EDIT: Colorspaces:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/ColorSpaces.html
Planar:- http://avisynth.nl/index.php/Planar
Interleaved:- http://avisynth.nl/index.php/Interleaved

Interlaced versus field-based video :- http://avisynth.nl/index.php/Interlaced_fieldbased
Advanced topics:- http://avisynth.nl/index.php/Advanced_topics

[Jamaika]

What has interlaced got to do with your assertion about IsPlanar being wrong ???
EDIT: Planar has nothing to do with being interlaced, it is the color format in memory [being in planes, rather than interleaved eg RGB24 or YUY2]
[ Planar can be interlaced or not (ie Progressive), Interleaved color formats can be interlaced or not (ie Progressive) ]

Planar means storage for each color channel is stored separately and contiguously, eg
RGB planar, stored as RRRRRRRRRR, GGGGGGGGGG, BBBBBBBBBB. Each channels pixel values stored together, in planes.
RGB24, RGB Interleaved stored as RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB. Each pixel channels stored together Interleaved (although usually as BGR, I think).

EDIT: Wiki Color Format:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html#color-formats
EDIT: The color formats: RGB, YUY2 and YV12:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/advancedtopics/sampling.html#the-color-formats-rgb-yuy2-and-yv12
EDIT: Colorspaces:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/ColorSpaces.html
Planar:- http://avisynth.nl/index.php/Planar
Interleaved:- http://avisynth.nl/index.php/Interleaved

Interlaced versus field-based video :- http://avisynth.nl/index.php/Interlaced_fieldbased
Advanced topics:- http://avisynth.nl/index.php/Advanced_topics

Maybe, my input codec is:
Planar YUV Formats: I420 0x30323449 12 8 bit Y plane followed by 8 bit 2x2 subsampled U and V planes.

Avisynth function: LWLibavVideoSource [input_yuv420p.mp4, 30000, 1001]
Input #0, avisynth, from 'AudioBoost3.avs': 0KB sq= 0B
Duration: 00:42:05.52, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 704x480, 29.97 fps, 29.97 tbr, 29.97
tbn
The problem is with:
Avisynth function: LWLibavVideoSource [input_yuv420p.mp4, 30000, 1001]
Avisynth function: z_ConvertFormat [YUV420P8, 709:709:709:limited=>709:709:709:limited, none]
[avisynth @ 000002f02ad57f60] avsresize: clip must be planar.

test wiki:
LWLibavVideoSource("input_rgb24.avi",fpsnum=30000,fpsden=1001)
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV420P8", colorspace_op="rgb:709:709:full=>709:709:709:limited")

[avisynth @ 000002f02ad57f60] avsresize: clip must be planar.

[pinterf]

This one is really tricky: I420 is a variant of YV12, but their colorspace constants differ. Some filters can only accept and check against the exact YV12 format.

This is why VideoInfo::IsSameColorspace
- first checks for exact code match,
then if no exact match then
- it compares the two VideoInfo's IsYV12() which reports true even if the clip is I420 _or_ YV12.

[wonkey_monkey]

Some questions spring to mind:

Can we see the whole script, just to make absolutely sure nothing else is happening?
Did you compile both AviSynth+ and AVSResize with GCC? Have you made any other changes to either of them?

[Jamaika]

Did you compile both AviSynth+ and AVSResize with GCC? Have you made any other changes to either of them?
Everything is possible, but this is a curiosity. Is this a gcc, mingw64 bug? Others on this forum add codecs x264,x265,vvenc,...

[wonkey_monkey]

Everything is possible, but this is a curiosity. Is this a gcc, mingw64 bug? Others on this forum add codecs x264,x265,vvenc,...

That doesn't answer my question. I think we may struggle here...

[StainlessS]

By Pinterf
This one is really tricky: I420 is a variant of YV1
I don't really think it is relevant. [But maybe]
It's the c code he's using somewhere [???, wherever he was using it, it WAS WRONG],
Don't know where he's using it.
On occasion some users change avs functions so they don't havta
provide fn args [ EDIT: bad idea ], me is guessing it's something like that.
{ Changes function, then wants help to make it work without telling what weird changes have been made/hard_coded }

Also, maybe should answer Wonkey Donkey questions.

[Emulgator]

Pinterf, hats off to you ! You did it. Beautiful.
Your AviSynth64+ version r4178-4182-uncommitted loads & unloads my reduced script in AvsPmod 2.7.9.2.
Processing finally with even CPU load, no more pulsing, and a beautiful speed gain !
And Topaz 2.6.4 eats the script happily and sees all frames. A dream came true.
Going deeper soon.

[pinterf]

Pinterf, hats off to you ! You did it. Beautiful.
Your AviSynth64+ version r4178-4182-uncommitted loads & unloads my reduced script in AvsPmod 2.7.9.2.
Processing finally with even CPU load, no more pulsing, and a beautiful speed gain !
And Topaz 2.6.4 eats the script happily and sees all frames. A dream came true.
Going deeper soon.
... Somewhere I knew it :) I received a fabulous Sleep Score of 82 from my Garmin. Thanks for your time. I'll make these commits live now.

[tormento]

If only Dogway would take advantage of the new features in his scripts…

[pinterf]

Freshly built v4193.

- 32 and 64-bit XP compatible versions
- 64 bit Intel ICX compiled version (only Avisynth.dll, plugins were just copied)
May require Intel C++ 2025 redistributable: https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html

Download Avisynth+ 3.7.3 r4193 test:
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4193

Changes since official 3.7.3
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#api-v11-whats-new
and millions of updated documentation pages.

[StainlessS]

Lovely, tanx P :)

[TR-9970X]

Surely it must be nearly time for 3.7.4....

[Emulgator]

Woohoo ! Donation on the way.
https://forum.doom9.org/showthread.php?p=2014728#post2014728
Still via this ?
https://buymeacoffee.com/pinterf
Or if paypal, PM me.

[pinterf]

Woohoo ! Donation on the way.
https://forum.doom9.org/showthread.php?p=2014728#post2014728
Still via this ?
https://buymeacoffee.com/pinterf
Or if paypal, PM me.
Thanks :), I tried to hide it well.

[real.finder]

Freshly built v4193.

- 32 and 64-bit XP compatible versions
- 64 bit Intel ICX compiled version (only Avisynth.dll, plugins were just copied)
May require Intel C++ 2025 redistributable: https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html

Download Avisynth+ 3.7.3 r4193 test:
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4193

Changes since official 3.7.3
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#api-v11-whats-new
and millions of updated documentation pages.

I did try it with last avspmod update and it work fine so far (its first time I did try the 64bit test update)
:thanks:

[tormento]

64 bit Intel ICX compiled version
Be my Valentine. :D

[FranceBB]

Who needs chocolate when we have a new Avisynth build to test! :)

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

[gispos]

Freshly built v4193.

- 32 and 64-bit XP compatible versions
- 64 bit Intel ICX compiled version (only Avisynth.dll, plugins were just copied)
May require Intel C++ 2025 redistributable: https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html
.
AvsPmod runs with the Intel ICX build without problems, but I can't open a script with any other program.

Do I have to install the runtimes ?
Is the Intel build better (faster) on an Intel CPU ?

[tormento]

AvsPmod runs with the Intel ICX build without problems, but I can't open a script with any other program.
Yes you have to. Read pinterf release post again. :)

I am using ICX build with AvsPmod with no problems here.

[tormento]

Who needs chocolate when we have a new Avisynth build to test! :)
:eek:

[pinterf]

AvsPmod runs with the Intel ICX build without problems, but I can't open a script with any other program.

Do I have to install the runtimes ?
Is the Intel build better (faster) on an Intel CPU ?
Runtimes are probably needed, but I cannot check since I already have them on my machine because of the tests. The Intel build should be quicker. In this case, the XP builds are using the Visual Studio 2017 compiler, so they probably lack all the 2019 and 2022 Microsoft compiler optimizations. Even if the Intel build were equal to an MSVC 2022 build, the XP builds using 2017 technology are probably slower. However, this may be an urban legend. I guess, the actual speed gain is negligible unless you do synthetic tests using only internal Avisynth functions without using external scripts.

[TR-9970X]

Runtimes are probably needed, but I cannot check since I already have them on my machine because of the tests. The Intel build should be quicker. In this case, the XP builds are using the Visual Studio 2017 compiler, so they probably lack all the 2019 and 2022 Microsoft compiler optimizations. Even if the Intel build were equal to an MSVC 2022 build, the XP builds using 2017 technology are probably slower. However, this may be an urban legend. I guess, the actual speed gain is negligible unless you do synthetic tests using only internal Avisynth functions without using external scripts.

Possibly stupid question....

Why XP builds ?

What build should I use for Ryzen CPU's, using W11 Pro ?

[FranceBB]

Why XP builds ?

What build should I use for Ryzen CPU's, using W11 Pro ?

it's just a term to say that they were compiled using v141_xp which is the Microsoft compiler, MSVC. They run on all versions of Windows from Windows XP all the way up to Windows 11. You're gonna be fine. ;)

As a bit of history, Avisynth has been supporting Windows 98SE and Windows 2000 since its inception on May 19th, 2000. The last Avisynth version, 2.6.1, from 2016, still supported them. When Avisynth+ arrived it brought plenty new things like high bit depth planar support (before we only had stacked and interleaved) and it was a major upgrade from the classic codebase. Support for Windows 98SE and Windows 2000 was dropped and the minimum requirement was bumped up to Windows XP which is still the case right now. :)

[TR-9970X]

it's just a term to say that they were compiled using v141_xp which is the Microsoft compiler, MSVC. They run on all versions of Windows from Windows XP all the way up to Windows 11. You're gonna be fine. ;)

As a bit of history, Avisynth kept supporting Windows 98SE and Windows 2000 since its Inception in April 2000 without dropping it. The last Avisynth version, 2.6.1, from 2016, still supported them. When Avisynth+ arrived it brought plenty new things like high bit depth planar support (before we only had stacked and interleaved) and it was a major upgrade from the classic codebase. Support for Windows 98SE and Windows 2000 was dropped and the minimum requirement was bumped up to Windows XP which is still the case right now. :)

Thanks for that, but to be pedantic, would the Intel build be suitable for Ryzen's, as it seems they might be optimised for Intel CPU's ?

[FranceBB]

Thanks for that, but to be pedantic, would the Intel build be suitable for Ryzen's, as it seems they might be optimised for Intel CPU's ?

The intel builds are created with ICC, the Intel compiler that used to be shipped with Intel Parallel Studio. They're gonna work on the Ryzen as well, but they were originally optimized with Intel Xeon in mind. As for the speed compared to MSVC, they're probably faster even if they're being used on an AMD CPU, but I don't know for sure. You should really try and test yourself with AVSMeter. I only really have an Intel i7 at home and several Intel Xeon at work, so I can't test it for you. :(

Full disclosure: I've been an AMD fanboy since birth, I owned plenty of CPUs the likes of AMD Athlon 1600, AMD Athlon 3200, AMD Athlon 3800, those were great monocore CPUs. Unfortunately, when multi core were introduced, I had one heartbreak after another, starting with the AMD Athlon 64 X2 but the one that made me draw the line was when my AMD Phoenom II X6 1100T, a 6c/6th at 3.3GHz (with boost to 3.7GHz) was being beaten by 4c/8th Intel i7 and was struggling even against 4c/4th Intel i5 of the time. Three years later, in 2013, I moved to Intel and I've never looked back.

[pinterf]

Thanks for that, but to be pedantic, would the Intel build be suitable for Ryzen's, as it seems they might be optimised for Intel CPU's ?
Suitable.

The optimizations applied in our builds are generic "optimize for speed" settings, making them suitable for any processor architecture. It's a one-size-fits-all approach. Even Intel processor generations vary, so if someone wants a finely tuned version for their specific processor type, they would need to do it themselves.

Most of the internal optimizations in Avisynth are handcrafted for SSE2, SSSE3, SSE4.1, AVX2, etc. While not all are implemented, SSE2 and AVX2 are generally covered. Only a few areas have versions written solely in C. Compilers can further optimize our already SIMD-optimized versions, which is where different compilers like Intel C++ Compiler, LLVM, GCC, and MSVC can excel or fall short.

In general, they all do excellent jobs.

[TR-9970X]

The intel builds are created with ICC, the Intel compiler that used to be shipped with Intel Parallel Studio. They're gonna work on the Ryzen as well, but they were originally optimized with Intel Xeon in mind. As for the speed compared to MSVC, they're probably faster even if they're being used on an AMD CPU, but I don't know for sure. You should really try and test yourself with AVSMeter. I only really have an Intel i7 at home and several Intel Xeon at work, so I can't test it for you. :(

Full disclosure: I've been an AMD fanboy since birth, I owned plenty of CPUs the likes of AMD Athlon 1600, AMD Athlon 3200, AMD Athlon 3800, those were great monocore CPUs. Unfortunately, when multi core were introduced, I had one heartbreak after another, starting with the AMD Athlon 64 X2 but the one that made me draw the line was when my AMD Phoenom II X6 1100T, a 6c/6th at 3.3GHz (with boost to 3.7GHz) was being beaten by 4c/8th Intel i7 and was struggling even against 4c/4th Intel i5 of the time. Three years later, in 2013, I moved to Intel and I've never looked back.

Nice, thanks again.

I have a majority of Ryzen's, but I do have a 13900KF, which is only a little "slower" than my 7950X.

I recently built a 32C Thread Ripper system, but haven't really done anything with it yet.

[TR-9970X]

Suitable.

The optimizations applied in our builds are generic "optimize for speed" settings, making them suitable for any processor architecture. It's a one-size-fits-all approach. Even Intel processor generations vary, so if someone wants a finely tuned version for their specific processor type, they would need to do it themselves.

Most of the internal optimizations in Avisynth are handcrafted for SSE2, SSSE3, SSE4.1, AVX2, etc. While not all are implemented, SSE2 and AVX2 are generally covered. Only a few areas have versions written solely in C. Compilers can further optimize our already SIMD-optimized versions, which is where different compilers like Intel C++ Compiler, LLVM, GCC, and MSVC can excel or fall short.

In general, they all do excellent jobs.

:thanks:

[LeXXuz]

I just updated AVS+ from an older build, 4066 IIRC, to the latest version.

Now I get an error in of my scripts saying "There is no function named 'ConvertToDoubleWidth' ".

Would appreciate some help on how to fix this.

[pinterf]

I just updated AVS+ from an older build, 4066 IIRC, to the latest version.

Now I get an error in of my scripts saying "There is no function named 'ConvertToDoubleWidth' ".

Would appreciate some help on how to fix this.
There must be a ConvertStacked.DLL in your Program Files (x86)/Avisynth+/plugins64+ (or plugins+ on 32-bit) folder

[LeXXuz]

There must be a ConvertStacked.DLL in your Program Files (x86)/Avisynth+/plugins64+ (or plugins+ on 32-bit) folder

MeGUI again. :mad: It somehow disliked my updated files and replaced/renamed them on its own. I guess it's about time to switch to a different frontend. :rolleyes:

Thanks pinterf, works fine now. :thanks:

[gispos]

Runtimes are probably needed, but I cannot check since I already have them on my machine because of the tests. The Intel build should be quicker. In this case, the XP builds are using the Visual Studio 2017 compiler, so they probably lack all the 2019 and 2022 Microsoft compiler optimizations. Even if the Intel build were equal to an MSVC 2022 build, the XP builds using 2017 technology are probably slower. However, this may be an urban legend. I guess, the actual speed gain is negligible unless you do synthetic tests using only internal Avisynth functions without using external scripts.
The Intel build behaves very strangely on my PC.
Before installing the runtimes, AvsPmod worked perfectly with the Intel build.
But I could not open a script with any other program.

After installing this Intel® oneAPI DPC++/C++ Compiler Runtime for Windows* 2025.0.0 (https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html), every program I try to open a script with crashes. Also AvsPmod does not run anymore.
What is the error?

VDub2 chrash:

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'VirtualDub64'...

...reading address 0000000000000000.


Edit:
I uninstalled the runtimes and AvsPmod is running again with the Intel build. But no other program.

[tormento]

Please notice that the latest Intel Runtimes are not 2025.0.0 but here (https://www.intel.com/content/www/us/en/developer/tools/oneapi/runtime-versions-download.html?runtimes=cpp-win).

[isidroco]

I hope those intel runtimes won't be required for future 3.74 version, as most of users don't have them installed.

Offtopic: Is there a way to manual install AviSynth 3.7.3+ (is there a .reg file to do it?) Thanks!

[FranceBB]

I hope those intel runtimes won't be required for future 3.74 version, as most of users don't have them installed.

as long as you pick the MSVC builds you won't need them.
Those are in the x86 x64 folders (v143) or x86_xp x64_xp (v141). ;)

[real.finder]

Offtopic: Is there a way to manual install AviSynth 3.7.3+ (is there a .reg file to do it?) Thanks!

try https://forum.doom9.org/showthread.php?t=172124

[gispos]

I have linked the runtimes that Ferenc has linked and that is 2025.0.0
Tormento links version 2025.0.4

With 2025.0.0 every program crashes and I'm annoyed that I now have the garbage left on my system.
I can't believe that 2025.0.4 should behave differently than the 2025.0.0 linked by Ferenc.

Can someone make a clear statement about this before I install another 800mb.
Thanks

[tormento]

Can someone make a clear statement about this before I install another 800mb.
With 2025.0.0 I had crashes when encoding and everything seems fine now with 2025.0.4.

But perhaps it's just a coincidence or a solar flare.

I never had any other sort of problems but the encoding part, perhaps as it's very intensive.

If you don't want to install 800 MB crap, simply use the MSVC version. :p

[DTL]

"I'm annoyed that I now have the garbage left on my system."

Old intel compilers builds do not need to install (register) anything in OS. You only need to add required .dlls in the path (put in the same folder as the AVS .dll or plugin .dll) so that OS executable file loader can find them. It is typically only a pair of dlls. So for 'uninstall' you only delete that .dlls if required.
They are typically libmmd.dll and svml_dispmd.dll . May be it is 'illegal' for freeware software developers to include required intel .dlls in the distributtion (upload to github in release archive ?). But official intel redistributable (with executable installer) may install something more and it can affect other software.

[pinterf]

Oh sorry, I didn't know that it causes so much trouble. Neither know why Intel do not refresh their page with their latest 2025.0.4 version.
I think next time it's better to do the Intel stuff using static linked libraries.

[StvG]

Old intel compilers builds do not need to install (register) anything in OS. You only need to add required .dlls in the path (put in the same folder as the AVS .dll or plugin .dll) so that OS executable file loader can find them. It is typically only a pair of dlls. So for 'uninstall' you only delete that .dlls if required.
They are typically libmmd.dll and svml_dispmd.dll .

It's the same for the new Intel compilers too.

[isidroco]

You only need to add required .dlls in the path ...
They are typically libmmd.dll and svml_dispmd.dll .
Manually extracted those DLL from latest intel_w_dpcpp_cpp_runtime_p_2025.0.4.1522 and copied both to SYSTEM32 and Plugins64 folders. But new avisynth doesn't work.
After previous comments, I refuse to install intel redistributable and will stick with previous AvisynthPlus_3.7.3post_20240131_test14 which doesn't require other "risky" installations.

[FranceBB]

will stick with previous AvisynthPlus_3.7.3post_20240131_test14 which doesn't require other "risky" installations.

Why?
Just use the x86_xp or x64_xp builds, they were compiled with MSVC as usual (i.e the Microsoft v141_xp compiler).

[DTL]

Manually extracted those DLL from latest intel_w_dpcpp_cpp_runtime_p_2025.0.4.1522 and copied both to SYSTEM32 and Plugins64 folders. But new avisynth doesn't work.


Asd-g recommend software for analyse for required dependencies - https://github.com/lucasg/Dependencies/releases . May be other .dlls are required for latest builds with ICX compiler.

At Win10 host it shows only libmmd.dll is missing -
https://i.postimg.cc/SxWZ6wCv/2025-02-23-132346.png
https://i.postimg.cc/SxWZ6wCv/2025-02-23-132346.png

Though libmmd.dll may depend on other Intel .dlls - may be needed to add all one by one.

[pinterf]

Aside from the 2025.0.0 vs 2025.0.4 issue:

The only Intel-specific DLL that the Intel-built AviSynth requires is libmmd.dll, which is a "high performance multithreaded math library." This library likely implements non-standard Intel intrinsics like _mm_sin_ps or _mm_atan2_ps, as well as their 64-bit double versions for trigonometric and other functions.

On my machine, libmmd.dll is located in:
C:\Program Files (x86)\Common Files\intel\Shared Libraries\intel64\
For AvsPMod I had to move this DLL next to avisynth.dll in C:\Windows\System32 to get it to work.

For testing, I loaded AviSynth with:

ctypes.WinDLL('C:\Windows\system32\AviSynth.dll')

It failed to load the Intel-built Avisynth.dll when the libmmd.dll was not next to it.

Seems like this DLL load method does not search the PATH for DLL dependencies.

However I was able to load AviSynth.dll using a different method (altered search path), like this:

import ctypes
from ctypes import wintypes

LOAD_WITH_ALTERED_SEARCH_PATH = 0x00000008

kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
LoadLibraryExW = kernel32.LoadLibraryExW
LoadLibraryExW.argtypes = [wintypes.LPCWSTR, wintypes.HANDLE, wintypes.DWORD]
LoadLibraryExW.restype = wintypes.HMODULE

def load_library_with_altered_search_path(dll_path):
return kernel32.LoadLibraryExW(dll_path, None, LOAD_WITH_ALTERED_SEARCH_PATH)

handle = load_library_with_altered_search_path(path)
if not handle:
raise ctypes.WinError(ctypes.get_last_error())

avidll = ctypes.WinDLL("", handle=handle)

Anyway, my advice is that if someone is using the Intel build with AvsPMod, they should move the necessary libmmd.dll next to Avisynth.dll.

This is applicable if we build it with the /MD option, which requires dynamic linking of the runtime libraries. If we use the /MT option for building Avisynth, it statically links all necessary components into the executable, i can see no extra dependencies.

Probably next time, folks.

[StvG]

This is applicable if we build it with the /MD option, which requires dynamic linking of the runtime libraries. If we use the /MT option for building Avisynth, it statically links all necessary components into the executable, i can see no extra dependencies.

You can keep /MD and add libmmds.lib/svml_disp.lib to the additional linker dependencies - you have MSVC dynamic runtimes with Intel static runtimes. This is how the Intel builds are created here (https://gitlab.com/uvz/AviSynthPlus-Builds).

[pinterf]

You can keep /MD and add libmmds.lib/svml_disp.lib to the additional linker dependencies - you have MSVC dynamic runtimes with Intel static runtimes. This is how the Intel builds are created here (https://gitlab.com/uvz/AviSynthPlus-Builds).
Thanks, so far I just blindly used Avisynth's CMake build ready made out-of-box.

[pinterf]

AviSynth+ r4198

Enjoy the life.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4198

[gispos]

AviSynth+ r4198

Enjoy the life.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4198
Unfortunately I have no luck with the r4198 icx build
No program wants to open an avs.

https://i.postimg.cc/zXSwwh0Y/Avisynth-r4198icx-error.jpg (https://postimages.org/)

Am I missing something else?
I think I have all the normal runtimes installed, at least every other Avisynth version has worked so far.

[DTL]

"optional AVX2 code paths"

From the end of 2024 we have 'full-blood' 512bit AVX512 processing in the Zen5 desktop AMD CPUs for end-users. If it is runtime-selectable it may be good to add also AVX512 auto-optimizations by Intel compiler (in the same file or in separate build).

"I have no luck with the r4198 icx build"

Zero address crash is not simple 'missing .dll' error - it is something more complex. Can you run with debugger attached to show if it is crash in VirtuaDub module and not in avisynth.dll module ? You can first run VirtualDub and attach debugger to its PID and next try to open .avs.

With VirtualDub 1.10.4 at Win7 x64 and E7500 CPU I got not crash but some unknown error in Avisynth :
https://i.postimg.cc/bYQsbZ3H/image-2025-02-24-210210972.png
https://i.postimg.cc/bYQsbZ3H/image-2025-02-24-210210972.png

If attempt to open "version" script (or any other script too ?).

Looks like this error message from AVS core https://github.com/pinterf/AviSynthPlus/blob/57fa8f9e5fe5e871b0658a486d17ea061b096a8e/avs_core/core/main.cpp#L957 . So it loads all libraries OK but something else not working.

Avisynth.dll from "x64_xp_or_better" folder is working.

[pinterf]

I was trying the famous rife script with this intel build and the latest avspmod. What can be the difference? I'm on w11pro, 11th gen i7. It worked fine.

[gispos]

VirtualDub2_64
The Avisynth.dll is loaded and after the VCRUNTIME140_1.dll is loaded the error starts.
Is it possible that the VCRUNTIME140 is not compatible with the Intel runtimes? Or are there newer VC runtimes after all?
Note: Fehler = Error

Ereigniszeit Ereignisart Thread-ID Speicheradresse Dateinam
00:01:32.426 DLL laden 6264 00007ff9`a43c0000 C:\Windows\SYSTEM32\AviSynth.dll
00:01:32.427 DLL laden 6264 00007ff9`f0010000 C:\Windows\System32\imagehlp.dll
00:01:32.427 DLL laden 6264 00007ff9`ac020000 C:\Windows\SYSTEM32\MSVCP140.dll
00:01:32.428 DLL laden 6264 00007ff9`e2d80000 C:\Windows\SYSTEM32\VCRUNTIME140.dll
00:01:32.428 DLL laden 6264 00007ff9`e9d30000 C:\Windows\SYSTEM32\VCRUNTIME140_1.dll
00:01:32.429 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.430 Fehler 6264 00007ff9`ee31b699 Fehlercode: 0xe06d7363, Parameter: , 0x19930520, 0x004fe740, 0x200905f0, 0x1fc70000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:36.003 Thread beenden 7304 Austrittscode: 0xc0000005

[pinterf]

"optional AVX2 code paths"

With VirtualDub 1.10.4 at Win7 x64 and E7500 CPU I got not crash but some unknown error in Avisynth
E7500 is good up to SSE4.1, I examined and searched the Intel compiler switches again, but they tell that the base "Not Set" processor level is for SSE2, and the /QaxCORE-AVX2 defines the alternative code path.

I don't know this VirtualDub version, where is it from? I'm using VirtualDub2 44282, please try with it, or with an even newer one.

[pinterf]

VirtualDub2_64
The Avisynth.dll is loaded and after the VCRUNTIME140_1.dll is loaded the error starts.
Is it possible that the VCRUNTIME140 is not compatible with the Intel runtimes? Or are there newer VC runtimes after all?
Note: Fehler = Error

Ereigniszeit Ereignisart Thread-ID Speicheradresse Dateinam
00:01:32.426 DLL laden 6264 00007ff9`a43c0000 C:\Windows\SYSTEM32\AviSynth.dll
00:01:32.427 DLL laden 6264 00007ff9`f0010000 C:\Windows\System32\imagehlp.dll
00:01:32.427 DLL laden 6264 00007ff9`ac020000 C:\Windows\SYSTEM32\MSVCP140.dll
00:01:32.428 DLL laden 6264 00007ff9`e2d80000 C:\Windows\SYSTEM32\VCRUNTIME140.dll
00:01:32.428 DLL laden 6264 00007ff9`e9d30000 C:\Windows\SYSTEM32\VCRUNTIME140_1.dll
00:01:32.429 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.430 Fehler 6264 00007ff9`ee31b699 Fehlercode: 0xe06d7363, Parameter: , 0x19930520, 0x004fe740, 0x200905f0, 0x1fc70000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:36.003 Thread beenden 7304 Austrittscode: 0xc0000005

I don't have problems, my vcruntime140.dll and vcruntime140_1.dll files in the system32 come with version 14.42.34433

[DTL]

VirtualDub 1.10.4 is build 35491. It is from some old decades 201x or 200x . With build 44282 it is really crashed but make more valuable crashlog with some call stack info:


VirtualDub2 crash report -- build 44282 (release-AMD64)
--------------------------------------

Disassembly:
7fee0052e20: 4883c108 add rcx, 08h
7fee0052e24: e93f880200 jmp e007b668
7fee0052e29: cc int 3
7fee0052e2a: cc int 3
7fee0052e2b: cc int 3
7fee0052e2c: 48895c2418 mov [rsp+18h], rbx
7fee0052e31: 56 push esi
7fee0052e32: 57 push edi
7fee0052e33: 4156 push esi
7fee0052e35: 4883ec40 sub rsp, 40h
7fee0052e39: 488b0558380700 mov rax, [e00c6698]
7fee0052e40: 4833c4 xor eax, esp
7fee0052e43: 4889442430 mov [rsp+30h], rax
7fee0052e48: 8b01 mov eax, [rcx]
7fee0052e4a: 4c8bf2 mov r14, edx
7fee0052e4d: 0fbaf008 btr eax, 08h
7fee0052e51: 488bf1 mov rsi, ecx
7fee0052e54: 83f801 cmp eax, 01h
7fee0052e57: 752c jnz e0052e85
7fee0052e59: ff1541230400 call dword ptr [e00951a0]
7fee0052e5f: 394648 cmp [rsi+48h], eax
7fee0052e62: 7419 jz e0052e7d
7fee0052e64: 488d4e08 lea rcx, [rsi+08h]
7fee0052e68: 488b01 mov rax, [rcx]
7fee0052e6b: 488b00 mov rax, [rax]
7fee0052e6e: ff15ac270400 call dword ptr [e0095620]
7fee0052e74: ff1526230400 call dword ptr [e00951a0]
7fee0052e7a: 894648 mov [rsi+48h], eax
7fee0052e7d: ff464c inc dword ptr [rsi+4ch]
7fee0052e80: e9f3000000 jmp e0052f78
7fee0052e85: 4d85f6 test esi, r14
7fee0052e88: 7524 jnz e0052eae
7fee0052e8a: ff1510230400 call dword ptr [e00951a0]
7fee0052e90: 394648 cmp [rsi+48h], eax
7fee0052e93: 0f849d000000 jz e0052f36
7fee0052e99: 488d4e08 lea rcx, [rsi+08h]
7fee0052e9d: 488b01 mov rax, [rcx]
7fee0052ea0: 488b00 mov rax, [rax] <-- FAULT
7fee0052ea3: ff1577270400 call dword ptr [e0095620]
7fee0052ea9: e988000000 jmp e0052f36
7fee0052eae: 48833a00 cmp qword ptr [rdx], 00h
7fee0052eb2: 7c62 jl e0052f16
7fee0052eb4: 7506 jnz e0052ebc
7fee0052eb6: 837a0800 cmp dword ptr [rdx+08h], 00h
7fee0052eba: 7e5a jle e0052f16
7fee0052ebc: ba01000000 mov edx, 00000001
7fee0052ec1: 488d4c2420 lea rcx, [rsp+20h]
7fee0052ec6: e8b5080000 call e0053780
7fee0052ecb: 488b442420 mov rax, [rsp+20h]
7fee0052ed0: 493b06 cmp eax, [r14]
7fee0052ed3: 7c0c jl e0052ee1
7fee0052ed5: 757d jnz e0052f54
7fee0052ed7: 418b4608 mov eax, [r14+08h]
7fee0052edb: 39442428 cmp [rsp+28h], eax
7fee0052edf: 7d73 jge e0052f54
7fee0052ee1: ff15b9220400 call dword ptr [e00951a0]
7fee0052ee7: 394648 cmp [rsi+48h], eax
7fee0052eea: 744a jz e0052f36
7fee0052eec: 488b4608 mov rax, [rsi+08h]
7fee0052ef0: 488d542420 lea rdx, [rsp+20h]
7fee0052ef5: 498bce mov rcx, esi
7fee0052ef8: 488b5810 mov rbx, [rax+10h]
7fee0052efc: e86f070000 call e0053670
7fee0052f01: 8bd0 mov edx, eax
7fee0052f03: 488d4e08 lea rcx, [rsi+08h]
7fee0052f07: 488bc3 mov rax, ebx
7fee0052f0a: ff1510270400 call dword ptr [e0095620]
7fee0052f10: 84c0 test al, al
7fee0052f12: 7522 jnz e0052f36
7fee0052f14: eba6 jmp e0052ebc
7fee0052f16: ff1584220400 call dword ptr [e00951a0]
7fee0052f1c: 394648 cmp [rsi+48h], eax
7fee0052f1f: 74 db 74h

Built on Anton4 on Fri Mar 20 00:39:05 2020 using compiler version 1500

Windows 6.1 (Windows 7 x64 build 7601) [Service Pack 1]
Memory status: virtual free 8388407M/8388608M, commit limit 7895M, physical total 3199M

RAX = 0
RBX = 7fede4c5e2b
RCX = 3c219d0
RDX = 0
RSI = 3c219c8
RDI = 3c21930
RBP = 31bf40
R8 = 31c050
R9 = ffffffffffffee21
R10 = 0
R11 = 286
R12 = ffffffff
R13 = 0
R14 = 0
R15 = 31c708
RSP = 31beb0
RIP = 7fee0052ea0
EFLAGS = 00010286


Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'VirtualDub64'...

...reading address 0000000000000000.

Pointer dumps:

RBX 7fede4c5e2b: 65757274 75725400 6f630065 6e69746e 68006575 61767865 0065756c 3a726f66
RCX 03c219d0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
RSI 03c219c8: 00000002 00690057 00000000 00000000 00000000 00000000 00000000 00000000
RDI 03c21930: 3f4ccccd 00000000 03c21800 00000000 00000000 00000000 03c2cd90 00000000
RSP 0031beb0: 00054be9 00000000 000f1983 00000000 001ed691 00000000 0013a7d1 00000000
0031bed0: 00f7fa0a 00000000 0040bf94 00000000 670cb5e9 000071af 00159000 00000000
0031bef0: 03c219c8 00000000 03c21930 00000000 0031c050 00000000 dd90fd6f 000007fe
0031bf10: 0000237f 00000000 0187f000 00000000 de4c5e2b 000007fe 0005e4f0 00000000
RBP 0031bf40: 03c21930 00000000 31f8b800 00000000 03c1af00 00000000 000505e0 00000000
0031bf60: 0031bff0 00000000 dd91bcd5 000007fe 03c21930 00000000 001555b0 00000000
0031bf80: 001555b0 00000000 03c21930 00000000 001207d8 00000000 00000040 00000039
0031bfa0: c7e2e000 00000000 54be9000 00000000 ed691000 00000001 fbd0e000 00000000
R8 0031c050: 00000062 00000039 00000001 00000000 54be9000 00000000 ed691000 00000001
R15 0031c708: 0031ea40 00000000 00000000 00000000 f56864a9 000007fe dd9f94ce 000007fe

Thread call stack:
7fee0052ea0: MSVCP140!_Thrd_yield [7fee0040000+12d60+140]
7fedd90fd6f: AviSynth!001ffd6f
7fedd91bcd5: AviSynth!avs_get_error [7fedd710000+2025c0+9715]
7fef1dd383f: ucrtbase!__stdio_common_vswprintf_s [7fef1dd0000+37a0+9f]
7fedd9121ec: AviSynth!CreateScriptEnvironment2 [7fedd710000+2021b0+3c]
7fedf7569f8: scripted!000069f8
7fedf7a3e43: scripted!VDGetPluginInfo [7fedf750000+8d40+4b103]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf7d314b: scripted!VDGetPluginInfo [7fedf750000+8d40+7a40b]
7fedf7d314b: scripted!VDGetPluginInfo [7fedf750000+8d40+7a40b]
7fedf756898: scripted!00006898
7fedf752282: scripted!00002282
7fedf754b1d: scripted!00004b1d
7fedf751f45: scripted!00001f45
7782f615: USER32!SystemParametersInfoW [77820000+f4f0+125]
7782f5e7: USER32!SystemParametersInfoW [77820000+f4f0+f7]
77836850: USER32!IsDialogMessageW [77820000+166d0+180]
7782f668: USER32!SystemParametersInfoW [77820000+f4f0+178]
77a8d8f5: ntdll!KiUserCallbackDispatcher [77a40000+4d8d6+1f]
7fedf754e63: scripted!00004e63
77839ae6: USER32!TranslateMessageEx [77820000+19974+172]
778337b6: USER32!GetWindowLongPtrA [77820000+13794+22]
7fedf755191: scripted!00005191
13f355f09: VirtualDub64!000c5f09
13f5975c2: VirtualDub64!003075c2
77a8fa48: ntdll!RtlAllocateHeap [77a40000+4f8d0+178]
13f586790: VirtualDub64!002f6790
13f56b765: VirtualDub64!002db765
7fef56864a9: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+1c9]
13f340f90: VirtualDub64!000b0f90
77a8d351: ntdll!RtlRestoreContext [77a40000+4d06f+2e2]
13f340f90: VirtualDub64!000b0f90
7fefdc62851: ole32!CoUninitialize [7fefdc40000+21324+152d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefdc73fff: ole32!ObjectStublessClient4 [7fefdc40000+33de0+21f]
77933a3d: kernel32!RegOpenKeyExW [77920000+13a20+1d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefe22d7a1: USP10!UspFreeMem [7fefe210000+1d740+61]
7fefdc53feb: ole32!CoGetTreatAsClass [7fefdc40000+13e90+15b]
13f340f90: VirtualDub64!000b0f90
77a690dd: ntdll!RtlDecodePointer [77a40000+28fb0+12d]
77a583db: ntdll!RtlUnwindEx [77a40000+18050+38b]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
13f340f90: VirtualDub64!000b0f90
13f340f90: VirtualDub64!000b0f90
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
77aba5eb: ntdll!RtlIsDosDeviceName_U [77a40000+55ac0+24b2b]
13f340f90: VirtualDub64!000b0f90
7fefdc62851: ole32!CoUninitialize [7fefdc40000+21324+152d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefdc73fff: ole32!ObjectStublessClient4 [7fefdc40000+33de0+21f]
77933a3d: kernel32!RegOpenKeyExW [77920000+13a20+1d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefe22d7a1: USP10!UspFreeMem [7fefe210000+1d740+61]
7fefdc53feb: ole32!CoGetTreatAsClass [7fefdc40000+13e90+15b]
7795051e: kernel32!RtlUnwindEx [77920000+30500+1e]
13f340f90: VirtualDub64!000b0f90
13f562b49: VirtualDub64!002d2b49
13f31e361: VirtualDub64!0008e361
7fefd8c3150: KERNELBASE!GetProcAddress [7fefd8c0000+30f0+60]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
7fef5686843: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+563]
7fef568656a: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+28a]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
13f56afae: VirtualDub64!002dafae
7fefdc77242: ole32!IsEqualGUID [7fefdc40000+34810+2a32]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
77a68e9e: ntdll!RtlLookupFunctionTable [77a40000+28df0+ae]
13f56afc7: VirtualDub64!002dafc7
13f5625f1: VirtualDub64!002d25f1
13f56afae: VirtualDub64!002dafae
13f56b96e: VirtualDub64!002db96e
13f56afc7: VirtualDub64!002dafc7
13f562530: VirtualDub64!002d2530
13f5625f1: VirtualDub64!002d25f1
13f56bc28: VirtualDub64!002dbc28
13f56b2aa: VirtualDub64!002db2aa
13f56c292: VirtualDub64!002dc292
13f56c611: VirtualDub64!002dc611
13f340f90: VirtualDub64!000b0f90
13f562773: VirtualDub64!002d2773
77a6905d: ntdll!RtlDecodePointer [77a40000+28fb0+ad]
77a58c0f: ntdll!RtlUnwindEx [77a40000+18050+bbf]
13f340f90: VirtualDub64!000b0f90
7fefdc5159a: ole32!CLSIDFromString [7fefdc40000+10680+f1a]
7fefdc516a7: ole32!CLSIDFromString [7fefdc40000+10680+1027]
13f31e361: VirtualDub64!0008e361
77936074: kernel32!RegGetValueW [77920000+15ed0+1a4]
77a8d948: ntdll!KiUserExceptionDispatcher [77a40000+4d91a+2e]
7fee0052ea0: MSVCP140!_Thrd_yield [7fee0040000+12d60+140]
77a59008: ntdll!RtlRaiseException [77a40000+18fc0+48]
77a59208: ntdll!RtlRaiseException [77a40000+18fc0+248]
7fefd8cb16d: KERNELBASE!RaiseException [7fefd8c0000+b130+3d]
77a8f9b8: ntdll!RtlAllocateHeap [77a40000+4f8d0+e8]
13f56afc7: VirtualDub64!002dafc7
13f565dc2: VirtualDub64!002d5dc2
13f56dff2: VirtualDub64!002ddff2

-- End of report


https://i.postimg.cc/157RM2d3/image-2025-02-25-010207178.png

Disassembly looks correct - RAX is zero and reading from zero address cause crash.

[pinterf]

I've created ReleaseWithDebug builds. These have the same speed as release builds (if they work :) ), but they may help to show where it crashes.

I've put together a zip file with four Intel ICX builds of Avisynth.dll and Avisynth.pdb. Each build comes with its corresponding PDB debug info file. Please copy both the DLL and PDB files into the System32 directory.

The variants are as follows (see folder names):

SSE2
SSE2 + AVX2
AVX2
AVX2 + AVX512 (for Ice Lake - 10th/11th gen i7 processors, for example)

You can download them from the link (the base pack is still there).
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4198

Thanks.

[tormento]

I've created ReleaseWithDebug builds..
As I am —still— an AVX user, do you think an Intel AVX build could be of any utility to have a small speed bump?

[tebasuna51]

For me, and for users even more ignorant than me, please can you explain the limits and advantages of each compilation of Avs+?

There are the xp_or_better, the intel_icx (with 4 variants) but also Clang and intelLLVM (https://gitlab.com/uvz/AviSynthPlus-Builds/) builds.

If there are a stable build of Avs+ 3.8.0 for xp_or_better please do it, and after try better (saying for what) compilations of these versions.

[pinterf]

As I am —still— an AVX user, do you think an Intel AVX build could be of any utility to have a small speed bump?

No.
AVX is floating point only.
Unless you have a full-32-bit float workflow, which is using exclusively Avisynth internal filters.

[pinterf]

For me, and for users even more ignorant than me, please can you explain the limits and advantages of each compilation of Avs+?

There are the xp_or_better, the intel_icx (with 4 variants) but also Clang and intelLLVM (https://gitlab.com/uvz/AviSynthPlus-Builds/) builds.

If there are a stable build of Avs+ 3.8.0 for xp_or_better please do it, and after try better (saying for what) compilations of these versions.

You might only see a slight improvement, perhaps just a few percentage points. A typical script, which is a bit more complex than:

ColorBars.ConvertBits(32).ThisAndThatResize(4096,2048).ConvertBits(8, dither=1)
and is probably using many external filters, won't be processed visibly quicker. Personally, I wouldn't bother with them (though I don't use Avisynth myself; I'm just a developer). However, since using a faster option is free, why not give it a try?

I just note, since the additional builds require more time (5-30 minutes per build type) and computer power, I don't bother creating versions other than the stock XP-to-Win11 regular version in the early tests. More untested options lead to more user reports. The more choices given, the more requests: "Why not a special build for my i7-k18236812 or ZX-Spectrum?" :)

[Jamaika]

The variants are as follows (see folder names):
SSE2
SSE2 + AVX2
AVX2
AVX2 + AVX512 (for Ice Lake - 10th/11th gen i7 processors, for example)

Little green man. In avisynth and many add-ons, ALIGN is set for 64 memory, i.e. only for AVX512. What variants for older computers?
I wonder what will be soon for AVX10 and ALIGN 128.
As for Intel add-ons, I am surprised that I managed to add for gcc/mingw64. The general ones are for MSVCRT and the add-ons are paid.

[Emulgator]

Success here !
Win10P64, i9-11900K (AVX512) 128GB, RTX3080 16GB
Feeding AvsPmod64 2.7.9.2, or VD64 44282, or Topaz 2.6.4 all AviSynth64 builds 4198 work nice here:
20250224 WinXP or better, Intel ICX
20250225 ICXBase, ICXBase+AVX2, ICX AVX2, ICX AVX2+AVX512.
Untested by me so far: WinXP32, Win7x64
Under my environment all build versions seem compatible, no speed differences worth mentioning.
(I wasn't expecting any, given that my scripts and called plugins may not use higher AVX at all.)
Many thanks again, Ferenc !

P.S. That successfully testing system had MSVC Runtimes 14.42.34433.0
As found out by others in following posts, it may well be that these AviSynth+ICX builds only run under these more recent runtimes.
Will repeat tests soon with a similar mid-2024 frozen Win10P64 system (hopefully still) containing earlier runtimes.
P.P.S. An older Win7U64 system with runtimes from 2022 immediately reports access violation with the ICX Base build.

[tebasuna51]

My speed test:
W10 v1607, Ryzen 5 1600X, RAM 8 GB
Simple QTGMC(Preset="Fast", EZDenoise=2.0) over a DV.avi

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4198, master, x86_64) (3.7.3.0)

Number of frames: 40430
Length (hh:mm:ss.ms): 00:13:28.600
Frame width: 720
Frame height: 572
Framerate: 50.000 (50/1)
Colorspace: YV12

xp-in-W10 r4198 icx-avx2 r4198 Clang r4198 intelLLVM r4198
----------------- ----------------- ----------------- -----------------
Frames processed: 40430 (0 - 40429) 40430 (0 - 40429) 40430 (0 - 40429) 40430 (0 - 40429)
FPS (min | max | average): 27.18|91.18|58.84 36.49|89.11|59.39 34.46|88.18|58.40 35.10|91.90|59.18
Process memory usage (max): 365 MiB 357 MiB 367 MiB 364 MiB
Thread count: 29 29 29 29
CPU usage (average): 28.6% 28.7% 28.5% 28.5%

Time (elapsed): 00:11:27.124 00:11:20.760 00:11:32.247 00:11:23.202
Seems for me the icx-avx2 is the winner, but only by 1% fast over the xp.

[StvG]

My speed test: ...

I hope you tested every variant at least 3 times (or at least twice) and used average/median for the final results in order to have more reliable test.

[pinterf]

I hope you tested every variant at least 3 times (or at least twice) and used average/median for the final results in order to have more reliable test.
Sometimes, I can see more than 1% difference between runs. Note also that the processor clock is not constant either. It's strange, but it also depends on how the memory was allocated, how the cache behaved, and how lucky the stars were at that moment of allocation. When the average starts showing a consistent 2% or more difference, one can be happy.

[StvG]

Sometimes, I can see more than 1% difference between runs. Note also that the processor clock is not constant either. It's strange, but it also depends on how the memory was allocated, how the cache behaved, and how lucky the stars were at that moment of allocation. When the average starts showing a consistent 2% or more difference, one can be happy.

You can add antivirus soft (if any), Windows SysMain (SuperFetch) to the equitation.

In some PC hardware forums when doing benches (Cinebench, Geekbench...) - antivirus is stopped and the bench app is assigned to the highest CPU priority. Several runs and the average/mean is taken.
Some folks go further and use a clean Windows installation just for the benches.

But when one see more than 5% difference, it's more likely caused by the different builds.

[DTL]

I've created ReleaseWithDebug builds.
I've put together a zip file with four Intel ICX builds of Avisynth.dll and Avisynth.pdb. Each build comes with its corresponding PDB debug info file. Please copy both the DLL and PDB files into the System32 directory.


Some good test results and some not very good:

1. At the 'fresh and rarely used' Win 7 x64 installation Base versions are working. The AVX2 and AVX2+AVX512 not crash but return some not very clear error in VirtualDub:

File open error (window title)
AVI Import Filter error: (Unknown) (80040154)
https://i.postimg.cc/v8nNDkzw/above-SSE.png

Also the 'main' release r4198 from 'x64_intel_icx' working too (in this Win 7 installation).

I use this Win7 installation mostly for rare things with MSVC2019 (and 2017) installed.

2. After reboot to my everyday used Win 7 x64 :
Base and initial release r4198 from 'x64_intel_icx' cause VirtualDub crash and AVX2 and AVX512 do not crash and display same
File open error (window title)
AVI Import Filter error: (Unknown) (80040154)
https://i.postimg.cc/v8nNDkzw/above-SSE.png

error message.

Unfortunately I do not have modern Visual Studio with x64 debugger installed in my 'everyday used' Win7 so can not use provided .pdb files. Any small and possibly portable x64 debugger for Win 7 can be recommended ? I do not have space to install Visual Studio in that Win 7 installation or it even can not run because of some damaging of system files (?). I do not remember why I uninstall it.

So the main test result: ICX builds can run in some 'fresh or very low/rare used' installations of Win 7 x64 but can cause Virtual Dub crash in some 'some time used or even some damaged' Win 7 x64 installations.

[DTL]

In avisynth and many add-ons, ALIGN is set for 64 memory, i.e. only for AVX512. What variants for older computers?
I wonder what will be soon for AVX10 and ALIGN 128.


It is not only for AVX512. It is up to AVX512 (and the case you have 8bit single byte samples in some planar format).

It is back compatible with AVX256 and SSE.

The more alignment used - the more RAM wasted at the end of rows for some row widths. But 64bytes alignment also still not enough for AVX512 if you process 16 or 32bit per sample formats.

Also it is not enough if we have row processing loops reading/storing >1 512bit dataword per loop iteration.

It was old idea to have plugin-requested row stride and alignment for frame buffers so the plugin can use faster and more simple in design SIMD loops without special end part for processing remaining samples not possible to read/write with main loop using many SIMD datawords read-writes if single SIMD dataword is long enough.

Any increased row stride and alignment (by power of 2) is back compatible with old plugins (I hope). But too large stride and alignment will waste too much RAM with small frame sizes.

So other idea was to make user-configurable from script command row stride and alignment. But it must be supported by internal plugin design to get some benefit on fast hosts with AVX(all families) CPUs or modern CPUs. So plugin can check at plugin init the provided by AVS core row stride and alignment and can select better SIMD processing functions (processing larger data blocks if possible for single data burst exchange between register file and caches or host RAM).

[gispos]

None of the 3 icx variants work for me, all programs crash.
I have no problems with xp_version, IntelLVM and Clang.

Also cannot use the pdb file. VDub2 shows the same RAX error with all three variants.

[Jamaika]

It is not only for AVX512. It is up to AVX512 (and the case you have 8bit single byte samples in some planar format).

It is back compatible with AVX256 and SSE.

The more alignment used - the more RAM wasted at the end of rows for some row widths. But 64bytes alignment also still not enough for AVX512 if you process 16 or 32bit per sample formats.

Also it is not enough if we have row processing loops reading/storing >1 512bit dataword per loop iteration.

It was old idea to have plugin-requested row stride and alignment for frame buffers so the plugin can use faster and more simple in design SIMD loops without special end part for processing remaining samples not possible to read/write with main loop using many SIMD datawords read-writes if single SIMD dataword is long enough.

Any increased row stride and alignment (by power of 2) is back compatible with old plugins (I hope). But too large stride and alignment will waste too much RAM with small frame sizes.

So other idea was to make user-configurable from script command row stride and alignment. But it must be supported by internal plugin design to get some benefit on fast hosts with AVX(all families) CPUs or modern CPUs. So plugin can check at plugin init the provided by AVS core row stride and alignment and can select better SIMD processing functions (processing larger data blocks if possible for single data burst exchange between register file and caches or host RAM).
There is no possibility of automatic alignment in Avisynth.
There is no record for different processors. And it is not only about the alignment value in the malloc function.
This value in avisynth is constant and is 64. In other functions it is converted to 64. For AVX2/AVX it is 32. So old processors do not have to work.

Example plugins RIFE:
#if NCNN_AVX512
#define NCNN_MALLOC_ALIGN 64
#elif NCNN_AVX
#define NCNN_MALLOC_ALIGN 32
#else
#define NCNN_MALLOC_ALIGN 16
#endif

static NCNN_FORCEINLINE void* fastMalloc(size_t size)
{
#if _MSC_VER
return _aligned_malloc(size, NCNN_MALLOC_ALIGN);
#elif (defined(__unix__) || defined(__APPLE__)) && _POSIX_C_SOURCE >= 200112L || (__ANDROID__ && __ANDROID_API__ >= 17)
void* ptr = 0;
if (posix_memalign(&ptr, NCNN_MALLOC_ALIGN, size + NCNN_MALLOC_OVERREAD))
ptr = 0;
return ptr;
#elif __ANDROID__ && __ANDROID_API__ < 17
return memalign(NCNN_MALLOC_ALIGN, size + NCNN_MALLOC_OVERREAD);
#else
unsigned char* udata = (unsigned char*)malloc(size + sizeof(void*) + NCNN_MALLOC_ALIGN + NCNN_MALLOC_OVERREAD);
if (!udata)
return 0;
unsigned char** adata = alignPtr((unsigned char**)udata + 1, NCNN_MALLOC_ALIGN);
adata[-1] = udata;
return adata;
#endif
}

[DTL]

None of the 3 icx variants work for me, all programs crash.


It may be some complex issue between VirtualDub + AVS core + Intel libraries and some other software.

If crash finally happen in VirtualDub module - we also need debug build of Virtual Dub with .pdb file for it.

May be some _version_ of additional loaded .dlls in 'used/updated Windows' is not compatible with current version of ICX compiler (its libraries) and it cause crash in returned value in VirtualDub.

Also the point of crash may be 'never fail before' so returned value do not checked (for being zeroed) inside VirtualDub and used as pointer and it crash at zero value. But this zero value may come from many other loaded third-party modules (not VirtualDub and not AVS core).

Here is debugger output of files loaded in 'normal' opening 'version' script with Base build (in working Win7 state/config)

'VirtualDub64.exe' (Win32): Loaded 'C:\distr\VirtualDub2_44282\VirtualDub64.exe'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\winmm.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\user32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\lpk.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\usp10.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvfw32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\shell32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\shlwapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.24380_none_e3731d0b30fb6b11\comctl32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\avifil32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ole32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\comdlg32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\oleaut32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msctf.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\distr\VirtualDub2_44282\plugins64\avlib-1.vdplugin'. Module was built without symbols.
'VirtualDub64.exe' (Win32): Loaded 'C:\distr\VirtualDub2_44282\plugins64\scripted.vdplugin'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msimg32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\uxtheme.dll'.
The thread 0xec8 has exited with code 0 (0x0).
< - start opening AVS script here
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\clbcatq.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\AviSynth.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-runtime-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-timezone-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-file-l2-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-localization-l1-2-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-synch-l1-2-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-processthreads-l1-1-1.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-core-file-l1-2-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-heap-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-string-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-stdio-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-convert-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-locale-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-filesystem-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-time-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-environment-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-math-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-utility-l1-1-0.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ddraw.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dciman32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\setupapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cfgmgr32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\devobj.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dwmapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\nvd3dumx.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\version.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\powrprof.dll'.
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\powrprof.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\nvd3dumx.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\version.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ddraw.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\dwmapi.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\setupapi.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\devobj.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\dciman32.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\cfgmgr32.dll'


Most interesting critical .dlls after start loading .avs script are


'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\clbcatq.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1.dll'.


Will try to replace 'bad Win7' with 'working Win7' versions of these files (or at least compare for binary equality - it is better idea).

[DTL]

Found and fixed - as expected it is about issues with MSVCP runtime and Intel libs :

Critical files are
'C:\Windows\System32\msvcp140.dll'.
'C:\Windows\System32\vcruntime140.dll'.
'C:\Windows\System32\vcruntime140_1.dll'.

Working with ICX builds version is
https://i.postimg.cc/W1rS0qYK/image-2025-02-25-231419318.png
14.42.34433.0 (from 29 Oct 2024 ?)

Not working version (VirtualDub crash) is 14.26.28720.3 (from 20 Mar 2020 ?).

It looks users need to update 140 MSVC runtimes to version from 2024 ?

Non-compatible with ICX build .dlls for testing - https://drive.google.com/file/d/1riwNEOc-qvM7Mi3P_7CqOMsdWH3f86pY/view?usp=sharing

[Emulgator]

Ah, good find.
My first everyday testing system is (unfortunately) updated, this broke Dual iGPU/dGPU capability, but ICX builds worked, and it is indeed 14.42.34433.0
Repeating tests on my other stable-frozen W10 system soon, and Win7U64.

[DTL]

Microsoft site also lists latest (for MSVC 2019 ?) https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

Latest Microsoft Visual C++ Redistributable Version
The latest version is 14.42.34433.0

[Emulgator]

And we have a hit: AviSynth+64 r4198 ICX Base under Win7U64, i9-940XM
Universal AviSynthInstaller reports: Immediate AccessViolation in C:\Windows\system32\MSVCP140.dll
Versions are 14.34.31931 from 05.10.2022

On that same 2009 system AviSynth+64 r4198 XP+ runs ok. (only simple scripts tested for now).
...one hour to go for the second mid-2024-frozen Win10 system to become free for testing...

[TR-9970X]

Microsoft site also lists latest (for MSVC 2019 ?) https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

Latest Microsoft Visual C++ Redistributable Version
The latest version is 14.42.34433.0

Why don't you use these distro's ??

These update ALL of them (after a restart).

https://github.com/abbodi1406/vcredist/releases

Visual C++ 2022 Redistributable - 14.44.34823.2

[Emulgator]

Because it breaks other stuff, and is close to impossible to repair afterwards.

[TR-9970X]

Because it breaks other stuff, and is close to impossible to repair afterwards.

I'm running W11 24H2, and I've never had an issue, but then I don't use most of these apps that you guys like to play around with !

[gispos]

Found and fixed - as expected it is about issues with MSVCP runtime and Intel libs :

Critical files are
'C:\Windows\System32\msvcp140.dll'.
'C:\Windows\System32\vcruntime140.dll'.
'C:\Windows\System32\vcruntime140_1.dll'.

Working with ICX builds version is
https://i.postimg.cc/W1rS0qYK/image-2025-02-25-231419318.png
14.42.34433.0 (from 29 Oct 2024 ?)

Not working version (VirtualDub crash) is 14.26.28720.3 (from 20 Mar 2020 ?).

It looks users need to update 140 MSVC runtimes to version from 2024 ?

Non-compatible with ICX build .dlls for testing - https://drive.google.com/file/d/1riwNEOc-qvM7Mi3P_7CqOMsdWH3f86pY/view?usp=sharing
My goodness!
I had looked up on a site what the latest MSVC runtimes are. I skimmed briefly and read “All in One runtimes 2015 to 2022”.
Hm, I have that on my system.
Kind of my own fault, but I think it should have been changed by name and not just 2o15 to 2022.

Then my first thoughts weren't so wrong. I was probably just too lazy to take a closer look.

VirtualDub2_64
The Avisynth.dll is loaded and after the VCRUNTIME140_1.dll is loaded the error starts.
Is it possible that the VCRUNTIME140 is not compatible with the Intel runtimes? Or are there newer VC runtimes after all?
Note: Fehler = Error

Ereigniszeit Ereignisart Thread-ID Speicheradresse Dateinam
00:01:32.426 DLL laden 6264 00007ff9`a43c0000 C:\Windows\SYSTEM32\AviSynth.dll
00:01:32.427 DLL laden 6264 00007ff9`f0010000 C:\Windows\System32\imagehlp.dll
00:01:32.427 DLL laden 6264 00007ff9`ac020000 C:\Windows\SYSTEM32\MSVCP140.dll
00:01:32.428 DLL laden 6264 00007ff9`e2d80000 C:\Windows\SYSTEM32\VCRUNTIME140.dll
00:01:32.428 DLL laden 6264 00007ff9`e9d30000 C:\Windows\SYSTEM32\VCRUNTIME140_1.dll
00:01:32.429 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.430 Fehler 6264 00007ff9`ee31b699 Fehlercode: 0xe06d7363, Parameter: , 0x19930520, 0x004fe740, 0x200905f0, 0x1fc70000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:32.478 Fehler 6264 00007ff9`ac033028 Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000
00:01:36.003 Thread beenden 7304 Austrittscode: 0xc0000005

[Emulgator]

...one hour to go for the second mid-2024-frozen Win10 system to become free for testing...

And to confirm gispos and DTL, we have a second hit:
AviSynth+64 r4198 ICX Base under that similar Win10P64, i9-11900K
Universal AviSynthInstaller reports: Immediate AccessViolation in C:\Windows\system32\MSVCP140.dll
Runtime versions are 14.36.32532 from 10.05.2023

I am very thankful for the XP-compatible builds and will be backing off from ultra-modern-but-incompatible compiler builds for now
(had only dived in for that educational reason anyway).
To me at least those marginal gains seem not worth the hassle of broken bridges, but I am still thankful to those who try.

[TR-9970X]

And to confirm gispos and DTL, we have a second hit:
AviSynth+64 r4198 ICX Base under that similar Win10P64, i9-11900K
Universal AviSynthInstaller reports: Immediate AccessViolation in C:\Windows\system32\MSVCP140.dll
Runtime versions are 14.36.32532 from 10.05.2023

I am very thankful for the XP-compatible builds and will be backing off from ultra-modern-but-incompatible compiler builds for now
(had only dived in for that educational reason anyway).
To me at least those marginal gains seem not worth the hassle of broken bridges, but I am still thankful to those who try.

I know you didn't like my suggestion of that AIO installer I posted a link to, you know you can unpack it, and probably copy any single .dll from the version you want, instead of just letting it install EVERYTHING.

Might be worth a try...

[Emulgator]

It was a wonderful experience back then, a nice readup here for all willing to try, see here:
https://forum.doom9.org/showthread.php?p=1981377&highlight=Abbodi#post1981377
Yes, single tries could help.

[real.finder]

I know you didn't like my suggestion of that AIO installer I posted a link to, you know you can unpack it, and probably copy any single .dll from the version you want, instead of just letting it install EVERYTHING.

Might be worth a try...

there are also this https://baltagy1.blogspot.com/2018/04/microsoft-visual-c-redistributable-repack.html

and this https://www.techpowerup.com/download/visual-c-redistributable-runtime-package-all-in-one/

[VoodooFX]

AviSynth+ r4198

Enjoy the life.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4198

No problems with it so far.

I just had an unpleasant surprise when a function I wrote using v3.7.3_r4198 produced garbage encodings on another PC running v3.7.3 (stable). :D
Why not bump the version to 4.0.0, or at least 3.8.0?

[Emulgator]

Second that. Enjoying the life with AviSynth+ r4198 and its broad choice of compilations here too.
Once qyot27 / pinterf / majority of power users agree that a milestone is reached
(and on github it looks like qyot27 is cleaning up the docs)
I would call it a day and welcome the suggested means of version distinction.

[qyot27]

Why not bump the version to 4.0.0, or at least 3.8.0?
All previous minor version bumps happened with the introduction/merge of milestone features*, and there's no reason to jump to 4.x given that massive API/ABI incompatibilities (we're not talking about regular churn of the INTERFACE_VERSION here; I mean stuff as major as a wholesale rewrite in a different programming language) have not arisen to warrant it.

*0.1 - first release of the initial fork; this would include 64-bit, asm->intrinsics rewrite, build system overhaul, etc.
[0.2] - would have been multithreading, but the bump never happened
[0.3] - would have been high bit depth and MinGW/GCC support, again, the bump never happened
3.4 - consolidation back to Github and a catch-up release before 3.5
3.5 - cross-platform (Linux/Mac/BSD) support
3.6 - merge of Neo features, ARM support/ability to build with the Intel intrinsics deactivated
3.7 - technically, PowerPC, and Haiku, with RISC-V, SPARC, MIPS, and Loongson added in subsequent bugfix versions (RISC-V and SPARC tested only in VM, MIPS and Loongson basically just tacked into config.h so it won't fail on those platforms but not personally tested because I don't have any of the relevant hardware); also generally allowing for frame properties to stabilize more

There are things I consider to be important enough to warrant future bumps to 3.8, 3.9, etc., but when work on those things might happen is anyone's guess.

[VoodooFX]

...there's no reason to jump to 4.x given that massive API/ABI incompatibilities have not arisen..

That's very, very conservative... take a look at Firefox or Chrome versioning.
"a function I wrote using v3.7.3_r4198 produced garbage with v3.7.3" <- That alone would be a good reason for me. Actually, 3.7.3 could be '4.0' since it reached the 4000-commit milestone. :D

[Emulgator]

Many thanks for that insight, qyot27, very impressive.

[FranceBB]

I'm actually ok with 3.7.4 for that matter.
Speaking of which, we're now in March 2025, there are 79 days from here (March 1st) to May 19th, so if it gets released on May 19th 2025 it would be on the day of Avisynth's 25th birthday.
That on its own would be quite a milestone. I mean, there aren't many projects on the web that can say to be 25 years old and if we think that it's been totally community driven, free and open source, this is even more impressive!


(it would be a Monday, so I might even bring a theme cake to the office to my colleagues for real this time).

[Boulder]

I have to say that about 20 years ago, I wouldn't have expected to still be using Avisynth this day. I guess I can start calling video processing my hobby now, thanks to pinterf for keeping it going for so long :)

[tormento]

I think next time it's better to do the Intel stuff using static linked libraries.
I don't think it's a good idea.

Two reasons: bug fixes and security issues can arise in time and people would be stucked with a bugged/insecure version.

Me myself had problems with the .0 version (random crashes on long encodes) that were solved in .4.

MSVC works well with shared libraries, I think ICC should stay with shared libraries too.

[LigH]

Such a unique signature:

https://www.rationalqm.us/www.math.berkeley.edu/benrg/signature.gif

Ben Rudiak-Gould, original developer of Avisynth

[pinterf]

New day, new build.

AviSynth+ r4210.
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4210

Today's feature: wildcard and regex support in propShow, propDelete and propCopy functions.
More info at
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_internal_functions_frame_properties.html
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/propShow.html
Like this:
PropCopy(a) # make all properties the same with of clip a
PropCopy(a, merge=true) # Adds new properties from clip a, overwrites if already exists

# Add properties from clip "a" which end with "1" or "2"
PropCopy(a, merge=true, props=["*2","*1"])

# Add properties from clip "a" where not started with "_"
PropCopy(a, merge=true, props="_*", exclude = True)

# same with regex
PropCopy(a, merge=true, props="^[^_].*$")

# erase all, then copy all, except listed ones
propCopy(org,props=["_Matrix", "_ColorRange"], exclude = true)

[FranceBB]

Ah, more tools to tame my everlasting enemy, frame properties!
Thank you Ferenc. :)

[pinterf]

I've seen your complaints, and that was the final straw. I was already considering a feature extension since Avisynth and frame properties are such hot topics. Recently, I received an ultimatum from the Secret Association of Pink Unicorns. They demand the immediate removal of all frame property adding functionality from Avisynth, while they welcome the extension of property deleters.

Then, the King of United Frames decreed that Avisynth must be the official language of the Solar System. This left poor Vapoursynth speakers on the Moon without legal protection, allowing them to add as many frame properties as they want. "This cannot be!" I said to myself. To ease FranceBB's pain and deep sorrow, I decided to implement regex. And that's exactly how it happened.

[tormento]

And that's exactly how it happened.
Please attach some of the drugs you are taking.

I want pink unicorns too. :p

P.S: I don't think having static Intel builds is a good idea, for the reasons I explained in my previous post.

[FranceBB]

To ease FranceBB's pain and deep sorrow, I decided to implement regex. And that's exactly how it happened.

And I really appreciate that! :D


I want pink unicorns too. :p


The Pink Pony Club is very unique.


https://youtu.be/8lmK_dMWY8o?si=Gej1t2lGi0SLiC5_

[LigH]

I want pink unicorns too. :p

PFUDOR (https://www.youtube.com/watch?v=qRC4Vk6kisY)

https://frupic.frubar.net/shots/44152.gif

[tormento]

AviSynth+ r4210
I've tested your 4210 ICX version and it's not working:

Script Error

Failed to load AviSynth+

Your previous one 4193 or the "unofficial" gitlab (https://gitlab.com/uvz/AviSynthPlus-Builds)4198 IntelLLVM work perfectly fine.

[tormento]

The Pink Pony Club is very unique.

PFUDOR

Actually even your drugs are very good too. :p

[Z2697]

Isn't ICC just based on LLVM now? Why not just use clang?
How did this ICC craziness even started? tormento asking for ICC builds everywhere?

[tormento]

Isn't ICC just based on LLVM now? Why not just use clang?
How did this ICC craziness even started? tormento asking for ICC builds everywhere?


🥱

tl;dr ICC compiler is simply the best one around. It produces clean, fast and stable code. Please stick with msvc or even better gcc and close your eyes whenever you see the words “intel” and/or ICC/ICX. Thank you.

[pinterf]

I wouldn't say it's stable :) Using a good static library ensures that Intel cannot mess it up later with a bad driver or library update (like they did with version 2025.0.0 and their OpenCL driver).
(And we are not talking about the need of the huge bloatware we must download and install just because of two small DLLs).

And in my next post, I'll show you how a theoretically good idea (supporting multiple optimized architectures through dynamic dispatching - just an additonal compiler switch) can result in significant performance loss.

[pinterf]

Since we'll soon have more support for Arm64, thanks to qyot27, I experimented a bit and updated Expr where we cannot have the convenient JIT.

So I rewrote the C (non-Intel-JIT) path to support vectorization, if the compiler is capable.

Even if the compiler is not very advanced (MSVC khhhhmm..) this approach is faster because it has less overhead when interpreting the instruction flow. It processes 16, 8, 4, and 1 floats when handling the horizontal line, taking the largest chunks it can then finishing the rest with the smaller ones.

Benchmarks (x64 bit). For comparison, I also provide the JIT results.

Script (optSSE2 = false disables JIT):

# Mandelbrot
ColorBarsHD()
a="X dup * Y dup * - A + T^ X Y 2 * * B + 2 min Y^ T 2 min X^ "
b=a+a
c=b+b
blankclip(width=960,height=640,length=1600,pixel_type="YUV420P8")
Expr("sxr 3 * 2 - -1.2947627 - 1.01 frameno ^ / -1.2947627 + A@ X^ syr 2 * 1 - 0.4399695 "
\ + "- 1.01 frameno ^ / 0.4399695 + B@ Y^ "+c+c+c+c+c+b+a+"X dup * Y dup * + 4 < 0 255 ?",
\ "128", "128",optSSE2 = false, optAVX2=false) # optVectorC=true default


MSVC: Microsoft VC, actual VS2022 version.
Intel: Intel C++ Compiler 2025 - LLVM based, aka ICX.

"Base" means the instruction set is not specified: SSE2 is the minimum for x64.

Compiler/Settings VectSize FPS
-------------------------------------- ---------- -----
MSVC debug 1 0.27
Intel (base + optional AVX2 paths) 1 1.01 (! Mixed instruction set support, slow)
MSVC Base 1 1.71 VectorSize=1, not optimal :)
MSVC old single variable C: - 2.82
Intel old single variable C: - 2.90
MSVC Base 16 4.47 (initial Proof of Concept version)
MSVC AVX2 16 4.59 (initial PoC version)
MSVC Base 16 5.94
MSVC AVX2 16 6.04
Intel Base 16 6.29 (initial PoC version)
Intel AVX2 optional AVX512 -Qax:AVX512 16 12.60 (! Mixed instruction set support, slow)
Intel Base 16 14.70
Intel AVX2 16 19.20
Intel AVX512 16 20.10
MSVC JIT SSE2 2x4 59.00 (dual lanes, XMM regs)
MSVC JIT AVX2 2x8 128.00 (dual lanes,YMM regs)


In this test, where dual processor optimization was enabled, Intel performed poorly (though it still achieved twice the speed of MSVC). It seems that dynamically dispatching code fragments to different instruction sets incurs significant overhead.

Conclusion:

We should better avoid builds mixed-code sets.

Since AVX2 has been generally supported for at least ten years, creating a non-mixed AVX2-only compilation is a reasonable enhancement.

Looking at the numbers, achieving one-third the speed of the old SSE2 JIT, which we considered fast, is quite impressive.

Even x86/x64 users can benefit from this speedup: if the Expr contains specific trigonometric functions (tan, asin, acos, atan) that have no JIT implementation, then Avisynth cannot use JIT and falls back to the C implementation.

[pinterf]

Such a unique signature:

https://www.rationalqm.us/www.math.berkeley.edu/benrg/signature.gif

Ben Rudiak-Gould, original developer of Avisynth
Nice signature indeed!

See also: Clive Barker's Abarat

[tormento]

I wouldn't say it's stable :)
You read where I wrote that the last build is not working for me, didn’t you? [emoji6]

[pinterf]

You read where I wrote that the last build is not working for me, didn’t you? [emoji6]
Opps, not yet. Don't know, why. It was compiled with base (SSE2) + optional AVX2.

[tormento]

Opps, not yet. Don't know, why. It was compiled with base (SSE2) + optional AVX2.

Try to compile a dynamic one. :D

[pinterf]

Try to compile a dynamic one. :D
Then I receive not one but ten complaints about the necessary hundred megabytes overhead and systems which Intel screwed up. If you read back, you'll note that uvz builds are created exactly like this.
Try to do it yourself, I don't know what do you expect from this.

[tormento]

Try to do it yourself, I don't know what do you expect from this.
It was a joke… [emoji6]

[pinterf]

Anyway, a more detailed error report is needed than just "Script Error, Failed to load AviSynth+". The following information would always help a lot:

Are your experiences limited to r4610 ICX build, or do they also occur with the r4610 MSVC versions?
From which system did you receive the error message?
If possible (everything is possible :) ), please check with avsmeter64 to ensure avisynth loads correctly and maybe displays a reason, why it would fail. e.g. plugin's compatibility, etc.

[gispos]

Hello Ferenc,
please check the return version of the r4210 icx version
I see: 3.7.2 r3661
And various scripts therefore spit out an error message.

The new Avisynth icx versions are fast, I feel that everything is a bit faster and also the caching works better than with the previous versions.

Edit:
Everything back to square one!
That was a mistake. The r4210 cannot be loaded in AvsPmod and AvsPmod then loads another available Avisynth version if an alternative path is specified under Options.

So I have to agree with Tormento, the r4210 does not work.
It is also a lot smaller than the r4198, forgot what to link?

[StvG]

...
Intel (base + optional AVX2 paths) 1 1.01 (! Mixed instruction set support, slow)
...
Intel AVX2 optional AVX512 -Qax:AVX512 16 12.60 (! Mixed instruction set support, slow)
...


What are these? Separate source file only with the relevant instructions?

[Z2697]

MSVC is not Clang.
Visual Studio can use Clang.

ICC is based on LLVM. Clang is based on LLVM, even better, it's the official frontend for LLVM.
ICC will not beat Clang.

Blindly trusting an Intel fanboy is not a good choice.

��

tl;dr ICC compiler is simply the best one around. It produces clean, fast and stable code. Please stick with msvc or even better gcc and close your eyes whenever you see the words “intel” and/or ICC/ICX. Thank you.

Which just sound ridiculous.
I didn't even brought up the "brand fanaticism" topic. I mean, Intel surely had better days.

[StvG]

MSVC is not Clang.
Visual Studio can use Clang.

ICC is based on LLVM. Clang is based on LLVM, even better, it's the official frontend for LLVM.
ICC will not beat Clang.

Blindly trusting an Intel fanboy is not a good choice.



Which just sound ridiculous.
I didn't even brought up the "brand fanaticism" topic. I mean, Intel surely had better days.

ICC is the old/legacy Intel C/C++ Compiler.
ICX is the new one based on LLVM.

In some cases (libs/apps) clang produces faster binaries, in other cases icx produces faster binaries, in third cases msvc produces faster binaries, in fourth cases gcc produces faster binaries...
There is no such thing "ICX is the best", there is no "ICC will not beat Clang" (implying Clang is always better than ICC). Not to mention that same compiler from one version to another can produce binaries with different speed.

[DTL]

New day, new build.

AviSynth+ r4210.
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4210



ICX not working in Win10 even after installing lastst C++ runtimes.

Debugger output is very poor - simple some C++ exception at some address


'VirtualDub64.exe' (Win32): Loaded 'C:\Distr\VirtualDub2_44282\VirtualDub64.exe'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\user32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\win32u.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32full.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp_win.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\comdlg32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\combase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\SHCore.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\shlwapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\shell32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\bcrypt.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ole32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\oleaut32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\winmm.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvfw32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\avifil32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.4355_none_60b8b9eb71f62e16\comctl32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\winmmbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\bcryptprimitives.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\uxtheme.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Distr\VirtualDub2_44282\plugins64\avlib-1.vdplugin'. Module was built without symbols.
'VirtualDub64.exe' (Win32): Loaded 'C:\Distr\VirtualDub2_44282\plugins64\scripted.vdplugin'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msimg32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msctf.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\TextShaping.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\TextInputFramework.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\CoreMessaging.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\CoreUIComponents.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ws2_32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ntmarta.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\WinTypes.dll'.
The thread 0x4fc has exited with code 0 (0x0).
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\clbcatq.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\windows.storage.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\wldp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cfgmgr32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\propsys.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\profapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dwmapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Program Files\Common Files\microsoft shared\ink\tiptsf.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\edputil.dll'.
Exception thrown at 0x00007FF94B94B699 in VirtualDub64.exe: Microsoft C++ exception: MyWin32Error at memory location 0x0000000000CFA7D8.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\WindowsCodecs.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\thumbcache.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ntshrui.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\sspicli.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\srvcli.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cscapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\StructuredQuery.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\policymanager.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp110_win.dll'.
The thread 0x1fb0 has exited with code 0 (0x0).
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\DataExchange.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\d3d11.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dcomp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dxgi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\twinapi.appcore.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\Windows.StateRepositoryPS.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\urlmon.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\netutils.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\iertutil.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\Windows.Storage.Search.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\apphelp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Users\USER\AppData\Local\Microsoft\OneDrive\25.025.0209.0001\FileSyncShell64.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\crypt32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\secur32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\wininet.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\wtsapi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\userenv.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\version.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\EhStorShell.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\setupapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cscui.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\Windows.FileExplorer.Common.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\AviSynth.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\imagehlp.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\msvcp140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140_1d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\AviSynth.dll'
Exception thrown at 0x00007FF94B94B699 in VirtualDub64.exe: Microsoft C++ exception: MyAVIError at memory location 0x0000000000CFEF68.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\AviSynth.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\imagehlp.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\msvcp140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140_1d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\AviSynth.dll'
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\AviSynth.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\imagehlp.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\msvcp140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140_1d.dll'
'VirtualDub64.exe' (Win32): Unloaded
<- start opening 'version' script

'C:\Windows\System32\AviSynth.dll'
Exception thrown at 0x00007FF94B94B699 in VirtualDub64.exe: Microsoft C++ exception: MyError at memory location 0x0000000000CFF428.

[pinterf]

What are these? Separate source file only with the relevant instructions?
No, it's for code generation. It optimizes for more than one (i.e., two) instruction sets. In the IDE, they appear under Code Generation (Intel).

The /Qax flag generates a secondary code path, allowing the program to dispatch between the base and optional versions at runtime. While I generally think this is beneficial (similar to what we do manually within Avisynth and plugins), and even MSVC does this (running SSE4.1 code instead of the base SSE2 path after checking an internal flag), in Expr, it has such a significant overhead that it kills performance. I tried "Not Set + Optional AVX2" and "AVX2 + Optional AVX512," but both failed to do what I expected. As you can see it in the benchmarks.

The rest of this VS2022/Intel specific page (two more) are optimizer options that fine-tune for a specific architecture, I guess, considering factors like cache, ports, and typical uOps.

So, while it's a good feature, I better avoid using it in the future.

[pinterf]

Hello Ferenc,
please check the return version of the r4210 icx version
I see: 3.7.2 r3661
And various scripts therefore spit out an error message.

The new Avisynth icx versions are fast, I feel that everything is a bit faster and also the caching works better than with the previous versions.

Edit:
Everything back to square one!
That was a mistake. The r4210 cannot be loaded in AvsPmod and AvsPmod then loads another available Avisynth version if an alternative path is specified under Options.

So I have to agree with Tormento, the r4210 does not work.
It is also a lot smaller than the r4198, forgot what to link?
@gispos, DTL, do no more test, don't waste your time. I'm creating a new build set (Expr changes) and will try to set only _one_ instruction set optimization at a time.

[pinterf]

This new build follows the latest Expr commits.

Since the modification affected the C (slowish) part of Expr, you won't see any new features here. With the Intel build, I stayed on the safe side. May the pink ponies be with you.

Avisynth 3.7.3 r4212.
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4212

By now, I'm more or less ready with implementing my ideas. Some other ideas are waiting in the Issues section, but they are not easy ones.

[real.finder]

I wouldn't say it's stable :) Using a good static library ensures that Intel cannot mess it up later with a bad driver or library update (like they did with version 2025.0.0 and their OpenCL driver).

so it was driver problem after all? https://forum.doom9.org/showpost.php?p=2013760&postcount=1584 did they fix it?

[Z2697]

ICC is the old/legacy Intel C/C++ Compiler.
ICX is the new one based on LLVM.

In some cases (libs/apps) clang produces faster binaries, in other cases icx produces faster binaries, in third cases msvc produces faster binaries, in fourth cases gcc produces faster binaries...
There is no such thing "ICX is the best", there is no "ICC will not beat Clang" (implying Clang is always better than ICC). Not to mention that same compiler from one version to another can produce binaries with different speed.

OK, ICX then. I do understand that sometimes one thing is better and some other times another thing is better, I mean it's possible that ICX can be better than Clang sometimes, but it will not beat Clang, does this makes sense? If you understand that as "implying ICX is not always better than Clang" not the other way around?

[DTL]

By now, I'm more or less ready with implementing my ideas. Some other ideas are waiting in the Issues section, but they are not easy ones.

Waiting for 2D resampler engine inside AVS+ core in 202x years. It also work in avs-libplacebo plugin - but it is GPU-only as I understand.

[tormento]

Avisynth 3.7.3 r4612
Thanks, now working here.

[FranceBB]

By now, I'm more or less ready with implementing my ideas. Some other ideas are waiting in the Issues section, but they are not easy ones.

XYZ support so that we don't have to spoof it as a fake RGB64 (i.e RGB 16bit)?

[DTL]

" 16bit"

16bit may be also float half-precision. It may be good for HDR linear. Because current civilization fail to do fast enough RAM for computing systems - usage of float16 allow to double performance with enough (acceptable) precision for visual systems.

But old CPU cores do not support float16 processing (conversion from float32 to float16 and back) ?

Also float16 will half RAM usage for float samples formats and it may be good for current AVS+ multithreading and caching model.

[pinterf]

Waiting for 2D resampler engine inside AVS+ core in 202x years. It also work in avs-libplacebo plugin - but it is GPU-only as I understand.
I've just documented your "new" resizers. Developers like documenting; this has always been the case. :) Please check and let me know if there are any major mistakes in it. Thank you in advance.
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html

[DTL]

I tried to register at the AVS wiki to add about new resizers but I have not received an activation email for months at my @gmail.com email address.

"SincLin2Resize (v3.7.3-) A high-quality resizer that supplements SincResize, designed to maintain performance with increased sinc taps for minimal artifacts."

It is a version of SincResize with a workaround for the 'kernel edge computing issue' of the original SincResize kernel. It is a bit more sharp in comparison with other weighted sinc kernels with the same number of taps used (like Lanczos or Blackman). To suppress that computing errors below 1 LSB of 8 bit recommended number of taps > 3..4. With too low taps used it still may expose that issue. For higher precision computing (> 8bit per sample) the minimum number of taps to shift residual computing error below 1 LSB may be higher.

Both SinPow and UserDefined2 resizers allow to control the 'acutance' effect of the output while saving from too much ringing (in some range of control params). Link to wiki for 'acutance' https://en.wikipedia.org/wiki/Acutance . Acutance of Gauss kernel may be treated as 'zero level' and for SinPow and UserDefined2 may be > zero (depending on control params).

For UserDefined2Resize:

"b: Controls the blurring. Optimal range: -50 to 250.
c: Controls the ringing. Optimal range: -50 to 250.
s (support): Controls the support size. Default is 2.2. Valid range: 2.0 to 4.0."

-50 to 250 are Valid range (values outside this range are typically of no sense and are clipped to -50 to 250). Though recommended c-values may be as low as -40 so the low range clipping may be expanded to -60 or lower.
s-value expected to have a valid range of about 1.8 to 4.0 (or more). 2.0 is too high clipping for low values. Sometimes s-values as low as 1.8 are still usable in some cases.

Typical usable range for b is 70..130 and for c is -30 to 23.

The b and c values are generally interconnected via table or recommended values. Where b typically looks like control for 'sharpness look/makeup' and c looks like a supplement to balance kernel to produce as low ringing as possible. Tables of recommended b and c values may be used as image form or transformed to HTML formatted table form for text-like documentation.
https://i.postimg.cc/sDRhLP1t/image-2025-03-08-015558168.png
where columns were planned as 'overshoot/acutance' view of the output but only single combination of b and c may produce the minimal ringing for each b and c pair (but may also depend on source sharpness (Fourier spectrum)). Table of the recommended b and c values may be mostly valid for high enough downsampling ratios like 10:1 or more but typically usable also to about 2:1 and less. So b > 130 typically close to GaussResize with 'zero acutance' ('film' look/makeup) and b < 95 produces high levels of sharpness/acutance ('video' look/makeup). For initial setup c value must follow b value from table and may be adjusted for each source to minimize ringing.
Internally it is based on a sum of weighted sinc functions by b and c params. With b=c=16 it is equal to SincResize with given support size by s-param.

"The default values of b and c (121/19) create a very soft result. It may be better to use sharper values like 90/-12."

Better version: The default values of b and c (121/19) create a soft film-like look/makeup. It may be better to use sharper values like 80/-20 with higher 'sharpness/acutance'.

s-param description: It controls the used part of the computed kernel in the resampler. Also affect the resampler' performance (more support - less performance). Most sinc-based resizers have support=taps.
For UserDefine2Resize it is possible to manually control support value: Low values like 1.8..2.2 may give some additional 'crispening' effect (while can cause more ringing). High values like 3..4 and more required for more linear processing (highest level of ringing suppression). Also the 'wide-long' soft kernels like b=210 c=98 may require larger support to save from too early kernel truncation in a resampler. If the kernel decays very fast - too much support param may be useless wasting of the computing resources. Higher values of support param may be required for highest precision computing using float samples formats.

SincLin2Resize taps count:
"It is designed to be "not-worse" in full-strike sinc taps count. Recommended to set SincLin2(taps) to two times larger than SincResize(taps)."

Better version: It provides at least taps/2 full-strike sinc taps (lobes ?) count before beginning of linear weighting to zero at the end of the kernel. Recommended to set SincLin2(taps) to two times larger in comparison with previously used SincResize(taps) in old projects. While performance of the resampler will degrade proportionally to taps value used". Taps param controls the balance between performance and quality and ringing length (if present).

"Range:
1-20 for SincResize"

As I remember taps param upper limit for SincResize was relaxed to 150 or more to show how that computing issue may go below 1 LSB for 8 bit with taps > about 80. Need to check current sources for current limit value.

For p-param of SinPow :
"Useful for creating content conditioned to the Nyquist frequency, reducing aliasing and ringing."

Better version: Useful for creating content conditioned to the band-limited channel, reducing aliasing and Gibbs-ringing.

Useful note about resizers usage:
The set of SinPower/UserDefined2 and Sinc/SincLin2/Lanczos/Blackman resizers form a complementary set of resizers for sinc-based workflow for digital imaging with controlled sharpness and ringing. Where SinPowerResize or UserDefined2Resize used for content-creation as downscaling (compressing) and any sinc-based resizer used for upscaling for displaying or intermediate processing (interpolation, decompressing).

Addition 2 to the Notes:
Most (except Point ?) resizers can be used for convolution processing with its kernel without resampling. To enable (force) processing, users must set non-zero values for src_left and/or src_top params (depending on the required dimensions for processing). To save from visible shifting the values must be very low floats (like 0.000001 - need to check the lowest acceptable as non-zero float value ?).

[wonkey_monkey]

I think I've found another version of this old issue (https://forum.doom9.net/showthread.php?p=1849921) (has it really been six years?!):

version.crop(8,32,16,16)
animate(0,100,"bicubicresize",\
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0)

There's a discontinuity at frame 50 because resizing is skipped. With b=1.0/3.0, c=1.0/3.0 (which is the default), or indeed anything other than b=0,c=0.5 (which I still maintain should be the default :sly: ), BicubicResize always blurs or sharpens its output, regardless of resizing, and that blur is missing from frame 50.

[ryrynz]

I've just documented your "new" resizers. Developers like documenting; this has always been the case.


https://i.imgur.com/Yh1tPCKm.jpeg

[pinterf]

I think I've found another version of this old issue (https://forum.doom9.net/showthread.php?p=1849921) (has it really been six years?!):

version.crop(8,32,16,16)
animate(0,100,"bicubicresize",\
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0)

There's a discontinuity at frame 50 because resizing is skipped. With b=1.0/3.0, c=1.0/3.0 (which is the default), or indeed anything other than b=0,c=0.5 (which I still maintain should be the default :sly: ), BicubicResize always blurs or sharpens its output, regardless of resizing, and that blur is missing from frame 50.
Strange, I've just came across it in the change log when I was looking for documentation hints. I remember it having been fixed.
"Resizers: don't use crop at special edge cases to avoid inconsistent results across different parameters/color spaces"

EDIT:
One condition is left there:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/resample.cpp#L941
and
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/resample.cpp#L972

[Z2697]

Maybe keep the old behavior, but add a parameter to force the interpolation? Like what fmtconv does with fh and fv.

[Z2697]

I tried ICX version and it's indeed faster, about 2.5x on my machine.
But I think it's because it uses Intel Math Libraries (the runtime requirements are libmmd.dll and svml_dispmd.dll)
But whatever.

Even x86/x64 users can benefit from this speedup: if the Expr contains specific trigonometric functions (tan, asin, acos, atan) that have no JIT implementation, then Avisynth cannot use JIT and falls back to the C implementation.
ICX is x64 only though.
BTW tan is sin/cos why is it not optimized like sin and cos?

[pinterf]

I tried to register at the AVS wiki to add about new resizers but I have not received an activation email for months at my @gmail.com email address.
[...]

Thanks, I try to integrate it.
The source of online documentation in maintained on github, that is the 'master'. It's in .rst format, which has its learning curve (formatting, to keep the conventions we use throughout the documentation, linking between pages and titles - which I always forget how to do it). But after doing so may pages, I start to get used to it.

When I'm ready, I build with Sphynx into html. Sphynx is a Python module, so you have to have a Python and do a simple "pip install sphynx" afaik. The I run 'make html' from distrib/docs/english and check the result from the local file system in a browser. distrib/docs/english/build/html/index.html

This must be the very same look, what is automatically generarated into
https://avisynthplus.readthedocs.io/en/latest/
(automatic build of rst changes is set up on github)


https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/docs/english/source/avisynthdoc/corefilters/resize.rst

[pinterf]

Maybe keep the old behavior, but add a parameter to force the interpolation? Like what fmtconv does with fh and fv.
I think I left the exact size check there because I'm sure most people would expect this behavior. I admit wonkey_monkey's use case needs to be addressed, and his request is perfectly understandable.

[pinterf]

I tried ICX version and it's indeed faster, about 2.5x on my machine.
But I think it's because it uses Intel Math Libraries (the runtime requirements are libmmd.dll and svml_dispmd.dll)
But whatever.


ICX is x64 only though.
BTW tan is sin/cos why is it not optimized like sin and cos?
I simply did not have time for that, nor was there public demand for it. But since Avisynth is getting smarter by users' requests, it can be arranged if you really need that. In JIT, we have to manually assemble and calculate the Taylor series and handle the edge case preparations. The tangent function has its own Taylor series; we could implement it in JIT, or calculate it twice using sine and cosine.

Imagine it like this:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/exprfilter/exprfilter.cpp#L835

In C, Intel is probably using its own quasi-SIMD functions like _mm_sin_ps, _mm_cos_ps, etc., which are all implemented in their math library. If used, these beat the speed of other compiler implementations by a huge margin.

EDIT:
Last time I implemented atan2.
I took a feasible C implementation, and converted it into our JIT commands.

https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/exprfilter/exprfilter.cpp#L682

EDIT2:
O.K. tangent is almost done in JIT, will do the rest and cleanup in the evening (work awaits me in the garden :))

[tormento]

I've just documented your "new" resizers.
Oh, wow! :thanks:

[tormento]

I tried ICX version and it's indeed faster, about 2.5x on my machine.
What I told you? :p

[Z2697]

What I told you? :p

The thing is, it's the optimized math library that contributes most to the speed, which makes much more sense to me than the compiler alone.

[tormento]

The thing is, it's the optimized math library that contributes most to the speed, which makes much more sense to me than the compiler alone.
It could actually be a solar flare or a fluke in the electricity.

The important thing is that, for our needs, it's faster.

[Z2697]

It could actually be a solar flare or a fluke in the electricity.

The important thing is that, for our needs, it's faster.

It's certainly not those random stuff.

Yeah... if your need is voluntarily disable JIT optimization when it's available? (Or other SIMD / assembly optimizations in other libraries)
Covering edge cases where there's no "written" optimization available is a good thing though, I must say.

[DTL]

Other long-awaiting feature for 'Geometric deformation filters' section : AddBorders() and LetterBox() must have an option to create 'filtered/conditioned' transients to save from ringing at displaying or other processing of this new created transients with interpolation engines. Currently it is possible to workaround only with scripting with extracting-filtering-inserting_back of filtered area of new created transients.
These are still very frequently used filters by users of analog captures like VHS and others.

At the *perfect world of AVS+ for moving pictures* the script like

BlankClip(100, 100, 100, color=$FFFFFF, pixel_type="YV12")
LetterBox(10,10,10,10,color=$000000)
LanczosResize(width*2, height*2, taps=10) (or other sinc-based upsizer with not very low taps number)
ConvertToRGB24(matrix="PC.601")

Must produce white frame with black borders without overshoots (flat/film look/makeup) and without ringing at the edges or corner. With current AVS+ user must use some more or less complex scripting to workaround this issue.

With release r4212 it still produce:
https://i.postimg.cc/G20P5YZt/image-2025-03-09-013416421.png

Expected output in some day new version:
(full-frame simulation with 2 of the several possible conditioning filters)
BlankClip(100, 100, 100, color=$FFFFFF, pixel_type="YV12")
LetterBox(10,10,10,10,color=$000000)
UserDefined2Resize(width, height, src_left=0.00001, src_top=0.00001) (or GaussResize(width, height, p=12, src_left=0.00001, src_top=0.00001))
LanczosResize(width*2, height*2, taps=10)
ConvertToRGB24(matrix="PC.601")

https://i.postimg.cc/cLnr5jZ7/image-2025-03-09-013805513.png

With Gauss p=12
https://i.postimg.cc/Gtd566Z4/image-2025-03-09-015049867.png

[tormento]

It's certainly not those random stuff.
I was joking…

[FranceBB]

I tried to register at the AVS wiki to add about new resizers but I have not received an activation email for months at my @gmail.com email address.

Try to reach out to Wilbert (https://forum.doom9.org/member.php?u=2705) directly or just ask him here (https://forum.doom9.org/showthread.php?t=105205&page=11). I'm sure he can enable your account on the wiki.

[isidroco]

Not sure if it's the right place. There's a bug in Normalize (v3.7.3+ r4066). Using 48k16b stereo will horribly saturate audio (even using normalize values as low as 0.02). Previously converting same audio to Float works fine.

[DTL]

Also it may be recommended to add user-defined support for GaussResize(). As s-param same as in UserDefined2Resize. Gauss kernel is also variable-sized and its useful size significantly depends on p-param value (the distance from zero argument to the low enough return values around zero). Currently support for GaussResize is fixed to 4.0

https://github.com/AviSynth/AviSynthPlus/blob/b038d0225e549fb5e329e68580cb0f3fdcc49d56/avs_core/filters/resample_functions.h#L247

to be some average value to fit many versions of kernel. But it may be too wide for narrow versions (and waste some performance) or too narrow for 'very wide' kernels and limit possible filtering/blurring effect if required. So it may be defaulted to 4.0 to keep compatibility with old scripts and workflows but may be controlled by user with second to p - s-param. The practical limits may be at least 1 to 10 or even more. In the param1 param2 param3 set of params for ConvertXXX for chroma resampling (or possible new applications of resize kernels to filtering like expected in AddBorders/LetterBox) it may be mapped to param2 (or param3 ?).

Also it may be good to add to resizers documentation support values for all resizers (from file https://github.com/AviSynth/AviSynthPlus/blob/b038d0225e549fb5e329e68580cb0f3fdcc49d56/avs_core/filters/resample_functions.h )
PointResize - support 0.0001 (expect = 0)
BilinearResize - support 1.0
BicubicResize - support 2.0
LanczosResize, BlackmanResize, SincResize, SincLin2Resize - support=taps
Spline16Resize - support 2.0
Spline36Resize - support 3.0
Spline64Resize - support 4.0
GaussResize - support 4.0 (expected to be used-defined)
SinPowerResize - support 2.0 (fixed by design)
UserDefined2Resize - support is user-defined by s-param (default 2.3 ?)

So we have 3 different classes of resizers with different support values for resampler:

1. Fixed by design:
PointResize, BilinearResize, BicubicResize, SinPowerResize, SplineXResize

2. Hard fixed to other param:
LanczosResize, BlackmanResize, SincResize, SincLin2Resize

3. Can be user-defined for performance/quality balance or special effects:
UserDefined2Resize, GaussResize

Also it is possible to make 'auto-support' option for GaussResize with limiting lowest usable kernel level to something like 0.01. It is the soultion of current kernel equation of https://github.com/AviSynth/AviSynthPlus/blob/b038d0225e549fb5e329e68580cb0f3fdcc49d56/avs_core/filters/resample_functions.cpp#L209

pow(2.0, - p*value*value);

by 'value' member. I.e. 0.01 = pow(2.0, - p*value*value); (note p = p-param * 0.1 at https://github.com/AviSynth/AviSynthPlus/blob/b038d0225e549fb5e329e68580cb0f3fdcc49d56/avs_core/filters/resample_functions.cpp#L208)

Online solvers gives
https://i.postimg.cc/Kz4qkzjF/image-2025-03-09-131927402.png

Auto-support for GaussResize may be activated if user set s-param to zero ?

After simplification for static members - auto-support=SQRT(6.64/p) (for kernel members above 0.01 of max of 1)
https://i.postimg.cc/bYtSyhgt/image-2025-03-09-151651035.png

It shows current support=4.0 is enough for p-param in range of about 4 to 100 and too big for range 20 to 100 but too low for p-param in current valid range of 0.1 to about 4.

[Emulgator]

There's a bug in Normalize (v3.7.3+ r4066). Using 48k16b stereo will horribly saturate audio.
Can confirm a horribly boosted-to-clip-at-FS audio while touching it with simple internal algos since maybe that version.
No time to give a decent in-depth description ATM though.

[StainlessS]

Can confirm a horribly boosted-to-clip-at-FS audio while touching it with simple internal algos since maybe that version.
No time to give a decent in-depth description ATM though.

About 12 months ago I had similar problem with nasty normalize, I think I mis-diagnosed the problem due to pretty massive scripts and hurry to get result, so I just kludged the problem.

I suspect that the problem I had may be this exact same thing. [I probably wrongly blamed LSmash]

Here thread that I was gonna delete but did not (thanks Emulgator),
the date of thread post is probably a good-ish indicator of problem oranges ( or should that be "origin" :) ). [Oranges by orange man:- https://www.youtube.com/watch?v=qUPsNgmXR7M ]

LSmash weird Audio [JFYI] (20 Feb 2024):- https://forum.doom9.org/showthread.php?p=1997964#post1997964

EDIT: The kludge I used involved conversion to Float audio, I think.

EDIT: In above thread the problem seemed to come from MeGUI normalized audio, but I also (depending upon some things) normalized in Avisynth instead,
I presume that MeGUI normalize is done via Avisynth anyway.
I never did pin down the actual culprit, and continue with the kludge.

[pinterf]

Not sure if it's the right place. There's a bug in Normalize (v3.7.3+ r4066). Using 48k16b stereo will horribly saturate audio (even using normalize values as low as 0.02). Previously converting same audio to Float works fine.
It was probably this one, which is a Microsoft MSVC compiler bug.
https://github.com/AviSynth/AviSynthPlus/commit/d78be370b6f5ef997bc15343b81f519931bf0d54
I made a workaround and reported the issue to Microsoft
https://developercommunity.visualstudio.com/t/Bad-code-gen-with-inlined-functions-with/10813706
See my repo which I created for just this report:
https://github.com/pinterf/msvc_bad_codegen_demo_2

In three month they still reached in problem solving the "Under Consideration" flag. I'm glad I don't write software for nuclear plants.

EDIT: It seems they silently fixed their optimizer compiler. The code built with Visual Studio 17.13.1 no longer has the bug.

[pinterf]

Implemented 'tan' in Expr (the JitASM way). I don't know who and why would use it but it was an interesting task.

Preliminary info:
Expr: implement tan (32 bit float) in JisASM

Benchmark script

BlankClip(1000,1280,720,pixel_type="Y8")
# swipes the range between -Pi to +Pi
s = "sxr 2 * 1 - 3.14159254 * 1 * tan 10 * 128 +"
# swipes the range between -5Pi to +5Pi
# s = "sxr 2 * 1 - 3.14159254 * 5 * tan 1 0 * 128 +"
a= Expr(s, optSSE2 = false, optAVX2=false, OptVectorC=False)
b= Expr(s, optSSE2 = false, optAVX2=false)
c= Expr(s, optSSE2 = True, optAVX2=false)
d= Expr(s, optSSE2 = True, optAVX2=True)

a # or b or c or d

Results:

MSVC Intel ICX LLVM
SinglePixel C : 48 66 [fps]
Vector friendly C: 122 175
JitASM SSE : 345 (same for both)
JitASM AVX : 727 (same for both)

[DTL]

About update for GaussResize : This commit may be used (after testing) - https://github.com/DTL2020/ResampleMT/commit/cbece7356bc06a7cccab69289c883525aaae934d

More detailed description - https://forum.doom9.org/showthread.php?p=2016041#post2016041

It have both user-defined b (base value) added and user-defined 's' or auto-controlled support value. So it is second resizer with 3 control params.

Also the Note can be added to Blur() filter documentation: If larger radius gauss blur is requred - the GaussResize() filter can be used in no-resize mode (convolution only) with low enough p-param values (below 10..15). It can be used for fade-in/out and blur-in/out use cases and also animated with Animate().

[pinterf]

AviSynth+ 3.7.3 r4217

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4217

Implement "tan" for Expr JITasm. See benchmarks in the post above.

[DTL]

icx build from r4217 not working in Win10 x64 again - 'version' script in VirtualDub returns "Avisynth open failure: Avisynth: script open failed!". Only x64_xp_or_better is working.

[pinterf]

There was no build method difference since the previous build. Zero extra geek optimizations, tools did not update themselves (neither msvc, nor ICX).
What does avsmeter64 and Avspmod say? Virtualdub opens avs though VfW interface, the others work differently.
Are your VC redistributables up-to-date? No more question comes into my mind.

[DTL]

Are your VC redistributables up-to-date?

VC++ vcp140.dll files are from 2021. It looks non-updated Win10. At other Win10 host r4217 icx is working.

Can we have some software-way to check for required OS/external components dependencies at avisynth.dll loading/running/startup ? We do not have installer now and it can not check requirements and display any warning.

Some owners of Windows hosts may not like updates like 'to not import new bugs from Microsoft or any other sources to already working software' and restrict to install possibly dangerous software. So not all Win10 hosts are auto-updated with latest Microsoft VC++ redistributables. Also may be in best case the required microsoft components can be 'statically linked' to single .dll so AVS+ can be more 'portable' ?

[pinterf]

We don't have tools to know what works and what not in recent test builds. It's an unfortunate thing that your 2021 redist causes problems _if_ running an ICX based AviSynth.
Install the official 3.7.3 installer, specifically the one with the VC redistributables bundle. Then you have a system with a bit more updated. Then you can copy and exchange the different DLLs as you want. Dependencies are clear in this aspect.

[gispos]

icx build from r4217 not working in Win10 x64 again - 'version' script in VirtualDub returns "Avisynth open failure: Avisynth: script open failed!". Only x64_xp_or_better is working.
The version works for me.
You wrote it yourself, the latest VC runtimes are required. The 4212 should not work on the system with the old runtimes either.

https://forum.doom9.org/showpost.php?p=2015433&postcount=3142

[DTL]

Also note about Animate(): It can only interpolate with linear function. For highly-non-linear processing it causes as result the very non-linear effects on 'timeline'. Is it possible somehow add user-prodived non-linear time function ? May be close to the way how user enter equation to Expr() ?

"You wrote it yourself, the latest VC runtimes are required."

I tried at different Win hosts. Some are 'public usage' and may not have right to install 'common use components updates'. VC++ files installed into system32 may damage other software at given host. It may be nice if Avisynth.dll with all required MS .dlls can be loaded from separate 'portable' folder. So no other software can access that .dlls and possibly become unstable.

[pinterf]

I think I've found another version of this old issue (https://forum.doom9.net/showthread.php?p=1849921) (has it really been six years?!):

version.crop(8,32,16,16)
animate(0,100,"bicubicresize",\
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0)

There's a discontinuity at frame 50 because resizing is skipped. With b=1.0/3.0, c=1.0/3.0 (which is the default), or indeed anything other than b=0,c=0.5 (which I still maintain should be the default :sly: ), BicubicResize always blurs or sharpens its output, regardless of resizing, and that blur is missing from frame 50.
Added "force" boolean to resizers, which forces the resizer algorithm to work even if the clip dimensions would not change at all. Replaces the src_left, src_top is 0.000001 workaround.
.
version.crop(8,32,16,16)
w=width()
h=height()
force=True
# at frame 50 Force=false (default) omits resizing, thus the intentional blur.
animate(0,100,"bicubicresize",\
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,w,h,force,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0,w,h,force)

See it in the next build.

[DTL]

"Added "force" boolean to resizers, which forces the resizer algorithm to work even if the clip dimensions would not change at all. "

It is also long-awaited update because resizers also used as convolution-filters engines in 'no-resize' mode.

But in old hack-mode user can force H and/or V processing with non-zero src_left and/or src_top param. If only 1D processing is requred it is good control. With 'force' it will enable both H and V ? It may be not always good. Better to make 2 dimensions separated logic so user can enable 1D convolution only. Separated control may be by 1 integer or text param like
0 - auto
1 - force H
2 - force V
3 - force H and V

Or 2 new bool params separated like forceH and forceV.

Usage example: If process UV planes of 4:2:2 format with some low-pass filtering - only H convolution is required.


Function Convert422ToRGB24mon_lin_x4_709(clip c)
{
uc=UToY(c)
vc=VToY(c)
uc=UserDefined2ResizeMT(uc,src_left=0.001,uc.width, uc.height, b=125, c=18)
vc=UserDefined2ResizeMT(vc,src_left=0.001,vc.width, vc.height, b=125, c=18)
uc=SincLin2ResizeMT(uc, src_left=0, uc.width*2, uc.height, taps=16)
vc=SincLin2ResizeMT(vc, src_left=0, vc.width*2, vc.height, taps=16)
yuv444=CombinePlanes(c, uc, vc, planes="YUV", source_planes="YYY", pixel_type="YUV444P10")
rgb_lin=ConvertYUVToLinearRGB(yuv444,Color=2)
rgb_lin=SincLin2ResizeMT(rgb_lin,rgb_lin.width*4, rgb_lin.height*4, taps=16)
yuv_out=ConvertLinearRGBToYUV(rgb_lin,Color=2)
return yuv_out.ConvertToRGB24(matrix="PC.709")
}

[pinterf]

What's the use case of blurring just either the H or V direction?

[DTL]

One example is shown in the post above - end_of_chain 'conditioning' of chroma subsampled channels. Before displaying (or format conversion with frame resizing or other RGB geometry changes like rotation may be). The 'intermediate' RGB<->subsampled_YUV conversions are not require this filtering (because in a long sequence of RGB<->subsampled_YUV conversions it will degrade colour sharpness). It is in the core design of chroma-subsampled digital moving pictures systems from the ages of ITU BT rec.601.

Also in the 'nice future' it is expected to have some flag for ConvertToYUV42xToRGB() (or to YUV 4:4:4) to perform unfiltered (intermediate) or filtered UV (final/end_of_chain) processing. Where for 4:2:2 input the UV filtering must be only in H direction.

Currently as AVS used as processing only software (intermediate conversions) the filtering is not (frequently) required. But high quality resize via (linear) RGB from YUV 4:2:0 to low res YUV 4:2:0 (sort of Main Rip Creation Process) also requires it for example.

Example of 'intermediate' workflow with YV12 input and 'unfiltered intermediate RGB' (this also 'nice to have' to be supported in the frame properties metadata - 'is RGB from unfiltered subsampled chroma ?' also 'is RGB half-banded chroma H ?' (from previous YUV 4:2:2 for example), 'is RGB half-banded chroma V ?' (from 4:2:0 YUV for example):

ConvertToRGB24()
RGBAdjust(...)
ConvertToYV12()

Example of 'display RGB' workflow for frame downsize for YV12 input:

ConvertToRGB24() (with filtering UVs to save from ringing at resize if resizer can do it) - restore 'flat RGB'
optional - convert to linear RGB
SinPowerResize(width/2, height/2) - re-condition RGB for lower frame size (also got full-band RGBs from any source - 4:4:4 or 4:2:x)
optional - convert to System Transfer Function RGB
ConvertToYV12() - half-band UV but left unconditioned ringing UVs for next (unlimited) processing stages if required

Example of 'display RGB' workflow for frame upsize for YV12 input (like SD to HD):

ConvertToRGB24() (with filtering UVs to save from ringing at resize if resizer can do it (sinc-based resize will do it)) - restore 'flat RGB'
optional - convert to linear RGB
SincLin2Resize(HD_width, HD_height)
optional - convert to System Transfer Function RGB
ConvertToYV12() - half-band UV but left unconditioned possibly ringing UVs for next (unlimited) processing stages if required

Current working script-function for conversion of 4:2:2 YUV to 'UVfiltered/display/monitor RGB' is

Function Convert422ToRGB24mon_709(clip c)
{
uc=UToY(c)
vc=VToY(c)
uc=UserDefined2Resize(uc,src_left=0.001,uc.width, uc.height, b=125, c=18)
vc=UserDefined2Resize(vc,src_left=0.001,vc.width, vc.height, b=125, c=18)
uc=SincLin2Resize(uc, src_left=0, uc.width*2, uc.height, taps=16)
vc=SincLin2Resize(vc, src_left=0, vc.width*2, vc.height, taps=16)
yuv444=CombinePlanes(c, uc, vc, planes="YUV", source_planes="YYY", pixel_type="YUV444P10")
return yuv444.ConvertToRGB24(matrix="PC.709")
}

And it uses H-only UV planes filtering. It can be created in compiled more optimized for RAM transfer and cache usage form in the future (as expansion of ConvertToRGB() with more arguments like UV conditioning kernel filter params). Though it is really a sequence of Convert422ToYUV444(using_UVfiltering) and next ConvertYUV444ToRGB(as today). But it is currently hidden in the logic of multi-input formats ConvertXXX filters.

Simple idea: If user not need to filter H+V - the old way of src_left !=0 can be used to force H-only filtering.

[StvG]

"You wrote it yourself, the latest VC runtimes are required."

I tried at different Win hosts. Some are 'public usage' and may not have right to install 'common use components updates'. VC++ files installed into system32 may damage other software at given host. It may be nice if Avisynth.dll with all required MS .dlls can be loaded from separate 'portable' folder. So no other software can access that .dlls and possibly become unstable.

If you want newer runtimes only for AviSynth.dll then put them next to AviSynth.dll. This way they be loaded instead the system runtimes in C:\System32.

[DTL]

But to load any version of Avisynth.dll at opening .avs script in some process I need to set somewhere (windows registry ?) path to the folder with that version of Avisynth.dll ? Instead of c:\windows\system32 (as default installer make ?). Why installer copy Avisynth.dll into system32 and not in the setup folder of Avisynth (in ProgramFiles or any other if possible to select by hands in installer) ?

I make search via windows registry for avisynth.dll string - but only found some path to SysWOW64. No path to \system32 (for 64bit .dll). I expect it is auto-loaded from that path only (for 64bit process) ?

[StvG]

But to load any version of Avisynth.dll at opening .avs script in some process I need to set somewhere (windows registry ?) path to the folder with that version of Avisynth.dll ? Instead of c:\windows\system32 (as default installer make ?). Why installer copy Avisynth.dll into system32 and not in the setup folder of Avisynth (in ProgramFiles or any other if possible to select by hands in installer) ?

The easiest way (without bothering with the registry) is to put AviSynth.dll next to the program you use. For e.g., next to VirtualDub64.exe/AvsPmod.exe.

Edit: Or add the location of AviSynth.dll to PATH.

[DTL]

Thank you. I copy files

Avisynth.dll (r4217 icx build)
msvcp140.dll
vcruntime140.dll
vcruntime140_1.dll
(from working host)

in the same filder with VirtualDub x64 at the 'restricted to install VC++ runtime updates' host and now VirtualDub can open 'version' script and shows r4217 build.

[StvG]

Thank you. I copy files

Avisynth.dll (r4217 icx build)
msvcp140.dll
vcruntime140.dll
vcruntime140_1.dll
(from working host)

in the same filder with VirtualDub x64 at the 'restricted to install VC++ runtime updates' host and now VirtualDub can open 'version' script and shows r4217 build.

If you didn't notice my edit of the previous post - also you can add the custom location of AviSynth.dll to PATH so to not have copies of AviSynth.dll+deps for every program you use with AviSynth.

[DTL]

If you didn't notice my edit of the previous post - also you can add the custom location of AviSynth.dll to PATH so to not have copies of AviSynth.dll+deps for every program you use with AviSynth.

But it can again cause some interference with unknown other software if OS .dll loader will somehow found that VC++ runtimes in the PATH location. Too dangerous.

Some more safe way may be to add to PATH in current process (or console prompt) only for the lifetime of this process.

And attempt to start VirtualDub and other software with batch file like


SET PATH=%PATH%; C:\Distr\Avisynth_3.7.3_20250309_r4217\x64_intel_icx\
start Veedub64.exe
exit


But sadly it is not working - looks like can not load VC++ runtimes near Avisynth.dll located in current process PATH (may be \system32 have higher priority in search order) .

Working solution: copy
msvcp140.dll
vcruntime140.dll
vcruntime140_1.dll
(required version) to the same folder with Virtualdub.exe and now AVS r4217 can be loaded via added PATH from batch file. It is also good enough as do not expose these possibly dangerous .dlls to other processes.

[StvG]

But it can again cause some interference with unknown other software if OS .dll loader will somehow found that VC++ runtimes in the PATH location. Too dangerous.

Put AviSynth.dll in X location alongside with the required deps. Add the location to the user PATH. The user PATH is appended to the system PATH.
"Local" PATH is check firstly->system PATH is checked secondly->user PATH is checked thirdly.

The two cases you can have:
1. You load app that requires same deps. The deps from system32 are loaded because the system PATH is checked before the user PATH.
2. You load AviSynth.dll. The deps next to AviSynth.dll are loaded because they are "local" and the "local" PATH is the very first that is checked. The deps in this location will be ever used only for the binaries next to them.

[DTL]

What's the use case of blurring just either the H or V direction?

Oh - I remember second use case - noted in the https://forum.doom9.org/showthread.php?p=2015981#post2015981

https://i.postimg.cc/MKQbDdNF/2025-03-11-084529.png

For better AddBorders/LetterBox filters also 1D filtering is required.

[pinterf]

Oh - I remember second use case - noted in the https://forum.doom9.org/showthread.php?p=2015981#post2015981

For better AddBorders/LetterBox filters also 1D filtering is required.
Sound reasonable, for me it's zero effort to implement 0..3 allowing different H and V settings instead of a simple boolean.

[pinterf]

Meanwhile, a nice "Animate" addition works on my test bench. This work is perhaps the last one before a feature freeze (Now the "Resize" force parameter, Gauss new parameters, and Animate is in the queue).

Animate can take an external function if you'd like more than a linear interpolation.

Even if you don't use an external function, a finer, more precise interpolation of integer values was implemented, and now 64-bit values are handled just fine. Internally, a 96.32-bit integer arithmetic is used for calculation. The calculated values are properly rounded.

Still undecided whether the custom function should return 0.0 at the beginning and 1.0 at the end of the range.

Now this is possible:

version.crop(8,32,16,16)
w=Width()
h=height()
force=3 # both H and V

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

# rules for animate callback: float param named "stage"
# stage is called for values (0.0 , 1.0)
# For proper start-end conditions
# f(0.0) = 0.0 and f(1.0) = 1.0 is a nice to have

function animhelper_lin(float "stage")
{
return stage # full linear
}

function animhelper_exp(float "stage")
{
return (stage*stage*stage)
}

fn_lin = Func(animhelper_lin)
fn_exp = Func(animhelper_exp)

#function
a=animate(0,100,"bicubicresize", fn_exp, \
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,w,h,force,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0,w,h,force)

#function implemented as linear
b=animate(0,100,"bicubicresize", fn_lin, \
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,w,h,force,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0,w,h,force)

# classic, always linear
c=animate(0,100,"bicubicresize", \
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,w,h,force,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0,w,h,force)

#check
d=Diff(b,c) # they are the same

StackHorizontal(a,b,c,d)

[DTL]

Sound reasonable, for me it's zero effort to implement 0..3 allowing different H and V settings instead of a simple boolean.

Yes - integer control with 0 to 3 cases is enough.

About better versions of ConvertToXXX for conversions between full-band and sub-sampled chroma:

1. Downconversions (from 4:4:4 to 4:2:x) should work as today with single resize filter params.
The pre-filtering and resizing can be done in single call to resampler with user-provided kernel params.

2. Upconversions (from 4:2:x to 4:4:4) need addition of special 'pre-filter' params set (same as current resize filter). And optional 1 more stage for UV passing to resampler in no-resize mode.

If user make 'standard intermediate' upconversion to 4:4:4 (YUV or dematrix to RGB) - the 'pre-filter' params is not set and this stage is skipped. Short kernel resizer used to save from ringing at 2x upsampling of unconditioned UVs - like Bicubic or short Spline (16?) or even Point. Today we have default Bicubic and it work about good.

If user make 'final end_of_chain' upconversion to 4:4:4 - the 'pre-filter' params set to anti-gibbs low pass filtering (like Gauss or SinPow or UD2) and resize filter can be long kernel sinc with many taps (like Sinc or SincLin2 or Lanczos or Blackman).

Default 'pre-filter' params set is 'not set' and pre-filtering stage is disabled/skipped.

The minimum required is new version of

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

With added UV prefiltering stage it expected:

ConvertToYUV444(clip, [ string matrix, bool interlaced,
string ChromaInPlacement,
string chromaprefilter,
float pre_param1, float pre_param2, float pre_param3,
string chromaresample,
float param1, float param2, float param3] )

where prefilter is only applied to further upsampled direction (H if input is 4:2:2 or H and V if input is 4:2:0). This expected to have performance and RAM usage benefit over user-script with extracting UV planes for prefiltering (and optional resizing) and combining back to YUV.

[pinterf]

Until I understand why on earth a second treat is needed on chroma :), a question:
Since those Gauss extra parameters don't do any harm and give some freedom, I adopted them. Since defaults are kept, this is fully compatible.
It's so simple, that I don't think I can expect change of mind on this topic, isn't it?

[DTL]

a question:
Since those Gauss extra parameters don't do any harm and give some freedom, I adopted them. Since defaults are kept, this is fully compatible.
It's so simple, that I don't think I can expect change of mind on this topic, isn't it?

Yes - I hope the changes are final. Some post-ideas on sources text:

1. The 'support' limits for SincResize and GaussResize are properties of resampler engine used and not kernels - so we can make
#define MAX_SUPPORT 150

(as current SincResize - it really depends on resampler's ability to process with enough performance and require not very small frame size) and make clamping of support (and taps) (0, MAX_SUPPORT) in both SincResize and GaussResize.

2. The highest p for GaussResize is naturally limited to about 50..100 where it becomes equal to PointResize (support falls greatly below 1) and do not decrease 'blur' any more. But lowest of 0.01 may be not enough if user process HD or UHD frame and want more soft blur and have enough compute resources. So the MAX_SUPPORT and min valid p-param for GaussResize may be subject of research and/or user-requests for max softening required. If we allow min p-param to 0.001 (or lower) - the MAX_SUPPORT define also need to be somehow higher (may be 250 or 500 - need to check the s-equation output). Or some research need about how much 'support' size can use current AVS+ resample engine (at how large frame sizes and colour-subsampling formats).

[DTL]

"Until I understand why on earth a second treat is needed on chroma "

You need to dig deeply to the beginning of the digital moving pictures on this planet at the current civilization - it is about 1/2 or century in the past. When the very first ITU BT 601 rec/standard on digitizing of analog video was developed. There were (may be still present) some articles about that times at EBU website (or Internet archive). The key words is something about 'we finally agreed on UV low-pass filters defined in BT rec.601 for 4:2:2 subsampled chroma but it cause UV signals ringing as hell'. It was designed to allow many generations YUV4:2:2<->RGB transcodings in the production chain without great chroma sharpness losses. I not remember the exact document link - will try to search one more time some later.

[tormento]

The killer feature to add would be CUDA support, such as NekoPanda started. I just dream of that.

And I think I will keep on dreaming. :)

[pinterf]

AviSynth is a framework that provides the necessary ecosystem for creating a filter chain that can keep data in GPU memory across filters, eliminating the need to transfer data back and forth between the CPU and GPU. Dreaming about a CUDA-core AviSynth is pointless without plugins, unless one is satisfied with a CUDA-accelerated Version() clip.

There are other ways to achieve this if authors write their own plugins and follow their own rules.

By the way, even Nekopanda didn't rewrite everything. They specifically rewrote filters to support only 8-bit, others only YV12, and MvTools with a block size of 8x8.

[DTL]

I did some simulation with
'standard bicubic subsampled chroma 4:2:2 ColorBars' names _b
and
'max possible bandwidth subsampled chroma 4:2:2 ColorBars" names _s

With different upconversions to 4:4:4 and 4x sinc-based displaying resizing (LanczosResize)

https://i.postimg.cc/Bbc55sGf/image-2025-03-11-184839773.png

Script:

Function Convert422To444dp(clip c)
{
uc=UToY(c)
vc=VToY(c)
uc=UserDefined2Resize(uc,src_left=0.001,uc.width, uc.height, b=115, c=9)
vc=UserDefined2Resize(vc,src_left=0.001,vc.width, vc.height, b=115, c=9)
uc=SincLin2Resize(uc, src_left=0, uc.width*2, uc.height, taps=16)
vc=SincLin2Resize(vc, src_left=0, vc.width*2, vc.height, taps=16)
yuv444=CombinePlanes(c, uc, vc, planes="YUV", source_planes="YYY", pixel_type="YUV444P8")
return yuv444
}

Function Convert422To444sp(clip c)
{
return ConvertToYUV444(c, chromaresample="userdefined2", param1=115, param2=9)
}

ColorBarsHD(2048,150)
UserDefined2Resize(width/8, height, b=120, c=13) # YUV 4:4:4 cond

bt601_chroma_b=ConvertToYUV422(chromaresample="bicubic") # AVS_bicubic 42x chroma - half band uncond
bt601_chroma_s=ConvertToYUV422(chromaresample="sinclin2") # close_bt 601 42x chroma - half band uncond

#single pass 2x upsize no anti-Gibbs
sp_noag_bic_b=ConvertToYUV444(bt601_chroma_b).Subtitle("sp_noag_bic_b")
sp_noag_bic_s=ConvertToYUV444(bt601_chroma_s).SubTitle("sp_noag_bic_s")

#single pass 2x upsize + use anti-Gibbs kernel
sp_ag_b=Convert422To444sp(bt601_chroma_b).Subtitle("sp_ag_b")
sp_ag_s=Convert422To444sp(bt601_chroma_s).Subtitle("sp_ag_s")

#dual pass
dp_ag_b=Convert422To444dp(bt601_chroma_b).Subtitle("dp_ag_b")
dp_ag_s=Convert422To444dp(bt601_chroma_s).Subtitle("dp_ag_s")

#last=StackVertical(sp_noag_bic,sp_noag, sp_ag, dp_ag)
last = StackVertical(sp_noag_bic_b, sp_noag_bic_s, sp_ag_b, sp_ag_s, dp_ag_b, dp_ag_s)

LanczosResize(width*4, height, taps=16)

ConvertToRGB24(matrix="PC.601")


The worst case ringing is when standard bicubic-based upsampler meet highest possible bandwidth subsampled chroma (possible from some sources). But if source produced with AVS-like ConvertTo422 with bicubic downsampled chroma it works good enough (AVS resizers are good complement each other like bicubic for downsize and upsize).

The single pass chroma upconverting with anti-ring kernel do not shows significant difference in ringing over pre-filtered chroma it is original frequency domain + second pass sinc-based flat upsampler (dual-pass chroma processing). Also the dark shadows in colour transients looks a bit smaller in single pass processing. So prefiltered chroma way may be left for special use cases (if it may benefit with some current user's source) and may be done in scripting.

[pinterf]

Avisynth+ 3.7.3 r4241
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4241

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/animate.html

Last week changes
20250311 3.7.3 r4241
--------------------
- Animate: Custom function option
- Animate: more precise granularity for integer interpolation, allow 64 bit input
- Animate: add proper rounding for integer interpolation
- Resizers: add "force" integer parameter to force the resizing process even if Avisynth decided it's not needed
- GaussResize: add "b" and "s" parameters See :doc:`Resize Filters <corefilters/resize>`.

20250309 3.7.3 r4217
--------------------
Expr: implement tanf in JisASM

Benchmark script

BlankClip(1000,1280,720,pixel_type="Y8")
# swipes the range between -Pi to +Pi
s = "sxr 2 * 1 - 3.14159254 * 1 * tan 10 * 128 +"
# swipes the range between -5Pi to +5Pi
# s = "sxr 2 * 1 - 3.14159254 * 5 * tan 1 0 * 128 +"
a= Expr(s, optSSE2 = false, optAVX2=false, OptVectorC=False)
b= Expr(s, optSSE2 = false, optAVX2=false)
c= Expr(s, optSSE2 = True, optAVX2=false)
d= Expr(s, optSSE2 = True, optAVX2=True)

a # or b or c or d

Results:

MSVC Intel ICX LLVM
SinglePixel C : 48 66 [fps]
Vector friendly C: 122 175
JitASM SSE : 345 (same for both)
JitASM AVX : 727 (same for both)


20250306 3.7.3 r4612
--------------------
Expr: Rewrite the C (non-Intel-JIT) path to support vectorization, if the compiler is capable.

I created this for non-Intel platforms where the (Intel SSE2-AVX2) JIT compiler does not work.

Even if the compiler is not very advanced (MSVC khhhhmm..) this approach is faster because it
has less overhead when interpreting the instruction flow. It processes 16, 8, 4, and 1 floats
when handling the horizontal line, taking the largest chunks it can then finishing the rest
with the smaller ones.

Benchmarks (x64 bit). For comparison, I also provide the JIT results.

Script (optSSE2 = false disables JIT):

# Mandelbrot
ColorBarsHD()
a="X dup * Y dup * - A + T^ X Y 2 * * B + 2 min Y^ T 2 min X^ "
b=a+a
c=b+b
blankclip(width=960,height=640,length=1600,pixel_type="YUV420P8")
Expr("sxr 3 * 2 - -1.2947627 - 1.01 frameno ^ / -1.2947627 + A@ X^ syr 2 * 1 - 0.4399695 "
\ + "- 1.01 frameno ^ / 0.4399695 + B@ Y^ "+c+c+c+c+c+b+a+"X dup * Y dup * + 4 < 0 255 ?",
\ "128", "128",optSSE2 = false, optAVX2=false) # optVectorC=true default

MSVC: Microsoft VC, actual VS2022 version.
Intel: Intel C++ Compiler 2025 - LLVM based, aka ICX.

"Base" means the instruction set is not specified: SSE2 is the minimum for x64.

Compiler/Settings VectSize FPS
-------------------------------------- ---------- -----
MSVC debug 1 0.27
Intel (base + optional AVX2 paths) 1 1.01 (! Mixed instruction set support, slow)
MSVC Base 1 1.71 VectorSize=1, not optimal :)
MSVC old single variable C: - 2.82
Intel old single variable C: - 2.90
MSVC Base 16 4.47 (initial Proof of Concept version)
MSVC AVX2 16 4.59 (initial PoC version)
MSVC Base 16 5.94
MSVC AVX2 16 6.04
Intel Base 16 6.29 (initial PoC version)
Intel AVX2 optional AVX512 -Qax:AVX512 16 12.60 (! Mixed instruction set support, slow)
Intel Base 16 14.70
Intel AVX2 16 19.20
Intel AVX512 16 20.10
MSVC JIT SSE2 2x4 59.00 (dual lanes, XMM regs)
MSVC JIT AVX2 2x8 128.00 (dual lanes,YMM regs)

In this test, where dual processor optimization was enabled, Intel performed poorly (though
it still achieved twice the speed of MSVC). It seems that dynamically dispatching code fragments
to different instruction sets incurs significant overhead.

Conclusion:

We should better avoid builds mixed-code sets.
Since AVX2 has been generally supported for at least ten years, creating a non-mixed
AVX2-only compilation is a reasonable enhancement.

Looking at the numbers, achieving one-third the speed of the old SSE2 JIT, which we considered
fast, is quite impressive. Even x86/x64 users can benefit from this speedup. If the Expr contains
specific trigonometric functions (tan, asin, acos, atan) that have no JIT implementation, then
Avisynth cannot use JIT and falls back to the C implementation.

Expr has now a new debug parameter: bool optVectorC (default true) which C code to run if non-JIT is used.

[DTL]

Now you can also update Notes to the Blur() - https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/blur.html

"If you need a larger radius Gaussian blur,..."

GaussResize(width, height, force=3, p=0.1, s=0)

It looks github web do not allow to add comments on lines or at least full .rst file. https://github.com/pinterf/AviSynthPlus/blob/master/distrib/docs/english/source/avisynthdoc/corefilters/resize.rst?plain=1#L438

Current: Force the resizing process even if the dimensions remain unchanged and ``src_width`` or ``src_top``
are zero. Useful to intentionally prevent sudden visual differences that might occur if resizing
is unexpectedly skipped.

* 0 - return unchanged if no resize needed
* 1 - force H - Horizontal resizing phase
* 2 - force V - Vertical resizing phase

Better text: Force the resizing or convolution with resize kernel (filtering) process even if the dimensions remain unchanged and ``src_width`` or ``src_top``
are zero. Useful to intentionally prevent sudden visual differences that might occur if resizing
is unexpectedly skipped or if convolution only (filtering) without resize is required.

* 0 - return unchanged if no resize needed
* 1 - force H - Horizontal resizing or convolution (filtering) phase
* 2 - force V - Vertical resizing or convolution (filtering) phase

For GaussResize p :
"original equation is s = sqrt(-ln(0.01)/(param*ln(b))"

p-param passed to GaussResize is internally scaled by 0.1 (old AVS arguments were integers only ?). So from user's view original equation is s = sqrt(-ln(0.01)/((p-param * 0.1)*ln(b))

Also in "as s = sqrt(4.6 / ((param * 0.1) * log(b)))" - log(b) in C-library is log based e-number (natural). So for less messy description may be better to write as 's = sqrt(4.6 / ((p * 0.1) * ln(b)))' . Where ln(b) is more universal math equation for natural logarithm. And 'p' and 'b' are directly entered by user params values.

For GaussResize b :
b: Controls the blurring. Valid range: 1.5 to 3.5.

Better text:
b: Controls the blurring. Valid range: 1.5 to 3.5. Filter kernel is b^(-p*0.1*(x^2)) . Default b is 2.0 to be compatible with pre-3.7.4 use cases. If high precision Gauss kernel is required (for example for filtering applications) it is recommended to use the base of the natural logarithm 2.71828.

[pinterf]

Now you can also update Notes to the Blur() -
[...]
GaussResize(width, height, force=3, p=0.1, s=0)
[...]

Thanks, for me it's better to see all your proposed changes here rather than at random places as comments. I prefer not having to think over where the modifications are.

[LigH]

What error exactly? Please quote.

[DTL]

Now it is script-based simulation of what we have now with AddBorders and what is nice to have in single call to AddBorders with options of filtering new transients:


Function AddBordersHF(clip c, int left, int right, int flt_rad)
{
unflt=AddBorders(c, left, 0, right, 0)
flt=GaussResize(unflt, unflt.width, unflt.height, p=10, b=2.71828, s=0, force=1)
uf_internal=Crop(c, flt_rad, 0, c.width-flt_rad*2, c.height)
return Overlay(flt, uf_internal, x=left+flt_rad, y=0)
}

Function AddBordersVF(clip c, int top, int bottom, int flt_rad)
{
unflt=AddBorders(c, 0, top, 0, bottom)
flt=GaussResize(unflt, unflt.width, unflt.height, p=10, b=2.71828, s=0, force=2)
uf_internal=Crop(c, 0, flt_rad, 0, c.height - flt_rad*2)
return Overlay(flt, uf_internal, x=0, y=top+flt_rad)
}


ColorBarsHD(2000,2000)
UserDefined2Resize(width/10, height/10)

std=AddBorders(10, 10, 10, 10)

AddBordersHF(last, 10, 10, 2)
AddBordersVF(last, 10, 10, 2)

StackVertical(std, last)

LanczosResize(width*4, height*2, taps=16)


https://i.postimg.cc/q74h7956/image-2025-03-12-201132497.png

It is not very high-performance way because filtering is processed over full frame (the small extras from input frame is enough around transients areas of size about (resizer's 'support' * 2 + 2 * flt_rad)).

The functions of AddBordersHF and AddBordersVF expected to be implemented in compiled form (and called one or both if H_or_V or H_and_V borders added).

Expected new params to AddBorders (and LetterBox):
1. Filtering kernel name and its params (+4 new params). Defaults: Gauss, p=10, b=2.71828, s=0)
2. Radius of filtered transient (integer, typically 1 (already good quality) or 2 or 3 (even better quality) is enough, 0 mean filtering is disabled)

For best performance in compiled form it may be done as 'in-place' transform - read narrow parts of source frame to filtering (convolution) engine and replace flt_rad*2 number of samples around transient with filtered samples. No full-frame RAM read and store.

[jpsdr]

@Jamaika
What exactly is the question ? I have update according DTL pull request, but not builds for now.

Still not add the "force" parameter, and this one will probably not be in the desampling, as it has no effect on the parameters of the resampling filter.
And still not updated the NNEDI internal call parameters... :(
Please, stop changing the resamplers and giving me more work... :D

[pinterf]

Now it is script-based simulation of what we have now with AddBorders and what is nice to have in single call to AddBorders with options of filtering new .
Meanwhile I did my study as well. I did a full AddBorders first, then cropped and blur-resized four smaller areas: a wider rectangle around the left/right/top/bottom margins, N pixels aouround the transient border area. Then with a specially written new filter MultiOverlay (quick one-pass overlay of N clips onto an original, with N pairs of xy coordinates) I copied back these blurred rectangles onto the transient area. In my proof of concept the force-resize was made on +/- 10 pixel wide rectanges from which I copied back only the +/- 1,2 or 3 pixel wide central part. Resizing a broader part is necessary, too small dimension are giving error.

[DTL]

There are many possible solutions for the filtering/blurring of new created transients with different quality/performance balance.

Usage of 'full-blood' specially designed kernels for resizing and wide/long-enough kernels/convolutions/supports allows to create best quality but requires more computing or usage of more complex convolution engines (like core resampler engine of AVS).

But in simple cases in the past we sometime uses much more simple filter Blur() with also H or V only processing depending on the direction of new added transient (setting amountH or amountV params only to non-zero). It is much more simple 3-samples wide kernel convolution-only engine and it gives not very bad result (may be about 70..90+% of possible quality of GaussResize convolution). But its kernel is more simple and more limited in possible max quality (because of too low support/length too).

Some 'task size estimations' :
For p=10 and b=2.72 in current GaussResize the 1% gauss-kernel 'side_size/support' is sqrt(4.6 / ((p * 0.1) * ln(b))) = 2.144 and it sort of 'provides 99% quality of gauss-kernel'. It mean it is enough to process +-3 input samples (total kernel size of 6) in convolution. With new required calculated samples of +-3 max to the sides of new created transient it mean we need to read 3+3=6 samples to the 'sides' of transient max (and total of 12 ?) to send to convolution engine. With 'radius' of 1 it is 1+3=4 and input 8 samples max. If number of new added (or filled in case of LetterBox) samples are not enough for current convolution step - we duplicate last edge sample (it may be already working in Blur() filter design). Sort of 'virtually expanded image of the same colour'.

For colour-subsampled formats the AVS resampler engine (used in 'resizers') may require more size of the buffer to process.

Also the 'no-resize' convolution engine from GeneralConvolution() filter can be used too. But as user need to manually create kernel coefficients it is not very easy to control so rarely used.

[DTL]

Some issue with Info() on small frame size ?

ColorBarsHD(2000,2000)
BilinearResize(width/10, height/10)
info()


Cropped upper part (shifted up ?)
https://i.postimg.cc/mkbXYQS2/image-2025-03-13-020055693.png

Also a question to make scripting easier - can we skip
int target_width, target_height =
Width and height of the returned clip.
params in Resize() ? If not set - can it assume it is equal to input ? Or at least if force > 0. If resize engine used for no-resize filtering - it is too long and possibly source of an error to search and type input width and height.

[pinterf]

AviSynth+ 3.7.3 r4246
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4246

AddBorders and LetterBox: add transient filtering.
new filter: MultiOverlay. Bulk copy-paste from clips.

More info:

Latest changes since 3.7.3: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
AddBorders doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/addborders.html
MultiOverlay doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/multioverlay.html

And at this point I'd like to stop adding more new features to 3.7.3.

[hello_hello]

Is the behavior of the Defined, Default and VarExist functions inconsistent?
I ask, as I've not used VarExist before and I expected it to be the same as Defined, in that the specified variable shouldn't be a string.

Z = VarExist(X)
I don't know what "X" means
(couldn't not knowing what "X" means return false?)

Z = VarExist("X")
Z is false

X = undefined() or any value other than a string
Z = VarExist(X)
Invalid arguments to VarExist

X = undefined()
Z = VarExist("X")
Z is true

X = "Y"
Z = VarExist(X)
Z is false
(should this return "invalid arguments to VarExist" if the variable must be specified as a string?)

X = "Y"
Z = VarExist("X")
Z is true

The Default and Defined functions seem to interpret string literals as variables.
I've never used them that way before, but after experimenting with VarExist, I thought I'd try it.

Z = defined(X)
I don't know what "X" means.

X = undefined()
Z = defined("X")
Z is true

X = undefined()
Z = defined(X)
Z is false

[DTL]

AviSynth+ 3.7.3 r4246
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4246

AddBorders and LetterBox: add transient filtering.


Thank you.

The most important Note to the documentation of AddBorders and LetterBox (and possibly any other filters used same method of conditioning of the transients in the future):

The anti-ringing filtering of transients created by currently implemented solutions is mostly valid (have most of the design-quality) for current/working Transfer Domain. Because currently AVS+ core does not support Transfer Domain conversions - it can only apply any filtering in Current Transfer Domain and can not serve as Transfer Domain conversion tool inside its filters.

It means if a user prepares content for being resized (processed with any interpolation) in another Transfer Domain (like in Linear) - the quality of anti-ringing created in another Transfer Domain will be degraded by Transfer Domain conversion. So if a user needs to prepare a content for any Transfer Domain with highest quality of anti-ringing filtered transients - the filters like AddBorders/LetterBox(r>0) must be applied to the clip converted to the required Transfer Domain first.

Typically AVS+ process clips with data in input data System Transfer Domain (we need clip/frameProperty with current Transfer Domain tagging some day) if users do not apply Transfer Domain conversion.

So example for preparing transients for being mostly compatible with Linear Transfer Domain (for example source in bt.601 System Transfer Domain and user prepare content for best quality resize in Linear Transfer Domain):

(in pseudo-filters)

ConvertTransfer(output="linear')
AddBorders(10, r=1)
..apply any other filters in Linear Transfer Domain..
ConvertTransfer(output="some_system')

Currently Transfer Domain conversions are supported by external plugins (avsresize, fmtconv and jpsdr's plugins and may be others).

[DTL]

Recommended edits for https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/addborders.html :

Param name "string "resample"": Typically resample means changing of samples count. Here we have only changed samples values by filtering. It also looks like some 'resampling' though. Maybe it is better to name the param 'filter' or '(filter_)kernel'.

Current text: "When r radius is not zero, then determines which resampler is used in the transient filtering. All AviSynth resizers are allowed: ("point", "bilinear", "bicubic", "lanczos", "lanczos4", "blackman", "spline16", "spline36", "spline64", "gauss" and "sinc", "sinpow", "sinclin2" and "userdefined2")."

Recommended text: When r radius is not zero, then determines which resampler' kernel is used in the transient filtering. All AviSynth resizers' kernels are allowed: ("point", "bilinear", "bicubic", "lanczos", "lanczos4", "blackman", "spline16", "spline36", "spline64", "gauss" and "sinc", "sinpow", "sinclin2" and "userdefined2"). Most useful are "gauss", "sinpow" and "userdefined2". Where "gauss", "sinpow" are easier to control and "userdefined2" can provide best quality (especially if r=2 or more with param3 (support) adjusted from default 2.3 to higher values like 5 or more. See also Notes below).


Current text: "These 'float' type parameters can be the additional parameters for the resampler. Some resizer algorithms would need and can be fine tuned with up to 3 parameters. Their default values depend on the selected chromaresample resizer kernel."

Recommended text: These 'float' type parameters can be the additional parameters for setup the used filtering kernel and convolution (support-size parameter). Some filtering algorithms would need and can be fine tuned with up to 3 parameters. Their default values depend on the selected filtering kernel.


Current text: "When r radius is not zero, transient filtering occurs. Even r=1 is giving sufficient protection for some next processing stages."

Recommended text: When r radius is not zero, transient filtering occurs. Even r=1 is giving sufficient protection for some next processing stages. Max used r-parameter value may reach 4 or 5 for some types of filtering if higher quality is required (total number of changed samples created by filtering process to 'describe' or 'encode' the transient's shape is r*2). See Note below. Also high values of r-parameter may be used for artistic intent to make transient to added border more visibly soft.


Current text: # Add 20 black pixels around the clip, filters (blurs) 1 pixel with the default "gauss" method
AddBorders(20, 20, 20, 20, r=1)

Recommended text: # Add 20 black pixels around the clip, filters (blurs) 1 pixel around new created transient (2 pixels total) with the default "gauss" kernel
AddBorders(20, 20, 20, 20, r=1)

Recommended Notes: As noted in Japan ARIB STD-B28 https://www.arib.or.jp/english/html/overview/doc/6-STD-B28v1_0-E1.pdf A.5 : The number of samples to be used for the transient shall be 6 to 9, in the case of 1920 horizontal samples, although it may depend upon the scale of hardware, process performance and the so-called “make up”. It means the max used value of the r-parameter may reach 4 or 5 (9/2=4.5 but only integers are valid for current implementation).

[pinterf]

Recommended edits for https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/addborders.html :


I wait a bit with the edit, your earlier modifications are already integrated (not commited yet - only together with this batch)

[DTL]

Recommended edits to https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html

Current text: When resizing images, convolution filters help in smoothing or sharpening the image to avoid artifacts like aliasing, which can occur when the image is scaled up or down.

Recommended text: When resizing images, convolution filters help in smoothing or sharpening the image to avoid artifacts like aliasing, ringing, which can occur when the image is scaled up or down.

Current text: The set of SinPower/UserDefined2 and Sinc/SincLin2/Lanczos/Blackman resizers form a complementary set for a sinc-based workflow in digital imaging, allowing controlled sharpness and ringing. SinPowerResize or UserDefined2Resize are used for content creation as downscaling (compressing), while any sinc-based resizer can be used for upscaling for display or intermediate processing (interpolation, decompressing).

Recommended text: The set of SinPower/UserDefined2 and Sinc/SincLin2/Lanczos/Blackman resizers form a complementary set for a sinc-based workflow in digital moving imaging, allowing controlled sharpness and ringing. Digital moving imaging is a subset of general digital imaging for processing of moving (or, in general, any transforming in time like rotating/scaling/skewing and other) objects' views in digital form with as low distortions as possible. SinPowerResize or UserDefined2Resize are used for content creation as downscaling (compressing), while any sinc-based resizer can be used for upscaling for display or intermediate processing (interpolation, decompressing). Other resize kernels (Bicubic, Spline, Point, Gauss) come from general purpose digital imaging (typically static or pixel-based images) and can be used when sinc-based workflow can not serve good or static images processing is required. Though Gauss kernel can also be used as a good quality anti-Gibbs ringing filter for sinc-based workflows.


Current text: Optionally, when a filtering radius is given, a custom resizer can be added to AddBorders and LetterBox. In these filters the transient areas (boundary of the new borders) are filtered, in order to prevent ringing e.g. in a subsequent upscale.

Recommended text: Optionally, when a filtering radius is given, a custom convolution filtering with given resizer's kernel can be applied to new transients created by AddBorders and LetterBox filters. In these filters the transient areas (boundary of the new borders) are filtered, in order to prevent ringing e.g. in a subsequent upscale or also as additional artistic intent.

Current text: Everything is the same as mentioned above in Resizers in ConvertToXXXX section, except, that 'gauss' default parameters are tunes for blurring:

Recommended text: Everything is the same as mentioned above in Resizers in ConvertToXXXX section, except, that 'gauss' default parameters are tuned for anti-ringing processing for subsequent sinc-based interpolation giving 'flat/film' 'look/make up' of the filtered transient:


Current text: SincLinResize (clip, int target_width, int target_height,
float "src_left", float "src_top", float "src_width", float "src_height",
int "taps", int "force")
Typing error - SincLin2Resize

Current text: Internally, it is based on a sum of weighted sinc functions by b and c parameters. With b = c = 16, it is equivalent to SincResize with the given support size by the s parameter.

Recommended text: Internally, it is based on a sum of weighted sinc functions by b and c parameters. The weighting coefficients for second and third kernel members are computed as weight=(paramrter_value - 16) / 219 to be directly compatible with classic 8-bit narrow video levels range mapping. While the first kernel member weighting coefficient (virtual a-parameter) is internally fixed to 1.0. With b = c = 16, it is equivalent to SincResize with the given support size by the s parameter.

Current text: The default values of b and c (121/19) create a soft film-like look/makeup. It may be better to use sharper values like 80/-20 with higher 'sharpness/acutance'

Recommended text: The default values of b and c (121/19) create a soft film-like look/makeup. In the use cases where higher 'sharpness/acutance' is required for 'video' look/makeup - the values like 80/-20 may be recommended.

Current text: p
Parameter for GaussResize and SinPowerResize only.
Sharpness. Range from about 1 to 100, with 1 being very blurry and 100 being very sharp.
GaussResize
Default: 30.0

Recommended text: p
Parameter for GaussResize and SinPowerResize only.
Sharpness.

GaussResize

Default: 30.0. Range from 0.01 to 100, with 0.01 being very blurry and 100 being very sharp. Values below about 5 require manually increasing the support-size (s-parameter) or setting s-parameter to zero (auto-computed support size internally). If support-size is left too small with low p-parameter values it will cause non-linear distortions.

Recommended Notes addition:
All AVS+ core resizers use the same highly optimized 1 Dimensional convolution and resampling engine supporting all sample formats and bit depths. In 'no-resize' modes it is used as a convolution only engine. The only difference between different 'Resizers' is kernel function sent to the resampler and 'support' size set for processing. This causes all these resizing methods to produce some different output result in comparison with single-pass 2 Dimensional resampling engines (typically used in JincResize or typically EWA-prefixed resize methods) even if the same kernel functions is used.

For information 'support' size for different 'Resize' methods used:
PointResize - support 0.0001 (expect = 0)
BilinearResize - support 1.0
BicubicResize - support 2.0
LanczosResize, BlackmanResize, SincResize, SincLin2Resize - support=taps
Spline16Resize - support 2.0
Spline36Resize - support 3.0
Spline64Resize - support 4.0
GaussResize - support 4.0 (or defined by s-parameter or auto-calculated)
SinPowerResize - support 2.0 (fixed by design)
UserDefined2Resize - support is user-defined by s-parameter (default is 2.3)

[DTL]

It looks we have some issue with the resampling engine at handling 'edge conditions' -

Test script:

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

near=AddBorders(0, 2, 0, 2, r=2)
far=AddBorders(0, 20, 0, 20, r=2)
far_crop=Crop(far, 0, 18, 0, -18)
near_black_expanded=AddBorders(near, 0,18, 0, 18, r=0)

StackVertical(near, far, far_crop, near_black_expanded)

LanczosResize(width*2, height*2, taps=16)


https://i.postimg.cc/pV4hD7B6/2025-03-15-212703.png

The created transient of radius=2 at the edge of frame should be valid for non-ringing resize. But sinc-based resizer still shows lots of ringing. If we add border length > taps number - the same created transient gives about non-ringed result at sinc-upsize to 2x.
Expected action of resampler at handling this edge case conditon - make extension of the last edge sample (duplicate) to the total kernel size of the resampler (make it equal to large-length added border). As last example.

Current workaround if resize required somewhere inside AVS - add border of enough size (to be comparable with resizer kernel size ?) and crop after resizing.

Addition: Tested with avsresize - it process edges as expected without ringing. So it is an issue in AVS+ resampler:
https://i.postimg.cc/BQtzzmRD/2025-03-15-230621.png

The use case of very small filtered borders transients: Add smoothing of top and bottom of the image of the wide-screen movies (like 2:35:1 cinema frame format) for playback at the TV-formatted 16:9 displays. Without smoothing we got some distraction of too sharp top and bottom edges of the frame if display's scaler do not provide service of some top+bottom image smoothing. Also the designer of the content may adjust smoothing to match internal image sharpness/look/makeup more precisely in comparison with some average image edges smoothing at playback device. 2 methods possible:

1. Add some new borders to the frame to save max useful samples but somehow increase frame size:
AddBorders(0,2,0,2,r=2, ... possible filter params to match image sharpness/look/makeup better)

2. Add internal small transient to black to top and bottom parts of frame. It more degrades original frame content but keep frame size unchanged:
LetterBox(2,2,0,0,r=2, ... possible filter params to match image sharpness/look/makeup better)

Example with wide-screen cinematic movie playback on 16:9 display:
https://i.postimg.cc/wBbywTND/2025-03-15-224240.png

Same applicable to left and right frame borders if adapt 4:3 old content to new 16:9 displays.

[Z2697]

Due to mirrored outside pixels perhaps?

[DTL]

Testing of padded-AVS+ resize vs avsresize and fmtconv with internal edge handling:

LoadPlugin("avsresize.dll")
LoadPlugin("fmtconv.dll")

Function Padded2xLanczosResize(clip c, int pad)
{
padded=AddBorders(c,pad,pad,pad,pad, r=0)
res_2x=LanczosResize(padded, padded.width*2, padded.height*2, taps=16)
return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

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)

avs_p=Padded2xLanczosResize(last, pad).Subtitle("AVS+ Padded2xLanczosResize taps=16", align=5)
avsr=z_ConvertFormat(width=width*2, height=height*2, resample_filter="lanczos", filter_param_a=16).Subtitle("avsresize lanczosResize taps=16", align=5)
fmtconv=fmtc_resample(w=width*2, h=height*2, kernel="lanczos", taps=16).Subtitle("fmt_conv lanczosResize taps=16", align=5)

d1 = Diff(avs_p,std)
#d2 = Diff(avs_p,avsr)
d2 = Diff(avsr,fmtconv)
d3 = Diff(avs_p,fmtconv)

StackHorizontal(StackVertical(std, avs_p, avsr), Stackvertical(d1, d2, d3))



https://i.postimg.cc/zG19rVfs/image-2025-03-16-225303187.png

The avsresize vs fmtconv is about equal (with about 1LSB difference at some corner samples) but all slightly different from 'padded resize'. The worst at r4246 is unpadded AVS+ (std) resize.

The padded versions of both avsresize and fmtconv also make some different outputs in comparison with unpadded resize by same engines. So different edges conditions handling workarounds (in different resize engines) gives still different results (vs padded method). It looks changing of kernel of resize filter in the 'resampling program' for handling edge conditions is not perfect way (but may give best performance because resampler process lowest data size).


LoadPlugin("avsresize.dll")
LoadPlugin("fmtconv.dll")

Function Padded2xLanczosResize(clip c, int pad)
{
padded=AddBorders(c,pad,pad,pad,pad, r=0)
res_2x=LanczosResize(padded, padded.width*2, padded.height*2, taps=16)
return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

Function Padded2xLanczosResizeAVSR(clip c, int pad)
{
padded=AddBorders(c,pad,pad,pad,pad, r=0)
res_2x=z_ConvertFormat(padded, width=padded.width*2, height=padded.height*2, resample_filter="lanczos", filter_param_a=16)
return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

Function Padded2xLanczosResizeFMTC(clip c, int pad)
{
padded=AddBorders(c,pad,pad,pad,pad, r=0)
res_2x=fmtc_resample(padded, w=padded.width*2, h=padded.height*2, kernel="lanczos", taps=16)
return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}


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)

avs_p=Padded2xLanczosResize(last, pad).Subtitle("AVS+ Padded2xLanczosResize taps=16", align=5)
avsr_p=Padded2xLanczosResizeAVSR(last, pad).Subtitle("avsresize Padded2xLanczosResize taps=16", align=5)
fmtc_p=Padded2xLanczosResizeFMTC(last, pad).Subtitle("FMTC Padded2xLanczosResize taps=16", align=5).ConvertBits(8)
avsr=z_ConvertFormat(width=width*2, height=height*2, resample_filter="lanczos", filter_param_a=16).Subtitle("avsresize lanczosResize taps=16", align=5)
fmtconv=fmtc_resample(w=width*2, h=height*2, kernel="lanczos", taps=16).Subtitle("fmt_conv lanczosResize taps=16", align=5)

d1 = Diff(avs_p,std)
#d2 = Diff(avs_p,avsr)
#d2 = Diff(avsr,fmtconv)
#d2 = Diff(avsr,avs_p)
#d3 = Diff(avs_p,fmtconv)

d2 = Diff(avsr,avsr_p)
d3 = Diff(fmtconv, fmtc_p)


StackHorizontal(StackVertical(std, avs_p, avsr), Stackvertical(d1, d2, d3))

[pinterf]

AviSynth plus 3.7.3 r4269

Topic of last wek: resizers.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4269

memory overread fix - heavy refactor/rewrite in almost all resizers (C/SSEx/AVX2 x 8/10-16/32bit x Horizontal/Vertical)
no more size limit ("image height is too small for this resizing method" errors are gone)
Fix artifacts on boundaries.
respect chroma location (fixes chroma shift on downsize with non-centered chroma locations)
new placement and keep_center parameters
C-only version a bit more vectorizable by smart compilers

and many fixes and additions to the documentation.


Visit our online docs for

Change list:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html

Resize filters:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html

[tormento]

Topic of last wek: resizers.
Could you consider adding the dithering methods included in fmtconv?

I find them useful, such as mode 8 that gives pleasant result and is resilient to compression.

[Jamaika]

Does LWLibavAudioSource work with the added fixes for avisynth f7b5954?

[DTL]

"Fix artifacts on boundaries."

It is also important addition to the Bugfixes section of https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html

[Z2697]

Could you consider adding the dithering methods included in fmtconv?

I find them useful, such as mode 8 that gives pleasant result and is resilient to compression.

why not just use fmtconv?

[pinterf]

Could you consider adding the dithering methods included in fmtconv?

I find them useful, such as mode 8 that gives pleasant result and is resilient to compression.
No :)

[tormento]

why not just use fmtconv?
As it's slow compared to other resizers/ditherer, at least on my machine.

[qyot27]

AviSynth+ 3.7.4 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.4) Full changelog on the Github release page. The macOS installer will come later.

New to this release is a full installer for Windows on ARM, so any of you with Snapdragon X Elite laptops (or maybe even one of those Ampere workstations) can use a native build instead of running it through the x64 emulation layer.

[DTL]

It is good. Next step to the nice future of digital moving pictures in 3.7.4-postXX is precise (float) control of placement of transient (its center of 0.5 level) in both AddBorders and LetterBox. Will try to prepare some simple script-based simulation how it can work.

So that finally we can run Animate(LetterBox()) with smooth slow-motion of the border in or out at any speed (from 0.000+ samples/frame). In current version we can have only integer control of placement and even worse - for 4:2:0 formats its granularity is 2.0. So with 4:4:4 formats animation can run, but the placement is only integer positions and jumps.

The real valuable use case of the float-precision control of the position of the transient is better quality of the very thin borders added. Currently AddBodrers or LetterBox(2,r=2) can not be precisely fine tuned (like we want something about LetterBox(2.5..2.8, r=2.8)) and for 4:2:0 formats next working is (4,r=4) that is too large step. When we make transient full-blooded Digital Motion Picture Object we can place it at any position (float-addessed) without distortion and in any chroma-subsampled format. As we have with any other objects in real digital moving pictures.

In 3.7.4 generation of good conditioned transients is working, but limited to integer positions placement only.

[pinterf]

AviSynth+ 3.7.4 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.4) Full changelog on the Github release page. The macOS installer will come later.

New to this release is a full installer for Windows on ARM, so any of you with Snapdragon X Elite laptops (or maybe even one of those Ampere workstations) can use a native build instead of running it through the x64 emulation layer.
Thanks to qyot27 for putting together this long-awaited release.

And much appreciated to everyone who shared ideas, requests, and bug reports, you’ve been a huge help!

If you want to talk more about this release, check out the discussion on GitHub:
https://github.com/AviSynth/AviSynthPlus/discussions/432

Additionally, here are some statistics showcasing our download count.


Avisynth 3.7.4 released 20250324
(first 10/48 hours)

61/159 AviSynthPlus_3.7.4_20250324-filesonly.7z
243/1075 AviSynthPlus_3.7.4_20250324.exe
14/46 AviSynthPlus_3.7.4_20250324_arm64.exe
58/163 AviSynthPlus_3.7.4_20250324_vcredist.exe
24/54 AviSynthPlus_3.7.4_20250324_xp.exe
21/44 AviSynthPlus_3.7.4_20250324_xp_vcredist.exe

Avisynth 3.7.3 released 2023.07.06 21 months before 3.7.4

10805 AviSynthPlus_3.7.3_20230715-filesonly.7z
56689 AviSynthPlus_3.7.3_20230715.exe
2024 AviSynthPlus_3.7.3_20230715_macOS_10.15+_x64-filesonly.tar.xz
2360 AviSynthPlus_3.7.3_20230715_macOS_10.15+_x64.pkg
1924 AviSynthPlus_3.7.3_20230715_macOS_11.0+_arm64-filesonly.tar.xz
2501 AviSynthPlus_3.7.3_20230715_macOS_11.0+_arm64.pkg
22942 AviSynthPlus_3.7.3_20230715_vcredist.exe
2771 AviSynthPlus_3.7.3_20230715_vcredist_xp.exe
2801 AviSynthPlus_3.7.3_20230715_xp.exe

Avisynth 3.7.2 released 2022.03.18, 16 months before 3.7.3

15910 AviSynthPlus_3.7.2_20220317-filesonly.7z
65920 AviSynthPlus_3.7.2_20220317.exe
7277 AviSynthPlus_3.7.2_20220317_macOS_10.13_._10.14-filesonly.tar.xz
7441 AviSynthPlus_3.7.2_20220317_macOS_10.13_._10.14_x64.pkg
7263 AviSynthPlus_3.7.2_20220317_macOS_10.15+_x64-filesonly.tar.xz
7316 AviSynthPlus_3.7.2_20220317_macOS_10.15+_x64.pkg
7215 AviSynthPlus_3.7.2_20220317_macOS_11.0+_M1-filesonly.tar.xz
7558 AviSynthPlus_3.7.2_20220317_macOS_11.0+_M1.pkg
18785 AviSynthPlus_3.7.2_20220317_vcredist.exe
8332 AviSynthPlus_3.7.2_20220317_vcredist_xp.exe
2994 AviSynthPlus_3.7.2_20220317_xp.exe

[DTL]

Here is script-based example of LetterBox with float placement of the new border (only left for example to make it more short):

Function LetterBoxLeftFloatP(clip c, float left, int flt_rad)
{
left_int=Int(left)
pad=1
l_padded=AddBorders(c,pad, 0,0,0)
unflt=LetterBox(l_padded, 0, 0, x1=left_int+pad)
frac=Frac(left)
flt=GaussResize(unflt, unflt.width, unflt.height, p=8, b=2.71828, s=0, force=1, src_left=(0.0-frac))
uf_internal=Crop(l_padded, left_int+flt_rad+pad, 0, l_padded.width-(left_int+flt_rad+pad), l_padded.height)
proc_padded=Overlay(flt, uf_internal, x=left_int+flt_rad+pad, y=0)
return Crop(proc_padded,pad,0,0,0).SubTitle(Format("left={left}"))
}

BlankClip(10000, 200, 200, color=$7F7F7F, pixel_type="YV24")

Animate(last, 0, 10000, "LetterBoxLeftFloatP",\
-0.5, 3,\
Float(last.width/2), 3)

LanczosResize(width*2, height*2, taps=16)


It even support such strange left coordinate like -0.5 (possibly lowest valid is -0.99) to move the new border completely out of the frame (for given flt_rad and filter kernel setup). But in the range of 0.0 to about 1.2 the balancing part of the transient still cropped out and it still shows some ringing (though still significantly less in comparison with old hard transient LettelBox(x1=1)). It looks with such simple method it is unavoidable (or special case for coordinates size < about 1.2 is required (changing filter kernel and possibly flt_rad to larger blurring).

"here are some statistics showcasing our download count."

15910 AviSynthPlus_3.7.2_20220317-filesonly.7z
65920 AviSynthPlus_3.7.2_20220317.exe

10805 AviSynthPlus_3.7.3_20230715-filesonly.7z
56689 AviSynthPlus_3.7.3_20230715.exe

This also confirm somehow sad idea: To the end of each civilization we have best designed tools with all fixes and requirements implemented (like software too) but no one need it anymore. 1 year (0.01 of a century) step at 202x shows decreasing in download rate at about 10 to 50% at different packages.

[Stereodude]

Are there some sort of language/character set dependencies in AVIsynth+ that are set by the application opening the .avs file?

I had a .avs that VirtualDub 2.2.0.755 could open without any issue. It would display a correct image with the correct number of frames just like any other .avs, but a jpsdr build of x265 (version 4.1.0.054+45+15-b8ba3fe87 [Mod by JPSDR using mod by Patman]) could not open the .avs from a cmd window in Windows 10 22H2. I got this message on the console:
avs+ [INFO]: AviSynth+ 3.7.3 (r4003, 3.7, x86_64)
avs+ [FLAW]: Error loading file: DGSource: Could not open one of the input files.
Check that the input files listed at the top of the DGI file actually exist.
This can happen after making an index and then moving the source file(s).

If you want to have your Avisynth script and your source file(s) in different directories,
then you must enable the Use Full Paths option in the DGIndexNV settings before saving your project.
Alternatively, you can edit the DGI file to add the full paths, in which case re-indexing is not required.
The script had:
DGSource("video.dgi").crop(0,20,-0,-20)
video.dgi file (name obscured for anonymity):
DGAVCIndexFileNV25 DGIndexNV 255.0.0.0 X64
C:\HDTV Tools\DGDecNV\

C:\Temp\BD\____é____...
The file being opened by DGDecNV had an é in the filename. I had to rename the source file changing the é to an e and then change the filename in the .dgi the same way and then x265 could open the .avs file. :confused:

I'm totally confused why one program could open the .avs and the other returned an error. This is the first time I've seen this.

[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 ?

[qyot27]

Are there some sort of language/character set dependencies in AVIsynth+ that are set by the application opening the .avs file?

I had a .avs that VirtualDub 2.2.0.755 could open without any issue. It would display a correct image with the correct number of frames just like any other .avs, but a jpsdr build of x265 (version 4.1.0.054+45+15-b8ba3fe87 [Mod by JPSDR using mod by Patman]) could not open the .avs from a cmd window in Windows 10 22H2. I got this message on the console:
avs+ [INFO]: AviSynth+ 3.7.3 (r4003, 3.7, x86_64)
avs+ [FLAW]: Error loading file: DGSource: Could not open one of the input files.
Check that the input files listed at the top of the DGI file actually exist.
This can happen after making an index and then moving the source file(s).

If you want to have your Avisynth script and your source file(s) in different directories,
then you must enable the Use Full Paths option in the DGIndexNV settings before saving your project.
Alternatively, you can edit the DGI file to add the full paths, in which case re-indexing is not required.
The script had:
DGSource("video.dgi").crop(0,20,-0,-20)
video.dgi file (name obscured for anonymity):
DGAVCIndexFileNV25 DGIndexNV 255.0.0.0 X64
C:\HDTV Tools\DGDecNV\

C:\Temp\BD\____é____...
The file being opened by DGDecNV had an é in the filename. I had to rename the source file changing the é to an e and then change the filename in the .dgi the same way and then x265 could open the .avs file. :confused:

I'm totally confused why one program could open the .avs and the other returned an error. This is the first time I've seen this.
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.

[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]

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 :confused:

[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 (https://github.com/pinterf/AviSynthPlus/releases) 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-9970X]

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]

AviSynth+ 3.7.4 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.4) 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]

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.

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]

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]

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]

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]

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]

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]

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)...:confused:
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)...:confused:
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/AviSynthPlus/blob/master/plugins/CMakeLists.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.

[jpsdr]

Quick question about new resamplers : if using default settings for new parameters/features, is the output identical to previous version ?
=> Or said otherwise, is the result of same script/same video with 3.7.3 and with 3.7.4 identical ?

EDIT:
Tried i386 but didn't solve the issue, but removing the processor check solved it... :D
I thought it could be a cmake issue, so i tested 3.31.[6 to 2] versions and also 3.30.8, but issue was the same.

[DTL]

"if using default settings for new parameters/features, is the output identical to previous version ?"

Expected no. At least with some kernels/sources combinations. The edges issues were solved so result is now different at least at the edges of frame (at distance about filter_support from edge samples). See example - https://forum.doom9.org/showthread.php?p=2016395#post2016395

Center area of the frame may be identical. Though at some ways of computing (SSE ?) pinterf also noted about skipping old lower precision SIMD method (with integer 8 and 16 bit samples formats ?). And even center area of the frame may have different result. Expected higher precision.

https://github.com/AviSynth/AviSynthPlus/issues/431#issuecomment-2733718649 -
significant code simplification is in progress (finally!) by dropping some SSSE3 and SSE4.1 8-bit resizer variants, which sacrificed accuracy for a slightly quicker mulhrs. I believe this was a mid-2000s hack. I retained SSE2, which is correct. Similarly, the AVX2 version was rewritten to avoid using mulhrs. I came across these while looking into the old resizer sources.

[pinterf]

Thanks, DTL, for summarizing the changes that jpsdr would meet. So, no, the results of 8-bit resamplers would not be bit identical. At other bit depths, I believe nothing has changed (except for the edge handling; you can surely expect differences there). Chroma results would also be different unless you specify the placement as "center" manually.

[hello_hello]

According to Compare() the output of A and B are not identical, so I assume the placement argument is being honoured, but in both cases the chroma placement in frame properties after resizing is 3 (YV12 source). Likewise when there's no chroma location in frame properties, no chroma location is written.

propSet("_ChromaLocation", 3)
A = GaussResize(width/2, height/2)
B = GaussResize(width/2, height/2, placement="bottom")

It'd be nice if one day the resizers could also have a placementOut argument too :)

[hello_hello]

pinterf,

I don't know if you saw my post a couple of pages back, but is there a way to force the VarExist argument to only accept a variable as a string, even if the variable itself is a string? For consistency the following should output something like "invalid arguments to VarExist", but instead it returns false:
X = "Y"
VarExist(X)

This would return "invalid arguments to VarExist" as expected:
X = 4
VarExist(X)

Similarly, the defined() function probably shouldn't return true for a string.
X = undefined()
defined("X")

Cheers.

One last question.... is there a reason why the subtitle function has to require a value for the LSP argument in order to output multiple lines? I know it's always been that way, but is there a reason why this shouldn't just output multiple lines?

Subtitle("X\nY\nZ")

[Gavino]

For consistency the following should output something like "invalid arguments to VarExist", but instead it returns false:
X = "Y"
VarExist(X)
I think you are getting confused between variable names and variable values.
VarExist(X) will pass the value of X, namely the string "Y", into the function.
Now, the argument passed to VarExist() is expected to be a string whose value is interpreted as a name, and it will check if a variable of that name exists.
So the output of false is correct (assuming there is no variable Y).
Similarly, the defined() function probably shouldn't return true for a string.
X = undefined()
defined("X")
On the other hand, defined() tests whether the actual value passed in is not equal to undefined(), so this is also correct.
(The variable X is not used here.)

[jpsdr]

I forgot the edges... Thanks for the answers.

[hello_hello]

I think you are getting confused between variable names and variable values.
VarExist(X) will pass the value of X, namely the string "Y", into the function.

I do understand the way it works, but to my way of thinking, ideally this would return true if X exists and false if it doesn't, and VarExist would never output an "I don't know what X means" error.

VarExist(X)

Maybe the variable has to be specified as a string for technical reasons, and I assume it'd be impractical to change it at this stage anyway.

[StainlessS]

HH, Well, if X dont exist, then error would be produced even before VarExist() would be called.
[when the arguement to VarExist is being evaluated by the script parser].

VarExist(), needs to know the name of the variable to see if it exists, not the value of an existing variable,
ie VarExist("Pi") not VarExist(3.1415926)
{
VarExist() scans the variable name table looking for the variable name entry, if it finds it then it exists, if not then it dont exist.
The Local name table is scanned first and if not found then the Global name table. <Local vars hide Global vars>
}

An existing variable can be Undefined [exists but not set to anything], but a non existing variable is not even Undefined, it dont exist at all.
An existing variable can have a type eg Undefined, Clip, String, Float, Int etc, and also value if the type is not Undefined.

EDIT: Inside a script function, an optional arg always exists (is declared as an optional arg to the function),
but if the arg is not provided by the calling code, then it is undefined.

Inside a script function, can use Defined(OptionalArgName) to test if was supplied by script function caller [and was not supplied as eg OptionalArgName=undefined].
Inside a script function, the Default() function eg OptionalArgName = Default(OptionalArgName,OptionalArgDefaultValue) could be implemented like

OptionalArgName = defined(OptionalArgName) ? OptionalArgName : OptionalArgDefaultValue

but external to a script function you would need to also test if a variable exists before can test if defined [unless you know for sure that it exists].

[jpsdr]

Hi.

I have an issue when i try to build soundtouch.

I have Visual Studio 2019 Update 9.26 installed with clang-llvm built option, but i don't install LLVM provided with VS, instead, i install the last LLVM version provided on the github.
When i want to build with LLVM, in the general settings i choose "LLVM-clang" instead of "Visual Studio".
It always worked with everything i tried on until now (x265, avisynth, DirectShow Source, any of my projects).
But when i tried with soundtouch, it builds with "Visual Studio", but when switched to "LLVM-clang", i have the following error (i've translated some parts):

2>------ Start of generation : Project : SoundTouch, Configuration : Release x64 ------
2>Building Custom Rule C:/PRG/Visual_2010/soundtouch/CMakeLists.txt
2>In file included from <built-in>:488:
2><command line>(6,9): error : macro name must be an identifier
2><command line>(7,9): error : macro name must be an identifier
2>Generation of project "SoundTouch.vcxproj" ended -- FAIL.

Same for soundstretch.
Does someone know by any chance how to fix this :confused:

[StvG]

Hi.

I have an issue when i try to build soundtouch.

I have Visual Studio 2019 Update 9.26 installed with clang-llvm built option, but i don't install LLVM provided with VS, instead, i install the last LLVM version provided on the github.
When i want to build with LLVM, in the general settings i choose "LLVM-clang" instead of "Visual Studio".
It always worked with everything i tried on until now (x265, avisynth, DirectShow Source, any of my projects).
But when i tried with soundtouch, it builds with "Visual Studio", but when switched to "LLVM-clang", i have the following error (i've translated some parts):

2>------ Start of generation : Project : SoundTouch, Configuration : Release x64 ------
2>Building Custom Rule C:/PRG/Visual_2010/soundtouch/CMakeLists.txt
2>In file included from <built-in>:488:
2><command line>(6,9): error : macro name must be an identifier
2><command line>(7,9): error : macro name must be an identifier
2>Generation of project "SoundTouch.vcxproj" ended -- FAIL.

Same for soundstretch.
Does someone know by any chance how to fix this :confused:

What's your cmake command line?

[jpsdr]

Hello.
My cmake command is:
@cd .\soundtouch\Build\x86_Broadwell
G:\CMakex64\bin\cmake -G "Visual Studio 16" -A Win32 ../../../../../Visual_2010/soundtouch -DCMAKE_INSTALL_PREFIX="C:\PRG\Visual_2019\AviSynth\Soundtouch\Install\x86_Broadwell" -DCMAKE_CXX_FLAGS_RELEASE="/sdl- /MP /O2 /Ob2 /Oi /Ot /Oy /GT /GL /GF /GS- /Gy /Qpar /arch:AVX2 /MD"

@cd ..\x64_Broadwell
G:\CMakex64\bin\cmake -G "Visual Studio 16" -A x64 ../../../../../Visual_2010/soundtouch -DCMAKE_INSTALL_PREFIX="C:\PRG\Visual_2019\AviSynth\Soundtouch\Install\x64_Broadwell" -DCMAKE_CXX_FLAGS_RELEASE="/sdl- /MP /O2 /Ob2 /Oi /Ot /Oy /GT /GL /GF /GS- /Gy /Qpar /arch:AVX2 /MD"

pause

[qyot27]

-G "Visual Studio 16 2019" -T LLVM-clang -A x64 and see what errors CMake spits out directly.

[jpsdr]

It fails saying it can't find the llvm-clang tools.
They are installed and they're working when using from VS, otherwise i would never been able to release all my LLVM builds... :D
(Except with soundtouch...).

[StvG]

The toolset probably should be -T llvm instead of -T LLVM-clang.

Also you can try with your original command without the -DCMAKE_CXX_FLAGS_RELEASE="... part.

[jpsdr]

Tried with "llvm", "clang-cl", "llvm-clang-cl", nothing works, always the message saying it can't find the tools.

[StvG]

Did you try:
@cd ..\x64_Broadwell
G:\CMakex64\bin\cmake -G "Visual Studio 16" -A x64 ../../../../../Visual_2010/soundtouch -DCMAKE_INSTALL_PREFIX="C:\PRG\Visual_2019\AviSynth\Soundtouch\Install\x64_Broadwell"

Btw you're running this command from "x64 Native tools...." not from simple cmd, right?

[jpsdr]

The full command which creates the solution, i double-click on the .bat file, so it's the same as running from cmd.
When the .bat file is finished and the solution created, i start Visual Studio, open the solution and finish the configuration/settings i can't do with the CMake/bat file.
And then i build the solution.

But, for the command with "-T", i've also do the same.
I'll try running it from "x64 Native tools...".

EDIT:
No change running from "x64 Native tools...", still saying it can't find the tools.

The only error message i have for now when building with llvm is the one provided post #3307... :(

[wonkey_monkey]

I just had another thought about my inter-filter communication idea which I outlined here (and further up): https://forum.doom9.org/showthread.php?p=2013635

It could also be useful if filters could access their "depth", e.g. so two filters could work out whether they were neighbouring in the chain. It could allow them to avoid unnecessary conversions, for example if you called two filters that knew about each other on an 8-bit clip in succession, the first filter could produce 32-bit float output and leave the downconversion for the second filter (but only if there are no intervening filters that don't understand such negotiations), which would reduce rounding errors. It could similarly help GPU filters decide when writing back to the CPU can (or can't) be avoided.

But maybe such things are best left for the user to make explicit in the script...

[StvG]

EDIT:
No change running from "x64 Native tools...", still saying it can't find the tools.

The only error message i have for now when building with llvm is the one provided post #3307... :(

I again ask - did you try:

@cd ..\x64_Broadwell
G:\CMakex64\bin\cmake -G "Visual Studio 16" -A x64 ../../../../../Visual_2010/soundtouch -DCMAKE_INSTALL_PREFIX="C:\PRG\Visual_2019\AviSynth\Soundtouch\Install\x64_Broadwell"

Then open the solution file, change to clang and try to build.

Your error suggests that some of the options isn't recognized by clang.

Try with default options, if this works, change option by option to see what's the culprit.

[qyot27]

I was able to replicate the problem from the command line directly with CMake a few days ago. Unpack the upstream LLVM somewhere, use https://github.com/zufuliu/llvm-utils to install the extra toolsets into VS2019, set the LLVMInstallDir environment variable to the bin directory where it was installed (only necessary for the latest release because there currently isn't an installer for 20.1.2, just 20.1.1), and invoke CMake using -G "Visual Studio 16 2019" -A x64 -T LLVM_v142.

Configuration completes successfully, msbuild (cmake --build . - the value of --config doesn't matter) fails. Unfortunately, the error message is exactly the same as above. The closest results from searching come from old questions on Stack Overflow that point toward it being a problem in the source code, like this one: https://stackoverflow.com/questions/44989366/macro-names-must-be-identifiers

But since the error message itself doesn't say anything about the actual piece of code that triggers the issue or in which source file, you're left guessing.

[jpsdr]

@StvG
I'm using the same exact options on others CMake stuff (avisynth, x265), and everything works fine.
Anyway, i tried exactly what you've asked, both directly or from "Native tools", the same error message.

@qyot27
I thought it was a CMake stuff file error, but according what you said, it may be something in the code, Visual Studio accept, but llvm less permissive don't ?
I never suspect that, but it's somehow a start... It would be indeed better as you said if the file with the problem was identified... :D

EDIT:
I tried to activate all the warnings in VS, but it didn't allow me to find anything (the fact i didn't see anything doesn't meen there is nothing... ;)).

[StvG]

I was able to replicate the problem from the command line directly with CMake a few days ago. Unpack the upstream LLVM somewhere, use https://github.com/zufuliu/llvm-utils to install the extra toolsets into VS2019, set the LLVMInstallDir environment variable to the bin directory where it was installed (only necessary for the latest release because there currently isn't an installer for 20.1.2, just 20.1.1), and invoke CMake using -G "Visual Studio 16 2019" -A x64 -T LLVM_v142.

Configuration completes successfully, msbuild (cmake --build . - the value of --config doesn't matter) fails. Unfortunately, the error message is exactly the same as above. The closest results from searching come from old questions on Stack Overflow that point toward it being a problem in the source code, like this one: https://stackoverflow.com/questions/44989366/macro-names-must-be-identifiers

But since the error message itself doesn't say anything about the actual piece of code that triggers the issue or in which source file, you're left guessing.

May be both of you (you and @jpsdr) should (since you're using not using VS 2022) to try older llvm versions because I don't have any issues with VS 2022.

Edit: I reproduced it. I had removed this line https://codeberg.org/soundtouch/soundtouch/src/commit/d994965fbbcf0f6ceeed0e72516968130c2912f0/CMakeLists.txt#L10. Removing the line - no issues.

[jpsdr]

Big :thanks:
Now i can build the .lib, and build the avs plugin with llvm. Because of course, building with llvm but using the .lib created with msvc didn't work.
What surprised me, in a good way, is that the .lib provided by Devil SDK worked with both msvc and llvm.

[StvG]

Because of course, building with llvm but using the .lib created with msvc didn't work.

Remove "/GL" when building with msvc and you will not have issues to use this lib when building avs with clang-cl.

[jpsdr]

:thanks: again... ;)
I think the "best" maybe is to be able to build everything with llvm (or the same toolchain for another compiler), but this is good to know.
And this probably answer the fact that i can use the Devil lib with llvm.

[qyot27]

AviSynth+ 3.7.5 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.5) There were some things that required a hotfix (particularly on non-x86 platforms), so the list of changes from 3.7.4->3.7.5 is pretty small.

CMakeLists.txt: if CMAKE_BUILD_TYPE isn't set, use Release
Update build.yml, retire unsupported 20.04, add 24.04
Fix an llvm syntax warning.
rstdoc: update change log
Bump to IF v11.1: Fix AVS_Value 64 bit data member declaration for 64 bit non Intel (X86_X64) systems.
rstdoc: open 3.7.5 change log, add Raspberry pi stuff to posix.
Fix gcc compilation warning
Fix: resizer crash for non-intel (e.g. aarch64), regression in 3.7.4
Fix #434: YtoUV crash, regression since 61d2c9a
Add pkgconf->cmake detection fallback message for SoundTouch
avisynth+_arm64.iss: assorted fixups
plugins/CMakeLists.txt: fix VDubFilter build check
Remove upx.exe from the source tree

[wonkey_monkey]

:thanks:

[amayra]

Why does AVS+ use a file compressor like UPX anyway ?

[qyot27]

AviSynth 2.5/2.6 were UPX-packed, and simply out of inertia some of my early builds of AviSynth+ were as well. But I stopped doing that literally 10 years ago (https://forum.doom9.org/showthread.php?p=1719797#post1719797), and the UPX-packed DevIL.dll that was stored in the source tree was changed to an unpacked one in 2020 because it was a hassle to remember to unpack it before building the installer (and of course, the vendored binaries/libraries don't exist in the source tree now anyway).

[tormento]

Why does AVS+ use a file compressor like UPX anyway ?


You can anyway unpack them.

[pinterf]

Thanks, qyot27.

Recently, I spent about ten times more time on a topic than I was originally inteded to, but it's an interesting one. Since qyot27 released an aarch64 Windows version of Avisynth+ (Arm64, specifically Arm64-v8 or v8.4a?), I thought I'd add Neon intrinsic support. (Think of Arm Neon as similar to SSE2 or AVX2 on Intel.)

I read the Arm documentation, and the intrinsics are logical and easy to understand, so it wouldn't take long to convert existing Avisynth code to Neon. Since this seemed straightforward, I decided to do it using real Neon intrinsics instead of the "header" method, which translates existing Intel SIMD to more or less usable Arm SIMD code.

To test on Arm, I need a cross compiler and a hardware and an OS.

I have an i7-11700 with plenty of processing power and RAM, so I tried installing Win11 under QEMU. Unfortunately, the how-to guides on the Internet were made before Win11 24H2, which closed the infamous TPM2.0 registry cheat method of installation. I went back to a previous Win11 23H2, which I successfully installed under QEMU. However, it was ridiculously slow - remember, this is real emulation - so slow that I couldn't even start a command prompt. By the time the start menu or search box appeared, a timeout occurred, and the menu collapsed back. :) I both had a system and not.

Fortunately, my sons bought a Raspberry Pi 5. One is using it for growing grapefruit seeds and monitoring soil humidity :), while the other is engaged in web development, so I borrowed his Pi5 for my Avisynth needs. Yes, real aarch64 hardware, no emulation, and with quite usable compilation speed. I successfully built ffmpeg and Avisynth 3.7.4 and started some tests.

Soon, some configuration issues were discovered in the build process, which were fixed and clarified in 3.7.5 in the build environment (See qyot27's changes, fixing default Release optimization when e.g. Ninja was used).

First, I decided to make our resampler code in Avisynth - the C version -more compiler-friendly (and finish some optimization tasks that were postponed in the 3.7.4 release). Vectorizing friendly C code means that even from well-written C, a good compiler would generate very quick SIMD instructions. This is what I've been doing in past weeks: modify, test, benchmark. First on Windows, then on Raspberry Pi 5 Arm64.

Now I can say that MSVC is not capable of any optimization on integer values (e.g., 8-16 bit pixel values) from C code. I tried to help MSVC by writing code that would assist it, but in vain. After a week, I reached the point where I don't want to fight anymore; I cannot win the battle against the compiler's limitations and ignorance.

What works in MSVC's own C++ compiler:

What is already written in direct Intel SIMD code.
- 32-bit float arrays. Maybe. Such operations would be realized and compiled into SIMD code.
- Use MSVC when you need to support ancient OSs.

Conclusion: I'd ban Windows MSVC Microsoft compiler builds for today's processors in use cases where we process integer data and no handcrafted SIMD code is not available.

What to use instead? MSVC + clang-cl or LLVM is perfectly fine. Also, Intel ICX, which is LLVM-based as well. gcc on non-Windows is fine as well.

For Intel/AMD64 processor code, LLVM wins over GCC (as of 2025) by seeing the code it generates (Godbolt Compiler Explorer is a great tool!). The GCC compiler is good, but it's not on LLVM's level. LLVM detects and utilizes many more tricks than any of the others, which surprised me.


And now, some benchmarks.

Horizontal resapling code compiler (Win64, SSE2, etc means the max processor level, the compiler can utilize), 8, 10 and 16 bit.
ClangCl: what VS2022 supports out of box
Intel: Intel C++ Compiler 2025 (LLVM 19, I think)
Figures are in FPS(bit depth)


417(8) 463 (10) 360(16) from C, MSVC SSE2 3.7.4
597(8) 631(10) 651(16) from C, Intel SSE4.2 3.7.4
1183(8) 1193(10) 889(16) from C, Intel AVX2 3.7.4

91(8) 83(10) 56(16) from C, MSVC SSE2 3.7.6
477(8) 468(10) 292(16) from C, ClangCl SSE2 3.7.6
429(8) 468(10) 1327(16)(!) from C, Intel SSE2 3.7.6
1734(8) 2545(10) 1580(16) from C, Intel SSE4.2 3.7.6
2173(8) 2620(10) 1804(16) from C, Intel AVX2 3.7.6

3800(8) from SIMD, MSVC AVX2
2870(8) from SIMD, Intel C++ 2025, SSSE3
4370(8) from SIMD, Intel C++ 2025, AVX2



The figures show:
- The C code can be written so as a good compiler can turn it easily to SIMD code.
- MSVC own compiler: no comment
- When the compiler can utilize a more modern processor instruction set (like we build it for "native" arch), speed benefits a lot.

[DTL]

It is also good to test with different frame sizes (relative to typical CPU cache size of about 2..20 MBytes ?) and multiplied to threads number as we have frame-based multithreading in current AVS+. Like with 3 different frame size:

1. Very small - buffer size much less of 2 MBytes.
2. Medium - buffer size is about 2..8 MBytes.
3. Big - buffer size is significantly more of 2..8 MBytes.

Also as current resizer is dual-1D it is good to test H+V changing of frame size (like 2x width and 2x height). Big enough number of tests may be required.

Most benefit of the 'good from-C' compiler expected on poorly SIMD-optimized parts of software as we have less and less human resources for SIMD optimizing and expected AI compilers may still helps somehow.

[wonkey_monkey]

What (if anything) is considered the correct way to ask a user for a colourspace as a filter parameter? Expect a string and convert with ColorSpaceNameToPixelType (or it's C++ equivalent)?

Could/should pixel type numbers be exposed as script function constants?

PS Has something happened to AVSMap recently? I was trying to compile my program after installing 3.7.5 and it was giving me unresolved external errors (I think, might have something different, but it was definitely linking-related), but a rebuild seem to fix it.

[qyot27]

Getting the macOS builds ready for 3.7.4 stalled so long (as a side effect of my access to an Intel version of macOS not working too well this time around, and waffling about where to draw the cutoff for the minimum OS version) that 3.7.5 ended up getting released first. It's probably just as well, since that ARM64 resizer issue that got fixed in 3.7.5 probably also affected macOS.

But I just fixed that issue by uploading the macOS build for 3.7.5. Unlike previous installers for macOS, this time, we have a Universal Binary, so there aren't separate installers for Intel vs. Apple Silicon. The minimum OS version is also set to macOS 13 Ventura, as that is the oldest version still supported by Apple. While it does limit the range of Intel Macs that can be installed to, there is always OpenCore-Legacy-Patcher or you could still build the binaries yourself (and given the differences introduced in 10.15 Catalina, if you're using anything older than that, you'd probably be better served by building it yourself). Unless something drastic has regressed lately, it's still possible to build AviSynth+ for Tiger (10.4) and Leopard (10.5) on PowerPC if you have the patience to let Tigerbrew compile much newer versions of the build tools (CMake, GCC, etc.), so...

Also, between having to disable Gatekeeper to run stuff that isn't code-signed on Apple Silicon (unless, like I mentioned above, you built it yourself) and the shift toward using RPATH shenanigans, the optimal long-term solution for native macOS support for AviSynth+ as well as client applications that use it will be for a package to get added to MacPorts and Homebrew, as they can deal with that weirdness without the user necessarily having to worry about it.

[PoeBear]

Is there a world where the comment and the backslash system could co-exist, similar to the "bug report"/non-working example from the documentation (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_the_full_grammar.html)?

ColorBars
ShowFrameNumber
Trim(0,9) # select some frames \
+ Trim(20,29)

I often do similar backslash uses when working with multiple Trims, often from multiple sources. Sometimes it's nice to throw in a comment on each Trim to remind myself why its switching sources. Currently, if I really need a comment, I have to section the Trims it into different clips, then merge them, eg:

ColorBars
ShowFrameNumber
scene1=last.Trim(0,9) #main color footage
scene2=last.Trim(20,21).Grayscale() #black and white scene, remote chroma
scene3=last.Trim(20,29) #back to main color footage
scene1+scene2+scene3

which can get tedious if there's a lot of clips. A long project with multiple sources can get into the many dozens. The more clips, the more chance to get confused by all the Trims and why they exist lol. Would love some 3rd type of comment that is lower precedence than the backslash. It would keep scripts shorter/cleaner, and help when working in the middle of the footage, eg inserting a new Trim without renaming each of the following clips

[wonkey_monkey]

Is there a world where the comment and the backslash system could co-exist, similar to the "bug report"/non-working example from the documentation (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_the_full_grammar.html)?

Can I interest you in ShebangMod (https://forum.doom9.org/showthread.php?p=1967744) and the associated ScriptMonkey plugin? Because I couldn't interest anyone else :D You can put comments wherever you like and you might not even need backslashes. I can't remember if it allows chaining to cross lines but I can look into adding that.

The current version is forked from AviSynth 3.7.2 but I can compile it again, or you can apply the small changes yourself to the latest source code.

[Gavino]

Is there a world where the comment and the backslash system could co-exist, similar to the "bug report"/non-working example from the documentation (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_the_full_grammar.html)?
Yes, just use the alternative comment form /* ... */, so the non-working example becomes the working:
ColorBars
ShowFrameNumber
Trim(0,9) /* select some frames */ \
+ Trim(20,29)

[qyot27]

Even though Gavino beat me to it, I have another point to make:

Is there a world where the comment and the backslash system could co-exist, similar to the "bug report"/non-working example from the documentation (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_the_full_grammar.html)?



I often do similar backslash uses when working with multiple Trims, often from multiple sources. Sometimes it's nice to throw in a comment on each Trim to remind myself why its switching sources. Currently, if I really need a comment, I have to section the Trims it into different clips, then merge them, eg:



which can get tedious if there's a lot of clips. A long project with multiple sources can get into the many dozens. The more clips, the more chance to get confused by all the Trims and why they exist lol. Would love some 3rd type of comment that is lower precedence than the backslash. It would keep scripts shorter/cleaner, and help when working in the middle of the footage, eg inserting a new Trim without renaming each of the following clips

# isn't the only comment type in AviSynth. C-style comments /* */ are also valid (as well as [* *] for nested comments), and do work in the above example, and in other contexts¹. Essentially, # works like C++-style // comments, and the issue to me seems less about the backslash than it is about how implicit last works when using the splice shorthand syntax. The way others got around it (as per the examples in the Github issue and the old forum posts) was by putting the backslash at the start of the second line, rather than at the end of the first.

¹Like commenting out a line when initializing an array variable that spans multiple lines. # fails entirely for this, you have to use /**/, and don't include the backslash in the comment.

The bug report the documentation mentions seems to have originated here:
https://github.com/AviSynth/AviSynthPlus/issues/6
which links back to
https://forum.doom9.org/showthread.php?p=1651141#post1651141
and
https://forum.doom9.org/showpost.php?p=1653525&postcount=293



The more concerning thing that I can see here is that there is something clearly wrong about the Trim operation in that example:
ColorBars
ShowFrameNumber
Trim(0,9) # select some frames \
+ Trim(20,29)
As copied directly from the documentation, this produces 1 frame.
avs2yuv -raw test.avs -o /dev/null
Warning: output will not contain any headers!
You will have to point resolution, framerate and format (and duration) manually to your reading software.
Avs2YUV 0.30
Script file: test.avs
Resolution: 640x480
Frames per sec: 30000/1001 (29.970)
Total frames: 1
Progress Frames FPS Elapsed Remain
[ 0.0%] 0/1 0.00 0:00:00 0:00:00
Started: Wed Apr 30 13:13:52 2025
Finished: Wed Apr 30 13:13:52 2025
Elapsed: 0:00:00
while
ColorBars
ShowFrameNumber
Trim(0,9) /* select some frames */ \
+ Trim(20,29)
produces 20, as the Trim commands would imply:
$ avs2yuv -raw test.avs -o /dev/null
Warning: output will not contain any headers!
You will have to point resolution, framerate and format (and duration) manually to your reading software.
Avs2YUV 0.30
Script file: test.avs
Resolution: 640x480
Frames per sec: 30000/1001 (29.970)
Total frames: 20
Progress Frames FPS Elapsed Remain
[ 95.0%] 19/20 1900.00 0:00:00 0:00:00
Started: Wed Apr 30 13:15:41 2025
Finished: Wed Apr 30 13:15:41 2025
Elapsed: 0:00:00

The implicit last is being set to *something*, and the Trim(20,29) command is appending to it, but it's all getting trashed down to a single frame if the backslash before the splice is commented out by a #. The documentation says that it's not returning [0..9,20..29], which is correct, but it's also not returning either one of [0..9] or [20..29] (or [20..29] appended to...whatever last was set to).



Secondarily, and going back to the point I made above about the arrays, is there any reason why the multi-line syntax needs to work the way it does when enclosed by any of the grouping syntax elements?

It's been a while, but I don't recall whether the {} in the function syntax require backslashes to allow lines to be spanned, because function definitions work more like C than typical script, and you'd only need the multi-line spanning in a case where the command inside the function would normally need it, but not the function as a whole.

And again, if you're initializing an array, I don't see why we'd need backslashes between the [] if it's just counting elements between those two characters. Is there some alternate use of these things that means that usage is ambiguous and multi-line span with backslash *needs* to still apply to them?

[wonkey_monkey]

Implicit last in this case is, I think, Trim(0,9). I would guess that "+" is inventing its own 0-frame clip for the LHS (based on the RHS?), since that is empty, then trim(20,29) acts on implicit last ("Trim(0,9)") - but since implicit last doesn't have frames 20-29, it just returns the last frame of it, which is frame 9.

Edit: actually it probably makes more sense that the "+" is just nulling itself in parsing: [null] + x => x

[qyot27]

Edit: actually it probably makes more sense that the "+" is just nulling itself in parsing: [null] + x => x
That does seem to be exactly what it's doing, which is leading to Trim(20,29) returning frame 9 instead. I don't think that's* expected behavior, but I could be wrong.

*Trimming a frame range that doesn't exist, I mean. -1 obviously has a special meaning, but a positive range that lies outside the valid already-trimmed range? Or was this the same thing that people complained about last time because it was an anti-feature they relied on?



So I guess here's a different question: within the parser, are comments removed first (as a sort of dead code elimination, the way a compiler would do it) before being executed? And if it does, and you comment a line, is the line blanked, or is it removed? Meaning: the newline is collapsed so that when you comment out line 2, does line 3 become line 2 or does it stay line 3 and line 2 still exists but empty? Practical experience seems to point toward the latter, since you can't comment out a line in the middle of a multi-line array initializer, even though most people would think it should collapse and be treated as if the line was deleted entirely.

[wonkey_monkey]

Well you can't do this:

ColorBars(\
width = 1024,\
/* asduhsd */
height = 1280)

or

ColorBars(\
width = 1024,\
# asduhsd
height = 1280)

So it seems it doesn't remove newlines near comments.

I would say AviSynth syntax is a tad outdated, hence my efforts to get around its limitations with ShebangMod. Just changing it outright would be too disruptive, especially when you've got things like ScriptClip to take into account, but an opt-in with a special header line seems like a good way to go (e.g. "#!AviSynth4"). Perhaps one simple modernisation could be "If you encounter a parsing error due to a newline, remove the newline and try again"?

Though that wouldn't help in the + Trim case above...

In Javascript you can do:

x = 6
+4
alert(x)


and it will alert "10". So maybe that works the opposite way - if you get a parsing error, assume an end of statement and try again. You can also force and end of statement with ";" of course, so:

x = 6;
+4
alert(x)


comes back as "6".

[Gavino]

That does seem to be exactly what it's doing, which is leading to Trim(20,29) returning frame 9 instead. I don't think that's* expected behavior, but I could be wrong.

*Trimming a frame range that doesn't exist, I mean. -1 obviously has a special meaning, but a positive range that lies outside the valid already-trimmed range? Or was this the same thing that people complained about last time because it was an anti-feature they relied on?

So I guess here's a different question: within the parser, are comments removed first (as a sort of dead code elimination, the way a compiler would do it) before being executed? And if it does, and you comment a line, is the line blanked, or is it removed? Meaning: the newline is collapsed so that when you comment out line 2, does line 3 become line 2 or does it stay line 3 and line 2 still exists but empty? Practical experience seems to point toward the latter, since you can't comment out a line in the middle of a multi-line array initializer, even though most people would think it should collapse and be treated as if the line was deleted entirely.
Yes, a unary '+' is simply treated as a null-op (even when applied to a clip, which doesn't make much sense).

And Trim clamps its frame arguments to the frame range of the source clip, so +Trim(20,29) applied to a 10-frame clip becomes, in effect, Trim(9,9).

Commenting out an entire line does not make the line disappear, since the new line at its end is not part of the comment!
(unless of course it's inside a block comment that has not yet been closed and thus extends onto the next line...)

[DTL]

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

[tebasuna51]

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]

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]

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]

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 (https://github.com/mstorsjo/llvm-mingw/issues/475) 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/AviSynthPlus/pull/440#issuecomment-2868872022

[Selur]

As a side note: It really is annoying that sometimes default plugins are in plugins/plugins+/plugins64/plugins64+ when using files_only.
(I ended up loading those plugins manually from a separate folder, to not having to check where the plugins are located on the release.)
=> I'm fine, but not to confuse others, maybe just stick with 'plugins' and that's it.

[LigH]

Maybe a function that accepts a file name only and looks in the two folders of the matching bitness on its own?

[tormento]

Is there any good samaritan to build AVS+ version of DFTTest2 (https://github.com/AmusementClub/vs-dfttest2)?

I've asked WolframRhodium who kindly refused.

Wouldn't be so bad to have a GPU accelerated version of DFTTest.

@pinterf? @anyone?

Thanks for any effort.

[qyot27]

As a side note: It really is annoying that sometimes default plugins are in plugins/plugins+/plugins64/plugins64+ when using files_only.
(I ended up loading those plugins manually from a separate folder, to not having to check where the plugins are located on the release.)
=> I'm fine, but not to confuse others, maybe just stick with 'plugins' and that's it.
I had to go back and check old releases, because I had no idea what this was referring to.

Only 3.5.0 deviates from the norm concerning the plugins[+|64|64+] naming, and given this post (https://forum.doom9.org/showthread.php?p=1902703#post1902703) from shortly after release, it appears that I hadn't prepared a filesonly package for 3.5.0, so it was added after the fact, presumably by pinterf. GitHub seems to have done something to the file timestamps for anything before mid-December 2021, so I can't see exactly when in relation to the release that the 3.5.0 filesonly was uploaded.

All of the other release filesonly archives follow the same pattern, because I just copy the contents of the Output/ directories MSVC creates directly into an AviSynthPlus_VERSION_DATE-filesonly directory, under the relevant build architecture (x64, x64-xp, x86, x86-xp). There have been a couple of times the architecture name differed (3.4.0 used 'amd64' and 'i686', 3.7.0 used a slightly more verbose 'x86-64|-32[_xp]'), but that was it.

arm64 test builds were present in the packages for 3.7.0, 3.7.1, and 3.7.2, but was skipped in 3.7.3, IIRC because it was languishing with virtually zero discussion around it (logical, because it was *only* in the filesonly package and did not have an installer).

arm64 returned in 3.7.4 and 3.7.5 once we actually did introduce an installer, but - as I've mentioned in other posts - part of that mainlining of the WinARM installer was changing how we build for that platform, so the arm64 directory on 3.7.4 and 3.7.5 is laid out completely differently from the earlier test builds.

[VoodooFX]

One script had me scratching my head for half an hour because it was producing unexpected, weird effects, all due to a missing dot...

Why this doesn't produce error, it ignores everything on the line after missing dot and outputs RGB:
BlankClip()
m=BlankClip().trim(0,-1)ConvertToY8
m

This produce error:
m=BlankClip().trim(0,-1)ConvertToY8
m

This outputs Y8:
BlankClip().trim(0,-1)ConvertToY8

[wonkey_monkey]

IIRC, if the parser runs into something that otherwise be unexpected, it assumes it's the start of a new statement.

So your first code is equivalent to:

BlankClip() # implicit last
m=BlankClip().trim(0,-1)
ConvertToY8 # this converts the implicit last cliip
m

The second is equivalent to:

m=BlankClip().trim(0,-1)
ConvertToY8 # no implicit last; error
m

And the third is equivalent to:

BlankClip().trim(0,-1)
ConvertToY8

It also means stuff like the following is valid:

a=1b=2
foo=3bar=10foo
a=1a2a

[FranceBB]

Happy 25th birthday, Avisynth! :D
(May 19th 2000 - May 19th 2025)

https://i.imgur.com/Eky4zyc.jpeg

[Gavino]

IIRC, if the parser runs into something that otherwise be unexpected, it assumes it's the start of a new statement.
That's correct.
To clarify, 'unexpected' here means a character that cannot legally continue the current statement.
It also means stuff like the following is valid:
a=1b=2
foo=3bar=10foo
a=1a2a
That produces the error 'I don't know what "a2a" means'.

[Jamaika]

Has avisynth been permanently removed from ffmpeg?
https://github.com/FFmpeg/FFmpeg/commit/4f7bc62c6644420557d02b3de65b75147eac79ec

[ryrynz]

How is "Move avisynth and dvdvideo under external libraries group" removal exactly?

[Jamaika]

Hmm... Only I was adding statically to ffmpeg and was counting on plugin modifications in this twenty-fifth anniversary. Now it looks like two separate projects.

[LigH]

In my scope you are the only person trying to link AviSynth statically into ffmpeg...

[Jamaika]

In my scope you are the only person trying to link AviSynth statically into ffmpeg...
I am surprised that the l-smash add-on for avisynth is static with ffmpeg
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases/


https://github.com/HomeOfAviSynthPlusEvolution/FFmpeg/tree/c54f59fbc13a57c168e5b7389976b7a4ec60b850
Modified ffmpeg? Probably yes.

[DTL]

Some sad information for Personal Computer users with current AVS+ filters and frame cache design. I asked a question at stackoverflow https://stackoverflow.com/questions/79633556/ the answer is: We still can not use all 32/64bit address space for software design if we need high performance computing. The only usable with best performance is address space of the size of CPU cache. It is only about 10 MBs of 10ths of MBs typically on top consumer CPUs (except Xeon MAX with HBM RAM onboard).

As answers shows - there still no standard way for software to skip data writing to RAM after generation inside the CPU core. (maybe some hacks with cache coherency control still exist ?) . Even if it is temporal data exchange in between AVS filters and no more consumer of this data exists in the future. It is the use case of a simple filter chain (without splitting of output to several consuming filters).

This causes the main performance impact: Each frame in AVS cache has its own virtual address space range. This means total address space used by AVS is much larger than CPU cache size if we process SD frames totally cacheable even with several threads running. If we only have 1 source buffer and 1 dest buffer to process in between all filters in a chain (of unlimited length).

But if each frame buffer of each intermediate frame in AVS+ cache has its own buffer and number of frames is Nxthreads_number for each connection between filters - this causes the total amount of virtual address space used to be much larger than the CPU cache size.

And with cycling processing of all frame buffers CPU produces data for each buffer and stores it first in some levels of fast cache. But production rate may be much higher than the cachelines storage rate to RAM via slow bus. This causes a quick exhausting of free cache lines and total CPU stall doing nothing and waiting for old frames to be downloaded from cache to RAM. CPUs do not have the right to overwrite still not saved to RAM cache lines with different virtual address data. This will cause data loss for later reading from these addresses.

The only legal way to increase performance in such host design - to send overwrite instructions to the same virtual addresses. This will legally update data in cache at the full write cache performance and do not cause CPU stall of the execution. The rest of data may be slowly downloaded into slow host RAM if time slots on the host RAM bus are present. Typically it is temporal data in between filters and no need for anyone more so can be skipped completely after the sink filter reads it all from cache.

This means general ideas to AVS filters and core design:
1. Use in-place transform filter design if possible (non-resizing and non-spatial non-temporal filters like Levels/Tweak/ColorYUV).
2. Stop using many frames cache (make an option for script writers ?) in between chained filters if possible and reuse a low number of allocated buffers (better only 2 buffers - source and dest and reassign at the next filter call for 1 input and 1 output filter or send pointer to trans in place filter). Need to test in debugger what happens if we set Prefetch(N,1) or even Prefetch(N,0) and make a script with a sequence of transform in place filters.
3. Make transform in place copies of filters where possible and instruct the filter manager of AVS core to use these filters with a single virtual address space allocated buffer in all filter chain while possible.

Also if there will be no usable (hacky) solution it looks we need to send request to intel and AMD for new instruction extension at least for SIMD like _mXX_loadu_invd(addr) of simply load data from addr and invalidate cache line with this addr. Though it is easy to do only for cache line aligned loads and if load full cache line only (so usable for AVX512 with 64bytes load and from L1D only with 64 byte cache line size).

I still hope some general solution exists like high-level operation of free(addr) or free_invd(addr) with also invalidating all cachelines containing addresses from memory-allocated area (with page-size granularity of 4KB). Though it may be natural if user of high-level language calls free() all data is now can be skipped and every free() call may also invalidate cache and save CPU from store not yet saved data from that memory region virtual addresses. This performance issue is really OS-design level with memory services to applications. It is strange if there is no solution yet.

[FranceBB]

Can I ask which version of SoundTouch was linked to TimeStretch when it was compiled?
SoundTouch version 2.4.0 was released on April 6th 2025 while Avisynth 3.7.5 was released on Apr 21st 2025, so I expected it to be using that one, however I'm getting some weird results, so I'm worried that version 2.3.3 from March 29th 2024 might have been used instead. It would make sense, given that Avisynth 3.7.5 is just a "tiny" update from Avisynth 3.7.4 which was released on Mar 24th 2025, so before the SoundTouch 2.4.0 official release.
If that's the case, if someone has a bit of time and everything setup already, can you recompile TimeStretch against SoundTouch 2.4.0? Otherwise I'll try to do it when I'm back later next week.

[qyot27]

git-9ef8458d85, HEAD as of 2025-02-27 15:25:09

The only commit after that which makes a difference to current HEAD is the one that was merged literally one week ago, on the 16th.

[pinterf]

Happy 25th birthday, Avisynth! :D
(May 19th 2000 - May 19th 2025)

In case we're still around to read the next round of birthday greetings (50th), we should definitely plan a BBQ somewhere halfway between our homes. Good wine will surely help the celebration—while my grandchildren will probably have to help me get to the party spot. :)

[hello_hello]

Is it by design that when you specify a chroma placement for a resizer and it differs from the chroma location in frame properties, the frame property isn't updated to reflect the chroma placement used for resizing? It's the same for ResampleMT when using the placement argument. For example:

# Frame property chroma = "left"
Spline36Resize(960,540, placement="center")
# Frame property chroma = "left"

Also, I just want to confirm...
As it's not possible to change the chroma location with the Avisynth resizers, is this a legit way to do it (for a YV12 source)?

ConvertToYV12(ChromaInPlacement="top_left", ChromaOutPlacement="center")

[pinterf]

Is it by design that when you specify a chroma placement for a resizer and it differs from the chroma location in frame properties, the frame property isn't updated to reflect the chroma placement used for resizing? It's the same for ResampleMT when using the placement argument.
Yes, by design.

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html

Section:
placement

[v0lt]

I did some tests of Unicode string support.
I use Avisynth+ 3.7.5 and save scripts in UTF-8.

FFVideoSource("Утка_Πάπια_오리.mkv")
It works!
FFVideoSource("Утка_Πάπια_오리.mkv")
Subtitle("Утка_Πάπια_오리")
The text is not displayed correctly.
FFVideoSource("Утка_Πάπια_오리.mkv")
Subtitle("Утка_Πάπια_오리", utf8=true)
Strange, but the Subtitle function, unlike FFVideoSource, requires additional specification of UTF-8 encoding.
MessageClip("Утка_Πάπια_오리")
The text is not displayed correctly. And it seems there is no way to use MessageClip with Unicode strings.

1. Is it possible to make any string parameters interpreted as UTF-8 strings? So that users don't have to write "utf8=true" for UTF-8 scripts.

2. Will the MessageClip function support UTF-8 in the future?

[qyot27]

AviSynth+ (and classic AviSynth, for that matter) are dependent on the system codepage/locale. Some plugins (and with utf8=true, internal functions) allow for converting between UTF8 and other string formats, but it's not automatic. Largely, it's handled outside of AviSynth+:

A) Set the Windows codepage to UTF-8. By far the easiest way to accomplish it, but some users get scared away from the 'Beta' language that the option uses in the config dialog. I can't remember if Win11 changed this to more neutral wording or even enables it by default now.

B) Set the client application to UTF-8 using that app manifest thing, whereby AviSynth(+) should probably inherit the changed locale. AFAIK, libraries can't have those manifests attached to them, only application binaries can. This is not something I've really tested, since I just went with A) about 6 or 7 years ago on Windows 10 and never looked back.


Just relying on the system setting is also why it can happily ingest/display UTF8 characters on all the non-Windows OSes, which all do default to UTF-8 and have for like, the last 20 years or so. Something to point out, though, is that you need to use a font that contains the Unicode characters as well.

On Windows, MessageClip uses Arial, which should then select Arial Unicode and display them (when talking about the system/application being set on UTF8, I mean). Everywhere else, MessageClip defaults to Terminus, which unfortunately does not contain all of the Unicode characters (from the example, it contains just Cyrillic and Greek, but not Hangul - and probably not the other CJK sets either); Subtitle/Text can load external fonts, so you could see it work if you give it GNU Unifont (https://www.unifoundry.com/unifont/index.html), for example. That one has all the glyphs, and it displays correctly for Text(), just with much wider spacing. MessageClip should probably have the font_filename option added to it as well.

This is one reason why there needs to be a Freetype2 backend, as that would allow for using Fontconfig to select TrueType and OpenType fonts that have the full range of glyphs and not be limited to bitmapped fonts with specific sizes.


Local tests below

MessageClip() per example:
https://i.imgur.com/CiOAkwq.png

Text() and Version(), with Text being provided an external BDF font file to provide the correct glyphs:
https://i.imgur.com/XSFuCBd.png

Ditto, but in VirtualDub2:
https://i.imgur.com/LXo6cff.png

[StvG]

Some plugins (and with utf8=true, internal functions) allow for converting between UTF8 and other string formats, but it's not automatic. Largely, it's handled outside of AviSynth+:

But some of the plugins are doing it automatically (e.g., the unofficial ffms2).

[pinterf]

@qyot27

1.) "if you give it GNU Unifont, for example. That one has all the glyphs, and it displays correctly for Text(), just with much wider spacing. MessageClip should probably have the font_filename option added to it as well."
Regarding the wider spacing: I suppose that BDF rendering rule implemention is missing something. I did not implement all features.

EDIT: (reason for visual gap found)
Regarding the wider spacing in Unifont, this is due to how FONTBOUNDINGBOX is interpreted during rendering. In Unifont's BDF header, FONTBOUNDINGBOX is set to 16 pixels wide. This causes all glyphs, regardless of their actual width, to be rendered with 16 pixel spacing in Avisynth's Text() function, resulting in visible gaps for narrower characters. While Unifont is conceptually monospaced, it technically includes variable-width glyphs. Many Latin characters have DWIDTH 8, but others (like U+007F or CJK characters) use DWIDTH 16. Thus the global FONTBOUNDINGBOX must be 16 pixels wide.

In a fully BDF-compliant renderer, the per-character DWIDTH and BBX values can override the global bounding box for spacing and alignment. However, Avisynth's BDF renderer does not implement this override behavior. It uses the global FONTBOUNDINGBOX width as a constant for the whole rendered text line.

So far I’ve only encountered BDF fonts where FONTBOUNDINGBOX, DWIDTH, and BBX were consistent across all glyphs. Unifont breaks this assumption, which in turn revealed a limitation in my implementation.

2.) The (C) (Copyright) character is missing on your system, why?

[qyot27]

2.) The (C) (Copyright) character is missing on your system, why?
That's the one side-effect I've encountered in the AviSynth+ core of switching the system codepage to UTF-8. On Ubuntu it displays the Copyright symbol just fine, but because Windows has to take a far more convoluted path to get there, that's probably where the issue lies.

[pinterf]

That's the one side-effect I've encountered in the AviSynth+ core of switching the system codepage to UTF-8. On Ubuntu it displays the Copyright symbol just fine, but because Windows has to take a far more convoluted path to get there, that's probably where the issue lies.
It's because on non-Posix builds this string is used:
#define AVS_COPYRIGHT "\n\xA9 2000-2015 Ben Rudiak-Gould, et al.\nhttp://avisynth.nl\n\xA9 2013-2025 AviSynth+ Project"

Which contains (C) symbol as xA9 but it's an invalid code sequence in UTF8 and is has problems on Hebrew or Arabic code pages as well. I'm gonna figure it out.

EDIT: and we returned to the problematic non-utf8 aware MessageClip

return Create_MessageClip(
#ifdef AVS_POSIX
AVS_FULLVERSION AVS_DEVELOPMENT_BUILD AVS_DEVELOPMENT_BUILD_GIT AVS_COPYRIGHT_UTF8
#else
AVS_FULLVERSION AVS_DEVELOPMENT_BUILD AVS_DEVELOPMENT_BUILD_GIT AVS_COPYRIGHT
#endif
, w, h, i_pixel_type, shrink, textcolor, halocolor, bgcolor, fps_numerator, fps_denominator, num_frames, env);

EDIT2:
Which in turn is using the non-changeable env->ApplyMessage, which has no utf8 parameter, and cannot even have one, without breaking the IScriptInterface.

EDIT3:
Version (C) symbol now works when Windows codepage is utf8, MessageClip utf8 bool parameter added; env->ApplyMessageEx added as a new v12 interface function. Now it needs a code cleanup, but before it I'd like to implement the Unifont 8-16 pixel fixed-variable :) width feature.

[StainlessS]

All of that there weird UTF8, Unicode, code pages etc, terrifies and fills me with despair.
I blame foreigners, hangin's too good for them.
Everybody should use English, if its good enough for God, it should be good enough for them
:)

[pinterf]

All of that there weird UTF8, Unicode, code pages etc, terrifies and fills me with despair.
I blame foreigners, hangin's too good for them.
Everybody should use English, if its good enough for God, it should be good enough for them
:)
You are right, but that's still way too modern. Let's ditch traditional English, and go full retro, I propose cuneiform on clay tablets, no more encoding issues, more fun. No exotic keyboard layouts, just have a good stylus. proper C++ support is questionable though, we'd have to step back a bit. :)

[jpsdr]

@pinterf
Is the AVX2 resample code in the current branch ok, or are you still working on it ?
Just to avoid to implement the new code in my ResampleMT and re-doing things later if it's for changing later.
No big deal, i am absolutely not in hurry.

[jpsdr]

@pinterf
I have a different result with my pure "C" 8bits and yours for the vertical part, and i don't see what's wrong...:(
Is it possible that there is something wrong in your pure "C" vertical ? :confused:

[DTL]

In June 2025 there were another big update on resampling engines (SIMD) and possible new resample function (H+V for each plane with single temp buf) for planar formats. But to the end of June there were no news from pinterf and what of the suggested updates will be transfered to main AVS+ branch is unknown. You can see latest news and commits about resamplers at this pull request - https://github.com/AviSynth/AviSynthPlus/pull/440 . Though some may be treated as performance tech demos and may be not safe for end of line and even end of buffer memory access.
For AVX512 many resizers somehow done too (at least all verticals ?) and only left 8 and 16bit H-resizers. Also you can see some performance optimization updates for AVX2 (mostly float32 resizers).

Also main new design idea on H-resizers (transposition of H-resize task to V and process with SIMD-friendly V-fma) cause possibility to design several more faster processing functions but limited to the filter support size (kernel size). This may make performance benefit for small-kernel resizers like Bilinear/Bicubic(?)/some small support Gauss and may be some others (like sinc-based with taps=2) but solution is not one for all H-resize function as exist in 3.7.5 AVS+ and before.
Also different SIMD architectures supports different size load and transposition with better performance (AVX512 is best as expected). This makes resampling engine more complex (and more complex to maintain) and may be not accepted by current very limited amount of developers resources. Though some more simple optimizations may be included.

[wonkey_monkey]

The examples for env->invoke with multiple parameters are all of this form:

AVSValue up_args[3] = { child, 384, 288 };
PClip resized = env->Invoke(upsizerString, AVSValue(up_args,3)).AsClip(); // up_args is AVSValue[1], but is effectively also AVSValue*(?)


But what if I don't have a fixed number of parameters? I'm trying to do an equivalent of this:

std::vector<AVSValue> up_args;
up_args.push_back(clip);
up_args.push_back(384);
up_args.push_back(288);
PClip resized = env->Invoke(upsizerString, AVSValue(up_args.data(), up_args.size())).AsClip(); // up_args.data() is AVSValue*


But it throws an exception about invalid arguments.

Is there any way to do what I'm trying to do? Or do I have to use a fixed size array allocated on the stack?

------------------

Also, I'm trying to catch any exceptions from call to invoke. But I can't work out what type is thrown. I can catch generally with (...) but AvisynthError and std::exception don't work.

[jpsdr]

@pinterf
Hi.

Now that i have updated to the new SSE code, i have a crash i didnt' have before.
I happens in resize_v_sse2_planar on the following line:

if (notMod2)
{ // do last odd row
// Load a single coefficients as a single packed value and broadcast
__m128i coeff = _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff[sizeMod2])); // 0|co|0|co|0|co|0|co

[DTL]

Current AVS+ repository lists for void resize_v_sse2_planar() https://github.com/AviSynth/AviSynthPlus/blob/91fc40819f63d5d6194507114ea5ff430481104e/avs_core/filters/intel/resample_sse.cpp#L231C1-L231C27

https://github.com/AviSynth/AviSynthPlus/blob/91fc40819f63d5d6194507114ea5ff430481104e/avs_core/filters/intel/resample_sse.cpp#L296
// Process the last odd row if needed
if (notMod2) {
// Load a single coefficients as a single packed value and broadcast
__m128i coeff = _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff + i)); // 0|co|0|co|0|co|0|co

May you got wrong text somewhere ?

Also you change function somehow - i counter used in loop and as pointer to the last index:
int i = 0;
for (; i < kernel_size_mod2; i += 2) {}
- after loop exit i+=2 always and
if (notMod2) {
// Load a single coefficients as a single packed value and broadcast
__m128i coeff = _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff + i)); // 0|co|0|co|0|co|0|co - reads last coef indexed by i from current_coef array (vector)

In your text you use
if (notMod2)
{ // do last odd row
// Load a single coefficients as a single packed value and broadcast
__m128i coeff = _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff[sizeMod2])); // 0|co|0|co|0|co|0|co

sizeMod2 may be not equal in all cases to i+=2 in the AVS+ current core version ?

[jpsdr]

SetMaxCPU("SSE2")
ColorBars(720,480).KillAudio()
Spline36ResizeMT(1280,720,src_left=17.2,src_width=680,src_top=-8.7,src_height=440)
DeSpline36ResizeMT(720,480,src_left=17.2,src_width=680,src_top=-8.7,src_height=440,accuracy=0,order=0)


The error message is the typical @00000000 cryptic one a unaligned acces can generate.

Edit:
Script edited...

[DTL]

_mm_set1_epi16() is a macro for C-compiler - https://www.laruence.com/sse/#text=_mm_set1_epi16&expand=4938 . It is up to compiler how to use aligned-safe read instructions and it is expected to work without alignment requirements.

[jpsdr]

It is up to compiler...
Even if i understand perfectly all the benefits of intrinsic, it's one of the reasons i'm not using them and still using ASM.

[DTL]

Have you check disassembly at the crash point ? Is it memory read instruction ?

Can you try non-modified function from AVS+ https://github.com/AviSynth/AviSynthPlus/blob/91fc40819f63d5d6194507114ea5ff430481104e/avs_core/filters/intel/resample_sse.cpp#L231C1-L231C27 ? Is it crash too ?

Script

SetMaxCPU("SSE2")
ColorBars(720,480).KillAudio()
Spline36Resize(1280,720,src_left=17.2,src_width=680,src_top=-8.7,src_height=440)
Spline36Resize(720,480,src_left=17.2,src_width=680,src_top=-8.7,src_height=440)


Work with AVS 3.7.5 without crash. It is better to move discussion to ResampleMT thread ?

[jpsdr]

I can't test the not-modified as it doesn't fit with my code, but... I didn't check enough, i forgot this is a line i've modified, so maybe indeed it's my fault.
I will check better.

[jpsdr]

I don't see any issue with the modified version.
I don't know what function to use, and how playing with the parameters will trig the "notmod2" code path with standard functions... :(

Edit:
I see my stupid noob level mistake...! :angry:
current_coeff[sizeMod2] return the value in the tab, when i need the address of ptr, so current_coeff+sizeMod2.
I've been tricked by the mmx version just up... :p
Sorry, it was indeed misplaced...

[DTL]

It looks you still have same issue in more places -
https://github.com/jpsdr/ResampleMT/blob/7a14f3b51534d2f67fa96c978f932b602c038e6b/ResampleMT/resample_sse.cpp#L173
https://github.com/jpsdr/ResampleMT/blob/7a14f3b51534d2f67fa96c978f932b602c038e6b/ResampleMT/resample_sse.cpp#L638

" one of the reasons i'm not using them and still using ASM."

Intrinsics allows to do universal x86 and x64 compilable program text and also a good compiler can do best job on registers usage and instructions placement for some known hardware architectures. Also programs can be compiled for future CPUs by future compilers without redesign.

The very sad thing happened after x86 programmer's used x86 ASM inlines in C AVS plugins text and after the era of x86 CPUs ended and also lots of freeware programmers left. The residuals of users left with unusable program text for new x64 CPUs. And the only possible way is to wait when (if ever) the AI compilers can redesign such plugins for x64 compilable program text. Many users and programmers in the beginning of 200x hoped the civilization would not die too fast and we always will have lots of free programmers doing program text redesign for any current CPU cores. But things went quickly in a sad way and we lost about all free programmers only about +20 years later.

Usage of intrinsics may help to last usable program texts a bit more I hope.

[jpsdr]

These 2 lines are good, _mm_set1_epi16 request directly the value to be broadcasted, so in the case of these 2 lines it's good, and it was like this in the original code.
Where i made the mistake, it was _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff[sizeMod2])) it needs the pointer, so the proper in that case is _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff+sizeMod2)) because current_coeff[sizeMod2] is the value, where current_coeff+sizeMod2 is the address of the value.
I think _mm_set1_epi16(current_coeff[sizeMod2]) would probably work, like on the others two lines you linked as current_coeff is a const short*. I don't understand why it's like this here, and differently on the other places, but i left it the way it is.

[DTL]

" I don't understand why it's like this here, and differently on the other places, but i left it the way it is."

The main resampling engine function definition is equal for all supported data types (8,9-16 and 32 bits)
void resizer_*(BYTE* dst8, const BYTE* src8, int dst_pitch, int src_pitch, ResamplingProgram* program, int width, int height, int bits_per_pixel);

and coeff buffer also have different types (integers and floats). So programmers need to convert single incoming pointers to function arguments into different pointer types inside each function implementation. So many functions were designed differently by different programmers.

With about 1/4 century of development AVS collects many different sets of resampling functions from different programmers and it is hard to make them all in the same style with low programmers resources of today.
Each set of resampling functions for each SIMD family from MMX to AVX512 contains at least:
1. 3 data types H-resamplers
2. 3 data types V-resamplers

The V-resamplers are typically simple and universal. Single function supports all kernel size and all resize ratios and can not be more optimized for performance.
The H-resamples are typically more complex (and slower) and with more and more large SIMD family it is possible to make some higher performance H-resamplers for some limited combinations of kernel size and resize ratios. This cause number of possible H-resamplers for big SIMD families like AVX2 and AVX512 even much more in count.

[jpsdr]

No, what i meant is why specificaly here there is in original code _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff+i)) when there is on other places _mm_set1_epi16(current_coeff[i]) (still in original code) with current_coeff being const short* always.

[vcmohan]

Since a couple of days whenever I try to access avisynth development or usage subforums, getting a message that it is forbidden. However I am able to view vaporsynth forum. Has anything changed for this ?

[StvG]

Since a couple of days whenever I try to access avisynth development or usage subforums, getting a message that it is forbidden. However I am able to view vaporsynth forum. Has anything changed for this ?

I have same problem. Refreshing few times the main forum page (https://forum.doom9.org) fix it.

[vcmohan]

thanks

[LigH]

This may happen when an element in the user account related cookie gets misinterpreted. Sometimes due to a board software update. Also quite regularly when Daylight Saving time toggles.

Clearing the cookies of this domain and logging in anew helps for a longer period of time.

[StvG]

This may happen when an element in the user account related cookie gets misinterpreted. Sometimes due to a board software update. Also quite regularly when Daylight Saving time toggles.

Clearing the cookies of this domain and logging in anew helps for a longer period of time.

It happens when browsing the forum without login.
Here at browser exit everything is cleared. Opening it and navigating to the forum, and accessing the Avisynth Usage and/or Avisynth Development subforums for the very first time (no cookies saved) - 403 Forbidden access.
I think there was forum update some time ago - now there is blue icon (d9) next to the page title. From this moment I started have this problem.

[jpsdr]

There is something i'm not able to find out... Where in resample pixel_offset is ajusted to be sure src+pixel_offset[x] is always aligned... (for horizontal resampling) :confused:

Edit:
I suddenly had a hunch...
Then checked the AVX2 code.... OMFG...!!! :eek:
If i understand properly the intrinsic the src read are unaligned...
I understand now why i can't find where the pixel_offset is adjusted aligned...

[manolito]

Please forgive me my ignorance, I have not followed this thread for a long time (due to a stroke about 4 years ago).

I am still using AVS+ 3.5.1, mainly because I had other things to do, and it "just worked". Now I figured I should probably upgrade to a current version of AVS+, and I did get some problems...

Updating to the last stable version worked fine, the installer did a good job, and at first it looked like there were no problems. But this changed when I executed a script which needed FineSharp by Didée. It crashed at this script line:
shrpD = mt_lutxy(c,b,"x y - abs "+LSTR+" / 1 "+PSTR+" / ^ "+SSTR+" * x y - x y - abs 0.001 + / * x y - 2 ^ x y - 2 ^ "+LDMP+" + / * 128 +")


I checked earlier versions of AVS+, and the latest working version is v 3.7.0. I do not really understand the code in this line, so there is no chance I could fix this myself. What are my options?

1. Ask Didée (not too smart, this code worked before, it should be fixed in AVS+)

2. Ask PinterF to fix it in AVS+

3. Do not use current AVS+ versions (possible, but not really what I want)

4. Use FFmpeg instead. Their SmartBlur filter comes pretty close to FineSharp.
smartblur=1.5:-0.35:-3.5:0.65:0.25:2.0



I would be really interested to know if I am the only one having this problem with FineSharp. Could it be my old ThinkPad with its CORE i5 CPU?


Any ideas?


Cheers
manolito

[Boulder]

Could it be my old ThinkPad with its CORE i5 CPU?


You could try using SetMaxCPU to see if there are any instruction set conflicts for some reason. However, I highly doubt that is the case.

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_internal_functions_global_options.html#setmaxcpu

[wonkey_monkey]

It worked okay for me (3.7.4 x64 on an i5). Is your MaskTools up to date? What are the properties (resolution, colourspace) of the source?

[DTL]

There is something i'm not able to find out... Where in resample pixel_offset is ajusted to be sure src+pixel_offset[x] is always aligned... (for horizontal resampling)

pixel_offset[] can not be aligned because it greatly depends on the resample ratio and source samples positions for current output sample convolution and resample ratio can be any real number. So it always (in most cases) need unaligned read from memory to SIMD. Some aligned positions are possible in the resampling program for a row but checking logic overhead may be much more in comparison with usage of unaligned loads always.

One possible way to use aligned reads and non-aligned pixel_offset[] sampling from the read part of a row is use aligned load of part of a row into SIMD register and use some permutation or shifting or any other existing data shuffling instructions inside SIMD register file.

In AVX2 H-resizer we have unaligned load from src+pixel_offset[] address https://github.com/DTL2020/AviSynthPlus/blob/034a47e2c91ad9d84ad24492d37a18f99b58d996/avs_core/filters/intel/resample_avx2.cpp#L101

[manolito]

It worked okay for me (3.7.4 x64 on an i5). Is your MaskTools up to date? What are the properties (resolution, colourspace) of the source?

My MaskTools version is mt_masktools-26.dll, this is what Didée recommends. My usual sources are half HD (1280x720), YUV 4:2:0, nothing special.

I only use AVS+ x32, I do not want to clutter my workflow with a mix of 32bit und 64bit plugins. This shoult not matter for an avsi plugin though.

[Boulder]

My MaskTools version is mt_masktools-26.dll, this is what Didée recommends. My usual sources are half HD (1280x720), YUV 4:2:0, nothing special.

This is the latest one: https://github.com/pinterf/masktools/releases/tag/2.2.30

[manolito]

Thanks a lot Boulder, your tip saved the day for me... :D

First after copying the file from your link to the plugins folder I still got the same error as before. I just had not realized that the old mt_masktools-26.dll was still present in my plugin folder, and it took precedence over the new masktools2.dll. After deleting this file everything worked fine.

So thanks again...

Cheers
manolito

[Boulder]

Thanks a lot Boulder, your tip saved the day for me... :D

First after copying the file from your link to the plugins folder I still got the same error as before. I just had not realized that the old mt_masktools-26.dll was still present in my plugin folder, and it took precedence over the new masktools2.dll. After deleting this file everything worked fine.

So thanks again...

Cheers
manolito

No worries, just happened to remember that masktools2 was one of the plugins pinterf had kept updated :)

Good to see you back.

[wonkey_monkey]

BicubicResize is bypassing itself when target width/height is the same as source width/height (and there is no offset). It should only do so if b = 0 (which it is not, by default).

[qyot27]

BicubicResize is bypassing itself when target width/height is the same as source width/height (and there is no offset). It should only do so if b = 0 (which it is not, by default).
Wasn't this the same or similar reason for https://forum.doom9.org/showthread.php?p=2016078#post2016078 ?

[wonkey_monkey]

Some previous "skip" conditions were removed, so I would have thought this one should be too: https://forum.doom9.org/showthread.php?t=175681

I hadn't noticed, or had forgotten, about "force", but it seems like a kludge to me. The default behaviour falls under the category of "surprising (https://en.wikipedia.org/wiki/Principle_of_least_astonishment)", for me (perhaps more surprising than a resizer defaulting to parameters which amount to a blur).

[LigH]

I was in contact with several text editor developers related to supporting syntax highlighting.

In the case of "Far manager", support for block comments, even the nested type with brackets, could be added. In the case of "PSPad", it seems that this requires the introduction of a new symbol pair class.

So while I am at it: Are there simple but complete lists of identifiers available which are supported by the current version of the AviSynth+ core (reserved words, core functions, etc.)? I guess a list of core functions can be provided by AVSMeter.

[DTL]

BicubicResize is bypassing itself when target width/height is the same as source width/height (and there is no offset). It should only do so if b = 0 (which it is not, by default).

All resizers (really single resizing engine calls with different kernel setup) skip dimension processing if no size changed and no shift requested (src_left and src_top == 0) and force=0 (default).

To force convolution processing with selected kernel in any resizer you need either change size or shift or set force param to > 0 (to force H or V or H+V processing).

2D resize in AVS+ core is really sequence of H+V runtime configurable 1D resize filters and if some dimension is not processed - the filter for this is not created and not included into the filtergraph at all.

[wonkey_monkey]

All resizers (really single resizing engine calls with different kernel setup) skip dimension processing if no size changed and no shift requested (src_left and src_top == 0) and force=0 (default).


Which is fine, and always gives the correct result anyway - except when you're using BicubicResize with b != 0 (it defaults to 1/3).

If BicubicResize checked for b != 0 before skipping, then I don't think force would be needed at all.

[VoodooFX]

In the case of "PSPad...

Be careful with that one, it has critical random bug damaging a file you edit.

[LeXXuz]

Anyone else having problems with special characters in file names again? Haven't had this with previous versions.

[wonkey_monkey]

There's a bug in Reverse() when called on a clip with 24-bit audio:

void Reverse::GetAudio(void* buf, int64_t start, int64_t count, IScriptEnvironment* env)
{
child->GetAudio(buf, vi.num_audio_samples - start - count, count, env);
int x = vi.BytesPerAudioSample() - 1;
char* buf2 = (char*)buf;
const int count_bytes = (int)vi.BytesFromAudioSamples(count);
for (int i=0; i<(count_bytes>>1); ++i) {
char temp = buf2[i]; buf2[i] = buf2[count_bytes-1-(i^x)]; buf2[count_bytes-1-(i^x)] = temp;
}
}

The problem is here. The bits in red - which to me looks like a case of too-clever-for-its-own-good - rely on vi.BytesPerAudioSample() being a power of 2, which is not the case for 24-bit audio.

[wonkey_monkey]

I opened MSVC and opened my local Avisynth 3.7.5 folder to make a build. But I got this error:

CMake Error at CMakeLists.txt:155 (message):
MSVC/ClangCL only supported on x86(-64). Use MinGW (llvm-mingw or gcc).

3.7.4 is doing the same, but I'm sure I didn't used to get this error - I could pretty much just open the local folder, wait for MSVC to do its thing, and then build. Has there been some update to MSVC which is causing something to fail?

I changed line 155 of CMakeLists.txt to:

message(FATAL_ERROR "MSVC/ClangCL only supported on x86(-64). Use MinGW (llvm-mingw or gcc).${PLATFORMID}xxx")


and this was the output:

1> CMake generation started for configuration: 'x64-Release'.
1> Command line: "C:\Windows\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo" -DCMAKE_INSTALL_PREFIX:PATH="C:\Projects\Avisynth\AviSynthPlus-3.7.5\out\install\x64-Release" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\Projects\Avisynth\AviSynthPlus-3.7.5" 2>&1"
1> Working directory: C:\Projects\Avisynth\AviSynthPlus-3.7.5\out\build\x64-Release
1> [CMake] -- Detected target processor as: AMD64
1> [CMake] -- Build type: RelWithDebInfo
1> [CMake] CMake Error at C:\Projects\Avisynth\AviSynthPlus-3.7.5\CMakeLists.txt:155 (message):
1> [CMake] MSVC/ClangCL only supported on x86(-64). Use MinGW (llvm-mingw or gcc).xxx
1> [CMake]
1> [CMake]
1> [CMake] -- Configuring incomplete, errors occurred!
1> 'C:\Windows\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo" -DCMAKE_INSTALL_PREFIX:PATH="C:\Projects\Avisynth\AviSynthPlus-3.7.5\out\install\x64-Release" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\Projects\Avisynth\AviSynthPlus-3.7.5" 2>&1"' execution failed with error: ''C:\Windows\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo" -DCMAKE_INSTALL_PREFIX:PATH="C:\Projects\Avisynth\AviSynthPlus-3.7.5\out\install\x64-Release" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\Projects\Avisynth\AviSynthPlus-3.7.5" 2>&1"' returned with exit code: 1'.

which seems to suggest ${PLATFORMID} is an empty string...?

[LigH]

That looks like the CPU architecture got misdetected...

[wonkey_monkey]

It detects the processor okay - AMD64 - but ${CMAKE_VS_PLATFORM_NAME}, which is what ${PLATFORMID} is based on, seems to be empty. A Google search only suggests a possible issue with it not getting filled in until project(...) is set, but that's done on line 79.

[StvG]

Change this snippet (https://github.com/AviSynth/AviSynthPlus/blame/master/CMakeLists.txt#L146-L152) with:
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(x86_64|amd64|x64|i[3-6]86|x86)$")
set(NON_X86_PLATFORM "OFF")
else()
set(NON_X86_PLATFORM "ON")
endif()

@qyot27 the original snippet doesn't work for other generator than Visual Studio one.

[qyot27]

Change this snippet (https://github.com/AviSynth/AviSynthPlus/blame/master/CMakeLists.txt#L146-L152) with:
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(x86_64|amd64|x64|i[3-6]86|x86)$")
set(NON_X86_PLATFORM "OFF")
else()
set(NON_X86_PLATFORM "ON")
endif()

@qyot27 the original snippet doesn't work for other generator than Visual Studio one.
Honestly, since I couldn't get Ninja and MSVC to ever play nice with one another, it makes sense why that wasn't caught.

[StvG]

Honestly, since I couldn't get Ninja and MSVC to ever play nice with one another, it makes sense why that wasn't caught.

The biggest pain for me using Ninja+MSVC to build AVS+ is that the version script doesn't work. Binary built with Ninja doesn't show the version when right click, properties, details.

[qyot27]

The biggest pain for me using Ninja+MSVC to build AVS+ is that the version script doesn't work. Binary built with Ninja doesn't show the version when right click, properties, details.
Only MSVC_IDE adds the .rc file, yes. Files.cmake, line 89. I can't remember what precisely about .rc files Ninja had issues with (it was six years ago), so it's hard to say whether it might have been fixed by now.

[wonkey_monkey]

Change this snippet (https://github.com/AviSynth/AviSynthPlus/blame/master/CMakeLists.txt#L146-L152) with:
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(x86_64|amd64|x64|i[3-6]86|x86)$")
set(NON_X86_PLATFORM "OFF")
else()
set(NON_X86_PLATFORM "ON")
endif()

I had to change it to from "amd64" to "AMD64", but that seems to have worked, thanks. Building like this should result in a fairly optimal DLL, right? I changed CMakeSettings.json to x64-Release.

@qyot27 the original snippet doesn't work for other generator than Visual Studio one.

I'm using Visual Studio :confused: and I'm sure it worked without alteration a few months ago...

[StvG]

I had to change it to from "amd64" to "AMD64", but that seems to have worked, thanks. Building like this should result in a fairly optimal DLL, right? I changed CMakeSettings.json to x64-Release.

Right. This is the case-insensitive version:
string(TOLOWER "${CMAKE_SYSTEM_PROCESSOR}" PROCESSOR_ID_LOWER)
if(PROCESSOR_ID_LOWER MATCHES "^(x86_64|amd64|x64|i[3-6]86|x86)$")
set(NON_X86_PLATFORM "OFF")
else()
set(NON_X86_PLATFORM "ON")
endif()

Yes, building like this will result in fairly optimal DLL. You built RelWithDebInfo version.

I'm using Visual Studio :confused: and I'm sure it worked without alteration a few months ago...

You use the Visual Studio environment but you're using Ninja building system not the native Visual Studio one (solution files).

From one of the your previous posts:
1> 'C:\Windows\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING=...

[wonkey_monkey]

I can't work out whether this is because I've added ninja.exe to MSVC at some point... I certainly can't see an obvious way to remove it again, or make it not the default, if I did. Anyway, alternative fix is to go into CMake settings and change the generator there.

[StvG]

Open your CMakeSettings.json, locate "generator" and change it from "Ninja" to "Visual Studio 17 2022" (or your VS version if it's not 2022). Check if you have "architecture"->"strategy" : "external", if so change "strategy" to "set". This way you will use the native VS generator (solution files).

[jpsdr]

Hi.

If i want to change chromaplacement property of a frame.

How do i do
avs_prop_set_int(env, avs_get_frame_props_rw(env, dst), "_ChromaLocation", 2, 0);
but using "avisynth.h" ?

And do i need to call MakePropertyWritable somewhere ?
If yes, where ?

[StvG]

The C++ API equivalent is:
env->propSetInt(env->getFramePropsRW(dst), "_ChromaLocation", 2, 0);

You don't need MakePropertyWritable in this case.

[jpsdr]

Thanks !

[jpsdr]

Using r4339.

How AddAlphaPlane is working ?

I tried the following:

ColorBars(pixel_type="yv24")
AddAlphaPlane(255)

Virtualdub2 throw me a decompressing error on frame 0, data is too short.

I tried:

a=ColorBars(pixel_type="yv24")
a.AddAlphaPlane(255)
a

The video output is YV24...

How do i get an YUVA video ?

An exemple in the wiki show a script using a not existing function (AToY8).

[Music Fan]

Shouldn't it be AddAlphaPlane ? If it comes from the function CombinePlanes.

[LigH]

"AddAlphaPlane()" would be the correct function name.

And I also tested it with pixel_type names (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/blankclip.html) explicitly supporting alpha channels: "YUVA444" and "YUVA444P8". Same issue.

PS: VirtualDub2 reports such errors. AvsMeter64 does not.

Unfortunately, this kind of errors does not appear in the "Log" window [F8]. How else do I get the exact error message out of VirtualDub2?

[TR-9970X]

Using r4337.

I have to ask, is this the latest build of Avisynth ??

[jpsdr]

It's the problem when testing on a PC, and posting on another. Some typo mistake happens... :D (corrected).
It was r4339, and there was some update since i think, but not related to features i'm using, so i didn't make a new build.

[TR-9970X]

It's the problem when testing on a PC, and posting on another. Some typo mistake happens... :D (corrected).
It was r4339, and there was some update since i think, but not related to features i'm using, so i didn't make a new build.

That's interesting, so are these builds available, somewhere ?

[jpsdr]

Is it normal that Virtualdub2 throw "Unknow [0][0][0][0] video format" for planarRGB (or RGBA) 32bits ? No issue with YUV 32bits.
I've checked out, and Virtualdub2 support 32bits planar RGB.
And i'm almost sure that when (a long time ago now) i was creating my HDR tools, i was able to open AVS script outputing 32bits planar RGB.

@TR-7970X
No, sorry, i'm juste making builds for myself, i don't have a repo or anything for it, there is already enough people sharing their AVS+ builds.

[Music Fan]

Did you open your script in Virtualdub2 32 bit ? Because it generally fails when openend in Virtualdub2 64 bit.

[poisondeathray]

Is it normal that Virtualdub2 throw "Unknow [0][0][0][0] video format" for planarRGB (or RGBA) 32bits ?

Did you mean 8bit per channel planar RGBAP ? (not 32bit per channel RGBAPS)

Works for me (vdub x64 44282 , the last shekh version)

info() reports RGBAP

[jpsdr]

No, i mean 32bit per channel.

Edit:
I forgot... I as indeed with Virtualdub2 64 bits. I'll try with 32 bits.

[jpsdr]

I begin to wonder finaly if Virtualdub2 is able to handle planar RGBPS (or RGBAPS). Because if i output 32bits YUV444, it opens, but file info said it's Y416. So, finaly, it's not float.
Is Virtualdub converting it, or is avisynth converting before outputing ?

But if i ouput RGBPS ou RGBAPS, i have the error i described (with both x86 or x64 Virtualdub2 versions).
Even if in Virtualdub2 it exists nsVDXPixmap::kPixFormat_RGB_Planar32F and nsVDXPixmap::kPixFormat_RGBA_Planar32F, i begin to wonder if they are realy fully implemented.

[DTL]

Typically most safe format for VirtualDub to monitor output is RGB24. All others may not work.

[v0lt]

Some time ago I wrote about problems with Unicode (https://forum.doom9.org/showpost.php?p=2019715&postcount=3366).

I found another one.
Avisinth+ writes errors to AvisynthError::msg in UTF-8 format. However, Avisinth+ receives system error text in ANSI (CP_ACP) format and stores it in AvisynthError::msg. The result is an error text with two encodings for different lines.

A simple example:
Create a script file named "Duck_Утка_Πάπια_오리.avs" and add one line to it:
LoadPlugin ("filename")
The file "filename" won't be found, and we'll see the following error message:
Cannot load file 'C:/TEMP/filename'. Platform returned code 126:
�� ������ ��������� ������.

(C:\TEMP\Duck_Утка_Πάπια_오리.avs, line 1)

PS: Pull request #457 (https://github.com/AviSynth/AviSynthPlus/pull/457).

[Emulgator]

Good find !

[mcjordan]

I have a dumb problem with compiling latest AviSynth from github repo with VS2022:
The problem is in lines from 505 onward of ../avs_core/filters/source.cpp (error C2665):

PClip Create_MessageClip(const char* message, int width, int height, int pixel_type, bool shrink,
int textcolor, int halocolor, int bgcolor,
int fps_numerator, int fps_denominator, int num_frames,
bool utf8,
IScriptEnvironment* env) {
...
that pointed to line 2155 and below:

return Create_MessageClip(
AVS_FULLVERSION AVS_DEVELOPMENT_BUILD AVS_DEVELOPMENT_BUILD_GIT AVS_COPYRIGHT_UTF8,
w, h, i_pixel_type, shrink, textcolor, halocolor, bgcolor, fps_numerator, fps_denominator, num_frames,
true, // utf8
env);

Please help me to resolve this. I'm not heavy experienced in modern programing and this simple problem really bothers me at 2 am... ;-)

[v0lt]

I'm not heavy experienced in modern programing and this simple problem really bothers me at 2 am... ;-)
Did you use CMake to generate the correct project files?

[mcjordan]

v0lt
Yes, latest from their site - 4.2.0-rc1.
Project files are OК, I have compiled AVS many times with VS2022 and VS2019, but two last commits...
As far as I can understand the situation there is some kind of discrepancy of this type:
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-2/compiler-error-c2665?view=msvc-170

P.S. LLVM and pure clang builds (via VS - not via Intel compiler) are problems-free.

[v0lt]

Visual Studio 2022 v17.14.18. I have no problems building and rebuilding the main repository.

PS: I can't build my forked repository (https://github.com/v0lt/AviSynthPlus) due to a version.h generation error.

[mcjordan]

v0lt
Thank you for collaboration. I use the same build of VS.
I'll try your fork later today and if there is anything new I will write.

[mcjordan]

v0lt
The mystery of error C2665 is solved.
In Configuration Properties/General I've set C++ Language Standard at ISO C++20 (/std:c++20).
In my quest to compile a "slightly" optimized version of AviSynth I've clearly gone too far.
With C++17 compatibility there are no compilation problems

[LigH]

Woohoo!

I remember several problems in the history of the media-autobuild suite caused by C++ language standards in different projects... :o

[tormento]

I someone can share some newer builds of AVS+ is welcome. I am stuck at 4313 (https://gitlab.com/uvz/AviSynthPlus-Builds).

[Emulgator]

The last commits are around UTF-8 in GetLastErrorText, so probably you won't miss a thing here.

[mcjordan]

tormento
I sent you a message.

[tormento]

tormento
I sent you a message.
Thank you. I think you should share with anyone here.

[tormento]

Sorry if the question has already been discussed, I couldn't find the answer searching.

I stumbled across Resizing with Colorspace Correction (https://usage.imagemagick.org/resize/#resize_colorspace) and I asked myself if normal resizing that we do with AVS+ internals, jpsdr's MT resizers or avsresize are correct.

Should I convert everything to (linear) RGB before resizing or it is implemented already in the most often used filters?

Originals (https://visibleearth.nasa.gov/images/55167/earths-city-lights)

https://usage.imagemagick.org/resize/earth_lights_direct.png
Not gamma aware resizing

https://usage.imagemagick.org/resize/earth_lights_colorspace.png
Gamma aware resizing

[Selur]

iirc ReSampleHQ (http://avisynth.nl/index.php/ResampleHQ) does it, but I don't think other resizers do.

[LigH]

As far as I remember I would agree with Selur.

I would not generally recommend converting everything to RGB, it will be slightly lossy especially when all YUV components have 8 bit depth only (except YCoCg/YCgCo which uses a symmetrically shifted color space, relative to the RGB cube).

[tormento]

I would not generally recommend converting everything to RGB, it will be slightly lossy especially when all YUV components have 8 bit depth only (except YCoCg/YCgCo which uses a symmetrically shifted color space, relative to the RGB cube).
AFAIK VapourSynth works in RGB by design.

So, every time VS opens a YUV source, it adds a lossy step to the operation?

[tormento]

ReSampleHQ does it, but I don't think other resizers do.
It's a pity that it hasn't been updated since ages, above all if the other resizers don't take gamma in account.

We need a reply from jpsdr for ResampleMT and from stvg for AVSresize.

[LigH]

I don't use VapourSynth. I only reply with my experience in AviSynth. Matching this thread's topic.

[FranceBB]

iirc ReSampleHQ (http://avisynth.nl/index.php/ResampleHQ) does it, but I don't think other resizers do.

Correct.


original=ImageSource("D:\earth_lights_lrg.jpg")

imagemagic_direct=ImageSource("D:\earth_lights_direct.png").Subtitle("ImageMagic Default")
imagemagic_RGB=ImageSource("D:\earth_lights_colorspace.png").Subtitle("ImageMagic Default RGB")

downscale_resample=ResampleHQ(original, 500, 250).Subtitle("Avisynth Resample HQ")

downscale_point=PointResize(original, 500, 250).Subtitle("Avisynth PointResize")
downscale_gauss=GaussResize(original, 500, 250).Subtitle("Avisynth GaussResize")
downscale_bilinear=BilinearResize(original, 500, 250).Subtitle("Avisynth BilinearResize")
downscale_bicubic=BicubicResize(original, 500, 250).Subtitle("Avisynth BicubicResize")
downscale_sinc=SincResize(original, 500, 250).Subtitle("Avisynth SincResize")
downscale_lanczos=LanczosResize(original, 500, 250).Subtitle("Avisynth LanczosResize")
downscale_blackman=BlackmanResize(original, 500, 250).Subtitle("Avisynth BlackmanResize")
downscale_sin=SinPowerResize(original, 500, 250).Subtitle("Avisynth SinPowerResize")
downscale_spline=Spline64Resize(original, 500, 250).Subtitle("Avisynth Spline64Resize")

v1=StackHorizontal(imagemagic_direct, imagemagic_RGB, downscale_resample)
v2=StackHorizontal(downscale_point, downscale_gauss, downscale_bilinear)
v3=StackHorizontal(downscale_bicubic, downscale_sinc, downscale_lanczos)
v4=StackHorizontal(downscale_blackman, downscale_sin, downscale_spline)

StackVertical(v1, v2, v3, v4)


https://i.postimg.cc/nhwF0434/resize-test.png

[poisondeathray]

I asked myself if normal resizing that we do with AVS+ internals, jpsdr's MT resizers or avsresize are correct.

Not by default, but avsresize and fmtc can perform linear scaling - you linearize the transfer, scale, then readjust the transfer back


Should I convert everything to (linear) RGB before resizing or it is implemented already in the most often used filters?


Discussed in other thread (many pages) . Technically linear is more correct for everything, all filters, all math operations, not just scaling. 1+1 =2 . There is no baked in gamma error in all math.

But basically for downscaling it can be beneficial for small bright areas - that's where general public can see it the most .




I would not generally recommend converting everything to RGB, it will be slightly lossy especially when all YUV components have 8 bit depth only (except YCoCg/YCgCo which uses a symmetrically shifted color space, relative to the RGB cube).

I agree in general, but gamma linearization is usually done in float, so it can be RGB<=>YUV can be lossless when done properly.

Also, "gamma" is a RGB concept. If the topic is "gamma scaling error" when scaling (or any filter for that matter), it should be done in float RGB. Actually every high end professional software already does linear gamma scaling and works in float RGB - eg. resolve, nukex




AFAIK VapourSynth works in RGB by design.

No


So, every time VS opens a YUV source, it adds a lossy step to the operation?
No



It's a pity that it hasn't been updated since ages, above all if the other resizers don't take gamma in account.

We need a reply from jpsdr for ResampleMT and from stvg for AVSresize.
Not sure about ResampleMT, but as above, AVSResize and FMTC can do linear scaling, but it's not by default

[tormento]

Not by default, but avsresize and fmtc can perform linear scaling - you linearize the transfer, scale, then readjust the transfer back

[…]

Not sure about ResampleMT, but as above, AVSResize and FMTC can do linear scaling, but it's not by default
Could you be so kind to show me a couple of examples of this back and forth for both?

[poisondeathray]

Could you be so kind to show me a couple of examples of this back and forth for both?


It's just the transfer argument to linear. You are "linearizing the gamma". So if you were starting with a RGB web image, in srgb



#assume starting with 8bit sRGB web image

#srgb to linear in 32bit float
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="rgb:srgb:709:f=>rgb:linear:709:f")

#resize step in current pixel type, which is RGBPS
z_ConvertFormat(width, height, resample_filter="spline36", colorspace_op="rgb:linear:709:f=>rgb:linear:709:f")

#transfer from linear back to srgb (8bit srgb in this case)
z_ConvertFormat(pixel_type="RGBP", colorspace_op="rgb:linear:709:f=>rgb:srgb:709:f")



If it was some video source, you 'd change the appropriate parameters such as matrix, pixel type etc...

[Boulder]

There's a couple of linear light downscaling examples at the end of the Avsresize wiki page.
http://avisynth.nl/index.php/Avsresize

[DTL]

Sorry if the question has already been discussed, I couldn't find the answer searching.

I asked myself if normal resizing that we do with AVS+ internals, jpsdr's MT resizers or avsresize are correct.

Should I convert everything to (linear) RGB before resizing or it is implemented already in the most often used filters?



It is really question about digital static imaging where RGB or YUV 4:4:4 (do not know what for if they can keep RGB) is possible. Even old/classic JPEG can store and unpack 4:4:4.

But with digital moving pictures general public world you mostly live with old poor and ugly 4:2:0 and can not benefit from resize in linear domain any significantly. Attempt to release such conditioned footage may cause more distortions at displaying because many displays perform scaling in System Transfer domain. Scaling in linear is more expensive and was NOT put to industry standards for digital displays. With digital-analog workflows and CRT displays it may be close to not possible at all because linear conversion was _after_ DAC and inside CRT device physically. This mean ADC and DAC work in System Transfer domain upscale mode. And this (partially and silently) was inherited to 'fully digital' seasons at the market. Also broadcast waveform monitors (Tektronix and Leader rasterizers and (all ?) CRT based oscilloscopes) make upscale only in System Transfer domain and do not have switch to make scale in linear domain. All this make a great pressure to continue use conditioning for System Transfer domain instead of moving to nice and lower distorted RGB with linear domain scaling.

There may be possibly more letters about how it is happen in this civilization. But later.

What is really important about AVS+ core close to this question:

Conversions of YUV 4:2:x to RGB 4:4:4 may be performed in different ways :

1. Current way in AVS+ core (and may be plugins ?) is upscale UVs to Y size (YUV 4:4:4) and perform dematrix to RGB.

This is not perfect and can not work well with that resize in linear idea because of a chicken and egg problem: To make resize in linear RGB we need RGB to perform dematrix and to get RGB in System Transfer we need to resize YUVs first. So it is already not possible to do perfectly.
I think it is not possible to convert Transfer in 4:2:0 form of digital data without resize (need to check this better).

This is also subject to add a Note to Resize documentation how ConvertToRGB/444 is working internally when upconverting from 4:2:0.

2. Second way to know and test is downsample Y to UV size and make dematrix of RGB in UV size. This will make half banded (H or H+V) RGB. This RGB can be converted in linear transfer without resize. Also we have full-band Y (in System Transfer domain). We can apply linear transfer conversion to it. It is not perfect step but close to nothing more to do with old ugly subsampled chroma formats. Y is close to G channel in properties (spectrum ?).
And can do attempt to transfer fine details from it (using sort of DPIDraw() or some other way like high band frequencies extract from Y and add to RGB half-banded ?) into RGB to get better result.

The sad issue of Transfer conversion from/to linear is frequency spectrum changes and this distort conditioning against Gibbs ringing (and even aliasing) created by production downsizers. This mean display (processing) upsizing must be performed in Conditioning domain and it must be tagged in metadata for receiver. But this tagging is not exist yet even. Nor in any industry standards. But if Conditioning domain is linear RGB - the conversion to subsampled YUV also adds distortions and degrage the total idea to add quality by production in linear RGB. To fix this - the distrubution must be also in RGB. And this is not true for public distribution formats.

Yes - pro NLEs may do scale in linear RGB. But they also can do data exchange in RGB or YUV 4:4:4. And these production formats do not reach poor endusers so this knowledge is partially useless for poor home endusers.

[tormento]

Thanks to everybody for their answers.

Conversions of YUV 4:2:x to RGB 4:4:4 may be performed in different ways :

1. Current way in AVS+ core (and may be plugins ?) is upscale UVs to Y size (YUV 4:4:4) and perform dematrix to RGB.

So, at the end of the day, is it worth to convert a 4:2:0 AVC or HEVC video to RGB to resize it? I am particularly worried about descaling procedure, where we have the inversion of the kernel matrix and the operation needs to be as precise as possible.

If positive, being descale existing only as jpsdr plugin, not knowing how they work internally, what is the least destructive way to upconvert to RGB, descale and downconvert to 420 again?

When the native resolution is half of the original one, we have an easy way to do it, i.e. descale Y plane only and work in 444. But when the native resolution is a random one?

[Emulgator]

But when the native resolution is a random one?
One would have to run FFT on source, find the ringing patterns, guess the source resolution and the resizer kernel used
then behind that maybe guess the sensor pattern (?!) and that resizer kernel used.
Then reverse those resizer kernels in reverse order in their respective spaces.
While doing so, correct old faults that had been incurred at that stage only.
So no artistic or neutralising grading, only Y/Chroma shifts that came in at that stage: Camera AGC, broadcast phase shifts, tape recording oversaturations etc.)
Then start anew, and this time grading/resizing/compositing as RGB in 32bit float in linear light please, only finally giving in to the requirement of distribution as YUV, again.
Patience & Persistence.

[tormento]

One would have to run FFT on source
I know how to find native ;)

My question was about a good strategy to descale converting to RGB and lose as tiny information as possible.

[DTL]

So, at the end of the day, is it worth to convert a 4:2:0 AVC or HEVC video to RGB to resize it? I am particularly worried about descaling procedure, where we have the inversion of the kernel matrix and the operation needs to be as precise as possible.

If positive, being descale existing only as jpsdr plugin, not knowing how they work internally, what is the least destructive way to upconvert to RGB, descale and downconvert to 420 again?


To keep most of quality you simply need to keep RGB after you somehow create it from input sources. You can only go to YUV 4:4:4 if compression require it. Simply never go back to the ugly and lossy chroma subsampled 4:2:x domain.

[jpsdr]

If positive, being descale existing only as jpsdr plugin, not knowing how they work internally,
How they work is described in the first post of my Internaly multi-threaded desampling functions thread.

[tormento]

How they work is described in the first post of my Internaly multi-threaded desampling functions thread.
I see no reference to how color spaces are internally treated.

[DTL]

I think they are same as AVS(+) internal resizers - completely separated planes resize without changing colour space.

[FranceBB]

Yep, the results from the MT version are pretty much like for like with the internal ones in the core. I remember testing them to see the differences a while back and then extending the test to the different CPU assemblies to catch any discrepancy there too. If I remember correctly, DTL did the same and ran a similar batch of tests. Anyway the point is that it's actually intended to be like that.

[tormento]

I was looking at avslibplacebo documentation (http://www.avisynth.nl/index.php/Avslibplacebo) and, for libplacebo_Resample, I've found the parameters

int trc = 1
The colorspace's transfer function (gamma / EOTF) to use for linearizing.

sigmoidize, linearize
Whether to linearize/sigmoidize before scaling.
Only relevant for RGB formats.
When sigmodizing, linearize should be true
Default: True.

sigmoid_center
The center (bias) of the sigmoid curve.
Must be between 0.0 and 1.0.
Default: 0.75.

sigmoid_slope
The slope (steepness) of the sigmoid curve.
Must be between 1.0 and 20.0.
Default: 6.5.

I just need to understand if that parameter means that it automatically converts to linear RGB when resampling or not. Any idea?

Whati is sigmoidization?

The default value for trc is BT_1886 (ITU-R Rec. BT.1886 (CRT emulation + OOTF). Does it fit for standard AVC BT.709 material or is it better to use Gamma values? In the latter case, which one is a good "default" one for BD mastered content?

[DTL]

I do not know any industry standards on spectrum shaping (including production resize). The general practic - you feed your master footage to master control monitor and adjust resizers (sharpeners/softerens/etc) to make image look/make-up you like. Simply work as program director. For each program different look/make-up may be used in fine details of the image. In medium and large size details generally all types of resizers make equal result.

" just need to understand if that parameter means that it automatically converts to linear RGB when resampling or not. Any idea?"

If it says
sigmoidize, linearize
Default: True.

it looks both convert to linear domain and to sigmoid domain are enabled by default.

"Whati is sigmoidization?"

Additional non-linear transfer domain. Created by some developers in the past for image resizing.

Try to look into imagemagic documentation.
AI Overview
ImageMagick offers a technique called "sigmoidal contrast" that can be applied before or during resizing to improve the visual quality, particularly for enlarging images or when dealing with certain types of content like line drawings or CG art. This technique applies a sigmoidal curve to the image's colorspace, effectively enhancing contrast in mid-tones while compressing highlights and shadows.

Applying Sigmoidal Contrast in ImageMagick:
The primary option for applying sigmoidal contrast is -sigmoidal-contrast <geometry>, which is used with the convert command. The geometry argument takes two values:
factor: This controls the amount of contrast enhancement. Higher values result in more pronounced contrast.
midpoint%: This specifies the point along the color range (from 0% to 100%) where the most significant contrast enhancement occurs. For example, 50% would center the enhancement in the mid-tones.

May be look as S-shaped transfer function.

[LigH]

Wikipedia: Sigmoid function (https://en.wikipedia.org/wiki/Sigmoid_function)

Helpful to limit infinite input ranges to finite output ranges. Also known as "soft clipping" in audio tasks.

[real.finder]

I have some questions about MT in avs+

is MT_SERIALIZABLE single thread? what cpu core will be used if there are more than one MT_SERIALIZABLE filter in the encoding script? if it always CPU 0 (first core) then will it better if it switch core (thread) for every filter that MT_SERIALIZABLE?

also IIRC in old avs mt
if we have for example:-
source call (MT_SERIALIZABLE)
some MT_MULTI_INSTANCE filter
another MT_MULTI_INSTANCE filter
yet another MT_MULTI_INSTANCE filter
some MT_NICE_FILTER filter

It was advised not to repeat "setmtmode(2)" for every filter since this may affect performance
so it will be like

setmtmode(3) #set mode to MT_SERIALIZABLE
source call
setmtmode(2) #set mode to MT_MULTI_INSTANCE
some MT_MULTI_INSTANCE filter
another MT_MULTI_INSTANCE filter
yet another MT_MULTI_INSTANCE filter
setmtmode(1) #set mode to MT_NICE_FILTER
some MT_NICE_FILTER filter

so the question now how avs+ deal with this case?

[takla]

I have some questions about MT in avs+


http://avisynth.nl/index.php/SetFilterMTMode#Choosing_the_correct_MT_mode

See also the "Example" section of that link.

SetFilterMTMode("FFVideoSource", 3)
or
SetFilterMTMode("FFVideoSource", MT_SERIALIZED)

[real.finder]

http://avisynth.nl/index.php/SetFilterMTMode#Choosing_the_correct_MT_mode

See also the "Example" section of that link.

SetFilterMTMode("FFVideoSource", 3)
or
SetFilterMTMode("FFVideoSource", MT_SERIALIZED)

already know this, it's not what I asked about

[qyot27]

Prefetch can be used multiple times in-script to alter the threading use per-filter. AFAIK, avoiding bottlenecks still requires structuring the script such that easily-scalable-threading doesn't get clogged up by other filters that don't scale nearly as well, regardless of what you actually do with Prefetch.

The correct part of the Wiki article was this, which notes the change in behavior and demonstrates multiple uses of Prefetch:
http://avisynth.nl/index.php/SetFilterMTMode#Prefetch

Controlling which CPU gets the task is something I imagine requires a much more robust level of device awareness*, and what actually controls that right now would have to be the OS's thread scheduler. Core-wise, I do know that on the Apple M1 (4P+4E), macOS prefers allocating the P cores to the process before the E cores, so Prefetch(4) will use the Performance cores, and only when you request more than that will it activate the Efficiency cores. I would presume most OSes act the same way, but I don't have any other Windows or Linux devices with heterogenous chips in them to actually test it.

*this is actually one aspect of several that I consider to be what a future bump to 3.8 would entail, btw



The behavior of the old MT fork isn't directly comparable to the way Plus does it. The old fork would change the threading model across the entire core, so multiple calls to SetMTMode had to be inserted between filters that had different scalability. Plus tethers the threading model to the individual filter and switches as necessary. Planning scripts in an optimal way is still required to avoid bottlenecks, but the fine threading control is delegated to Prefetch (hence the summary above this), not to changing the entire core's MT mode.

[real.finder]

Controlling which CPU gets the task is something I imagine requires a much more robust level of device awareness*, and what actually controls that right now would have to be the OS's thread scheduler.

thanks for the detailed information!

so, if there are 2 MT_SERIALIZED filters in-script, they will use the same thread? will this be changed in the future?

[DTL]

Filters (external plugins) can use their own multithreading. The MT_SERIALIZED only (at least ?) ensures the AVS+ core will send (request ?) frames in sequential order to single only instance of a filter in a total filter graph. This is important for filters with temporal processing. In other MT modes AVS+ core creates several instances of a filter and splits the total frame number to process to some blocks and process in different threads. This causes a random number of frames processed by each instance of a filter (with blocks like cache number of frames requested in Prefetch()) and can break the design of temporal filters.

So if filter need to do temporal processing it tries to request MT_SERIALIZED mode (like MAnalyse with temporal=true).

[rgr]

Filters (external plugins) can use their own multithreading. The MT_SERIALIZED only (at least ?) ensures the AVS+ core will send (request ?) frames in sequential order to single only instance of a filter in a total filter graph. This is important for filters with temporal processing. In other MT modes AVS+ core creates several instances of a filter and splits the total frame number to process to some blocks and process in different threads. This causes a random number of frames processed by each instance of a filter (with blocks like cache number of frames requested in Prefetch()) and can break the design of temporal filters.

So if filter need to do temporal processing it tries to request MT_SERIALIZED mode (like MAnalyse with temporal=true).

So what would a sample script with such a filter look like, for example, this one?

BSSource("input.mp4")
crop(...)
QTGMC(NoiseProcess=1,(...),TR=3)
lsfplus
Levels(...)

I've noticed that simply adding Prefetch to the end of such a script causes random frames to have errors (appearing to be decoding errors, e.g., part of the frame shifted to the right/left).

[DTL]

" part of the frame shifted to the right/left"

I not sure if QTGMC uses MAnalyse with temporal predictors enabled (may be at some preset ?) . If even temporal predictors enabled and not serialized MT mode used it expected to cause only very slight degradation of motion estimation quality (but at the repeating pattern of the frames).

Temporal predictors are the previous frame motion vectors. They are not present only for 0 frame of a clip in normal (serialized) mode. But in group of frames MT mode (standard) they are invalid (not present) for each starting frame of a group (of cache number of frames ?) and this can cause some repeatable ME quality degradation in total clip.

To test it you can simply enable and disable temporal predictors for MAnalyse and try to force different MT modes with SetMTMode().

From mvtools documentation:

temporal

Use temporal predictors from previous frame motion vectors. Not compatible with SetMTMode (classic Avisynth) or other than MT_SERIALIZED mode for Avisynth+, and requires a linear access to work correctly. Note: Since 2.7.32 the filter registers itself automatically MT_SERIALIZED instead of MT_MULTI_INSTANCE under Avisynth+ when temporal=true is given.

[ENunn]

i'm having an issue with some of my script encodes. i don't know if this is a plugin bug or an avisynth bug or what

whenever i use a plugin that adds grain i'm getting a glitch that shows up for only one frame, and it only happens in my encodes.

https://i.imgur.com/0TdaFqn.png

this does NOT show up when i preview my script in avspmod.

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

i have tried using multiple grain plugins (f3kdb, addgrainc, neo_dfttest's dither function), encoding to multiple codecs in ffmpeg (x264, prores, utvideo), and i have also tried encoding in virtualdub, and they all have the same issue. it seems like the only fix for it is to lower the prefetch value or not use prefetch at all.

i don't know if anyone else has this problem, but i figured i'd share whats going on on my end.

[Boulder]

You could try using something like Preroll(10) right after your source loading line.

[ENunn]

You could try using something like Preroll(10) right after your source loading line.

didn't fix it unfortunately

[Emulgator]

Post your script. Try different source filters.

[poisondeathray]

whenever i use a plugin that adds grain i'm getting a glitch that shows up for only one frame, and it only happens in my encodes.


If you encode it several separate times, does the glitch always occur on the exact same frame in the same position? Or is it a random distribution , or maybe more than 1 frame and you didn't see it?

Also check your cpu / hardware temperatures during encoding and perform HW stability checks . A single frame preview in avspmod is not going to "tax" the system as much as full encoding . No prefetch is going to be less resource intensive than prefetch(high number)

[ENunn]

Post your script. Try different source filters.

LoadVirtualDubPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\ccd_64bit.vdf", "ccd", 0)
v = AVISource("i:\virtualdub\fix\vhs\opening to blind fury 1992 vhs.avi")
a = lwlibavaudioSource("i:\recordings\opening to blind fury 1992 vhs.flac")
audiodub(v,a)
preroll(10)
#delayaudio(.100)
#delayaudio(.150)
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
Levels(30, 1,940, 0, 1020, coring=false,dither=true).tweak(bright=0, cont=1.00, hue=-0, sat=0.850, coring=false, dither=true).convertbits(8)
#turnRight().Histogram().TurnLeft()
Trim(291, 3042)
Mergechroma(separatefields().vinverse().weave())
converttorgb32(matrix="rec601", interlaced=true,chromaresample="point")
e=separatefields().selecteven().CCD(5,0)
o=separatefields().selectodd().CCD(5,0)
interleave(e,o).weave()
converttoyv24(matrix="rec601", interlaced=true,chromaresample="point")
qtgmc(preset="Faster", tr2=2, ezdenoise=0.0, sharpness=0.0, sourcematch=3, border=false)
neo_dfttest(sigma=5, tbsize=3)
LSFplus(ss_x=1.5, ss_y=1.5, secure=true, Spwr=2, SdmpHi=0, soothe=false, preblur="on", keep=25)
FineDehalo(rx=2.5, ry=2.5)
neo_f3kdb(grainy=64, grainc=64, dynamic_grain=true)
converttoyv12(matrix="rec601", interlaced=false,chromaresample="point")
prefetch(10)

tried lwlibavvideosource, had the same result

If you encode it several separate times, does the glitch always occur on the exact same frame in the same position? Or is it a random distribution , or maybe more than 1 frame and you didn't see it?
nope. it's different every time. when it shows up its only for a frame but i wouldn't be surprised if it shows up multiple times on the encode. i haven't really checked the whole video.

Also check your cpu / hardware temperatures during encoding and perform HW stability checks . A single frame preview in avspmod is not going to "tax" the system as much as full encoding . No prefetch is going to be less resource intensive than prefetch(high number)

everything's cool and stable.

[DTL]

Can we enable multi-processor compilation for Visual Studio (at least) for AVS+ in the cmake settings ? If it not cause additional bugs it is visibly faster in the initial building of the project.

[real.finder]

nope. it's different every time. when it shows up its only for a frame but i wouldn't be surprised if it shows up multiple times on the encode. i haven't really checked the whole video.


maybe one filter you use has wrong mt mode, maybe ccd

[qyot27]

Can we enable multi-processor compilation for Visual Studio (at least) for AVS+ in the cmake settings ? If it not cause additional bugs it is visibly faster in the initial building of the project.
It's the user's job to select an appropriate number of parallel jobs when they build the project; we should not be in the business of making any assumptions about that. There is no one-size-fits-all setting - even in the current/near future generation of CPUs, what works as a reasonable value for a 9850HX won't fit Nova Lake, to say nothing of any recent Threadripper PRO or Epyc or Xeon.

Other CPU architectures (and x86, if using MinGW or Linux/macOS/BSD/Haiku) already have Ninja if you want full core saturation by default. And while it isn't a concern with AviSynth+, in principle, setting the number of parallel jobs too high can cause problems in the build tools themselves if you don't have enough RAM. The llvm-mingw compilation process will repeatedly die after a while on a Samsung Galaxy Book4 Edge (Snapdragon X Elite X1E-80-100, 12 cores, 16GB RAM) if allowed to just use all cores, because it will run out of memory.

[ENunn]

maybe one filter you use has wrong mt mode, maybe ccd

nah this has been happening long before i started using ccd. i posted about this issue before on both videohelp and doom9. here's a post i made of it happening on an older script.
(https://forum.doom9.org/showthread.php?t=185782) at first i thought it was the median filter causing it, but nah its something with all the plugins i've tried that add grain.

[real.finder]

nah this has been happening long before i started using ccd. i posted about this issue before on both videohelp and doom9. here's a post i made of it happening on an older script.
(https://forum.doom9.org/showthread.php?t=185782) at first i thought it was the median filter causing it, but nah its something with all the plugins i've tried that add grain.

maybe post a minimal script with small sample that causing it so we can see what is the problem

[DTL]

It's the user's job to select an appropriate number of parallel jobs when they build the project; we should not be in the business of making any assumptions about that. There is no one-size-fits-all setting - even in the current/near future generation of CPUs, what works as a reasonable value for a 9850HX won't fit Nova Lake, to say nothing of any recent Threadripper PRO or Epyc or Xeon.



Eh - I mean we have a simple switch like on or off in Visual Studio project settings :

https://i.ibb.co/5XcZ9ghY/2025-11-07-101416109.png (https://ibb.co/V0B6NcYH)

It looks /MP compiler option only and no more adjustments. With current cmake project generation it looks this option is missed and compilation takes only 1 core and slower. With this setting enabled the compiler auto-selects everything and task manager shows all cores loaded and compilation going faster. If this not causes any issues it expected to be enabled.

Also it is *nice to have* .editorconfig file for Visual Studio to set even strings formatting. pinterf made this file for mvtools project:

root = true

# NOTE: editorconfig-core-c has a hardcoded limitation of 50 chars per .ini section name

[*.{cpp,h,hpp,c,asm,hlsl}]
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
end_of_line = crlf
insert_final_newline = true

[Sources/fstb/*.{cpp,h,hpp,c,asm}]
indent_style = tab
tab_width = 3
[Sources/conc/*.{cpp,h,hpp,c,asm}]
indent_style = tab
tab_width = 3

[*.md]
indent_style = space
trim_trailing_whitespace = false


After using of the project files from current cmake generator it looks default Visual Studio settings not match AVS+ files and strings tabs spaces (ident_size ?) are bigger. And may be hidden CR/LF at the end of lines not match too.

[DTL]

i'm having an issue with some of my script encodes. i don't know if this is a plugin bug or an avisynth bug or what

whenever i use a plugin that adds grain i'm getting a glitch that shows up for only one frame, and it only happens in my encodes.

https://i.imgur.com/0TdaFqn.png

it seems like the only fix for it is to lower the prefetch value or not use prefetch at all.

i don't know if anyone else has this problem, but i figured i'd share whats going on on my end.

Looks like some part of processing may have issues with multithreading (not correct lock of buffers to process or other).

I got somehow similair look of the frame when I test not MT-friendly implementation of filter in AVS+ core.
https://i.ibb.co/XrVyrRrP/2025-11-08-104614796.png (https://ibb.co/DHLGH2HF)

Try to decrease number of filters in script to make smallest possible script with same issue to attempt to narrow filter with this issue.

The next sad feature found with this implementation: After script load (access from frame 0 in VirtualDub) or any random seek operation system return some sequence of corrupted frames but if continue making sequential frame access over about (MT cache number ?) frames - the distortions stops and next frames returned OK. As I remember I have very close looking issue with first several corrupted frames with mvtools2 encodings. But at the long footage with slow start from black frames it is not very annoying. But the source of these errors may be close like some still present issue in AVS+ multithreading. It is at least subject to note.

If tested with Prefetct(4,1) instead of Prefetch(4) - the number of corrupted frames become significantly lower (like about 2..3). As I remember deafult cache number of frames is threads x2 (?) so Prefetch(4) equal to Prefetch(4,8) (?). It looks like something going out of sync at clip start or random seek operation and going in sync after about cache_number_frames sequential access. Even if some non-MT correct implementation in the filter exist.

Some working tech demo of planes-sequential processing workflow for AVS+ filters created: Idea description https://github.com/AviSynth/AviSynthPlus/issues/460 and current sources and release for test with Invert() filter example - https://github.com/DTL2020/AvisynthPlus-plane-base-filter-example/releases
Old AVS and AVS+ filtergraph uses frame-based (full structure of planes) dataflow between filters and this causes worse data locality in CPU caches and performance degradation. Better performance solution (for compatible filters) is process single plane in a sequence of compatible filters.

Complete implementation requires both redesign of AVS+ core and some changes in compatible filters. This API update do not change plane processing core of the filters and only changes processing order of the planes in the filtergraph. So required redesign of filters is not very much. Mostly addition of 2 new methods of connecting filters with partial frame processing (first plane) and requesting of each residual plane processing from output filters to input filters via filtergraph.

[Emulgator]

Good find, DTL.

[rgr]

" part of the frame shifted to the right/left"

I not sure if QTGMC uses MAnalyse with temporal predictors enabled (may be at some preset ?) . If even temporal predictors enabled and not serialized MT mode used it expected to cause only very slight degradation of motion estimation quality (but at the repeating pattern of the frames).

In addition to shifting parts of the image, there are also errors like this one -- part of the image simply becomes a black spot.

https://gcdnb.pbrd.co/images/U0SLZXSG7DK8.png?o=1

[DTL]

New testbuild to play with - https://github.com/DTL2020/AviSynthPlus/releases/tag/post-3.7.5_m1_test5

Finally working implementation with multithreading and manual control of size of the part of the plane to process in between sequence in filtergraph via new script function.

Test script:

SetRowsRegionSize(32000)

ColorBarsHD(2500, 1000)

Invert()
Invert()
Invert()
Invert()
Invert()
Invert()
Invert()
Invert()

Prefetch(4)


Test results at i3-2120 CPU (128k L1 (32k per each of 4 cores ?), 512k L2, 3.0MB L3 caches) :

For 8 Invert() in a sequence and Prefetch(4) - AVS+ 3.7.5 release 123 fps.
Test 5 release depending on SetRowsRangeSize() setting:
1024k - 130fps
512k - 272 fps
256k - 336fps
64k - 405 fps
32k - 412 fps

It looks best optimized for about 1/4 of L1 cache size (if it is enough in size like 32k and more ? or L1 cache size of each core ?). Max performance increases about 3.34x in comparison with full frame all planes cycling in each filter (with frame size 2500x1000 and YV24 format of 4:4:4).

Need to make program text smaller in next versions and attempt to add the same processing modes in some more visible results filters like Levels(). A sequence of Invert() are not clear to check if they are all really processing all parts of each frame in a sequence.

Currently this tech demo only supports simple fiter chains without splitting of output clips to several consumer filters. Standard filters expected to use standard GetFrame() connection pin/method. But new filters need to solve this issue (they currently ask sources about available best performance modes and will try to put requests on partially processed frames/planes).

[ENunn]

maybe post a minimal script with small sample that causing it so we can see what is the problem

lwlibavvideosource("path\to\file.mkv", fpsnum=30000,fpsden=1001,rap_verification=false,prefer_hw=3)
assumetff()
qtgmc(preset="Faster", tr2=2, ezdenoise=0.0, sharpness=0.0, sourcematch=3, border=false)
neo_dfttest(sigma=5, tbsize=3)
neo_f3kdb(grainy=64, grainc=64, dynamic_grain=true)
prefetch(10)

i don't think a small sample isn't gonna show my issue consistently. but here's a link to one though. (https://mega.nz/file/nglGBbyZ#OyQngGohJHphtNiwG13kpK3P44ch5hVHwOhXgvuzoFw)

i did an encode with prefetch set to 3. the glitching STILL HAPPENS!! i don't get it. this is a different source but the issue still applies.
https://i.imgur.com/quOTuJT.png

good info dtl!!

Try to decrease number of filters in script to make smallest possible script with same issue to attempt to narrow filter with this issue.

i did some tests. i made separate scripts. one with only qtgmc, one with only qtgmc and neo_dfttest, one with only qtgmc and neo_f3kdb, and one with qtgmc, neo_f3kdb, and neo_dfttest.

qtgmc - no glitching
qtgmc and neo_dfttest - glitching
qtgmc and neo_f3kdb - no glitching
qtgmc, neo_dfttest, and neo_f3dkb - i didn't notice any glitching on this encode but as mentioned before, it happens randomly and the glitches are different every time. it could also be happening in dark scenes and i don't notice it.

so it looks like it ISN'T the grain plugins that are causing it, but neo_dfttest. welp, time for a new denoiser.

[real.finder]

so it looks like it ISN'T the grain plugins that are causing it, but neo_dfttest. welp, time for a new denoiser.

seems its old problem https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest/issues/6

[DTL]

Looks like edges of some blocks are damaged (zero YUVs and green spots ?) and blurred to internals of the block. Though sometime black spots blurred from edge of the block.

[real.finder]

Looks like edges of some blocks are damaged (zero YUVs and green spots ?) and blurred to internals of the block. Though sometime black spots blurred from edge of the block.

it seems, anyway here what I find about it https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest/issues/6#issuecomment-3536772841

[ENunn]

thanks for the solutions!! unfortunately performance tanks when i add the things you posted on the github. my script was 10fps before, now it's 4. not 100% sure why.

[DTL]

Someone need to make test build from latest sources with that commit about threads lock. May helps. But I do not see build instructions with Visual Studio. No project files. No cmake.

[pinterf]

seems its old problem https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest/issues/6

The fftw library planner function is not thread safe. A simple instance of plugin can make it thread safe on its own. But when there are multiple instances and/or different plugins that use fftw DLLs, they can still mess into each others planner.

Avisynth's new v12 interface can help with this topic, if they use the same "global lock", different instances and plugins can safely work together.

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/Cplusplus_api.html#cplusplus-acquiregloballock

The original issue:
https://github.com/AviSynth/AviSynthPlus/issues/444

My old fft3dfilter repo got this update as well.
https://github.com/pinterf/fft3dfilter/commit/599632e3878caaf7aab93d822cc3a426b4003fbc

[pinterf]

Overlay add/remove got 32-bit float and direct RGB support.

So here is a long-time-no-see test build from me, Avisynth r4335.

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

For the change list, check readme inside, or the usual https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

Built with Visual Studio 2026, I wonder if people with ancient (or not so ancient) systems can use them without problem. The XP build are with MSVC, the non-XP ones were built with clang-cl (LLVM) option.

Theoretically the Microsoft Visual C++ redistributable - which is not part of this pack (called now "Visual C++ Redistributable v14") - is still general for v14 compiler families (2017-2026):
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-c-redistributable-v14
(remember: the redist XP support stopped at an old specific version)

Give feedback, please, whether it works on pre-Win10 systems.

[tebasuna51]

...
So here is a long-time-no-see test build from me, Avisynth r4335.
...
Give feedback, please, whether it works on pre-Win10 systems.

Problems with old W10 versions mine is (Build 14393)
AvsInfo checks:

[LigH]

No surprise that a recompilation with a newer Visual Studio may require newer MSVC runtimes. Installing e.g. the recent AIO repack should help.

[StainlessS]

Posted by seagate yesterday:- Repack – Visual C++ redistributable runtimes v.0.103.0 – by abbodi1406 (https://gitlab.com/stdout12/vcredist/-/releases/v0.103.0//)

[jpsdr]

The new v14 redistributable (14.50) doesn't install on Windows 7, but i don't know if it's mandatory for VS2026 builds, or if the last 2022 (14.44.35211) is still enough.
I'm still making my AVS build with VS2019 and LLVM.

[v0lt]

pinterf
What version of InnoSetup will you be using in the next release?
I'd like to try fixing the display of the license text in the Russian localization.

[qyot27]

x86 releases are still on Inno Setup 5. ARM releases are on Inno Setup 6, because there's no point in maintaining installer compatibility with ancient, long past EOLed OSes for legacy reasons on an architecture they were never available for.

[pinterf]

New test build. 32/64 bit,

A Clang-cl (LLVM) build and an XP (MSVC) build as well.

Avisynth+ v3.7.6pre-r4356 test build
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4356

Changes since last week:

- add AVX512 VNNI flag (avisynth.h, avisynth_c.h)
- make Info() more compact when displaying AVX512 flags.
- optimize horizontal 32-bit float small (<=4) kernel size
- optimize 32-bit float vertical avx2
- Add mechanism (cache hint) to inform a filter about the effective number of threads when Prefetch is called.

Check full change list and additional info links here:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

[jpsdr]

Just to be sure, it's still not possible to know the Prefetch value during the "Create" stage ?

[DTL]

It is expected to be possible. It is designed to inform filter about threads number so filter can configure itself for best performance before processing start. Though how to be sure this already was set by environment may be not clear.

May be the only good time (but a bit later) is to check
num_threads at the beginning of GetFrame() method and select required processing way.

From example:

class ConvertToRGB : public GenericVideoFilter {
private:
int num_threads; // initialize it, since CACHE_INFORM_NUM_THREADS is not called if no Prefetch is used
...
int __stdcall SetCacheHints(int cachehints, int frame_range) override {
if (cachehints == CACHE_GET_MTMODE) return MT_NICE_FILTER;
if (cachehints == CACHE_INFORM_NUM_THREADS) {
num_threads = frame_range;
}
return 0;
}

- the class member num_threads expected to be initialized by environment (if Prefetch is set to >1 for this script area) before first call to GetFrame() of this class (?). So default init value at class constructor may be = 1 (or any other required default in the fiter). And if Prefetch > 1 is set - its value will be increased (set) by calling of SetCacheHints(CACHE_INFORM_NUM_THREADS, Prefetch_num).

[jpsdr]

Unfortunately it's too late, i create my threadpools in the "Create" stage. Anyway, it was just for being able to have an "automatic" value in my prefetch parameter. There was not until now, it will just stay the same.

[pinterf]

Just to be sure, it's still not possible to know the Prefetch value during the "Create" stage ?

Yep, I thought that it will be too late. I thought, you could still create the thread pool, but when Prefetch signals to your filter the actual "mt go live" thread count, then you can somehow rearrange this-or-that and set back the process to work with 0..height-1 limits again, instead of feeding your own threads with the partial stripes.

Anyway, the feature is there...

[DTL]

May be simply add one more function to IScriptEnvironment like GetThreadsNum() ? And user can call it from class constructor if required.

[pinterf]

May be simply add one more function to IScriptEnvironment like GetThreadsNum() ? And user can call it from class constructor if required.
When a class is created, the future thread count is not known. It only turns out when Prefetch is reached, and at this point all filters before the Prefetch will be informed about the actual count.

[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.

P.S. My C:\Windows\SysWOW64\MSVCP140.dll: 14.29.30156.0

[pinterf]

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/cpp/windows/latest-supported-vc-redist?view=msvc-170#latest-supported-redistributable-version

[aarv]

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

[pinterf]

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/AviSynthPlus/releases/tag/v3.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/en/latest/avisynthdoc/changelist376.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]

New build, Merry Christmas!
Likewise!
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 (https://github.com/Irrational-Encoding-Wizardry/descale).
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]

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]

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]

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/AviSynthPlus/blob/362477cb9c67c3f54dd40d56efb990fc77dad9e9/avs_core/filters/intel/resample_avx2.cpp#L1806 . May be already some implementations in 2026.

[tormento]

AVS resizers also do not support different user-defined border handling processing.
That's why I "miss" them ;)

[qyot27]

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 (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt) 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 (https://stackoverflow.com/questions/67456720/vscode-c-c-intellisense-with-clang-mingw)). 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 (https://www.msys2.org/docs/arm64/), but Windows 11 resolves that by using an emulator (same as Rosetta on macOS, or FEX (https://fex-emu.com/) - 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 (https://github.com/mstorsjo/llvm-mingw) 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 (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/docs/english/source/avisynthdoc/contributing/avsplus_external_deps_guide_manual_arm.rst) 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 (https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-soundtouch/PKGBUILD) and DevIL (https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-devil/PKGBUILD) 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)

[Emulgator]

Win10P64 i9-11900K Avs r4392 x86_64 runs ok.
Win10P64 i9-11900K Avs r4392 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 "official" AviSynth.dll (4289.375) x86 runs ok.

My C:\Windows\SysWOW64\MSVCP140.dll: 14.29.30156.0 (was the same with AccessViolation of r4356)

---------------------------------------------------------
2004 DELL XPS M1710 (Core2Duo T7600G, 4GB) Dual-boot, first into WinXPPro32SP3:
AvsPmod32 2.7.9.4, one-liner source script
FFMS2("path\file.mp4",-1,-1)
Avs+ r4289 x86 runs ok.
Avs+ r4335 x86 runs ok.
Avs+ r4356 x86 runs ok.
Avs+ r4392 x86 runs ok.
Many thanks, pinterf !
--------------------------------------------------
Same 2004 DELL XPS M1710 (Core2Duo T7600G, 4GB) Dual-boot, other boot into Win7P64SP1:
AvsPmod32/64 2.7.9.4, same one-liner source script
FFMS2("path\file.mp4",-1,-1)

Avs+ r3961 x86 runs ok.

---------- "Official" 3.7.5, many thanks, qyot27 and pinterf !------

Avs+ r4289 x86 XP32 runs ok, plus the non-xp run ok !
Avs+ r4289 x64 XP64 runs ok, plus the non-xp run ok !

3.7.5 seems to be the gold standard of compatibility for me.

---------- pinterf test versions, many thanks, pinterf ! -------

Avs+ r4335 x86 XP32 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"
Avs+ r4335 x64 XP64 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"

Avs+ r4356 x86 XP32 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"
Avs+ r4356 x64 XP64 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"

Avs+ r4392 x86 XP32 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"
Avs+ r4392 x64 XP64 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"

Together with those x86 build crashes it looks to me as if the concerning compilation environment is generating builds departing from that universal compatibility.
---------------------------

Further tests on a "proper one-trick pony" 2009 i940XM 8GB Win7U64 to follow...
Seems to confirm these findings: 3.7.5 is the gold standard of compatibility.
Avs+ r4392: the non-xp versions x86 and x64 suffer from "procedure entry 'CreateFile2' missing in Kernel32.dll", even on Win7 and a newer CPU.

[pinterf]

Thank you
In 2024 there was a binary change how mutexes are working. Old redistributables are not compatible with MS toolsets from end of 2024. This is the mutex crash, which is not win7 and vs2026 specific, you just need to refresh the too old redistributables. I will figure out which is the first working version. Search for: c++ mutex lock crash.
Second part: missing CreateFile2 means that Win7/8.1 support is dropped in both VS2026 and the 14.50.xx redistributable. I suppose the v145 toolset requires that. Win7 compatible builds should use v143 toolset, I guess not the last one but have to find the specific version number and only use that.
Btw the xp toolset is way too old, it does not allow using new (c++20) elements, fully incompatible. It takes 65 minutes to build one dll. For the incompatibility reason I'd like to drop it, if not in the next release, but in the next-next for sure. It will be enough to keep Win7 compatibility.

[jpsdr]

The last working Windows 7 redistributable is 14.44.35211, if it's what you want to know.

[pinterf]

The last working Windows 7 redistributable is 14.44.35211, if it's what you want to know.
Thanks, we'll register it, just like the latest XP compatible one.

Regarding the "mutex lock crash", it's there, since June, 2024, which belonged to VS 2022, toolset 17.10.
https://github.com/microsoft/STL/issues/4730

The toolset's baseline version is 14.39.32551.0, so with old redistributables prior to this version our program will crash in mutex related code.

Then the Win7 compatibility.

The last Windows 7 compatible Visual Studio 2022 version was 17.7: toolset version v143 (14.37.xxxx)

Since toolset v143 (14.38.xxxx) the programs will not work on Windows 7.

Not to mention VS2026 which started with toolset v145 (14.50.xxxxx-).

(VS2026 can use older toolsets as well, if they are selected)

[pinterf]

Avisynth new build.
20251223 3.7.5.r4400 (pre 3.7.6)
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4400

20251223 3.7.5.r4400 (pre 3.7.6)

- Resamplers, horiz. float, add back DTL2020's new quick algorithms for kernel size <= 4. Since MT is not their forte, use the generic resamplers if Prefetch > 1.
- AVX512 float resampler additions, optimize horizontal (kernel size <= 8), add code for vertical (DTL2020)
- Fix an ApplyMessage regression not recognizing '\n' line ends of Authors.avs (since 20250831)

XP build still exist.
Non-XP version is built with clangcl (LLVM).
Windows 7 not supported.
Needs fresh VC14 redistributables. Get latest V14 redistributable from here (permalink to the .exe):
https://aka.ms/vc14/vc_redist.x64.exe

[flossy_cake]

I've been using AVSMeter (benchmarking tool) to try and understand when the frame cache comes into play to boost performance.

Suppose we do:


SelectEvery(1,0,0) # double the fps with duplication
BicubicResize(3840,2160)


Would the frame cache see that BicubicResize has already generated an upscaled frame for the duplicate and just re-use the same output frame? Is that how it works? Because in AVSMeter tests I am getting conflicting results - in some cases I see a gain, in others I don't.

:thanks:

[StainlessS]

See CacheTest,


CacheTest(), by StainlessS @ Doom9. https://forum.doom9.org/showthread.php?t=184920

CacheTest(clip c, String "text"="", String DvChar="", Bool "Always"=False, Bool "Silent"=False)

CacheTest() Sends text message to DebugView when requested frame is "Out Of Sync", ie not previous frame + 1.
Insert between filters to see if there are any repeat requests for frame, or out of sync frame requests.

Requires DebugView, [ DebugView v4.90, @ Micro$oft:- https://learn.microsoft.com/en-us/sysinternals/downloads/debugview ]
DebugView captures debug messages on your local machine (or network) and shows them in a window, can also save to file.
These messages may be output by the system, or eg graphics card driver, or some other program on a machine.
[really annoying when nVidia floods debug logs in some supposedly non beta drivers].
You can add a DebugView Filter via DebugView Edit menu, to only capture debug message lines containing some substring eg ":",
so that you only see the lines containing that substring, but you would then need to ensure that your debug messages also contain ":".
NOTE, RT_Stats plugin has RT_Debug() and RT_DebugF() functions for outputting script debug Info in real time during Filter Graph creation
stage, or during frameserving from within the Runtime environment (eg ScriptClip).
All RT_Debug/RT_DebugF messages contain a COLON character.

Args:

Text, Default "".
Allows add some kind of text label to the Title string that is output to DebugView.
Where CacheTest filter Instance is 3, and Text="PorridgeOats", and DvChar="", then
the Title output would be "CacheTest_0003_PorridgeOats:". (Ends with SINGLE COLON, ':')

DvChar, Default "".
Where CacheTest filter Instance is 3, and Text="PorridgeOats", and DvChar=":", then
the Title output would be "CacheTest_0003_PorridgeOats::". (Ends with DOUBLE COLON, ':')
The DvChar is inserted after the always present 1st ":" character, it allows to set
a more specific DebugView filter string, so as to only see CacheTest debug messages in DebugView.
Some messages sent to DebugView may not involve a COLON, some do use a COLON, you can eg set
DvChar to ":" so that only DebugView messages containing "::" will be captured, or can set some other character following ':'.
(You could even set DebugView filter to eg "CacheTest" if required, or even "PorridgeOats").

Always, Default False.
True = Output all frame requests debugview.

Silent, Default False.
True = switch off ALL messages (overrides ALWAYS).
Leaves an additional Cache between filters, without writing messages to DebugView.

Shows messages as in
"CacheTest_0005_Node_A1: 1001] *** REPEAT REQUEST {RepeatCnt=7, OSyncCnt=21}"
where there is a repeat request for CacheTest instance 0005 where Text="Node_A1",
@ frame 1001, and total Repeat Count = 7, and Out Of Sync Count = 21.
OR,
"CacheTest_0003_Marmalade: 873] *** OUT OF SYNC REQUEST, Previous=884 {RepeatCnt=7, OSyncCnt=21}"
where there is an Out Of Sync request for CacheTest instance 0003 where Text="Marmalade",
@ frame 873, where previous request was for frame 884, and total Repeat Count = 7, and Out Of Sync Count = 21.

############################################

Example:
Return Colorbars(Pixel_type="YV12").KillAudio.CacheTest()


Untested

Last="..."

ALWAYS=True

CacheTest(Text="Cache_SOURCE_A",Always=ALWAYS) # I expect Source filter caching to occur here !!! (due to double request in below SelectEvery)
SelectEvery(1,0,0) # double the fps with duplication
CacheTest(Text="Cache_SELECTEVERY_B",Always=ALWAYS)
BicubicResize(3840,2160)
#CacheTest(Text="Cache_BICUBIC_B",Always=ALWAYS)
Return Last

[flossy_cake]

@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?

Revisiting AVSMeter using the upscaling example, it looks to me like Avisynth isn't getting it from the cache when doing a synthetic test with no other filters in the pipeline. But with other more "real world" tests where multiple other filters are in the pipeline, I see almost no performance difference whether I do the framedoubling before/after the upscaling. But I think that is just because of bottlenecks to do with other filters still waiting to finish. If I get rid of all other filters then it seems performance drops by roughly half when moving the upscaling to after the framedoubling which is consistent with upscaling twice as many frames which means no caching.

[DTL]

It looks old full-blood Xeon Golds like 613x are not detected as 'fast' and AVX512 processing not enabled. Can we force CPUF_AVX512_FAST from script ?

[pinterf]

It looks old full-blood Xeon Golds like 613x are not detected as 'fast' and AVX512 processing not enabled. Can we force CPUF_AVX512_FAST from script ?

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

[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 },

[pinterf]

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
Thanks, obviously I missed it on a copy-paste session. Also, http://avisynth.nl/index.php/Convert is O.K.
In a next rstdoc update will include the fix.

[v0lt]

I'd like to clarify the GetFrame method.
Older VSFilters didn't throw exceptions in GetFrame, and it simply didn't work. The newer xy-VSFilter raises a ThrowError if it doesn't support the video format (https://github.com/pinterf/xy-VSFilter/blob/053d9321541f73ffe2fe3900a7e356517fd44c03/src/filters/transform/vsfilter/plugins.cpp#L1280), which causes many applications (FFmpeg-based) to crash.
Example script.
LoadPlugin("c:\temp\XySubFilter\VSFilter.dll")

Colorbars(1280, 720)
ConvertToPlanarRGB()

TextSub("c:\temp\test_subtitles.srt")
In my ScriptSourceFilter, the call to PClip::GetFrame is inside a try-catch block (https://github.com/v0lt/ScriptSourceFilter/blob/4156b65eb64809a64f035b202851c8c8e7f7119b/Source/AviSynthStream.cpp#L194), but that doesn't help (or am I doing something wrong).

Is this an application issue or an xy-VSFilter issue?

[wonkey_monkey]

AvisynthError isn't derived from std::exception, so your code won't catch it (I think).

(Not sure why xy-VSFilter isn't checking the format in its constructor...)

[v0lt]

AvisynthError isn't derived from std::exception, so your code won't catch it (I think).
Thanks. I forgot about that again. I fixed it (https://github.com/v0lt/ScriptSourceFilter/commit/9a649e93c7c828fe9785f5b731bafc2f9d6e7731).

But this does not work with avformat_open_input (https://github.com/v0lt/avlib_vdplugin/blob/3392c6a03958a66bae63ddd5586e083b12ae591b/src/InputFile2.cpp#L725).

Added:
(Not sure why xy-VSFilter isn't checking the format in its constructor...)
Thanks. It works (https://github.com/v0lt/VSFilter/commit/182d0f395d62224bafae4e92de44893960c3456e)!

[pinterf]

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

20260203 3.7.5.r4483 (pre 3.7.6)
--------------------------------
* rst documentation update: RGBAdjust https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/adjust.html
* rst documentation update: ColorYUV https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/coloryuv.html
* optimization: add AVX2 TurnLeft/TurnRight/Turn180 (R/L: 1,5-3x speed).
* optimization: ConvertBits AVX2 integer->float
* optimization: ConvertToPlanarRGB(A): YUV->RGB add AVX2 (2-3x speed)
* optimization: ConvertToPlanarRGB(A): YUV->RGB 16 bit: a quicker way (1,5x)
* Fix: C version of 32-bit ConvertToPlanarRGB YUV->RGB to not clamp output RGB values.
* ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.
* ConvertToPlanarRGB(A): from YUV->RGB full range output: optimized in-process when bits=32, other cases call ConvertBits internally.
* Fix: Packed RGB conversions altering the bit-depth (e.g. rgb32->ConvertToRGB64() worked always in full range.
* Add more AVX512 resampler code. (WIP)
* Add more AVX512_BASE code paths (Resamplers)
* Build: add _avx512b.cpp/hpp pattern in CMake to detect source to compile with base (F,CD,BW,DQ,VL) flags.
However AVX512_BASE itself is set only when AVX512_FAST found.
For pre-Ice Lake (older AVX512) systems you can enable it with SetMaxCPU("avx512base+") and get the optimized AVX512_BASE functions.
* Build: add new architecture z/Architecture

[Kurt.noise]

Hi,

Didnt look closely but I've seen CUDA parameters into the compilation settings. What is it for exactly ?

[DTL]

It looks for memory management (and filtergraph filters interconnection ?) for CUDA-based plugins (no CUDA internal filters currently ?). It looks like in old times when the number of programmers was big there was an attempt to make CUDA-computing avisynth with script-based filters interconnection inside CUDA-accelerator and/or even a mix of onCPU and onCUDA filters. But the development of this looks like it stopped a long time ago. Now all filters work as onCPU and if a filter needs some external acceleration it makes all memory management inside itself. This causes some performance loss in case of single filter and more in case of a filterchain but it is more simple in support by the current limited number of developers.

There is an idea for special onAccelerator filters extended filters interconnection interface like GetFrameToBuffer(buffer_description) so that onAccelerator based filters can ask for storage of a frame directly into an allocated upload buffer in global virtual memory address space. Currently AI/NN filters like RIFE and avs-mlrt only can get frames by standard GetFrame() method and make additional copy into allocated buffers for uploading to the accelerator. With the largest RGBPS format this causes great load on the memory subsystem (though while AI/NN filters are not very fast it may be not greatly visible).

As I understand, the idea of the CUDA-based filtergraph was to save from frame resources upload/download to/from host RAM if several CUDA-based filters are connected in a graph inside an external accelerator. Current AVS filters interconnection (typically via software Cache() for frame-based MT) require to write frames to host RAM cache buffers and read from cache buffers (though some DO_NOT_CACHE_ME mode exist and filters can attempt for direct connection via GetFrame() ?).

[tormento]

As I understand, the idea of the CUDA-based filtergraph was to save from frame resources upload/download to/from host RAM
So, there could be an implementation for my beloved BM3DCUDA, where the temporal part is CPU bonded?

[DTL]

CUDA-based filters may interact with other CUDA-based filters without downloading input/output frames to host RAM.

Important update for use with ML/AI/NN filters -
ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.

It mean instead of long and slow sequence

ConvertToPlanarRGB()
ConvertBits(32)

before RIFE/avs-mlrt filters after r4483 can be used single (and faster) filter

ConvertToPlanarRGB(bits=32)

It is expected finally faster in comparison with avsresize Z_ConvertFormat(pixel_type="RGBPS") if convert from YUV.

Also uint8..16 to float32 precision may become a bit better because the new function uses direct int32 immediate to float32 conversion without immediate integer stage.
May be close in precision to possible (but also slower)
ConvertBits(32)
ConvertToPlanarRGB()
sequence.

Also waiting for a new test release from pinterf - it will have finally fixed ColorBarsHD to any integer precision and float and again fixed matrix/dematix part for better YUV<->RGB conversions to test precision of new functions. Currently ColorBarsHD uses only 8bit internal table and bit depth upscale and can not be used as a good source generator for precise matrix testing at different bit depths.
Precision of 10bit YUV to 8bit RGB conversion expected to be very close or equal to avsresize in new test release.

[pinterf]

CUDA-based filters may interact with other CUDA-based filters without downloading input/output frames to host RAM.

Important update for use with ML/AI/NN filters -
ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.

It mean instead of long and slow sequence

ConvertToPlanarRGB()
ConvertBits(32)

before RIFE/avs-mlrt filters after r4483 can be used single (and faster) filter

ConvertToPlanarRGB(bits=32)

It is expected finally faster in comparison with avsresize Z_ConvertFormat(pixel_type="RGBPS") if convert from YUV.

Also uint8..16 to float32 precision may become a bit better because the new function uses direct int32 immediate to float32 conversion without immediate integer stage.
May be close in precision to possible (but also slower)
ConvertBits(32)
ConvertToPlanarRGB()
sequence.

Also waiting for a new test release from pinterf - it will have finally fixed ColorBarsHD to any integer precision and float and again fixed matrix/dermatix part for better YUV<->RGB conversions to test precision of new functions. Currently ColorBarsHD uses only 8bit internal table and bit depth upscale and can not be used as a good source generator for precise matrix testing at different bit depths.
Precision of 10bit YUV to 8bit RGB conversion expected to be very close or equal to avsresize in new test release.
Yep, returning to this matrix conversion area during development caused a "bit" more work, testing, and experimentation than I had initially expected. I can't quite compete with the accuracy of avsresize, as it performs all matrix operations internally in 32 bit float.

However, at 16-bit, a possible +/-1 lsb error can be considered as "good enough".

When using full range, it's effectively the same as working in 32 bit float; for complex transformations (like full range bit depth conversion), my version uses float calculations internally as well.

Avisynth hasn't previously had chained (fused) filter options where a matrix was involved, so this bits= parameter is a first. It immediately became clear that while optimizing the simplest conversion was easy, the code bloats exponentially when you try to optimize every specific sub-case. Luckily, the more complex cases finally needed 'float' - inside and could be unified.

Combining the bit depth conversion is not only much faster but also more accurate than simply adding ConvertBits after the YUV-RGB conversion, so it was a very good and useful idea from DTL.

[tormento]

CUDA-based filters may interact with other CUDA-based filters without downloading input/output frames to host RAM.
My usual script is something like:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\DehaloAlpha\Dehalo_alpha.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\Dither\mt_xxpand_multi.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\FineDehalo\FineDehalo.avsi")
DGSource("M:\In\The promised neverland S1 ~Dynit\01-1.dgi")
z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv420p16")
DeBilinearResizeMT(1280, 720, threads=2, prefetch=2, accuracy=2)
z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv444ps")
BM3D_CUDA(sigma=12, radius=4, chroma=true, block_step=6, bm_range=12, ps_range=6, fast=false)
BM3D_VAggregate(radius=4)
z_ConvertFormat(resample_filter="spline64",dither_type="error_diffusion",pixel_type="yuv420p16")
FineDehalo(rx=2, ry=2, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=0.3, brightstr=1.0, showmask=0, contra=0.0, excl=true)
libplacebo_Deband(radius=12, iterations=4, temporal=false, planes=[3,3,3])
fmtc_bitdepth (bits=10,dmode=8)
Prefetch(2,6)

How could I change it to have some performance increase, according to the last commits?

[DTL]

Currently looks like no. In future some 420<->444 conversion performance increase expected in UV 2x upsize/downsize but it is not yet ported to AVS+ core so no test release exist. Also it is internal Resize() optimization and not required script changes.

As some testing may be recommended to try 14bit integers instead of 16bit. It was found 16bit format was not nice for performance in many AVS filters and processed by different functions in comparison with 10-14 bits. But if you use external filters - it may depend on their implementations. The precision may be not greatly different between 14 and 16bits.

[FranceBB]

Older VSFilters didn't throw exceptions in GetFrame, and it simply didn't work.

I remember it well. Sometimes I forgot to convert things at the end and I ended up wasting encoding hours only to find out that the output wasn't hardsubbed.

TextSub("whatever.ass") would literally pass the frames through without returning any error nor overlaying any subtitles.

https://images2.imgbox.com/5b/83/SheFAaHM_o.png
https://images2.imgbox.com/48/58/QTaqLlNH_o.png

there was an attempt to make CUDA-computing avisynth with script-based filters interconnection inside CUDA-accelerator and/or even a mix of onCPU and onCUDA filters.

Yes, however it's always better to avoid going back and forth between CPU and GPU (so onCPU and onCUDA) because it means copying a lot of data and it might not be worth it. One classic example of this is Cube() and DGCube() from Donald Graft. Although - on paper - DGCube() makes the entire tetrahedral interpolation and application of the 65x65x65 LUT on the GPU and it's significantly computationally faster than doing it on the CPU with AVX512, copying huge frames from RAM (DDR) to VRAM (GDDR) via the motherboard lanes to perform the process and then back causes a significant slowdown and only really makes DGCube() a fraction faster than Cube(), thus losing almost all its advantage. We're talking about 16bit RGB Planar UHD frames here for normal content (or potentially 6K for post production stuff shot in log).


Now all filters work as onCPU and if a filter needs some external acceleration it makes all memory management inside itself. This causes some performance loss in case of single filter and more in case of a filterchain but it is more simple in support by the current limited number of developers.


To be fair, this is very easily supportable and it's actually very simple from the user perspective as well given that there's no need to mess with MT Modes and Prefetch() either as the threadpool is created internally by the filter itself, so from a user perspective you know that all you have to do is write the script and it will run everywhere.

Also, when it comes to distributed farms like in the case of FFAStrans running on prem, the servers it's running on may not be all exactly the same and have the very same dedicated GPU with the same drivers etc and the same goes for the CPU cores, instruction sets (assembly optimization) etc so writing the scripts and letting the filters "figure it out" automatically on the CPU is actually very helpful.

Even in a cloud environment in which you typically have 1 machine = 1 job with a workflow running end to end, you only really have CPU only EC2 like the Elastic c6i.4xlarge and Elastic c6i.2xlarge that we're using as only the ones without a GPU would scale up and down by being created dynamically according to the number of jobs. Sure, one could set it up in a similar way with GPU powered EC2, but the likelihood of them not being created as there aren't any resources available for the region raises significantly, thus making the CPU only option way more appealing. TL;DR I would rather pick something slower but that works and is available all the time than something slightly faster that might not be available.


Also waiting for a new test release from pinterf - it will have finally fixed ColorBarsHD to any integer precision and float and again fixed matrix/dematix part for better YUV<->RGB conversions to test precision of new functions. Currently ColorBarsHD uses only 8bit internal table and bit depth upscale and can not be used as a good source generator for precise matrix testing at different bit depths.
Precision of 10bit YUV to 8bit RGB conversion expected to be very close or equal to avsresize in new test release.

That's actually gonna be very good as I routinely use Avisynth's colorbars to test stuff, so thank you for looking into this guys. :)

[FranceBB]

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

Windows XP Builds (x86-xp):

Tested and working on Windows XP Professional x86
https://images2.imgbox.com/be/29/1TfQ9EEX_o.png

Windows 7 Builds (x64-win7-19.44.35221-17.14):

Tested and working on Windows Server 2008 R2 x64
https://images2.imgbox.com/77/55/707MuoSA_o.png

[DTL]

"How could I change it to have some performance increase, according to the last commits?"

What I found with some total encoding performance testing (using x264.exe as MPEG encoder) and RIFE as some call to accelerator processing: The performance may depend not on the best performance single filter but on some magic combinations of filters in a graph.
I see you use avsresize for all format conversions. In my test it is not best for total performance (equal to not-best other AVS filters sequences).
So if you have time for long testing - you can also test single or even sequences of AVS filters of Convert(matrix) + ConvertBits() if total encoding performance is visibly different.

In my (test) case with RIFE:

Fastest convert of YV12 to planar RGBPS before RIFE filter is
ConvertToPlanarRGB()
ConvertBits(32)

all other ways (with single ConvertToPlanarRGB(bits=32) and Z_ConverFormat(pixel_type="RGBPS") and reverse order of ConvertBits(32).ConvertToPlanarRGB() are slower. And it is tested with r4483 (and sources up to 09 Feb). But all this may be changed in any new release if we will have any changes in AVS caching and new frames fetching from global frames buffer etc.

The total encoding fps difference between 'lucky fast' filters sequence and 'about all other slow' is about 22..23 vs 14..15 fps.

Full test script was

LoadPlugin("avsresize.dll")
LoadPlugin("RIFE.dll")

ColorBars(800,800,pixel_type="YUV444P8")

#ConvertToPlanarRGB(bits=32)
#ConvertBits(32)
ConvertToPlanarRGB()
ConvertBits(32)
#Z_ConvertFormat(pixel_type="RGBPS")

RIFE(denoise_tr=1)

ConvertBits(8)
ConvertToYV12()
Prefetch(2)

And x264 encoding is
x264.exe --profile high --crf 18 --preset "placebo" --merange 50 --psnr -o out.264 rife_test.avs

Typical average performance GPU load graph and x264 fps
https://i.ibb.co/FqsFXDd6/ss01.png (https://ibb.co/tPZ9zJ1B)

Anomaly best performance Convert filters sequence
https://i.ibb.co/tPPd5Y8T/gs01.png (https://ibb.co/JFFhPr5w)

Maybe some complex issue with Windows threading and GPU drivers etc.

Another idea: RIFE in denoise-mode (tr=1) requests -1 and +1 frames from current to output interpolated frame. A bit close to MDegrain1(). This may cause some significant performance difference in AVS caching and sequence of
ConvertToPlanarRGB()
ConvertBits(32)
may have some more lucky results ?
But these filters are simple and sequence
ConvertBits(32)
ConvertToPlanarRGB()
expect to have same cache service time performance (not including larger float data size after ConvertBits(32) ).

[wonkey_monkey]

Presumably RIFE has to upload multiple frames to the GPU for each output frame. How efficiently does it do so?

Edit: I see you mentioned that. Off the top of my head, to be compatible with prefetch(2) it can't be keeping track of internal state between frames so it must be uploading 3 frames every time. If it could keep track of what's previously been loaded, and ran single-threaded, could it eliminate two of those uploads?

[DTL]

RIFE applied to AVS is still a very simple 2 frame input and 1 frame output engine. And it always uploads 2 frames to get 1 output frame (+ time param to interpolate between 0.0 (first frame) to 1.0 (second frame) float). This allows it to run in random access mode without additional programming. But this causes 2x additional upload traffic if work with sequential frames requests. It may not know how to remap the last uploaded frame to be first and only upload 1 new frame. It is subject to one more issue to open for possible optimization in the RIFE AVS plugin (if underlying NN engine support resources remapping).

In theory any temporal radius filter with sequential frame requests at output (normal encode mode in 1 thread) can only upload 1 new frame and remap all tr-frames by shifting to 1 and skipping first (oldest) frame if accelerator memory is enough to hold all tr-frames at once. But with current massive-multithreaded CPUs running at single threaded mode may not make best performance for the accelerator. Also with random output frame access the frame source engine needs to upload all required frames before output requested frame. This is additional programming to remember uploaded frames numbers. Also each thread must either have its own frame pool in (very small and expensive accelerator memory) or even some global memory manager interconnected with AVS frame cache to run >1 threaded filters if frame numbers in different threads overlap. This expectation was some part of the idea of onCUDA filters processing.

Because current underlying RIFE engine always work with 2 frames (and can not remember surround frames to make quality better) the optimizing sequential frame access by remap last frame to first and upload only 1 new may not give significant performance boost if even it is possible with currently used Vulkan API and RIFE engine. Though it is subject to testing if possible. Much better performance boost may be with larger-tr engines (but we currently do not have any ?).

Current AVS groups of frames multithreading model require the constant new output frame (not sequential) filter refresh after the current group of frames at current thread fully processed and thread getting a new work unit of the next group of frames (may be also in some random order). This means the filter in the thread needs to reupload all frames to the accelerator for the current requested output frame at the start of each frame group. Or attempt to remap frames from the global uploaded frames pool for current clip (if available and managed). This requires even more programming.

[wonkey_monkey]

Just did a quick test: skipping the each-frame upload (2048x1024 RGB32) to my Vulkan remapping filter takes me from 140fps to 180fps (or 100fps to 160fps if I pass RGB24, which needs a CPU conversion to RGB32). And that's just 8mb. A 4K float input would be 132mb.

What if we could upload the native YUV planes to the GPU, and convert them to RGBA there? Or would that just be letting the CPU go to waste?

[Nomolu]

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


After installing Avisynth r4483 on my system, I went to test the 32-bit version of it. I immediately got this error message:

Avisynth open failure:
Cannot load a 64 bit DLL in 32 bit Avisynth: 'C:/Program Files (x86)/AviSynth+/plugins+/DirectShowSource.dll'.

E:\Video_Processing\Test.avs, line 2

My test script is really simple:
AviSource("D:\ToR\video_a.avi")
Trim(1188, 89809)


To fix the problem, I started downloading older prereleases and found a good 32-bit version of DirectShowSource.dll in r4356. Then I got the 64-bit error message with the 'ImageSeq.dll' file. I replaced that file and got the error message with the 'TimeStretch.dll' file.

So, it seems that several of the 64-bit plugins (DirectShowSource.dll, ImageSeq.dll, and TimeStretch.dll) are wrongly located in the "x86-19.50-clangcl-llvm-20.1.8\plugins" of the current release packages and missing from the "x64-19.50-clangcl-llvm-20.1.8\plugins" directory.

This is the only problem I've ran into so far with the r4483 build.

[DTL]

What if we could upload the native YUV planes to the GPU, and convert them to RGBA there?

Unfortunately current progress in development of image processing at accelerators (in opensource) is very poor and they still work mostly like working tech demos designed by students for processing RGBPS images only.

Need additional work to add YUV integer to RGBPS conversion in accelerator to unpack uploaded YV12 resource-texture to RGBPS. But it looks we already do not have programmers to do this simple work.

So RIFE and avs-mlrt only can work in slowest mode of full unpack of YV12 to RGBPS onCPU and upload largest resources to accelerator (via lots of redundant CPU data copy too).

Best solution is to simply allow accelerator to DMA AVS YV12 planar buffers onboard (from AVS cache) and do all work onboard.

[wonkey_monkey]

Is there any documentation/example for passing functions as parameters to plugins ('n' in AddFunction parameter string)?

[pinterf]

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

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



20260213 3.7.5.r4507 (pre 3.7.6)
--------------------------------
Fix Layer "add" 8 bit, regression in r4504

20260212 3.7.5.r4504 (pre 3.7.6)
--------------------------------
* Fix: inaccurate ColorBarsHD 10+ bit values. Now they are derived from the 32-bit float
RGB definitions instead of upscaling a 8 bit precalculated YUV value.
Add Ramp section the lead-in-lead-out.
* Fix: GreyScale + SSE2 + RGB32 + matrix="RGB" overflow.
Rare usage; "RGB" matrix (Identity) uses a 1.0 coefficient which exceeds the signed 16-bit
SIMD limit of 32767 at 15-bit precision. Added bounds checking to fallback to C-code for any
coefficients >= 1.0 or < −1.0.
* Fix: YUV->RGB limited range matrix accuracy for 10-16 bits.
* Use a different rounding in matrix coefficient's integer approximation.
* "ConvertToPlanarRGB": ``bits`` parameter: on-the-fly bit-depth conversions to YUV->RGB conversion.
- Full range target: 8-16 bits internal calculation is in 32-bit float.
- Limited range target: a quicker, bit accuracy optimized integer calculation path.
* Not Fixed: Speed degradation when in-constructor GetFrame(0) (e.g. frame-property getter)
is used. Disable internal Cache object creation. Does not work in complex scripts, preparation
is 5-10 min instead of <1 sec. Investigation continues (Issue #476: https://github.com/AviSynth/AviSynthPlus/issues/476)
* Avoid MTGuard and CacheGuard creation if filter returns one of its clip parameter unaltered.
* Add some avx2 stuff to Layer and Invert
* Optimization: Overlay "Blend": aarch64 NEON optimization

20260203 3.7.5.r4483 (pre 3.7.6)
--------------------------------
* rst documentation update: RGBAdjust https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/adjust.html
* rst documentation update: ColorYUV https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/coloryuv.html
* optimization: add AVX2 TurnLeft/TurnRight/Turn180 (R/L: 1,5-3x speed).
* optimization: ConvertBits AVX2 integer->float
* optimization: ConvertToPlanarRGB(A): YUV->RGB add AVX2 (2-3x speed)
* optimization: ConvertToPlanarRGB(A): YUV->RGB 16 bit: a quicker way (1,5x)
* Fix: C version of 32-bit ConvertToPlanarRGB YUV->RGB to not clamp output RGB values.
* ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.
* ConvertToPlanarRGB(A): from YUV->RGB full range output: optimized in-process when bits=32, other cases call ConvertBits internally.
* Fix: Packed RGB conversions altering the bit-depth (e.g. rgb32->ConvertToRGB64() worked always in full range.
* Add more AVX512 resampler code. (WIP)
* Add more AVX512_BASE code paths (Resamplers)
* Build: add _avx512b.cpp/hpp pattern in CMake to detect source to compile with base (F,CD,BW,DQ,VL) flags.
However AVX512_BASE itself is set only when AVX512_FAST found.
For pre-Ice Lake (older AVX512) systems you can enable it with SetMaxCPU("avx512base+") and get the optimized AVX512_BASE functions.
* Build: add new architecture z/Architecture

[pinterf]

Is there any documentation/example for passing functions as parameters to plugins ('n' in AddFunction parameter string)?
Perhaps this one:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_function_objects.html

EDIT:
or in function parameter
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/conditionalfilter.html

and in Avisynth source (runtime functions accept function objects)
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/conditional/conditional.cpp#L61

[Jamaika]

https://github.com/pinterf/AviSynthPlus/commit/8d5075d6df6dca5e8f55c740addc7e3c00b321c8
I don't know why are minor DEBUG fixes added?
cache.cpp:745:146: error: macro "_RPT3" passed 6 arguments, but takes just 5
745 | _RPT3(0, "CacheGuard::SetCacheHints called. cache=%p hint=%d (%s) frame_range=%d\n", (void*)this, cachehints, hintname.c_str(), frame_range); // P.F.
| ^
In file included from cache.h:38,
from cache.cpp:35:
avisynth.h:157: note: macro "_RPT3" defined here
157 | #define _RPT3(a,b,c,d,e) ((void)0)
|
cache.cpp: In member function 'virtual int CacheGuard::SetCacheHints(int, int)':
cache.cpp:745:7: error: '_RPT3' was not declared in this scope
745 | _RPT3(0, "CacheGuard::SetCacheHints called. cache=%p hint=%d (%s) frame_range=%d\n", (void*)this, cachehints, hintname.c_str(), frame_range); // P.F.
| ^~~~~

[Columbo]

It's a single code base. pinterf and others may want to build with _DEBUG when troubleshooting. Did I miss your point?

[pinterf]

Yes, minor, since compared to last week's ~40 hrs work on the project it was just a quick moment to copy-paste _RPT3 and not modifying the _RPT3 to _RPT4. Sorry for the inconvenience.

[pinterf]

(I don't know what private compiler settings are you using again, for me it said '0 warning(s)', vs. your environment which drives it to an error. Anyway, thanks for the report. Fixed.)

[wonkey_monkey]

and in Avisynth source (runtime functions accept function objects)
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/conditional/conditional.cpp#L61

When I tried to pass a parameter to the constructor as a PFunction (via args[x].AsFunction()) I get:

unresolved external symbol "public: class PFunction __cdecl AVSValue::AsFunction(void)const " (?AsFunction@AVSValue@@QEBA?AVPFunction@@XZ)

:confused:

Is it something to do with this?

c++ strict conformance: cannot Convert PFunction to PFunction&

Edit: or this:

PFunction AsFunction() const; // internal use only

So external plugins can't make use of it?

[pinterf]

When I tried to pass a parameter to the constructor as a PFunction (via args[x].AsFunction()) I get:

unresolved external symbol "public: class PFunction __cdecl AVSValue::AsFunction(void)const " (?AsFunction@AVSValue@@QEBA?AVPFunction@@XZ)

:confused:

Is it something to do with this?



Edit: or this:

PFunction AsFunction() const; // internal use only

So external plugins can't make use of it?
In expression.cpp I encountered with the problem, but can't remember the details:

if (real_name == nullptr) {
// if name is not given, evaluate expression to get the function
eval_result = func->Evaluate(env);
if (!eval_result.IsFunction()) {
env->ThrowError(
"Script error: '%s' cannot be called. Give me a function!",
GetAVSTypeName(eval_result));
}
//auto& func = eval_result.AsFunction(); // c++ strict conformance: cannot Convert PFunction to PFunction&
const PFunction& func = eval_result.AsFunction();
real_name = func->GetLegacyName();
real_func = func->GetDefinition();
}

[pinterf]

Meanwhile a hotfix, 8 bit Layer "add" mask problems
New build, sorry for that.
Avisynth r4507
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4507

[FranceBB]

Meanwhile a hotfix, 8 bit Layer "add" mask problems
New build, sorry for that.
Avisynth r4507
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4507



x86-xp build
Tested and working on Windows XP Professional x86
https://images2.imgbox.com/7d/67/T0aokMyB_o.png


x64-win7-19.44.35221-17.14 build

Tested and working on Windows Server 2008 R2 but there seems to be a problem with assembly optimizations somewhere in x64.

SetMaxCPU("none")
video=LWLibavVideoSource("M2991374.mxf")
ch1=LWLibavAudioSource("M2991374.mxf", stream_index=1, fill_agaps=1)
ch2=LWLibavAudioSource("M2991374.mxf", stream_index=2, fill_agaps=1)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

propClearAll()

ConvertBits(16)

Limiter(min_luma=4096, max_luma=60160, min_chroma=4096, max_chroma=60160)

SinPowerResize(1024, 576)
Info()

produces the right output
https://images2.imgbox.com/15/50/b2RcxLk8_o.png

however if I remove the

SetMaxCPU("none")

I get the following
https://images2.imgbox.com/1f/7a/mH5z8SUN_o.png

which is clearly wrong.

Even a simple SetMaxCPU("SSE2") produces the same result which means that only the C++ code is "fine" and there's a problem somewhere in the manually written intrinsics in assembly.


Digging a bit further, this seems to be related to 4:2:2 10bit planar and can be reproduced with a simple:

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(10)
Info()


In other words:

8bit planar 4:2:2 with assembly optimizations is fine


ColorBars(848, 480, pixel_type="YV16")
Info()


https://images2.imgbox.com/4b/be/ksj26nCs_o.png

32bit float 4:2:2 with assembly optimizations is fine

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(32)
Info()

https://images2.imgbox.com/86/97/gCGESemm_o.png


10bit, 12bit, 14bit, 16bit planar 4:2:2 with assembly optimization from SSE2 onwards are not


ColorBars(848, 480, pixel_type="YV16")
ConvertBits(10)
Info()


https://images2.imgbox.com/4d/7c/2Nh5pTt4_o.png


ColorBars(848, 480, pixel_type="YV16")
ConvertBits(12)
Info()


https://images2.imgbox.com/52/f3/sYxvCpjx_o.png


ColorBars(848, 480, pixel_type="YV16")
ConvertBits(14)
Info()


https://images2.imgbox.com/bc/8b/fXzDMMwD_o.png


ColorBars(848, 480, pixel_type="YV16")
ConvertBits(16)
Info()


https://images2.imgbox.com/a2/a3/PclbMINY_o.png

[jpsdr]

You've found the Dolby Vision LUT...
I mean, green/purple, it's the way Dolby Vision is displayed when not supported... :D

[FranceBB]

You've found the Dolby Vision LUT...
I mean, green/purple, it's the way Dolby Vision is displayed when not supported... :D

All this time trying to invert IPTc2 dvhe0509 and the answer was there in front of out eyes... LMAO


Jokes aside I triple checked and I can confirm that it only happens on x64 in the Windows 7 build.

x86-xp isn't affected.


ColorBars(848, 480, pixel_type="YV16")
ConvertBits(10)
Info()


https://images2.imgbox.com/cb/fa/vyhgUaqv_o.png




Tomorrow morning I'll try the x64-xp build.


EDIT: I did, final results:

Avisynth_3.7.6_20260213_tst_r4507

- x64-xp
- x64-win7-19.44.35221-17.14

8bit planar and 32bit float 4:2:2 ok.
problem with 10bit, 12bit, 14bit, 16bit planar 4:2:2 when assembly optimization are used (SSE2 onwards).
SetMaxCPU("none") forces C++ which is error free.

- x86-xp

all ok (8bit, 10bit, 12bit, 14bit, 16bit planar and 32bit float) 4:2:2. Everything is fine both with assembly optimization (tested up to SSE4.2 which is the maximum XP supports).

[pinterf]

Thanks FranceBB, I thought, it would be super-easy, but I was not able to reproduce it.
EDIT: It's the display, which is using ConvertToRGB32() after that.
EDIT: fixed, exchanged G and B in bit-depth changing YUV->RGB full scale code.

[pinterf]

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

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

Actual:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

20260216 3.7.5.r4523 (pre 3.7.6)
--------------------------------
- Fix r4504 regression YUV->RGBP bit-depth changing full-scale SSE2/AVX2 bug (exchanged G,B storage)
- "Layer" YUV mul/add/subtract/lighten/darken: refactor chroma placement calculation, allowing SIMD optimization in the main frame processing
- "Layer" YUV/RGBP mul/add/subtract/lighten/darken: refactor function dispatchers, add AVX2 path (LLVM/clangcl recommended)
- Fix C-only vertical resampling code which added more rounding than needed (regression since pre-3.7.5 20250427)
- Invert: per-plane processing for planar formats, use C even in AVX2, proper chroma inversion
- New: AddAlphaPlane opacity parameter
- New: ResetMask opacity parameter
- rstdoc: document "opacity" in AddAlphaPlane and ResetMask
- rstdoc: detail Layer "use_chroma" and opacity
- Overlay "Blend": more speed, but keep accuracy, use float only where really needed
- Layer: use YV16 internally for YUY2 (lessen source bloat)

20260213 3.7.5.r4507 (pre 3.7.6)
--------------------------------
Fix Layer "add" 8 bit, regression in r4504

20260212 3.7.5.r4504 (pre 3.7.6)
--------------------------------
* Fix: inaccurate ColorBarsHD 10+ bit values. Now they are derived from the 32-bit float
RGB definitions instead of upscaling a 8 bit precalculated YUV value.
Add Ramp section the lead-in-lead-out.
* Fix: GreyScale + SSE2 + RGB32 + matrix="RGB" overflow.
Rare usage; "RGB" matrix (Identity) uses a 1.0 coefficient which exceeds the signed 16-bit
SIMD limit of 32767 at 15-bit precision. Added bounds checking to fallback to C-code for any
coefficients >= 1.0 or < −1.0.
* Fix: YUV->RGB limited range matrix accuracy for 10-16 bits.
* Use a different rounding in matrix coefficient's integer approximation.
* "ConvertToPlanarRGB": ``bits`` parameter: on-the-fly bit-depth conversions to YUV->RGB conversion.
- Full range target: 8-16 bits internal calculation is in 32-bit float.
- Limited range target: a quicker, bit accuracy optimized integer calculation path.
* Not Fixed: Speed degradation when in-constructor GetFrame(0) (e.g. frame-property getter)
is used. Disable internal Cache object creation. Does not work in complex scripts, preparation
is 5-10 min instead of <1 sec. Investigation continues (Issue #476: https://github.com/AviSynth/AviSynthPlus/issues/476)
* Avoid MTGuard and CacheGuard creation if filter returns one of its clip parameter unaltered.
* Add some avx2 stuff to Layer and Invert
* Optimization: Overlay "Blend": aarch64 NEON optimization

20260203 3.7.5.r4483 (pre 3.7.6)
--------------------------------
* rst documentation update: RGBAdjust https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/adjust.html
* rst documentation update: ColorYUV https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/coloryuv.html
* optimization: add AVX2 TurnLeft/TurnRight/Turn180 (R/L: 1,5-3x speed).
* optimization: ConvertBits AVX2 integer->float
* optimization: ConvertToPlanarRGB(A): YUV->RGB add AVX2 (2-3x speed)
* optimization: ConvertToPlanarRGB(A): YUV->RGB 16 bit: a quicker way (1,5x)
* Fix: C version of 32-bit ConvertToPlanarRGB YUV->RGB to not clamp output RGB values.
* ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.
* ConvertToPlanarRGB(A): from YUV->RGB full range output: optimized in-process when bits=32, other cases call ConvertBits internally.
* Fix: Packed RGB conversions altering the bit-depth (e.g. rgb32->ConvertToRGB64() worked always in full range.
* Add more AVX512 resampler code. (WIP)
* Add more AVX512_BASE code paths (Resamplers)
* Build: add _avx512b.cpp/hpp pattern in CMake to detect source to compile with base (F,CD,BW,DQ,VL) flags.
However AVX512_BASE itself is set only when AVX512_FAST found.
For pre-Ice Lake (older AVX512) systems you can enable it with SetMaxCPU("avx512base+") and get the optimized AVX512_BASE functions.
* Build: add new architecture z/Architecture

[FranceBB]

Thanks for the new build and for fixing the issue (https://github.com/pinterf/AviSynthPlus/commit/c6d7126b4cfcb6d5c683729090415f0809c219db), Master Ferenc.

Avisynth_3.7.6_20260216_tst_r4523

x64-win7-19.44.35221-17.14
Windows Server 2008 R2 x64

Now 4:2:2 10bit/12bit/14bit/16bit work correctly with assembly optimizations up to SSE4.2 as well.
https://images2.imgbox.com/dc/f6/wtPJAGA1_o.png

x86-xp
Windows XP Professional x86

works normally as usual

https://images2.imgbox.com/77/2e/EtmUlX0J_o.png

[DTL]

Oh - Windows XP of decades old can use F16C pack/unpack instructions. And big set of AVX512_FP16 instructions for direct computing in FP16 format is not ready to use in most of current CPUs even in 2026.

[pinterf]

Here's a new pre-release build.
Latest test build (https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4529)
Avisynth+ v3.7.6pre-r4529 test build (20260220)

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

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


As a result of a chain reaction. After ColorBarsHD 10+ bit was fixed, I did the same update to ColorBars, with almost a full rewrite. Additionally I fixed the reported color matrix as well. I wanted then to visualize the changes, and it turned out that the existing vectorscope (color, color2) is quite basic. So I added a lot of options to them (for details, see
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/histogram.html), made them matrix and color range aware. Made them accurate (rounding, proper scaling to visible vectorscope area from full or limited range colors). That was another 3/4 rewrite, refactor.

So enjoy this new build, I'm sure FranceBB will be happy to test the new color/color2 overlay flags :) and you all would give me additional ideas.


20260220 3.7.5.r4529 (pre 3.7.6)
--------------------------------
- Fix Colorbars inaccurate 10+ bit, by using ground truth linear RGB, similarly to ColorBarsHD.
- Fix reporting 709 matrix instead of the 601 (170m)
- Full refactoring.
- update doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/colorbars.html
- Histogram "color" and "color2" (Vectorscope modes)
- almost full refactoring.
- Drawing is now matrix and color range aware. target positions (75%) +-I and +Q.
- add individual overlay options:
added ``matrix``, ``graticule``, ``targets``, ``axes``, ``iq``, ``iq_lines``, ``circle``
parameters
- Fix: copy alpha from clip, initialize alpha to zero in the histogram area.
- Accurate pixel positioning and scaling to the active histogram area,
limited/full range aware.
- update doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/histogram.html


20260216 3.7.5.r4523 (pre 3.7.6)
--------------------------------
- Fix r4504 regression YUV->RGBP bit-depth changing full-scale SSE2/AVX2 bug (exchanged G,B storage)
- "Layer" YUV mul/add/subtract/lighten/darken: refactor chroma placement calculation, allowing SIMD optimization in the main frame processing
- "Layer" YUV/RGBP mul/add/subtract/lighten/darken: refactor function dispatchers, add AVX2 path (LLVM/clangcl recommended)
- Fix C-only vertical resampling code which added more rounding than needed (regression since pre-3.7.5 20250427)
- Invert: per-plane processing for planar formats, use C even in AVX2, proper chroma inversion
- New: AddAlphaPlane opacity parameter
- New: ResetMask opacity parameter
- rstdoc: document "opacity" in AddAlphaPlane and ResetMask
- rstdoc: detail Layer "use_chroma" and opacity
- Overlay "Blend": more speed, but keep accuracy, use float only where really needed
- Layer: use YV16 internally for YUY2 (lessen source code bloat)

[DTL]

Great. We again can use the good skin tone mark at the vectorscope.

About program text comments of linear RGB: The colour bars are not in linear RGB (scene linear light). They are in system transfer domain encoding. The RGB sources for colour bars in the documents are defined simply to check the matrix/dematrix in distribution but not check transfer conversion too.

With 2-levels current colour bars sources it is not an issue because they do not contain transfer-dependent transients.

Though some old documents indirectly point to the 'conditioning domain' or colour bars and it is a system transfer domain (not linear-light RGB). It may be designed to make DAC and levels checking at waveform monitors more easy. As I understand, close to zero waveform monitors can do transfer conversion to linear before DAC or other way of interpolated (upscaled) waveform draw (render).

So it may be put to the notes section of ColorBars filter: The output is not conditioned to any transfer domain (and it is partially good) and has direct switch transients between levels. The levels are set as defined in the colour bars standard but it is not 75% linear RGB. It is 75% RGB still in system transfer domain encoding (to mark it sometime and in the ITU/EBU documents used R'G'B').

To condition in any required domain for frequency-limited (Nyquist) channel can be used sequence of:

#to condition transients in transfer domain R'G'B' with 75% in transfer domain
ColorBars(target_width*10, target_height*10, pixel_type="RGB")
UserDefined2Resize(width/10, height/10) #not perfectly match the recommended ITU filter response

#to condition transients in linear domain RGB with 75% in transfer domain
ColorBars(target_width*10, target_height*10, pixel_type="RGB")
#convert transfer to linear RGB (no AVS+ filter currently exist - use avsresize ?)
UserDefined2Resize(width/10, height/10) #not perfectly match the recommended ITU filter response
#convert transfer to target domain R'G'B' (no AVS+ filter currently exist - use avsresize ?)


Also it is nice to have some day to add Transfer() filter to AVS+ core to support transfer domain conversions too. For example to support resize in linear domain with all internal filters only.
Also additional frame/clip properties to mark:
1. Current transfer domain
2. Target conditioning transfer domain for resizing

About real ITU transients shaping filter: https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.801-1-199510-W!!PDF-E.pdf
1 Formulae : the filter impulse response is a Blackman window. We have BlackmanResize with the same (or close) window function https://github.com/AviSynth/AviSynthPlus/blob/c98ae61c51fc6c2216e7d314bf7f34582268431e/avs_core/filters/resample_functions.cpp#L133 . To make required frequency shaping filter we need to use this window as filter kernel and scale for timing as defined in the recommendation:

for –3T < t < 3T, R(t) = 0.42 + 0.50 cos(π t/ 3T) + 0.08 cos(2π t/ 3T) – otherwise R(t) = 0 (filter_support is 3T ?) .

The value of T is 74 ns for digital waveforms A1, A2, A3 and A4 and 148 ns for A5 and A6. To make filtering more simple - all colour bars may be filtered with a single filter of T=74ns (very close to 1 step between target samples, 1/74ns is 13.513 MHz and 1 sample step in PAL/rec.601 is duration of 1/13.5 MHz).A separate 'resize' named filter can be added to Resize filters like BlackmanITUResize(). Users can use it for getting better conditioned ColorBars or for some other conditioning workflows if the exact Blackman-type response is required.

[FranceBB]

So enjoy this new build, I'm sure FranceBB will be happy


I'm so happy right now. This is a very unexpected present, so thank you!
About the colorbars, we've got ColorBars() for BT.601, ColorBarsHD() for BT.709, are we gonna get ColorBarsUHD() for BT.2020? :D


Something appears to be off in Histogram, though, as this:


FFMpegSource2(V:\F1_Movie_FULL_HD_16x9_4tracks_2ch_DolbyE_DolbyE_Stereo_Stereo.mxf", atrack=4)


test1=Histogram(mode="color2", matrix="709", graticule="on", keepsource=false, circle=true, axes=true, iq=true, iq_lines=true)
test2=Histogram(mode="color2", matrix="709", graticule="on", keepsource=false, circle=true, axes=false, iq=false, iq_lines=false)
test3=Histogram(mode="color", matrix="709", graticule="on", keepsource=false, circle=true, axes=true, iq=true, iq_lines=true)
test4=Histogram(mode="color", matrix="709", graticule="on", keepsource=false, circle=true, axes=false, iq=false, iq_lines=false)

v1=StackHorizontal(test1, test2)
v2=StackHorizontal(test3, test4)

StackVertical(v1, v2)


produces identical results despite one combination having


axes=false, iq=false, iq_lines=false


and the other having


axes=true, iq=true, iq_lines=true


https://images2.imgbox.com/a4/42/gPuP9OR2_o.png

This was tested using the x86-xp build on Windows XP Professional x86 and using the x64-win7-19.44.35221-17.14 build on Windows Server 2008 R2 Standard x64.


Other than that, I can happily confirm that

ColorBars(848, 480, pixel_type="YUV444P16")

can produce a proper 16bit output and that both _Matrix and _Range are signaled via the frame properties correctly as Limited and BT.601 while before it said BT.709. :)

https://images2.imgbox.com/b9/c3/8fVo6CPg_o.pnghttps://images2.imgbox.com/87/22/tU7cG5R0_o.png

Left: x86-xp build on Windows XP Professional x86 --- Right: x64-win7-19.44.35221-17.14 build on Windows Server 2008 R2 Standard x64

[real.finder]

It is not 100%, just a trivial case was fixed. So the likelyhood you are seeing this error was decreased. There still can be circumstances in the frame request pattern when you get this error.

and now it fully fixed (https://github.com/pinterf/TIVTC/releases)! thank you so much pinterf!

I think all avs/avs+ mt and non-mt problems is fixed, we can encode faster and without deadlock or crashes or glitches thanks to you and Asd-g (and others that fixes and improved avs+ like nekopanda and avs+ father ultim)

[FranceBB]

and now it fully fixed (https://github.com/pinterf/TIVTC/releases)! thank you so much pinterf!

Absolutely amazing news for this and for giving some love to SSE4.1, there may not be many users but they will definitely appreciate it.

Thank you, Master Ferenc! :D

[pinterf]

I'm so happy right now. This is a very unexpected present, so thank you!
About the colorbars, we've got ColorBars() for BT.601, ColorBarsHD() for BT.709, are we gonna get ColorBarsUHD() for BT.2020? :D

Something appears to be off in Histogram, though, as this:

produces identical results despite one combination having


Check with targets=true, this is a master switch for the axes, as a result of my wrong decision, just tell me (honestly, since you went into the rabbit hole, it seem illogical so must be changed).
EDIT: haha, not a wrong decision, just a mis-placed ending curly-bracket, one block outer than it was necessary :)

[pinterf]

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

The biggest focus lately has been cleaning up the xxToYUV functions to bring their parameters and optimization in line with ConvertToPlanarRGB. This process triggered an endless series of new issues, forcing me to dig deep into historical code to understand why things were built the way they were.

Also, I updated our online documentation according these changes and findings.

I’ve also fixed the Histogram parameters related to the new features introduced in recent builds, which were discussed in the posts above.

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

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

20260305 3.7.5.r4549 (pre 3.7.6)
--------------------------------
- Fix: memory leak in Subframe/MakePropertyWritable after static-frame sources (ColorBars, BlankClip)
- any->YUV conversions (See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html ).
- accept bits ans quality parameters, similar to ConvertToPlanarRGB
- the legacy 8-bit-named functions (``ConvertToYV12``, ``ConvertToYV16``,
``ConvertToYV24``) allowing high-depth sources.
- "ConvertToYUY2": rewritten to route all conversions through YV16.
- "ConvertToYUY2": ``ChromaOutPlacement`` parameter added (was missing, present in ConvertToYV16).
- "ConvertBackToYUY2": kept for backward compatibility; now forwards to ``ConvertToYUY2``. The pre-2.5 left-pixel-only chroma hack is no longer
needed or applied; the YV16 lossless repack path avoids chroma resampling loss entirely for roundtrip workflows.
- 8 bit packed RGB formats are converted to planar RGB before 444 conversion.
Utiliting the optimized and maintained planar RGB infrastructure
- Fix: "ConvertToYUY2" / "ConvertToYV12": progressive YV12<->YUY2 conversion (use generic YV16/YV12 path)
- Fix: "ConvertToYUY2": ``_ChromaLocation``, ``_Matrix`` and ``_ColorRange``
frame properties were not read from YV12 source frames and not written to YUY2 output frames
in the old legacy direct conversion path.
- Fix: "ConvertToYUY2": SSE2 interlaced upsampling used wrong weighting direction, differing from the C reference implementation.
- Update https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`
- matrix syntax
- ConvertToYUY2
- ``bits`` and ``quality`` parameters
- Update Sampling https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/advancedtopics/sampling.html with historical content notes
on legacy ``YUY2`` handling.

[jpsdr]

Thanks for all your work pinterf.
And it's again work for FranceBB who have to make all of his tests... ;)

[TR-9970X]

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

Surely r3.7.6 will be next :)

[Nomolu]

Release 3.7.5 r4549 has introduced a bug when using the Overlay function on YUY2 video. I can reproduce it using this simple script:

Version()
ConvertToYUY2()
Overlay(last)

It causes this error:

Avisynth open failure:
ConvertToYUV422: Can only convert from Planar YUV.
E:\z_InProgress_E\Version - Overlay.avs, line 3

And, like I mentioned in post #3619, how about no longer putting 64 bit plugins in the 32-bit plugin directory of the builds?

Anyhow, thank you for all of the hard work, pinterf!

[pinterf]

Release 3.7.5 r4549 has introduced a bug when using the Overlay function on YUY2 video. I can reproduce it using this simple script:

Version()
ConvertToYUY2()
Overlay(last)

It causes this error:

Avisynth open failure:
ConvertToYUV422: Can only convert from Planar YUV.
E:\z_InProgress_E\Version - Overlay.avs, line 3

And, like I mentioned in post #3619, how about no longer putting 64 bit plugins in the 32-bit plugin directory of the builds?

Anyhow, thank you for all of the hard work, pinterf!
Please check the next day version, thanks, YUY2 conversions were temporarily were disabled in the final build, accidentally, I fixed since then.

[Nomolu]

Yup, 3.7.5.r4551 fixes the problem with Overlay and YUY2 video. :thanks:

[pinterf]

And thanks for spotting the 64-bit dlls put into the 32-bit plugins folder as well. These were intended to be a copy from the latest official 3.7.5 'filesonly' release, unfortunately, a copy-paste error on my end led to the mismatch.

[pinterf]

Latest test build (https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4554)
Avisynth+ v3.7.6pre-r4554 test build (20260307)


20260307 3.7.5.r4554 (pre 3.7.6)
--------------------------------
- Fix: Working 'quality' parameter for 10-14 bits sources in YUV<->RGB conversions (was: blackness)

20260306 3.7.5.r4551 (pre 3.7.6)
--------------------------------
- Reenable YUY2 in planar target conversions as source (disabled in r4549)
- ConvertToY also gets bits and quality parameters, latter is used when source is RGB.

20260305 3.7.5.r4549 (pre 3.7.6)
--------------------------------
- Fix: memory leak in Subframe/MakePropertyWritable after static-frame sources (ColorBars, BlankClip)
- any->YUV conversions (See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`.
- accept bits and quality parameters, similar to ConvertToPlanarRGB
- the legacy 8-bit-named functions (``ConvertToYV12``, ``ConvertToYV16``,
``ConvertToYV24``) allowing high-depth sources.
- "ConvertToYUY2": rewritten to route all conversions through YV16.
- "ConvertToYUY2": ``ChromaOutPlacement`` parameter added (was missing, present in ConvertToYV16).
- "ConvertBackToYUY2": kept for backward compatibility; now forwards to ``ConvertToYUY2``. The pre-2.5 left-pixel-only chroma hack is no longer
needed or applied; the YV16 lossless repack path avoids chroma resampling loss entirely for roundtrip workflows.
- 8 bit packed RGB formats are converted to planar RGB before 444 conversion.
Utilizing the optimized planar RGB infrastructure.
- Fix: "ConvertToYUY2" / "ConvertToYV12": progressive YV12<->YUY2 conversion (use generic YV16/YV12 path)
- Fix: "ConvertToYUY2": ``_ChromaLocation``, ``_Matrix`` and ``_ColorRange``
frame properties were not read from YV12 source frames and not written to YUY2 output frames
in the old legacy direct conversion path.
- Fix: "ConvertToYUY2": SSE2 interlaced upsampling used wrong weighting direction, differing from the C reference implementation.
- Update https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`
- matrix syntax
- ConvertToYUY2
- ``bits`` and ``quality`` parameters
- Update Sampling https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/advancedtopics/sampling.html with historical content notes
on legacy ``YUY2`` handling.

20260220 3.7.5.r4529 (pre 3.7.6)
--------------------------------
- Fix Colorbars inaccurate 10+ bit, by using ground truth linear RGB, similarly to ColorBarsHD.
- Full refactoring.
- update doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/colorbars.html
- Histogram "color" and "color2" (Vectorscope modes)
- full refactoring.
- Drawing is now matrix and color range aware. target positions (75%) +-I and +Q.
- add individual overlay options:
added ``matrix``, ``graticule``, ``targets``, ``axes``, ``iq``, ``iq_lines``, ``circle``
parameters
- Fix: copy alpha from clip, initialize alpha to zero in the histogram area.
- Accurate pixel positioning and scaling to the active histogram area,
limited/full range aware.
- update doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/histogram.html

[tormento]

- Fix: Working 'quality' parameter for 10-14 bits sources in YUV<->RGB conversions (was: blackness)
Would you please explain this more in detail?

I can find no reference about that feature/parameter.

I've found fmtconv to be the most precise among the conversion plugins. If AVS+ internals could become so precise and even fast, they would be welcomed ones.

[jpsdr]

@pinterf
Hi.
What is the resamplers status ?
Are the new functions (AVX2 & AVX512) Ok, and can i begin to try to implement them in my ResamplerMT, or are they still in testing mode ?
Just to try to avoid to spend hours for nothing if i have to redo everything later. By later i mean shortly, not if something in a few months append and a fix/change is needed.

[DTL]

Most important update on resamplers for permutex-based functions still not ported to AVS+ is yet another pre-processing of the coeffs in the resampling program. It looks universal for all H to V permute-based transposition functions. See this commit https://github.com/DTL2020/AviSynthPlus/commit/a2604a2fcbb0589e578640a376901c03dc9c9f7e

Also some simple data locality optimization at the 2d resizing of multi-planes (typical colour) formats - process each plane in 2 resizers in a sequence instead of processing all planes in first dimension at first and all planes in second dimension at next stage https://github.com/DTL2020/AviSynthPlus/commit/810f91ba468601316f8ddf89adee3c9821eb9bfd . This allows output of the first resize to be hot in cache if possible to be read by second stage.

[jpsdr]

I have a question about:
cache_size_L2 = env->GetEnvProperty(AEP_CACHESIZE_L2);
What is the result if called in an avisynth version not supporting AEP_CACHESIZE_L2 ?
In that case, what default value should be used ?

Edit:
Looking at resampler_h_detect_optimal_scanline it seems that if unsupported return 0, it's Ok.

@DTL
I'm in a special lucking rare case, work is for now quiet, so i would say that i have time for begin to check how to implement things.
But in the opposite, i don't have time for now when back home for testing. I've pushed for now in my ResampleMT the SSE and AVX2 update. As it was only for float cases, i was in a way very easy, as i don't have to care about my range and YUY2 mode parameters ;).
But no check for now. So, if on your side you have time to build and test, be my guest... :D
If not, no hard feeling, of course !

Edit2:
Forgot to ask... Why there is resample_avx512.cpp, resample_avx512.h but also resample_avx512.hpp and resample_avx512b.cpp and not just the first two ?

Edit3:
@DTL
You and pinterf made a lot of work, thanks.
You talked about a commit not yet in avs+, it means that your repo is up to date to current avs+, with something more you made, am i correct ?
Is what you made "final", or is there some benchmarks to make to finalize like pinterf done ?
Do you think just taking the "benchmark winners" and removing all the unused functions would be enough ? It will reduce the work for me to implement in ResampleMT.

[DTL]

"Why there is resample_avx512.cpp, resample_avx512.h but also resample_avx512.hpp "

As I remember this was a special hack by pinterf to support many compilers (and many OSes/architectures ?) builds with AVX512. If you build with only MSVS it is not required. This makes program text more complex.

[jpsdr]

Thanks, and i'll keep only the "winners" functions. Not realy thrilled to spend hours for implementing dead code... :(

[DTL]

" it means that your repo is up to date to current avs+, with something more you made, am i correct ?"

It is based on the 4439 commit to main AVS+ branch and newer commits are not included.

" just taking the "benchmark winners" and removing all the unused functions would be enough ? "

There are many function versions and too few real hardware resources for testing. I can only access old Xeon about mid 201x years and pinterf can test at the 'slow' consumer grade intel-11 CPU. So the real winners at the new AVX512 and CPU cache architectures (like AMD Zen5 and new intels) may be different.

The vertical resizers are few and universal (for any filter size and any resample ratio) and horizontals are much more complex and many are limited to only small filter sizes and generally upsample (and very small downsample) ratios. One use case of the 2x upsampling and /2 downsampling with short kernel BicubicResize in AVS+ core is to work in ConvertXXX for chroma upsize/downsize at the different chroma subsampling conversions.

There still no generic AVX512 H-resize function to support all filter sizes and all resample ratios. Some attempts to redesign AVX2 H-resize generic to AVX512 were not good in performance (may be also at old/slow AVX512 CPUs ?).

Also performance of the V-stripe scan H-resizers (without coeffs reloading and keeping in register file) is only good if in/out plane size fits in CPU caches. And this memory scan pattern (for store) is very non-friendly with main host RAM (SDRAM). Some attempts in partial V/H memory access pattern interleaving (like an H-stripe of about L2 cache size filled with partial V-stripes with still less coeffs reload per frame and forcing ready H-stripe to flush to host RAM as linear write stream) may be not complete winners at all use cases (only a few tested).

The real top-performance H-resizers as a special plugin may be designed like fftw software with performance measuring at current host with current task options of different implementations and selecting best. The processing time of the long footage is very long and time addition for small performance testing may be not visible at the full processing of the footage. Or you can make manual tuning options for users to try different implementations (and other performance-tuning options of each implementation like number of rows in a stripe) to select the best if the user cares.

Currently selected functions to AVS core may be only 'local winners' but fail with some not tested possible use cases (like very large frame sizes). Even with some automation script designed by pinterf it is still a long task to test very different use cases of the resizers.

Performance may also significantly depend on the threads number and host memory performance (frequency, bus width, memory channels number). In the AVS+ resizer the single function (single CPU core/thread) processes the whole plane and in ResampleMT several threads can process parts of a plane and this also may change the total performance and need testing again.

" resample_avx512b.cpp"

Because AVS+ core must support many compilers and also many CPU cores (with different AVX512 instructions sets - separated to AVX512_BASE and AVX512_FAST now in cpuid.h):
1. Functions with AVX512 instructions up to the 'base' set (old AVX512) separated in avx512b.cpp file.
2. Functions with all AVX512 instructions up to AVX512_FAST (see cpuid.h) located in avx512.cpp file.
As I remember some compilers (also clang LLVM ?) are controlled by external options for each file and 'fast' and 'base/old' AVX512 functions can not be mixed in single file.

For example 10-16bit integer H-resize can run on the old AVX512 CPUs but 8bit can not because 8bit permutex instruction not yet present in AVX512_BASE instructions sets. The direct software emulation of 8bit permute instruction works visibly slower and also not needed in such form because better to make separate 8bit function with 2x16bit outputs (required for later 16bit multiplication).

[jpsdr]

Finaly it may be faster than expected (doesn't mean it will be fast :D), so no remove.

[jpsdr]

Unable to build AVX512, i have an error on _bzhi_u64 unknow... :(

Edit:
WT...??!!! You can't build an x86 version of resample_avx512.hpp ???

Edit2:
Thanks to Chat GPT, i found how to handle this...

[jpsdr]

About AVX512 code, something bothering me...

As some core functions share the same code and are in the same file (for exemple resize_h_planar_uint8_avx512_permutex_vstripe_ks4_internal) for Fast and Base, you must compile the code with all the settings for Fast. Even if you have differents code pathes for intrinsic, as you've allowed the compiler to use all the options, how can you be sure it doesn't use them in the code ? Either in the "not intrinsic" part, or even in intrisic ? If you've allowed compiler to uses "better" CPU instructions than the one you choose in the intrinsic, what prevent it to use them, if it produces exactly what you've asked him to do, but better ? Even more, in the parts without intrinsic (standard C++ code) that are in the Base code path, how can you be sure it will not use Fast instructions, as it's allowed to do so ?

I hope i've explained properly my concern.

[DTL]

I am not sure how MSVC works with single /arch:AVX512 switch enabled. At least it can compile any directly used instructions (in the intrinsics). But I am not sure if it can use any supported by current used version of compiler AVX512 instructions to make better binary (and this may create not compatible with old AVX512 CPUs binary). It is subject to ask Microsoft (or robots or look in the MSDN).

With clang-LLVM users must manually enable each used AVX512 instruction set for each file and I think the compiler can not use any more AVX512 instruction sets (so binary will be compatible with CPUs up to defined AVX512 instruction sets). If some AVX512 instruction set is not enabled in compiler options and its intrinsic is used - the compiler will stop with error.

You may try to look in the cmake files how it prepares AVX512 switches for each _avx512X file for clang-LLVM (or other compilers like GCC ?).

The very widely used difference between AVX512_BASE (old) and AVX512_FAST (new) functions versions for convolution (resize and many other) is usage of old madd+add (sequence of 2 instructions)
result_lo = _mm512_add_epi32(result_lo, _mm512_madd_epi16(src_lo, coeff)); // a*b + c
for old AVX512 chips and usage of new AVX512_VNNI single instruction
result_0_31lo = _mm512_dpwssd_epi32(rounder, src_r0r1_0_31lo, coef_r0r1_0_31lo);
in the functions versions for AVX512_FAST.

So for AVX512_BASE binary compiler can not use VNNI single instruction optimization of FMA. How it is solved for MSVC builds I do not know. In program text I use templated function to select between old and VNNI methods and we expect the compiler will not optimize add+madd version of templated fucntion to VNNI instruction and make binary not compatible with non-VNNI CPUs.

Also this may be the reason to separate avx512b.cpp and avx512.hpp files for building with different (supported) compiler options. And for avx512b.cpp only AVX512_BASE AVX512 options enabled and it may be more fail safe from attempt to optimize for higher AVX512 instructions sets.

[jpsdr]

It seems i wasn't clear enough : it's the same code in the same file used for both Fast/Base, so it doesn't have different compiler options.
Also, i can only specify compiler options for .c/.cpp files, i can't for .h/.hpp. As they are included in files, the .h/.hpp is build with the options of the .c/.cpp calling it. To be able to build with LLVM, i had to activate ALL the avs options for both avx512 abd avx512b as they both include the .hpp. Finaly, i was able to build only activating ALL the options for all the AVX512 files.

[tormento]

Let me introduce the elephant in the room.

Isn’t time to add XYZ support to AVS+?

Powerful CPUs made DCP processing a thing even on “home” workstations.

What about that? [emoji4]

[PoeBear]

Is that not just due to the lack of external plug-ins? Ie if someone ported this VapourSynth plug-in (https://github.com/yuygfgg/Vapoursynth-MXFJ2KSource), is AVS+ missing some core functionality that it would still need?

[StainlessS]

Anything, anywhere, in a avisynth source that handles a colourspace (eg YV12), for resizing, colorspace conversion, blur, overlay, and any other colorspace handling [EDIT: pixel changes] you can think of,
would require a similar code path as eg YV12, we're talking a lot of new code here (I think).
XYZ addition is not a simple ask, lots of sweat and perhaps tears too.
[EDIT: Early Avisynth supported only YUY2 and RGB interleaved, it took some time to add even YV12]

Of course external plugins support would also require new code, excepting something like ClipClop which just juggles frame pointers and such,
does not process any colorspace data at all. [ClipClop only required additional code for debug/metrics text rendering for high bit depth, if you do not use text render, then always worked fine with HBD].
Most external plugins are not like ClipClop and would require added code path for XYZ stuff.
EDIT: Builtin functions like Trim() and Splice() would (like ClipClop) not (I think) need any changes.

EDIT:
I presume that XYZ would only exist in float format [not eg 8/10 bit], but dont know if might require 32 bit and/or 64 bit float [or additional bittages].

EDIT: Maybe all above is total bollocks ! :(

[Reel.Deel]

I updated to the latest test version (Avisynth+ v3.7.6pre-r4554 test build) and a simple mp_pipeline script that has always worked now returns an error.
MP_Pipeline: Unable to create slave process. Message:
(C:\Users\test\test.avs, line 12)

MP_Pipeline("""
### platform: win64
# this part of script will be run in a 64 bit process
Version(pixel_type="YV12")

# The line below is splitter
### ###

### platform: win32
HDRAGC(min_gain = 3.0, max_gain = 4.0, coef_gain=2)
### ###
""")

last

I downgraded both x64/x32 Avisynth to v3.7.5 and still the same problem. Then I downgraded the just x32 to v3.7.3 (version I has originally) and now the simple script works again. I'm using MP_Pipeline v0.23. HDRAGC (agc.dll) is in the plugins folder

[DTL]

" XYZ support to AVS+?"

For many filters without colour space conversion you can try to use it with current version and report if any issues exist. For better precision (if it is in linear transfer and HDR-like real range) - use float32 samples format. For SDR linear range the 12..14 bit expected to be enough.

[gispos]

I updated to the latest test version (Avisynth+ v3.7.6pre-r4554 test build) and a simple mp_pipeline script that has always worked now returns an error.


MP_Pipeline("""
### platform: win64
# this part of script will be run in a 64 bit process
Version(pixel_type="YV12")

# The line below is splitter
### ###

### platform: win32
HDRAGC(min_gain = 3.0, max_gain = 4.0, coef_gain=2)
### ###
""")

last

I downgraded both x64/x32 Avisynth to v3.7.5 and still the same problem. Then I downgraded the just x32 to v3.7.3 (version I has originally) and now the simple script works again. I'm using MP_Pipeline v0.23. HDRAGC (agc.dll) is in the plugins folder

MP_Pipeline works for me with this combination. I haven't tried anything newer. I didn't even know there was a version 0.23.

Avisynth 64bit, 3.7.5.0 r4523
Avisynth 32bit, 3.7.5.0 r4392
MP_Pipeline, 0.22
AGC.dll, 10.09.2006 18:37

Edit:
I just updated to MP_Pipeline v0.23 and it works.
In one of my recent Avisynth updates, the 32-bit Avisynth version contained 64-bit DLLs; perhaps that's a problem for you?

[Reel.Deel]

MP_Pipeline works for me with this combination. I haven't tried anything newer. I didn't even know there was a version 0.23.

Avisynth 64bit, 3.7.5.0 r4523
Avisynth 32bit, 3.7.5.0 r4392
MP_Pipeline, 0.22
AGC.dll, 10.09.2006 18:37

Edit:
I just updated to MP_Pipeline v0.23 and it works.
In one of my recent Avisynth updates, the 32-bit Avisynth version contained 64-bit DLLs; perhaps that's a problem for you?

Thanks for the feedback. I found the problem. I had an old yadifmod2 32bit plugin (v0.0.4-1 2016/07/04) in the autoload folder. Turns out in Avisynth > 3.7.3 it throws an error

Avisynth open failure:
'C:/Program Files (x86)/AviSynth+/plugins/yadifmod2.dll' plugin loading error:
Unknown exception


False flag, my bad, I'm rusty :p

[rgr]

Latest test build (https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4554)
Avisynth+ v3.7.6pre-r4554 test build (20260307)

[CODE]
20260307 3.7.5.r4554 (pre 3.7.6)
--------------------------------
- Fix: Working 'quality' parameter for 10-14 bits sources in YUV<->RGB conversions (was: blackness)


So far, I've been converting to RGB using Convertbits(32).ConvertToPlanarRGB (first converting to 32 bits to improve the accuracy of the conversion to RGB). Does ConvertToPlanarRGB(bits=32, quality=true) work the same way - first to 32 bits, then to RGB?
(I converted to YUV the same way, except I converted to 16 bits first.)

Edit: "Update https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`
matrix syntax
ConvertToYUY2
bits and quality parameters"

The link on the page has an unnecessary apostrophe at the end.

"any->YUV conversions (See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`.
accept bits and quality parameters, similar to ConvertToPlanarRGB"

Here too.

[flossy_cake]

Small feature request for a frame prop please if possible.

In the Internal filter TemporalSoften (http://avisynth.nl/index.php/Soften#TemporalSoften), there is the parameter scenechange which sets the threshold for detecting scenechanges, which disables temporal softening for those frames to prevent blending over scenechanges.

Could we have an option to tell it to read from the _SceneChangePrev (http://avisynth.nl/index.php/Internal_functions#SceneChangePrev) property -- that way I can do my own better scenechange detection and copy it to that prop and TemporalSoften can use that instead.

I tried already to do it using ScriptClip but it doesn't work properly for technical reasons , things to do with desync and not being able to control the direction of blends either side of the scene which TemporalSoften manages internally when it detects a new scene

:thanks:

[real.finder]

The fftw library planner function is not thread safe. A simple instance of plugin can make it thread safe on its own. But when there are multiple instances and/or different plugins that use fftw DLLs, they can still mess into each others planner.

Avisynth's new v12 interface can help with this topic, if they use the same "global lock", different instances and plugins can safely work together.

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/Cplusplus_api.html#cplusplus-acquiregloballock

The original issue:
https://github.com/AviSynth/AviSynthPlus/issues/444

now most of the important plugins get this fix, which are:-

http://avisynth.nl/index.php/FFT3DFilter

http://avisynth.nl/index.php/Dfttest

http://avisynth.nl/index.php/ManyPlus

https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest

------------------------------

and here plugins that still dont get the fix:-

http://avisynth.nl/index.php/VariableBlur

http://avisynth.nl/index.php/Spectrogram

https://github.com/HomeOfAviSynthPlusEvolution/neo_FFT3D (at least not in the Releases)

https://github.com/Asd-g/AviSynth-FFTSpectrum

DePan, DePanEstimate and mvtools https://github.com/pinterf/mvtools/issues/65

http://avisynth.nl/index.php/KPassFilterCL


did I forget one? :)

[flossy_cake]

Small feature request for a frame prop please if possible.

In the Internal filter TemporalSoften (http://avisynth.nl/index.php/Soften#TemporalSoften), there is the parameter scenechange which sets the threshold for detecting scenechanges, which disables temporal softening for those frames to prevent blending over scenechanges.

Could we have an option to tell it to read from the _SceneChangePrev (http://avisynth.nl/index.php/Internal_functions#SceneChangePrev) property -- that way I can do my own better scenechange detection and copy it to that prop and TemporalSoften can use that instead.

I tried already to do it using ScriptClip but it doesn't work properly for technical reasons , things to do with desync and not being able to control the direction of blends either side of the scene which TemporalSoften manages internally when it detects a new scene

:thanks:


I realise no-one probably cares about this but I came up with a funny workaround which I thought was mildly amusing. Basically just insert a white flash frame with BlankClip(color=$ffffff) on the scenechanges and then set TemporalSoften's scene thresh to some thing really high like 0.65-0.80 so it only detects the white flash frames as scenechange. Then remove the white flash frames afterwards when AverageLuma() >= 235 and copy paste the next frame after it into the current one. It's crazy but it works. Just hope I don't get any desync with multithreading that could muck up the timing otherwise I could end up with random white flash frames in the video which would look a bit embarrassing :o

[pinterf]

New build! Thanks for your patience; I intentionally took a break from the forum for these weeks.
Avisynth r4565
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4565

I was primarily focused on ColorBarsUHD (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/colorbarsuhd.html). The post testing and validation work (avsresize, fmtconv, HDRTools) threw a few surprises and required some (a lot of) extra checks. I could easily spend another two weeks on this topic, but I’ve had enough for now.

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

And for all the changes:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html
20260328 3.7.5.r4565 (pre 3.7.6)
--------------------------------
- Add ColorbarsUHD
- Fix: LruCache self-tuning cache resize: raised ghost-hit threshold from ghosted>0 to ghosted>1,
preventing unbounded cache growth during backward seeking (Issue #379) and Bob/SeparateFields
access patterns (Issue #270).
- Fix: VideoFrame::Release() race condition in frame property cleanup under multi-threaded use
(stability fix for static-frame sources such as ColorBars, BlankClip).
- Histogram "color"/"color2": add targets100 parameter: the 6 ColorBars target boxes at 100% luma scale.
- Fix: YUV<->RGB conversion with quality=true at 10-14 bit sources (regression).
- Fix: Histogram "color"/"color2": "target" parameter no longer acts as master switch for "axes".

[gispos]

New build! Thanks for your patience; I intentionally took a break from the forum for these weeks.
Avisynth r4565
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4565

20260328 3.7.5.r4565 (pre 3.7.6)
--------------------------------
- Fix: LruCache self-tuning cache resize: raised ghost-hit threshold from ghosted>0 to ghosted>1,
preventing unbounded cache growth during backward seeking (Issue #379) and Bob/SeparateFields
access patterns (Issue #270).


Now the strange behavior of QTGMC is also fixed: https://forum.doom9.org/showthread.php?t=186869
After playback a few frames back and the playback became significantly slower and started to jerk. Was worse with 32bit than with 64bit.

This fix is ​​very nice!

Edit:
Edit deleted. Error on my part.

[flossy_cake]

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

- Fix: LruCache self-tuning cache resize: raised ghost-hit threshold from ghosted>0 to ghosted>1,
preventing unbounded cache growth during backward seeking (Issue #379) and Bob/SeparateFields
access patterns (Issue #270).


Hi pinterf and thankyou for all your hard work keeping Avisynth alive.

I am testing the x64-win7 build and these were my findings just now...

1. Text() crash with "\n"


ColorBars().KillAudio().ConvertToYV12()

return Text("\n", lsp=0) # crash
#return Text("\n", lsp=undefined()) # no crash
#return Text("n", lsp=0) # no crash


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


2. Issue #379 (https://github.com/AviSynth/AviSynthPlus/issues/379#issue-2056158737) appears unresolved


ColorBarsHD().KillAudio()
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Prefetch(4)


Testing with AvsPMod:

1. Let it play for 200 frames, then pause
2. Hold left arrow to framestep backwards for 50 frames to frame 150
3. Press play

Result on my system:

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


Testing with MPC-HC + LAV (I think LAV Splitter is the one calling Avisynth.dll?)

1. Let it play for 200 frames, then pause
2. Tap "frame-step back" key multiple times (key can be set in MPC-HC's Options > Player > Keys)

Result on my system:

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


I will need to test this on my Win10 machine tomorrow with the standard x64 build.

That Win10 machine is more powerful and I think the smaller the CPU load, the less of an issue #379 becomes. That's why I had to put all that resizing of 4k->1080p->4k to put some load on the CPU otherwise there is no issue.

It's some weird thing when the CPU gets loaded up and you get some kind of cache thrashing?

Maybe we can try changing the ghost-hit threshold? Could you maybe add some testing options for me via SetCacheMode()? Like ghosted>2, ghosted>3, ghosted>4 etc ?

:thanks:

[flossy_cake]

Have tested on my win 10 machine (12600KF CPU).....Text("\n", lsp=0) does NOT crash on the Win10 build. Issue #379 still present.

[StvG]

Have tested on my win 10 machine (12600KF CPU).....Text("\n", lsp=0) does NOT crash on the Win10 build.

This crash does occur in both Windows 10 and Windows 11 when using AviSynth Intel compiler build.

[real.finder]

I think if someone wants to save memory then SetMemoryMax is not the right tool, because it can slow everything down.
It would probably be really useful to have an option in Avisynth to control the cache behavior, either more aggressively or not.
For me, please go in the aggressive direction. :)

maybe as 3 or CACHE_AGGRESSIVE http://avisynth.nl/index.php/Internal_functions#SetCacheMode ;)

and it will be nice if it get new auto default (maybe as -1 or CACHE_AUTO) option to see the available RAM and select the mode base on it, since mode 1 is use even less than the default (mode 0) (https://forum.doom9.org/showthread.php?p=1913370#post1913370)

[gispos]

maybe as 3 or CACHE_AGGRESSIVE http://avisynth.nl/index.php/Internal_functions#SetCacheMode ;)

and it will be nice if it get new auto default (maybe as -1 or CACHE_AUTO) option to see the available RAM and select the mode base on it, since mode 1 is use even less than the default (mode 0) (https://forum.doom9.org/showthread.php?p=1913370#post1913370)
Everything is going wrong for me today.
I just wanted to delete my previous posting. I loaded version 3.5 and thought it was the new one.

I tested CacheMode once with 1 and it got stuck, so I have to test again.
I will now delete my previous posting.

Edit:
I'm not happy with the cache behavior of the last version, in contrast to an old 3.5 version that caches 30 frames (bookmarks) without any problems, the new version already has problems with 10 frames. Frames that have already been cached are repeatedly thrown out of memory.

[real.finder]

now most of the important plugins get this fix, which are:-

http://avisynth.nl/index.php/FFT3DFilter

http://avisynth.nl/index.php/Dfttest

http://avisynth.nl/index.php/ManyPlus

https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest

------------------------------

and here plugins that still dont get the fix:-

http://avisynth.nl/index.php/VariableBlur

http://avisynth.nl/index.php/Spectrogram

https://github.com/HomeOfAviSynthPlusEvolution/neo_FFT3D (at least not in the Releases)

https://github.com/Asd-g/AviSynth-FFTSpectrum

DePan, DePanEstimate and mvtools https://github.com/pinterf/mvtools/issues/65

http://avisynth.nl/index.php/KPassFilterCL


did I forget one? :)

Mvtools2 and DePans (with DePanEstimate) get the fix thanks to pinterf update!

[pinterf]

Thanks for the feedbacks, I'll slowly process them.
EDIT: zero-line-length Text crash is fixed (commit and test-release later)

[flossy_cake]

Is there something special about frame number 8 in relation to caching/multithreading?

Because inside GetFrame if I track nonlinear frame access by storing the current frame number into a class member variable and look at its value on the next frame, seeking often causes the prefetcher to make all these random GetFrames to frame number 8 even when I am thousands of frames ahead and have been playing video for 30 seconds.

Then after a while (sometimes up to 30 seconds) it settles down and stops randomly getting frame 8 and i get nice linear pattern again. But it's always frame 8, which is weird - is that hardcoded somehow? This is with MT_SERIALIZE and prefetch(4). This is also different to how it behaves inside a ScriptClip where I dont get these random requests of of frame number 8 (I still get some nonlinear access of course, that's part and parcel with multithreading, but it's not the same frame 8 again and again).

Grok sez...


Why frame 8 specifically?

The prefetcher in AviSynth+ does not pick random low numbers. It has internal logic that often causes it to (re)request a small fixed offset or a specific early frame during certain situations.
The number 8 is very common because:

Default prefetch window / step size
Many parts of the prefetch/cache system use small look-ahead values (often 4, 6, 8, or multiples of 8). Frame 8 is a frequent "probe" or "anchor" point when the prefetcher is trying to detect the access pattern at the start of a new range, after a cache miss, or when filling small gaps.

Cache validation / pattern detection
The core sometimes issues a request for frame N mod 8 or a small fixed frame like 8 when it wants to check consistency, validate the cache state, or when it temporarily "resets" its linear prediction after detecting a skip/jump. Frame 8 is a safe, small, non-negative number that is often used as a sentinel or test frame in the prefetch thread.

Alignment with internal constants
Several internal structures and default values in AviSynth+ (cache window sizes, prefetch distance, alignment-related code) are powers of 2 or multiples of 8. Frame 8 ends up being a "popular" low frame that the prefetcher falls back to when it needs to issue an out-of-order request for housekeeping reasons.

In short: Frame 8 is not special to your video — it's special to AviSynth+’s prefetch/cache implementation. It’s a recurring "noise" frame that many developers see when they add debug logging to MT_SERIALIZED filters.
Why it appears "sporadically"
It usually happens right after:

A cache miss higher up the chain
Small skips created by the prefetcher (e.g. requesting 96 → 98 → 100)
When the prefetch thread is trying to fill gaps or re-synchronize its prediction
After seeking or at the beginning of a new playback segment


edit: seem to have gleaned a pattern:


Prefetch(n) Frame number of random getframes

Prefetch(4) 8
Prefetch(2) 4
Prefetch(1) 2



So it seems to be double the prefetch value.

So let's say I'm using Prefetch(2) and I'm on frame 5000, the access pattern randomly goes like this:

5000, 5001, 5002, 5003, 4, 5004, 5005, 5006 etc...

And if I use Prefetch(4) it goes:

5000, 5001, 5002, 5003, 8, 5004, 5005, 5006 etc...

So I guess that's probably normal then?

________________________

edit: I guess it must be because the 3rd parameter of Prefetch is "frames" which defaults to threads*2. Coincidence?

edit: huh that's weird, if I get rid of a PropShow() which I'm using to track nonlinear access through frame properties, the problem goes away. It also goes away if I put a RequestLinear() between the MyFilter() and PropShow() (but not if I put it before MyFilter) suggesting PropShow is somehow the culprit who is triggering the frame cache to spaz out. Tried using Text() inside ScriptClip to print out my frame props and got the same issue, so it must be something to do with writing text overlays. Oh well at least I can dodge it now. And turning multithreading off altogether solves it too.

[wonkey_monkey]

Years later I'm still in the dark about the whole #define AVS_LINKAGE_DLLIMPORT / AVS_Linkage thing.

It seems you can do one of two things when compiling a plugin: either define AVS_LINKAGE_DLLIMPORT and link to avisynth.lib, or create your AVS_linkage variable which you set to the passed vectors parameter on initialisation.

Is one preferred over the other?

[Columbo]

Preferred by who? ;) Personally I prefer the second. Not for any reason but only because it's the method used by the sample plugins I modeled stuff on way back when.

[qyot27]

If you ask me, everyone should be strongly encouraged to move to opening the core with LoadLibrary or dlopen, and skip linking to it entirely. Examples of which are the way the FFMS2 C-plugin accesses the core or presumably by using this C++ wrapper that Asd-g published:
https://github.com/Asd-g/avisynthplus-c-api-dynamic-loader

[Reel.Deel]

did I forget one? :)

I think DeFreq should also be on the list. Someone recently added high bit-depth and additional colorspaces to it. Not sure if it has "the fix" - https://github.com/Kraz3yIvan/DeFreqPlus

[rgr]

https://github.com/HomeOfAviSynthPlusEvolution/neo_FFT3D (at least not in the Releases)


You can remove the neo_fft3d plugin and use:
1. QTGMC: denoiser="fft3dfilter"
2. TemporalDegrain2: limitFFT=11 (use fft3dfilter for limiting)

[real.finder]

I think DeFreq should also be on the list. Someone recently added high bit-depth and additional colorspaces to it. Not sure if it has "the fix" - https://github.com/Kraz3yIvan/DeFreqPlus

I dont think it has the fix, anyway, the new list

The fftw library planner function is not thread safe. A simple instance of plugin can make it thread safe on its own. But when there are multiple instances and/or different plugins that use fftw DLLs, they can still mess into each others planner.

Avisynth's new v12 interface can help with this topic, if they use the same "global lock", different instances and plugins can safely work together.

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/Cplusplus_api.html#cplusplus-acquiregloballock

The original issue:
https://github.com/AviSynth/AviSynthPlus/issues/444

now most of the important plugins get this fix, which are:-

DePan, DePanEstimate and mvtools https://github.com/pinterf/mvtools/issues/65

http://avisynth.nl/index.php/FFT3DFilter

http://avisynth.nl/index.php/Dfttest

http://avisynth.nl/index.php/ManyPlus

https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest

------------------------------

and here plugins that still dont get the fix:-

https://github.com/Kraz3yIvan/DeFreqPlus

http://avisynth.nl/index.php/VariableBlur

http://avisynth.nl/index.php/Spectrogram

https://github.com/HomeOfAviSynthPlusEvolution/neo_FFT3D (at least not in the Releases)

https://github.com/Asd-g/AviSynth-FFTSpectrum (edit: done in 1.1.2)

http://avisynth.nl/index.php/KPassFilterCL

[pinterf]

If you ask me, everyone should be strongly encouraged to move to opening the core with LoadLibrary or dlopen, and skip linking to it entirely. Examples of which are the way the FFMS2 C-plugin accesses the core or presumably by using this C++ wrapper that Asd-g published:
https://github.com/Asd-g/avisynthplus-c-api-dynamic-loader
Thanks to pointing to this repo, I have an in-queue C-plugin project (AvsInpaint) on which I can apply this and experiment with.

[pinterf]

While working on an update for AvsInPaint, and performing comparison tests with different formats I noticed inconsistent behavior between various Avisynth merge methods (Overlay, Layer, and Merge). I found pixel differences and issues with near-max pixel merge data.
Frustrated by these inconsistencies, I started a huge refactoring project to remove the redundant code base and rewrite this section. This was a much larger task than I thought originally, it triggered more and more places to look into, I found several unoptimized paths as well.
This has been my primary focus for the past month, but I am finally nearing completion. I'll be back then.

[tormento]

I'll be back then.
Thank you for your time and devotion.

[flossy_cake]

Is propGetAll (http://avisynth.nl/index.php/Internal_functions/YDifferenceToNext#propGetAll) working correctly for arrays, or is it only returning first element?


If the property value for a given key is an array again then "value" will be an array as well.


I can only access the first element:


BlankClip()
propSet("Array", ["one", "two", "three"])
PropShow()

ScriptClip(last,
\ """
props = propGetAll()
string = ""
for (i=0, ArraySize(props)-1){
string = string + String(props[i,0]) + " = " + String(props[i,1]) + "\n"
}

return Text(string, lsp=0, align=5)

\ """, after_frame=true, local=false)



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


If props[0,1] was an array, then stringifying the array should just give an empty string, not "one".

I have tried props[0,1,1] or props[0][1][1] to try and retrieve "two" (second element of array) but it gives errors like array index out of bounds and such.

:thanks:

[gispos]

Is propGetAll (http://avisynth.nl/index.php/Internal_functions/YDifferenceToNext#propGetAll) working correctly for arrays, or is it only returning first element?

If props[0,1] was an array, then stringifying the array should just give an empty string, not "one".

I have tried props[0,1,1] or props[0][1][1] to try and retrieve "two" (second element of array) but it gives errors like array index out of bounds and such.

:thanks:

That's how it works for me, maybe there are other ways...
Oh, I see your question refers to propGetAll(). Then my answer is probably incorrect.
Using 'propGetAll' only returns the array of all Frame properties.
To iterate through the array of a single property, you need to use a separate 'for' loop on the array.

BlankClip()
propSet("Array", ["one", "two", "three"])
PropShow()

ScriptClip(last,
\ """
ar = propGetAsArray("Array")
str = ""
for (i=0, ArraySize(ar)-1){
str = str + ar[i] + "\n"
}

return Text(str, lsp=0, align=5)

\ """, after_frame=true, local=false)


https://i.postimg.cc/sD9J96dR/arrayget.jpg

[Boulder]

I updated my Avisynth installation since a long time, and noticed something weird with this combination and multithreading in AVS+. This is a 3840x2160 UHD source. When opened in VDub, the video looks like it was first downscaled heavily, then upscaled back. If I comment out the cropping or Prefetch, it works fine. Also if I use jpsdr's multithreaded resizers instead of internal ones, it works fine.

DGSource("W:\dovi\hot\hot.dgi")
Crop(0,44,-0,-44)
z_ConvertFormat(pixel_type="RGBPS", chromaloc_op="auto=>same", colorspace_op="auto:auto:auto:auto=>rgb:linear:same:full", cpu_type="AVX2", approximate_gamma=true, use_props=3)
BicubicResize(2560, 1384)
z_ConvertFormat(pixel_type="YUV420P16", cpu_type="AVX2", approximate_gamma=true, dither_type="none", use_props=4)
Prefetch(threads=12, frames=4)

I was able to determine that r4392 works but r4400 already has this issue.

[pinterf]

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

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

**20260518 3.7.5.r4604 (pre 3.7.6)**
--------------------------------
- Subtitle: add "placement" string parameter — chroma location hint for subsampled
YUV (4:2:0, 4:2:2, 4:1:1). When gdi=true, all three siting modes are supported:
"MPEG2"/"left" (default), "MPEG1"/"center", and "top_left" (UHD 4:2:0/4:2:2).
Default is read from the _ChromaLocation frame property, falling back to "left".
When gdi=false only "left" and "center" are implemented (same as Text).
- Subtitle: add "gdi" bool parameter. When false, Subtitle uses the built-in bitmap
font (Terminus) instead of Windows GDI rendering (same path as Text). Faster and
cross-platform compatible; placement is then limited to "left"/"center".
Default: true.
See at https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/subtitle.html
- Text: add "gdi" bool parameter (accepted, has no effect; API compatibility with
Subtitle — on non-Windows Subtitle is aliased to Text). Default: false.
- Subtitle Antialiaser (Windows GDI): GetAlphaRect() now has SSE4.1, AVX2, and
AVX512 SIMD implementations.
Internal mask buffer refactored to row-interleaved SoA layout for correct
chroma-placement-aware UV compositing via prepare_effective_mask_for_row
downsampling (8 MaskModes covering all subsampling ratios x siting variants;
SIMD rowprep dispatch matching Overlay/Layer).
- ShowCRC32: new "channels" (select planes), "mode" (0=combined, 1=per-plane), and
"showmode" (0=display, 1=display+frameprop, 2=frameprop only) parameters;
frame property "ShowCRC32" is an int64 array of unsigned 32-bit CRC values;
planar RGB(A) planes always in R,G,B,A order; packed formats with default parameters
hash the raw buffer unchanged (backward-compatible).
See at https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/showframes.html
- rstdoc: document Invert's chroma inversion behavior
See at https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/invert.html

20260506 3.7.5.r4589 (pre 3.7.6)
--------------------------------
TL;DR (since r4565):
- Layer/Overlay/Merge: weighted and masked-merge kernels unified into a shared family (C/SSE4.1/AVX2/NEON);
SIMD chroma-placement mask downsampling for 4:2:0/4:2:2/4:1:1 sources;
"placement" parameter for Overlay "blend" (new) and Layer (new "top_left" option added):
values are "mpeg2" (default), "mpeg1", "top_left".
See at https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/layer.html
- Layer: new "mulovr" mode (Overlay-compatible YUV multiply with luma-driven chroma desaturation);
new "top_left" placement option; legacy MMX/iSSE removed.
- Merge (non-masked) C/SIMD integer arithmetic unified.
- SIMD additions: AVX2/SSE4.1/NEON float chroma-mask row preparation; AVX2 float weighted merge.
- Further optimizations: Invert (AVX2/SSE2), ExtractX (direct packed-RGB path),
ConvertBits int depth-reduce C loop, PlanarRGB(A)->RGB32/64 (AVX2).
- SetFilterProp: conditional injection by filter argument value; capture mode;
SetFilterPropPassthrough helper; GetFilterProps() diagnostics function.
See also: https://github.com/AviSynth/AviSynthPlus/issues/393
and the online documentation at https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/setfilterprop.html

- Bug fixes: Text("\n") crash on zero-length lines; Layer no longer silently rounds odd x/y
offsets on subsampled YUV — accepts them as-is like Overlay; ceiling formula for
non-grid-aligned positions — last chroma column/row is no longer skipped in either filter.

[jpsdr]

Hi.
I've made some benchmarks (results will be posted later in appropriate thread), doing them i've noticed something...

I was benchmarking my MT resizer, when i've noticed something odd with the number of threads reported by AVSMeter.


Core i7 860 (4 cores / 8 threads)
-----------

Windows 7 x86
AVS 2.60 (2.6.0.6)

My MT resizer
threads=1: (1 thread)
threads=2: (3 threads)
threads=4: (5 threads)
threads=8: (9 threads)

This is old standard AVS, nothing odd.


Rizen Threadripper Pro 7975WX (32 cores / 64 threads)
-----------

Windows 10 x64
AVS+ 3.7.5 (r4657)

Internal Bicubic
No Prefetch: (68 threads)
Prefetch(4): (72 threads)
Prefetch(32): (100 threads)
Prefetch(64): (132 threads)

When i saw this insane number of threads with my MT resizer, i've tested with the internal resizer instead, to be sure it wasn't from my side.
The number of threads increase with the Prefetch value, expected, but why 68 threads in the first place when there is nothing with multithreadind enabled ?

For No Prefetch, the script is just :

ColorBars(3840,2160,"YV24").KillAudio().trim(0,199)
BicubicResize(width/2, height/2)

[pinterf]

Good question, maybe an autoloaded plugin is starting its thread pool?

[jpsdr]

Good remark.
Easy to check, so i deleted all the files in plugins64 and plugins64+ directories.
Same results, so all these threads are created by AVS+, even when no prefetch required.

[qyot27]

Could avsmeter simply be reporting OS thread initialization?

[StvG]

It looks more like thread pool with size of the total logical threads is initialized and locked even if it's not used.
I tested with 20 logical threads CPU and got 24 threads - 20 threads pool (1 per logical thread) + 4 threads for baseline processes (AVSMeter main thread, AviSynth core management, OS memory/caching threads).

[pinterf]

My figures are 22 threads with 8 core/16 logical processors (i7-11700)

[pinterf]

Status update: I'm currently integrating the (hopefully final) AVX-512 resampler implementations based on DTL's code and ideas (detailed speed tests and their evaluation and the million of small tuning trials require a lot of work and time), along with a few extra tweaks and fixes.
Beyond this, I don't really want to add any more new features into current version, unless of course when an annoying new bug or an extremely challenging feature request pops up.

[jpsdr]

It looks more like thread pool with size of the total logical threads is initialized and locked even if it's not used.

If it was the case, the number of threads shouldn't increase when Prefetch is used. But as you see in my post, the number of threads increases according the value of Prefetch, meaning, and it's a good thing, that the prefetch threadpool size is just tuned according the prefetch value.

[pinterf]

I suppose that the default thread pool, which is always created, would serve the possible (not-so-widely-used and never really finalized) IScriptEnvironment2 entries:

(from Avisynth.h: )

virtual IJobCompletion* __stdcall NewCompletion(size_t capacity) = 0;
virtual void __stdcall ParallelJob(ThreadWorkerFuncPtr jobFunc, void* jobData, IJobCompletion* completion) = 0;

Unlike some other former IScriptEnvironment2 calls, I did not dare to pull these two back to our standard IScriptEnvironment.

Prefetcher's threading is an addon on top of this.

Moreover: multiple Prefetch oocurencies in the script with different thread count specification will start their own prefetch thread pool.

[jpsdr]

Ah...! I forgot this one existed !
Now it make sense.

[StvG]

My figures are 22 threads with 8 core/16 logical processors (i7-11700)

Did you test with completely empty default plugins folder?

I too have two extra threads when I have plugins in the default plugins folder (autoloading path).

[pinterf]

Did you test with completely empty default plugins folder?

I too have two extra threads when I have plugins in the default plugins folder (autoloading path).
No, I'm full with autoloaded plugins, it was just a quick out-of-box test.

[jpsdr]

Is possible... no is it easy to make something (like using a "first time boolean") to create/allocate this threadpool only if the feature is used, for exemple on the first call of ParallelJob (or any similar feature function) ?

[pinterf]

New build: AviSynth+ r4626
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4626

Featuring a tweaked AVX-512 (both base and "fast") resampler update. Thanks to DTL for his implementation and ideas, which I then tweaked further to achieve more speed and acceptable performance with MSVC and for AVX-512 baseline (pre-Ice-Lake) as well. This part is a massive update; no wonder it took a year to reach this point (though with large gaps in the timeline when I had no time or was overwhelmed by the continous code changes). The development process was like an evolution: to see what worked, at least four times as many candidate ideas were implemented, many of which ultimately didn't make the cut.

Aside from this, there are no new features, mainly two reported bug fixes and other regression fixes that I uncovered here and there.

[StainlessS]

Lots of work there P, great Respect ensues.

Thanks muchly :)

[StainlessS]

@Pinterf,

Perhaps you might find this video from YT of interest.
21 Yr Old Disproves 4 Decades Old Belief in Computing :- https://www.youtube.com/watch?v=EdVG5qNm2rY

Link to Andrew's Paper on "Optimal Bounds for Open Addressing Without Reordering"
https://arxiv.org/pdf/2501.02305 [EDIT: Paper from Feb 2025]


TIMESTAMPS:
00:00 - Introduction
02:09 - What is a Hash Function?
07:37 - Andrew's Education and Work
18:34 - How His Work Changes the Future

Discover how Andrew Krapivin overturned a legendary 40-year-old conjecture in theoretical computer science regarding hash tables. In this video, we explore the mathematics of "Elastic Hashing" and how it shatters the speed limits once set by Turing Award winner Andrew Yao.

For decades, the "speed limit" of data structures was thought to be set in stone. Hash tables are the "filing cabinets" of the internet, powering everything from database records to web browser passwords. However, computer scientists long believed that as these tables approached 99% capacity, performance would inevitably crash—a phenomenon known as the "problem of the full parking lot".

In 1985, Andrew Yao codified this belief, suggesting that any "greedy" strategy for placing data was at the mercy of linear probability: if only 1 in 1,000 slots are empty, you’d have to check 1,000 slots to find one. This created a forced choice: you could have a fast hash table or a full one, but never both.

Andrew Krapivin, a 21-year-old undergraduate at Rutgers, didn't even know this famous conjecture existed. While working on a side project for memory compression, he realized that traditional methods failed because they were "greedy"—they always grabbed the first available spot, which created massive "traffic jams" of data. Krapivin’s solution, Elastic Hashing, is brilliantly counterintuitive.

Instead of taking the first open slot, the algorithm intentionally skips empty spaces to create "firebreaks". These strategic gaps prevent data clusters from merging, keeping the system running with the snap and speed of a nearly empty structure—even at 99.99% capacity.
This discovery isn't just a mathematical curiosity; it has massive implications for the future of Edge AI and database efficiency.

And here a youtube comment from the video comments section {by @pebbleschan6085} :)
Elastic hashing is a prior art created by nature ; it is exhibited by men going to a mens room and selecting an available urinal or cubicle when the next man always evaluates the current state and chooses the most equally distant one from occupied ones.

EDIT: From Feb 2025, so maybe you're already aware of the breakthrough.

[hello_hello]

Am I misinterpreting the new matrix options when converting from YUV to YUV? (AviSynth+ r4626)
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html#syntax-and-parameters

YUV→RGB→YUV conversion using the specified matrix and range for each leg:

ConvertToYUV444(clip, matrix="601:l=>709:l")
# SD limited input, HD limited output

Should the above example perform a matrix conversion when converting from YUV to YUV, similar to a conversion with the ColorMatrix plugin?
If that's the case, it appears not to be working.

Cheers.

[hello_hello]

Anyone else experienced this when using LSFMod with Avisynth+ r4626? (Ryzen 7900X CPU)
I've tried a few different versions of LSFMod back to version 1.9.
The video is YV12 with LSFMod() added to the script.
These are thumbnails. The full screenshots also show that much of the right side of the second image is black.

Avisynth+ r4549 (r4604 is also okay)
https://i.ibb.co/whVpjQXg/Avisynth-r4549.png (https://ibb.co/whVpjQXg)

Avisynth+ r4626
https://i.ibb.co/Fbp3svB0/Avisynth-r4626.png (https://ibb.co/Fbp3svB0)

[DTL]

Post a shortest possible script to check the issue. Looks like some blocks of samples at SIMD processing of the part of a row are not processed correctly. Also try to disable SIMD with SetMaxCPU("none") (at the beginnig of the script) to check if this is fixed.

[hello_hello]

The (almost) shortest possible script to reproduce the problem.

# SetMaxCPU("none")
ColorBars()
ConvertToYV12() # or YV24 or YV16
KillAudio()
LSFMod()

It's fine when SetMaxCPU("none") is used.
SetMaxCPU("AVX2") also appears to be okay.
The problem occurs with SetMaxCPU("AVX512base").

I'm running Avisynth+ in Wine, although hopefully that's not the cause, given earlier versions of Avisynth+ are okay.

[StainlessS]

HH,
I'm running Avisynth+ in Wine, although hopefully that's not the cause, given earlier versions of Avisynth+ are okay.
Maybe mod "ColorBars().info()" to the short script (display CPU flags).

https://www.amd.com/en/products/processors/desktops/ryzen/7000-series/amd-ryzen-9-7900x.html

Supporting Chipsets A620 , X670E , X670 , B650E , B650 , X870E , X870 , B840 , B850
CPU Boost Technology Precision Boost 2
Instruction Set x86-64
Supported Extensions AES , AMD-V , AVX , AVX2 , AVX512 , FMA3 , MMX-plus , SHA , SSE , SSE2 , SSE3 , SSE4.1 , SSE4.2 , SSE4A , SSSE3 , x86-64


EDIT:

# SetMaxCPU("none")
# SetMaxCPU("AVX512base")

ColorBars().Info()
ConvertToYV12() # or YV24 or YV16
KillAudio()
LSFMod()

[pinterf]

Am I misinterpreting the new matrix options when converting from YUV to YUV? (AviSynth+ r4626)
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html#syntax-and-parameters

YUV→RGB→YUV conversion using the specified matrix and range for each leg:

ConvertToYUV444(clip, matrix="601:l=>709:l")
# SD limited input, HD limited output

Should the above example perform a matrix conversion when converting from YUV to YUV, similar to a conversion with the ColorMatrix plugin?
If that's the case, it appears not to be working.

Cheers.
Sorry, the documentation went a bit ahead. Technically it could be done. But this type of conversion, which lacks going into linear domain, just doing a multiplied matrix operation in the gamma corrected nonlinear pixel data, cannot be exact (would just do the same as old colormatrix), though 601/709 are relatively close to each other but this type of transformation is discouraged, as I learned meanwhile.

[pinterf]

The (almost) shortest possible script to reproduce the problem.

# SetMaxCPU("none")
ColorBars()
ConvertToYV12() # or YV24 or YV16
KillAudio()
LSFMod()

It's fine when SetMaxCPU("none") is used.
SetMaxCPU("AVX2") also appears to be okay.
The problem occurs with SetMaxCPU("AVX512base").

I'm running Avisynth+ in Wine, although hopefully that's not the cause, given earlier versions of Avisynth+ are okay.
Reproduced on my i7-11700, and was probably fixed. Will test further and then make new builds tomorrow evening. Thanks for the report and thanks to DTL, too, who moved the issue to github.

[LigH]

Core filters: Overlay and mask filters (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters.html#overlay-and-mask-filters): The entry for Mask links to Layer (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/layer.html) instead of Mask (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/mask.html).

[Myrsloik]

The format support in avs+ is genuinely confusing. I tried to construct the constant for YUV440. And it doesn't error on construction. Instead it errors when creating a frame.

The relevant code is here:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/avisynth.cpp#L4377

Why have such an elaborate set of flags for subsamplings if I can't use them?

[v0lt]

The format support in avs+ is genuinely confusing. I tried to construct the constant for YUV440. And it doesn't error on construction. Instead it errors when creating a frame.
You can't just come up with a new format ID and hope it works.

[Myrsloik]

You can't just come up with a new format ID and hope it works.

Sure can. Just did.

[pinterf]

I'm on long holiday till July 31st w/o PC, and will continue pending tasks in August.

[qyot27]

The enums to control for color constants are basically just for being pieced together for the core's I/O, any new format needs to be explicitly defined and exported rather than made on the fly. It probably wouldn't hurt to actually provide some mechanism for that, albeit with a massive caveat utilitor attached.

That said, https://github.com/AviSynth/AviSynthPlus/pull/502

If there is some sort of problem for C++ plugins accepting what's in that PR, then sure. But it worked for libavformat being able to display the output of Version(pixel_type="YUV440") (or YUV440P10, P12).

[flossy_cake]

How much headache would it be to add namespaces to .avs scripts?

C++ supports namespaces and it looks fairly simple but I have no idea how the script parser works so it could be a nightmare for all I know.

I need namespaces for 2 reasons:

1. I use many ScriptClips all in the one .avs file, and to "see" outside of ScriptClip from within you need to use globals and gosh I have a lot of them now cause my ScriptClips uitlize many runtime frame counters, thresholds etc. that need to be read and/or modified by all ScriptClips at runtime. If I could put it all into a namespace then that avoids polluting the global namespace.

2. I can only call my main function once otherwise the second call would start overriding globals used by the previous call. With a namespace I could assign each function call a new namespace and avoid the issue.

Currently my plan to reduce my global namespace pollution is to append some random numbers or characters to the end of every one of my global names (big job) and then put some logic to disallow multiple calls.

But obviously a namespace would be much nicer.

If we take ScriptClip out of the equation, namespaces wouldn't be needed as we could just pass everything as function arguments. But actually even that might not work because there is a very conservative limit to the number of function arguments allowed by Avisynth, which I'm already brushing up against.

I had thought to maybe put all variables into 1 big array and pass that around as an argument, but that won't work either cause they can only be accessed by an integer index not a string index - you can't go globals["variable_name"]. And then if you want to modify it you can't go globals[0] = 3.14 because that's invalid you have to go globals = ArraySet(globals , 3.14, 0) which is probably slow too.

:thanks:

[wonkey_monkey]

I feel like I may have asked this before, but is there any way to access frame properties without having to get a PVideoFrame via GetFrame, and if not, should there be?

For example: some source filters will put the frame type (I, P, B) in a frame property. It could be very useful to scan all of these when a script loads, but if it means generating every frame then then it'll take far too long.

Conceptually it seems like frame properties should exist somewhere independent of video frame pixels. Or are the two inexorably tied together for backwards compatibility?

[v0lt]

How much headache would it be to add namespaces to .avs scripts?
I don't want new features right now. I'm waiting for the release!

[flossy_cake]

I feel like I may have asked this before, but is there any way to access frame properties without having to get a PVideoFrame via GetFrame, and if not, should there be?

For example: some source filters will put the frame type (I, P, B) in a frame property. It could be very useful to scan all of these when a script loads, but if it means generating every frame then then it'll take far too long.

Conceptually it seems like frame properties should exist somewhere independent of video frame pixels. Or are the two inexorably tied together for backwards compatibility?

I think I've asked a question like that before too but in the context of scripts, whether doing a PropGet forces a GetFrame.

The answer was yes, and I think it's by design since frame properties could be derived from the pixels, so the pixels have to be evaluated anyway.

eg. filters that write frame difference metrics, or scenechange status, or update the field order would need to evaluate the frame to calculate such properties.

But the source filter seems to be an exception to the rule, because its frame properties aren't calculated from Avisynth clip pixels, so I think you are right and it should be theoretically possible to make a special code path for source filter frame properties that doesn't require an internal GetFrame.

But I'm having trouble understanding how this could be a performance issue if you are getting the frame properties immediately after the source filter in which case you should be getting probably thousands of frames per second in a benchmark. What's your use case scenario? Are you trying to prescan the source filter's frame properties of every frame? Like, potentially hundreds of thousands of frames?

[StvG]

I feel like I may have asked this before, but is there any way to access frame properties without having to get a PVideoFrame via GetFrame, and if not, should there be?

For example: some source filters will put the frame type (I, P, B) in a frame property. It could be very useful to scan all of these when a script loads, but if it means generating every frame then then it'll take far too long.

Conceptually it seems like frame properties should exist somewhere independent of video frame pixels. Or are the two inexorably tied together for backwards compatibility?

This is more related to the source filters. They know the frame type without decoding needed. So, the source filter can expose function to get only frame type without decoding / getting the pixel data.

[gispos]

...
For example: some source filters will put the frame type (I, P, B) in a frame property. It could be very useful to scan all of these when a script loads, but if it means generating every frame then then it'll take far too long.

+1
It would be wonderful to have functions for communicating directly with the source filter. Two things would be of interest: '_PictType' and '_AbsoluteTime'.

[flossy_cake]

I don't want new features right now. I'm waiting for the release!

Fair enough, maybe it's more appropriate to implement it as a standalone plugin kind of like GScript, something like this...


GScript("""

namespace MySpace {

global MyCounter = 0 # only stuff inside MySpace sees this

ScriptClip(last, """

global MyCounter = MyCounter+1
return last.Text(String(MyCounter))

""")

}

""")


Because then we don't have to mess around with Avisynth script parser and risk breaking stuff .