AviSynth+ thread Vol.2

[pinterf]

AviSynth+ 3.7.3 r4217

https://github.com/pinterf/AviSynthP...ag/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]

Originally Posted by pinterf

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]

Originally Posted by 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.

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

Originally Posted by wonkey_monkey

I think I've found another version of this old issue (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 ), 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]

Originally Posted by DTL

"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]

Originally Posted by 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) ?

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]

Originally Posted by 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.

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]

Originally Posted by StvG

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]

Originally Posted by DTL

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]

Originally Posted by pinterf

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.p...81#post2015981



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

[pinterf]

Originally Posted by DTL

Oh - I remember second use case - noted in the https://forum.doom9.org/showthread.p...81#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.