z.lib resizers for AviSynth+

[Stephen R. Savage]

z_ConvertFormat(
clip clip,
int "width",
int "height",
str "pixel_type",
str "colorspace_op",
str "chromaloc_op",
bool "interlaced",
float "src_left",
float "src_top",
float "src_width",
float "src_height",
str "resample_filter",
float "filter_param_a",
float "filter_param_b",
str "resample_filter_uv",
float "filter_param_a_uv",
float "filter_param_b_uv",
str "dither_type")

width: output width in pixels
height: output height in pixels
pixel_type: output pixel type ("YV12", "YUV420P16", etc.)
colorspace_op: colorspace operation description
Format is
"matS[:transS[:primS[:rangeS]]]=>matD[:transD[:primD[:rangeD]]]"
Example JPEG to MPEG: "170m:709:709:f=>709:709:709:l"
chromaloc_op: chroma location operation description
Format is "[locS]=>[locD]"
Example JPEG to MPEG2: "center=>left"
interlaced: whether to use interlaced mode (default: false)
resample_filter: resampling mode
filter_param_a: first parameter to resampler
filter_param_b: second parameter to resampler
Example Bicubic (Mitchell-Netravali):
resample_filter="bicubic", filter_param_a=0.333, filter_param_b=0.333
Example 4-tap Lanczos: resample_filter="lanczos", filter_param_a=4
resample_filter_uv: resampling mode for chroma
filter_param_a_uv: first parameter to chroma resampler
filter_param_b_uv: second parameter to chroma resampler
dither_type: dithering type

See VapourSynth documentation for valid string constants.

Also has all the AviSynth resizers, but with "z_" prefix.

Download: r2 (https://www.sendspace.com/file/h4lmxg)

[Reel.Deel]

Thanks twc, are you planning on adding support for colorspace and bit depth conversions?

[pinterf]

Thanks, I will look try it later it when I have time, just looked at the source.

A remark: Planar RGB plane order is PLANAR_G, PLANAR_B, PLANAR_R
Question: AVS+ default alignment is 32. Is the 64 byte alignment is a requirement for zimg?

[wonkey_monkey]

Just curious, but what does "z.lib" refer to in this context? It's too close to zlib to Google for it...

[Reel.Deel]

Just curious, but what does "z.lib" refer to in this context? It's too close to zlib to Google for it...

See here: https://github.com/sekrit-twc/zimg#zlib

[TheFluff]

I'm pretty sure he named it that just to be obnoxious. It's what he does.

[filler56789]

I'm pretty sure he named it that just to be obnoxious. It's what he does.

lol LoL LOL

http://forum.videohelp.com/attachments/37296-1465229588/003.jpeg http://forum.videohelp.com/attachments/37295-1465229580/002.jpeg http://forum.videohelp.com/attachments/37302-1465229635/009.jpeg

[MysteryX]

Does this provide 16-bit support for AviSynth+?

[Sparktank]

Any updates on this?

[Sparktank]

Is there any update needed?

I wouldn't know if it needs updating or not, so I was asking.

[Sparktank]

Does any of this have to do with Zimg?
Zimg is getting a lot of updates.
And the documentation for this is lazy. I find things better looking at source code.

ZIMG is getting a lot of updates. This isn't getting anything.
https://github.com/sekrit-twc/zimg

Would it be better to ask Pinterf to make a port? Or even cretindesalpes?

Open source is nice. But only for those who know what it means.

Why is ZIMG getting more updates than this very small port?
The doc really says nothing. I only learn from looking at the source code and guessing.


Does the AVS+ port mean nothing?
I'll stick to Dither_tools until AVS+ really improves on these functions.

[TheFluff]

It's an Avisynth plugin that uses the zimg resizers, yes, but since nobody seemed interested in it I doubt it'll ever get updated again. Just use the Vapoursynth version instead; there's no reason to use Avisynth anymore since the new avsproxy plugin (https://forum.doom9.org/showthread.php?t=175141) lets you load even ancient no-source 32-bit Avisynth plugins in a 64-bit Vapoursynth process, or run Avisynth scripts if that's a thing you need.

[real.finder]

It's an Avisynth plugin that uses the zimg resizers, yes, but since nobody seemed interested in it I doubt it'll ever get updated again. Just use the Vapoursynth version instead; there's no reason to use Avisynth anymore since the new avsproxy plugin (https://forum.doom9.org/showthread.php?t=175141) lets you load even ancient no-source 32-bit Avisynth plugins in a 64-bit Vapoursynth process, or run Avisynth scripts if that's a thing you need.

what is the difference between avsproxy and MP_Pipeline?

[edcrfv94]

what is the difference between avsproxy and MP_Pipeline?

MP_Pipeline can not export clip to VapourSynth and pass it back.

[Stephen R. Savage]

Since it came up in the main AviSynth+ thread, I updated the first post with a new build. It has an updated version of z.lib.

[pinterf]

Since it came up in the main AviSynth+ thread, I updated the first post with a new build. It has an updated version of z.lib.
Speedwise much better on my i7-7770. I guess it's really not much time is spent in resizers in complex scripts but I definitely like the art of optimization.

[pinterf]

Something strange happens.
When resizing vertically performance suddenly drops at delta=256.
Using avsresize r1b, x64, Intel i7-7700, current dev avs+ x64
w = 1920
h = 1920
BlankClip(width=w, height=h, length=8000, pixel_type = "YUV444P8")
#z_Spline64Resize(w,h+255) # 192.5 fps
z_Spline64Resize(w,h+256) #30 fps

[Stephen R. Savage]

You managed to find an obscure bug in z.lib. I updated first post with a new build (z.lib 2.7.3).

[videoh]

These conversions seem extremely slow compared to the Vapoursynth core equivalents. Really, it is too slow to be usable. Here is the script:

dgsource("THE GREAT WALL.dgi",fulldepth=true)
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")
#tonemap()
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(8)

For a typical clip, this takes 45 seconds while the corresponding Vapoursynth script takes 13 seconds.

Is there any way to speed things up or do we have to declare Avisynth+ dead for things like this?

MAGA (Make Avisynth Great Again)

[pinterf]

These conversions seem extremely slow compared to the Vapoursynth core equivalents. Really, it is too slow to be usable. Here is the script:

dgsource("THE GREAT WALL.dgi",fulldepth=true)
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")
#tonemap()
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(8)

For a typical clip, this takes 45 seconds while the corresponding Vapoursynth script takes 13 seconds.

Is there any way to speed things up or do we have to declare Avisynth+ dead for things like this?

MAGA (Make Avisynth Great Again)
The functions - I think - are not autoregistering their MT modes for Avs+. Try using SetFilterMTMode avs+ function, probably they are MT_NICE_FILTER compatible but at least good for MT_MULTI_INSTANCE.

[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/vapoursynth/blob/master/src/avisynth/avisynth_compat.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 (https://forum.doom9.org/showthread.php?t=175279).

[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]

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]

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]

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]

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.

[videoh]

No comment on the source filter handling penalty? That appears more serious than the avsresize slowness.

[videoh]

How about avsmeter diagnostics ? Can't work with Vapoursynth, so comparison would not be possible.

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. Prefetch 4 or 8 made no difference. Anyway, if users are forced to tweak things like this then it is just braindead, IMHO.

Can you double check some other measurement tools? maybe vspipe to ffmpeg, vs. avs to ffmpeg for example . Never used those and don't see the relevance.

[videoh]

I want to demonstrate the source filter handling penalty of Avisynth+. Recall that the same DGSource executable is used by both Vapoursynth and Avisynth+. Here are the two scripts:

Vapoursynth:

import vapoursynth as vs
core = vs.get_core()

core.avs.LoadPlugin(path="D:/Don/Programming/C++/DGDecNV/DGDecodeNV/x64/release/DGDecodeNV.dll")
video = core.avs.DGSource('THE GREAT WALL.dgi',fulldepth=True)
video=core.std.AssumeFPS(video,fpsnum=1000, fpsden=1)
video.set_output()

Avisynth+:

loadplugin("d:\don\Programming\C++\dgdecnv\DGDecodeNV\x64\release\dgdecodenv.dll")
SetFilterMTMode("DGSource", MT_MULTI_INSTANCE)
dgsource("THE GREAT WALL.dgi",fulldepth=true)
assumefps(1000.0)
prefetch(8)

Results playing in VirtualDub2:

Vapoursynth: 6 seconds
Avisynth+: 12 seconds

If I remove the prefetch then Avisynth+ finishes in 7 seconds. But that will disable multithreading for anything else in the script.

This together with the inefficient conversions makes Avisynth+ unusable for me. I remind of the overall result for the simple process of tonemapping a UHD stream:

Vapoursynth: 13 seconds
Avisynth+ with avsresize: 45 seconds

Which one do you think a sensible person would use?

[TheFluff]

As much as I approve of demonstrating the superiority of Vapoursynth, I really don't think setting a source filter to MT_MULTI_INSTANCE is a good idea. MT_SERIALIZED forces everything upstream of the filter to be synchronous and single threaded, but source filters have no upstream so it doesn't matter. VS source filters tend to be serial in nature too.

[Stephen R. Savage]

It is because the avsresize was never tested with gamma function operations. It is missing this statement from the VS z.lib filter that enables certain speed-ups:


vsresize.cpp:L683: m_params.allow_approximate_gamma = 1;

[videoh]

As much as I approve of demonstrating the superiority of Vapoursynth, I really don't think setting a source filter to MT_MULTI_INSTANCE is a good idea. MT_SERIALIZED forces everything upstream of the filter to be synchronous and single threaded, but source filters have no upstream so it doesn't matter. VS source filters tend to be serial in nature too. I'm sure you're right, but the setting doesn't seem to have any effect at all. I'm not familiar with Vapoursynth internals. ;)

[poisondeathray]

You would expect prefetch(2) should be faster in that script

For the src filter threading issue, it did not affect the old avisynth(-) mt (at least no reports as bad as this) - what is different about the threading model here in avisynth(+) ?

[videoh]

It is because the avsresize was never tested with gamma function operations. It is missing this statement from the VS z.lib filter that enables certain speed-ups:


vsresize.cpp:L683: m_params.allow_approximate_gamma = 1;
Thanks, I will try adding that. Of course, that may remove one penalty but not the source filter penalty.

[videoh]

It is because the avsresize was never tested with gamma function operations. It is missing this statement from the VS z.lib filter that enables certain speed-ups:


vsresize.cpp:L683: m_params.allow_approximate_gamma = 1;
Bravo Stephen! With that change, avsresize performance is the same as Vapoursynth. Will you release an update with this change?

Now let's try to figure out the second issue.

[poisondeathray]

For the src filter issue - it doesn't appear to be a GPU latency /transfer issue, because avs+ prefetch(4) incurs no significant penalty with dss/dss2 cuvid