Kronos plugin is released under the GPL license. You must agree to the terms of 'Copying.txt' before using the plugin or its source code.

This is a filter for Avisynth 2.5 that provides a simple and easy way to benchmark or profile filter chains (i.e. combination of several filter calls, like mfToon). This is done by using 2 functions, StartTimer() and StopTimer() that should called respectively before the filter chain, and after it:

• StopTimer() measures the time needed to get a frame; this however only accounts for the time the frame needs to be provided by the source and to go through all filters before reaching StopTimer()
• StartTimer() then measures how much time is needed for the frame to be provided and to go through all filters before reaching StartTime()

Hence, the difference is the time the filter chain really took to execute. This time however doesn't only account for the real execution time:

• Windows is multithreaded, which means several operations are actually done successively to make it work; some tasks executed in parallel with the filter chain (like your winamp decoding MP3) are also present in this total time
• There is an unreducible bias due to Avisynth and multithreading management (scheduling) overhead

The first point can be reduced by the use of GetThreadTimes, as suggested by Kassandro in this thread about his own filter AVSTimer, while the second can't be eliminated; still as suggested by Kassandro, running the benchmark on a sufficient number of frames should reduce a part of this error. This is even more true as the filter's initialization often go through a particular process, and caching can produce very variable measures on a few frames.
This is disabled for now, as the accuracy of this function brings worse results than a very precise measure that doesn't account for multithreading.

Last very usefull addition hinted by Kassandro is the use of explicit timers. As you can run up to 6 timers in the same script file, it is needed to distinguish them, by using a required parameter, timer, which is the name you want to give to the timer, most probably a name linked to the filter chain you're benchmarking (like "deen").

In order to provide easy access to the results, several means are offered:

• Use of debugview (or any application able to capture DebugOutputString messages): as it is the less userfriendly and probably less usefull, I'll assume only people already knowing how to use debugview will be interested in using it
• On screen display: the option full (see syntax of the filter below) will print on the video frame timer the results for each running timer in the inverse order they are called (i.e. first timer initialized through StartTimer() will be displayed at the bottom of the frame); see the examples later on this page.
• MessageBox: when you close the script/video source, a pop up will appear, displaying the average values measured. This is controlled by the mb option
• Log file: as all repetitive benchmark, you're likely not to waste your time in front of the computer, and just have them go through a batch file/processing. You can then give a logfile where to write/append (ie the text will be added to the file if it exists) the average final results, and at what time it was first called. Through the log option, you can provide an absolute path to the log file.

There are several points you must know before getting into trouble. Although you would have found thme by yourself, here is an exhaustive list:

• The StopTimer() and StartTimer() functions require a string to name the timer used,
• StopTimer() must have a corresponding StartTimer() at the start of the filter chain, unless you want to measure the execution time since the source (but after it - it can't measure how much time a source takes to provide a frame); a lonely StartTimer() brings nothing but is harmless
• You must provide an absolute path for the logfile; otherwise, 2 files are created:
  
  • One in the plugin folder, with the interesting stuff (measure result)
  • One in the folder of the script you're testing with the stuff that would help you identify the results (start/end time)
• Kronos has a built-in limitation of 6 concurrent timers.
• The mb must never be used with a batch: it would just lock the application, and maybe crash any other application (while it should affect the encoding application) the messagebox popping has decided to block.
• The full option should only be used when you actually look at the screen: for batch benchmarking, it's particularly useless

I assume you are sufficiently familiar with AviSynth to build your own filters, otherwise I suggest you read the AviSynth's FAQ.

StartTimer(string timer)
StopTimer(string timer, boolean full, boolean mb, string logfile)

Options are:

• string timer tells how the timer should be named
• full=true will output a debug string with time taken for each frame
• mb=true will use an additionnal messagebox to pop up on exit to display those stats
• if logfile is defined and is a valid filename, "logfile" will be created or appended with those stats, and the start and stop measure times.

As it is contains graphics, I leave you the possibility to disable viewing of pictures before opening the example page.

Purposedly, the package are put last. So, get on of those files!