Avisynth+

[LouieChuckyMerry]

Back for more. After receiving enough help here to upgrade from 32 bit AviSynth+ to 64 bit--thanks again for all the help :) --for my usual Blu-ray sources, I'm now trying to learn how to use 64 bit AviSynth+ for my DVD sources. I've found all the required 64 bit .dll's for my upscale scripts except ColorMatrix (to convert from Rec.601 to Rec.709). After much searching and reading, it seems that I can simply replace the 32 bit line:

ColorMatrix(Mode="Rec.601->Rec.709")

with:

ConvertTo(Proper Symbols Here)

in 64 bit AviSynth+, but I can't figure out just what the proper symbols are. In case it matters, my script is something like:

DGSource Here
### Deinterlace ###
TFM(Mode=7,UBSCO=False)
### Color Conversion ###
ColorMatrix(Mode="Rec.601->Rec.709")
### Adjust Color ###
MergeChroma(aWarpSharp2(Depth=16))
### Crop ###
Crop(8,1,-8,0)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor").Blur(1.0)
MT_Merge(Minblur(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(TR=3,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,n16=True,n16_Out=True)
### Resize ###
EDI_RPow2(CShift="Spline64",FWidth=960,FHeight=720)
aWarpSharp4xx(Depth=5)
### Darken-Thin Lines ###
FastLineDarkenMod4(Strength=24,Prot=6)
aWarpSharp4xx(Blur=4,Type=1,Depth=8,Chroma=2)
### Deband ###
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)

As always, thanks for any help.

Edit: Happy Saturday! After banging my (obviously thick) head against the wall for a while longer I realized that MeGUI has a copy of ColorMatrix.dll in its AviSynth_Plugins folder, so I borrowed a copy from the 64 bit version and all is well. I'd still be curious if "ConvertTo(Something)" would do the same job...

[real.finder]

bug in expr? in float(32)

mt_lut( "x range_half - 0.1 * range_half +", scale_inputs="floatf", U=3,V=3 )

not same as

expr( "x range_half - 0.1 * range_half +" ,scale_inputs="floatf")

without scale_inputs="floatf" they are same

[pinterf]

bug in expr? in float(32)

mt_lut( "x range_half - 0.1 * range_half +", scale_inputs="floatf", U=3,V=3 )

not same as

expr( "x range_half - 0.1 * range_half +" ,scale_inputs="floatf")

without scale_inputs="floatf" they are same

Do you know which one is correct?

[real.finder]

Do you know which one is correct?

the mt_lut one is correct

[pinterf]

the mt_lut one is correct
O.k. thanks, I check them both and found no problem for a quick five-minute investigation, so I need more time.

[pinterf]

the mt_lut one is correct
This issue was fixed, it's on git already, I'll make a build next week.

[real.finder]

This issue was fixed, it's on git already, I'll make a build next week.

thank you

[djonline]

Trim not work after Import, only after DirectShowSource.

DirectShowSource("avisynth-stage1-with-MTS.avs") still not work with LAV splitter 0.71

Then write the Trim in a separate line, not after a dot.

If the imported script returns a clip, then it should be passed to the usual internal variable "last", which is then implicitly assumed where no explicit clip variable was written.

If it does not return any clip, then it can't be used as video source anyway.
Still not work with Deshaker, video is shaked when using Import

"00425.MTS-pass2.avs"
vid="00425.MTS"
o=DirectShowSource(vid)
o+o.Trim(0,29)
ConvertToRGB32
LoadVirtualDubPlugin ("c:\Program Files\Vdub\vdub64\plugins64\Deshaker_64.vdf", "deshaker",0) deshaker ("19|2|30|4|1|0|1|0|640|480|1|2|1000|1000|2000|2000|4|0|6|2|8|30|300|3|f:\\00425.MTS.1.1000.1000.2000.2000.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|70|70|10|30|1|1|30|30|0|0|0|0|1|0|1|10|1000|1|88|1|1|20|30000|100|20|1")

00425.MTS-loader.avs
#DirectShowSource("00425.MTS-pass2.avs").Trim(30,0)
Import("00425.MTS-pass2.avs")
Trim(30,0) #video is shaked with this

[StainlessS]

# "00425.MTS-pass2.avs"
vid="00425.MTS"
o=DirectShowSource(vid)
# o+o.Trim(0,29) # Join o.trim(0,29) to END OF o
o.Trim(0,29) # presume this is required
#o.Trim(29,0) # EDIT: Or, is it this
ConvertToRGB32
LoadVirtualDubPlugin ("c:\Program Files\Vdub\vdub64\plugins64\Deshaker_64.vdf", "deshaker",0)
deshaker ("19|2|30|4|1|0|1|0|640|480|1|2|1000|1000|2000|2000|4|0|6|2|8|30|300|3|f:\\00425.MTS.1.1000.1000.2000.2000.log"
\ + "|0|0|0|0|0|0|0|0|0|0|0|0|0|1|70|70|10|30|1|1|30|30|0|0|0|0|1|0|1|10|1000|1|88|1|1|20|30000|100|20|1")

[Stereodude]

Is there an avisynth+ version of DitherTools by any chance (I searched but came up empty)? If not, is there a way to get dithertool's rgb48y output into RGBP16 which AVIsynth+ handles? I think rgb48y and RGBP16 are basically the same thing just stored differently.

[real.finder]

Is there an avisynth+ version of DitherTools by any chance (I searched but came up empty)? If not, is there a way to get dithertool's rgb48y output into RGBP16 which AVIsynth+ handles? I think rgb48y and RGBP16 are basically the same thing just stored differently.

avisynth+ version of DitherTools? no, it's still avs25/avs26

some DitherTools functions for avs+? yes, like the one I post here (https://forum.doom9.org/showthread.php?p=1880226#post1880226) maybe there are others by another persons

[qyot27]

Is there an avisynth+ version of DitherTools by any chance (I searched but came up empty)? If not, is there a way to get dithertool's rgb48y output into RGBP16 which AVIsynth+ handles? I think rgb48y and RGBP16 are basically the same thing just stored differently.
From the Dither tools wiki page:
"rgb48y" 48-bit RGB. The components R, G and B are conveyed on three YV12 or Y8 (if supported) stack16 clips interleaved on a frame basis.
I don't truly know how to interpret that description. Because from what it sounds like, you'd have to treat a Y8 frame (assuming it would default to Y8 on 2.6 and Plus) as an individual RGB plane, but you *also* have to apply ConvertFromStacked() and Select every third frame into individual variables to try then stitching them back together into a real RGBP16 stream with CombinePlanes (http://avisynth.nl/index.php/CombinePlanes). That's just my best guess, assuming the 'interleaved on a frame basis' means something like 6 frames being R1-B1-G1-R2-B2-G2, and not 'interleaved' in the sense that Stack16 format's counterpart Interleaved16 was for doing high bit depth.

IMO, I think it'd be easier to see if other Plus-compatible plugins (or its native HBD and dither functionality) can do what you want without bringing DitherTools into it at all.

[stax76]

I would like to request scaling for Info() because with 4K it's barely readable.

A player such as mpv shows always the same OSD font size regardless of the video resolution.

[qyot27]

I would like to request scaling for Info() because with 4K it's barely readable.

A player such as mpv shows always the same OSD font size regardless of the video resolution.
Just set the font size to 72. Or higher. Whatever you want; it's been customizable for three years now (https://github.com/AviSynth/AviSynthPlus/issues/99) (AviSynth Wiki (http://avisynth.nl/index.php/Info)).

http://i.imgur.com/i9nIFfCh.jpg (https://imgur.com/i9nIFfC)

[wonkey_monkey]

May I recommend Info2 (https://forum.doom9.org/showthread.php?t=176563), which is much easier to read and much much faster (it's missing a couple of not-that-useful things from Info).

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

[VoodooFX]

What AVS+ vs AVS 2.6 does differently at initial script load? I noticed that one of my script loads ~hundred times slower in AVS+.
Most slowness I localized to this pseudo code below, AVS loads it in milliseconds or a second when AVS+ takes ~few minutes. (I don't want to publish script atm).

Trim1 = clip.Trim(22,-30)+clip.Trim(22222,-30)
a = Trim1.Loop(200)

a.PseudoParse()
Trim(0,-1)
setA = PseudoSetting(last)
aClip = clip.PseudoJob(setA)

Trim2 = aClip.Trim(22,-30)+aClip.Trim(22222,-30)
b = Trim2.Loop(200)

b.PseudoParse()
Trim(0,-1)
setB = PseudoSetting(last)
bClip = aClip.PseudoJob(setB)

Trim3 = bClip.Trim(22,-30)+bClip.Trim(22222,-30)
c = Trim3.Loop(200)

c.PseudoParse()
Trim(0,-1)
setC = PseudoSetting(last)
cClip = bClip.PseudoJob(setC)

return cClip

[wonkey_monkey]

Hard to say if we don't know what all the Pseudo functions do. Is there still a speed difference if you take those blocks out (replacing them aClip = a, etc), leaving just all the splices?

[VoodooFX]

It goes slower in some geometric progression with every xClip block, AVS 2.6 loads it in a second, when AVS+ runs script faster than AVS (I think). If it helps: PseudoParse() is AnalyzeLogo(), PseudoSetting() is ImageWriter(), PseudoJob() is DeblendLogo() from AVSInpaint.

Actual script will be more confusing without manual(yet), and I want to solve few other issues before publishing it.

PS:
Replacing to: aClip = Clip, bClip = Clip - just makes script 3 times faster to load. Remove all those "inception" blocks and AVS+ still is significantly slower at loading.

[LigH]

May I recommend Info2 (https://forum.doom9.org/showthread.php?p=1878265)

Pretty pretty!
:goodpost:

[magiblot]

What is the range of expected pixel values for floating-point formats? [0..1], [0..255/256], or the former for RGB and the latter for YUV?

[FranceBB]

What is the range of expected pixel values for floating-point formats? [0..1], [0..255/256], or the former for RGB and the latter for YUV?

8bit:
Full Range 0-255 / Limited TV Range: 16-235

10bit:
Full Range 0-1023 / Limited TV Range: 64-940

12bit:
Full Range 0-4080 / Limited TV Range: 256-3760

14bit:
Full Range 0-16320 / Limited TV Range: 1024-15040

16bit:
Full Range 0-65280 / Limited TV Range: 4096-60160

32bit float:
Full Range 0.0-0.99609375 / Limited TV Range: 0.0625-0.91796875


This simulates clipping a 32bit signal:


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

ConvertBits(32, truerange=true)

Limiter(min_luma=0.0625, max_luma=0.91796875)


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


Wrongly clipping 8bit values from a 32bit float clip:


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

ConvertBits(32, truerange=true)

Limiter(min_luma=16, max_luma=235)


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


I personally work with 16bit precision which I think it's enough when my output is gonna be dithered down to 8bit for SD, HD and FULL HD footages, 10bit for UHD broadcast footages and 12bit for UHD Masterfiles.
So far I haven't used 32bit precision in a real world scenario, but still, it's kinda cool to have such an high bit depth. :)

[jpsdr]

12bit:
Full Range 0-4080
14bit:
Full Range 0-16320
16bit:
Full Range 0-65280
32bit float:
Full Range 0.0-0.99609375

What...:confused::eek:

Is this only YUV, or is it also RGB (mostly for 16bits for the last one). I didn't expect remaining gap between theorical max for full range.

[wonkey_monkey]

What...:confused::eek:

Is this only YUV, or is it also RGB (mostly for 16bits for the last one). I didn't expect remaining gap between theorical max for full range.

I assumt it's because it's done as bit-shifts. 255<<4 = 4080, 255<<6 = 16320, 255<<16 = 65280.

10-bit wasn't on the list but I assume it's 0-1020.

It's possibly a way to make all up-conversions consistent/transitive (and fast), but I wonder if down-conversions are more complicated. By a simple bit-shift, only one value in 16-bit would map to 255 in 8-bit (62580), whereas 256 values (0-255) would map to 0.

[magiblot]

32bit float:
Full Range 0.0-0.99609375 / Limited TV Range: 0.0625-0.91796875

This is what theory says, as explained in http://avisynth.nl/index.php/Autoscale_parameter, http://avisynth.nl/index.php/Convert and other places:

* The special-purpose matrices PC.601 and PC.709 keep the range unchanged, instead of converting between 0d-255d RGB and 16d-235d YUV, as is the normal practice.

Which implies that these ranges apply to RGB as well. And this makes sense to me as using multiples of 1/256 should help avoid rounding errors.

However, the question is: do filters actually expect pixel values to be in that range?

ConvertBits, for instance, seems not to:

Conversion from and to float is always full-scale.

Practical examples show different behaviours:

BlankClip(height=240).ConvertToPlanarRGB()
Expr(String(255.0/256.0), format="RGBPS") # 255d
StackVertical( Expr("x 256 *", format="RGBP8").ConvertToRGB32().RGBAdjust(analyze=true).Subtitle("'D notation'-compliant conversion"),
\ ConvertToRGB32().RGBAdjust(analyze=true).Subtitle("Default conversion") )

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

BlankClip(pixel_type="YV24")
Expr("0.0", format="YUV444PS")
ColorYUV(levels="PC->TV") # Bug in ColorYUV? Picture turns green
ColorYUV(analyze=true) # OK: luma is 0.6250 == 16/256

Expr("1.0", format="YUV444PS")
ColorYUV(levels="PC->TV")
ColorYUV(analyze=true) # Confusing: luma is 0.91796875 == 235/256, but input expected to be 1.0 rather than 255/256

Expr(String(235.0/256.0), format="YUV444PS")
ColorYUV(levels="TV->PC")
ColorYUV(analyze=true) # Same as before: 235/256 translates into 1.0 instead of 255/256

BlankClip(color_yuv=$108080, pixel_type="YV24") # Plain black in limited range
ConvertBits(32)
ColorYUV(analyze=true) # Inconsistent: 16d represented as 16/255 == 0.062745... (periodic number)

From ColorYUV's behaviour, one could assume that [16d..235d] is used for limited range and [0..1] for full range. But, by looking at ConvertBits, one would deduce that [16/255..235/255] and [0..1] are to be used instead. Documentation, conversely, speaks of [16d..235d] and [0d..255d].

In addition, RGBAdjust and Compare are unable to analyze floating-point pixel types, which makes it more difficult to see what's going on.

[jpsdr]

10-bit wasn't on the list but I assume it's 0-1020.

10-bit wasn't in my list, but was on original post with, for this one, expected value of 1023.

[StainlessS]

My natural inclination when using up shift would be to fill the 'nullified' least signifcant bits in destination number with the most significant bits from source number.

eg 8->10 bit,
7654321076 src bit indexes
9876543210 dst bit indexes

or eg 8->16
7654321076543210
fedcba9876543210 # hexified

But, that aint right, apparently.

EDIT: I think Knuth, TAOCP, Vol 1, Fundamental Algorithms, would suggest same for fast accurate upscale using shift only. [I left my copy on a train many years ago].

[poisondeathray]

Why is this horizontal line shifted ? (You can see it if you return a vs. b)

YV24 (and using ConvertToYUV444) works as expected, so is it some chroma resizing issue in 32bit? I tried different chromainplacement/chromaoutplacement settings as well

r2772 MT x64 ; or is it already fixed in one of the beta releases ?


a=colorbars(pixel_type="YV12").trim(0,-1)

a
ConvertBits(32)
ConvertToPlanarRGB(matrix="rec601", chromaresample="point")
ConvertToYUV420(matrix="rec601", chromaresample="point")
ConvertBits(8)
b=last

interleave(a,b)

[StainlessS]

Dont know but,

a=colorbars(pixel_type="YV12")

a
ConvertBits(32)
ConvertToPlanarRGB(matrix="rec601", chromaresample="point")
ConvertToYUV420(matrix="rec601", chromaresample="point")
ConvertBits(8)
b=last

#a
#b
b.subtract(a).stackHorizontal(a) # EDITED

https://i.postimg.cc/RZQNmMYx/a-02.jpg (https://postimages.org/)
ver$ r2900

EDIT: changed order from a.subtract(b) to b.subract(a) and reposted image.
So, eg where subtracted is yellow, then output is more yellow than input.
EDIT: Added in blue, b.subtract(a).stackHorizontal(a)

Dont know if as expected or not.

[poisondeathray]

Dont know if as expected or not.




It's supposed to be lossless ; it is with vapoursynth

32bit float "expected" range is 0-1 , but negative values , and values than 1 should are kept. They are in other programs too. That's one of the main reasons for using float. It's commonly used with raw processing, and high end effects/compositing

You can read off the values in vapoursynth editor for different bit depths , and for float (<0 , >1 ), but I cannot "read" values in avspmod besides 8bit, I don't know what avs+ is doing

I think this issue has something to do with chroma resampling, because if you do colorbars(pixel_type="YV24"), and ConvertToYUV444 after the RGB step, it works as expected (equivalent)

If you do 8bit or 16bit (instead of 32), you got not equivalent (as expected) .

Float is required for the lossless round trip, but if it was a problem with float processing in general then the YV24 should have errors too

[wonkey_monkey]

My natural inclination when using up shift would be to fill the 'nullified' least signifcant bits in destination number with the most significant bits from source number.

But, that aint right, apparently.


The problem with that - mathematically speaking, anyway - is that it would make 8 bit->16 bit different from 8-bit->12 bit->16 bit, for example.

10111111 -> 1011111110111111

10111111 -> 101111111011 -> 1011111110111011

[StainlessS]

Taken to extreme,
1 bit to 16 bit

1
1111111111111111 # same as before but with the repeated downshift of most signiicant bits (recurring stuff).

Shift only
1 # 1=max poss
1000000000000000 # half max poss

It is an imperfect universe that we live in, guess we just gotta put up with it. [thank goodness that its not forever]

[jpsdr]

@FranceBB
Is there any spec (REC-BT, ...) where these full range data are described/explained ? And especialy if they also report to RGB.
Because i'm almost sure (but maybe i'm wrong...), and mine included, the avs filters use for full range max value (2^nBits)-1 and not 255 << (nBits-8) (with exception of 10 bits).
Seems a new value for the range parameter of my filter may be needed.

[TheFluff]

http://www.vapoursynth.com/doc/functions/resize.html

See "pixel range" at the bottom

[jpsdr]

It says that full range is (2^nBits)-1 and not 255 << (nBits-8), so, it's different from what FranceBB says.
But it's what T-REC-H.265-201802-S!!PDF-E says in page 409.

[hello_hello]

I noticed an oddity in the way negative zero variables are converted to string when they're float. The variables in the script are never negative, but I want them to display that way, unless they're zero. The upshot is....

This displays as 0
subtitle(string(float(-0), "%.0f"))

While this displays as -0
subtitle(string(-float(0), "%.0f"))

As does this
xxx = float(0)
subtitle(string(-xxx, "%.0f"))

And this
xxx = -float(0)
subtitle(string(xxx, "%.0f"))

But not for a double negative.
xxx = -float(0)
subtitle(string(-xxx, "%.0f"))

Avisynth 2.6 doesn't display the negative sign for any of them.

Cheers.

[VoodooFX]

Continuation from this post (https://forum.doom9.org/showthread.php?p=1882432#post1882432).

This script is 71 times faster in AVS v2.6 vs AVS+ :
clip = LWLibavVideoSource("C:\LagarithYV12.avi.lwi")
clp = clip.ConvertToRGB24
a = clp.Trim(20,-30)+clp.Trim(2000,-30)
a = a+a+a+a+a+a+a+a+a+a
a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a
return a

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

[StainlessS]

See here:- https://forum.doom9.org/showthread.php?p=1883127#post1883127

[ajp_anton]

This might be a very odd and niche feature request, but here goes...

In ConditionalReader, the OFFSET command offsets all lines below it a fixed number of frames, but it can be overwritten by another OFFSET command. My request is to add a new command, something like ADDOFFSET (or if you can think of a better name), where it doesn't overwrite previous offsets, but adds its offset to the previous one.

For example:
# This is for frame 0, obviously
0 value0
OFFSET 2
# This is for frame 3: 1 + offset 2
1 value1
# This adds 4 to the previous offset of 2
ADDOFFSET 4
# So this is now for frame 8: 2 + offsets 2+4
2 value2
# And this will overwrite the previous offset(s), as before
OFFSET 10
# So this is for frame 13: 3 + offset 10
3 value3


edit: Or maybe you could call it by
OFFSET+=4
# and of course also
OFFSET-=4
# while maybe even adding the possibility to write
OFFSET=2

edit2:
And for the motivation of this... say you have a long list of values for sequential frames, but then you need to add gaps here and there. With the current implementation of OFFSET, you can't change one gap without having to also change every OFFSET after it, and you can't directly read what the gap is without having to subtract the previous OFFSET.

[TheFluff]

Continuation from this post (https://forum.doom9.org/showthread.php?p=1882432#post1882432).

This script is 71 times faster in AVS v2.6 vs AVS+ :


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

is there any difference if you replace all the splices with loop()?

[StainlessS]

is there any difference if you replace all the splices with loop()?
still a significant difference with blankclip.

BlankClip(length=1000000000)
return Last

https://i.postimg.cc/c1RZsH7r/Untitled-00.jpg (https://postimages.org/)


EDIT: and with mostly loop()s

#clip=LSMashvideoSource("1941 Flint Michigan Parade [Low, 360p].mp4")
clip=BlankClip(length=3000)
clp = clip.ConvertToRGB24
a = clp.Trim(20,-30) + clp.Trim(2000,-30)

#a = a+a+a+a+a+a+a+a+a+a # *10
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20, = * 1600000 ::: 1600000 * 60 = 96,000,000

a=a.loop(1600000,0,59)

return a #.info # 96,000,000 frames ### Max possible frames = $7FFFFFFF, ~= 2,000,000,000

avs+ capped at about same time as v2.6 std had completed, and with still lots of time yet to expend.
https://i.postimg.cc/C16XsTHW/Untitled-01.jpg (https://postimages.org/)


EDIT: Avs+ a bit faster if no ConvertToRGB24 [EDIT: Avs 2.6 std takes about 2:45.00 for same script, unlike previous, quite a bit longer than avs+]

#clip=LSMashvideoSource("1941 Flint Michigan Parade [Low, 360p].mp4")
clip=BlankClip(length=3000).Killaudio
#clp = clip.ConvertToRGB24
clp=clip
a = clp.Trim(20,-30) + clp.Trim(2000,-30)

#a = a+a+a+a+a+a+a+a+a+a # *10
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20, = * 1600000 ::: 1600000 * 60 = 96,000,000

a=a.loop(1600000,0,59)

return a #.info # 96,000,000 frames ### Max possible frames = $7FFFFFFF, ~= 2,000,000,000

https://i.postimg.cc/NFXWbC0b/Untitled-00.jpg (https://postimages.org/)

[LigH]

See here:- https://forum.doom9.org/showthread.php?t=174797&page=10

Links with page numbers are a bit unreliable. People could have customized their "posts per page". Best use the "Link".

https://www.ligh.de/tmp/Link.png

[StainlessS]

Thanks, not intentional, fixed.

[Groucho2004]

This script is 71 times faster in AVS v2.6 vs AVS+ :
https://i.imgur.com/bDnMHrA.png
Classic Avisynth caches these 60 frames:
a = clp.Trim(20,-30)+clp.Trim(2000,-30)
and re-uses that block of memory for all loop and/or splice operations. Setting setmemorymax() to 128 or 64 shows what's happening.

AVS+ seems to read from the source every time in this scenario.

[pinterf]

For historical reasons (https://github.com/pinterf/AvisynthPlus/commit/50a1e569) Trim - along with other filters - is declared internally as a NonCachedGenericVideoFilter.
Changing that back to GenericVideoFilter yields significant speed increase.

Such filters are: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop

[VoodooFX]

For historical reasons (https://github.com/pinterf/AvisynthPlus/commit/50a1e569) Trim - along with other filters - is declared internally as a NonCachedGenericVideoFilter.
Changing that back to GenericVideoFilter yields significant speed increase.

Such filters are: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop

If it is only historical reason can you change them back to cached GenericVideoFilter?

[filler56789]

If it is only historical reason can you change them back to cached GenericVideoFilter?

I second that. "History" should be no excuse for bugs /design_flaws /bad_performance.

[Groucho2004]

I'm sure pylorak had a good reason for that commit, if I recall correctly it was related to MT functionality.

[Myrsloik]

I second that. "History" should be no excuse for bugs /design_flaws /bad_performance.

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.

[real.finder]

maybe as compromise and neutral Solution, trim can has cache parameter (false by default) if FrameCache() or RequestLinear() can't fix the slowdown

[VoodooFX]

I understand that such code doesn't make sense, until you know that it is the only way to get desirable result from external plugin.