InterFrame 2.8.2 - Framedoubling/60FPS/HFR conversion script

[johnmeyer]

It's about the same level as new mvtools.Which "new MVtools" are you referring to? There is a Fizick build in April (v2.5.11.22), but then there is also a "pfmod" version. I haven't updated for awhile and I should probably be using one of these, but which one?

[Reel.Deel]

Cool, where is it? I must have missed that

Here: http://forum.doom9.org/showthread.php?t=166582

Which "new MVtools" are you referring to? There is a Fizick build in April (v2.5.11.22), but then there is also a "pfmod" version. I haven't updated for awhile and I should probably be using one of these, but which one?

He's refering to MVTools from VapourSynth which is essentially the same as Fizicks latest version for AviSynth (minus what was mentioned in post #898 (http://forum.doom9.org/showpost.php?p=1775818&postcount=898)).

There is a Fizick build in April (v2.5.11.22), but then there is also a "pfmod" version. I haven't updated for awhile and I should probably be using one of these, but which one?

The pfmod version includes all of the recent updates from the latest MVTools by Fizick. It also includes all the extra features and functions from cretindesalpes' modified MVTools.

Additional functions: MDegrainN, MRestoreVect, MScaleVect, MStoreVect

Additional features: all of the MDegrain filters can output 16-bit video. The plugin is also internally multi-threaded and can be enabled for those who do not use a multi-threaded AviSynth. Lastly it includes a 64-bit binary which can be used with AviSynth+.

It should be a no brainier on which one to use. :)

[johnmeyer]

It should be a no brainier on which one to use. :)I'll see if I can figure it out. Thanks for the help!!

[amayra]

i try to update SVPflow but i failed can any one do something about it ?

[Magik Mark]

Subjunk,

Thanks for this great script. I just would like to know if you have a version that would work on Avisynth+ via Staxrip?

Tried the script found on the first post and I'm getting initial error of unknown variables in the preset

[amayra]

can use interframe without MeGUI ?

[SubJunk]

can use interframe without MeGUI ?Yeah you can, it's just an AviSynth script. I've also used it with FFmpeg and MEncoder

[urukazuto]

Hello I'm new to this forum and impressive with this interframe. I want to ask how to use Framedoubling using mvtools ? The first page does the explanation of using avisyth + interframe + svplugin.

but how about mvtools? it's usable on avistyh also? or does it only available to vapoursyth?

[StainlessS]

urukazuto, Perhaps you should post in an mvtools thread instead of a 'competitor to mvtools' thread.
Having said that, there does not seem to be an mvtools v2.0 thread in Avisynth Usage (only in Avisynth Development section).

But, you could do worse than to read the examples provided in mvtools v2.0 docs, ie


# To double fps with MFlowFps for 'best' results (but slower processing):
AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
# assume progressive PAL 25 fps or NTSC Film 23.976 source
super = MSuper(pel=2)
backward_vec = MAnalyse(super, overlap=4, isb = true, search=3)
# Use block overlap, halfpixel accuracy and Exhaustive search
forward_vec = MAnalyse(super, overlap=4, isb = false, search=3)
MFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(last), \
den=FramerateDenominator(last))

[Groucho2004]

I like MBlockFPS:

function foo(clip source, int "multi")
{
last = source
multi = default(multi, 2)

super = MSuper(source, pel = 2, hpad = 0, vpad = 0, rfilter = 4)
backward_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
forward_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
backward_2 = MRecalculate(super, chroma = false, backward_1, blksize = 8, searchparam = 1, search = 3)
forward_2 = MRecalculate(super, chroma = false, forward_1, blksize = 8, searchparam = 1, search = 3)
backward_3 = MRecalculate(super, chroma = false, backward_2, blksize = 4, searchparam = 0, search = 3)
forward_3 = MRecalculate(super, chroma = false, forward_2, blksize = 4, searchparam = 0, search = 3)
MBlockFps(source, super, backward_3, forward_3, FramerateNumerator(last) * multi, FramerateDenominator(last), mode = 0)

return last
}

[kolak]

Why do you do 3 times vectors? Does this improves their quality, os over all quality?
Can I use it with flowfps?

[StainlessS]

Kolak,
Post here by Feisty2 (although concerns more Vapoursynth):- http://forum.doom9.org/showthread.php?p=1737136#post1737136

(As I understand it) First BlkSize=16, is fast but a little imprecise. As further iterations at lower BlkSize, so refines precision (but gets slower).
MBlockFps is pretty much interchangeable with MFlowFps, although there may be some caveats. (Actually, I prefer MBlockFps too).

[Groucho2004]

Kolak,
Post here by Feisty2 (although concerns more Vapoursynth):- http://forum.doom9.org/showthread.php?p=1737136#post1737136

(As I understand it) First BlkSize=16, is fast but a little imprecise. As further iterations at lower BlkSize, so refines precision (but gets slower).
MBlockFps is pretty much interchangeable with MFlowFps, although there may be some caveats. (Actually, I prefer MBlockFps too).
There is some info about the redefinition of "blksize" in the MVTools2 documentation. I put this function together based on hints and snippets from various sources. It's a bit slow but I certainly prefer it to SVP which produces terrible artefacts in my opinion. Other people's mileage may vary, the result also depends heavily on the nature of the source.

[feisty2]

Kolak,
Post here by Feisty2 (although concerns more Vapoursynth):- http://forum.doom9.org/showthread.php?p=1737136#post1737136

(As I understand it) First BlkSize=16, is fast but a little imprecise. As further iterations at lower BlkSize, so refines precision (but gets slower).
MBlockFps is pretty much interchangeable with MFlowFps, although there may be some caveats. (Actually, I prefer MBlockFps too).

depending on how you define "precision", I would just say smaller block size does not necessarily equal higher precision, like it picks a smaller neighborhood to estimate the local status, the estimation gets closer to the exact local status as the neighborhood shrinks down, and a box weighted bilateral is the mathematical limit of neighborhood -> 0, and obviously bilateral is lame cuz a zero length neighborhood also makes zero use of self similarity
and by the way smaller block size produces less coherent motion vectors which are toxic to slo-mo kinda stuff

[Groucho2004]

depending on how you define "precision", I would just say smaller block size does not necessarily equal higher precision, like it picks a smaller neighborhood to estimate the local status, the estimation gets closer to the exact local status as the neighborhood shrinks down, and a box weighted bilateral is the mathematical limit of neighborhood -> 0, and obviously bilateral is lame cuz a zero length neighborhood also makes zero use of self similarity
and by the way smaller block size produces less coherent motion vectors which are toxic to slo-mo kinda stuff
OK Sensei. Any suggestions to optimize that function for SloMo?

[feisty2]

OK Sensei. Any suggestions to optimize that function for SloMo?

I would just go with a large block size like motion vector coherence MATTERS to frame interpolation...
blksize = 16 seems like a balanced choice to me..

[Groucho2004]

I would just go with a large block size like motion vector coherence MATTERS to frame interpolation...
blksize = 16 seems like a balanced choice to me..
Thanks, I'll try it later.

[kolak]

Kolak,
Post here by Feisty2 (although concerns more Vapoursynth):- http://forum.doom9.org/showthread.php?p=1737136#post1737136

(As I understand it) First BlkSize=16, is fast but a little imprecise. As further iterations at lower BlkSize, so refines precision (but gets slower).
MBlockFps is pretty much interchangeable with MFlowFps, although there may be some caveats. (Actually, I prefer MBlockFps too).

Well, I found that for HD source block 32 (with 8 or 16 overlap) gives the best results and latest mvtools in vapourysnth produce way less artefacts than svp. As some people mentioned smaller blocks size quite often causes more artefacts. I actually asked for bigger blocks sizes in mvtools. Search parameter and DCT for me affect quality the most. DCT=1 is way the best one, but sooooo slow (and we are not talking about flashes etc, but even on "normal" frames). As I said few times maybe things like 2 pass analysis with adaptive block switching and search parameter would be optimal. I assume this would be crazy slow.

[StainlessS]

Kolak, If you come up with a 'one size fits all' solution, be sure to post it, thank you sir. EDIT: or, A one size fits nearly all.

[johnmeyer]

Is the MVTools for vapousynth substantially different than MVTools for AVISynth? I keep putting off using vapoursynth, but if I can get visibly better results, then I'll take the time to install and learn.

[feisty2]

Is the MVTools for vapousynth substantially different than MVTools for AVISynth? I keep putting off using vapoursynth, but if I can get visibly better results, then I'll take the time to install and learn.

you were obviously gratified with how I fixed that Iceland footage last time, and you gave up anyways..
why should this time be any different?

[kolak]

Kolak, If you come up with a 'one size fits all' solution, be sure to post it, thank you sir. EDIT: or, A one size fits nearly all.

There maybe solution, which is adaptive block :)
The things is that Groucho2004 is not using 1 command with a block size, but recalculate option, which I assume may help with quality.

[kolak]

Is the MVTools for vapousynth substantially different than MVTools for AVISynth? I keep putting off using vapoursynth, but if I can get visibly better results, then I'll take the time to install and learn.

I think it's the same. Not sure about speed, but there is new version for vs coming with some speed optimisation.

[feisty2]

There maybe solution, which is adaptive block :)
The things is that Groucho2004 is not using 1 command with a block size, but recalculate option, which I assume may help with quality.

It definitely helps with denoising and stuff like that, not with frame interpolation

[kolak]

Thanks, but I have some idea.

Some scenes benefit from search=6 or search=7 (they produce double edges but no artefacts which is better when watched in full motion), so if I use 3 step re-calculate: search=4, then search=6, then search=7 then in theory I should get better interpolation (assuming best vectors are picked properly). No?
This is almost like my 2 pass adaptive search/block idea.

[feisty2]

Thanks, but I have some idea.

Some scenes benefit from search=6 or search=7 (they produce double edges but no artefacts which is better when watched in full motion), so if I use 3 step re-calculate: search=4, then search=6, then search=7 then in theory I should get better interpolation (assuming best vectors are picked properly). No?
This is almost like my 2 pass adaptive search/block idea.

Recalculate works by minimizing the vector SAD, it recalculates a vector if its SAD is above the threshold
You get search=3 by picking vectors calculated by exhaustive search in different (horizontal or vertical) directions based on SAD
and you claimed that search=3 sucked,,,

[kolak]

Yes, search=3,4 or 5 maybe produced best vectors SAD wise, but they introduce artefacts on some scenes (e.g. car going quickly across the frame). In such a case search=7 will do bit of double edges, but this is way better than artefacts from e.g. search=3.

[feisty2]

Then your recalculating different kinds of searching algorithms method won't work cuz it's basically a less efficient search=3

[kolak]

I thought this will use search=3 for most frames and than just switch to eg. search=7 only for some frames (or none).
I'm running test now which then I will compare against pure search=3 mode (PSNR wise).

[kolak]

Looks like this makes most frames about the same as pure search=3, but then some of them (those with artefacts) are different as they are coming from search=7. So it does behave sort of hybrid and gives different result than pure search=3. Speed suffers a lot also :(
but... some scenes don't look good on TV- bit juddery...
DCT=1 is stil best bet for quality and slow speed :)

[StainlessS]

In my humble opinion the Feisty2, is the replacement for Didee [EDIT: time will tell if of worth] , the big dog, on the block.
Unfortunately, he is not that nice.
He is what he is, we have to accept that and deal with it, not nice I know, but that is the Feisty2, thing.

Me Loves him, but what a pain. (Feisty, had a few beers, Forgive me or die)
:) [EDIT: You might want to specify how you will die, ie tragic accident etc]

[johnmeyer]

In my humble opinion the Feisty2, is the replacement for Didee [EDIT: time will tell if of worth] , the big dog, on the block.
Unfortunately, he is not that nice.
He is what he is, we have to accept that and deal with it, not nice I know, but that is the Feisty2, thing.

Me Loves him, but what a pain. (Feisty, had a few beers, Forgive me or die)
:) [EDIT: You might want to specify how you will die, ie tragic accident etc]He just took another minor shot at me, but I don't mind it because he's just trying to tell grandpa to get off his butt and get on with it.

He is not entirely wrong about that.

And I agree with the Didée comparison: neither of them suffer fools (which, I guess, includes me), but they both have pretty unique ways of looking at video problems and therefore develop very unusual solutions to problems.

The only real downside is that very few of us can understand how the scripts work and the presentation is often more cryptic than it really needs to be. This makes it very difficult to build on their work or take it in a new direction. This is my only real complaint: both "open source" and the work done in these forums requires a collegial approach because one person can seldom do everything needed to create great software.

[urukazuto]

Thank you for the explanation and Suggestion.

I want to ask about MBlockFps Processing Mode, a lot of people apparently using mode = 0 (the fastest), and I read the documentation, it seems the mode 3 to 8 mentioning masking, are they further increased masking and quailty also? Anyone that try this?

[StainlessS]

I like MBlockFPS:

function foo(clip source, int "multi")
{
last = source
multi = default(multi, 2)

super = MSuper(source, pel = 2, hpad = 0, vpad = 0, rfilter = 4)
backward_1 = MAnalyse(super, chroma = false, isb = true, blksize = 16, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
forward_1 = MAnalyse(super, chroma = false, isb = false, blksize = 16, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
backward_2 = MRecalculate(super, chroma = false, backward_1, blksize = 8, searchparam = 1, search = 3)
forward_2 = MRecalculate(super, chroma = false, forward_1, blksize = 8, searchparam = 1, search = 3)
backward_3 = MRecalculate(super, chroma = false, backward_2, blksize = 4, searchparam = 0, search = 3)
forward_3 = MRecalculate(super, chroma = false, forward_2, blksize = 4, searchparam = 0, search = 3)
MBlockFps(source, super, backward_3, forward_3, FramerateNumerator(last) * multi, FramerateDenominator(last), mode = 0)

return last
}


Perhaps might try this mod


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, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(superfilt, chroma = false, isb = false, blksize = 16, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, searchparam = 1, search = 3)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3)
bw_3 = MRecalculate(super, chroma = false, bw_2, blksize = 4, searchparam = 0, search = 3)
fw_3 = MRecalculate(super, chroma = false, fw_2, blksize = 4, searchparam = 0, search = 3)
MBlockFps(source, super, bw_3, fw_3, FramerateNumerator(Source) * multi, FramerateDenominator(Source), mode = 0, Blend=False)
return last
}


Hpad, and vpad are recommended in docs
In MVTools before v2.0 the value of padding = block size was always used internally. Now it is not strict but recommended value.
With hpad=0, you can get oscillating (disappearing/reappearing) verticals at left and right edges when things move near screen edges.
Same top and bottom if vpad=0.
EDIT: I have not been able to reproduce this during current testing, but have noticed it in the past.

during some test comparisons, not using MRecalculate() produced some blockiness that was squashed by a single MRecalculate(blksize = 8).

I really dont like Blend=True default, it makes detecting scene changes bloody impossible.

This is probably what I will use in future, unless someone can suggest something better.

Function DoubleRate(clip c) {
c
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, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(superfilt, chroma = false, isb = false, blksize = 16, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, searchparam = 1, search = 3)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3)
MBlockFps(super, bw_2, fw_2, num=0, den=0, mode=0, Blend=false)
Return Last
}


EDIT: Maybe Overlap of say 2, could improve a little (on MRecalculate). ???
EDIT: Scratch above EDIT, produces weird flashing with Overlap=2 in MRecalculate.

[feisty2]

Perhaps might try this mod


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, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(superfilt, chroma = false, isb = false, blksize = 16, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, searchparam = 1, search = 3)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3)
bw_3 = MRecalculate(super, chroma = false, bw_2, blksize = 4, searchparam = 0, search = 3)
fw_3 = MRecalculate(super, chroma = false, fw_2, blksize = 4, searchparam = 0, search = 3)
MBlockFps(source, super, bw_3, fw_3, FramerateNumerator(Source) * multi, FramerateDenominator(Source), mode = 0, Blend=False)
return last
}


Hpad, and vpad are recommended in docs

With hpad=0, you can get oscillating (disappearing/reappearing) verticals at left and right edges when things move near screen edges.
Same top and bottom if vpad=0.

during some test comparisons, not using MRecalculate() produced some blockiness that was squashed by a single MRecalculate(blksize = 8).

I really dont like Blend=True default, it makes detecting scene changes bloody impossible.

This is probably what I will use in future, unless someone can suggest something better.

Function DoubleRate(clip c) {
c
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, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(superfilt, chroma = false, isb = false, blksize = 16, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, searchparam = 1, search = 3)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3)
MBlockFps(super, bw_2, fw_2, num=0, den=0, mode=0, Blend=false)
Return Last
}


Make "overlap" > 0 and the blockiness will disappear
And then you'll see why small blocks suck at frame interpolation

[feisty2]

MAnalyse(blksize=16, overlap=8, ...)
And no extra pointless MRecalculate

[StainlessS]

These two are garbage, I must have screwed up somewhere (weird flashing, EDIT: Green and Pink frames).


Function DoubleRate3(clip c) {
c
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)
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))
MBlockFps(super, bw_1, fw_1, num=0, den=0, mode=0, Blend=false)
Return Last
}

Function DoubleRate4(clip c) {
c
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))
MBlockFps(super, bw_1, fw_1, num=0, den=0, mode=0, Blend=false)
Return Last
}

But this works ok

Function DoubleRate2(clip c) {
c
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)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3)
MBlockFps(super, bw_2, fw_2, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), mode=0, Blend=false)
Return Last
}

[feisty2]

Overlap=8
Plus whirling and blockiness, you can only avoid one

[StainlessS]

The two above Garbage functions still fail with Overlap=8, Green, Pink and Gray frames (sometimes), and jumping backwards and forwards in time.

EDIT: The two Garbage functions above, both work ok if changed to MFlowFps() and removing mode=0 (not an arg to MFlowFps).

Looks like something may be broken in latest (I think) mvtools MBlockFps.

[feisty2]

The two above Garbage functions still fail with Overlap=8, Green, Pink and Gray frames (sometimes), and jumping backwards and forwards in time.

So chroma was screwed, gotcha
Append "convettoy8()" at the end of the script and check if luma is okay
If it is, then that's probably an mvtools bug

[StainlessS]

See previous edit feisty.

EDIT: I'de say definite bug, not just the chroma that is screwed up, and temporal chaos.

[feisty2]

See previous edit feisty.

EDIT: I'de say definite bug, not just the chroma that is screwed up, and temporal chaos.

well, I ain't used avisynth for a while but blockfps in vaporsynth mvtools works
give it a go

import vapoursynth as vs
core = vs.get_core()

clp = blah blah blah
super = core.mv.Super(clp,pel=4,hpad=16,vpad=16,rfilter=4)
bw_1 = core.mv.Analyse(super,isb=True,blksize = 16,overlap=8,search=3,badrange =-24)
fw_1 = core.mv.Analyse(super,isb=False,blksize = 16,overlap=8,search=3,badrange =-24)
clp = core.mv.BlockFPS(clp, super, bw_1, fw_1, num=0, den=0, mode=0, blend=False)

clp.set_output()

[StainlessS]

I'de love to 'give it a go', unfortunately I is on XP32, and nobody cares bout us lil ol' XP users :)

With 4 window stack display, Garbage function, Good function, Subract(Garbage,Good), Subract(Garbage,Good),
If I play (in VDUB) say some part of early clip, and then jump to near the end of clip,
and play, then will sporadically show frames from the early part of clip that was recently played. Sometimes it shows
what looks to be frames from a diagnostic Subtract that is showing in one of the windows.
Looks like its totally Mucked up (substitute an alternate first letter of your choice).

EDIT MvTools2 that I'm using is v2.5.11.20.

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
}

[feisty2]

and BlockFPS is definitely more or less better than FlowFPS in general
FlowFPS

import vapoursynth as vs
core = vs.get_core()

clp = xxx
clp = core.fmtc.bitdepth(clp,bits=32,fulls=False,fulld=True)
super = core.mvsf.Super(clp,pel=4,hpad=16,vpad=16,rfilter=4)
bw_1 = core.mvsf.Analyze(super,isb=True,blksize = 16,overlap=8,search=3,badrange =-24)
fw_1 = core.mvsf.Analyze(super,isb=False,blksize = 16,overlap=8,search=3,badrange =-24)
clp = core.mvsf.FlowFPS(clp, super, bw_1, fw_1, num=0, den=0, blend=False)

clp.set_output()

http://i.imgur.com/7qxG8QF.png
http://i.imgur.com/i0kNuz0.png
BlockFPS

import vapoursynth as vs
core = vs.get_core()

clp = xxx
clp = core.fmtc.bitdepth(clp,bits=32,fulls=False,fulld=True)
super = core.mvsf.Super(clp,pel=4,hpad=16,vpad=16,rfilter=4)
bw_1 = core.mvsf.Analyze(super,isb=True,blksize = 16,overlap=8,search=3,badrange =-24)
fw_1 = core.mvsf.Analyze(super,isb=False,blksize = 16,overlap=8,search=3,badrange =-24)
clp = core.mvsf.BlockFPS(clp, super, bw_1, fw_1, num=0, den=0, blend=False)

clp.set_output()

http://i.imgur.com/qK1QrgG.png
http://i.imgur.com/D1R03LQ.png

[StainlessS]

Perhaps all posts relating to MvTools2 should be separated into a new thread, Its really about time MvTools2 had a thread in the Avisynth Usage forum,
and Interframe dont need lots of posts about it's competitor.
I suggest from post #915 (to put Groucho2004 in command) and maybe insert the two posts 913 and 914 after the first post, if possible.

All those in favour, say "Aye!".

[Groucho2004]

The two above Garbage functions still fail with Overlap=8, Green, Pink and Gray frames (sometimes), and jumping backwards and forwards in time.

EDIT: The two Garbage functions above, both work ok if changed to MFlowFps() and removing mode=0 (not an arg to MFlowFps).

Looks like something may be broken in latest (I think) mvtools MBlockFps.
I'm still using mvtools2 v2.5.11.3 since the newer versions crash/throw exceptions when multi-threaded. In this older version, MBlockFps actually throws an error when using "overlap" > 0 in MAnalyse(). So, MFlowFps may be a better choice in this case.

[kolak]

and BlockFPS is definitely more or less better than FlowFPS in general


Is -24 for badrange is "better". Default is 24.

[Groucho2004]

Is -24 for badrange is "better". Default is 24.
From MVTools2 doc:
badrange: the range (radius) of wide search for bad blocks. Default is 24 (image pixel units). Use positive value for UMH search and negative for Exhaustive search.

[kolak]

Yes, rtfm (properly) :)

[pinterf]

These two are garbage, I must have screwed up somewhere (weird flashing, EDIT: Green and Pink frames).


Function DoubleRate3(clip c) {
c
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)
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))
MBlockFps(super, bw_1, fw_1, num=0, den=0, mode=0, Blend=false)
Return Last
}

Function DoubleRate4(clip c) {
c
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))
MBlockFps(super, bw_1, fw_1, num=0, den=0, mode=0, Blend=false)
Return Last
}


Indeed. There is a missing copy of the 16 bit internal buffers back to 8 bit result when overlap is used. I will fix it in my pfmod branch in the next release.