How has AviSynth been multi-threaded?

[Inventive Software]

I'm curious as to how it's been modified / changed to support multi-threaded CPUs. I've searched and read a few topics, and there's a plugin that adds multi-threading for other plugins. But is there support for native command multi-threading? By native command, I mean commands like AVISource or DirectShowSource. I'm planning an upgrade to a dual-core CPU, and multi-threaded AviSynth would really help! :D

[Jeremy Duncan]

I know tsp's mt enables multi core cpu threading.
But I've never read anything about something like that being built right into Avisynth.

tsp is making a new version of mt avisynth.dll and might make another one for avisynth 2.5.7.

I think tsp is the only creator of .dll's that enable Avisynth to multithread.

The problem is that a avisynth.dll and mt.dll has to be made before it can be integrated into a unreleased avisynth.exe. At least I think this is the way it goes. It's never going to happen, a multithreading avisynth.exe that doesn't need to use tsp's mt plugins.
At least that's my opinion.

[foxyshadis]

The other option is adding some openMT code to existing plugins and recompiling. tsp's method is far better and more scalable, but if you need to use a recent avisynth the other way works.

[IanB]

The implementation is based on the idea of speculative pre-rendering of next frames in the cache. I.e you ask for frame 1, the top most cache does not contain the frame so assigns 1 thread to render it, another thread is assigned to pre-render frame 2. It's not quite so simple because there is a cache between every filter node and similar logic applies throughout the getFrame tree. But you get the idea.

There is are whole threads, http://forum.doom9.org/showthread.php?t=94996 and http://forum.doom9.org/showthread.php?t=95596 that discuss the ins and outs to do with this.

AVS 2.6 will have the MT code (barring serious problems).

[foxyshadis]

I still think it should be a design goal of 2.5.7 to include at least rudimentary multithreading, of the MT() split-screen variety. It works so well and stable, along with the frame threading you brought up, that it's disappointing that it won't even be an option for a stable release until 2.6, whenever that comes.

[MacAddict]

Hope 2.6 comes along sooner than later then. I too would have like to seen it in 2.5.7, at least in it's infancy stage.

[Fizick]

A am not sure, what is optimal way to implement multithreading in Avisynth.
For example, Canopus Edius use two thread: one for even field, second for odd field (with syncro commant of course).

Other option: some filters can be build with internal multitherding (as foxyshadis says but with another conclusion). For example, soon I hope to release FFT3DFilter with support of threads.

[IanB]

The trick is to find ways to usefully divide that task up. At the script level about all that can be done is to speculate that frame N+1 will be wanted next, so pre-render it. The Select.... family of filters pretty much nuke that concept.

Within a filter that wants multiple input frames to generate it's output frame, and it threads it's GetFrame calss, chances are much better.

Of course there are many other possibilities.

[lexor]

The trick is to find ways to usefully divide that task up. At the script level about all that can be done is to speculate that frame N+1 will be wanted next, so pre-render it. The Select.... family of filters pretty much nuke that concept.
I don't quite see how Select filters are a problem to this, it's just a little mapping that has to be done, after you give it a Select command it *should* (note I don't have developer's knowledge on how it implements it) internally create a logically continuous map of frames to be rendered for its own use, so N+1 in new logical order can be mapped to N+2000 in the source, and so on. Avisynth should always be able to tell what frame comes next (and in theory it should know exactly which frames come next from this point to the very end)

[tsp]

if setmtmode(5) is not used in the script the speculate part is done at the end of the filterchain so select() shouldn't cause any problem. Of course if the program calling avisynth is requesting random frame the prediction will fail.
Also the filter MT() works by splitting the frame in smaller part and letting each thread work on each part. This doesn't work for filters that requires informations about the entire frame like mvtools or some of the deinterlacers.

[Fizick]

may be for interlaced video we can
Unfold fields (or stack vertical),
use MT(),
Fold fields

[tsp]

yes I have thought about that too. It will only use two threads but I think it will take a while before we all get quadcore cpus anyway.