Vapoursynth

[Jukus]

Thanks for answers.

Originally Posted by _Al_

anyway, but do not cut some lines and resize back to the same number, that is nasty

You mean it's a hoax?
Some people think that the resolution of the image should necessarily be multiples of 8 or even 16.
There are also hardware players that do not understand the non-standard resolution, anamorph.

[_Al_]

There is copping scripts, tutorials, calculators included, etc., on web since era of digital video started, especially at the beginning everyone was cropping like they'd get candy each time they did that. And those scripts and advises are still out there.
About mod, take a major HD resolution dimension 1080 that does not even qualify for mod 16.
If there is a filter that needs mod 8 or 16 you go with it otherwise there is no reason to change video to get to that mod. What I meant with those 2 pixels black strips, just leave it there (if it is an top or bottom). Maybe the best advice is going with basics for DVD, you see black stripes on sides crop them , total 16 pixels left and right, then resize to 16:9 to 854x480. At this point if those black stripes bother you, you can crop them, but that I'd do only if having letterbox, not some 2 pixels.

[Jukus]

@_AI_
Likely, people look at x264 log and see there "magic blocks of pixels"
...
[libx264 @ 0x55565ecbfd80] mb I I16..4: 10.1% 74.9% 14.9%
[libx264 @ 0x55565ecbfd80] mb P I16..4: 2.2% 9.2% 1.0% P16..4: 52.0% 17.5% 13.3% 0.5% 0.2% skip: 4.0%
[libx264 @ 0x55565ecbfd80] mb B I16..4: 0.1% 0.4% 0.0% B16..8: 42.9% 5.1% 1.0% direct: 2.7% skip:47.8% L0:36.5% L1:46.9% BI:16.6%
[libx264 @ 0x55565ecbfd80] 8x8 transform intra:73.7% inter:70.4%
...
[libx264 @ 0x55565ecbfd80] i16 v,h,dc,p: 11% 6% 3% 80%
[libx264 @ 0x55565ecbfd80] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 8% 4% 9% 15% 14% 16% 13% 13%
[libx264 @ 0x55565ecbfd80] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 7% 3% 8% 16% 15% 15% 12% 12%
[libx264 @ 0x55565ecbfd80] i8c dc,h,v,p: 30% 25% 19% 26%

[Jukus]

How to write an analog of that code for VS?

interp = nnedi3(field=0, qual=2)
deint = YadifMod(order=0, edeint=interp)
TFM(order=0, mode=3, clip2=deint, slow=2).TDecimate(hybrid=1)

[ChaosKing]

Originally Posted by Jukus

How to write an analog of that code for VS?

interp = nnedi3(field=0, qual=2)
deint = YadifMod(order=0, edeint=interp)
TFM(order=0, mode=3, clip2=deint, slow=2).TDecimate(hybrid=1)

clip = your source
interp = core.nnedi3.nnedi3(clip, field=0, qual=2)
deint = core.yadifmod.Yadifmod(clip, order=0, edeint=interp)
clip = clip.vivtc.VFM(order=0, mode=3, clip2=deint).vivtc.VDecimate()

There's no hybrid=1 parameter in VDecimate().

[stax76]

Hello Myrsloik, I've some questions...

Is there some documentation or sample code for DLL discovery and loading?

I've looked at the nvenc code and it is using Run-Time Dynamic Linking, I don't know if it relies on VS being in Path or if it searches the VS location in the registry and modifies the Path env var of the process.

vspipe appears to do Load-Time Dynamic Linking, discovery and manual loading is not necessary because the DLLs are located in the same directory.

Do all setup variants add VS to the Path env var and apps can rely on that?

Do all setup variants register the VS location in the registry? If so which key(s)?

I believe Load-Time Dynamic Linking is possible and preferred, I'm mostly unsure about path discovery.

[ChaosKing]

Originally Posted by stax76

Do all setup variants add VS to the Path env var and apps can rely on that?

Do all setup variants register the VS location in the registry? If so which key(s)?

Yes, see https://github.com/vapoursynth/vapou...aller.iss#L142

Since VS was split in global and user installation variants we need to check 4 reg paths:
CurrentUser / LocalMachine => "SOFTWARE\VapourSynth-32" and "SOFTWARE\VapourSynth"

[stax76]

Thanks, might somebody have done this before with C++ and Win32? I'm very clumsy with that...

[Myrsloik]

Originally Posted by stax76

Hello Myrsloik, I've some questions...

Is there some documentation or sample code for DLL discovery and loading?

Do all setup variants add VS to the Path env var and apps can rely on that?

Do all setup variants register the VS location in the registry? If so which key(s)?

I believe Load-Time Dynamic Linking is possible and preferred, I'm mostly unsure about path discovery.

Is there some documentation or sample code for DLL discovery and loading?
No. You read the location you need from the registry. HKLM/HKCU (depends on current user install mode) and then software\vapoursynth (or vapoursynth-32 for poor people) and the keys of interest are called VSScriptDLL and VapourSynthDLL. Simply use loadlibrary and call vsscript_getVSApi2() or getVapourSynthAPI() depending on which dll you use.

Do all setup variants add VS to the Path env var and apps can rely on that?
No. It's a user option and you can never depend on this.

Do all setup variants register the VS location in the registry? If so which key(s)?
Yes, see above. I guess portable doesn't but that's hardly a setup variant...

[stax76]

Made some simple wrapper library for AviSynth and VapourSynth, it was necessary because AviSynth has no C or COM interface...

https://github.com/staxrip/staxrip/t...er/FrameServer

https://github.com/staxrip/staxrip/b...FrameServer.vb

https://github.com/staxrip/staxrip/b...deoRenderer.vb

[amichaelt]

Originally Posted by stax76

it was necessary because AviSynth has no C or COM interface...

What about avisynth_c.h?

[stax76]

I don't know, maybe I should try it, sample code would help. When I started the library I didn't know a lot about C/C++ (last project more than 10 years ago) and AviSynth, after completing it I know a little more. With the AviSynth part I had few issues, no problems with VapourSynth.

[DJATOM]

The way you're using frame fetching in VS is inefficient. In general you have to care about async frame requests on your end, otherwise it works like a single-threaded frameserver.

[Myrsloik]

Originally Posted by amichaelt

What about avisynth_c.h?

Using the avisynth C api is really iffy. If all you want is to evaluate a script and get frames out then writing your own C++ wrapper dll will be so much more reliable and also faster. Believe me, I've tried both ways long ago when developing yatta.

VapourSynth has a very straightforward C-api in comparison.

[_Al_]

If trying to modify props and clip resolution is ridiculously small, it crashes, where no recovery is possible, it locks a PC.

rgb  = core.std.BlankClip(width=30, height=16, format=vs.RGB24)
rgb2 = rgb.std.PlaneStats(prop='PlaneStats')
PROP_NAME  = f'New_string_name_here'
def copy_prop(n,f):
   f_out = f[0].copy()
   f_out.props[PROP_NAME] = '{:.1f}'.format(f[1].props['PlaneStatsAverage']*100)
   return f_out
rgb = core.std.ModifyFrame(rgb, [rgb, rgb2], copy_prop)

[stax76]

Originally Posted by DJATOM

The way you're using frame fetching in VS is inefficient. In general you have to care about async frame requests on your end, otherwise it works like a single-threaded frameserver.

For a GUI like staxrip it's totally fine, it's not used for encoding but only to access parameters and for a basic crop and preview dialog that doesn't support playback and HDR color handling but has mpv/mpc integration to take care of this. The GDI based WinForms rendering was ridiculously slow but it was addressed with a hardware accelerated Direct2D replacement. It does a vertical flip and converts to RGB32 in software via avs/vs. For best possible performance vertical flip and YV12 could be handled by Direct3D and like you told frames could be accessed asynchronously.

[Myrsloik]

Originally Posted by _Al_

If trying to modify props and clip resolution is ridiculously small, it crashes, where no recovery is possible, it locks a PC.

rgb  = core.std.BlankClip(width=30, height=16, format=vs.RGB24)
rgb2 = rgb.std.PlaneStats(prop='PlaneStats')
PROP_NAME  = f'New_string_name_here'
def copy_prop(n,f):
   f_out = f[0].copy()
   f_out.props[PROP_NAME] = '{:.1f}'.format(f[1].props['PlaneStatsAverage']*100)
   return f_out
rgb = core.std.ModifyFrame(rgb, [rgb, rgb2], copy_prop)

I can't reproduce this and need more information. CPU? OS? Number of threads? Does it happen every time?

[Myrsloik]

R49-RC1 is now available. All maintenance this time since I'm slowly working on the separate audio build.

Changes:

r49:
updated to python 3.8 on windows
updated visual studio 2019 runtime version
updated zimg and added support for spline64 resize method
fixed a savestring bug in avscompat (sekrit-twc)
interleave, selectevery and separate fields now have a modify_duration argument to determine if they modify frame durations and fps
addborders and crop now update the _fieldbased attribute properly when an odd number of lines are cut from the top
fixed add to path not working for single user installs
fixed compilation on non-x86 systems
fixed an infinite loop in the expr filter optimizer that was introduced in r48 (sekrit-twc)

[lansing]

I don't know if this is a bug from vapoursynth or KNLMeansCL. KNLMeansCL requires input clip to be YUV444P10, but it still complains about it when I converted my clip to YUV444P10.

clip = core.resize.Bicubic(clip, format=vs.YUV444P10)
clip = core.knlm.KNLMeansCL(clip)

But then it works when I convert it to YUV444P8

[Selur]

@lansing: read https://github.com/Khanattila/KNLMeansCL/issues/42