MVTools-pfmod

[tormento]

Small important update based on pinterf sources from 9 November 2021
Tested SSE41 builds thoroughly, both standard and SO1.

I am now using the SO1 version, instead of stable one, because of its speed and good results.

If you want to try a SSE42 build, my CPU supports it and perhaps we can get a little speed bump.

[DTL]

Later it looks I found a bug in that build from December 3 - it may cause skipping some valuable predictors and decrease degraining quality. Hope bugfixed build - (both x64 and x86)
https://drive.google.com/file/d/1kMcDG7v5lb3HM2PFMFwrGs2H8JBx3Pl1/view?usp=sharing

"SSE42 build, my CPU supports it and perhaps we can get a little speed bump."

Unfortunately SSE4.2 do not adds any significant. The only way to boost performance with all predictors and all levels refining - either AVX2 or better AVX512 capable chip.

For old CPUs only possible to try 'logical optimizations' like PT=4 mode - with pure interpolated prediction at level 0. It may provide lower quality of degraning but fastest possible mode. Also it is planed to put to SIMD (of low family like simple SSE) the InterpolatePrediction() function and it may also add some speed at SSE-level chips. But it still of lower priority - I currently in developing of multi-blocks search for AVX2 and AVX512 and interesting in the difference between 4/8 blocks AVX2 processing vs 16/32 blocks AVX512 processing. Of blocksize 8x8.
Today the 4Blocks 8x8 sp1 avx2 function looks like converted from pure tech speed test to something working for degraining.

Addition: PT=4 do require re-adjusting thSAD value in MDegrain (lower to about 1.5 times from 'standard' because it output SAD from level 1 and it typically lower). Using 'standard' thSAD value may cause too much detail blurring as usual too high setting of thSAD.

[tormento]

Hope bugfixed build
Can you release for SSE41 too?

Thanks.

[DTL]

I hope all possible SSE enabled. I just not put it to the file name. Only possible is add intel compiler build for some exact chip family - you have Sandy Bridge ? It may be a bit faster.

[tormento]

you have Sandy Bridge ? It may be a bit faster.
Yep, good old i7-2600k. Best Intel CPU ever :)

[DTL]

I think the best home chip is about i5-11400 now. But it looks it need about 200 watt unlocked power and cooler to run with AVX512 at good performance. If run with rated TDP 65 watt limit it looks will self-limiting to much lower performance level.

[tormento]

I think the best home chip is about i5-11400 now. But it looks it need about 200 watt unlocked power and cooler to run with AVX512 at good performance. If run with rated TDP 65 watt limit it looks will self-limiting to much lower performance level.


Alder Lake is a nice beast, unfortunately you have to disable E-Cores to have AVX-512 back.

[FranceBB]

The only way to boost performance with all predictors and all levels refining - either AVX2 or better AVX512 capable chip.

AVX512?
Bring it on for the next stable release, Sky servers will thank you for the AVX512 build speed-up! :D

https://c.tenor.com/VY3BZMLHJ_8AAAAC/come-to-me-dr-evil.gif

[DTL]

Alder Lake is a nice beast, unfortunately you have to disable E-Cores to have AVX-512 back.

As I understand if Windows task planner is not very bad it can load both P and E cores and E also helps. But I not sure how thread will detect if it can use AVX512 version of function or not. Also pricing for Adler Lake may be much more in compare with lower Rocket Lake like 11400.

As for DDR5 vs DDR4 - I not sure if it makes lot difference. As I see with typical latency about 50 ns the real random access byte-read speed is about 20 MBytes/s. And linear transfer is typical > 50 GBytes/s nowdays. The gap is about 2500 times. Unfortunately progress in latency at SDRAM is about 2 times at about 2 decades.

Can you make test of speed for 64x16 vs 16x64 block processing ? At old Core 2 Duo E7500 CPU I got about 60% of speed difference. But at i5-9600 and i5-11500 much less (looks latest intels have better hardware prefetchers tuned and really have about 10 times more cache).
I think about re-design of MDegrainN memory access pattern for better speed of memory access but it also need time and data if it will significantly helps to newer CPUs.

"AVX512?"

Yes - it have 4 times larger register file and allow to process 4 times more blocks in a single search op (if vector coherency domain is large enough - that is frequently happens). But it looks something still bad with consumer-level AVX512 intels - testers reports of large power overbudget if try to load CPU with calculation and not limit power at motherboard power supply. So it either over-heated (with small funny box cooler) and auto-trottle speed or overload motherboard power supply and crash/BSOD/etc of even burn motherboard. I personally have really burn-out motherboard at Pentium2 time - it was 2 slots and 1 of 2 once burn at night.
So it looks 14 nm intel can not run with AVX512 processing even at nominal frequency and start to auto-trottle itself. So the performance at consumer-level AVX512 chips may be still limited. Or very good (water ?) cooler required and special motherboard with large power over-limiting over rated chip TDP (like 3x times larger). I wonder how server-class intel chips with > 10 cores of AVX512 work at full speed for years.
I hope newer 7nm intel chips will be less power-hungry at AVX512 processing. But it still the future.

" will thank you for the AVX512 build speed-up!"

Unfortunately creating 'massive multi-block' processing versions of search functions takes lots of time for checking. The 'very simple' 4blocks sp1 AVX2 function take visible part of day to check all 4 blocks x 8 positions_each_block = 32 test points. And for AVX512 it is planned up to 32 blocks - 32x8=256 test points. Or require to build special test software for automation testing task. And for level>0 the sp2 versions required that have 24..25 search positions for each block - it is 32x25=800 points to test for full checking. The performance of new hardware quickly outperform the performance of user to create programs for it.
I hope AVX512 16/32 blocks 'tech demo' of SearchOption=4 will soon be available to check for possible speedup of AVX512.

[FranceBB]

I wonder how server-class intel chips with > 10 cores of AVX512 work at full speed for years.

Dunno, but they just do and the clock doesn't go down. On the other hand, we're talking about CPUs with a much lower clock than in the consumer versions. in my case the CPU has 56c/112th with base clock 2.20GHz. Whenever I use AVX2, it goes up to 2.50GHz even at 100% usage, however, if I try to do the same with AVX512, it will go down to 2.20GHz, which, again, ain't bad 'cause that's the base/standard CPU clock frequency.



I hope newer 7nm intel chips will be less power-hungry at AVX512 processing. But it still the future.


Perhaps. Fingers crossed, though. :)



Unfortunately creating 'massive multi-block' processing versions of search functions takes lots of time for checking. The 'very simple' 4blocks sp1 AVX2 function take visible part of day to check all 4 blocks x 8 positions_each_block = 32 test points. And for AVX512 it is planned up to 32 blocks - 32x8=256 test points. Or require to build special test software for automation testing task. And for level>0 the sp2 versions required that have 24..25 search positions for each block - it is 32x25=800 points to test for full checking. The performance of new hardware quickly outperform the performance of user to create programs for it.


Ah, yeah, right, I see...


I hope AVX512 16/32 blocks 'tech demo' of SearchOption=4 will soon be available to check for possible speedup of AVX512.

Well, fingers crossed again, then. :)

[Dogway]

I'm talking about future future but Intel chips will start to make sense again after Meteor Lake, but personally will wait until Luna or Nova Lake, when new tech like big-little, TDP and DDR5 issues (and prices!) settle down. In any case I don't think heat issues will improve so I see myself switching from my current 140mm rad to a 280mm one.

[DTL]

In the future future I think it is good to make 'auto-degrain' version with some preset output target SNR. And auto-adjustment of tr and thSAD values to reach this preset output target SNR.

We have everyday lots of different footages with different camera gain settings so even with about equal cameras the relative noise levels still very different from outdoor shootings with good lighting and low gain and noise to indoor opera/balet show with poor lighting and high relative noise levels from raised gain at cameras. So to use large tr and thSAD values for worst noise will take more time and degrade quality at low noise footages. Some automation required. Like statistical analysis of medium/average SAD coming from MAnalyse and backward adjusting of tr and thSAD from MDegrainN.

[tormento]

But I not sure how thread will detect if it can use AVX512 version of function or not.
Der8auer's test shows that AVX512 work only when E-cores are disabled, at least for Alder Lake. There is a tradeoff, yet to be know, between the E-cores you lose and the performance increase of AVX512. Unfortunately nobody tested the difference yet on this forum.
Can you make test of speed for 64x16 vs 16x64 block processing?
Yes if you do proper versions without having to put hand to the AVSI I use. :)
I think about re-design of MDegrainN memory access pattern for better speed of memory access but it also need time and data if it will significantly helps to newer CPUs.
Is there any chance you will port MVTools to CUDA, Vulkan or OpenCL? Than would help a lot more and nowadays it's much more widespread to have a fast GPU than the latest CPU.
So it looks 14 nm intel can not run with AVX512 processing even at nominal frequency and start to auto-trottle itself.
Motherboards automatically lower the multiplier of 2 or more. If you want to keep good performances and disable that setting in bios, your only solution is to use a very good liquid cooling system, at least 360mm.

[Dogway]

I have thought on adding some auto-tune algo, based on variance or stdev, but it implies sampling a portion of the clip and I don't know how user friendly that would be.
If you offhand the portion sampling to the filter it will spend most of the time trying to find a "flat" area to sample and yet it would fail based on luminance based grain.

Maybe the first option might be better, there are many estimators so it's a matter of finding one that works nice with SAD. SAD is a simple L1-norm if I'm not mistaken. I will run some tests.

EDIT: test

# 8-bit input
Crop(1278, 0, -462, -868)
a=ex_median("IQM5")

# 5x5 block SAD
SAD = Expr(last,a,"
x[-2,-2] y[-2,-2] - abs x[-1,-2] y[-1,-2] - abs x[0,-2] y[0,-2] - abs x[1,-2] y[1,-2] - abs x[2,-2] y[2,-2] - abs
x[-2,-1] y[-2,-1] - abs x[-1,-1] y[-1,-1] - abs x[0,-1] y[0,-1] - abs x[1,-1] y[1,-1] - abs x[2,-1] y[2,-1] - abs
x[-2,0] y[-2,0] - abs x[-1,0] y[-1,0] - abs x[0,0] y[0,0] - abs x[1,0] y[1,0] - abs x[2,0] y[2,0] - abs
x[-2,1] y[-2,1] - abs x[-1,1] y[-1,1] - abs x[0,1] y[0,1] - abs x[1,1] y[1,1] - abs x[2,1] y[2,1] - abs
x[-2,2] y[-2,2] - abs x[-1,2] y[-1,2] - abs x[0,2] y[0,2] - abs x[1,2] y[1,2] - abs x[2,2] y[2,2] - abs
+ + + + + + + + + + + + + + + + + + + + + + + +
","")

ScriptClip( function[a, SAD] () {
str = AverageLuma(SAD)*5
subtitle(string(str)) } )

[DTL]

"test shows that AVX512 work only when E-cores are disabled, at least for Alder Lake."

It looks Microsoft was not ready to such hybrid chips and still no official threading API to support thread signaling if it use some instructions set and to chip Threads Planner to use this data and not allow some threads to be switched to non-supported core and crash. So it either all active cores use AVX512 or application will crash when Thread Planner will occasionally switch it to E-core.

"Is there any chance you will port MVTools to CUDA, Vulkan or OpenCL?"

There is already some version of CUDA-based processing. I do not have fast GPUs of CUDA-capable. That versions may be limited in max tr value ? Or only fixed to MDegrain1,2,3, ?
In the very theory I think about distributed processing of MAnalyse with workers based on any hardware (CPU/GPU/ASIC etc) but it still not help to the MDegrainN that is not very fast curently too. And to put MDegrainN do GPU with all frame processing it looks required too much of onboard memory (it scan via 2*tr ref frames for each output frame, for tr=30 and UHD 8Msamples frame with pel=1 it is about 1.5 GBytes memory minimum, the current tr max is 128). MAnalyse only scan via current and 1 ref frame for each call of MDegrainN GetFrame() so each src-ref pair may be offloaded to small enough worker. Anyway it is too much redesign and I not any good C programmer - I can only make simple C programs and assembler. Nowdays as Microsoft disables inline asm in x64 programs it is intrinsics-based. Some known issue about intrinsics based program - https://stackoverflow.com/questions/70261138/force-compiler-to-use-memory-operand-from-intrinsics/70261394#70261394 . So it will more or less depend on compiler and need to make it compatible with many compilers and select the best by speed of output executable.

"# 5x5 block SAD"

In the MShow it can be switched showsad to 'true' - Allows to show the mean (scaled to block 8x8) SAD after compensating the picture

I think its value is good correlated with the SNR.

With script:

LoadPlugin("mvtools2.dll")
LoadPlugin("AddGrainC.dll")

ColorBarsHD(1920,1080)

AddGrain(0)
Trim(0,250)
super = MSuper (pel=1)
forward_vec1 = MAnalyse(super, isb = false, search=3, searchparam=2, chroma=false, delta = 1, mt=false)
MShow(super,forward_vec1, showsad=true)


addgrain=0 sad=0 (infinite SNR)
addgrain=1 sad=68
addgrain=2 sad=96
addgrain=4 sad=136
addgrain=8 sad=191
addgrain=16 sad=271

"do proper versions without having to put hand to the AVSI I use"

Here is 2 tests (with that latest .dlls with PT4 for possibly fastest speed of MAnalyse to look at MDegrainN raw speed):

LoadPlugin("mvtools2_asb16_ivc_SO1_PT4.dll")

ColorBarsHD(1920,1080)
Trim(0,1000)

tr = 12 # Temporal radius

super = MSuper (pel=1, hpad=64, vpad=64)
multi_vec = MAnalyse (super, multi=true, blksize=64, blksizeV=16, delta=tr,chroma=false,mt=false, levels=2)
MDegrainN (super, multi_vec, tr, thSAD=300, thSAD2=300-1, mt=false)

Prefetch(2)


vs


LoadPlugin("mvtools2_asb16_ivc_SO1_PT4.dll")

ColorBarsHD(1920,1080)
Trim(0,1000)

tr = 12 # Temporal radius

super = MSuper (pel=1, hpad=64, vpad=64)
multi_vec = MAnalyse (super, multi=true, blksize=16, blksizeV=64, delta=tr,chroma=false,mt=false, levels=2)
MDegrainN (super, multi_vec, tr, thSAD=300, thSAD2=300-1, mt=false)

Prefetch(2)


The second with vertical block 16x64 runs significantly slow at my iCore2 Duo E7500 CPU. Like 8 fps vs 13.5 fps. Though it somehow depends on hpad and vpad values. It is also a point to check why.

[tormento]

It looks Microsoft was not ready
I think it's Intel side. Alder Lake has the same architecture of Xeon ones and they do support AVX512.
There is already some version of CUDA-based processing
You mean SVP? AFAIK it's paid and really limited.
I do not have fast GPUs of CUDA-capable
A 1060 one should be really cheap now. Even a 1050 could be enought to try CUDA or other primitives.
And to put MDegrainN do GPU with all frame processing it looks required too much of onboard memory
KNLMeansCL and BDMV do a good job and memory is a culprit if you do heavy MT only. I don't know if the memory requirements are the same but I can easily process a 1080p source with 6 threads on a 3GB video card. AFAIK GPUs are good at heavily parallelized tasks. Perhaps the MDegrain part could work, as I can see that GPU filters, until now. are noise related.

[FranceBB]

Nowdays as Microsoft disables inline asm in x64 programs it is intrinsics-based.

What's the difference between inline assembly and manually written intrinsics? Aren't intrinsics specialised parts of the program written in assembly? Is the difference the fact that with intrinsics you can tell which instructions set to use dynamically while with inline assembly you can't and it would just fail if you try to execute a program which has AVX2 in a CPU that supports SSE4.2?

A couple of other questions:

- do you think we will ever get to a point in which compilers will be smart enough to generate fast enough code automatically at compile time while targeting an instruction set so that manually written intrinsics won't be necessary/worth writing or will it ever be science fiction?

- with the increasing number of high level languages and many young programmers taking the short route and using rust, python, electron, etc do you think there's gonna be a drop in performance in the near future as less and less people will be able to code in C++, let alone write instrinsics in assembly?


You mean SVP? AFAIK it's paid and really limited.

I think he means the Japanese Avisynth Neo version, which is based on a much older version of MVTools and the documentation of which is entirely in Japanese, so... Good Luck xD

[qyot27]

What's the difference between inline assembly and manually written intrinsics? Aren't intrinsics specialised parts of the program written in assembly? Is the difference the fact that with intrinsics you can tell which instructions set to use dynamically while with inline assembly you can't and it would just fail if you try to execute a program which has AVX2 in a CPU that supports SSE4.2?
It's easier to show it than describe it, in a sense.

Inline assembly is using the actual assembly code syntax itself, inside the code. It's usually compiler-specific as well, at least to a certain degree. Stuff like NASM assembly probably doesn't count, as even though it does go down to the base commands, it's slid in externally and parsed by a dedicated program. Some inline assembly does still exist in the AviSynth+ sources, like this block in PluginManager.cpp (which, because of how this works, can only be used when building with MSVC for 32-bit):
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/PluginManager.cpp#L1210

Intrinsics, on the other hand, are largely compiler-provided shortcuts to the CPU's SIMD instructions that are able to be used more like regular C/C++, as keywords when the code needs to target particular instructions. For example, here in focus_sse.cpp:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/intel/focus_sse.cpp#L157

All those __m128i and _mm_**_** calls? Those are the intrinsics.


Runtime dispatch of a particular feature set doesn't have anything to do with inline asm vs. intrinsics; that's purely on either the compiler or the programmer setting up dispatching correctly. If a SIMD instruction your CPU doesn't support gets through, the program will crash with a SIGILL when you try to run it. How compilers treat the regular C/C++ code can factor into this as well: if the compiler was told to optimize everything for an instruction set your CPU doesn't support, it'll translate the compiled C/C++ code into SIMD that doesn't exist on that CPU, and you'll get a SIGILL (this isn't as much of a problem with MSVC, but it can be a big one with GCC).

Generally, this is why Release builds of just about anything don't have myriad different builds compiled for every permutation of CPU out there: the plain code was left with the general optimizations the compiler can do but not any SIMD translation, and any inline asm or intrinsics are only active under codepaths it can detect are needed. Or at best, there's a baseline minimum CPU the plain code gets optimized for (one example would be FFMS2 and the whole thing over -msse/-march=pentium3 or -msse2 on 32-bit builds).

[DTL]

"I think it's Intel side. Alder Lake has the same architecture of Xeon ones and they do support AVX512."

I do not think Xeons have hybrid of different cores with different instructions sets. I think Adler Lake is the first chip with this design. And it require special software support.

"You mean SVP? AFAIK it's paid and really limited."

I see that thread - https://forum.doom9.org/showthread.php?t=183476 it is about SVSuper and SVAnalyse and uses GPU ? Also pinterf point to some project - https://github.com/pinterf/AviSynthCUDAFilters/tree/master/KTGMC .

"What's the difference between inline assembly and manually written intrinsics? "

Intrinsincs is semi-asm semi-C. Mostly special C operators more or less mapped to 'real' hardware CPU instructions (also containing many 'virtual' macros that is a sequences of instructions more or less on the compiler decision). One of the possible issue - it do not have method of pointing to memory operand where avaialble (currently). So if compiler fail to understand programmer's idea it is only possible to send complain to compiler's designer and waiting to next patched release if possible. Or write separate asm file to the project manually.

"you can tell which instructions set to use dynamically while with inline assembly you can't and it would just fail if you try to execute a program which has AVX2 in a CPU that supports SSE4.2?"

No. With intrinsics programmer must design separate functions for each large-vector co-processor type (SSE2/AVX2/AVX512 and future). Instructions sets between different large-vector co-processors are not compatible.

"- do you think we will ever get to a point in which compilers will be smart enough to generate fast enough code automatically at compile time while targeting an instruction set so that manually written intrinsics won't be necessary/worth writing or will it ever be science fiction?"

No. Each hardware SIMD large-vector co-processor architecture require special and separated design of program and they are not completely 'expandable' between different SIMD families and generations. They even do not inherit instructions sets completely with advances of generations - SSE have unique minpos() instruction and in it 128bit SSE4.1 only. Not exist in the next AVX2 and AVX512 and looks like not any replacing. So after SAD calculation in AVX2 or AVX512 instructions it is required to go down to 128bit SSE and use minpos() to found where is the min SAD positioned. It still faster in compare with going to 'general purpose core' and use loop with compare-based search for minimum member of vector. And SkyLake and possibly newer chips have 3 execution ports for minpos() instruction so after 4 clocktics latency it can output 3 minpos results per clock.
AVX2 256bit have mpsadbw() that not propagated to AVX512 and as I see the dbsadbw() in AVX512 can not be used as complete replacing. mpsadbw can be used for search up to sp3 full positions and sp3.5 with reduced 1 column. And dbsadbw only for sp1 (and for larger sp with data shift/reloading but it is a performance penalty).
So the already created program design can not be easily ported to next generation of large-vector co-processor. So the 'AVX512' search function is actually mix of different instructions sets down to SSE. Fortunately chips are still backward-compatible and AVX512 chip can execute SSE instructions though there is some penalty of going down from 512bit vectors to 128bit and back.

"- with the increasing number of high level languages and many young programmers taking the short route and using rust, python, electron, etc do you think there's gonna be a drop in performance in the near future as less and less people will be able to code in C++, let alone write instrinsics in assembly?"

It need to be separated 'general purpose Computer usage' and 'special data processing'. The general purpose computer usage is enough serviced by any high level programming language and general purpose CPU part of core. The special data processing is typically usage of special SIMD co-processor. The SIMD large-vector co-processor is highly integrated in general purpose CPU core but still have its special instructions set (and limited in operations) and separated register file (different size and 'word width' for each family). Any compiler with knowledge about its presence can use its register file for some temporal storage or even some data processing. And unlikely will be any compilers from 'general purpose' high level programming languages to SIMD co-processor (intel promises for 'auto-parallelization' where possible and where available but it still require too much preparation work from programmer). Because it is special purpose processing engine and not compatible with typical high level programming language. Though the intrinsics support can be made to any high level compiler. In theory it is possible to make special compiler for auto-creating designs for different SIMD co-processors but it is sort of the far future and the number of useful tasks will be still very limited. Mostly real is special libraries of functions designed for selected SIMD co-processor family.

[tormento]

I do not think Xeons have hybrid of different cores with different instructions sets.
Sapphire Rapids will have the same architecture, at least for Golden Cove (P-cores). I dunno if it will have E-cores too, even if I have my doubts about it.

Would you please explain me the differences between each search options and parameter options? I saw you compiled plain version, search option 1 and SO1 plus parameter 4. How are them different, speed and quality wise?

[DTL]

"plain version, search option 1 and SO1 plus parameter 4. How are them different, speed and quality wise?"

Plain is controlled by parameters optSearchOption(0,1) and optPredictorType(0,1,2,4).

SO1 is hardcoded optSearchOption=1 - it should be like you tested + fixed bug with skipping some predictors. Full quality (default PredictorType=0).

SO1_PT4 - is hardcoded optSearchOption=1 optPredictorType=4. It is special demo of 'logical optimization' - skipping level 0 processing and output interpolated (scattered to 4 larger buffer positions) prediction from level 1 (other levels uses PT=0 - full predictors). It should be fastest but quality may be more or less degrade depending on content. May be it will be useful for 'drafting' work or other. Require lowering thSAD value at MDegrain (I hope it is controlled in the typical script functions params) to about 1.5 times lower in compare with 'standard'.

" I dunno if it will have E-cores too."

I think Xeon customers are not interested in paying thousands for low-performance Effective cores. And re-design software to use mixed cores chip.

[tormento]

SO1 is hardcoded optSearchOption=1
Quality wise, is it better, worse or on par with stable?
It should be fastest but quality may be more or less degrade depending on content.
I already have idea where to use it, such as double SMDegrain calls, on the first one.

[DTL]

"Quality wise, is it better, worse or on par with stable?"

It should be very close.

"double SMDegrain calls, on the first one."

Yes - may be good example. But you can not mix different .dlls with equal functions names in 1 script. To use PT4 in one script it is required to load 'universal options-controlled .dll' and set param optPredictorType=4 to the draft MAnalyse().

[tormento]

Yes - may be good example. But you can not mix different .dlls with equal functions names in 1 script. To use PT4 in one script it is required to load 'universal options-controlled .dll' and set param optPredictorType=4 to the draft MAnalyse().
I thought about it just after posted. I hope dogway will adopt your version when stable.

[DTL]

Some not very great about AVX-512 in Adler Lake - https://www.anandtech.com/show/17047/the-intel-12th-gen-core-i912900k-review-hybrid-performance-brings-hybrid-complexity/2

Though speedbonus of AVX-512 if correctly used by software is about 3..4x over the old chips.

[DTL]

Some fresh info about first testing of SO3 (4 blocks 8x8 AVX2 processing) and SO4 (16 blocks 8x8 AVX512 processing) on
1. i5-11600 (2 DIMMs single sided (1 ranks) installed, possibly 2 channels)

2. Xeon Gold 6134 (all 6 memory channels should be installed in HP workstation)

Current results:
1. i5-11600 in raw MAnalyse performance (MDegrain rows processing close to disabled - only 1 st column left) about 2 times slower in best case (195 vs 104 fps).
2. SO3 4 blocks AVX2 processing in current testbuild a bit better at Xeon and a bit slower at i5-11600 in compare with AVX512 16 blocks processing. It looks even 4 blocks AVX2 processing takes all available memory bandwidth. And task still severily memory bound.
3. SO3 at Xeon (with 6 memory channels) is about 60% faster SO2 (1 block SIMD search). At i5-11600 - about 40% faster.
4. Some simple attempt of prefetching source blocks (about +3..+4 groups of blocks in advance) at all systems make a bit better performance (about 2..3%) so it is good to adjust manual prefetches. The hardware prefetchers not completely nice. And it also points to severe memory speed bounding of task.
5. At Xeon 8cores and 16 Hyperthreading switching from 8 to 16 threads good adds performance - about 40%. At i5-11600 8 cores 16 Hyperthreading - switching from 8 to 16 threads almost change nothing (may be 2 single rank DIMMs in 2 channels too low in speed to use > 8 threads).

So todo list:
1. Finish debug SO3 first.
2. Try to re-write MDegrainN processing to lines-based for the total frame width scan instead of current blocks-based. And test its speed difference.

[DTL]

"Is there any chance you will port MVTools to CUDA, Vulkan or OpenCL? Than would help a lot more and nowadays it's much more widespread to have a fast GPU than the latest CPU."

It looks we come to the limit of current architecture of 'triplet' MDegrainN + Avisynth-API + MAnalyse.

It uses frames memory management by Avisynth and in host-CPU memory. It is working with host-CPU for MAnalyse but not effective with ME-engine on separate HW-accelerator board.

With current architecture to create MVs for N output frames of N MDegrain threads it is require to upload to HWAcc board in worst case (2_x_tr)_x_2 x_N frames. With partial optimization of keeping Src resource reference for all calls to MAnalyse it can be lowered to (2_x_tr)_x_N . But with full optimization with resource management in HWacc board by one coordinator process it will be close to N only.

So in best case we need to ask Avisynth core developers to add HWAcc frames memory management so any filter in the Avisynth environment can only point to the resource ID (frame buffer) already loaded to HWAcc memory instead of re-uploading it every time.

I see in DeviceManager.cpp of Avisynth something about CUDA, but current ME-API from Microsoft is based on DirectX-graphics API resources operation (upload/download to DirectX/GPU-domain and interfacing with ME-engine). It is less specific of HW manufacturer but still specific for Windows OS and also not Linux/UNIX compatible (directly, may be wine ?).

The current may be easy to implement solutions may be:
1. Make DX12-ME option for MAnalyse to be compatible with all other filters of MVtools but it will be most ineffective with data transfer speed to HWAcc.

2. Make separate version of MDegrain(X/N) with direct interfacing with DX12-ME and working without MAnalyse. It will have its own tracking of loaded to HWAcc resources (frames) and decrease upload traffic.
It is still not compatible with AVS-MT nicely because each instance of MDegrain(X/N) will create its own pool of uploaded frames to HWAcc and it is also not best way.

3. Make again internal MT MDegrain(X/N) using existing avstp.dll (cured from freezing) or some other MT. It can manage its single pool of uploaded to HWAcc frames and use all host CPU cores for degraining processing. It may be not best solution for large processing scripts using AVS-MT ? Is it possible to run only one instance of MDegrainN in AVS-MT environment and many other filters ?

Current data flow in DX12-ME processing with ME engine in HW video encoder:
https://i3.imageban.ru/out/2021/12/28/2d0f003450a61a41ec96a46d57035af9.png

[DTL]

Make design idea how to make pel=2 and pel=4 processing faster:

In the old days the CPUs were slow and for sub-pel processing MSuper create 4x for pel=2 and 16x for pel=4 sub-shifted copies of input frame and the special GetBlock(x,y) function returns pointer to the sub-shifted full size sub-plane. This cause increasing read memory to 4x and 16x for pel 2 and 4. But close to zero CPU load for getting sub-shifted ref block for processing.

Todays CPUs much faster in computing and todays PC architecture still very slow in host RAM speed and its latency and caches sizes are too low to fit so many buffers.

So is an idea - to make sub-shifting of ref block 'on-request'. So simply add +1 block-sized buffer to MAnalyse and MDegrain 'workspace' and modify GetBlock(x,y) function to create sub-shifted block from single full-sized ref plane and return pointer to temp buf of this sub-shifted ref block. It will not be compatible with optSearchOption > 1 of Manalyse many search functions (for now it will increase search radius from 2 to 4 for pel=2 and only radius=4 SIMD search may be used - larger still not created but possible with AVX512).

Need an idea how to control this from mvtools params. In best way it should started from MSuper() - not create sub-shifted planes at all but send bit-flag of 'new pel' processing to Manalyse and Mdegrain. May be encode it as a bitfield in nPel value (currently it is 1 or 2 or 4) it is 0,1,2 bits set. So may be set 3rd bit to indicate 'new pel' processing ?

[tormento]

Make design idea how to make pel=2 and pel=4 processing faster
I know you are working really hard and I appreciate your fantastic job but, if you want to pursue the directx path, better you find a way to introduce HBD support.

Just my 2 cents. ;)

[DTL]

"a way to introduce HBD support."

DX12_ME API currently do not support anything but NV12 for MVs search input. And it 8bit YV12 format. The MDegrainN is support any old mvtools2 (the only float looks like broken somewhere but I think noone use it) inputs that 16bit also.

Current main sad limit - no overlap support with DX12_ME only search (may be overlap may be added with additional MRecalculate() before MDegrainN - but it will make processing slower and may remove most of benefit of DX12_ME pel up to 4 speed).

The DirectX/DirectCompute can have full functions of onCPU mvtools but may be in some future. Currently only 1 of 3 tasks is in active development - the SAD calculating on DirectCompute-ComputeShader because it not exist with DX12_ME output. The MVs search (including overlap mode) and MDegrainN is still for future. It may not give very large speedup for me - my system with i5-9600K CPU still very slow with x264 encoding. So with full degraining offload to accelerator I will got only about 2x total transcoding speed. Currently with pel=4 ME engine load is about 30% only and I mostly interesting in putting its resources to help x264 in speed - see https://forum.doom9.org/showthread.php?p=1962723#post1962723 .

About pure onCPU pel>1 we have big field of new SIMD functions:

1. Sub-shift to temp buf in RAM(cache) and feeding separate search functiion. (For each pel, block size)
2. Load src + ref blocks in register file and perform sub-shift + search in register file only (require to load interpolation kernel in register file too). It looks only possible with AVX2 or better AVX512 register file even for small 8x8 block.

[Ceppo]

There is an adobe plugin called Twixtor that allows blend interpolation like mvtools and another mode where it takes one of the interpolated frames and returns it without blending it. This mode would require only one motion vector and may give better interpolation result, at least Twixtor user say that this mode is often superior to blend. Is there any chance to get this blend free interpolating function?

[DTL]

I think it is important addition to the project - to add interface for input/output of moving data from MAnalyse to user-accessible format inside scripting environment and read back to client filters.

I read Dogway already ask for some way to get MVs from MAnalyse to check.

As I found with static images (static parts of moving images) processing - https://forum.doom9.org/showthread.php?p=1963966#post1963966 - the 2frames based MAnalyse search can not decrease noise on temporal axis and so the MVs data between MAnalyse and MDegrain client when processing noised sources may require additional filtering. I can add some form of temporal filtering to MDegrainN but it may be very content-dependent and may be it is good to allow many external non-C programmers developers to experiment with in-between motion data processing before final MDegrain blending.

Currently it looks we do not have common/standard exchange formats for motion data. With DX12 the Microsoft way of exchange is converting to 2D texture of 16+16 bit signed 2 component format (size of texture = number of blocks HxV). But it only provide translate motion x,y data.

For current AVS+ it is idea to convert to RGBPS format texture/clip with mapping as
R - x
G - y
B - SAD

And may be make 2 additional functions to convert MAnalyse output pseudo-clip to MotionData-RGBPS and back. So users of scripts with sample-accesing functions may try to read or read and send back processed (filtered) motion data to the downstream client filters. May be it is enough to provide motion data only per level=0 and not all other levels (MDegrain only uses level=0 data ?).

In the best future we need some extended format may be like XML (?) with many motion (transform) params for each block:
1. Translate (x,y)
2. Rotate (rz (rx, ry) ?)
3. Scale (sx,sy)
4. Skew (.., sx, sy)
5..
N. SAD scalar unsigned data

May be for multi-movement search engines use set of separated RGBPS or Y-PS clips for each type of movement (translate/rotate/scale/etc). So if client filter can accept different types of motion data it will accept several input motion-clips. It will keep compatibility with old versions/scripts.

[DTL]

A couple of other questions:
- do you think we will ever get to a point in which compilers will be smart enough to generate fast enough code automatically at compile time while targeting an instruction set so that manually written intrinsics won't be necessary/worth writing or will it ever be science fiction?



Some more information about motion search on non-CPU data compute accelerators:

1. Good information: The data compute accelerators also support dedicated hardware instructions for many SAD computing on input vectors - the msad4 intrinsinc in HLSL: https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-msad4 . Also have an example for searching position of reference pattern in a buffer. That mean the SAD-based motion search form current MAnalyse may be more efficiently ported into Compute Shader version.

2. The very strange situation about 'low level' programming of compute accelerators: It not support 'assembler' level programming. Only C-like languages. Example of question about direct 'assembler-level' programming of accelerator - https://stackoverflow.com/questions/55813432/how-to-compile-from-shader-assembler-code-in-directx-11 .
For NVIDIA CUDA - https://stackoverflow.com/questions/7353136/is-there-an-assembly-language-for-cuda .

So it mean currently the compiler must produce as best as possible executable result for accelerator and no manual hand-crafting is possible (not officially supported). Programmer need to use higher-level functions intrinsics or simple C-like statements. That is partial answer on the question about current and may be future state of compiler optimizations for at least part of current computing hardware (and may be typically higher in performance in compare with host desktop CPU). May be accelerators from different manufacturers are not fully compatible with instructions sets so even in 'compiled' state the program may still use some pseudo-code for further adapting to executing hardware at runtime.

It looks AMD also will someday support AVX512 register file and some instructions. https://www.extremetech.com/computing/325888-gigabyte-leaks-amd-zen-4-details-5nm-avx-512-96-cores-12-channel-ddr5
So it is good to test the sub-sample processing with upsizing of 1x level to 2x or 4x for pel=2 and pel=4 search in MAnalyse and shifting for MDegrainN on AVX512 functions.

[FranceBB]

It looks AMD also will someday support AVX512 register file and some instructions. https://www.extremetech.com/computing/325888-gigabyte-leaks-amd-zen-4-details-5nm-avx-512-96-cores-12-channel-ddr5
So it is good to test the sub-sample processing with upsizing of 1x level to 2x or 4x for pel=2 and pel=4 search in MAnalyse and shifting for MDegrainN on AVX512 functions.

Thanks for the info. Honestly, when I had to purchase new servers in 2019, I went again for Intel Xeon mostly due to the fact that they were the only ones supporting AVX-512. They're encoding files through Avisynth and either x262/Libavcodec MPEG-2 Encoder or x264 on a daily basis, calling then the mxf muxer (either BBC BMX or the closed source paid Omneon mxf muxer provided by Harmonic). I do make use of MVTools extensively for the Tape Remastering workflows put in place in Summer 2020 after Derek's suggestion, so seeing a speed improvement in there would be nice. I'm not planning to get any new servers anytime soon as I'm re-allocating old AVID Transcode servers to become "new" Avisynth servers. They're just low speed 10c/20th Intel Xeon with AVX2 only, so nothing compared to the three 56c/112th AVX-512 beasts I bought in 2019, but they're gonna do the job. I guess the time to perhaps try an AMD test bench for professional encoding use in servers MIGHT come in 2025 if I'll have to buy more servers, but for the time being, I guess I'm gonna be fine as I have a farm with:

- 3 Intel Xeon 56c/112th AVX-512 128 GB of RAM
- 2 Intel Xeon 20c/40th AVX-2 64 GB of RAM
- 1 Intel Xeon 10c/20th AVX-2 32 GB of RAM (old server)

and soon-ish I'm gonna have 19 more of those, so:

- 20 Intel Xeon 10c/20th AVX-2 32 GB of RAM (old server)

that should take care of all the extra work and ideally the 3 monsters will pick up and handle almost only the ProRes, XAVC, MJPEG2000 etc UHD clips and the other ones will take care of the old/legacy XDCAM-50 FULL HD version and the MPEG-2 12 Mbit/s Long GOP M=3 N=15 SD version of movies, tv series etc.

The only nag is that for SD versions only I always have to call ommcp.exe and remux with the Omneon muxer 'cause Omneon playout ports have their own special flag and they don't follow the normal container's flag or stream's flag for aspect ratio. This is because once you flag it within Omneon, it will tell the playback port what to do, so not only whether it's 4:3 or 16:9 but also whether you want to crop it, add borders, leave it as it is etc.

I really honestly wish SD to die 'cause encoding 2022 movies in SD BT601 only to serve some people really breaks my heart.

[DTL]

Made some graphics to show how MDegrain works with incoming SAD deviations and for understanding how to set thSAD (and wpow) value for different input noise-based SAD distributions.

https://i4.imageban.ru/out/2022/06/28/44eb4fb767b05f134515006c7a979dc0.png

Also attached to post to keep at this server.

As for thSCD1 value: The current ideas it shoud be at least as great as thSAD. Default thSCD1 looks like 400, so if increasing thSAD above 400 it may required to raise thSCD1 too or it will work as internal thSAD limiter and will also throw-away blocks from processing completely because detected as scene-changed blocks and completely wrongly compensated.

As for AVX512:

Currently I am in the finishing process of testing new processing mode for MDegrainN and pel > 1 with inside CPU core generating sub-pel compensated block instead of fetchig of pre-computed by MSuper() block from host memory (using old fully pel-refined super clip to 4x size for pel=2 and 16x size for pel=4). It works about good and faster but for best speed require processing inside register file of chip. So the AVX2 512 bytes sized register file is enough only for 8x8 8bit and lower block sizes (so can only fully service YV12 8 bit colour format with 8x8 luma and 4x4 chroma blocks, the 4:2:2 YV16 may be added with 4x8 chroma block size but not sure if it is widely used, also not sure if it supported by current mvtools at all). For any larger it is better to use 2048 bytes AVX512 register file (also with a bit faster processing of twice longer vectors). So todays 8x8 16bit blocks and 16x16 16bit blocks already require AVX512 for best speed.

The 16bit 8x8 and 16x16 blocks processing AVX2 functions can be designed but will have lower performance because of store-load temp results from register file to L1d cache and back and it ruines speed to a factor about 5. Not total function speed but internal partial operations touching memory susbsystem like cache. Main reason of these functions will be to save RAM usage and it also adds to processing speed.

I also will post a test sample of MAnalyse with same 'runtime-calculating' pel >1 blocks fetching. But it looks even at UMH optimized search it still slower in compare with pre-calculated super-clip of pel=4 about 2 times at i5-9600K chip. Will try to test at i5-11600 chip with AVX512 versions of sub-shift functions too later.

So the main speed benefit of new MDegrainN processing of pel >1 is when using ME hardware accelerator so the most speed limit was memory fetching of blocks from large 16x sized pel=4 super clip at 4K resolutions. It is about 1.2 fps at i5-9600K with old super clip mode and about 6 fps with new inside chip shifting of 1x sized frames.

[tormento]

Made some graphics to show how MDegrain works with incoming SAD deviations and for understanding how to set thSAD (and wpow) value for different input noise-based SAD distributions.
How this graph would help us to find the correct values for parameters? I am looking at it and I am "a bit" confused.

What is the latest version that of MVTools that I can use with SMDegrain with no AVSI modification, withouth AVX2/512 requirement?

[DTL]

"How this graph would help us to find the correct values for parameters?"

I hope it can help to understand MDegrainN activity when parameters changing:
1. When thSAD is too low - any tr value will not help in degraining.
2. The good working value of thSAD have enough visible 'barrier' or 'step' effect - untill it reach lower noise-SAD levels it is mostly ineffective. After it is set to upper noise-SAD values it become already nearly maximum effective and increasing thSAD to higher levels mostly do nothing (useful) but may cause more details blurring.
3. After thSAD reach optimal level - the most of degrain-strength adjustment is only tr-width (value). Increasing thSAD to twice or more higher above optimal will mostly not add anything useful to degrain activity.

To the left it is placed rotated graph of different DegrainWeight() functions graphs scaled to 'possibly optimal' thSAD vertical value to show how blocks weights depend on SAD and thSAD values and with different wpow params. May be it is good to shoot a video-lection with a several minutes or more duration with attempt to describe this drawing better :) .

"What is the latest version that of MVTools that I can use with SMDegrain with no AVSI modification, withouth AVX2/512 requirement?"

In theory any builds should be backward compatible with old scripts. All new params are in the default disabled state. Also the max available version of SIMD co-processor is auto-detected.
It was funny to found the old program text around MAnalyse() functions that very ancient 'isse' common functions param was truncated to SSE or nothing only. And there were no newer functions above SSE 128bit to use more newer chips. So this truncation were never detected untill the AVX2 functions were added.

[tormento]

I hope it can help to understand MDegrainN activity when parameters changing
I do it manually, increasing tr and thsad at the same time, until compressibility comes to decrease less and less rapidly.

tr=3, thsad=300 -> x265 -> file size
tr=4, thsad=400 -> x265 -> file size

etc...

But it's very time consuming and I have always wondered if there is a way to do it automatically.
In theory any builds should be backward compatible with old scripts.
I remember that you sent here a version with one hardcoded parameter that could really increase speed without affecting quality in a visible manner. Would it be possible to have that version, updated?

[LeXXuz]

"How this graph would help us to find the correct values for parameters?"

I hope it can help to understand MDegrainN activity when parameters changing:
1. When thSAD is too low - any tr value will not help in degraining.
2. The good working value of thSAD have enough visible 'barrier' or 'step' effect - untill it reach lower noise-SAD levels it is mostly ineffective. After it is set to upper noise-SAD values it become already nearly maximum effective and increasing thSAD to higher levels mostly do nothing (useful) but may cause more details blurring.
3. After thSAD reach optimal level - the most of degrain-strength adjustment is only tr-width (value). Increasing thSAD to twice or more higher above optimal will mostly not add anything useful to degrain activity.

To the left it is placed rotated graph of different DegrainWeight() functions graphs scaled to 'possibly optimal' thSAD vertical value to show how blocks weights depend on SAD and thSAD values and with different wpow params. May be it is good to shoot a video-lection with a several minutes or more duration with attempt to describe this drawing better :) .

"What is the latest version that of MVTools that I can use with SMDegrain with no AVSI modification, withouth AVX2/512 requirement?"

In theory any builds should be backward compatible with old scripts. All new params are in the default disabled state. Also the max available version of SIMD co-processor is auto-detected.
It was funny to found the old program text around MAnalyse() functions that very ancient 'isse' common functions param was truncated to SSE or nothing only. And there were no newer functions above SSE 128bit to use more newer chips. So this truncation were never detected untill the AVX2 functions were added.

These figures are ver interesting and thanks for the more detailed explanation.

I never paid much attention to anything else but prefiltering, tr and thSAD. Simply because I didn't understand enough how all the other parameters are connected with each other. Yes, I read the docs. But that still was way over my head at times. :o

So the very big question is how to determine the somewhat best SAD value for a source file.

Right now, much like tormento already mentioned, it's more like a lot of trial and error for me. So I was wondering if there may be any automated way to measure this somehow. It doesn't have to measure the best possible settings but something like a decent base of params to just tweak a little here and there to personal liking. Otherwise starting from scratch for every movie will be a life's work if I ever want to recode my collection. :D

[DTL]

" that version, updated?"

The most currently developed new feature of internal shifting for MDegrainN need at least AVX2 CPU to run faster in compare with old versions. And still have only YV12 format supported in this mode with Y-block size of 8x8. So it will not run faster at old AVX-only chip.

" always wondered if there is a way to do it automatically"

Initial estimation of the thSAD may be with MShow(showsad=true). To make it work stable I use single pair of frames search:

super = MSuper(mt=false, pel=1)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, search=3, chroma=true, mt=false)
MShow(super,forward_vec1, showsad=true)


With multi-mode of MAnalyse it typically not shows SAD stable enough.

" increasing tr and thsad at the same time"

thSAD mostly control 'quality by blurring' and tr the 'amount of degraining'. So initially it is good to set as high thSAD as still not too much degrade fine details but already making degraining with relatively low tr like 3. And next increase tr to balance speed/degraining ratio. And look for the ratio of thSAD vs thSCD1 value - if thSAD > thSCD1 visibly (also if mean SAD by MShow(showsad=true) is > thSCD1) - need to start raise thSCD1 too.

[Boulder]

As for thSCD1 value: The current ideas it shoud be at least as great as thSAD. Default thSCD1 looks like 400, so if increasing thSAD above 400 it may required to raise thSCD1 too or it will work as internal thSAD limiter and will also throw-away blocks from processing completely because detected as scene-changed blocks and completely wrongly compensated.

Interesting - I thought that scene change detection affected the whole frame and not just a single block. If you use MShow to view the vectors, you get that impression.

[DTL]

Updated post:

After more looking into the source: Yes - the array 'usable_flag_arr' is one per frame entry.

The usage of thSCD1 and thSCD2 is mostly as

bool FakePlaneOfBlocks::IsSceneChange(sad_t nTh1, int nTh2) const
{
int sum = 0;
for ( int i = 0; i < nBlkCount; i++ )
sum += ( blocks[i].GetSAD() > nTh1 ) ? 1 : 0;

return ( sum > nTh2 );
}


So when there are too many blocks with SAD > thSCD1 - the total frame marked as not-usable. So thSCD1 really directly compared with block SAD but the final result is per-frame but not per-block.

So engine allow some blocks to have SAD > thSCD1 and still be in processing (only if the frame still marked as usable !). But after percentage of these blocks become > thSCD2 - the whole frame is marked as unusable and thrown away from processing.

thSCD2 (int, 130)
Threshold which sets how many blocks have to change for the frame to be considered as a scene change. It is ranged from 0 to 255, 0 meaning 0 %, 255 meaning 100 %. Default is 130 (which means 51 %).

So user must carefully look for situation when thSAD > thSCD1 - it may quickly stops any useful processing and any increasing of tr will be useless.

[LeXXuz]

Just throwing in some numbers...

I had:
thSAD=800, tr=12 and thSC1=default => total file size 7.72GB

now retried with:
thsad=800, tr=12 and thSCD1=600 => 6.59GB
thsad=800, tr=24 and thSCD1=600 => 5.69GB

I think tr=24 and higher thSCD1 were totally worth it. At least for this source. However, I will not go any higher than 24, speed gets too low for general use. With tr=12 I had 5.18FPS and with tr=24 it dropped to 2.91FPS including prefiltering and a modified "slower" setting of x265. That's barely still okay. But any slower would kill me with my next electrical bill. :D

Will now lower thSAD more closer to thSCD1 and see how much file size will increase, because 800 is already smoothing too much for my taste.

[DTL]

"thsad=800, and thSCD1=600"

I think in practical use cases thSCD1 should be not less than thSAD. Default is thSAD=thSCD1=400 as I see from documentation.

" total file size 7.72GB"

If you encode in crf mode with x264 (may be x265 too) there may be also some 'threshold effect' based of crf-value close to MDegrain activity - if you set crf as high so the MPEG encoder do not detect changed blocks - it encodes as static and no residual noise changes and output file size reduces very visibly. Same happens if after increasing thSAD and tr to such high values that residual noise is below 'crf-threshold' of MPEG encoder you also got significant filesize decrease.

So you may try to make a research of

(thSAD, tr) in mvtools + (crf) in MPEG encoder and look how output file size is changed.

So practically mvtools are pre-processor for higher-ratio MPEG compressing. As moving from MPEG4-AVC to MPEG-HEVC may give about +50% compression ratio but using denoise before MPEG4-AVC may add thousands % of compression ratio and also make image more clean and clear. I currently have about 22000Kbit/s in non-denoised documentaries in FullHD and about 4500Kbit/s after 'deep denoising' with same crf=18 x264 encoder. So additional compression ratio from denoise-preprocessing is about 488%.

"Will now lower thSAD more closer to thSCD1 "

In the 2.7.45 and older the DegrainWeight weighting functions have fixed control param of 2. In the newer versions it is wpow param of MDegrainN and may be set up to 6 and 7=equal weight. It allow to increase block weight inside thSAD without setting thSAD too high. I typically use wpow=4 now. BlockWeight=f(wpow, blockSAD) is that graph at the left rotated 90degrees at the big combined image https://i4.imageban.ru/out/2022/06/28/44eb4fb767b05f134515006c7a979dc0.png
Unfortunately in the used math functon wpow > 6 is too slow in computing so after 6 the SAD-based smooth falloff weighting is disabled and equal weighting used - so wpow=7 is the max possible degraining at given thSAD but may cause additional visual issues.

[LeXXuz]

Initial estimation of the thSAD may be with MShow(showsad=true). To make it work stable I use single pair of frames search:

super = MSuper(mt=false, pel=1)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, search=3, chroma=true, mt=false)
MShow(super,forward_vec1, showsad=true)



Is this the average value found for a frame or the maximum?
With the source I currently have it hardly goes over 400. I use 600 now which still leaves a little noise in the picture.
Also I start to think there is more than just grain in this film that makes it compress so badly. I think I noticed some flickering and mosquito noise around edges too. Looks like the source bitrate was already chosen too low when this Blu-ray was created. :(

[DTL]

"Is this the average value found for a frame or the maximum?"

MShow -> showsad

Allows to show the mean (scaled to block 8x8) SAD after compensating the picture and quantity (thSCD2) of bad (thSCD1) blocks.

Mean is about average I think. May be it also good to add more statistics to MShow like ends of distribution like mean of 5..10% smallest SAD and mean of 5..10% of highest SAD.

[takla]

Yeah. Using what ever thSAD Mshow shows ain't gonna work. A quick test with one of my sources shows a range from ~50 to ~200 (so my default 150 was actually pretty good here).

And yes, having the statistic show some % of lowest and highest SAD would be very helpful.

thSAD NEEDS to be dynamically adjusted automatically. It should not be a fixed value. What SHOULD be a fixed value is something like thSADmax which caps the maximum.

OR you could also make it so there is a logfile that writes every frames SAD value and have MDegrain read from it. Basically 2-pass mode.

[anton_foy]

Yeah. Using what ever thSAD Mshow shows ain't gonna work. A quick test with one of my sources shows a range from ~50 to ~200 (so my default 150 was actually pretty good here).

And yes, having the statistic show some % of lowest and highest SAD would be very helpful.

thSAD NEEDS to be dynamically adjusted automatically. It should not be a fixed value. What SHOULD be a fixed value is something like thSADmax which caps the maximum.

OR you could also make it so there is a logfile that writes every frames SAD value and have MDegrain read from it. Basically 2-pass mode.

I use these lines below to regulate thSAD and TR dynamically with ScriptClip.
Although my material is noisy 4K sLog-2 footage so for other material the "noise detection" may be tweaked or changed to fit the purpose better:


o=last

#Prefilter:
b=fastblur(3)
P=merge(o,b,0.5).ex_levels(12,1.2,100)

pk = converttoRGB()
pl = pk.converttoPlanarRGB()
in = pl.ex_invert()

t=ScriptClip(function[in,pl,pk,p] () {

lum = in.averageR()
rgb = pk.RGBDifferenceFromPrevious()
luma = int(lum + rgb)
ttr = int(luma*0.0001)
ths = int(luma*0.0067)

TSMC(tradius=ttr,lumathresh=ths,auxclip=p)
} )

Also in this case I use mocomped TemporalSoften but you can use mdegrainN or SMDegrain instead. Note my prefiltering is a simple fastblur+levels which after months of testing prefiltering techniques surprisingly works the best (out of all the other prefiltering I tried) for my material.

[takla]

I use these lines below to regulate thSAD and TR dynamically with ScriptClip.
Although my material is noisy 4K sLog-2 footage so for other material the "noise detection" may be tweaked or changed to fit the purpose better:


o=last

#Prefilter:
b=fastblur(3)
P=merge(o,b,0.5).ex_levels(12,1.2,100)

pk = converttoRGB()
pl = pk.converttoPlanarRGB()
in = pl.ex_invert()

t=ScriptClip(function[in,pl,pk,p] () {

lum = in.averageR()
rgb = pk.RGBDifferenceFromPrevious()
luma = int(lum + rgb)
ttr = int(luma*0.0001)
ths = int(luma*0.0067)

TSMC(tradius=ttr,lumathresh=ths,auxclip=p)
} )

Also in this case I use mocomped TemporalSoften but you can use mdegrainN or SMDegrain instead. Note my prefiltering is a simple fastblur+levels which after months of testing prefiltering techniques surprisingly works the best (out of all the other prefiltering I tried) for my material.

That is nice and might help some people, but in this case, I want to get the exact value from Mshow. How to I accomplish this? I don't think support for that is there.

[LeXXuz]

"Is this the average value found for a frame or the maximum?"

MShow -> showsad

Allows to show the mean (scaled to block 8x8) SAD after compensating the picture and quantity (thSCD2) of bad (thSCD1) blocks.

Mean is about average I think. May be it also good to add more statistics to MShow like ends of distribution like mean of 5..10% smallest SAD and mean of 5..10% of highest SAD.

The second digit shows the quantity of bad blocks? What does bad blocks mean in that context?