AviSynth+ thread Vol.2

[pinterf]

...
instead, by talking directly to the preceding filter (which can also pass messages further up, if required), I can pass a pointer to a container and get all of those preceding filters to push their data into it. You could also use a filter to modify a preceding filter's behaviour (probably against the ethos of a filter chain, but potentially a useful trick), which you couldn't do with frame properties.

It wouldn't be a pointer to a frame, it would be a pointer to the filter instance (or just one of its variables) which generated the clip. With that you could access its methods, which might include one that generates and returns the padded, hierarchical data, or what have you (mvtools is maybe not the best example since passing such data as frames does make some sense; but there are other cases where it's not visual data, or isn't even per-frame data).

I dunno, maybe it is a silly idea that few other people would ever have a reason to use. But - if I'm not mistaken - it would be pretty much zero-cost to implement, practically a one-liner like GenericVideoFilter::GetAudio.
Your ideas are never silly. You are one of the rare Avisynth developers who create *new* plugins and ideas. (Unlike me, who is just a plugin maintainer/fixer/enhancer).

So you'd like to create a wormhole or a message queue between filter instances?

[wonkey_monkey]

So you'd like to create a wormhole or a message queue between filter instances?

Pretty much, but the details can be left to authors as long as they can pass an AVSValue upward. In that way it's complementary to frame properties, which propagate downward.

I'm not too clear on exactly what's required to do this but I'm guessing IClip needs to handle a base case and maybe return a void AVSValue, while GenericVideoFilter's override will pass the value up to the parent (sorry, child! :D)

Could it be as simple as:


AVSValue IClip::ReceiveMessage(AVSValue input) { return AVSValue(); }

AVSValue GenericVideoFilter::ReceiveMessage(AVSValue input) { return child->ReceiveMessage(input); }


?

Or to go really barebones:


void IClip::ReceiveMessage(void* input) { }

void GenericVideoFilter::ReceiveMessage(void* input) { child->ReceiveMessage(input); }


and let authors figure everything else out for themselves!

[LigH]

I have a question about the ColorBars plugin.

ColorBars is a core filter, not a loadable plugin DLL.

There are several possible FourCC's for 32-bit RGB in AVI. But I guess ffmpeg will use an internal video format identifier instead when using an internal AviSynth demultiplexer...

I use ffmpeg with avisynth 3.7.3+.

The current documentation is in the AviSynth+ Docs (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/colorbars.html). I hope you can find more details there.

[Jamaika]

ColorBars is a core filter, not a loadable plugin DLL.

There are several possible FourCC's for 32-bit RGB in AVI. But I guess ffmpeg will use an internal video format identifier instead when using an internal AviSynth demultiplexer...
Thank you for your answer. I was surprised by the creators' answer.
When we enter RGB32, only the alpha channel is displayed.
To unlock the rest, use the function RGBAdjust(ab=255)

And one more thing contrary to wiki documentation. No RGB is supported using KNLMeansCL. And everything is clear.
What isn't clear to Jamaika. Does OpenCL support Intel processors without graphics card? It is about the CPU option.

[LigH]

In general, OpenCL is an abstraction library for complex calculations. It does not require GPGPU support per se, it can be implemented in CPU SIMD instructions too. But it usually gains a lot of efficiency from massive parallelism in GPGPU's.

PS: Who do you mean by "the creator"?!

[Jamaika]

In general, OpenCL is an abstraction library for complex calculations. It does not require GPGPU support per se, it can be implemented in CPU SIMD instructions too. But it usually gains a lot of efficiency from massive parallelism in GPGPU's.
I have an inactive CPU for Intel. How do I set the BIOS? What drivers should I install for Intel i5-13600K?

PS: Who do you mean by "the creator"?!
https://github.com/pinterf/KNLMeansCL/pull/9

[LigH]

I have an inactive CPU for Intel. How do I set the BIOS? What drivers should I install for Intel i5-13600K?

I don't think you need to set any special option in the BIOS, as a CPU-only OpenCL driver would just use CPU instructions available for every application.

I do not have any intel CPU. So I can only guess that Intel® CPU Runtime for OpenCL™ Applications with SYCL support (https://www.intel.com/content/www/us/en/developer/articles/technical/intel-cpu-runtime-for-opencl-applications-with-sycl-support.html) might be the one you are interested in; no warranties.

[Jamaika]

Thanks LigH. I thought it was impossible. I was convinced that OpenCL was overriding Windows. I also don't see an option to connect openCL GPU and CPU although press wrote about it some time ago. For x264 it's always GPU.It even works. Is OpenCL needed today when there is CUDA?
Intel processor without graphics card:
https://ibb.co/fHQCsbv

[LigH]

Is OpenCL needed today when there is CUDA?

I remember that Universe Sandbox is not able to use CUDA because it only supports single precision calculations. It works well with OpenCL.

[tormento]

No RGB is supported using KNLMeansCL.
Dunno your needs but for noise reduction BM3D is vastly superior, even if lot heavier and unfortunately it needs CPU for the temporal part.

[pinterf]

And one more thing contrary to wiki documentation. No RGB is supported using KNLMeansCL. And everything is clear.
What isn't clear to Jamaika. Does OpenCL support Intel processors without graphics card? It is about the CPU option.
Wiki is O.K. As it says, KNLMeans supports packed _and_ planar RGB, except RGB24 and RGB48.

[Jamaika]

Wiki is O.K. As it says, KNLMeans supports packed _and_ planar RGB, except RGB24 and RGB48.
I disagree.
Supported color formats: RGB32, Y8, YV12, YV16, YV24, YV411
AviSynth+: all planar formats (8/10/12/14/16/32bit, Y/YUV/RGB with or without alpha) are supported. RGB64 is also supported.

Test original:
ColorBars(width=640, height=480, pixel_type="rgb32")
KNLMeansCL(device_type="gpu",device_id=0)

KNLMeansCL: 'info' requires Gray8 or YUVP8 color space!

I added no display information. After corrections:
https://ibb.co/t3BYVkg

[pinterf]

I disagree.
Supported color formats: RGB32, Y8, YV12, YV16, YV24, YV411
AviSynth+: all planar formats (8/10/12/14/16/32bit, Y/YUV/RGB with or without alpha) are supported. RGB64 is also supported.

Test original:
ColorBars(width=640, height=480, pixel_type="rgb32")
KNLMeansCL(device_type="gpu",device_id=0)

KNLMeansCL: 'info' requires Gray8 or YUVP8 color space!

I added no display information. After corrections:
https://ibb.co/t3BYVkg
False alarm. If you do your own build where
- you intentionally changed the source and hardcoded info="true" (?? why?)
- despite you know about the error message ("KNLMeansCL: 'info' requires Gray8 or YUVP8 color space!")
Then it is the plugin which does not work??

No more comments.

[Jamaika]

Thanks for the explanation. For Jamaica it was convoluted and complicated. I added the info parameter so that there would be an automatic test of the GPU card when removing white Gaussian noise.
If the user finds that it is good, he can disable the parameter.
What surprises Jamaica? That he has to look for the number of colors for 8/16bit RGB and has to give an external parameter to display these colors.
ColorBars(width=640, height=480, pixel_type="rgb64")
KNLMeansCL(device_type="gpu",device_id=0,info=false)
RGBAdjust(ab=65535)

[Jamaika]

Dunno your needs but for noise reduction BM3D is vastly superior, even if lot heavier and unfortunately it needs CPU for the temporal part.
Thanks for the info. Is this plugin or some replacement also for avisynth?

[tormento]

Thanks for the info. Is this plugin or some replacement also for avisynth?


It’s a plugin for VS, ported to AVS+ too.

[FranceBB]

Out of curiosity, I'm gonna put it out here 'cause I wouldn't know where else to put this, but I've got a live recorded feed which was quite interesting once indexed it in terms of frame properties:

frame 1 to 13 (matrix, transfer, primaries as BT709)
frame 14 to 910 (matrix, transfer, primaries are missing)
frame 911 (matrix BT709, transfer, primaries are missing)
frame 912 to 922 (matrix, transfer, primaries as BT709)

This wasn't made by several appended clips, it's a single interview transmitted via a satellite feed and encoded by an hardware encoder.

https://i.imgur.com/wLiwn3J.pnghttps://i.imgur.com/oQWnTD9.png
https://i.imgur.com/ecVJW2G.pnghttps://i.imgur.com/9iLlHCt.png

With Avisynth now carrying frame properties, those were "transmitted" to FFMpeg but remained statically set as BT709, thus making the encode go through. :D
FFMpeg itself on the other hand isn't able to read the input on its own 'cause if you -i the source.mxf file instead of the AVS Script.avs then it sees them changing and it really really really didn't like that:

[vf#0:0 @ 00000192f22fed40] Reconfiguring filter graph because video parameters changed to yuv422p(tv, unknown), 1920x1080

immediately followed by:

[swscaler @ 00000192f23de080] Unsupported input (Error number -129 occurred): fmt:yuv422p csp:unknown prim:reserved trc:reserved -> fmt:yuv422p csp:bt709 prim:reserved trc:reserved

which resulted in:

[vf#0:0 @ 00000192f22fed40] Error while filtering: Error number -129 occurred

[vf#0:0 @ 00000192f22fed40] Task finished with error code: -129 (Error number -129 occurred)

[vf#0:0 @ 00000192f22fed40] Terminating thread with return code -129 (Error number -129 occurred)


Sample (if you're curious): https://we.tl/t-qfePLdYbcM
Now, given that FFMpeg doesn't support changing frame properties, sticking with the same property at the beginning and setting it static was a smart move (as far as the Avisynth scripts are concerned) ;)
This can also be tested with a simple:

ColorBars(848, 480, pixel_type="YV12")

part1=trim(0, 5).propSet("_Matrix", 5)
part2=trim(6, 10).propSet("_Matrix", 1)

part1++part2


which doesn't make it crash and leaves the Matrix set to BT601 for the entirety of the clip.
In my opinion this is the expected behavior, so please don't change it.
In the meantime, however, I did open a ticket to the FFMpeg guys to get that fixed: https://trac.ffmpeg.org/ticket/11436
Have you guys ever faced anything like this?
By the way, with me being me I actually just take the nuclear option of going full propclearall(), but you know... :P

[DTL]

There were the feature request to implement 2D resampler engine in AVS core at ages of AVS 2 - https://sourceforge.net/p/avisynth2/feature-requests/113
Created: 2013-05-26
Milestone: Future Release
Status: accepted

Can we expect such engine in AVS+ core in 202x years so it can have Jinc-based resizers (also about any 1D kernel can be tested in 2D using radius length as agrument) ? At 202x years we got >10 GB RAM in typical execution host so it can store full-frame coeffs table in x64 mode for UHD frames with some usable kernel size (like 3..5 taps at least).

For fixed integer size upsampling the very low memory implenentations also possible (examples in master-1 branch of JincResize plugin at https://github.com/Asd-g/AviSynth-JincResize/tree/master-1 ) and running also faster because of no host RAM read traffic.

[FranceBB]

Does it mean that

Jinc36Resize()
Jinc64Resize()
Jinc144Resize()
Jinc256Resize()

are gonna be included in the core and won't require asd's plugin any longer, just like all the other currently available resizers?

[Jamaika]

For fixed integer size upsampling the very low memory implenentations also possible (examples in master-1 branch of JincResize plugin at https://github.com/Asd-g/AviSynth-JincResize/tree/master-1 ) and running also faster because of no host RAM read traffic.
I'm a lousy programmer. I don't know why the JInc plugin is reverted under AVS 2.0. The problem with plugins is also that ALING is always 64 under AVX512. Changing it to 32 under AVX2 doesn't necessarily have to work.

[DTL]

Jinc36Resize()
Jinc64Resize()
Jinc144Resize()
Jinc256Resize()


They are simply short names for JincResize(tap=N) where N from 3 to 8.

Jinc36Resize is an alias for JincResize(tap=3).
Jinc64Resize is an alias for JincResize(tap=4).
Jinc144Resize is an alias for JincResize(tap=6).
Jinc256Resize is an alias for JincResize(tap=8).

I really think of testing SinPow (soft of) and UserDefined2 kernels as 2D downsize. The UserDefined2 kernel is easier to convert to 2D with replacing sinc() to jinc() base function. So with JincResize they can form complementary downscale and upscale resizers for 2D resampling engine (same as SinPow and UserDefined2 for downscale and any Sinc-based resizer for upscale for 1D resample engine).

In libplacebo I see users already make some not very small set of resizers including 2D engine and some set of base kernels and weighting functions - https://github.com/Asd-g/avslibplacebo . Though the naming is completely messy and not directly shows if 1D or 2D resampler used (may be ewa-prefixed are 2D only ?). So 2D resizers are not lost in the past.

The main (complex) step required is implementing a 2D resampling engine in AVS+ core and next (easy) steps are addition of any possible (practically useful) kernels to it.

"I don't know why the JInc plugin is reverted under AVS 2.0."

May be it was in the very beginning of development and was not ported to AVS+ core because of too many issues at that time ? Though from 2013 - If someone does the hard yards and submits some working code I am happy to include it in a future version.

First AVS version of 2D resampler (with example of Jinc weighted by Jinc kernel named JincResize) dated of November 2013 - https://forum.doom9.org/showthread.php?p=1655610#post1655610

[Jamaika]

Thanks for answer. I did for c++17 as best could. If there are any modifications let us know.

For those willing. How to run vsTBilateral? Test wiki.
http://avisynth.nl/index.php/VsTBilateral

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 827

[pinterf]

Hi, dear early adopters :),

Please take a look at this test release and give it a try. We would appreciate your feedback, especially if you find any incompatibilities.

There are significant internal changes, including support for 64-bit integers and doubles, as well as v11 interface additions and modifications. (Just making proper thematic commits from the already finished code took a day!)

Thanks.
(reuploaded after a hotfix)
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4173

Changes (please read it):
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#api-v11-whats-new

[tormento]

Hi, dear early birds
Tried, just for fun. :p

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\1-04.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)

Error:

D:\Eseguibili\Media\StaxRip\Apps\Encoders\x265\x265.exe --crf 16 --preset slow --output-depth 10 --level-idc 4.1 --no-high-tier --auto-aq --vbv-bufsize 20000 --vbv-maxrate 20000 --bframes 5 --ref 5 --keyint 96 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --min-luma 64 --max-luma 940 --overscan show --qpfile "M:\In\Attack on titan ~858p Dynit\1-05.qp" --output "M:\In\Attack on titan ~858p Dynit\1-05.hevc" --input "M:\In\Attack on titan ~858p Dynit\1-05.avs_temp\1-05.avs"

avs+ [INFO]: AviSynth+ 3.7.3 (r4172, master, x86_64)
avs+ [INFO]: 1526x858 fps 24000/1001 i420p10 frames 0 - 34737 of 34738
raw [INFO]: output file: M:\In\Attack on titan ~858p Dynit\1-05.hevc
x265 [INFO]: HEVC encoder version 4.1+79+12-81640d428 [Mod by Patman]
x265 [INFO]: build info [Windows][ICC 20250000][64 bit] 10bit
x265 [INFO]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [INFO]: Main 10 profile, Level-4.1 (Main tier)
x265 [INFO]: Thread pool created using 8 threads
x265 [INFO]: Slices : 1
x265 [INFO]: frame threads / pool features : 3 / wpp(14 rows)
x265 [INFO]: Coding QT: max CU size, min CU size : 64 / 8
x265 [INFO]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [INFO]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [INFO]: Keyframe min / max / scenecut / bias : 9 / 96 / 40 / 5.00
x265 [INFO]: Lookahead / bframes / badapt : 25 / 5 / 2
x265 [INFO]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [INFO]: References / ref-limit cu / depth : 5 / on / on
x265 [INFO]: AQ: mode / str / qg-size / cu-tree : auto / 1.0 / 32 / 1
x265 [INFO]: Rate Control / qCompress : CRF-16.0 / 0.60
x265 [INFO]: VBV buffer / maxrate / init : 20000 / 20000 / 0.900
x265 [INFO]: tools: rect limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [INFO]: tools: rskip mode=1 signhide tmvp strong-intra-smoothing lslices=4
x265 [INFO]: tools: deblock sao dhdr10-info


Video encoding returned exit code: -1073741819 (0xC0000005)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Start: 12:59:46
End: 12:59:52
Duration: 00:00:05

[pinterf]

Video encoding returned exit code: -1073741819 (0xC0000005)


Big thanks, this is what I thought of.

Did it start or crashed immediately upon loading the avs script? (I can see that 0:05 is shown, so it has started?)

As the list of the plugins and scripts is a little bit too long to understand what failed exactly, can you comment out this and that from your script and run it again.

Meanwhile I try to grab those tools and scripts you are using.

[tormento]

Did it start or crashed immediately upon loading the avs script? (I can see that 0:05 is shown, so it has started?
AFAIK it didn't process even a single frame. The initial delay has to do with my slow PC.

[pinterf]

Thank you, I hope it is fixed now.
EDIT: reuploaded.
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4173

[DTL]

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 ?

[Emulgator]

Many thanks, pinterf !
First impressions on Win10P64, CPU i9-11900K, GPU RTX3080, 128GB RAM:
AviSynth.dll r4173 (06.02.2025 17:10) 64bit, AvsPmod64 2.7.8.9: Known-to-be-working-under-r4066 script (larger stuff, RIFE etc.): Crash on first loading (F5)
Well, even with empty plugins folder: Silent crash.
AviSynth.dll r4173 (06.02.2025 16:56) 32bit, AvsPmod32 2.7.8.9: Known-to-be-working-under-r4066 script: Loads ok.

P.S. AVSMeter64 found PlanarTools.dll (2016-07-05) guilty.
Lets see. Why the r4173 64bit crash with empty plugins folder ?
Renamed that PlanarTools.dll to .dead
r4173 64bit still crashes on simple loading of a framecounter script.

XP32ProSP3 and Win7U64 tests to follow as I get access to these systems again.
If all works nicely, a donation of mine is in order.

[FranceBB]

In r4173 both x86 and x64 Avisynth seem to be complaining about the old PlanarTools.dll

x64

'C:/Program Files (x86)/AviSynth+/plugins64+/PlanarTools.dll' plugin loading error:
Unknown exception

x86

'C:/Program Files (x86)/AviSynth+/plugins+/PlanarTools.dll' plugin loading error:
Unknown exception


Verified on both Windows 10 Enterprise x64 and Windows XP Professional x86.

[Emulgator]

That fits. I just see that within 32bit AviSynth I had my 32bit PlanarTools (05.07.2016) deactivated some years ago because of incompatibilities.
So there couldn't have been complaints in 32bit world here today.
Ah... Could it be that the 64bit PlanarTools still hangs around in RAM here and hampers the innocent new AviSynth ?

Power cycling soon...
Well, did not help, not even ColorBars() can be invoked here in AviSynth.dll r4173 (06.02.2025 17:10) 64bit, AvsPmod64 2.7.8.9

[pinterf]

In r4173 both x86 and x64 Avisynth seem to be complaining about the old PlanarTools.dll
How old? Could you please upload it somewhere?

[Emulgator]

These are Chikuzen's PlanarTools.dlls 0.3.0 from 05.07.2016, x86 from 00:28 and x64 from 00:30
https://github.com/chikuzen/PlanarTools/releases

BTW, these PlanarTools.dlls are not the main culprit, although they may be.
They expect MS VisualC++ 2015 and SSE2 or crash, SSSE3 for RGBtoRGB or fallback.

For x64 I went back to your r4066 and all is peachy.

[Jamaika]

I see that tests have already started. :D
exprfilter.cpp: In member function 'void Exprfilter::calculate_lut(IScriptEnvironment*)':
exprfilter.cpp:4403:32: error: 'avs_malloc' was not declared in this scope; did you mean '_mm_malloc'?
4403 | d.luts[plane] = (uint8_t *)avs_malloc(lut_size, 32); // 256 lut_x 65536: lut_xy (8 bit)
| ^~~~~~~~~~
| _mm_malloc
exprfilter.cpp: In destructor 'virtual Exprfilter::~Exprfilter()':
exprfilter.cpp:4658:19: error: 'avs_free' was not declared in this scope
4658 | if(d.luts[i]) avs_free(d.luts[i]); // aligned free
| ^~~~~~~~
Problem name Cache:
x86inc.asm:31: error: private_prefix not defined
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o):cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o):svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
collect2.exe: error: ld returned 1 exit status
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
collect2.exe: error: ld returned 1 exit status
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here

[pinterf]

These are Chikuzen's PlanarTools.dlls 0.3.0 from 05.07.2016, x86 from 00:28 and x64 from 00:30
https://github.com/chikuzen/PlanarTools/releases

BTW, these are not the main culprit. For x64 I went back to your r4066 and all is peachy.
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

[pinterf]

These are Chikuzen's PlanarTools.dlls 0.3.0 from 05.07.2016, x86 from 00:28 and x64 from 00:30
https://github.com/chikuzen/PlanarTools/releases

BTW, these PlanarTools.dlls are not the main culprit, although they may be.
They expect MS VisualC++ 2015 and SSE2 or crash, SSSE3 for RGBtoRGB or fallback.

For x64 I went back to your r4066 and all is peachy.
0.3.0 is not good, using the forbidden-to-use internal interface (IScriptEnvironment2*) of Avs+.
It was fixed
https://github.com/chikuzen/PlanarTools/commit/5b58b579fda1db589574042e7b45df507a27fb23
but 0.3.1 was never released.

Btw, this Avisynth build already contains wonkey-monkey's request, that a bad plugin would cause instant crash, instead of silently do nothing and poor developer/script writer debugs for days to detect why it does not work.

This is why it crashed upon the plugin autoloading process.

[pinterf]

I see that tests have already started. :D
exprfilter.cpp: In member function 'void Exprfilter::calculate_lut(IScriptEnvironment*)':
exprfilter.cpp:4403:32: error: 'avs_malloc' was not declared in this scope; did you mean '_mm_malloc'?
4403 | d.luts[plane] = (uint8_t *)avs_malloc(lut_size, 32); // 256 lut_x 65536: lut_xy (8 bit)
| ^~~~~~~~~~
| _mm_malloc
exprfilter.cpp: In destructor 'virtual Exprfilter::~Exprfilter()':
exprfilter.cpp:4658:19: error: 'avs_free' was not declared in this scope
4658 | if(d.luts[i]) avs_free(d.luts[i]); // aligned free
| ^~~~~~~~
Problem name Cache:
x86inc.asm:31: error: private_prefix not defined
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o):cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o):svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
collect2.exe: error: ld returned 1 exit status
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
collect2.exe: error: ld returned 1 exit status
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
I hope you are using our CMake build environment.
EDIT.
When you compile together 100000000 different projects, don't surprise that the 'rarely used' Cache class name occurs in multiple places, like in libvmaf_x64 (what is it??? Avisynth related? No.) as well. Please don't report nonexistant bugs which are not bug and error, and don't make me spend more time on your "reports", which has approximately 9 out of 10 is just like trolling. Thanks in advance.

[Jamaika]

I've dealt with problems. The new avisynth works. Is it better? I'll leave that to the professional.
I treat my ffmpeg creation as a toy.

https://github.com/AviSynth/AviSynthPlus/commit/528b67805ae218c08703ef71dd0cbce5bd7335b2
https://www.sendspace.com/file/k3qy6x

[FranceBB]

0.3.0 is not good, using the forbidden-to-use internal interface (IScriptEnvironment2*) of Avs+.
It was fixed
https://github.com/chikuzen/PlanarTools/commit/5b58b579fda1db589574042e7b45df507a27fb23
but 0.3.1 was never released.

Thank you Grandmaster Ferenc, as always, for the explanation and for pointing me to the right direction! :)
I relinked to the new Avisynth 3.7.4 r4173 header and used the latest master which includes commit 5b58b57 to create the new builds. It works! :D

x64 Avisynth 3.7.4 r4173
https://i.imgur.com/zK6ye97.png

x86 Avisynth 3.7.4 r4173
https://i.imgur.com/gsqZ373.png

They expect MS VisualC++ 2015

I built statically this time with v143 (MSVC - Visual Studio 2022).
In case anyone needs those: https://github.com/FranceBB/PlanarTools/releases/download/0.3.1/PlanarTools-0.3.1.zip


Chikuzen repository: https://github.com/chikuzen/PlanarTools
Temporary builds: https://github.com/FranceBB/PlanarTools/releases


There are 4 folders:

- x86
- x64
- x86_xp
- x64_xp

The normal ones are compiled with v143 and linked statically, the XP ones are compiled with v141_xp and /Zc:threadSafeInit and they're also linked statically, however it seems to be complaining about ReleaseSRWLockExclusive, AcquireSRWLockExclusive, WakeAllConditionVariable and SleepConditionVariableSRW when running on XP.

https://i.imgur.com/JhsNe86.png

Any other hint for the XP builds, Grandmaster Ferenc?

[Emulgator]

Continuing testing r4173 x64 on VirtualDub64 44282:
Framecounter works, ColorBars works.
filepaths derived via AviSynth internal functions: The filename "The Young BD Lens Correction AVS+64.avi.avs" comes out reversed:
NO SUCH FILE: E:\5_PREPROC\sva.iva.46+SVA noitcerroC sneL DB gnuoY !

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("LWLibavVideoSource", 3)
SetFilterMTMode("LWLibavAudioSource", 3)
SetFilterMTMode("DGSource", 3)
SetFilterMTMode("InpaintDelogo", 3)
scriptextlen=FindStr(RevStr(ScriptFile()),".")
vidextlen=FindStr(RevStr(LeftStr(ScriptFile(),StrLen(ScriptFile())-scriptextlen)),".")
vidfolder=ScriptDir()
audfolder=vidfolder
vidfile=LeftStr(ScriptFile(),(StrLen(ScriptFile())-scriptextlen-vidextlen))
audfile=vidfile
vidext=LeftStr(RightStr(ScriptFile(),scriptextlen+vidextlen),vidextlen)
vidsrc= vidext==".d2v" ? "MPEG2Source" : vidext==".dga" ? "AVCSource" : vidext==".dgi" ? "DGSource" : "LWLibavVideoSource"
audext=vidext==".d2v" ? ".ac3" : vidext==".dgi" ? ".ac3" : vidext
audpid= vidext==".d2v" ? " T80 2_0ch 224Kbps DELAY 0ms" : vidext==".dgi" ? " PID 1100 2.0ch 48KHz 192Kbps DELAY 0ms" :""
#audpid= vidext==".d2v" ? " T81 3_2ch 448Kbps DELAY 0ms" : vidext==".dgi" ? " T81 3_2ch 48KHz 448Kbps DELAY 0ms" :""
audsrc= audext==".ac3" ? "NicAC3Source" : audext==".mp4" ? "LWLibavAudioSource" : "LWLibavAudioSource"
#audsrc="BestAudioSource"
Exist(String(vidfolder)+String(vidfile)+String(vidext)) ? Apply(vidsrc,String(vidfolder)+String(vidfile)+String(vidext))\
: Assert(false, "NO SUCH FILE: " + String(vidfolder)+String(vidfile)+String(vidext) + " !")
Exist(String(audfolder)+String(audfile)+String(audpid)+String(audext)) ? AudioDub(last,Apply(audsrc,String(audfolder)+String(audfile)+String(audpid)+String(audext))) : last
#++++++++++ End of AutoPath script head ++++++++++++

This snippet works under r4066

Hrm. The filename
vts_01_1.d2v.avs
works fine in r4173. Are spaces the problem ? Seems so. The first space in <filename> seems to break it by reversing the string.

[VoodooFX]

Issues are not enabled on AvsPMod repo, so I started a discussion:
https://github.com/gispos/AvsPmod/discussions/16

I think gispos doesn't know that such thing exists at github.
Better post at https://forum.doom9.org/showthread.php?t=175823

[Jamaika]

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

[tormento]

Thank you, I hope it is fixed now.
Tested and working for that script.

Speed is on par with 4096 version.

P.S: I saw that many plugings from Asd-G are still based on 2.5 header, even if from last year or so. Is it a bug from AVSMeter or a tragic reality? ;)

[pinterf]

Tested and working for that script.

Speed is on par with 4096 version.

P.S: I saw that many plugings from Asd-G are still based on 2.5 header, even if from last year or so. Is it a bug from AVSMeter or a tragic reality? ;)

The C plugins have traditionally used different numbering, which is a bit more coarse than the actual interface version they support. This 2.5 version is different from an older C++ plugin version 2.5.

Anyway, I plan to update AVSMeter (I use it frequently). This update is necessary because C plugins will also be updated; there is a new entry point that signals 64-bit data compatibility.

[wonkey_monkey]

Anyway, I plan to update AVSMeter (I use it frequently).

Any feasibility of registering it so it appears as a right-click option for .avs files?

[pinterf]

Continuing testing r4173 x64 on VirtualDub64 44282:
Framecounter works, ColorBars works.
filepaths derived via AviSynth internal functions: The filename "The Young BD Lens Correction AVS+64.avi.avs" comes out reversed:
NO SUCH FILE: E:\5_PREPROC\sva.iva.46+SVA noitcerroC sneL DB gnuoY !

Thank you for the report. The issue originated from a commit on April 17, 2024, which introduced the string cache.

Previously, RevStr would first store the string and then reverse it. However, if the string was already stored, it did not create a duplicate, causing the previously stored variable to be overwritten.

This has been fixed by making a safe copy of the string before performing the operation.

A similar bug occurred with UCase and LCase, which have now been fixed as well.

I'm gonna prepare a new build.

[pinterf]

Any feasibility of registering it so it appears as a right-click option for .avs files?
And supporting GetAudio as well. I missed it badly.

[Emulgator]

The issue originated from a commit on April 17, 2024, which introduced the string cache.
Beautiful, nice find !

[pinterf]

Thank you Grandmaster Ferenc, as always, for the explanation and for pointing me to the right direction! :)
I relinked to the new Avisynth 3.7.4 r4173 header and used the latest master which includes commit 5b58b57 to create the new builds. It works! :D

The normal ones are compiled with v143 and linked statically, the XP ones are compiled with v141_xp and /Zc:threadSafeInit and they're also linked statically, however it seems to be complaining about ReleaseSRWLockExclusive, AcquireSRWLockExclusive, WakeAllConditionVariable and SleepConditionVariableSRW when running on XP.

Any other hint for the XP builds, Grandmaster Ferenc?
You have statically linked, but even with dynamic linking, Windows XP requires the system to use the last XP-compatible VC++ redistributable, not the latest one. You will likely need to choose a specific version: 14.28.29213.0 is the last compatible version, as newer versions result in errors due to missing APIs.

For more information,
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170
Or at our github repo:
https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Prerequisites/keep.me

[pinterf]

Early adopter test version with a ten-month regression fix:
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4176

Changes (since last real release):
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#what-s-new-in-the-api-v11