z.lib resizers for AviSynth+

[videoh]

Thanks for your reply.

MT_NICE_FILTER crashes, and MT_MULTI_INSTANCE is as slow as not declaring the mode.

[videoh]

zimg is used in Vapoursynth so we can't blame this on zimg. Is it just the case that Avisynth+ multithreading is terminally deficient? Or is there some heavy penalty for not having the resizing in the core? Or both? If anyone cares about Avisynth+ there will have to be an answer and resolution.

[pinterf]

Try eliminating dgsource for speed tests.

[videoh]

Huh? The same DGSource() executable is used for both Avisynth+ and Vapoursynth testing.

Vapoursynth: 13 seconds
Avisynth+ with z.lib: 45 seconds

[pinterf]

I was asking you for benchmarks w/o dgsource (e.g. using a BlankClip instead) because Avisynth+ runs source filters in MT_SERIALIZED mode.
I don't know how it works in VapourSynth but that can be a difference, which could be eliminated by omitting source filter.
When a source filter would benefit from a specific MT mode, you have to set it for that specific filter manually. It would show then that DgSource with MT_SERIALIZED mode is bottleneck or not.

[videoh]

DGSource runs fine in MT_MULTI_INSTANCE but it makes no difference. I'll try with blank clip.

[DJATOM]

DGSource is actually handled as source filter inside VS's avisynth wrapper: https://github.com/vapoursynth/vapou...ompat.cpp#L378, so it should not be a bottleneck for tests.

[videoh]

With BlankClip (specifying 10000 frames at 1000 fps and playing in VirtualDub2, just the format conversions):

Vapoursynth 14 sec
Avisynth+ 22 sec

The difference is not as large but is still quite significant. So there is a pure penalty in the conversions and another penalty in the handling of the source filter.

Setting DGSource MT_NICE_FILTER or MT_MULTI_INSTANCE makes no difference (DGSource is actually thread safe and CUVID supports multiple instances). So why does Vapoursynth apparently not suffer these penalties while Avisynth+ does? I tried a large value in SetMemoryMax() but again it made no difference.

Don't get me wrong; I've been a stalwart supporter of Avisynth(+) since year 2000 and have greatly appreciated your efforts along with everyone else. I just want to be able to continue using it in the UHD world.

MAGA (Make Avisynth Great Again)

[jpsdr]

Are the speed test results from playing the same avs script in Avs+ and Vapoursynth, or, is it the avs script using z.lib vs Vapoursynth using internal conversion ?
If it's the second case, one possible explaination would be that the conversion is just faster in Vapoursynth than z.lib.
You're not alone thinking z.lib conversion is slow, also here.

[videoh]

Interesting, thanks for that confirmation.

It's the second case, of course. But avsresize (z.lib) is basically just a wrapper around zimg, and zimg is used by Vapoursynth. The difference I guess is in invoking it in the core versus an external filter. Hopefully pinterf can shed some light on things for us. zimg could be added to the Avisynth+ core. Things take time, it's not a surprise.

[Myrsloik]

Originally Posted by videoh

Interesting, thanks for that confirmation.

It's the second case, of course. But avsresize (z.lib) is basically just a wrapper around zimg, and zimg is used by Vapoursynth. The difference I guess is in invoking it in the core versus an external filter. Hopefully pinterf can shed some light on things for us. zimg could be added to the Avisynth+ core. Things take time, it's not a surprise.

Nope, no "core" magic there. It's just an internal plugin and nothing more. No secrets.

[videoh]

Seems that Avisynth has reached end of life, but what do I know?

[jpsdr]

Is the actual build of z.lib up to date with the zimg version ? Does Vapoursynth and this z.lib use the same zimg version ?

[videoh]

I rebuilt avsresize with the the latest version of zimg:

https://github.com/sekrit-twc/zimg

[poisondeathray]

Were those observations based on your rebuilt avsresize, or "avsresize-r1c" provided in the 1st post ? or same results ?

[real.finder]

Originally Posted by videoh

Seems that Avisynth has reached end of life, but what do I know?

you say that just because one filter run faster in vs?! there are another cases that avs is faster like https://github.com/Khanattila/KNLMeansCL/wiki/Benchmark

I think there are something in avsresize dll that case that slowness

[gonca]

Apart from the fact that the benchmark is for 1080p, and not 4K as is being discussed, it actually shows that vpy can handle formats, channels and precisions that avs can't

[videoh]

Originally Posted by poisondeathray

Were those observations based on your rebuilt avsresize, or "avsresize-r1c" provided in the 1st post ? or same results ?

Results are the same for both.

[poisondeathray]

How about avsmeter diagnostics ? changing prefetch values ? - check memory / cpu usage etc... is "prefetch(8)" the "best" number in that situation ? Personally I like the auto threading of vpy better.

Can you double check some other measurement tools? maybe vspipe to ffmpeg, vs. avs to ffmpeg for example .

I'll try to compare some other operations in avs vs. vpy tomorrow for z.lib/zimg , if sekrit-twc / s.savage doesn't post by then

[pinterf]

Originally Posted by videoh

With BlankClip (specifying 10000 frames at 1000 fps and playing in VirtualDub2, just the format conversions):

Vapoursynth 14 sec
Avisynth+ 22 sec

The difference is not as large but is still quite significant. So there is a pure penalty in the conversions and another penalty in the handling of the source filter.

Setting DGSource MT_NICE_FILTER or MT_MULTI_INSTANCE makes no difference (DGSource is actually thread safe and CUVID supports multiple instances). So why does Vapoursynth apparently not suffer these penalties while Avisynth+ does? I tried a large value in SetMemoryMax() but again it made no difference.

Don't get me wrong; I've been a stalwart supporter of Avisynth(+) since year 2000 and have greatly appreciated your efforts along with everyone else. I just want to be able to continue using it in the UHD world.

MAGA (Make Avisynth Great Again)

Thanks, the difference is still big, worth investigating when I have time.