InterFrame 2.8.2 - Framedoubling/60FPS/HFR conversion script

[SubJunk]

Version 1.9 is released, it adds support for 2 more types of 3D inputs (Half-SBS and Half-Over-Under).
Please see the documentation for details/descriptions.

[Shah Jahan]

I see that the code has Spline36Resize, if I change the code and make it Spline64Resize then will it work? Do you advise it? Is it a good/bad idea?

And this doesn't work for real-time viewing even on my Phenom II Quad Code overclocked to 3.6GHz. Only Super/Ultra Fast work albeit with not-so-good quality. Hoping for the promised faster-but-same-quality version to be released soon. Is it possible to add a GUI that gives several options to tweak like SVP Manager does? If you can pull that you'd immediately have a larger user-base.

[SubJunk]

Hi Shah, welcome to Doom9 :)

I see that the code has Spline36Resize, if I change the code and make it Spline64Resize then will it work? Do you advise it? Is it a good/bad idea?In normal 2D usage there is no resizing, that is just for 3D InputTypes.
Spline64 is for downsizing whereas 36 is more neutral, and the resizing in InterFrame 3D modes should be neutral. In reality it won't make much if any difference, but logically 36 is better suited than 64.

[Shah Jahan]

Hi Shah, welcome to Doom9 :)

In normal 2D usage there is no resizing, that is just for 3D InputTypes.
Spline64 is for downsizing whereas 36 is more neutral, and the resizing in InterFrame 3D modes should be neutral. In reality it won't make much if any difference, but logically 36 is better suited than 64.

Alright, thanks.

Now is there a way to tweak your presets like in SVP? SVP gives a lot (perhaps a bit too many?) options that you can change and we'd love to have the same with InterFrame.

BTW, how is your script different to SVP? Do you offer anything more which SVP doesn't?

Thanks.

[SubJunk]

The main difference is that, while InterFrame does support realtime playback, its main purpose is to allow users to encode and save their videos at higher framerates, while SVP is for realtime only.
This means that even users with slow computers can watch the highest quality interpolation instead of having to compromise on quality. It also means people can watch those highest-quality videos anywhere like on their TV via a media server.
InterFrame's default preset also offers higher quality than is possible with the SVP GUI - SVP can do it if you manually edit the avs file, but not via the GUI.

InterFrame also properly supports 4 types of stereoscopic 3D inputs whereas SVP doesn't AFAIK.

I would like to add that I love SVP. I'm not competing against it and I think we both have cool things to offer :)

P.S. I wrote a review of SVP here (http://www.spirton.com/svp-smoothvideo-project/) saying most of the same things.

[Shah Jahan]

Alright, thank for the reply.

SVP can do it if you manually edit the avs file, but not via the GUI.
Wait, what?! Why not from the GUI?

Also, with AVS, I have tweaked it to almost all settings to their highest levels and still have a smooth playback, but I guess Interframe is more intended towards encoding? Do you plan to have a real-time playback script, possibly with a GUI, if not then atleast an AVS script?

Re-encoding is too much a work, a hassle that most would prefer to skip, but if it can be done on-the-fly then it will garner more interest I guess. From a sheer marketing point of view, real-time has more market than re-encode. Just a suggestion, BTW I love what you do.

[SubJunk]

Wait, what?! Why not from the GUI?Because the settings are too CPU-intensive. You even said yourself that you can't use most InterFrame presets in realtime :) There is no speed difference between SVP and InterFrame on the same settings; the only reason this is slower on most presets is because the quality is higher.

Also, with AVS, I have tweaked it to almost all settings to their highest levels and still have a smooth playback, but I guess Interframe is more intended towards encoding? Do you plan to have a real-time playback script, possibly with a GUI, if not then atleast an AVS script?I'm not sure what you mean by "if not then at least an AVS script". InterFrame is an AviSynth script.

[CruNcher]

Alright, thank for the reply.


Wait, what?! Why not from the GUI?

Also, with AVS, I have tweaked it to almost all settings to their highest levels and still have a smooth playback, but I guess Interframe is more intended towards encoding? Do you plan to have a real-time playback script, possibly with a GUI, if not then atleast an AVS script?

Re-encoding is too much a work, a hassle that most would prefer to skip, but if it can be done on-the-fly then it will garner more interest I guess. From a sheer marketing point of view, real-time has more market than re-encode. Just a suggestion, BTW I love what you do.

Econonmy wise you have to take into account how balanced it is and how much you have to invest CPU cycle wise if you first tried out SVP & Interframe on 1080p content you will see what i mean ;) Realtime is possible but it will almost need all the resources available and for smooth playback a combination of CPU+GPU is needed which balance wise is crazy 2x power consumption for 1 task :). In this perspective investing it @ Transcoding time 1x can be more efficient depending on your scenario (clients shouldn't invest their resources ect). A complete Cuda/APP Implementation (even if it's less effective, lot of avg consumer won't detect problems in 1 frame randomly @ all) in those regards like i think Cyberlink (TrueTheater® Motion), Arcsoft (part of SimHD), Corel (Intervideo the first ones who implemented Philips Trimension algorithm for consumer Software use) and Mirilis (Motion²) have them can be far more efficient resource wise for Realtime Playback on the Desktop without a special Hardware solution (DSP). Though last tests i did with @ least Cyberlinks Tzan TrueTheater® Motion Cuda showed also extreme CPU usage but this can be also because i used only a Compute 1.1 and no Compute 1.2 card which should be more efficient in offloading the CPU (still obviously you have all the memory copy back and forth over the PCI-E going on and in such regards Sandy Bridge could become interesting as well as AMDs APU shorter cached transfer paths).

[Shah Jahan]

Will it be possible to add a buffer? Like when a video is played, or skipped forward it buffers for a [user selected time] before it starts to play? So that all the processing is done before hand and when the video starts to play it has a head-start so that it doesn't stutter? I don't know if having such a thing is possible? But I'll surely use it if it does! So is it possible? You can set the default value as 0 so that only those who intend to use it will manually set it on to a value they prefer.

Although the question remains, is it possible?

[SubJunk]

is it possible?You can set up ffdshow to buffer, but it's not possible to include it in an AviSynth script (nor should it be) :)

[Shah Jahan]

You can set up ffdshow to buffer, but it's not possible to include it in an AviSynth script (nor should it be) :)

So if I set ffdshow to buffer, then will I be able to use your script without lags? If yes, then how to enable it?

[SubJunk]

I'm not sure, maybe start a new thread for it or search old threads :)

Edit: I found this when I searched:

Now open up ffdshow and go to the avisynth tab, uncheck Add ffdshow video source and check buffer back/ahead. I have mine at 0/99 but the best value is probably 0/24.

[magnetite]

I tried doing the real-time thing just for fun. Didn't go so well. As was said earlier, you'll need major CPU/GPU power. I have a Sandy Bridge i7 2600K and a GTX 570, and I'd probably prefer to re-encode everything. Currently for SD material, I can use Interframe at around 145 FPS with the x264 Ultra Fast preset and MT mode 2. MT mode 1 will crash x264 for my DVDs. A 45 minute episode takes roughly 20 minutes to do, so I guess it's not too bad. Then again, I've got over 400 DVDs and around 45 Blu-rays. :eek:

Did it before, but didn't get the quality I wanted (not enough CRF). I think it was 16 before. This time I'm going for CRF 14. I guess for myself, I'd want to shoot for as close to the source as possible.

[SubJunk]

Yep I use 14 personally, and I know some release groups who have even gone to 11 before.
11 and 14 are different in screenshots but with a moving source I don't think anyone could tell the difference (queue videophiles telling me I must be blind ;))

[magnetite]

Hey Subjunk. I'm just curious, but is MeGUI the only program that works with this? I keep getting this "Attempted to read or write protected memory. Memory is corrupt" or sometimes x264 will crash, even though I've got the MTMode set high enough.

I do also use Mediacoder, which allows for Avisynth scripts, so I'm wondering if you knew how to get Interframe working with that? I might have more luck.

[SubJunk]

Hi magnetite :) It should work with any program that supports AviSynth.
I had that "protected memory" error some time in the past and I fixed it by installing a Microsoft Visual C++ Redistributable package. I think I only had the 2008 one and it needed the 2005 one or something, I installed a whole bunch of them and that fixed the bug.

I've attached a screenshot of the ones I have installed, so hopefully one of them will fix the bug for you :) If you need help finding download links let me know

[magnetite]

Nevermind. I spoke too soon. I'll try the C++ thing.

I installed roughly 12 of those redistributables and I'm still getting the error. I don't think my actual RAM is corrupt, otherwise I would probably be getting lots of BSODs, but I'll run a RAM test just to be sure.

Edit: Something I didn't try before. I left out the line where it sets the maximum amount of memory in the script, and that seemed to get it going.

[Shah Jahan]

I'm not sure, maybe start a new thread for it or search old threads :)

Edit: I found this when I searched:

Thanks, I tried different buffer settings but I think InterFrame is more inclined towards encoding and not a real-time thing.
Thanks for all the help though :thanks:

[DeathTheSheep]

Why is there a dependency on a cumbersome closed-source "plugin" that requires a password to install and fails to detect the presence of existing MT avisynth?

http://img684.imageshack.us/img684/5920/passwordl.png (http://imageshack.us/photo/my-images/684/passwordl.png/)

Can anyone just provide a zip of the "SVP" mvtools2 plugins? Last I checked MVTools2 was FOSS.

[edit]Ignore me. After downloading IF1.9 anyway, I saw the zip contained the dependencies already. My apologies! Perhaps you might consider advertising this fact on the download page itself -- "Dependencies (Included in zip!)"

[SubJunk]

Perhaps you might consider advertising this fact on the download page itself -- "Dependencies (Included in zip!)"Good idea, I will add that :)

[DeathTheSheep]

Excellent! Great work on the filter. I have one thing to point out: borders suffer from very strange artifacts -- perhaps if some border padding was used...or removed? I see you're using hpad/vpad. Is this even right with the flow functions? I don't see a reason to use this with a non-block search.

Here's a case-in-point with preset placebo. The first picture is default tuning; the second is with tune=smooth; the third is using a different, simple script without recalculation or anything (notably lacking vpad/hpad). Look at the borders on the far left/right:

Default tuning:
http://img101.imageshack.us/img101/9341/borders.jpg (http://imageshack.us/photo/my-images/101/borders.jpg/)

Tune=smooth:
http://img29.imageshack.us/img29/1827/borderstuningsmooth.jpg (http://imageshack.us/photo/my-images/29/borderstuningsmooth.jpg/)

Mine:
http://img135.imageshack.us/img135/1457/borderscorrectsimplemfl.jpg (http://imageshack.us/photo/my-images/135/borderscorrectsimplemfl.jpg/)

Another thing I realized after looking at these images is that the quality seems crispest in the last image in multiple places (note the woman's chin, the bricks under her lowered arm, the background near her outstretched hand, etc).

[SubJunk]

Yes there are sometimes those border problems with fast panning, they're caused by hpad and vpad, which are values that somewhat-ironically make the details near the edges more accurate ;)
The effect can be removed by setting hpad and vpad values to 0, with the tradeoff obviously being that the edges are less accurate.

I will make a post in the mvtools2 thread about it, maybe Fizick is unaware of that side-effect.

[SubJunk]

Another thing I realized after looking at these images is that the quality seems crispest in the last image in multiple places (note the woman's chin, the bricks under her lowered arm, the background near her outstretched hand, etc).Yeah, it does look better in that frame. What is the script you used?
It's possible that your script has benefits I can learn from, or that it got lucky with that particular scene, either way I'm interested to see the script so I can test for myself :)

[Didée]

It's a common misunderstanding that "more effort" in MVTools settings would necessarily increase the quality of flow interpolation. That's (partly) true for denoising, but not for flow-interpolation.

The motion search is about block matching. Block matching is not strictly related to motion. Any change related to vector coherence will "improve here, degrade there".

Said it a hundred times, here is the hundred-and-first: MVTools has no idea what "motion" actually is. It's only simple algorithms. No brain, no AI.

[SubJunk]

That's a very simplistic way of putting it. Compromise is rarely equal, so while changes may be compromises it's still possible to make improvements.
The mvtools2 scripts we use today are much better than the ones we used 3 years ago.

As for the point you keep raising about it having no brain or AI, I'm aware you have said it a hundred times but I've never seen it be in response to anything; I'm not aware of anyone claiming it did have those qualities.

[DeathTheSheep]

That's a very simplistic way of putting it. Compromise is rarely equal, so while changes may be compromises it's still possible to make improvements.
The mvtools2 scripts we use today are much better than the ones we used 3 years ago.

As for the point you keep raising about it having no brain or AI, I'm aware you have said it a hundred times but I've never seen it be in response to anything; I'm not aware of anyone claiming it did have those qualities.

By "effort" in this case, Didee is pointing out that you don't need high searchparam values and the like. It's true -- here's an example of a scene that would be expected OTOH to benefit greatly from a so-called "larger range motion search" but which actually isn't benefited by increasing the area scanned around a match:

High-speed case (defaults, pad=0):
http://img593.imageshack.us/img593/9938/fasthirange.jpg (http://imageshack.us/photo/my-images/593/fasthirange.jpg/)

High-speed case (tweaks=true, pad=0)
http://img7.imageshack.us/img7/8371/fastmyrange.jpg (http://imageshack.us/photo/my-images/7/fastmyrange.jpg/)

Medium-speed case (defaults, pad=0)
http://img810.imageshack.us/img810/7228/slowerhirange.jpg (http://imageshack.us/photo/my-images/810/slowerhirange.jpg/)

Medium-speed case (tweaks=true, pad=0)
http://img163.imageshack.us/img163/2003/slowermyrange.jpg (http://imageshack.us/photo/my-images/163/slowermyrange.jpg/)

Here you have version 2.0 with a few new treats. Output is identical to 1.9 by default, but contains the following new treats:
Tweaks (default false): Enables my tweaks. Should improve quality across the board, pretty much.
Pad (default 1): Scaling factor for padding. 0-0.5 is recommended to avoid the horrific edge artifacts.
Tuning = "Smoothfilm": A new setting for Tuning, it gently merges in some local motion enhancement. Significantly fewer artifacts than "Smooth".


#------------------------------------------------------------------------------#
# #
# InterFrame 2.0pre by SubJunk, DeathTheSheep #
# #
# A frame interpolation script that primarily uses MVTools2 for making #
# accurate estimations about the content of non-existent frames #
# Its main use is to give videos higher framerates like newer TVs do #
#------------------------------------------------------------------------------#


# For instructions and further information see the included InterFrame.html
# For news go to spirton.com


function InterFrame(clip Input, string "Preset", string "Tuning", int "NewNum", int "NewDen", string "FlowPath", bool "GPU", string "InputType", float "Pad", bool "Blend", bool "Tweaks") {
# Defaults
Preset = default(Preset , "Medium" )
NewNum = default(NewNum , 0 )
NewDen = default(NewDen , 0 )
Tuning = default(Tuning , "Film" )
FlowPath = default(FlowPath , "Undefined")
GPU = default(GPU , false )
InputType = default(InputType, "2D" )
Pad = default(Pad , 1 )
Blend = default(Blend , true )
Tweaks = default(Tweaks , false )

# Validate inputs
Assert(Preset == "Placebo" || Preset == "Medium" || Preset == "Fast" || Preset == "Faster" || Preset == "Very Fast" || Preset == "Super Fast" || Preset == "Ultra Fast", "'"+Preset+"' is not a valid preset. Please check the documentation for a list of the valid presets.")
Assert(Tuning == "Film" || Tuning == "Smooth" || Tuning == "Smoothfilm" || Tuning == "Animation", "'"+Tuning+"' is not a valid tuning. Please check the documentation for a list of the valid tunings.")
Assert(InputType == "2D" || InputType == "SBS" || InputType == "OU" || InputType == "HSBS" || InputType == "HOU", "'"+InputType+"' is not a valid InputType. Please check the documentation for a list of the valid InputTypes.")
Assert(FlowPath != "Undefined", "You must specify FlowPath. Please check the documentation for details.")

# Get either 1 or 2 clips depending on InputType
InputType == "SBS" ? Eval("""
FirstEye = InterFrameProcess(Input.crop(0 , 0, -Input.Width/2, 0), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
SecondEye = InterFrameProcess(Input.crop(Input.Width/2, 0, 0 , 0), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
StackHorizontal(FirstEye, SecondEye)
""") : InputType == "OU" ? Eval("""
FirstEye = InterFrameProcess(Input.crop(0, 0 , 0, -Input.Height/2), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
SecondEye = InterFrameProcess(Input.crop(0, Input.Height/2, 0, 0 ), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
StackVertical(FirstEye, SecondEye)
""") : InputType == "HSBS" ? Eval("""
FirstEye = InterFrameProcess(Input.crop(0 , 0, -Input.Width/2, 0).Spline36Resize(Input.Width, Input.Height), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
SecondEye = InterFrameProcess(Input.crop(Input.Width/2, 0, 0 , 0).Spline36Resize(Input.Width, Input.Height), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
StackHorizontal(FirstEye.Spline36Resize(Input.Width/2, Input.Height), SecondEye.Spline36Resize(Input.Width/2, Input.Height))
""") : InputType == "HOU" ? Eval("""
FirstEye = InterFrameProcess(Input.crop(0, 0 , 0, -Input.Height/2).Spline36Resize(Input.Width, Input.Height), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
SecondEye = InterFrameProcess(Input.crop(0, Input.Height/2, 0, 0 ).Spline36Resize(Input.Width, Input.Height), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
StackVertical(FirstEye.Spline36Resize(Input.Width, Input.Height/2), SecondEye.Spline36Resize(Input.Width, Input.Height/2))
""") : Eval("""
InterFrameProcess(Input, Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType, Pad=Pad, Blend=Blend, Tweaks=Tweaks)
""")
}

function InterFrameProcess(clip Input, string "Preset", string "Tuning", int "NewNum", int "NewDen", string "FlowPath", bool "GPU", string "InputType", float "Pad", bool "Blend", bool "Tweaks") {
#Assign defaults to Tweakable values
rfilter_val = 4
overlap_val = (Tuning == "Smoothfilm") ? 6 : 4
overlap_val2 = 2
sp_val = 4
sp_val2 = 3
sp_val3 = 1
badSAD_val = 2000
plevel_val = 0
dct_val = (Tuning == "Smoothfilm") ? 8: 5

#Apply Tweaks (if applicable) by changing some variables
Tweaks == true ? Eval("""
rfilter_val = 4
overlap_val = (Tuning == "Smoothfilm") ? 6 : 4
overlap_val2 = (Tuning == "Smoothfilm") ? 4 : 2
sp_val = 2
sp_val2 = 2
sp_val3 = 2
badSAD_val = 20000
plevel_val = 0
dct_val = (Tuning == "Smoothfilm") ? 8: 5
""") : Eval(""" """)


# Create processed clip for slower presets
Preset == "Placebo" || Preset == "Medium" || Preset == "Fast" || Preset == "Faster" ? Eval("""
ProcessedSource = Input.RemoveGrain(mode=17)
""") : Eval("""
# Don't want ProcessedSource
""")

# Set variables controlled by Tuning
BlockSize = (Tuning == "Film") ? 16 : \
(Tuning == "Animation" ) ? 32 : \
(Tuning == "Smooth" ) ? 8 : 16

# Create super clip/s
SuperRegular = MSuper(Input, hpad=Floor(Pad*BlockSize), vpad=Floor(Pad*BlockSize), rfilter=rfilter_val)

Preset == "Placebo" ? Eval("""
CustomPelClip = EEDI2(Input, field=1).Spline36Resize(2*width(Input), 2*height(Input), src_left=0.25)

Super = MSuper(ProcessedSource, hpad=Floor(Pad*BlockSize), vpad=Floor(Pad*BlockSize), rfilter=rfilter_val, pelclip=CustomPelClip)
""") : Preset == "Medium" ? Eval("""
Super = MSuper(ProcessedSource, hpad=Floor(Pad*BlockSize), vpad=Floor(Pad*BlockSize), rfilter=rfilter_val)
""") : Eval("""
Super = MSuper(Input, hpad=Floor(Pad*BlockSize), vpad=Floor(Pad*BlockSize), rfilter=rfilter_val)
""")

# Make interpolation vector clip
Preset == "Ultra Fast" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=true , badSAD=badSAD_val, chroma=false)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=false, badSAD=badSAD_val, chroma=false)
""") : Preset == "Super Fast" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val)
""") : Preset == "Very Fast" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val)
backward = MRecalculate(Super, backward, blksize=8, searchparam=sp_val3, overlap=overlap_val2)
forward = MRecalculate(Super, forward, blksize=8, searchparam=sp_val3, overlap=overlap_val2)
""") : Preset == "Faster" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val, search=3, pelsearch=3)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val, search=3, pelsearch=3)
backward = MRecalculate(Super, backward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3)
forward = MRecalculate(Super, forward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3)
""") : Preset == "Fast" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val, search=3, pelsearch=3)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val, search=3, pelsearch=3)
backward = MRecalculate(Super, backward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3)
forward = MRecalculate(Super, forward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3)
""") : Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val, search=3, dct=dct_val, pelsearch=3)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val, search=3, dct=dct_val, pelsearch=3)
backward = MRecalculate(Super, backward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3, dct=dct_val)
forward = MRecalculate(Super, forward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3, dct=dct_val)
""")

# Determine new framerate
NewNum != 0 ? Eval("""
# Use user values
""") : Input.Framerate == 25 ? Eval("""
NewNum = 50
NewDen = 1
""") : Input.Framerate == 30 ? Eval("""
NewNum = 60
NewDen = 1
""") : Eval("""
NewNum = 60000
NewDen = 1001
""")

# See whether to use GPU-acceleration or not
svp_flow_lib = GPU == true ? FlowPath+"libflowgpu.dll" : FlowPath+"libflowsse.dll"
Finest = GPU == true ? SuperRegular : MFinest(Input, SuperRegular)

# Put it together
MSmoothFps(Input, SuperRegular, backward, forward, finest=Finest, num=NewNum, den=NewDen, algo=23, ml=0, sadml=0, sadgamma=2, block=false, blend=Blend)
}

Try it before you buy it. So to speak.

[Didée]

IF (search==3) AND (processing_time == bearable) THEN { (searchparam == way_way_too_small) OR ((search=3)==nonsense) }

[SubJunk]

DeathTheSheep, I'll test your script soon but I wanted to reply about the padding before I forget.
The reason for the weird stuff on the borders of that video is just that the source is under-cropped; the right-most pixels are darker. Try cropping away those bad pixels and that error will go away. Thanks to Didee for pointing it out, I don't know why I didn't notice sooner.

[DeathTheSheep]

DeathTheSheep, I'll test your script soon but I wanted to reply about the padding before I forget.
The reason for the weird stuff on the borders of that video is just that the source is under-cropped; the right-most pixels are darker. Try cropping away those bad pixels and that error will go away. Thanks to Didee for pointing it out, I don't know why I didn't notice sooner.

Perhaps that is the case! Easier done than said anyhow, no? ;) :thanks:

For realtime playback, it would nevertheless be reasonable to decrease/eliminate the padding. After all, with every source there seems to be different cropping problems -- unless you use ffdshow with autocrop or the like, you're bound to run into problems sometime. Especially software like handbrake, megui, etc don't default to enabling crop correction. It's probably best to leave it up to the user's discretion. On this same vid, if I halve the crop value, the problem is largely diminished for casual viewing, so perhaps it's a good compromise in any case.

And at least now it's an option. So all's well that ends well, eh? ;)

[SubJunk]

I think I would rather leave the padding. To my knowledge, most people who use this script use it with scene releases, and the scene has strict rules about cropping :)

So your tweaks are basically to raise badSAD and lower searchparam, but I don't agree with either of those changes. I spent many hours testing badSAD values on different source videos and tabulated the results. Sometimes lower badSAD was worse, but more often it was better.

Searchparam is a hard thing because, as we all keep saying, it really depends on content. Sometimes 4 is best and sometimes 3 is best, and sometimes even 2, but again in testing I've found that 4 is better more often. Higher than 4 can cause warping, so 4 is the sweet-spot more often than not.
I have made the suggestion to Fizick to allow mvtools2 to dynamically change values like blksize and searchparam according to the amount of difference in the frame and he has said he will make that feature, but I don't know when.

The main consequence of using a lower searchparam is that mvtools2 will lose coherence on objects in motion, for example:
Mine (http://www.spirton.com/uploads/60FPS/test-20110607-1-SubJunk.png) - Yours (http://www.spirton.com/uploads/60FPS/test-20110607-1-DeathTheSheep.png)
Mine (http://www.spirton.com/uploads/60FPS/test-20110607-2-SubJunk.png) - Yours (http://www.spirton.com/uploads/60FPS/test-20110607-2-DeathTheSheep.png)
You see how in mine it recognises that the helicopter and the hand are supposed to be joined, but in yours it doesn't realise that because it doesn't have enough information to.

I really appreciate the effort and interest anyway, thanks a lot :)

[DeathTheSheep]

I think I would rather leave the padding. To my knowledge, most people who use this script use it with scene releases, and the scene has strict rules about cropping :)

So your tweaks are basically to raise badSAD and lower searchparam, but I don't agree with either of those changes. I spent many hours testing badSAD values on different source videos and tabulated the results. Sometimes lower badSAD was worse, but more often it was better.

Searchparam is a hard thing because, as we all keep saying, it really depends on content. Sometimes 4 is best and sometimes 3 is best, and sometimes even 2, but again in testing I've found that 4 is better more often. Higher than 4 can cause warping, so 4 is the sweet-spot more often than not.
I have made the suggestion to Fizick to allow mvtools2 to dynamically change values like blksize and searchparam according to the amount of difference in the frame and he has said he will make that feature, but I don't know when.

The main consequence of using a lower searchparam is that mvtools2 will lose coherence on objects in motion, for example:
Mine (http://www.spirton.com/uploads/60FPS/test-20110607-1-SubJunk.png) - Yours (http://www.spirton.com/uploads/60FPS/test-20110607-1-DeathTheSheep.png)
Mine (http://www.spirton.com/uploads/60FPS/test-20110607-2-SubJunk.png) - Yours (http://www.spirton.com/uploads/60FPS/test-20110607-2-DeathTheSheep.png)
You see how in mine it recognises that the helicopter and the hand are supposed to be joined, but in yours it doesn't realise that because it doesn't have enough information to.

I really appreciate the effort and interest anyway, thanks a lot :)

No problem. It was worth the [search] effort. ;) I guess my major point is, although the higher search ranges (more so than badSAD) can help -- their usefulness is source- and scene-dependent. The issue with that (and 'sweet spot' logic) is that when these larger ranges don't help, they produce even uglier artifacts than that unjoined/blurred plane/hand of yours -- they produce alarming warping (even in slower motion), long trailing artifacts, and/or strangely defined, inconsistent border ghosting. In casual viewing of frame-doubled content, that's a lot more off-putting than the objects that may not be "joined" -- because often (perhaps less often, as you say, but often nonetheless) they are less consistent than the lower search range. But when the big range fails (or jumps at a false bunch of candidates), the artifacts are often more distracting.

And this is why. Like Didee said, the algorithm is too simple, for as the range of potential "good candidate" vectors is increased beyond initial predictors, many more vectors (proportional to r^2!) that coincidentally happen to have a "good" SAD score stand a good chance of being picked, since there would be enough 'red herrings' in a given spatial area. Furthermore, the chance of a vector being designated good may be expected to decrease with increasing search radius -- and though there are safeguards and penalties in place, they are arbitrary thresholds. What's worse, consider this -- because the fields are cohesive (forced to conform to a blksize-dependent lambda), other vectors will be "brought down" by the coincidental presence of a few falsely decent random predictions in a certain far-off place, and as a result of the rest of the vectors trying to seek conformity, the entire field is contorted miserably.

A transformed search would actually generate decent info, since the list of "false positives" (a natural function of search radius) is drastically decreased. Instead of SAD-based ESA, to draw the analogy with x264 motion search modes, if a form of hadamard-transformed exhaustive search (TESA) were performed instead, it would automatically eliminate (or much reduce) the potential effects of these miserably failed searches over a larger distance -- and increase the accuracy of closer searches, too. Obviously, the issue is always what metric to optimize for, and how to more intelligently calculate 'cost' of any given search (Didee brings up "AI").

As it happens, the default search parameter, 2, is almost always 'safest', since it usually produces an acceptable result without a perfusion of ugly artifacts in failed cases.

In both of your two pictures, it appears to me that the artifacts are well within an 'acceptable' range when a scene with such motion is watched in real-time. The low-range search produces a result which is blurrier and not as consistent. But in my experience, it's when the walls start to morph, lines contort across large distances, large jagged ghosting patterns become apparent, etc (common failings of an erroneous large-radius search), that the rules governing the very frame cohesion the system is designed to protect (via lambda, lsad, etc) brings everything down spectacularly.

[LoRd_MuldeR]

It appears that it doesn't handle scene cuts very well:

Sequence 1:
http://img689.imageshack.us/img689/5756/interframe1.png
http://img560.imageshack.us/img560/5233/interframe2.png
http://img13.imageshack.us/img13/4876/interframe3.png

Sequence 2:
http://img219.imageshack.us/img219/1905/interframe4.png
http://img197.imageshack.us/img197/1729/interframe5.png
http://img809.imageshack.us/img809/8026/interframe6.png

[SubJunk]

No problem. It was worth the [search] effort. ;) I guess my major point is, although the higher search ranges (more so than badSAD) can help -- their usefulness is source- and scene-dependent. The issue with that (and 'sweet spot' logic) is that when these larger ranges don't help, they produce even uglier artifacts than that unjoined/blurred plane/hand of yours -- they produce alarming warping (even in slower motion), long trailing artifacts, and/or strangely defined, inconsistent border ghosting. In casual viewing of frame-doubled content, that's a lot more off-putting than the objects that may not be "joined" -- because often (perhaps less often, as you say, but often nonetheless) they are less consistent than the lower search range. But when the big range fails (or jumps at a false bunch of candidates), the artifacts are often more distracting.

And this is why. Like Didee said, the algorithm is too simple, for as the range of potential "good candidate" vectors is increased beyond initial predictors, many more vectors (proportional to r^2!) that coincidentally happen to have a "good" SAD score stand a good chance of being picked, since there would be enough 'red herrings' in a given spatial area. Furthermore, the chance of a vector being designated good may be expected to decrease with increasing search radius -- and though there are safeguards and penalties in place, they are arbitrary thresholds. What's worse, consider this -- because the fields are cohesive (forced to conform to a blksize-dependent lambda), other vectors will be "brought down" by the coincidental presence of a few falsely decent random predictions in a certain far-off place, and as a result of the rest of the vectors trying to seek conformity, the entire field is contorted miserably.

A transformed search would actually generate decent info, since the list of "false positives" (a natural function of search radius) is drastically decreased. Instead of SAD-based ESA, to draw the analogy with x264 motion search modes, if a form of hadamard-transformed exhaustive search (TESA) were performed instead, it would automatically eliminate (or much reduce) the potential effects of these miserably failed searches over a larger distance -- and increase the accuracy of closer searches, too. Obviously, the issue is always what metric to optimize for, and how to more intelligently calculate 'cost' of any given search (Didee brings up "AI").

As it happens, the default search parameter, 2, is almost always 'safest', since it usually produces an acceptable result without a perfusion of ugly artifacts in failed cases.

Honestly, in both of your two pictures, the artifacts are well within an acceptable range. It's when the walls start to morph, lines contort and drag large distances, large jagged ghosting patterns become apparent, etc (common failings of an erroneous large-radius search), the rules of the very frame cohesion the system is designed to protect (via lambda, lsad, etc) brings everything down spectacularly.We definitely all agree that the algorithm is too simple. It would be great if mvtools2 were better suited to this task, or if another plugin were instead, but we must work with what we have :)

It appears that it doesn't handle scene cuts very well:

Sequence 1:
http://img689.imageshack.us/img689/5756/interframe1.png
http://img560.imageshack.us/img560/5233/interframe2.png
http://img13.imageshack.us/img13/4876/interframe3.png

Sequence 2:
http://img219.imageshack.us/img219/1905/interframe4.png
http://img197.imageshack.us/img197/1729/interframe5.png
http://img809.imageshack.us/img809/8026/interframe6.pngYes, we've had a lot of discussions about scene cuts and in the end I decided to not handle them at all because mvtools2 isn't good at detecting them.
No matter which values the scene-cut variables (thSCD1 and thSCD2) are set to, they either detect fast-action sequences as scene-changes or fail to detect scene-changes.
So in the end I decided it is better to always have smooth motion instead of it getting choppy every time something moves quickly.

The final straw was in an episode of Criminal Minds during a scene of running through a corn field. Every single frame in that scene is detected as a scene-change even on modest detection settings :rolleyes:

Edit: It is of course possible to tweak the thSCD values per video for some videos to get accurate scene-changes, but this is a script that is meant to just run with little-to-no configuration.

[DeathTheSheep]

The final straw was in an episode of Criminal Minds during a scene of running through a corn field. Every single frame in that scene is detected as a scene-change even on modest detection settings :rolleyes:

Edit: It is of course possible to tweak the thSCD values per video for some videos to get accurate scene-changes, but this is a script that is meant to just run with little-to-no configuration.

Maybe OT, but which episode was this? :cool:

Weren't there some more accurate scenecut detection filters for Avisynth that can be incorporated instead (as dependencies or whatnot)?

[SubJunk]

Maybe OT, but which episode was this? :cool:I think S06E07 :)

Weren't there some more accurate scenecut detection filters for Avisynth that can be incorporated instead (as dependencies or whatnot)?I'm not aware of any but if anyone knows of one, it would be great to try

Edit: I saw SCSelect() mentioned as being better at detecting scene changes than mvtools2. I don't have the AviSynth scripting knowledge to pull off automatic integration if it's possible, but maybe someone else does?

[DeathTheSheep]

Okay. I increased 'object cohesion' a bit without introducing more artifacts. After comparing with some clips of searchparam 3, I found some interesting culprits. In a lot of cases where it produced the better picture, it wasn't due to an increased motion search at all -- but due to an increased number of good vectors per larger area. The bad effects were mostly caused by the opposite. Two additional simple parameters allowed me to replicate some level of this positive behavior without increasing searchparam -- and therefore drastically reducing the amount of artifacts. Give this puppy a shot with tweaks=true. (Ironically, I don't think it will be of much help on the particular extreme samples you brought up earlier...)


#------------------------------------------------------------------------------#
# #
# InterFrame 2.0pre2 by SubJunk, DeathTheSheep #
# #
# A frame interpolation script that primarily uses MVTools2 for making #
# accurate estimations about the content of non-existent frames #
# Its main use is to give videos higher framerates like newer TVs do #
#------------------------------------------------------------------------------#


# For instructions and further information see the included InterFrame.html
# For news go to spirton.com


function InterFrame(clip Input, string "Preset", string "Tuning", int "NewNum", int "NewDen", string "FlowPath", bool "GPU", string "InputType", float "Pad", bool "Blend", bool "Tweaks") {
# Defaults
Preset = default(Preset , "Medium" )
NewNum = default(NewNum , 0 )
NewDen = default(NewDen , 0 )
Tuning = default(Tuning , "Film" )
FlowPath = default(FlowPath , "Undefined")
GPU = default(GPU , false )
InputType = default(InputType, "2D" )
Pad = default(Pad , 1 )
Blend = default(Blend , true )
Tweaks = default(Tweaks , false )

# Validate inputs
Assert(Preset == "Placebo" || Preset == "Medium" || Preset == "Fast" || Preset == "Faster" || Preset == "Very Fast" || Preset == "Super Fast" || Preset == "Ultra Fast", "'"+Preset+"' is not a valid preset. Please check the documentation for a list of the valid presets.")
Assert(Tuning == "Film" || Tuning == "Smooth" || Tuning == "Smoothfilm" || Tuning == "Animation", "'"+Tuning+"' is not a valid tuning. Please check the documentation for a list of the valid tunings.")
Assert(InputType == "2D" || InputType == "SBS" || InputType == "OU" || InputType == "HSBS" || InputType == "HOU", "'"+InputType+"' is not a valid InputType. Please check the documentation for a list of the valid InputTypes.")
Assert(FlowPath != "Undefined", "You must specify FlowPath. Please check the documentation for details.")

# Get either 1 or 2 clips depending on InputType
InputType == "SBS" ? Eval("""
FirstEye = InterFrameProcess(Input.crop(0 , 0, -Input.Width/2, 0), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
SecondEye = InterFrameProcess(Input.crop(Input.Width/2, 0, 0 , 0), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
StackHorizontal(FirstEye, SecondEye)
""") : InputType == "OU" ? Eval("""
FirstEye = InterFrameProcess(Input.crop(0, 0 , 0, -Input.Height/2), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
SecondEye = InterFrameProcess(Input.crop(0, Input.Height/2, 0, 0 ), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
StackVertical(FirstEye, SecondEye)
""") : InputType == "HSBS" ? Eval("""
FirstEye = InterFrameProcess(Input.crop(0 , 0, -Input.Width/2, 0).Spline36Resize(Input.Width, Input.Height), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
SecondEye = InterFrameProcess(Input.crop(Input.Width/2, 0, 0 , 0).Spline36Resize(Input.Width, Input.Height), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
StackHorizontal(FirstEye.Spline36Resize(Input.Width/2, Input.Height), SecondEye.Spline36Resize(Input.Width/2, Input.Height))
""") : InputType == "HOU" ? Eval("""
FirstEye = InterFrameProcess(Input.crop(0, 0 , 0, -Input.Height/2).Spline36Resize(Input.Width, Input.Height), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
SecondEye = InterFrameProcess(Input.crop(0, Input.Height/2, 0, 0 ).Spline36Resize(Input.Width, Input.Height), Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType)
StackVertical(FirstEye.Spline36Resize(Input.Width, Input.Height/2), SecondEye.Spline36Resize(Input.Width, Input.Height/2))
""") : Eval("""
InterFrameProcess(Input, Preset=Preset, Tuning=Tuning, NewNum=NewNum, NewDen=NewDen, FlowPath=FlowPath, GPU=GPU, InputType=InputType, Pad=Pad, Blend=Blend, Tweaks=Tweaks)
""")
}

function InterFrameProcess(clip Input, string "Preset", string "Tuning", int "NewNum", int "NewDen", string "FlowPath", bool "GPU", string "InputType", float "Pad", bool "Blend", bool "Tweaks") {
#Assign defaults to Tweakable values
rfilter_val = 4
overlap_val = (Tuning == "Smoothfilm") ? 6 : 4
overlap_val2 = 2
sp_val = 4
sp_val2 = 3
sp_val3 = 1
badSAD_val = 2000
plevel_val = 0
dct_val = (Tuning == "Smoothfilm") ? 8: 5
BlockSize = (Tuning == "Film") ? 16 : \
(Tuning == "Animation" ) ? 32 : \
(Tuning == "Smooth" ) ? 8 : 16
lambda_val = 1000 * BlockSize * Blocksize / 64
lsad_val = 1200

#Apply Tweaks (if applicable) by changing some variables
Tweaks == true ? Eval("""
rfilter_val = 4
overlap_val = (Tuning == "Smoothfilm") ? 6 : 4
overlap_val2 = (Tuning == "Smoothfilm") ? 4 : 2
sp_val = 2
sp_val2 = 2
sp_val3 = 2
badSAD_val = 20000
plevel_val = 0
dct_val = (Tuning == "Smoothfilm") ? 8: 5
lambda_val = 1000 * BlockSize * Blocksize / 128
lsad_val = 1600
""") : Eval(""" """)


# Create processed clip for slower presets
Preset == "Placebo" || Preset == "Medium" || Preset == "Fast" || Preset == "Faster" ? Eval("""
ProcessedSource = Input.RemoveGrain(mode=17)
""") : Eval("""
# Don't want ProcessedSource
""")

# Create super clip/s
SuperRegular = MSuper(Input, hpad=Floor(Pad*BlockSize), vpad=Floor(Pad*BlockSize), rfilter=rfilter_val)

Preset == "Placebo" ? Eval("""
CustomPelClip = EEDI2(Input, field=1).Spline36Resize(2*width(Input), 2*height(Input), src_left=0.25)

Super = MSuper(ProcessedSource, hpad=Floor(Pad*BlockSize), vpad=Floor(Pad*BlockSize), rfilter=rfilter_val, pelclip=CustomPelClip)
""") : Preset == "Medium" ? Eval("""
Super = MSuper(ProcessedSource, hpad=Floor(Pad*BlockSize), vpad=Floor(Pad*BlockSize), rfilter=rfilter_val)
""") : Eval("""
Super = MSuper(Input, hpad=Floor(Pad*BlockSize), vpad=Floor(Pad*BlockSize), rfilter=rfilter_val)
""")

# Make interpolation vector clip
Preset == "Ultra Fast" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=true , badSAD=badSAD_val, chroma=false, lambda=lambda_val, lsad=lsad_val)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=false, badSAD=badSAD_val, chroma=false, lambda=lambda_val, lsad=lsad_val)
""") : Preset == "Super Fast" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val, lambda=lambda_val, lsad=lsad_val)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val, lambda=lambda_val, lsad=lsad_val)
""") : Preset == "Very Fast" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val, lambda=lambda_val, lsad=lsad_val)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val, lambda=lambda_val, lsad=lsad_val)
backward = MRecalculate(Super, backward, blksize=8, searchparam=sp_val3, overlap=overlap_val2)
forward = MRecalculate(Super, forward, blksize=8, searchparam=sp_val3, overlap=overlap_val2)
""") : Preset == "Faster" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val, search=3, pelsearch=3, lambda=lambda_val, lsad=lsad_val)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val2, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val, search=3, pelsearch=3, lambda=lambda_val, lsad=lsad_val)
backward = MRecalculate(Super, backward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3)
forward = MRecalculate(Super, forward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3)
""") : Preset == "Fast" ? Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val, search=3, pelsearch=3, lambda=lambda_val, lsad=lsad_val)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val, search=3, pelsearch=3, lambda=lambda_val, lsad=lsad_val)
backward = MRecalculate(Super, backward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3)
forward = MRecalculate(Super, forward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3)
""") : Eval("""
backward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val, plevel=plevel_val, isb=true , badSAD=badSAD_val, overlap=overlap_val, search=3, dct=dct_val, pelsearch=3, lambda=lambda_val, lsad=lsad_val)
forward = MAnalyse(Super, blksize=BlockSize, searchparam=sp_val, plevel=plevel_val, isb=false, badSAD=badSAD_val, overlap=overlap_val, search=3, dct=dct_val, pelsearch=3, lambda=lambda_val, lsad=lsad_val)
backward = MRecalculate(Super, backward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3, dct=dct_val)
forward = MRecalculate(Super, forward, blksize=8, searchparam=sp_val3, overlap=overlap_val2, search=3, dct=dct_val)
""")

# Determine new framerate
NewNum != 0 ? Eval("""
# Use user values
""") : Input.Framerate == 25 ? Eval("""
NewNum = 50
NewDen = 1
""") : Input.Framerate == 30 ? Eval("""
NewNum = 60
NewDen = 1
""") : Eval("""
NewNum = 60000
NewDen = 1001
""")

# See whether to use GPU-acceleration or not
svp_flow_lib = GPU == true ? FlowPath+"libflowgpu.dll" : FlowPath+"libflowsse.dll"
Finest = GPU == true ? SuperRegular : MFinest(Input, SuperRegular)

# Put it together
MSmoothFps(Input, SuperRegular, backward, forward, finest=Finest, num=NewNum, den=NewDen, algo=23, ml=0, sadml=0, sadgamma=2, block=false, blend=Blend)
}

[SubJunk]

OK, I'll have a look soon :)
P.S. The next version will either be 1.9.1 or 1.10, not 2.0 :)

[magnetite]

I know you guys were talking about using your CPU and GPU combined to do real time transcoding. However, is it possible for Interframe to use both your CPU and GPU at the same time for re-encoding? I know you have to choose between the two, but if you've got a system with the latest hardware, it would be kind of cool to see if that would work or not. It would increase the speed of the script if both were used.

[SubJunk]

I know you guys were talking about using your CPU and GPU combined to do real time transcoding. However, is it possible for Interframe to use both your CPU and GPU at the same time for re-encoding? I know you have to choose between the two, but if you've got a system with the latest hardware, it would be kind of cool to see if that would work or not. It would increase the speed of the script if both were used.Sure, it has been possible for months by using the GPU parameter, like:
InterFrame(GPU=true, FlowPath="C:\Program Files\AviSynth 2.5\plugins\")
:)

[magnetite]

Oh okay, I was a bit confused earlier about that. I thought GPU=true used the GPU only, and the CPU would be idle, but I guess not.

[SubJunk]

Oh okay, I was a bit confused earlier about that. I thought GPU=true used the GPU only, and the CPU would be idle, but I guess not.I'll clarify that in the documentation now :)

[magnetite]

That's a big improvement. I was getting roughly 160 FPS before, and I just tested a video, and now I'm getting 200 FPS.

[SubJunk]

Great! :)

[DeathTheSheep]

How does "SmoothFPS" work? It's a bit different than FlowFPS for a few reasons (GPU acceleration support, better frame blending when good matches aren't found, faster, etc). I see there are parameters I've never seen before in an mvtools2 function. What do they control? For instance, there's a parameter that I believe deals with the algorithm used to interpret and create the new frame -- but which "algo" does what? I can't seem to find any other info on this function.

[SubJunk]

algo=1, block=false = MFlow
algo=11, block=true = MBlockFps(mode=0)
algo=12, block=true = MBlockFps(mode=1)
algo=13, block=true = MBlockFps(mode=2)
algo=21, block=false = MFlowFps(mask=0)
algo=22, block=false = MFlowFps(mask=1)
algo=23, block=false = MFlowFps(mask=2)

That's a rough estimation, but there are some differences, especially with algo=13 which is quite different to anything in the official mvtools2 release.

P.S. I'm still testing the script you gave and I might use some of it, but I'm being very careful and testing a lot of different videos.

[dfan]

For I avoid that artifacts, I configure in MAnalyse: delta=0 (for back) and delta=-2 (for forw). But using MAnalyse's delta, the script loses estimation power :\

[SubJunk]

InterFrame 1.10 is released. See the first post for details and enjoy :)

Edit: I also updated the sample videos

[edison]

http://www.mediafire.com/file/33w33iqfjlgxa5l/svp_artifacts_supression_high_vs_interframe_720p.mkv

The artifacts supression settings of SVP is very useful in some case although somtimes will cause blending look, how can I enabled similar thing with InterFrame ?

[CruNcher]

http://www.mediafire.com/file/33w33iqfjlgxa5l/svp_artifacts_supression_high_vs_interframe_720p.mkv

The artifacts supression settings of SVP is very useful in some case although somtimes will cause blending look, how can I enabled similar thing with InterFrame ?

the first look says interframe smokes svp smoothness wise in this case very impressive :) hehe btw that compare remembers me of this split compare though for superresolution with the avatar source ftp://ftp.cs.huji.ac.il/users/raananf/demo.mpg

Only near Realtime CPU, GPU, FPS, Memory utilization (CPU&GPU) and Frame Number visualization is missing in your compare for both then it would be perfect, and yeah in very very very high motion sequences you see the prediction issues but in lower motion they not visible and the smoothness wins overall ;)

[SubJunk]

The artifacts supression settings of SVP is very useful in some case although somtimes will cause blending look, how can I enabled similar thing with InterFrame ?I don't offer the SVP-like settings because I don't think it looks good, but if you want it you can manually change line 132 from algo=23 to algo=13.

the first look says interframe smokes svp smoothness wise in this case very impressive :)Thanks a lot :)