MVTools-pfmod

[pinterf]

Get latest version from here:
MvTools2 with depans, release pages

Historical part here:
----

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

mvtools-pfmod 2.7.0.1

- 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

[Overdrive80]

Originally Posted by 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

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

[Motenai Yoda]

Originally Posted by Overdrive80

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]

Originally Posted by Fizick

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?

[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

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

Originally Posted by pinterf

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)

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

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

[GMJCZP]

Originally Posted by GMJCZP

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

What happened with that?

[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. In the original 2.6.0.5 it worked and hopefully I did not ruin it.

[bilditup1]

Originally Posted by pinterf

I don't know if it helps, but you could try avstp. 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");