Avisynth+

[Myrsloik]

Originally Posted by wonkey_monkey

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]

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]

@P, see here:- http://forum.doom9.org/showthread.ph...77#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)


With FAIL=True (on last frame 255 where input frame Y is 255.0)


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]

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

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/w8sayu...ck4.5.zip/file


I hope it helps.

Cheers,
Frank.

[StainlessS]

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

Originally Posted by StainlessS

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

FranceBB: As always thank you for your help .

Originally Posted by FranceBB

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?

Originally Posted by FranceBB

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/w8sayu...ck4.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?

Originally Posted by FranceBB

I hope it helps.

Cheers,
Frank.

It truly does, danke!

[StainlessS]

Originally Posted by LouieChuckyMerry

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]

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]

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]

Originally Posted by StainlessS

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.

Originally Posted by real.finder

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.

Originally Posted by jpsdr

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]

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]

Originally Posted by jpsdr

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

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]

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

FranceBB: I had to read your last post three times but I finally understand: I'm a "dumb child" . 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]

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]

Hello Folks!

I went here: http://www.avs-plus.net/
and downloaded this: https://github.com/AviSynth/AviSynth...Plus-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.

[StainlessS]

markfilipak,
Avoid r1576, is from several years ago [4 or 5].
Get This one AviSynthPlus_3.4.0_20191020.exe from here:- https://github.com/AviSynth/AviSynthPlus/releases

[filler56789]

http://www.avs-plus.net/ should be shut down for good.