MVTools-pfmod

[tormento]

I never said that I was modding SMDegrain
Oh... I am so sorry.

I confused you with real.finder.

[GMJCZP]

The version 2.7.0.22c not working in XP 32 bits. Access violation.

[pinterf]

Sad. I was compiling them with xp in mind.
One week holday begins, I'll disappear.

[real.finder]

P.S.
Could not try it with SMDegrain.avsi, because the script internally assumes YV12 for planar YUV format.

it didn't

planar = IsYUY2(input) ? true : false

planar in SMDegrain mean YUY2, I was surprised too

so it should work like qtgmc in yv16 and yv24, especially with http://pastebin.com/JtWFN124

[pinterf]

it didn't

planar = IsYUY2(input) ? true : false

planar in SMDegrain mean YUY2, I was surprised too

so it should work like qtgmc in yv16 and yv24, especially with http://pastebin.com/JtWFN124

This modified smdegrain.avsi works!
The old version gave "image heights don't match" when using lsb=true because it assumed the dimensions of YV12 subsampling.

[pinterf]

After-before holiday release for early adopters :)

general: supporting Y8, YV16, YV24 format besides YV12 and YUY2
Some additional fixes for YV24
Allow greyscale input (Y8) - I hope
dct modes >= 5 now use SATD again (so far it was in dead code, contrary to 2.5.13.1 remarks)
fftw 3.3.5 support (changed function names, 3.3.4 still OK), see http://www.fftw.org/download.html
XP support again
compiled to SSE2 with optional SSE4.2 paths

Download: 2.7.0.22d for 32 and 64 bit (20160816) (https://github.com/pinterf/mvtools/releases/tag/r2.7.0.22d)

[Sparktank]

fftw 3.3.5 support

Oh cool, didn't even notice an update for FFTW.
Looking at the Release Notes (http://www.fftw.org/release-notes.html), it's not critical to little old me.

[pinterf]

Oh cool, didn't even notice an update for FFTW.
There are other (http://forum.doom9.org/showthread.php?p=1777186#post1777186) nice topics on doom9 :)

[Sparktank]

There are other (http://forum.doom9.org/showthread.php?p=1777186#post1777186) nice topics on doom9 :)

I'm too far behind to pick up on VS scripting to make regular use of VS.

But, it's good to know that the update is making rounds.
For future reference, I'll make note of it.

[yup]

pinterf!
:thanks:
I see some slowdown for dct=5, approx. 10%.
FFTW updated.
yup.

[pinterf]

pinterf!
:thanks:
I see some slowdown for dct=5, approx. 10%.
FFTW updated.
yup.
Yes, slowdown, because the old one did virtually nothing.

[real.finder]

hi pinterf, since you work on mvtools, dogway said that denoising chroma with luma only vectors is bugged

[pinterf]

Is this bug a new one with yv24? Anyway, some more hint, format, script and parameters would be welcome. Freeze or just garbaged output? I am thankful for each minute I can spare instead of blind guessing.

[real.finder]

Is this bug a new one with yv24? Anyway, some more hint, format, script and parameters would be welcome. Freeze or just garbaged output? I am thankful for each minute I can spare instead of blind guessing.
it's old, dogway write this in SMDegrain

!chroma ? Assert(plane==0, "Denoising chroma with luma only vectors is bugged in mvtools and thus unsupported") : nop()

and here http://forum.doom9.org/showthread.php?p=1551305#post1551305

[pinterf]

Thanks, I will look into it.

[pinterf]

I have run the script you linked
chroma=false
plane=4

super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
bv2=super_search.MAnalyse(isb = true, delta = 2,chroma=chroma)
bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
fv2=super_search.MAnalyse(isb = false, delta = 2,chroma=chroma)
MDegrain2(super_search, bv1, fv1, bv2, fv2, thSAD=200,plane=plane)

but found nothing.

Since I had to deal with the code, did it seriously and unified the MDegrain1/2/3 code for better understanding. It became much more general and a bit faster (at least for MSVC).

As a result of generality: now we have a new MDegrain4 and MDegrain5.

Note that MDegrainN still exists but if there are no special extra SAD parameters, it calls MDegrain1/2/3. No change, it did call them before - but now calls MDegrain4 and MDegrain5 for tr=4 or 5. (Reason by the docs: because they are faster).

Then I became curious whether I can make mvtools co-operate with the latest avs+ dev build, so went on. I had already made MSuper work for 16 bit in the past. The analyzation parts (b and f vectors) still work at 8 bits (haven't ported yet MAnalyze), but MDegrain1/5 can use a 16 bit input and 16 bit super clip and the output is also native 16 bits

a=Avisource("Hi8.avi").assumefps(25,1).trim(0, 499)
a=a.ConvertToYUV444()
sup = a.MSuper(pel=1) #pel=2
fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)
fv3 = sup.MAnalyse(isb=false, delta=3, overlap=4)
bv3 = sup.MAnalyse(isb=true, delta=3, overlap=4)
fv4 = sup.MAnalyse(isb=false, delta=4, overlap=4)
bv4 = sup.MAnalyse(isb=true, delta=4, overlap=4)
fv5 = sup.MAnalyse(isb=false, delta=5, overlap=4)
bv5 = sup.MAnalyse(isb=true, delta=5, overlap=4)
sup16=a.ConvertBits(16).MSuper(pel=1)
a.ConvertBits(16).MDegrain5(Sup16, bv1, fv1, bv2, fv2, bv3, fv3, bv4, fv4, bv5, fv5, thSAD=10000). Info()
ConvertBits(8, dither=0)


Btw, I managed to replace/rewrite the remaining inline asm codes (integer DCT, Resizers, YUY2 converters etc.) for SIMD intrinsics, and now it compiles x64 version in plain VS2015 (+yasm of course)!

And the last info:
Earlier last week I have found some more YV12/YUY specific codes (x/2) in MFlow/MFlowFPS, which may have issues at YV24 in 2.7.0.22d. I hope these occurences were the last ones of this type.

PS: no release, just status report

[tormento]

As a result of generality: now we have a new MDegrain4 and MDegrain5.
We need MDegrain6 too ;)

[pinterf]

Haha, I was just practicing. And you will get a special MDegrain2.718281, too

[tormento]

Haha, I was just practicing. And you will get a special MDegrain2.718281, too

MDegrainE :D

[real.finder]

I have run the script you linked
chroma=false
plane=4

super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
bv2=super_search.MAnalyse(isb = true, delta = 2,chroma=chroma)
bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
fv2=super_search.MAnalyse(isb = false, delta = 2,chroma=chroma)
MDegrain2(super_search, bv1, fv1, bv2, fv2, thSAD=200,plane=plane)

but found nothing.



since dogway didn't come I find sample that has the bug

first, I edit the SMDegrain to accept this case (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution?p=2413356&viewfull=1#post2413356)

the sample http://rgho.st/private/64kh5qQPS/203861da41c6be0a9bc92d8518f840c5

here frame 55 without filter http://i.imgur.com/24VWm23.png

and here with SMDegrain(chroma=false) http://i.imgur.com/fIkzlH1.png

[pinterf]

Ok, here is my script

FFMS2("chroma.mp4")
#ConvertToYUV444()
chroma=false
plane=4 # 0:Luma 1:U 2:V 3:UV 4:All
#ConvertBits(12) #10-16
#super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
super_search=MSuper(chroma=true)

bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
a=MDegrain1(super_search, bv1, fv1, thSAD=0,plane=plane)
b=MDegrain1(super_search, bv1, fv1, thSAD=200,plane=plane)
c=MDegrain1(super_search, bv1, fv1, thSAD=2000,plane=plane)
Stackvertical(a,b,c)#.GreyScale() # bigger thSAD: more "false" blocks but not in greyscale
#MShow(super_search, bv1) #uncomment to see vectors
#super_search #uncomment to see super clip
#ConvertBits(8)


I cannot see bugs here. The big static uniform colored areas make the motion estimation very hard.
Uncomment the MShow line above the see those vectors.

What I also recognized that the blotchy artifacts occur when the luma-only sad is minimal.
Check frame 49, lower right corner. MDegrain is in work, it blends frame #50 into that.
You can check it best at the thSAD=2000 clip. (3rd one if using the above stacked script)
When you uncomment grayscale conversion, it seem to be ok.
I think this kind of clip needs fine-tuning.

[real.finder]

Ok, here is my script

FFMS2("chroma.mp4")
#ConvertToYUV444()
chroma=false
plane=4 # 0:Luma 1:U 2:V 3:UV 4:All
#ConvertBits(12) #10-16
#super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
super_search=MSuper(chroma=true)

bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
a=MDegrain1(super_search, bv1, fv1, thSAD=0,plane=plane)
b=MDegrain1(super_search, bv1, fv1, thSAD=200,plane=plane)
c=MDegrain1(super_search, bv1, fv1, thSAD=2000,plane=plane)
Stackvertical(a,b,c)#.GreyScale() # bigger thSAD: more "false" blocks but not in greyscale
#MShow(super_search, bv1) #uncomment to see vectors
#super_search #uncomment to see super clip
#ConvertBits(8)


I cannot see bugs here. The big static uniform colored areas make the motion estimation very hard.
Uncomment the MShow line above the see those vectors.

What I also recognized that the blotchy artifacts occur when the luma-only sad is minimal.
Check frame 49, lower right corner. MDegrain is in work, it blends frame #50 into that.
You can check it best at the thSAD=2000 clip. (3rd one if using the above stacked script)
When you uncomment grayscale conversion, it seem to be ok.
I think this kind of clip needs fine-tuning.

yes, you right, but the problem is why with chroma=true at the thSAD=200 clip chroma will be good but with chroma=false will be that bad?

[pinterf]

yes, you right, but the problem is why with chroma=true at the thSAD=200 clip chroma will be good but with chroma=false will be that bad?
When you ignore chroma in MAnalyze, the computed SAD (sum of absolute pixel differences between frame blocks (e.g. current, current-1)) will only be computed on luma. If SAD is zero, the blocks are 100% similar.

MDegrain makes its decision on comparing this precomputed sad value (per block) with the given thSAD parameter.

The position of the artifacts is seen exactly at those places where the luma value (check the greyscale clip) is very similar between the compared - e.g. current - next_by_1 - frames.
I think that in this case the SAD of the block (based on luma data only) is well below the given thSAD threshold,thus the blocks are getting blended together. If the difference (SAD) is minimal, then the similar blocks are practically averaged (more or less).

So based only by the luma, it happens that two completely differently colored blocks are merged. Although they differ on the chroma very much, but we asked MAnalyze to ignore it with chroma=false. And we can see the result: one block of the current frame is orange, the next frame contains a blueish grey block at the same place, their luma is similar; the resulting block will look nice in greyscale, but the chroma - and our visual feelings - will be somewhat mixed.

At least this is what I have learned from the code itself and the usage experiences so far.

[real.finder]

When you ignore chroma in MAnalyze, the computed SAD (sum of absolute pixel differences between frame blocks (e.g. current, current-1)) will only be computed on luma. If SAD is zero, the blocks are 100% similar.

MDegrain makes its decision on comparing this precomputed sad value (per block) with the given thSAD parameter.

The position of the artifacts is seen exactly at those places where the luma value (check the greyscale clip) is very similar between the compared - e.g. current - next_by_1 - frames.
I think that in this case the SAD of the block (based on luma data only) is well below the given thSAD threshold,thus the blocks are getting blended together. If the difference (SAD) is minimal, then the similar blocks are practically averaged (more or less).

So based only by the luma, it happens that two completely differently colored blocks are merged. Although they differ on the chroma very much, but we asked MAnalyze to ignore it with chroma=false. And we can see the result: one block of the current frame is orange, the next frame contains a blueish grey block at the same place, their luma is similar; the resulting block will look nice in greyscale, but the chroma - and our visual feelings - will be somewhat mixed.

At least this is what I have learned from the code itself and the usage experiences so far.

I see, so chroma=false without plane=0 is bad idea especially in Anime

maybe with good chosen of Search parameter in MAnalyze will make it better

[pinterf]

After having released the first real test build of high bit depth Avisynth+, here is another release:
MvTools2 2.7.1.22 (https://github.com/pinterf/mvtools/releases/tag/r2.7.1.22)

Important note:
Built with VS2015, this build is 3-8% slower than previous ICC build. Don't use it if you stuck at YV12 or YUY2 clips and this speed loss makes you unhappy.

Changes:

Experimental native 10-16 bit support (MSuper, MAnalyze, MDegrain1-5, MDegrainN)
Some additional fixes for YV24
New: MDegrain4, MDegrain5
16 bit SATD (slow C) for dct>=5 modes and SSE2 optimized regular SAD for 10-16 bits
for 10+ bits you need at least Avisynth+ r2290 but works with classic avs on 8 bits
Inline assembly rewritten to intrinsics -> 64 bit build is possible in VS2015
(External assembly untouched)
Experimental AVX/AVX2 code paths (maybe insignificant, at least I had a test how to mix them together with a non-avx core


Demo script (avs+):
SetMemoryMax(6000)
FFMS2("prores_yuv422p10le_hq_apch_yuv422p10.mov").RemoveAlphaPlane() #if YUVA original
ConvertBits(14)
ConvertToYUV444()
sup = MSuper(pel=1) #pel=2
fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)
fv3 = sup.MAnalyse(isb=false, delta=3, overlap=4)
bv3 = sup.MAnalyse(isb=true, delta=3, overlap=4)
fv4 = sup.MAnalyse(isb=false, delta=4, overlap=4)
bv4 = sup.MAnalyse(isb=true, delta=4, overlap=4)
fv5 = sup.MAnalyse(isb=false, delta=5, overlap=4)
bv5 = sup.MAnalyse(isb=true, delta=5, overlap=4)
MDegrain5(Sup, bv1, fv1, bv2, fv2, bv3, fv3, bv4, fv4, bv5, fv5, thSAD=10000). Info()
ConvertBits(8,dither=0)

[Motenai Yoda]

sure this is right? with ConvertBits(16)
sup = MSuper(pel=1) #pel=2
fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)
MDegrain2(Sup, bv1, fv1, bv2, fv2, thSAD=200)
converttostacked()
b=last

d=Dither_convert_8_to_16()
sup2 = MSuper(pel=1) #pel=2
fv12 = sup2.MAnalyse(isb=false, delta=1, overlap=4)
bv12 = sup2.MAnalyse(isb=true, delta=1, overlap=4)
fv22 = sup2.MAnalyse(isb=false, delta=2, overlap=4)
bv22 = sup2.MAnalyse(isb=true, delta=2, overlap=4)

m=d.dither_get_msb()
supM = m.Msuper(pel=1)

l=d.dither_get_lsb()
supL = l.Msuper(pel=1)

msb=m.MDegrain2(SupM, bv12, fv12, bv22, fv22, thSAD=200,lsb=true)
lsb= l.MDegrain2(SupL, bv12, fv12, bv22, fv22, thSAD=200)

nullclip = l.mt_lut(y=0,u=0,v=0)
diff1=stackvertical(nullclip,lsb)
msb.dither_add16(diff1)
c=last

mt_makediff(b,c,u=3,v=3)
levels(100,1,155,0,255,true)

I get the same lsb part but different msb one, like is applied dithering on msb.
also seems to be slower

[pinterf]

sure this is right? with ConvertBits(16)
sup = MSuper(pel=1) #pel=2
fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)
MDegrain2(Sup, bv1, fv1, bv2, fv2, thSAD=200)
converttostacked()
b=last

d=Dither_convert_8_to_16()
sup2 = MSuper(pel=1) #pel=2
fv12 = sup2.MAnalyse(isb=false, delta=1, overlap=4)
bv12 = sup2.MAnalyse(isb=true, delta=1, overlap=4)
fv22 = sup2.MAnalyse(isb=false, delta=2, overlap=4)
bv22 = sup2.MAnalyse(isb=true, delta=2, overlap=4)

m=d.dither_get_msb()
supM = m.Msuper(pel=1)

l=d.dither_get_lsb()
supL = l.Msuper(pel=1)

msb=m.MDegrain2(SupM, bv12, fv12, bv22, fv22, thSAD=200,lsb=true)
lsb= l.MDegrain2(SupL, bv12, fv12, bv22, fv22, thSAD=200)

nullclip = l.mt_lut(y=0,u=0,v=0)
diff1=stackvertical(nullclip,lsb)
msb.dither_add16(diff1)
c=last

mt_makediff(b,c,u=3,v=3)
levels(100,1,155,0,255,true)

I get the same lsb part but different msb one, like is applied dithering on msb.
also seems to be slower
1.) Is it intentional that the input of the 2nd pass is the stacked 8 bit output of the first 16 bit degrain phase?
2.) Then I don't understand the second part.
You make a d=Dither_convert_8_to_16() from an already stacked clip, and take its lsb that is always zero and filter it, why?
l=d.dither_get_lsb()
supL = l.Msuper(pel=1)
lsb= l.MDegrain2(SupL, bv12, fv12, bv22, fv22, thSAD=200)


My comparison script:

FFMS2("chroma.mp4")#.trim(0, 499)
orig8=last
ConvertBits(16)
sup = MSuper(pel=1) #pel=2
fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)
MDegrain2(Sup, bv1, fv1, bv2, fv2, thSAD=200)
converttostacked()
stackedresult1 =last

orig8
sup2 = MSuper(pel=1) #pel=2
fv12 = sup2.MAnalyse(isb=false, delta=1, overlap=4)
bv12 = sup2.MAnalyse(isb=true, delta=1, overlap=4)
fv22 = sup2.MAnalyse(isb=false, delta=2, overlap=4)
bv22 = sup2.MAnalyse(isb=true, delta=2, overlap=4)
stackedResult2 = orig8.MDegrain2(Sup2, bv12, fv12, bv22, fv22, thSAD=200,lsb=true)

mt_makediff(stackedresult1,stackedresult2,u=3,v=3)
levels(100,1,155,0,255,true)

[Motenai Yoda]

1.) Is it intentional that the input of the 2nd pass is the stacked 8 bit output of the first 16 bit degrain phase?
2.) Then I don't understand the second part.
You make a d=Dither_convert_8_to_16() from an already stacked clip, and take its lsb that is always zero and filter it, why?
1- no it wasn't lol
2- that is the way I use mdegrain on stacked clip, indeed lsb filtered part is all 0 if the input clip's lsb is all 0

btw I found a lot of differences even with your method, in the msb part too...

[pinterf]

1- no it wasn't lol
2- that is the way I use mdegrain on stacked clip, indeed lsb filtered part is all 0 if the input clip's lsb is all 0

btw I found a lot of differences even with your method, in the msb part too...
There's no reason to get identical results.
For 16 bit input, even if the original clip is 8 bits and its straight 16 bit conversion has zero lsb, the lower resolution subclips in Super are already interpolated and have meaningful lsb parts.
So the vectors after MAnalyze are possibly different than it would be estimated from a single 8 bit source.
Then the weighting and blending inside MDegrain works with higher precision than for a 8 bit input. That is a difference, too.

[real.finder]

speaking of MAnalyze, I have an idea in my mind but I don't know if it good or not, or even if I can do it

it's for 8 bit clip, it's by doing convert to yv24 (if it not yv24) then merge Y, U and V in one 16 bit plane (Y16) then use it in MAnalyze to get more accurate motion vectors

and then use the vectors for both luma and chroma

[real.finder]

@pinterf

can you add rgb24 support in MSuper and MAnalyse and MRecalculate?

making the support work as if it one colour not treats it as R G B separately

:thanks:

[feisty2]

RGB sucks
I added RGB support in my branch of mvtools and it didn't work out so well

[StainlessS]

@pinterf

can you add rgb24 support in MSuper and MAnalyse and MRecalculate?

making the support work as if it one colour not treats it as R G B separately

:thanks:

How exactly would one measure differences if implemented as above ?

Would diff in blue count a teeny weeny bit, in green somewhat more, and in red a helluva lot ?

[real.finder]

How exactly would one measure differences if implemented as above ?

Would diff in blue count a teeny weeny bit, in green somewhat more, and in red a helluva lot ?

I didn't get what you mean well but what about convert rgb24 to hex (http://forum.doom9.org/showpost.php?p=1784059&postcount=2499) internally in MAnalyse and MRecalculate?

[StainlessS]

One would have to have some difference measure, eg convert rgb to luma-y, and measure dif in that.
Or rgb color cube distance.
I don't get what you are saying about convert to hex.
Perhaps you should elaborate a little on what you want.

[real.finder]

One would have to have some difference measure, eg convert rgb to luma-y, and measure dif in that.
Or rgb color cube distance.
I don't get what you are saying about convert to hex.
Perhaps you should elaborate a little on what you want.

https://en.wikipedia.org/wiki/Web_colors#Converting_RGB_to_hexadecimal

[pinterf]

Mixing color component together does not help. The base of the whole motion analysis is SAD, pixel values of two frames get subtracted, then we get the absolute value and finally sum them up for 8x8, 16x16, up to 128x128 (vapoursynth mvtools2 port) pixel blocks.
Creating a compound representation of rgb value result us that the component at the lsb side will affect the result for 1/65536 of weight than the component at the msb side 0xff0000 mask (for 8 bits)

[StainlessS]

See here Bug in v2.5.11.2 and v2.5.11.20, and v2.5.11.22. Fixed in v2.7.1.22:- http://forum.doom9.org/showthread.php?t=174025

Also, MvTools2 v2.7.1.22 MBlockFps(Blend=False) and MFlowFps(Blend=False) are broken, creates mangled frames at scene change.

[pinterf]

Hi,

could you please try this test build (overlap fix only), and report back, though the scenechange problem is not intended to be fixed.

http://www.mediafire.com/file/u8pp73pjrcp4v2p/2.7.1.22postForStainless.7z
(test only, not for public)

Edit: what do you mean under "mangled", can you provide a test script and a hint where to look at that behaviour, and also, whether older 2.5.xx or 2.6.0.5 versions behave similarly?

[StainlessS]

Overlap fix seems to work ok.

By Mangled I meant that bad frame was produced, did not seem to be blend or correct behavior when Blend=False, ie duplicate previous frame
(that is End Of Scene Frame) at scene change.

Script testing v2.6.0.5 (frames are so different that synthesized frames should be same as frame prior to them [EDIT: when Blend=false).
EDIT: Result Frames 0, 2 and 4 are the original frames with a scene change between each, frames 1 and 3 are synthesized frames at scene change.

Function DoubleRate(clip c,Bool "Blend",Bool "Flow") {
# Works OK with MvTools2 v2.6.0.5
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow=Default(Flow,False) # If True, Use MFlowFps instead of MBlockFps
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4)
bw_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, searchparam = 1, search = 3) # No Overlap (currently broken for final vectors)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3) # No Overlap
Return (!Flow)
\ ? MBlockFps(super, bw_2, fw_2, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), mode=0, Blend=Blend)
\ : MFlowFps(super, bw_2, fw_2, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend)
}

BLEND=False
FLOW=False
A=Colorbars.Killaudio.ConvertToYV12.Trim(0,-1)
B=A.FlipHorizontal
(A++B++A).ShowFrameNumber
DoubleRate(Blend=BLEND,Flow=FLOW)
BilinearResize(320,240)
I=Last.Blankclip(Height=4)
StackVertical(Trim(0,-1),I,Trim(1,-1),I,Trim(2,-1),I,Trim(3,-1),I,Trim(4,-1))

result
https://s20.postimg.cc/8g734a3y5/Mvt1_zpsnlgewgiq.png (https://postimg.cc/image/drlzozq0p/)

Script testing v2.7.1.22 and working for OverLap and without the previous script MRecalculate to step over the Overlap bug (In actual fact v2.6.0.5 puts
up error OverLap Must be 0, if function creating MBlockFps used vectors, use Overlap>0).


Function DoubleRate(clip c,Bool "Blend",Bool "Flow") {
# for MvTools2 v2.7.1.22 testing
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow=Default(Flow,False) # If True, Use MFlowFps instead of MBlockFps
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4)
bw_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
Return (!Flow)
\ ? MBlockFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), mode=0, Blend=Blend)
\ : MFlowFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend)
}

BLEND=False
FLOW=False
A=Colorbars.Killaudio.ConvertToYV12.Trim(0,-1)
B=A.FlipHorizontal
(A++B++A).ShowFrameNumber
DoubleRate(Blend=BLEND,Flow=FLOW)
BilinearResize(320,240)
I=Last.Blankclip(Height=4)
StackVertical(Trim(0,-1),I,Trim(1,-1),I,Trim(2,-1),I,Trim(3,-1),I,Trim(4,-1))


Result (showing 'Mangled frames')
https://s20.postimg.cc/6po22smf1/Mvt2_zpsjhtxm4sh.png (https://postimg.cc/image/o2ychnhq1/)

You can check the behaviour using 2nd script DoubleRate() and look at any scene change, with Blend=True, should create blend at scene change, if false, then should use copy of End of Scene frame for synthesized frame [EDIT: As in first above result].

Thanks pinterf, looking good. :)

EDIT: I dont know if you saw a previous edit from the Interframe thread, here tis:-

EDIT: The problem seems to occur if OverLap used in creating final BackWards and Forwards vectors supplied to MBlockFps,
ie MAnalyse(Overlap=whatever) if MRecalculate not used, and in final MRecalculate(Overlap=whatever) if used.

This works ok without Overlap in final vectors

Function foo2(clip source, int "multi") {
last = source
multi = default(multi, 2)
prefilt = DeGrainMedian() # some smoothing
superfilt = MSuper(prefilt, hpad=16, vpad=16) # all levels for MAnalyse
super = MSuper(source, pel = 2, hpad = 16, vpad = 16, rfilter = 4) # one level is enough for MRecalculate
bw_1 = MAnalyse(superfilt, chroma = false, isb = true, blksize = 16, OverLap=8, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(superfilt, chroma = false, isb = false, blksize = 16, OverLap=8, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, OverLap=4, searchparam = 1, search = 3)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, OverLap=4,searchparam = 1, search = 3)
bw_3 = MRecalculate(super, chroma = false, bw_2, blksize = 4, searchparam = 0, search = 3) # No Overlap
fw_3 = MRecalculate(super, chroma = false, fw_2, blksize = 4, searchparam = 0, search = 3) # No Overlap
MBlockFps(source, super, bw_3, fw_3, FramerateNumerator(Source) * multi, FramerateDenominator(Source), mode = 0, Blend=False)
return last
}


But think I'll be using this until fixed at least.

Function DoubleRate(clip c,Bool "Blend") {
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
prefilt = DeGrainMedian() # some smoothing
superfilt = MSuper(prefilt, hpad=16, vpad=16, rfilter = 4) # all levels for MAnalyse
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4,levels=1) # one level is enough for MRecalculate
bw_1 = MAnalyse(superfilt, chroma = false, isb = true, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(superfilt, chroma = false, isb = false, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, searchparam = 1, search = 3) # No Overlap (currently broken for final vectors)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3) # No Overlap
MBlockFps(super, bw_2, fw_2, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), mode=0, Blend=Blend)
Return Last
}


EDIT: Ive Added BLEND arg to above two scripts, Default False, here are both results in order with BLEND=True

script 1
https://s20.postimg.cc/rnytembnh/Mvt1_T_zpsem2whf25.png (https://postimg.cc/image/4mi88vbzt/)

script 2 (showing 'Mangled frames')
https://s20.postimg.cc/i5z2ekpz1/Mvt2_T_zpsut3baxg8.png (https://postimg.cc/image/x1xlm61dl/)

EDIT: I've added FLOW=False default to both scripts, so you can also test MFlowFps if set true.

EDIT: I spoke too soon, there seems to be a problem at right and bottom edges on real video, also can be seen on frames 1 and 3
of 2nd results.

Script producing

Function DoubleRate(clip c,Bool "Blend",Bool "Flow") {
# for MvTools2 v2.7.1.22 testing
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow=Default(Flow,False) # If True, Use MFlowFps instead of MBlockFps
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4)
bw_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
Return (!Flow)
\ ? MBlockFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), mode=0, Blend=Blend)
\ : MFlowFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend)
}


AvisourcE("F:\v\StarWars.avi")

DoubleRate
Trim(12744,12746)
LanczosResize(400,224)
StackVertical(Trim(0,-1),Trim(1,-1),Trim(2,-1))


https://s20.postimg.cc/g2on6wq65/tinman_zpszva3otnp.png (https://postimg.cc/image/3o1v6kynt/)

EDIT: Still occurs if adding Crop(4,4,-4,-4) before call to DoubleRate (get rid of any crud, for padding).
EDIT: Still occurs if changing hpad and vpad to 0.
EDIT: And a live video scene change (Blend=false)
https://s20.postimg.cc/h68rivat9/Luke_zpsgeuc6dpt.png (https://postimg.cc/image/5tw613249/)

EDIT: What above looks like using v2.6.0.5 and same script but with script1 DoubeRate(Blend=True), Blend=False (as above)
should produce 2nd frame same as the 1st frame.
https://s20.postimg.cc/w3h8jvo1p/Luke_Blend_zpsqjrprzvo.png (https://postimg.cc/image/oaqkrwi2h/)

[pinterf]

Thanks, don't spend any more time on it, fabuolus error report. Now it's my turn.

[pinterf]

Hi StainlessS!

Try this test build please.
http://www.mediafire.com/file/aako4wx66anwoak/2.7.2.22ForStainlessS.zip

About the bug. er...
Guess what: A /256 was somehow changed into /(8*8) for better readability :). No, it wasn't really me, but the monkeys.

As a side-effect I think I have ported MFlowFPS to native 10-16 bits that can be used with Avisynth+.

[StainlessS]

MBlockFPS, have fixed side green border, but bottom green border remains in synthesized frames where not at scene change,
ie at scene change, synthesized frame is duplicate of previous frame (blend=false), or simple 50.0/50.0 blend (Blend=True),
so just a problem in synthesized frames that are not at scene change.
The Mangled frames at scene change have gone.

MFlowFPS, dont see any problems.

Unfortunately, I made a bob-boo earlier in other 'Compiler Error ???' thread, I said problem was gone (MSCDetection floating point -1.#IND000),
unfortunately, I dont seem to have checked for more than the disappearance of the floating point error, seems that the MSCDetection return clip
never spots a scene change, all frames identical Green, which is I think all YUV channels 0. (Both End of Scene and Start of Scene clips fail).

Below, code snippet to do detections easily yourself, requires no external plugins (EXCEPT of course MVTools2, which I know you have :) ).


FN="F:\v\StarWars.avi"

BLEND= false
FLOW = false

#######################
Avisource(FN)

#Trim(10000,0)

DORG=SelectEvery(1,0,0) # Original Each frame twice
DBL =DoubleRate(Blend=BLEND,Flow=FLOW)

DORG_S = DORG.Sub("Original, Each frame twice",0)
DBL_S = DBL.Sub("Double Rate : Blend="+String(Blend)+" Flow="+String(Flow),1)

Return StackVertical(DORG_S,DBL_S)
#######################

Function DoubleRate(clip c,Bool "Blend",Bool "Flow") {
# for MvTools2 v2.7.1.22 testing
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow=Default(Flow,False) # If True, Use MFlowFps instead of MBlockFps
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4)
bw_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
Return (!Flow)
\ ? MBlockFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend, mode=0)
\ : MFlowFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend)
}

Function Sub(clip c,string tit,int Md) {
Function SubStrLo(int n,string tit,Int Md) {Return string(n)+"] "+tit+(n%2==0?"":Md==0?" (Duplicate)":" (Synthesized)")}
S = "SubTitle(SubStrLo(current_frame,"+Chr(34)+tit+Chr(34)+","+String(Md)+"))"
StackVertical(c.BlankClip(height=20).ScriptClip(S),c)
}


Produces something like below (at scene change, Blend=true [no green bottom border in synth frame at scene change])
https://s20.postimg.cc/jq4ecyyd9/Moons_zpspa6uhpct.png (https://postimg.cc/image/f48a4mcu1/)

EDIT: Above script, you can scrub through whole movie in eg VDubMod and check-out scene changes, and mod BLEND and FLOW
to check other modes.

EDIT: Oops, sorry, above script requires Grunt plugin.

EDIT: Got rid of Grunt() requirement, script updated.

[pinterf]

Hi! Found something, another try

http://www.mediafire.com/file/60o8c43r2cbyi3d/2.7.2.22StainLessS2.zip
Test build, not a release.

The bottom line bug was fixed.

The fixes/additions since 2.7.1.22:
- new: MBlockFPS 10-16 bit
- nSCD2 regression fix
- nSCD1 (thCSD1) scale for 10+ bits
- MBlockFPS: overlaps working buffers were not copied to the output.
- MBlockFPS: overlaps: Right columns were ok for the luma only.
- MBlockFPS: overlaps: Blend of bottom rows were operating on somewhere the top rows instead of the last row.

There are still visible differences on the edges, because right and bottom lines are simply blended when we use overlaps, but this is the way it works.

[StainlessS]

There are still visible differences on the edges, because right and bottom lines are simply blended when we use overlaps, but this is the way it works.

Oh dear, wish you had not told me that, I'll be forever looking for it now :)

https://s20.postimg.cc/mlhhju2d9/Olap8_zpsbrsjy3u5.png (https://postimg.cc/image/6n8rtp855/)

Script, no requirements.

FN="F:\v\StarWars.avi"

BLEND= false
FLOW = false

#######################
Avisource(FN)

DORG = SelectEvery(1,0,0) # Original Each frame twice
DBLA = DoubleRateA(Blend=BLEND,Flow=FLOW)
DBLB = DoubleRateB(Blend=BLEND,Flow=FLOW)
DBLC = DoubleRateC(Blend=BLEND,Flow=FLOW)

DORG_S = DORG.Sub("Original, Each frame twice",0)
DBLA_S = DBLA.Sub("DoubleRate_A(OLap=0) : Blend="+String(Blend)+" Flow="+String(Flow),1)
DBLB_S = DBLB.Sub("DoubleRate_B(NEW, Olap=8) : Blend="+String(Blend)+" Flow="+String(Flow),1)
DBLC_S = DBLC.Sub("DoubleRate_C(MRecalc, Olap=8): Blend="+String(Blend)+" Flow="+String(Flow),1)

H = DORG_S.Blankclip(Height=4,color=$FFFFFF)
LFT = StackVertical(DORG_S,H,DBLB_S)
RGT = StackVertical(DBLA_S,H,DBLC_S)
V = LFT.Blankclip(Width=4,color=$FFFFFF)

Return StackHorizontal(LFT,V,RGT) #.trim(48115,0)
#######################

Function DoubleRateA(clip c,Bool "Blend",Bool "Flow") {
# Overlap = 0
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow=Default(Flow,False) # If True, Use MFlowFps instead of MBlockFps
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4)
bw_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, OverLap=0, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, OverLap=0, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
Return (!Flow)
\ ? MBlockFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend, mode=0)
\ : MFlowFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend)
}


Function DoubleRateB(clip c,Bool "Blend",Bool "Flow") {
# for MvTools2 v2.7.1.22 testing
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow=Default(Flow,False) # If True, Use MFlowFps instead of MBlockFps
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4)
bw_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, OverLap=8, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, OverLap=8, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
Return (!Flow)
\ ? MBlockFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend, mode=0)
\ : MFlowFps(super, bw_1, fw_1, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend)
}

Function DoubleRateC(clip c,Bool "Blend",Bool "Flow") {
# Works OK with MvTools2 v2.6.0.5
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow=Default(Flow,False) # If True, Use MFlowFps instead of MBlockFps
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4)
bw_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, OverLap=8, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, OverLap=8, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, searchparam = 1, search = 3) # No Overlap (currently broken for final vectors)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3) # No Overlap
Return (!Flow)
\ ? MBlockFps(super,bw_2, fw_2, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend, mode=0)
\ : MFlowFps(super, bw_2, fw_2, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), Blend=Blend)
}

Function Sub(clip c,string tit,int Md) {
Function SubStrLo(int n,string tit,Int Md) {Return string(n)+"] "+tit+(n%2==0?"":Md==0?" (Duplicate)":" (Synthesized)")}
S = "SubTitle(SubStrLo(current_frame,"+Chr(34)+tit+Chr(34)+","+String(Md)+"))"
StackVertical(c.BlankClip(height=20).ScriptClip(S),c)
}

Shows Synthesized frame, not at scene change, motion coming in from RHS.
TopLeft, original frames, every other one a duplicate,
Top Right, Overlap=0,
Bot Left, New version MvTools, Overlap=8
Bot Right, Old, Overlap=8, with MRecalculate.

All seems to be working OK, for block/Flow/FPS.

Script to show problem in MSCDetection, no requrements.


FN="LowBitrateAnime.AVI"
Avisource(FN)

Function EndOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at EOS
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
bv=sup.MAnalyse(isb=true, delta=1,blksize=16,overlap=8)
Return c.MSCDetection(bv,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function StartOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at SOS
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
fv=sup.MAnalyse(isb=false,delta=1,blksize=16,overlap=8)
Return c.MSCDetection(fv,thSCD1=thSCD1,thSCD2=thSCD2)
}

EOS = EndOfSceneClip
SOS = StartOfSceneClip
#return EOS
SSS="""
e = EOS.AverageLuma
s = SOS.AverageLuma
Subtitle(String(current_frame)+String(e,"] EOS=%.1f")+String(s," : SOS=%.1f"))
(e!=0.0)
\ ? Subtitle("End Of Scene",Size=48,Text_Color=$FF0000,Y=Height/2-24,Align=5)
\ : (s!=0.0) ? Subtitle("Start Of Scene",Size=48,Text_Color=$0000FF,Y=Height/2+24,Align=5)
\ : NOP
return last
"""

Scriptclip(SSS)


We are nearly there :)

EDIT: Oh damn, meant to put the MBlockFPS example up on PhotoBucket instead of MFlowFPS, arh well done now.

EDIT: MBlockFPS version
http://i1136.photobucket.com/albums/n494/StainlessStephen/BlkOlap8_zpsa5wve3uc.png
EDIT: Above image lost due to Photobucket problem.

EDIT: The Blending mentioned in the quote at top of post is shown on Right Hand Edge of lower two (Overlap) images in
both image sets (dark edge, sourced from next image coming from rhs).

[pinterf]

I'm not saying I'm ready, this is just a new test build inspired by StainlessS :)

http://www.mediafire.com/file/k78dcmzft746kv1/2.7.3.22StainlessS4.zip

There were side effects again, ported some more mvtools2 filters to native 10-16 bits and fixed some bugs.

Recent change log

20161117: MFlow, MFlowInter, MFlowBlur: native 10-16 bits
20161117: MSCDetection: fix scene change filler pixel default value
20161117: MFlowFPS: native 10-16 bit
20161117: MCompensate: native 10-16 bit + possible bugfix bottom padding UV
20161117: Fix SAD for 10-16 bit depths for horizontal block sizes >= 16
20161116: MBlockFPS: Additional overlap fixes (bottom lines)
20161116: MBlockFPS: native 10-16 bit with Avisynth plus
20161116: MBlockFPS: additional overlap fix (Right)
20161115: Fix nSCD2 (Scene change threshold block count %) (2.7.1.22 regression)
20161114: MBlockFPS overlap fix test build (copy buffer to output)


Short status report on the 8+ bit transition:
MShow, MDepan are not yet ported to 10-16 bits. You can try the others, e.g. MDegrains for 10+ bits with Avisynth plus.

EDIT: MFlow, MFlowInter, MFlowBlur ported, removed from the non-16 bit list.

And of course you can freely use 4:2:2 and 4:4:4 formats.
(like YV16 and YV24)

[StainlessS]

Thanks pinterf, everything seems hunky dory,
I'll continue to use this version and report if I find any anomalies, again thanx.

EDIT: I'll probably be using something like below

Function ChangeFrameRate(clip c,Bool "Blend",Bool "Flow",Int "Num",Int "Den",Int "BlkSize",Int "OverLap") {
# Req MvTools2 v2.7.1.22+ for Overlap>0
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow=Default(Flow,False) # If True, Use MFlowFps instead of MBlockFps
BlkSize=Default(BlkSize,16) Overlap=Default(Overlap,BlkSize/2)
n=Default(num,0) d=default(den,0) valid=(n>0 && d>0) n=(!valid)?c.FramerateNumerator*2:n d=(!valid)?c.FramerateDenominator:d # Default = doublerate
super = c.MSuper(pel=2, hpad=BlkSize, vpad=BlkSize,rfilter=4)
bv = MAnalyse(super, chroma=false, isb=true, blksize=BlkSize, OverLap=OverLap, searchparam=3, plevel=0, search=3, badrange=(-24))
fv = MAnalyse(super, chroma=false, isb=false, blksize=BlkSize, OverLap=OverLap, searchparam=3, plevel=0, search=3, badrange=(-24))
Return (!Flow)
\ ? c.MBlockFps(super, bv, fv, num=n, den=d, Blend=Blend, mode=0)
\ : c.MFlowFps(super, bv, fv, num=n, den=d, Blend=Blend)
}

Function DoubleRate(clip c,Bool "Blend",Bool "Flow") {Return c.ChangeFrameRate(Blend,Flow,c.FramerateNumerator*2,c.FramerateDenominator)}

[pinterf]

Thanks, StainlessS, you were excellent, first class tester. You really deserve a new mvtools3 that can realtime interpolate the two suns of tatooine on a ZX81.
But until then I will just bump the version numbers and make a release soon.

Good news for me that finally I have finished porting the last two filters, MDepan and MShow for high bit depth, and also finished the two other DLLs for video stabilizing with Depan (DepanEstimate) and DepanStabilize.

[pinterf]

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

[Sparktank]

Great work, guys! :goodpost: