Avisynth Memory allocation

[may24]

Hi all,

can someone share me a few insights on how Avisynth (not the plus version) handles memory allocation.

For instance: If I write a .avs script hat opens two 1080p video files (AVC) and each one gets its own variable, I suspect avisynth will allocate memory for both making it accessible via the variables.
Also I assume that this references will be available due script has finished execution.
Or is there kind of an "deconstructor" to explicitly free memory ?

Now, what if I re-assign an new Video file to the same variable ? Will the "old" allocation be dropped and a new be made ?

I've read that Plugins (such as external decoders: ffmpeg-source, lsmash ect) do their own memory management.

So in the end it seems quite impossible to guess how much memory your script will allocate until you open it and check with a task manager ... and even that seems to be fairly correct as tailing functions, scripts or plugins will add to this number making it quite unpredictable (think of de-interlacers).

Or do I miss anything here ?
Can you give me an insight on how avs memory management works

[feisty2]

However it works, does it matter??

[amayra]

this will take more time than you think if you cant understanding source code of Avisynth so... I suggest you to try AVSMeter (http://forum.doom9.org/showthread.php?t=165528) to know how much memory your script will allocate

[wonkey_monkey]

Now, what if I re-assign an new Video file to the same variable ? Will the "old" allocation be dropped and a new be made ?

If you had a script like this:


a=avisource("one.avi")
b=avisource("two.avi")

c=a+b

b=avisource("three.avi")

return b+c


AviSynth is not going to be able to drop any "allocation" for the first use of b, because that object is still going to be required whenever a frame is fetched.

[may24]

Thanks a lot for your answers.

Now, what about this

a=avisource("one.avi")
b=avisource("two.avi")

return(a)


Will Avisynth recognize that instance "b" is never used and therefore de-allocate the memory ?

[StainlessS]

Now, what about this

a=avisource("one.avi")
b=avisource("two.avi")

return(a)


Will Avisynth recognize that instance "b" is never used and therefore de-allocate the memory ?

Dont know but

a=avisource("one.avi")
b=avisource("two.avi")
b=0 # would for sure call destructor on clip b
return(a)


It probably does not matter much either way.

EDIT: Unless eg

a=avisource("one.avi")
b=avisource("two.avi")
c=b
b=0 # Instance c copy of b may well still persist and so "two.avi may remain open.
return(a)


On second thoughts, methinks maybe local variables at main script level (without Global specifier) will still persist
during frame serving, but local variables at local function level would cease to be (unless called via some runtime environment filter
eg Scriptclip). I guess the definitive answer is 'it depends'.

Here post on order that things occur during compile stage, might be of interest:- http://forum.doom9.org/showthread.php?p=1594454#post1594454

EDIT: You could always find out for yourself (check out RT_Stats)


#a=avisource("one.avi")
#b=avisource("two.avi")

a=ColorBars.KillAudio
b=ColorBars.KillAudio

SSS="""
n=current_frame
Ex=RT_VarExist("b")
RT_DebugF("%d] b %s Exist",n,Ex?"does":"does not",name="TEST: ")
RT_Subtitle("%d] b %s Exist",n,Ex?"does":"does not")
"""

return a.ScriptClip(SSS)


During Frameserving from DebugView (google)

00000005 21:11:11.515 TEST: 0] b does Exist
00000006 21:11:11.562 TEST: 1] b does Exist
00000007 21:11:11.593 TEST: 2] b does Exist
00000008 21:11:11.625 TEST: 3] b does Exist
00000009 21:11:11.656 TEST: 4] b does Exist
00000010 21:11:11.687 TEST: 5] b does Exist

[Groucho2004]

Now, what if I re-assign an new Video file to the same variable ? Will the "old" allocation be dropped and a new be made ?
Yes.

Now, what about this

a=avisource("one.avi")
b=avisource("two.avi")

return(a)


Will Avisynth recognize that instance "b" is never used and therefore de-allocate the memory ?
No.

It took 2 minutes to test that with AVSMeter as suggested above.