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