AviSynth 2.5 alpha status and thoughts

[sh0dan]

First of all, I'd like to thank everyone who has helped out on the Alpha tests. It wouldn't have been possible without you!

I would like to sum up the experiences, and give you a status.

Overall I think it's time to stabilize the code and get a beta finished. This should include bugfixes in ALL filters - and update of documentation.
YV12 support seems to be a good thing. I wasn't very sure of how much we would benefit from it, but it seems to be worth the big efford. The list of buggy filters is getting shorter and shorter. YV12 support seems stable now, and with the new release of VirtualDubMod and XVID we have the programs needed to support them.
Audio support. We still need some testing on this, but it's not easy now. I feel there is a very good framework, but because of the limited feedback, this is mostly a feeling I have from myself from recoding most of the current filters. Filter conversion to floats/multichannel is mostly complete - resampleaudio being the most urgent for floats (but also the most difficult.
Plugin support. Filters aren't compatible. I expected this to be a major uproar, but people has taken this very well. I have done the most possible to help plugin writers convert - by making the changes mostly internal. There might still be one significant change in the plugin support, but it should only take 2 seconds for filter writers to change their code. So plase: Don't label your 2.5 filters "final", until the beta.
Future support. Soon I will go through avisynth.h, and look at how we can support the most new features in the future without having to change the specs again. At some point we'll probably have to again, but hopefully 2.5 will last as long as 1.0.
Filter Information. (Filters being able to give information about how they operate).This is the one thing I still feel should make it into 2.5. I hope I get the time to finish a GOOD proposal for a way of soing this - otherwise it will not make it into 2.5


So for the 2.5 beta we're mostly talking about cleaning up the internals - not many new features. 2.5 is basically a new framework, and not as much about new features. So there'll still be work to be done on 2.5.1, 2.5.2 and so on :)

[cult]

I downloaded the new vdmod 1.4.11.1,koepis 9/11 xvid build,avisynth alpha 2.5(7/11 build)and marcs 0,9 mpeg3dec.Installed everything under win98 partition so I wont get a mess with my avisynth 2.06.I guess everything worked.I got a 2pass short clip that looked great!!!Speed improvement about 25-30%.Also used c3dyv12.Amazing all.Thank u guys!!!
My only dissapointment:couldnt use trim.Please,please is there any way I can use it or have to wait?

[iago]

@cult

Atm, I'm using Trim for some short test encodes with AviSynth Alpha 2.5 (7-11-2002), Koepi's 09112002-1 build, Marc's MPEG2Dec3.dll (v0.9) and VirtualDubMpg2 (modified by Shodan) ;).

regards,
iago

[cult]

didnt anyone try yet vdmod 1.4.11.1?It seems to work now with yv12

[Pasqui]

@cult
Yes it works perfectly ;)

[sh0dan]

Originally posted by cult
My only dissapointment:couldnt use trim.Please,please is there any way I can use it or have to wait?
Trim shouldn't be affected at all by any 2.5 changes, so your problem is probably in the script or elsewhere.

[Wilbert]

Overall I think it's time to stabilize the code and get a beta finished. This should include bugfixes in ALL filters - and update of documentation.

I'm not sure how to adjust to documentation. Consider for example the faq. Parts of section 2, 3 and all of section 5 is only applicable to v2. There are basically three options:

[list=1]
Make a separate faq for v2.5.
Make a new section 6 for v2.5 related stuff, and say explicitly which questions of the other sections are only applicable to v2.
Integrate if fully without making a new section.
[/list=1]

Personally I would vote for the second option. I think it is best to have a separate section for v2.5. Any other ideas?

[WarpEnterprises]

I am also voting for merging the new things in the existing docu and making them explicitly visible, e.g. adding a chapter and/or flagging them "2.5 only".
@RB/sh0dan: Btw. I will add a german translation of the 2.6 docu soon, which I think would be best in a separate dir ..\doc_ger\..
Is this ok and could it be included in future release versions?

[sh0dan]

@WE: Sounds great - I'll make a separate optional selection in the installer for german documentation.

What's the timeframe for this? I'm thinking about doing a 2.07 release soon, so I'd like to know if I should wait for it.

[Wilbert]

Maybe you can wait till friday then I can sent an update of the faq to sourceforge.

[sh0dan]

Yes, yes - There are still a few issues I want to have solved before 2.07. :rolleyes:

[WarpEnterprises]

If I get along as scheduled I will be ready till next weekend (let's say saturday night)

[Belgabor]

Originally posted by sh0dan

Filter Information. (Filters being able to give information about how they operate).This is the one thing I still feel should make it into 2.5. I hope I get the time to finish a GOOD proposal for a way of soing this - otherwise it will not make it into 2.5



If I may interfere again ;)

Dont forget to do the same same for the internal filters, not only plugins. And some Boolean to find out if the filter is internal/plugin would be nice too :)
(In case you wonder, yes I'm working on something :p)

Cheers
Belgabor

[sh0dan]

@Belgabor: I would love to, but I'm not sure how good I will be able to support it.
The main problem is, that I'm not sure how well it would translate into a GUI program.
The current implementation will extend the PClip (inherited by GenericVideoFilter), so that you can walk through the filter chain and request information about each filter.
The problem is, that you're never calling the constructor directly, the filter is always created through the "Create" functions. That means that one function may create several clips.

Take resize for example. It has one create function for each filter type. This create function does some calculations based on the size you give. Then it (usually) puts on a ResampleH and ResampleV clip right after eachother. This completely destroys any information about how they were called. Many other filters operate this way.

The complely other way is to register these information the same way as "AVSFunction"'s are registered today. That way you cannot cannot use the filter chain to find out any information about the filters. Everything would have to be created by the GUI.

[Mr.Shine]

Originally posted by sh0dan

Plugin support. Filters aren't compatible. I expected this to be a major uproar, but people has taken this very well. I have done the most possible to help plugin writers convert - by making the changes mostly internal. There might still be one significant change in the plugin support, but it should only take 2 seconds for filter writers to change their code. So plase: Don't label your 2.5 filters "final", until the beta.



I think the reason why there was no "major uproar" yet is because Avisynth 2.5 is still stated as strictly alpha. Most people (and I'm including specifically me here ;-)) might be hoping that there WILL be a way of loading old filters into the final Avisynth 2.5, maybe even a way to autodetect new/old so autoloading mixed filters will work aswell.

[trbarry]

It does seem there should be a way of loading old filters, as long as they are allowed to be confused if they get YV12 data. But I'm not sure what the answer is.

- Tom

[Richard Berg]

The only real incompatibility with old plugins is the DLL linkage, not the lack of new features (though of course they'll be buggy if fed YV12 or floating-point audio or what have you). The first (very ugly) method that comes to mind is to add something like #include "avisynth.old_h" and wrap it in a different namespace.

In general, though, I don't see this being a problem. The more "final" 2.5 gets, the more important widespread support is, but then again the motive to go back and recompile plugins increases at the same rate, recalling that at least 90% of plugins are open-source.

Filter Information. (Filters being able to give information about how they operate).This is the one thing I still feel should make it into 2.5. I hope I get the time to finish a GOOD proposal for a way of soing this - otherwise it will not make it into 2.5
I probably don't have much say in things these days, but FWIW this is the most important feature to me. (Yes, I too am working on "something.") It's also the hardest to get right; I suggest a thread of its own...

[sh0dan]

I probably don't have much say in things these days, but FWIW this is the most important feature to me. (Yes, I too am working on "something.") It's also the hardest to get right; I suggest a thread of its own...

Your opinion is very welcome!
My currently best solution is a registering function, much like the one currently registering filters today, but it supplies one or more function to AviSynth, from which it can read parameters and descriptions.
The function could be something like the one I put into levels.cpp (Tweak::FilterInfo). AviSynth can request several types of information, and the filter then has to return information.

Perhaps the information function could be passed as a fourth parameter, when the plugin or internal filter registers a command??

[Bidoche]

@sh0dan

To me, it seems right that the the filter info must be passed to avisynth at registration,
that way a gui can present choices about possibles filters without hardcoding.

Let's say you use a FilterInfo struct (or class) as only parameter at filter registration
(the others params should be derived from it (maybe not the create function but name and parameter list are desired filter info))

Then each PClip could return too this info about the filter who created it, with maybe something more to get the values of the parameters.

I hope I helped.

[jarthel]

I assume that 2.5 is backward compatible with YUV2. right?

I don't use Xvid and it seems I need to use Xvid to appreciate YV12.

jayel

[Richard Berg]

@jarthel -- yes, all the old colorspaces [should] work

@shodan -- I think it would be better to pass a struct with the actual info rather than a query-function. The latter is a lot of overhead for both the filter programmer & user. Something like:


// put this somewhere
struct FilterArg {
char type;
bool optional;
string name;

AVSValue min;
AVSValue max;
AVSValue default;

string description;
}

struct FilterInfo {
int type;
int inputColorspace;
string name;
string author;
string version;
string description;

vector<FilterArg> args;
}


// currently in internal.h
struct AVSFunction {
const char* name;
const char* param_types;
AVSValue (__cdecl *apply)(AVSValue args, void* user_data, IScriptEnvironment* env);
FilterInfo* filterInfo; // I searched a bit, pretty sure the old 'user_data' isn't ever used
};


// in avisynth.h
class IClip
{
public:
// ...
virtual FilterInfo * __stdcall getFilterInfo(IScriptEnvironment* env) {
if (filterInfo) {
return filterInfo;
} else {
env->ThrowError("Plugin provides no filter info");
}
}

// ...
virtual __stdcall ~IClip() { if (filterInfo) delete filterInfo }

private:
// ...
FilterInfo * filterInfo;
}


class IScriptEnvironment {
public:
// ...

virtual void __stdcall AddFunction(const char* name, const char* params, ApplyFunc apply, FilterInfo* filterInfo) = 0; // one of many mentions of user_data that should be changed
virtual FilterInfo* __stdcall GetFilterInfo(string filterName) = 0; // implement as simple lookup + call to Foo::getFilterInfo
virtual vector<string> __stdcall ListFunctions() = 0; // another very helpful addition, implementation left as exercise ;)


// in avisynth.cpp
[implementation of new ScriptEnvironment functions above]

// in foo.cpp
AVSFunction Foo_filters[] = {
{ "Foo", "cifiii", Foo::Create } // no change necessary
// ...
}

Foo::Foo ( ... )
{
// ...

filterInfo = new filterInfo;
filterInfo.name = "Foo";
// etc.
}


That's the first thing that comes to mind, anyway. Might be a bit cleaner to have the "user" be in charge of managing the memory allocation of FilterInfo's instead, but having the base class handle the grunt work fits in with what I perceive to be the general Avisynth design...

[Richard Berg]

Other things to consider as future release milestones (not necessarily 2.5):


Review internal filters. Add some (rotate, Marc's optimized blur2/sharpen2, temporalsmoother from mpegdec.dll?), remove some (arcane stuff like peculiarblend). Automatic plugin loading makes the difference between plugins & internal filters much less noticeable, but there's still something to be said for having "core" filters in the core and exotic stuff in plugins.
Revise license as we discussed a few months ago; add link to Avisynth.org & SourceForge in each text block; update copyright notice with current date, authors, & version.
Rewrite parser to provide 'hooks' that can be used by the script environment (and thus, GUIs & other programs), as well as fix currently intractable bugs like this (http://sourceforge.net/tracker/index.php?func=detail&aid=591299&group_id=57023&atid=482673) and this (http://sourceforge.net/tracker/index.php?func=detail&aid=635813&group_id=57023&atid=482673)
Change the way field/frame based video is represented so that it's consistent throughout the various info structs. If we decide it can't be determined reliably by Avisynth itself, then leave either leave it up to plugin authors (no support at all) or users (keep relevant VideoInfo fields uninitialized until AssumeFrame/FieldBased is encountered, add AssumeTop/BottomFirst functions that are treated similarly) or some combination.
Standardize, or at least discuss, how we're going to support optimizations. What's the oldest CPU we'll support? How should multiple ASM versions of functions be maintained?
Long shot: code cleanup. Get rid of __function decorations, review const correctness, review portability, add lots more comments, begin process of converting to idiomatic C++/STL types, remove dependencies on C library...

[jarthel]

how about SSE2? :)

jayel

[sh0dan]

Originally posted by Richard Berg

Review internal filters. Add some (rotate, Marc's optimized blur2/sharpen2, temporalsmoother from mpegdec.dll?), remove some (arcane stuff like peculiarblend). Automatic plugin loading makes the difference between plugins & internal filters much less noticeable, but there's still something to be said for having "core" filters in the core and exotic stuff in plugins.


Peculiarblend, ShowFiveVersions, FixLuminance, DeleteFrame, maybe Bob & Spatialsoften are something that I have hard to see as "core" funtionality.
I think Marc is already working on integrating the new blur.

Revise license as we discussed a few months ago; add link to Avisynth.org & SourceForge in each text block; update copyright notice with current date, authors, & version.

2.5 could be a nice time to do this. Do you have the time?


Rewrite parser to provide 'hooks' that can be used by the script environment (and thus, GUIs & other programs), as well as fix currently intractable bugs like this (http://sourceforge.net/tracker/index.php?func=detail&aid=591299&group_id=57023&atid=482673) and this (http://sourceforge.net/tracker/index.php?func=detail&aid=635813&group_id=57023&atid=482673)

I'm not that much into the script parser, so I have ignored this. I think that hooks for GUI's will be a very good thing!

Change the way field/frame based video is represented so that it's consistent throughout the various info structs. If we decide it can't be determined reliably by Avisynth itself, then leave either leave it up to plugin authors (no support at all) or users (keep relevant VideoInfo fields uninitialized until AssumeFrame/FieldBased is encountered, add AssumeTop/BottomFirst functions that are treated similarly) or some combination.

This is still a big issue. I've just mostly ignored it, and left it as it has been until now (it _mostly_ works). To be honest, I'm not 100% sure how GetParity is supposed to work. My suggestion is to add this information to videoinfo, like this: // Colorspace properties.
enum {
CS_BFF = 1<<25,
CS_TFF = 1<<26,
CS_FIELDBASED = 1<<27,
CS_BGR = 1<<28,
CS_YUV = 1<<29,
CS_INTERLEAVED = 1<<30,
CS_PLANAR = 1<<31
};
And then adding IsTFF() and IsBFF() and IsParityKnown() to the VideoInfo struct.


Standardize, or at least discuss, how we're going to support optimizations. What's the oldest CPU we'll support? How should multiple ASM versions of functions be maintained?

MMX should IMO be defined as minimum - Resize functions havne't worked on non-MMX machines since version 1.something, so I'm pretty sure that no-one will care if we set this as minimum.


Long shot: code cleanup. Get rid of __function decorations, review const correctness, review portability, add lots more comments, begin process of converting to idiomatic C++/STL types, remove dependencies on C library...

I'm actually quite new in C++ - my background is actually java-programming - so I don't know much about this. What would this mean in real life?

[sh0dan]

Originally posted by jarthel
how about SSE2? :)

Well, if you buy me a P4 machine ;)

OK - Someone with SSE2 skills are free to take up this. For now I keep to ISSE - just look at the CPU-poll on xvid.org for why this makes sense.

[sh0dan]

Originally posted by Richard Berg
@shodan -- I think it would be better to pass a struct with the actual info rather than a query-function. The latter is a lot of overhead for both the filter programmer & user. Something like:
[...]
That's the first thing that comes to mind, anyway. Might be a bit cleaner to have the "user" be in charge of managing the memory allocation of FilterInfo's instead, but having the base class handle the grunt work fits in with what I perceive to be the general Avisynth design...
Seems very nice and clean - much less for the plugin writer to do.
Could you explain how the "vector<FilterArg> args;" would be defined (by a filter) - I haven't used this before. Could you give an example?

(It seems a bit agressive to throw an error, if no FilterInfo is found :devil: )

btw, nice to have you here again - you've been missed :)

[Bidoche]

@sh0dan

Damn, for someone new to C++, you are already quite the man :eek:

I am no C++/STL guru myself (more into java too) so I can't point you to useful info.
but I can say this : STL stands for stantard template library and is a set of templated container classes with pointer-like iterator to go through them (and ...)
You can find there more or less the equivalent of the java Vector, LinkedList, Map, Set....
You have a string class to replace the poor char* (it's more like the java String, it knows how to do some tricks :p)

[Nic]

tip:
at the start of the header add:
#include <vector>
using namespace std;

// then you can add:
vector<FilterArg> args;

// (if FilterArg is a class)

//an example of how to access and iterate the vector

vector<args>::iterator itrArg;
for (itrArg = args.begin(); itrArg != args.end(); itrArg++)
{
(*itrArg).Whateverparameter = 5;
}

etc etc :)

-Nic

[Bidoche]

vector<FilterArg> args(5); //if 5 is the arg count (it's an initial size, vector increase size as needed)

//create the FilterArg here

args.push_back(arg1);
args.push_bash(arg2);
....

to go through the vector u can use:
for(int = 0; i < args.size(); i++) {
//work with args[i];
}
or
for(vector<FilterArg>::iterator p = args.begin(); i != args.end(); i++) {
//work with *p
}

here is a page about STL vector operation (it's not that clear, sorry)
http://www.sgi.com/tech/stl/Vector.html

Edit: damn i am too slow at typing :p

Edit2: http://www.fredosaurus.com/notes-cpp/stl/header-vector.html is better

[Belgabor]

Originally posted by Richard Berg



struct FilterInfo {
int type;
int inputColorspace;
string name;
string author;
string version;
string description;

vector<FilterArg> args;
}



Does this include the info if the filter is internal or external or is it some other stuff?




class IScriptEnvironment {
public:
// ...

virtual void __stdcall AddFunction(const char* name, const char* params, ApplyFunc apply, FilterInfo* filterInfo) = 0; // one of many mentions of user_data that should be changed
virtual FilterInfo* __stdcall GetFilterInfo(string filterName) = 0; // implement as simple lookup + call to Foo::getFilterInfo
virtual vector<string> __stdcall ListFunctions() = 0; // another very helpful addition, implementation left as exercise ;)
virtual vector<string> __stdcall ListKeyWords() = 0;
virtual vector<string> __stdcall ListInternalFunctions() = 0;
virtual vector<string> __stdcall ListExternalFunctions() = 0;





This being an alternative/addition to the above. (with keywords i mean stuff like 'last', 'return', 'end', 'int' etc.)

Cheers
Belgabor

P.S: Richard, sh0dan pm me if you want a preview of what I'm doing ;)

[Bidoche]

I just tried converting the FunctionTable class from avisynth.cpp to STL.
There are probably some errors in it but i think it is illustrates STL enough.


class AVSFunction {
string name;
string param_types;
AVSValue (__cdecl *apply)(AVSValue args, void* user_data, IScriptEnvironment* env);

AVSFunction(string _name, string _param_types) : name(_name), param_types(_param_types) { }

~AVSFunction() {
delete name;
delete param_types;
}
};

class FunctionTable {

class Plugin {
string name;
vector<AVSFunction> plugin_functions(1);

Plugin(string _name) : name(_name) { }

~Plugin(){
delete name;
delete plugin_functions;
}
};

//predicate object for using with the find algorythm
class AVSmatch {
string * name;
vector<AVSValue> * args = 0;
bool strict;

AVSmatch(string * _name, vector<AVSValue> * _args) name(_name), args(_args) { }

AVSmatch(string * _name) name(_name) { }

bool operator() (AVSFunction& avs) {
return avs.name == *name && args != 0 && TypeMatch(itrAVS->param_types, args, strict&1, env);
}
};

vector<AVSFunction> local_functions(0);
vector<Plugin> plugins(0);
bool prescanning, reloading;

IScriptEnvironment* const env;

public:

FunctionTable(IScriptEnvironment* _env) : env(_env), prescanning(false), reloading(false) { }

~FunctionTable() {
delete local_functions;
delete plugins;
}
}

void StartPrescanning() { prescanning = true; }
void StopPrescanning() { prescanning = false; }

void PrescanPluginStart(string name)
{
if (!prescanning)
env->ThrowError("FunctionTable: Not in prescanning state");
_RPT1(0, "Prescanning plugin: %s\n", name);
plugins.push_back(new Plugin(name));
}

void RemovePlugin(Plugin& p) {
plugins.erase(find(plugins.begin(), plugins.end(), p):
}

void AddFunction(string name, string params, IScriptEnvironment::ApplyFunc apply) {
if (prescanning && plugins.empty())
env->ThrowError("FunctionTable in prescanning state but no plugin has been set");
AVSFunction f = new AVSFunction(name, params);
if (!prescanning) {
f.apply = apply;
local_functions.push_back(f);
} else {
_RPT1(0, " function %s (prescan)\n", name);
plugins.back().plugin_functions.push_back(f);
}
}

AVSFunction* Lookup(string * search_name, vector<AVSValue> * args, bool* pstrict) {
vector<AVSFunction>::iterator itrAVS;
vector<Plugin>::iterator itrPlug;
AVSmatch arg_match(search_name, args);
for (int strict = 1; strict >= 0; --strict) {
arg_match.strict = (*pstrict = strict&1);
// first, look in loaded plugins
if ( (itrAVS = find(local_functions.begin(),
local_functions.end(),
arg_match ))
!= local_functions.end() )
return &(*itrAVS);
// now looks in prescanned plugins
for (itrPlug = plugins.begin(); itrPlug != plugins.end(); itrPlug++)
if ( (itrAVS = find(itrPlug->plugin_functions.begin(),
itrPlug->plugin_functions.end(),
arg_match ))
!= itrPlug->plugin_functions.end() ) {
_RPT2(0, "Loading plugin %s (lookup for function %s)\n", itrAVS->name, itrPlug->name);
// sets reloading in case the plugin is performing env->FunctionExists() calls
reloading = true;
LoadPlugin(AVSValue(&AVSValue(&AVSValue(itrAVS->name), 1), 1), (void*)false, env);
reloading = false;
// just in case the function disappeared from the plugin, avoid infinte recursion
RemovePlugin(*itrPlug);
// restart the search
return Lookup(search_name, args, pstrict);
}
// finally, look for a built-in function
if ( (itrAVS = find(local_functions.begin(), //i consider builtin_functions is a vector too
local_functions.end(),
arg_match ))
!= local_functions.end() )
return &(*itrAVS);
}
return 0;
}

bool Exists(string * search_name) {
vector<AVSFunction>::iterator itrAVS;
vector<Plugin>::iterator itrPlug;
AVSmatch same_name(search_name);
if ( find(local_functions.begin(), local_functions.end(), same_name )
!= local_functions.end() )
return true;
if (!reloading)
for (itrPlug = plugins.begin(); itrPlug != plugins.end(); itrPlug++)
if ( find(itrPlug->plugin_functions.begin(),
itrPlug->plugin_functions.end(), same_name )
!= itrPlug->plugin_functions.end() )
return true;
if ( find(builtin_functions.begin(), builtin_functions.end(), same_name )
!= local_functions.end() )
return true;
return false;
}

static bool SingleTypeMatch(char type, const AVSValue& arg, bool strict) {
switch (type) {
case '.': return true;
case 'b': return arg.IsBool();
case 'i': return arg.IsInt();
case 'f': return arg.IsFloat() && (!strict || !arg.IsInt());
case 's': return arg.IsString();
case 'c': return arg.IsClip();
default: return false;
}
}

bool TypeMatch(string * param_types, vector<AVSValue> * args, bool strict, IScriptEnvironment* env) {

bool optional = false;

string::iterator it = param_types->begin();

for (int i=0; i<args->size(); ++i) {

if (it == param_types->end()) {
// more args than params
return false;
}

if (*it == '[') {
// named arg: skip over the name
it = find(it, param_types->end(), ']');
if (it == param_types->end())
env->ThrowError("TypeMatch: unterminated parameter name (bug in filter)");
++it;
optional = true;
}

if (it[1] == '*') {
// skip over initial test of type for '*' (since zero matches is ok)
++it;
}

switch (*it) {
case 'b': case 'i': case 'f': case 's': case 'c':
if ((!optional || args[i].Defined()) && !SingleTypeMatch(*param_types, args[i], strict))
return false;
// fall thru
case '.':
++it;
break;
case '+': case '*':
if (!SingleTypeMatch(it[-1], args[i], strict)) {
++it;
--i;
}
break;
default:
env->ThrowError("TypeMatch: invalid character in parameter list (bug in filter)");
}
}

// We're out of args. We have a match if one of the following is true:
// (a) we're out of params; (b) remaining params are named; (c) we're
// at a '+' or '*'.
return (*it == 0 || *it == '[' || *it == '+' || *it == '*');
}
};

[Marc FD]

hi ^^

about internal filters : i think avisynth should be able to do ALL the BASIC operations.

for me bobing IS a basic operation. so i'ld prefer it to stay in avisynth .
i'm speaking of dumb-classic-good-old bob here ^^
BTW, IMHO, current avisynth bob filter is crap. interpolating the complementary field on a frame basis seems more logical too me. but i'm not a deinterlace-guru ^^

you can throw out spatial soften, because nobody use it.

i'm going to update blur this WE, and if you're interressed, i can begin to code some YV12 rotate stuff ^^, i've some little ideas.

BTW, i don't like how PLANAR_Y,PLANAR_V and PLANAR_U are defined.
what about :

PLANAR_Y = 1,
PLANAR_V = 2,
PLANAR_U = 3,
PLANAR_ALIGNED = 0x08

makes more sense to me. or did i miss something.

and again :

// Colorspace properties.
enum {
CS_BFF = 1<<25,
CS_TFF = 1<<26,
CS_FIELDBASED = 1<<27,
CS_BGR = 1<<28,
CS_YUV = 1<<29,
CS_INTERLEAVED = 1<<30,
CS_PLANAR = 1<<31
};


can you have both CS_BGR and CS_YUV ? both CS_INTERLEAVED and CS_PLANAR ?? both CS_BFF and CS_TFF ??

i think flags should be used only when it's logical, like the CPU flags, who are defined a very logical way.

> MMX should IMO be defined as minimum - Resize functions havne't worked
> on non-MMX machines since version 1.something, so I'm pretty sure
> that no-one will care if we set this as minimum.

of course, MMX is the minimum required. but keeping old C code is very usefull for documentation, because it's more human-readable. i wouldn't be able to understand the MMX resampling stuff without the old C version ^^

it's GPL software, we are here to share our skills and knowledge to do something great ^^. so keeping documentation on the source is a good thing. if you read virtualdub's filters sources, you would see that sometimes, there is no C code avaible (because avery optimised everything ^^) and it's a really harder to understand how it works. ar least for me :D

Cheers,
MarcFD

[sh0dan]

Originally posted by Marc FD
[B]
BTW, i don't like how PLANAR_Y,PLANAR_V and PLANAR_U are defined.
what about :

PLANAR_Y = 1,
PLANAR_V = 2,
PLANAR_U = 3,
PLANAR_ALIGNED = 0x08

makes more sense to me. or did i miss something.

In general you shouldn't care (as filter/plugin writer) how these are defined - just should NOT rely on them. Use the enums - that's why they are there!

This is mainly for future implementations. It's not difficult to imagine a function, where you for example will have it process one or more planes, then you cannot give it any parameters like "Process planeY and U, but not V".

I see you use these values in Blur2 - don't! They may change, and the day they do, your filter will have a bug.


and again :

// Colorspace properties.
enum {
CS_BFF = 1<<25,
CS_TFF = 1<<26,
CS_FIELDBASED = 1<<27,
CS_BGR = 1<<28,
CS_YUV = 1<<29,
CS_INTERLEAVED = 1<<30,
CS_PLANAR = 1<<31
};


can you have both CS_BGR and CS_YUV ? both CS_INTERLEAVED and CS_PLANAR ?? both CS_BFF and CS_TFF ??

Again, I made this, so we didn't have to rewrite avisynth again. Using fixed values (and variables) would make it impossible to add another colorspace (or property) without changing the internal structures again.

- If we use a CS_YUV, and it means that it is RGB, when it is false - then we can't in any way add another colorspace.
- Interleaved/Planar, same thing - there are other possibilities.
- CS_BFF, CS_BFF - if both are false, we don't know how this videoclip is interlaced.


i think flags should be used only when it's logical, like the CPU flags, who are defined a very logical way.

I don't get it - what's more logical about that? And how does it affect your code?

[scmccarthy]

begin process of converting to idiomatic C++/STL types, remove dependencies on C library...

How is it a good thing to remove dependence on the C library and a good one to embrace a depence on the STL? Their both libraries.

Avery wrote his own version of vector. The top of his header file reads:

// Okay, so this is a poor man's STL vector. I'd rather not drag in the STL

Maybe you would like to look at Avery's version of vector.h and the source files he uses them in:

[jarthel]

Originally posted by sh0dan
Well, if you buy me a P4 machine ;)

OK - Someone with SSE2 skills are free to take up this. For now I keep to ISSE - just look at the CPU-poll on xvid.org for why this makes sense.

we are talking about Avisynth here not Xvid. :)

Why not conduct an avisynth poll?

jayel

[Richard Berg]

@jarthel -- I have a feeling the ratio of users is about the same, since Avisynth is mostly an enthusiast's tool (for now...) It will be many years before we can assume an SSE2 baseline, though, so finding a way to incorporate optimizations without breaking stuff / bloating code / etc. is a higher priority (for the core -- plugin authors are free to do as they please, of course) than actually adding SSE2 at this point.

How is it a good thing to remove dependence on the C library and a good one to embrace a depence on the STL? Their both libraries.
Fundamentally, the C library is incompatible with C++ paradigms; the quasi-language that masquerades as "C/C++" is IMHO an abomination that showcases the strengths of neither language while capitalizing on the flaws of each :) On a pragmatic level, C is a pain in the butt for designing large programs (for users, think of that as more time spent on stupid bugs vs. adding cool features) and often significantly slower. Of course, trying to rewrite everything is a much greater folly than adapting to stuff that (if nothing else) works, but gradual refactoring of old code should be a goal of any major project.

Avery is a really smart dude, but I'd never consider using VirtualDub as an example of readable/maintainable code.

[scmccarthy]

@Richard Berg

If I step back and examine my resistance to any lib, it is because I just started compiling avisynth 2.5a filters with Microsoft's cl.exe from the winxp ddk. I'd like to minimize dependance on libs for speed and simplicity, but also because I am not sure if have the STL libs at all.

In avisynth.h, I renamed BYTE to unsighed char and add the line:

#define _ASSERTE(expr) ((void)0)

Little dependancies to specific development environments have a way of sneaking in unnoticed. So far, avisynth is extremely spare in its demands on the programmer and the programming environment it needs. Right now, I would rather research the specs on mpeg-2, color spaces, and Linear Algebra than brush up on object oriented programming. Hopefully, avisynth will continue to be easy to write filters for and extremely flexible in it's scripting. Ben was very clever in how he wrote avisynth; it has the potential to be different from any other tool. I get nervous when people talk about making avisynth easier to use, because ultimately flexibility and ease of use contradict one another. A tool will become less useful as it becomes easier to use.

[Richard Berg]

Fear not -- if anything, an even bigger goal is to improve portability (read: minimize dependencies) to the point where it runs on Linux or OSX with a simple recompile. More minor but along the same lines, I certainly intend to keep plugin development as easy as possible for both newcomers & current authors.

The STL isn't really a "library" in that it exists in source form, not something to be linked in. Any popular compiler should support it out of the box (some better than others -- VC6's many template bugs are certainly a concern to watch out for). It is explicitly designed to be "speedy & simple".

Avisynth's cleverness, if you ask me, comes from the "C++ part" of its design -- for example, overloading new/delete operators so that client code has easy access to ref-counted ("smart") IClips.** Its reliance on C-style character buffers, on the other hand, is merely a PITA.

Note: I certainly do NOT intend to mess with the OS hooks until absolutely necessary (porting to other systems). Nevermind that it's very sensitive & prone to inducing weird incompatibilities -- more to the point, no amount of clever design can make Win32 pretty :)


**However, based on conversations with Edwin & others, I'm not still not convinced the implementation is bug-free. This illustrates the point perfectly: simply typedef-ing PClip as a std::auto_ptr or boost::scoped_ptr or similar would have worked equally well and removed the need to reinvent the wheel (introducing code complexity, bug potential, maintainance necessity, etc. in the process). In fairness to Ben, of course, these tools were quite new in 1998 and not always supported by compilers of the day.

[Belgabor]

Considering the filter info stuff we discussed earilier.

I have to take back some of what I said. After reconsideration I have to say that <vector> stuff should NOT be used as return value or parameter of any info exchange function. While this may work in c/c++, many gui programmers, including myself, might use other programming languages. (And I get nightmares thinking about how to deal with that in delphi...)

So I'd say simple functions like

int GetFilterCount();
(Filterinfo *) GetFilterInfo(int n);

should be used.

Cheers
Belgabor

[Wilbert]

YV12 support seems to be a good thing. I wasn't very sure of how much we would benefit from it, but it seems to be worth the big efford. The list of buggy filters is getting shorter and shorter. YV12 support seems stable now, and with the new release of VirtualDubMod and XVID we have the programs needed to support them.

A dozen of times I tried to encode the movie gladiator. I'm using VDubMod 1.4.11.1 (after installing VDubMod 1.4.11), newest MPEG2DEC3, tried with DivX5.02 pro and the latest couple of Koepi builds (4/11, 9/11). My avs script only contains crop+resize (everything mod 4). Everytime it keeps crashing during the first or second pass. (I also tried different versions of AviSynth 2.5.)

When I add the line ConvertToYUY2 at the bottom, encoding to DivX5.02 (2 pass, standard settings) works fine.

I will post this at sourceforge, but it is very frustrating.

btw, I'm using Win98SE + Athlon 1.2 GHz.

[Gaia]

I have encoded five movies with Avisynth 2.5 and Xvid without any crashes.

[Didée]

Hello,

though working in YV12 works like a charm in general, sometimes I have the following effect:

At some time during the encoding, the picture stalls. The encoding finishes up to the correct end frame number, but the end of the avi contains only one still picture, sometimes jumping around a bit.

This is no playback problem: Looks the same in Virtualdub (whichever version), and a look at the stats file gives the proof.

I don't see where the bug is buried: VirtualDubMod, mpeg2dec3, XviD/Divx5-YV12-decoding ??

(Everything is set up properly for YV12-support, and the script may even be as simple as avisource-crop-resize-return, respecting MOD8 in every step.)

As I said, most times everything works flawless, but the above phenomenon sometimes appears.
A friend of mine sometimes has the same problem, too.

Someone else noticed this ??

[Richard Berg]

@Belgabor -- I definitely agree on that point. Whatever happens internally, all of the exposed point should remain C interfaces. That means keeping the correct calling convention / name mangling too, of course, lest we forget.

BTW, don't take any of this discussion the wrong way: aesthetic & usability issues were way way down on my list for a reason. There is no compelling need to rip things apart now (or ever) as you might argue there was when we split everything into multiple files & launched the so-called v2.xx, and it certainly won't be the defining feature of any future version I can forsee. More practically, you don't fix what ain't broke :)

[Gaia]

Originally posted by Didée
Hello,

though working in YV12 works like a charm in general, sometimes I have the following effect:

At some time during the encoding, the picture stalls. The encoding finishes up to the correct end frame number, but the end of the avi contains only one still picture, sometimes jumping around a bit.

This is no playback problem: Looks the same in Virtualdub (whichever version), and a look at the stats file gives the proof.

I don't see where the bug is buried: VirtualDubMod, mpeg2dec3, XviD/Divx5-YV12-decoding ??

(Everything is set up properly for YV12-support, and the script may even be as simple as avisource-crop-resize-return, respecting MOD8 in every step.)

As I said, most times everything works flawless, but the above phenomenon sometimes appears.
A friend of mine sometimes has the same problem, too.

Someone else noticed this ?? I have done lot of testing with Xvid and YV12 and never have seen anything like this. I have some very strange hardware problems sometimes but no nothing like this.

[JohnMK]

Humbly request that SelectRangeEvery be worked into the latest build of Avisynth.

[trbarry]

Maybe a relate bug to above. In the YV12 interlace/TomsMoComp thread (http://forum.doom9.org/showthread.php?s=&threadid=37915) I wrote:I noticed there is a bug with Avisynth 2.05 and MPEG2DEC3_YV12 on the Video Essential Montage, the torture test. It causes strange ghosting and wierd effects when it swithes back from video to film source. But it was a problem even without TomsMoComp, so I released this anyway.

and Marc FD replied:
i noticed it a while ago. it's not a MPEG2Dec3 bug, because it happens with XviD too. the problem is in Avisynth internals. i think some planar code is missing in the cache, or something like that. (looks like missed memcpy's for U and V planes for me)


I can easily reproduce this, with no filters.

And can anyone tell me the correct way in a filter to ask Avisynth for the current TopFirst (parity) value, or to tell Avisynth that a YV12 clip is now Frame Based (progressive)?

I put code in YV12 TomsMoComp for both, but don't trust it.

- Tom

[vinetu]

Bug report
Originally posted by Didée
Hello,

though working in YV12 works like a charm in general, sometimes I have the following effect:

At some time during the encoding, the picture stalls. The encoding finishes up to the correct end frame number, but the end of the avi contains only one still picture, sometimes jumping around a bit.

Just to conform - same here (windowsXP sp1)
@Gaia: what is your OS?

However I think that trbarry's question is MORE IMPORTANT !

[jarthel]

shouldn't this thread be moved to the developer section? regular avisynth users won't have a clue to have you are talking about (C++ code). :)

It'll get less publicity but then the thread is mainly for beta testers and programmmers.

just a thought.

[Wilbert]

Sorry I lied, "When I add the line ConvertToYUY2 at the bottom, encoding to DivX5.02 (2 pass, standard settings) works fine." results also in crashes. I will do more tests.

I encountered two other bugs:

1) Adding a line ConvertToYUY2 results in an error message that the width/height must be a multiple of four (I know that this must be the case for YV12).

2) When loading a divx4 file in avisynth and adding the line ConvertToYUY2 (ConvertToYV12 gives exactly the same results) results in a clip like this: (see attachment) I didn't test divx5/xvid clips.

[NiTroGen]

Originally posted by Didée
At some time during the encoding, the picture stalls. The encoding finishes up to the correct end frame number, but the end of the avi contains only one still picture, sometimes jumping around a bit.I have this problem when using AVS2AVI. If I encode with VirtualDubMod I get this error "Avisynth: caught an access violation attempting to write to 0xfffff7ff". It's always the same memory address. I have Win2K-SP3 installed.

[JohnMK]

Shodan or somebody else perhaps?

Would you be willing to recompile the alpha with the latest additions? Vlad59 added SelectRangeEvery, amongst other modifications I suppose.

[CruNcher]

At some time during the encoding, the picture stalls. The encoding finishes up to the correct end frame number, but the end of the avi contains only one still picture, sometimes jumping around a bit.


The combination of this (order) gets rid off it (for me) hope it helps :)

MPEG2Source("D:\uranusproject.d2v",idct=5,iPP=false)
SelectOdd()
DoubleWeave
TomsMoComp(0,0,0) <- important other values destroy some frames
Convolution3D(preset="vhsBQ")
BicubicResize(512,384)

[Bidoche]

Rewrite parser to provide 'hooks' that can be used by the script environment (and thus, GUIs & other programs), as well as fix currently intractable bugs like this and this
I'm not that much into the script parser, so I have ignored this. I think that hooks for GUI's will be a very good thing!
I just looked into the parser code and I think we can fix the negation bug like this :

PExpression ScriptParser::ParseAddition(bool negationOnHold) //update exterior calls to ParseAddition(false)
{
PExpression left = ParseMultiplication(negationOnHold);
bool plus = tokenizer.IsOperator('+');
bool minus = tokenizer.IsOperator('-');
bool doubleplus = tokenizer.IsOperator('++');
if (plus || minus || doubleplus) {
tokenizer.NextToken();
PExpression right = ParseAddition(minus);
if (doubleplus)
return new ExpDoublePlus(left, right);
else
return new ExpPlus(left, right); //no longer ExpMinus 'right' will be negated when needed
}
else
return left;
}

PExpression ScriptParser::ParseMultiplication(bool negationOnHold)
{
PExpression left = ParseUnary();
bool mult = tokenizer.IsOperator('*');
bool div = tokenizer.IsOperator('/');
bool mod = tokenizer.IsOperator('%');
if (mult || div || mod) {
tokenizer.NextToken();
PExpression right = ParseMultiplication(false);
if (mult)
left = new ExpMult(left, right);
else if (div)
left = new ExpDiv(left, right);
else
left = new ExpMod(left, right);
}
if (negationOnHold) //negate the factorised result if needed
left = new ExpNegate(result);
return left;
}
Like this it does not substract, but add the opposite. (add in complexity)

By the way, it would probably be a good idea to rewrire parser/scanner as generated by a compiler compiler program (would be easier to modify/add features).
If nobody else is up to the task I can look into it.

[Richard Berg]

That would be nice indeed -- I'm not very good with bison, but it would sure be cool to have some of its features.

Along similar lines, has anyone else seen these revisions (http://sourceforge.net/tracker/index.php?func=detail&aid=638436&group_id=57023&atid=482676)? Dunno whom to thank, but looks sweet...

[sh0dan]

Originally posted by Wilbert
1) Adding a line ConvertToYUY2 results in an error message that the width/height must be a multiple of four (I know that this must be the case for YV12).

2) When loading a divx4 file in avisynth and adding the line ConvertToYUY2 (ConvertToYV12 gives exactly the same results) results in a clip like this: (see attachment) I didn't test divx5/xvid clips.

1) I added YUY2 Mod4 width requirement, because HuffYUV has bug with non-mod4 widths - it displays chroma garbage on the leftmost pixels. This is also the case for older versions! We could leave it out, but since both DivX and Xvid encodes garbage on non-mod4 widths, I dont' see much of a point.

2) I have experienced U/V swapping with MJPEG-files, but I haven't tested DivX4, but it seems like it also has the bug. I have planned of adding SwapUV, but haven't got around to it yet.

@JohnMK:

Humbly request that SelectRangeEvery be worked into the latest build of Avisynth.

Already done - not released yet, since I still have a bug in separatefields() I would like to fix. Also I haven't tested filter compatebility with my latest changes, and I don't want to break to much, too sudden.

@Richard:

Along similar lines, has anyone else seen these revisions? Dunno whom to thank, but looks sweet...

Yes, indeed! I'll see if I can get the time to implement them ASAP!

[Abond]

A report for encode with AviSynth2.5.
The source: reported from DVD2AVI as PAL, 4:3, interlaced, Running Man R2, about 144000 frames. The most weird source I have seen (well, only 80 videos, not big experience). Ghosting effects at movement, horizontal lines, blended frames at scene change - I assume bad 29,976>25, NTSC>PAL conversion.
The script:
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynth25\mpeg2dec3.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynth25\UnFilter.dll")
mpeg2source("C:\temp\runing.d2v")
trim(0,136800)
crop(12,72,680,434)
UnFilter(-20,-20)
BicubicResize(512,300,0,0.75)
resulted in thick green line at right side (but not at the edge see the image). Other weird thing is that after the first pass were reported about 129 000 encoded frames (see trim()), but at the end the whole movie was there. Without UnFilter() the encoding was correct (no green line, reported 136800 frames)
Oops, I'm sorry, don't know how to attach the image.

[HarryM]

'SegmentedAviSource' isn't implemented in v2.5, please???

[cult]

@abond
for the green line take a look in unfilter thread

[sh0dan]

Originally posted by HarryM
'SegmentedAviSource' isn't implemented in v2.5, please???
It isn't??? What happends when you use it?

[ErMaC]

Shodan - on the Mod4 requirement for converting to YUY2... I think it's a bad idea.

Say I have a filter chain and I need to convert a non-mode4-width video to YUY2 just so I can run a specific filter on it, then I convert back to RGB afterwards. I'm not planning on encoding anything in YUY2, I just need to use a YUY2 filter. Should I be forced to resize my video just so I can run said filter on it?

Instead of throwing an Assert() on the ConvertToYUY2, you could instead throw an Assert() if the return clip from the script is in YUY2 but isn't mod4. Thus:

Blackness(width=318,height=240,fps=30)
ConvertToYUY2()

will throw an exception when you open the AVIfile anyways, but:

Blackness(width=318,height=240,fps=30)
ConvertToYUY2()
ImaginaryFilter()
ConvertToRGB()

won't throw one.

I hope all that made sense. ^_^ probably shouldn't do too much thinking about video processing at 5AM.

[sh0dan]

Originally posted by ErMaC
Shodan - on the Mod4 requirement for converting to YUY2... I think it's a bad idea.

Mod 4 YUY2 is only for output, you can still use mod2 internally. Only, if you try to output an YUY2 with non-mod4, you'll get an error.

[ErMaC]

Ah OK guess we were both thinking the same thing then. :) Glad to hear it.

[Bidoche]

@Richard Berg

That would be nice indeed -- I'm not very good with bison, but it would sure be cool to have some of its features.

Bison does not do C++, I dunno if it may be a problem or not...
I am currently investigating CppCC (http://cppcc.sourceforge.net) who can do C++ and has some nice features too :)
And it has the advantage to produce both scanner and parser (only one prog to learn :p)

@all
I attached a first version of an avisynth grammar, tell me if it seems ok to you.
In it, Eval and co are considered normal function and so not considered.
I did not take into account the difference between avsfunctions ( which return clip) and script functions (which don't), but it can be done.

[Boulder]

Originally posted by sh0dan

2) I have experienced U/V swapping with MJPEG-files, but I haven't tested DivX4, but it seems like it also has the bug. I have planned of adding SwapUV, but haven't got around to it yet.


I've had U/V swapping when loading DivX3, 4 and 5 files in AviSynth. It seems that the DivX5.02 decompressor screws the colors up. PicVideo MJPEG files don't seem to have this problem.

Hope you'll get the SwapUV function added rather soon.

[Wilbert]

Another (possible?) bug: (maybe it is a bug of VDubMod)

When loading DivX5 clip with AC3 audio in VDubMod works fine, but making an avs-script (containing just AviSource(divx5+AC3)) and loading this in VDubMod doesn't work. VDubMod can't load the audio.

[mfluder]

Hi sh0dan,

It looks like I found a bug in Bicubic and LanczosResize while Bilinear looks fine. I am using latest alpha, but I tried also with older builds and the bug is there. I attached 3 screenshots in png format (Bicubic, Lanczos and Bilinear) where you can clearly see the bug. The best I can describe is that there are some strange white dots around letters. The script I used was very simple, and only contains croping and resizing:

LoadPlugin("D:\Ripping\Avisynth\plugins\MPEG2Dec3.dll")
mpeg2source("D:\Trailers\LePacte\LePacte.d2v")
crop(16,92,688,416)
BicubicResize(640,272,0,0.75)

mfluder

[sh0dan]

@mfluder: Interesting. Do you have a source (perhaps a very short huffyuv), so I can reproduce the bug? Does it help to put at Limiter() instruction before the resize?

@wilbert: Doesn't sound like it has anything to do with AviSynth - or is it me?

@all: Sorry for the lack of updates - I'm very busy at work atm. And I'm also rebuiling my home computer, and getting internet at home. So I hope to be back soon!

[mfluder]

Originally posted by sh0dan
@mfluder: Interesting. Do you have a source (perhaps a very short huffyuv), so I can reproduce the bug? Does it help to put at Limiter() instruction before the resize?

Yes, I have the source. I can make short huffyuv clip out of it. Just tell me if you want it to be full PAL resolution, or to crop the black borders or to resize it to some other size. The only problem is that I have a dial-up connection and currently I don't have any web space and huffyuv clips, even if very short, if in very high resolution can be very large in size. But if you give me your e-mail I'll send it to you. Oh yes, I also tried with Limiter() before resize but it doesn't help.

mfluder

[Wilbert]

@wilbert: Doesn't sound like it has anything to do with AviSynth - or is it me?

Maybe you are right. I will post it at the VDubMod page. But do you have any idea why it can't read the audio part of those files?

Is the audio converted to uncompressed 5.1 channel WAV when putting divx5+AC3 in an AviSynth script?

@all,

Regarding the problems I had: I installed AviSynth 2.5 11/11 and mpeg2dec3 v0.92 and the crashes (using divx5 or xvid) disappeared. I suspect the problems was mpeg2dec3 v0.90, but I'm not sure about that ...

[wing1]

@Sh0dan and @all

I am sorry to interrupt this thread with a request/question. I don't want to open another unnecessary thread for this.

2.5 version are great. I just recently switch over and all went well. I use tweak and convertfps functions on all my script. However, these functions still operate under yuy2 mode in 2.5 which means I have to do a converttoyuy2() to adjust and then converttoyv12(). My question is are these functions on the todo list or they are not to be converted?

[sh0dan]

Originally posted by wing1
I use tweak and convertfps functions on all my script. However, these functions still operate under yuy2 mode in 2.5 which means I have to do a converttoyuy2() to adjust and then converttoyv12(). My question is are these functions on the todo list or they are not to be converted?
ConvertFPS is not a hight priority. As for tweak, a C-version should be pretty fast to write (we can do assembler later). You could try ColorYUV - it has most of the tweak functionalities.

Originally posted by Wilbert
Is the audio converted to uncompressed 5.1 channel WAV when putting divx5+AC3 in an AviSynth script?
Yes - it might be a larger problem, that Vdub doesn't support >2 audio channel, except for direct stream copy. AVS2AVI will probably be able to handle this more gracefully.

[sh0dan]

@all: A new alpha has been uploaded - changes are:

* Added general property handling to avisynth.h (Also TFF, BFF to videoinfo - isn't reliable yet!)
* Added some debugging to avisynth.cpp
* Added the following planar (YV12) operators:
o SwapUV(clip) - Swaps chroma channels.
o UToY(clip) Copies chroma U plane to Y plane (image is now half as big)
o VToY(clip) as above, but V plane.
o YToUV(clipU,clipV) - puts the luma channels of the two clips as U and V channels. Image is now twice as big, and luma is 50% grey. Use MergeLuma, if you want to add luma values.
* Blankclip now works!
* Fixed bug in chroma horizontalreduceby2.
* Fixed ceil, floor and round functions.
* Added following functions to script: IsRGB24(), IsRGB32(), VersionNumber(), VersionString(), Int(float), Frac(float), Float(int), Value(string), HexValue(string). (feature request [ 636143 ]). Needs to be documented!
* Version is now defined in internal.h


I also made i priority list for 2.5 beta, 2.5 release and 2.5.1 - feel free to comment!

[sh0dan]

Originally posted by Bidoche


PExpression ScriptParser::ParseAddition(bool negationOnHold) //update exterior calls to ParseAddition(false)
{
[...]
}

PExpression ScriptParser::ParseMultiplication(bool negationOnHold)
{
[...]
if (negationOnHold) //negate the factorised result if needed
left = new ExpNegate(result);
return left;
}

Like this it does not substract, but add the opposite. (add in complexity)


I assume left = new ExpNegate(result); should be left = new ExpNegate(left);? How well is this tested? I don't want to break anything, since we're about to do 2.0.7 very soon.

[Bidoche]

@sh0dan

Yes, you are right it should be left = new ExpNegate(left);
(there is no 'result' in fact)

Since I haven't managed to compile avisynth yet, (i didn't try to hard either, but C++ Builder does not like avisynth code... :/)
it is untested so far. :p

Anyway, I have started writing a complete parser for avisynth.
It only handles int, float and bool expressions made of literals so far, (ie the part that doesn't mess with the internals)
I will post a test version of this soon.

The rest will require some internal modificiations
(for ex: my parser is fully typed when avs is not for now, so var and functions should be asked for return type for it to work)

I need too some input about the expected behavior of metafunctions Import, Eval, Apply.
Does Import switch the parser to the other source and after continue, or does it just execute directive and learn function ?
Does Eval and Apply expect evaluable arg at parse time (easier) or at run time (arghhh :/)

[trbarry]

Most previously existing Avisynth filters are probably video only filters that check for YUY2 as needed. I don't think there are as many external audio filters.

So before all this is carved in stone I guess I really have to ask ... Is there any way that at least that subset of filters could be made to work on YUY2 or RGB data without having to be recompiled?

Maybe it is just not possible but it sure would be nice for legacy filters that are probably not going to be converted soon, or at all.

I'm not talking about any auto conversion to YUY2 here. Probably just trying to lay out the control blocks so the most important video related fields stay the same size and place. But I haven't tried to go study the code to see what has changed.

- Tom

[benf2]

Must have missed it, but after searching thru many many threads i havent found a link to download avisynth 2.5...only 2.0* versions.

Would someone please point me to the link...thanks

[trbarry]

See the YV12 sticky at the top of the forum.

- Tom

[benf2]

Thanks...told u i missed it ;)

[JohnMK]

I'm still very much unclear on the status of SelectRangeEvery. Is it in now?

[HarryM]

Originally posted by JohnMK
I'm still very much unclear on the status of SelectRangeEvery. Is it in now?

Yes, in Avisynth 2.5 build 21112002 is SelectRangeEvery implemented. I test it, it is fully functional! O.K. :D

[Brother Darrell]

Originally posted by cult
...Installed everything under win98 partition so I wont get a mess with my avisynth 2.06....

Does anyone know of a way to use the 2.06 version concurrently with 2.5 on win2k? I would love to be able to swap between the 2 of them without having to do a separate partition or re-installing and rebooting everytime. I like them both (mostly 2.06 because of all the filters available that will not work with 2.50)A way to have them co-exist would be cool.

[sh0dan]

@Brother Darrell: Use search - this has been discussed several times.

[JuanC]

Originally posted by Brother Darrell
Does anyone know of a way to use the 2.06 version concurrently with 2.5 on win2k? I would love to be able to swap between the 2 of them without having to do a separate partition or re-installing and rebooting everytime. I like them both (mostly 2.06 because of all the filters available that will not work with 2.50)A way to have them co-exist would be cool. Here's what I did:[list=1] Install VirtualDubMod in its own folder somewhere in your disk.
Install AviSynth 2.5 beta
Move the avisynth dll from \windows\system32 to VirtualDubMod's folder
Install Avisynth 2.07
Put the plugins for each Avisynth version into the corresponding folder[/list=1]That's it! This way you should be able to use 2.5beta from VDMod and 2.07 from any other program...

[Brother Darrell]

Search is how I found This thread...looking for the very same thing...hmmm, maybe not using the right keywords?..will try again..thanks,at least I know it's here somewhere.

[Brother Darrell]

Originally posted by JuanC
Here's what I did:[list=1] Install VirtualDubMod in its own folder somewhere in your disk.
Install AviSynth 2.5 beta
Move the avisynth dll from \windows\system32 to VirtualDubMod's folder
Install Avisynth 2.07
Put the plugins for each Avisynth version into the corresponding folder[/list=1]That's it! This way you should be able to use 2.5beta from VDMod and 2.07 from any other program...

Thank you!...though I will still look for the threads some more..I ain't so lazy as not to put SOME effort into it.

[sh0dan]

thread (http://forum.doom9.org/showthread.php?s=&threadid=44029&highlight=script+2.5+2.07)

When figuring out how to do this - put it up somewhere on avisynth.org!