AviSynth 2.6.0 Alpha4 [Jan 14th, 2013]

[IanB]

Did anyone get SoundOut to work with Avisynth v2.60a4? When i open a script (ending with SoundOut()) in Virtualdub i get the error message:

Avisynth open failure:
Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 176310176

Is it supposed to work in 2.60 or is something not implemented properly?
You probably have an early development version compiled with AVISYNTH_INTERFACE_VERSION = 5, this of course will not work with 2.5.8 or versions of 2.6 that rely on the version correctly describing the API level expected.

Any plugin that purports to be version 5 must support all the requirements of the latest 2.6 API. In this case CACHE_GETCHILD_CACHE_MODE returning a valid mode.

Plugin authors may use the reserved version 4 to prevent loading in 2.5.8 but still be treated as a 2.5 plugin by 2.6.

I will have a look to see if I can add some protection code for AvisynthPluginInit2 plugins that try to lie that they are version 5.

[Wilbert]

You probably have an early development version compiled with AVISYNTH_INTERFACE_VERSION = 5, this of course will not work with 2.5.8 or versions of 2.6 that rely on the version correctly describing the API level expected.
I guess so. So i need to recompile the plugins with the latest avisynth.h? Will try that later.

[IanB]

Given we are talking about SoundOut (pass through video) it would be more useful to compile it as a 2.5 plugin, then it would work with all versions.

[Groucho2004]

Do you think it's "fair" to say that AviSynth 2.5.8 is better than 2.6.0 just because the former is tagged as being "Stable" whereas the latter is tagged as being "Alpha" (like Zathor basically is argumenting)?

Or would you agree with SEt, that AviSynth 2.6.0 is better than 2.5.8, even though it's tagged as being "Alpha"?
SEt was comparing MT versions and their MT implementations.

As for the official (non-MT) Avisynth versions - 2.6 has had many bug fixes and added features since 2.58 and it seems to be just as stable.
Also, the more people use it, the more testing is done and we may finally get out of Alpha stage.

[IanB]

As a 2.5.8 replacement 2.6.0 should be just as stable. It passes all current the 2.5 regression tests, while 2.5.8 fails a few due to bugs being fixed and test to expose them being added. Most problems show up in new code, so if you use the new 2.6 features, that is where you might expect to find problems. A lot of people are downloading 2.6. And the only 2.5 bug reports I seem to get are for things broken in 2.5.8 as well, the few 2.6 bug reports are to do with things like YV24 overlay and YV411 text painting.

I have most of the API changes mapped out to cover hooks for expected features for 2.6.1 and 2.6.2 like extra colour spaces and threading so that 2.6 plugins won't need to be recompiled. I have a long standing bug in the cache from 2.5.7 that I am working on at present and I intend to do an Alpha 5 release when I finish and test that fix. If Alpha 5 stands up without any new bugs I will probably promote it to Release Candidate 1, i.e. 1st Beta release.

[StainlessS]

As IanB says, you can use v2.6a4 as a more stable v2.58 so long as you dont use new features.

Me RECOMMENDED's. :)

I use v2.6a4 (well Groucho2004's ICL version usually, for a couple of recent fixes), and MeGUI uses that one
and not 2.5.8.5 in MeGUI directory. (Although recently a user found he also had to manually update the MeGUI copy on
W7 64bit for some reason or it was not using 2.6).

EDIT: Of course (slaps head), MeGUI only uses the MeGUI local copy for its built in tools eg Avisynth Script Creator,
if feeding AVS files directly into MeGUI, then it uses the system copy.

EDIT: Zathor reply to below post (linked to from following post) :-
Btw even if MeGUI provides 2.6 it will only be used when no AviSynth is installed at all on the system. Therefore it will be used by the more inexperienced users and the AviSynth build must work.

[StainlessS]

FYI, Mr B,

I've decided to ignore chroma altogether for YV411 in DDigit, it seems to provide the least objectionable results,
although might look a little weird on something like colorbars, looks not too bad on live video.
Could not manage to find a good fix for chroma as DDigit is inherently character based and the control characters in the
stream make things much harder to implement as opposed to a raster scan implementation like your Info.h without any control codes.
(At least without slowing it down significantly, and it would still look ropey).
EDIT: Above problem in DDigit relates to faint chroma stripes due to background fade applied twice, at the end a character and
beginning of next character, when on non greyscale frame.


Will though try to implement (using the reserved and last available 'C' escape sequence {'\v'}) an alternative luma only
colormap for eg Y8 and YV411, something like '\v0' to '\vF' == luma 0 -> 255 in steps of 17 (== 255/15).

EDIT: Looks OK over Colorbars(). Might want to reduce background multiplier a little from 7/8, 3/4, and 5/8 both seem OK,
and improves visibility if chroma background not faded.

[real.finder]

ver. 2.5.8 supports 6 (5.1) Channels in audio

is 2.6 supports 8 (7.1)?

[tebasuna51]

ver. 2.5.8 supports 6 (5.1) Channels in audio

ver 2.5.8 support also 7.1.

[real.finder]

ver 2.5.8 support also 7.1.

um, but there http://avisynth.org/mediawiki/GetChannel

Did not mention 7.1

[Wilbert]

It says "it returns one or more channels of a multichannel signal". It support a large amount of channels (there might be some limit, but i'm too lazy to look that up). The main question is whether your source filter loads them all.

[tebasuna51]

um, but there http://avisynth.org/mediawiki/GetChannel

Did not mention 7.1

Like Wilbert say: "It support a large amount of channels"

More important is this:
"The ordering of the channels is determined by the ordering of the input file, because AviSynth doesn't assume any ordering (1). In case of stereo 2.0 WAV and 5.1 WAV files the ordering should be as follows (2)"

(1) AviSynth don't have a essential property of audio to manage multichannel audio (MaskChannels), to identify each channel.
Then the user must be careful only with the channel order, trying to preserve the standard order not always obvious.

(2) No problem with standard stereo: FrontLeft, FrontRight

With 5.1: FL, FR, FCenter, LFE, RearL, RearR

Here there are a difference with Microsoft defined channels:
SideL, SideR (-+90º from Center channel) and BackL, BackR (-+130º from Center channel).
BTW, both can be assumed like standard 5.1:
FL, FR, FC, LFE, BL, BR or FL, FR, FC, LFE, SL, SR

With 7.1: the standard order don't have problems, must be:
FL, FR, FC, LFE, BL, BR, SL, SR

With 6.1: here we must be careful because don't exist a standard order defined and the BackCenter can be before or after the Rear channels depending if we consider the Rear like Back or Side.

You must know if the input is:
1) FL, FR, FC, LFE, BL, BR, BC
or
2) FL, FR, FC, LFE, BC, SL, SR
and if the output must have the order 1) or 2)

[ajp_anton]

Is there a 64-bit build of 2.6 available? I just need to combine a few 2.6 features with large amounts of RAM (not expecting any speed boosts or plugin support).

[Reino]

E=Import("sample_E.avs")
A=BassAudioSource("sample_A.wav").DelayAudio(3388169/44100.0)
W=Import("sample_W.avs").DelayAudio(3599778/44100.0)

Mix1=MixAudio(W,A,1.0,1.0)
Mix2=MixAudio(Mix1,E,1.0,1.0)

ConvertAudioTo16bit(Mix)I'm doing some audio mixing (A begins before E ends, and W begins before A ends) and I've noticed something odd. By closely examining the script's outcome in Audacity, I noticed for W I have to lower the DelayAudio with 1 sample (3599777) to align everything perfectly, which isn't necessary for A.
Can any developer/anyone who knows the inner workings of Avisynth confirm this is how Import() works?
-----------------

In reference to this post, I was wondering if this would also work for DelayAudio. Something like this?
A=BassAudioSource("sample_A.wav")
A.DelayAudio(113414616/44100).DelayAudio((113414616%44100)/44100.0)

[Gavino]

Can any developer/anyone who knows the inner workings of Avisynth confirm this is how Import() works?
Import() should have no effect on audio delay.
What do the scripts sample_E.avs and sample_W.avs contain?

In reference to this post, I was wondering if this would also work for DelayAudio.
Yes, it should work - DelayAudio() converts time to samples in the same way as AudioTrim().

[Reino]

Sorry for the late response, but in the end it turned out to be a stupid little mistake on my part. It was all just a rough draft. I then rewrote the script and worked out the rest.
It's all about doing this (https://www.youtube.com/watch?v=4Y3aKcQ0HK4) (view in 720p!) with Avisynth (http://pastebin.com/YZDx0ND8).

Follow-up question:
Subtitle(String(Int(AudioDuration)/60)+":"+String(Int(AudioDuration)%60)+MidStr(String(Frac(AudioDuration)),2,4)+" ("+AudioLengthS+" samples)")
...produces: "2:4.278 (5480666 samples)".
Do you know how I can change this so that 0-9s always have a preceding 0 and that the example thus becomes "2:04.278 (5480666 samples)".

[Gavino]

Subtitle(String(Int(AudioDuration)/60)+":"+String(Int(AudioDuration)%60)+MidStr(String(Frac(AudioDuration)),2,4)+" ("+AudioLengthS+" samples)")
...produces: "2:4.278 (5480666 samples)".
Do you know how I can change this so that 0-9s always have a preceding 0 and that the example thus becomes "2:04.278 (5480666 samples)".
Use the second argument of String() to control the formatting: String(..., "%02.0f")
http://avisynth.nl/index.php/Internal_functions/Conversion_functions

[Reino]

Man, you're fast! Thanks a lot! ;)

[Reino]

Small problem with the Subtitle-string still:
12962398 samples / 44100Hz = 4:53.931927... -> 4:53.932, but with MidStr(String(Frac(AudioDuration)),2,4) that obviously results in 4:53.931. I thought of using Round(float), but it converts to an integer, so that's of no use.
Do you know of a clever way to round off with an accuracy of 3 decimals, Gavino?

[Chikuzen]

MidStr(String(Frac(AudioDuration + 0.0005)),2,4)

[Reino]

That's very clever indeed. Haven't thought of that. Thanks!

[Gavino]

Another way is again to use the formatting function of String():
MidStr(String(Frac(AudioDuration), "%5.3f"),2,4)

[Gavino]

Actually, it occurs to me there is now a further problem (with both Chikuzen's solution and mine).

If the fractional part is greater than 0.9995, you need to round up to the next whole second.
Even worse, when seconds > 59.9995, you need to change the minute count too.

A solution is to round the duration to the nearest millisecond before calculating the minute and second parts:
duration = round(AudioDuration*1000)/1000.0
then use this new duration in place of AudioDuration to display as before.

[Reino]

The samples I had thus far didn't reveal this flaw, so I probably wouldn've never known. Thanks a lot, Gavino!

The end of my script now:
Duration=Round(AudioLengthF/44.1)/1000.0
Subtitle(String(Int(Duration)/60)+":"+String(Int(Duration)%60,"%02.0f")+\
MidStr(String(Frac(Duration),"%5.3f"),2,4)+" ("+AudioLengthS+" samples)")

Btw, AviSynth Wiki's description on the formatting function of String() (http://avisynth.nl/index.php/Internal_functions/Conversion_functions) was a little confusing, so I changed the text a tiny bit and corrected a small mistake in one of the examples.

[StainlessS]

There seems to be a mismatch between docs and source for Subtitle().

Doc

Align | Normally 4 <left and baseline>; if x=-1, then 5 <horizontal center and baseline>



Subtitle::Create

const int align = args[10].AsInt(args[2].AsFloat(0)==-1?2:7);


ie default = 7, if x == -1 then 2. (perhaps 2 should be 8, if so both docs and source wrong).

Can it be verified which is intended behavior please. (doing something similar).

[Gavino]

There seems to be a mismatch between docs and source for Subtitle().
Looking at source file text-overlay.cpp (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/filters/text-overlay.cpp?view=log) in CVS, it seems code originally matched docs, but defaults changed in file revision 1.6 (23 Apr 2005).

[StainlessS]

Thanx G. I still think both docs and code may be wrong, seems odd that default top left (7)
and if x== -1, then applies 2, ie bottom middle. For Top-center, 2 might be correct on a mobile
numeric keypad, but on a PC keypad that position is 8.

The question remains, what is intended behavior ?

[Gavino]

The question remains, what is intended behavior ?
Change was made by IanB, so perhaps he can explain.
No reason given in CVS, except 'tidy'.

[IanB]

Sorry, I can't remember that far back. Possibly making the default text be all inside the frame. Maybe there was a thread discussing the issue around that time?

Anyway just document what it does now.

[Wilbert]

Anyway just document what it does now.
I updated the docs (offline will follow later).

[Robert Martens]

Trying to generate some test clips over the weekend, I stumbled over what I believe is a bug when converting RGB32 to Y8 in Avisynth 2.6; clips with a width of eight or more show a shift to the right by four pixels, the right side cropped by four and the left side padded with copies of the left four columns. I've tried every width from one through seven pixels, and they all work as expected. I've been testing with this script:

pixel_type = "RGB32"
width = 1
height = 16

a = BlankClip(width=width, height=height, color=$0F0F0F, pixel_type=pixel_type)
b = BlankClip(width=width, height=height, color=$555555, pixel_type=pixel_type)
c = BlankClip(width=width, height=height, color=$AAAAAA, pixel_type=pixel_type)
d = BlankClip(width=width, height=height, color=$F0F0F0, pixel_type=pixel_type)
e = BlankClip(width=width, height=height, color=$FEFEFE, pixel_type=pixel_type)

StackHorizontal(a, b, c, d, e, d, c, b)
ConvertToY8()

Commenting out ConvertToY8 should produce a visually identical clip, but instead the content is shifted to the right. The conversion works as expected in the September 27th, 2009 build, but the May 25th, 2011 and January 14th, 2013 builds show the behavior. Converting to Y8 from RGB24 works correctly in all three releases.

I tried checking out and building the project myself at a few points, and though the code has since been broken out into its own file, it seems that the update of src/convert/convert_planar.cpp from revision 1.12 to 1.13 (rewriting the ConvertToY8 functions in Softwire) is where things changed.

I've spent a few hours between yesterday and today going over this, but I'm getting nowhere; I thought perhaps I could notice something between comparing the RGB32 and RGB24 code paths, or by comparing those with an older revision, but Assembly is proving my superior, and I'm stumped. Is this a real bug, or have I sent myself on a wild goose chase?

[IanB]

Yep it's a bug. The "x86.add(ecx, 4);" at line 166 in convert_rgbtoy8.cpp was moved after the dependant pixel load at line 163 to fill the stall on mm3, the load code did not get the offset updated to match.

[vcmohan]

I am trying to port my TransAll to 2.6
The compiler gives an error at a line reading
const int bytes = vi.BytesFromAudioSamples(count);

fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'E:\8168\vc98\p2\src\P2\main.c', line 494)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Error executing cl.exe.

I am unable to make out this. I am on XP and VC6.
Request help.

[cretindesalpes]

I remember VC 6 was crashing sometimes with bad syntax, typically when forgetting the parenthesis after the definition of a constructor or something like this. The indicated line is generally irrelevant. Also, changing the order of the included files may magically prevent this kind of crash. Check carefully your syntax, or better, use a more recent compiler.

[vcmohan]

No. The error reporting is definitely from that line. It did not like specifying bytes as int. changing it to __int64 worked. With Avisynth 2.5.8 I did not get this error though.

[StainlessS]

I seem to have found an Avisynth v2.6a4 BUG (not checked in V2.58)


A=Colorbars().convertToYV12()
#MergeRGB(a,a,a) # ERROR:- "MergeRGB: Input to filter must be in RGB colorspace"
MergeARGB(a,a,a,a) # OK

[Groucho2004]

I seem to have found an Avisynth v2.6a4 BUG (not checked in V2.58)


A=Colorbars().convertToYV12()
#MergeRGB(a,a,a) # ERROR:- "MergeRGB: Input to filter must be in RGB colorspace"
MergeARGB(a,a,a,a) # OK


Can't reproduce this. Tried 2.6A4 (my ICL build and official), Set's MT and 2.58.

Edit: That error message is not part of the Avisynth source so Ian seems to be on the right track - as usual.

[IanB]

@StainlessS,

Maybe you are using TSP's RGBmanipulate, feature request: extract red/green/blue() ; mergergb() (http://forum.doom9.org/showthread.php?t=93090).


And people with your experience are allowed (expected) to read the source and refer to the lines that you think are in error.

[StainlessS]

OK, guys, you got me.
RGBManipulate, goes in the bin.

[vcmohan]

I am still confused about usage of AVISYNTH_INTERFACE_VERSION. Can a plugin access the version at run time? If so how? I find that in the avisynth header file it is already defined. So at compile time one can get this info.

[IanB]

Have you read post #50 "Notes about AVISYNTH_INTERFACE_VERSION usage."?

AVISYNTH_INTERFACE_VERSION is a compile time constant, and without trickery the core API does not directly expose the value it was compiled with. Think about it as an indicator to how much API you have, low numbers -> old shorter API set, higher numbers -> more features available.

You are expected to ask "Do you support version X ?" with IScriptEnvironment::CheckVersion(int version) and either complain you need a later version or provide remedial code paths to support older versions.

In all plugins you provide the IClip member "virtual int __stdcall IClip ::GetVersion() { return AVISYNTH_INTERFACE_VERSION; }" which the core uses to determine the feature set available from the filter class.

[StainlessS]

I am not a CPP programmer and have been and still am totally oblivious to the concerns in this thread
(EDIT correction, under previous question),
so mainly I just ignore them, compile time stuff fulfills my need as I am not able to distinguish the difference.
why I need to add an IClip member, dont know, presumed only for eg source filter.
Am equally informed about Cache usage, am yet to see a single simple example other than returning 0, and no
real idea what that does.

V.C. Mohan, if you can sort it out, send me a PM, I'de quite like to understand it myself.

Some things about Avisynth, are to me, a complete mystery.

EDIT: I have read previous linked thread more than once, still non the wiser.

EDIT: My guess is that there are a lot of people that do not understand, but are reluctant to expose themselves as
stupid, hands up, I am stupid. If I were wrong, then there would not be the repeated queries about same,
all of which seem to repeatedly misunderstand the already existing posts. We need it spelt out in words of 1 syllable
or less, so the the vast majority of stupid people (like me) can understand.

[Robert Martens]

You are expected to ask "Do you support version X ?" with IScriptEnvironment::CheckVersion(int version) and either complain you need a later version or provide remedial code paths to support older versions.

In all plugins you provide the IClip member "virtual int __stdcall IClip ::GetVersion() { return AVISYNTH_INTERFACE_VERSION; }" which the core uses to determine the feature set available from the filter class.

I've been having trouble understanding this subject myself, and so far I've been distinguishing between 2.5 and 2.6 by way of separate build configurations. There are two things that confuse me:

First is the unfamiliar behavior of CheckVersion. I imagine I'm showing my ignorance of design patterns here, but I'd have expected a function one could simply call to get a version number, which could then be used to branch in various directions. Instead, it appears that all you do is call the function (optionally providing an API version number, which defaults to the value of AVISYNTH_INTERFACE_VERSION) and the core will check whether or not the plugin has been compiled for a later version, throwing an error if so:

src/core/avisynth.cpp
----

void ScriptEnvironment::CheckVersion(int version) {
if (version > AVISYNTH_INTERFACE_VERSION)
ThrowError("Plugin was designed for a later version of Avisynth (%d)", version);
}

Poking through the Avisynth source while typing up this post, I saw a call to CheckVersion that shows the function used in a try...catch block:

src/core/avisynth_c.cpp
----

extern "C"
int AVSC_CC avs_check_version(AVS_ScriptEnvironment * p, int version)
{
p->error = 0;
try {
p->env->CheckVersion(version);
return 0;
} catch (AvisynthError err) {
p->error = err.msg;
return -1;
}
}

This makes the usage clearer, but wasn't apparent just from the avisynth header. Off the top of my head I'm still not sure if I can use it in the way I'd like to in my project, but hopefully that points someone else in the right direction for their own work.


My other difficulty was with part of post 50, where you mention IClip::GetVersion, saying

And through the IClip interface it is the authors responsibility to declare the level of support the plugin provides.

which to me suggests that I have to do something beyond inherit from either IClip or GenericVideoFilter. The definition of IClip, however, shows the GetVersion function is already defined to return the value of AVISYNTH_INTERFACE_VERSION defined in the header I'm using, and I am in fact able to call my filter's GetVersion and retrieve the right value, even though I haven't overridden the header's copy of the function anywhere in my own code.

Is there something else I need to do with GetVersion? I feel like I've asked that before and gotten an answer, but I can't remember since I'm dumb, so please bear with me.

[vcmohan]

Still unclear to me.
Does older to avisynth version 2.6 check the version from the plugin through GetVersion?
Does only avisynth 2.6 and presumably later versions check the version?
At what stage the version is checked? . Is it prior to Get Frame and or Get audio ?
I am trying to avoid multiple compilations of the plugins.

[Chikuzen]

At what stage the version is checked? . Is it prior to Get Frame and or Get audio ?

The version check is done at LoadPlugin().
If your plugin's AVISYNTH_INTERFACE_VERSION is 5, then avisynth.dll older than 2.6 can't load your plugin.

[Groucho2004]

It's really simple guys (and documented (http://avisynth.nl/index.php/Cplusplus_API#CheckVersion)!):

CheckVersion(5) throws an error when a avisynth.dll is used that does not support this interface version (2.58 for example).

GetVersion() simply returns the interface version of the loaded avisynth.dll.

[vcmohan]

" chicuzen :- If your plugin's AVISYNTH_INTERFACE_VERSION is 5, then avisynth.dll older than 2.6 can't load your plugin."

I thought the older to 2.6 avisynth does not check the version, and therefore plugins compiled with avisynth.h of 2.6 can still be loaded and if properly coded these plugins can operate. Now it appears that particular doorway was shut. Pity.

[StainlessS]

Avisynth v2.6 plugs now use a different plugin initialization routine AvisynthPluginInit3(), v2.58 AvisynthPluginInit2().

#ifdef AVISYNTH_PLUGIN_25
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
#else
/* New 2.6 requirement!!! */
// Declare and initialise server pointers static storage.
const AVS_Linkage *AVS_linkage = 0;

/* New 2.6 requirement!!! */
// DLL entry point called from LoadPlugin() to setup a user plugin.
extern "C" __declspec(dllexport) const char* __stdcall
AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {

/* New 2.6 requirment!!! */
// Save the server pointers.
AVS_linkage = vectors;
#endif
env->AddFunction("RoboCrop", "c[Samples]i[Thresh]f[Laced]b[wMod]i[hMod]i[RLBT]i[Debug]b[Ignore]f[Matrix]i[Baffle]i"
"[ScaleAutoThreshRGB]b[ScaleAutoThreshYUV]b[CropMode]i[Blank]b[BlankPC]b[Align]b[Show]b"
"[LogFn]s[LogAppend]b"
,Create_RoboCrop, 0);
return "`RoboCrop' RoboCrop plugin";
// A freeform name of the plugin.
}

[Wilbert]

In all plugins you provide the IClip member "virtual int __stdcall IClip::GetVersion() { return AVISYNTH_INTERFACE_VERSION; }" which the core uses to determine the feature set available from the filter class.
Let me ask a dumb question too ;) I'm probably misunderstanding this, but i want to document something about creating new plugins.

Suppose i created a plugin with the new v5 avisynth.h. It's a plugin that should work with AviSynth 2.5 too (let's say minimal v3 because i used SubframePlanar somewhere). Does the above mean i should add the line

int __stdcall GetVersion();

in the constructor? And add the lines

int __stdcall NamePlugin::GetVersion() {
return int(3);
}

after it? So how and where (in the code) does the core uses this to determine the feature set available from the filter class?

[IanB]

The version checking stuff is more for apps that load Avisynth.dll and call the CreateScriptEnvironment entry point.

You would give the lowest version you can live with on the CreateScriptEnvironment call, then check if some extra API's are available with some IScriptEnvironment::CheckVersion calls.


The IClip::GetVersion is mostly for the core to find out about plugins. For most applications the inherited implementation is satisfactory. Of course if you need something special then like the other IClip members you can override it in your class. Currently the 2.6 core call IClip::GetVersion to test if IClip::SetCacheHints support the version 5 calls. Apps that load Avisynth.dll it may be useful to know the versions of returned PClip's from Invoke and friends.


It was never intended for 2.6 plugins to be loadable by earlier versions of the Avisynth core. The brief was 2.6 would load and support 2.5 plugins, period! That said, it is fairly easy to write a single .dll plugin that could be loaded and used by a 2.5 Avisynth core and still be a complete 2.6 plugin to a 2.6 Avisynth core.

To do so the .dll only needs to provide both AvisynthPluginInit2 and AvisynthPluginInit3 entry points. One brute force solution would be to have separate 2.5 and 2.6 filter classes and reference each behind the appropriate AvisynthPluginInit* entry point. A less brutish solution could be to provide a local static copy of the AVS_linkage for use with a 2.5 core case, hopefully the 2.6 core version of the AVS_linkage is used in the 2.6 code paths. Just needs a little imagination .....


I am not a CPP programmer ....Yet you write quite an number of plugins and usefully contribute to the discussions.