MVTools-pfmod

[hello_hello]

It could be that I'm losing my mind, or maybe it's related to the previous MDegrainN bug, but I've been using the following for light denoising now and then:

tr = 1 # Temporal radius
mt = true # Internal multithreading
lsb = false # 16-bit
thSAD = 200 # denoising strength
blksize = 16 # block size
overlap = 4 # block overlap
super = MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
MDegrainN (super, multi_vec, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

That works fine, but if I make the three changes highlighted blue below, it results in an error message "Invalid arguments to function MDegrainN". Am I missing the obvious?

#tr = 1 # Temporal radius
mt = true # Internal multithreading
lsb = false # 16-bit
thSAD = 200 # denoising strength
blksize = 16 # block size
overlap = 4 # block overlap
super = MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=1)
MDegrainN (super, multi_vec, tr=1, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

Thanks.

[MysteryX]

Originally Posted by hello_hello

MDegrainN (super, multi_vec, tr=1, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

tr is the name of the variable, not the name of the parameter.

Try this

MDegrainN (super, multi_vec, 1, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

[hello_hello]

MysteryX,
If it's a named argument, shouldn't tr=1 work, or am I being dumb?

Your suggestion does work, by the way.

MDegrainN (super, multi_vec, 1, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

But to me it should work like this. All these MAnalyse configurations seem to be fine:

tr = 1 # Temporal radius
mt = true # Internal multithreading
lsb = false # 16-bit
thSAD = 200 # denoising strength
blksize = 16 # block size
overlap = 4 # block overlap
super = MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
MDegrainN (super, multi_vec, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

or

multi_vec = MAnalyse (super, blksize=16, mt=mt, multi=true, overlap=overlap, delta=tr)

or

multi_vec = MAnalyse (super, 16, mt=mt, multi=true, overlap=overlap, delta=tr)

I'm not understanding why the same doesn't apply to "tr", or even supplying the input clips for MDegrainN as named arguments. That doesn't seem to work either. Should it, or am I being silly?

[MysteryX]

Originally Posted by hello_hello

I'm not understanding why the same doesn't apply to "tr", or even supplying the input clips for MDegrainN as named arguments. That doesn't seem to work either. Should it, or am I being silly?

Because the argument's name is not "tr". We'd have to check in the doc to know the argument's name.

[hello_hello]

I did.

tr
Temporal radius, > 0. Must match the mvmulti content, i.e. the delta parameter in MAnalyse.

MDeGrainN (
clip,
clip super,
clip mvmulti,
int tr,
int thSAD (400),
int thSADC (thSAD),
int plane (4),
int limit (255),
int limitC (limit),
int thSCD1,
int thSCD2,
bool isse,
bool planar,
bool lsb (false),
int thSAD2 (thSAD),
int thSADC2 (thSADC),
bool mt (true)
)

[pinterf]

Originally Posted by hello_hello

While I'm asking, I assume this means there's a reasonable difference between the old ff3dfilter and the new? Is it something to care about?

Cheers.

fft3dfilter 2.3 vs fft3dfilter 2.4



fft3dfilter 2.3 vs fft3dfilter 2.1.1

Maybe different compiler, 80 bit x87 arithmetic vs 64 bit IEEE double/float, or rounding, etc...
I have found a build of 2.1.1 version from 2011 which is giving identical results to the current 2.2.4 but is different from the original 2007 version.
Nevertheless, the differences are very minor.
Even the existing C and SSE results are different within the same plugin, so I don't think we should put more time into investigating bit-identical outputs in this case.

[pinterf]

Originally Posted by hello_hello

I did.

tr
Temporal radius, > 0. Must match the mvmulti content, i.e. the delta parameter in MAnalyse.

MDeGrainN (
clip,
clip super,
clip mvmulti,
int tr,
int thSAD (400),
int thSADC (thSAD),
int plane (4),
int limit (255),
int limitC (limit),
int thSCD1,
int thSCD2,
bool isse,
bool planar,
bool lsb (false),
int thSAD2 (thSAD),
int thSADC2 (thSADC),
bool mt (true)
)

MDegrainN's signature:
ccci[thSAD]i[thSADC]i[plane]i[limit]i[limitC]i[thSCD1]i[thSCD2]i[isse]b[planar]b[lsb]b[thsad2]i[thsadc2]i[mt]b

Even super and mvmulti are named in the documentation but cannot be specified with their names.

[hello_hello]

pinterf,

Thanks for your efforts. The "tr" thing seems odd, but at least now I know why.

Cheers.

[pinterf]

New mvtools2 release, fixed broken MDegrainN chroma.
Thanks hello_hello for the report.

Download mvtools2 2.7.21.22 with depans

- 2.7.21.22 (20170629)
  Fix: [MDegrainN] fix chroma plane processing

[MysteryX]

I'm trying to build MvTools2 to run it into a profiler to see if anything comes up while running with MT.

How do I get it to build? It needs YASM.

I downloaded the x64 version of YASM. Extracted to this folder and removed the "vs" in front of each file so it's called "yasm"
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\BuildCustomizations\

Then I copied vsyasm.exe to
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\bin\

I changed the project to use VS 2017 and WinSdk10.

I get this error

The command ""C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\bin\"vsyasm.exe -Xvc -f Win32 -g cv8 -i "asm/include" -o "Win32\Debug\mvtools\\" -rnasm -pnasm -DPREFIX  asm\Bilinear.asm  asm\fdct_mmx.asm" exited with code 1.

What's missing?

[StainlessS]

MysteryX, could these be related.

https://forum.doom9.org/showthread.p...75#post1742975

https://forum.doom9.org/showthread.p...81#post1780581

[feisty2]

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?

[StainlessS]

Originally Posted by feisty2

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?

I'm sure that Pinterf would appreciate all assistance that you care to offer in doing that, would likely be lots of hard work and a whole bevy of new bugs to iron out, but would give you much satisfaction when you've finally done it successfully.

Looking forward to it.

[MysteryX]

Here are benchmark tests of jm_fps script (simplified version)

function jm_fps(clip C, int Dct) {
    Blksize=16
    BlkSizeV=16
    Dct = Default(Dct, 0)
    NewNum=60
    NewDen=1
    Recalculate = false
    Prefilter = C.RemoveGrain(22)
    superfilt = MSuper(prefilter, hpad=16, vpad=16) # all levels for MAnalyse
    super = MSuper(C, hpad=16, vpad=16, levels=1)
    bak = MAnalyse(superfilt, isb=true, blksize=BlkSize, blksizev=BlkSizeV, overlap = BlkSize>4?(BlkSize/4+1)/2*2:0, overlapv = BlkSizeV>4?(BlkSizeV/4+1)/2*2:0, search=3, dct=Dct)
    fwd = MAnalyse(superfilt, isb=false, blksize=BlkSize, blksizev=BlkSizeV, overlap = BlkSize>4?(BlkSize/4+1)/2*2:0, search=3, dct=Dct)
    fwd = Recalculate ? MRecalculate(super, fwd, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : fwd
    bak = Recalculate ? MRecalculate(super, bak, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : bak
    Flow = MFlowFps(C, super, bak, fwd, num=NewNum, den=NewDen, blend=false, ml=200, mask=2, thSCD2=255)
    return Flow
}

DCT=0, single-thread

FPS (min | max | average):      3.189 | 14.91 | 5.136
Memory usage (phys | virt):     289 | 296 MiB
Thread count:                   21
CPU usage (average):            12%

DCT=0, Prefetch(8)

FPS (min | max | average):      2.933 | 77949 | 15.08
Memory usage (phys | virt):     1401 | 1422 MiB
Thread count:                   29
CPU usage (average):            68%

DCT=1, single-threaded

FPS (min | max | average):      0.160 | 16.01 | 0.448
Memory usage (phys | virt):     314 | 319 MiB
Thread count:                   21
CPU usage (average):            11%

DCT=1, Prefetch(8)

FPS (min | max | average):      0.109 | 66813 | 1.119
Memory usage (phys | virt):     1096 | 1105 MiB
Thread count:                   26
CPU usage (average):            37%

DCT=0 is "fine" with 68% CPU usage. DCT=1 is what gives problems with multi-threading with 37% CPU usage, choppy playback, and occasional freezes -- but DCT=1 is definitely better than before the recent Pinterf fix!

[Groucho2004]

Originally Posted by feisty2

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?

The asm shit tends to be pretty fast if done properly.

[feisty2]

Originally Posted by Groucho2004

The asm shit tends to be pretty fast if done properly.

->

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?

no comment

[Groucho2004]

Originally Posted by feisty2

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?

Define "use intrinsics". There is no automatic ASMShitToIntrinsics converter of which I'm aware. There are ~10,000 lines of asm in mvtools2.

[feisty2]

Originally Posted by Groucho2004

Define "use intrinsics". There is no automatic ASMShitToIntrinsics converter of which I'm aware. There are ~10,000 lines of asm in mvtools2.

https://software.intel.com/sites/lan...rinsicsGuide/#

[Groucho2004]

Originally Posted by feisty2

https://software.intel.com/sites/lan...rinsicsGuide/#

Very good, you posted the Intel intrinsics reference. I still don't see the magic that converts 10000 lines of ASM shit to intrinsics.

[Groucho2004]

Originally Posted by feisty2

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?

By the way, what did you do with the asm shit in your VS single precision mvtools?