AviSynth+ thread Vol.2

[Myrsloik]

At the moment I cannot imagine how could I do that in a consistent way with parameter parsing.

Anyway when things are settling down I'd like to reproduce an issue with VapourSynth with which I had troubles and had to fix.

But probably you can answer it right now.

I added property "X" to a frame.
Then later (in another "ScriptClip") I added property "X" index #1 (2nd array element).

This array addition was not thread safe, second addition appeared multiple times in propShow when used in an MT environment. So the container was not detached in this case.

The fix was in this commit
https://github.com/AviSynth/AviSynthPlus/commit/f38951eb978def978a35ea210148e05c60117290

Probably this one has no proper use case but I encountered the issue during my mt stress tests.

Doh, will have to fix that one. I'm surprised nobody noticed it for so many years.

And a bit of a warning: I consider VSMap/VSVariant and such to be some of the absolutely worst bits of code that I want to redo some day soon so don't copy it too much.

Random scribbles on things I also think are suboptimal in general before you copy something even worse: https://github.com/vapoursynth/vapoursynth/issues/59

[Groucho2004]

Grab new Avisynth headers (at the moment from here):
https://github.com/AviSynth/AviSynthPlus/tree/neoI see you added CS_RGBP8 and CS_RGBAP8 which are the same as CS_RGBP and CS_RGBAP. I guess we don't need the latter ones any more, right? I'm asking because if I check the colorspaces in a switch statement the compiler blurts out an error about duplicate definition (or something to that effect).

[pinterf]

I see you added CS_RGBP8 and CS_RGBAP8 which are the same as CS_RGBP and CS_RGBAP. I guess we don't need the latter ones any more, right? I'm asking because if I check the colorspaces in a switch statement the compiler blurts out an error about duplicate definition (or something to that effect).
Yes, you don't need the non-8 version.

[Groucho2004]

Yes, you don't need the non-8 version.Thanks.

[pinterf]

Random scribbles on things I also think are suboptimal in general before you copy something even worse: https://github.com/vapoursynth/vapoursynth/issues/59
Thanks the warning I won't be hyperactive. :)

[feisty2]

I was randomly browsing avisynth's filter sdk and the invoke API doesn't seem very elegant, it is currently

auto args = std::array{ AVSValue{ arg1 }, AVSValue{ arg2 }, ... };
auto result = env->Invoke("Filter", AVSValue{ args.data(), args.size() });

it could be much prettier using the following syntax

auto result = env["Filter"](arg1, arg2, ...);

or even better with named function call

auto result = env["Filter"]("param1", arg1, "param2", arg2, ...);


function call with arbitrary arguments could be implemented by variadic templates, simple example (https://godbolt.org/z/4ugXdE).
also see its implementation in vsfilterscript (https://github.com/IFeelBloated/vsFilterScript/blob/master/include/Plugin.vxx#L11)

[Boulder]

Is there something like ResampleHQ in Avisynth+, that could be used to downscale HDR sources properly and get 16bit output? I think the original RHQ only outputs 8bit and probably only works well with non-HDR sources.

[feisty2]

it's simply gamma aware resampling, many alternatives.
also resampling under linear light introduces way more ringing and I don't actually consider it "HQ"

[Boulder]

also resampling under linear light introduces way more ringing and I don't actually consider it "HQ"

What would you suggest for downscaling HDR sources?

[feisty2]

https://github.com/WolframRhodium/VapourSynth-dpid

[Boulder]

Is it possible to force the source filter, DGSource in this case, to use only one thread? If I use a high value with Prefetch, GPU usage shoots through the roof and seems to slow things down considerably (tested with AVSMeter). With Vapoursynth, I usually get 3-5% GPU usage with a very similar processing chain (denoise and resize, UHD source).

[videoh]

Source filters automatically use MT_SERIALIZED. What makes you think it is using more than one thread?

[Boulder]

Source filters automatically use MT_SERIALIZED. What makes you think it is using more than one thread?

At least the thread count increases along with Prefetch, so I gathered it will actually use them all.

I need to test the MVTools stuff to see what happens - my larger denoiser function stalls quite bad with a high Prefetch value and GPU usage is over 90% while the frameserver should have enough to do instead of requesting new frames from DGSource.

[Groucho2004]

Is it possible to force the source filter, DGSource in this case, to use only one thread? If I use a high value with Prefetch, GPU usage shoots through the roof and seems to slow things down considerably (tested with AVSMeter). With Vapoursynth, I usually get 3-5% GPU usage with a very similar processing chain (denoise and resize, UHD source).Do you have other GPU filters in the chain?

Edit: Ran a test with this simple script:
DGSource("src.dgi")
#prefetch(8)

Without prefetch:
Frames processed: 3810 (0 - 3809)
FPS (min | max | average): 200.9 | 849.4 | 789.9
Process memory usage (max): 121 MiB
Thread count: 9
CPU usage (average): 26.6%

GPU usage (average): 27%
VPU usage (average): 71%
GPU memory usage: 417 MiB
GPU Power Consumption (average): 39.5 W


With prefetch(8):
Frames processed: 3810 (0 - 3809)
FPS (min | max | average): 1.731 | 537125 | 57.77
Process memory usage (max): 191 MiB
Thread count: 17
CPU usage (average): 17.4%

GPU usage (average): 26%
VPU usage (average): 77%
GPU memory usage: 417 MiB
GPU Power Consumption (average): 39.5 W

As you can see, GPU usage and GPU memory do not change proving that there's only one GPU thread in both scenarios. Speed and efficiency however take a serious hit.

[Boulder]

No, just the source decoding. I just tested an MVTools based denoising function (basically MCDegrainsharp with some chained MRecalculate etc.) I created in Avisynth and Vapoursynth, doing pretty much the same thing in both. In AVS+, the GPU usage is over 90% and AVSMeter proceeds very slowly, like 2-3 fps. In Vapoursynth, the GPU usage is under 10% and CPU usage over 95%. Speed in vspipe is 11-12 fps.

I'll have to strip down the function part by part to see what happens. I just find it strange that GPU decoding is being done so much compared to Vapoursynth.

[qyot27]

AviSynth+ 3.6.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Added predefined macros for ARM processors. Tested on Raspberry Pi 4B with the aarch64 image of Ubuntu 20.04.
Added support for disabling the Intel SIMD intrinsics. Gets automatically disabled on non-x86 targets.
Added submodule to allow macOS 10.13 and 10.14 to build AviSynth+ with the native Clang compiler
Fixed some warnings on GCC (wangqr)
Implemented GetNumPhysicalCPUs on Linux and macOS (wangqr)
New function:

SetMaxCPU(string feature)

string "feature"

"" or "none" for zero SIMD support, no processor flags are reported
"mmx", "sse", "sse2", "sse3", "ssse3", "sse4" or "sse4.1", "sse4.2", "avx, "avx2"

parameter is case insensitive.
Note: "avx2" triggers FMA3 flag as well.

Processor options w/o any modifier will limit the CPU flag report to at most the processor level.
When "feature" is ended by '+', relevant processor feature flag will be switched on
When "feature" is ended by '-', relevant processor feature flag will be removed
Multiple options can be put in a comma separated list. They will evaluated in that order.

Examples:
SetMaxCPU("SSE2") reports at most SSE2 processor (even if AVX2 is available)
SetMaxCPU("avx,sse4.1-") limits to avx2 but explicitely removes reporting sse4.1 support
SetMaxCPU("C,avx2+") limits to plain C, then switches on AVX2-only support
Script array for NEW_AVSVALUE define are working again. (default in Linux build experimental)
Fix: Mix/Max Runtime function 32bit float chroma: return -0.5..0.5 range (was: 0..1 range)
AviSynth+ enhancements by Nekopanda (Neo fork)
Allow multiple prefetchers (MT) (mentioned earlier)
Multithreading and deadlock fixes for ScriptClip
(originally I intended to pull only Neo changes which were fixing an old AVS+ bug,
namely ScriptClip and multithreading. But I was not able to do that without pulling
nearly everything from Neo)
Caching enhancements.
SetCacheMode(0) or SetCacheMode(CACHE_FAST_START) start up time and size balanced mode
SetCacheMode(1) or SetCacheMode(CACHE_OPTIMAL_SIZE) slow start up but optimal speed and cache size
Latter can do wonders especially at really low memory environment
ScriptClip and variable stability in multithreading.
UseVar, special filter, opens a clean variable environment in which only the
variables in the parameter list can be seen.
"escaped" string constants: with e prefix right before the quotation mask
n"Hello \n" will store actual LF (10) control character into the string
\n \r \t \0 \a \f \\ and " are converted
Introduce function objects into scripts
Functions can appear as standard Avisynth variables and parameters (AVSValue type='n')
https://github.com/nekopanda/AviSynthPlus/wiki/Language-New-Features
Even with variable capture [] (like in GRuntT args)
Filter graph. Switch it on by putting SetGraphAnalysis(true) at the beginning of the script.
Dump to text file with DumpFilterGraph. E.g. DumpFilterGraph("graph.txt", mode=2)
Frame properties (still from Neo!)
(experimental, we have planned it in Avs+, probably we'll try to follow the VapourSynth methods(?))
Fix: Multithreading enhancements and fixes (Nekopanda, from Neo fork)
Fix old ScriptClip (runtime filters) issue
In this example "current_frame" variable was not seen by YDifferenceFromPrevious scripted within SubTitle
resulting in "ERROR: Plane Difference: This filter can only be used within run-time filters" message
Now this script finally works:

SetLogParams("log.txt", LOG_DEBUG)
ColorBars(width=640, height=480, pixel_type="yv12")
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious))")
Prefetch(4)
Fix deadlock of ScriptClip on MT
MT improvement
Allow multiple Prefetchers
Add argument to Prefetch to change # of prefetch frames without changing # of threads( ex. Prefetch (clip c, int threads, int "frames") )
In the original Plus, you could use only one Prefetch, but you can use any number of CUDA versions.
Also, an argument has been added to specify the number of frames to prefetch.
Prefetch (1,4) # Make 1 thread stand and prefetch 4 frames
By doing so, flexible parallelization configuration is possible, such as pipeline parallelization.

*threads*
Number of threads. If it is 0, it passes without doing anything.

*frames*
Number of frames to prefetch.
Again, if it is 0, it passes without doing anything.
Fix: BuildPixelType: chroma subsampling of sample clip was ignored.
POSIX: better behaviour under non-Windows because of having multiple sized fixed fonts, not only a single size=20 one.
e.g. MessageClip(), Info(), Version(), ColorYUV "show", internal ApplyMessage
Text filter:
font types with
"Terminus" fixed fonts added (12-14-16-18-20-22-24-28-32, regular + bold)
"Info_h" good old 10x20 fixed font kept under this name
much more international unicode characters (1354), use utf8=true under Windows
use fontname parameter (default "Terminus", other choice is "info_h")
use font_filename parameter (accepts BDF fonts at the moment import is probably not too smart but worked for Terminus)
use size parameter (12 to 32, if no size is available, a smaller one is chosen but at least the smallest one)
new parameter: bold (default false)
Info() filter: when parameter "size" < 0, font is automatically enlarged over 640x480
(POSIX limit: minimum size is 12, maximum size is 32 limited by available fixed fonts)")
SIL OPEN FONT LICENSE added because of usage of Terminus fonts)
able to build w/o GDI and font rendering engine under Windows, so that text-overlay filters
work like in POSIX version of AviSynth+ (mainly for my development test)
Use with NO_WIN_GDI define.
Fix: ReplaceStr when the pattern string to be replaced is empty
New:
Exist() to have bool utf8 parameter
This is another function to have utf8 option:
Usage: b = Exist("Здравствуй.mkv",utf8=true). Avs file is saved as utf8 w/o BOM
Fix: broken Exist for directories (regression appeared in 3.5.0)
Fix: ColorYUV: really disable variable search when parameter "conditional" is false
Development:
ScriptEnvironment::VSprintf: parameter (void *) is changed back to va_list.
May affect C interface (avs_vsprintf) and CPP interface (ScriptEnvironment::VSprintf)
Enhanced: Planar RGB to YUV 444 10-14 bits: more precision (32 bit float internally)
Enhanced: Planar RGB to YUV 444 10-16 bits: AVX2 (speed improvement)

[magnetite]

Upgrading Avisynth+ from 3.5.1 to 3.6.0 gives MeGUI an access violation error. Uninstalling it and reverting back to Avisynth+ 3.5.1 fixes it.

Avisynth:
-Reverted from 3.6.0 to 3.5.1
-Take ownership of folder, as well as the DLL in system32 folder
-When installing Avisynth+ with the VC++ redistributables exe, I right clicked and ran as admin.

MeGUI:
-Downloaded and installed a fresh 2913 64-bit zip file.
-Updated it, turned off the included Avisynth.
-Took ownership of the folder.
-When re-installing, I right clicked and ran as admin.



Faulting application name: MeGUI.exe, version: 1.0.2913.0, time stamp: 0x5d962e5b
Faulting module name: avisynth.dll, version: 3.6.0.0, time stamp: 0x5ec59d7e
Exception code: 0xc0000005
Fault offset: 0x0000000000095020
Faulting process id: 0x1424
Faulting application start time: 0x01d62efcf2d9fcf1
Faulting application path: C:\MeGUI 64-bit\MeGUI.exe
Faulting module path: C:\WINDOWS\SYSTEM32\avisynth.dll
Report Id: da2e7f88-bfbd-4fd7-b1ff-729d933d58d6
Faulting package full name:
Faulting package-relative application ID:


Had similar issues when trying out the 3.5.2 install of Avisynth+.

[qyot27]

Post the output of (https://forum.doom9.org/showthread.php?t=174797)
avsmeter64 avsinfo

[magnetite]

Here's the log.

[Groucho2004]

Here's the log.
Approval of that attachment could take a loooong time. Post to pastebin.

[magnetite]

Okay, here's the avsinfo (https://pastebin.com/yXWP2494) log and the Avisynth+ 3.6.0 (https://pastebin.com/M0wY17ui) setup log.

[qyot27]

Had similar issues when trying out the 3.5.2 install of Avisynth+.
The problem is on MeGUI's side. They hardcode each individual AVISYNTH_INTERFACE_VERSION to specific routines in their homespun AviSynthWrapper.dll thing and any substantive version bumps to the AviSynth API will therefore make MeGUI choke on itself.

This is what gdb tells us about what MeGUI is doing:
(gdb) r
Starting program: /e/Documents/MeGUI-2913-64/MeGUI.exe
[New Thread 10080.0x15f0]
[New Thread 10080.0x1a0c]
[New Thread 10080.0x2e14]
[New Thread 10080.0x1b8c]
[New Thread 10080.0x2884]
[New Thread 10080.0x2944]
[New Thread 10080.0x2b1c]
[New Thread 10080.0x1ca0]
[New Thread 10080.0x6bc]
[New Thread 10080.0x228c]
[Thread 10080.0x228c exited with code 0]
[New Thread 10080.0x93c]
[New Thread 10080.0x1518]
[New Thread 10080.0x720]
[New Thread 10080.0x2964]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ffc08765020 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
(gdb) bt
#0 0x00007ffc08765020 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#1 0x00007ffc0876542e in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#2 0x00007ffc08765b39 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#3 0x00007ffc08a26efe in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#4 0x00007ffc08765494 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#5 0x00007ffc08765b39 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#6 0x00007ffc0872ce1b in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#7 0x0000000180002543 in dimzon_avs_init_2 () from /e/Documents/MeGUI-2913-64/AvisynthWrapper.DLL
#8 0x00007ffbacc8ea90 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

The exact part of avisynth_c.cpp it's choking on (at line 314):
https://github.com/AviSynth/AviSynthPlus/blame/e08d7c84179eb9a50b58736c78aeb1a4f41467ec/avs_core/core/avisynth_c.cpp#L311

[pinterf]

I was randomly browsing avisynth's filter sdk and the invoke API doesn't seem very elegant, it is currently

auto args = std::array{ AVSValue{ arg1 }, AVSValue{ arg2 }, ... };
auto result = env->Invoke("Filter", AVSValue{ args.data(), args.size() });

it could be much prettier using the following syntax

auto result = env["Filter"](arg1, arg2, ...);

or even better with named function call

auto result = env["Filter"]("param1", arg1, "param2", arg2, ...);


function call with arbitrary arguments could be implemented by variadic templates, simple example (https://godbolt.org/z/4ugXdE).
also see its implementation in vsfilterscript (https://github.com/IFeelBloated/vsFilterScript/blob/master/include/Plugin.vxx#L11)
Interesting ideas, they are a bit abstract for our present thinking.
I wish that was the only task to simplify. Instead there are many other opportunities to make the code a bit cleaner. E.g. removing all checks for 16 byte frame aligment in Avisynth (no unaligned frames allowed), and there are still other ancient techniques there which are sometimes workarounds for a VS2005 behaviour.

[pinterf]

AviSynth+ 3.6.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Thanks, it's a milestone.

Known issues
- Due to interface extensions, some plugins relying on old IScriptEnvironment2 no longer work (=crash)
- CPP 2.5 plugins which are using "Invoke" will probably have problems.
- MEGUI (?)

Rebuild list
- KNLMeansCL (https://github.com/pinterf/KNLMeansCL/releases) (fails because using env2->SetFilterMTMode instead of cache hints - see my mods in source)
I hope this link is temporary, I don't want to hijack this project.

- chikuzen's plugins rebuilt by Asd-g
https://github.com/Asd-g?tab=repositories

- GScript
See download link in Groucho2004's topic (https://forum.doom9.org/showthread.php?t=173259)

[pinterf]

I'd like to say a big thanks to Nekopanda. Some years ago he started an independent fork of Avisynth+ for his needs (you may know it as CUDA fork), which I wasn't even aware of for a long time, how serious changes were incorporated in that version.

He made many fixes and enhancements to the core.

- Multithreading fixes (the infamous ScriptClip issues)
(originally I only wanted to cherry-pick from Nekopanda fork to solve this problem, but the changes were not independent from the core changes he made as well so after spending weeks on resolving conflicts with our existing stuff, finally I had to integrate almost everything from there)
- language extension: function objects and variables. In interface: PFunction
- fine tune cache system, set optional caching strategy
- multiple Prefetch with new parameters
- 'escaped' string literals starting with e prefix e.g. e"Hello world\r\n"
- filter graph export

[Boulder]

Here's an example of a script which starts pounding on the GPU at 100%. I've tried changing the prefetch value, but I've not found a good value which would put the CPU (12c/24t) to work at 90-100%. In Vapoursynth, a very similar script uses 95-100% of the CPU and is much faster. GPU usage stays below 10% almost all the time.

DGSource("potter_stone.dgi", ct=280, cb=280, cl=0, cr=0) # UHD source

c2 = convertbits(bits=16)
c2blur = c2.blur(0.2)
prefilt = convertbits(bits=10)

w = prefilt.width()
h = prefilt.height()
prefilt = prefilt.removegrain(12, 12).gaussresize(w, h, 0, 0, w+0.0001, h+0.0001, p=2).mergeluma(prefilt, 0.1)

sharp_luma = c2.sharpen(0.6)
sharp_chroma = c2.sharpen(0.2)
sharp = sharp_luma.mergechroma(sharp_chroma)

superanalyse = prefilt.msuper(pel=2, hpad=16, vpad=16, sharp=2, rfilter=4)
supermdg = sharp.msuper(pel=2, hpad=16, vpad=16, levels=1, sharp=2, rfilter=4)

fv1 = manalyse(superanalyse, isb=false, delta=1, blksize=64, overlap=32, search=5, searchparam=8, pelsearch=8, truemotion=false, dct=5, mt=false)
bv1 = manalyse(superanalyse, isb=false, delta=1, blksize=64, overlap=32, search=5, searchparam=8, pelsearch=8, truemotion=false, dct=5, mt=false)
fv1 = mrecalculate(superanalyse, fv1, thsad=100, blksize=32, overlap=16, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
bv1 = mrecalculate(superanalyse, bv1, thsad=100, blksize=32, overlap=16, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
fv1 = mrecalculate(superanalyse, fv1, thsad=100, blksize=16, overlap=8, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
bv1 = mrecalculate(superanalyse, bv1, thsad=100, blksize=16, overlap=8, search=5, searchparam=6, truemotion=false, dct=5, mt=false)

fv1scaled = fv1.mscalevect(bits=16)
bv1scaled = bv1.mscalevect(bits=16)

c2blur.mdegrain1(supermdg, bv1scaled, fv1scaled, thsad=200, thsadc=200, plane=4, limit=255, limitc=255, thscd1=200, thscd2=70)

Prefetch(24)

[pinterf]

And a list about changes that affect future plugins.
Both serious and not so serious plugin writers have to keep in mind.

So just some thoughts.

[Frame properties]
AviSynth+ now have frame property support which was imported from VapourSynth. Thanks to Myrsloik.

Note that this is only the framework, a possibility, the 0th step.
We'll write on it later, documentation is lagging here - but it should appear on a refreshed Filter SDK.

Until then, even if you don't use them, you have to know some facts.

Frame properties are passed along and inherited with the frames in the filter graph.

Inheritance is broken if a filter does not behave in a frame-property friendly way. There is not problem when a plugin is using MakeWriteable. But when using NewVideoFrame which accepts only a format input (VideoInfo) the chain is broken. There is no frame property source for this empty frame. Avisynth core cannot guess it. But now we have a new IScriptEnvironment function "NewVideoFrameP" with the option of specifying the property source which will be copied to the newly created frame as well.

[AviSynth+ headers]

https://github.com/AviSynth/AviSynthPlus/tree/master/avs_core/include

cpp: avisynth.h (and the affected items under /avs)
c: avisynth_c.h

Avisynth+ Interface V8
- cpp interface: IScriptEnvironment was extended
- c interface: functions added to IScriptEnvironment are available as well
- former IScriptEnvironment2 items were moved to IScriptEnvironment (memory pool allocation, free, query of internal core properties, etc..)
- frame property support

[OS, compiler and architecture dependency]
This topic will probably require years.

Firstly you have a little help from Avisynth headers

#include "avs/config.h"

will set you some useful defines you can work with and act upon them (compiler flavours: MSVC, clang, GCC; OS flavours, Windows, POSIX, BSD; machine architectures: Intel, ARM)

At the present state most Avisynth plugins were coded with Microsoft Visual C++. Sometimes it's even difficult to port old sources to the actual MSVC syntax (and I'm not talking about C++17, but even having a valid C++11 syntax).
Then it will fail to build with clang, then it fails with gcc. And we are still on Windows.

Moving to POSIX introduces newer problems (case sensitivity, loading external DLLs such as fftw3, file system usage)

And when all this works you'll recognize that there are ARM machines and your code is full with Intel SIMD parts mixed into the C.

So it will require a big change in coding style and thinking.

VapourSynth is a "bit" ahead of us.

[magnetite]

I passed a note along to the MeGUI developers at Sourceforge about the issue, as well as I posted something in the MeGUI bug thread here.

[tebasuna51]

If MeGUI is broken I think also BeHappy, because use also a special AviSynthWrapper.dll

I read than also many plugins can't work with the new version.

When make a new version must be backward compatible, please begin with AviSynth 4.0, or a new fork, because the changes are too big.

If you plan to do that big changes remember my old suggestion of change the audio property NumChannels with MaskChannels (the NumChannels can be obtained from MaskChannels and the audio are now well defined).

[pinterf]

I read than also many plugins can't work with the new version.

List them here, we'll try to solve their problems.


When make a new version must be backward compatible, please begin with AviSynth 4.0, or a new fork, because the changes are too big.

Some of the (temporarily) broken plugins violated this remark placed in avisynth.h:
" Note to plugin authors: The interface in IScriptEnvironment2 is
preliminary / under construction / only for testing / non-final etc.!
As long as you see this note here, IScriptEnvironment2 might still change,
in which case your plugin WILL break. This also means that you are welcome
to test it and give your feedback about any ideas, improvements, or issues
you might have."

[tebasuna51]

List them here, we'll try to solve their problems.

The problems must be solved before launch a new version.

We need another set of plugins?

EDIT: maybe a new set called Avs* instead Avs+

[pinterf]

In general you'll need no new set of plugins.

But when you find a plugin which fails, post here or report the issue on github or report to the maintainer of the specific plugin.

[qyot27]

If MeGUI is broken I think also BeHappy, because use also a special AviSynthWrapper.dll
AFAICT, it just re-uses the same .dll from MeGUI. Which from the SVN history also previously had to be updated to support interface version 6. And for when AviSynth+ added high bit depth (eventually counted as interface version 7 for all of about a month and half).

From a cursory glance at the sources of the wrapper (https://sourceforge.net/p/megui/code/HEAD/tree/AvisynthWrapper/trunk/), I can't even tell why it would be throwing errors on avs_get_read_ptr_p specifically - it doesn't even seem to use the C interface at all. It also seems to be trying to use the init function intended for 2.5.7 instead of the one that was extended for interface version 6 and the high bit depth and MT features Plus introduced.

So all that needs to happen is that AviSynthWrapper.dll needs to be updated to be aware that version 8 exists. If there are any particulars in the API it has to compensate for, then it can do so at the same time in the version 8 loading function.

I read than also many plugins can't work with the new version.
Like pinterf pointed out, it should be only plugins that ignored the warning that the new-to-avsplus IScriptEnvironment2 wasn't stable and was subject to change that got hit by that particular issue.

Unless you were referring to the frame property support, which is simply that old plugins that don't support it will probably interfere with new plugins that do support it, not that the plugins break or cause the script to fail (well, unless the script was relying on the frame properties, maybe? But that's still the new feature ceasing to work, not the old stuff failing). To be honest, the new frame property and in-script array stuff is a little over my head.

When make a new version must be backward compatible, please begin with AviSynth 4.0, or a new fork, because the changes are too big.
That's precisely why it was bumped to 3.6 instead of continuing the 3.5.x series. Remember, AviSynth 2.6 was not perfectly backward compatible with 2.5, either. Plugins broke during the development of 2.6 and client programs (read: FFmpeg, x264) that depended on 2.5 having code baked into its headers broke when it was cleaned up in 2.6 and moved out of the headers, forcing them to either awkwardly try to support both, or to drop support of 2.5 outright.

The major.minor versions in AviSynth (in total, not just Plus) have always been mostly just symbolic. They aren't semantic versions (https://semver.org/), although since we now support more than just Windows, I am trying to ensure that the third version indicates just bugfixes or changes that don't impact any kind of compatibility. The version that really matters for compatibility checking is AVISYNTH_INTERFACE_VERSION, which was bumped when it changed to signal as much.

Note: the essential information that one actually needs to get and use from the AviSynth(+) API actually did not change here, as evidenced by the fact that a build of FFmpeg from December 30th, using headers that predate native Linux support¹ and still referred to themselves as interface version 6, can still load 3.6.0 and operate correctly.

¹predated 3.4.0, actually; the last time the compat/ headers in FFmpeg were updated (before getting removed in the wake of 3.5.0 being available on more than just Windows) was in May of 2019.

[Kurtnoise]

Hi,

I can concur about AvisynthWrapper stuff. It just needs to be recompiled using #8 as interface.

btw, Im trying to compile ffmpeg w/ avisynth support but I'm getting this error :
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h: In function 'avs_load_library':
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1450:41: error: macro "AVSC_LOAD_FUNC" passed 2 arguments, but takes just 1
1450 | AVSC_LOAD_FUNC(avs_is_444, avs_is_yv24);
| ^
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1325: note: macro "AVSC_LOAD_FUNC" defined here
1325 | #define AVSC_LOAD_FUNC(name) {\
|
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1450:3: error: 'AVSC_LOAD_FUNC' undeclared (first use in this function)
1450 | AVSC_LOAD_FUNC(avs_is_444, avs_is_yv24);
| ^~~~~~~~~~~~~~
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1450:3: note: each undeclared identifier is reported only once for each function it appears in
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1451:41: error: macro "AVSC_LOAD_FUNC" passed 2 arguments, but takes just 1
1451 | AVSC_LOAD_FUNC(avs_is_422, avs_is_yv16);
| ^
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1325: note: macro "AVSC_LOAD_FUNC" defined here
1325 | #define AVSC_LOAD_FUNC(name) {\
|
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1452:41: error: macro "AVSC_LOAD_FUNC" passed 2 arguments, but takes just 1
1452 | AVSC_LOAD_FUNC(avs_is_420, avs_is_yv12);
| ^
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1325: note: macro "AVSC_LOAD_FUNC" defined here
1325 | #define AVSC_LOAD_FUNC(name) {\
|
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1453:37: error: macro "AVSC_LOAD_FUNC" passed 2 arguments, but takes just 1
1453 | AVSC_LOAD_FUNC(avs_is_y, avs_is_y8);


something wrong within headers ?

[Groucho2004]

Here's an example of a script which starts pounding on the GPU at 100%. I've tried changing the prefetch value, but I've not found a good value which would put the CPU (12c/24t) to work at 90-100%. In Vapoursynth, a very similar script uses 95-100% of the CPU and is much faster. GPU usage stays below 10% almost all the time.No idea why your GPU load is so high, I can't reproduce that. Have you tried L-Smash source filter with GPU support?

[pinterf]

Hi,

I can concur about AvisynthWrapper stuff. It just needs to be recompiled using #8 as interface.

btw, Im trying to compile ffmpeg w/ avisynth support but I'm getting this error :
[code]C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h: In function 'avs_load_library':

Thanks, fixed on git.

[Boulder]

No idea why your GPU load is so high, I can't reproduce that. Have you tried L-Smash source filter with GPU support?

Just tried with LWLibavVideoSource, dead slow too. GPU usage is around 40-50% and the whole process less than 1 fps as CPU usage was in the low 20s. This was without cropping so the frame size was 3840x2160.

[manolito]

Not happy with AVS+ 3.6...

(I use the 32-bit version exclusively)

So far all my old plugins from the pre-modernization effort times seem to work, which is a welcome surprise. But the new MT process handling does not play nice with my older 32-bit StaxRip version (last 32-bit stable version 1.1.90).

Whenever an AVS filter in Staxrip is added or modified, the filter will be called to test it, and after a successful test the process will be terminated and released from memory. With AVS+ 3.6.0 this does not work any more. My source filter is DSS2Mod with LAV Filters, and now I get at least 3 instances of the LAV splitter and LAV Video source filter. This slows down the encoding by about 1 fps, and I think that it is unnecessary.

This is the script created by StaxRip:
LoadPlugin("C:\Program Files (x86)\StaxRip\Applications\AviSynth plugins\Decomb\Decomb.dll")
DSS2("D:\Jurassic World.mkv", preroll=15)
FDecimate(25)
Crop(0,0, -Width % 4,-Height % 4)
ColorMatrix(source=0,dest=2)
RequestLinear(rlim=50, clim=50)
ConvertToYV12()
Spline36Resize(704,396)
# Insert Loc parameter here:
Loc="20,14,-588,-330"
InpaintDelogo(mask="d:\logomask.bmp", Loc=Loc, Mode="Inpaint", Turbo=0)
RequestLinear(rlim=50, clim=50)
FineSharp()
avstp_set_threads(1)
Prefetch(4)
Trim(6151,172368)

For my needs this latest version 3.6 has nothing to offer, I am going back to 3.51. And generally I agree with Tebasuna:

If you want to push new versions without much testing compatibility with established and popular encoder GUIs then please create a new fork. You can make more radical changes then like drop 32-bit support and reject older plugins. And maybe some dev will agree to make a few bugfix updates to the older (traditional, maybe retro) 3.5x fork.


Just my 2 cents...
manolito

[pinterf]

If you want to push new versions without much testing compatibility with established and popular encoder GUIs then please create a new fork.
??? Are you aware how many developers are working on Avisynth+ and how many remains when they make a new fork?

[real.finder]

since I am not with or against new fork but if it will be new fork in the end, then maybe better call it AvxSynth+ (since there are old AvxSynth (https://github.com/avxsynth/avxsynth/wiki)) because it work in Linux and so :)

[manolito]

Personally I do not use MEGui, but just looking at the MEGui threads at Doom9 and seeing how active they are I can only assume that a lot of folks do use MEGui.

AviSynth is not a software which is used by itself, it is a frame server which is used in conjunction with other software. So I believe that the AVS devs always must keep an eye on this other software which depends on AviSynth.

Releasing a new AviSynth version without even having tested it with MEGui and some other encoder GUIs is simply embarrassing. Why are you AVS+ devs in such a hurry to push out your latest and coolest achievements? Can't you just leave this turf to VS?

[Stereodude]

Why are you AVS+ devs in such a hurry to push out your latest and coolest achievements? Can't you just leave this turf to VS?
Perhaps a better question that should be answered first is what tangible problems are they trying to fix/improve that even warrant these dramatic changes (that break things)?

[Groucho2004]

Releasing a new AviSynth version without even having tested it with MEGui and some other encoder GUIs is simply embarrassing.That's a matter of opinion, I suppose. I think the "GUI" guys should keep up with current developments and update their Avisynth interfaces accordingly. Hard-coded interface versions such as found in the megui wrapper are ridiculous.

[pinterf]

Not happy with AVS+ 3.6...

[...]
Whenever an AVS filter in Staxrip is added or modified, the filter will be called to test it, and after a successful test the process will be terminated and released from memory. With AVS+ 3.6.0 this does not work any more. My source filter is DSS2Mod with LAV Filters, and now I get at least 3 instances of the LAV splitter and LAV Video source filter.

When something is kept in the memory it's not normal, and it means the resource if not freed up properly.

Question 1:
I have found DSS2mod on an Internet wayback machine linked from Avisynth.nl, is it the latest one?
Question 2:
Are you using the avss_26.dll?

[manolito]

1. I believe it is.
2. Yes, I do use avss_26.dll, dated from 2014-10-05

Right now I am in the middle of a long encode, I will test how ffms2 and LSMASH behave under AVS+ 3.6 ASAP and report back.

[MeteorRain]

It is very arguable. MeGUI is coded to work with a specific range of avisynth versions. It's the author of MeGUI's responsibility to support new versions. If you use a toolkit package like MeGUI where it maintains its own tool sets, use that, use whatever version it tested with.

If MeGUI was tested with 2.5, use 2.5 and not 2.6 2.7 3.0 3.6 3.7 4.0 or anything else, or it's your risk of having things broken, or your work to get it fixed.

[Groucho2004]

MeGUI is coded to work with a specific range of avisynth versions.I have never used megui so I wonder what that means. As I understand it, megui is just a frontend for various encoders and uses Avisynth to gather information about the source file/script. So, if I'm correct it just has to load the script and extract the information from it, right?

[manolito]

I will test how ffms2 and LSMASH behave under AVS+ 3.6 ASAP and report back.

ffms2 behaved nicely under AVS+ 3.6, but LWLibavVideoSource did not. I used the latest STVG and Holywu versions. So I still will go back to AVS+ 3.51

[StainlessS]

As time goes on relentlessly, so some apps get stuck in time warp, not sure, think MeGUI devs have been abscent now for some time (I aint updated
MeGUI for maybe 9 months [actually stable XP build for maybe 2+ years], as some things just dont work for XP, and if it dont work for that, then is of little use to me).
I have never used megui so I wonder what that means.
As various whotsits change, so args etc [EDIT: or even OS version compatibility] change and so no longer comply with MeGUI expectation of function arguments etc, ie no longer work proper/at all.

EDIT: And if one thing dont work proper, the whole shabang can/will fail.
EDIT: Just like Smaug's missing scale, one small imperfection and that damn iron arrow killed the cute cuddly little critter.

[StainlessS]

MeGUI is a Windows soft and don't need the Avs+ 3.6.0 new version. Also there are plugins than don't work with this new version.

Use the Options -> Main -> Always use the included AviSynth

Above good advise. [Above from one of the MeGUI threads]

Also, maybe about time that Avisynth(+) had a thread in Avisynth Usage forum, where current stable build should be posted, not really right that
users have to visit devs forum for what might be a stable version.
(this has always been a problem, and not just Avisynth, several other culprits [among many] being ffms2 and LSMash, mvtools, masktools and more)
(devs dont like dirtying their hands talking to users, I can appreciate that, I dont likem' either, nothing but trouble).