MVTools-pfmod

[DTL]

Some first possibly working testbuild with VS2017 - https://drive.google.com/file/d/15v64hHVv2vtB87qddLaZYGHXXKWfpZ9S/view?usp=sharing . For new AVX2 exhaustive search way.
Only chroma=false and searchparam=2 (default ?) and 4. Full levels esa search is search=3 but one of levels always esa(radius=2) so it possibly will partially works on most of search methods. Block size only default 8x8.
Tested only in SDE intel AVX simulator in debug build (still not have AVX-capable chip at my home). So can not measure the performance. Will have access to AVX-capable cpu only at my work a few days in a month.
The MDegrainN triggers some assert (do not know why - may be VS2017 not completely compatible with mvtools project also ?) . So tested with MDegrain2() in debug build.

Unfortunately the new functions still require sadly check for input vector validity - the calling of search with invalid vectors need to be fixed in the future because it may slow process with non-needed checks. If disabled - it will run-out of buffers addresses and crash.

The MShow displays vectors differs from old search (Expanding search) but degrain looks like works without visible blurring so the vectors looks like not very bad.

[DTL]

Design ideas about Y+PseudoHueSat 8+8bit samples SAD processing: (instead of YUV 8+8+8 bit typically (up to) 3 passes)

1. Hue looks like naturally 2D essence so if unrolled to 1D will have discontinuity point. Unfortunately CPU can not process SAD of 4+4 low and high packs of bits of 8bit byte. (Or I still do not know if some math possible). This discontinuity + natural noise will cause large changes of PHS value near some colour tone and it will cause this colour tone blocks to treat as non-equal so they will not be denoised. We can only place it to some rare enough colour tone (I think close to Magenta). The simple 4-quadrants adjusting of the colour tone where discontinuity is happens is feeding PHS() calculation function with +-U and/or +-V values.

2. The Y+PHS coded plane may be processed with 1 pass SAD SIMD AVX2 same (close to) as for 16x8 block size of 8bit samples.

3. Simple enough calculation of PHS value from UV: (in 8bit unsigned, center to 127 codelevel for green colour tone and/or zero saturation)
(DiamondAngle(U,V)-2)*Sat(UV)*some_norm+127.
where
DiamondAngle(x,y):

float DiamondAngle(float y, float x)
{
if (y >= 0)
return (x >= 0 ? y / (x + y) : 1 - x / (-x + y));
else
return (x < 0 ? 2 - y / (-x - y) : 3 + x / (x - y));
} //x and y in 0..1 range, out is 0..4 range.

and Sat(x,y) about ((abs(U)+abs(V)) >> some_norm_value) - sort of saturation.
It may be made as SIMD calculation at runtime or may be simple LUT of 8=f(8,8) bit values that is 16 kBytes in size and will fit in L1 cache. Good to test both ways.

[DTL]

Some working release for test: https://github.com/DTL2020/mvtools/releases/tag/2.7.45-1 .
Due to no user-controls yet it have many build versions:
mvtools2.dll - standard PseudoEPZSearch, Esa search and searchparam 2 and 4 with chroma=false uses new AVX2 SAD.
mvtools2_ml1.dll - maxlevels limited to 1, searchparam only 2.
mvtools2_ml1.dll - maxlevels limited to 2.
mvtools2_glob_med_pred_ml2.dll - maxlevels limited to 2, only global and medium MV predictors, medium speed and quality
mvtools2_no_pred_ml1.dll maxlevels limited to 1, no predictors, fastest speed, lowest motion search quality.

Test script (1080i source):

SeparateFields()
tr=12
super=MSuper(last,chroma=true)
multi_vec=MAnalyse (super, multi=true, delta=tr, search=3, searchparam=2, overlap=2, chroma=false)
MDegrainN(last,super, multi_vec, tr, thSAD=300, thSAD2=200)
Weave()


CPU i5-9600K
AVSMeter results (fps):
release-2.7.45: 7.2
mvtools2.dll: 9.53
mvtools2_glob_med_pred_ml2.dll: 11.46
mvtools2_ml1.dll: 11.31
mvtools2_ml2.dll: 10.03
mvtools2_no_pred_ml1.dll: 18.35

Test encoding average datarate with x264 (no MdegrainN : 24252) (kbit/s)
release-2.7.45: 7866
mvtools2.dll: 7812
mvtools2_glob_med_pred_ml2.dll: 8464
mvtools2_ml1.dll: 8376
mvtools2_ml2.dll: 7844
mvtools2_no_pred_ml1.dll: 9342

So 'compression ratio' with best motion search (slowest) is about 3.08 and worst (fastest) is about 2.6. With difference in MAnalyse speed about 2 times.

So it is really greatly limited with memory-access for SADs for both Refine() search and predictors testing. Attempt to add Prefetch* into FetchPredictors() helps nothing - it really need to reorganize data in memory for better access with predictors-defined pattern.

Pull-request with current version created. Current idea is to add new user-input control like 'predictors=(all, partial, none)' and 'levels=(1,2,all/auto) for MAnalyse. To control quality/speed ratio.

[tormento]

So 'compression ratio' with best motion search (slowest) is about 3.08 and worst (fastest) is about 2.6. With difference in MAnalyse speed about 2 times.
You could run some synthetic benchmark such as SSIM or PSNR. Not always less is better, IMHO.

[DTL]

Do the project compatible with Intel C++ compiler (integrated in Visual Studio) ?

I see some include defines about Intel_compiler. Also from command line I can compile and build .lib with Intel C++ 19.1 (from Parallel Studio XE 2020) for linking with VisualStudio 2019 all other build. (Excluding that .cpp from build in VS2019).

But when I try to switch 'Platform Toolset' to Intel compiler in Visual Studio (or even for the selected .cpp files) - the strange happens: Visual Studio project dies with unability to open project (mvtools) properties pages and unability to build. Same happens with VisualStudio 2017 and 2019 (tried 16.3 and 16.8). The only way to fix - to replace VS project files (.sln, .vsxproj) from the old state.
May be the VS project files are not compatible with IDE Visual Studio with Intel C++ build tools ? May special command line batch file exist to build mvtools.dll from Intel C++ command line interface (environment) ?

I want to try IntelC++ compiler build to test for speed and with many available hardware-specific optimisations.

You could run some synthetic benchmark such as SSIM or PSNR. Not always less is better, IMHO.

It need to be very syntetic because with degrain we do not have 'clean' source to compare with. So only way is to get some clean enough source and to add syntetic noise.

There are possible 2 types of errors with motion search for MDegrain:

1. Block marked as equal (SAD below theshold) by error.
2. Block search missed (not found any better position in compare with initial).

The 1 type errors cause blurring at motion areas and make output MPEG speed lower. It is most bad error because it typically good visible.
The 2 type errors only decrease degrain ratio (typically on motion areas) that is less visble.

[kedautinh12]

I meet error notice when use last ver MVTool2 with TemporalDegrain2Mod


Avisynth script error:
Evaaluate: Unhandled C++ exception!
(C:/Program Files (x86)/Avisynth+/plugin64+/TemparalDegrain-v2.3.1MOD.avsi, line 276)


Turnback to old ver 2.7.44 error was gone
Location error
https://github.com/kedaitinh12/AVSPlus-Plugins/blob/b21b35baf0556e120d2de63ff7557bb5d9c3005d/TemporalDegrain-v2.3.1MOD.avsi#L276

My script:

TemporalDegrain2(limitFFT=2, postFFT=6)

[pinterf]

Hi kedautinh12, I'd need the clip width and height and video format (e.g. YV12?)

[tormento]

It need to be very syntetic because with degrain we do not have 'clean' source to compare with. So only way is to get some clean enough source and to add syntetic noise.
I meant to compare from previous version of MVTools and your ones.

[kedautinh12]

Hi kedautinh12, I'd need the clip width and height and video format (e.g. YV12?)

Here:
https://drive.google.com/file/d/1JrfnSTpy-C961AP7Ww-HI-yXnZpBnsbK/view?usp=drivesdk

[pinterf]

Here: ...
Thanks for the sample clip, so far it works nicely with 2.7.45 at 0.61 fps (no Prefetch)

I've got no NVidia card on developer machine so I'm using

TemporalDegrain2(limitFFT=2, postFFT=5) # BM3DCPU

instead.

[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.

...

Or are there any other stabilizers that could do this?

I've made some progress on this. wonkey_donkey has a plugin in development that did quite good job on the test clip that I provided. However the plugin is not ready yet.

I tried to change the MDepan plugin and removed the check for negative delta. It worked, Depan plugin stabilized the video, but there was still too much movement across the clip.

I then decided to implement my own ideas about using sprocket holes to match the frames globally. It took some time, but it's ready now: https://github.com/arnean/PerfPan Not very efficient implementation, but it worked on the single clip I have at the moment. I will scan more films and see how it behaves.

[kedautinh12]

Thanks for the sample clip, so far it works nicely with 2.7.45 at 0.61 fps (no Prefetch)

I've got no NVidia card on developer machine so I'm using

TemporalDegrain2(limitFFT=2, postFFT=5) # BM3DCPU

instead.

I check again and find out my nvidia driver only standard and no dch. I install dch driver and it's work correctly

[DTL]

Sort of *need for testers* request:

For test-release https://github.com/DTL2020/mvtools/releases/tag/r2.7.46-pre.a.01 (also copy to google disk because of frequent repository removing for forking new actual version - https://drive.google.com/file/d/1Qm5H42ia6wYsD-ckFmU1Nalhl72qut4J/view?usp=sharing ).

Recommended testscript:

tr = 8 # Temporal radius - need testing low (2..3 and high values like 10+)
super = MSuper ()
multi_vec = MAnalyse (super, multi=true, delta=tr,chroma=false,mt=false, levels=2)
MDegrainN (super, multi_vec, tr, thSAD=400, thSAD2=400-1)


2 test cases:
1. Early skip of processing blocks with zero weight. It adds 2 conditions of zero checks that can decrease speed but if weight is zero it skips fetching from memory ref block and skips its processing that will increase speed. The total influence on speed depends on thSAD value and noise level in the processed footage. (Zero weights occur when blockSAD > thSAD and blockSAD increases with increasing of noise amplitude).

Files: mvtools2_ww_es.dll - use early zero weight skip, mvtools2_ww_ns.dll - use old all blocks processing without condiitons. Currently fast zero weight skip only used in MDegrainN_sse2 so to test with low tr (2..3 the thSAD must be different from thSAD2 - to use MDegrainN instead of MDegrain2,3). Required tested tr values - low as about 2..3 and higer like 10.

2. Modification of weights of blocks to average. Old/classic MVtools uses additional weighting of blocks below thSAD with linear function
f(x)=(thSAD^2-blockSAD^2)/(thSAD^2+blockSAD^2)
It causes the blockSADs close to thSAD(2) to get low weights (close to zero if blockSAD slightly below thSAD). That decreases degrain ratio but may help to prevent more blurring if 'Type1' error occur (block have SAD below thSAD but it is not noised block but different block (moved/scaled/rotated etc).
So using same sad-wise method for both motion compensating and selecting (and weigthing) blocks for avaraging is not totally error-free and nice. And may need more logical supplementing.
So it looks the 'weighting of weights' method is the great field for finetuning and need to be additional user-param for MDegrain*() functions.
Currently for test is 2 builds:
mvtools2_ww_es.dll - old/classic linear weighting of weights
mvtools2_eqw_es.dll - equal weighting of all blocks below thSAD(2). It is also a bit faster because no double float division is required.
The using of thSAD2 in MDegrainN only a bit lower thSAD increase degrain ratio but may cause more blurring (and other bugs) with motion.
Test task: to check if mvtools2_eqw_es.dll produce better degrain ratio with all other equal params (tr mostly and thSAD(2)) and if introduce some visual quality degradation - to describe it. It possibly applies to all MDegrain* functions because of MDegrain3.h header file.

These builds also may contain test of OpenMP in MAnalyse() enabled to it better to disable avstp mt for MAnalyse(). Also MAnalyse() have new params
optSearchOption=0 (default), if =1 - use new _avx2 esa search functions for search=3 and searchparam=2,3,4 (3 and 4 still not debugged in this build), and block size 8x8 and chroma=false and nPel=1 (in MSuper).
optPredictorType=0 (default), if =1 - use partial predictors (faster but less vectors found and less degrain quality), if =2 - use no predictors - faster than (1) but less quality. To use searchparam > 2 the 'levels' must be >1.

One bad use case for 'classic' weights weighting:
The natural photon-shot noise have Poisson distrubution (coming to Gauss with practically large numbers of photons per sample) and it have both low and high deviations from mean value. It cause SAD deviations also low and high.
When block with high SAD deviation is in tr-scope of degrain process (but still below thSAD) it got low weight to most of other blocks and low include its content to other blocks. But when processing reach this block - all other blocks in tr-scope got low weights and this block keeps most of its deviation after weighted-averaging. And in MPEG-compression later this block treats as different block and increases bit number for frame.
I think 1-pass idea of comparing current block SAD with others is not perfect - may be better to compare 'previous-averaged' (that is close to expected block looking) SAD with others. But it looks like need multi-pass degraining. With second SAD-search process of '1-pass-degrained plane' with input source. May be it is hard to implement in 1-pass scripting without intermediate 1-pass degrained full plane output to temp file.

So current thSAD value need to be high enough to make good weights for blocks with large noise-deviated SADs but low enough to decrease rate of 'block not equal' errors. I think this contradiction may be somehow (better) resolved. With sad-independent weighting (simple averaging of all tr-scope blocks with sad below trSAD) we can have lower thSAD value with still catching into processing the more blocks with high noise-deviated SADs.

[Dogway]

I think some MDegrain values are not auto-scaled for 32-bit float, as I could see limit and limitc, didn't test more.

[Dogway]

2 weeks later but with the same issue, the wiki (http://avisynth.nl/index.php/MVTools)states that MDegrain and MSuper support 32-bit float, yet all I get is a black screen.

ConvertBits(32)

super_search = ConvertBits(8).MSuper(rfilter=4)
bv1 = super_search.MAnalyse(isb = true, delta = 1, overlap= 4)
fv1 = super_search.MAnalyse(isb = false, delta = 1, overlap= 4)
MDegrain1(MSuper(levels=1), bv1, fv1, thSAD=300, thSADC=150)

[DTL]

Looks like a bug in 32-bit codepath. It looks MDegrainN have some support of 32bit format but in C-reference only (slow). PlanarRGB 32bit same black screen also.

Update - some testbuild with SIMD-based FetchPredictors() - https://github.com/DTL2020/mvtools/releases/tag/r.2.7.46-a.03 . It looks it was slow because of too many conditional tests and branching in the CheckMV() and Median(). Now it is fully redesigned to SSE(4.1 minimum required). The clipping may differs from old versions so new is only called with optSearchOption > 0. So now full-predictors MAnalyse should run faster on CPUs SSE4.1+ and with all possible other options sets + additional speedup for blocks 8x8 8bit luma=false pel=1 with AVX2-capable chips.

[DTL]

FranceBB,
In MRecalculate, with square side = 1, does that mean that it searches only 1 pixel side to side, up and down, or NONE.

Not sure if problem, just asking. [EDIT: ie, is your MRecalculate a timewasting NOP]

It looks like hidden (still) undocumented feature of MAnalyse - it ignores user-input of searchparam at the finest (largest) level of search and always use searchparam=pel at finest/largest level. So setting to zero do not disables search at finest level.
I think it is optimization idea of old developers because in other case it is better to allow user to feed a vector/array of searchparams for each search level to find best speed/quality balance. Or at least add more user-input param like searchparamfinest=int or useequalsearchparamatalllevels=bool.
There is still idea that with fast enough search engine it possible to make something like pel=1 sp=2 levels=1 faster in compare with pel=1 sp=1 levels=2. But currently the program do not allow to actually use sp > pel at the fastest processing with level=1 and perform silent fallback to sp=pel.
Because each level require full-frame memory recall (but each next level buffer size is 1/4 of previous). So if memory speed is final limit of speed - the 1 pass search with levels=1 may be faster in compare with 2 pass levels=2 (1 + 1/4 memory).

[takla]

@DTL

With my Ryzen 3900x:

2.7.45 (mvtools-2.7.45-with-depans20210608)
time=70.115s

2.7.46 (Release_2.7.46_pre_a_03 AVX2)
time=63.457s

Using these settings (https://forum.doom9.org/showthread.php?t=183192)
Except this: ConvertBits(8, dither=1)
ffmpeg -benchmark -i TEST.avs -c:v ffv1 TEST.mkv

Very nice speed-up. Filesize was identical too.

[DTL]

Thank you for testing and report.

There is many new changes since that test-build. Now when fixing optPredictorType=2 (something like 'only hierarchical predictor' mode) I found may be useful method of returning different SAD value from MAnalyse to MDegrain and it significally helps in some cases of noise or noise-like aliasing of interlaced camera. It is return sad not from finest level of search but from prevoius.
Currently fixed mode of optPredictorType=2 works like this (it possibly the only possilble mode for this limiting preictor mode) but works acceptable only with levels=1 or 2. May produce severe artifacts with levels >2. But it still fastest mode for possibly lowes quality degrain work. Also with levels 2 and more it start to blur more and more (still do not know why - may be too many low-sad values).

But in optPredictorType=1 this 'previous-level sad return' maybe controlled only for finest level (using hidden still working feature of nSearchParam==1 at finest level) so it allow to use optPredictorType=1 with any levels number (the 2 is faster in compare with auto/all like 6). It is also possible in 'all predictors' mode optPredictorType=0 if required (still not added).

So current latest testbuild - https://github.com/DTL2020/mvtools/releases/tag/r.2.7.46-a.04 . The executables *sf.dll return special sad from non-finest level to MAnalyse. It typically 2 or more times lower in compare with 'standard' sad so allow to use lower thSAD(2) values in MDegrain. With too high thSAD it may cause more artifacts like visibility of blocks edges/corners so may require increasing of overlap param (I currently use overlap=2). So require more precise thSAD adjusting per given content. If this feature will be found as useful it may be additional user-switch param.

Current optSearchOption valid values:
0 - standard processing equal to 2.7.45 (for compatibility)
1 - partial SIMD optimizations for all options may be used. Like ClipMV, FetchPredictors. Exhaustive search (type=3) for searchparam 1 and 2 (and 3,4) is new AVX2-based. Though I see the r=3 and r=4 is of low use because default r=2 for levels except finest (slowest) and at finest/slowest level uses the fixed r=1 uses.
2 - special 'preset=fast' for degraining work, have hardcoded fixed many 'default' params for faster execution (less conditions checks).
Currently aggregated and fixed params for optSearchOption=2:
blksize = blksizeV = required to be 8,
search=3,
searchparam=2,
pel = required to be 1 in MSuper
chroma = false,
outfile = disabled,
dct = disabled,
badSAD = (infinite,disabled)
badrange = (disabled),
temporal = false,
trymany = false,
required CPU opts: SSE, SSE4.1, AVX2.

There may be also the very first 'tech demo' of multi-(4)-blocks search with optSearchOption=3 but it still not work for degrain at all - simply test for speed possible more SIMD-oriented processing on AVX2-capable chips.

My typical production using script currently is about

tr=12
super=MSuper(chroma=true, mt=false, pel=1)
multi_vec=MAnalyse (super, multi=true, delta=tr, search=3, searchparam=2, overlap=2, chroma=false, mt=false, optSearchOption=2, optPredictorType=1,levels=4)
MDegrainN(last,super, multi_vec, tr, thSAD=175, thSAD2=160, mt=false,wpow=4)

[takla]

@DTL


function EZdenoise(clip Input, int "thSAD", int "thSADC", int "TR", int "BLKSize", int "Overlap")
{
thSAD = default(thSAD, 150)
thSADC = default(thSADC, thSAD)
TR = default(TR, 3)
BLKSize = default(BLKSize, 8)
Overlap = default(Overlap, BLKSize/2)

Super = Input.MSuper(pel=1)
Multi_Vector = Super.MAnalyse(Multi=True, Delta=TR, BLKSize=BLKSize, Overlap=Overlap, optSearchOption=1)

Input.MDegrainN(Super, Multi_Vector, TR, thSAD=thSAD, thSAD2=thSAD/2, thSADC=thSADC, thSADC2=thSADC/2)
}



LWLibavVideoSource("C:\Users\Admin\Documents\01.mkv")
Trim(0, 1440)
ConvertBits(16)
EZdenoise()
ConvertBits(8, dither=1)
Prefetch(12, 48)



2.7.45
time=70.115s

2.7.46
optSearchOption=0
time=63.457s

2.7.46
optSearchOption=1
time=58.777s


optSearchOption=0

is ~10% faster then the original
optSearchOption=1

is ~16% faster then the original

Very nice speedups. Thank you very much!

[tormento]

There is many new changes since that test-build.
I'd like to test them too. Do they offer any difference in speed/quality when using with "old" default parameters such as replacement of the stable build?

[DTL]

2.7.46
optSearchOption=0
time=63.457s'

Do you see any difference between intel (ic) and msvc builds at AMD CPU ? With optSearchOption=0 most of C program should run as 2.7.45 but may be release 2.7.45 was build with only SSE2 instructions enabled and latest is with AVX2 and intel C builds are multi-file IPO and for not very old CoffeLake family.
The intel compiler provides options for optimizations to about 15 or more chip families so the final 2.7.46 release may be build to 15+ different executables for endusers to test for best speed at existing CPU. The building from sources at user-side for current CPU is not comnon for Winsows users I see.

[takla]

@DTL

I see no big difference between the 4 DLLs no matter if sf or std, intel or msvc.

With optSearchOption=0 the time is always around 62 seconds (if there is a difference here, it is very hard to measure because Ryzen CPU-Boost is very sensitive to temperature and each encoding run changes temperature, obviously)

[DTL]

"Do they offer any difference in speed/quality when using with "old" default parameters such as replacement of the stable build?"

If it change quality so it definitely not bit-compatible with old release. Pinterf ask to keep bit-identical output for old options set. So most of new additions that possibly can give any different result is guarded with optSearchOption > 0.

The min/max SIMD operations in ClipMV() may not be completely compatible with old C-version of compare.
The Median(), and check of MotionDistortion() for 4 predictors in all-predictors path should be compatible. But still not placed to 'old path' (that is search_mv_slice()). Most new is only in SO=2.
Also checking of MotionDistortion may be even faster in SSE2 instead of AVX2 because less gathering operations of sources in long 256bit vector and paralleling of execution ports in some new chips. It is in 'to do' list.

There is also some 'need much testing' optimization of removing paranoid IsVectorOK() test in search functions. I think it is mostly non needed in the most of frame area and only protect from out of buffer access and crash near edges. The current fix to DyMin/DyMax calculation is included only in SO=2 now (also for compatibility with old processing). But may be enabled with SO=1 in all options path. Currently SO=2 is very limited in possible options and only 8x8 block size.

Though some small (test) optimizations like non-cached stores in InterpolatePredictors and MDegrainN will work with all old options (if SSE2 present).
The non-cached store in MDegrainN may still not be visibly helpful before next re-write to one-bus-transaction 64byte transfers of source and result. It is in 'to do' list.

"because Ryzen CPU-Boost is very sensitive to temperature and each encoding run changes temperature, obviously"

Yes - the temperature speed trottling makes testing of each small optimization visibly hard. And the more really optimization loads the SIMD execution ports and register file - the faster and more heat production and CPU speed trottling. So I typically stop spend time to test each small SIMD optimization.

There is also one more hidden feature (because no info messages available in Avisynth without stop processing) - the MAnalyse tries to allocate buffer of large pages for 'vectors'. If it fails in fallback to standard pages. The only way to check if allocation of largepages is success is in Win10 use RAMMap tool. In Win7 it may fails to display too. The indirect way is look into AVSMeter RAM memory usage report - if largepages were allocated - the displayed amount of used RAM will be reduced (to several MB or 10ths MB). Because largepages allocations do not included in most of software reports of used memory. Also to use it - the process owner (user) must enable Lock Pages in memory Privilege in Windows administration ( https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/enable-the-lock-pages-in-memory-option-windows?view=sql-server-ver15 ). It is default not set for all users and Administrators too in standard Microsoft-supplied versions of Windows (may be enabled in special user-builds). The diagnostic messages at obtaining this privilege for process at startup of MAnalyse is disabled (because it fails processing completely in todays AVS). May be some user-side log console is exist to silently throw diagnostic ? May be windows events -> software events ?
And the most probability of successive allocation is after fresh windows reboot (or use special memory defragment tools - external to Microsoft). I see Win10 typically keeps some small (about 256 MB) pool of non-fragmented memory for lp-allocations (possibly) if total RAM installed is large enough (may be > 1..4 GB) but may be only if there were no full-RAM applications running before, etc. For typical use of MAnalyse only about 1 largepage of 4 MB is required (for frame sizes up to 4K) and per each thread in AVS+ MT running (internal avstp MT use only one buffer for all threads). So it typically success long time after system reboot in Win10 and fast start fallback to standard pages in Win7 with 4 Gb memory installed.

[DTL]

@DTL
With optSearchOption=0 the time is always around 62 seconds (if there is a difference here, it is very hard to measure because Ryzen CPU-Boost is very sensitive to temperature and each encoding run changes temperature, obviously)

It is more interesting to see results of optSearchOption=2 (it uses block size 8x8 only) and may be SO=3 at AMD massive-multicore CPU chip (it currently only can run without crash with command like optSearchOption=3, levels=2. Levels=1 may cause crash, though is fastest.)

I will try to make AVX512 SO=4 (placeholder) to see the benefit of 16-blocks processing vs 4 (SO=3) - at work we have 2 HP new workstations with new Zeons Gold with AVX512. May be at next week.

Currently with preliminary speed tests at i5-9600K the 4-blocks processing SO=3 is about 3x faster in compare with 2.7.45. Though the 'predictors mode' is close to PT=2 that is of lowest quality. With PT=1 the speed benefit may be visibly less.

[takla]

@DTL
Can you explain what "Levels" is supposed to do? I tried levels=0 (default) and levels=4 but it only affected file size. Encoding time was not affected.
Does a higher level value increase degrain quantity? or quality?
Also, what is "wpow=4" in your mdegrain example?

Here are some more tests. This time I've locked my Ryzen 3900x CPU to 4.2GHz to ignore temperature affecting encoding time.

Also, In my testings, optSearchOption=2, optPredictorType=1 is the same speed-wise (47.5sec) as when just using chroma=false for MAnalyse. So I'll have to check frames for visual differences.

mvtools2_msvc_SO2std.dll
optSearchOption=1
time=59.720s
time=59.145s

mvtools2_msvc_SO2sf.dll
optSearchOption=0
time=61.502s
optSearchOption=1
time=57.792s
time=57.683s

-

2.7.45
overlap=4

mt=false
time=68.609s

mt=true
time=68.898s
time=69.167s
783.145 KB

search=3, searchparam=2
783.145 KB
time=69.688s

levels=4
time=68.481s
782.730 KB
search=3, searchparam=2
time=70.952s

-

2.7.46

mvtools2_msvc_SO2sf.dll
optSearchOption=2, optPredictorType=1, levels=0
time=47.453s
782.938 KB

levels=4
time=47.477s
782.441 KB

optPredictorType=0, levels=0
rtime=59.138s
783.150 KB

[DTL]

"Can you explain what "Levels" is supposed to do? I tried levels=0 (default) and levels=4 but it only affected file size. Encoding time was not affected.
Does a higher level value increase degrain quantity? or quality?"

It is one of the most important param for speed/quality balance. It is important to understand the multi-levels hierarchical search process for adjusting params for quality/speed balance of degraining.
The input image is progressively shrinked 2 times to form a sequence of levels for searcing. So level 0 is largest (may be pel=2 is even 2 larger), level 1 is twice smaller in linear size (1/4 of samples size), level 2 is 1/4 smaller linear and 1/16 of samples count and so on.

So the most important things for speed happens at level 0 and partially at level 1. All other levels are very small and almost invisible in processing time.

Levels are counting from 0. But param levels=0 mean 'all levels' that for typical HD frame is about 6 (0,1,2,3,4,5). Lowering number of used levels cause lost of the very long vectors (when moving in the frame is fast enough). It is typically very rare. So for precise motion compensating work using all levels is good idea to get max quality of fast moving objects. But for degraining work it is of low priority because it just mean lower degraining on fast moving objects (and they are rare and low visible). So for practical degraining the used levels may be limited to 0,1 or may be 0,1,2 (the levels param is total count so 0,1 mean levels=2 and 0,1,2 means levels=3). The fastest (about +1/4 speed of MAnalyse) is levels=1 but quality is lowest (it can not found vectors >1 in size, so it mostly static areas only degraining and for very slow motion).

Understanding levels is important because it is planned to put the individual levels control for better speed/quality balance. In the next versions it is planned to use 'vectors/arrays' params instead of scalar allowing to adjust search params for each level. It will allow to use faster method for slowest/largest level 0 while keeping levels 1,2 and more processing for catching more longer vectors.
So in current version optPredictorsType=0 mean use same 'all predictors' mode at all levels and in newer versions optPredictorsType="2,1,0" mean use fastest PT=2 at level 0, medium PT=1 at level 1, standard PT=0 at level 2 and others.

To see speedup in 2.7.45 and current testbuilds you can set levels=1 (mean only largest level 0 in processing, skipping all others). There is small difference in speed between levels=0 (all) and levels=4 (0,1,2,3) because all major sized levels 0,1,2 is in the processing.

" what is "wpow=4" in your mdegrain example?"

It is new param to control internal weighting of blocks in averaging process in MDegrain (currently only for N but pinterf will propagate it to all other Degrains because with equal thSADs and tr< 6 the other Degrains are used). In old versions wpow=2 internally and not controlled by user.
https://i6.imageban.ru/out/2021/11/23/83efd2f4e0bd78cfb70f92e3413f7c44.png
Setting wpow >2 (valid is 1,2,3,4,5,6,7) allow to increase block weight and get more 'degrain power' with same thSAD and possibly lower blurring. Max 7 mean no additional weighting (all blocks inside thSAD threshold with equal weight) cause max degrain power but may increase artifacts.

"mt=false
time=68.609s"

Do you really use internal MT with avstp.dll ? I see at modern intel CPUs internal MT is always slower in compare with AVS MT. Also mixing avstp-mt + AVS is very great speed penalty. So I only use AVS MT (Prefetch(numthreads) at the end of script) and always disable internal avstp-mt (or just delete avstp.dll from search path and working path). If you do not really have avstp.dll in the system it is just skipped option (do nothing).

"SO2std.dll"

*std.dll and *sf.dll should be of the same speed and only provided for test degrain quality in special cases of noise and noise-like aliasing/moire. So for tests you can use either ic*std or msvc*std which is best for speed at AMD CPU (after one short test and keep selected .dll for all other tests).

"optSearchOption=2, optPredictorType=1, levels=0
time=47.453s"

For a bit better speed you can set levels=2 (only 0 and 1 level used). It may increase filesize a bit.

Do optSearchOption=3 can start (not crash) at your system ? With new ideas I think it may be 'adaptive block size' processing with increasing block to close to 16x16 (the 4x1 of 8x8 is equal to 16x16 in samples count, and 2x2 of 8x8 is equal to 16x16 block in shape too) if vector field locally is enough coherent and still keep refining quality close to 8x8 block size. Also if 4x 8x8 fits in AVX2 register file it is worth to try to make new AVX2 functions for 16x16 block size exhaustive search and look at speed.

"In my testings, optSearchOption=2, optPredictorType=1 is the same speed-wise (47.5sec) as when just using chroma=false for MAnalyse. "

May be something else limit the speed ? Do you test raw performance of the script with AVSMeter or it is encodings time with MPEG-encoder ?

[takla]

@DTL

Do you really use internal MT with avstp.dll ? I see at modern intel CPUs internal MT is always slower in compare with AVS MT. Also mixing avstp-mt + AVS is very great speed penalty. So I only use AVS MT (Prefetch(numthreads) at the end of script) and always disable internal avstp-mt (or just delete avstp.dll from search path and working path). If you do not really have avstp.dll in the system it is just skipped option (do nothing).

Oh, ok. Good to know. Yeah I don't have that avstp.dll. That is probably also why my tests show no difference between mt=true or false. I just wanted to test that setting because you had it in your example script. I too use prefetch for my scripts.

*std.dll and *sf.dll should be of the same speed and only provided for test degrain quality in special cases of noise and noise-like aliasing/moire. So for tests you can use either ic*std or msvc*std which is best for speed at AMD CPU (after one short test and keep selected .dll for all other tests).

sf.dll was consistently ~2 seconds faster, as you can see from my tests.

And thank you on the explanation for levels and wpow :)

[DTL]

"sf.dll was consistently ~2 seconds faster"

It is strange enough. It returns significantly different sad (lower) values to MDegrainN and require thSAD re-adjusting for lower values (about 1.5 times lower in compare with no-sf version) otherwise can cause more blurring. It is special testcase.

" I don't have that avstp.dll."

Yes - that mean internal avstp-based mt simply can not run. But typically avisynth users with many plugins installed may have avstp.dll in the search path (or plugins folder or..) and it will be loaded. Currently MVtools do not emit any diagnostic messages - I think to add to windows applications evens (at windows builds) so they can be read by windows event viewer.

"you had it in your example script."

I set mt=false to strictly disables internal mt if system can found avstp.dll somewhere inside many folders (I can keep it for testing somewhere). The default for MVtools is to use internal mt if avstp.dll is found somewhere and it can greatly reduce performance.

Also I think of testing 'ultrafast' 'predictor-mode' with interpolated vectors but not checked/refined at slowest 0-level at all. It may be optPredictorType=3 but for best use require 'multi-params' input for setting this mode only for level 0 and setting some 'real' predictor mode for smaller levels to base interpolation at.

[tormento]

"sf.dll was consistently ~2 seconds faster"
Is it possible to have a non AVX2 build?

Unfortunately my system is too old to support it.

[DTL]

"Is it possible to have a non AVX2 build?"

I hope you have at least SSE4.2 ? I will make SSE build with intel c version optimized up to SSE 4.2. Msvc build will be up to SSE2 in old C but to use optSearchOption=1 some optimizations it is require SSE 4.1 minimum.

[tormento]

I hope you have at least SSE4.2 ? I will make SSE build with intel c version optimized up to SSE 4.2.
I have Sandy Bridge, i.e. up to AVX instruction set.

[DTL]

So all SSE versions should work. Also you can use optSearchOption=1 to enable some 'universal' up to SSE4.1 optimizations in vectors data preparation.
Here is todays evening build - https://github.com/DTL2020/mvtools/releases/tag/r.2.7.46-a.05 . Have sse and avx2 folders and I hope intel .dlls is correct.

Added optPredictorType 3 and 4.
3 - only check the SAD of the predictor from level 1 at level 0. No refining search at level 0. SAD value should be typical.
4 - only use interpolated vectors and SAD from level 1 at level 0 . No SAD check at level 0. (SAD value is reduced typically, same as with *sf.dll with PT=1, and thSAD in MDegrainN need to be lower).
Should work with any other options - no special requirements.

PT=3 and PT=4 require levels > 1. It mean there should be some smaller levels to perform 'real' vectors search before level 0. (levels=0 that is 'all/auto' also valid). The fastest should be PT=4 - use interpolated vectors from level 1 without check or refining. But the SAD value will be lower typically so thSAD adjustment in MDegrainN required (typically to about 1.5x lower).

As currently no 'vector/array' inputs to values it is equal to optPredictorType="3,1" and "4,1" (currenty hardcoded inside GroupofPlanes) that mean use PT=3 or 4 at level 0 and use PT=1 (medium) at all other levels.

[tormento]

So all SSE versions should work. Also you can use optSearchOption=1 to enable some 'universal' up to SSE4.1 optimizations in vectors data preparation.
Thanks for the SSE build. Will check it ASAP.

Unfortunately I mostly use mvtools inside SMDegrain so I can't pass options beside the preset ones.

[DTL]

Unfortunately I mostly use mvtools inside SMDegrain so I can't pass options beside the preset ones.

For MdegrainN (if you use tr > 6) I think you can add wpow param to line 386 of https://github.com/Dogway/Avisynth-Scripts/blob/e6ed53e432cbd9ee631befafed3b5884cfd8505a/SMDegrain%20v3.3.8d/SMDegrain%20v3.3.8d.avsi#L386

And MAnalyse for tr > 6 looks like line 314 https://github.com/Dogway/Avisynth-Scripts/blob/e6ed53e432cbd9ee631befafed3b5884cfd8505a/SMDegrain%20v3.3.8d/SMDegrain%20v3.3.8d.avsi#L314
Simply add new params optSearchOption=1 and optPredictorType (>1 if try to test it) to the end of arguments.

To try skip MRecalculate it is possibly need to set something like Refinemotion to false. The download link from wiki http://avisynth.nl/index.php/SMDegrain is 404-dead. So I think it is the latest version at github found.

[tormento]

The download link from wiki is 404-dead
Dogway took the helm back (https://github.com/Dogway/Avisynth-Scripts). Why to link to the dead wiki page?

[DTL]

I typically try to download avisynth stuff from that wiki links. Hope they up to date. Instead of searching forums or github for tons of versions not known if in new or old, stable or not state etc. So wiki is also old and not updated ?

I read Dogway post about the need of 16*16 block for HD. I have an idea how to put possibly faster search to SIMD but it also need AVX2 to load full 16*16 source block and leave place for SAD results. To prevent source block reload from cache at each search step. So no very great results expected for pre-AVX2 CPUs. There may be small optimizations like putting to SSE SIMD InterpolatePredictors and MotionDistortion for multi-vector search. But anyway any possibly not-bitexact operation with old version will be separated with optSearchOption >0. To have ability to quick test if it cause new issues for example.

I mostly interested how the silently Exhaustive search was changed to Expanding search but the same search=3 option number and naming in the documentation remain. Though with penaltyNew >0 it will gives different results from exhaustive for the minimum SAD from the all tested search positions.
I have an idea how to make exact simulation of current Expanding search from AVX2 search SADs array but it will be slower. So it is good to see test reports if old expanding search really need/better and worth to spend time to made separate version of function for it.

Expanding search is not isotropic because of fixed positions scan sequence and if vector with equally low SAD will be found from the start of search - it will be output as a result if even vector with better SAD exist and with same radius. And with increase of penaltyNew it become worse.

[tormento]

I typically try to download avisynth stuff from that wiki links.
I tried the two SSE builds, both Intel Compiler and MSVC. To have a real world comparison I did a small encode with the script

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\2_23 Brazil (director's cut)\brazil.dgi",ct=24,cb=24,cl=0,cr=0)
ConvertBits(16)
SMDegrain (tr=6, thSAD=600, refinemotion=true, contrasharp=false, PreFilter=4, plane=4, chroma=true)
fmtc_bitdepth (bits=8,dmode=8)
Prefetch(6)

without any alpha optimization, i.e. I simply replaced the dll.

They are a bit slower than the stable one.

2.7·45
encoded 4128 frames, 4.39 fps, 3771.03 kb/s, duration 0:15:41.11

pre5ic
encoded 4128 frames, 4.16 fps, 3771.03 kb/s, duration 0:16:32.76

pre5msvc
encoded 4128 frames, 4.28 fps, 3771.03 kb/s, duration 0:16:04.20

The resulting files are identical in size, differing only a few bytes in the initial part. However they are mkv, not 264 as I probably should have done to have a clear compare and it's matroska perhaps adding some info about data time and so on.

You told something about SSE4.2 optimization. Couldn't you make it as default in the SSE builds instead of having to add as switch? I am plain sure anybody here has a CPU capable of supporting them.

[DTL]

"They are a bit slower than the stable one."

It is also a subject to test why. May be non-cached stores may be not good for some use cases and need to be put to special 'searchoption' number (not default zero).

"Couldn't you make it as default in the SSE builds instead of having to add as switch?"

It can not be default because it may produce not equal result with old versions. Only possible is to create many testbuilds with enabled/disabled different methods. Will try to do soon.

[kedautinh12]

Link died

[tormento]

Here is a testbuilds for users of scripts without set of params to MAnalyse
None of those are working.

I can't even get a nice error, they simply produce a 0 size file.

[DTL]

Oh - it looks at least error with hard setting of optPredictorType inside - it looks everywhere is PT=0. Sorry - not tested it for output result after build. Will try to look what is wrong.

"simply produce a 0 size file."

May be it simply crash at startup. Can you look in system evens viewer or drwatson log - may it have some crash records ? It is strange - it should use only SSE instructions up to SSE 4.1 and checked at Intel Core2Duo E7500. Will enable check for required SSE version in next testbuild.

Edit: Found source of one error - Visual Studio opens for editing files form different copy of the project. So all .dlls were build from equal sources. Will rebuild now. Though it not shows why processing not make any result.

[DTL]

Well - new fixed testbuild and checked for run at Core2Duo E7500: https://drive.google.com/file/d/1ry35P1JddVd_9rv8kG3fosPGlV6BiyeY/view?usp=sharing

Have both SO0 and SO1 builds for all PT values.
The PT2 versions removed because can not run correctly without limiting levels to about 2..3. PT4 require lowering of thSAD to about 1.5 times lower in compare with other.

On E7500 old CPU optSearchOption=1 with some new SSE optimizations enabled runs slower - it looks not all old SSE CPUs can run faster with SSE versions of functions instead of C. So it definitely can not be non-controlled enabled in final release.

[DTL]

Issue found with latest testbuild : crash with block size 16x16 and (ALIGN_SOURCEBLOCK = 1 'asb1' in file names) (aligned copy disabled). With default padding = 8. If increase padding to 16 (in Msuper) - crash not happens. So users of scripts with default MSuper params (hpad=vpad=8) will have crash if using faster 'asb1' builds with block size 16x16. Looks x264 SSE2 and SSSE3 16x16 SAD functions was not tested with disabling aligned copy of source block.
Hope for some workaround for this issue. Current user-side workaround - increase hpad and vpad to about blocksize or larger if crash occur.

[Dogway]

I got a BSOD with latest official build, trying to return a scaled MV clip... I panicked. Lost my dev version script of SMDegrain (filled with zeros), luckily it wasn't much, only a few commented expressions and notes.

This was more or less the trigger. I was trying to check bv1 clip dimensions to debug an issue I was having.
Environment:
i7-4790K
Win7-SP1 x64
AVS+ test29 x64
no avstp.dll in plugin path


setmemorymax(2048)
DGSource(bluray source)
ConvertBits(16)
w=width()
h=height()
bicubicresize(w*2,h*2)

pref8 = ConvertBits(8, dither=-1)
pref8 = pref8.BilinearResize(w, h)
pref8 = pref8.ConvertToYUV420(false,"","MPEG1","spline16","top_left").ConvertBits(16)
pref8 = pref8.ex_Luma_Rebuild(S0=3.0,c=0.0625,uv=3,tv_range=true,fulls=false).ConvertBits(8, dither=-1)

super_search = MSuper(pref8, pel=1, chroma=true, hpad=0, vpad=0, sharp=1, rfilter=4, mt=true)
Recalculate = MSuper(pref8, pel=1, chroma=true, hpad=0, vpad=0, sharp=1, rfilter=4, mt=true,levels=1)
bv1 = super_search.MAnalyse(isb = true, delta = 1, overlap=8, blksize= 16, search=4, chroma=true, truemotion=false, divide=0, dct=0, searchparam=2, pelsearch=1, temporal=false, trymany=false, scaleCSAD=1, mt=true)
bv1 = MRecalculate(Recalculate, bv1, overlap=4,blksize=8, thSAD=200, chroma=true, truemotion=false, divide=0, dct=0, scaleCSAD=1, mt=true)
bv1 = bv1.MScaleVect()

bv1

# without prefetch, in avspmod

[pinterf]

I got a BSOD with latest official build, trying to return a scaled MV clip... I panicked. Lost my dev version script of SMDegrain (filled with zeros), luckily it wasn't much, only a few commented expressions and notes.

This was more or less the trigger. I was trying to check bv1 clip dimensions to debug an issue I was having.
Environment:
i7-4790K
Win7-SP1 x64
AVS+ test29 x64
no avstp.dll in plugin path


setmemorymax(2048)
DGSource(bluray source)
ConvertBits(16)
w=width()
h=height()
bicubicresize(w*2,h*2)

pref8 = ConvertBits(8, dither=-1)
pref8 = pref8.BilinearResize(w, h)
pref8 = pref8.ConvertToYUV420(false,"","MPEG1","spline16","top_left").ConvertBits(16)
pref8 = pref8.ex_Luma_Rebuild(S0=3.0,c=0.0625,uv=3,tv_range=true,fulls=false).ConvertBits(8, dither=-1)

super_search = MSuper(pref8, pel=1, chroma=true, hpad=0, vpad=0, sharp=1, rfilter=4, mt=true)
Recalculate = MSuper(pref8, pel=1, chroma=true, hpad=0, vpad=0, sharp=1, rfilter=4, mt=true,levels=1)
bv1 = super_search.MAnalyse(isb = true, delta = 1, overlap=8, blksize= 16, search=4, chroma=true, truemotion=false, divide=0, dct=0, searchparam=2, pelsearch=1, temporal=false, trymany=false, scaleCSAD=1, mt=true)
bv1 = MRecalculate(Recalculate, bv1, overlap=4,blksize=8, thSAD=200, chroma=true, truemotion=false, divide=0, dct=0, scaleCSAD=1, mt=true)
bv1 = bv1.MScaleVect()

bv1

# without prefetch, in avspmod

I've changed the source filter to a ColorbarsHD().
bv1 is a 172444 x 1 sized RGB32 clip. Works for me from avsmeter64 and in 64 bit avspmod as well.

[Dogway]

Oh well, thanks for testing, I didn't feel brave enough to reproduce. I guess the long sized clip did something to my RAM, also I was running low on disk space so it could be a thing. I thought bv1 was similar to msuper clip. Now I will try to debug without returning mv clips, lesson learned.

[DTL]

Small important update based on pinterf sources from 9 November 2021 - https://drive.google.com/file/d/1EEYaSzC3JL1Y-4SRj2Cr_sLkBNGUgows/view?usp=sharing . Should run stable with block size 16.

Added check of coordinates of predictors to skip repeated check of already checked predictor. Should make optPredictorType=0 (all predictors, old default) close to PT1 in speed while still kepping all possible predictors.
In real footage many predictors are equal (of Zero, Global, Median and 4 neibour, also may be +Temporal if enabled)) so keeping track of already checked predictors saves form some calls to single SAD() function that is not SIMD-friendly and hard to optimize.
Speed is content-dependent so the completely static sources like ColorBars() will give more speed. So better to test speed on real footage with different movements. Included also very small SSE41 optimizations in separate file and hardcoded inside SO=1 for users of old scripts.

[kedautinh12]

Any chance for x86 ver?? :D

[DTL]

It built by system - https://drive.google.com/file/d/1B6Exq4tp6QV6Ao5xZjqGpw_BPAcBaiI9/view?usp=sharing

but not any good tested if work correctly.