AviSynth plugins Multithreaded?

[scmccarthy]

Recently, I learned how to override the multithread default for compiling dll by using -ML with cl.exe, then /DLL with link.exe.

It makes them a little smaller, but is it better?

Stephen

[dividee]

Actually, I think it's better. Look at the last few posts of this old thread:
http://forum.doom9.org/showthread.php?s=&threadid=31623

[scmccarthy]

@dividee

Thanks for the prompt reply, I really appreciate it.

Stephen

[scmccarthy]

@dividee

The thread you pointed me to said that I should compile my plugins multithreaded.

Stephen

[dividee]

Sorry about the late reply, this time.

It seems I misunderstood your first post. You said the switch overrides the multithread default and I assumed the multithread default was off and you were turining it on. From your last post I guess it's the other way around.

Anyway, I indeed think it's better to compile them multithreaded.

[scmccarthy]

@dividee

When I compile using the switch that makes a dll with cl, it is multithreaded. But if I don't call link from cl, I can use the non-dll switches for cl and use /dll with link at linking time. It is only the linking that determines whether it is a dll anyway. So then I could use the switch that makes a single threaded exe instead if I wanted to. To put it another way, the cl dll switches don't do anything different from the exe switches until it calls link anyway, so once I suppress linking, I can use the exe switches. Of course I was wrong about there not being any single threaded cl dll switch in the first place.

You see how easy that is? :cool:

Stephen

[Nic]

As a basic rule, if threads are used in anyway, always use the multithreaded libraries. Its strange that threads can even be used with the single thread libraries (seeing the very bizarre problems they can cause). However, single thread library code seems to run faster...(and according to you, smaller).

Cheers,
-Nic

[scmccarthy]

@nic

I was thinking that maybe multiple uses of the same filter within the same script might result in multithreading. Otherwise, I would never write a program that called for more than one process. I strive to call as few libraries as possible. The idea being that speed and compactness will result. Also, I never learned how to explicitly start a new thread in Windows programming.

My question was meant to be does AviSynth require its filters to be multithreaded?

Stephen

As a basic rule, if threads are used in anyway, always use the multithreaded libraries.
Yes, so if I did explicitly code threads, I would certainly always use the multithreaded libraries. I didn't interpret what you said this way until now.

[Nic]

Sorry if my comment wasn't particulary useful at the time, the thread just reminded me of an instance at work, where I couldn't understand the memory corruptions I was getting. And it was due to using CreateThread in SingleThreaded App... (doh).

Using multiple instances of the same avisynth filter shouldn't cause any multiple thread problems whatsoever. From my little experience with avisynth, it does not appear to need multithreaded libraries at all (and with the singlethreaded libraries it can be a little faster).

Cheers,
-Nic

[dividee]

Avisynth itself is not multithreaded, AFAIK. But avisynth is just a library; the calling process could still create multiple threads and run avisynth multithreaded. However, I'm not aware of any application that does that currently. Avisynth should be able to run multithreaded, it seems BRG took that into consideration from the start, that's why I try to write my plugins "multithread-friendly". Note that compiling with the appropriate switch is not always sufficient to make your plugin work in a multithreaded context.

[scmccarthy]

Note that compiling with the appropriate switch is not always sufficient to make your plugin work in a multithreaded context.
I am going to jump to the conclusion that plugins as simple as mine probably would work in a multithread context.
I'm not aware of any application that does that currently.
Due to the fact that I hate having extra overhead and extra space dedicated to something that never gets used, maybe I should drop the linking to the multithreaded library if by 'application' you refer to a gui running avisynth. If, on the other hand, you are refering to multiple uses of the same plugin within the same script or multiple threads run at the same time, then I feel it is important to make the plugins multithreaded, since I want to leave people the freedom to use any plugin in that manner.

Stephen

[dividee]

Indeed I was refering to a GUI running avisynth, multiple uses of the same filter in a script is not affected. I admit I never compared single-threaded vs. multi-threaded DLLs regarding ressources usage, but except maybe for filesize, I doubt the difference is important enough to notice. Do as you see fit.

[scmccarthy]

@dividee

Thanks,

using commandline compilters nessesicates specifying each option oneself. Which way do compile them. I'd understand if you can't be sure when your running a visual compiler. I suppose I am dissing visual compilers, but I am not dissing you or anyone who uses one. It is just that is does seem like it would be hard to keep trach of everything Visual Studio does by default.

As an example, I still need to edit my avisynth.h to include windows.h instead of just windef.h. I imagine that windows.h gets included by default behind the scenes for every windows project, so it does not affect anyone except me. I feel priviledged, however, to learn this stuff by working in an environment that does nothing at all by default. It forces me to know more about my development environment just to get something to compile.

Multithreaded versions use libcmt.lib instead of libc.lib. The third alternative, msvcrt,lib is the one VS uses, I imagine.

So, if you know, how do you compile your programs, multi- or single- threaded?

Stephen

[dividee]

I compile my plugins multithreaded.
I just did a quick compile test. It's strange that you mention in your original post that compiling them singlethreaded makes them a little smaller, it's the other way around for me: multithreaded: 11k, singlethreaded: 44k. I don't know what accounts for such a large difference (probably because I'm using an evil visual compiler).

I agree with you: using "lower level" tools are better to understand what's going on behind the scene. But not everyone wants to be that much involved in the inner workings of every tool he uses. For instance, I have more fun reverse-engineering network protocols than learning all the ins and outs of microsoft compilers ;)

I'm a bit surprised you can't compile your plugins without modifying avisynth.h. It should be possible, by defining some symbols or using some command line switch to compile it the same way as in the IDE.

[scmccarthy]

@divideeI'm a bit surprised you can't compile your plugins without modifying avisynth.h. It should be possible, by defining some symbols or using some command line switch to compile it the same way as in the IDE. My contention is the IDE is including windows.h by default.

It could be that it is defining certain things by default, but either way it is the same idea. My compiler is made by Microsoft with their include and lib files. I get error messages saying certain things are not defined properly unless I include windows.h or alternately, find a way around having to include windef.h at all. I am positive that the include files are the same, so this is the only explanation.

WINNT.H error (3364) : error C2146 : context error : missing ';' before identifier 'ContextRecord'.

Stephen

[cweb]

I hope this isn't offtopic, but is there any means to write an avisynth plugin in C rather than C++? This would probably allow the use of non-MSVC compilers like gcc.

[scmccarthy]

@cweb

I noticed what you said in Marc's farewell thread, and did not entirely buy it. This of course is a much better place to respond, however. First, I used to use Mingw32 (Which stands for Minimum gnu windows api32 or something.) for compiling BladeEnc. I even modified that code to encode free bitrates. I have been thinking about returning to the gcc again and will check to see if I can compile AviSynth plugins with it. I believe it is possible.

Seemingly out of nowhere, let me tell you to get the free bcc compiler, for the tool that comes with it called grep. Without grep, I could never figure out how to compile anything properly.

Oh, oh, I feel this message is spinning out of control, but trust me, you will still learn something from this.

First of all, I don't have MSVC, but only the commandline equivalents. It is because of my experience working only with commandline compilers staring with Borland's Turbo C++, then mingw32, bcc32, and now cl.exe that I think I can help you.

On the other hand, you might be right that gcc doesn't work with AviSynth, my experience doesn't entirely invalidate your point since I probably have the same library and include files that come with MSVC. My version comes from the Windows Driver Development kit for WinXP which microsoft practically gives away for free.

MinGW32 uses libraries and headers from the basic WinAPI32 too, so it should work. Most recently I compiled dividee's mpeg2dec.dll using the following commandlines:cl /Ob2 /O2 /G6 /Wall /wd4710 /wd4668 /wd4820 /wd4619 /wd4512 /wd4100 /wd4706 /wd4514 -ML /DMPEG2DEC_EXPORTS /c %1 /ID:\WINDDK\2600\inc\wxp /ID:\WINDDK\2600\inc\crt /IC:\Progra~1\MicroS~2\include ml /c /coff /Cx link *.obj advapi32.lib /OUT:%1.dll /DLL /LIBPATH:D:\WINDDK\2600\lib\wxp\i386 O2 means optimize for speed, G6 means compile for a 686 cpu(P3 or P4), /Wall means show all warnings except for the following eight, -ML means compile for single threaded, /DMPEG2DEC_EXPORTS is a define, /c means not to link, then we have three include files, two from WINDDK and one from the MicroSoft Platform Development Kit. Oh, and cl is the name of the compiler and /Ob2 allows inline expansion. ml is masm, c again suppresses linking, /coff is necessary for Windows API32, I don't care why anymore, /Cx preserves case, meaning is would treat car and CAR as two different variables, otherwise they would be treated the same. For link we have something special. advapi32.lib is necessary for mpeg2dec.dll because it uses RegOpenKeyEx() from the win32 API and that fuction is in that library. Normally, that is not part of the link command. /DLL creates a dll instead of an executable.

I suppose none of this is a helpful as if I gave you a commandline for the gcc compiler, but this might give you some idea and a clearer explanation of what's involved in working in a commandline environment might be called for in this thread anyway.

As for writing a plugin in c rather than c++, I am on solid ground in saying that MinGW32 is a win32 api c++ compiler and that is not your problem.

Stephen

[scmccarthy]

Search for '__GNUC__' to see the fixes for compiling with MinGW32 in the attached avisynth.h header file.

Stephen

[cweb]

You can compile the plugin, and I did in fact, but (the binary version made available of) avisynth is compiled with MSVC++ and the object/class calls do not work at present between different C++ compilers. This is a known fact which I have read about on other websites and newsgroups. There is no binary standard to call a c++-compiled DLL of another compiler. You can do it with C but not yet with C++.

I do have grep (various versions actually) and yes, I did set
all the required gcc parameters. Thanks anyway.

Originally posted by scmccarthy
@cweb

that code to encode free bitrates. I have been thinking about returning to the gcc again and will check to see if I can compile AviSynth plugins with it. I believe it is possible.

Seemingly out of nowhere, let me tell you to get the free bcc compiler, for the tool that comes with it called grep. Without grep, I could never figure out how to compile anything properly.

Oh, oh, I feel this message is spinning out of control, but trust me, you will still learn something from this.

First of all, I don't have MSVC, but only the commandline equivalents. It is because of my experience working only with commandline compilers staring with Borland's Turbo C++, then mingw32, bcc32, and now cl.exe that I think I can help you.

On the other hand, you might be right that gcc doesn't work with AviSynth, my experience doesn't entirely invalidate your point since I probably have the same library and include files that come with MSVC. My version comes from the Windows Driver Development kit for WinXP which microsoft practically gives away for free.

MinGW32 uses libraries and headers from the basic WinAPI32 too, so it should work. Most recently I compiled dividee's mpeg2dec.dll using the following commandlines: O2 means optimize for speed, G6 means compile for a 686 cpu(P3 or P4), /Wall means show all warnings except for the following eight, -ML means compile for single threaded, /DMPEG2DEC_EXPORTS is a define, /c means not to link, then we have three include files, two from WINDDK and one from the MicroSoft Platform Development Kit. Oh, and cl is the name of the compiler and /Ob2 allows inline expansion. ml is masm, c again suppresses linking, /coff is necessary for Windows API32, I don't care why anymore, /Cx preserves case, meaning is would treat car and CAR as two different variables, otherwise they would be treated the same. For link we have something special. advapi32.lib is necessary for mpeg2dec.dll because it uses RegOpenKeyEx() from the win32 API and that fuction is in that library. Normally, that is not part of the link command. /DLL creates a dll instead of an executable.

I suppose none of this is a helpful as if I gave you a commandline for the gcc compiler, but this might give you some idea and a clearer explanation of what's involved in working in a commandline environment might be called for in this thread anyway.

As for writing a plugin in c rather than c++, I am on solid ground in saying that MinGW32 is a win32 api c++ compiler and that is not your problem.

Stephen

[cweb]

Thanks - I will have a look.

Edit: Ok - you incorporated the 'fix' or brackets patch I posted on sourceforge. :)

Edit: The define __int32 long I did add myself in the plugin source
myself before calling avisynth.h. So this really does not help
solve the dll calling problem - you can compile a plugin into a dll
using MinGW32 however it still will be able to be called from avisynth
as required (because avsynth is compiled using MSVC++). Thanks anyway,
perhaps a way will be found in future.


Originally posted by scmccarthy
Search for '__GNUC__' to see the fixes for compiling with MinGW32 in the attached avisynth.h header file.

Stephen

[cweb]

Hi,
I found this on the MingW32 users mailing list which is very relevant to which compiler must be used to compile avisynth plugins:

"Why can't I link g++-compiled programs against libraries compiled by
some other C++ compiler?"

"Some people think that, if only the FSF and Cygnus Support folks would
stop being stubborn and mangle names the same way that, say, cfront
does, then any g++-compiled program would link successfully against any
cfront-compiled library and vice versa. Name mangling is the least of
the problems. Compilers differ as to how objects are laid out, how
multiple inheritance is implemented, how virtual function calls are
handled, and so on, so if the name mangling were made the same, your
programs would link against libraries provided from other compilers but then crash when run. For this reason, the ARM encourages compiler
writers to make their name mangling different from that of other
compilers for the same platform. Incompatible libraries are then
detected at link time, rather than at run time. "

[scmccarthy]

@cweb

That is all true, however, the beauty of MinGW32 as opposed to other gcc compilers is that the WIN32 API is converted from the *.lib form to the *.a form that gcc compilers use. I did not bother going further because I had no way of knowing you had already passed that hurdle and I have to actually read the documentation that comes with MinGW32 in order to compile a dll. I suppose you know the compiler will look for a winmain() function by default unless you use the right switches, but if I assume anything past what you told me, I am going to miss the problem.

I resist your statement that it is impossible, because I have experience getting Tord and the other developers to re-write bladesys.cpp and system.h in BladeEnc to make it automatically compile for MinGW32, my main compiler at the time. It wasn't easy figuring out what was causing the trouble.

Stephen

[scmccarthy]

@cweb

OK cweb, I now agree it won't work with c++.You can compile the plugin, and I did in fact, but (the binary version made available of) avisynth is compiled with MSVC++ and the object/class calls do not work at present between different C++ compilers. "Why can't I link g++-compiled programs against libraries compiled by These two quotes refer to different things. MinGW32 comes with compatible libraries for the WIN32 API as I said. That's why it is better than cygwin.

I can only understand what you are saying in terms of specifics. I think the problem is a plugin compiled with MinGW32 cannot call the exported fuction AviSynthPluginInit2() in the avisynth.dll. That is specific enough for me. It is not worth the time to figure out how to write a c plugin. I think it is possible, however, as long as you create the needed classes with c.:devil:

Stephen

[Richard Berg]

As far as I know, the only functions exported from avisynth.dll ARE using an 'extern C' interface. I definitely intend to keep Avisynth accessible from anything that can link with standard C until another binary standard (probably COM (http://arstechnica.infopop.net/OpenTopic/page?a=tpc&s=50009562&f=6330927813&m=4470946045)) is in place.

[scmccarthy]

Well yes, AvisynthPluginInit() is a c function and that makes is possible for a standard c program to link to avisynth. Calling GenericVideoFilter and GetFrame from a standard c program is the challenge. I don't know what calling GetFrame would look like in that program. Would GetFrame become the starting point in the program? Is GetFrame a callback function?

Stephen

[MrTibs]

I've been following your thread with great interest because I want to compile Avisynth plugins with Dev-C++.

Although I know nearly nothing about C++ and C++ DLL calling conventions and name mangling, I would like to ask some questions.

Assuming that you are using the same calling conventions (between the DLL and host application) it is only name mangling that poses the biggest problem. Here is my question: can we not force Dev-C++ to mangle the names in the same way that MSVC does through compiler directives and define statements? Or is there a binary problem with the DLL file?

BTW I did get the "invert" filter example to compile in Dev-C++ using your avisynth.h modifications. The dll didn't work but I wonder if the name mangling is the last issue.

Any help would be great!

[Belgabor]

Hm, if I got it right you overlooked something. Diffrent name mangeling is only a way to tell the developer at link time that it won't work, otherwise it would fail at runtime. The problem is not functions, but objects which are organized very diffrently from compiler to compiler, so (to the knowlegde I gained through this thread) its simply impossible to use a gcc object in msvc and vice versa.

(Carefully reread cweb's latest post)

[scmccarthy]

You are right Belagor. If you read this thread cardfully, you will find no refernce to name mangling. I don't understand what is meant by 'object', only that whatever it is it is right. (I love two letter words.)

I think what it is is the exported function AvisynthPluginInit() within the avisynth dll cannot find the code in the plugin...

I don't remember now, but let me share my theory on how to get around this. I think if you compiled the avisynth dll itself with gcc into a lib or object, then compiled the plugin, linking into the avisynth lib, maybe the plugin would work with a normally compiled version of avisynth.

Or perhaps it would only work with a gcc compiled dll.

Stephen

[MrTibs]

Thanks guys. It seems that the hardest information to find is right in front of you. (higher up in the thread)

I am not ready to give up on this issue yet but it is clear a simple DLL header hack won't do the trick. There are a few pages out there on how to call non-MSVC DLLs so I will be back bugging you with more questions. (Idealy, I'd like it if Avisynth could all Dev-c++, Delphi and Borland c++ dlls natively.) Opensource means open to develop for as well.

If I'm not carefull, I may actually learn a little about C++.

[Belgabor]

Originally posted by scmccarthy
I think what it is is the exported function AvisynthPluginInit() within the avisynth dll cannot find the code in the plugin...


Nope, that would be the trouble if the problem lay in name mangeling. To explain where the problem is I have to give a short explanation on objects.
A object is, overly simplified, a record with included functions. Now the troble lies (basically & again simplified) how the compiler stores those functions (usually a pointer table). E.g. the trouble could be (dunno if that is the case) that gcc stores this function table first and the variables second, and mscv does it the other way round, so if you call a object function compiled with the wrong compiler it assumes the pointer to the actual function to be in the wrong place.
To sum it up, if someone doesnt find an incredibly intelligent way of handling this, it won't ever work. Period. Well, at least not until avisynth provides a way to write plugins in c.

[vhelp]

Hello everyone.

I too (among others) am in this endeavor.. to port DLL's written by other
languages like Delphi :p

Belgabor,
I think I understand exactly what you are stating. I can't express my thought
well enough in words here, but I do understand.

As MrTib's had putted it, in short, I think it would be easier
if the developers of AVIsynth would just incorporate the feature to
allow Delphi and others, to map into their engine, so we can also enjoy creating functions and whatnots for AVIsynth to process. But, instead,
we have to resort to trickery, minipulation or whatever it takes
(if it can be done at all) to link into AVIsynth's engine for it to use
our DLL's. Currently, there exists no method, other than C/C++ and
that's a real bummer. C/C++ is a beast. And, unless you sleep w/ C,
or have an already made "filter" framework (template) in C/C++ to develop
quick DLL filters, that and coupled w/ some basic knowledge of C/C++ and
creating DLL within, you're not gonna get very far.

I've ben thinking or toying around w/ a recepie for a wrapper for a while
now. I've already thrown one at another FORUM.

Basically, it starts out in C...
* You write a C hook or whatever you want to call it into AVIsynth - our shell.
* Next, you add in some functions (buffers, pointers, structures etc)
.. these are all basically empty shells. you could start out w/ small steps,
.. like, start w/ a Buffer of a given size. Have a specific test file of
.. KNOWN data, and work with that.
* next, you clean up C syntax that would allow Delphi to use it, making sure
.. of correct param passing laws etc. i.e., ctecl or stdcall
* next, as a test, in C, bring back the DLL (modified w/ Delphi)
.. if C can open the DLL and use any functions that Delphi had added to it, then
.. surely, we are ready to give AVIsynth a try at using the DLL (our Wrapper
.. DLL) ??
.. I mean, even if it means to just add in a function that only BEEPS. If somehow,
.. AVIsynth were to BEEP ( he he.. ) then we scored a point. Well, in theory it
.. does work.

Call me crazy, but I ran this idea over and over in my head many times.
It seems to work, at least in theory. All's that it will take is a BUNCH
of trial and error tests. Lots of them. But, that's what hacking is all
about. ..running many tests, till an answer is found.

Unfortunately, the only thing stopping me from testng my THEORY above, is I do
not have C++ (other than couple command-line ones ie, GPL and GNU versions
from Books and things)

In the mean time, I will endeavor to find a way to allow Delphi DLL's
to be used in AVIsynth. I know its most likely not going to work,
but i refuse to just give up. I stated that elsewheres, that a few days ago, I
had managed to get AVIsynth to accept a DLL I was working on. This same DLL
does not work in AVIsynth any more.. as I continue to get errors about it not
being "bla, bla, bla... 1.0 plugin version" or something like that. I went on saying
that my system's CPU resource percent was down to 7% and that my pc
may have had the flue, and just took anything in (but did nothing with it)
The very next day though, when my pc was strong again, I could not reproduce
the same results. I'm stumped :(

Never the less, I will continue (here and there, when time allows) on this DLL
project.

Well, I have other items to search out, so I'll be surfing around.. I'll keep my
eye out on this DLL business and report back (here and other FORUMS) my
findings, if any, so us Delphi users can benefit as well :cool:

Have a good evening all.
-vhelp

[scmccarthy]

@belagorNope, that would be the trouble if the problem lay in name mangeling. Someone already pointed out that if name mangling were the problem the plugin would have a link error. So I realize name mangling is not the problem. I point specifically to AvisynthPluginInit because that is the dllexport funtion that should allow Avisynth to call the plugin. A object is, overly simplified, a record with included functions. That is true as a general definition, but we are talking about a specific case. You should be able to name the included funtion that applies to this case. The object must have a name! But I still think I already did find the name, i.e. the function that is declared as the dllexport: AvisynthPluginInit.

I came to my conclusion while I was following the example code for compiling a dll with gcc.

Your name is Belgabor? I am much more comfortable with my spelling.

Stephen

[MrTibs]

Here is an article that talks about using C++ odjects in Delphi:

http://rvelthuis.bei.t-online.de/articles/articles-cppobjs.htm

Here are a series of articles about using MSVC dll's with Borland.

http://www.bcbdev.com/articles.htm

[Belgabor]

Interesting links :) Seems the whole thing is not a simpossible as I thought.
Its still impossible for avisynth in its current implementation though (well at least without a wrapper done in msvc). Plugins not only need to call functions from an avisynth object, they also have to provide a object for avisynth to call, moreover this is allocated by the dll and disposed by avisynth, something which is said impossible on all the links you gave.
what might be possible is to write a filter that acts as a wrapper for filters written in a different language.

[scmccarthy]

@belgabor

One thing about this that confuses me is which is the dll avisynth or the plugins. Most explanations discuss an executable calling a dll. With AviSynth who is calling who?

Stephen

[MrTibs]

I was turning that problem over in my head last night. Avisynth is a dll that calls dlls. When calling the plugin, however, Avisynth passes an object that contains subroutines that are hosted in Avisynth and thus called by the plugin dll.

I've concluded that I'll treat Avyisynth as the host application and use the example article I posted as a guide for the object passing.

One option is to limit the plugin wrapper to passing a single frame. This would severly limit the usefullness of the wrapper but would make building the wrapper much easier. We could use the "invert" sample code as the base but instead of working on the frame, simply pass the Delphi DLL the frame. The thing that concerns me with this method is how to load and unlaod our Delphi DLL. I believe that we should be able to publish routines to load and unload our dll or to "autoload" our dll but we I don't know if our Delphi dll will auto unload with this method. I think that the avisyth script would [need to] look like this:
------------------
#load the dll that will wraps all delphi dlls
#it contains the routines:
#LoadDelphiPlugin,DelphiPlugin,UnloadDelphiPlugin
LoadPlugin("DelphiWrapper.dll")

#load my delphi plugin
LoadDelphiPlugin("mydelphifilter.dll")

DelphiPlugin("mydelphifilter,param1,param2,param3")
....
UnloadDelphiPlugin("mydelphifilter.dll")
--------------------

This assumes that we can publish more than one routine per c++ dll.

[scmccarthy]

@MrTibs

Two things:

1) a lot of this thread is about why MinGw32 cannot be used to compile plugins for AviSynth. The point being that Delphi is not a C++ compiler.

2) A wrapper implies you want to be able to compile existing plugins with Delphi. It is not a wrapper if you write all the code. Instead that would just be writing plugins in Delphi.

Stephen

[MrTibs]

Sorry, my mistake. I'm actually posting on two different threads dealing with the same issue (one about Delphi) and I got confused.

I also readily admit I'm not sure what the difference is between a wrapper and a loader or whatever we are talking about here. Perhaps a moment of clarification would help me.

As I understand it, MinGW, Delphi or any other non-MSVC compiler will not be able to create plugins because of the way objects are passed between the host application and the C++ DLL. If Avisynth was written in C or compiled in MinGW, we might have a chance (but only with plugins compiled with the same compiler). In order to get non-MSVC libraries loaded by Avisynth, we'll need to either add-to/change the load procedure in Avisysnth to use either a C calling convention (or perhaps a pseudo-COM) or to create a MSVC compiled plugin that will act as a "loader" for the non-MSVC DLL. Tle "loader" is responsible to tell Avisynth where the objects are to be found in the DLL. Now comes the confusing part:

Since the "loader" is generic and thus doesn't have a pre-programmed function name to report to Avisynth, do we need to go through it in order to use the non-MSVC filter it loaded (so that we can call it)? Also, will Avisynth automatically unload our non-MSVC filter correctly when it executes or do we need to do that manually?

My opinion is that in the long run, it would be much better to add to Avisynth's loading function to properly load non-MSVC DLLs. This would make MinGW and other C++ DLLs transparent to the end user. (Of course I don't know how to do this.)

[Belgabor]

However you would do it, it will be a major hassle. You'll have to wrap every object function of every Avisynth object that might be used by a filter.

[scmccarthy]

In order to get non-MSVC libraries loaded by Avisynth, we'll need to either add-to/change the load procedure in Avisysnth to use either a C calling convention Since AviSynth already uses a C calling convention for AvisynthPluginInit, this is already possible. I think the trick would be to call the five virtual functions: GetFrame(int n, IScriptEnvironment* env)
GetParity(int n) { return vi.IsFieldBased() ? (n&1) : false; }
GetAudio(void* buf, __int64 start, __int64 count, IScriptEnvironment* env)
SetCacheHints(int cachehints,int frame_range)
GetVideoInfo()

In fact this is the entire interface along with:'

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
env->AddFunction("ColorBars_YV12", "[w]i[h]i", Create_ColorBars_YV12, 0);
return "`ColorBars_YV12' sample plugin";
}

This is a plugin that uses IClip instead of PClip.

Stephen