AviSynth SMP Support

[ChrisBensch]

I know that coders are terribly busy with other things in AviSynth, but I was curious as to any efforts for true SMP support for AviSynth?

[Richard Berg]

The only place it would really make sense is when a filter is encountered that takes more than one clip argument: conceivably, different threads could be spun off as the interpreter worked upward.

In practice, I think it's easier to split an encoding job into multiple parts if you want to take full advantage of multiple processors. A smart GUI could do this transparently with the existing program.

[sh0dan]

@Richard - the problem would be that frames are being requested by child->GetFrame(), which doesn't return until the frame is ready - so there is no way a filter can request the next frame until the first is finished.

The only way I see is to spawn thread(s) that generate frames which are likely to be requested (ie, when the app. requests frame n, another thread starts generating frame n+1). When n+1 is requested it can be fetched from the cache.

The cache would also have to be modified, so the same frame isn't requested upwards twice - this will mean stalling one thread, but most filter chains should even themselves out.

It would be an interesting project after i fix the last bugs in DirectShowSource (most annoying is a ¤#&%¤""! deadlock/crash), so we can get 2.5.3 out...

[Bidoche]

@sh0dan

A filter could spawn a thread, make it request a frame, while it request its own and wait till both are done.
Why wouldn't it be possible ?

[sh0dan]

I was thinking of it as a generic SMP-support, that didn't require filter modifications. Filters can request multiple frames, but there is a large chance that it will run into problems upstream, and stall. Not to talk about the problems with multiple multithreaded filters (/me shivers).

However filters that are assuming linear access might force us to insert cache synchronization, where a cache must wait for thread (frame n) to have returned a frame before thread (frame n+1) are allowed to return the generated frame.

Wow - that's a big showstopper. Filters like Telecide cannot even be requested to deliver frame n + 1 before it has returned frame n. There is however no way the cache requesting from a filter can know if the filter is relying on linear access. It would basicly mean that thread two cannot be invoked before thread one has returned.

Conditional filters will have significant problems too - using multiple threads and conditional filters will be close to impossible, as variables are no longer reliable.

[sh0dan]

Avery Lee sent some very good thoughts to me by email:
I noticed on doom9's forums that the Avisynth team is pondering how to multithread filters, and hit upon the synchronous GetFrame() problem. It turns out the synchronous GetFrame() can be worked around: create each Avisynth filter in a Win32 fiber, and each time a filter needs to block on a frame, hop the thread to another fiber and begin execution of another frame. Avisynth graphs should be directed acyclic graphs and thus cycles should not be a concern. If fibers are not available a thread per filter will work, although it'll be synchronization hell and less efficient.

The real problem you guys are going to have is that Avisynth frame refcounting is not multithread-safe, and the code to do so is _baked into every filter_. ++vfp->refcount is NOT safe on multiple threads even on a single CPU system; I have seen a 2.4GHz P4 violate the increment about once every four hours with only a one-instruction window for the goofup to occur. Solving this problem could be extremely nasty; what you may have to do, barring an API change, is to create a shadow video frame for each filter, and after each filter run a sweep of the filter's shadows to notify the global, asynchronous garbage collector of which frame buffers can be freed. This will get nasty very quickly, obviously.

I have not looked through the consequences of the first part.

The second part is quite alarming, since it would require replacing avisynth.h in filters and forcing a recompile.

Should it have been "InterlockedIncrement(&vfb->refcount)" instead of the simple increment. Silly though, as Ben did this in the Cache filter, and NOT in the avisynth.h - if it had only been the other way around. :(

I guess there are issues still to be looked at before SMP support makes sense.

Just to post _something_ positive - I've fixed some of the DirectShow problems, so it is now stable to use with seeking - though with limited sound support - expect a new version soon!

[Wilbert]

Just to post _something_ positive - I've fixed some of the DirectShow problems, so it is now stable to use with seeking - though with limited sound support - expect a new version soon!
Very nice!

Btw, I saw that Avery Lee also added some optimization stuff to avisynth.org. I hope it's useful.

[Bidoche]

Do you really expected to be able to add multithread support without a recompile ?

Anyway the simplest way to make PVideoFrame thread-safe is probably to define it in term of boost::shared_ptr

[JohnMK]

I'm not quite sure where AviSynth would benefit from this. There's enough SMP support as I see it -- your mpeg4 codec is encoding on one CPU while the avisynth filters are on the other. The only appreciable advantage I'd see in SMP Avisynth is if you had 4 CPUs, e.g. 2 x Pentium 4 Xeons (Hyperthraeding).

[stickboy]

Originally posted by JohnMK
There's enough SMP support as I see it -- your mpeg4 codec is encoding on one CPU while the avisynth filters are on the other.That doesn't help much when people want to use two-pass encoding or when people encode to Huffyuv first.

[JohnMK]

Sure it helps two-pass encoding, if by two-pass encoding you mean two passes of mpeg4 & avisynth filters each pass.

[stickboy]

Originally posted by JohnMK
Sure it helps two-pass encoding, if by two-pass encoding you mean two passes of mpeg4 & avisynth filters each pass.Oh, right.

I meant to say "people want to use two-pass encoding and encode to Huffyuv first."

[Richard Berg]

A smart GUI a la above should be able to join the files before passing them to the compressor. It doesn't even need to do a disk-based copy: just create a temporary AVS like

return Avisource("huff1.avi") + Avisource("huff2.avi")


With my duals it's been faster to do the filtering twice as the two-pass runs, but this method could be faster still.