AviSynth+ thread Vol.2

[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.