MVTools-pfmod

[tormento]

Now we need a revised masktools :)

[real.finder]

New release:


MvTools2 2.7.5.22 (20161119)
General support of 10-16 bit formats with Avisynth Plus (r2294 or newer recommended)
with new MDegrain4 and MDegrain5 filters.
Depan: 2.13.1 (20161119)
DepanEstimate: 2.10 (20161119)
General support of 10-16 bit formats with Avisynth Plus
Compiled for 64 bit for the first time
Supporting YV16 and YV24 for 8 bit and their 10+ bits equivalents
Requires 2.6 interface


Download:
MvTools 2.7.5.22 + Depan + DepanEstimate for 32 and 64 bits (https://github.com/pinterf/mvtools/releases/tag/r2.7.5.22)

For general info see readme or the first page of the thread.
Have fun.

Todo:

greyscale support (not tested)
Port remaining inline assembly to SIMD intrinsics
satd 16 bit to SIMD
fix reported bugs


:thanks: Energetic as always :D

has the Depan fix this bug (http://forum.videohelp.com/threads/371336-Stabilization-Tools-Pack-v2-1?p=2386111&viewfull=1#post2386111) (turns the video green)?

[Reel.Deel]

New release:


MvTools2 2.7.5.22 (20161119)
General support of 10-16 bit formats with Avisynth Plus (r2294 or newer recommended)
with new MDegrain4 and MDegrain5 filters.
Depan: 2.13.1 (20161119)
DepanEstimate: 2.10 (20161119)
General support of 10-16 bit formats with Avisynth Plus
Compiled for 64 bit for the first time
Supporting YV16 and YV24 for 8 bit and their 10+ bits equivalents
Requires 2.6 interface


Download:
MvTools 2.7.5.22 + Depan + DepanEstimate for 32 and 64 bits (https://github.com/pinterf/mvtools/releases/tag/r2.7.5.22)

For general info see readme or the first page of the thread.
Have fun.

Todo:

greyscale support (not tested)
Port remaining inline assembly to SIMD intrinsics
satd 16 bit to SIMD
fix reported bugs


Awesome work as always, thanks pinterf! :thanks:


has the Depan fix this bug (http://forum.videohelp.com/threads/371336-Stabilization-Tools-Pack-v2-1?p=2386111&viewfull=1#post2386111) (turns the video green)?

I think Fizick fixed it in the latest release, see here: http://forum.doom9.org/showthread.php?p=1763563#post1763563

Now we need a revised masktools :)

A while back tp7 started working on a 16-bit MaskTools, unfortunately it was not finished. See here: https://github.com/tp7/masktools/commits/16bit

Maybe someone will come along and finish it. Another route is porting VS' Expr and co.

[feisty2]

Someday, maybe there will be a complete version of mvtools that could merge all mvtools variations into one
One binary serves as both a vaporsynth plugin and an avisynth plugin, supporting bitdepths from 8 to 32 and arbitrary temporal radius..

[real.finder]

I think Fizick fixed it in the latest release, see here: http://forum.doom9.org/showthread.php?p=1763563#post1763563



I missed this update...

[real.finder]

MvTools2 2.7.5.22d is slower than mvtools2 2.7.0.22d

~1.7 fps vs ~1.5 fps with same complex script

is this because it built without ICC?

[Groucho2004]

MvTools2 2.7.5.22d is slower than mvtools2 2.7.0.22d

~1.7 fps vs ~1.5 fps with same complex script

is this because it built without ICC?
No. It's because ill-tempered fairies have invaded your computer and are eating CPU cycles. :sly:

If you post the script that causes this behaviour and possibly mention what CPU you have you'll probably get a better answer.

[pinterf]

MvTools2 2.7.5.22d is slower than mvtools2 2.7.0.22d

~1.7 fps vs ~1.5 fps with same complex script

is this because it built without ICC?
Yes.
Since then I found some bottlenecking places when using __forceinline helped poor vs2015.

Testing on a typical MDegrain3 script:
2.7.5.22: 4.13 fps (VS2015)
2.7.0.22d: 4.69 fps
2.7.futu.re: 4.62 fps (VS2015)

Promising.

[Groucho2004]

Testing on a typical MDegrain3 script:
2.7.5.22: 4.13 fps (VS2015)
2.7.0.22d: 4.69 fps

What CPU do you use for these tests? Also, what switches for ICC?

[pinterf]

i7 ivy bridge.
Icc build was for sse2 with optional sse4.1 code paths

[real.finder]

Yes.
Since then I found some bottlenecking places when using __forceinline helped poor vs2015.

Testing on a typical MDegrain3 script:
2.7.5.22: 4.13 fps (VS2015)
2.7.0.22d: 4.69 fps
2.7.futu.re: 4.62 fps (VS2015)

Promising.

why stop using ICL in last ver.? for amd users?

[Groucho2004]

Icc build was for sse2 with optional sse4.1 code pathsWell, that's just one switch (QaxNNN). From my experience with Intel compilers, there are at least 5-7 other switches that can affect performance. Just a little selection:
/O3 optimize for maximum speed and enable more aggressive optimizations

/Qipo[n] enable multi-file IP optimization between files

/Qunroll-aggressive

/Qopt-ra-region-strategy[:<keyword>]
select the method that the register allocator uses to partition each
routine into regions
routine - one region per routine
block - one region per block
trace - one region per trace
loop - one region per loop
default - compiler selects best option

/Qprof profiling

[pinterf]

Will check it later now i'm from mobile.

[Groucho2004]

Icc build was for sse2 with optional sse4.1 code paths
One more thing about the automatic CPU dispatcher (enabled with QaX...) in the Intel compiler - This could actually have an impact on AMD CPUs since I suspect that even with the latest incarnation of the compiler it may chose sub-optimal optimizations for those.
If I build for specific instruction sets, I always "hard-code" them by using "Qx..." instead of "QaX...". This way all CPUs use the same code path. That of course means building binaries for each instruction set.
I also recommend testing if the SSE4.x or even AVX options really make a difference. More often than not, they don't. As usual, it all depends on the code.

[jpsdr]

If I build for specific instruction sets, I always "hard-code" them by using "Qx..." instead of "QaX...". This way all CPUs use the same code path. That of course means building binaries for each instruction set.
Oh... You too.

Didn't know some of the options :

/Qunroll-aggressive
/Qopt-ra-region-strategy[:<keyword>]

I'll have to check themn even if... "aggressive". Just seeing the word make me a little suspicious.

[Groucho2004]

Oh... You too.

Didn't know some of the options :

/Qunroll-aggressive
/Qopt-ra-region-strategy[:<keyword>]

I'll have to check themn even if... "aggressive". Just seeing the word make me a little suspicious.
Don't worry. :)

I suppose my way of building binaries differs a lot from what everyone else does. I don't use the IDE, I create makefiles for my projects and build from the command line with batch files. The makefiles have easily accessible compiler and linker options so I can quickly change them, rebuild and test.

As for all compiler options - run "icl -help" and pipe into a text file. And there are of course the Intel docs that come with the compiler which have lots of stuff about optimization (which almost nobody reads, I guess).

[pinterf]

One more thing about the automatic CPU dispatcher (enabled with QaX...) in the Intel compiler - This could actually have an impact on AMD CPUs since I suspect that even with the latest incarnation of the compiler it may chose sub-optimal optimizations for those.
If I build for specific instruction sets, I always "hard-code" them by using "Qx..." instead of "QaX...". This way all CPUs use the same code path. That of course means building binaries for each instruction set.
I also recommend testing if the SSE4.x or even AVX options really make a difference. More often than not, they don't. As usual, it all depends on the code.

Not to mention the aligment hints, hints for typical loop size, etc.

Finally I couldn't find my old ICC settings. Sure, loop unrolling was at default, so it was not fine-tuned, but I've seen unrolled loops in the asm output (sometimes I check the asm code that compilers generate). Global optimization was on, and the maximum optimization, too.

When I have successfully gained back a lot of speed, I used VS2015's performance profiler that showed me the parts where the code spends most of the time. Then I forced these functions to be inline.

There were other optimizations I have made, so perhaps the ICC version could also be faster, from the current codebase.

Interesting article on the optimizer changes came with VS2015 update 3:
https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/

[Groucho2004]

There are also oddball cases where the compiler options for max. speed have the opposite effect. I have a couple of programs where turning off automatic inlining or even using "O1" instead of "O2/O3" results in faster binaries. Always test, if possible on Intel and AMD CPUs.

[jpsdr]

And there are of course the Intel docs that come with the compiler which have lots of stuff about optimization (which almost nobody reads, I guess).
Yes, i've read it... a long time ago.;)

[pinterf]

New version. 2.7.6.22
Depan and DepanEstimate are unchanged.

https://github.com/pinterf/mvtools/releases/tag/2.7.6.22

Change log
2.7.6.22 (20161204) - fixes and speedup


fix: sumLumaChange underflow (used for dct=2,6,9) (regression during 16 bit support)
fix: MeanLumaChange scale for 10-16 bits (used for dct=2,6,9)
fix: Mask fix: 8 bit mask resizer bug in SIMD intrinsics - Thx real.finder
(regression on inline asm -> SIMD transition)
Fix: dctmode=1,2: pixel distance was not corrected for 16 bit pixel sizes
speed: Let's help VS2015 with some __forceinline directives to recognize the truth.
speed: Misc optimizations throughout the code (bit shifts instead of div or mul)
speed: FFTW DCT: C code replaced with SIMD SSE2/SSE4 (FloatToBytes, BytesToFloat)
speed: 16 bit SAD: a few optimizations in SSE2, AVX-coded SSE2 and AVX2 codepath
VS2015 compiler: /MT -> /MD (from static to dynamic dlls - now it really needs VS2015 redistributables)

[Motenai Yoda]

depanestimate (or depan) parameters have been changed? coz scene change detection looks broken to me

[tormento]

Strange enough, now MDegrain5 is more effective than MDegrain6 in SMDegrain and almost comparable with MDegrain4.

Perhaps MDegrain6 (and MDegrainN) is needed or simply wrong script implementation?

[pinterf]

Strange enough, now MDegrain5 is more effective than MDegrain6 in SMDegrain and almost comparable with MDegrain4.

Perhaps MDegrain6 (and MDegrainN) is needed or simply wrong script implementation?
I don't understand exactly but when MDegrainN is called, if thSAD2 = thSAD and thSADC = thSADC2 then MDegrainN will call the original MDegrain1..5 because it is said to be faster.
MDegrain6 does not exist, it always uses MDegrainN.

[pinterf]

depanestimate (or depan) parameters have been changed? coz scene change detection looks broken to me
Dunno, this one needs investigating.

[tormento]

I don't understand exactly but when MDegrainN is called, if thSAD2 = thSAD and thSADC = thSADC2 then MDegrainN will call the original MDegrain1..5 because it is said to be faster.
MDegrain6 does not exist, it always uses MDegrainN.

I meant SMDegrain with tr=5 or tr=6. According to my experience, 6 was more effective in noise reduction than 5.

Can't trace back when things went wrong, as I always used 4 or 6.

[real.finder]

ok, I did another change, http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution?p=2413356&viewfull=1#post2413356

try with always_mdegrainn=true

[tormento]

try with always_mdegrainn=true

Files:

pee.264 (http://www53.zippyshare.com/v/c6vwyvYM/file.html)
pee.dgi (http://www53.zippyshare.com/v/mGjFageP/file.html)

SMDegrain.avsi (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution?p=2413356&viewfull=1#post2413356) + this (http://forum.doom9.org/showthread.php?p=1787600#post1787600) variation to use KNLMeansCL 1.0

Basic script and variations:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\Pee Wee's big adventure\pee.dgi")

ChangeFPS(last,last,true)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false)

Prefetch(7)

encoded 2162 frames, 7.81 fps, 4015.53 kb/s, duration 0:04:36.77
av2y [info]: E:\in\Pee Wee's big adventure\pee_44.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 43.2 MB bytes.

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false,always_MDegrainN=true)

encoded 2162 frames, 7.72 fps, 4245.76 kb/s, duration 0:04:40.05
av2y [info]: E:\in\Pee Wee's big adventure\pee_44a.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 45.7 MB bytes.

SMDegrain (tr=5,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false)

encoded 2162 frames, 7.00 fps, 3771.63 kb/s, duration 0:05:08.76
av2y [info]: E:\in\Pee Wee's big adventure\pee_54.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 40.6 MB bytes.

SMDegrain (tr=5,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false,always_MDegrainN=true)

encoded 2162 frames, 6.81 fps, 3991.23 kb/s, duration 0:05:17.41
av2y [info]: E:\in\Pee Wee's big adventure\pee_54a.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 42.9 MB bytes.

SMDegrain (tr=6,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false)

encoded 2162 frames, 6.16 fps, 3806.16 kb/s, duration 0:05:51.22
av2y [info]: E:\in\Pee Wee's big adventure\pee_64.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 40.9 MB bytes.

SMDegrain (tr=6,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false,always_MDegrainN=true)

encoded 2162 frames, 6.12 fps, 3806.16 kb/s, duration 0:05:53.37
av2y [info]: E:\in\Pee Wee's big adventure\pee_64a.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 40.9 MB bytes.

Something is going wrong, I think, in script or in latest MVTools iteration. How is possible that a 6 frame noise reduction is less effective than a 5 frame and almost equivalent to a 4?

[real.finder]

Files:

pee.264 (http://www53.zippyshare.com/v/c6vwyvYM/file.html)
pee.dgi (http://www53.zippyshare.com/v/mGjFageP/file.html)

SMDegrain.avsi (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution?p=2413356&viewfull=1#post2413356) + this (http://forum.doom9.org/showthread.php?p=1787600#post1787600) variation to use KNLMeansCL 1.0

Basic script and variations:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\Pee Wee's big adventure\pee.dgi")

ChangeFPS(last,last,true)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false)

Prefetch(7)

encoded 2162 frames, 7.81 fps, 4015.53 kb/s, duration 0:04:36.77
av2y [info]: E:\in\Pee Wee's big adventure\pee_44.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 43.2 MB bytes.

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false,always_MDegrainN=true)

encoded 2162 frames, 7.72 fps, 4245.76 kb/s, duration 0:04:40.05
av2y [info]: E:\in\Pee Wee's big adventure\pee_44a.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 45.7 MB bytes.

SMDegrain (tr=5,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false)

encoded 2162 frames, 7.00 fps, 3771.63 kb/s, duration 0:05:08.76
av2y [info]: E:\in\Pee Wee's big adventure\pee_54.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 40.6 MB bytes.

SMDegrain (tr=5,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false,always_MDegrainN=true)

encoded 2162 frames, 6.81 fps, 3991.23 kb/s, duration 0:05:17.41
av2y [info]: E:\in\Pee Wee's big adventure\pee_54a.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 42.9 MB bytes.

SMDegrain (tr=6,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false)

encoded 2162 frames, 6.16 fps, 3806.16 kb/s, duration 0:05:51.22
av2y [info]: E:\in\Pee Wee's big adventure\pee_64.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 40.9 MB bytes.

SMDegrain (tr=6,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false,always_MDegrainN=true)

encoded 2162 frames, 6.12 fps, 3806.16 kb/s, duration 0:05:53.37
av2y [info]: E:\in\Pee Wee's big adventure\pee_64a.avs: 1920x1080, 2997/125 fps, 2162 frames
Final file size is 40.9 MB bytes.

Something is going wrong, I think, in script or in latest MVTools iteration. How is possible that a 6 frame noise reduction is less effective than a 5 frame and almost equivalent to a 4?

I think that MDegrainN with thSAD2 (it's thSAD/2 in SMDegrain) will did it in another way, like what MRecalculate do, so now you have new option to do your denoise :)

[tormento]

I think that MDegrainN with thSAD2 (it's thSAD/2 in SMDegrain) will did it in another way, like what MRecalculate do, so now you have new option to do your denoise :)

I really can't understand you... :(

[real.finder]

I really can't understand you... :(

I mean always_mdegrainn=true, you can use it even with tr=1

it will make the denoise more friendly with the details (it will look like refinemotion=true)

[tormento]

I mean always_mdegrainn=true, you can use it even with tr=1

it will make the denoise more friendly with the details (it will look like refinemotion=true)

Ok but I can't really understand why now tr=6 gives so bad results...

[Motenai Yoda]

@real.finder IIRC there was a bug in smdegrain when chroma = something and plane = something (maybe about prefilter???) I sent an mp about the fix to dogway some time ago but IIRC he didn't applied it

[real.finder]

@real.finder IIRC there was a bug in smdegrain when chroma = something and plane = something (maybe about prefilter???) I sent an mp about the fix to dogway some time ago but IIRC he didn't applied it

I think you mean this http://forum.doom9.org/showthread.php?p=1779900#post1779900

[Motenai Yoda]

IIRC was something of smdegrain itself,

what about using a prefilter clip and chroma=false?
087
Chr2 = chroma ? 3 : IsClip(prefilter) ? 1 : (prefilter == 3 ? 2 : 1)

... looks like was fixed in the end.

[Groucho2004]

pinterf, you mentioned that your version was forked from 2.6.0.5 and that you did not touch the code that interfaced with avstp.dll. I ran a test to see how it affects the speed.

The simple script:
colorbars(width = 1024, height = 512, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 199)
addgrain(var = 100)
super = MSuper(pel = 2, sharp = 1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap = 4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap = 4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap = 4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap = 4)
MDegrain2(super, backward_vec1, forward_vec1, backward_vec2, forward_vec2, thSAD = 400)


The first run is with a slightly older version of Fizick's mvtools2.dll (2.5.11.3), built by me with VC10:
Frames processed: 200 (0 - 199)
FPS (min | max | average): 7.003 | 13.65 | 7.148
Memory usage (phys | virt): 150 | 149 MiB
Thread count: 1
CPU usage (average): 25%
Efficiency index: 0.2859


Next is with your latest (2.7.6.22):
Frames processed: 200 (0 - 199)
FPS (min | max | average): 5.805 | 11.34 | 5.878
Memory usage (phys | virt): 149 | 148 MiB
Thread count: 1
CPU usage (average): 25%
Efficiency index: 0.2351


And here is yours with avstp.dll present in the auto-load directory:
Frames processed: 200 (0 - 199)
FPS (min | max | average): 8.886 | 28.06 | 14.87
Memory usage (phys | virt): 151 | 149 MiB
Thread count: 4
CPU usage (average): 71%
Efficiency index: 0.2095


I enabled the efficiency index feature in AVSMeter to see how well the plugins use CPU cycles. Your version clearly makes use of avstp but it is rather inefficient. Removing avstp will run the code single-threaded but it's quite a bit slower and less efficient than Fizick's DLL. So, my point is - Perhaps the code that interfaces with avstp causes an overhead and explains the slower operation, even when avstp is not present. Just some food for thought.

[tormento]

Perhaps the code that interfaces with avstp causes an overhead and explains the slower operation, even when avstp is not present. Just some food for thought.
I completely removed avstp and use AviSynth+ MT with way better results. IMHO avstp is almost useless.

[pinterf]

When I will have time, I should check the SAD function selection.
avstp surely has no that much overhead.

[pinterf]

New release. I was trying to give a speed boost for my mod.
MvTools2 2.7.7.22 and Depans (https://github.com/pinterf/mvtools/releases/)


change some 8 bit SAD functions for the better
separating bottleneck 8 bit/16 bit code paths in order not to use slower int64 calculations for 8 bit, where there are no integer overflow problems
more __forceinlines for helping the compiler
general speed gain of 5-15% compared to 2.7.6.22, much reduced speed gap compared to the "classic" YV12 8 bit mvtools2 versions


Groucho2004, thank you for the inspiring speed test, I was using that test script with 8 and 16 block sizes, avsmeters were burning hard :)

[StainlessS]

You be a star Pinterf, Thanx :)

[Groucho2004]

New release. I was trying to give a speed boost for my mod.
MvTools2 2.7.7.22 and Depans (https://github.com/pinterf/mvtools/releases/)
It's a bit faster, ~6.5 fps with the same test as above.

[real.finder]

Fizick MVTools v2.5.11.22 -> ~5.0 fps

pinterf MvTools2 2.7.6.22 -> ~4.3 fps

Firesledge MvTools 2.6.0.5 -> ~4.85 fps

pinterf MvTools2 2.7.7.22 -> ~4.79 fps

pinterf mvtools2 2.7.0.22d -> ~4.31 fps

pinterf MvTools2 2.7.5.22d -> ~3.9 fps

[real.finder]

MSuper is broken after mvtools2_2.7.0.22d (mvtools2_2.7.0.22d was fine)

ex:-


ColorBars(width=640, height=480, pixel_type="YUY2")
MSuper(sharp=1)


will gave access violation reading 0x176A9000

[pinterf]

Thank you for the report

New release:
MvTools2 2.7.8.22 + Depan + DepanEstimate (https://github.com/pinterf/mvtools/releases/tag/2.7.8.22)


fix: YUY2 input (MvTools, DepanStabilize) - regression after 2.7.0.22d
fix: YUY2 freeze at script exit.
MDegrain YUY2 plane deallocation fix. This bug is present in MDegrain3 in the original 2.5.11.22.
Helper YUY2 planes were freed up even if not allocated.

[Reel.Deel]

Pinterf, regarding speed have you included the changes from SVP's MVTools? IIRC correctly, jackoneil included this change in his VS version.

A while back I did some speed test with different versions of MVTools. Results were similar to Keiyakusha's; MVTools from SVP (http://svp-team.com/wiki/Plugins:_MVTools2) is faster than the rest. On their website they claim MAnalyze to be faster. Maybe jackoneill can include this difference?



MAnalyse
Can be faster than original version (with chroma=true) by 20-40%, look at PlaneOfBlocks.h for changes.

A DL link in longer on their website so here it is: mvtools-2.5.11.9-svp.zip (https://web-beta.archive.org/web/20150829061844/http://www.svp-team.com/files/gpl/mvtools-2.5.11.9-svp.zip)

[pinterf]

Pinterf, regarding speed have you included the changes from SVP's MVTools? IIRC correctly, jackoneil included this change in his VS version.



A DL link in longer on their website so here it is: mvtools-2.5.11.9-svp.zip (https://web-beta.archive.org/web/20150829061844/http://www.svp-team.com/files/gpl/mvtools-2.5.11.9-svp.zip)
Yes, it smartly shortcuts the limit check. Here cost is sum of MotionDistortion, luma SAD and chroma SAD. The fast version is checking a limit after each component, and not after summing up all the three. E.g. if cost is already over the limit after having luma SAD, it does not call SAD for chroma.

[pinterf]

I mean yes, I have checked now.
But no, I have not integrated. But I will, thanks

[pinterf]

New build
MvTools2 2.7.9.22 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.9.22)
New: much faster analysis when choma is involved.
The speed up idea was applied from the 2.5.11.9-svp branch

[StainlessS]

New build

You guys, all of you, thanx so very much. (Pinterf, RD, SVP team, the whole lot of you + some that went un-mentioned) :)

[Sparktank]

You guys, all of you, thanx so very much. (Pinterf, RD, SVP team, the whole lot of you + some that went un-mentioned) :)

^ This!

I cannot imagine a world without this to help interpolating movies. :)

[FranceBB]

New build
MvTools2 2.7.9.22 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.9.22)
New: much faster analysis when choma is involved.
The speed up idea was applied from the 2.5.11.9-svp branch

Thank you! :D