Filter/plugin lifecycle

[DrPhill]

I may be being picky, but is there a distinct end-point to the life-cycle of a plugin? I ask as I allocate memory at the start of processing (during the first frame request) and keep this (references from userData in params) throughout the life of the plugin.

When should I free it?

I thought that maybe I could calculate the last frame to be requested, but I can see problems with that. For example I build the data that goes in this allocated memory by looking at every single frame the previous filter in the chain will provide. So if someone else did this to me I would be freeing the memory and recalculating the data more frequently than needed.

I was always taught that 'if you open it, shut it, if you take it out put it back, if you allocate it then free it'. What do folk here do?

[Gavino]

I believe you are using the C API.
In that case, you should set the free_filter member of your AVS_FilterInfo to be a function that does the required freeing of memory.

Things are simpler when using the C++ API as you would simply do the freeing in the filter's destructor.

You cannot know what is the last frame to be rendered since frame requests can come in any order.

[DrPhill]

I believe you are using the C API.
In that case, you should set the free_filter member of your AVS_FilterInfo to be a function that does the required freeing of memory.

Things are simpler when using the C++ API as you would simply do the freeing in the filter's destructor.

You cannot know what is the last frame to be rendered since frame requests can come in any order.

Excellent, thankyou Gavino. That is exactly what I needed.

You are right, I am using the C API.

I did not know that there was a FreeFilter function. Where might I find more info, please. I will look around for it myself, but may miss it, so any pointers would be very helpful.

[DrPhill]

Ahh, I think I have got it

void AVSC_CC freeFilter(AVS_FilterInfo *) {
MyParams* params = (MyParams*) p->user_data;
// free the memory here
}

AVS_Value AVSC_CC extractMotion(AVS_ScriptEnvironment * env, AVS_Value args, void * use_inplace) {
AVS_Value v;
AVS_FilterInfo * fi;

(........................)
fi->user_data = (void*) params;
fi->get_frame = extractMotionGetFrame; // my function to return frames
fi->free_filter = freeFilter; // my function to free resources
v = avs_new_value_clip(new_clip);
(.......................)
return v;
}

So one last question - rather lazily I grabbed the memory using
params->uberMask = new int[dataSize];
but I have a feeling I should have used malloc() and then I can use a matching mfree(). I have some vague memory from long ago when I did this stuff commercially that there are some gotchas here. Something to do with the size of the memory or the pointer? Any hints as to the exact code?
params->uberMask = malloc(dataSize * sizeof(int));
(............................)
mfree(params->uberMask);
params->uberMask = 0;

[Gavino]

So one last question - rather lazily I grabbed the memory using
params->uberMask = new int[dataSize];
In that case, you are using C++ code (and presumably some C++ compiler), even though using the C API for Avisynth. Therefore, you can use the corresponding C++ code to free it:
delete [] params->ubermask;

Is there a good reason for using the C API?
(Perhaps you don't know C++ well or don't have a Microsoft compiler.)
The C++ API is much simpler to use (and doesn't really require advanced knowledge of C++).

[DrPhill]

In that case, you are using C++ code (and presumably some C++ compiler), even though using the C API for Avisynth. Therefore, you can use the corresponding C++ code to free it:
delete [] params->ubermask;

Is there a good reason for using the C API?
(Perhaps you don't know C++ well or don't have a Microsoft compiler.)

OK, that makes sense. Thanks again Gavino.

I am using Codeblocks and its default compiler because I liked the price. I am using C rather than C++ because I thought I read that in order to compile C++ I needed some stuff associated with MSVC++ and that that would drag down a load of .NET, all of which seems like overkill for a hundred lines of source code.

I am as adept at C++ as I am at C, but both of those were last used in anger (i.e. commercially) some two decades or more ago (yep, old duffer now). I code for a hobby now, but prefer Java (since Smalltalk is passé). The similarities between languages make swapping easier (algorithms are nearly identical) and harder (when dealing with low level stuff like actual memory).

I have nearly finalised my code now - I have added a 'blur' stage to the the uber-mask which helps remove small areas of persistent but uninteresting change. I will comment the code heavily and make it available to anyone interested. Probably on SourceForge.

[SEt]

Native API of Avisynth is C++, C one is ugly hack in my opinion. Use of MSVC won't drag any .NET until you actually use it, if IDE of it isn't needed - look at the PlatformSDK, it also contains compiler and required libraries.

[DrPhill]

Native API of Avisynth is C++, C one is ugly hack in my opinion. Use of MSVC won't drag any .NET until you actually use it, if IDE of it isn't needed - look at the PlatformSDK, it also contains compiler and required libraries.

Granted a C adapter layer grafted onto a C++ interface is never going to look slick, but I have had to code to interfaces a lot less pretty than this one. Actually, I thought it rather good myself - (for C/C++ that is, both look a little 'last century' after Java :p).

I have a filter doing roughly what I want now. (I am on stage three of 'make it work, make it right, make it fast'). I am not sure that I want to install a load more gorp and learn to drive another set of compile tools unless there is a big benefit. Maybe if I think of another filter I need then that will enthuse me.

But if anyone is rewriting AVISynth in Java, please give me a call...........

[Wilbert]

But if anyone is rewriting AVISynth in Java, please give me a call...........
I never used it, but you might want to look at javisynth (https://sourceforge.net/apps/trac/javisynth).

[DrPhill]

I never used it, but you might want to look at javisynth (https://sourceforge.net/apps/trac/javisynth).

Thanks, I did look at that. A good idea, but not what I had in mind. It allows calls from Java into AVISynth. I was jokingly referring to a Java rewrite of AVISynth - that would provide platform independence, and a very easy route to adding plugins. Not that I intend this as any criticism of the current AVISynth in C/C++, which works perfectly well and has allowed me to solve my problem with a minimum of fuss.

[Ghitulescu]

I was jokingly referring to a Java rewrite of AVISynth - that would provide platform independence, and a very easy route to adding plugins.

And it will require a computer 5-10x more powerful to perform at the same speed, plus the "long felt need" of hunting bugs not only in its source code but also in the java libraries ;).

C++ is portable enough ;).

[amtm]

Thanks, I did look at that. A good idea, but not what I had in mind. It allows calls from Java into AVISynth. I was jokingly referring to a Java rewrite of AVISynth - that would provide platform independence, and a very easy route to adding plugins. Not that I intend this as any criticism of the current AVISynth in C/C++, which works perfectly well and has allowed me to solve my problem with a minimum of fuss.

Not to bring to much seriousness to a cheeky comment but that would be a terrible idea for one thing for anyone who wanted to write plugins in any language other than Java (and many plugin developers will want to). Having to write bindings to other languages using JNI is an absolutely terrible mess. At least with the 'ugly' C API you can create bindings to tons of languages quite easily. The same is could not be said for the reverse.

[amtm]

C++ is portable enough ;).

Of course. The most significant portion of the JVM is written in it. ;)

[DrPhill]

And it will require a computer 5-10x more powerful to perform at the same speed, plus the "long felt need" of hunting bugs not only in its source code but also in the java libraries ;).

C++ is portable enough ;).

I did not intend to start a language wars thread, so I will respectfully disagree with those opinions. They were true once, but no longer. ( See the Wiki article on JIT (http://en.wikipedia.org/wiki/Just-in-time_compilation), especially the bullet points just after "JIT code generally offers far better performance than interpreters. In addition, it can in some cases offer better performance than static compilation, as many optimizations are only feasible at run-time:").

Not to bring to much seriousness to a cheeky comment but that would be a terrible idea for one thing for anyone who wanted to write plugins in any language other than Java (and many plugin developers will want to). Having to write bindings to other languages using JNI is an absolutely terrible mess. At least with the 'ugly' C API you can create bindings to tons of languages quite easily. The same is could not be said for the reverse.

That is a much better argument against a rewrite in Java. JNI is a pig, although a dedicated adapter layer would allow linking to current C filters without changing the filters. I have seen such a layer written, but would not volunteer to write one.

Of course, the killer argument against a rewrite is that AVISynth works, it works well, and it works now. Nuff said, and sorry I opened that can of worms.....

Phill