Structure of the AVSLib library

Table of contents

Library Structure

The library is structured around modules. Each module contains related filters, functions and (possibly) global variables and constants.

Modules with common characteristics are further organised into packages. A package is thus a set of modules with related scope of operation.

A package may in turn be further divided to (an unlimited depth of) sub-packages. The later typically happens when the number of modules is getting big and their puprose can be grouped to broader categories.

[<< to top]

Library Specifications

FeatureSpecification

Maximum array lenght

Maximum allowed string length. This is 2^32-1 for Avisynth versions >= 2.5.6 and only 1024 for Avisynth version 2.5.5 and earlier (achieved with a hack developed by AVSLib).

Maximum number of array elements

Variable, depending on the length of the string representation of each element and the delimiter in effect.

For Avisynth versions >= 2.5.6 is practically unlimited (>> 1 million); for Avisynth version 2.5.5 and earlier is rather small (around 50 - 150, depending on the types stored inside the array).

Maximum number of auto-clip globals

Maximum allowed int (MAX_INT) plus one (currently 2^32)

Supported operations on array elements

All, except some very specific string-related quirks with specific values.

In detail: because containers' handler functions try to evaluate elements (calling Eval() on them) when they are accessed, certain operations with strings cannot be performed.

For example: adding "not" to all elements of a string array with an array operator does not work as intended. "Not" (remember Avisynth is case-insensitive) is an AVSLib function ie a global identifier.

See the containers and operators tutorials for details).

Maximum nesting depth / arguments' values on itterative function calls

Limited only by available stack space and range of the result's datatype allowed by Avisynth.

Maximum number of calls to filters/functions inside scripts.

Limited only from available memory space allowed by Avisynth or/and the operating system (maximum process memory size).

Supported Avisynth versions

Any (no reports up to now for non-functioning features in a specific version).

The parts of AVSLib that base their functionality on external plugins may be limited by plugin-specific limitations (most notably, they will not work on 2.0.x versions).

In typical library's usage, especially for Avisynth version 2.5.6 and later, it is unlikely that any "hard" limit will be reached. If a limit is reached it is likely to be a resource limit imposed by Avisynth or the operating system.

If this is the case, rearrange the script in groups of smaller scripts (ie divide and conquer). Keep in mind that many parts of the library (especially array-related) are "dense", meaning that even a single line in the script (depending of course on line's contents) if expanded to equivalent Avisynth statements without the use of AVSLib may well reach several pages in length.

[<< to top]

Naming conventions

AVSLib uses naming conventions in order to divide the large number of functions it provides in separate logical namespaces, to convey structure information and to aid library's users to reduce their learning curve and avoid common mistakes.

Note that many of these are just proposals of coding-style conventions; Avisynth script language does not support separate namespaces, does not distinguishes case, nor it flags name conflicts (instead it resolves them automatically).

However, it is precisely this lack of protection of identifiers' names which makes necessary a high level of discipline on behalf of the script writer, in order to avoid masking essential library functionality and the errors that this masking will inevitably produce.

The naming conventions used throught AVSLib are the following:

[<< to top]

Reserved names

All names begining with the "private" designator (the double underscore at the begining of the name) are considered reserved. Any future version of AVSLib may freely modify them, delete them, change their semantics, etc. The list of entities that this rule applies includes:

Public library constants are also considered reserved in the sense that their value (and associated type) should remain unaltered by user scripts.

[<< to top]

Reserved actions

These include in general all actions that involve messing around with the library's reserved namespace. In particular, the following rules should be observed, unless you are a library developer or your main objective is to research curious new bug species:

[<< to top]