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

[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