AviSynth+ thread Vol.2

[Emulgator]

Fix Prefetch(1) + AvsPMod crash
Yippie, thanks, Ferenc ! Köszönom szepen !
Was undoing all my Prefetch calls last week, now it works fine again.

[Emulgator]

And here is an updated .bat file for Groucho2004's Universal Avisynth Installer to accommodate AVS+372

https://forum.doom9.org/showthread.php?p=1963566#post1963566

[Dogway]

I've been wondering for some time. Is it possible with CombinePlanes to pick the chroma of the first clip and the luma of the second? Main reason, keep frameprops from the first clip, but also for other uses:
CombinePlanes(YUVa,YUVb,source_planes="UVY",planes="YUV") # pseudo-call

Also mix several clips into one, format is the same (bitdepth, size, subsampling):
CombinePlanes(YUVa,Ub,YUVc, source_planes="YUVUYUV",planes="YUV") # pseudo-call

By the way there's also this (https://forum.doom9.org/showthread.php?p=1960946#post1960946)old optimization issue on pixel fetching.

[real.finder]

I've been wondering for some time. Is it possible with CombinePlanes to pick the chroma of the first clip and the luma of the second? Main reason, keep frameprops from the first clip, but also for other uses:
CombinePlanes(YUVa,YUVb,source_planes="UVY",planes="YUV") # pseudo-call

like this https://github.com/realfinder/AVS-Stuff/blob/de638db2e833b71eb652d0949a3500eeb12f3d05/avs%202.5%20and%20up/F3KDB_s.avsi#L175 and https://github.com/realfinder/AVS-Stuff/blob/70e3f1dd630c59265aee23b83f108df5ff81fc56/avs%202.6%20and%20up/scaled444tonative.avsi#L51 ?

edit: don't know why but CombinePlanes(YUVa,YUVb,planes="UVY",source_planes="UVY") seems did what you want

[Dogway]

Replicating your call I get an error with:
CombinePlanes(YUVa,YUVa,YUVb,planes="UVY",sample_clip=YUVa)
"CombinePlanes: source and target plane dimensions are different"
YUVa and YUVb are YUV420 clips though.

[wonkey_monkey]

I'm having another of my wacky ideas, but I'm struggling to find the place in the AviSynth source where I'd need to put it. Whereabouts in the source would I find the code that actually opens an.avs file and gets ready to parse it? Is that always done via an invoke of "Import"?

[real.finder]

Replicating your call I get an error with:
CombinePlanes(YUVa,YUVa,YUVb,planes="UVY",sample_clip=YUVa)
"CombinePlanes: source and target plane dimensions are different"
YUVa and YUVb are YUV420 clips though.

which call? in the links? they need to be monochrome (Y/Y8) IIRC

anyway as I said try
CombinePlanes(YUVa,YUVb,planes="UVY",source_planes="UVY")

[Dogway]

Thanks real.finder, getting somewhere although very counterintuitive. But it was only picking U from YUVa, I need the next to pick chroma from YUVa and luma from YUVb.
CombinePlanes(YUVa,YUVa,YUVb,planes="UVY",source_planes="UVY")
I'm sure this is not an optimal way to merge planes. I don't know how ShufflePlanes work in VS but working in other programs you can mix everything (plane/channel independent) with everything like Shuffle in Nuke, Swizzle in Substance, etc

[StainlessS]

Wonkey,
clarify, you wanna hack the source ?
what are you tryin' to do. [your wacky ideas are often entertaining :) ]
Import is sorta load script into ram, do a SaveString() on it, and then an Eval() on the saved string.
.

[wonkey_monkey]

Well, it's borne from my frustration with AviSynth's multiline syntax, the requirement to put a \ on the end of every line (which is a pain to write and edit, and makes it look very cluttered) and the inability to comment out lines in a multiline block.

I thought about suggesting a change to the parser - it could just ignore newlines within function call brackets (except those in strings).

But then I thought, no, maybe it's too risky to make those kind of changes, even if they seem like they should be harmless.

So then I thought, what if AviSynth offered a way for a regular plugin, which takes a string as input and gives a string as output, to pre-parse a script? It could remove newlines and deal with comments, or do other things that the AviSynth grammar can't do. That way the AviSynth parser is blameless if someone wants to use such a plugin and runs into a problem.

So what I thought was this: if a script begins with a shebang and a filter name (e.g. "#!filter_name"), AviSynth will strip the shebang line and pass the script to the named filter as a string to be transformed. It will then parse what it receives back as normal.

So for example, you could give it this script:

#!monkify_my_script

AviSource("test_file.avi")

{FlipVertical|FlipHorizontal}

ConvertTorRGB32(
matrix = "rec709",
# interlaced = true,
chromainplacement = "MPEG2",
chromaresample = "sinc",
# chromaoutplacement = "DV"
)

and it would, before doing anything else, send the script (minus the first line) to the function monkify_my_script, which is just a regular AviSynth plugin filter. The filter would do its thing, and in this case it might return:

AviSource("test_file.avi")

FlipVertical # the filter chose this at random from the strings inside {...|...}

ConvertTorRGB32(matrix = "rec709", chromainplacement = "MPEG2", chromaresample = "sinc") # commented parameters, newlines, and trailing comma removed (and ths comment added, how meta is that?)

You could specify multiple shebang lines and AviSynth will only start parsing once the script has passed through all of the filters specified.

[StainlessS]

I see.
[EDIT: Due to avisynth syntax] There is some kind of problem with multiple expressions not being able to tell if whole lot is a single expression or
is multiple, where you need a newline to explicitly prevent wrong interpretation, however I cannot remember an expression where this occurs.
(It has come up before, but my brain aint feeling very chippa at the moment, I just wanna go to sleep).
So, there may be a dragon lurking in your idea, ready and waiting to gobble you up.

[wonkey_monkey]

a) That case doesn't apply to function parameters, which are strictly separated by commas and can't contain multiple statements anyway.

b) In any case, that's why I propose the filtering method rather than a change to the parser (even though the limited case wouldn't be very harmful), because then it's the user's choice to pass the script through the filter.

[StainlessS]

I meant dragons in the "monkify_my_script()" filter whotsit.

[wonkey_monkey]

Oh, quite possibly, but they would be my dragons to slay.

[real.finder]

Thanks real.finder, getting somewhere although very counterintuitive. But it was only picking U from YUVa, I need the next to pick chroma from YUVa and luma from YUVb.
CombinePlanes(YUVa,YUVa,YUVb,planes="UVY",source_planes="UVY")
I'm sure this is not an optimal way to merge planes. I don't know how ShufflePlanes work in VS but working in other programs you can mix everything (plane/channel independent) with everything like Shuffle in Nuke, Swizzle in Substance, etc

in http://avisynth.nl/index.php/CombinePlanes#Examples you can copy luma from first clip, U and V from the second

but you need the opposite, so maybe CombinePlanes need an update to accept arrays so it can be used as

CombinePlanes(YUVa,YUVb,planes="UVY",source_planes=[1, 2, 3]) # plane 0 is the 1st Y so we start from 1, plane 3 is the 2nd Y

or maybe update the present string cases so we can set it as source_planes="U1V1Y2"

or better both :) it's up to pinterf

[Dogway]

It's just an example. I might also want to merge UV from YUV and Luma from Y (depending on the prerequisites of the function needs), I know there's ExtractU() and ExtractV() but isn't that defeating the purpose of a combine planes function? Doing everything in one place might optimize some of these tasks.

[Mitra]

I compiled and installed AVS+Cuda and CUDAFilters without any problems, but when run this script:
FFMS2("s.ts")
onCUDA()
KTGMC()

gives this error:
This Avisynth does not support memory type 2 (CUDA)
(m.avs, line 2)
m.avs: Unknown error occurred

and with this:
FFMS2("s.ts")
KTGMC()
onCUDA()

gives this error:
Evaluate: Unhandled C++ exception!
(C:/Program Files (x86)/AviSynth+/plugins64+/KTGMC.avsi, line 451)
(m.avs, line 2)
m.avs: Unknown error occurred

and these are line 449~451 of KTGMC.avs :
449- bobbed = (InputType == 0) ? useEdiExt ? isyuy2(EdiExt) ? EdiExt.nonyuy2clipin(true) : EdiExt : planarClip.KTGMC_Bob( 0,0.5 ) : \
450- (InputType == 1) ? planarClip : \
451- planarClip.Blur( 0,1 )


i don't know how to solve the errors. :(

my machine : i7 10700k, GTX 1660, Nvidia driver 472.84 standard , Win 10

Please help me.

[Boulder]

There seems to be a problem with setting frame properties to a different clip than 'last'.

DGSource("whatever.dgi")
dbl=SmoothD2(quant=5, zw=1, ncpu=1).SmoothD2c(quant=5, zw=1, ncpu=1)
PropSet(dbl, "_Matrix", 1)
PropSet(dbl, "_Transfer", 1)
PropSet(dbl, "_Primaries", 1)
PropSet(dbl, "_ChromaLocation", 0)
PropSet(dbl, "_ColorRange", 1)
PropSet(dbl, "_FieldBased", 0)
propshow(last)

This script shows only the _FieldBased property even though the original clip has 11 keys.


EDIT: In fact, there's an issue without that external clip. If the 'last' clip has existing properties and you use PropSet to set some property, it deletes all the others. The possible subsequent PropSet calls don't do that, they just add keys.

[StainlessS]

Boulder,
I know nowt bout that there propset stuff, but check your intent that you show Propshow(last) and not Propshow(dbl) [maybe should be this]

[I dont see how setting properties of a filtered clip, can alter those of the source to the filtered clip, nor why that might be desirable]

EDIT: Indeed, if dbl plays no part in the output, does the propset stuff even do anything. [I've no idea ???]

EDIT: To below, OK B, was just checking that posted was as intended.

[Boulder]

That's just to replicate the issue. As SmoothD2 does not support passing the props through but deletes all, I have to put them back in to use the clip then in a different function. I was just debugging the problem and found out that something strange happens to the original clip props, which should be untouched in this case. Then later I notices that if I only change one property for the original clip, the rest get deleted.

[Boulder]

There might be other issues there regarding prop handling as well. I've tried testing Dogway's SmoothD2c function which uses frame props, and when refreshing the output in the script editor in VDub2 with F5, I often get errors complaining that the color range property cannot be found. It can be fixed only by actually reloading the script, and even then it sometimes fails. I'm not using Prefetch at this point to make sure it won't interfere.

[wonkey_monkey]

What's the proper way to get frame properties in C++? Information seems to be a bit scant, with most search results pointing back to this thread which has a few examples but some seem to be out of date. There's PVideoFrame's getProperties and getConstProperties, but I can't seem to assign them to local variables. Then there's env's getFramePropsRW and getFramePropsRO - I only want to read, but can't seem to use RO because I can't set it to a local variable (which will change on each frame) without a cast because the return value is a const...

Also... how long does an AVSMap(*) remain valid for? Should it be assumed to be invalid as soon as the PVideoFrame is destroyed? Is there a safe way to copy it elsewhere and store it more permanently, separate from its PVideoFrame?

[StvG]

There seems to be a problem with setting frame properties to a different clip than 'last'.

DGSource("whatever.dgi")
dbl=SmoothD2(quant=5, zw=1, ncpu=1).SmoothD2c(quant=5, zw=1, ncpu=1)
PropSet(dbl, "_Matrix", 1)
PropSet(dbl, "_Transfer", 1)
PropSet(dbl, "_Primaries", 1)
PropSet(dbl, "_ChromaLocation", 0)
PropSet(dbl, "_ColorRange", 1)
PropSet(dbl, "_FieldBased", 0)
propshow(last)

This script shows only the _FieldBased property even though the original clip has 11 keys.


EDIT: In fact, there's an issue without that external clip. If the 'last' clip has existing properties and you use PropSet to set some property, it deletes all the others. The possible subsequent PropSet calls don't do that, they just add keys.

You probably want DGSource("whatever.dgi")
dbl=SmoothD2(quant=5, zw=1, ncpu=1).SmoothD2c(quant=5, zw=1, ncpu=1)
PropSet(dbl, "_Matrix", 1) # this one becomes last
PropSet( "_Transfer", 1)
PropSet( "_Primaries", 1)
PropSet( "_ChromaLocation", 0)
PropSet( "_ColorRange", 1)
PropSet( "_FieldBased", 0)
propshow(last)

What's the proper way to get frame properties in C++? Information seems to be a bit scant, with most search results pointing back to this thread which has a few examples but some seem to be out of date. There's PVideoFrame's getProperties and getConstProperties, but I can't seem to assign them to local variables. Then there's env's getFramePropsRW and getFramePropsRO - I only want to read, but can't seem to use RO because I can't set it to a local variable (which will change on each frame) without a cast because the return value is a const...

Also... how long does an AVSMap(*) remain valid for? Should it be assumed to be invalid as soon as the PVideoFrame is destroyed? Is there a safe way to copy it elsewhere and store it more permanently, separate from its PVideoFrame?

Check here (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt#L1217). Search for frameprop in this doc because there are some new additions.

[StainlessS]

PropSet(dbl, "_Matrix", 1) # this one becomes last
shit, why did I not see that !
Nice one StvG,
you are the biz :)

[Boulder]

Nice catch! I considered propSet like a variable setting, which would not affect the selection of active clip :)

[Boulder]

There might be other issues there regarding prop handling as well. I've tried testing Dogway's SmoothD2c function which uses frame props, and when refreshing the output in the script editor in VDub2 with F5, I often get errors complaining that the color range property cannot be found. It can be fixed only by actually reloading the script, and even then it sometimes fails. I'm not using Prefetch at this point to make sure it won't interfere.

This one still remains.

DGSource("whatever.dgi")
dbl=SmoothD2(quant=5, zw=1, ncpu=1).SmoothD2c(quant=5, zw=1, ncpu=1)
dbl=propCopy(dbl, last)
return last

Refreshing a couple of times will bring up the error that _ColorRange is not set. It definitely should be since the source filter attaches them to the clip.

At least these are needed to test:
https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi
https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/DeblockPack.avsi
https://www.dropbox.com/s/ui8chlbzopuqs5a/SmoothD2-a3_x64.zip?dl=1

[StvG]

There might be other issues there regarding prop handling as well. I've tried testing Dogway's SmoothD2c function which uses frame props, and when refreshing the output in the script editor in VDub2 with F5, I often get errors complaining that the color range property cannot be found. It can be fixed only by actually reloading the script, and even then it sometimes fails. I'm not using Prefetch at this point to make sure it won't interfere.

This one still remains.

DGSource("whatever.dgi")
dbl=SmoothD2(quant=5, zw=1, ncpu=1).SmoothD2c(quant=5, zw=1, ncpu=1)
dbl=propCopy(dbl, last)
return last

Refreshing a couple of times will bring up the error that _ColorRange is not set. It definitely should be since the source filter attaches them to the clip.

At least these are needed to test:
https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi
https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/DeblockPack.avsi
https://www.dropbox.com/s/ui8chlbzopuqs5a/SmoothD2-a3_x64.zip?dl=1

ResizersPack.avsi is also needed.

I don't have issues with this script (only replaced DGSource with ffms2) when refreshing in AvsPmod.

Edit: The source didn't have _ColorRange prop. I can reproduce the issue after I set this prop.

[Shinkiro]

Video encoding very often hangs in a random place, it just stops and that's it. it looks like this https://disk.yandex.com/i/ab0R1-txImXnVw and when you restart the encoding, it may end successfully or hang in another place.
Now I have Avisynth 3.7.2_test3 codec x265-3.5-Mod-by-Patman-x64-gcc11.2.0
But I had it happen on older versions of Avisynth and x265

x265 "script - 01.avs" -o "video [BDRip 1080p].hevc" ^
--profile main10 --level-idc 4.1 --output-depth 10 ^
--crf 16.0 --bframes 16 --bframe-bias 0 --ref 4 --b-pyramid ^
--aq-mode 3 --aq-strength 0.85 --qcomp 0.70 --pbratio 1.20 --qp-adaptation-range 2 --qg-size 16 --qpmin 0 --qpmax 51 --qpstep 4 ^
--limit-modes --limit-refs 3 --open-gop --cbqpoffs -2 --crqpoffs -2 ^
--ctu 32 --max-tu-size 16 --tu-intra-depth 2 --tu-inter-depth 2 --limit-tu 4 ^
--vbv-maxrate 10000 --vbv-bufsize 10000 --vbv-init 1.0 ^
--rd 4 --dynamic-rd 2 --rdoq-level 2 --psy-rd 2.00 --psy-rdoq 5.00 ^
--b-adapt 2 ^
--min-keyint 24 --keyint 240 --subme 5 --rc-lookahead 80 --merange 44 --max-merge 4 --me star --wpp ^
--no-sao --no-sao-non-deblock --no-rect --no-amp --no-tskip --rskip 0 ^
--no-strong-intra-smoothing ^
--no-early-skip ^
--colorprim 1 --transfer 1 --colormatrix 1 --sar 1:1 --frame-threads 14 ^
--deblock 1:-1


setmemorymax(6144)
tr=2
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
DGSource("01-02.dgi")
Trim(42630,0)

F=last
A=last.TAAmbk(aatype=-1, preaa=1, postaa=false, sharp=0, mtype=0, cycle=2, dark=0.0)
mthr=34
mask=flatmask(2, scale=5, lo=4, MSR=40, invert=false).mt_lut("x "+string(mthr)+" <= x 1 >> x 1 << ?", U=1, V=1).RemoveGrain((980>960) ? 20 : 11, -1)
AA=TAAmbk(aatype=-1, preaa=1, postaa=false, sharp=0, mtype=5, cycle=1, dark=0.0)
ed=ex_merge(F, AA,mask, luma=true, Y=3, UV=3)

FilterMapB="[37889 39964]"
FilterLineB=ed
ReplaceFramesSimple(FilterLineB, mappings=FilterMapB)

F=last
mthr=44
mask1b=ex_edge("kirsch",6,10).ConvertToY()
mask2b=ex_edge("kirsch",4,7).ConvertToY()
mask=last.ConditionalFilter(mask1b, mask2b, "AverageLuma()",">","50").mt_lut("x "+string(mthr)+" <= x 1 >> x 1 << ?", U=1, V=1).RemoveGrain((980>960) ? 20 : 11, -1)

deg1 = last.SMDegrain(tr=2,thSAD=121, thSADC=50, thSCD1=156,thSCD2=96, contrasharp=false, refinemotion=true, chroma=true, plane=4)
deg2 = last.SMDegrain(tr=3,thSAD=321, thSADC=150, thSCD1=256,thSCD2=96, contrasharp=false, refinemotion=true, chroma=true, plane=4)
deg=last.ConditionalFilter(deg2, deg1, "AverageLuma()",">","50")
ex_merge(deg ,F ,mask, luma=true, Y=3, UV=3)

ConvertBits(bits=10)
neo_f3kdb(sample_mode=2, Y=68, Cb=68, Cr=68, grainy=54, grainC=40, range=15, dynamic_grain=true)
Prefetch(tr)

But this happens on different settings and scripts
I have found repeated complaints on the Internet about the same or very similar situations, but I have not found a single solution to this problem or at least a hint of which element is responsible for this problem. The codec, avisyth or some plugin is to blame for this, or perhaps something in the system?

[FranceBB]

But this happens on different settings and scripts
I have found repeated complaints on the Internet about the same or very similar situations, but I have not found a single solution to this problem or at least a hint of which element is responsible for this problem. The codec, avisyth or some plugin is to blame for this, or perhaps something in the system?

My bet is on avstp.dll
Delete it from your plugins folder and try again.

https://github.com/pinterf/mvtools/issues/46

[Shinkiro]

My bet is on avstp.dll
Delete it from your plugins folder and try again.

https://github.com/pinterf/mvtools/issues/46
Thank you! I'll try without it.

[wonkey_monkey]

I compiled AviSynth+ from source using Visual Studio 2019 which all went swimmingly well. But with my AviSynth.dll copied over the previously installed one, .avs files have lost their filetype icon.

How to fix?

[gispos]

Hello Ferenc,
if I initialize a clip in AvsPmod and display e.g. frame number 100, frame 0 is called 3 times and only then frame 100.

ScriptClip("""
WriteFile("E:\Temp\get_frame_test.txt", string(current_frame), append=true, flush=True)
return last
""")

result
0
0
0
100

How can this be? I have gone through all the relevant AvsPmod code and cannot find a call to frame 0 anywhere.

Does avisynth itself call frame number 0 on various queries such as get_video_info or get_pixel_info or get_color_type or the like?
Matrix and properties reading I have deactivated.

[gispos]

I compiled AviSynth+ from source using Visual Studio 2019 which all went swimmingly well. But with my AviSynth.dll copied over the previously installed one, .avs files have lost their filetype icon.

How to fix?
Nirsoft has very useful freeware.
With FileTypesMan you can also set the file icons. In FileTypesMan left file menu A double click on the avs file opens a context menu with the options. You can also create new explorer entries with which program you want to open the avs.

https://www.nirsoft.net/utils/file_types_manager.html

https://i.postimg.cc/rRVBmNYP/Spnap-Shot.jpg (https://postimg.cc/rRVBmNYP)

[wonkey_monkey]

Sorry, I meant how to fix as in how to add the icon to the DLL, so if anyone wanted to try my DLL they wouldn't lose their icons.

With regard to your frame 0 problem, I had a look through the source code but couldn't find many places where AviSynth gets frame 0, but ConvertToRGB is one of them. Are you invoking that for display?

[gispos]

Sorry, I meant how to fix as in how to add the icon to the DLL, so if anyone wanted to try my DLL they wouldn't lose their icons.

Ok, but it is still worth taking a look at the tools offered there.

...but ConvertToRGB is one of them. Are you invoking that for display?
Yes.

real.finder makes trouble :)
https://forum.doom9.org/showthread.php?p=1964292#post1964292

I compared an older avisynth version with the latest version. There is different behavior when initializing a clip or using the preview filter.

Initialize clip or turn preview filter on or preview filter change a parameter in Levels() on frame 240
Avisynth 2772 MT

240
240
240

AvsPmod makes 1 call on frame 240 and avisynth makes 2 more calls on frame 240

Avisynth 3.72 test 3

0
0
0
240

I see AvsPmod makes 1 call on frame 240 but avisynth makes 3 more calls on frame 0
But I don't know what triggers these 3 additional calls to frame 0.
get_video_info, eval a clip, converttorgb32, set or read global variable ?

I think when avisynth makes internal calls to a frame, that should not be forwarded. WriteFile should not know about it.

With the old avisynth the 3 calls on frame 240 are much easier to clean up than with the 3 calls on frame 0

global last_frame = -1
/**avsp_filter
Levels(0, 1.00, 172, 0, 255, coring=true)
ScriptClip("""
if (last_frame != current_frame){
WriteFile("E:\Temp\get_frame_test.txt", string(current_frame), append=true, flush=True)
}
global last_frame = current_frame
return last
""")
**/

[Nuihc88]

0
0
0
240
I suspect that i have been occasionally running into this same behavior while using newer AviSynth+ test builds for realtime playback with CrendKing's DirectShow AviSynth Filter.
Older frames sometimes flicker on screen while seeking as the Script-environment is reinitializing. EDIT: I used to see same sort of behavior a lot years ago with SEt's AviSynth MT & ffdshow combo, except it was way worse then.
Possibly triggered in CrendKing's filter by this prefetching hang workaround (https://github.com/CrendKing/avisynth_filter/commit/07be726624633a85b2e58c79eb6d6d2c94810ae7), but i'm not sure as the issue only surfaced some time after i started using 3.7.2 test builds.

EDIT: This is my guess as to what is going on here:
1. during initialization current_frame = 0 in AviSynth+ cache?
2. prefetchers don't get cleared when closing and opening script clips?
3. current_frame doesn't get separate instances (unique identifiers) while calling for frame or clip info?
4. current_frame doesn't get cleared from cache when closing and opening Script-environments?

[gispos]

real.finder makes trouble :)
https://forum.doom9.org/showthread.php?p=1964292#post1964292

I compared an older avisynth version with the latest version. There is different behavior when initializing a clip or using the preview filter.

Initialize clip or turn preview filter on or preview filter change a parameter in Levels() on frame 240
Avisynth 2772 MT

240
240
240

AvsPmod makes 1 call on frame 240 and avisynth makes 2 more calls on frame 240

Avisynth 3.72 test 3

0
0
0
240


To be honest, I don't care, I don't need this, should those who need it continue to take care of it...
I only showed the incorrect behavior because I was forced to do so.

[StvG]

Hello Ferenc,
if I initialize a clip in AvsPmod and display e.g. frame number 100, frame 0 is called 3 times and only then frame 100.

ScriptClip("""
WriteFile("E:\Temp\get_frame_test.txt", string(current_frame), append=true, flush=True)
return last
""")

result
0
0
0
100

How can this be? I have gone through all the relevant AvsPmod code and cannot find a call to frame 0 anywhere.

Does avisynth itself call frame number 0 on various queries such as get_video_info or get_pixel_info or get_color_type or the like?
Matrix and properties reading I have deactivated.

Btw there is similar issue - https://github.com/AviSynth/AviSynthPlus/issues/210

[Kogarou]

One big advantage Vapoursynth has had for the last few years is nnedi3cl, which is one of the few old plugins re-written for vs without a port-back, and NNEDI3 is one of the backbones of filtering.
Is there anyone capable of porting nnedi3cl back to AVS+? I have tried but I'm not skilled enough with either SDKs to do it :(

[kedautinh12]

One big advantage Vapoursynth has had for the last few years is nnedi3cl, which is one of the few old plugins re-written for vs without a port-back, and NNEDI3 is one of the backbones of filtering.
Is there anyone capable of porting nnedi3cl back to AVS+? I have tried but I'm not skilled enough with either SDKs to do it :(

You can ask him a question with create new issue :D
https://github.com/Asd-g/AviSynthPlus-Scripts/issues

[qyot27]

Just musing, but for filters like nnedi and its offspring, I wonder how much of a difference it would make in performance being run on something with dedicated AI cores - the M1, for example. Granted, that would be an even heavier porting effort since you'd probably have to completely redesign the dispatcher to make sure it's using the Neural Engine rather than the CPU or the OpenCL features of the GPU, but still.

[wonkey_monkey]

Purely out of curiousity: why does ColorBarsHD generate a 1288x720 clip instead of 1280x720?

[FranceBB]

Purely out of curiousity: why does ColorBarsHD generate a 1288x720 clip instead of 1280x720?

Uhm if it was 1920x1088 I would have said that it was because of the inactive lines that are generally there in terrestrial signals etc anyway, but since it 1288x720 I have no idea.

[LigH]

May there be a mistake in the "pitch" interpretation?

[pinterf]

Hello Ferenc,
if I initialize a clip in AvsPmod and display e.g. frame number 100, frame 0 is called 3 times and only then frame 100.

ScriptClip("""
WriteFile("E:\Temp\get_frame_test.txt", string(current_frame), append=true, flush=True)
return last
""")

result
0
0
0
100

How can this be? I have gone through all the relevant AvsPmod code and cannot find a call to frame 0 anywhere.

Does avisynth itself call frame number 0 on various queries such as get_video_info or get_pixel_info or get_color_type or the like?
Matrix and properties reading I have deactivated.
When clip properties are needed then yes, there is a GetFrame(0) in such filters' constructor, e.g. in resizers, 444<->420 or <->rgb converters.

[FranceBB]

Is it gonna be the same if I use propclearall() after indexing? Is it still gonna call frame 0, find out that it holds nothing and move on or is it gonna behave like the old Avisynth and just call frame X?

[pinterf]

Purely out of curiousity: why does ColorBarsHD generate a 1288x720 clip instead of 1280x720?
I guess because it is divisible by 7 and allows of drawing perfectly spaced bar sections.

[Dogway]

I think green bar luma value is wrong in the wiki of ColorBarsHD. It should read 133 (currently 134), I had to double check with the original paper. Its full range value also has to be fixed.

I also had the chance to benchmark Expr() lut. I get slower performance (~7%) when using it instead of real time calculations.
ConvertBits(14)
expr(last,last,"f32 x y atan2 0.5 * x +", lut=2, scale_inputs="int")
expr(last,last,"f32 x y atan2 0.5 * x +", lut=2, scale_inputs="int")
expr(last,last,"f32 x y atan2 0.5 * x +", lut=2, scale_inputs="int")
Prefetch(6)

Unrelated, but as I understand it scale_inputs has no effect with LUT mode right? It's always dependent on input bitdepth (and input variables).

[pinterf]

Thanks pinterf! Could you take a look at this (https://forum.doom9.org/showthread.php?p=1960946#post1960946)? Not sure if that's to be expected but I run a few tests and got consistent performance readings.
Here's another example, again 2% with prefetch(4), with prefetch(6) performance is worse and inconsistent.
expr("x[-1,-1] x[0,-1] x[1,-1] x[-1,0] x[0,0] x[1,0] x[-1,1] x[0,1] x[1,1] + + + + + + + + 0.111111111 *") # P(6) ~360 P(4) 389
#expr("x[1,1] x[0,1] x[-1,1] x[1,0] x[0,0] x[-1,0] x[1,-1] x[0,-1] x[-1,-1] + + + + + + + + 0.111111111 *") # P(6) ~360 P(4) 381
I think it depends on how processor's memory data line prefetch works, L1/L2/L3 cache memory utilization and timing issues affect the performance seriously. The more thread you are using the larger likelihood that a processed part will be kicked out from the cache, thus the bottleneck of parallel processing will be not the processor itself but the memory speed.

Forum member DTL is using an interesting Intel tool with which one can analyze such metrics, cache hits, misses, unaligned access, etc... Art of fine tuning.

https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top/analyze-performance/microarchitecture-analysis-group/memory-access-analysis/memory-usage-view.html

But I'm sure that what you'd find optimal for one processor arhitecture, an older or a much newer one will not necessarily benefit from that.

[pinterf]

I think green bar luma value is wrong in the wiki of ColorBarsHD. It should read 133 (currently 134), I had to double check with the original paper. Its full range value also has to be fixed.

I also had the chance to benchmark Expr() lut. I get slower performance (~7%) when using it instead of real time calculations.
ConvertBits(14)
expr(last,last,"f32 x y atan2 0.5 * x +", lut=2, scale_inputs="int")
expr(last,last,"f32 x y atan2 0.5 * x +", lut=2, scale_inputs="int")
expr(last,last,"f32 x y atan2 0.5 * x +", lut=2, scale_inputs="int")
Prefetch(6)

Unrelated, but as I understand it scale_inputs has no effect with LUT mode right? It's always dependent on input bitdepth (and input variables).

A 14 bit lutxy needs a 0.5 GBytes LUT table. Probably this is too much to keep all of it in a fast cache memory.
When you decrease the bit depth to 12 and 10 bits, it would act quicker.
But LUT it is still going pixel-by-pixel, while Expr can translate 32 pixels at a time. We wish that the optimum - which to use, lut or Expr - would be guessed before use.