InterFrame 2.8.2 - Framedoubling/60FPS/HFR conversion script

[TCmullet]

SubJunk,

Concerning the error message, "SVSmoothFps: unable to init FlowLib [code 0x100FF]", can't you at least tell me what it (or at least the code part) means and perhaps why it doesn't help you (or the SVP boys) to debug this problem?

A parallel question perhaps would be in order. Should I have been able to copy over the openCL.dll from my old SVP folder (2012) and expect it to work? When it didn't (and that Groucho fellow alerted me to the idea that maybe it's tailored to a particular graphics card--the one that installed it), I began to agree with him, and pursued the Intel one for my own chip (Intel HD Graphics is what it's simply called). Of course the openCL from my old SVP folder (which I had forgotten I had) is obviously old (2012).

[SubJunk]

I don't know what that error message means but to me it looks like a generic initialization error, and I'm not sure if locating the correct version of openCL.dll is the right approach.

Edit: In my case, I still have the issue despite having the correct openCL.dll file on my system, so that's probably not the fix.

[Andrey /MAG/]

TCmullet,
SubJunk is right. It is message about initialization error.
You don't need to install OpenCL alone. You don't need to copy it from SVP or another location. You just need to install later drivers for you videocard. For HD Graphics you need to go to intel site and download it. Select 32 or 64 bit by your OS ditdepth.

OpenCL.dll in SVP folder is a helper for the last way to determine OpenCL-compatibility to systems without OpenCL installed. It is not OpenCL to work with. SVP don't use it while smoothing. It use system OpenCL installed with graphic drivers.

[SubJunk]

Thanks to Mag's help I have fixed the issue for me - the problem was that MeGUI has a dummy version of OpenCL.dll in one of its folders and it works after deleting that.

[TCmullet]

TCmullet,
SubJunk is right. It is message about initialization error.
You don't need to install OpenCL alone. You don't need to copy it from SVP or another location. You just need to install later drivers for you videocard. For HD Graphics you need to go to intel site and download it. Select 32 or 64 bit by your OS ditdepth.

OpenCL.dll in SVP folder is a helper for the last way to determine OpenCL-compatibility to systems without OpenCL installed. It is not OpenCL to work with. SVP don't use it while smoothing. It use system OpenCL installed with graphic drivers.
Wow, you've given me hope, Mag! Thanks!

But I'm still a hurtin.

I had installed Intel's openCL runtime. (I had picked the one that installs both 32 and 64.) I see now (thanks to you) that I needed to update video adapter driver. I did go to Intel again per your suggestion, but a warning there implied that I should go to mobo mfgr as they may have modified things.

I went to Gigabyte and found VGA driver for my mobo and cpu. (Took quite a bit of searching to confirm that I have the Sandybridge i5 cpu. Gigabyte required that I know that.) The installer simply expanded itself as though I was creating a CD. I ran from what would be the CD's root dir, the "setup.exe" to completion (requiring reboot). One of the folders was "openCL", so I ran that exe next (which did not require reboot). However, the 2 openCL.dlls that I had installed earlier via the openCL-only package from Intel (with file dates 1/25/2015) were still there. Intuition told me that the current Gigabyte-picked driver's openCL installer "saw" the later dates and left both of them there in the two system folders. I unstalled the openCL runtime which did not remove the two 1/25 files. I deleted the 2 copies of openCL.dll manually. Then ran (again) the openCL installer that came with the Gigabyte-approved driver. It DID put 2 new dll files there (system32 and sysWOW64).

Here it gets a little interesting. The 2 prior dlls dated 1/25/2015 were bigger than the 50K dll in the SVP folder (2012), as I recall. But the ones there now (from the Gigabyte approved full driver package) are only 18K and dated 5/15/2012.

And sadly, InterFrame fails again.
SVSmoothFps: unable to init FlowLib [code 0x10000]

Help, please!

[foxyshadis]

Ouch. Forget that OEM junk, unless you want to work with a 2012 video driver. Stick with the latest Sandybridge (aka 2nd generation Core) driver direct from Intel -- despite the warning, OEMs don't really do any useful customization beyond slapping their logos on things, and everyone in the know goes direct.

[SubJunk]

I just checked VirtualDub and it worked for me so that might narrow the issue down.

Edit: what foxyshadis said

[TCmullet]

Ouch. Forget that OEM junk, unless you want to work with a 2012 video driver. Stick with the latest Sandybridge (aka 2nd generation Core) driver direct from Intel -- despite the warning, OEMs don't really do any useful customization beyond slapping their logos on things, and everyone in the know goes direct.
Did so. Multiple times. Still no go. (But I stand a bit wiser, uh "in the know" now, thanks to you, Foxyshadis.)

Should I add on the openCL runtime that Intel provides separately? It will definitely get a new pair of openCL.dlls in there. (The "current" intel driver puts them with 5/15/2012, still old - and older than when I ran the OpenCL runtime package earlier without the newer driver.)

[TCmullet]

I followed my own question. I attempted to install the new OpenCL runtime again. But it said I must uninstall the older one. I don't know if "older one" meant what I had erroneously installed earlier before I knew to update the graphics driver or if it meant the one installed by the new driver.

Either way, I went to control panel and found the Intel OpenCl runtime and unstalled it. Installed the new one I had gotten previously. Yes, the openCL.dlls are now 1/25/2015.

But InterFrame STILL fails to initialize!

What's NEXT?????

[TCmullet]

Me again, w/further news.

I discovered a simple tool called GPU-Z by TechPowerup. At bottom of it's main panel in which it shows lots of textboxes with display-only data about my adapter, it has a line saying "Multi-GPU: Disabled". That doesn't scare me as I woulda guessed I have only 1 GPU.

The next and last line says Computing: and has 4 checkboxes, each for one of "OpenCL", "CUDA", "PhysX" and "DirectCompute". All 4 are unchecked (and uncheckable). When I hover mouse over the first one, a pop-up says "OpenCL: Shows whether OpenCL is available on this adapter".

I'm scared. What does this imply for what I will have to do to get OpenCL to work??

SubJunk, can you be open to the idea of writing "fallback" code to emulate in non-GPU code what computations the GPU is doing when you do call the GPU? This is, I believe standard practice when writing code for multiple levels of hardware--"get the app to do in software what would be better done in hardware IF the hardware was available". Uh, maybe it's not SubJunk, but someone at SVP?? (But of course, I still would have as a goal getting my system to use OpenCL.)

[SubJunk]

It's possible your video card just doesn't support the things that SVP needs. It's possible Chainik would be able to implement the GPU code in CPU mode but when I asked about it years ago I think he said it isn't possible. Maybe he'll reply here to clear it up.

[TCmullet]

I was a computer programmer once (before I became obsolete too late). And it was always in the forefront of my mind that "any process that can be defined can be programmed". More explicity, if the algorithm is defined and implemented in one programming context, it should be able to be implemented in any other computing context. You're simply computing numbers, etc. Should be doable. Now whether it would be easy, that's another question. We were all gooey eyed when the Motorola 6809 processor was revealed and it had (big long drum roll....) HARDWARE multiply instruction! Before then you had to write subroutine to do simple multiply. I would think the same concept would apply here in the graphics computing arena. But of course I don't know the hardware/programming context, so I could be out to lunch, at least in part.

Had a chance to confirm things with a local tech. For sure these onboard adapters do not have openCL. Have to get a graphics adapter. He helped me to see that (1) the onboard adapter has no memory of it's own; (2) it steals memory from the main bank of 16GB, leaving 15.9GB "usable". That means I'm doing all my graphics on a mere 100MB! No money, but I DO have an old ATI w/512MB that might be DDR3 compatible (he says). Gotta do bit of research. If I have DDR3 (which I do) and the card is DDR3 compatible, and I have the right slot, I'll have my card and eat it too!

[SubJunk]

Hope the old ATI card works :)

[foxyshadis]

I was a computer programmer once (before I became obsolete too late). And it was always in the forefront of my mind that "any process that can be defined can be programmed". More explicity, if the algorithm is defined and implemented in one programming context, it should be able to be implemented in any other computing context. You're simply computing numbers, etc. Should be doable. Now whether it would be easy, that's another question. We were all gooey eyed when the Motorola 6809 processor was revealed and it had (big long drum roll....) HARDWARE multiply instruction! Before then you had to write subroutine to do simple multiply. I would think the same concept would apply here in the graphics computing arena. But of course I don't know the hardware/programming context, so I could be out to lunch, at least in part.

Had a chance to confirm things with a local tech. For sure these onboard adapters do not have openCL. Have to get a graphics adapter. He helped me to see that (1) the onboard adapter has no memory of it's own; (2) it steals memory from the main bank of 16GB, leaving 15.9GB "usable". That means I'm doing all my graphics on a mere 100MB! No money, but I DO have an old ATI w/512MB that might be DDR3 compatible (he says). Gotta do bit of research. If I have DDR3 (which I do) and the card is DDR3 compatible, and I have the right slot, I'll have my card and eat it too!

Sandy Bridge doesn't really work that way. Yes, it does have a unified memory architecture (as in, it steals from main memory), but it can address up to 1.7GB. Slowly.

I have several Sandy Bridge PCs at work I can test on tomorrow, but unfortunately I just found some bad news (https://software.intel.com/en-us/articles/opencl-sdk-frequently-asked-questions/#10): Ivy Bridge is the first Intel integrated GPU to support OpenCL. The Sandy Bridge OpenCL drivers must all be unsupported testing software that was never final, so it was never fixed to work.

Unfortunately, OpenCL code is very different from typical procedural CPU code, and because of the way OpenCL is built, it's not as simple as targeting it to the CPU. (Bizarrely, though, if your igpu supports OpenCL, only then can you run OpenCL code on the CPU instead. That's an Intel restriction.) Your AMD should be at least a 7000-series to support OpenCL 1.1 that SVP needs. Some 6000-series should work as well.

[TCmullet]

...(Bizarrely, though, if your igpu supports OpenCL, only then can you run OpenCL code on the CPU instead. That's an Intel restriction.)
All good stuff you said. But "running opencl code on the cpu instead" is not what I meant. I was speaking of rewriting the algorithmic portions necessary in native CPU code. I didn't know that there was such a thing as running opencl code on a cpu. If there is, great. But if not, native cpu code is what I meant.

[TCmullet]

Hope the old ATI card works :)
Thanks, Sub. But more bad news, doubly so.

That ATI turned out, which closer inspection of tiny model info on the card showed, to be an AGP card!

I have 2 main system. "Main" one is a big ol' Dell w/Pentium 4HT 3.0 ghz and hyperthreading. 24" very good LG monitor, "can't live without the 24 now that I'm hooked". I knew I had a graphics adapter so as to use DVI cable, but forgot what I had.

12/2012 I was able to acquire a custom-assembled i5-2400S quad-core. I do HD capture and all processing of video files there. (Only 22" monitor with vga cables.) It's worked great til this OpenCL issue.

I keep equip. boxes, and have box for Evga 210 card w/512mb, but couldn't remember where I installed it. Turns out it is in the P4HT! But the P4HT is way to slow to do video file processing. So I would remove the 210 card reverting to builtin adapter. It does do my 1920x Windows XP screen okay.

I put the Evga 210 into the i5 thinking "all will be well". Failed to even come after I changed the bios from "built-in adapter" to "auto".

Then I found the answer to everything. Evga box says "This graphics card requires: 300 watt or greater power supply with a minimum of 18 amps on the +12 volt rail". Not a problem. I'm "sure" the builder put one bigger than that in there. But had to be sure. Took case off, and drat, can't see labelling. Had to partially lift the supply out of the case to read this:
Output: 250W max
+12v: 14A

Raaaaaaaaats!

So I'll be running InterFrame only on my slow Atom330 (1.6 ghz) until can save up for a power supply. (This comes at a very bad dollar time.)

Need power supply to run video card. Need video card to run OpenCL. Need OpenCL to do best possible InterFrame (lacking non-GPU fallback code). Need InterFrame to create the videos I need for a major project. Such is life at times.

(100+GB Lagarith files will be slowly and frequently migrating between my systems for weeks now.)

[SubJunk]

I'd be happy to do some conversions for you. I have unlimited Internet bandwidth and a fairly fast computer.

[TCmullet]

I'd be happy to do some conversions for you. I have unlimited Internet bandwidth and a fairly fast computer.
You are very kind, friend. But each Lag. file is on order of 100GB output from InterFrame, then I'll feed that file into AviSynth again with nothing but SuperRes. (And it's not just the intermediate files that are big, but the finals will be too, even though the intial source is generally tiny FLVs.) I don't think we can tranfer the files between us as timely as would be necessary. And I still have research on final encoding parameters needed for this special project.

Plus this would be many such conversions in the days ahead. No, I have to tackle this myself. Will speed up once I get a pwr supply some weeks from now.

At present, I'm bombing so much with Lagarith as intermediate file that I'm currently evaling other codecs, notably x264vfw and the newly released MagicYUV. (The latter even as we speak.)

[TCmullet]

It's possible Chainik would be able to implement the GPU code in CPU mode but when I asked about it years ago I think he said it isn't possible. Maybe he'll reply here to clear it up.
I would guess he meant, "No it's not possible to EASILY fix this." - whether he meant get the GPU code to run in CPU mode or totally rewrite the GPU functional logic in native CPU instructions. (The latter is the only option I was suggesting.)

I'm sure that rewriting a non-GPU equivalent of the GPU portion of the code would be very tedious, even though I believe that conceptually it must be possible. (Just like it was possible to write a software Multiply instruction back in the days when the microprocessors didn't have a hardware Multiply.)

[SubJunk]

Cool, no problem. By the way, I recommend using H.265 for the intermediate files if you aren't already; even at lossless quality it should have a much smaller filesize than any other codec. It almost seems impossible how small the files get but I've done lots of encodings with it and sure enough it looks amazing. The jump between H.263 and H.264 was good but subtle if you knew the good XviD settings, but H.265 is so far beyond both of them it's no contest.

[TCmullet]

Cool, no problem. By the way, I recommend using H.265 for the intermediate files if you aren't already; even at lossless quality it should have a much smaller filesize than any other codec. It almost seems impossible how small the files get but I've done lots of encodings with it and sure enough it looks amazing. The jump between H.263 and H.264 was good but subtle if you knew the good XviD settings, but H.265 is so far beyond both of them it's no contest.Funny you suggest this now. It was early today that my exasperation at Lagarith blowing for unknown reasons drove me to discover and try MagicYUV and also act on my thin knowledge of x264 and x264vfw.

After experimenting all day, I'm starting to use x264vfw at cq=0 (lossless) with "Ultrafast" to generate the intermediate file output from Avisynth including InterFrame as the last step of that. And just now, also after much testing, I started a run of my first video (a 2 hour one) with x264vfw with cq=15.

And now you want me to drop all that and go with H265! I'm game, but pray tell where does one get a binary of it, especially one that is vfw so I can encode from VirtualDub?

[SubJunk]

x265 is the H.265 encoder I use, but I don't think they have a vfw version. However you can always switch to MeGUI for middle steps unless there's a reason you need VirtualDub for all stages

[TCmullet]

I need VirtualDub to run Video Enhancer (aka Super Res) as the only filter before the vfw encoding (or Super Res as Avisynth plugin).

I just got the x265, but it appears to be a command line only.

I just got the x265gui, aka "Internet Friendly Media Encoder", but seems like a piece of trash, as it doesn't tell you anything about setting it up to use x265 (like how to point to the cmd line executable for one), even in their online documentation. Crazy. I'm inclined to hate everything about it, esp. as the site that gave it and the cmdline x265 seemed to say you can use this gui with x265.

It's okay if no vfw IF I can pipe AviSynth into it.

Hey, why don't you tell me exactly what YOUR setup is like for executing a Vdub filter (or Avisynth output) and running it right into x265? (Please?)

[SubJunk]

My setup is just to use MeGUI for everything, since I find it to be a very transparent tool. If you see my guide for using InterFrame (http://www.spirton.com/convert-videos-to-60fps/) it explains what my setup is, just replace the script with your script, and use x265 instead of x264. MeGUI includes both of those encoders.

[TCmullet]

Okay I've cooled down a bit and studied it a bit more, including some info here:
http://www.softpedia.com/get/Multimedia/Video/Encoders-Converter-DIVX-Related/Internet-Friendly-Media-Encoder.shtml

Seems you're expected to have a source file all ready to convert to h265. No I want to run Avisynth into it, or run plugin Virtualdub filter, THEN output to an encoder. I don't see how I can use this, even if all I had was InterFrame as the needed task.

[TCmullet]

Oh, we were posting at the same time. Okay, I'll go back there and get MeGUI as per whatever it says there. (I'm trusting I can add a bunch more Avisynth items PRECEDING the invocation of InterFrame.) Thanks.

[SubJunk]

Like I said, use MeGUI instead of that program. It accepts AviSynth scripts, and even has a useful AviSynth templating interface (ctrl+r)

Edit: Cool, I hope it works well for you, and yes you can add whatever you want into the AviSynth script

[TCmullet]

Like I said, use MeGUI instead of that program. It accepts AviSynth scripts, and even has a useful AviSynth templating interface (ctrl+r)

Edit: Cool, I hope it works well for you, and yes you can add whatever you want into the AviSynth script

But will the output of that (a file encoded in x265) be inputable into VirtualDub??

And may I add an even more off-point question? I have been oblivious to the whole area of colorspace conversions. I'm not color-blind, but my eyes may be somewhat color insensitive, as I don't easily see subtle color differences. I've heard that a drawback to Vdub is that all output is RGB. Yet in Avisynth, some functions require me to convert to YV12 which I am ("ConvertToYV12()"). If Avisynth is outputting YV12 and I immediately read it in Vdub and do some things and send to an encoder, is Vdub converting it back to RGB needlessly before sending it out? Vdub has SO many features unknown. Can you advise a little, please? (And it may help someone else who reads this.) Seems to me I recall this issue is a reason why VirtualDubMod was born (VdubMod using YV12 instead of RGB), but it's rather obsolete I heard.

[creaothceann]

But will the output of that (a file encoded in x265) be inputable into VirtualDub??
Of course it will be if you use Avisynth for opening and have a h.265 decoder installed.

I have been oblivious to the whole area of colorspace conversions. I'm not color-blind, but my eyes may be somewhat color insensitive, as I don't easily see subtle color differences. I've heard that a drawback to Vdub is that all output is RGB.
All VirtualDub filters operate in RGB colorspace. If you do this (http://i.imgur.com/26fYir4.png) then the data will be passed directly to the encoder (and of course you can't use VirtualDub filters). I use VirtualDubMod because in the preferences I can set this mode to be the default one. (This was also explained in the link in my last post (http://www.animemusicvideos.org/guides/avtech/colorspace.html).)

Yet in Avisynth, some functions require me to convert to YV12 which I am ("ConvertToYV12()"). If Avisynth is outputting YV12 and I immediately read it in Vdub and do some things and send to an encoder, is Vdub converting it back to RGB needlessly before sending it out?
Yes, it'll immediately decode it to RGB unless you do the step above.

Seems to me I recall this issue is a reason why VirtualDubMod was born (VdubMod using YV12 instead of RGB), but it's rather obsolete I heard.
VirtualDubMod also uses RGB. And it's not obsolete if you only use it to connect Avisynth scripts, video files, decoders and encoders.

[bxyhxyh]

It is bit off topic to this thread. But I wanted to confirm this

Yes, it'll immediately decode it to RGB unless you do the step above.

Is what you wrote really true?

When I open YV12 video via Avisynth, its file information says Decompressor: Internal DIB Decoder (YV12) and in Option->Performance->AVI section, there is a checkbox labeled Directly Decode Uncompressed YCbCr (YUV) sources is checked. Even if I uncheck it, file information says Decompressor: Xvid MPEG-4 Codec (YV12)

Edit: Never mind, it was about input. Not output. Sorry.

[creaothceann]

When I open YV12 video via Avisynth, its file information says Decompressor: Internal DIB Decoder (YV12) and in Option->Performance->AVI section, there is a checkbox labeled Directly Decode Uncompressed YCbCr (YUV) sources is checked. Even if I uncheck it, file information says Decompressor: Xvid MPEG-4 Codec (YV12)
Save the file without selecting a compressor, then open it with AVISource("file2.avi").info - it'll say "RGB24" which means the original data has been converted.

[Music Fan]

With Virtual Dub, you can choose the decompression format and output format in video, color depth to let yv12 in yv12 (among others).

[chainik_svp]

It's possible Chainik would be able to implement the GPU code in CPU mode but when I asked about it years ago I think he said it isn't possible. Maybe he'll reply here to clear it up.

:D

At the beginning OpenCL implementation was a "rewritten CPU code", pixel-to-pixel identical to MVTools output.
Now it's using some features GPU can do hell more efficient (difference is like tens times I think) so there's no way back :)

[SubJunk]

InterFrame 2.8.0 is released! It updates to the newest versions of SVP libraries and updates documentation, like descriptions and examples. Enjoy :)

[TCmullet]

Great! Thanks! Uh, it's not clear... Should we copy those 2 "dependency" dlls over the ones we have now? And should we do so even if they are smaller that the prior ones??

[Sparktank]

Great! Thanks! Uh, it's not clear... Should we copy those 2 "dependency" dlls over the ones we have now? And should we do so even if they are smaller that the prior ones??

Replace existing "svpflow1.dll" + "svpflow2.dll" with these newer ones.
Delete existing "svpflow_cpu.dll" + "svpflow_gpu.dll" if any because they are now merged into "svpflow2.dll".

Same goes for any installation if using SVP (http://www.svp-team.com/).

[TCmullet]

At this moment, upgrading is dangerous. Replacing the files svpflow1.dll and svpflow2.dll causes other things to blow up!

Here's the discussion going on right now (which is a discussion about GameDrop, a script to replace duplicated frames with generated ones):

http://www.svp-team.com/forum/viewtopic.php?pid=47325#p47325

On the surface, it looks like the new SVP code is defective, if using causes things to blow up that didn't before.

[Sparktank]

Here's the discussion going on right now (which is a discussion about GameDrop, a script to replace duplicated frames with generated ones):

http://www.svp-team.com/forum/viewtopic.php?pid=47325#p47325

Interframe gets its libraries from SVP developers.
http://forum.doom9.org/showthread.php?t=164554

Hardly anything in that thread directly related to Interframe.
Interframe is a much simpler alternative to SVP.

I would suggest you could bring this up in the "SVPflow motion interpolation" thread here, but you're already over there.

[TCmullet]

I suppose I can try the new dlls with the new InterFrame, and maybe the new InterFrame does not use the dll logic that is defective. But it simply seems dangerous to convert to new dlls when doing so causes scripts that were working to not work. (InterFrame isn't the only thing I use Avisynth or svpflow*.dll for.)

I posted there as part of the GameDrop script discussion, but added a warning here, as the new dlls are used by both.

[TCmullet]

I posted there as part of the GameDrop script discussion, but added a warning here, as the new dlls are used by both.
Mag79, one of the SVP developers, has noticed it there and is looking into it.

[chainik_svp]

SVConvert function is broken, but don't panic :D It isn't used by Interframe

[TCmullet]

SVConvert function is broken, but don't panic :D It isn't used by Interframe
Good to know. But I need to use GameDrop before I then use InterFrame on the same video program. (Doesn't it make sense? I recover lost frames with GameDrop, then take the repaired video and convert 30-to-60 fps.)

Can you assure me that the new dlls do not affect the video output of GameDrop? That is, they improve speed, but no difference in quality of frame generation. I could revert back to the prior dlls for GameDrop (which at least do not blow up), then go forward with the broken ones for the new InterFrame. But only if you (perhaps in consultation with SubJunk) affirm that GameDrop's functionality (the content of any generated frames) is not improved by the new dlls.

(And I do like those big smiling teeth of yours.) :)

[SubJunk]

@TCmullet you can easily verify it for yourself in probably less time than it took to write these replies ;) for what it's worth I tested the new DLLs before releasing the update (as I always do) and there is no difference in the quality, except that it has potentially improved when using the "Fastest" and "Animation" tunings

[TCmullet]

@TCmullet you can easily verify it for yourself in probably less time than it took to write these replies ;) for what it's worth I tested the new DLLs before releasing the update (as I always do) and there is no difference in the quality, except that it has potentially improved when using the "Fastest" and "Animation" tuningsI didn't write it so have no basis for NOT knowing that subtle things might have been changed (in the output of GameDrop, that is). Can't take weeks to look under every crevice, that's why a word from you all is the solution.

[TCmullet]

SubJunk,

Would you please look at these? I've created and uploaded 2 short AVIs encoded losslessly with the x264vfw codec. Though short, they're still too big to be attachments, so they are on my own server.

http://www.tomsgoodfiles.com/Test-ball-motion.x264v-q0.504p30.avi
http://www.tomsgoodfiles.com/Test-ball-motion.x264v-q0.504p60.avi

The foreground has two talking heads; ignore them as it's the action behind them that is of interest. (This is a good clip to study this problem.)

The first clip (p30) was input to InterFrame, and yes GPU was true.

Play them, then in the 2nd one (60fps output from InterFrame), please observe the "double" ball near the middle in frame 45.

Why am I not able to generate a frame that positions the ball at the spot between those two balls, but instead makes a "double exposure"? Especially in light of this promo graphic:
http://www.svp-team.com/wiki/File:Memc.jpg

[chainik_svp]

Why am I not able to generate a frame that positions the ball at the spot between those two balls

I think you know where to ask the question :D Definitely not here...
And just an advice - when you'll be asking, please attach two adjacent frames that make an aritifac plus the exact AVS script.

[TCmullet]

Why am I not able to generate a frame that positions the ball at the spot between those two balls

I think you know where to ask the question :D Definitely not here...
And just an advice - when you'll be asking, please attach two adjacent frames that make an aritifac plus the exact AVS script.
I just went thru (in recent days) great lengths to conclude that the place to ask anything about SubJunk's InterFrame WAS here and not there.

And I thought you all WOULD like a specially cut video showing the works in place in a real video. Okay, I'll repost there (http://www.svp-team.com/forum/viewforum.php?id=7 in a new thread), will include the links for the videos, plus will include 2 pics plus the generated one. (Oh, and also the script.)

(But SubJunk, if you want to address this, I welcome your thoughts.)

Chainik, perhaps you will say the reason for this is that SVP has the underlying code. Yes, I knew that. But I had thought that SubJunk and his thread here was the correct place. I'm trying...

[TCmullet]

Why am I not able to generate a frame that positions the ball at the spot between those two balls

I think you know where to ask the question :D Definitely not here...
And just an advice - when you'll be asking, please attach two adjacent frames that make an aritifac plus the exact AVS script.
I've done so, here:
http://www.svp-team.com/forum/viewtopic.php?id=2429

[raffriff42]

The ball is probably moving too fast for the given search radius. It's also quite small and moving behind foreground objects. A very difficult problem. Search radius (http://www.svp-team.com/wiki/SVP:Profile#Search_radius)
Limits the maximum length of motion vectors. Large radius is not always better than small, because the found "far" motion vector may be incorrect, resulting in more artifacts.

[SubJunk]

2.8.0.1 is released, which doesn't change anything to do with InterFrame so feel free to skip it unless you use SVPflow DLLs for something else :) Thanks chainik for the fix!