AviSynth+ thread Vol.2

[gispos]

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

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

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

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

[pinterf]

Thank you very much for the quick reaction!

[pinterf]

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

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

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

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

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

[pinterf]

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

Test script to check

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

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

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

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

[pinterf]

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

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

[Jamaika]

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

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

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

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

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

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

[pinterf]

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

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

[tebasuna51]

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


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

Installed Avisynth version(s):

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

[pinterf]

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

[Jamaika]

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

[pinterf]

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

[DTL]

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

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

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

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

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

[Emulgator]

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

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

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

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

[DTL]

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

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

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

[pinterf]

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

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

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

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

[Jamaika]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Emulgator]

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

[DTL]

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


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

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

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

[Jamaika]

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

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

[Emulgator]

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

[DTL]

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

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

[Jamaika]

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

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

[pinterf]

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

[tormento]

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

[tormento]

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

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

gives me the error:

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

Resize8
"YUV420P16" is an unsupported color format

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

while 4173 works fine.

[Emulgator]

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

[pinterf]

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

[jpsdr]

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

[qyot27]

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

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

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

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

[pinterf]

Resize8
"YUV420P16" is an unsupported color format

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

[pinterf]

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

[Emulgator]

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

[pinterf]

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

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

[pinterf]

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

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

[Emulgator]

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

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

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

What works: Single call RIFEwrap(FrameDouble=true)

[qyot27]

This one isn't new build related:

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

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

[wonkey_monkey]

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

[pinterf]

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

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

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

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

[pinterf]

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

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

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

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

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

Toggle Preview
Reload Script (ctrl-f5)

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

[gispos]

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

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

Toggle Preview
Reload Script (ctrl-f5)

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

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

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

I will take a closer look at it though.

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

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


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

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

[jpsdr]

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

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

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

[gispos]

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

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

Toggle Preview
Reload Script (ctrl-f5)

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

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

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

I will take a closer look at it though.

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

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


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

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

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

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

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

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

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


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

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

[pinterf]

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


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

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

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

[pinterf]

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

:)


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

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

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

[wonkey_monkey]

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

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

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

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

[pinterf]

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

Give 3.7.2 a try.

[gispos]

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

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

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

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

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

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

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

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

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

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

[wonkey_monkey]

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

Give 3.7.2 a try.

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

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

I'll keep digging.

[pinterf]

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

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

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

[wonkey_monkey]

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

Nope, line 380:

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


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

Edit: _pimpl->MaxSampleCount = 96084352