Vapoursynth

[Myrsloik]

I've now enabled the github wiki. Anyone with a github account can freely edit it. It's empty right now so suggest a good structure.

https://github.com/vapoursynth/vapoursynth/wiki

[stax76]

I suggests a Tools page like so:

Editors

VapourSynth Editor

GUIs

StaxRip
Simple x264/x265 Launcher

Encoders

QSVEncC
NVEncC
VCEEncC

Misc

vspipe
VirtualDub

[splinter98]

Originally Posted by stax76

I'm also using the github wiki for StaxRip but can't really tell how it compares to other solutions. What could also be interesting is readthedocs.org, most people here know it from the excellent x265 docs, it looks like it's built with Python so a natural fit for VapourSynth.

https://readthedocs.org

https://x265.readthedocs.org

+1 for read the docs it should be a simple case of sign up, link to the github and enable the webhook and it will build on pull updates (and should support tag based version history which is useful for people using older versions for whatever reason). (it could also be set up as a cname for docs.vapoursynth.com if desired).

The wiki still useful for user contributed items, such as example snippets.

[foxyshadis]

Myrsloik, would you consider extending clip.format with min and max (or minval/maxval)? 2**clip.format.bits_per_sample-1 works for integer formats, though ugly, but that should be 1.0 for floats. Making it generic would be even uglier, like:
maxval=2**clip.format.bits_per_sample-1 if clip.format.sampletype==vs.INTEGER else 1.0

[foxyshadis]

I've made a new page for the community to list AviSynth equivalents to ease the transition to VS: https://github.com/vapoursynth/vapou...th-Equivalents

Hopefully this will keep others from banging their head as much as I did on the path to enlightenment. Also helps me, since I'm so forgetful.

[Myrsloik]

I guess I could add a function for it but it's actually a bit more complicated. For floating point it also depends on the plane and format. I'll think about it a bit because it definitely could be useful to have in many scripts.

And when you write about function equivalents, don't always assume Lut is faster than expr. The jit compilation in r28 gives a huge speedup.

[foxyshadis]

Originally Posted by Myrsloik

I guess I could add a function for it but it's actually a bit more complicated. For floating point it also depends on the plane and format. I'll think about it a bit because it definitely could be useful to have in many scripts.

And when you write about function equivalents, don't always assume Lut is faster than expr. The jit compilation in r28 gives a huge speedup.

Didn't know that, nice. Even then I was going to edit it to say that it'd only be useful for 8-bit, since memory bandwidth on most luts is likely to be a much bigger speed-killer, unless it's a very expensive expression.

[DarkSpace]

For the integer formats, will your min/max values handle limited/full/custom ranges, too?

[Myrsloik]

Originally Posted by DarkSpace

For the integer formats, will your min/max values handle limited/full/custom ranges, too?

Don't go there. Limited/full range is a frame property so that's per frame. There's a reason I didn't add a simple function. It's not simple at all. Ever.

[Myrsloik]

Behold R28 RC1. No more changes planned unless a serious bug is found. Most of the performance regression relative to R27 should be fixed.

All R28 changes:

r28:
the installer will now download and install the vs2013 and vs2015 runtimes if needed
now uses python 3.5
fixed vdecimate parallel mode
pow is now accepted in expr expressions
expr now accepts up to 26 inputs (x-z, a-w)
expr now has runtime code generation on x86 cpus using jitasm
now normalizes the framerate returned from avisynth filters
it is now a fatal error to set the videoinfo of a filter to a non-normalized framerate
added a few more checks for proper api usage
get_core() can now be used in callbacks and other external functions in python
now returns an error message saying that windows needs to be updated in certain cases when plugin loading fails
fixed loop filter (nodame)
lut and lut2 can now output float as well
now accepts scripts that start with a BOM as well
fixed an image corruption bug with 9-16 bit input to rgvs when the c++ code is used
fixed division by zero issues in muldivrational in vshelper.h
blankclip can now create 0 (unknown/variable) fps clips
added float support to planedifference and planeaverage
added half support to addborders
relevant compile time options are now in the version string

[Myrsloik]

Look at me! I'm multitasking! I can argue on the interweb and release stuff at once! R28 is ready. Prepare to have FATAL ERRORS IN YOUR NIGHTMARES!

The usual summary blog of interesting changes. Full changelog in the first post as usual.

[mawen1250]

core.resize in R28 returns "Warning: data is not aligned! This can lead to a speedloss" in command line.

[jackoneill]

Originally Posted by mawen1250

core.resize in R28 returns "Warning: data is not aligned! This can lead to a speedloss" in command line.

It always (?) does that. You shouldn't use it anyway. zimg now has a drop-in replacement all-in-one filter.

[Myrsloik]

Originally Posted by mawen1250

core.resize in R28 returns "Warning: data is not aligned! This can lead to a speedloss" in command line.

That's very odd. All buffers should be aligned. I'll have to figure out why that happens.

[NailBomber]

Is there currently a way to get frame data out of video and write it into an image? Something like using clip.get_frame() then writing it with opencv?

[Myrsloik]

Originally Posted by NailBomber

Is there currently a way to get frame data out of video and write it into an image? Something like using clip.get_frame() then writing it with opencv?

If you want it written as text you can simply use FrameProps to print the relevant ones.

[TurboPascal7]

Originally Posted by NailBomber

Is there currently a way to get frame data out of video and write it into an image? Something like using clip.get_frame() then writing it with opencv?

src = core.ffms2.Source(...)
src = core.resize.Bicubic(src, format=vs.RGB24)

planes_count = src.format.num_planes
for x in range(10):
    frame = src.get_frame(x)
    image = cv2.merge([np.array(frame.get_read_array(i), copy=False) for i in reversed(range(planes_count))])
    cv2.imshow("", image)  # or something like cv2.imwrite("{0}.png".format(x), image) if you want it saved
    cv2.waitKey(0)

Something like this works for now (converted to rgb because working with subsampled formats in opencv is all kinds of painful). Basically you use get_read_array to get the raw bytes, convert them to numpy arrays and then do whatever you want with them.

[NailBomber]

Myrsloik, sorry, I meant the frame itself.

Thank you, TurboPascal7.

[splinter98]

Originally Posted by TurboPascal7

src = core.ffms2.Source(...)
src = core.resize.Bicubic(src, format=vs.RGB24)

planes_count = src.format.num_planes
for x in range(10):
    frame = src.get_frame(x)
    image = cv2.merge([np.array(frame.get_read_array(i), copy=False) for i in reversed(range(planes_count))])
    cv2.imshow("", image)  # or something like cv2.imwrite("{0}.png".format(x), image) if you want it saved
    cv2.waitKey(0)

Something like this works for now (converted to rgb because working with subsampled formats in opencv is all kinds of painful). Basically you use get_read_array to get the raw bytes, convert them to numpy arrays and then do whatever you want with them.

Don't forget if you just want to write out the video as a series of images, then imwri is likley to be faster. (If you want to then go on and do some other processing then yes the way TurboPascal7 has suggested is the way to go about it.)

Also if you then want to go about editing the images, you need to do:

src = core.ffms2.Source(...)
src = core.resize.Bicubic(src, format=vs.RGB24)

planes_count = src.format.num_planes
for x in range(10):
    frame = src.get_frame(x)
    image = cv2.merge([np.array(frame.copy().get_write_array(i), copy=False) for i in reversed(range(planes_count))])
    cv2.imshow("", image)  # or something like cv2.imwrite("{0}.png".format(x), image) if you want it saved
    cv2.waitKey(0)

[mawen1250]

For GRAY and YUV mask (haven't tested RGB), with first_plane=True, std.MaskedMerge will unexpectedly change the color. Probably because it clamps the UV mask to limited range.
I found this issue when trying to use AssVapour since the clipa and clipb are very different under this case.