Avisynth+ [Archive] - Page 98

qyot27

26th August 2019, 20:08

I'm sure pylorak had a good reason for that commit, if I recall correctly it was related to MT functionality.
Early 2014 was when the MT functionality was being implemented and the caching behavior was refactored in tandem with it. That's almost certainly the reason, even if just tangentially.

I mean, the other thing to point out is that the tests are being run single-threaded, and some of that syntax is wonky (probably minuscule in any possible performance detriment, but whatever). Actually using MT shows how artificial this test is in the first place, because it scales with # of cores in virtually 1:1 fashion.

Script (with the cruft trimmed out and clarified (http://avisynth.nl/index.php/The_full_AviSynth_grammar#Identifiers)):
clp = FFVideoSource("test.avi").ConvertToRGB24()
a = clp.Trim(20,-30)+clp.Trim(2000,-30)
a1 = a+a+a+a+a+a+a+a+a+a
a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1
Prefetch(4)

Without Prefetch:
>avsmeter test.avs

AVSMeter 2.9.6 (x86) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, i386) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 381.3 | 2361 | 1977
Process memory usage (max): 44 MiB
Thread count: 16
CPU usage (average): 35.7%

Time (elapsed): 00:00:06.070

With Prefetch(4):
>avsmeter test.avs

AVSMeter 2.9.6 (x86) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, i386) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 2164 | 12104 | 10044
Process memory usage (max): 51 MiB
Thread count: 20
CPU usage (average): 57.5%

Time (elapsed): 00:00:01.195

64-bit results, for good measure:
Without Prefetch:
>avsmeter64 test.avs

AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 948.1 | 2770 | 2303
Process memory usage (max): 25 MiB
Thread count: 16
CPU usage (average): 39.1%

Time (elapsed): 00:00:05.211

With Prefetch(4):
>avsmeter64 test.avs

AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 1767 | 13659 | 11223
Process memory usage (max): 32 MiB
Thread count: 20
CPU usage (average): 55.7%

Time (elapsed): 00:00:01.069

With Prefetch(5):
>avsmeter64 test.avs

AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 1692 | 139899 | 23581
Process memory usage (max): 33 MiB
Thread count: 21
CPU usage (average): 34.1%

Time (elapsed): 00:00:00.509

If I up the Prefetch value on the 32-bit test to 5 (one higher than the number of cores in this J3455), avsmeter then reports that it's too short to measure. 64-bit hits the same barrier at Prefetch(6). Of course, that's for 12000 frames at a frame size of 196x88; who knows how much more you can abuse the frame threading beyond n cores with frames at a normal size and runtime length.

filler56789

26th August 2019, 21:26

The reason for not adding caches is simple: avoid insane amounts of useless cache instances from being created. This is a very reasonable tradeoff since the max depth of sane uncached operations is about 10 or so. Not many millions. In typical cases the reduced cache overhead will provide a speedup. That's right! It goes faster for everybody except you!

What you've done here is implement the video scripting equivalent of an extremely inefficient algorithm. I personally view this like someone implementing bubble sort (https://en.wikipedia.org/wiki/Bubble_sort) and then complaining about poor performance. Avisynth is a programming language and nobody can protect you from your own shortcomings. It's similar to how Matlab is really slow unless you figure out a way to express things as matrix operations. You have to work with the programming language, NOT AGAINST IT.

1) Thanks for the useful information. Then I stand corrected, sir.

2) And then I don't know why pinterf wrote ""historical" reasons" instead of giving a straight-to-the-point answer like yours. Perhaps that was a misplaced joke or/and his "sense of humor" is broken......

P.S.:

3) I am not VoodooFX alright ;)

wonkey_monkey

26th August 2019, 23:35

What you've done here is implement the video scripting equivalent of an extremely inefficient algorithm. I personally view this like someone implementing bubble sort (https://en.wikipedia.org/wiki/Bubble_sort) and then complaining about poor performance. Avisynth is a programming language and nobody can protect you from your own shortcomings. It's similar to how Matlab is really slow unless you figure out a way to express things as matrix operations. You have to work with the programming language, NOT AGAINST IT.

So - and I'm probably being dim here, or missing some MT thing because I've never really dug into that - how do you implement a loop of a small clip section, in Avisynth+, so you can get the same performance as seen in 2.6?

VoodooFX

27th August 2019, 18:20

Actually using MT shows how artificial this test is in the first place, because it scales with # of cores in virtually 1:1 fashion.

Loading time of the real script (link to - pseudo script (https://forum.doom9.org/showthread.php?p=1882432#post1882432), the part where the real script is parsing loops when loading):
2s - AVS Standard 2.6
61s - AVS+
304s - AVS+ with Prefetch(4)

Trims, loops replaced with SelectRangeEvery (~3600 frames from clip):
41s - AVS Standard 2.6
46s - AVS+
247s - AVS+ with Prefetch(4)

pinterf

27th August 2019, 19:36

Early 2014 was when the MT functionality was being implemented and the caching behavior was refactored in tandem with it. That's almost certainly the reason, even if just tangentially.

Setting the non-caching behaviour for zero-op filters in general seemed to be a good idea at that time in 2014, but as this use case shows the idea does not work for Trim and the probably for the other functions mentioned above. In the past few years I have already put back some deleted invoking of InternalCache to Avisynth+ since some real world (and not synthetic) scripts were slow in specific scenarios. Non-caching Trim probably has no penalty only when it appears alone and right after a source filter (? this has to be tested).

Zetti

27th August 2019, 22:01

Is there a ETA for a new stable build?

ajp_anton

28th August 2019, 23:09

Bug?

I don't know if this is supposed to be "expected behavior", but at least I didn't expect anything like this.

When a resizer is fed cropping coordinates from outside of the picure, what exactly is supposed to happen? I expected it to simply repeat the last line of the image, but that doesn't seem to be the case.

function blackborder(clip c,int pix)
{
return c.crop(0,pix,0,-pix).addborders(0,pix,0,pix)
}

blankclip(width=100, height=100, length=20, pixel_type="y8", color=$ffffff)

animate(0,19,"blackborder", 0, 19)

lanczos4resize(width,height, 0, -height/2, width, height*2)
histogram
This creates a white image, but with a black border the same size as the framenumber. It then "zooms out", but keeps the overall dimensions the same, by taking a larger area around the frame and resizing it to the original size.

On frame 0, the expected behavior happens, where it just repeats the white border indefinitely and the zoomed-out image is also 100% white. On frame 1 and onwards, I was expecting it to treat the outside world as being black, however that's not what happens.

Depending on how thick the black border is and what resizer is used, the outside color oscillates around gray/black, mimicking the wave-like nature and the sampling area of the resizer. For complete blackness, a 6 pixel border is needed for spline36, 2 for bilinear, etc.

ajp_anton

29th August 2019, 06:45

ConvertBits(8,dither=1)
doesn't seem to work for 8-bit sources.

Wiki says:
"Dithering is allowed only for 10-16bit (not 32bit float) sources."
You can dither from 16bits to 16bits so why not from 8bits to 8bits? I'm assuming those will just pass through the video untouched anyway. Life gets easier when I can just slap on a convert to 8bits at the end without worrying about what the input bitdepth is.

LigH

29th August 2019, 07:25

Dithering is a technique to spread quality loss while reducing the precision. Converting from 8 bits per color component to 8 bits, there is no reduction, thus no loss to be spread.

ajp_anton

29th August 2019, 07:48

Dithering is a technique to spread quality loss while reducing the precision. Converting from 8 bits per color component to 8 bits, there is no reduction, thus no loss to be spread.Yes, I know. So why is 16bits to 16bits allowed?
edit: I'm not saying 16b->16b actually does anything. I'm just confused over the fact that it's allowed, while 8b->8b isn't. I'm advocating for allowing also 8b->8b for when you can just add it to the end of a script or a function, without adding a check to see if it's allowed... (I feel like I'm repeating myself here, everything is already in the original post).

ajp_anton

29th August 2019, 07:55

Another bug?

ConditionalReader:

TYPE string
DEFAULT this_is_the_default

1 test
2 string
5
8 testing
This throws an error that it doesn't understand line 6 (the one with frame 5). Note that there's just one space after 5. The space is there to separate the frame number from the value. In this case I want the value to be an empty string.
Note that setting the default string to empty *does* in fact work (with just the one space after "DEFAULT"), but the exact same thing *does not* work for the individual frames.

edit:
This example script goes with the above "test.txt" text file, for testing purposes:
ColorBars
Trim(0,500)
ScriptClip("Subtitle(String(myvar))")
ConditionalReader("test.txt", "myvar", false)

pinterf

29th August 2019, 08:13

ConvertBits(8,dither=1)
doesn't seem to work for 8-bit sources.
You can dither from 16bits to 16bits so why not from 8bits to 8bits?
Because I didn't have additional weeks to implement it like it works for 10-16 bit sources (where you can specify dither_bits)

pinterf

29th August 2019, 08:47

pinterf

29th August 2019, 12:50

Test build again, files only.
Avisynth+ r2915 (https://drive.google.com/open?id=1fD3icmCBr3x3tHjFzxsr5h8Rw6nO4uZV)
Changes since last r2900 test in July (for all changes since r2772 see readmes):
- Changed: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop are using frame cache again (similar to classic Avs 2.6)
- Enhanced: Expr: faster exp, log, pow for AVX2 (sekrit-twc)
- ConditionalReader: allow empty value in text file when TYPE string
- Fix: Expr: fix non-mod-8 issues for forced RGB output and YUV inputs
- New: AviSource support v308 and v408 format (packed 8 bit 444 and 4444)
- Fix: AviSource v410 source garbage (YUV444P10)
- Fix: Expr: when using parameter "scale_inputs" and the source bit depth conversion occured, predefined constants
(ymin/max, cmin/max, range_min/max/half) would not follow the new bit depth

StainlessS

29th August 2019, 13:21

OOOoooh lovely https://www.cosgan.de/images/smilie/froehlich/k020.gif

VoodooFX

29th August 2019, 13:49

Thank you. Now trims/loops are fast. :cool:

2s - AVS Standard 2.6
61s - AVS+ r2772
2s - AVS+ r2915

manolito

31st August 2019, 22:48

After confirming speed issues when using FFVideoSource or LWLibavVideoSource under AVS+ 32-bit in MT mode:
https://forum.doom9.org/showthread.php?p=1883664#post1883664
I just want to know if it is feasible to add some kind of workaround to AVS+ to ensure linear frame requests to these source filters.

Cheers
manolito

poisondeathray

8th September 2019, 22:20

More evidence of the ConvertToXX (chromaresample="point") bug with shifting chroma, as pointed out in post 4287

avsresize does not exhibit the bug (nor does vapoursynth)

https://forum.doom9.org/showthread.php?p=1884351#post1884351

pinterf

9th September 2019, 12:28

pinterf

9th September 2019, 12:28

poisondeathray

9th September 2019, 14:07

Is classic Avisynth 2.6 affected as well?

Yes

I forgot that Gavino explained this a long time ago

https://forum.doom9.org/showthread.php?p=1571315#post1571315

wonkey_monkey

9th September 2019, 17:39

poisondeathray

9th September 2019, 19:56

I just made this image to compare chroma resampling in converttoXXX:

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

It shows the result of repeat conversions between YV12 and RGB24. Does it indicate a problem with "sinc"?

If nothing else, it shows a downward shift which none of the others (except "point", for reasons already discussed) exhibits.

Yes the ConvertToXX "sinc" implementation has issues too . Looks to be more than just down direction. Also occurs with avs classic

avsresize shows expected result with sinc

https://i.postimg.cc/kg7MjBk4/sinc.png

StainlessS

9th September 2019, 22:38

Just curious, what is the purpose of

Null "c[copy]s" # Function Null(clip c,String "Copy")

Is it some temp debug thing for test version avs+ r2915

colorbars(pixel_type="YV12")
#NULL("YV24")
NULL()
info

Error reading source frame 0: Avisynth read error: bug found

EDIT: Also, I found a script from some time ago, (about june/july)

Colorbars
x=GetPlaneWidthSubSampling
return last

Dont know if it was implemented back then or whether or not I was just testing for the function existing, but it aint supported in r2915,
perhaps that is part reason I gave up s_ExLogo modding, is pretty fundamental function and easily added, can next issue of avs+ have it (GetPlaneWidthSubSampling) and
also GetPlaneHeigthSubSampling too please.
I can use RT_ColorSpaceXMod(clip) and RT_ColorSpaceYMod(clip,Laced) but not for avs+ colorspaces. https://forum.doom9.org/showthread.php?p=1864802#post1864802

EDIT: Below maybe handy for Wiki/Docs (where ColorSpaceXMod and ColorSpaceYMod cropping granularity of colorspace due to U and V)
where ColorSpaceYMod would be as BitLShift(1,Last.GetPlaneHeightSubSampling) OR Last.RT_ColorSpaceYMod() in Avs Std.

H=5 # Test height
CS="YV24"
ColorSpaceYMod = 1 # ColorSpaceYMod = 1 : Can crop vertically in multiples of 1 for YV24 : ColorSpaceYMod = BitLShift(1,Last.GetPlaneHeightSubSampling)
# ColorSpaceYMod = 1 : if eg Y8, GetPlaneHeightSubSampling() would produce error if no chroma.
Colorbars(Pixel_type=CS)
O=Last
crop(0,0,0,H*ColorSpaceYMod)

# MINIMUM CROPPED INPUT SIZE PER RESIZER
# Resizer Name # Minimum (cropped) input size that succeeds (eg ColorSpaceYMod=2 for YV12, 1 for YV24 : ColorSpaceXMod for horizontal same sort of thing for width)
#PointResize(O.Width,O.Height) # 1*ColorSpaceYMod
#BilinearResize(O.Width,O.Height) # 2*ColorSpaceYMod
#BiCubicResize(O.Width,O.Height) # 3*ColorSpaceYMod
#Spline16Resize(O.Width,O.Height) # 3*ColorSpaceYMod
#Spline36Resize(O.Width,O.Height) # 4*ColorSpaceYMod
#Spline64Resize(O.Width,O.Height) # 5*ColorSpaceYMod
#GaussResize(O.Width,O.Height,p=30.0) # 5*ColorSpaceYMod
#Lanczos4Resize(O.Width,O.Height) # 5*ColorSpaceYMod (taps=4)
#LanczosResize(O.Width,O.Height,taps=3) # (taps+1)*ColorSpaceYMod
#BlackmanResize(O.Width,O.Height,taps=4) # (taps+1)*ColorSpaceYMod
#SincResize(O.Width,O.Height,taps=4) # (taps+1)*ColorSpaceYMod

# Uncomment one of above

return Info

EDIT: Maybe ColorSpaceXMod/YMod would actually be more useful [than GetPlane-Height/Width-SubSampling], and avoid special cases [in script] where no chroma or RGB.

pinterf

10th September 2019, 08:57

Just curious, what is the purpose of

Null "c[copy]s" # Function Null(clip c,String "Copy")

Is it some temp debug thing for test version avs+ r2915

I was not aware of such function, it probably served debug purposes from the beginnings.

pinterf

10th September 2019, 09:34

Yes the ConvertToXX "sinc" implementation has issues too . Looks to be more than just down direction. Also occurs with avs classic

avsresize shows expected result with sinc

https://i.postimg.cc/kg7MjBk4/sinc.png

In Avsresize sinc is a (legacy) lanczos with taps=4.
While "sinc" in Avisynth+ has different core from Lanczos.

Which can be a bug or not.

Lanczos and Sinc are different in avisynth+ because
"sinc" does not have the extra calculation of sinc(value) * sinc(value/taps) like Lanczos has.

avs+ Lanczos:

double LanczosFilter::sinc(double value) {
if (value > 0.000001) {
value *= M_PI;
return sin(value) / value;
} else {
return 1.0;
}
}

double LanczosFilter::f(double value) {
value = fabs(value);

if (value < taps) {
return (sinc(value) * sinc(value / taps));
} else {
return 0.0;
}
}

avs+ sinc filter
/***********************
*** Sinc filter ***
***********************/
double SincFilter::f(double value) {
value = fabs(value);

if (value > 0.000001) {
value *= M_PI;
return sin(value)/value;
} else {
return 1.0;
}
}

StainlessS

10th September 2019, 12:44

I was not aware of such function, it probably served debug purposes from the beginnings.

Dang!, you are correct.
Also present in v2.58, seen the function lists for v2.58, v2.60,
v2.61, avs+ many times and never noticed it before.
EDIT: Ideal for April Fool jokes, make AVS+/Plugin coders think they have serious bug in avs+ or plugs. https://www.cosgan.de/images/smilie/froehlich/a065.gif

LigH

11th September 2019, 07:31

I believe a Null() transform filter is useful for the ternary conditional statement (if ? then : else) when one alternative is not supposed to change the clip. But there was also a NOP statement, IIRC?

StainlessS

11th September 2019, 10:04

Null() not useful to replace NOP.

Null(clip c, string "Copy"="none"), is not intended to be used from script.
from v2.60 std source, debug.h

class Null : public GenericVideoFilter
/**
* Class for debugging Avisynth internals.
**/

As it is in avs v2.60 std source, seems to always produce error
debug.cpp

/*******************************
******* Null Filter *******
******* for debugging *******
******************************/

Null::Null(PClip _child, const char * _copy, IScriptEnvironment* env)
: GenericVideoFilter(_child), copy(_copy)
{
}

Null::~Null()
{
}

PVideoFrame __stdcall Null::GetFrame(int n, IScriptEnvironment* env)
{
PVideoFrame src = child->GetFrame(n, env);

BYTE * foo = new BYTE[256];
BYTE * bar = new BYTE[256];
MemDebug md;

md.randomFill(foo, 8, 8, 8);
env->BitBlt(bar, 8, foo, 8, 8, 8);

md.reset();
int i = md.randomCheck(bar, 9, 8, 8); // ssS: Looks like always forces error (9 instead of 8)

if (i)
env->ThrowError("bug found"); // ssS: OUR SHOWN ERROR "Error reading source frame 0: Avisynth read error: bug found"

delete [] foo;
delete [] bar;

if (!lstrcmpi(copy, "makewritable"))
{
env->MakeWritable(&src);
return src;
}

// TODO: no support for planar formats!
if (!lstrcmpi(copy, "memcopy"))
{
PVideoFrame dst = env->NewVideoFrame(child->GetVideoInfo(), 16);
if (dst->IsWritable() == false)
env->ThrowError("new frame not writable"); // honestly don't know whether to expect this condition

memcpy( dst->GetWritePtr(), src->GetReadPtr(), src->GetPitch() * src->GetHeight() );
return dst;
}

if (!lstrcmpi(copy, "bitblt"))
{
PVideoFrame dst = env->NewVideoFrame(child->GetVideoInfo(), 16);
if (dst->IsWritable() == false)
env->ThrowError("new frame not writable"); // honestly don't know whether to expect this condition

env->BitBlt( dst->GetWritePtr(), src->GetPitch(), src->GetReadPtr(), src->GetPitch(),
src->GetRowSize(), src->GetHeight() );
return dst;
}

//if (!lstrcmpi(copy, "none"))
// do nothing
return src;
}

AVSValue __cdecl Null::Create(AVSValue args, void*, IScriptEnvironment* env)
{
return new Null(args[0].AsClip(), args[1].AsString("none"), env);
}

Cant say that I understand whats happening there, seems a bit weird.
EDIT: Dont know where this bit is coming from "Error reading source frame 0: Avisynth read error".

EDIT: Although this dont throw error (As no GetFrame called, only Null() constructor called)

# this just returns the info whatsit, no error thrown
colorbars(pixel_type="YV12")
O=Last

Last.Null(Copy="What the hell ! ") # always do the Null thingy

return O.Info

EDIT: Maybe that particular code is intended to be "hacked as required", and above is just how it was left after last use.

wonkey_monkey

16th September 2019, 17:19

Myrsloik

16th September 2019, 19:42

I'm writing a C++ program which creates an IScriptEnvironment2 for the purposes of displaying clips. It also lets the user modify the filter chain by changing conversion matrix, interlacing settings, bobbing, etc. If I invoke a filter, is there any way to absolutely forbid the environment from ever caching frames from that filter? And would this/could this propagate to downstream filters, so that every single request for an output frame (even if it was the same frame that had just been requested) would go back up the chain to the uncached filter?

The short answer is no. Simply recreate the filter chain from the point where the settings are changed. Generally only source filters are slow to create and destroy anyway so it works just fine (that's how YMC's preview works in case anyone remembers that)

wonkey_monkey

29th September 2019, 22:24

I may have mentioned this before - I couldn't find anything in my history, but the forum search is not the greatest.

converttoyv12 throws an error on construction if the input clip isn't mod2, as it should - except when the input is Y8, in which case it fails to do so and leaves it to NewVideoFrame() to throw the error. May happen in other cases too.

StainlessS

30th September 2019, 12:56

@P, see here:- http://forum.doom9.org/showthread.php?p=1886177#post1886177

Note to Pinterf, ConditionalFilter Fails where uses Length=1 in BlankClip, dont think it should.
InC = Last.BlankClip(Length=1,Color_YUV= InColor) OutC= Last.BlankClip(Length=1,Color_YUV=OutColor)

ROW = True
LIMITLO = 74.0 # >= is Target
LIMITHI = 100.0 # <= is Target
INCOLOR = $008080 # Set where in target range
OUTCOLOR = $FF8080 # Not in target range
SHOW = false # Return StackHorizontal, original as Y8, and mask.
###############
Colorbars.Trim(0,-100).convertToY8
MskByRowAveY(Row=ROW,LimitLo=LIMITLO,LimitHi=LIMITHI,InColor=INCOLOR,OutColor=OUTCOLOR,Show=SHOW)
Return Last

Function MskByRowAveY(clip c, Bool "Row", Float "LimitLo", Float "LimitHi", Int "InColor", Int "OutColor", Bool "Show") { # http://forum.doom9.org/showthread.php?p=1886177#post1886177
# Where AveLuma of pixel Row/Coloumn is between LimitLo<===>LimitHi, then set to Incolor, else OutColor. Colors Specified as YUV, where only Y8 returned.
c myName="MskByRowAveY: "
Row=Default(Row,true) LimitLo=Default(LimitLo, 0.0) LimitHi=Default(LimitHi,127.5)
InColor =Default(InColor ,$000000) OutColor=Default(OutColor,$FF8080) Show=Default(Show,False)
Assert(0.0 <= LimitLo <= LimitHi,myName+String(LimitLo,"0.0 <= LimitLo(%f)") + String(LimitHi," <= LimitHi(%f)"))
Assert(LimitHi <= 255.0,myName+String(LimitHi,"LimitHi(%f) <= 255.0"))
ConvertToY8.KillAudio O=Last
(Row) ? SeparateRows(O.Height) : SeparateColumns(O.Width)
InC = Last.BlankClip(Color_YUV= InColor) OutC= Last.BlankClip(Color_YUV=OutColor)
Last.ConditionalFilter(InC,OutC,String(LimitLo,"(%f<=AverageLuma<=")+String(LimitHi,"%f)"))
(Row) ? WeaveRows(O.Height) : WeaveColumns(O.width)
Return (SHOW) ? StackHorizontal(O,Last) : Last
}

EDIT: Easier for testing (Without SeperateRows)

FAIL = False # Force Falure ?
C=0
For(i=0,255) {
C2=BlankClip(Pixel_Type="Y8",Length=1,Color_YUV=(i*256+$80)*256+$80)
C=(!c.IsClip) ? C2 : C ++ C2
}
C # 256 frames, Y ascending

Len = (FAIL) ? 1 : FrameCount

K=Last.BlankClip(Length=Len,Pixel_Type="Y8",Color_YUV=$008080).Subtitle("[FAIL=" + String(FAIL) + "] Is NOT greater than 100.0",Align=5)
W=Last.BlankClip(Length=Len,Pixel_Type="Y8",Color_YUV=$FF8080).Subtitle("[FAIL=" + String(FAIL) + "] Is greater than 100.0",Align=5)

ConditionalFilter(W,K,"averageLuma >= 100.0 ",Show=true)
C=C.Scriptclip("""Subtitle(String(current_frame,"%.0f] Y=") + String(AverageLuma,"%.2f"))""")
StackHorizontal(C,Last)

#Trim(255,-1) # Only show last frame where result should be WHITE.

With FAIL=False (on last frame 255 where input frame Y is 255.0)
https://i.postimg.cc/w7TgT2Bz/Fail-False.jpg (https://postimg.cc/w7TgT2Bz)

With FAIL=True (on last frame 255 where input frame Y is 255.0)
https://i.postimg.cc/vgzkJRfV/FailTrue.jpg (https://postimg.cc/vgzkJRfV)

EDIT: Only Fails when BOTH W and K clips are of single frame length, otherwise succeeds. [have not tried 0 length clips]
EDIT: Over the years I've had problems trying to use Conditional filters [maybe always this one and because of Length thing], and is the reason that I tend to use Scriptclip for nearly everything.

EDIT: And v2.60 Std does not have optional arg Show, whereas v2.61 does. [for Wiki Editor, not mentioned when Show was added]

For above Easier for testing (Without SeperateRows),
With v2.60 std, if you wrap for/next in GScript wrappers, and remove optional Show from conditionalFilter call, then it works as posted, but still has the Length error as in avs+.
Strangly, v2.61 std shows some kind of "Invalid arguments to conditionalFilter" type message where v2.60 standard works ok, Odd.

EDIT: Above in BLUE, I had Grunt in both v2.58 and v2.60Std plugins, but not in v2.61std, and as Grunt allows for differing args(string expression), v2.61 failed on single string expression without
the Operator and Expression2 strings.

Grunt docs

ConditionalFilter

ConditionalFilter(clip testclip, clip source1, clip source2, string expression1, string operator, string expression2
[, bool showx, string args, bool local])
GConditionalFilter(clip testclip, clip source1, clip source2, string expression1, string operator, string expression2
[, bool show, string args, bool local])

ConditionalFilter(clip testclip, clip source1, clip source2, string expression
[, bool showx, string args, bool local])
GConditionalFilter(clip testclip, clip source1, clip source2, string expression
[, bool show, string args, bool local])

cf. AviSynth internal function ConditionalFilter

LouieChuckyMerry

7th October 2019, 16:56

Hello. Some months ago with help here I was able to transition from AviSynth+ 32 bit with LSB high bit depth to AviSynth+ 64 bit with native high bit depth processing, almost doubling my encoding speed. Thanks again to all who helped :thanks: . Also with help I translated my old script for upscaling 480p to 720p in native high bit depth using EDI_PRow2. I'm now trying to figure out how to downscale 1080p to 720p in native high bit depth but am having trouble, as it seems EDI_PRow2 isn't designed for downscaling. Does anyone have a suggestion for a downscaling resizer that works in native high bit depth? I've searched about but can't find anything. Here's the script:

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
aWarpSharp4xx(Depth=5)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

If I run the above script it's actually 8x slower than my old script using the LSB hack (and tests have determined that EDI_PRow2 is the reason for the slowdown). Thanks in advance for any help.

FranceBB

7th October 2019, 17:18

Does anyone have a suggestion for a downscaling resizer that works in native high bit depth? I've searched about but can't find anything.

If you mean a simple resizing kernel, Avisynth+ built in resizing kernel work with high bit depth, however I suggest you to use the MT version made by Jean-Philippe.
You can find them here: https://forum.doom9.org/showthread.php?t=174248

For instance, this works absolutely fine in 4:4:4 16bit planar:

ColorBars(3840, 2160, pixel_type="YV24")
ConvertBits(16)

Spline64ResizeMT(848, 480)

You can use other resizing kernel like Bilinear, Bicubic, Lanczos etc.
I actually suggest to use Lanczos for downscale and Spline36 or Spline64 to upscale.

Anyway, since in your script you were using EDI, you may wanna check out NNEDI which also works in 16bit planar:

ColorBars(3840, 2160, pixel_type="YV24")
ConvertBits(16)

nnedi3_rpow2(cshift="Spline64ResizeMT", rfactor=2, fwidth=848, fheight=480, nsize=4, nns=4, qual=1, etype=0, pscrn=2, threads=0, csresize=true, mpeg2=true, threads_rs=0, logicalCores_rs=true, MaxPhysCore_rs=true, SetAffinity_rs=false, opt=3)

as well as 16bit stacked:

ColorBars(3840, 2160, pixel_type="YV24")
Dither_convert_8_to_16()

nnedi3_resize16(target_width=848, target_height=480, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

Another resizer that works in 16bit stacked is LinearResize which lets you choose your desired resizing kernel and upscale or downscale with 16bit stacked precision:

ColorBars(3840, 2160, pixel_type="YV24")
Dither_convert_8_to_16()

LinearResize(848, 480, kernel="spline64", mode=0, lsb_in=true, lsb_out=true, TVrange=true, matrix="709", matrix_out="709", cplace_in="mpeg2", cplace_out="mpeg2", NoRing=false, interlaced=false)

LinearResize is part of the ResizerPack that you can find here: http://www.mediafire.com/file/w8sayuutsbgbmvd/ResizersPack4.5.zip/file

I hope it helps.

Cheers,
Frank.

StainlessS

7th October 2019, 18:15

NNEDI3_RPow2 intended for UPSCALE ONLY, it can eg double (x2, x4, x8, power of 2, etc) the dimensions of input clip with good-ish neural net type stuff upsize, and then
using the 'CShift="Spline64"' bit, downsize to the exact required size, and fix center shift imposed by the NNEDI3_RPow2 upsizing.

Is likely slower than LSB high bit depth when down sizing, because you upsize with NNEDI3_RPow2 (probably 4x the area of source), and then downsize to target size.
Only use NNEDI3_RPow2 if UPSIZE.

I usually use NNedi3_RPow2, but assume EDI_RPow2 works the same-ish.

EDIT: Intended for NNedi3_RPow2, but I assume will work with Edi_RPow2
Estimate_Nnedi3_Rpow2() :- https://forum.doom9.org/showthread.php?t=176437

Rough usage

ColorBars(Width=400,Height=400,Pixel_type="YV12")
InW=Width
InH=Height

SCALE = 3.3
TH = 1.5
TH2 = TH
TAPS = 5

RND = 4 # Rounding to multiple of RND
OutW = (InW * SCALE + RND-1).Int / RND * RND # Round UP
OutH = (InH * SCALE + RND-1).Int / RND * RND # Round UP
#OutW = (InW * SCALE + RND/2).Int / RND * RND # Round Nearest
#OutH = (InH * SCALE + RND/2).Int / RND * RND # Round Nearest

rFactor=Last.Estimate_Nnedi3_Rpow2(OutW,OutH,th=TH,th2=TH2)
(rFactor>1)
\ ? nnedi3_rpow2(rfactor=rfactor,cshift="LanczosResize",fwidth=OutW,fheight=OutH,ep0=TAPS) [* Upsizing *]
\ : LanczosResize(OutW, OUTH, src_left=-0.5, src_top=-0.5, taps=TAPS) [* NOT Upsizing *]

S=String(InW,"InW=%.0f")+String(InH," : InH=%.0f")+String(OutW,"\nOutW=%.0f")+String(OutH," : OutH=%.0f")+String(rFactor,"\nrFactor=%.0f\n") + ((rFactor>1) ? "Using RPOW2" : "Not Using RPOW2")

Return Subtitle(S,Size=Height/16.0,lsp=0)

Change the stuff above in BLUE

EDIT: Nnedi3 resize16() script has ratiothr [instead of above TH and TH2] to do similar:- http://avisynth.nl/index.php/Nnedi3_resize16#Scaling_Ratio_Calculation
Scaling Ratio Calculation
float ratiothr = 1.125

When scale ratio is larger than ratiothr, use nnedi3+Dither_resize16 upscale method instead of pure Dither_resize16.
When horizontal/vertical scale ratio > "ratiothr", we assume it's upscaling
When horizontal/vertical scale ratio <= "ratiothr", we assume it's downscaling

LouieChuckyMerry

7th October 2019, 18:39

FranceBB: As always thank you for your help :) .

If you mean a simple resizing kernel, Avisynth+ built in resizing kernel work with high bit depth, however I suggest you to use the MT version made by Jean-Philippe.

You can find them here: https://forum.doom9.org/showthread.php?t=174248

For instance, this works absolutely fine in 4:4:4 16bit planar:

ColorBars(3840, 2160, pixel_type="YV24")
ConvertBits(16)

Spline64ResizeMT(848, 480)

You can use other resizing kernel like Bilinear, Bicubic, Lanczos etc.
I actually suggest to use Lanczos for downscale and Spline36 or Spline64 to upscale.

Thank you very much. I've run a few tests and LanzcosResizeMT seems to work fine. What's the difference between Lanzcos and Lanzcos4?

Anyway, since in your script you were using EDI, you may wanna check out NNEDI which also works in 16bit planar:

ColorBars(3840, 2160, pixel_type="YV24")
ConvertBits(16)

nnedi3_rpow2(cshift="Spline64ResizeMT", rfactor=2, fwidth=848, fheight=480, nsize=4, nns=4, qual=1, etype=0, pscrn=2, threads=0, csresize=true, mpeg2=true, threads_rs=0, logicalCores_rs=true, MaxPhysCore_rs=true, SetAffinity_rs=false, opt=3)

as well as 16bit stacked:

ColorBars(3840, 2160, pixel_type="YV24")
Dither_convert_8_to_16()

nnedi3_resize16(target_width=848, target_height=480, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

Another resizer that works in 16bit stacked is LinearResize which lets you choose your desired resizing kernel and upscale or downscale with 16bit stacked precision:

ColorBars(3840, 2160, pixel_type="YV24")
Dither_convert_8_to_16()

LinearResize(848, 480, kernel="spline64", mode=0, lsb_in=true, lsb_out=true, TVrange=true, matrix="709", matrix_out="709", cplace_in="mpeg2", cplace_out="mpeg2", NoRing=false, interlaced=false)

LinearResize is part of the ResizerPack that you can find here: http://www.mediafire.com/file/w8sayuutsbgbmvd/ResizersPack4.5.zip/file

I was using EDI_PRow2 to upscale because of its native 16 bit support. I've used NNEDI in the past but stopped when I upgraded to native 16 bit, and the same for LinearResize (thanks dogway!), so your XXXResizeMT suggestion is great. With this script:

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
LanczosResizeMT(1280,720)
aWarpSharp4xx(Depth=5)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

do you see any way to improve downscaling 1080p?

I hope it helps.

Cheers,
Frank.

It truly does, danke!

StainlessS

7th October 2019, 19:21

What's the difference between Lanzcos and Lanzcos4?

Form docs
LanczosResize / Lanczos4Resize
LanczosResize is an alternative to BicubicResize with high values of c about 0.6 ... 0.75 which produces quite strong sharpening. It usually offers better quality (fewer artifacts) and a sharp image.

Lanczos was created for AviSynth because it retained so much detail, more so even than BicubicResize(x,y,0,0.75). As you might know, the more detail a frame has, the more difficult it is to compress it. This means that Lanczos is NOT suited for low bitrate video, the various Bicubic flavours are much better for this. If however you have enough bitrate then using Lanczos will give you a better picture, but in general I do not recommend using it for 1 CD rips because the bitrate is usually too low (there are exceptions of course).

The input parameter taps (default 3, 1<=taps<=100) is equal to the number of lobes (ignoring mirroring around the origin).

Lanczos4Resize (added in v2.55) is a short hand for LanczosResize(taps=4). It produces sharper images than LanczosResize with the default taps=3, especially useful when upsizing a clip.

Warning: the input argument named taps should really be lobes. When discussing resizers, taps has a different meaning, as described below (the first paragraph concerns LanczosResize(taps=2)):

"For upsampling (making the image larger), the filter is sized such that the entire equation falls across 4 input samples, making it a 4-tap filter. It doesn't matter how big the output image is going to be - it's still just 4 taps. For downsampling (making the image smaller), the equation is sized so it will fall across 4 *destination* samples, which obviously are spaced at wider intervals than the source samples. So for downsampling by a factor of 2 (making the image half as big), the filter covers 2*4=8 input samples, and thus 8 taps. For 3x downsampling, you need 3*4=12 taps, and so forth.

Thus the effective number of taps you get for downsampling is the downsampling ratio times the number of filter input taps (thus Tx downsampling and LanczoskResize results in T*2*k taps), this is rounded up to the next even integer. For upsampling, it's always just 2*k taps." Source: [avsforum post].

EDIT: From what I've read elsewhere, NNEDI3_RPow2() does not handle native 16 bit, but EDI_RPPow2() does, however, what I said in post #4886
about NNedi3_RPow2() still holds for EDI_RPow2(), do not DOWNSCALE using EDI_RPow2(), just use your chosen Spline64Resize() instead of the EDI_RPow2() line.

Only use NNEDI3_RPow2 or EDI_RPow2() if UPSIZE.

real.finder

8th October 2019, 05:52

the problem with Spline64Resize and others naked avs resizes except dither_resize and avsresize (z_ConvertFormat) always centred chroma placement and that problem with mpeg2 420 and 422 subsampling

resizex use MT version that made by Jean-Philippe if it present

jpsdr

8th October 2019, 08:50

BTW, the version i've made of nnedi3 (and nnedi3_rpow2) supports native 16 bits, and also nnedi3_rpow2 doesn't have the centred chroma placement issue that also has the original.

LouieChuckyMerry

9th October 2019, 04:54

Form docs

EDIT: From what I've read elsewhere, NNEDI3_RPow2() does not handle native 16 bit, but EDI_RPPow2() does, however, what I said in post #4886
about NNedi3_RPow2() still holds for EDI_RPow2(), do not DOWNSCALE using EDI_RPow2(), just use your chosen Spline64Resize() instead of the EDI_RPow2() line.

Only use NNEDI3_RPow2 or EDI_RPow2() if UPSIZE.

Thanks again :) . I'll hopefully run some upscale-downscale tests this weekend with EDI, NNEDI, Spline, Lanczos, Bicubic, and others.

the problem with Spline64Resize and others naked avs resizes except dither_resize and avsresize (z_ConvertFormat) always centred chroma placement and that problem with mpeg2 420 and 422 subsampling resizex use MT version that made by Jean-Philippe if it present

Thank you :) . I've downloaded ResizeX and will run some tests hopefully this weekend.

BTW, the version i've made of nnedi3 (and nnedi3_rpow2) supports native 16 bits, and also nnedi3_rpow2 doesn't have the centred chroma placement issue that also has the original.

Merci :) . I'll hopefully run some tests this weekend.

jpsdr

9th October 2019, 10:45

If you use my ResizexxxMT and also my NNEDI version, you'd better get my plugin package with all my filters in one dll instead of several filters in several dll.

LouieChuckyMerry

9th October 2019, 15:39

If you use my ResizexxxMT and also my NNEDI version, you'd better get my plugin package with all my filters in one dll instead of several filters in several dll.

Thanks for the advice, jpsdr. It's here in case someone finds it useful: JPSDRPluginsPack (https://forum.doom9.org/showthread.php?t=174248). Several questions:

1) When you typed "ResizexxxMT" did you mean "ResampleMT/Desample"? I didn't find anything named "ResizexxxMT".

2) I'm running Win 7 x64 with an Intel Core i5-3320M CPU--Speccy states "MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, Intel 64, NX, VMX, AES, AVX"--so which version would I use, the "Release_Intel_W7_Core2_SSE4.2"? Apologies for my ignorance.

Edit: Trial and error has taught me that my laptop is old, and W7_AVX is my best option.

3) Would you have a suggestion, or personal preference, for which resize plugin to use for upscaling animation DVD's (eg, The Simpsons and Futurama) and downscaling animation Blu-rays (eg, Adventure Time).

Thank you very much.

FranceBB

10th October 2019, 07:16

1) When you typed "ResizexxxMT" did you mean "ResampleMT/Desample"? I didn't find anything named "ResizexxxMT".

He means his set of resizers, like BilinearResizeMT, BicubicResizeMT, LanczosResizeMT ecc.

2) I'm running Win 7 x64 with an Intel Core i5-3320M CPU--Speccy states "MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, Intel 64, NX, VMX, AES, AVX"--so which version would I use, the "Release_Intel_W7_Core2_SSE4.2"? Apologies for my ignorance.

Those are CPU Instruction sets which in terms of a program refer to how the program has been compiled. A program can have manually written intrinsics (e.g parts written in assembly) or it can be written using C++ and then compiled.
To clarify this, there are low-level programming languages like Assembly and high-level programming languages like C++. When you write a program and then you compile it, it's up to the compiler to produce a code that the machine understands.
If you write it using a low-level programming language like Assembly, the code is gonna be very optimized as it's gonna be as close as possible to what the machine understands, however writing a full program in a low-level language is a nightmare, especially for complicated things, where it's easy to lose track of what you are doing and why you are doing it. As opposite, a high level programming language like C++ is easier to use, however it will be less optimized 'cause the compiler has to "guess" about what you wanted to do and "bring" your code to something that a machine can understand. Generally, the idea is to use a high level programming language and then optimize the key parts by manually writing intrinsics, (which is not easy and it's far too advanced for me as I'm not able to do that and I only code using a high level programming language).
Now, in the case of Jean-Philippe plugins, I believe that they were written in C++ only and then compiled using different assembly optimizations. (It's been a while since I last checked the code, though, so I might be wrong).
This way, it's gonna be the compiler that will try to understand what the programmer wanted to do and will try to optimize it for different assembly instructions, which won't be as fast as manually written intrinsics, but it will be faster than using no assembly optimizations at all.
Now, I know what you are thinking... you are basically thinking "fair enough, Frank, but what are those SSE, SSE2, SSE3 SSSE3, SSE4.1, SSE4.2, AVX ecc things?".
Well, one way I use to explain this to non-programmers is to think about two CPUs, an old one with SSE2 and a recent one with AVX2.
Think about the SSE2 CPU as a "dumb child" who can only do addition and the AVX2 one as a "smart child" who can do multiplication.
Of course, as long as the teacher assigns those children additions, both are gonna be fine, however, if the teacher assigns those children multiplications, the second child (the smart one) will do them, while the first one (the dumb one) will have to split them into additions and then will get to the same result.
The teacher is like the program you are trying to execute.
Additions is like a program compiled with SSE2.
Multiplication is like a program compiled with AVX2.
If you try to assign multiplications to the dumb child without splitting them into additions, the dumb child won't be able to do them, which means that if you compile a program with AVX2 and you try to open it with an SSE2 capable CPU it won't be able to run it and will fail, however if you split them in sums and you assign them to the dumb child, he will be able to do them, but it will take longer (i.e if you compile the program with SSE2, the CPU will be able to run the program but it will be slower).

And... that's it. :)
I know that it's a very simple way to see it and there is more behind this, but I'm not gonna explain it any further as it would take pages to get into details of what each and every instruction set does, but you can check Wikipedia for them as they are all documented.
One little note at the end: remember that I told you that sometimes programs are written in C++ only and then compiled with assembly optimizations by the compiler which has to guess what the compiler is doing? Well, it may not guess right and, as a matter of fact, there are times in which an AVX2 compiled code is not faster than an SSE4.2 compiled one (I'm sure there are topics about it on Doom9 but I can't think about them, I just know that I've been over this other times in the past). :)

jpsdr

10th October 2019, 09:36

@LouieChuckyMerry
You can use either Release_Intel_W7_Core2_AVX or Release_W7_AVX.
After, check the readme also.

There is a lot of ASM optimized, CPU path is made internaly for these parts, but for the other C++ code, compiler optimize.

LouieChuckyMerry

11th October 2019, 15:35

FranceBB: I had to read your last post three times but I finally understand: I'm a "dumb child" :D . Seriously, thanks for the, er, dumbed down explanation. As a computer noob I found it quite informative and am very appreciative :) .

jpsdr: Thanks for your help, and for all your awesome plugins :) .

Happy Friday!

qyot27

21st October 2019, 04:06

https://github.com/AviSynth/AviSynthPlus/releases

AviSynth+ 3.4.0 has been released. I debated whether to post a new thread in order to make sure it was visible, but I figured that even if a dedicated release post gets made, it should also be posted here too.

Back in June there was a somewhat-short discussion about the versioning and a new release. Since there weren't any objections brought up about the commit I'd mentioned as having done a version bump, and nearly four months went by, I simply went ahead and did it. Another big reason is that there's a MAJOR patchset I've been working on in manic bursts over the last month, and since it changes a good amount of things I wanted to make sure there was a solid official release to point to before a lot of the work hammering that patchset into shape really gets going.

3.4 is pretty boring, all told. As the big changes from pull request #101 were already committed to MT several months ago, 3.4 basically catches up with pinterf's development branch (r2915 from late August) and has a small number of additional patches to smooth over the packaging process and officially roll over to the new versioning.

Some other highlights:
MT was finally merged back into the master branch.
A new '3.4' branch was created to [hopefully] track releases in the 3.4 series from this point forward.
How to do third-number version releases is still an open question; should it be vital bugfixes only? A generic X number of months rolling forward? Really open to suggestion here.
Part of the release is actually a GCC build of 3.4. Installation notes included (and packaged in a 7zip archive instead of an installer) because I haven't added the requisite logic to the InnoSetup script to handle FHS-style install paths yet.
Due to the version bump, don't be surprised if some curmudgeonly software that didn't like using AviSynth+ suddenly starts working with it.

markfilipak

21st October 2019, 06:05

Hello Folks!

I went here: http://www.avs-plus.net/
and downloaded this: https://github.com/AviSynth/AviSynthPlus/releases/download/Rel-r1576/AviSynthPlus-r1576.zip
and unzipped it.
Now I have these:
\AviSynth.dll
\system\DevIL.dll
\plugins\DirectShowSource.dll
\plugins\ImageSeq.dll
\plugins\Shibatch.dll
\plugins\TimeStretch.dll
\plugins\VDubFilter.dll
I checked them at VirusTotal.

I understand what avisynth is.
What do I do with the DLLs?

The documentation begins with writing a 1st script.
There appears to be nothing that outlines how to set up the frameserver, how to get started, how to bootstrap the process.
I know there's a Windows installer. It's by Inno. I lost the magic formula for opening Inno Setups to check the internals for viruses and it's unclear whether VirusTotal actually does that when it analyzes a wrapper executable.
I already have Python 3.7 (64-bit) installed.
What more do I need and how do I proceed?

I have 2 objectives:
1, Retire HandBrake, and
2, try some interframe field blending ideas that should improve on 2-3 pull-down.

Thanks.