Avisynth+

[qyot27]

avs-plus.net was just simply not updated much after a couple years. Even ultim released newer versions than r1576 (from the MT branch). pinterf's repo and releases are the current development HEAD, yes, and it is not a fork.

[Nico8583]

Thank you, so it's better to install pinterf's releases (like r2772) ?

[StainlessS]

Yes, nobody should be using r1576, unfortunately Pinterf dont have control over the first post of this thread.

[Nico8583]

Thank you ;) I try it.

[Groucho2004]

Yes, nobody should be using r1576, unfortunately Pinterf dont have control over the first post of this thread.
Time for a new thread or a moderator to update the first post. I think the latter is a better option.

[StainlessS]

Moderator update of 1st post would be repeatedly required, (and the mods are so busy as is),
Pinterf has been deliberating whether or not to open new thread (since before XMAS I think),
Guess we just have to wait for the black smoke or the white smoke, to signal a decision.

[Groucho2004]

Moderator update of 1st post would be repeatedly requiredTrue, didn't consider that. So, a new thread then.

[FranceBB]

Moderator update of 1st post would be repeatedly required, (and the mods are so busy as is),
Pinterf has been deliberating whether or not to open new thread (since before XMAS I think),
Guess we just have to wait for the black smoke or the white smoke, to signal a decision.

Yep. Unfortunately this whole thing is very confusing, 'cause most of the people who don't actually follow Doom9 end up installing the Legacy Avisynth 2.6.1 or worse, the old version of Avisynth+, thus getting compatibility issues and facing regressions without knowing why.
I wasn't very keen to move from Avisynth 2.6.1 myself even though I do follow Doom9 and I post here quite often, only 'cause everywhere else people were commenting about the stability issues and other severe bugs and I was so afraid to break my workflow that I kept Avisynth 2.6.1 'till 2017. (Stainless probably remembers the posts about my concerns).
As a matter of fact, later on, in 2017, I found out that all these "rumors" were about the "old" Avisynth+, not the (at the time current) branch maintained by Ferenc. In fact, when I switched, it not only was faster, but it also fixed some pretty particular "bugs" (more like inconsistencies to be fair) that the legacy Avisynth had and it even allowed me to finally ditch 16bit stacked/interleaved in favor of a real 16bit, it allowed me to apply LUTs, to tone-map and to do many other things that were just not possible with the legacy Avisynth.
In a nutshell, from my experience, I think that many people are misguided and end up installing the wrong/old version of Avisynth/Avisynth+ due to the lack of proper and clear documentation, which is a shame, really, for the community, so I'm totally in favor of starting a new topic and perhaps updating the Wiki and make it clear that the Ferenc's version is the only one that is still developed and that it should really be the only one to be used.

[Dogway]

Fix according, I have no clue what scale_inputs does.

Edit:Updated code in next page.

[Groucho2004]

I have no clue what scale_inputs does.
http://avisynth.nl/index.php/Expr

[tebasuna51]

Time for a new thread or a moderator to update the first post. I think the latter is a better option.

My EDIT in first post have a link to last pinterf version (Avisynth+ r2772-MT) and to first post than begin with pinterf avs+ discussion.

I can't do anything more. I think is better a new thread by pinterf.

[videoh]

You done good, tebasuna51. Thank you.

[Dogway]

http://avisynth.nl/index.php/Expr

In fear of repeating myself...
I have no clue what scale_inputs does. ?

[pinterf]

In fear of repeating myself...
?
Use it when you don't want to bother with the different bit-depths within your Expr script. Depending on your choice, the Expr expression will always see your input clip to be 8 (or other bit depth, fine tuned with the i8, i10, etc Expr keywords)

The parameter helps converting old 8-bit-only Expr (or mt_lutxxx family) expression strings to a generic good-for-all-bit-depth string.

Since there is an automatic input conversion phase (e.g. pixel values of a 10 bit input clip will be divided by 4.0 to have them in the 8 bit range), then a back-conversion phase (result will be multiplied by 4.0 before converting the intermediate pixel result back to 10 bit integer). Using this method Expr itself is a little bit slower, but the conversion takes place only when the input bit-depth is different from the bit-depth used in Expr.

[pinterf]

Regarding the new thread, yeah, I'll start it, promise, unfortunately my draftsman is on holiday :), I wanted to write a proper intro w/o mis-spelling.
Anyway it's time for a new release but I found way too many other tasks and coding adventures for myself, so it's just a question of weeks.

[Dogway]

Thanks pinterf, I think I got it.

Float style code only works with 32bit float videos, but integer style code works with everything, unless you have uknown bitdepth variables (float, integers, clips) in which case you can use the scale_inputs setting to bring them to a common denominator (8-bit).

This is my Expr version of mt_merge(), if you pinpoint something odd or not optimized please correct me. (not working with 32bit float)


function expr_merge ( clip a, clip b, clip msk, bool "luma", string "scale_inputs") {

luma = Default(luma, true)
scale_inputs = Default(scale_inputs, "all")

luma ? Eval("""
msk
w = Width()
h = Height()
Y = ConvertToY8()
U = Y.BicubicResize(W/2,H/2,-.5,.25, src_left=0.25 - (0.25/w))
V = U
msk=CombinePlanes(Y, U, V, planes = "YUV", sample_clip=msk)""") : nop()

code="x z range_max - abs * y z * + range_size / "
expr(a,b,msk,code,code,code, scale_inputs=scale_inputs) }

[pinterf]

1.) You can omit abs by exchanging range_max and z in your script
(x * (range_max - z) + y * z) / range_max

(Expr uses 32 bit floats internally, regardless of the input pixel bit depth, so 255 becomes 255.0 and this floating point number is used until at the end the result is automatically rounded and converted back to integer (for 8-16 bit clips).
But in actual integer pixel-type implementations like in mt_merge or Avisynth Overlay there are simplifications:

(x * range_max - x * z + y * z) / range_max -->
x + (y - x) * z / range_max

is used, this is one less multiplication. But in real life it's a bit more difficult, as masks are stretching from 0..255 (8 bits example). E.g. for 8 bits division by range_max is replaced by division by 256 which is an easy right-bit-shift-8. In exchange the mask extremes (255) have to be treated specially: for maximum mask value we are returning always y. The * 255 right-shift-8 will not work properly for all input combinations.

-- end of popular science :) -- )

2.) You can write code, code, code as code: when an expression is not given for a plane plane, it will be copied from the previous one.

[ChaosKing]

Thanks to Asd there is now a 64-bit VariableBlur v0.7 (among other plugins). See http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

Source code(s) available here: http://avisynth.nl/index.php/User_talk:Asd

I have put it on github https://github.com/avisynth-repository/VariableBlur

[real.finder]

This is my Expr version of mt_merge(), if you pinpoint something odd or not optimized please correct me. (not working with 32bit float)


function expr_merge ( clip a, clip b, clip msk, bool "luma", string "scale_inputs") {

luma = Default(luma, true)
scale_inputs = Default(scale_inputs, "all")

luma ? Eval("""
msk
w = Width()
h = Height()
Y = ConvertToY8()
U = Y.BicubicResize(W/2,H/2,-.5,.25, src_left=0.25 - (0.25/w))
V = U
msk=CombinePlanes(Y, U, V, planes = "YUV", sample_clip=msk)""") : nop()

code="x z range_max - abs * y z * + range_size / "
expr(a,b,msk,code,code,code, scale_inputs=scale_inputs) }

why you made merge function? if it because this old bug (https://github.com/tp7/masktools/issues/12) then pinterf already fix (https://github.com/pinterf/masktools/commit/ad143a5693882c6c827dd4ff8dbfe29de843dcb2) it

and there are already MasknotCL, MaskCL and my https://pastebin.com/aLP9Mb3z and all these in avs26 nowadays is useless since the bug fixed, unless you use avs 2.5

[Dogway]

The goal was that if someone wanted to keep a 32f bit process chain they could saving on quantization processing time and error accumulation (bitdepth down conversion) on the usual heavy filtering done in the scripts, but without removing the support for integer type bitdepths. Float precision is also benefitial for less degradation in dark images or parts of them.

I understand this is currently not possible due to the right-shift mechanism (discrepancies in masks), unless we get an official expr_merge with said optimizations. For now I will apply your suggestions (a ternary op in masks) until we get an internal function. I haven't cared for cosmetics yet.

Edit: @real.finder, because I asked a few days ago about an internal equivalent of mt_merge and nobody replied, so assumed there were none (long time out of touch) . Your script does the job perfectly although with a dependency. I will spend my time on my other tools.

Edit2: After testing smaskmerge() also didn't work for 32bit so I adapted mine and now is bitdepth agnostic.

[real.finder]

Edit: @real.finder, because I asked a few days ago about an internal equivalent of mt_merge and nobody replied, so assumed there were none (long time out of touch) . Your script does the job perfectly although with a dependency. I will spend my time on my other tools.

Edit2: After testing smaskmerge() also didn't work for 32bit so I adapted mine and now is bitdepth agnostic.

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

and

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

and

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

the formula seems work fine even in float, what you mean by "didn't work for 32bit"?

[Dogway]

Test with this, as pinterf explained a hack is needed when mask is range_max in float precision. I also had to remove the try catch for cl_exprxyz() in smaskmerge.avsi since it was triggering an error in the script.

16-bit integer__________32-bit float
http://i.imgur.com/aYEak4Ut.png (https://imgur.com/aYEak4U) http://i.imgur.com/vbpzRQnt.png (https://imgur.com/vbpzRQn)

blankclip(length=48,width=720,height=480, color=$00000,pixel_type="YV12")
expr("sx frameno + 32 % 16 < range_half range_max ?","sx frameno 2 / + 16 % 8 < range_half sx 15 / - range_half ?","sx frameno 2 / + 16 % 8 < range_half sx 8 / - range_half ?")

ConvertBits(32) # 32bit float vs 8-16bit integer

video=last
video2=video.trim(20,0)

x1=string(20)
x2=string(600)
y1=string(50)
y2=string(340)
msk=expr("sx "+x1+" >= sx "+x2+" <= & sy "+y1+" >= sy "+y2+" <= & & range_max range_min ?", "range_half", "range_half").trim(0,-1).FreezeFrame(0, FrameCount(last)-1, 0)

##########################

smaskmerge(video, video2, msk,3,3,3, luma=true)

ConvertBits(8)

# Debug Chroma planes
# ExtractU()

[real.finder]

so the problem only in chroma? I think this because the zero-chroma-center transition, don't know how chroma mask in float should be, let see what pinterf said and how it work in mt_edge and mt_merge

[pinterf]

Without reverse engineering the Expr itself, yep, float chroma goes -from 0.5 to 0.5, sometimes it can be tricky to apply on it a universal Expr. Perhaps with "range_size"? Anyway, masks are just weights going from 0 to 1.0.

[real.finder]

Without reverse engineering the Expr itself, yep, float chroma goes from -0.5 to 0.5, sometimes it can be tricky to apply on it a universal Expr. Perhaps with "range_size"? Anyway, masks are just weights going from 0 to 1.0.

in this case range_size not suitable for non-float, in 8 bit will be 256 not 255

maybe temporary shifting to 0-1.0 for float chroma if there are only universal (luma) Expr available? or with some parameter to set that

same for masktools lut things

[LouieChuckyMerry]

Hello, and thanks in advance for any help. About five years ago, kind, patient people here and elsewhere helped me develop a quite nice basic template for shriveling and improving my Blu-rays with 10-bit x264 using MeGUI with SEt's MT AviSynth. I'm still using MeGUI, but I've recently upgraded to pinterf's AviSynth+ and am wanting to verify that I've translated my template correctly.

The original SEt AviSynth MT template is:

SetMemoryMax(XXXX)
SetMTMode(X,X)
SOURCE INFORMATION HERE
SetMTMode(X)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3("Settings Depend On Source",LSB_In=True,LSB=True)
### Preview Source OR Send 16-bit Output To x264 10-bit ###
# DitherPost()
Dither_Out()

with the x264 custom command line:

--demuxer raw --input-depth 16 --sar 1:1

while my current pinterf AviSynth+ template, with the same above x264 custom command line, is:

SOURCE INFORMATION HERE
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3("Settings Depend On Source",LSB_In=True,LSB=True)
ConvertFromStacked
ConvertBits(10,Dither=0)
Prefetch(X)

which outputs normal-looking 10-bit video at ~15% higher frames per second than the SEt AviSynth MT script. Thanks pinterf :) .

Anyway, I just want to make sure that all is well before I attack further encoding. I'm using the newest .dll's-.avsi's I could find: pinterf's dual signature MaskTools2.2.18.dll, pinterf's MVTools2.7.41.dll, Dither1.27.2.avsi, SMDegrain3.1.2.93s.avsi.

And some questions:

0) Is the new AviSynth+ template truly processing in 16-bits from the beginning to the output?

1) Is the "ConvertBits(10,Dither=0")" call necessary given that I'm sending 16-bit to 10-bit x264; ie, would removing this cause a lack of proper dithering?

2) Is the:

F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)

block proper for AviSynth+? Or can it be improved?

3) What have I missed?

Thanks again for any help; I really appreciate it :) .

[LouieChuckyMerry]

As I was checking some test clips, I noticed that very rarely there's an error message from, I think, AviSynth+ superimposed across the top, center of single frames:

Script error: Invalid arguments to function 'IsCombedTIVTC'
([ScriptClip], line 1)

Here's a couple screenshots: S1.E1-Simpsons[NTSC]-AviSynth+ErrorMessages (http://www.mediafire.com/file/7q5sflbj55vnj26/S1.E1-Simpsons[NTSC]-AviSynth%2BErrorMessages.7z). Is there any way to stop this happening (other than not creating script errors ;) )? The script runs fine otherwise (I've used it successfully in the past with SEt's AviSynth MT and this never happened). Also, if anyone would answer my questions above from 7 May about syntax I'd be very thankful for the help :) .

EDIT: Turns out that adding "PreFetch(X)" to the end of a script for encoding interlaced video improves speed but causes errors. Sorry for the bother; a more detailed explanation is in the MeGUI: General Questions and Troubleshooting Thread (https://forum.doom9.org/showthread.php?p=1874620#post1874620).

[stax76]

ConvertBits(10,Dither=0)

This outputs 10 bit, you can certainly serve 16 bit to x265, I don't know which way is better.

[LouieChuckyMerry]

ConvertBits(10,Dither=0)

This outputs 10 bit, you can certainly serve 16 bit to x265, I don't know which way is better.

Thanks, stax76. Can you explain the difference between:

ConvertFromStacked.ConvertBits(10,Dither=0)

and

ConvertFromStacked

given the script? That is, does the first line dither the raw 16-bit to 10-bit then send this 10-bit output to x264 10-bit while the second would send raw 16-bit to x264 ten bit? More importantly, I guess, is there a difference in quality? Seems silly to me to dither then serve instead of just serving the 16-bit to x264 10-bit, if that's the case.

[Motenai Yoda]

If wasn't fixed, x265's --dither doesn't work other than for 8bit output, without --dither it'll do a truncate.
for x264 it should work well as it apply a sierra dithering iirc

[stax76]

Is it possible to fully automate ConvertFromDoubleWidth meaning calling it only when it is double width. When the aspect ratio is > 3.5 then it is very likely double width and that's good enough for me, my problem is I don't know what to use as bits argument, how do I know if it is 10 or 16 bit?

[DJATOM]

Isn't it better to write a patch for lsmashsource plugin and don't rely on vague heuristics?

[stax76]

It's better sure but if it was trivial somebody would have already done it. :)

[DJATOM]

It looks trivial for me, but I don't have much time to spend for coding. I'm working everyday from December.

[tyee]

Just a quick question - I am finally upgrading to avisynth+ and have done it manually and it seems to be working fine but I am wondering a couple of things -

1. I copied the 2 avisynth.dll's in my 64 bit system to the required windows folders
2. I updated the registry with the new location of my "plugins+" folder. My old folder seems to be used if I rename this new folder, which is correct according to the docs although the 2 registry entries that my original avisynth is supposed to use do not exist!
3. In my new "avisynth+" folder I have copied the two folders that came in the zipfile, these are "c_api" and "system" and the files within. "c_api" folder has "avisynth.lib" and "avisynth.exp". Is this where they should be left?

Everything seems to work ok. I can load a video and one filter I added does work.

Oh, one last question - Do I have to use any MT commands in my scripts like in the older version? I'm using pinterf's avisynth+.

Update on MT - OK, found the info on MT and it's commands. Just tried it and I see no speed increase using Prefetch(4).

[ChaosKing]

Just a quick question - I am finally upgrading to avisynth+ and have done it manually and it seems to be working fine but I am wondering a couple of things -

1. I copied the 2 avisynth.dll's in my 64 bit system to the required windows folders
2. I updated the registry with the new location of my "plugins+" folder. My old folder seems to be used if I rename this new folder, which is correct according to the docs although the 2 registry entries that my original avisynth is supposed to use do not exist!
3. In my new "avisynth+" folder I have copied the two folders that came in the zipfile, these are "c_api" and "system" and the files within. "c_api" folder has "avisynth.lib" and "avisynth.exp". Is this where they should be left?

Everything seems to work ok. I can load a video and one filter I added does work.

Oh, one last question - Do I have to use any MT commands in my scripts like in the older version? I'm using pinterf's avisynth+.

Update on MT - OK, found the info on MT and it's commands. Just tried it and I see no speed increase using Prefetch(4).

3. you don't need these files. There is a "Universal Avisynth Installer" https://forum.doom9.org/showthread.php?t=172124 which does all the work for you. You just need to set the path in the bat file.

[MysteryX]

Pinterf, just pointing out this line
https://github.com/pinterf/AviSynthPlus/blob/08146c9edd19bfb7980ff61d1c000c4194c8589a/avs_core/filters/fps.cpp#L655

// :FIXME: Use fast plane blend routine from Merge here

[pinterf]

Pinterf, just pointing out this line
https://github.com/pinterf/AviSynthPlus/blob/08146c9edd19bfb7980ff61d1c000c4194c8589a/avs_core/filters/fps.cpp#L655

// :FIXME: Use fast plane blend routine from Merge here

Done already
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/fps.cpp#L671
Up to avx2

[MysteryX]

dammit I was using the wrong source code. I always have a hard time finding the right source code version.

I'm looking at ConvertFps code. Why is it that when I debug the code and step frame by frame, in ConvertFPS::GetFrame, mix_ratio is always 1023 (out of 1024) and thus doesn't perform any blend? Then if I seek elsewhere in the file then it starts blending with other ratios.

Really something looks wrong. If I debug and put a breakpoint right after discarding based on threshold, and I play the video, blending doesn't get triggered at all because all frames have ratio of 1023!?? Then if I seek, it's a different ratio but all the frames will have that same ratio until I seek again. I'm using your version now, but something doesn't look right.

That's debugging a copy of your code I made into my project; so it's possible something got broken during copy too.

EDIT:
Never mind my source video was already a 60fps!!!

[MysteryX]

Oh. Interesting. Pinterf, your new code for ConvertFps calculates mix_ratio and mix_ratio_f but never uses them!! Thus altering those variables shows no difference whatsoever!

Seems like the function is only capable of doing a 50/50 blend?

Edit: it's using frac_f instead of mix_ratio; but then it's ignoring the threshold calculation.

[pinterf]

Edit: it's using frac_f instead of mix_ratio; but then it's ignoring the threshold calculation.
Thanks I'm gonna check it soon.

[pinterf]

Oh. Interesting. Pinterf, your new code for ConvertFps calculates mix_ratio and mix_ratio_f but never uses them!! Thus altering those variables shows no difference whatsoever!

Seems like the function is only capable of doing a 50/50 blend?

Edit: it's using frac_f instead of mix_ratio; but then it's ignoring the threshold calculation.
No problem there, in this section mix_ratio is used for threshold comparison, but the frac_f holds the real blending weight of the two neightbouring frames. Anyway, I have deleted some unused variables to make it a bit clearer.

[wonkey_monkey]

I'm writing a C++ program that creates its own Avisynth environment. When I compile it, I get:

error LNK2001: unresolved external symbol "struct AVS_Linkage const * const AVS_linkage" (?AVS_linkage@@3PEBUAVS_Linkage@@EB)

That goes away if I add:

#define AVS_LINKAGE_DLLIMPORT

which is what I used to do in my old plugins. Nowadays, in my plugins, I do:

const AVS_Linkage *AVS_linkage = 0;

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
AVS_linkage = vectors;
...

but I don't know how to, or if I should, translate this to my standalone C++ program. So - since I have no idea what this vectors thing is about - what's the right thing to do?

[Groucho2004]

I'm writing a C++ program that creates its own Avisynth environment. When I compile it, I get:

error LNK2001: unresolved external symbol "struct AVS_Linkage const * const AVS_linkage" (?AVS_linkage@@3PEBUAVS_Linkage@@EB)

That goes away if I add:

#define AVS_LINKAGE_DLLIMPORT

which is what I used to do in my old plugins. Nowadays, in my plugins, I do:

const AVS_Linkage *AVS_linkage = 0;

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
AVS_linkage = vectors;
...

but I don't know how to, or if I should, translate this to my standalone C++ program. So - since I have no idea what this vectors thing is about - what's the right thing to do?
Have a look at my avsr (https://forum.doom9.org/showthread.php?t=173259) code, "avsr.cpp" in particular.
It basically boils down to this:
//global defs
const AVS_Linkage *AVS_linkage = 0;
typedef IScriptEnvironment * __stdcall CREATE_ENV(int);

HINSTANCE hDLL;
hDLL = ::LoadLibrary("avisynth");

if (!hDLL)
{
//Error handling
return;
}

int iInterfaceVersion;
IScriptEnvironment *AVS_env = 0;

try
{
CREATE_ENV *CreateEnvironment = (CREATE_ENV *)GetProcAddress(hDLL, "CreateScriptEnvironment");
if (!CreateEnvironment)
{
::FreeLibrary(hDLL);
//Error handling
return;
}

iInterfaceVersion = 6;
while (!AVS_env)
{
if (iInterfaceVersion < 5)
{
::FreeLibrary(hDLL);
//Error handling
return;
}

AVS_env = CreateEnvironment(iInterfaceVersion);
iInterfaceVersion--;
}

AVS_linkage = AVS_env->GetAVSLinkage();

//do your stuff
...


//important!
AVS_env->DeleteScriptEnvironment();
AVS_env = 0;
AVS_linkage = 0;
}
catch (AvisynthError err)
{
//Error handling
}
catch (other error handling mechanisms)
{
//Error handling
}

::FreeLibrary(hDLL);

[MysteryX]

No problem there, in this section mix_ratio is used for threshold comparison, but the frac_f holds the real blending weight of the two neightbouring frames. Anyway, I have deleted some unused variables to make it a bit clearer.
Why isn't it calculating the threshold on the same frac_f directly?

[wonkey_monkey]

Have a look at my avsr (https://forum.doom9.org/showthread.php?t=173259) code, "avsr.cpp" in particular.
It basically boils down to this:


That's a lot of stuff! What am I missing out on if I just use #define AVS_LINKAGE_DLLIMPORT intead?

[Groucho2004]

That's a lot of stuff! What am I missing out on if I just use #define AVS_LINKAGE_DLLIMPORT intead?Don't know, never tried it. I developed this initialisation over the years, some bits are courtesy of IanB's suggestions. It's not a lot of stuff, it's the bare minimum. :p

What is your program supposed to do?

Edit: A couple of examples can also be found on avisynth.nl:
http://avisynth.nl/index.php/Filter_SDK/avs2yuv
http://avisynth.nl/index.php/Filter_SDK/avs2pcm

[MysteryX]

Hey Pinterf, I just realized that if any AVS script is running and auto-loading plugins, even if it's not using them, it's locking all those files on the hard drive. There's probably a better way of doing that.

[StainlessS]

What if eg Scriptclip() on occasion [EDIT: not every frame] uses a function/filter, you dont 100% for sure know that its never gonna use it.
[ EDIT: or do you ? - same situation with plugin, where defo cant be sure ED: or can you ? ]

Best leave alone, let user decide what he/she/it is gonna lock-n'-load.

[MysteryX]

What if eg Scriptclip() on occasion [EDIT: not every frame] uses a function/filter, you dont 100% for sure know that its never gonna use it.
[ EDIT: or do you ? - same situation with plugin, where defo cant be sure ED: or can you ? ]
No problem.
1. Do a discovery of all DLLs and what's in them
2. Once the script is loaded and started rendering, unload everything that is not in use
NOTE: We still know what functions are available and where
3. If a function is later called that is unloaded, load it.

Otherwise, while we have any script playing that uses auto-loading, we cannot update any dll files.