View Full Version : InterFrame 2.8.2 - Framedoubling/60FPS/HFR conversion script
Pages :
[
1]
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SubJunk
22nd March 2011, 22:04
Introduction:
InterFrame uses SVP plugins to create interpolated frames from real ones.
It has been compared with real 60FPS content with good results; it will never be as good as the real thing but it is very good and will continue to get better with your input :)
Step-by-step guide on how to use InterFrame for beginners (http://www.spirton.com/convert-videos-to-60fps/)
Download:
http://www.redskiesguild.com/urbanterror/uploads/urtplus-download.png (http://www.spirton.com/uploads/InterFrame/InterFrame-2.8.2.zip)
All dependencies are included in the download
Video samples:
Here is a before and after video comparison:
Original File (http://www.spirton.com/uploads/InterFrame/20130218-Sample-Original.mkv)
InterFrame (default settings with GPU=true) (http://www.spirton.com/uploads/InterFrame/20130218-Sample-InterFrame.mkv)
Code samples:
Here is a sample of what the AviSynth script could look like.
It shows the recommended syntax and should be used with SET's AviSynth 2.6 MT build from here (http://forum.doom9.org/showthread.php?t=148782). It requires a build of AviSynth that can do multithreading.
Cores=4
SetMemoryMax(512)
SetMTMode(3, Cores)
LoadPlugin("svpflow1.dll")
LoadPlugin("svpflow2.dll")
Import("InterFrame2.avsi")
dss2("video.mkv", fps=23.976).ConvertToYV12()
SetMTMode(2)
InterFrame(Cores=Cores)
Description:
You've probably all seen the concept before in new TVs, sometimes called "Smooth Motion", "Higher Hz", "True Motion", "TruMotion", "HFR" or just the number of Hz (like 120Hz, 200Hz, 240Hz, etc.), well this is exactly the same but it works on any TV or computer monitor.
It inserts interpolated frames in between the real ones to make either 50FPS (for PAL sources) or 59.94FPS (for NTSC sources) output.
The best sources to use are 29.97FPS and 25FPS videos since they are neatly divisible to 59.94FPS and 50FPS respectively, but it works well with 23.976FPS too.
Documentation:
The help page is here (http://www.spirton.com/uploads/InterFrame/InterFrame2.html). The documentation is also included in the download.
It contains a detailed breakdown of all options.
Disclaimer:
Some people are conceptually opposed to things like this for many reasons, including:
- It's not true to the director's vision for the video.
- Film should have lower framerates (even real 60FPS content looks too smooth and "cheap").
- The interpolated frames are "fake".
Hopefully people with those opinions can just choose to not use this plugin instead of starting arguments about it; that is your choice and this is ours.
Changelog: (full version (http://www.spirton.com/interframe/#Changelog))
21/05/2015 - 2.8.2:
Updated SVPflow to 1.1.15, which increased speed (thanks, SVP (http://www.svp-team.com/)!)
02/05/2015 - 2.8.1:
Updated SVPflow to 1.1.14, which increased speed by up to 15% (thanks, SVP (http://www.svp-team.com/)!)
10/03/2015 - 2.8.0.1:
Updated SVPflow to 1.1.13, which fixed the unused SVConvert function (thanks, SVP (http://www.svp-team.com/)!)
fairchild
23rd March 2011, 03:31
Thanks for this. This can be used as well to do it in realtime as well so you don't have to re-encode the files? This is a script I found by another user from another forum. It doesn't work that smooth for me though, I get alot of frame drops. Probably my CPU is lacking and showing it's age.
SetMTMode(1,16)
V = ffdshow_source()
SetMTMode(2)
G = V.RemoveGrain(mode=3)
H = G.MSuper(pel=2, hpad=8, vpad=8, rfilter=4)
S = V.MSuper(pel=2, hpad=8, vpad=8, rfilter=4)
A = H.MAnalyse(isb=true, blksize=16, plevel=0, search=3, searchparam=3, badrange=(-24), dct=10)
B = H.MAnalyse(isb=false, blksize=16, plevel=0, search=3, searchparam=3, badrange=(-24), dct=10)
C = S.MRecalculate(A, blksize=8, blksizev=8, search=3, searchparam=1)
D = S.MRecalculate(B, blksize=8, blksizev=8, search=3, searchparam=1)
E = S.MRecalculate(C, blksize=4, blksizev=4, search=3, searchparam=1)
F = S.MRecalculate(D, blksize=4, blksizev=4, search=3, searchparam=1)
V.MFlowFps(S, E, F, num=FramerateNumerator(V)*2, den=FramerateDenominator(V)*1, mask=2, ml=10000, blend=false)
GetMTMode(false) > 0 ? distributor() : last
Is this script using InterFrame at all or no?
SubJunk
23rd March 2011, 03:47
Yes, that is a script from Widezu and is quite similar to the Medium (default) preset of InterFrame.
You can use InterFrame for realtime processing, too, except then it would just be like:
SetMTMode(1,0)
ffdshow_source()
SetMTMode(2)
InterFrame(Preset="Fast")
GetMTMode(false) > 0 ? distributor() : last
Using that Fast preset of InterFrame should be enough to give you smooth playback in realtime, but it will be poor quality.
If you are interested, I can increase the quality of the "Fast" preset so it is still ok for realtime playback but looks better. Let me know :)
fairchild
23rd March 2011, 07:36
Yes, that is a script from Widezu and is quite similar to the Medium (default) preset of InterFrame.
You can use InterFrame for realtime processing, too, except then it would just be like:
SetMTMode(1,0)
ffdshow_source()
SetMTMode(2)
InterFrame(Preset="Fast")
GetMTMode(false) > 0 ? distributor() : last
Using that Fast preset of InterFrame should be enough to give you smooth playback in realtime, but it will be poor quality.
If you are interested, I can increase the quality of the "Fast" preset so it is still ok for realtime playback but looks better. Let me know :)
Yes the difference from fast to medium is drastic indeed. Fast allows no dropped frames but during fast moving scenes it really breaks apart and quality goes downhill.
Thanks for providing the script, now I have two ways to play around with. I think it's probably just my cpu, maybe if I had an i7 or even a core2quad. Don't spend any time on my account though working on the script, I just wanted to try it and show it to friends so they can see the effect. (I don't plan to use it 24/7) Maybe if some other users on here plan to use it or you get requests then go for it. Thanks again. :)
BTW, what are the recommended settings for 3:2 Pulldown and Buffer back/ahead?
Soulhunter
23rd March 2011, 16:27
Looks good, except for the first two seconds (the guys jacket)!
SubJunk
24th March 2011, 05:24
I've just updated to 1.2, the changelog is:
- Renamed Fast preset to Ultra Fast
- Added Very Fast and Fast presets - these are so that users who are using it for realtime playback have more options to suit their computer speed
- Increased quality of Placebo and Medium presets
- Added Tuning variable
- Improved detection of scene-changes
- Added the file dependencies to the download since a couple of them were confusing some people
- Added links to the dependency websites in the help file
Don't spend any time on my account though working on the script, I just wanted to try it and show it to friends so they can see the effect. (I don't plan to use it 24/7) Maybe if some other users on here plan to use it or you get requests then go for it. Thanks again. :)It's no problem, I want to make this script as useful as it can be :)
As the changelog above says, I have added some more presets ("Very Fast" and "Fast", while the old version of "Fast" is renamed to "Ultra Fast") that will hopefully let you achieve better quality with realtime playback.
BTW, what are the recommended settings for 3:2 Pulldown and Buffer back/ahead?You can deal with pulldown the same way as usual, just do it before the InterFrame() line and not after :)
Looks good, except for the first two seconds (the guys jacket)!Thanks :)
Yes, I purposely used a clip that isn't perfect since I didn't want people to expect it to be perfect.
I think that is a good representation of what it will usually look like. Sometimes it is worse and sometimes it is better.
aegisofrime
24th March 2011, 06:02
Thanks for the continued development of this script :)
BTW, I'm curious what movie is the sample from? It looks interesting...
SubJunk
24th March 2011, 06:30
Thanks aegis, if there are any features you'd like to see feel free to suggest them :)
It's from a great film called Mr. Nobody (https://secure.wikimedia.org/wikipedia/en/wiki/Mr._Nobody_%28film%29). One of my faves :)
SubJunk
30th March 2011, 04:56
Version updated to 1.3, the changelog is:
- Added new Tuning value called Smooth, some people may prefer it to default so check out the sample
- Improved detection of scene-changes
I've updated the documentation with more details, too.
Lastly, the sample videos have been updated to reflect the new quality and tunings, check them out :)
Forfront
30th March 2011, 07:24
Hi' Sub, :)
Does the "VeryFast" preset not work for realtime? I tried it but avisynth asked what is "SuperDeGrained". Thanks
Edit: Never mind didn't space "Very Fast":rolleyes:
SubJunk
30th March 2011, 07:52
Hi Forfront :)
Glad you got it sorted. I will add descriptive warning messages in the next version to avoid that in the future :)
Forfront
30th March 2011, 17:43
Ok thanks, probably only happen to me though, typing fast can be +/- sometimes :D
SubJunk
1st April 2011, 02:42
Well in case it happens to more people I have updated to the version to 1.3.1 :)
The changes from 1.3 are:
- Added input validation for Tuning and Preset values with descriptive error messages
I also added a mini-changelog to the first post.
SubJunk
10th April 2011, 13:01
InterFrame has been updated to 1.4.
This version introduces GPU-acceleration and quality improvements.
The video samples have also been updated :)
Fizick
10th April 2011, 17:43
SubJunk,
please do not forget GPL when distributute plugins
aegisofrime
10th April 2011, 18:30
Wow GPU acceleration! Certainly looks interesting. Great job with the plugin so far, I gave it a whirl just now and it definitely seems like it produces less nasty artifacts than MVTools 2 does. BTW, any chance of a 64-bit version? :thanks:
SubJunk
10th April 2011, 22:29
SubJunk,
please do not forget GPL when distributute pluginsGood point, sorry for forgetting about that. It is done now.
By the way, do you have any suggestions on how to squeeze more general quality from the script, regardless of how slow it gets?
Wow GPU acceleration! Certainly looks interesting. Great job with the plugin so far, I gave it a whirl just now and it definitely seems like it produces less nasty artifacts than MVTools 2 does. BTW, any chance of a 64-bit version? :thanks:Thanks a lot for the feedback :)
Yes it produces less artifacts because the new DLLs include a new type of masking, so there are actually 2 masks working now instead of 1. It has hardly any effect on performance, but a big effect on quality :)
I will check for you on the 64-bit versions, that would be cool I agree.
-Vit-
11th April 2011, 00:18
One thing you're not doing is using MMask (in SAD mode) to determine areas with a probable poor motion match. In those areas flow will likely create a mess, so use a different interpolate instead. I have used a Gauss-blurred flow as the SAD gets a little high (the blur obscures the most obvious artefacts), and/or a simple frame average where the SAD is very high (which effectively removes the appearance of flow, but is better than the alternatives). QTGMC does a simple version of this with its shutter motion blur, but using a motion mask rather than SAD.
SubJunk
11th April 2011, 00:39
Hi -Vit-, thanks for the input! I love QTGMC, I use it all the time.
It does use MMask, it is included in the custom DLLs and is activated by the sadml parameter in the MSmoothFps function. It is similar to Yushko's script in that respect, if you're familiar with his YFRC function.
metanat
11th April 2011, 01:26
I have watched around 15 movies that have used various versions of this script, including the latest version. The script has continually improved, to the point that now it is a must have for movie watching. After some initial adjusting to the different feel it gives the movie, you might find, as I have, that it makes a massive difference to the watching experience, creating a silky real-life smoothness that you just don't get without it. Watching regular framed movies now makes them feel jittery, and leaves me wishing they were converted with InterFrame.
Looking forward to more improvements SubJunk, keep up the awesome work!
fairchild
11th April 2011, 04:17
Hey SubJunk, tried today to use the newer InterFrame to do some realtime frame doubling today using ffdshow, and it's spitting out an error at me. Not sure how to fix it. All I did was copy the plugins you added in the dependencies into my AviSynth/plugins directory. Using the following script:
SetMTmode(2,2)
ffdshow_source()
SetMTMode(2)
InterFrame(Preset="Fast")
GetMTMode(false) > 0 ? distributor() : last
Error given is:
MSmoothFPS: unable to load library given in svp_flow_lib (InterFrame.avsi, line 87)
Edit: I google'd the error and supposedly it has to do with the new GPU acceleration that you added. It means your card is not supported .
SVP GPU acceleration requires OpenCL 1.1
The thing is my card is an HD 5800 series card and does have OpenCL, not sure if it has 1.1 though. Using the 11.4 preview drivers also, maybe that has something to do with it.
SubJunk
11th April 2011, 04:19
Hi fairchild, sorry about that. I was made aware of the error earlier and I'm updating it to fix that now. Should be released within a few hours :)
It isn't a bug, but I forgot to add a check that FlowPath was specified, which it needs to be :)
-Vit-
11th April 2011, 04:50
I had a quick look at the SVP MVTools mod but didn't notice it used a SAD mask. Interesting. It's a shame that it only provides GPU acceleration for flow (MSmoothFps ). Would have thought that MAnalyse was the function to accelerate, but that would be much more difficult to do...
Didée
11th April 2011, 07:23
One thing you're not doing is using MMask (in SAD mode) to determine areas with a probable poor motion match. In those areas flow will likely create a mess, so use a different interpolate instead.
How should that work for Flow Interpolation? Trying to do this manually at the script level, there is a problem...
A vector is a path from point A to point B. MMask shows the block metric at the end point of the vector. It would be needed to have the mask located at a point somewhere inbetween, at a fraction of the vector's length. This is not available. And manual compensation of the mask is not possible either, because the mask is located at the end point of the vector, and you can only compensate in the vector direction start->end.
SubJunk
11th April 2011, 07:57
InterFrame 1.5 is released!
The changes are:
- Improved the quality of the default, Fast and Placebo presets
- It now checks for the existence of the mandatory value for FlowPath and displays an alert if it isn't defined
- Added the GPU parameter (true for GPU-acceleration, false for CPU-only)
I have watched around 15 movies that have used various versions of this script, including the latest version. The script has continually improved, to the point that now it is a must have for movie watching. After some initial adjusting to the different feel it gives the movie, you might find, as I have, that it makes a massive difference to the watching experience, creating a silky real-life smoothness that you just don't get without it. Watching regular framed movies now makes them feel jittery, and leaves me wishing they were converted with InterFrame.
Looking forward to more improvements SubJunk, keep up the awesome work!Wow, that's such an encouraging post. Thanks a lot and I'm glad you are enjoying it!
I had a quick look at the SVP MVTools mod but didn't notice it used a SAD mask. Interesting. It's a shame that it only provides GPU acceleration for flow (MSmoothFps ). Would have thought that MAnalyse was the function to accelerate, but that would be much more difficult to do...Yeah the sadml parameter is really useful, it fills a gap that was always there.
In InterFrame it's used lightly, because the blur effect looks strange when it's too strong (with each frame changing from sharp to blurry it's a weird strobing-blur effect).
It is an especially useful parameter for when the background is passing by quickly while something small is relatively unmoving on the screen. Without sadml the unmoving thing bounces around like crazy, but with even a light sadml like 150 it stabilises significantly.
How should that work for Flow Interpolation? Trying to do this manually at the script level, there is a problem...
A vector is a path from point A to point B. MMask shows the block metric at the end point of the vector. It would be needed to have the mask located at a point somewhere inbetween, at a fraction of the vector's length. This is not available. And manual compensation of the mask is not possible either, because the mask is located at the end point of the vector, and you can only compensate in the vector direction start->end.It's similar to the masking technique used in YFRC, but it is done at the plugin level, not the script level.
If you would like to see how it's done, you can download the sources here (http://www.svp-team.com/files/gpl/mvtools2-2.5.11-svp.zip) :)
The thing is my card is an HD 5800 series card and does have OpenCL, not sure if it has 1.1 though. Using the 11.4 preview drivers also, maybe that has something to do with it.I have added the new parameter "GPU" for you and other users with incompatible video cards.
So just use something like:
InterFrame(GPU=false, FlowPath="C:\Program Files (x86)\AviSynth 2.5\plugins\")
Please let me know if it works for you :)
fairchild
11th April 2011, 08:45
I have added the new parameter "GPU" for you and other users with incompatible video cards.
So just use something like:
InterFrame(GPU=false, FlowPath="C:\Program Files (x86)\AviSynth 2.5\plugins\")
Please let me know if it works for you :)
It's working well now, thanks for the speedy fix. :thanks:
Using the following script with 10,10 buffer and ignore pulldown:
SetMTmode(2,2)
ffdshow_source()
SetMTMode(2)
InterFrame(Preset="Fast", GPU=true, FlowPath="C:\Program Files (x86)\AviSynth 2.5\plugins\")
GetMTMode(false) > 0 ? distributor() : last
SubJunk
11th April 2011, 09:38
It's working well now, thanks for the speedy fix. :thanks:Great, glad it's working for you :)
ncatt
11th April 2011, 10:36
Hi SubJunk! Thanks for this great script! The gpu option is working very fast in my machine. With gpu=true the encode was nearly 40% faster. My gpu is a gtx580. :thanks:
Didée
11th April 2011, 10:42
It's similar to the masking technique used in YFRC, but it is done at the plugin level, not the script level.
If you would like to see how it's done, you can download the sources here
The point is not how things are done at the plugin level. My point is that at the script level it's hardly possible to make any meaningful use of MMask in combination with "Flow"-style filters.
If all accessibility would stop "at the plugin level", then things like e.g. Q/TGMC would not exist at all. :p
aegisofrime
11th April 2011, 10:51
Hi, just want to point out a slight error in the documentation:
FlowPath:
Sets the location of the libflow DLL files.
The full path of libflowgpu.dll and libflowgpu.dll, for example "C:\Program Files\AviSynth 2.5\plugins\".
Note: This is the only mandatory value; the script will not work without this.
default - Undefined (string)
One of those should be libflowsse.dll right? Pretty obvious, but in the interest of perfection just wanted to point it out :p
-Vit-
11th April 2011, 11:01
And manual compensation of the mask is not possible either, because the mask is located at the end point of the vector, and you can only compensate in the vector direction start->end.
We have forward and backward vectors...
Sure, not perfect (e.g. occlusion), but better than doing nothing in practice. YFRC's solution is not unreasonable: overlay the forward and reverse mask.
Didée
11th April 2011, 11:59
Sure, But those vectors are not correlated. Don't you see? Forward and backward vectors are computed completely independent from each other. And therefore it is absolutely possible that forward and backward vectors are finding different matches! (It's not only "possibly", it is even somewhat *likely*.)
See - you have to objects in two consecutive frames. Let's assume MVTools (should) try to match these two objects:
http://img703.imageshack.us/img703/7262/pic01j.png (http://img703.imageshack.us/i/pic01j.png/)
MAnalyse finds a match during backward search:
http://img585.imageshack.us/img585/8039/pic02.png (http://img585.imageshack.us/i/pic02.png/)
but a different match (or no match at all) during the forward search:
http://img545.imageshack.us/img545/2742/pic04.png (http://img545.imageshack.us/i/pic04.png/)
Take the backward search, and for simplicity lets talk about the block SAD:
The backward match causes a certain SAD:
http://img858.imageshack.us/img858/3299/pic03.png (http://img858.imageshack.us/i/pic03.png/)
Now, the task is to "Flow" the future object backwards by a fraction of the backward-vector's length:
http://img33.imageshack.us/img33/2659/pic05a.png (http://img33.imageshack.us/i/pic05a.png/)
Obviously, the mask you (would) get from MMask is not correlated with the Flow-compensation.
Now, the obvious idea is to compensate the mask. But this does not work.
Again: the forward vector is not correlated to the backward vector, and very well might have a completely different direction.
http://img69.imageshack.us/img69/6623/pic06.png (http://img69.imageshack.us/i/pic06.png/)
Problem? Ah! Problem!
One would need to be able to use a given vector in inverse direction. But there is no means to do that.
"Within" the plugin, it's a different story. There, it is sufficient to know -- while doing the flow-compensation -- that the currently-used vector has a certain metric "attached". This suffices to produce a result with an according weighting. That's okay.
But from the script level, it is not possible to align a fractionally flow-compensated object with the MMask that is created at the vector's end position.
SubJunk
11th April 2011, 12:37
Hi SubJunk! Thanks for this great script! The gpu option is working very fast in my machine. With gpu=true the encode was nearly 40% faster. My gpu is a gtx580. :thanks:That's a great result, thanks for the feedback! :)
The point is not how things are done at the plugin level. My point is that at the script level it's hardly possible to make any meaningful use of MMask in combination with "Flow"-style filters.That (and your next post) is all irrelevant to this script, however correct, though I do appreciate the effort you went to with the images ;) :D
Hi, just want to point out a slight error in the documentation:
FlowPath:
Sets the location of the libflow DLL files.
The full path of libflowgpu.dll and libflowgpu.dll, for example "C:\Program Files\AviSynth 2.5\plugins\".
Note: This is the only mandatory value; the script will not work without this.
default - Undefined (string)
One of those should be libflowsse.dll right? Pretty obvious, but in the interest of perfection just wanted to point it out :pYou're right, nice catch :) It's fixed in the online document and will be fixed in the next version download :D
-Vit-
11th April 2011, 19:49
Didée: I know. Regardless, problem areas are often found correctly. The "incorrect" case is not virulent. Fixing flow weirdness is valuable and "downgrading" an area mistakenly is relatively harmless in this use case. But I also enjoyed your pictures ;)
Subjunk: now you use SVP's GPU flow, how would you say your script compares with SVP?
Didée
11th April 2011, 20:24
Glad if I managed to entertain you with handdrawn art.:D - See, I had only a few minutes during lunchbreak.
-Vit-: That's almost as good as "there is no energy crisis. My current comes right out of the wall socket!"
Within the limits of what MVTools' filters are doing, the metric usage is sufficient.
But there are cases where the plugin is producing bad junk. (Funny deformations, or exzessive blending). MVTools can not produce anything senseful for certain areas.
Now, IF you had an idea how to produce some senseful interpolation nonetheless, then you cannot use it, because you can NOT locate the problem area from the script level.
Don't mistake that with the motion blurring you have in QTGMC. That one is not nearly as critical. You start with discrete target locations, and the area affected by motion blurring naturally will be located rather close to those discrete target areas. This is a luxury you don't have when doing a "free" interpolation. In particular when there is some "large" movement (would be a "long" vector) that MAnalyse completely misses, then you can do nothing. You just can't locate the affected areas.
Sorry if I disturbed the highly interesting discussion about wrapping MVTools documented examples in a function. Perhaps this isn't the place anymore to look for fresh ideas and ingeniosity.
Didée
11th April 2011, 20:41
More @topic, I tried to read a little source code, and got reminded why I don't like to read source code.
MSmoothFps.cpp: switch(algo)
{
case AlgoFast_1dir:
case AlgoFast_2dir:
case AlgoNoMask1:
case AlgoNoMask2:
case AlgoNoMask3:
case AlgoSimple:
case AlgoNormal:
case AlgoExtended: break;
default:
if(algo<90 || algo>100)
env->ThrowError("MSmoothFps: incorrect 'algo' value.");
}
InterFrame.avsi: MSmoothFps(Input, SuperRegular, backward, forward, finest=SuperRegular, num=NewNum, den=NewDen, algo=23, ml=0, sadml=150, sadgamma=2, block=false, blend=true)
Having cancelled the "true" programming back when original C just had started, am I interpreting this wrong?. The sourcecode seems to suggest that the script's default value is incorrect?
Gavino
11th April 2011, 21:17
The sourcecode seems to suggest that the script's default value is incorrect?
algo=23 corresponds to AlgoExtended, so is accepted by the first part of the switch statement.
libflow.h:
enum FlowLib_Algo
{
AlgoUnknown=0,
AlgoFast_1dir =1,//MFlow "1-dir"
AlgoFast_2dir =2,//MFlow "2-dir"
AlgoNoMask1 =11,//MBlockFps, mode=0
AlgoNoMask2 =12,//MBlockFps, mode=1
AlgoNoMask3 =13,//MBlockFps, mode=2
AlgoSimple =21, //like FlowInterSimple from MaskFun.cpp OR MBlockFps, mode=3
AlgoNormal =22, //FlowInter
AlgoExtended=23, //FlowInterExtra
AlgoMask =127,
AlgoProcessBlocks =128
};
SubJunk
11th April 2011, 22:20
now you use SVP's GPU flow, how would you say your script compares with SVP?Well SVP has many options and is great for realtime. I really recommend it for users who don't want to touch scripts, who would rather an easier experience.
It has always been my goal with InterFrame to find the highest quality settings without compromising for speed, and in my opinion InterFrame offers the best visual quality of any script or program I have seen, when using the default preset.
If I didn't believe that then I would either learn from the better script as I have done many times, or stop making this and just use the other script instead :)
What do you think about it? Any tips are always appreciated, especially from the great author of the incredible QTGMC :)
Sorry if I disturbed the highly interesting discussion about wrapping MVTools documented examples in a function. Perhaps this isn't the place anymore to look for fresh ideas and ingeniosity.You have brilliant knowledge and are one of the greatest contributors on this forum ever, now if only we could talk with you without being met with condescension the path to progress may be smoother and faster :)
-Vit-
12th April 2011, 01:26
I've looked over your script but not really experimented with it. One thing that immediately stands out is the EEDI2 custom pelclip. That's from the MVTools docs; doesn't that example assume interlaced source? Because it discards half the lines, interpolates them back, then resizes. You're assuming progressive source, yes? So wouldn't something like nnedi3_rpow2 be more appropriate? [without cshift, I believe].
SubJunk
12th April 2011, 01:45
I've looked over your script but not really experimented with it. One thing that immediately stands out is the EEDI2 custom pelclip. That's from the MVTools docs; doesn't that example assume interlaced source? Because it discards half the lines, interpolates them back, then resizes. You're assuming progressive source, yes? So wouldn't something like nnedi3_rpow2 be more appropriate? [without cshift, I believe].It does seem you're right logically but in testing I got a better result like this after comparing all the EEDI and NNEDI functions. I don't know why but it did seem consistent across multiple videos.
At any rate I am considering removing that option from the script because it is such a slight improvement for a huge performance hit. I don't think I would ever recommend it.
Didée
12th April 2011, 09:20
I have added the new parameter "GPU" ...
Please let me know if it works for you
With GPU=false it doesn not work correctly for me.
On Intel Pentium-D (WinXP): the output shows a 2x2 array of the input.
On Intel i7-860 (Win7): every few moments, there are green "flashes" all over the screen. (Didn't look close - could be the green builds a "cross" pattern, related to the grid of the 2x2 array.)
src = colorbars().converttoyv12().reduceby2().showframenumber()
dbl = src.interframe(GPU=false,FlowPath="C:\ [...] \InterFrame-1.5\Dependencies\")
stackhorizontal( interleave(src,src).subtitle("source").addborders(4,4,4,4),
\ dbl.subtitle("InterFrame(GPU=false)").addborders(4,4,4,4))
return(last)
http://img190.imageshack.us/img190/9342/interframegpufalse.jpg (http://img190.imageshack.us/i/interframegpufalse.jpg/)
Colorbars is just for demonstration. Running a native 1280x720 clip shows the same issue.
Gavino
12th April 2011, 09:23
One thing that immediately stands out is the EEDI2 custom pelclip. That's from the MVTools docs; doesn't that example assume interlaced source? Because it discards half the lines, interpolates them back, then resizes.
EEDI2 doesn't discard half the lines. It resizes an image by 2x in the vertical direction by copying the existing pixels and interpolating new ones in between them. So it works for progressive sources - the MVTools doc example is assuming progressive as it doesn't call SeparateFields before EEDI2.
SubJunk
12th April 2011, 09:48
With GPU=false it doesn not work correctly for me.
On Intel Pentium-D (WinXP): the output shows a 2x2 array of the input.
On Intel i7-860 (Win7): every few moments, there are green "flashes" all over the screen. (Didn't look close - could be the green builds a "cross" pattern, related to the grid of the 2x2 array.)
src = colorbars().converttoyv12().reduceby2().showframenumber()
dbl = src.interframe(GPU=false,FlowPath="C:\ [...] \InterFrame-1.5\Dependencies\")
stackhorizontal( interleave(src,src).subtitle("source").addborders(4,4,4,4),
\ dbl.subtitle("InterFrame(GPU=false)").addborders(4,4,4,4))
return(last)
http://img190.imageshack.us/img190/9342/interframegpufalse.jpg (http://img190.imageshack.us/i/interframegpufalse.jpg/)
Colorbars is just for demonstration. Running a native 1280x720 clip shows the same issue.Darn, that happens for me too.
It is related to that dll (libflowsse.dll) because it even happens with a simple script like this:
svp_flow_lib = "C:\path\libflowsse.dll"
Super = MSuper()
backward = MAnalyse(Super, isb=true)
forward = MAnalyse(Super, isb=false)
MSmoothFps(Super, backward, forward, num=48000, den=1001, algo=23)
I will contact the SVP guys, it is probable that it was an incorrect assumption of mine that libflowsse.dll would work the same as libflowgpu.dll.
-Vit-
12th April 2011, 09:56
EEDI2 doesn't discard half the lines. It resizes an image by 2x in the vertical direction by copying the existing pixels and interpolating new ones in between them. So it works for progressive sources - the MVTools doc example is assuming progressive as it doesn't call SeparateFields before EEDI2.
Ah yes, I forgot; the meaning of "field" is completely different between EEDI2 and [EEDI3/NNEDI2/NNEDI3]. (...)
Gavino
12th April 2011, 10:12
it is probable that it was an incorrect assumption of mine that libflowsse.dll would work the same as libflowgpu.dll.
Perhaps it would have been a good idea to test this before releasing it... ;)
SubJunk
12th April 2011, 11:59
Perhaps it would have been a good idea to test this before releasing it... ;)I had tested it, but not thoroughly enough. I had run a preview of the script and it was perfect, because the bug only affects 1 in every 2 frames (the preview happened to be on a good/original frame) ;)
I would usually test more thoroughly but I had several users without GPUs posting that it no longer worked so I wanted to release the fix ASAP for them :)
Ah yes, I forgot; the meaning of "field" is completely different between EEDI2 and [EEDI3/NNEDI2/NNEDI3]. (...)That's convenient! ;) I've also noticed that sometimes the documentation for those plugins just says "this has the same parameters as *function in other plugin*" so you have to open the other documentation :) It's a fun ride, but worth it
SubJunk
12th April 2011, 22:46
Version 1.5.1 is released with the GPU=false fix. Sorry to the people who encountered this bug.
SubJunk
13th April 2011, 06:25
Version 1.5.2 is released which is very minor, it just changes the default value of GPU from true to false because I discovered that the GPU mode reduces quality slightly.
It's a problem with SVP and the developers are aware of it so hopefully there is a fix coming soon :)
SubJunk
19th April 2011, 23:31
Version 1.6 is released which fixes the GPU mode bug and adds more presets for realtime users. Enjoy :)
jemm54
20th April 2011, 22:00
Hello, im having problems with this plugin, this is the error:
[Image]
im not sure what that means....
BTW, thanks for the plugin....
Edited: Make the picture smaller or upload it somewhere else and give a link. I've refused the pic.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.