SVPflow motion interpolation (Avisynth + Vapoursynth, Linux, Mac?)

[chainik_svp]

Short version: SVPflow is a successor to MVTools2, providing more speed and more quality. Now available for Windows/Linux/Mac in both 32 and 64-bit versions.

Long story :)
With all respect to Fizick MVTools is old and there’s almost no progress (except for bug fixes) for several years now. Obviously MVTools isn’t perfect so someone should do something with it :devil: And there comes another problem: MVTools is big and fat. There’re tons of dead, commented and copy-pasted code in it. For example all “client” functions (MFlow, MFlowFps, MBlockFps, …) are identical in at least 50% of code which is bad for further development.
And there’s SVP project that started in 2008 on biggest Russian IT forum (iXBT.com). Main goal was to provide some user-friendly controls over all that MVTools-based scripts inside ffdshow for real-time smooth video playback. They’ve experimented with scripts, tuned GUI and so on.
At some time I’ve noticed that MVTools performance is too low on AMD CPU’s, so I’ve made a patch that increased MFlow / MFlowFps speeds up to 50% on all Athlons/Phenoms. That was the beginning – SVP 2.0 :D
The second step was creating MSmoothFps function that incorporates all “client” MVTools function in one with GPU accelerated rendering via OpenCL and some more stuff and it was SVP 3.0. The output of this function was per-pixel the same as output of original MFlowXXX. In latter versions we’ve made some speed optimizations (20-50%) in motion vectors search.
But all of that was only a warming-up before the real job – to give MVTools a second life.


So, SVPflow consists of two parts: GPLed motion vectors search and closed-source frame rendering.

Downloads.
The description and downloads are available there (http://www.svp-team.com/wiki/Plugins:_SVPflow).
Also many of you’re familiar with Interframe (http://forum.doom9.org/showthread.php?p=1486831) script ;)

Disclaimer.
SVPflow isn’t a complete replacement for MVTools cause it’s missing most of additional functions. As of now the main goal of project is to provide fast and high quality real-time video conversion, so all functions unnecessary for this task was cut off and sources were cleared and refactored.

Also there’re a lot of new features added and I could tell about them if someone is interested in ;)

----------
Version 4.0.0.128 (02/22/16)
= bump versions to match SVP 4 multi-OS release
+ Vaporsynth/Windows 32-bit/64-bit builds
+ Vaporsynth/Linux 32-bit/64-bit builds
+ all filters now compatible with MT mode 1


Version 1.1.16 (07/08/15)
= fixed random crash in svpflow1.dll found by SVP 3.1.7 users

Version 1.1.15a (05/15/15)
+ 64-bit build added

Version 1.1.15 (05/13/15)
= fixed performance issues with the default main.search.coarse.width value (introduced in 1.1.12)

Version 1.1.14 (04/24/15)
= up to 15% faster
= 2nd attempt to fix broken SVConvert function NOT fixed in 1.1.13


Version 1.1.13 (03/09/15)
= fixed broken SVConvert function


Version 1.1.12 (03/04/15)
= up to 20% faster
+ "64-bit ready" - assembler code (still not all of them) ported/rewritten in intrinsics, target compiler is VC++2013
+ new option in SVAnalyse - search.main.coarse.width - to get more than one "finest" levels
+ SATD for 32-x blocks
= reduced memory usage for large number of small blocks
= refactoring - removed svpflow_cpu/gpu modules - merged with svpflow2


Version 1.0.11 (05/04/14)
= Fixed crash in CPU rendering mode with pel>1 and blend=true
= Fixed rounding error in GPU rendering mode


Version 1.0.10 (04/01/14)
+ GPU rendering in linear light by default
= SAD functions updated to the latest x264 code


Version 1.0.9 (07/17/13)
+ SVSmoothFps switches to 13th SVP shader if scene quality is below scene.m1 value
= GPU rendering was very slow for some "prime" frame sizes (like 1916x1076) on some video cards
- removed workaround for a bug in early IvyBridge's drivers


Version 1.0.8 (02/03/13)
= fixed regression from 1.0.5 (low rendering precision in GPU mode)
= improved lighting quality (reduced color banding)

Version 1.0.7 (01/23/13)
+ improved scene change detection
= fixed crash after SVConvert, adjusted SAD values in MVTools' vectors field


Version 1.0.6 (12/23/12)
+ super clip size reduced by 4 for pel=1
('full' param in SVSuper and 'src' param in SVAnalyse)
= added workaround for OpenCL rendering on Intel's IvyBridge GPUs
+ "Ambilight" can now produce "glow" effect from all sides of the frame
('light.zoom' param in SVSmoothFps)
= several small bugs fixed:
== crash with frame rate ratio < 2 (50->60, 60->50 and so on)
== arts near screen edges with CPU rendering and some frame / block sizes combination
== green lines with 21th shader and arts masking on CPU

Version 1.0.5 (05/03/12)
= added compatibility with GTX680 (and may be with all other Kepler GPUs) - thanks to flagger

Version 1.0.4 (05/02/12)
+ added special.delta param

Version 1.0.3 (04/16/12)
= fixed random crash in MT mode
= fixed usage of invalid predictors from reverse vectors (thanks -Vit-)

Version 1.0.2 (04/04/12)
= support for multiply SVSmoothFps instances needed for proper 3D handling
+ SVConvert function for integration with MVTools-based scripts
+ GPU selection for rendering
= updated SAD/SATD x264 code

[aegisofrime]

Hmm I wonder if Q/TGMC could be updated to make use of SVPflow? Or are the functions used by Q/TGMC not present in SVPflow yet?

[Zerofool]

Also there’re a lot of new features added and I could tell about them if someone is interested in ;)
Yes, please do.
And also, if I may ask you to consider implementing support for YV24 colorspace in a future version, that would be great.
Thank you for your work!

[chainik_svp]

aegisofrime
No it couldn't. It uses MDegrain, MCompensate and MFlowBlur.
All I could do is providing some kind of converter from SVAnalyse vectors to MAnalyse output format o_O

Zerofool
consider implementing support for YV24 colorspace in a future version

There's no real visual difference in real-time between YV12 and YUY2, but YUY2 processing is 30% slower.
That's the reason why SVPflow supports only YV12 now.
YV24 will be 2 times slower.
So why? :)

[-Vit-]

All I could do is providing some kind of converter from SVAnalyse vectors to MAnalyse output format o_O
Even that would be very interesting and potentially provide quality improvements to QTGMC. Are there any major differences in format?

[chainik_svp]

Are there any major differences in format?

Nope, just forward and backward vectors together plus additional integer for each block (it's average luma value).

[lansing]

so so far SVPflow can't be used for denoising?

[-Vit-]

My edit to my last post crossed with your reply so you may have missed it, I had some questions about the new penalty settings:

What does pnbour do exactly? It seems related to field coherence, but I can't quite tell from the docs.

How exactly does penalty.prev work - does it assume that forward vectors at frame 1 (from the frame 0 to frame 1) are expected to be the opposite of backward vectors at frame 1 (from frame 2 to frame 1)? Or does it have a temporal aspect, forward vectors at frame 1 are expected to be the reverse of backward vectors at frame 0 (I think you probably know what I mean), or is it something different again...
Also are there downsides to penalty.prev? Objects appearing or disappearing would strongly affect it, but that's a problem case already.

Thanks for you work BTW :)

[henryho_hk]

aegisofrime
All I could do is providing some kind of converter from SVAnalyse vectors to MAnalyse output format o_O


Yes, please.

And from your experience how promising is GPU based rendering? I am replacing my display card (ATI 4850). Now choosing between 5850 (if i could find it), 6850 and GTX 560SE (336 CUDA core).

[chainik_svp]

-Vit-

In MVTools there're up to 5 predictors for each block:
- zero vector (with pzero penalty)
- global (with pglobal penalty)
- interpolated from previous level (w/o any penalty)
- left, top, right (interpolated) and their median (with lambda penalty)

In SVPflow:
- zero (pzero)
- global (pglobal) (but global MV is average between forward global MV and backward global MV)
- from previous level (w/o penalty)
- from previous level in opposite direction (*) (if exists, with prev penalty)
- vectors of up to 8 already processed neighbours (**) (with pnbour penalty)

(*) Forward (from frame 0 to frame 1) and backward (from 1 to 0) vectors are finding at the same time, like this: "fwd on smallest level 5", "bwrd on smallest level 5", "fwd on level 4", "bwrd on level 4", ..., "fwd on finest level 0", "bwrd on finest level 0".
So when processing some block in "bwrd level 5" we can take already founded MV from "fwd level 5" that points to this block (if such MV exists) as a predictor.
And for block in "fwd level 4" we can take MV interpolated from "bwrd level 5" that points to this block.

(**)
In MVTools blocks are processed in strict order row by row. In SVPflow order of processing is defined by block's SAD values - blocks with less SAD are processing first. So for each block its already processed neighbours (if any) are always have better quality. BTW the next good idea is to sort blocks not by SAD but by its contrast value...

[chainik_svp]

henryho_hk
how promising is GPU based rendering?

1. It's fast :)

2. It provides much more precision cause all processing on GPU done in floats.
What's the point of hpel and qpel? First: you can find vectors with non-integer coordinates up to 0.5 or 0.25 of pixel. Second: it makes additional interpolated planes in super clip that are used by CPU rendering to fetch sub-pixels.
What if you need to render frame at the time moment = 0.2, for example? You'll need not the original MVs but forward MV/5 and backward MV*4/5. Obviously there're no exactly those sub-pixel with neither hpel nor qpel on CPU.
But GPU can easily fetch the exact sample you need, it's like "infinite" pel level ;) Also with high precision rendering there's less need for high precision in vectors search.

3. It can do bicubic interpolation instead of bilinear (even on low-end cards) which is definitely visible with naked eye.

I dunno why but I can't upload any attachments images :(

--------
Upd: some images (http://imgur.com/a/MwglB).

[Didée]

BTW the next good idea is to sort blocks not by SAD but by its contrast value...
Finally! That sounds like ... something.

When you bring "block contrast" into the game, consider making various SAD thresholds RELATIVE to block contrast. The current system with absolute values surely was easy to implement, but really, it is quite dumb. (An object is sold for $50. Is this a good price, or is it expensive? Well, it depends on the kind of object ... obviously. Now, is SAD=50 a good threshold, or not? Well, it depends...)

[chainik_svp]

Didée
Yeah, I know that it was your ideas about contrast ;)

Right now block contrast is used for "adaptive" search distance - large distance for more contrast blocks, zero distance for uniform ones. Which is good for eliminating "window blinds" artifacts BTW.
And relative (or "adjusted") SAD is used in scene change detection, but it's adjusted not by contrast but by avg. luma.

[Terka]

It is great news! Thank you, chainik_svp!

[Bloax]

I dunno why but I can't upload any attachments images :(

http://imgur.com/
;)

[chainik_svp]

Bloax
That's not exactly what I've looked for... but thanks :)

Some synthetic images (http://imgur.com/a/MwglB) with GPU rendering. Big blue thing with red edge moves on some background.
All images with pel=1!

[Wilbert]

So, SVPflow consists of two parts: GPLed motion vectors search and closed-source frame rendering.
Would you be willing the release the frame rendering under GPL too?

[henryho_hk]

henryho_hk
1. It's fast :)
some images (http://imgur.com/a/MwglB).

No flame .... but NVidia or ATI better? :rolleyes:

[gyth]

consider implementing support for YV24 colorspace in a future version
YV24 will be 2 times slower.

IMO it'd be like subpixel estimation, but with real data instead of interpolated.

Zerofool, you could do something like this. I'm sure there are some gotchas, like chroma placement.
w=width
h=heigth
resize (2 * w, 2 * h)
converttoYV12

#motion stuff

converttoYV24
resize(w, h)

[chainik_svp]

Would you be willing the release the frame rendering under GPL too?
No, but "never say never" (c)

NVidia or ATI better?
As of now - the same s..t :D
But on NV you can do real HW deinterlacing with LAV @CUDA before motion interpolation.

[-Vit-]

Forward (from frame 0 to frame 1) and backward (from 1 to 0) vectors are finding at the same time
Both those vectors are between the current frame and the next. But the forward vectors returned are from previous frame to current. How do you deal with that in the implementation?

[Atak_Snajpera]

Chainik_svp will you be able to do some magic algorithm to correctly interpolate "moving legs"
http://forum.doom9.org/showthread.php?p=1566206#post1566206

[chainik_svp]

Frame #N in MAnalyse(isb=false) clip contains forward vectors from N-1 to N.
Frame #N in MAnalyse(isb=true) clip contains backward vectors from N+1 to N.

Frame #N in SVAnalyse clip contains forward vectors from frame N to N+1 and backward vectors from N+1 to N.

-Vit-, what's your question? :)

[-Vit-]

You answered my question :rolleyes:.
That means SVAnalyse returns different forward vectors with settings vectors:1 and vectors:3.
I ask because it's important when converting SVAnalyse vectors to MVTools compatible ones. The forward vectors are "shifted" by 1 frame

[chainik_svp]

That means SVAnalyse returns different forward vectors with settings vectors:1 and vectors:3.
Why? o_O With vectors=1 backward vectors will be undefined/zeroes, that's the only difference. At least I've wrote it to work in this way :D

BTW, smoothfps_params.debug.vectors=true will draw vectors almost like MShow.
If you set 3:1 interpolation then first interpolated frame will show forward vectors and second - backward ones.

-----
Oh, I see. You assume that the description of "vectors" param is right :D
It's a copy-paste mistake ;)

[-Vit-]

Oh, I see. You assume that the description of "vectors" param is right :D
Ah! Now you see why I asked about implementation, because I was wondering how you honored what the docs said - penalty.prev would be unpleasant to implement with the MVTools approach. The actual way you're doing things is much simpler.

[Zerofool]

Zerofool
consider implementing support for YV24 colorspace in a future version

There's no real visual difference in real-time between YV12 and YUY2, but YUY2 processing is 30% slower.
That's the reason why SVPflow supports only YV12 now.
YV24 will be 2 times slower.
So why? :)
I totally agree, but that's for real-time processing of YV12 sources.
I used MVtools, and I plan to use SVPflow for a different thing - adding motion blur to video games footage (which is RGB), in slow, "offline" manner (so I wouldn't mind if it's slow). When converted to YV12, there's often a visual degradation of the image quality, especially at borders between objects with very different colors (for example, red car on green-ish background). With YV24, this problem is gone, the video looks visually lossless to the source.
When the motion blur is added, the problem with YV12 is less pronounced, but still bugs me, that's why I'd very much like it if SVPflow supported YV24 colorspace (of course, if it's not too much work to implement it).

IMO it'd be like subpixel estimation, but with real data instead of interpolated.

Zerofool, you could do something like this. I'm sure there are some gotchas, like chroma placement.
w=width
h=heigth
resize (2 * w, 2 * h)
converttoYV12

#motion stuff

converttoYV24
resize(w, h)
Yeah, my footage has real data (it's RGB).
I've experimented with such approach, for higher precision, but using NNEDI3_rpow2, and I don't think the difference in quality is worth the big loss in speed.
But still, thanks for the suggestion.

[chainik_svp]

-Vit-
All that "temporal" things should be great but they're almost impossible now because they harm multi-threading performance. (This may not be the case here but for consumer software it's very bad)
Every night I think about my own threading inside plugins :D

Avisynth has different main purpose - non-linear editing. If all we want is just frame-by-frame linear processing then MT caches and "distributor" are not helping ;)
That's why SVP uses a custom Avisynth build that has:
- different distributor that manages threads pool a little more efficient
- tuned caches that hold only up to <some amount> of frames, where <some amount> depends on threads count.

I plan to use SVPflow for a different thing - adding motion blur to video games footage

Then I think you should do more than posting if you want some features added just for your business o_O

[Atak_Snajpera]

in other words "donate or die" ;)

[Zerofool]

Then I think you should do more than posting if you want some features added just for your business o_O
Hey, don't get me wrong, that was just an idea. I guess some developers would be happy to know that some people are using their product in weird, non-standard way, to achieve different things. And expanding the capabilities of their product would only be seen as a positive thing.

It's not business as in Business, I don't get money for that, it's just for personal amateur-grade videos - some of my favorite moments from classic (mostly 5+ years old, rarely newer) games. And hopefully, YV24 support would be useful for other users/gamers as well.

Anyways, good luck to the project.

[chainik_svp]

in other words "donate or die" ;)

Why so serious? :)
Just remember that the one and only goal is to maximize quality and speed for real-time playback. "Removing legs" is OK within this task but adding YV24 is NOT.

I don't get money for that
Me too :)
"Just an idea" - ok, we'll append it to the looooong TODO list.

[gyth]

I've experimented with such approach, for higher precision, but using NNEDI3_rpow2, and I don't think the difference in quality is worth the big loss in speed.
If you want precision, use point resize. (but be on the lookout for chroma shift)

Another possibility is to calculate using YV12 and then apply the motion vectors to the rgb (a separate "YV8" clip for each color).
And with pixel art, using pel=1 should be faster and help keep things pixelated.

[Zerofool]

ok, we'll append it to the looooong TODO list.
OK, great. Thank you!

If you want precision, use point resize. (but be on the lookout for chroma shift)

Another possibility is to calculate using YV12 and then apply the motion vectors to the rgb (a separate "YV8" clip for each color).
And with pixel art, using pel=1 should be faster and help keep things pixelated.
Thanks for the suggestion, I'll give it a try. Is it OK to ask you for help on how to do that, in a PM, because I don't want to spam this thread?

[Andrey /MAG/]

...some magic algorithm to correctly interpolate "moving legs"
http://forum.doom9.org/showthread.php?p=1566206#post1566206

You can try to change some settings in SVAnalyse params (http://www.svp-team.com/wiki/Plugins:_SVPflow):
1. block.w and block.h. The lower value the more precise vector field. Set them to 8.
2. main.search.distance. Use usual positive values or big negative ones. Set it to -10.
3. main.penalty.lambda and main.penalty.plevel.
The more lambda give more coherent movements, but more doubled contours. You need smaller values.
The more plevel give grown of coherence level by level from coarse to finest.
Try this:
main.penalty.lambda=3.0
main.penalty.plevel=1.0

And to change SVSmoothFps params:
4. algo. Set it to 2. Only one source frame will be used. So no double contour.

Fast result animation:
http://i.imgur.com/nFjai.gif

[Terka]

chainik_svp:
thank you!
When aproximately do you think the svtools will be ready for usage?
What advantage do you expect over the mvtools?
Would it be possible to use already calculated vectors for x264 encoding (why should x264 search for vectors, when avisynth already did this)

[Didée]

No. "Vectors ideal for encoding" and "vectors visually reflecting object motion" are two very different ballgames. Also consider the much more complicated situation in x264 - multiple references, multiple adaptive partition sizes, I/P/B-Frames, etc.

In a word, Avisynth's motion vectors are pretty much useless for x264. If at all, they could be used for something like "initial predictors" ... but that levels of ME is pretty fast in x264 anyway. Most probably things would get worse instead of better. In both speed and quality.

[chainik_svp]

When aproximately do you think the svtools will be ready for usage?

What do you mean? :confused: It's ready and is used in released software called "SVP".

[Terka]

SVPflow only, mvtools has mvdegrain etc.

[chainik_svp]

SVPflow 1.0.2 (http://www.svp-team.com/files/gpl/svpflow-1.0.2.zip)
= support for multiply SVSmoothFps instances needed for proper 3D handling
+ SVConvert function for integration with MVTools-based scripts
+ GPU selection for rendering
= updated SAD/SATD x264 code

How SVConvert should work:
super_params="{pel:1}"
analyse_params="{}"

super = SVSuper(super_params)
vectors = SVAnalyse(super, analyse_params)

forward_mv = SVConvert(vectors, false)
backward_mv = SVConvert(vectors, true)

super_mv = MSuper(pel=1, hpad=0, vpad=0) #padding should be zero here!
MFlowFps(super_mv, backward_mv, forward_mv, num=60, den=1)

[Nevilne]

Awesome stuff, thank you.

[mastrboy]

what is the performance penalty of using SVConvert?

[chainik_svp]

I'm sure it's about zero :)

But the important thing is: SVAnalyse vectors can point outside of frame while MAnalyse ones can not (at least with zero MSuper padding), so I have to clip all such vectors.

[-Vit-]

Thanks for the SVConvert functionality. Are the forward vectors already shifted back one frame to match the forward vectors we would expect from MVAnalyse?

A couple of other things I noticed:
- The vectors returned seem to be slightly non-deterministic when using SetMTMode(2) and many threads. Is that a known or a concern?
- The default for SVSuper scale.down is 2 not 4 as stated in the docs (I know to check now... :p)

[chainik_svp]

The vectors returned seem to be slightly non-deterministic when using SetMTMode(2)
It can't be. What's the source filter? The one and only non-deterministic behavior that I know was caused by DirectShowSource().

The default for SVSuper scale.down is 2 not 4 as stated in the docs (I know to check now... :p)
:D Thanks. :rolleyes: I think I should exchange "2" for "rfilter" with "4" for "sharp" in sources...

Are the forward vectors already shifted back one frame
I hope so :)

[-Vit-]

I have been using DGDecode_mpeg2source. I tried a number of .d2v sources, several (but not all) demonstrated slight non-determinism on many frames using the scripts below.

I've been testing TGMC adapted to use SVPflow. TGMC blends motion compensated neighbor frames with the current to remove bob-shimmer and enhance detail. This requires accurate vectors or it produces blurring and ghosting. Initial tests show that the svpflow vectors are fine much of the time. But they are rather less accurate than the TGMC MVTools settings in a number of situations and produce more ghosting/blurring overall. However, I've only experimented briefly, using the default settings mostly, so I hope I can find better tailored settings. I also want to be sure I'm doing things correctly.

I'd particularly like to check how I implemented delta for SVAnalyse. The script uses vectors of delta 1 and 2. To get delta 2 I did this:

vecs2e = super.SelectEven().SVAnalyse( svAnalyse )
vecs2o = super.SelectOdd(). SVAnalyse( svAnalyse )
fVec2 = Interleave(vecs2e.SVConvert( isb=false ), vecs2o.SVConvert( isb=false ))
bVec2 = Interleave(vecs2e.SVConvert( isb=true ), vecs2o.SVConvert( isb=true ))

The scripts in full. Outer script was standard (script is deterministic if SVP=false):

SetMTMode(3,8)
DGDecode_mpeg2source("some.d2v")
SetMTMode(2)
TGMC_SVP_Test(SVP=true)
Distributor() # or not


Main script function. The outer code is TGMC. The motion code is highlighted in the middle - it's written to make settings adjustments and comparisons simple:

function TGMC_SVP_Test( clip Input, bool "SVP" )
{
SVP = default( SVP, true )

Prefilter = 2 # Prefilter for search clip: 0 = none, 1 = Gauss blur + slight back blend, 2 = Full TGMC pre-filter
Sharpness = 1.5 # TGMC range not QTGMC range
EdiThreads = 1

w = Input.Width()
h = Input.Height()
epsilon = 0.0001

bobbed = Input.bob(0,0.5)

ts1 = bobbed.TemporalSoften( 1, 255,255, 28, 2 )
ts2 = bobbed.TemporalSoften( 2, 255,255, 28, 2 )
binomial0 = ts1.Merge( ts2, 0.357 ).Merge( bobbed, 0.125 )

repair0 = binomial0.DeshimmerRepair( bobbed )

spatialBlur = Prefilter > 0 ? repair0.RemoveGrain( 12,12 ).GaussResize( w,h, 0,0, w+epsilon,h+epsilon, p=2 ).MergeLuma( repair0, 0.1 ) : repair0
tweaked = Prefilter > 1 ? mt_lutxy( repair0, bobbed, "x 3 + y < x 3 + x 3 - y > x 3 - y ? ?", U=3,V=3 ) : NOP()
srchClip = Prefilter > 1 ? spatialBlur.mt_lutxy( tweaked, "x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?", U=3,V=3 ) : spatialBlur


#----------MOTION ANALYSIS - MVTools and/or SVPflow-------------

# Initial test - have only matched the TGMC overlap to the SVPflow setting, all other settings are the defaults for TGMC or SVPflow

# SVPflow settings for SVSuper and SVAnalyse
svSuper = "{ gpu:0, pel:2, scale:{up:2, down:2} }"
svBlock = "w:16, overlap:2"
svSearch = "type:4, distance:-4, satd:false, coarse:{type:4, distance:-10, satd:true}"
svPenalty = "lambda:10.0, plevel:1.5, lsad:8000, pnew:50, pglobal:50, pzero:100, pnbour:50, prev:0"
svAnalyse = "{ block:{" + svBlock + "}, main:{ search:{" + svSearch + "}, penalty:{" + svPenalty + "}}}"

# MVTools settings for MVSuper and MVAnalyse
mvSuper = "pel=2, hpad=8, vpad=8"
mvBlock = "blksize=16, overlap=4"
mvSearch = "search=4, searchparam=2, pelsearch=2"
mvPenalty = "truemotion=false, lambda=100*(16*16)/(8*8), lsad=400, pnew=25, plevel=0, global=true, DCT=0" # (16*16)/(8*8) is (blksize/8)^2
mvAnalyse = mvBlock + ", " + mvSearch + ", " + mvPenalty

# Calculate forward and backward vectors from search clip using either MVTools2 or SVPflow
srchSuper = SVP ? srchClip.SVSuper( svSuper ) : Eval("srchClip.MSuper(" + mvSuper + ")")
vecs1 = SVP ? srchSuper.SVAnalyse( svAnalyse ) : NOP()
vecs2e = SVP ? srchSuper.SelectEven().SVAnalyse( svAnalyse ) : NOP()
vecs2o = SVP ? srchSuper.SelectOdd(). SVAnalyse( svAnalyse ) : NOP()
fVec1 = SVP ? vecs1.SVConvert( isb=false ) : Eval("srchSuper.MAnalyse( isb=false, delta=1, " + mvAnalyse + ")")
bVec1 = SVP ? vecs1.SVConvert( isb=true ) : Eval("srchSuper.MAnalyse( isb=true, delta=1, " + mvAnalyse + ")")
fVec2 = SVP ? Interleave(vecs2e.SVConvert( isb=false ), vecs2o.SVConvert( isb=false )) : Eval("srchSuper.MAnalyse( isb=false, delta=2, " + mvAnalyse + ")")
bVec2 = SVP ? Interleave(vecs2e.SVConvert( isb=true ), vecs2o.SVConvert( isb=true )) : Eval("srchSuper.MAnalyse( isb=true, delta=2, " + mvAnalyse + ")")

pad = SVP ? 0 : 8 # Padding requirement for SVP

#-----------------------------------------------------------


edi = Input.NNEDI3( field=-2, nsize=1, nns=1, qual=1, threads=EdiThreads, U=true,V=true )

ediSuper = edi.MSuper( pel=2, levels=1, hpad=pad, vpad=pad )
bComp1 = edi.MCompensate( ediSuper, bVec1, thSCD1=180,thSCD2=98 )
fComp1 = edi.MCompensate( ediSuper, fVec1, thSCD1=180,thSCD2=98 )
tMax = edi.mt_logic( fComp1, "max", U=3,V=3 ).mt_logic( bComp1, "max", U=3,V=3 )
tMin = edi.mt_logic( fComp1, "min", U=3,V=3 ).mt_logic( bComp1, "min", U=3,V=3 )

degrain1 = edi.MDegrain1( ediSuper, bVec1,fVec1, thSAD=10*(8*8), thSCD1=180,thSCD2=98 )
degrain2 = edi.MDegrain1( ediSuper, bVec2,fVec2, thSAD=10*(8*8), thSCD1=180,thSCD2=98 )
binomial1 = degrain1.Merge( degrain2, 0.2 ).Merge( edi, 0.0625 )

vresharp = Merge( binomial1.mt_expand( mode="vertical", U=3,V=3 ), binomial1.mt_inpand( mode="vertical", U=3,V=3 ) )
resharp = binomial1.mt_lutxy( vresharp.RemoveGrain(12), "x x y - "+ string(Sharpness) + " * +", U=3,V=3 )

backBlend1 = resharp.mt_makediff( mt_makediff( resharp, binomial1, U=1,V=1 ).RemoveGrain( 12, -1 ).GaussResize( w,h, 0,0, w+epsilon,h+epsilon, p=5 ), U=2,V=2 )

sharpLimit1 = backBlend1.mt_clamp( tMax,tMin, 0,0, U=3,V=3 )

stableSuper = sharpLimit1.MSuper( pel=2, levels=1, hpad=pad, vpad=pad )
stable = sharpLimit1.MDegrain1( stableSuper, bVec1,fVec1, thSAD=4*(8*8), thSCD1=180,thSCD2=98 )

repair2 = stable.DeshimmerRepair( edi )

return repair2
}

function DeshimmerRepair( clip Input, clip Ref )
{
bobdiff = mt_makediff( Ref, Input, U=3,V=3 )
choke1 = bobdiff.mt_inpand( mode="vertical", U=3,V=3 ).mt_inpand( mode="vertical", U=3,V=3 ).mt_deflate( U=3,V=3 )
choke1 = choke1.mt_expand( mode="vertical", U=3,V=3 ).mt_expand( mode="vertical", U=3,V=3 )
choke2 = bobdiff.mt_expand( mode="vertical", U=3,V=3 ).mt_expand( mode="vertical", U=3,V=3 ).mt_inflate( U=3,V=3 )
choke2 = choke2.mt_inpand( mode="vertical", U=3,V=3 ).mt_inpand( mode="vertical", U=3,V=3 )
bobrepair = bobdiff.mt_lutxy( choke1, "x 129 < x y 128 < 128 y ? ?", U=3,V=3 ).mt_lutxy( choke2, "x 127 > x y 128 > 128 y ? ?", U=3,V=3 )
return Input.mt_adddiff( bobrepair, U=3,V=3 )
}

[Andrey /MAG/]

I tried a number of .d2v sources, several (but not all) demonstrated slight non-determinism
Do you ever see such non-determinism when using MAnalyse function?
I sow different results earler on MAnayse. And I can't understand what the cause of results difference from run to run.

I have checked source codes. And no "random" function there. :confused:

[-Vit-]

The script I provided above uses MAnalyse if SVP=false and SVAnalyse if SVP=true. It's always deterministic with MAnalyse and with single-threaded SVAnalyse. However, with multi-threaded SVAnalyse (SetMTMode) it is fairly frequently non-deterministic on some sources. So the issue is with threading: thread-unsafe code, a dependency on the order of frame processing, or something similar...

Edit: <snip> Removed a mistaken crash report - I'd missed out an MSuper. Must remember that a super clip from SVSuper can't be used with MVTools functions. The TGMC script does that properly though.

[chainik_svp]

non-deterministic

Found it, it's caused by error in reverse vectors handling.
Also found bug in svpflow2 that could lead to crash in MT mode :)

[chainik_svp]

OK, ver.1.0.3 (http://www.svp-team.com/files/gpl/svpflow-1.0.3.zip) :D

= fixed random crash in MT mode
= fixed usage of invalid predictors from reverse vectors

[Bernardd]

Hello,
With ver 1.0.3, in CPU mode, i have not the same output (very small difference) with refine: [ { thsad: 200 } ] or refine: [ ]. It is like thsad = 200 is not default value for SV Analyse refine params_string.
I do not understand why.
Thank.
Bernard

[chainik_svp]

Bernardd
What difference did you expect? I believe it works as described.

[Bernardd]

Hi Chainik

I want to write a script for SVSmooth with only the usefull params_string for my clip (restoring old Super 8 films). It seem for me that Refine params_string tunning is not necessary. Perhaps is wrong. For example i have changed refine: thsad value without observe frame picture change.

So in my script i have deleted all Refine params_strings with default values. This line " refine: [ { thsad: 200, search: { type: 4, distance: 4, satd: false }, penalty: { pnew: 50 } } ]" has been deleted. I expect no frame picture change, but i have a little change.

I hope you understand.

Thank

Bernard

[chainik_svp]

I hope you understand.

I'm trying :) So you think that "refine: []" should produce the same output as "refine: [ {thsad:200} ]", right?
This's wrong cause "[]" is just an empty array, nothing to do here. For the refinement there should be at least one element in the array, like this: "[ {} ]".

[Bernardd]

Ok, for this,
but i want to say that the not written line "refine: [{.............}]" (all line is deleted) do not produce the same output as "refine: [ {thsad:200} ]".

[Yellow_]

hi, any advice on parameters to minimize shape shifting Preditor style artifacts in movement, simple normal people movement. As a rough start point I tried defaults :-) and then this, I'm starting with 24p source to 120fps and I'm not expecting miracles just minimise movement artifacts however long it takes to analyse and encode. No doubt I'm using the functions badly:

super_params="{pel:1}"
analyse_params="{ algo: 2, block:{w:8} }"

super = SVSuper(super_params)
vectors = SVAnalyse(super, analyse_params)

forward_mv = SVConvert(vectors, false)
backward_mv = SVConvert(vectors, true)

super_mv = MSuper(pel=1, hpad=0, vpad=0) #padding should be zero here!
MFlowFps(super_mv, backward_mv, forward_mv, num=120, den=1)

Many thanks

[chainik_svp]

Yellow_

Why MFlowFps? It has no advantages over SVSmoothFps.
The main weapon to kill that arts around moving objects is cover/uncover masking (called "occlusion mask" in MVTools documentation) but this mask should be much more correct in SVPflow. So try to use SVSmoothFps with "algo:21", GPU acceleration and bicubic vectors/masks interpolation turned on ("cubic:1") and play with "mask.cover" value.

[Yellow_]

Thanks for the reply, unfortunatley I'm using this on Linux via Wine so haven't been able to get GPU stuff working even if my NV card is supported. My problem. :-)

So I'm here:

super = SVSuper("{pel:1}")
vectors = SVAnalyse(super, "{ algo: 21, block:{w:8} }")

SVSmoothFps(super, vectors, "{ num:120, den:1, algo:21, cubic:0 }", url="www.svp-team.com")

Looking at mask stuff now. Cheers.

**EDIT**

Vast improvement over first attempt. :-)

Added a mask cover of 50 to start, what I'm seeing is a jagged edge trailing movement, ie: outline of where the moving object was previous frame.

[chainik_svp]

haven't been able to get GPU stuff working
Have you seen that (http://imgur.com/a/MwglB)? ;)

BTW I've read that Wine now supports OpenCL calls but I'm too lazy to check it :D

---------
With smaller blocks - "{block:{w:8}, refine: [{thsad:-1}] }" - mask should be more accurate.

[Yellow_]

Cheers, I'll look into getting GPU stuff going via Wine. I get overlap error due to CPU frame comp with thsad:-1 :-(

[Mug Funky]

just dropping by to say thanks to all involved in the SVP project.

my canon workflow owes a lot to it :)

what i'm doing:

- shoot at as high a framerate as i can manage (720p60), at as high a shutterspeed as i can get a good exposure on (i like to shoot wide open, so it's no problem to get 1/250 or so). also, high fps means less rolling-shutter effect than if i'd shot at my target frame rate. less jelly = better.

- depanstabilize. goes without saying if i'm not willing to give up coffee.

- SVPfps to my output framerate*samples. samples working in the same way as in a graphics package.

- temporalsoften to blend only frames that correspond to my desired shutter angle wrt the output frame rate

- selectevery(samples, 0)

i'm able to output 2400/1001 with motion blur as if it was shot that way at 180 degrees :)

the interpolation quality is such that when it fails, i don't see weird things. usually just a little ghosting.

me happy :)

[Anacletus]

Hi chainik_svp,

would you mind explaining how to translate this standard MDegrain2 call in order to take advantage of your plugins?


AviSource("something.avi")
super = MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)


If i understand correctly i should use something like this for MDegrain1?


AviSource("something.avi")
super = SVSuper("{pel:2, gpu:1}")
vectors = SVAnalyse(super, "{gpu:1,block:{w:8,h:8,overlap:2}}")
forward_mv = SVConvert(vectors, false)
backward_mv = SVConvert(vectors, true)
super_mv = MSuper(pel=1, hpad=0, vpad=0)
MDegrain1(super_mv, backward_mv, forward_mv, thSAD=400)


I'm missing if there the possibility to use more motion vectors as for MDegrain2 or if this is unnecessary with SVP plugins..

Can you please point me to the right direction?

Thanks

[chainik_svp]

Can you please point me to the right direction?
I think -Vit- already gave a clue (http://forum.doom9.org/showthread.php?p=1568520#post1568520) how to emulate "delta=2".

Again, I'm not trying to completely replace MVTools, so MDegrain and other things are not in my interests now ;)
But it's not a big deal to add "delta" param so if someone thinks it'll be useful I could do that.

[-Vit-]

My delta=2 method works fine, but don't try to simplify the fVec2 line, I believe it would be an error:

fVec2 = Interleave(vecs2e.SVConvert( isb=false ), vecs2o.SVConvert( isb=false )) # Correct
fVec2 = Interleave(vecs2e, vecs2o).SVConvert( isb=false ) # Error

That's because SVAnalyse generates forward vectors offset by 1 from MVAnalyse so SVConvert shifts the forward vectors back by one. However, with a delta of 2 they need shifted back by 2, so the SVConvert goes inside the Interleave. May not matter for the bVec3 line, but I suggest just to leave it as is in my original post (http://forum.doom9.org/showpost.php?p=1568520&postcount=45).

---

For delta=3 do this:

params_string = "{gpu:0}" # plus any other SVAnalyse settings
vecs30 = super.SelectEvery(3,0).SVAnalyse( params_string )
vecs31 = super.SelectEvery(3,1).SVAnalyse( params_string )
vecs32 = super.SelectEvery(3,2).SVAnalyse( params_string )
fVec3 = Interleave( vecs30.SVConvert(isb=false), vecs31.SVConvert(isb=false), vecs32.SVConvert(isb=false) )
bVec3 = Interleave( vecs30.SVConvert(isb=true ), vecs31.SVConvert(isb=true ), vecs32.SVConvert(isb=true ) )


Never tested that but it's just the same process.

And here's a function to generate MVTools vectors using SVAnalyse and an arbitrary delta. It requires GScript. I've only tested it a little:

# Use SVAnalyse with a given delta and convert vectors to MVTools format
# Returns a single vector clip containing interleaved forward and backward vectors.
# Example:
# vec3 = super.SVAnalyseConvert( 3, "{gpu:0, pel:2}" ) # delta=3
# fVec3 = vec3.SelectEven()
# bVec3 = vec3.SelectOdd()
#
function SVAnalyseConvert( clip super, int "delta", string "params_string" )
{
delta = default(delta, 1)
params_string = default(params_string, "{gpu:0}")

GScript("""
if (delta == 1) {
vecs = super.SVAnalyse( params_string )
return Interleave( vecs.SVConvert(isb=false), vecs.SVConvert(isb=true) )
}
else {
cf = ""
cb = ""
sD = string(delta)
for (i=0, delta-1) {
sI = string(i)
Eval( "vecs"+sD+sI+"=super.SelectEvery("+sD+","+sI+").SVAnalyse( params_string )" )
cf = cf + "vecs"+sD+sI+".SVConvert(isb=false)"
cb = cb + "vecs"+sD+sI+".SVConvert(isb=true)"
if (i != delta-1) {
cf = cf + ","
cb = cb + ","
}
}
return Eval( "Interleave(Interleave("+cf+"),Interleave("+cb+"))" )
}
""")
}


___

And yes, I guess a delta parameter would be nice! :D

[Anacletus]

Again, I'm not trying to completely replace MVTools, so MDegrain and other things are not in my interests now ;)

Fair enough, thank you ;)

@-Vit-
Thank you too ;)

[chainik_svp]

So in my script i have deleted all Refine params_strings with default values. This line " refine: [ { thsad: 200, search: { type: 4, distance: 4, satd: false }, penalty: { pnew: 50 } } ]" has been deleted. I expect no frame picture change, but i have a little change.

A-ha! :D Why "distance: 4"? Default value is pel value from SVSuper.

[chainik_svp]

-Vit-
I guess a delta parameter would be nice!

Ver. 1.0.4 (http://www.svp-team.com/files/gpl/svpflow-1.0.4.zip) ;)
look at special.delta param in SVAnalyse
{block:{...}, main:{...}, refine:{...}, special:{delta:2}}

[Bernardd]

Hi Chainik,

I apologize, my Refine line is not with whole default values. But always

output for this
SVAnalyse( super, """{ gpu: 0, vectors: 3, block: { w: 16, h: 16, overlap: 0 },
main: { levels: 0,
search: { type: 4, distance: -10, sort: true, satd: false,
coarse: { type: 4, distance: -10, satd: true, trymany: false, bad: { sad: 1000, range: -24 } } },
penalty: { lambda: 10.0, plevel: 1.5, lsad: 8000, pnew: 50, pglobal: 50, pzero: 100, pnbour: 50, prev: 0 } } ,
refine: [ { thsad: 200, search: { type: 4, distance: 2, satd: false }, penalty: { pnew: 50 } } ] }""")


is not same as output for this
SVAnalyse( super, """{ gpu: 0, vectors: 3, block: { w: 16, h: 16, overlap: 0 },
main: { levels: 0,
search: { type: 4, distance: -10, sort: true, satd: false,
coarse: { type: 4, distance: -10, satd: true, trymany: false, bad: { sad: 1000, range: -24 } } },
penalty: { lambda: 10.0, plevel: 1.5, lsad: 8000, pnew: 50, pglobal: 50, pzero: 100, pnbour: 50, prev: 0 } }
}""")


Bernard

[chainik_svp]

Bernardd
You don't have any refinement defined in second case. I repeat: default refinement will be with "refine: [ {} ]" string.

[Bernardd]

Thank Chainik,

I apologize, I have not understand fast. Now it is OK.

Second question, when i restore old Super 8 movies to return Framerate from 16.667 fps to 25, i have tried "plevel = 10" with algo 23 for minimize blend.

What it is the max plevel value usable ?

Bernard

[chainik_svp]

Bernardd
What it is the max plevel value usable ?

I've got no idea :)
But this extremely high "plevel" value means almost zero lambda penalty on all levels except smallest one which leads to less coherent vectors field.

[chainik_svp]

Version 1.0.5 (http://www.svp-team.com/files/gpl/svpflow-1.0.5.zip)
= added compatibility with GTX680 (and may be with all other Kepler GPUs) - thanks to flagger

[Bernardd]

Thank Chainik,

I understand now why high plevel is able to minimize blend in some case. With less motion coherence, blend is no more necessary to build the best coherent frame.

Bernard

[Boulder]

-Vit-
I guess a delta parameter would be nice!

Ver. 1.0.4 (http://www.svp-team.com/files/gpl/svpflow-1.0.4.zip) ;)
look at special.delta param in SVAnalyse
{block:{...}, main:{...}, refine:{...}, special:{delta:2}}So can we now simply use three SVAnalyse calls with various delta and then SVConvert to get the MVTools-format vectors out? It seems that SVAnalyse produces a lot more stable vector field than MAnalyse so I'd very much like to incorporate it into my own functions as an alternative :)

And thanks for all your hard work, there is never too much development these days :)

[chainik_svp]

So can we now simply use three SVAnalyse calls with various delta and then SVConvert to get the MVTools-format vectors out?

That's the plan :) But someone obviously should try it and report :D

thanks for all your hard work, there is never too much development these days
thanks! (http://www.svp-team.com/wiki/Donation)

[Mounir]

I haven't tried svp yet but i'd be intereted as it us the gpu; basically i want to replace the mvtools part in my script how would i code that ?

my script:

SeparateFields()
a=last
mot=removegrain(11,0).removegrain(20,0).DepanEstimate(range=2)
take2=a.depaninterleave(mot,prev=2,next=2,subpixel=2)
clean1=take2.TMedian2().selectevery(5,2)

sup1 = clean1.minblur(1).removegrain(11,0).removegrain(11,0)
\ .mt_lutxy(clean1,"x 1 + y < x 2 + x 1 - y > x 2 - y ? ?",U=2,V=2)
\ .msuper(pel=2,sharp=0)
sup2 = a.msuper(pel=2,levels=1,sharp=2)

bv22=sup1.manalyse(isb=true, truemotion=true,global=true,delta=2,blksize=8,overlap=4,search=5,searchparam=3,DCT=2)
bv21=sup1.manalyse(isb=true, truemotion=true,global=true,delta=1,blksize=8,overlap=4,search=5,searchparam=3,DCT=2)
fv21=sup1.manalyse(isb=false,truemotion=true,global=true,delta=1,blksize=8,overlap=4,search=5,searchparam=1,DCT=2)
fv22=sup1.manalyse(isb=false,truemotion=true,global=true,delta=2,blksize=8,overlap=4,search=5,searchparam=1,DCT=2)
interleave(a.mcompensate(sup2,fv22),a.mcompensate(sup2,fv21),a,a.mcompensate(sup2,bv21),a.mcompensate(sup2,bv22))

selectevery(5,2)
sup3 = last.msuper(pel=2,sharp=2)
bv33=sup3.manalyse(isb=true, truemotion=true,global=true,delta=3,blksize=8,overlap=4,search=5,searchparam=3,DCT=2)
bv32=sup3.manalyse(isb=true, truemotion=true,global=true,delta=2,blksize=8,overlap=4,search=5,searchparam=3,DCT=2)
bv31=sup3.manalyse(isb=true, truemotion=true,global=true,delta=1,blksize=8,overlap=4,search=5,searchparam=3,DCT=2)
fv31=sup3.manalyse(isb=false,truemotion=true,global=true,delta=1,blksize=8,overlap=4,search=5,searchparam=1,DCT=2)
fv32=sup3.manalyse(isb=false,truemotion=true,global=true,delta=2,blksize=8,overlap=4,search=5,searchparam=1,DCT=2)
fv33=sup3.manalyse(isb=false,truemotion=true,global=true,delta=3,blksize=8,overlap=4,search=5,searchparam=1,DCT=2)
last.mdegrain3(sup3,bv31,fv31,bv32,fv32,bv33,fv33,thSAD=499)
Interleave()
weave()

[chainik_svp]

Mounir
You script won't use any GPU with SVPflow.

[Bloax]

SVP Is still faster though. :rolleyes:

[chainik_svp]

Compared with what? :) With the original Fizick's 2.5.11.3 - yes, with the version from SVP 3.0.6 (http://www.svp-team.com/wiki/Plugins:_MVTools2) - not really (except SVPflow has "adaptive search radius" feature of cause).

Mounir
Do you really need "dct=2" and different search options for forward and backward MVs?
If not then central part of the script could be something like this:
sup1 = clean1.minblur(1).removegrain(11,0).removegrain(11,0)
\ .mt_lutxy(clean1,"x 1 + y < x 2 + x 1 - y > x 2 - y ? ?",U=2,V=2)
\ .SVSuper("pel:2, scale:{up:0}")

search_params="block:{w:8,overlap:3}" #or whatever

v21=sup1.SVAnalyse("{"+search_params+"}")
v22=sup1.SVAnalyse("{"+search_params+",special:{delta:2}}")

bv22=v22.SVConvert(isb=true)
bv21=v21.SVConvert(isb=true)
fv21=v21.SVConvert(isb=false)
fv22=v22.SVConvert(isb=false)

sup2 = a.msuper(pel=2,levels=1,sharp=2)
interleave(a.mcompensate(sup2,fv22),a.mcompensate(sup2,fv21),a,a.mcompensate(sup2,bv21),a.mcompensate(sup2,bv22))

selectevery(5,2)
sup3 = last.msuper(pel=2,sharp=2,hpad=0,vpad=0)

# SVAnalyse accepts MSuper with zero padding!
v31=sup3.SVAnalyse("{"+search_params+"}")
v32=sup3.SVAnalyse("{"+search_params+",special:{delta:2}}")
v33=sup3.SVAnalyse("{"+search_params+",special:{delta:3}}")

bv33=v33.SVConvert(isb=true)
bv32=v32.SVConvert(isb=true)
bv31=v31.SVConvert(isb=true)
fv31=v31.SVConvert(isb=false)
fv32=v32.SVConvert(isb=false)
fv33=v33.SVConvert(isb=false)

last.mdegrain3(sup3,bv31,fv31,bv32,fv32,bv33,fv33,thSAD=499)

[Mounir]

@ chainik_svp
Your code return an error for \ .SVSuper("pel:2, scale:{up:0}")
error: i don't know what "clean1" means

[chainik_svp]

o_O I thought it's your script.
Or you've just taken it from somewhere and you've got no idea how it works?
In the last case I suggest to ask -Vit- for assistance with all this stuff like "delta" and mdegrain.

[Tempter57]

Mounir
SVSuper( "{ gpu:0, pel:2, scale:{up:0} }")

[chainik_svp]

Tempter57
if it was so easy
error: i don't know what "clean1" means
;)

[Tempter57]

Tempter57
if it was so easy

;)
Well, preset DVD MDegrain2_SVP mask4 DLS
#RemoveGrainSSE2.dll
#RepairSSE2.dll
#mvtools2SVP.dll
#svpflow1.dll
#svpflow2.dll
#fft3dgpu.dll
#WarpSharp.dll
#mt_masktools-26.dll
#average.dll
#AddGrainC.dll
#GradFun2DB.dll
#VagueDenoiser.dll
#flash3kyuu_deband.dll
#Gradfun2dbmod.avs
#Ylevels.avs
#LimitedSharpenFaster Mod.avs


setmemorymax(768)

# ColorYUV(gain_y=0,cont_y=0,cont_u=0,cont_v=0,gain_v=0,gain_u=-0,off_y=0,off_u=-0,off_v=-0)

source = last
preNR = source.fft3dgpu(wintype=1,degrid=1,bw=16,bh=16,ow=8,oh=8,bt=4,sigma=1.0,sigma2=1.2,sigma3=2.0,sigma4=1.0,plane=4).GradFun2DB(1.01)

setmtmode(2)
sup1 = preNR.SVSuper( "{ gpu:0, pel:2, scale:{up:2, down:2} }")

search_params = "gpu:0, vectors:3, block:{w:16,overlap:3}"
v21 = sup1.SVAnalyse("{"+search_params+"}")
v22 = sup1.SVAnalyse("{"+search_params+",special:{delta:2}}")

bv22 = v22.SVConvert(isb=true)
bv21 = v21.SVConvert(isb=true)
fv21 = v21.SVConvert(isb=false)
fv22 = v22.SVConvert(isb=false)

mask1 = source.mmask(bv22, ml=100, kind = 1, Ysc = 255, gamma=0.999)
mask2 = source.mmask(bv21, ml=100, kind = 1, Ysc = 255, gamma=0.999)
mask3 = source.mmask(fv21, ml=100, kind = 1, Ysc = 255, gamma=0.999)
mask4 = source.mmask(fv22, ml=100, kind = 1, Ysc = 255, gamma=0.999)
maskb = mt_lutxy(mask1,mask2,"x 255 < y 255 < x y + 2 / x ? y ?")
maskf = mt_lutxy(mask3,mask4,"x 255 < y 255 < x y + 2 / x ? y ?")
tmask = mt_lutxy(maskb,maskf,"x 255 < y 255 < x y + 2 / x ? y ? 32 - 255 * 223 /")# комбинированная маска оценки движения SAD

source2 = mt_merge(source,preNR,tmask,Y=3,U=3,V=3)
sup2 = source.msuper(pel=2, levels=1, sharp=2)
den = source2.MDegrain2(sup2,bv21,fv21,bv22,fv22,thSAD=300,thSCD1=400,thSCD2=102)
Diff1 = mt_makediff(source,den,U=3,V=3)

NR = den.VagueDenoiser(method=4, nsteps=8, wavelet=2, Wiener=true, auxclip=preNR, percent=95, chromaT=0.8, wratio=0.75, threshold=0.4)
Diff2 = mt_makediff(source,NR,U=3,V=3)

lutxy = mt_lutxy(Diff1,Diff2,"x 128 - abs y 128 - abs < x y ?")
smB = source.mt_makediff(lutxy,U=3,V=3)

# MASKING
mE = mt_edge(smB,"prewitt",0,255,0,0,V=1,U=1).mt_lut(expr="x 1.8 ^",U=1,V=1).removegrain(4,-1).mt_inflate(U=1,V=1)
mL = mt_logic(tmask.invert(),mE,"min",U=1,V=1).removegrain(20,-1)
mF = mt_logic(tmask,mE,"max",U=1,V=1).removegrain(20,-1)

# SHARPENING
b1c = source.MCompensate(sup2, bv21)
f1c = source.MCompensate(sup2, fv21)
Sclp = smB.LSFmod(defaults="slow", preblur="ON", strength=100)
# Sclp = ContraHD(smB,source,b1c,f1c,0)
Tmax = source.mt_logic(f1c,"max",U=1,V=1).mt_logic(b1c,"max",U=1,V=1)
Tmin = source.mt_logic(f1c,"min",U=1,V=1).mt_logic(b1c,"min",U=1,V=1)
shrp = Sclp.mt_clamp(Tmax, Tmin, 2, 2, U=1, V=1)
sL = mt_merge(smB,shrp,mL,U=2,V=2)

# DEBANDING
# GFc = sL.f3kdb(sample_mode=2,dynamic_grain=false,keep_tv_range=false,dither_algo=3,y=64,cb=64,cr=64,grainY=48,grainC=48)
GFc = sL.GradFun2DBmod(thr=1.21,thrC=1.5,mode=2,str=0.6,strC=0.0,temp=50,adapt=64)
Frs = mt_merge(GFc,sL,mF,luma=true,U=3,V=3)
Frs#.mergechroma(den)
YlevelsS(0,1.0,255,0,255,false)

# -- visualisations --
# stackvertical(source,last)
# interleave(source,last)


if SVSuper( " gpu:0, pel:2, scale:{up:2, down:2 } " ) => error " SVSuper: invalid "params" syntax"

[bmb]

hey their, im currently using this script

super = MSuper(pel=2,chroma=false)
backward_vec1 = super.MAnalyse(isb = true, blksize=16, delta = 1, overlap=8,chroma=false,search=5,searchparam=4,temporal=true)
forward_vec1 = super.MAnalyse(isb = false, blksize=16, delta = 1, overlap=8,chroma=false,search=5,searchparam=4,temporal=true)
MDegrain1(super, backward_vec1,forward_vec1,thSAD=20,plane=0)

i use it to denoise and remove grain generated from sharpening, it works great (the best iv used so far) it keeps the detail of the picture sharp and still theirs no noise or blocks generated.. my sources are bluray content.. i sometimes get slight noise and blocks (depending on the compression) i was wondering if you could translate it or offer a script better with this SVP and il test it out and report back.. thanks ...

[Boulder]

One small question: is there any harm in using a super clip created by MSuper instead of SVSuper when the vectors are converted to MVTools2 format after SVAnalyse?

[chainik_svp]

Boulder
There's no difference.

bmb
super = MSuper(pel=2,hpad=0,vpad=0)
vec = super.SVAnalyse("{block:{overlap:3}}")
backward_vec1 = vec.SVConvert(isb=true)
forward_vec1 = vec.SVConvert(isb=false)
MDegrain1(super, backward_vec1,forward_vec1,thSAD=20,plane=0)
didn't test it

[Boulder]

I tried to test your modded Avisynth build, but avs2pipemod keeps on crashing during launch so I cannot pipe the output to 64-bit x264. Opening the script in VDub has no issues.

[chainik_svp]

Boulder
tried version from here (http://forum.doom9.org/showthread.php?p=1565165#post1565165), works for me (without x264): "avs2pipemod.exe -rawvideo test.avs > out"

[Boulder]

Hm, it's possible that I have an outdated piping client (although I have had no problems using Avisynth 2.5.8 or 2.6 earlier). I'll get the latest one and retry.

[Boulotaur2024]

just dropping by to say thanks to all involved in the SVP project.

my canon workflow owes a lot to it :)

what i'm doing:

- shoot at as high a framerate as i can manage (720p60), at as high a shutterspeed as i can get a good exposure on (i like to shoot wide open, so it's no problem to get 1/250 or so). also, high fps means less rolling-shutter effect than if i'd shot at my target frame rate. less jelly = better.

- depanstabilize. goes without saying if i'm not willing to give up coffee.

- SVPfps to my output framerate*samples. samples working in the same way as in a graphics package.

- temporalsoften to blend only frames that correspond to my desired shutter angle wrt the output frame rate

- selectevery(samples, 0)

i'm able to output 2400/1001 with motion blur as if it was shot that way at 180 degrees :)

the interpolation quality is such that when it fails, i don't see weird things. usually just a little ghosting.

me happy :)
Hi Mug Funky, could you please post your script ?

I currently use QTGMC for my motion blur needs but MVTools does produce weird artefacts *, I'd be curious to see how SVPflow performs in comparison

* these aren't exactly artefacts in my case but more the typical MvTools "morphing effect" between scene changes

[kolak]

+1 for the script :)

[Boulder]

Hm, it's possible that I have an outdated piping client (although I have had no problems using Avisynth 2.5.8 or 2.6 earlier). I'll get the latest one and retry.Yep, the latest version seems to work. Now some testing and if results are what I'd like them to be, I think I'm going to ask SEt if he could take a look at the modifications to put them in his 2.6 build :)

[chainik_svp]

The main idea is to limit each cache size (in frames), opposite to Avisynth approach when all caches uses one common "frames" pool somehow limited with SetMemoryMax value. This can easily lead to cache misses in general case BUT as far as I know that SVP's script is linear frame-by-frame only - it works.

So may be it's not a good idea to include such behavior in official Avisynth, but may be as an additional argument to SetMTMode()...

[Boulder]

I have some results. In a regular case with "DGSource-Downsize to 720p-MVTools based denoise", your and SEt's Avisynth build are pretty much the same what comes to speed. Your build uses something like 200-250M less memory (svp_cache_fwd=4 vs SetMemoryMax(512)).

In an "MPEG2Source-TFM-TDecimate-MVTools based denoise", SEt's build is slightly faster. The amount is small, 1-2%, and the difference would be even smaller if x264 was set to a slower preset (I used ultrafast to remove the encoding bottleneck). The difference in memory usage is the same as in the first example

However, a script with SRestore doesn't seem to work with your build as it crashes upon script loading in VDub and avs2pipemod. I'm not that surprised since it's a mean piece of work and if I'm not entirely mistaken, multithreading is a bit of a no-no although I don't remember anybody really confirming that. But doesn't the same apply to TDecimate as well?

[chainik_svp]

Your build uses something like 200-250M less memory (svp_cache_fwd=4 vs SetMemoryMax(512)).
720p is too easy and 250M is nothing :) I'm talking about situations when official Avisynth can't work at all. For example "canonical" MVTools-based interpolation script can easily run out of memory with 1080p and pel=2 in MSuper regardless of SetMemoryMax value.

[Boulder]

Hehe, that's true. I was afraid of trying to QTGMC 1080i as the tests would have a taken a veeery long time ;)

[chainik_svp]

4k (http://www.svp-team.com/forum/viewtopic.php?id=767) ? :D

[Boulder]

Yeah ----- when the day comes that I can buy a reasonably priced TV that supports the format :D

[Mug Funky]

for the two people interested:


function frcblur( clip c, int "num", int "den", float "angle", int "samples" )
{

num = default(num,24000)
den = default(den,1001)
samples = default(samples,7) # anything more than 11 is way overkill. internally this number is doubled by default.
angle = default(angle,0) # 0 disables motion blur. 180 is standard cine camera.
multiplier = angle==0? 1 : round( samples/(angle/360.) )
parmstring = "{rate:{num:" + string( multiplier * num ) + ",den:" + string(den) + ",abs:true},algo:21,cubic:1}}"

c

spr = svsuper("{pel:2,gpu:1}")
vec = svanalyse(spr,"""{block:{w:32,h:32},refine:[{thsad:200}]} """)
sorathread()

svsmoothfps(spr,vec,parmstring, url="www.svp-team.com")

sorathread()
angle==0? last : temporalsoften(multiplier/2 -1,255,255,255)
angle==0? last : selectevery(multiplier,0)

}


this requires sorathread, the very easy to use threading plugin. i'm running 2.6 so i don't have much MT stuff available.

here's a script example, with stabilization thrown in:
QTinput("x:\things\MVI_1402.MOV",audio=2)

assumetff()

assumetff()
converttoyv12()

sorathread()
mdata = DePanEstimate(last)
DePanStabilize(last, data=mdata,cutoff=0.333,initzoom=1.1,addzoom=true,zoommax=1.5,rotmax=10.,tzoom=3.0,pixaspect=1.0,prev=3,next=3)
sorathread()

frcblur(num=25,den=1,angle=180)



requires the latest (still old) depan+depanestimate

i'm using QTinput because of the luma levels issue with ffms2.

[Reel.Deel]

Thanks Mug Funky! The result looks very nice. :)

For Avisynth MT I had to add the mt=x argument to svsmoothfps.

Sorry for being a little off topic but what are the issues with FFMS2 and luma?

[kolak]

Thanks!- will try.

[Mug Funky]

@ Reel.Deel:
libavcodec based decoders until very recently decoded canon footage as tv range when they should have decoded them as fullrange. so we ended up with crushed blacks and clipped whites.

from watching the changelogs, it's been fixed recently, but i'm not sure which version ffms is compiled against, and i broke my msys environment and can't seem to get ffms-cplugin to usefully compile any more. hence i'm using qtinput to be safe (if a little unnecessarily slow and in 422 instead of native 420)

[Reel.Deel]

I've been using the Canon Technicolor profile and have not noticed any of the above issues. I will definitely keep an eye on it though :). Thanks again Mug Funky.

@ chainik_svp

Hello chainik_svp, first of all thanks for all your work and of course the rest of the SVP Team. I was reading the changelog (http://www.svp-team.com/wiki/Changelog) and noticed that v.3.1.2 was just recently released. Just wondering if any of the SVP dlls have been updated since v.1.0.5?

[chainik_svp]

Reel.Deel
Yeah, algo=1 is broken in 1.0.5 and it's fixed in libs bundled with SVP 3.1.2.
Also there was a little issue with U & V channels on smallest levels in super clip.

[TheSkiller]

I just tried to test the motion blur script (http://forum.doom9.org/showthread.php?p=1577458#post1577458) by Mug Funky and downloaded the SVP AviSynth plugins (not the installer) from their download site (http://www.svp-team.com/wiki/Download).
The problem is, whenever I try to load my script I get (for example): "Plugin svpflow1.dll is not an AviSynth 2.5 plugin".

OK, why is this? :( I'm using 2.6 SEt.


Edit: Putting all plugins in a folder and calling only svpflow1 and 2 seems to work better (am I supposed to do that?), but I still get an instant crash without error message.

This does not work here:
SetMemoryMax(1024)

LoadPlugin("C:\libs\svpflow1.dll")
LoadPlugin("C:\libs\svpflow2.dll")

AVIsource("E:\unsynced\6_b.avi").ConvertToYV12()

frcblur(num=60,den=1,angle=360)

OK, I got it to work. It seems it is mandatory to define SetMTmode() with SVPplugins? I also added mt=2 (2 threads) to svsmoothfps.

[Mug Funky]

ah. nice find. i tend not to use MT build because that's how i roll. i'll probably get into them when they're more stable than the stock release. they probably are already and i'm just scared...

though one thing - temporalsoften needs to be done in linear colorspace to give a really convincing effect. unfortunately it'll need a rewrite for that, because the deep colour workarounds don't work for filters that change the picture substantially - they merge back in all bandy and weird.

here's where i wish i wasted more time in highschool learning C++ and not learning 3D modelling, but then my life would have turned out completely differently.

[chainik_svp]

It seems it is mandatory to define SetMTmode() with SVPplugins?

Not really.
SVSmoothFps just needs to know how many threads are in use.
The code is like this:
int threads=get_value_from_params("mt");
if(threads==0)
threads=avisynthEnvironment->GetMTMode();

So:
0. Avisynth 2.5, 2.6 ---> error loading svpflow2.dll (undefined reference to GetMTMode)
1. With "mt" value specified it'll work in any other case
2. Otherwise (without "mt" value):
2.1. Avisynth 2.5 MT ---> OK
2.2. Avisynth 2.5 MT without SetMTMode() call ---> hmmm, i've no idea :D
2.3. Avisynth 2.6 MT ---> crash (different IScriptEnvironment interface definition)

[kolak]

chainik_svp -any news about improvements to scene change detection?

[Terka]

Hi chainik, when do you think svp would be ready to use in complex scripts like QTGMC?

[Boulder]

There is no reason why it would not work. It's more like "when is -Vit- ready to publish a version of QTGMC with SVAnalyse support". The syntax is a bit cumbersome and as QTGMC uses parameters heavily it's not too easy to modify the script.

[aegisofrime]

There is no reason why it would not work. It's more like "when is -Vit- ready to publish a version of QTGMC with SVAnalyse support". The syntax is a bit cumbersome and as QTGMC uses parameters heavily it's not too easy to modify the script.

I may be remembering things wrongly but I think he said that SVP offered little improvement, speed or quality wise over MVTools.

Correct me if I'm wrong though.

[poisondeathray]

I may be remembering things wrongly but I think he said that SVP offered little improvement, speed or quality wise over MVTools.

Correct me if I'm wrong though.

The 1st post

Short version: SVPflow is a successor to MVTools2, providing more speed and more quality.



But I don't recall seeing actual #'s based on GPU speedup comparisons or detailed quality comparisons (they might be buried somewhere)

[Keiyakusha]

it is a successor to mflowfps so far. it need to improve a lot to be useble for something that is not frame interpolation... as I understand mdegrain is not possible at all with SVP. you still have to add mvtools and even then it will be no more than temporal radius 1. and overcoming this by scripting will be slower than just using normal mvtools... even with temporal radius 1 SVP+mvtools approach hardly beats classic mvtools tr1 speed-wise. Also I got some artifacts with SVP's analogue to mrecalculate.
and regarding non-svp mvtools from svp project... i find dither-mvtools to be faster. (chroma wasn't processed when I compared speed)

[Boulder]

You can definitely have temporal radius higher than 1, that's what the delta parameter is for in SVAnalyse.

If you find artifacts, it would be useful to everyone if they were reported.

The vector field produced by SVAnalyse is different from what comes out of MAnalyse. I don't know if it's better or worse, but to me it looks as if it catches the actual motion better.

[Keiyakusha]

You can definitely have temporal radius higher than 1, that's what the delta parameter is for in SVAnalyse.
I don't know what delta is. It says:special: { delta: 1 } Some special parameters not used in SVP. Interval between analysed frames.
Not very informative. Please post script that shows how to simulate mvtools mdegrain2-3
From what I understand equivalent to mvtools temporal radius is "vectors" parameter
1 - forward only, from current frame to the following one (not useful at all),
2 - backward only, from following frame to the current one (useful only with "smoothfps.algo: 1"),
3 - search both directions.
how to make it go from current frame to 3 frames both directions and then use it in some equivalent of mvdegrain (that doesn't exist)? if it is possible, why it doesn't mentions it?

If you find artifacts, it would be useful to everyone if they were reported.
These are kind of ghosting similar to the one when you see when doing frame interpolation and happens with extreme values of thsad in refine. but without extreme values it doesn't refines as good as mrecalculate. was found on anime sources when you don't necessarily have motion in every (part of the) frame.

[Boulder]

This post has one example of a 3-frame radius in MDegrain: http://forum.doom9.org/showthread.php?p=1574161#post1574161 (the latter part of the script). The vectors parameter tells if the result should contain forward, backward or both vectors.

[Keiyakusha]

I see, then they need to rewrite documentation because it clearly states that it goes only one frame in one direction and delta is not used ^__^
I'll try some time later delta=2 and 3. but still we don't have replacement for mdegrain. here is no mistake.

[chainik_svp]

Keiyakusha

"delta" is not a part of SVP (that's why it's named "special.delta" ;)), it was added only by -Vit-'s request.
I dunno why he's gone from this thread right after it was added :D, may be MVs field quality isn't so important in deinterlacing.

And yes, I believe SVPflow vectors are better than MVTools. (otherwise what's the point? :D)

when do you think svp would be ready to use in complex scripts
We've made two options to "connect" almost any MVTools-based script to SVPflow:
- ability to use MSuper as super clip and
- SVConvert function
and I've no idea what else we could do :confused:

they need to rewrite documentation
I wish it was the primary task :devil:

chainik_svp -any news about improvements to scene change detection?

Sorry, it's summer time :)

[Keiyakusha]

and I've no idea what else we could do :confused:

Implement mdegrain in renderer part and anything else from mvtools that isn't in SVP yet?

So far this is limited and only partially true:
SVPflow is a successor to MVTools2, providing more speed and more quality

[Reel.Deel]

Implement mdegrain in renderer part and anything else from mvtools that isn't in SVP yet?

So far this is limited and only partially true:SVPflow is a successor to MVTools2, providing more speed and more quality.


To be fair, Chainik_svp did post a disclaimer.


Disclaimer.
SVPflow isn’t a complete replacement for MVTools cause it’s missing most of additional functions. As of now the main goal of project is to provide fast and high quality real-time video conversion, so all functions unnecessary for this task was cut off and sources were cleared and refactored.


Later on, he went on to say this:

Again, I'm not trying to completely replace MVTools, so MDegrain and other things are not in my interests now ;)
But it's not a big deal to add "delta" param so if someone thinks it'll be useful I could do that.

------------------------------------------

@ chainik_svp

it's summer time :)

Enjoy your summer!!:D

[Keiyakusha]

To be fair, Chainik_svp did post a disclaimer.
Why you telling this to me? Tell it to those who want to "use SVP in complex scripts". Personally I'm not interested in this project that much.

[kolak]

@ chainik_svp

Enjoy your summer!!:D

+1 :thanks:

[johnmeyer]

[Edit]See later post (http://forum.doom9.org/showpost.php?p=1594927&postcount=128) for more up-to-date attempt (which still doesn't work ...).

Trying to replace MFlow in a motion-compensated dirt removal script, but not succeeding. Here's the original function:

function RemoveDirtMC(clip,int "limit", bool "_grey")
{
_grey=default(_grey, false)
limit = default(limit,6)
i=MSuper(clip,pel=2)
bvec = MAnalyse(i,isb=false, blksize=8, delta=1, truemotion=true)
fvec = MAnalyse(i,isb=true, blksize=8, delta=1, truemotion=true)
backw = MFlow(clip,i,bvec)
forw = MFlow(clip,i,fvec)
clp=interleave(forw,clip,backw)
clp=clp.RemoveDirt(limit,_grey)
clp=clp.SelectEvery(3,1)
return clp
}

And this is my attempt to re-write:

function RemoveDirtMCSVP(clip,int "limit", bool "_grey")
{
svp_flow_lib="C:\Program Files\AviSynth 2.5\plugins\MVTools\SVP Version\libflowgpu.dll"
_grey=default(_grey, false)
limit = default(limit,6)
i=MSuper(clip,pel=2)
bvec = MAnalyse(i,isb=false, blksize=8, delta=1, truemotion=true)
fvec = MAnalyse(i,isb=true, blksize=8, delta=1, truemotion=true)
backw = MSmoothFps (clip,i,fvec, bvec, algo=1) #These two lines appear to be the problem
forw = MSmoothFps (clip,i,fvec, bvec, algo=1)
clp=interleave(forw,clip,backw)
clp=clp.RemoveDirt(limit,_grey)
clp=clp.SelectEvery(3,1)
return clp
}


I think the problem is that, despite what the SVP doc says, MSmoothFPS doesn't really encapsulate ALL of the functionality of the various MVTools2 functions.

My purpose in doing this is initially to improve performance, but also perhaps also (eventually) improve quality by adding some of the refinements in the updated MVTools2 (which I installed) and SVP itself.

Any help would be appreciated. Thanks!

[Reel.Deel]

Hi John, to succesfully use SVP with MVTools2 you have to use SVAnalyze and SVConvert.

From the documentation (http://svp-team.com/wiki/Plugins:_SVPflow):
SVConvert(vectors, isb: bool) Convert SVAnalyse output to the format of MAnalyse compatible with "client" MVTools 2.5 functions.

vectors - motion vectors data produced by SVAnalyse function,
isb - which vectors to extracts: forward if isb=false, backward if isb=true.

Example:
super = SVSuper(super_params)
vectors = SVAnalyse(super, analyse_params)

forward_mv = SVConvert(vectors, false)
backward_mv = SVConvert(vectors, true)

super_mv = MSuper(pel=1, hpad=0, vpad=0) #padding should be zero here!
MFlowFps(super_mv, backward_mv, forward_mv, num=60, den=1)



* Edit *

Also, for SVSuper, SVAnalyze, and SVConvert you only need svpflow1.dll.

[johnmeyer]

Hi John, to succesfully use SVP with MVTools you have to use SVAnalyze and SVConvertI have used that code in other projects, but I was lead to believe that the special MVTools2 build available at the SVP project site lets you use MVTools2 vectors. Here's the sample code that is included with that download:

SetMemoryMax(1024)

pel=2
recalc=true

svp_flow_lib="..\libflowgpu.dll"
LoadPlugin ("..\mvtools2.dll")

SetMTMode(3,10)
DirectShowSource("path\to\video.avi")
ConvertToYV12()
SetMTMode(2)

super=MSuper(pel=pel)
finest=pel==1 ? super : MFinest(super)

backward_vec=MAnalyse(super, isb=true, blksize=16, overlap=4)
forward_vec=MAnalyse(super, isb=false, blksize=16, overlap=4)

backward_vec = recalc==0 ? backward_vec : MRecalculate(super, backward_vec, blksize=8, overlap=2)
forward_vec = recalc==0 ? forward_vec : MRecalculate(super, forward_vec, blksize=8, overlap=2)

MSmoothFps(super, backward_vec, forward_vec, finest=finest, num=60, den=1, algo=13, sadml=200, blend=false)

The implication from the last line in this code is that MSmoothFPS can use the vectors from this version of MVTools2.

While I'm awaiting further replies, I'll try your suggestions. Also, this is a later version of my attempt to get it to work (but still not working):


function RemoveDirtMCSVP(clip,int limit, bool "_grey")
{
svp_flow_lib="C:\Program Files\AviSynth 2.5\plugins\MVTools\SVP Version\libflowgpu.dll"
_grey=default(_grey, false)
limit = default(limit,6)
i=MSuper(clip,pel=2)
bvec = MAnalyse(i,isb=false, blksize=8, delta=1, truemotion=true)
fvec = MAnalyse(i,isb=true, blksize=8, delta=1, truemotion=true)
backw = MSmoothFps (clip,i,fvec, algo=1,num=0, den=1,block=false)
forw = MSmoothFps (clip,i,bvec, algo=1,num=0, den=1,block=false)
clp=interleave(forw,clip,backw)
clp=clp.RemoveDirt(limit,_grey)
clp=clp.SelectEvery(3,1)
return clp
}

[Reel.Deel]

Ahh I see, you're trying to use the SVP MVTools (http://svp-team.com/wiki/Plugins:_MVTools2) and not the SVPFlow plugin, correct?

[johnmeyer]

Ahh I see, you're trying to use the SVP MVTools (http://svp-team.com/wiki/Plugins:_MVTools2) and not the SVPFlow plugin, correct?Yes, but my goal, as I stated above, is to improve performance and, possibly, quality. Therefore, I am not "stuck" on doing it this way. The reason I decided on this path is that it looked like I might not only be able to improve the performance in this part of the script, but also another part that uses MDegrain. I know there is a way to use SVP with MDegrain, even though it is a barely-supported afterthought to the main goal of the project (frame interpolation), but using this special MVtools2 build seemed like it might be more direct and have fewer problems.

Still working on it ...

[johnmeyer]

Getting closer, but still no joy. The video is 16 fps progressive. This looks like it should work, but I don't think algo=2 does anything different than algo=1. Neither line interpolates anything, but instead just gives me the original. I can change num to 32 and then get interpolation. I suppose I could do this for this frame, do the same thing for the previous frame (trim(last,0)) but that seems wrong somehow.

In the code below, the

interleave(backw,clip,forw)

line gives me three identical frames, i.e., I'm not getting an intermediate estimated frame as I would get with MFlow.

function RemoveDirtMCSVP(clip,int limit, bool "_grey")
{
svp_flow_lib="C:\Program Files\AviSynth 2.5\plugins\MVTools\SVP Version\libflowgpu.dll"
_grey=default(_grey, false)
limit = default(limit,6)
i=MSuper(clip,pel=2)
bvec = MAnalyse(i,isb=true, blksize=8, delta=1, truemotion=true)
fvec = MAnalyse(i,isb=false, blksize=8, delta=1, truemotion=true)
backw = MSmoothFps (clip,i,bvec,fvec, algo=2,num=16, den=1,block=false)
forw = MSmoothFps (clip,i,bvec,fvec, algo=1,num=16, den=1,block=false)
clp=interleave(forw,clip,backw)
clp=clp.RemoveDirt(limit,_grey)
clp=clp.SelectEvery(3,1)
return clp
}

[Didée]

The behavior is correct. MSmoothFPS is a framerate changer. And the wrong filter for what you want to do.

You have a 16fps clip. If you use num=32,den=1, then MSmoothFPS converts 16fps to 32fps by inserting 1 interpolated frame between each two original frames.
If you set num=16,den=1, then MSSmoothFPS converts 16fps to 16fps, by doing nothing. That's perfectly fine. ;)

What you need to use is MFlow, or (rather) MCompensate. But not MSmoothFPS / MFlowFPS.

[johnmeyer]

What you need to use is MFlow, or (rather) MCompensate. But not MSmoothFPS / MFlowFPS.I have come to the same conclusion. However, the reason I thought this would work was the following statement on the SmoothVideo Project MVTools 2 Page (http://www.svp-team.com/wiki/Plugins:_MVTools2):
MSmoothFps [is] a completely new function that encapsulates MFlow, MFlowFps and MBlockFps functionality and with GPU support enabled is almost indefinitely faster than MFlowFps.
So, wanting to get better performance, and being a reasonable person, I took this to mean that I could get this "indefinitely faster" performance when estimating forward and backwards prior to using an external denoiser, in this case RemoveDirt.

I still think there might be a way to do what I want if I first decimate every other frame, then use MSmoothFPS to double the framerate from this decimated version and, following that step, use what is now an interpolated frame. This will certainly work, but I don't know how to get the estimation to work both in the backward and forward direction. Maybe I can get the second estimated frame that I need by working on a clip that is played backwards ...

So, if I get some time later today I'm going to try this route.

[edit] Oh, upon further thinking, decimation followed by interpolation won't work at all because it's like using a delta of 2 and the estimated frame won't be very accurate, even though it will be in the correct temporal position.

[chainik_svp]

johnmeyer
Sorry I'm too late...

By "encapsulates MFlow" I meant "it can replace MFlow in 'low-end' motion interpolation scripts", like this:
===
f50=src.MFlow()
interleave(src,f50)
===

Thanks for pointing me to the other use cases of MFlow.
May be it'll be implemented in some future version cause this's rather simple to add :)

Still you can use SVAnalyse's vectors with MFlow...

=======
BTW that one-way compensation (with MFlow) can't take any real improvements from GPU acceleration cause it's just trivial.

[johnmeyer]

Thanks for the reply!

[kolak]

chainik_svp any progress in SVP development?

[chainik_svp]

chainik_svp -any news about improvements to scene change detection?

could you remind me what's wrong with scene detection? :)

[kolak]

Well- not reliable- you (or SubJunk) also said this :)
Can you borrow code from eg x264? It's just not working very well- when set to low it misses scene changes, when set to high than there are false detection in the middle of one the scene and motion is broken.

[SubJunk]

kolak: After thinking about it a lot, I think 100% accurate scene-change detection is impossible. The reason is just that in high-action scenes, two frames in the same scene can be as different as a scene change even though they aren't a scene change. So it means any program will always struggle.
However, this works out to be a good thing in my opinion because if we try to interpolate two frames in the same scene that are very different, the results will be even worse than a simple frame-blend, because there is nothing to estimate from, so every estimate will be incorrect and look funny with warps, tearing, etc.
Those are my thoughts anyway

[Nick [D]vB]

Hi all, I've only just discovered SVP, I have not had time to test anything yet but it looks very interesting.

Sorry if this has been asked before but I was just wondering if you could use DGDecNV to fully accelerate all the non-avisynth stuff?

http://neuron2.net/dgdecnv/dgdecnv.html

Would it help reduce CPU usage much, has anyone tried it?

thanks

[SubJunk]

I used to use it all the time, it does increase the speed of loading/reading the input file.

[Nick [D]vB]

But not the CPU usage so much?

[SubJunk]

Yeah it would lower the CPU usage with this

[Nick [D]vB]

Cool, that's good to know.

[TheSkiller]

Hey all,

I'm experiencing a problem of constant crashing within 1-4 minutes into processing. I'm after a frame rate conversion from 59.94 to 50. I have already narrowed down my script to something very basic, just to make sure it's not caused by something else.

I also removed all the SetMTMode() stuff, tried different SetMemoryMax() values – no luck.


I'm using AviSynth 2.6 (sET's MT), WinXP (32 bit), 3GB RAM, Core2Duo E8500 (3.16 GHz).

I should mention that I have never used SVSmoothFps before.


My basic test script which crashes VDub:

SetMemoryMax(800)
LoadPlugin("C:\svpflow1.dll")
LoadPlugin("C:\svpflow2.dll")

AVIsource("video.avi") #704x576, Ut video RGB24
ConvertToYV12()


super=SVSuper("{gpu:0}")
vectors=SVAnalyse(super, "{}")
SVSmoothFps(super, vectors, "{ rate:{num:50,den:1,abs:true}, algo:11 }",
\ url="www.svp-team.com", mt=1)

Usually I get no error message, but sometimes VDub's error message window pops up and says:
"An integer division by zero occurred in module 'svpflow2'...
...while running thread "Dub-I/O" (thread.cpp:150)."

I tried with and without GPU, different mt=x values within SVSmoothFps but still no luck.
I even emptied my complete plugins folder to make sure it's not caused by some unexplainable incompatibility with some other plugins.
I have absolutely no clue what else I could do or whats wrong. :(

[leeperry]

hi there, I'm currently in the market for an artifacts-free double frame rate interpolation script, what's the easiest way to use this package for this very purpose please? I'd be using ffdshow in realtime, feeding madVR+Reclock.

also, I understand that this package is GPU accelerated...sounds good! Could you also make it output P016 somehow in order to feed madVR with the cleanest signal?

:thanks:

[chainik_svp]

TheSkiller
Try to set scene.mode=0 in SVSmoothFps params
I know "adaptive" mode (which is by default) has a bug when converting from 50 to 60 fps, may be this's the case

what's the easiest way to use this package for this very purpose please?

Consider installing SVP and runing it :D

[TheSkiller]

chainik you're the man! Mode:0 does the trick, it's no longer crashing, thanks. :cool:

The quality of the frame rate conversion is pretty impressive as well – I can hardly tell a difference even when stepping through the 50 fps result frame by frame in VDub. I don't mind one or the other blended scene change since it's impossible to notice in normal playback speed.

[mark0077]

hi there, I'm currently in the market for an artifacts-free double frame rate interpolation script, what's the easiest way to use this package for this very purpose please? I'd be using ffdshow in realtime, feeding madVR+Reclock.

also, I understand that this package is GPU accelerated...sounds good! Could you also make it output P016 somehow in order to feed madVR with the cleanest signal?

:thanks:

After I install Windows on any machine, I get the required svp dlls from the interframe discussion page and put them in a directory (I usually put them under my player, eg mpc-be C:\Program Files (x86)\MPC-BE\SVP), and simply add one line to ffdshow avisynth page, which is basically the default interframe avsi file, with some small modifications I use specifically for my machine to choose varying quality depending on input resolution. ie

Import("C:\Program Files (x86)\MPC-BE\SVP\InterFrame_custom.avsi")

[Kaotech]

Hello,

I use LSF for sharpen, and when SVP running, my sharpen code is erased.

How to set up SVP to keep the LSF sharpen ?

[TheSkiller]

Post your script.

[Kaotech]

The script is generated automatically by SVP when running video, but this script erase my lsf sharpen.

I would like to input LSF code when svp generated the ffdshow.Avs or svp don't generate the code every time in avisynth

Avisynth :

Try {
svppath="C:\Users\PCHC\AppData\Roaming\SVP 3.1\"
import(svppath+"AVS\ffdshow.avs")
delim=":"
WriteFileStart(svppath+"Logs\SAR.txt", "ffdshow_sar_x","delim","ffdshow_sar_y")
WriteFileStart(svppath+"Logs\avsFPS.txt", "FramerateNumerator()", "delim", "FramerateDenominator()")
}
Catch(err_msg) {
ffdShow_source().Subtitle(err_msg)
WriteFileStart(svppath+"Logs\AVSError.txt", "err_msg")
}

ffdshow.avs :
svp_scheduler=true
SetMemoryMax(1024)

LoadPlugin("C:\Program Files (x86)\SVP\plugins\svpflow1.dll")
LoadPlugin("C:\Program Files (x86)\SVP\plugins\svpflow2.dll")

threads=7
SetMTMode(3,threads)
ffdShow_source()
assert(width==1920 && height==800,"Frame size "+string(width)+"x"+string(height)+" instead of 1920x800")
SetMTMode(2)
LanczosResize(1280,534)

super_params="{scale:{up:0},gpu:1,rc:true}"
analyse_params="{main:{search:{coarse:{distance:-10},bad:{sad:2000}}},refine:[{thsad:65000}]}"
smoothfps_params="{rate:{num:5,den:2},algo:23,cubic:1,mask:{cover:80},scene:{}}"

super=SVSuper(super_params)
vectors=SVAnalyse(super, analyse_params)
smooth_video=SVSmoothFps(super, vectors, smoothfps_params, mt=threads, url="www.svp-team.com")
smooth_video
distributor()

[Kaotech]

The solution :

Check "Program files\SVP 3.1\AVS\MSmoothFps.avs" wink

SVP directly copy the code to output AVS script.

[chainik_svp]

Version 1.0.6 - link (http://www.svp-team.com/files/gpl/svpflow-1.0.6.zip)
+ super clip size reduced by 4 for pel=1
('full' param in SVSuper and 'src' param in SVAnalyse)
= added workaround for OpenCL rendering on Intel's IvyBridge GPUs (*)
+ "Ambilight" can now produce "glow" effect from all sides of the frame
('light.zoom' param in SVSmoothFps)
= several small bugs fixed:
== crash with frame rate ratio < 2 (50->60, 60->50 and so on)
== arts near screen edges with CPU rendering and some frame / block sizes combination
== green lines with 21th shader and arts masking on CPU

(*) not quite sure about IvyBridge (HD2500 & HD4000 video), it may still be broken, I'll post an update in a few days in that case. Anyway it was broken so nothing changed in the worst case :)

[chainik_svp]

super clip size

We don't need original frame in super clip now for pel=1 so we can save some memory here.
Can be useful for real big frame sizes like 1080p SBS stereo pairs or especially 4K video.

Sample code is included in the archive.
source=last
super = SVSuper("{pel:1, full:false}")
vectors = SVAnalyse(super, "{}", source)
SVSmoothFps(super, vectors, "{}", url="www.svp-team.com")

[SubJunk]

Thanks!

[chainik_svp]

Improved "Ambilight"

See some images there (http://imgur.com/a/S15z4).
It's a new light.zoom value (float) in SVSmoothFps that defines how "far" we should "zoom out", in percents of original frame size.
Note that original frame content remains unchanged but resulting frame will be bigger.

[mark0077]

Thanks chainik

[chainik_svp]

IvyBridge ... I'll post an update in a few days in that case.
It seems to work now, I've uploaded an updated zip at the same location (http://www.svp-team.com/files/gpl/svpflow-1.0.6.zip).

[Overdrive80]

Hi, before of nothing, thanks for your script and merry christmas.

Actually I use MVtools2 but I am interesting in try your script but I use mvtools2_mod of ditherpack. If I could use a mix of mvtools2 with your script to increase efficiency, its my question.

My script:



super=Msuper() #SVSuper()

backward_vec3 = MAnalyse(super, isb = true, delta = 3, overlap=4,search=4) #SVAnalyse(super, isb = true, delta = 3, overlap=4,search=4)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4,search=4) #SVAnalyse(super, isb = true, delta = 2, overlap=4,search=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4,search=4) #SVAnalyse(super, isb = true, delta = 1, overlap=4,search=4)

forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4,search=4) #SVAnalyse(super, isb = false, delta = 2, overlap=4,search=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4,search=4) #SVAnalyse(super, isb = false, delta = 2, overlap=4,search=4)
forward_vec3 = MAnalyse(super, isb = false, delta = 3, overlap=4,search=4) #SVAnalyse(super, isb = false, delta = 3, overlap=4,search=4)

MDegrain3(super,backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,
\thSAD=370,plane=4,lsb=true).ditherpost(mode=2)

Could it generate any problem or run fine???

Thanks in advance.

[chainik_svp]

Overdrive80
There's a sample code inside zip - sample_convert_mv.avs

---
Something like this:
sv_super = SVSuper("{pel:2}")
sv_vectors_1 = SVAnalyse(sv_super, "{}")
sv_vectors_2 = SVAnalyse(sv_super, "{special:{delta:2}}")
sv_vectors_3 = SVAnalyse(sv_super, "{special:{delta:3}}")

#!!! Get MVTools-compatible vectors clips
backward_vec3 = SVConvert(sv_vectors_3, true)
backward_vec2 = SVConvert(sv_vectors_2, true)
backward_vec1 = SVConvert(sv_vectors_1, true)
forward_vec3 = SVConvert(sv_vectors_3, false)
forward_vec2 = SVConvert(sv_vectors_2, false)
forward_vec1 = SVConvert(sv_vectors_1, false)

#!!! Use any MVTools function. Padding should be zero.
mv_super = MSuper(pel=2, hpad=0, vpad=0)
MDegrain3(mv_super,backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3)

[Overdrive80]

Ok, thanks. I will try it.

EDIT:

Mvtools2 normal
http://s13.postimage.org/moba200ur/Mvtools.png (http://postimage.org/image/moba200ur/)

Mvtools2 svp
http://s13.postimage.org/d566ma2qb/Mvtools_svn.png (http://postimage.org/image/d566ma2qb/)

[Overdrive80]

Hi, sorry for repost.

I will observe that introducing artifacts. I had attached snapshots.

[chainik_svp]

i dunno, you can give me full scripts (both MVTools and SVPflow) and two source frames if you want :)

[Overdrive80]

i dunno, you can give me full scripts (both MVTools and SVPflow) and two source frames if you want :)

http://www.mediafire.com/?n675d3537xzifjg

[chainik_svp]

Thanks, I'll look into it.

Just for start: MAnalyse has default block size 8*8, and you set overlap to 1/2 of block. Also "wide second search for bad vectors" (badSAD) turned off.
On the other hand SVAnalyse sets block size to 16*16 and overlap to 1/4 of block with wide search on.
So comparable params should be: "{block:{w:8,overlap:3}, main:{search:{coarse:{bad:{sad:10000}}}}}"

[Overdrive80]

Thanks, I'll look into it.

Just for start: MAnalyse has default block size 8*8, and you set overlap to 1/2 of block. Also "wide second search for bad vectors" (badSAD) turned off.
On the other hand SVAnalyse sets block size to 16*16 and overlap to 1/4 of block with wide search on.
So comparable params should be: "{block:{w:8,overlap:3}, main:{search:{coarse:{bad:{sad:10000}}}}}"


Then would be like this?:

sv_super = SVSuper("{pel:2}")
sv_vectors_1 = SVAnalyse(sv_super, "{block:{w:8,overlap:3}, main:{search:{coarse:{bad:{sad:10000}}}}}")
sv_vectors_2 = SVAnalyse(sv_super, "{block:{w:8,overlap:3}, main:{search:{coarse:{bad:{sad:10000}}}}, special:{delta:2}}")
sv_vectors_3 = SVAnalyse(sv_super, "{block:{w:8,overlap:3}, main:{search:{coarse:{bad:{sad:10000}}}}, special:{delta:3}}")

#!!! Get MVTools-compatible vectors clips
backward_vec3 = SVConvert(sv_vectors_3, true)
backward_vec2 = SVConvert(sv_vectors_2, true)
backward_vec1 = SVConvert(sv_vectors_1, true)
forward_vec3 = SVConvert(sv_vectors_3, false)
forward_vec2 = SVConvert(sv_vectors_2, false)
forward_vec1 = SVConvert(sv_vectors_1, false)

#!!! Use any MVTools function. Padding should be zero.
mv_super = MSuper(pel=2, hpad=0, vpad=0)
MDegrain3(mv_super,backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3)

EDIT: I test it and the result is:

http://s7.postimage.org/nkouv2ig7/Sin_t_tulo.jpg (http://postimage.org/image/nkouv2ig7/)

Now its even more slow.

[chainik_svp]

Overdrive80
You've asked a really good question :D
First of all I've found several bugs in SVConvert that can result in crash.

Also I can't tell that motions vectors from SVPflow are worse or better than MVTools' and interpolated picture (with MFlowFps / SVSmoothFps) is better with SVPflow, BUT MDegrain gives really much artifacts. Which reminds me that absolute SAD values with SVPflow are different from MVTools, so thSAD values in MVTools functions should also be different OR I need to adjust them inside SVConvert... o_O

So we're working on your case and stay tuned :D

[Overdrive80]

Overdrive80
You've asked a really good question :D
First of all I've found several bugs in SVConvert that can result in crash.

Also I can't tell that motions vectors from SVPflow are worse or better than MVTools' and interpolated picture (with MFlowFps / SVSmoothFps) is better with SVPflow, BUT MDegrain gives really much artifacts. Which reminds me that absolute SAD values with SVPflow are different from MVTools, so thSAD values in MVTools functions should also be different OR I need to adjust them inside SVConvert... o_O

So we're working on your case and stay tuned :D

Thanks and excuse me for making troubles. ^_^'

[zambelli]

The plugin is great, but why the JSON syntax? Why not just use traditional Avisynth parameters syntax?

[Mystery Keeper]

Made this mod of dtttestMC:
# Motion-compensated dfttest by twc
# Aka: Really Really Really Slow
#
# Requirements:
# dfttest
# MVTools2
# SVP >= 1.0.5
#
# Suggested:
# Dither (for stack16 processing)
#
# Description of function parameters:
#
# pp = Clip to calculate vectors from (default input)
# mc = Number of frames in each direction to compensate (default 2, max 5)
# lsb = stack16 output and processing (default false)
#
# dfttest Y, U, V, sigma, sbsize, sosize, tbsize, and dither are supported.
# Extra dfttest parameters may be passed via dfttest_params.
# MVTools2 pel, thSCD, thSAD, blksize, overlap, dct, search, and
# searchparam are also supported.
#
# analyzeparams = SVAnalyze parameters in JSON format. Exclude "vector", "gpu" and "delta"
#
# sigma is the main control of dfttest strength.
# tbsize should not be set higher than mc * 2 + 1.

function dfttestSV(clip input, clip "pp", int "mc", bool "mdg", bool "Y", bool "U", bool "V", float "sigma", int "sbsize", int "sosize", int "tbsize", int "dither", bool "lsb", string "dfttest_params", int "thSAD", int "thSCD1", int "thSCD2", int "pel", bool "gpu", string "analyzeparams")
{
# Set default options. Most external parameters are passed valueless.
mc = default(mc, 2).min(5)
lsb = default(lsb, false)
Y = default(Y, true)
U = default(U, true)
V = default(V, true)
tbsize = default(tbsize, mc * 2 + 1)
dfttest_params = default(dfttest_params, "")
gpu = default(gpu, false)
sgpu = gpu ? "1" : "0"
spel = pel==4 ? "4" : pel==2 ? "2" : "1"
analyzeparams = default(analyzeparams, "")

# Set chroma parameters.
chroma = U || V

# Prepare supersampled clips.
pp_enabled = defined(pp)
sv_super = pp_enabled ? SVSuper(pp,"{gpu:" + sgpu + ", pel:" + spel + "}") : SVSuper(input,"{gpu:" + sgpu + ", pel:" + spel + "}")
pp_super = pp_enabled ? MSuper(pp, pel=pel, chroma=chroma) : MSuper(input, pel=pel, chroma=chroma)

# Motion vector search.
vec1 = SVAnalyse(sv_super, "{vectors:3, gpu:" + sgpu + ", special:{delta:1}" + analyzeparams + "}")
vec2 = SVAnalyse(sv_super, "{vectors:3, gpu:" + sgpu + ", special:{delta:2}" + analyzeparams + "}")
vec3 = SVAnalyse(sv_super, "{vectors:3, gpu:" + sgpu + ", special:{delta:3}" + analyzeparams + "}")
vec4 = SVAnalyse(sv_super, "{vectors:3, gpu:" + sgpu + ", special:{delta:4}" + analyzeparams + "}")
vec5 = SVAnalyse(sv_super, "{vectors:3, gpu:" + sgpu + ", special:{delta:5}" + analyzeparams + "}")

b5vec = vec5.SVConvert(isb=true)
b4vec = vec4.SVConvert(isb=true)
b3vec = vec3.SVConvert(isb=true)
b2vec = vec2.SVConvert(isb=true)
b1vec = vec1.SVConvert(isb=true)
f1vec = vec1.SVConvert(isb=false)
f2vec = vec2.SVConvert(isb=false)
f3vec = vec3.SVConvert(isb=false)
f4vec = vec4.SVConvert(isb=false)
f5vec = vec5.SVConvert(isb=false)

# Motion Compensation.
b5clip = MCompensate(input, pp_super, b5vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
b4clip = MCompensate(input, pp_super, b4vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
b3clip = MCompensate(input, pp_super, b3vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
b2clip = MCompensate(input, pp_super, b2vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
b1clip = MCompensate(input, pp_super, b1vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
f1clip = MCompensate(input, pp_super, f1vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
f2clip = MCompensate(input, pp_super, f2vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
f3clip = MCompensate(input, pp_super, f3vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
f4clip = MCompensate(input, pp_super, f4vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)
f5clip = MCompensate(input, pp_super, f5vec, thSAD=thSAD, thSCD1=thSCD1, thSCD2=thSCD2)

# Create compensated clip.
interleaved = mc >= 5 ? Interleave(b5clip, b4clip, b3clip, b2clip, b1clip, input, f1clip, f2clip, f3clip, f4clip, f5clip) :
\ mc == 4 ? Interleave(b4clip, b3clip, b2clip, b1clip, input, f1clip, f2clip, f3clip, f4clip) :
\ mc == 3 ? Interleave(b3clip, b2clip, b1clip, input, f1clip, f2clip, f3clip) :
\ mc == 2 ? Interleave(b2clip, b1clip, input, f1clip, f2clip) :
\ Interleave(b1clip, input, f1clip)

# Perform dfttest. Exception handling required for official dfttest.
try {
filtered = Eval("dfttest(interleaved, Y=Y, U=U, V=V, sigma=sigma, sbsize=sbsize, sosize=sosize, tbsize=tbsize, lsb=lsb" + dfttest_params + ")")
}
catch(err_msg)
{
filtered = Eval("dfttest(interleaved, Y=Y, U=U, V=V, sigma=sigma, sbsize=sbsize, sosize=sosize, tbsize=tbsize" + dfttest_params + ")")
}

return SelectEvery(filtered, mc * 2 + 1, mc)
}

1) Getting heavy ghosting on scene change or fast motion.
2) Result is much more blurry than with MVTools2.
3) Can not set "distance" parameter in any section. Getting Access Violation error. Tried both gpu true and false.

[chainik_svp]

Mystery Keeper

1. MSuper must be used with "hpad=0, vpad=0"!
2. The same problem: "absolute SAD values with SVPflow are different from MVTools, so thSAD values in MVTools functions should also be different OR I need to adjust them inside SVConvert"
3. I've got a fix for access violation errors in SVConvert and I'll post it in a few days.
4. It's not necessary to include "{vectors:3, gpu:" + sgpu" in each SVAnalyse call
5. Since MCompensate makes motion compensation by blocks it may be important that default block size is 8*8 w/o overlapping in MAnalyse and 16*16 with overlap in SVAnalyse.

zambelli
why the JSON syntax? Why not just use traditional Avisynth parameters syntax?

why not? :D
just try to write params for several (variable number from 0 to 3) MRecalculate calls in "traditional syntax"

[Mystery Keeper]

MSuper must be used with "hpad=0, vpad=0"!
Thank you. That heavy ghosting is gone. But some minor ghosting is still there. And result is still very blurry.
It's not necessary to include "{vectors:3, gpu:" + sgpu" in each SVAnalyse call
Put them there so user wouldn't accidentally override them.

[Mystery Keeper]

The root of my problems happened to be me neglecting MCompensate parameters. With fine tuning I got rid of ghosts and blurring at least in some sources. So thank you very much for a great plugin!

[chainik_svp]

Version 1.0.7 (01/23/13)
+ improved scene change detection
= fixed crash after SVConvert, adjusted SAD values in MVTools' vectors field

link (http://www.svp-team.com/files/gpl/svpflow-1.0.7.zip)

[kolak]

How much is it improved (other words- what has been changed in algorithm)?

2nd question- is it possible to do simple linear (blended) conversion with scene change detection with svpflow?

[chainik_svp]

kolak
what has been changed in algorithm?

unordinary long motion vectors will trigger scene change even if SAD values are too low to do that
technically it's a penalty added to output MV's SAD values based on vector length

is it possible to do simple linear (blended) conversion with scene change detection with svpflow?

you mean like "blend=true" in MSmoothFps? yes, it's a scene.blend param

[kolak]

Will this improvement help in case where 2 frames are eg. some dark background with person in the middle who moves a bit?
There is luma parameter- is it taken for scene change detection calculations?

I'm talking about blended frame interpolation- not about blending frames on scene changes.

[chainik_svp]

Will this improvement help in case where 2 frames are eg. some dark background with person in the middle who moves a bit?
You tell me ;)

There is luma parameter- is it taken for scene change detection calculations?

scene change will be detected if number of blocks with "adjusted SAD" > "limits.scene" will be more than "limits.blocks" percents of all blocks, that has "adjusted SAD" value > "limits.zero", where "adjusted SAD" is "block SAD"/"block average luma" (*)

(*)
"adjusted SAD" is "block SAD"/("block average luma" power of scene.luma value)

[chainik_svp]

Version 1.0.8
= fixed regression from 1.0.5 (low rendering precision in GPU mode)
= improved lighting quality (reduced color banding)

link (http://www.svp-team.com/files/gpl/svpflow-1.0.8.zip)

[SubJunk]

Thanks chainik!

[kolak]

@chainik
Any plans to support YUY2- I know you said it's pointless, but there is use for it in some situations.

[chainik_svp]

Any plans to support YUY2

I don't think so

[TheSkiller]

What about planar color spaces other than YV12 like YV24 – that would come it very handy for frame rate conversions that need to be put through a NLE (in RGB) after. :)
I may be wrong but from my point of view the only difference between YV12 and YV24 is the size of the chroma planes, while the difference between YV12 and YUY2 is also YUY2 not being a planar color space (and therefore much harder to implement now).

[kolak]

Well- I'm not actually after YUY2, but more for 422 sampling precision (instead of 420).

[Stormborec]

Source video 25 FPS ...

I've used this combination of filters:

QTGMC(InputType=1,TR0=0,Rep0=0,SrchClipPP=2)

InterFrame(NewNum=60,NewDen=1,cores=2)

QTGMC(InputType=1,TR0=0,Rep0=0,SrchClipPP=2,tr2=0)

edgecleaner(16)

LSFMod(defaults="slow")

GradFun2DBmod()

and the result is near perfect ...

[kolak]

How does it help?

[Stormborec]

It repairs the doubled edges, which often creates interframe.

Try and you'll see ...

[kolak]

Has to be slow as hell :)

[Terka]

chainik_svp, could you please implement cross-corelation to SVPtools?
http://forum.doom9.org/showthread.php?p=1620594#post1620594

[Mystery Keeper]

Asked him that already. He didn't want to bother >_> Said he didn't think cross-corelaton (a.k.a. phase correlation) would be any better than SAD.

[chainik_svp]

SVPflow 1.0.9

+ SVSmoothFps switches to 13th SVP shader if scene quality is below scene.m1 value
= GPU rendering was very slow for some "prime" frame sizes (like 1916x1076) on some (AMD's only?) video cards
- removed workaround for a bug in early IvyBridge's drivers, so it's working now with full precision BUT you'll need recent Intel's drivers!

direct link (http://www.svp-team.com/files/gpl/svpflow-1.0.9.zip)

[Sparktank]

Thank you for the work on SVP!
Wonderful! I've actually gotten around to really trying this out.

Works beautifully on my Intel HD3000 via HDMI.
Granted for full blu-ray remuxes, I have to drop the resolution down to 1280 or less.
But generally produces excellent results since the largest screen I have is a 34" HDTV (old TV from 2005 so not LCD! 1080i!!!)
Still playing a lot with the different settings for my own preference taste. I'm so used to converting with InterFrame that all these new options are somewhat baffling.

On my Dell LCD monitor, it's so much better when I match the refresh rate (75.353Hz).

I've yet to test it out on my desktop, but since it's a single core with really old hardware, I think I'll save the desktop the stress, lol.

Looking forward to future progress. :)

[Morte66]

Hi chainik_svp,

I just tried your motion analysis plugin today in a MDegrain3 script, and I like it. It seems about 30% faster then MVTools2 for slightly nicer results, on the settings I chose. Thanks.

I have a question about h/v padding on super clips... I've read various warnings about setting it to 0 on clips made with MSuper. Does that apply only to clips that are going to be used for motion analysis, or would it apply also to super clips used just for degraining but with vectors produced by SVP?

Here's an example of how I've done it:

function SVPKiller(clip source, int "r", int "thSAD", int "blkSize", bool "doRepair")
{

blkSize = default(blkSize,8)
searchParams = "block:{w:" + String(blksize) + ",overlap:3}"
doRepair = default(DoRepair, false)
thSAD = default(thSAD,400)
r = default(r,3)

source = source.assumeframebased()

calm = source.ReduceFlicker(strength=3,aggressive=true)
calm = calm.Repair(source,mode=1)
calm = calm.RemoveGrain(mode=17)
calm = calm.RemoveGrain(mode=17)
calm = calm.RemoveGrain(mode=17)

calmSuper = SVSuper(calm,"{}")

v1=calmSuper.SVAnalyse("{"+SearchParams+"}")
v2=calmSuper.SVAnalyse("{"+SearchParams+",special:{delta:2}}")
v3=calmSuper.SVAnalyse("{"+SearchParams+",special:{delta:3}}")

bv3=v3.SVConvert(isb=true)
bv2=v2.SVConvert(isb=true)
bv1=v1.SVConvert(isb=true)
fv1=v1.SVConvert(isb=false)
fv2=v2.SVConvert(isb=false)
fv3=v3.SVConvert(isb=false)

sourceSuper = source.MSuper(pel=2, hpad=blksize, vpad=blksize, levels=1)

r == 3 ? MDegrain3(source, sourceSuper, bv1, fv1, bv2, fv2, bv3, fv3, thSAD=thSAD) : \
r == 2 ? MDegrain2(source, sourceSuper, bv1, fv1, bv2, fv2, thSAD=thSAD) : \
MDegrain1(source, sourceSuper, bv1, fv1, thSAD=thSAD)

doRepair == true ? repair(source,mode=17): last
}

The bit that's bothering me is the clip assigned to sourceSuper near the end.

[chainik_svp]

Morte66

All of MVtools's functions really need padding - just in case motion vector points outside the frame. MAnalyse needs padding to have a chance to get semi-correct edge vectors and all of "client" functions will just crash W/o padding in super clip.

On the other hand SVAnalyse produces correct "outside" vector on the edges and it doesn't need padding at all. Also as far as SVSmoothFps preferred working mode is GPU-assisted it doesn't need padding too.

In both SVSmoothFps (CPU mode) and SVConvert vectors that point outside are just clipped.

[Boulder]

Copy-pasted from here: http://forum.doom9.org/showthread.php?t=167844

There's something funny about SetMemoryMax in your Avisynth build. Using the special features settings, I have a custom function (nothing fancy, just stuff put together in one function) which causes a huge memory consumption if SetMemoryMax is 384 and I start encoding the script or playback it in VDub. The same doesn't happen with SEt's build. If I set SetMemoryMax to 1024, the consumption is as high as with SEt's build but it doesn't increase much during processing.

In addition to this, I've also experienced quite a few livelocks. The processing seems to get stuck, CPU usage suggests that only one thread is being used but nothing progresses. This usually occurs quite early in the encoding.

[chainik_svp]

Well, I can't say anything about complex scripts with tens of filters in the chain.
The goal for this Avisynth build was to allow setting really big count of threads (like 20 or 30) for simple MSuper/MAnalyse/MFlowFps chain which is just impossible with standart build. And it's getting worse with pel>1.

Avisynth works like this: when you build a chain
<filter_1> - <filter_2> - <filter_3>
it actually builds
<filter_1> - <CACHE_1> - <filter_2> - <CACHE_2> - <filter_3> - <CACHE_3>

The problem is each "cache_X" try to hold up to 200 frames no matter what - from N-100 to N+100 (where N is current frame).
So all I did is explicitly limit every cache to something like [N-2;N+<user_defined_value>].

> In addition to this, I've also experienced quite a few livelocks.

In addition to cache limiting my build has it's own "distributor" algorithm cause we've found SEt's one isn't effective in some cases (e.g. frame doubling). By "is not effective" I mean "the same result in frames per second can be achieved with less number of processing threads".

May be this algorithm still can lead to deadlock in some cases o_O if you're really interested we could try to debug your case ;)

[Boulder]

Of course I'm interested in helping out :) I'll PM you the function and script that I use so you can check if there's something there that could cause the memory issues.

[TheSkiller]

I'm trying to use a denoised clip for motion estimation and then apply frame rate conversion (59.94 -> 50) using SVSmoothFps to my noisy source clip, but somehow it does not work as expected.

SVSmoothFps returns the denoised clip most of the time except at scene changes. Here is my script. What am I doing wrong?



no_denoise=last.subtitle("no_denoise")

FFT3DFilter(sigma=4.5)

super=SVSuper("{gpu:0}")
vectors=SVAnalyse(super, "{ }")
SVSmoothFps(no_denoise, super, vectors,
\ "{ rate: {num:50,den:1,abs:true}, algo:13, mask:{cover:100,area:60} }",
\ url="www.svp-team.com", mt=2)

[Boulder]

You apply FFT3DFilter to "last" which is the clip that SVSmoothFPS is also applied on.

[TheSkiller]

HolyWu, thanks a lot, that does the trick! :) :goodpost:

[chainik_svp]

SVPflow 1.0.10

+ GPU rendering in linear light by default (see "linear" param in SVSmoothFps)
= SAD functions updated to the latest x264 code
= minor changes in black borders filling (it can fill very thin - 2px - borders now)

direct link (http://www.svp-team.com/files/gpl/svpflow-1.0.10.zip)

[chainik_svp]

Some comparisons about "linear light":
1st (http://screenshotcomparison.com/comparison/42204)
2nd (http://screenshotcomparison.com/comparison/42206)

The biggest difference is on thin light objects on dark background. The perfect video to test on (http://www.avsforum.com/t/1157287/hd-1080i-test-pattern-to-determine-vector-adaptive-deinterlacing-others-icl-ticker) - linear light produces much less flickering.

http://www.svp-team.com/images/linear/Slices_nolinear1_ani.gif vs. http://www.svp-team.com/images/linear/Slices_linear1_ani.gif

http://www.svp-team.com/images/linear/Slices_nolinear2_ani.gif vs. http://www.svp-team.com/images/linear/Slices_linear2_ani.gif

[Reel.Deel]

SVPflow 1.0.10

+ GPU rendering in linear light by default (see "linear" param in SVSmoothFps)
= SAD functions updated to the latest x264 code
= minor changes in black borders filling (it can fill very thin - 2px - borders now)

direct link (http://www.svp-team.com/files/gpl/svpflow-1.0.10.zip)

Thank you chainik, long time no see :).

[johnmeyer]

Some comparisons about "linear light": ... Those pathological test cases look absolutely amazing. If that translates to real video cases, the improvements will be quite substantial. Thank you!

[chainik_svp]

SVPflow 1.0.11

= Fixed crash in CPU rendering mode with pel>1 and blend=true
= Fixed rounding error in GPU rendering mode (leads to flickering (+-1 luma) visible on dark scenes)


Additional thanks to SubJunk for not pointing me to the 1st one.

[SubJunk]

My computer has been broken so I couldn't do good testing until it was fixed. Glad you fixed it!

[mark0077]

cheers for the update!

[franketto]

I have crash in VD on the KernelBase.dll just after loading the avs script, trying settings with higher value on threads .

i.e I have a script:


SetMemoryMax(1024)
global svp_scheduler=true
threads=10
global svp_cache_fwd = threads + 2
SetMTMode(3,threads)

source = AVIsource(".......avi")

setmtmode(2)

#some filters....



If I set threads = 8 all is ok, but with >= 10 it crashes. (I have an i7 920 4core 6GB ram, W7 pro 64bit)
With other (less) filters I can raise a bit until it crashes again.

I tried to change all other settings (setmemorymax), but nothing changes.

So, is this the only method to detect how many threads can we use? Raise the threads value until it crashes on load in VD? Or are there some other tricks to raise that value?

For the rest, thank you chainik_svp, with SVConvert I get a 40% increase in speed.

EDIT:
Even if it loads in VD, I had to lower threads to 7 to make it render to x264, otherwise it crashes... but this way I get CPU @ 45%: this vanishes the speed gain vs plain avisynth 2.6 MT...!

[StainlessS]

Just thought I'de point something out, it is not a problem for me.

With
svpflow1.dll v1.3.5.0, svpflow2.dll v1.5.8.0 and svpflow_cpu.dll v1.7.2.0, supplied with Interframe v2,
in my plugins directory, and running VS 6.0, selecting to debug one of my plugs, VS debugger runs selected app
VirtualDubMod, but pops up an error message "First Chance Exception in VirtualDubMod.exe, (NTDLL.dll); 0xC0000008: Invalid Handle".
Problem disappears on removing these three plugs from plugins folder (still occurs if only svpflow1.dll in plugs dir).

Might be an indication of a problem in the plugins. (Interframe does not seem to be affected).

EDIT: I tried also copying svpflow_gpu.dll v1.8.4.0 to plugins, where I get this message,

"The application has failed to start because OpenCL.dll was not found. Re-installing the application may fix the problem."

and then on OK'ing the alert box I get the original error message. Might assist in knowing that the original error occurs
after the gpu dll tries to access OpenCL dll. (I dont use the gpu dll).

[Groucho2004]

Just thought I'de point something out, it is not a problem for me.

With
svpflow1.dll v1.3.5.0, svpflow2.dll v1.5.8.0 and svpflow_cpu.dll v1.7.2.0, supplied with Interframe v2,
in my plugins directory, and running VS 6.0, selecting to debug one of my plugs, VS debugger runs selected app
VirtualDubMod, but pops up an error message "First Chance Exception in VirtualDubMod.exe, (NTDLL.dll); 0xC0000008: Invalid Handle".
Problem disappears on removing these three plugs from plugins folder (still occurs if only svpflow1.dll in plugs dir).

Might be an indication of a problem in the plugins. (Interframe does not seem to be affected).
What version of Avisynth? I get these "First chance" exceptions all the time when I debug something that loads the AVS+ avisynth.dll. These exceptions can apparently usually be ignored and you can disable them in the debugger.

[StainlessS]

I'm currently using Official v2.6. (think I'll switch again to using your ICL build).
the debug messages are of little concern, just thought the devs might be interested to know.
thanks Groucho.

[chainik_svp]

SVPflow 1.1.12

= up to 20% faster (0)
+ "64-bit ready" (1) - assembler code (still not all of them) ported/rewritten in intrinsics, target compiler is VC++2013
+ new option in SVAnalyse - search.main.coarse.width (2) - to get more than one "finest" levels
+ SATD for 32-x blocks (3)
= reduced memory usage for large number of small blocks (4)
= refactoring - removed svpflow_cpu/gpu modules - merged with svpflow2

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.12.zip)

Comments:

(0) For example: default settings (16x blocks, 1/4 overlap, pel 2), 1080p, 5:2 FRC, single thread: 27 fps vs. 22.7 fps.
But 32-x block will be much slower with default settings - see (3)

(2) Coarse levels differ from finest level in some processing options, like search type/distance, usage of SATD, "trymany" and sorted blocks order. This option allows to divide levels into "finest" and "coarse" by their width - levels with width less than "coarse.width" will be processed with "coarse" options. Default value is 1050.

(3) 32-x block was always processed with SAD function regardless of options used

(4) You possibly won't ever see this with regular Avisynth 2.6 :D But it's something like 1.8 GB vs. 1.4 GB memory usage for 1080p @4x blocks, or 4K @8x blocks

(1) In fact I have 64-bit build working with 64-bit AVS+ MT. Still AVS+ (and especially MT) is far for being stable enough for SVP :(

[kolak]

Any thoughts about adding phase correlation?

[chainik_svp]

I'll be happy enough if/when it'll work in x64 with built-in MT.
Sadly it's too much work on a paid job...

[kolak]

I assume same answer for 16bit pipe:)

[chainik_svp]

gpu rendering pipe is floating point already
MVs search part is quite good with 8 bit integers
What exactly are you asking for? :)

[SubJunk]

Thanks a lot for the update!

[kolak]

gpu rendering pipe is floating point already
MVs search part is quite good with 8 bit integers
What exactly are you asking for? :)

16bit pipe, so I can preserve 10bit.

[feisty2]

16bit pipe, so I can preserve 10bit.

vaporsynth mvtools can grant your wish

[Reel.Deel]

vaporsynth mvtools can grant your wish
Yeah but in terms of motion interpolation quality, SVPFlow is definitely much better.

gpu rendering pipe is floating point already
MVs search part is quite good with 8 bit integers

I second kolak request, would be nice for SVP to support 16-bit input/output. Regarding SVAnalyse only supporting 8-bit, we can always dither to 8-bit and perform the actual interpolation on the 16-bit clip.

[chainik_svp]

Correct me if I'm wrong but to be able to use 16-bit video formats plugin should be compiled with 2.6 avisynth.h. So I'll be forced to release rendering plugin under GPL. Right?

Another question - why the hell all of you people need 10 bits? :) I really don't understand. 10 bit is an encoder option/feature to compress 8-bit sources better. And somewhere after decoder you always need to dither it down to 8 bits. So why just don't do it right after the decoder?

[Reel.Deel]

Correct me if I'm wrong but to be able to use 16-bit video formats plugin should be compiled with 2.6 avisynth.h. So I'll be forced to release rendering plugin under GPL. Right?

No, a regular 2.5 plugin would suffice. Take a look at Dither, (http://forum.doom9.org/showpost.php?p=1386559&postcount=3)it's a 2.5 plugin. 16-bit processing in AviSynth just uses the Stack16 (http://forum.doom9.org/showpost.php?p=1631712&postcount=7) format which splits the MSB/LSB. MSB at the top, LSB at the bottom, thus the stack 16 format is always double in height.

[feisty2]

Another question - why the hell all of you people need 10 bits? :) ?
I don't want 10 bits, I want float point, you might input an 8 bits clip and output 8 bits for the result clip, but you need every step in between to be at the highest possible precision to avoid rounding error add-ups, it doesn't matter if all you need is one simple filter, but it does matter if you got a process filter chain
like, if every filter only takes integer input and outputs integer result
input : 120
process : 120 / 7 = 17.14285714285714.., round to 17
process : 17*7 = 119

or you result integer, but everything in between is at float point
input : 120
process : 120 / 7 = 17.14285714285714..
process : 17.14285714285714.. * 7 = 120

that's why it matters

[kolak]

Because even if final delivery is 8bit you should always keep your main master at 10bit (specially when you had nice 10bit source material).
You may want to do legalisation, dithering etc, so 10bit master is a very useful. It's rather for pro market, but 10bit is quite often a must there.

[SEt]

Correct me if I'm wrong but to be able to use 16-bit video formats plugin should be compiled with 2.6 avisynth.h. So I'll be forced to release rendering plugin under GPL. Right?
There is no 'official' support for >8 bit even in Avisynth 2.6. Also, you can make 2.5 plugin with support of 2.6 colorspaces – I don't think that interfaces are subject to license restrictions.

And somewhere after decoder you always need to dither it down to 8 bits. So why just don't do it right after the decoder?You are definitely wrong. I have 10+ bit pipeline from decoder to monitor and don't need to go back to 8 bits anywhere.

[chainik_svp]

I have 10+ bit pipeline from decoder to monitor

You - may be.
But most people take 8-bit anime encoded in 10-bit, send it as 8-bit to monitor that shows it on 6-bit LCD panel :D And they all really think they watching 10-bit video...

[Sparktank]

:D And they all really think they watching 10-bit video...

Pretty sure in this century they know by now they're not watching 10bit.
To them, they're just watching less banded material than the sources.

[mark0077]

Thanks for the update!

I guess 20% improvement isn't in work sent to the cpu? I am using GTX 980 with core i7 920 @ 3.6ghz. I'm always able to play 1080p -> 59.94fps conversion with 16 block size and overlap 2 without frame drops, ~45% cpu load max, but switching to 8 block size as is default for Medium preset in Interframe, the cpu usage seems to always be my bottle neck. It hits 100% and I get frame drops. I guess theres nothing I can do about it as my cpu is limiting factor now and not the gpu?

gpu load is only 17% according to gpu-z in this scenario, cpu 100% when I go to 8 block size :D Is there any possibility of future updates to move more of this work to the gpu do you think or is not feasible?

[SubJunk]

Yeah it would be really cool to see the GPU do more :)

[chainik_svp]

I guess 20% improvement isn't in work sent to the cpu?

Well, it is.
Like I said before - at default settings (16x blocks, 1/4 overlap, pel 2), 1080p, 5:2 FRC, single thread: 27 fps vs. 22.7 fps

[mark0077]

ah ok, I guess my cpu isn't good enough then :D Is the work thats being done on cpu currently, even possible to do on the gpu efficiently? My lovely GTX 980's fans arn't even spinning but my poor cpu is maxed out :D

[chainik_svp]

SVPflow 1.1.13

= fixed broken SVConvert function

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.13.zip)

[TCmullet]

SVPflow 1.1.13

= fixed broken SVConvert function

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.13.zip)
Good news. Thank you!

But as I seek to copy the two dlls over, I see the date for svpflow1.dll is a day earlier (1/27/2015) than the last known version (1/28/2015). Are you sure something's not mixed up?? (I always expect equal or later dates, not earlier ones.)

[chainik_svp]

TCmullet
Are you sure something's not mixed up??

I believe you'll tell me :D

[TCmullet]

TCmullet
Are you sure something's not mixed up??

I believe you'll tell me :D
I just did. :) I trust you'll have an explanation for why the later one has an earlier date (a boo-boo IMHO) and maybe a fix.

[chainik_svp]

I have no idea. My screen's showing me right now the contents of zip file downloaded from the link above:
"svpflow1.dll 356864 2015-03-06 14:25"
which is the exact binary from there (http://www.svp-team.com/forum/viewtopic.php?pid=47347#p47347)

[TCmullet]

Partial mistake by me. It is svpflow2.dll, not 1.dll. I got it again from where you say "direct link". That is, I downloaded again after your last reply. Date still says 1/27/2015, whereas the prior one (the one SubJunk gave out with InterFrame 2.8.0 as dependencies) was 1/28/2015.

[Sparktank]

It is svpflow2.dll.
Date still says 1/27/2015, whereas the prior one (the one SubJunk gave out with InterFrame 2.8.0 as dependencies) was 1/28/2015.

I got:

svpflow-1.1.12\svpflow2.dll
created:‎ July-‎17-‎13, ‏‎8:39:57 AM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

svpflow-1.1.13\svpflow2.dll
created: ‎July-‎17-‎13, ‏‎8:39:57 AM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

InterFrame-2.8.0\Dependencies\svpflow2.dll
‎created: March-‎04-‎15, ‏‎8:09:58 PM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

Whatever you're using to extract could be changing the dates to the day you extract them.
There should be options to keep original dates of the files inside the archive.

svpflow1.dll has the same (modification) dates between svpflow-1.1.12 & InterFrame-2.8.0: ‎January-‎27-‎15, ‏‎5:37:26 AM
Only svpflow-1.1.13 has different date for svpflow1.dll: ‎March-‎06-‎15, ‏‎3:25:21 AM

[TCmullet]

I got:

svpflow-1.1.12\svpflow2.dll
created:‎ July-‎17-‎13, ‏‎8:39:57 AM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

svpflow-1.1.13\svpflow2.dll
created: ‎July-‎17-‎13, ‏‎8:39:57 AM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

InterFrame-2.8.0\Dependencies\svpflow2.dll
‎created: March-‎04-‎15, ‏‎8:09:58 PM
modified: ‎January-‎27-‎15, ‏‎5:46:25 AM

Whatever you're using to extract could be changing the dates to the day you extract them.
There should be options to keep original dates of the files inside the archive.

svpflow1.dll has the same (modification) dates between svpflow-1.1.12 & InterFrame-2.8.0: ‎January-‎27-‎15, ‏‎5:37:26 AM
Only svpflow-1.1.13 has different date for svpflow1.dll: ‎March-‎06-‎15, ‏‎3:25:21 AM
Okay, you've gotten me suspicious. I killed the WinRAR I was using. Now only Windows Explorer (Win 7) is handling things. One question about YOUR data... How can a modification date be EARLIER than a creation date, unless one has grossly tampered with the system clock?

I've reextracted all from the InterFrame 2.8.0 zip file. W7 sadly mucks the mod dates. But creation dates are as follows:
InterFrame2.avsi 3/5/2015 4:01pm
InterFrame2.html 3/5/2015 4:08pm
Dependencies:
Builds.txt 3/4/2015 10:02pm
svpflow1.dll 1/28/2015 1:37am
svpflow2.dll 1/28/2015 1:46am

Things could be off by hours at worst due to time zones, but maybe SubJunk could confirm who's dates are correct.

And just for the fun of it, I redownloaded 2.8.0 from:
http://www.spirton.com/interframe/ and got same creation dates.

I need to revisit all this now that I am looking at creation dates vs mod dates. It appears that unzipping mods the mod date. (I'm disliking Win7 more and more.)

[TCmullet]

Furthermore, I've redownloaded from "direct link" and the creations dates are:
svpflow1.dll 3/6/2015 1:25pm
svpflow2.dll 1/27/2015 3:46pm

So.... does SubJunk need to update his dlls to be current? (But maybe unnecessary if InterFrame does not use any svp.dll changes since 1/28 or 1/27.)

And btw, I see one potential difficulty. As these 2 dlls seem to be "copied around", there is no way to associate them with any particular version of SVPFlow (1.1.13 in this case). There are no dates in the change log.

I guess the important question for me is, should I copy these dlls, obtained from "direct link" to my plugins folder for Avisynth and use them for all things I might use them for, and disregard the ones that came with InterFrame 2.8.0?

[Sparktank]

How can a modification date be EARLIER than a creation date

The extraction settings were set to retain original dates/times from whatever was archived by whomever archived the files.

Downloaded Interframe and extracted and got the same results.
Removing settings to retain original dates changed all dates to current date/time that I extracted.

But, I checked CRC values for different versions.

CRC for svpflow2.dll in svpflow-1.1.12 and InterFrame-2.8.0 are identical.
svpflow-1.1.13 doesn't match anything because it's obviously updated.

The affected dates in SubJunks Interframe archive are probably due to the date/time he extracted and/or created his archive and depending on what software and settings he used.
SubJunk can confirm what software he's using and the settings.

An alternative to WinRAR is 7zip.
It has settings to retain original dates for the archived files, whether you're extracting or archiving.

You might be able to retain original dates in Windows own extractor, but probably if you use the CMD instead of the integrated shell.
I don't know, never used OS extactor.

That's as far as I'll continue on the subject of the dates for the files.

Back on topic, I appreciate the updates to SVPflow.
I'm noticing considerable performance increase on full 1080p (non-cropped) remuxes (in regards to using SVP).

[Sparktank]

InterFrame 2.8.0?

Has not been updated to use SVPflow v1.1.13 yet.
(it will probably be released as v2.8.1)

[kaefert]

I have a question about SVP: When I have Avisynth running on a computer without a compatible GPU from this list:
http://www.svp-team.com/wiki/GPU_Compatibility

and use SVP with the "{gpu:0}" parameter set - will this only run slower, or will I also have a lower quality of the motion interpolated frames than the GPU-Version?

Background: I do not view the result live, but encode it for later viewing it on an hardware media player - therefore I can tolerate slower speeds, but I would like to know if the CPU version is "only" slower or also lower in quality then the GPU version of SVP.

[mark0077]

gpu being used does increase quality. See below quote from the SVP user Manual http://www.svp-team.com/wiki/SVP:User_manual

"Attention: GPU acceleration enhances the frame interpolation quality"

[kaefert]

gpu being used does increase quality. See below quote from the SVP user Manual http://www.svp-team.com/wiki/SVP:User_manual

"Attention: GPU acceleration enhances the frame interpolation quality"

well, this guide is focused on live playback of motion interpolated frames. this will of course be better quality with a gpu than without, since the cpu can't perform the same level of caluclations in real time that a gpu can - but when the real time requirement is lifted, is that statement still true?

[Sparktank]

is that statement still true?

Should still apply to offline.
InterFrame uses SVPflow and is intended for encoding and benefits greatly from using GPU.

[mark0077]

well, this guide is focused on live playback of motion interpolated frames. this will of course be better quality with a gpu than without, since the cpu can't perform the same level of caluclations in real time that a gpu can - but when the real time requirement is lifted, is that statement still true?

All the same, InterFrames Medium preset is pretty much as good quality as you can get at the moment (live or offline), and it works in realtime on medium / fast PCs. Saves having to convert all movies offline.

[kaefert]

@mark0077 - well, if one doesn't use a PC for playback, then realtime direct displaying is not really an option.
and also I do not use avisynth just for SVP, I use it as nonlinear video editor and motion interpolating frames is just one part of my process.

[chainik_svp]

Find a link (http://imgur.com/a/MwglB) on the 1st page.
GPU rendering is more "soft" and precise (integer vs. floating point math), also it's done in "linear light".

[kaefert]

thanks for those pics chainik_svp! are there maybe also somewhere pics of the two frames that this interpolated motion predicted frames where generated from?

[chainik_svp]

take any background and add color circles in MS paint :)

[kaefert]

so it where two frames with the same green brownish background and both had the same sized blue circle with red border (uniform border with same thickness everywhere?) on different positions on this background? how big was the overlap?

[chainik_svp]

circle positions are easily seen by halos from the cover/uncover mask

it's not an easy scene (and not a typical one) for MVs search
it just gives good explanation of different frame rendering modes

[kaefert]

hmm, yes okey. but one question - is there an additional red circle on the left/top of the blue one or is this only an artefact of the blue circles' red border moving?

[lansing]

chainik_svp you should update the svp installer package as well. I was using version 3.1.6 and it still uses the old svpflow plugin.
I was having issue with stuttering video playback on progressive video for a long time until I just found out that there's a update to the plugin today, and it fixes the issue.

[chainik_svp]

SVPflow 1.1.14

= up to 15% faster
= 2nd attempt to fix broken SVConvert function NOT fixed in 1.1.13

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.14.zip)

up to 15% performance improvement got mainly from the usage of Intel's compiler instead of VC++2013 (in versions 1.1.x) and VC++2003 (in versions 1.0.x)

[Sparktank]

This is wonderful news! I'm already enjoying the previous update so much.
Thanks for the update.

[mark0077]

Thanks Chainik!

[SubJunk]

Cool, thanks!

[billqs]

I'm attempting to use SVP along with madVR to scale and play 1080P & 720P videos at 2160p. I have a R9280x Radeon which unfortunately limits playback at 2160p to 30fps. Is there anyway I could get SVP to work in this situation? My Home Theater rig:
MSI Z79 Socket 2011 motherboard, i7 3820 3.6 CPU 16GB Ram. Result runs through a Denon X7200 Receiver and to my Sony 500ES 4k Projector. Any help would be appreciated.

[kolak]

Send HD 60p signal and let projector to do scaling.

[billqs]

Send HD 60p signal and let projector to do scaling.

Thanks. I do this quite a lot. I was told, however, that madVR can produce video equal in quality to lumagen video processors. The Sony projector does a great job for scaling except it introduces ringing for fake sharpness.

I am still experimenting with madVR settings, but even with settings not completely high, I'm getting a wonderful, sharp image without ringing.
All I'm missing is what I do enjoy about the Sony which is MotionFlow, which is why I want to use SVP. I'm under the assumption that SVP won't work with 30fps output which my AMD card is limited too. Is this correct?

[marcellus]

Hello SVP-Team,

Many thanks for your nice plugin!

I have some questions regarding SVPflow but let me explain first what I'm using it for. I have a chinese "GoPro-like" sport camera (in fact is this very one, bought under another brand name from Auchan: IronXCam DXG 5G9V HD (http://www.ironxcam.com/products_detail?sn=34&type=1) ) and want to stabilize what I shot from my chest mount. I record in 1280x960@29.970 FPS (camera is able to shot 1280x720@59.94 but it's not the widest angle available). I use SVP for motion analysis, then I convert the analysis in MVTools2 format, then I use MDepan and DepanStabilize to deshake it. To get rid of black borders I apply though DepanStabilize to another clip, obtained overlaying (with a blured mask) the original clip over a blured MSuper clip pel=1 resized to 1920x1080 (yes, creative use of hpad and vpad edge pixels repeating :) ). This way I shot two birds: get rid of distracting black border (I don't like the way Deshaker does it) and obtain a full HD clip. And while I am at it I finally use SVPflow to double the frame rate. All is then encoded with x264. I use AviSynth+ r1779 MT.

This is the script:

SetMemoryMax(1024)
global threads=2
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3)
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\DePan.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\svpflow1.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\svpflow2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll")
LoadCPlugin("C:\Program Files (x86)\AviSynth+\plugins\ffms2.dll")
source=FFVideoSource("C:\!Backup SD\CBLM 2015-04-25\FILE0006.mp4") #source is H,264 1280x960 30000/1001 FPS
source_blur=source.BicubicResize(32,24,1,0).BicubicResize(128,96,1,0) #blured + reduced source
super_blur=source_blur.MSuper(hpad=32,vpad=6,pel=1,levels=1,mt=true).BicubicResize(1920,1080,1,0) # MSuper of blured source with specific padding (for edge pixels repeating), blured further more and resized to 1920x1080
blur_mask=source.BlankClip(width=126,height=94,color=$FFFFFF).AddBorders(2, 2, 2, 2, color=$000000).ColorYUV(levels="TV->PC").BicubicResize(1300,980,1,0).Crop(10,10,1280,960,align=true).FreezeFrame(0,-1,0) # Soft blured mask for overlaying source over blured MSuper
combined=super_blur.Overlay(source,320,60,mask=blur_mask)
super_svp=source.SVSuper("{gpu:1}")
vectors_svp=super_svp.SVAnalyse("{}")
convert_svp=vectors_svp.SVConvert()
depan_data=source.MDepan(convert_svp,error=999,thSCD2=255,zoom=false,rot=false) # I have no scenes or zoom, and rotation is kind of incontrolable and annoying
stabilized=combined.DePanStabilize(depan_data,mirror=15,dxmax=320,dymax=60,zoommax=1,rotmax=0,cutoff=0.20,damping=1.00)
super_svp_60=stabilized.SVSuper("{gpu:1}")
vectors_svp_60=super_svp_60.SVAnalyse("{refine:[{}]}")
final=stabilized.SVSmoothFps(super_svp_60, vectors_svp_60, "{algo:1,cubic:1}", url="www.svp-team.com", mt=threads)
return final.Prefetch(threads)


"Before" clip frame:
http://i60.tinypic.com/jzwhlz.jpg

"After" clip frame:
http://i62.tinypic.com/2wc36ky.jpg

I like very much the result, there are little artifacts if you watch it frame by frame with a magnifying glass but nobody should judge this way.

But there is one problem: speed. Encoding runs at about 2.5 - 3.5 FPS (which is excruciating given the fact that I get double number of frames comparing to the original). What can I do to speed it up?

The main bottleneck is DepanStabilize, actually I managed to optimize the script for it with about 1-1.5 FPS because initially I was first doubled the frame rate and then stabilize it (getting ~1.5 FPS this way :( ). No wonder because Depan had to work on double number of frames. Aparently Depan is much slower at moving the picture to it's right place than it is SVPFlow at motion analyse + motion interpolated frame generation.

So my questions are:

1. SVPflow use any GPU for motion analysis? Because when I only do the SVAnalyse->SVConvert->MDepan->DePanStabilize step the GPU load is 0 (checking with GPU-Z) even though i have set {gpu:1}. Only when I throw in the frame doubling step GPU load shows some activity (5-6%).

2. Do the quality settings in NVidia driver Control Panel affect the speed/quality of the result? I tried some variations but I couldn't figure out for myself what is the reality for sure.

http://i57.tinypic.com/15hg5g8.png

http://i60.tinypic.com/2w33iuu.png

2. Because my clips have no scenes I want to disable completely scene detection and if possibly improve this way the motion detection / frame doubling speed or quality. What settings should I use?

3. Is there any way to use SVPflow or MVtools functions to replace DepanStabilize? Or could that functionality be implemented in SVPFlow / MVTools2 (yeah, I know, wishful thinking :) )

4. Rolling shutter problem, any way to deal with it? Some SVPFlow / MVTools tricks? It's kind of tolerable with my clips, as they are wide angle, but it would be nice to do something about it.

Many thanks again and best regards!

[chainik_svp]

marcellus

1. Nope. GPU is only active in SVFlowFps.
2. They shouldn't unless you're using some hardware decoder. All the video driver settings are for DXVA decoding only.
2. (again :D) Scene changes detection doesn't affect performance at all.

3,4. I have no idea :D
Try to figure out what is a real bottleneck in your script. What's the performance difference with removed DePanStabilize - "stabilized=combined"?

First option I'd play with is "subpixel - pixel interpolation accuracy (default = 2)". Setting this one to zero should help a lot.

[chainik_svp]

SVPflow 1.1.15

= fixed performance issues with the default main.search.coarse.width value (introduced in 1.1.12)

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.15.zip)

[mark0077]

Thanks Chainik

[chainik_svp]

64-bit build added under the same 1.1.15 version.

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.15a.zip)

This build is mainly for testing purposes.

It is (should be) fully functional, but it lacks some assembler code for up-/down-scaling in the super clip compared to the 32-bit version.
So the performance of SVSuper() may be hurt, especially with pel>=2 and upscaling method different from bilinear.
Luckily there's no point in measuring performance of standalone SVSuper() and usually it isn't a bottleneck in real processing chains.

Still this build seems to be faster (in some cases) than 32-bit one by up to 10-15%.
May be it's faster due to some bug ;)

[Reel.Deel]

64-bit build added under the same 1.1.15 version.

direct link (http://www.svp-team.com/files/gpl/svpflow-1.1.15a.zip)

This build is mainly for testing purposes.

It is (should be) fully functional, but it lacks some assembler code for up-/down-scaling in the super clip compared to the 32-bit version.
So the performance of SVSuper() may be hurt, especially with pel>=2 and upscaling method different from bilinear.
Luckily there's no point in measuring performance of standalone SVSuper() and usually it isn't a bottleneck in real processing chains.

Still this build seems to be faster (in some cases) than 32-bit one by up to 10-15%.
May be it's faster due to some bug ;)

Awesome, thank you very much for the x64 build. Will definitely test it out. One little feature request, any interest in adding a chroma (true/false) parameter? This would be useful on black and white clips.

[chainik_svp]

Reel.Deel
any interest in adding a chroma (true/false) parameter? This would be useful on black and white clips.

usefulness of what kind do you expect? performance / quality / both / smth else?

[Reel.Deel]

usefulness of what kind do you expect? performance / quality / both / smth else?

I would hope performance (MVTools has a chroma parameter and it's indeed faster when set to false). Also some people have said that chroma=false on greyscale clips does improve quality a bit, I have not tested this so I cannot confirm.

[Morte66]

Hi, I've been trying SvpAnalyse vectors with Medgrain. I get brief "blank clumps" in the output, usually around moving legs and near scene changes. These are not present with MAnalyse.

I'm using AviSynth 2.6.0 release and SVPFlow1.dll v2.0.3.0. I have had similar problems with earlier SVP releases.

I made a sample: https://dl.dropboxusercontent.com/u/80519209/AmeliaTest.zip

AmeliaTest.mkv is the input cut from my BluRay, the MVTools/SVP scripts and output files AmeliaTest.mvd.mkv/AmeliaTest.svp.mkv are included. You'll see the problem around the woman's legs as the clip opens and again at about the five second mark.

Here's the SVP script I'm using:
SetMemoryMax(1000)
SetMtMode(3,5)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("E:\zzzVideo\SVP Test\AmeliaTest.mkv")
SetMtMode(2)

AssumeFrameBased()

ColorYUV(levels="TV->PC")

#MDegrain(3)
SvpDegrain3()

return last


function SvpDegrain3(clip source) {
super = SVSuper(source,"{}")

v1=super.SVAnalyse("{block:{w:16,overlap:3}}")
v2=super.SVAnalyse("{block:{w:16,overlap:3},special:{delta:2}}")
v3=super.SVAnalyse("{block:{w:16,overlap:3},special:{delta:3}}")

bv3=v3.SVConvert(isb=true)
bv2=v2.SVConvert(isb=true)
bv1=v1.SVConvert(isb=true)
fv1=v1.SVConvert(isb=false)
fv2=v2.SVConvert(isb=false)
fv3=v3.SVConvert(isb=false)

sourceSuper = source.MSuper(pel=2, hpad=0, vpad=0, sharp=2)
MDegrain3(source, sourceSuper, bv1, fv1, bv2, fv2, bv3, fv3, thSAD=300)
}


function MDegrain3(clip source)
{
super = source.MSuper(pel=2, hpad=16, vpad=16, sharp=2)
backward_vec3 = MAnalyse(super, blksize=16, isb = true, delta = 3, overlap=8)
backward_vec2 = MAnalyse(super, blksize=16, isb = true, delta = 2, overlap=8)
backward_vec1 = MAnalyse(super, blksize=16, isb = true, delta = 1, overlap=8)
forward_vec1 = MAnalyse(super, blksize=16, isb = false, delta = 1, overlap=8)
forward_vec2 = MAnalyse(super, blksize=16, isb = false, delta = 2, overlap=8)
forward_vec3 = MAnalyse(super, blksize=16, isb = false, delta = 3, overlap=8)

MDegrain3(source, super, backward_vec1, forward_vec1, backward_vec2, forward_vec2, backward_vec3, forward_vec3, thSAD=300)
}

I wonder...
- Am I doing something wrong in my script to convert the vectors?
- If not, is there anything I should do with SVP parameters to tackle this issue?
- Does this happen to anybody else?

[chainik_svp]

Hmm...
First one is at the frame edge and 2nd one is right before scene change.
And both scene changes detection algorithm and handling of edges was significantly changed in SVPflow.
An investigation is required :)

[chainik_svp]

OK, the main reason is different SAD absolute values in MVs.
The next question is "why they're so different" but the quick solution is to adjust threshold values is MVTools (thSAD, thSCD1/2)
For instance, thSCD1=300 (instead of default value = 400) solves issues on scene changes.

[Morte66]

OK, the main reason is different SAD absolute values in MVs.
The next question is "why they're so different" but the quick solution is to adjust threshold values is MVTools (thSAD, thSCD1/2)
For instance, thSCD1=300 (instead of default value = 400) solves issues on scene changes.

Thanks chainik.

It seems setting ShSCD1 = 2*thSAD/3 is a solution to the sort of gross artifact that happens on frames 117-119. Wow, I've been using MDegrain for years and I never even looked at thSCD1 before. :eek:

But it doesn't solve the trailing edge seen from frame 0, unfortunately. [Unless I set thSCD1/2 so low that I'm getting a scene change on every frame, which switches off overall denoising.]

[chainik_svp]

Ver. 1.1.16
= fixed random crash in svpflow1.dll found by SVP 3.1.7 users

the fix may also affect motion vectors quality

link (http://www.svp-team.com/files/gpl/svpflow-1.1.16.zip)

[Sparktank]

Great work!
I'm already seeing significant improvement over last release.

This fix really improves quality.
I noticed (but haven't thoroughly tested) that the previous release ended up causing artefacting, more than usual.
Mostly just outlined artefacting. Quite severe compared to previous versions.

But now this fix, I can get back into even 60fps interpolation. :)

[travolter]

@Chainik

Really big thanks for the last updates!!! The performance is becoming better on each version thanks to the code optimizations.

Many coders rely on brute force and the classic reply: "buy new hardware".. few ones try to optimize nowadays.

Im oldie in the motion interpolation and I love when I need less cpu usage of my machine doing same tasks along these years ;)

[tsk1979]

In the changelog it says 64bit is available. But I am unable to find 64bit version on the download page. Any links?

[chainik_svp]

SVPflow 4 (rev.128)

The libraries from upcoming multi-OS release of SVP 4.

The main difference is that both Avisynth and Vapoursynth plugins are built from the very same sources for all platforms.
So right now we have:
- Windows / Avisynth / 32 / 64
- Windows / Vapoursynth / 32 / 64
- Linux / Vapoursynth / 32 / 64
- Mac / Vapoursynth / 64 <===== soon

Now all the functions (SVSuper/SVAnalyse/SVSmoothFps) are compatible with MT mode 1.

Note that Linux ones built on Ubuntu 14.04 and as of now depend on Qt5 libs (Core, Network).

See the Vapoursynth sample script inside the arch.

link (http://www.svp-team.com/files/gpl/svpflow-4.0.0.128.zip)

[mark0077]

Thanks Chainik. Which would you personally recommend at this moment in time in terms of getting the most performance out of ones machine, avisynth (with mt mode 1) or vapoursynth. Are there any other changes in the latest version 4 over 3 that are worth updating for, ie quality improvements?

[chainik_svp]

Vapoursynth seems much more efficient and stable in terms of multithreading, however the peak performance is the same as with Avisynth.

Picture quality is the same as with SVP ver.3.

[bennynihon]

Vapoursynth seems much more efficient and stable in terms of multithreading, however the peak performance is the same as with Avisynth.

Picture quality is the same as with SVP ver.3.

I'm trying to use the latest 64-bit SVPflow plugins with AVISynth and its complaining about no function SVConvert existing. This is version svp-4.0.0.128. And Avisynth has no trouble finding SVSuper and SVAnalyse, so its not as if the plugin dll isn't being found. Can you ensure this latest version actually has this SVConvert function, or if it's changed names? thanks!

FYI, the 32-bit version does in fact have SVConvert. So seems to be an issue limited to the 64-bit plugin.

[amayra]

can you give full list of new features ?

[kolak]

Vapoursynth seems much more efficient and stable in terms of multithreading, however the peak performance is the same as with Avisynth.

Picture quality is the same as with SVP ver.3.

No quality improvements? Shame:(

Alchemist OD (software version of their expensive hardware box) gained quality and now clearly outperforms SVP (for the cost of speed and resource requirements).

Also- is it just my imagination or SD content keeps much better quality than HD after SVP conversion (are there some internal compromises on SD+ frame sizes)?

[Bloax]

Also- is it just my imagination or SD content keeps much better quality than HD after SVP conversion (are there some internal compromises on SD+ frame sizes)?
HD content does contain more accurate data on what's actually going on, but this comes at the price of having to do many more calculations to come forward to the same results as SD.
And since pretty accurate motion estimation on SD is already pretty expensive, getting the same kind of quality in HD would be really demanding on the hardware.

[kolak]

For file conversions SVP speed is very good, so I'm happy with eg. 3x slower mode which will also keep relatively good quality on HD.
I'm happy to do some test- got access to K80 Tesla card :)

[amayra]

is this project is no long open source ?

[Reel.Deel]

is this project is no long open source ?

What makes you think that? From the SVP website:
(https://www.svp-team.com/w/index.php?title=Plugins:_SVPflow)
svpflow1

This is a motion vectors search plugin which is a refactored version of MVTools2 2.5 so this plugin is distributed under terms of the GNU GPL license.

svpflow2

A closed-source frame rendering plugin.

It has always been this way, as the documentation states, you can find the svpflow1 source code here: http://www.svp-team.com/files/gpl/svpflow1-src.zip

[Floatingshed]

I am completely confused by this!
How do I use SVPflow to change fps from 60 to 50 without involving the GPU?

Thanks.

[StainlessS]

Floaty, try Interframe if having problems, is simple. Just put dll's in Plugins and also the Interframe2.avsi script, then simple as


num=30000 # EDIT: or for 50FPS num=50 den=1
den=1001
Cores=4
Interframe(NewNum=num,NewDen=den,cores=Cores)


from Interframe2 script


function InterFrame(clip Input, string "Preset", string "Tuning", int "NewNum", int "NewDen", bool "GPU", string "InputType",
\ int "OverrideAlgo", int "OverrideArea", int "Cores", bool "FrameDouble") {
# Defaults
Preset = default(Preset , "Medium")
NewNum = default(NewNum , 0 )
NewDen = default(NewDen , 0 )
Tuning = default(Tuning , "Film" )
GPU = default(GPU , false )
InputType = default(InputType , "2D" )
OverrideAlgo = default(OverrideAlgo, 0 )
OverrideArea = default(OverrideArea, 0 )
FrameDouble = default(FrameDouble , false )

[Floatingshed]

Hello, thanks for the suggestion, but I seem to have an unidentifiable issue with interframe.

I encode to h264 but the encode stops at random points each time, no obvious reason (sometimes after a few frames, sometimes after several minutes or an hour). If I use motionprotectedfps I have no problems, I could use this but was looking/hoping for a more modern filter with fewer artifacts...

[StainlessS]

Just curious, does stop if rendering to lossless avi via for instance ut-vidio or magicyuv ?

[Floatingshed]

No it doesn't, in fact that is how I have been getting around it, render to lossless then run a second process to convert the lossless to h264. I am guessing that it is a memory issue but there's nothing obvious (to me anyway!)

[StainlessS]

@FloatingShed, Could this perhaps be related to you issue:- http://forum.doom9.org/showthread.php?t=173908

Perhaps get together and compare systems.

EDIT: I dont know what SVP player is.

EDIT: Full quote.
This is some serius annoying troubel ive had lately on svp player, ive removed ervreything and did a fresh re-install of the whoe package but for some reason after like 3 seconds of playing on media player classic, the entire danm thing freezes up.

[amayra]

What makes you think that? From the SVP website:
(https://www.svp-team.com/w/index.php?title=Plugins:_SVPflow)




It has always been this way, as the documentation states, you can find the svpflow1 source code here: http://www.svp-team.com/files/gpl/svpflow1-src.zip

svpflow1 in svp-team in website is 4.0.0.128 and in "SVP 4\plugins" have 4.0.0.132

[Reel.Deel]

@chainik_svp

According to the changelog here (https://www.svp-team.com/wiki/Changelog), there's been a handful of updates to SVPflow. The first post and the the download section of the SVP wiki still list version 4.0.0.128. :confused:


SVPflow - 4.1.0.141 - 2017-04-05
= fixed high CPU load with frame interpolation off

SVPflow - 4.1.0.140 - 2017-03-03
+ rendering in 10 bit color depth (Vapoursynth only)

SVPflow - 4.0.0.137 - 2016-08-25
= fixed random crash in mpv and VLC

SVPflow - 4.0.0.136 - 2016-08-18
= fixed video corruption with smooth.cubic=0

SVPflow - 4.0.0.135 - 2016-04-30
= Win: fixed random crash in some cases

SVPflow - 4.0.0.132 - 2016-03-18
- Win: dropped legacy Avisynth 2.5 interface support
+ Win: added SVConvert function in 64-bit version

SVPflow - 4.0.0.131 - 2016-03-04
= Mac: initial public release
- Linux: removed Qt dependencies

SVPflow - 4.0.0.130 - 2016-02-27
= may fix crashes in some cases
= fixed wrong colors in SVPlight

SVPflow - 4.0.0.129 - 2016-02-23
= fixed crash with SVPlight enabled

[kolak]

Looks like anything above 4.0.0.128 is not available for download.

https://www.svp-team.com/wiki/Plugins:_SVPflow

still shows 4.0.0.128 as latest version for download.

[cork_OS]

Here are svpflow libs from the latest SVP4 update: https://www.dropbox.com/s/9wjx4uq07sgy9qw/SVP4-svpflow.zip?dl=0

[Selur]

@cork_OS: do you also have the latest libs for Vapoursynth?

[cork_OS]

@cork_OS: do you also have the latest libs for Vapoursynth?
No, but MysteryX have just asked (http://www.svp-team.com/forum/viewtopic.php?pid=64786#p64786) Chainik to update the libs:
Nothing can stop anyone to take .dll/.so/.dylib from the SVP installation ;)

But I agree that it should be updated. We'll do it soon enough...
However there's nothing useful in the Avisynth part since rev.128

[Selur]

Using:
# Imports
import os
import sys
import ctypes
Dllref = ctypes.windll.LoadLibrary("G:/Hybrid/vsfilters/Support/libfftw3f-3.dll")
# Loading Support Files
Dllref = ctypes.windll.LoadLibrary("G:/Hybrid/vsfilters/Support/OpenCL.dll")
import vapoursynth as vs
core = vs.get_core()
# Import scripts folder
scriptPath = 'G:/Hybrid/vsscripts'
sys.path.append(os.path.abspath(scriptPath))
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/FrameFilter/Interframe/svpflow2_vs64.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/FrameFilter/Interframe/svpflow1_vs64.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/GrainFilter/AddGrain/AddGrain.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/DenoiseFilter/FFT3DFilter/vsfft3dfilter.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/DenoiseFilter/DFTTest/DFTTest.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/DenoiseFilter/KNLMeansCL/KNLMeansCL.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/ResizeFilter/NNEDI3/libnnedi3.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/Support/libmvtools.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/Support/temporalsoften.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/Support/scenechange.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/Support/fmtconv.dll")
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/SourceFilter/FFMS2/ffms2.dll")
# Import scripts
import havsfunc as havsfunc
# Loading C:\Users\Selur\Desktop\source.avi using FFMS2
clip = core.ffms2.Source(source="C:/Users/Selur/Desktop/source.avi",cachefile="H:/Temp/avi_3ed4c33894e101eeafef5c603ca7faab_4827.ffindex",format=vs.YUV422P8,alpha=False)
# making sure input color matrix is set as 470bg
clip = core.resize.Point(clip, matrix_in_s="470bg")
# making sure input color range is set to TV (16-235) scale.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
# setting field order to what QTGMC should assume
clip = core.std.SetFrameProp(clip=clip, prop="_FieldBased", intval=2)
# Deinterlacing using QTGMC
clip = havsfunc.QTGMC(Input=clip, Preset="Fast", TFF=True)
# adjusting frame count with Interframe/SVP
clip = havsfunc.InterFrame(clip, NewNum=60, NewDen=1)
# Output
clip.set_output()
I get a 'Python exception: SVSuper: Clip must be YV12' since I wanted to stick with 4:2:2 for the output I was wondering:
What would be the most lossless way to apply Interframe/SVP and getting 4:2:2 as output?

Cu Selur

[MysteryX]

SVP supports only YV12. If you want to use it, you need to convert to YV12 and can then convert back to YV16 if you want.

Alternatively, my implementation FrameRateConverter (https://forum.doom9.org/showthread.php?p=1810223#post1810223) supports YV16 or YV24, but is much slower especially with multi-threading -- but with considerably better quality.

[markfilipak]

SVPflow was recommended to me by a fellow on the ffmpeg-user list.
I reckon that it's a library, not an application. If so, what is the prerequisite?

I've been developing ffmpeg transcodes based on this:
ffmpeg -i INPUT -filter_complex "minterpolate ..." ... OUTPUT

A typical transcode of a 2 hour movie takes 3 days on a 3.6GHz, 8 thread CPU with both INPUT & OUTPUT on an SSD-RAID0. Why? Because minterpolate is single-threaded and there's no GPU support -- I have an NVIDIA GTX M960M GPU with 1356 CUDA cores.

Related (OT): The ffmpeg telecine filter has a memory leak that kills lengthy transcodes. When combined with minterpolate, transcodes of 5 minute videos (which take ~3 hours) exhaust swap and don't complete -- my RAM is 32GB and swap is 128GB. Any alternative suggestion would be greatly appreciated.

Thanks!

[johnmeyer]

I suggest you look at the original SVPFlow thread:

SVPflow motion interpolation (https://forum.doom9.org/showthread.php?t=164554)

Post #1 includes links to the various downloads. I haven't clicked on that in years, so I don't know if all the prerequisites (other DLLs, etc.) are included, but hopefully they are, and you can then get everything in one click.

[markfilipak]

(Hmmm... I'm still not getting notifications...)

Thanks John,

I suggest you look at the original SVPFlow thread:

SVPflow motion interpolation (https://forum.doom9.org/showthread.php?t=164554)

Post #1 includes links to the various downloads. I haven't clicked on that in years, so I don't know if all the prerequisites (other DLLs, etc.) are included, but hopefully they are, and you can then get everything in one click.

Nope. There's no links to applications that support SVPflow. I think they include Avisynth and Avisynth+ and Vapoursynth (and maybe more). I once downloaded Vaporsynth -- I don't remember why I chose it -- but there's no installer, the start menu just contains fluff. I think there's some controversy regarding Avisynth versus Avisynth+ versus Vapoursynth but I can't remember what they are. It all looks too disorganized and I've already lost too much of my remaining lifetime with ffmpeg.

Are there any wise souls here who can advise me? I'm just trying to get the best quality transcodes possible. I'm not streaming. I've run Handbrake many times but it makes fairly low quality transcodes and doesn't provide for ffmpeg functions to be pasted into the workflow. MKVToolNix GUI is wonderful, but remuxes solely.

Holy Smoke! I just downloaded 'http://www.spirton.com/uploads/InterFrame/20130218-Sample-InterFrame.mkv' & 'http://www.spirton.com/uploads/InterFrame/20130218-Sample-Original.mkv'. This is what I've been trying to do for almost a year to various reactions: "Why do you want to do that?" "60Hz TVs are inherently bad" "You don't know what you're doing" "That's just how movies look on TV" "What judder?" etc. ffmpeg -vf minterpolate is too slow (a 2 hour video to 60FPS in 3 days!). How do I replicate what I downloaded?

[manolito]

Hi Mark,

I think that johnmeyer is the main guy to answer your questions, but he is probably too shy to advertise his own frame interpolation scripts... :p

Whatever, I'll do my best to give you a short overview about what is currently available for AviSynth:

1. MotionProtectedFPS
Based on a plugin by Clouded, very fast even for real time playback. Causes way more artifacts than the MVTools2 based solutions. The source needs to be mod8.

2. Interframe based solutions (SVPFlow)
Optimized for speed to make it work for real time playback. More artifacts than the slower MVTools2 based scripts by johnmeyer and MysteryX.

3. jm_fps by johnmeyer
Derived from an MVTools2 example script, but using optimized parameters. Delivers very nice results. The following scripts are based on it.

4. mx_fps based on Frame Rate Converter by MysteryX
This is a simplified and stripped down version of Frame Rate Converter. It also works under classic AVS 2.6, no support for Hi Bit and Hi Color (only 8 bits and 4:2:0 chroma supported). Works under WinXP and does not require a SSE2 capable CPU.

5. Frame Rate Converter by MysteryX
Adds artifact masking and a few other improvements to the johnmeyer script. Sometimes useful, sometimes not. Very tweakable.


I have uploaded a couple of test conversions using the source you have linked to. This source is not very demanding for frame interpolation, so even the simpler and faster scripts do a pretty good job on it. FWIW I also included AIO packages for MotionProtectedFPS, jm_fps and mx_fps. If you want to play with them just make sure that you don't have duplicate DLLs in your AviSynth\Plugins folder which contain identical function names. If you already have the RGTools plugin in your autoload folder then do not add RemoveGrain.dll to your audoload folder...



Have fun
manolito

[markfilipak]

Hi Mark,
Hi Manalito,

Thanks for the overview.

I'm fair-use transcoding movies I own for my media server. I seek the best possible transcodes to show on a 60Hz TV -- I hate judder! My laptop has an NVIDIA GTX 980M GPU, so any solution should use it.

What I've been doing -- I'm leaving some things out for simplicity:
This:
ffmpeg -i INPUT -filter_complex "minterpolate=fps=60/1.001" OUTPUT
goes straight to 60fps but takes 1-1/2 days per hour of running time. It also makes some minor errors.
This:
ffmpeg - INPUT -filter_complex "minterpolate=fps=48/1.001, telecine=pattern=3322, pp=linblenddeint" OUTPUT
goes to 48fps (so fewer errors), then telecines, then blends the combed frame -- good enough but still takes 1 day per hour of running time.

minterpolate is single-threaded, no GPU use. I think SVPflow would be better, faster.

I've done a lot of reading. I can't figure out the relationship between Avisynth, Avisynth+, Vapoursynth, and Python.

My case is probably pretty strange since I'm starting with a desired filter (SVPflow) and then trying to figure out how to use it. It's a bit like walking into "The Matrix" half way through and asking, "Who's the guy with the gun? And how can he fly?"

Got any advice (or links) to help figure out the path with heart?

[markfilipak]

https://www.sendspace.com/file/823xkp


I download that stuff. Thanks, but...

'20130218-Sample-Original.mkv'
- 24pps@24/1.001fps
- h264 (High), yuv420p(progressive), 1280x534 [SAR 1:1 DAR 640:267], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
- 1697 frames

'20130218-Sample-InterFrame.mkv'
- 60pps(interpolated)@60/1.001fps
- Motion compensated target that is incredibly beautiful.
- h264 (High), yuv420p(progressive), 1280x534 [SAR 1:1 DAR 640:267], 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default)
- 4241 frames

'jm_fps.mkv'
- 24pps(3322telecined)@60/1.001fps
- Extreme judder
- h264 (High), yuv420p(progressive), 1280x532, SAR 1:1 DAR 320:133, 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default)
- 4242 frames

'mx_fps.mkv'
- 24pps(3322telecined)@60/1.001fps
- Extreme judder
- h264 (High), yuv420p(progressive), 1280x532, SAR 1:1 DAR 320:133, 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default)
- 4242 frames

'motionprotectedfps.mkv'
- 24pps(3322telecined)@60/1.001fps
- Extreme judder
- h264 (High), yuv420p(progressive), 1280x528, SAR 1:1 DAR 80:33, 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default)
- 4241 frames

Is there something you wanted me to see because what I did see made me ill.

[manolito]

Sorry, I made these tests using StaxRip, and I must have inserted the FPS conversion command in the wrong place. Please disregard these clips and use the ones from here instead:
https://www.sendspace.com/file/e74ism

[markfilipak]

Sorry, I made these tests using StaxRip, and I must have inserted the FPS conversion command in the wrong place. Please disregard these clips and use the ones from here instead:
https://www.sendspace.com/file/e74ism

That's okay, you probably have as many balls in the air as I do. However...

20130218-Sample-Original.mkv - 1697 frames
20130218-Sample-Original.mkv - h264 (High), yuv420p(progressive), 1280x534 [SAR 1;1 DAR 640;267],
20130218-Sample-Original.mkv - 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

20130218-Sample-InterFrame.mkv - 4241 frames
20130218-Sample-InterFrame.mkv - h264 (High), yuv420p(progressive), 1280x534 [SAR 1;1 DAR 640;267],
20130218-Sample-InterFrame.mkv - 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default)

jm_fps.mkv - 4238 frames
jm_fps.mkv - h264 (High), yuv420p(progressive), 1280x528 [SAR 3439;3478 DAR 137560;57387],
jm_fps.mkv - SAR 88;89 DAR 640;267, 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default)
** Frames have been lost
** Frame height has been truncated to 33 slices
** SAR is wrong

motionprotectedfps.mkv - 4238 frames
motionprotectedfps.mkv - h264 (High), yuv420p(progressive), 1280x528 [SAR 3439;3478 DAR 137560;57387],
motionprotectedfps.mkv - SAR 88;89 DAR 640;267, 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default)
** Frames have been lost
** Frame height has been truncated to 33 slices
** SAR is wrong

mx_fps.mkv - 4240 frames
mx_fps.mkv - h264 (High), yuv420p(progressive), 1280x528 [SAR 3439;3478 DAR 137560;57387],
mx_fps.mkv - SAR 88;89 DAR 640;267, 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default)
** Frames have been lost
** Frame height has been truncated to 33 slices
** SAR is wrong

[manolito]

These were quick and dirty conversions via ffmpeg command line. I made the source mod8 first because motion.dll requires it. This should explain the slight SAR offset. The source filter was DSS2Mod which is known to skip a frame at the end quite often.

The important thing to look for is the smoothness of the motion, and you need to look for the typical interpolation artifacts. As I said before, this source is not very demanding, so even the MotionProtectedFPS result looks pretty good to me. If you feed the interpolators with a demanding source like Anime or with moving vertical edges (like driving along a fence) you certainly will see lots of artifacts.



//EDIT//
I have to correct myself. When I said that this source is not too demanding for frame interpolation I was not looking close enough...
The problems start in the scene where she goes into the house. When she takes off her coat have a look at her arms. And it gets worse when she walks to the stairs. The camera rolls with her so her face stays pretty much in the center of the frames. But the background moves all the time, and the background is not in focus. A typical problem for frame interpolation. All the scripts I tested show heavy artifacts, they all revert to blending. And still they all exhibit warped lines. It is a tradeoff between motion judder or artifacts, pick your poison.

[markfilipak]

These were quick and dirty conversions via ffmpeg command line.

Howdy. That's what I'm trying to do but I don't know how to form the ffmpeg command. Specifically, I don't know how to incorporate svpflow (either one). If I knew how, I'd simply buy them from SVP but so far the SVP folks have not responded.

Do you care to share your ffmpeg command line, Sir?
And is there a special build to make it happen? The nightly git builds don't seem to incorporate SVP.

I have a fairly recent NVIDIA GPU and the latest driver.

Thanks,
Mark.

PS: I have a terrific, 20 second clip.

[manolito]

PS: I have a terrific, 20 second clip.

Please upload it, I like to play with such stuff...


For the ffmpeg command line, I think this is a misunderstanding. I used ffmpeg just to invoke its built-in X264 encoder. All the frame interpolation stuff is handled by AviSynth.

As you already found out, the ffmpeg "minterpolate" filter is not really usable. All the frame interpolate filters I was talking about are based on AviSynth, and the same goes for SVPFlow.

For my conversion I abused an older tool which can change the speed of video clips. It creates an AVS script which is then fed as the source to an ffmpeg command line.

ChangeSpeed.avs:
new_fps = 23.976 * 100 / 100
video = DSS2("F:\Download\20130218-Sample-Original.mkv", fps=23.976, preroll=15)
audio = DirectShowSource("F:\Download\20130218-Sample-Original.mkv", video=false)
AudioDub(video, audio)
Crop(0,0,-Width % 4,-Height % 4)
ConvertToYV12()
AssumeFPS(new_fps)
jm_fps(59.94)


ffmpeg command:
ffmpeg.exe -i changespeed.avs -vcodec libx264 -aspect 2.397 -crf 19 -preset medium -tune film -acodec libfdk_aac -ac 6 "F:\Download\20130218-Sample-Original_speed=100%.mkv"


Bottom line is that for all the interpolation scripts I talked about you will need to use AviSynth. Do you have Avisynth installed at all? If so, do you use AVS+ (which can do multitasking)?

[Ceppo]

Is there YV24 support?

[manolito]

Not for jm_fps and my stripped down version of the original FrameRateConverter mx_fps (because I nneded it to run on ancient machines without SSE2 capable CPUs running classic AVS 2.6 under WinXP). For SVPFlow see here:
https://forum.doom9.org/showthread.php?p=1811797#post1811797

But the original FrameRateConverter by MysteryX running under AVS+ and using the latest plugin versions which support high bitdepth and Hi Color should support YV24 (did not test it myself).

[StainlessS]

From Manolito post 311

new_fps = 23.976 * 100 / 100
video = DSS2("F:\Download\20130218-Sample-Original.mkv", fps=23.976, preroll=15)
audio = DirectShowSource("F:\Download\20130218-Sample-Original.mkv", video=false)
AudioDub(video, audio)
Crop(0,0,-Width % 4,-Height % 4)
ConvertToYV12()
AssumeFPS(new_fps)
jm_fps(59.94)
Just thought I'de point out that
new_fps = 23.976 * 100 / 100 = 23.976002 #with a bit of precision rounding error --- 100 not a power of 2 [should be same ie 23.976].
# not sure what is intended.


blankclip(width=320,height=240)
old_fps=23.976
new_fps = old_fps * 100 / 100
Subtitle( string(old_fps) + " : " + string(new_fps),size=32)

result
https://i.postimg.cc/LswsTyLF/z-00.jpg (https://postimages.org/)

EDIT: Should it be 24000 / 1001.0, ~ 23.97602398 [or 23.9760239760239760239760 ... ie 239760 Recurring]

EDIT:
Specifically, I don't know how to incorporate svpflow (either one).
I have the same question
Can you just use the old script with current dll's ?
EDIT: this one, InterFrame2.avsi, mine seem to be from 2015, current dlls' from 2019.
Latest script by subjunk appears to be this one:- https://forum.doom9.org/showthread.php?p=1486831

[Selur]

I stumbled over what chainik_svp wrote (https://forum.doom9.org/showthread.php?p=1574161#post1574161):
sup3 = last.msuper(pel=2,sharp=2,hpad=0,vpad=0)

# SVAnalyse accepts MSuper with zero padding!
v31=sup3.SVAnalyse("{"+search_params+"}")
v32=sup3.SVAnalyse("{"+search_params+",special:{delta:2}}")
v33=sup3.SVAnalyse("{"+search_params+",special:{delta:3}}")
and tried using it with:
ClearAutoloadDirs()
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\LSMASHSource.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\svpflow1_64.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\mvtools2.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\masktools2.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\DePanEstimate.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\DePan.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\RgTools.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\MedianBlur2.dll")
Import("I:\Hybrid\64bit\Avisynth\avisynthPlugins\mtmodes.avsi")

# loading source: G:\TestClips&Co\files\test.avi
# color sampling YV12@8, matrix: bt601, scantyp: progressive, luminance scale: limited
LWLibavVideoSource("G:\TESTCL~1\files\test.avi",cache=false,dr=true,format="YUV420P8", prefer_hw=0)

FixRipsP2SVP()
# Converting from 8 to 10bit for encoder
ConvertBits(10)
# setting output fps to 25.000fps
AssumeFPS(25,1)
PreFetch(16)
# output: color sampling YV12@10, matrix: bt601, scantyp: progressive, luminance scale: limited
return last

function FixRipsP2SVP(clip a)
{
a
clense(reduceflicker=false).merge(last,0.5).clense(reduceflicker=false)
mot=removegrain(11,0).removegrain(20,0).DepanEstimate(range=2)
take2=a.depaninterleave(mot,prev=2,next=2,subpixel=2)
clean1=take2.TMedian2().selectevery(5,2)
search_params="gpu: 1, block:{w:4,overlap:2}" # can't use blocksize 4, w:4 <> blocksize 8

sup1 = clean1.minblur(1).removegrain(11,0).removegrain(11,0)
\ .mt_lutxy(clean1,"x 1 + y < x 2 + x 1 - y > x 2 - y ? ?",U=2,V=2)
sup1 = sup1.SVSuper("{ pel: 2, gpu: 1, scale: { up: 0 } }")
v21=sup1.SVAnalyse("{"+search_params+"}")
fv21=v21.SVConvert(isb=false)
bv21=v21.SVConvert(isb=true)

sup2 = a.msuper(pel=2,levels=1,sharp=2)
v22=sup1.SVAnalyse("{"+search_params+", special: { delta: 2 } }")
bv22=v22.SVConvert(isb=true)
fv22=v22.SVConvert(isb=false)

interleave(a.mcompensate(sup2,fv22),a.mcompensate(sup2,fv21),a,a.mcompensate(sup2,bv21),a.mcompensate(sup2,bv22))
TMedian2().selectevery(5,2)

sup3 = last.msuper(pel=2,sharp=2,hpad=0,vpad=0)
# SVAnalyse accepts MSuper with zero padding!
v31=sup3.SVAnalyse("{"+search_params+"}")
bv31=v31.SVConvert(isb=true)
fv31=v31.SVConvert(isb=false)

v32=sup3.SVAnalyse("{"+search_params+",special:{delta:2}}")
bv32=v32.SVConvert(isb=true)
fv32=v32.SVConvert(isb=false)

v33=sup3.SVAnalyse("{"+search_params+",special:{delta:3}}")
bv33=v33.SVConvert(isb=true)
fv33=v33.SVConvert(isb=false)

last.mdegrain3(sup3,bv31,fv31,bv32,fv32,bv33,fv33,thSAD=499)

interleave()
return last
}


function MinBlur(clip clp, int r, int "uv")
{
uv = default(uv,3)
uv2 = (uv==2) ? 1 : uv
rg4 = (uv==3) ? 4 : -1
rg11 = (uv==3) ? 11 : -1
rg20 = (uv==3) ? 20 : -1
medf = (uv==3) ? 1 : -200

RG11D = (r==0) ? mt_makediff(clp,clp.sbr(),U=uv2,V=uv2)
\ : (r==1) ? mt_makediff(clp,clp.removegrain(11,rg11),U=uv2,V=uv2)
\ : (r==2) ? mt_makediff(clp,clp.removegrain(11,rg11).removegrain(20,rg20),U=uv2,V=uv2)
\ : mt_makediff(clp,clp.removegrain(11,rg11).removegrain(20,rg20).removegrain(20,rg20),U=uv2,V=uv2)
RG4D = (r<=1) ? mt_makediff(clp,clp.removegrain(4,rg4),U=uv2,V=uv2)
\ : (r==2) ? mt_makediff(clp,clp.medianblur(2,2*medf,2*medf),U=uv2,V=uv2)
\ : mt_makediff(clp,clp.medianblur(3,3*medf,3*medf),U=uv2,V=uv2)
DD = mt_lutxy(RG11D,RG4D,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?",U=uv2,V=uv2)
clp.mt_makediff(DD,U=uv,V=uv)
return(last)
}

# median of 5 clips from helpers.avs by G-force
function Median2(clip "input_1", clip "input_2", clip "input_3", clip "input_4", clip "input_5", string "chroma")
{
chroma = default(chroma,"process") #default is "process". Alternates: "copy first" or "copy second"
#MEDIAN(i1,i3,i5)
Interleave(input_1,input_3,input_5)
chroma == "process" ? Clense(reduceflicker=false) : Clense(reduceflicker=false,grey=true)
m1 = selectevery(3,1)
#MAX(MIN(i1,i3,i5),i2)
m2 = input_1.MT_Logic(input_3,"min",chroma=chroma).MT_Logic(input_5,"min",chroma=chroma).MT_Logic(input_2,"max",chroma=chroma)
#MIN(MAX(i1,i3,i5),i4)
m3 = input_1.MT_Logic(input_3,"max",chroma=chroma).MT_Logic(input_5,"max",chroma=chroma).MT_Logic(input_4,"min",chroma=chroma)
Interleave(m1,m2,m3)
chroma == "process" ? Clense(reduceflicker=false) : Clense(reduceflicker=false,grey=true)
selectevery(3,1)
chroma == "copy first" ? last.MergeChroma(input_1) : chroma == "copy second" ? last.MergeChroma(input_2) : last
Return(last)
}

function TMedian2(clip c) {
Median2(c.selectevery(1,-2), c.selectevery(1,-1), c, c.selectevery(1,1), c.selectevery(1,2) )
}


But my problem is that
sup3 = last.msuper(pel=2,sharp=2,hpad=0,vpad=0)
# SVAnalyse accepts MSuper with zero padding!
v31=sup3.SVAnalyse("{"+search_params+"}")
aborts with "SVAnalyse, non-valid number of levels".


-> Does anyone know how to fix this?

Cu Selur

[StainlessS]

You usin' DTL mod of Mvtools [I think he made some test changes which might possibly be cause] ?

Have you tried something like add Levels=0 or Levels=5 to mSuper().
Think 0 is default which might be internally converted to 5, maybe, possibly, perhaps.

[Selur]

Have you tried something like add Levels=0 or Levels=5 to mSuper().yes, tried 0-6.

You usin' DTL mod of Mvtools [I think he made some test changes which might possibly be cause] ?
Nope, I tried with https://github.com/pinterf/mvtools.
(Now, I also tried with mvtools2_asb1_PT1std_msvc.dll, but that didn't change anything).

[flossy_cake]

Just coming to grips with SVPFlow... am I correct in understanding that it cannot deal well with video containing duplicate frames? For example as a synthetic test, I have a 25p video and make every second frame a duplicate with SelectEvery(1,0,0) or ChangeFPS(50), I cannot then use SVP on this clip and turn it into interpolated 50p? I tried using "{rate:{num:2,den:1,abs:false}" to turn it into 100p and then SelectEven() back down to 50p, but it doesn't work - the duplicates seem to confuse the motion vectors and I end up with uneven cadence. I've tried playing with "mode:" as well without luck.

It seems SVP needs every frame to be a unique frame in order to work properly, is that right? :thanks:

[johnmeyer]

Any motion estimation algorithm expects the video to be smooth and continuous in the time domain. Any duplicates or gaps (i.e., missing frames) will cause problems.

If you have perfect duplicates (or even "near perfect" duplicates), those are easy to remove prior to feeding the video to motion estimation (SVP, in your case). For instance, if you were starting with 24 fps film that had been telecined to 29.97, you would perform inverse telecine using the TFM/TDecimate combination which comes as part of the IVTC package. That would leave you with 23.976 progressive frames with no duplicates. You would then feed this to SVP.

[flossy_cake]

Any motion estimation algorithm expects the video to be smooth and continuous in the time domain. Any duplicates or gaps (i.e., missing frames) will cause problems.

If you have perfect duplicates (or even "near perfect" duplicates), those are easy to remove prior to feeding the video to motion estimation (SVP, in your case). For instance, if you were starting with 24 fps film that had been telecined to 29.97, you would perform inverse telecine using the TFM/TDecimate combination which comes as part of the IVTC package. That would leave you with 23.976 progressive frames with no duplicates. You would then feed this to SVP.

Thanks, that's what I was anticipating.

Well, In the end I couldn't tolerate the artefacts with SVP regardless of settings. Hand gestures are particularly problematic.

Probably the one setting that mitigates interp artefacts the most is the "area" setting but then it doesn't really look much different than frameblending, actually it looks like a blend of the frameblended frame and the motion compensated frame as I can still see a dull remnant of the motion compensated junk blended in. Seem to be lots of scenechange false positives too.

It's extremely impressive when it's working well, on controlled pans and such. "So close yet so far" is how I would describe it.

[johnmeyer]

It's extremely impressive when it's working well, on controlled pans and such. "So close yet so far" is how I would describe it.Yup. You perfectly summed up motion estimation. My version of your summation comes from the last two lines of the poem about the girl with the curl on her forehead: "When she was good she was very, very good, but when she was bad, she was horrid."

If you have lots of time, you can make two videos, one using motion estimation and the other using frame blending. You then look for the awful motion estimation artifacts and, for that one frame, substitute frame blending. It works.

One person in this forum made a valiant attempt to automate that substitution idea, and even used masks to only replace the frame-blended result for the part of the frame which contains the artifact. He put a huge effort into the project, but unfortunately, it never quite succeeded.

[coolgit]

Thanks, that's what I was anticipating.

Well, In the end I couldn't tolerate the artefacts with SVP regardless of settings. Hand gestures are particularly problematic.

Probably the one setting that mitigates interp artefacts the most is the "area" setting but then it doesn't really look much different than frameblending, actually it looks like a blend of the frameblended frame and the motion compensated frame as I can still see a dull remnant of the motion compensated junk blended in. Seem to be lots of scenechange false positives too.

It's extremely impressive when it's working well, on controlled pans and such. "So close yet so far" is how I would describe it.

For clarification are you using SVPFlow or SVPFlow2?

[flossy_cake]

For clarification are you using SVPFlow or SVPFlow2?

I'm not sure - in my avisynth plugins folder I have:
svpflow1_64.dll
svpflow2_64.dll

They came from v4.2.0.142 here (http://avisynth.nl/index.php/SVPflow#Downloads) (I specifically chose that version as it's the last version that doesn't require SVPManager to be running).

I am calling it using the Interframe() wrapper, eg.


InterFrame(
\ GPU=true,
\ Tuning="film",
\ Preset="medium",
\ OverrideAlgo=21,
\ OverrideArea=100,
\ Cores=8)
\ .Prefetch(8)

# reducing halos with OverrideAlgo (13->21)
# reducing wavy lines with OverrideArea (0->100)


I tried moving svpflow1_64.dll out of the plugins folder and got the error "no function SVSuper" so I think it's using svpflow1_64.dll, although Interframe also calls SVAnalyse() and SVSmoothFps() as well.

But Interfame is quite old so it's probably using SVPFlow1 I would imagine.

How do I use SVPFlow2 at the same settings as Interframe?

edit: oh SVPSmoothFPS() is SVPFlow2, right?

[Selur]

edit: oh SVPSmoothFPS() is SVPFlow2, right?
Yes, see: https://www.svp-team.com/wiki/Manual:SVPflow#svpflow2

[flossy_cake]

I don't have motion interpolation on my TV - for those who have it on recent model TV's I'd be interested to hear some of your opinions about how SVPFlow compares with brands like LG, Panasonic, Sony. Is it much worse? A little worse? About the same? etc. I haven't been following the TV scene for a while, for all I know maybe frame interpolation on TV's got better over the last 10 years.
:thanks:

[coolgit]

I'm not sure - in my avisynth plugins folder I have:
svpflow1_64.dll
svpflow2_64.dll

They came from v4.2.0.142 here (http://avisynth.nl/index.php/SVPflow#Downloads) (I specifically chose that version as it's the last version that doesn't require SVPManager to be running).


Actually last version is svpflow1 4.3.0.156 and svpflow2 4.3.0.161.

[kedautinh12]

Actually last version is svpflow1 4.3.0.156 and svpflow2 4.3.0.161.

But it needs SVPManager to be running

[coolgit]

But it needs SVPManager to be running

Nope.

[Selur]

Hybrid comes with:
32bit Avisynth:
svpflow1.dll: 4.3.0.156
svpflow2.dll: 4.3.0.160
64bit Avisynth:
svpflow1_64.dll: 4.3.0.156
svpflow2_64.dll: 4.3.0.161
64bit Vapoursynth:
svpflow1_vs64.dll: 4.5.0
svpflow2_vs64.dll: 4.3.0.161

Cu Selur