Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th January 2012, 10:26   #1  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Filter/plugin lifecycle

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?
DrPhill is offline   Reply With Quote
Old 13th January 2012, 11:17   #2  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,412
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.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 13th January 2012, 12:11   #3  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Quote:
Originally Posted by Gavino View Post
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 is offline   Reply With Quote
Old 13th January 2012, 12:49   #4  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Ahh, I think I have got it
Code:
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
Code:
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?
Code:
params->uberMask  = malloc(dataSize * sizeof(int));
(............................)
mfree(params->uberMask);
params->uberMask = 0;
DrPhill is offline   Reply With Quote
Old 13th January 2012, 13:10   #5  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,412
Quote:
Originally Posted by DrPhill View Post
So one last question - rather lazily I grabbed the memory using
Code:
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:
Code:
    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++).
__________________
GScript and GRunT - complex Avisynth scripting made easier

Last edited by Gavino; 13th January 2012 at 13:13.
Gavino is offline   Reply With Quote
Old 13th January 2012, 13:36   #6  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Quote:
Originally Posted by Gavino View Post
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:
Code:
    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.
DrPhill is offline   Reply With Quote
Old 15th January 2012, 20:49   #7  |  Link
SEt
Registered User
 
Join Date: Aug 2007
Posts: 374
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.
SEt is offline   Reply With Quote
Old 15th January 2012, 21:51   #8  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Quote:
Originally Posted by SEt View Post
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 ).

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...........
DrPhill is offline   Reply With Quote
Old 15th January 2012, 22:38   #9  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,341
Quote:
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.
Wilbert is offline   Reply With Quote
Old 16th January 2012, 09:21   #10  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Quote:
Originally Posted by Wilbert View Post
I never used it, but you might want to look at 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.
DrPhill is offline   Reply With Quote
Old 16th January 2012, 10:08   #11  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,751
Quote:
Originally Posted by DrPhill View Post
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 .
__________________
Born in the USB (not USA)
Ghitulescu is offline   Reply With Quote
Old 16th January 2012, 17:13   #12  |  Link
amtm
Guest
 
Posts: n/a
Quote:
Originally Posted by DrPhill View Post
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.

Last edited by amtm; 16th January 2012 at 17:15.
  Reply With Quote
Old 16th January 2012, 17:32   #13  |  Link
amtm
Guest
 
Posts: n/a
Quote:
Originally Posted by Ghitulescu View Post
C++ is portable enough .
Of course. The most significant portion of the JVM is written in it.
  Reply With Quote
Old 17th January 2012, 11:01   #14  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Quote:
Originally Posted by Ghitulescu View Post
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, 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:").

Quote:
Originally Posted by amtm
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
DrPhill is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.