Not entirely certain as to the viability of this but: Rather than divide frames up and process them in separate threads, as has been oft suggested, divide up the filters. Simple scripts which would see no benefit from this typically are fast enough that one is limited by the encoder not being able to attain the same rates, but large scripts with many commands would see a large benefit from this style of multithreading. lets make an example of this with a simple and (possibly) common script:
Rather than running all of this in one thread run "TFM(order=-1)" in one thread, "TDecimate(hybrid=0)" in another, and "Spline36Resize(1280,720)" in another. This will allow for an easy method of dividing up the work that should be compatible with all current filters. Furthering the filters capacity to work asynchronously is just a matter of having Avisynth have the capacity to store several completed frames from each filter that is working ahead of schedule (so if TFM was faster than TDecimate, and TDecimate was faster than Spline36Resize, then each filter would work until it was x many frames ahead of the next filter and then just wait for the filter after it to progress (I know system can be much more complicated than this but with the proper amount of intelligence even those more complex script should be able to work under this and even see a large speed up.)). This will increase the overhead of AVIsynth's operation, but with the ever dropping price of ram and the increasing capacity of modules, few would miss that space in the light of multithreaded operation.
Log in to post a comment.