AVSMeter

AVSMeter measures how fast an AviSynth script can deliver frames. Drop a script onto it, or name it on the command line, and the console counts frames as they are served, reporting the slowest and fastest moments and the average frames per second, alongside the processor load, the memory the script consumed and the number of threads in use. Nothing is encoded and nothing is displayed, which is the point. The script runs with almost no overhead, so the figures describe the script itself rather than whatever encoder or player would normally sit on top of it.

That matters because an AviSynth script is a chain of filters, and when an encode crawls or a preview stutters, the question is which link is slow. Run the script here, comment out a filter, run it again, and the difference in frames per second is the answer.

AVSMeter also tests the AviSynth installation itself, reporting the version, the plugin directories, every loaded plugin and every available function, which turns the frequent mystery of a script that works on one machine and fails on another into a comparison of two reports. It is a console tool with no window, and that is all it needs to be.

Running a script and reading the numbers

The simplest use of AVSMeter is dragging a script onto the executable, which runs it from the first frame to the last and prints the clip’s properties, from resolution and frame rate to length and colour format, followed by the speed and resource figures when it finishes. Called from the command line, the same run accepts switches for a frame range, a time limit so a long clip is sampled rather than processed in full, and a log file or a CSV file recording the frame-by-frame numbers for a spreadsheet.

The three speed figures tell different stories. A low minimum with a high average points at a filter that chokes on particular frames, such as a scene change or a dark passage, while a low average across the board means the chain is simply heavy. Memory climbing steadily through a run is the signature of a filter that leaks or a multithreading setting that buffers too many frames, and that reading is how many crashes in encodes are diagnosed before they happen.

Reporting the plugins and functions

The AVSMeter information switch produces a report on the set-up rather than a script. It lists the AviSynth build and its type, the plugin folders it searches, each plugin found with its path and version, and the complete set of functions those plugins expose, with a note of any that failed to load. A plugin compiled for the wrong architecture, a duplicate function name from two plugins or a missing dependency shows up here in plain text, and the report is the first thing experienced users ask for when a script fails.

That report is also the way to confirm that a new plugin has been picked up and to see which version answers to a function name when several are installed. For the video file itself, before any script touches it, MediaInfo describes the source, and the two reports together cover both ends of a problem, the file and the chain that reads it.

Processor load and memory

Processor usage is reported as a low and a high across the run, which shows whether a script is using the cores it could. A chain stuck at a fraction of the processor on a many-core machine is a candidate for multithreading settings, and the thread count the tool reports confirms whether they took effect.

Memory is tracked the same way, with a peak figure that tells whether a script will fit in the address space available to the encoder that will host it.

Graphics card figures

AVSMeter can include graphics card usage when GPU-Z is running beforehand, since the meter reads the card’s figures from that tool rather than measuring them itself. That is how a script using a hardware decoder or a card-accelerated filter is checked to see whether the card is doing the work it was given.

A chain that was supposed to decode on the card but shows no card activity has fallen back to the processor, and the figures make that visible in one run.

Where it fits in the workflow

AVSMeter measures a script and nothing more. It does not edit, preview or encode, so it lives beside the editor where the script is written and the encoder that will consume it. A typical cycle is to write a filter chain, meter it, adjust, meter again, and only then hand the script to a frame-serving video editor or a command-line encoder for the real run, knowing the speed and memory to expect. Front ends that drive AviSynth often bundle it for exactly that reason, so a setting change can be measured without leaving the front end.

It assumes a working knowledge of AviSynth scripting, since the numbers mean nothing without knowing what the filters do, and its console output looks like the diagnostic tool it is.

Conclusion

AVSMeter suits anyone who writes or tunes AviSynth scripts and wants to know, in numbers, how fast a filter chain runs and why, before an encoder spends hours finding out. The speed figures isolate the slow filter, the memory trace predicts the crash, and the installation report settles the plugin mysteries that eat evenings.

It is a console tool for people who already speak the language of filters and functions, and it does nothing for anyone else. Keep it beside the script editor, meter every change, and the encoder’s run becomes the last step rather than the first test.