Vapoursynth

[kolak]

import vapoursynth as vs
import havsfunc as haf
import mvsfunc as mvs

core = vs.get_core()

src = ...

last = src
last = haf.ChangeFPS(last, 60000, 1001)
last = mvs.AssumeTFF(last) # Actually, not all filters support this, unfortunately
last = core.std.SeparateFields(last)
last = core.std.SelectEvery(last, 4, [0, 3])
last = haf.Weave(last, tff=True) # this one doesn't
last.set_output()


This should do it. You need mvsfunc and havsfunc for this to work.

Sort of double my question- no way of running this on vs native capabilities with 8bit+ support?

[feisty2]

kind of a more fair test here
did some cleanup to my version and it runs a bit faster now... just a little bit
http://i.imgur.com/jqv4sH5.png
and jackoneill's version (https://github.com/dubhater/vapoursynth-temporalsoften/blob/master/src/temporalsoften.c)
inserted clamping, and compiled with the same settings used in my version
http://i.imgur.com/e76T5Ur.png
still faster..

dunno what's happening here cuz I'm no professional programmer...
looking for some advice

[feisty2]

so I managed to get rid of alloca(), and got a performance boost again,
http://i.imgur.com/eRxhyis.png

interesting, so alloca() actually cost some time here, thought stack memory allocation should come with miniature and negligible costs...

@Myrsloik
Is 347.69fps against 371.93fps (6.517% performance loss) acceptable?
I'll stop investigating further about performance stuff if so...

[Myrsloik]

I guess it's close enough. Sometimes just changing irrelevant stuff makes it compile things very differently and slower. That's life. Try making gcc builds of both and compare that. The result could be completely different. Or try clang-cl (http://llvm.org/builds/) which is easy to use in windows.

[Myrsloik]

This is an important filtering announcement:

Stop using RemoveGrain!
...at least some of the modes.

Several RemoveGrain functions have now gotten better substitutes in the core that support float as well.
Mode 4 replacement (always same speed or faster, much faster for 8bit): Median()
Mode 20 replacement (always same speed or faster): Convolution(matrix=[1, 1, 1, 1, 1, 1, 1, 1, 1])
Mode 19 replacement (about half as fast): Convolution(matrix=[1, 1, 1, 1, 0, 1, 1, 1, 1])
Mode 11&12 replacement (about half as fast): Convolution(matrix=[1, 2, 1, 2, 4, 2, 1, 2, 1])

[feisty2]

https://github.com/IFeelBloated/vapoursynth-focus

repo renamed to vapoursynth-focus, added SpatialSoften port, all sample types except half precision are supported like TemporalSoften
SpatialSoften was coded for YUY2 in avisynth and I gotta say, YUY2 is a BITCH!!!
@Myrsloik
guess you could simply merge it to https://github.com/vapoursynth/vapoursynth/tree/master/src/filters

[LigH]

SpatialSoften was coded for YUY2 in avisynth and I gotta say, YUY2 is a BITCH!!!

Yes, packed-pixel formats are a lot more annoying than planar formats. That's why AviSynth people still hope for a full featured YV16 port of QTGMC... or does it already work? Okay, wrong topic here. :rolleyes:

[Boulder]

The Windows compiling instructions say that YASM 1.3.0 is broken on Windows. In what way - i.e., does it affect compiling other stuff such as x264 or x265 as well?

[LigH]

YASM 1.3.0 - broken in which way? x265 relies on it...

[Myrsloik]

The Windows compiling instructions say that YASM 1.3.0 is broken on Windows. In what way - i.e., does it affect compiling other stuff such as x264 or x265 as well?

The visual studio integration is broken.

[feisty2]

Yes, packed-pixel formats are a lot more annoying than planar formats. That's why AviSynth people still hope for a full featured YV16 port of QTGMC... or does it already work? Okay, wrong topic here. :rolleyes:


//Avisynth SpatialSoften
...
int edge = (diameter+1) & -4; //wtf????
for (x=0; x<edge; ++x) // diameter-1 == (diameter>>1) * 2
dstp[y*dst_pitch + x] = srcp[y*src_pitch + x];
for (; x < row_size - edge; x+=2)
{
int cnt=0, _y=0, _u=0, _v=0;
int xx = x | 3; //wtf?????
int Y = srcp[y*src_pitch + x], U = srcp[y*src_pitch + xx - 2], V = srcp[y*src_pitch + xx];
for (int h=0; h<diameter; ++h)
{
for (int w = -diameter+1; w < diameter; w += 2)
{
int xw = (x+w) | 3; //?????
if (IsClose(line[h][x+w], Y, luma_threshold) && IsClose(line[h][xw-2], U,
chroma_threshold) && IsClose(line[h][xw], V, chroma_threshold))
{
++cnt; _y += line[h][x+w]; _u += line[h][xw-2]; _v += line[h][xw];
}
}
}
dstp[y*dst_pitch + x] = (_y + (cnt>>1)) / cnt;
if (!(x&3)) { //??????
dstp[y*dst_pitch + x+1] = (_u + (cnt>>1)) / cnt;
dstp[y*dst_pitch + x+3] = (_v + (cnt>>1)) / cnt;
}
}
...


been told C is nothing but a glorified assembly language, never thought that to be serious, and I actually do think that's being serious not kidding staring at all these bizarre bullshit bitwise operations required for YUY2
YUY2 is evil

[jackoneill]

been told C is nothing but a glorified assembly language, never thought that to be serious, and I actually do think that's being serious not kidding staring at all these bizarre bullshit bitwise operations required for YUY2
YUY2 is evil

I'm pretty they are not required. It all depends on the programmer's style:

// the largest multiple of 4 less than or equal to diameter + 1:
int edge = (diameter+1) & -4; //wtf????

// Slightly more intelligible because I don't have to think about how -4 looks in binary:
int edge = (diameter + 1) & ~3;

// And more still:
int edge = (diameter + 1) / 4 * 4;

// or:
int edge = (diameter + 1) - ((diameter + 1) % 4);

GCC output with -O2:

4003b0: 8d 47 01 lea eax,[rdi+0x1]
4003b3: 83 e0 fc and eax,0xfffffffc

4003b0: 8d 47 01 lea eax,[rdi+0x1]
4003b3: 83 e0 fc and eax,0xfffffffc

4003b0: 8d 47 04 lea eax,[rdi+0x4]
4003b3: 83 c7 01 add edi,0x1
4003b6: 0f 49 c7 cmovns eax,edi
4003b9: 83 e0 fc and eax,0xfffffffc

4003b0: 8d 47 01 lea eax,[rdi+0x1]
4003b3: 89 c1 mov ecx,eax
4003b5: c1 f9 1f sar ecx,0x1f
4003b8: c1 e9 1e shr ecx,0x1e
4003bb: 8d 14 08 lea edx,[rax+rcx*1]
4003be: 83 e2 03 and edx,0x3
4003c1: 29 ca sub edx,ecx
4003c3: 29 d0 sub eax,edx

Notice how even the latter two don't contain the dreaded idiv instruction. Furthermore, these seem to be unsigned quantities. If you make the variables unsigned instead of int:

4003b0: 8d 47 01 lea eax,[rdi+0x1]
4003b3: 83 e0 fc and eax,0xfffffffc

4003b0: 8d 47 01 lea eax,[rdi+0x1]
4003b3: 83 e0 fc and eax,0xfffffffc

4003b0: 8d 47 01 lea eax,[rdi+0x1]
4003b3: 83 e0 fc and eax,0xfffffffc

4003b0: 8d 47 01 lea eax,[rdi+0x1]
4003b3: 83 e0 fc and eax,0xfffffffc



int xx = x | 3; //wtf?????

// The next multiple of 4, minus 1
int xx = x / 4 * 4 + 3;

GCC output with -O2:

4003b0: 89 f8 mov eax,edi
4003b2: 83 c8 03 or eax,0x3

4003b0: 8d 47 03 lea eax,[rdi+0x3]
4003b3: 85 ff test edi,edi
4003b5: 0f 49 c7 cmovns eax,edi
4003b8: 83 c8 03 or eax,0x3

With unsigned variables:

4003b0: 89 f8 mov eax,edi
4003b2: 83 c8 03 or eax,0x3

4003b0: 89 f8 mov eax,edi
4003b2: 83 c8 03 or eax,0x3



// If x is a multiple of 4:
if (!(x&3)) { //??????

if (x % 4 == 0) {

GCC output with -O2:

4003b0: 89 f8 mov eax,edi
4003b2: 83 e0 03 and eax,0x3

4003b0: 89 fa mov edx,edi
4003b2: c1 fa 1f sar edx,0x1f
4003b5: c1 ea 1e shr edx,0x1e
4003b8: 8d 04 17 lea eax,[rdi+rdx*1]
4003bb: 83 e0 03 and eax,0x3
4003be: 29 d0 sub eax,edx

With unsigned variables:

4003b0: 89 f8 mov eax,edi
4003b2: 83 e0 03 and eax,0x3

4003b0: 89 f8 mov eax,edi
4003b2: 83 e0 03 and eax,0x3


tl;dr: C lets you fiddle with the bits directly, but you don't have to if you'd rather not.

[TheFluff]

Avisynth code looks like it does because it is from the dark ages and written by people who really didn't care about code maintenance.

[Selur]

As a side note: the new DGDecNV version which uses Avisynth 2.6 seems to work fine with Vapoursynth. (http://rationalqm.us/board/viewtopic.php?f=8&t=463&start=10#p5005 and following)

[Boulder]

Whoa, that's perfect :) I never got a notification from that thread, thanks for pointing it out.

[feisty2]

sometimes I just think something like this

auto src_stride = vsapi->getStride(src, plane) / sizeof(float);
auto srcp = reinterpret_cast<const float *>(vsapi->getReadPtr(src, plane));
auto h = vsapi->getFrameHeight(src, plane);
auto w = vsapi->getFrameWidth(src, plane);
for (auto y = 0; y < h; ++y) {
for (auto x = 0; x < w; ++x) {

//srcp[x], blah blah blah

}
srcp += src_stride;
}

which is the widely used way of filter writing, is super inconvenient, the frame itself is 2D obviously
and treating it like 1D(single line each time) brings a lot of extra trouble sometimes, referencing neighbor pixels at the current line is direct and handy, and referencing vertically neighbor pixels goes straight to pointer arithmetic and that's error prone and not nice..

so why not just treat it like 2D cuz it's, well, just actually 2D..

auto src_stride = vsapi->getStride(src, plane) / sizeof(float);
auto srcp = reinterpret_cast<const float *>(vsapi->getReadPtr(src, plane));
auto h = vsapi->getFrameHeight(src, plane);
auto w = vsapi->getFrameWidth(src, plane);
auto actual_srcp = reinterpret_cast<decltype(&srcp)>(alloca(sizeof(srcp) * h));
for (auto i = 0; i < h; ++i)
actual_srcp[i] = srcp + i * src_stride;
for (auto y = 0; y < h; ++y)
for (auto x = 0; x < w; ++x) {

//actual_srcp[y][x], blah blah blah

}

this makes referencing vertically and horizontally neighbor pixels equally handy, no pointer arithmetic required since actual_srcp itself is a 2D pointer.
just wondering why no one ever did this, I mean, what's the con of writing filter this way?

[Myrsloik]

Worse code generation. That's why. Every time you try to be clever the visual studio compiler punishes you with insanely stupid code generation.

And it's not 2D at all in memory. Obfuscation will only make fewer people remember that.

[~SimpleX~]

Myrsloik, does "std.PlaneStats" work correctly? Should PlaneStatsDiff be calculated like abs(f[0].props.PlaneStatsAverage - f[1].props.PlaneStatsAverage)?

I have a script like this:

sep = core.std.PlaneStats(core.std.SeparateFields(clip, tff=True), plane=0)
top = core.std.SelectEvery(sep, 2, 0)
bot = core.std.SelectEvery(sep, 2, 1)

def _apply_show(n, f):
fout = f[0].copy()
diff = abs(f[1].props.PlaneStatsAverage - f[2].props.PlaneStatsAverage)
fout.props.FieldsDiff = diff
return fout

propclip = core.std.ModifyFrame(clip, clips=[clip, top, bot], selector=_apply_show)

if True:
return core.text.FrameProps(core.std.PlaneStats(top, bot, plane=0))
else:
return core.text.FrameProps(propclip, props=["FieldsDiff"])


PlaneStatsDiff value is not even close to FieldsDiff.

[Myrsloik]

Myrsloik, does "std.PlaneStats" work correctly? Should PlaneStatsDiff be calculated like abs(f[0].props.PlaneStatsAverage - f[1].props.PlaneStatsAverage)?

I have a script like this:

sep = core.std.PlaneStats(core.std.SeparateFields(clip, tff=True), plane=0)
top = core.std.SelectEvery(sep, 2, 0)
bot = core.std.SelectEvery(sep, 2, 1)

def _apply_show(n, f):
fout = f[0].copy()
diff = abs(f[1].props.PlaneStatsAverage - f[2].props.PlaneStatsAverage)
fout.props.FieldsDiff = diff
return fout

propclip = core.std.ModifyFrame(clip, clips=[clip, top, bot], selector=_apply_show)

if True:
return core.text.FrameProps(core.std.PlaneStats(top, bot, plane=0))
else:
return core.text.FrameProps(propclip, props=["FieldsDiff"])


PlaneStatsDiff value is not even close to FieldsDiff.

Only planestats gives the correct value. The planeaverage way is wrong. I think I brainfarted when I wrote that lpng ago.

[shekh]

this makes referencing vertically and horizontally neighbor pixels equally handy, no pointer arithmetic required since actual_srcp itself is a 2D pointer.
just wondering why no one ever did this, I mean, what's the con of writing filter this way?

You precomputed result of multiply into table.

Advantages:
marginally cleaner code

Disadvantages:
no performance gain (integer multiply is fast)
longer code to access pixel (maybe slower)
extra cache pollution

[littlepox]

Bug Report for std.Expr(probably another bug in the ternary operator):

src8 = core.lsmas.LWLibavSource("xxx.mkv") # some normal video input
res = core.std.Expr(src8, "x 5 < 0 x 10 < x 16 - dup * 256 ? ?")
res.set_output()

This crashes.

#####################################################

However,


src8 = core.lsmas.LWLibavSource("xxx.mkv") # some normal video input
res = core.std.Expr(src8, "x 5 >= x 10 < x 16 - dup * 256 ? 0 ?")
res.set_output()

This works.

[Myrsloik]

Bug Report for std.Expr(probably another bug in the ternary operator):

src8 = core.lsmas.LWLibavSource("xxx.mkv") # some normal video input
res = core.std.Expr(src8, "x 5 < 0 x 10 < x 16 - dup * 256 ? ?")
res.set_output()

This crashes.

#####################################################

However,


src8 = core.lsmas.LWLibavSource("xxx.mkv") # some normal video input
res = core.std.Expr(src8, "x 5 >= x 10 < x 16 - dup * 256 ? 0 ?")
res.set_output()

This works.

And which version did you use?

[littlepox]

And which version did you use?

R32 64bit with Python 3.5.0

[Myrsloik]

R32 64bit with Python 3.5.0

Try the latest R33 test version then.

[feisty2]

replicable under r33 test4
http://i.imgur.com/bobM2Gj.png

[littlepox]

Excuse me if this is trivial, but where can I get the builds for the test versions?

[Boulder]

Excuse me if this is trivial, but where can I get the builds for the test versions?

http://forum.doom9.org/showthread.php?p=1775684#post1775684

Myrsloik compiles them every now and then and posts the links here.

[littlepox]

http://forum.doom9.org/showthread.php?p=1775684#post1775684

Myrsloik compiles them every now and then and posts the links here.

Thanks. Just as f2 pointed out, that bug is replicate under R33 test4.

[Selur]

When using LWLibavSource in Vapoursynth like this:
# Imports
import vapoursynth as vs
core = vs.get_core()
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/Vapoursynth/vapoursynth64/plugins/SourceFilter/LSmashSource/vslsmashsource.dll")
# Loading Source: C:/Users/Selur/Desktop/test2160.mov ProRes 10bit 4196x2160
clip = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/test2160.mov")
# Cropping
clip = core.std.CropRel(clip=clip, left=0, right=0, top=224, bottom=224)
# Output
clip.set_output()
I notice:
a. it's really slow compared to when using LWLibavSource in an Avisynth script
b. I get an error message when I close the preview :
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001cb3508e060] ignoring 'frma' atom of 'mp4a', stream format is 'mp4a' is there a way to suppress that error? (not really interested in the audio,..)

Cu Selur

Ps.: is there also a portable version of the latest vapoursynth test build?

[Myrsloik]

R33 test6 (https://dl.dropboxusercontent.com/u/73468194/VapourSynth-R33-test6.exe)

Changes from test4:

Should fix the recently reported expr bug
The installer now allows other python distributions to be used, works with anaconda under certain conditions
Some more genericfunctions tweaks that probably no one will notice

[feisty2]

Okay...
Where's test5?

[Selur]

@myrsloik: any chance for a portable version of the test6 ?

[Myrsloik]

@myrsloik: any chance for a portable version of the test6 ?

Maybe when I reach RC stage. Still have to test so many things. But at least I'm done with all new features for R33... I think.

QTGMC (and other complex scripts) speed comparisons with R32 are also welcome. I'm curious how bug different it makes. Just remember to replace the relevant removegrainmodes first.

[~SimpleX~]

Myrsloik, could you please fix PlaneStats (average/diff)? I'd like to use it in SmartFade function (which compares average luma of top/bottom fields).

[Myrsloik]

Myrsloik, could you please fix PlaneStats (average/diff)? I'd like to use it in SmartFade function (which compares average luma of top/bottom fields).

Fix what? It's correct. Or you at least have to describe why you think it sin't correct.

[~SimpleX~]

Why abs(f[0].props.PlaneStatsAverage - f[1].props.PlaneStatsAverage) is not the same with the PlaneStatsDiff generated by core.std.PlaneStats(clip1, clip2, plane=0)?
I've asked that one page ago.

[Myrsloik]

Why abs(f[0].props.PlaneStatsAverage - f[1].props.PlaneStatsAverage) is not the same with the PlaneStatsDiff generated by core.std.PlaneStats(clip1, clip2, plane=0)?
I've asked that one page ago.

Because that's not how a per pixel difference is calculated

[jackoneill]

Myrsloik, could you please fix PlaneStats (average/diff)? I'd like to use it in SmartFade function (which compares average luma of top/bottom fields).

Maybe this helps: https://github.com/dubhater/Wobbly/blob/27be6fba018139dd46d77b8aa3fc956e84833149/src/wibbly/WibblyJob.cpp#L280

[~SimpleX~]

Only planestats gives the correct value. The planeaverage way is wrong. I think I brainfarted when I wrote that lpng ago.

Then I didn't understand what you meant here. Sorry.

Maybe this helps: https://github.com/dubhater/Wobbly/blob/27be6fba018139dd46d77b8aa3fc956e84833149/src/wibbly/WibblyJob.cpp#L280

Yup, thanks. That's close to my function, but I like the code. :thanks:

[aculnaig]

VapourSynth latest git.
zimg latest git.

Give me this.



CXX src/core/libvapoursynth_la-vsresize.lo
src/core/vsresize.cpp: In constructor ‘{anonymous}::vszimg::vszimg(const VSMap*, void*, VSCore*, const VSAPI*)’:
src/core/vsresize.cpp:747:69: error: ‘NAN’ was not declared in this scope
src_left = propGetScalarDef<double>(in, "src_left", NAN, vsapi);
^~~
make: *** [Makefile:1457: src/core/libvapoursynth_la-vsresize.lo] Error 1




GCC info



gcc --version


gcc (GCC) 6.1.1 20160802
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.




EDIT --> Rolling back to commit f96db59 compile fine

[feisty2]

@Myrsloik
http://forum.doom9.org/showthread.php?t=173470
http://forum.doom9.org/showthread.php?t=173703
these 2 modules I wrote are well documented and seem to be bug free for now after series of different tests..
can you add them to the plugin list?

[Myrsloik]

It's time for the glorious R33 RC1 (https://dl.dropboxusercontent.com/u/73468194/VapourSynth-R33-RC1.exe)!

It's now mostly compiled with clang-cl which should give slightly better performance and hopefully no new bugs either. Note that the internal resizers now have reached feature parity with fmtconv apart from a few of the more exotic dithering methods.

And remember to STOP USING REMOVE GRAIN (http://forum.doom9.org/showpost.php?p=1775776&postcount=2191) (sometimes)

Changes:
r33:
added autoadjust to prefetch list
the resizers can now have the active image region specified to do things like subpixel shifts and cropping
genericfilters is no longer included with the installer and has been deprecated for a long time, if you for some reason miss canny simply use the tcanny plugin instead for a better implementation
assvapour was renamed to subtext and now supports bitmap subtitles as well (jackoneill)
alternative python installations can now be selected when installing on windows, note that there many pitfalls when not using python from python.org
the rshift argument of sobel/prewitt is now deprecated because it's pointless, simply scale the min and max args as appropriate
optimized minimum, maximum, median, deflate, inflate, convolution (1x3, 3x1 and 3x3) on x86 cpus
added float support to minimum, maximum, median, deflate, inflate, convolution, prewitt, sobel, invert, limiter, binarize and levels functions, note that most of the arguments have been changed from int to float
the whole project can now be compiled with clang-cl under windows
directshowsource from recent avs+ can now be used
fixed swapped uv planes with yuv411 output in vsvfw and avfs
merged vsfs with the latest version of avfs, avfs now work for both vapoursynth and avisynth scripts and no longer has shell integration
avisource can now open all formats vsvfw can output plus b48r
fixed corrupted output in vfm when clip2 isn't 8 bit
fixed crash due to stack overflow if an extremely long filter graph is freed
now installs the vs2015 update 3 runtimes on windows
vsvfw will now automatically convert rgb24 to packed bgra for convenience
added b64a and P416 output to vsvfw
updated to zimg v2.2 branch
mixed imwri fixes
fixed rare access violation in expr when ternary operator is used (jackoneill)

As usual speed comparisons with R32 are welcome. Especially with scripts with fmtconv and removegrain replaced.

[Myrsloik]

@Myrsloik
http://forum.doom9.org/showthread.php?t=173470
http://forum.doom9.org/showthread.php?t=173703
these 2 modules I wrote are well documented and seem to be bug free for now after series of different tests..
can you add them to the plugin list?

Vine I'll add but something that even calls itself placebo is something I'm not so sure would be useful to others...

[feisty2]

Vine I'll add but something that even calls itself placebo is something I'm not so sure would be useful to others...

I found that performance boost without serious quality degradation is possible for Oyster recently, so keeping the temporal radius 6 for Oyster.Basic and setting a smaller radius like 3 or 2 in other functions gave me at least 10x speed boost! speed could be further revved by using 0.5 pixel precision motion estimation instead of 0.25 pixel precision stuff, and MVTools' internal resampling function instead of NNEDI

and besides, it could also be useful if someone has some short and precious footage that suffers from compression artifacts, in this case people care much less about performance and much more about quality, like movies that were shot mostly on 35mm but a few scenes on 70mm IMAX because those scenes are valuable and deserve better

or maybe someone like me finds it interesting and would like to toy or experiment with it...

[Selur]

It's time for the glorious R33 RC1!
Portable version too ? :D

[Myrsloik]

Portable version too ? :D

32bit (https://dl.dropboxusercontent.com/u/73468194/VapourSynth32-Portable-R33-RC1.7z)

64bit (https://dl.dropboxusercontent.com/u/73468194/VapourSynth64-Portable-R33-RC1.7z)

[Selur]

Thanks! :)

[feisty2]

https://github.com/IFeelBloated/vapoursynth-focus/releases/tag/r4
windows binaries(x86+x64 with no extension) for spatialsoften and temporalsoften
I messed around with LLVM a while ago and the binary it generated was slower than msvc binary...

[Myrsloik]

R33 RC2 (https://dl.dropboxusercontent.com/u/73468194/VapourSynth-R33-RC2.exe)

Possibly fixes some newly introduced resizing issues

Will post a portable version after things are confirmed to actually be fixed

[Selur]

:D Portable version too ? :D