MT 0.7(+custom avisynth)a filter to run filters multithreaded. Usefull for SMP or HT

[tsp]

vcmohan: The params will be computed in both threads as the class will be instantiated for each thread.

mroz: making a simple native function EndScript() could be easy. But it isn't the optimal way to make it transparent.

[mroz]

Originally Posted by tsp

mroz: making a simple native function EndScript() could be easy. But it isn't the optimal way to make it transparent.

Indeed. So what would the optimal way be?

[IanB]

Originally Posted by mroz

So what would the optimal way be?

Doing nothing!

[vcmohan]

Originally Posted by tsp

vcmohan: The params will be computed in both threads as the class will be instantiated for each thread.

Does this mean that if params are to be computed from field x, then in both threads they are from same field and not from x in one and x+1 in the other? I have this doubt as in the two threads alternate fields will be processed and the plugin will have no control on that.

[mroz]

Originally Posted by IanB

Doing nothing!

Um, but I've already been told that isn't possible, hence can't be regarded as an optimal solution since it isn't a solution at all. Unless I'm missing something.

[Fizick]

vcmohan,
Are you say about MTi() function ?

[IanB]

@vcmohan,

The PVideoFrames from all the GetFrame calls will be shared thru the cache. If the filter does internal calculations from additional GetFrame calls then each thread will independantly calculate the same (or similar) result. So only the internal work of the filters own GetFrame processing is unique. If the filters maintain static data, Class level or Global, that is not interlocked then a more restrictive SetMTMode may be required.

[Boulder]

With Distributor() in my script for HC with tsp's latest MVTools build, I get these weird artifacts in the first couple of frames of the encode (see the bottom right corner of the actual video area of the screenshot).

With Distributor()

Without Distributor() (no multithreading)

[tsp]

IanB: Good description of SetMTmode(1). With SetMTmode(2), MT() or MTi() the class variables is not shared between threads.

Boulder: Could you upload a short clip (10 frames or so) and the script you use?

[Boulder]

Originally Posted by tsp

Boulder: Could you upload a short clip (10 frames or so) and the script you use?

I'll upload the sample clip for you tomorrow.

[Boulder]

Here is the sample m2v file from the original DVB capture: http://www.savefile.com/files/1196029. See the artifacts appear when you encode in HC022 using the script below. When Distributor() is removed, there are no artifacts but no multithreading Avisynth processing either.

My script:

SetMTMode(2)
MPEG2Source("rwanda.d2v",cpu=4)
Crop(4,72,-4,-70,true)
DegrainC(sad=200)
AddGrain(3,0,0)
AddBorders(8,72,0,70)
Distributor()
ChangeFPS(last,last,true)

DegrainC is in degrain.avsi in the Avisynth plugins directory. The contents of the file are:

global idx_1 = 100
global idx_2 = 200

function Degrain( clip c, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "limy", int "limuv" )
{
global idx_1 = idx_1 + 1
global idx_2 = idx_2 + 1
blk = default( blk, 16 )
ol = default( ol, 0 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
limuv = default( limuv, 255 )
vbw1=MVAnalyse(c,isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(c,isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(c,isb=true,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(c,isb=false,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
nolimit = MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=idx_1,plane=pl)
defined(limy) ? LimitChange(MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=idx_1,plane=pl),c,limy,limuv) : nolimit
}

function DegrainC( clip c, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "limy", int "limuv" )
{
global idx_1 = idx_1 + 1
global idx_2 = idx_2 + 1
blk = default( blk, 16 )
ol = default( ol, 0 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
limuv = default( limuv, 255 )
vbw1=MVAnalyse(c,isb=true,truemotion=true,delta=1,pel=2,chroma=true,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(c,isb=false,truemotion=true,delta=1,pel=2,chroma=true,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(c,isb=true,truemotion=true,delta=2,pel=2,chroma=true,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(c,isb=false,truemotion=true,delta=2,pel=2,chroma=true,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
nolimit = MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=idx_1,plane=pl)
defined(limy) ? LimitChange(MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=idx_1,plane=pl),c,limy,limuv) : nolimit
}

function DegrainFFTC( clip c, clip cleaned, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "limy", int "limuv" )
{
global idx_1 = idx_1 + 1
global idx_2 = idx_2 + 1
blk = default( blk, 16 )
ol = default( ol, 0 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
limuv = default( limuv, 255 )
vbw1=MVAnalyse(cleaned,isb=true,truemotion=true,delta=1,pel=2,chroma=true,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(cleaned,isb=false,truemotion=true,delta=1,pel=2,chroma=true,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(cleaned,isb=true,truemotion=true,delta=2,pel=2,chroma=true,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(cleaned,isb=false,truemotion=true,delta=2,pel=2,chroma=true,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
nolimit = MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=idx_2,plane=pl)
defined(limy) ? LimitChange(MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=idx_2,plane=pl),c,limy,limuv) : nolimit
}

function DegrainFFT( clip c, clip cleaned, int "blk", int "ol", int "sh", int "sad", int "pl", int "div", int "limy", int "limuv" )
{
global idx_1 = idx_1 + 1
global idx_2 = idx_2 + 1
blk = default( blk, 16 )
ol = default( ol, 0 )
sh = default( sh, 2 )
sad = default( sad, 200 )
pl = default( pl, 4 )
div = default( div, 0 )
limuv = default( limuv, 255 )
vbw1=MVAnalyse(cleaned,isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vfw1=MVAnalyse(cleaned,isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vbw2=MVAnalyse(cleaned,isb=true,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
vfw2=MVAnalyse(cleaned,isb=false,truemotion=true,delta=2,pel=2,chroma=false,blksize=blk,idx=idx_1,sharp=sh,overlap=ol,divide=div)
nolimit = MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=idx_2,plane=pl)
defined(limy) ? LimitChange(MVDegrain2(c,vbw1,vfw1,vbw2,vfw2,thSAD=sad,idx=idx_2,plane=pl),c,limy,limuv) : nolimit
}

[tsp]

Boulder: It is not MVtools that ist he problem. This simple script produces the same result:

SetMTMode(2)
MPEG2Source("rwanda.d2v",cpu=4)
Distributor()

both with HC and virtualdub. DGIndex complained about a Opening GOP is not closed. Maybe this is only causing problem with multithreading.

[Boulder]

In case of that non-closed opening GOP, DGDecode should take the first good frame and repeat it for those undecodable frames. The distributor is causing the issue, but I don't know if there is a way to fix it without changes in the way HC handles video input. Since it is a Fortran application, it might be that there is no way to avoid using Distributor.

[tsp]

Boulder: It is not HC that is causing it. It is MPEG2Source. Try this version instead:

SetMTMode(5)
MPEG2Source("rwanda.d2v",cpu=4)
SetMtmode(2)
Crop(4,72,-4,-70,true)
DegrainC(sad=200)
AddGrain(3,0,0)
AddBorders(8,72,0,70)
Distributor()
ChangeFPS(last,last,true)

[IanB]

@tsp,

I have often wondered about the wisdom of doing the following

SetMTMode(2)
MPEG2Source("rwanda.d2v",cpu=4)

I know it is "safe", but doesn't it lead to potential non contiguous frame order requests with the associate performance penalty of redecoding GOP's.

Certainly with AviSource if you get the request order wrong the penalty is harsh because frames skipped during short forward seeks are not cached and lead to a full redecode back from the last key frame.

[tsp]

IanB: I did some testing with a 10.000 frame long h264 encoded using ffdshow rev 1220 720x576 pixel 1804 kbps 98 keyframes size: 86 MB.
reported time it took to complete "run video analysis pass" in virtualdub 1.6.17 with my opteron 165(dual core) @2400MHz

AVISource("D:\simH264.avi")

97 sec (103 fps) 86 MB read

SetMTmode(2)
AVISource("D:\simH264.avi")

182 sec (55 fps) 277 MB read

SetMTmode(2)
AVISource("D:\simH264.avi")
fft3dfilter()

534 sec (18,7 fps)

SetMTmode(5)
AVISource("D:\simH264.avi")
setmtmode(2)
fft3dfilter()

531 sec (18,8 fps)

AVISource("D:\simH264.avi")
fft3dfilter()

654 sec (15,3 fps)

AVISource("D:\simH264.avi")
fft3dfilter(ncpu=2)

603 sec(16,8 fps)

function MVDegrain2i(clip "source", int "overlap", int "dct", int "idx")
{
overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker
idx=default(idx,1) # use various idx for different sources in same script
fields=source.SeparateFields() # separate by fields
backward_vec2 = fields.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=overlap, idx = idx,dct=dct)
forward_vec2 = fields.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=overlap, idx = idx,dct=dct)
backward_vec4 = fields.MVAnalyse(isb = true, delta = 4, pel = 2, overlap=overlap, idx = idx,dct=dct)
forward_vec4 = fields.MVAnalyse(isb = false, delta = 4, pel = 2, overlap=overlap, idx = idx,dct=dct)
fields.MVDegrain2(backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400,idx=idx)
Weave()
}

setmtmode(2)
AVISource("D:\simH264.avi").trim(0,-500)
mvdegrain2i(4,1,1)

315 sec (1,59 fps)

function MVDegrain2i(clip "source", int "overlap", int "dct", int "idx")
{
... same as above
}

setmtmode(5)
AVISource("D:\simH264.avi").trim(0,-500)
setmtmode(2)
mvdegrain2i(4,1,1)

312 sec (1,60 fps) 5 MB read

function MVDegrain2i(clip "source", int "overlap", int "dct", int "idx")
{
... same as above
}

AVISource("D:\simH264.avi").trim(0,-500)
mvdegrain2i(4,1,1)

1143 sec (0,44 fps) 777 MB read (I did repeat this 3 times with the same result!)

So the conclusion is that for fast script it is a very good idea to use mode=5 for avisource(and mpeg2dec) while for slower scripts it doesn't matter as much or if a codec that only saves keyframes is used (MJPEG or HUFFYUV). The explanation, I think, is that the threads are desynced in the slower scripts so most of the time only one thread are executing code inside Avisource. Something weird are happening in the last example. I will try repeating it with the official 2.5.7 as it looks like a severe cache miss/bug in my version?

[edit]
1130 sec for the official avisynth 2.5.7 in the last script.
[/edit]

[edit2]
this script

function MVDegrain2i(clip "source", int "overlap", int "dct", int "idx")
{
... same as above
}

setmtmode(5)
AVISource("D:\simH264.avi").trim(0,-500)
mvdegrain2i(4,1,1)

completes in 617 sec (0,81 fps) 5 MB read
so it looks like it is the non multi-threaded cache that are messing up. (as only 1 thread is used in the above code).
[/edit2]

[Fizick]

it looks like a severe cache miss/bug in my version?

can you test more old version (may be even 1.6.4-1.7.0 ?)

BTW, what is "777 MB read" ?

[tsp]

Originally Posted by Fizick

it looks like a severe cache miss/bug in my version?

can you test more old version (may be even 1.6.4-1.7.0 ?)

more test results, same script (with no setmtmode)
avisynth 2.5.8 alpha 2+mvtools 1.8.4.4: 1023 sec
avisynth 2.5.8 alpha 2+mvtools 1.6.4: 910 sec
avisynth 2.5.7MT + mvtools 1.6.4: 1007 sec

so I still believe it is more of a cache issue than a MVTools issue.

BTW, what is "777 MB read" ?

that the virtualdub process has read 777 MB from the harddisk. The number of page fault is the same with and without SetMTmode so I believe that the source file is read multiple times.

[IanB]

@tsp,

Interesting results. At a raw 103fps your machine averages 9.7msecs to decode a frame, and at 15.3fps your machine takes 65.4msecs to decode+fft3dfilter a frame.

So given 65.4-9.7 = 55.7msecs for fft3dfilter, 2 cores but only sequentially accessing frames, the best time expected could be 9.7+55.7/2 = 37.5msecs or 26.6fps. Which we don't seem to come close to.

I would be interested to see if forcing sequentialness, i.e.

SetMTmode(5)
AVISource("D:\simH264.avi")
ChangeFPS(last,last,true)
setmtmode(2)
fft3dfilter()

and

AVISource("D:\simH264.avi")
ChangeFPS(last,last,true)
fft3dfilter(ncpu=2)

makes any significant difference.

Also if you have time you might test some medium weight filters like Blur() or ...Resize()

[Fizick]

fft3dfilter has internal fft cache, I never consider how (in)effective it will be in multitreading env.