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

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

 

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

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th September 2005, 17:24   #1  |  Link
gzarkadas
Registered User
 
gzarkadas's Avatar
 
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 222
New library with Avisynth script extensions

Below are the links to a new extension library for Avisynth that I have developed in order to fulfill my needs as an Avisynth user for the various extras that I wanted to have in my scripts:

Download page: http://sourceforge.net/projects/avslib/
Online documentation: http://avslib.sourceforge.net/

The library currently offers the following main features:
  • A new container 'datatype' (the array) for all variable types (including clips' arrays and mixed types' arrays) and numerous functions, including operators, to handle arrays.
  • A large set of mathematic and statistical functions, that operate both on single variables and whole arrays.
  • A standard set of clip-editing functions which in addition they allow user-specified functions for arbitrary post-processing of result's parts, for example: implementation of transitions, filtering, insertion of cover-story (intro clips), etc.
  • A set of general purpose animation functions that animate position, size and opacity on succesive frame segments in one step, supporting all arguments of Overlay standard Avisynth function.
  • A set of functions to aid script debugging.
It is a stable, production version; see the example scripts at the documentation.

Any comments, suggestions or ideas for improvement are welcomed.
gzarkadas is offline   Reply With Quote
Old 27th September 2005, 22:37   #2  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,345
Great, that looks very impressive! I guess we've some reading and testing to do this week
Wilbert is offline   Reply With Quote
Old 27th September 2005, 23:17   #3  |  Link
gzarkadas
Registered User
 
gzarkadas's Avatar
 
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 222
Thank you. I will be happy to answer any questions, should they arise during this process.

To help start with, there are ready test scripts along with their results both in the documentation and the distribution file to start with (the "Example scripts" section).

Also, before starting to code scripts it is essential that the "Limitations" page of the documentation is read, to avoid asking more than the library can deliver.

I would further recommend reading the "Backgrounders / Tutorials" articles, which provide an overview of the library internals.
gzarkadas is offline   Reply With Quote
Old 27th September 2005, 23:21   #4  |  Link
danpos
BDVD Team
 
danpos's Avatar
 
Join Date: Dec 2004
Location: Rio de Janeiro - RJ/Brasil
Posts: 306
Yep, it seems to provide more power to (already) powerfull AVISYNTH!

I will study it soon.

THX for your time and efforts.

Cya!
danpos is offline   Reply With Quote
Old 28th September 2005, 09:00   #5  |  Link
tsp
Registered User
 
tsp's Avatar
 
Join Date: Aug 2004
Location: Denmark
Posts: 807
It looks good but why didn't you implement it by creating a plugin (dll file)?
__________________
Get my avisynth filters @ http://www.avisynth.org/tsp/
tsp is offline   Reply With Quote
Old 28th September 2005, 10:03   #6  |  Link
stickboy
AviSynth Enthusiast
 
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,268
Neat. I'll have to look at this in more depth later.

I skimmed through some of it, and a few parts look really familiar. Did you base (or copy) parts of it from some of my work? It's certainly okay if you did, since I released all of my scripts to the public domain. Still, if that indeed is the case, it seems like it'd be proper etiquette to give some form of attribution.

Also, it'd probably be good if you and I worked together to avoid name clashes. For example, my version of Undefined() is different from yours (but is equivalent to your Undef()). (Frankly I see no value in your Undefined(); !Defined() will do and has equal expressive power.)

Last edited by stickboy; 28th September 2005 at 10:37.
stickboy is offline   Reply With Quote
Old 28th September 2005, 22:54   #7  |  Link
gzarkadas
Registered User
 
gzarkadas's Avatar
 
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 222
Quote:
Originally Posted by tsp
It looks good but why didn't you implement it by creating a plugin (dll file)?
For a long list of reasons, the most important of them presented at the end of this post as an appendix, to avoid cluttering those that may not be interested.

To give a one paragraph summary: Because it was challenging to do so and because I believe that Avisynth needs in the long-term native script language extension libraries; they add value because the power of scripting compared to a GUI implementation is that you can gradually build code to shorten repetitive tasks and rapidly implement new solutions to application-domain problems.

APPENDIX - (Partial) List of reasons

1. First of all it was a challenging mental exercise (especially the implementation of the array module); I like challenges , so I chose the hard way.

2. Second, because I assess that the script language has all the necessary constructs to create arbitrarily complex behavior, although of cource one will need more steps to achieve his/hers targets since he/she will have to start from the bare fundamentals.
However, if libraries exist, then development of new source code is faster (see the thread http://forum.doom9.org/showthread.php?t=96750; it took me just a part of one morning to implement the solution, because I already had the library to provide the hard parts of the implementation).
Therefore, I implemented it this way to provide a proof that building complex libraries with Avisynth script language is possible and in fact not inferior to the other alternative (see the next points, below).

3. For portability-related issues. Writing in an interpeted language is portable accross major version changes of the host application and across operating systems. Therefore, there is little chance that I will need to update even a single line of code when Avisynth 3 will come forward or whenever a port of Avisynth to Linux or Mac is done.

4. For maintenance-related issues. Packaging over 160 functions to a plugin is more difficult than placing them into source script files.
In addition, I have the intention to add in a later version a partial import scheme of the library for which having the ability to simply break code inside source script files and write a few headers is much more desired than distributing code across C++ projects and recompiling.

5. For speed-related issues. Interpreted code is always slower than compiled code but in our case the penalty is low because the interpreted code actually most of the time only administers calls to C++ functions (filters) and assignment of their results to variables. Most of the time spent to script execution is devoted to manipulation of large data streams by the (internal or plugin) C++ functions.
Thus, writing 'glue' code in avisynth script does not impose a serious performance penalty and in fact it repays more, because of rapid script development and the associated reduction of time spent by the script writer (IMHO computer's time is always a least expensive resource than human's time).

6. The filter SDK documentation in avisynth.org states that a plugin cannot return an array; thus impementing arrays with a plugin would be a complex task, because everything should be handled internally by the plugin since the actual array would never be possible to be returned and stored inside a script variable. Not to mention operations on arrays; I would end up writing a separate interpreter.
gzarkadas is offline   Reply With Quote
Old 29th September 2005, 00:55   #8  |  Link
gzarkadas
Registered User
 
gzarkadas's Avatar
 
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 222
Quote:
Originally Posted by stickboy
Neat. I'll have to look at this in more depth later.

I skimmed through some of it, and a few parts look really familiar. Did you base (or copy) parts of it from some of my work? It's certainly okay if you did, since I released all of my scripts to the public domain. Still, if that indeed is the case, it seems like it'd be proper etiquette to give some form of attribution.

Also, it'd probably be good if you and I worked together to avoid name clashes. For example, my version of Undefined() is different from yours (but is equivalent to your Undef()). (Frankly I see no value in your Undefined(); !Defined() will do and has equal expressive power.)
I have used some of the names that you (and others also) have used, but since such basic functions or language primitives such as "min", "max", "throw", "insert", "delete", etc. have been around for many years in textbooks and example code all over the world, I cannot give attribution; I don't know to whom should I attribute. Not even most of the math or stat functions that I have included in the library (to use an obvious example) I consider them to originate from me; they are direct applications of math textbook formulas.

I have also used or built upon the implementation of a couple of your functions, notably Undef and IsCallable (I am using the library names), for which I will give attribution. As I will do to every other request that may arise; I have already prepared an attribution section in the library's documentation (at the 'Project Information' page, last section) which however I decided to leave empty in this very first release waiting first for Avisynth community's input regarding the library. It will be filled in the very next update.

Regarding the second part, I prefer 'Undef' because it is the same way names are #undefed in C/C++; 'Undefined' is better suited for a logical test function. I also consider it more consistent with the general style of the script language, which is basically C-style.

As a last comment, I also consider it good to work together, both with you and the other Avisynth community members, because one of the main reasons I have spent time to setup a project in SourceForge for this library, is to eventually work together on it with other developers.
gzarkadas is offline   Reply With Quote
Old 29th September 2005, 09:29   #9  |  Link
stickboy
AviSynth Enthusiast
 
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,268
Quote:
Originally Posted by gzarkadas
I have used some of the names that you (and others also) have used, but since such basic functions or language primitives such as "min", "max", "throw", "insert", "delete", etc. have been around for many years in textbooks and example code all over the world, I cannot give attribution
Of course, and I certainly wouldn't expect anything for those.
Quote:
I have also used or built upon the implementation of a couple of your functions, notably Undef and IsCallable (I am using the library names), for which I will give attribution.
Yeah, those two in particular are the ones that caught my eye. (Note that IsCallable is based on an idea from mf.)
Quote:
Regarding the second part, I prefer 'Undef' because it is the same way names are #undefed in C/C++; 'Undefined' is better suited for a logical test function. I also consider it more consistent with the general style of the script language, which is basically C-style.
Hm. That's an interesting point. So my motivation was that some other languages have a notion of an "undefined" type. For example, in JavaScript typeof(someUndefinedVariable) will yield the string "undefined". In this sense, then, you can treat "Undefined" as a constant (since AviSynth's parser, for better or worse, supports VB-like syntax for argument-less functions):
Code:
foo = undefined
Also, #undef actively undefines a specified variable, but Undef() can't. #undef is an action, whereas Undef() simply yields a value.

And finally, my opinion is still that your definition of Undefined() offers nothing over !Defined() and therefore is a namespace collision for no compelling reason.

Last edited by stickboy; 29th September 2005 at 09:31.
stickboy is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


All times are GMT +1. The time now is 17:48.


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