z.lib resizers for AviSynth+

[videoh]

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(+) ? I ran the entire HDR->SDR process again with the avsresize fix. Here is the script:

loadplugin("d:\don\Programming\C++\dgdecnv\DGDecodeNV\x64\release\dgdecodenv.dll")
loadplugin("D:\Don\Programming\C++\Avisynth filters\ToneMap float\x64\release\tonemap.dll")
loadplugin("D:\Don\Programming\C++\avsresize-r1c\x64\release\avsresize.dll")
SetFilterMTMode("z_ConvertFormat", MT_MULTI_INSTANCE)
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="YV12",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(2)
The overall performance is now the same as Vapoursynth!

The prefetch number didn't affect the timing but value 2 made things smooth and 8 made it go in stops and starts.

So, hey, Avisynth+ lives on. :eek: but :)

[videoh]

I'll release an Avisynth+ port of Phillip Blucas's tonemap filter within a few days (with some performance improvements). Then there will be a full HDR->SDR solution for Avisynth+.

It's close to being realtime for UHD (22fps on my machine) when playing in VirtualDub2. It would be nice if we could squeeze a little more performance out of zimg (or port equivalent conversions to CUDA).

[Sharc]

so, hey, avisynth+ lives on. :eek: But :)
oh happy day :)

[TheFluff]

Setting the source filter to MT_MULTI_INSTANCE with prefetch(2) is functionally much like doing something like

src1 = dgsource("file.dgi")
src2 = dgsource("file.dgi")
interleave(src1.selecteven(), src2.selectodd())


So if you have too many instances you'll start trashing the disk because you'll have many threads reading from the same file. Depending on the filter chain, it may or may not be beneficial to do this. You'll get as many instances as you have threads whether you want to or not. On the other hand if the source filter is MT_SERIALIZED there'll only be one instance of it and it'll only process one frame request at a time, but other filters that are requesting frames from it may run in parallel in various ways. The requesting thread will always block and wait for the request to complete though because that's just how the API is designed.

In VS, all Avisynth filters are always run single threaded and in a single instance, but VS attempts to fit them into its nonblocking frame request framework as well as it can, and it will also automatically attempt to request frames from source filters linearly in order. I'd expect it to run most source filters slightly faster than Avs+ would with MT_SERIALIZED.

I wrote a very long and boring attempt to explain the differences between the concurrency models here (https://forum.doom9.org/showthread.php?t=174437) a while ago.

[videoh]

Thanks for that explanation. I tried to read your link some time ago, but I fell asleep. :p

Is there anything to be gained by making a Vapoursynth-native version of DGSource()?

[TheFluff]

For a source filter I don’t think there’s anything significant to gain performance-wise, no. Not sure about how complete the VS compatibility layer is in terms of various exotic colorspaces and/or bitdepths though.

[DJATOM]

Thanks for that explanation. I tried to read your link some time ago, but I fell asleep. :p

Is there anything to be gained by making a Vapoursynth-native version of DGSource()?

Yes. Autoloading is great!

[videoh]

For a source filter I don’t think there’s anything significant to gain performance-wise, no. Not sure about how complete the VS compatibility layer is in terms of various exotic colorspaces and/or bitdepths though. Thank you. All I need is YUV420P016 and that is covered now.

[videoh]

Yes. Autoloading is great! Alrighty then, I'll do it. Actually I already have it from a while ago, just have to add a few fixes that flowed under the bridge since then.

[videoh]

Please give the script that plays that fast for UHD content (3840x2160 16-bit). Just to be clear, I am talking about playing the script in VitualDub2.

Will you release a fixed avsresize so I don't have to include one? Thanks.

[pinterf]

Thanks. Now it's fast!

But now it seems that probably the VS integration would be better (compiler optimization?), surely it's not an MT issue, even the single-threaded case is slower a bit.
Provided my two scripts are comparable, please note if it's not the case.

(Win10, i7-7700)
Avs+ r2636
Avsmeter64: 264 fps (was: 41fps with r1c)
Avsmeter64: (thread=1, no prefetch): 90 fps

VapourSynth r43
VSEdit r18 Benchmark: 217 fps
VSEdit r18 Benchmark: (threads=1): 83 fps

VirtualDub2 r41462 (Direct Stream Copy, switched off input/output preview):
avs+: 172 fps (37fps with r1c)
vs r43: 150 fps

Passing a YUV420P16 clip to Virtualdub2 runs through a P016 conversion - both at VapourSynth and Avisynth+ -, and possibly VDub2 makes further copy/conversions which are extra overhead.
I was using this script to find the slowness before your r1d patch:
BlankClip(10000,1920,1080,"YUV420P8")
z_ConvertFormat(resample_filter="bicubic", pixel_type="RGBPS",colorspace_op="709:709:709:l=>rgb:linear:2020:l", dither_type="none") # r1c: slooooow, r1d: faaast
z_ConvertFormat(resample_filter="bicubic", pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(4)


import vapoursynth as vs
core = vs.get_core(threads=4)
clip = core.std.BlankClip(width=1920, height=1080, length=10000, color=[0, 128, 128], format=vs.YUV420P8)
clip = core.resize.Bicubic(clip=clip, format=vs.RGBS, matrix_s="rgb", transfer_s="linear", primaries_s="2020", matrix_in_s="709", transfer_in_s="709", primaries_in_s="709", dither_type="none")
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P16, matrix_in_s="rgb", transfer_in_s="linear", primaries_in_s="2020", matrix_s="709", transfer_s="709", primaries_s="709", dither_type="ordered")
clip.set_output()

[jpsdr]

What is the difference between

z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")

and the BT.2020 convert implemented in avs+ ?

Is it related to the formula in REC-BT.2100 page 4 and 5 ?
Or is it something found only in SMTPE 2084 ?

[TheFluff]

What is the difference between

z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")

and the BT.2020 convert implemented in avs+ ?

Is it related to the formula in REC-BT.2100 page 4 and 5 ?
Or is it something found only in SMTPE 2084 ?
I dunno, does Avs+ even have linear RGB builtin? As far as I know the builtin Avs+ BT2020 conversion doesn't touch the gamma at all. The conversion you quoted is SMPTE 2084 to linear, and the zimg ST2084 transfer functions are in zimg/colorspace/gamma.cpp line 228 and onwards (https://github.com/sekrit-twc/zimg/blob/master/src/zimg/colorspace/gamma.cpp#L228).

zimg does support HLG too, but under the name ARIB B67, see zimg/colorspace/gamma.cpp line 154 and on (https://github.com/sekrit-twc/zimg/blob/master/src/zimg/colorspace/gamma.cpp#L154).

[videoh]

I updated the first post with a new build. Thank you!

[videoh]

Passing a YUV420P16 clip to Virtualdub2 runs through a P016 conversion I thought those two were the same thing. DGSource() delivers CS_YUV420P16. Why would there need to be any conversion?

[pinterf]

I thought those two were the same thing. DGSource() delivers CS_YUV420P16. Why would there need to be any conversion?
P016 is a semi-packed format which is needed for passing a YUV420P16 clip.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx
Similarly Y416 is used for passing a YUV444P16 clip through the VfW interface, VirtualDub is using.

[videoh]

I see, thank you. If there are spurious conversions inside Avisynth+ or Windows due to VfW maybe that is another reason to prefer Vapoursynth and native Vapoursynth filters. It seems insane to me to convert to an intermediate semi-packed format.

And thank you for your test results. Hopefully, Myrsloik will comment on your performance numbers.

[pinterf]

As at 8 bits, 10-16 bit formats are also negotiated through the Vfw interface, here (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/main.cpp#L1047). For YUV420P16 the fourcc code P016 is reported, this is what VirtualDub2 understands. This format is semi-packed one, Y "plane" is followed immediately wih UVUVUVUV.. data, so that pitch is the same as of the Y data. For YUV422P10 the P210 is used, but you have 2 more choices, such as V210 and Y3[10][10] fourcc codes. These other options can be set thought Avisynth+ OPT_xxx variables (http://avisynth.nl/index.php/Internal_functions#Global_Options), which should appear at the beginning of the scripts.
EDIT: this conversion is done once in the outputting stage, because VirtualDub2 works through VfW. The same interface and method is used by VapourSynth

[TheFluff]

Yeah, for VfW you need the packing unfortunately. VS also uses P016 for YUV420P16 when outputting through the VfW interface. If you're outputting through e.g. vspipe though, you can output whatever format you want.

[Myrsloik]

Yeah, for VfW you need the packing unfortunately. VS also uses P016 for YUV422P16 when outputting through the VfW interface. If you're outputting through e.g. vspipe though, you can output whatever format you want.

You shouldn't be using vfw, it's <current year>. It mostly exists for convenience, previews and backward compatibility. You're sacrificing a lot of threading by using vfw, do the right thing and use vspipe. Or avspipe or whatever...

[videoh]

Questions for Myrsloik:

1) I have made a version of DGDecodeNV that supports both native Avisynth and native Vapoursynth. Will we have to remove DGSource from your avscompat layer, or will Vapoursynth see the native version and use it even if the avscompat layer still has DGSource given as a source filter?

2) Any comment on pinterf's benchmarking showing Vapoursynth a bit slower?

[TheFluff]

It doesn't need to be removed, you can have (and use) both. VS plugins get their own namespaces so the same function name can exist in several different plugins that are loaded at the same time. That is, you can have both core.avs.DGSource() and core.dg.DGSource() in the same script, no problem. The AVS compat stuff is only used when loading plugins with core.avs.LoadPlugin.

You can't have two functions with the same name in the same plugin namespace though, so IIRC if you load an Avisynth plugin that uses overloaded functions (exports the same function more than once but with different argument signatures) in VS, the compat layer will de-conflict by renaming the functions, so you get e.g. func(), func_2(), func_3() etc.

[Myrsloik]

Question for Myrsloik: I have made a version of DGDecodeNV that supports both native Avisynth and native Vapoursynth. Will we have to remove DGSource from your avscompat layer, or will Vapoursynth see the native version and use it even if the avscompat layer still has DGSource given as a source filter?

Don't forget to mark the filter as fmUnordered and have the flag nfMakeLinear set. Will you export frametype information as well?

[poisondeathray]

2) Any comment on pinterf's benchmarking showing Vapoursynth a bit slower?

One difference might be blankclip . It's much faster in avisynth. Like 100x faster with 0% cpu usage , no overhead. You can set the length to 1000000 and it will finish instantaneously with blankclip only.

[Myrsloik]

One difference might be blankclip . It's much faster in avisynth. Like 100x faster with 0% cpu usage , no overhead. You can set the length to 1000000 and it will finish instantaneously with blankclip only.

Add keep=1 as an argument to vs blankclip to speed it up a lot. If you don't it creates a new frame every getframe call to avoid extreme memory bloat in some corner cases. Most people never notice the difference anyway until the benchmarks come out...

[videoh]

How do I "mark the filter as fmUnordered and have the flag nfMakeLinear set"?

Thank you.

[Myrsloik]

How do I "mark the filter as fmUnordered and have the flag nfMakeLinear set"?

Thank you.

You'll have a line with createfilter that looks something like this:
vsapi->createFilter(in, out, "DGSomething", init, getframe, free, fmUnordered, nfMakeLinear, data, core);

[poisondeathray]

Add keep=1 as an argument to vs blankclip to speed it up a lot. If you don't it creates a new frame every getframe call to avoid extreme memory bloat in some corner cases. Most people never notice the difference anyway until the benchmarks come out...

Yes, I tried that (I actually read the docs this time :) ) . You still don't get "ludicrous" speed

I think it might have to do with avsmeter64. If you send avs to a "real" encoding application , ffmpeg , vdub, x264, etc... you don't get those "instant" speeds when outputting null

This is why I suggested looking at other testing methodologies earlier - there are discrepancies between the methods and numbers, sometimes large

I like ffmpeg since it accepts both avs and vspipe. There still is a discrepancy with blankclip between avs and vpy . Avs is about 20% faster

[pinterf]

Add keep=1 as an argument to vs blankclip to speed it up a lot. If you don't it creates a new frame every getframe call to avoid extreme memory bloat in some corner cases. Most people never notice the difference anyway until the benchmarks come out...
Thanks, in this case keep=1 has practically no effect.

[Myrsloik]

Yes, I tried that (I actually read the docs this time :) ) . You still don't get "ludicrous" speed

I think it might have to do with avsmeter64. If you send avs to a "real" encoding application , ffmpeg , vdub, x264, etc... you don't get those "instant" speeds when outputting null

This is why I suggested looking at other testing methodologies earlier - there are discrepancies between the methods and numbers, sometimes large

I like ffmpeg since it accepts both avs and vspipe. There still is a discrepancy with blankclip between avs and vpy . Avs is about 20% faster

I sure hope you benchmarked this way:
vspipe script.vpy .

And at ludicrous speeds you basically end up benchmarking very irrelevant things, like the number of calls used for writing to stdout and nothing else.

[poisondeathray]

I sure hope you benchmarked this way:
vspipe script.vpy .

And at ludicrous speeds you basically end up benchmarking very irrelevant things, like the number of calls used for writing to stdout and nothing else.


Exactly! You want to measure the pipe speed before an actual encoding application . Because that is how it would be used in real usage scenario. IMO , that is more useful information


vspipe --y4m script.vpy - | ffmpeg -f yuv4mpegpipe -i - -an -f null NUL



ffmpeg -i script.avs -an -f null NUL

[videoh]

You'll have a line with createfilter that looks something like this:
vsapi->createFilter(in, out, "DGSomething", init, getframe, free, fmUnordered, nfMakeLinear, data, core); Thank you. nfMakeLinear is undefined. Do I need more recent headers?

Yes, I will export frame info.

Do I still need to do this:

muldivRational(&VI[0].fpsDen, &VI[0].fpsNum, 1, 1);

[Myrsloik]

You need newer headers and you still need to do that

[videoh]

Thanks. Working now.

[videoh]

What is the Vapoursynth equivalent of:

env->SetVar(env->Sprintf("%s", "FFPICT_TYPE"), static_cast<int>(ctype));

[Myrsloik]

What is the Vapoursynth equivalent of:

env->SetVar(env->Sprintf("%s", "FFPICT_TYPE"), static_cast<int>(ctype));

If the picture type is a single char you'd do something like this:
VSMap *Props = vsapi->getFramePropsRW(Dst);
vsapi->propSetData(Props, "_PictType", &Frame->PictType, 1, paReplace);


Note that many properties have standard names and types. See this part of ffms2 (https://github.com/FFMS/ffms2/blob/master/src/vapoursynth/vapoursource.cpp#L172) for hints.

[videoh]

Thanks.

[Myrsloik]

No properties are required but a list of what you should call some things if you do attach them is here (http://www.vapoursynth.com/doc/apireference.html#reserved-frame-properties). For example all the colorpsace stuff gets used by format conversions automatically then.

You're free to make up your own properties too as long as they don't start with _.

[videoh]

Nice. Just what the doctor ordered.

[poisondeathray]

The discrepancy with BlankClip you observed comes from the fact that, one uses direct file input while the other uses pipe. If you use ffmpeg -i test.avs -an -f null NUL you do see faster fps. But if you use avs2pipemod64 -y4mp test.avs | ffmpeg -f yuv4mpegpipe -i - -an -f null NUL you will see the same (or very close) fps compared to vpy. I don't know if pipe does cause that large overhead or it's the limitation of ffmpeg itself.


It is what we currently use. If there is overhead, than means if you use ffmpeg to encode, that overhead is currently incurred in real practice too - i.e it reflects reality. If you were to encode, say using libx264, it would be marginally slower because of that penalty

But I would like to compare "apples to apples" someday. It is a dream. Maybe with this :)


https://forum.doom9.org/showpost.php?p=1838296&postcount=10

maybe quote it before it might disappear

[poisondeathray]

So, the penalty of pipe only has a significant impact when the script itself is quite fast. Otherwise in practical complex scripts, together with real encoding, it could be considered negligible.

Thanks for the testing!

It's just 1 test so far, but 4.5% faster is still significant. But when coupled with actual encoding (-c:v something), you'd expect that difference to drop more

[TheLastOfUs]

Doesn't work for me. Constantly still says no such function z_ConvertFormat. I put it under plugins+ in AviSynth+ Prog Files x86 :/

Using FFMS2 for a 4K mkv...what am I doing wrong?

[Groucho2004]

Doesn't work for me. Constantly still says no such function z_ConvertFormat. I put it under plugins+ in AviSynth+ Prog Files x86 :/

Using FFMS2 for a 4K mkv...what am I doing wrong?
Run "AVSMeter avsinfo" (or "AVSMeter64 avsinfo") and let us know if that produces any errors.
It's quite possible that you don't have the required runtimes installed.

[TheLastOfUs]

Run "AVSMeter avsinfo" (or "AVSMeter64 avsinfo") and let us know if that produces any errors.
It's quite possible that you don't have the required runtimes installed.

AVSMeter just crashes, assuming its flipping out because that function doesn't exist apparently.

AviSynth+ 0.1 (r1576, x86) (2.6.0.5)

Script error: There is no function named 'z_ConvertFormat'.
(C:\Users\Desktop\AVSMeter281\New File (1).avs, line 2)

[Groucho2004]

AVSMeter just crashes, assuming its flipping out because that function doesn't exist apparently.

AviSynth+ 0.1 (r1576, x86) (2.6.0.5)

Script error: There is no function named 'z_ConvertFormat'.
(C:\Users\Desktop\AVSMeter281\New File (1).avs, line 2)
1. Update AVS+ to the most recent version (https://github.com/pinterf/AviSynthPlus/releases)
2. Read my last post again - The command line should be "AVSMeter avsinfo"

[TheLastOfUs]

Ok doing so now!

[TheLastOfUs]

Didn't even REALIZE there's a most recent fork. I always just went to AviSynth+ website lol

[TheLastOfUs]

1. Update AVS+ to the most recent version (https://github.com/pinterf/AviSynthPlus/releases)
2. Read my last post again - The command line should be "AVSMeter avsinfo"


Updating worked. Thank you kindly!

I love avsmeter. It's amazing for diagnosis. I'm surprised I'm JUST now finding out about your tool!

[TheLastOfUs]

sOLVED!

[TheLastOfUs]

Remove!