some more test, same source as before:
Code:
setmtmode(2)
AVISource("D:\simH264.avi")
changefps(last,last,true)
94 sec (106 fps)
(so just as good as with no multithreading)
Code:
AVISource("D:\simH264.avi")
MT("fft3dfilter()",2,8)
521 sec (19,2 fps) slightly better than using setmtmode(2) but still fft3dfilter doesn't scales to well.
Code:
AVISource("D:\simH264.avi")
changefps(last,last,true)
MT("fft3dfilter()",2,8)
532 sec (18,8 fps) slightly slower. No surprise as MT() split the frame in two and process each part in a separate thread so it is sequential access even without changefps (same story for fft3dfilter(ncpu=2))
Code:
setmtmode(5)
AVISource("D:\simH264.avi")
changefps(last,last,true)
setmtmode(2)
fft3dfilter()
548 sec (18,2 fps) without changefps() 536 sec (18,7 fps). Again slower with changefps() and still slower than mt() (probably due to fft3dfilters intertal fft cache).
and now for a medium weight filter spline16resize
Code:
AVISource("D:\simH264.avi")
Spline16Resize(640,480)
154 sec (64,9 fps)
Code:
setmtmode(2)
AVISource("D:\simH264.avi")
Spline16Resize(640,480)
172 sec (58,1 fps) slower than without multithreading due to non sequential access.
Code:
setmtmode(5)
AVISource("D:\simH264.avi")
setmtmode(2)
Spline16Resize(640,480)
357 sec! (28 fps) ouch even worse, so always using mode=5 for avisource is not a good idea.
Code:
setmtmode(5)
AVISource("D:\simH264.avi")
changefps(last,last,true)
setmtmode(2)
Spline16Resize(640,480)
117 sec (85,5 fps) large improvement suggesting that non-sequential access is the culprit.
Code:
setmtmode(2)
AVISource("D:\simH264.avi")
changefps(last,last,true)
Spline16Resize(640,480)
105 sec (95,2 fps) fastest time.
so changefps(last,last,true) is most efficient when used with fast scripts while it makes the script slower in slow scripts.
Also I noticed that changefps made the largest difference in script where the fps was very unstable.