MVTools-pfmod

[pinterf]

Get latest version from here:
MvTools2 with depans, release pages (https://github.com/pinterf/mvtools/releases)

Historical part here:
----

I'd like to announce my first published plugin mod.

mvtools-pfmod 2.7.0.1 (https://github.com/pinterf/mvtools/releases/download/r2.7.0.1/mvtools-2.7.0.1-pfmod.7z)

- based on mvtools 2.6.0.5
- Sorry, no new colorspaces, just v2.6 API
- access violation fixes
- Intel C++ 16 build with Visual Studio 2015
- 32 and 64 bit versions
- works like a charm with latest AVS+ r1828-MT :) (though I didn't have problems with 2.6.0.5)

Background (chain reaction):
- Once I tried to use DepanStabilize on vapoursynth. The reason was that vapoursynth offers 16 bit color depth natively, and I have modified DepanStabilize for using stacked input.
- One day I changed my vapoursynth to 64bit only.
- I realized that DepanStabilize is 32bit only, so I compiled it to 64 bit.
- But VapourSynth did not allow to use old 2.5 AVS API for x64. So I modified DepanStabilize for v2.6 API.
- At that time I had no confidence porting DepanEstimate to x64 (input for DepanStabilize), tried to use MDepan from the native vapoursynth mvtools. But this function was not ported yet.
- Had to go back to use the 64 bit 2.6.0.5 mvtools on VapourSynth, but it was v2.5 API => ported it
- mvtools MDepan did not work, I had freezes. Learned debugging dlls in visual studio. Caught a famous 0xc0000005 in it and happily fixed it. And myrsloik was kind enough to integrate a hack into vs's avscompat module just because of 64-bit avs mdepan.
- Meanwhile my DepanStabilize-mod got YV24 support, and with stacked high bit depth logic, and I was able to stabilize my 10 bit Prores 444 test files! I reached my goal: my 8mm film restoration project is not starting anymore with dropping to 8bit YV12 right in the very first step.
- The mvtools project stalled - I was busy with fixing avs+ mt slowdown - until recently stax76 had problems under Win10 and the existing x64 mvtools2. After some busy nights another access violation was fixed in the x64 part.
- Thus I had a working mvtools2 version, and didn't want to keep it in secret.
- Finally along with my avs+ branch I had to learn how to create git repos, branch, push, as all these git things are new to me.

So please use this mod with fun.

[Fizick]

Hi, pinterf!

From your readme.md:
Current build as of March 31, 2016:
2.7.0.1 (skipped 2.6.x.x to leave numbering space to the previous authors)
It is a bug :)
I have small update to original MVTools . And versioning is confusing now. 2.6.x.x is not appropriate for me (it is without Firesledge's additions). May be will use 2.5.11.10,...

P.S. I also have bad 8mm films for restoration.

[Motenai Yoda]

as I remember with overlap = blksize/4 the last rows or coloumns are unfiltered , at least, by mdegrainX
are you planning to fix this?

ps I have 2.6.0.5 version

[pinterf]

I have small update to original MVTools . And versioning is confusing now. 2.6.x.x is not appropriate for me (it is without Firesledge's additions). May be will use 2.5.11.10,...

P.S. I also have bad 8mm films for restoration.
Restoration project never ends, mine is not even started, always waiting to the best workflow, testing new scripts, re-scan some originals in every two years hoping for the better, ehh, too much time.
But you are back here. Good. :)

Anyway, that's what I don't like, billions of versions doing almost the same, one fixing this, other's version fixes that, my version fixed some other things. And now it seems that I missed some other (quality) fixes, as Motenai Yoda noticed?

[Overdrive80]

as I remember with overlap = blksize/4 the last rows or coloumns are unfiltered , at least, by mdegrainX
are you planning to fix this?

ps I have 2.6.0.5 version

For this, didnt it use int "hpad", int "vpad" of Msuper? I dont remember very fine.

[Motenai Yoda]

For this, didnt it use int "hpad", int "vpad" of Msuper? I dont remember very fine.

I didn't investigate too much, as I tried with 16/4 or 32/8 it needs mod64 res...
but I see the same even with overlap=blksize/2, just difference in how many rows or coloumns are unfiltered.

Maybe it's some rounding stuff

[pinterf]

New mvtools2 version on the horizon.
Update: merged with Fizick's 2.5.11.22 version.
More info in the first post.

Download mvtools2 2.7.0.22 for 32 and 64 bit (https://github.com/pinterf/mvtools/releases/download/r2.7.0.22/mvtools2-2.7.0.22.7z)

[jpsdr]

Out of curiosity i take a qucik look at the asm code, and i've noticed a possible issue in this :

%macro RB2CubicHorizontalInplaceLine_SSE_macro 3 ; weight1, weight2, shift
[endprolog]
xchg rdx, rcx ; pSrc, nWidthMMX
; mov rdx, pSrc
; mov rcx, nWidthMMX
; prepare constants
pcmpeqw mm7, mm7 ; = FFFFFFFFFFFFFFFF
pxor mm6, mm6 ; =0
psubw mm6, mm7 ; =1
psllw mm6, %3-1; 4 ; *16 = 16

pxor mm7, mm7 ; =0

pcmpeqw mm5, mm5 ; = FFFFFFFFFFFFFFFF
psrlw mm5, 8 ; /256 = 00FF00FF00FF00FF
mov eax, %1; 05
movd mm4, eax
pshufw mm4, mm4, 0

mov eax, %2; 10
movd mm3, eax
pshufw mm3, mm3, 0


mov eax, 1 ; very first (left) is skipped

.loopw:
cmp eax, ecx
jge .finish

movq mm0, [rdx+rax*2-2]


In your code, you allways use only eax, never fully clear rax, put 1 in eax and not rax, and suddenly use rax. Is it safe ? Can't something be left in the up 32 part when you suddenly use rax ? Personnaly, i should have put "mov rax,1" instead.
Didn't look all the code, so don't know if there is "issues" like this elsewhere.

[pinterf]

Possibly not if the prolog really dont nullify it. Already fixed one or two such cases where I had to deal with the code but haven't checked all asm codes.

[bcn_246]

After Fizick updated mvtools to 2.5.11.22 and fixed some issues (e.g. green artifacts in MFlowInter), I made a new merge with 2.6.0.5 that still works in both 32 and 64 bit.

Download mvtools2 2.7.0.22 for 32 and 64 bit (20160429) (https://github.com/pinterf/mvtools/releases/download/r2.7.0.22/mvtools2-2.7.0.22.7z)

After it survived a full night QTGMC("Slow") 100-thread stress test under Avisynth+ 64bit (r1849), I decided to publish it.
Please give it a try.

----
I'd like to announce my first published plugin mod.

mvtools-pfmod 2.7.0.1 (https://github.com/pinterf/mvtools/releases/download/r2.7.0.1/mvtools-2.7.0.1-pfmod.7z)

- based on mvtools 2.6.0.5
- Sorry, no new colorspaces, just v2.6 API
- access violation fixes
- Intel C++ 16 build with Visual Studio 2015
- 32 and 64 bit versions
- works like a charm with latest AVS+ r1828-MT :) (though I didn't have problems with 2.6.0.5)

Background (chain reaction):
- Once I tried to use DepanStabilize on vapoursynth. The reason was that vapoursynth offers 16 bit color depth natively, and I have modified DepanStabilize for using stacked input.
- One day I changed my vapoursynth to 64bit only.
- I realized that DepanStabilize is 32bit only, so I compiled it to 64 bit.
- But VapourSynth did not allow to use old 2.5 AVS API for x64. So I modified DepanStabilize for v2.6 API.
- At that time I had no confidence porting DepanEstimate to x64 (input for DepanStabilize), tried to use MDepan from the native vapoursynth mvtools. But this function was not ported yet.
- Had to go back to use the 64 bit 2.6.0.5 mvtools on VapourSynth, but it was v2.5 API => ported it
- mvtools MDepan did not work, I had freezes. Learned debugging dlls in visual studio. Caught a famous 0xc0000005 in it and happily fixed it. And myrsloik was kind enough to integrate a hack into vs's avscompat module just because of 64-bit avs mdepan.
- Meanwhile my DepanStabilize-mod got YV24 support, and with stacked high bit depth logic, and I was able to stabilize my 10 bit Prores 444 test files! I reached my goal: my 8mm film restoration project is not starting anymore with dropping to 8bit YV12 right in the very first step.
- The mvtools project stalled - I was busy with fixing avs+ mt slowdown - until recently stax76 had problems under Win10 and the existing x64 mvtools2. After some busy nights another access violation was fixed in the x64 part.
- Thus I had a working mvtools2 version, and didn't want to keep it in secret.
- Finally along with my avs+ branch I had to learn how to create git repos, branch, push, as all these git things are new to me.

So please use this mod with fun.
Thanks, can also confirm this works with the Dither package.

[GMJCZP]

Thanks for the contribution, but not working in WXP SP3. Again, VS2015 is the guilty.

[pinterf]

First post links to the package containing an additional XP-win32 build.

Due to problems of Intel compiler with xp toolsets, XP builds temporarily need VS2015, so I cannot provide x64 build for XP now.

[GMJCZP]

It works, thanks!
Without AvsMeter, I noted that this build is more slow that Fizick and cretindesalpes versions. It's weird.

[pinterf]

Yes, weird. What is your processor?
I compiled the XP version with the simplest /arch:SSE.
And I suppose the built-in asms are working the same way.

I checked the x86 versions with avsmeter on my standard qtgmc(fast) script.
2.6.0.5 (cretindesalpes): 101 fps
2.7.0.22: 104-105 fps (practically head by head the non-XP: Intel 2017beta, and XP:VS2015 builds)
Fizick's one did not run as Mdegrain1 does not have a named argument "lsb".

[GMJCZP]

I have C2D E4400 and I use AVisynth sET MT. For accident the tests have been with MT mode deactivated.

[BakaProxy]

Idk if this has already been asked and/or answered but is it possible to use mvtools in mt? Uhh more like whenever I use mdegrain (and the vectors that come allong) cpu utilization is rather low, some scenarios even only 20%. I've tried every mt mode with mvtools but it either completely freezes the encode or it doesn't change anything performance wise. Prefetch amounts don't change anything as well, it just takes longer to start with large amounts.

Verstuurd vanaf mijn SM-A500FU met Tapatalk

[pinterf]

I don't know if it helps, but you could try avstp (http://forum.doom9.org/showthread.php?t=164407). In the original 2.6.0.5 it worked and hopefully I did not ruin it.

[bilditup1]

I don't know if it helps, but you could try avstp (http://forum.doom9.org/showthread.php?t=164407). In the original 2.6.0.5 it worked and hopefully I did not ruin it.

I have successfully used your build with avstp 1.0.3 and AviSynth 2.6.1 alpha. This appears to provide a speed bump of 25% (6fps --> 7.44fps) when used with a 4770K@4.5Ghz on an MPEG2 1080i30 source run through QTGMC with Fast preset and divisor = 2 followed by a Spline36Resize to SD (640x360). Not sure whether this is good or bad performance for QTGMC with your MvTools and avstp. Usage does not get higher than 33%...but at least it's stable and unfinicky, unlike AVS MT.

[Groucho2004]

@pinterf
mvtools2 and some other of Fizick's plugins insists on (delay-) loading "fftw3.dll". The FFTW distributables however are named "libfftw3f-3.dll". In order to avoid renaming and user confusion I suggest adding the code in blue:
hinstLib = LoadLibrary("fftw3.dll"); // delayed loading
if (hinstLib == NULL)
hinstLib = LoadLibrary("libfftw3f-3.dll");

[pinterf]

Thank you, done.
I've already done it in DepanEstimate (work still in progress)

[yup]

pinterf!
I am testing Your MVTools under Avisynth+ 64 bit and find strange behaviour during using QTGMC, when try dct=5 I see wrong motion estimation, other dct 1,2,3, 4 work normally.
yup.

[GMJCZP]

Without AvsMeter, I noted that this build is more slow that Fizick and cretindesalpes versions. It's weird.

What happened with that?

[pinterf]

What happened with that?
Could not reproduce, for me, it was faster in a qtgmc process. But I don't know what kind of script you are using.
What numbers (fps) did you see without and with avsmeter on the different mvtools versions?

[pinterf]

pinterf!
I am testing Your MVTools under Avisynth+ 64 bit and find strange behaviour during using QTGMC, when try dct=5 I see wrong motion estimation, other dct 1,2,3, 4 work normally.
yup.
Is it only the x64 version or 32 bit, too?
If both versions share the problem, unfortunately it must be in the deepness of the original code, would be very hard for me to dig into it.
And if it is reproducible also with Fizick's version, we should ask him.
Nevertheless, I will try it when I have time; bwt, is it hard to recognize, or I will see an obvious garbage?

[GMJCZP]

Test results only with AvsMeter:

Log file created with: AVSMeter 2.2.8 (x86)

[Clip info]
File.avi
Number of frames: 2447
Length (hh:mm:ss.ms): 00:01:21.656
Frame width: 512
Frame height: 384
Framerate: 29.967 (100000/3337)
Colorspace: YV12
Active MT Mode: 0
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

[Script]
function PreF_MDeGrain(clip src, int "radius", int "P_thSAD")
{

radius = default(radius, 2)
P_thSAD = default(P_thSAD, 400)

preNR = src.frfun3b(s=8,T=2,tuv=7)

preNR_super = preNR.MSuper(pel=2, sharp=1)
src_super = src.MSuper(pel=2, sharp=1, levels=1)

backward_vec3 = MAnalyse(preNR_super, isb = true, delta = 3, overlap=4)
backward_vec2 = MAnalyse(preNR_super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(preNR_super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(preNR_super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(preNR_super, isb = false, delta = 2, overlap=4)
forward_vec3 = MAnalyse(preNR_super, isb = false, delta = 3, overlap=4)

radius >= 3 ? src.MDegrain3(src_super, backward_vec1, forward_vec1, backward_vec2, forward_vec2, backward_vec3, forward_vec3, thSAD=P_thSAD) : \
radius == 2 ? src.MDegrain2(src_super, backward_vec1, forward_vec1, backward_vec2, forward_vec2, thSAD=P_thSAD) : \
src.MDegrain1(src_super, backward_vec1, forward_vec1, thSAD=P_thSAD)
}

[Results]

MVTools 2.7.0.22 XP (pinterf):

[Runtime info]
Frames processed: 2447 (0 - 2446)
FPS (min | max | average): 4.663 | 10.79 | 5.337
Memory usage (phys | virt): 368 | 364 MiB
Thread count: 1
CPU usage (average): 50%
Time (elapsed): 00:07:38.488

MVTools 2.6.0.5 (cretindesalpes):

[Runtime info]
Frames processed: 2447 (0 - 2446)
FPS (min | max | average): 4.372 | 12.48 | 6.170
Memory usage (phys | virt): 367 | 364 MiB
Thread count: 1
CPU usage (average): 50%
Time (elapsed): 00:06:36.585

MVTools 2.5.11.22 (Fizick):

[Runtime info]
Frames processed: 2447 (0 - 2446)
FPS (min | max | average): 5.836 | 14.11 | 6.548
Memory usage (phys | virt): 364 | 362 MiB
Thread count: 1
CPU usage (average): 50%
Time (elapsed): 00:06:13.685

[Groucho2004]

@GMJCZP
The script is incomplete. It seems you cut arbitrary parts out of the log file.
If you want us to try and reproduce it you'll have to post the entire script.

[GMJCZP]

@GMJCZP
The script is incomplete. It seems you cut arbitrary parts out of the log file.
If you want us to try and reproduce it you'll have to post the entire script.

Do you mean include performance data?

[Groucho2004]

Do you mean include performance data?
No, the full script.

[GMJCZP]

Here:

[Script]

# PLUGINS
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\avstimerf.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\Decomb521VFR1.3_PPro-P3.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\mt_masktools-26.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\TIVTC.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\masktools.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\dither.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\Deen_beta.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\EEDI2_imp.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\deblock.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\Tnlmeans.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\dfttest.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\nnedi3.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\RemoveGrain.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\RemoveGrainTSSE3.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\KNLMeansCL.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\yadifmod2.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\nnedi2.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\RemoveDirtSSE2.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\WarpSharp.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\aWarpSharp2.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\nnedi.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\nnedi2.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\asharp.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\awarpsharp.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\Average.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\TcannyMod.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\DeFlicker.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\ChromaShift.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\gradfun2db.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\cnr2.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\mvtools2.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\unfilter.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\ColorMatrix.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\frfun3b.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\fft3dfilter.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\ReduceFlickerSSE3.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\Toon-v1.1.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\DctFilter.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\Repair.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\RepairTSSE2.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\tdeint.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\TBilateral.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\tmm.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\sangnom.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\undot.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\vinverse.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\VagueDenoiser.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\SSIQ.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\MVTools.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\DeGrainMedian.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\FillMargins.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\MSharpen.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\mipsmooth.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\VSFilter.dll")
#LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\DeDup.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\autoadjust.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\VerticalCleanerSSE3.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\AviSynthPlugins\Convolution3DYV12.dll")



import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\Sharpening\SeeSaw\SeeSaw.avs"
import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\Sharpening\FastLineDarken\FastLineDarkenMod.avsi")
import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\Correccion color\YLevels\YLevels_mt.avsi")
import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\Fix Chroma\ChromaShift_SP\ChromaShift_SP.avs")
import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\DeBanding\Dither\dither.avsi")
import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\DeBanding\Dither\mt_xxpand_multi.avsi")
import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\Compresion de videos\SPresso.avsi")
import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\Restauracion de frames\Imagenes en Avisynth\RescueFrame.avsi")
import("D:\Tipos de archivo de audio y video\Avi\Herramientas Avi\AviSynth\Scripts\John Meyer MVDeGrain\PreF_MDeGrain.avsi")


avisource("File.avi",audio=false)

PreF_MDeGrain()

[pinterf]

That is quite a big difference, worth the inspection

[Groucho2004]

That is quite a big difference, worth the inspection
I'm getting very similar results, different source but the trend is the same:
MVTools 2.7.0.22 XP (pinterf):

[Runtime info]
Frames processed: 200 (0 - 199)
FPS (min | max | average): 3.139 | 4.879 | 3.190
Memory usage (phys | virt): 360 | 357 MiB
Thread count: 2
CPU usage (average): 25%
Time (elapsed): 00:01:02.687

MVTools 2.6.0.5 (cretindesalpes):

[Runtime info]
Frames processed: 200 (0 - 199)
FPS (min | max | average): 3.625 | 5.432 | 3.688
Memory usage (phys | virt): 353 | 350 MiB
Thread count: 2
CPU usage (average): 25%
Time (elapsed): 00:00:54.227

MVTools 2.5.11.22 (Fizick):

[Runtime info]
Frames processed: 200 (0 - 199)
FPS (min | max | average): 3.494 | 5.718 | 3.938
Memory usage (phys | virt): 380 | 378 MiB
Thread count: 2
CPU usage (average): 25%
Time (elapsed): 00:00:50.791

[pinterf]

I wonder if its only the xp build that is slow?

[yup]

pinterf
Is it only the x64 version or 32 bit, too?
If both versions share the problem, unfortunately it must be in the deepness of the original code, would be very hard for me to dig into it.
And if it is reproducible also with Fizick's version, we should ask him.
Nevertheless, I will try it when I have time; bwt, is it hard to recognize, or I will see an obvious garbage?
Avisynt+ 32 bit ant Your version MVTools work without problem.
Testing script
SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
AVISource("samplevhs.avi")
AssumeTFF()
QTGMC(dct=5)
Prefetch(8)
sample video https://www.dropbox.com/s/5exreq9j9e0r0hs/test.avi?dl=0
yup.

[pinterf]

SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
AVISource("samplevhs.avi")
AssumeTFF()
QTGMC(dct=5)

sample video https://www.dropbox.com/s/5exreq9j9e0r0hs/test.avi?dl=0
yup.
Nasty bug. But reproducible. So far that's all.
Something within MVAnalyze is broken on x64.
This modification works:
QTGMC(/*Preset="Slower",*/dct=5, ChromaMotion=false)

[yup]

pinterf!
Yes, it is work
chromamotion=false
I am using this option for my VHS capture video.
yup.

[pinterf]

Dear users, 2016 is a lucky year, MvTools2 finally got YUV 4:2:2 and 4:4:4 support (YV16 and YV24).

See source and binaries here:
MVTools2 2.7.0.22c (https://github.com/pinterf/mvtools/releases/tag/r2.7.0.22c)

Please try this *test* build, which works for me with my usual scripts and YV16 gives identical output as with the former YUY2 format.

No need hacking YUY2 sources any more to special planar format and back, convert your source once to YV16 and process it.

P.S.
Could not try it with SMDegrain.avsi, because the script internally assumes YV12 for planar YUV format. BTW the script is full with YUY2 conversion, maybe it can be lighter, too.

[yup]

pinterf!
:thanks:
Work with QTGM without problems, practically at same speed like YV12.
yup.

[Reel.Deel]

Very nice. Thank you pinterf! :)


No need hacking YUY2 sources any more to special planar format and back, convert your source once to YV16 and process it.

P.S.
Could not try it with SMDegrain.avsi, because the script internally assumes YV12 for planar YUV format. BTW the script is full with YUY2 conversion, maybe it can be lighter, too.

Yes, both QTGMC and SMDegrain are quite bloated due to the planar YUY2 hack. A while back I started modding QTGMC to remove the hack, I never finished but MVTools supporting YV16 makes it a lot easier.

[GMJCZP]

Hi pinterf, and Windows XP problem?
Anyway thank you for your effort.

[pinterf]

Did you try it?

[feisty2]

Hi pinterf, and Windows XP problem?
Anyway thank you for your effort.

just drop xp already, turn to Linux if you dislike windows10 or windows7

[tormento]

Very nice. Thank you pinterf! :)



Yes, both QTGMC and SMDegrain are quite bloated due to the planar YUY2 hack. A while back I started modding QTGMC to remove the hack, I never finished but MVTools supporting YV16 makes it a lot easier.

Please make the SMDegrain mod available when finished :)

[Motenai Yoda]

It's an hard work to add y8 and 16bit support too?

[feisty2]

Kind of, some components like SATD were coded in asm and incompatible with high bitdepth, gotta rewrite them completely
And 16bits support is sort of practical still
Floating point support is much harder, not sure if it's possible to implement floating point support and integer support both within a single plugin
vectors are like, int vx, int vy, int sad for both uint8_t and uint16_t
And SAD(sum of absolute differences) for floating point inputs are also floating points obviously, gotta do some reinterpret_cast tricks here

[pinterf]

It's an hard work to add y8 and 16bit support too?

y8 is possibly easy, possibly working with three planes is hardcoded now.

16 bit/float support is hard (=takes time), but even this modding to YV24 took days and was a nightmare.

I have already put high bit depth supporting code here and there and my last internal version has a working MSuper in 16 bits as a first step.

And I think I will not cut the possibility of the float version, just for my curiosity (inspired by feisty2)

[pinterf]

Since 2.7.0.22c I have found 3-4 other use of harcoded div 2 for horizontal subsampling (affects only YV24), but will make a fix only if I have time.
Till then you are still encouraged to test it, of course.

[feisty2]

you're gonna get into the floating point SAD trouble if you do plan to mess with fp support,
I did a nasty reinterpret_cast trick to stuff fp SAD in vectors

static inline auto _fakeint(float a) {
return reinterpret_cast<int32_t &>(a);
}

static inline auto _back2flt(int32_t a) {
return reinterpret_cast<float &>(a);
}

maybe there's a better way to do this, but...

[Motenai Yoda]

Kind of, some components like SATD were coded in asm and incompatible with high bitdepth, gotta rewrite them completely

IIRC both x264 and x265 should yet sports high bitdepth SATD in asm.

[amayra]

can you do something about SVPflow i try to updated but i failed

[Reel.Deel]

Please make the SMDegrain mod available when finished :)

I never said that I was modding SMDegrain. Ask Dogway if he's interested, I'm sure he can do more efficiently since it's his script. A while back I gave him a few suggestions (post 87-89 (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution?p=2409148&viewfull=1#post2409148)) but nothing came of it.

can you do something about SVPflow i try to updated but i failed

Please do not cross-post. SVPflow has nothing to do with this thread.