MVTools-pfmod

[tormento]

Yes that's my plan, in the realm of what is possible with avs+ I will try to run a per-scene rolling average of peak luminance.


That would be great. I have tried to convert Zack Snyder’s Justice League from HDR to SDR and I found they used different peak for every scene. I quit the project. If you want to have a good benchmark, try with it.

[zorr]

Hi, the docs on MBlockFps say there is parameter float thres (0). It however doesn't exist, instead I found (looking at the code) that there is parameter ml.

It looks like ml should be a float value as the function signature has defined it as double

MVBlockFps::MVBlockFps(
PClip _child, PClip _super, PClip mvbw, PClip mvfw,
unsigned int _num, unsigned int _den, int _mode, double _ml, bool _blend,
sad_t nSCD1, int nSCD2, bool _isse2, bool _planar, bool mt_flag,
IScriptEnvironment* env
)

It doesn't seem to accept a float value though, the error message is "Script error: the named argument "ml" to MBlockFPS had the wrong type". Integer values work fine.

Also if anyone knows what's the recommended range for the ml parameter and is it perhaps dependent on the mode? I have a theory that modes 0-3 have a completely different range (0.0 - 1.0 ?) than the other modes but I haven't been able to test it because ml doesn't accept a float.

[patul]

Zorr,

While the wiki is seemed to be not updated yet, if you check here (http://www.avisynth.nl/users/fizick/mvtools/mvtools2.html), the ml value is not 0.0-1.0, but

ml: mask scale factor. Default=100.

But I don't know, whether pinterf made any changes on this.

EDIT:
I think what happened was, pinterf forked mvtools from Firesledge's version 2.6.0.5, the float thres(0) was there, hence the documentation. Then along the way pinterf partially merged changes from Fizick's with double _ml parameter in this commit (https://github.com/pinterf/mvtools/commit/28ab958b7f34b67c94ad2c1db42dd3ae781acec1#diff-0e54059c778bbb5448b3f35026dc516cce97c60971caecf40b6cc035f13ae158), however the documentation was still the Firesledge's version.

[kedautinh12]

For pinterf ver, you can check wiki here:
https://github.com/pinterf/mvtools/tree/mvtools-pfmod/Documentation

[pinterf]

For pinterf ver, you can check wiki here:
https://github.com/pinterf/mvtools/tree/mvtools-pfmod/Documentation
Thanks for pointing that, yes, specifically the mvtools2.html which I maintain, and is included in the downloadable release packages as well.

[patul]

@pinterf, what about thres & ml parameters mentioned by zorr above (and also edited part of my post)?

[pinterf]

It seems that in MBlockFps the ml parameter was left as 'integer' instead of float. This must be a bug.
MMask, MFlowInter, MFlowFPS are all float.

env->AddFunction("MMask", "cc[ml]f[gamma]f[kind]i[time]f[Ysc]i[thSCD1]i[thSCD2]i[isse]b[planar]b", Create_MVMask, 0);
env->AddFunction("MFlowInter", "cccc[time]f[ml]fb[thSCD1]i[thSCD2]i[isse]b[planar]b[tclip]c", Create_MVFlowInter, 0);
env->AddFunction("MFlowFps", "cccc[num]i[den]i[mask]i[ml]f[blend]b[thSCD1]i[thSCD2]i[isse]b[planar]b[optDebug]i", Create_MVFlowFps, 0);
env->AddFunction("MBlockFps", "cccc[num]i[den]i[mode]i[B][ml]i[blend]b[thSCD1]i[thSCD2]i[isse]b[planar]b[mt]b", Create_MVBlockFps, 0);

EDIT: I'm gonna arrange a fix soon

[pinterf]

Mvtools2 2.7.45
https://github.com/pinterf/mvtools/releases/tag/2.7.45

[kedautinh12]

Thanks

[GMJCZP]

Thank you very much.

[real.finder]

new out32 seems broken
super_search = MSuper(rfilter=4)

bv2 = super_search.MAnalyse(isb = true, delta = 2, overlap= 4)
bv1 = super_search.MAnalyse(isb = true, delta = 1, overlap= 4)
fv1 = super_search.MAnalyse(isb = false, delta = 1, overlap= 4)
fv2 = super_search.MAnalyse(isb = false, delta = 2, overlap= 4)

MDegrain2(MSuper(levels=1), bv1, fv1, bv2, fv2, out32=true, thSAD=300, thSADC=150)

with 8bit input it give 8bit output, with 10-16 input give same bitdepth as input but also pink output

[pinterf]

As I wrote in the change log, do not use it. Experiment/debug/fun better not knowing about it. Even the name is stupid, because I intended to test the internal overlaps calculation simplificatiin to use floats instead of integer magic which rounds at least twice during the process. I' going to test when it is worth to use it. Either speed or quality-wise. So it is only for me but I appreciate the feedback.

[zorr]

Thanks for pointing that, yes, specifically the mvtools2.html which I maintain, and is included in the downloadable release packages as well.

Yes, that's the one I was looking at. But it's fixed in the latest release, thanks!

[tormento]

There is a mistype in MVTools-2.7.45 html:

gf<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang='en' xml:lang='en' xmlns="http://www.w3.org/1999/xhtml">

[zorr]

For me the new SIMD intrinsics code for MSuper: rfilter=0 and 1 is a bit slower than the old SSE version. The impact was about 50ms in a script with 4 x MSuper, 4 x MAnalyse and 2 x MFlowFPS which takes about 4 seconds to run (this of course depends a lot on the parameters of the other functions).

However the new MSuper: sharp=1 version is faster.

[pinterf]

For me the new SIMD intrinsics code for MSuper: rfilter=0 and 1 is a bit slower than the old SSE version. The impact was about 50ms in a script with 4 x MSuper, 4 x MAnalyse and 2 x MFlowFPS which takes about 4 seconds to run (this of course depends a lot on the parameters of the other functions).

However the new MSuper: sharp=1 version is faster.
I suppose bit depth is 8, and processor type is at least sse 4.1?
EDIT: In the original asm code there was a missing rounder, which was fixed (reference methods in C were O.K.). This means that the new version one more addition and an extra register to use. But I think the speed difference for this change is probably neglible in the final benchmark for x64, but probably even for 32 bit versions.
EDIT2: sse4.1 has difference and is quicker than sse2 only in 10+ bit clips using the modes above.

[zorr]

I suppose bit depth is 8, and processor type is at least sse 4.1?

Correct, I tested on Ryzen 3900X. The measurement was done using one thread only (and no prefetch), median of 10 runs. Consistent and repeatable.

EDIT: In the original asm code there was a missing rounder, which was fixed (reference methods in C were O.K.). This means that the new version one more addition and an extra register to use.

Correct code is of course more important than a minor performance regression, and this is really very minor. Thanks!

[MysteryX]

There is MvTools for Avisynth and also a VapourSynth version here (https://github.com/dubhater/vapoursynth-mvtools). What's weird is that the Mask output is completely different between Avisynth and VapourSynth libraries; I'd guess the VapourSynth one is more accurate by fixing some bugs in the old Avisynth code.

However the VapourSynth Mask code doesn't support 16-bit (https://github.com/dubhater/vapoursynth-mvtools/issues/16), and Analyze code could be expanded to support blksize 12 and 24. The author of the VapourSynth library has no plan on fixing those anytime soon. Perhaps someone else could take on these tasks, and as I mentioned elsewhere -- it wouldn't be hard to make those libraries work on both platforms at once with just a bit of code abstraction. And Pinterf, you're very familiar with the whole MvTools codebase, and know how to write assembly code, so that probably would be easiest for you (if you find time!)

[real.finder]

it wouldn't be hard to make those libraries work on both platforms

maybe, but vs devs don't do this even if the plugin already work on both https://forum.doom9.org/showpost.php?p=1944391&postcount=1330 so why you ask avs+ dev about this?!

[MysteryX]

maybe, but vs devs don't do this even if the plugin already work on both https://forum.doom9.org/showpost.php?p=1944391&postcount=1330 so why you ask avs+ dev about this?!
Perhaps devs didn't realize how easy it is to make it work for both; it's actually easier because it separates Avisynth/VapourSynth management from the more complex plugin code.

Perhaps there's also silent rivalry between one platform or the other. But really it makes no sense.

In the future I'd just write plugins working for both out-of-the-box. The extra code needed is just boilerplate copy/paste from one project to the next.

btw Avisynth has a lot more devs. VapourSynth platform is good but lacks in devs.

[real.finder]

I think VapourSynth has a lot more devs not avs+ https://github.com/HomeOfVapourSynthEvolution and many others! except scripting cases and tools like Avspmod (which gispos do nice work about it) avs+ only got pinterf, Asd-g and qyot27 for now and some plugins makers like wonkey_monkey and StainlessS

Also vs now got no more features than avs+ since 3.7 release (avs+ now has Cross Platforms and new Syntax additions like Array and another new things and frame properties), and in same time VapourSynth now lost win7 users!

And at least for doom9 community avs+ got the vast majority of users https://forum.doom9.org/showthread.php?t=182887 but I think VapourSynth still got majority of Discord Anime fansub encoders

[feisty2]

there's no "rivalry" per se. it's more of a general lack of interest. most plugin developers are themselves the user of a particular frameserver program, and they develop plugins for whatever they use. very few people use both avs and vs.

[MysteryX]

there's no "rivalry" per se. it's more of a general lack of interest. most plugin developers are themselves the user of a particular frameserver program, and they develop plugins for whatever they use. very few people use both avs and vs.
That was the case for me; hence porting anything to VapourSynth was not a priority at all. Primarily because I didn't know how and nobody has instructions for it.

But once you know -- and with the right boilerplate code -- writing for both is just as easy. I wouldn't be a bad idea for me to produce a video of quickly porting a plugin to work on both.

As for MvTools2, it wouldn't be a bad idea either to explore why the mask is so different in both versions; and perhaps even merge them instead of having 2 separate code-bases to maintain.

[MysteryX]

Also vs now got no more features than avs+ since 3.7 release (avs+ now has Cross Platforms and new Syntax additions like Array and another new things and frame properties), and in
wow Avisynth made a lot of progress lately! I'm not seeing those in the 3.7 change log though, where can I read about those newer additions?

[StainlessS]

There are a few repo's about [I get confused too],
Pinterf [2772-MT]:- https://github.com/pinterf/AviSynthPlus/tree/master
Quot27[3.7.0]:- https://github.com/AviSynth/AviSynthPlus/releases

[there might be more, I aint sure :) ]

EDIT: thanks RF.

[real.finder]

wow Avisynth made a lot of progress lately! I'm not seeing those in the 3.7 change log though, where can I read about those newer additions?

in fact those changes was before 3.7 but 3.7 are more stable than 3.6

most of those changes come from backport from avsneo you can read https://forum.doom9.org/showthread.php?t=181351 and "Did you know" from pinterf starting from https://forum.doom9.org/showthread.php?p=1913646#post1913646

[real.finder]

There are a few repo's about [I get confused too],
Pinterf [2772-MT]:- https://github.com/pinterf/AviSynthPlus/tree/master
Quot27[3.7.0]:- https://github.com/AviSynth/AviSynthPlus/releases

[there might be more, I aint sure :) ]

https://github.com/pinterf/AviSynthPlus/tree/master is dead now, pinterf now adding changes directly to https://github.com/AviSynth/AviSynthPlus which is the main and original repo not only Quot27

[pinterf]

wow Avisynth made a lot of progress lately! I'm not seeing those in the 3.7 change log though, where can I read about those newer additions?
See readme.history in https://github.com/AviSynth/AviSynthPlus/tree/master/distrib/Readme
(in fact they are almost the same, the readme_history.txt is a bit more verbose, mostly for older features)
These files are copied in the Avisynth installation folder as well and in my intermediate test 'files-only' builds

[zorr]

I'd like to experiment with manipulating the vectors created by MAnalyse. First something simple like calculating multiple variations and taking the median. But it would also be fun and perhaps useful to go full Inception and feed the vectors back into MVTools for temporal denoising. There's a lot of potential for new/improved functionality if the vectors could be manipulated in ordinary AviSynth code.

So I'd like to request a new MStoreVect / MRestoreVect format which has these features:
-outputs the vector X and Y components so that each is represented by a single pixel
-X coordinates separated from Y coordinates (this makes manipulation easier)
-vectors would start from X coordinate 0 (the header data would be padded)
-image width would be the number of horizontal blocks

It would then be easy to grab the vectors with Crop, manipulate them and restore them back into the original image and then back into MVTools with MRestoreVect.

I looked at the vector's definition, X and Y are integers so that would mean the clip would need to be Y32 but since that means floats the whole range cannot be represented (only 24 bits). However, the maximum realistic vector lengths should be about pel*clip.width so it should easily fit into 16bits (or am I not understanding something?). I think even 8 bits is enough for most cases, movement could still be <= 31 pixels per frame with pel 4 (assuming only frames N-1 and N+1 are used).

It would perhaps be useful to be able to recalculate the SAD values after the vectors have been updated, but that's just a bonus feature, being able to manipulate the vectors would already be great!

What do you think pinterf, is this feasible and not too burdensome to implement? :)

[tormento]

I'd like to experiment with manipulating the vectors created by MAnalyse.
How much I would like that all these efforts could one day arise to a MVCUDA version.

[Dogway]

Currently mvtools is the bottleneck of most scripts, I calculated that for a 2h feature we need a performance of at least 5fps to finish an encode in 10h, good value for an overnight encode. I think this is still a bit far when using refinemotion (a must in my book) -1080p @ 16-bit-.

[tormento]

Currently mvtools is the bottleneck of most scripts, I calculated that for a 2h feature we need a performance of at least 5fps to finish an encode in 10h, good value for an overnight encode. I think this is still a bit far when using refinemotion (a must in my book) -1080p @ 16-bit-.
Can you explain me the use of trymany and the best case scenario? The MVTool documentation is not really explicit.

[arnea]

I need to use MDepan with super clip created with negative delta (i.e. I want to stabilize clip globally in relation to one specific frame). However MDepan does not support this at the moment. There is a check in constructor that throws error when mvclip.nDeltaFrame is not 1.

What needs to be changed in order to make it work? I could do the modifications but perhaps someone can point me in right direction.

For background: I scanned an old 8mm films using Wolverine Hawkeye scanner. The films were in bad condition and the frames are not aligned with each other. I did an overscan and hoped to use the perforation as an anchor for stabilization. My plan was to crop frames so that only perforation part was left and calculate the needed shifts based on this clip. Then apply to the shifts to the original clip so that all frames are aligned with each other and finally crop the clip so that only image area remains. I do not want to stabilize or process the clip itself - I want to keep the original camera movements.

Most of the stabilizers do the stabilization in relation to previous frame or frames. Those stabilizers removed the quick jumping from frame to frame, but frames still slowly drifted. My thinking was that I should calculate the needed shifts in relation to single (first) frame of the clip.

MVtools is so far the only stabilizer that allows to specify single reference frame. I planned to create offsets for Depan and then use it to do the stabilization but alas for some reason it is not supported by MDepan.

Or are there any other stabilizers that could do this?

[arnea]

I read the MVDepan.cpp source and at first it seems that when I do forward search and set the range to 0 then it should be ok.

[real.finder]

don't know if it possible to add more things from 2.5.11.9-svp (https://web.archive.org/web/20150206030422/http://www.svp-team.com/files/gpl/mvtools-2.5.11.9-svp.zip) same as https://forum.doom9.org/showthread.php?p=1704418&highlight=search_coarse#post1704418 but seems one of the reasons that vs port act in a different way (aside from hpad and vpad are 8 in avs but in vs they are 16)

using this YV12 source (https://www.sendspace.com/file/jpne22)

AVISource("mv test.avi")
super_search = MSuper(hpad=16,vpad=16)

bv1 = super_search.MAnalyse(isb = true, delta = 1, overlap= 4)

MMask(last, bv1)

in frame 1 (2nd one) I got

https://i.postimg.cc/xqKjwCYz/avs.png (https://postimg.cc/xqKjwCYz)
in avs mvtools in x64 avs+

and
https://i.postimg.cc/wtr6gYyn/avs-svp.png (https://postimg.cc/wtr6gYyn)
in old mvtools-svp in avs

and
import vapoursynth as vs
core = vs.get_core()
clip=core.lsmas.LWLibavSource(source=r'mv test.avi')
super_search = core.mv.Super(clip)

bv1 = core.mv.Analyse(super_search, isb = True, delta = 1, overlap= 4)

clip=core.mv.Mask(clip, bv1)
clip.set_output()
https://i.postimg.cc/ZWzDd732/vs.png (https://postimg.cc/ZWzDd732)
in vs

maybe those can help https://github.com/dubhater/vapoursynth-mvtools/commit/fb96fd14fbee05ba72e80faff23e3b0d65db7f9b and https://github.com/dubhater/vapoursynth-mvtools/commit/6f5d0134fd3c2322da23b53f8f770eda9f2700f9

making avs act same will break the compatibility with existing scripts so they should be activated with some parameter

[wonkey_monkey]

Arnea,

I have a plugin in development which should do exactly what you want. I've been meaning to release it for a while but haven't got round to it yet.

Can you post a sample so I can test it?

[DTL]

I see note on the last release at github:

experimental avx2 for MDegrain1..6 (was not worth speedwise on my i7700 - memory transfer is bottleneck)

I currently interested in MDegrainN with tr about 12 (about 1 second of time at 25fps). So it mostly probable will be memory limited so with current design it is no help of put more SIMD optimizations ?

May be try to walk to 'segmented frame' memory approach as frame size moves from SD to UHD is not possible to fit several frames into cache (even largest L2/L3). So it may be less easy to handle in program but it will allow the time-axis data of several frames to be in the cache at the same time. May be it can be simulated now with scripting - like cut frame to pieces and process in sequential order (or may be better in separate threads). It will also introduce more hardness with inner-frame edges of pieces (or may be just skip some possible to process blocks as they move between pieces of frame).

Also I read many about DRAM pages switching but still can not found good examples how to use it for real optimizations. But also for fastest access to some limited in size block of data it is better to store it in the same DRAM page. Finding what is DRAM page size at given hardware execution system may be separate task and (physical) addresses DRAM pages start/end. Because as I understand the DRAM page size is about equal to Row number of bits in current DRAM modules and it may greatly depends on the physical memory installed.
Also because of virtual memory approach in Windows it may required special memory allocation routine to allocate contiguous physical memory area (having some fixed number of physical DRAM pages and aligned to DRAM page start/end address). It may be solved in ring0 by installing custom driver providing memory allocation function to user-space with contiguous physical addressing.
Unfortunately AllocateUserPhysicalPages() in user-mode can not provide physical pages to be contiguous in physical addressing. It looks on todays Windows only MmAllocateContiguousMemory() in kernel mode may helps.
So it looks good to make some custom memory manager with system-startup driver (when physical memory allocation still not very fragmented and it is possibly to allocate large enough buffers for MDegrainN to run) and test it for performance for read-write between addresses to determine the actual DRAM pages start/end borders.
As article https://www.researchgate.net/publication/333939622_Design_of_Processing-Inside-Memory_Optimized_for_DRAM_Behaviors shows - the mapping of physical addresses to DRAM rows may be easy enough like some MSB of address encodes rows and all other LSBs encode something else inside row (that is natural to try to get less possible rows/(pages)-switching with sequential memory access). But the exact bit of PHY address where the rows addressing starts may be need to be determined. As the article shows the 'size' of PHY DRAM page (i.e. when rows start to switch) may be 14 LSB bits of address that is about 16 kBytes. 8 typical Windows-OS pages of 4 kBytes.

Not sure how much it may help with hardly memory-bound processing but it still may be some step in performance with still limited to host CPU and host memory software.

Also as I already post in some thread 'segmented frame' approach of frame buffers in memory layout may be useful with most of large-frames processing because with HD/UHD frames the row stride become very large and easily run-outs of L1 cache size if trying to access even small 8x8 block of 1 frame. So the hardware auto-prefetch looks like can not handle such memory access well and start to re-write many caches with non-needed prefetched data. So reading one 8x8 block of 1 frame and next 8x8 block of other frame cause great cache re-write and wipe old data (useful for processing neibour blocks). Also may be with accessing different DRAM physical pages so forcing memory to page-switching (closing current row and opening other) and degrade poor performance even more.
From https://my.eng.utah.edu/~cs7810/pres/11-7810-12.pdf
Row buffers act as a cache within DRAM
 Row buffer hit: ~20 ns access time (must only move
data from row buffer to pins)
 Empty row buffer access: ~40 ns (must first read
arrays, then move data from row buffer to pins)
 Row buffer conflict: ~60 ns (must first writeback the
existing row, then read new row, then move data to pins)
So it may be good to organize DRAM access at processing with using most of current 'open row /DRAM page' for read-write and attempt to keep in CPU cache read data from later used DRAM pages. It may possibly helps to performance.

[pinterf]

Degrain itself is quick. Most time is spent in vector search, working with 8x8 pixel blocks not even requires the sse xmm registers in 8 bit videos.

[DTL]

As I understand vector search in many frames sequence require fetching of the small blocks (like 8x8) from all frames from close enough distance inside each frame. Also if it uses planar data and all 3 channels - is x3 more pain on fetching bytes from different DRAM pages/rows. So interleaved formats really not very bad for processing colour data.
So may be before start of processing perform re-arranging of input data in the way to maximize DRAM row/page hits with the current memory access pattern (and may be change pattern if possible too). As noted the presentation the memory controller in the system tries to re-arrange memory access to maximize row/page hit rate but it is good to help starting from application.

Yes - it will add the time for re-packing before and after processing as Avisynth currently do not support 'segmented frame (tiled ?)' formats for in and out to plugins. But if performance benefit will be more than loss on re-packing it will help.

Current 1920x1080 planar 16bit Y plane have stride of 3840 bytes and 16 kByte DRAM page fits only about 4 rows of frame. The UHD 4K is even worse. For fetching data for even 8x8 block the 1 more DRAM page switch required for 2K and +3 switches for 4K. One idea about segmenting was - if the H and V access distance is about equal - so make segment to fit 1 DRAM page size as a square. Like 16K page and 16bit samples - 64(2byte)x128. Many 8x8 blocks will fit into 1 DRAM page and search with large enough radius will also hit with 1 DRAM page for the reading of whole 8x8 blocks.

If vector search is performed with many reads from small frame's areas (it possibly will be cached in some form) - it may be better to re-arrange parts of frames before processing to sit in less number of DRAM pages. Will try to look at the typical RAM accessing pattern at the vector search.

"working with 8x8 pixel blocks not even requires the sse xmm registers in 8 bit videos."

So memory-bounding is so awful that even SSE 128bit make almost no help in speed ?

[DTL]

Tried to test segmented frame processing:

Function DG(clip c)
{
tr=12
super=MSuper(c,pel=1)
multi_vec=MAnalyse(super, multi=true, delta=tr, overlap=4)
return MDegrainN(c, super, multi_vec, tr, thSAD=400, thSAD2=250)
}

.. 1920x1080 separated fields clip here YV12

ExtractY()

lg=Crop(0,0,1920,256)
DG(lg)



and cutted to 128x128 pieces:

Function DG(clip c)
{
tr=12
super=MSuper(c,pel=1)
multi_vec=MAnalyse(super, multi=true, delta=tr, overlap=4)
return MDegrainN(c, super, multi_vec, tr, thSAD=400, thSAD2=250)
}


ExtractY()

dg01=Crop(0,0,128,128).DG()
dg02=Crop(128,0,128,128).DG()
dg03=Crop(128*2,0,128,128).DG()
dg04=Crop(128*3,0,128,128).DG()
dg05=Crop(128*4,0,128,128).DG()
dg06=Crop(128*5,0,128,128).DG()
dg07=Crop(128*6,0,128,128).DG()
dg08=Crop(128*7,0,128,128).DG()
dg09=Crop(128*8,0,128,128).DG()
dg010=Crop(128*9,0,128,128).DG()
dg011=Crop(128*10,0,128,128).DG()
dg012=Crop(128*11,0,128,128).DG()
dg013=Crop(128*12,0,128,128).DG()
dg014=Crop(128*13,0,128,128).DG()
dg015=Crop(128*14,0,128,128).DG()


dg101=Crop(0,128,128,128).DG()
dg102=Crop(128,128,128,128).DG()
dg103=Crop(128*2,128,128,128).DG()
dg104=Crop(128*3,128,128,128).DG()
dg105=Crop(128*4,128,128,128).DG()
dg106=Crop(128*5,128,128,128).DG()
dg107=Crop(128*6,128,128,128).DG()
dg108=Crop(128*7,128,128,128).DG()
dg109=Crop(128*8,128,128,128).DG()
dg110=Crop(128*9,128,128,128).DG()
dg111=Crop(128*10,128,128,128).DG()
dg112=Crop(128*11,128,128,128).DG()
dg113=Crop(128*12,128,128,128).DG()
dg114=Crop(128*13,128,128,128).DG()
dg115=Crop(128*14,128,128,128).DG()


up=StackHorizontal(dg01,dg02,dg03,dg04,dg05,dg06,dg07,dg08,dg09,dg010,dg011,dg012,dg013,dg014,dg015)
lo=StackHorizontal(dg101,dg102,dg103,dg104,dg105,dg106,dg107,dg108,dg109,dg110,dg111,dg112,dg113,dg114,dg115)
StackVertical(up,lo)


The 128x128 pieces version of Y8 format works about 4% faster at Core2Duo E7500 CPU. Though it have some more cut/stack operations. And uses non-DRAMpage aligned buffers. May be with 128x128 frames it makes less vector search operations ?

With 128x256 size of piece and 1920x512 total frame size it is about 5.5% faster. Here system have 2 channels and they can also add +1 bit before row switching so may be actual 'size of fastest memory contiguous area' may be from 8 to 32 kBytes and may be more depending on channels number, ranks and bank size. But there also some sad info - at some systems memory controller may XOR some row LSBs with other address bits to make some stride arrays access (large enough - like 100 kBytes) to hit same row. So real rows switching addresses is not monotonically increases even in physical address space. So exact performance gain of attempt to data exchange to same rows of SDRAMs as much as possible depends on the current machine configuraion and settings of memory controller (may be only mainboard manufacturer knows how it is configured - it is not even OS config usually).

[real.finder]

making avs act same will break the compatibility with existing scripts so they should be activated with some parameter

I note that setting lsad=0 (MAnalyse(isb = true, delta = 1, overlap= 4, lsad=0)) will crash
https://i.postimg.cc/c4hJcVrF/Untitled.png (https://postimages.org/)
but it's fine in vs, is there are bug that vs mvtools fixed or vs mvtools has hidden changes (that prevent it from happen) as always?

edit:

another news, vs mvtools v7 (edit: I am in v21 now and it still same as v7) act very similar to svp
https://i.postimg.cc/XpQrBztY/vs-mvtools-v7.png (https://postimg.cc/XpQrBztY)

[pinterf]

Div by zero is real crash and usually indicates a bug, at least a missing parameter validity check. Minimal script is available or I should just use that mvanalize line?

[real.finder]

Div by zero is real crash and usually indicates a bug, at least a missing parameter validity check. Minimal script is available or I should just use that mvanalize line?

AVISource("mv test.avi (https://www.sendspace.com/file/jpne22)")
super_search = MSuper(hpad=16,vpad=16)

bv1 = super_search.MAnalyse(isb = true, delta = 1, overlap= 4, lsad=0)

MMask(last, bv1)

also update for vs mvtools case, even v23 work same as avs one! I was use VapourSynth64Portable_2020_09_06.7z since long time and now even new download of VapourSynth64Portable_2020_09_06.7z give similar output to avs! I Shouldn't have overwrite the libmvtools that in old VapourSynth64Portable_2020_09_06!

[DTL]

Some question about building with GCC from msys2 (it looks I damage my VisualStudio2015 install trying to clean winsxs directory so it can not even open project properties window):
The files looks like built OK. The only warnings about NOMINMAX define.
The built .dlls (mvtools2.dll and depans) looks like loads into Avisynth (require some additional gcc .dlls - libgcc_s_seh-1.dll , libstdc++-6.dll , libwinpthread-1.dll ).
But at attempt to run script - Avisynth throws errors: Can not found MSuper, MAnalyse, MDegrainN functions.

Latest Msys2, gcc version 10.3.0 (Rev5, Built by MSYS2 project). Used 64bit msys2 and minigw64. Latest testbuild of Avisynth+ from pinterf (3.7.0 (r3382, 3.7, x86_64).
Latest sources from github - mvtools-2.7.45 .

Also attempt to build Debug versions (for debugging and profiling with source text) with command

cmake --build . --config Debug

Build .dlls of the same size as --config Release (about 13 MByte for mvtools2.dll).

[qyot27]

Don't build C++ interface plugins with GCC unless you know what you're doing. Or you're on Linux. Or Mac. Or BSD. Or Haiku.

[DTL]

Readme.md directly lists the build method of GCC and cmake at msys2. And listed make and build commands work and produces result .dlls. May be it require special versions of each tool (not listed) ?
I do not even have idea how to debug why functions not visible from loaded .dll. Without any other error.

May be required special headers from windows sdk ? And not from installed to msys2 gcc ? I also do not know why it reqiure additional .dlls from GCC to run (load). May be some settings required for 'static linking' ?

[DTL]

At work I have VS2019 and it build OK.

First strange finding - the disabling of multi-leveling makes MAnalyse significally faster. Test build of mvtools.dll with disabled leveling (use only one 'full-frame' level as I think) https://drive.google.com/file/d/1NQsxPB-kB6AtlE2IbE7fg0bOC2COFfP7/view?usp=sharing .
Changing is MAnalyse.cpp add line 261 nLevelsMax = 1;

At practical

tr = 12 # Temporal radius
super = MSuper ()
multi_vec = MAnalyse (super, search=3, searchparam=8, multi=true, delta=tr,overlap=4)
MDegrainN (super, multi_vec, tr, thSAD=400, thSAD2=150)


Also it allows super = MSuper (levels = 1) without throwing error by MAnalyse about not enough levels.
Speedup about 2 times. If it works OK (I still made few tests but looks like working for degraining without visible bugs for now) it may be good to add one more user-param to MAnalyse like 'maxlevels'.

I look into motion search code - it looks it uses 'block vs plane' search and it is not very fiendly with gross SIMD streams processing (and may be not friendly with CUDA/GPU acceleration). But it allows to use non-esa type of logical speed-up.
I think of trying to add 'brute-force' method of simple full-esa 'plane vs plane' comparizon of located in CPU cache planes and selecting best SAD for output.
It is re-write possibly starting from PlaneOfBlocks::SearchMVs() function. Do any documentation available for the output formay of data returned by this function ?
I see the method of writing output file of MVs - it is simple enough like frame number and x,y,SAD of each block. But the return by MAnalyse 'motion clip' looks like more complex.

Addition: As found later the minimum good value for nLevelsMax is 2 because with 1 the searchparam=2 internally and user-defined searchparam (search raduis) not used (looks only one level always uses searchparam=2) . Started to make AVX2 sad functions for radius 2. For larger radius AVX512 will be very useful (less reload data from cache). Current state of design - at github https://github.com/DTL2020/mvtools .
As I see the most easy and some speed-up (possibly about 2..3 times) is re-write PlaneOfBlocks::ExhaustiveSearch(different block size and radus) for processing without branching and at register file of CPU. It possibly available up to searchparam=4 with AVX2-capable CPU. The asm core of ExhaustiveSearch8x8_sp2_avx2() is mostly finished but I still do not know what is the output format of x,y coordinates (usually processed by CheckMV()) - relative to center of block (i.e. -2..2 for s=2) or absolute in the 'workarea' grid ?

[DTL]

About luma-only search and possible gross colour errors with close luma different colour tones:
It is an idea to perform search with Y + sort of Hue channel from HSB colour space. Skip Saturation channel and it will possibly cause much rare and less visible saturation errors.
And processing 2 planes instead of 3 will increase search speed to about 1/3. To make something looking to Hue plane without slow trigonometry from UV channels we need to found some simple and fast math. I think may be even just mix half bits of U and V 8bit channels to form some 8bit bitpacks inherits some variance from U and V channels and put it to 'colour-sad' search pass.

[anton_foy]

About luma-only search and possible gross colour errors with close luma different colour tones:
It is an idea to perform search with Y + sort of Hue channel from HSB colour space. Skip Saturation channel and it will possibly cause much rare and less visible saturation errors.
And processing 2 planes instead of 3 will increase search speed to about 1/3. To make something looking to Hue plane without slow trigonometry from UV channels we need to found some simple and fast math. I think may be even just mix half bits of U and V 8bit channels to form some 8bit bitpacks inherits some variance from U and V channels and put it to 'colour-sad' search pass.

Interesting. Is this the same phenomenon of washed out saturation and losing hues due to overfiltering? I see this especially when filtering chroma with fft3dfilter and other "spatial" denoisers. Dogway mentioned a while ago that he had started to write a YUV to HSL conversion script, maybe this would come in handy?

[DTL]

"Is this the same phenomenon of washed out saturation and losing hues due to overfiltering?"

It was idea how to workaround issue described in https://forum.doom9.org/showthread.php?p=1783361#post1783361 . Without full processing of both colour-difference planes.
Now I see at CheckMV():

sad_t sad=LumaSAD<pixel_t>(workarea, GetRefBlock(workarea, vx, vy));
cost += sad + ((penaltyNew*(safe_sad_t)sad) >> 8);
if(cost>=workarea.nMinCost) return;

sad_t saduv = (chroma) ? ScaleSadChroma(SADCHROMA(workarea.pSrc[1], nSrcPitch[1], GetRefBlockU(workarea, vx, vy), nRefPitch[1])
+ SADCHROMA(workarea.pSrc[2], nSrcPitch[2], GetRefBlockV(workarea, vx, vy), nRefPitch[2]), effective_chromaSADscale) : 0;
cost += saduv + ((penaltyNew*(safe_sad_t)saduv) >> 8);

So it first full process 1 plane (Y usually) and if chroma=true (default) - compute sads for 2 more planes (typically UV). And resulted sad = luma_sad+chroma_sad. But chroma_sad collected from 2 planes (sad_u + sad_v). If the most horrible bug is about chroma tone only - so we can re-arrange chroma data from 2 planes into 1 plane (close to Hue in HSB model for example) and skip 1 of 3 planes search. It will be 'in-between' solution between limited quality luma-only search (sometime causing chroma tone mixing artefacts) and full 3-planes search (more slower).

Unfortunately Avisynth looks like not support converting of YUV into HSB for example and MAnalyse still do not have coded-in selection of planes for search (like 1, or 1+2, or 1+2+3). So it is some work to the future.
Though it is now possible with extract/combine planes to make something like Y + CromaTone mix of channels. Though using of simply pure U or V will already works better in compare with Y-only. But it is better to think about colour-science how to prepare the most useful 8bit data from 2x8 bit U+V channels for best colour tone discrimination. With simple enough math for speed. Full quality YUV to HSB convert require trigonimetric that is very slow with high precision. May be simply selecting upper or lower 4 bits and blend will be enough. But it is require some thinking higher of lower of U and V is better etc. It is not need to follow some high tolerance colour description - it just need to be unique identifier of colour tone. May be simply drop bit-depth of UV to 4 bit and combine to 8bit though they code mostly saturation and colour tone (and very few of brightness) and we need more colour tone.

"YUV to HSL conversion script,"

High quality YUV to HSL require sin/cos/tan and it is very slow. I think we will found some much faster solution for this special task (not need to use derived Hue-like-channel in high quality output).
Wiki lists selection of min/max and case-like processing (of difference and division) to calculate H(ue) https://en.wikipedia.org/wiki/HSL_and_HSV . That is also no good for speed.