AviSynth+ thread Vol.2

[tormento]

Any consideration for OpenCL?
OpenCL is a nice standard but benchmark shows that CUDA is way faster and there is a really strong support with compilers and from Nvidia.

[wonkey_monkey]

and there is a really strong support with compilers and from Nvidia.

But ONLY from Nvidia. No Nvidia? No CUDA.

[videoh]

Stupid post of the day. So what? No Microsoft no Windows. No Apple no iPhone. You get the drift.

[wonkey_monkey]

No, I don't get the drift, so maybe you didn't get the drift in the first place. If a user doesn't have Nvidia hardware then they're not going to be able to use anything that relies on CUDA. OpenCL, if I understand correctly is practically ubiquitous.

[tormento]

OpenCL, if I understand correctly is practically ubiquitous.
Then much better Vulkan than OpenCL.

[FranceBB]

When a european man uses imperial units, a CUDA core of his video card core dies. :p

Eheheh... Doom9, where impossible things happen. ;)
(Honestly, though, I hope all the cuda core in my Quadro P4000 are fine xD)

OpenCL is a nice standard but benchmark shows that CUDA is way faster and there is a really strong support with compilers and from Nvidia.

True. Although OpenCL is available on any GPU, including those from Intel and AMD, it's also true that the performances have not been so good. Honestly, I don't mind pushing towards cuda. The whole industry is already pushing towards it and it's the de facto standard for those kind of calculations.

If a user doesn't have Nvidia hardware then they're not going to be able to use anything that relies on CUDA. OpenCL, if I understand correctly is practically ubiquitous.

The thing is that OpenCL has been proven to be slow, especially on Nvidia cards, so losing a lot in performance only to make it run on different cards isn't generally something that businesses are willing to accept. I work in broadcast and I can tell you that no matter where you go, if you open up the workstations of any studio, you'll find an NVIDIA Quadro, it's just the way it is. Some very small studios may have an RTX but that's about it, it's always NVIDIA. What I'd like to see in the future for Avisynth is a widespread use of cuda with plugins that can work on the CPU for the rest of the community and on the GPU for those owning an NVIDIA card. I know it may not make some users happy, but industry-wise it makes a lot of sense. I work in the encoding department, we have servers running Avisynth automated tasks all the time for ingest and outgest (incoming and outgoing media) and I have plenty of NVIDIA Quadro cards that are used by AVID Media Composer and Davinci Resolve, but I can't use them for Avisynth (except for a very limited set of plugins - Thank you Donald ;) ) and I can't use them in encoding either due to the lower quality outcome compared to x264/x265. I am actually using them to encode with x264 + OpenCL but honestly, the speedup is so reduced that I can barely tell the difference. I would love to be able to use them for Avisynth as it would speed up things a lot!

[videoh]

If a user doesn't have Nvidia hardware then they're not going to be able to use anything that relies on CUDA. Same can be said about iPhones and lots of other things. So what?

It's like a joke from our youth: Why did the man jump out of the airplane? Answer: Because if he didn't jump out of the airplane he'd still be in the airplane.

You are saying nothing. Putting stuff in bold doesn't improve an argument.

[wonkey_monkey]

Same can be said about iPhones and lots of other things. So what?

So look at all the work pinterf and others have done to NOT keep Avisynth tied to a particular operating system. I just wondered if it might be preferable not to throw in with another proprietary system when there are open alternatives, but I appreciate that pinterf isn't starting something new from scratch here, if he's even starting anything at all.

[real.finder]

maybe both or all (with Vulkan) since Vulkan not work with many old gpus but OpenCL do

like this plugin do https://github.com/HomeOfVapourSynthEvolution/VapourSynth-Waifu2x-w2xc (it even work with CPU only)

gpu: Controls the environment to use.

0 = disable GPU
1 = auto detect. It will run on the first available environment in the following order:
CUDA
Vulkan
AMD OpenCL
FMA
AVX
Intel OpenCL
SSE3
OpenCV filter2D
2 = force to use OpenCL

[videoh]

Note that he puts CUDA first. ;)

[real.finder]

Note that he puts CUDA first. ;)

it's self-evident that CUDA is better for Nvidia

[videoh]

Y'all can only make self-evident observations? Or maybe it was a lame joke?

[DJATOM]

I love CUDA. Literally I'm NVidia fanboy, I think their GPUs are great:cool:

[Atak_Snajpera]

I love CUDA. Literally I'm NVidia fanboy, I think their GPUs are great:cool:

True NVIDIA fanboy would buy rtx3090 instead of that rtx2070 you have now. You must upgrade NOW!!!! Sell your kidney or/and car if you can't afford IT.

[DJATOM]

No, I'm not that insane. But I'll definitely buy 3080 once prices dumps.

[Atak_Snajpera]

No, I'm not that insane. But I'll definitely buy 3080 once prices dumps.

They will dump maybe after 4000 series... But then 3080 will be outdated and new series will be again sold out directly to chinese crazy miners.

[tormento]

No, I'm not that insane. But I'll definitely buy 3080 once prices dumps.
Wait for TI flavor. If you want to work seriously with 4K HDR, I think you will need more than 10GB for heavy MT.

[tormento]

maybe both or all (with Vulkan) since Vulkan not work with many old gpus but OpenCL do
I ain't a programmer but I can see FFMPEG is following the Vulkan path for general compatibility. And, to be honest, lot of not so ancient hardware supports it.

[videoh]

I would buy three 3090s right now if I could find any.

[DJATOM]

> TI
I'll consider it based on my local prices and availability. Literally I need it for filters like eedi3/nnedi3 where 10G memory isn't really a problem. In fact, 2070 with 8G is enough for it, but eedi3 is slow.

[pinterf]

Slowly porting some function documention of Neo fork (from Japanese) to Avisynth wiki.
Achievement of January is: http://avisynth.nl/index.php/DumpFilterGraph

[tormento]

I'll consider it based on my local prices and availability. Literally I need it for filters like eedi3/nnedi3 where 10G memory isn't really a problem. In fact, 2070 with 8G is enough for it, but eedi3 is slow.
Can you process HDR 4k material within 8GB? How many threads? Which GPU based filters do you use?

[DJATOM]

Yes, it's enough for 4k tonemap or eedi3/nnedi3 upscaling.

[tormento]

Yes, it's enough for 4k tonemap or eedi3/nnedi3 upscaling.
Do you use any GPU based filter?

[DJATOM]

All of those filters uses GPU (tonemap is cuda-based and edi stuff is OpenCL).

[tormento]

Is there any way to determine thru AVS+ the apparent and real bit depth of a video stream?

With apparent I call the number of bits (8/10/12/16), with real the non zero part of the bits itself.

I am starting to play with > 8 bits scripts and sometimes I have doubts about their real effectiveness.

[DJATOM]

Probably ScriptClip can help with detection, but it looks obscure for me and Idk howto write proper detection with it. Vapoursynth's std.FrameEval is much easier :D.
With python modules we can check md5 or crc of every frame and compare hash values. For example, create few clips (8, 10, 12, 14, 16) and compare source frame's md5 with every modified clip's frame hashes, then append metrics into variable. At exit (https://docs.python.org/3/library/atexit.html) write log file from metric variable and check found values across entire clip.

[videoh]

Maybe you can source the 10-bit into a clip c1. Then source it again into c2 and apply ConvertBits(8) followed by ConvertBits(10) to it. Finally do Subtract(c1,c2).Levels(...) to visualize any difference in the two low bits. If the 10-bit source is not real (i.e., low bits all zero) then you won't be able to amp up any visible difference.

BTW, don't forget that high bit depth is not just about getting more resolution, it's also about dynamic range for HDR.

[tormento]

I thank you both for the reply. I find a bit strange that a frame server hasn't functions to analyze the frame properties.

[pinterf]

I thank you both for the reply. I find a bit strange that a frame server hasn't functions to analyze the frame properties.
Extremely strange. Specify "analyze", specify "frame properties".
Did you expect a ready made function IsThisSourceReally8bitInFake10bitFormat()?

Anyway, you can look at the histogram. e.g. Histogram("levels", bits=10), it is not that wide yet, or else you can show only the histogram part with keepsource=false. Valid histogram resolutions are bits=8,9,10,11,12.

[tormento]

Extremely strange. Specify "analyze", specify "frame properties".
Did you expect a ready made function IsThisSourceReally8bitInFake10bitFormat()?
Given a single frame or a stream, the ability to detect bit depth and the capability to show the color bit value for a reasonable amount of pixels, to understand if all the bit depth is used or only “resized” to a deeper one, adding zeros only.

[pinterf]

Besides the above mentioned 10 bit Histogram you can write an expression for that in Expr.

[tormento]

Besides the above mentioned 10 bit Histogram you can write an expression for that in Expr.


Will try the histogram ASAP. For Expr, unfortunately I haven’t the capabilities to do it. Thanks, anyway.

[tormento]

Anyway, you can look at the histogram. e.g. Histogram("levels", bits=10)
I made a simple AVS script and, opening it in VirtualDub2, I can see that, when a video stream has a bit depth minor than the bits parameter, I can see "gaps" in the graph of levels.

Would be of much trouble to add an option for 16 bits too?

[pinterf]

For practical reasons the option is disabled. I hope that no one wants to display a clip with width=65536.

[tormento]

For practical reasons the option is disabled. I hope that no one wants to display a clip with width=65536.
Wait... what has bits to do with width?

[pinterf]

If we are talking about Histogram "bits": a 8 bit histogram has 2^8 (=256) horizontal columns for levels. A 10 bit histogram is shown in 1024 (2^10) columns. And a histogram with 16 bit resolution can be shown on 65536 columns.

[tormento]

If we are talking about Histogram "bits": a 8 bit histogram has 2^8 (=256) horizontal columns for levels. A 10 bit histogram is shown in 1024 (2^10) columns. And a histogram with 16 bit resolution can be shown on 65536 columns.
I am talking about "bits" parameter, i.e.

Histogram("levels", bits=12,keepsource=false)

I can find the true bitdepth of a stream just looking at histograms. That works fine for 8/10/12. How can understand if a stream is 16 bits or 10 bits without bits=16?

[pinterf]

I am talking about "bits" parameter, i.e.

Histogram("levels", bits=12,keepsource=false)

I can find the true bitdepth of a stream just looking at histograms. That works fine for 8/10/12. How can understand if a stream is 16 bits or 10 bits without bits=16?
Then you have to learn Avisynth, especially Expr or masktools lut expressions, or think about other techniques. Or ask your stream sources where they obtained a 16 bit master from.

[FranceBB]

Hi Ferenc,
I have just a thing to report.

The AviSynth+ 3.7.0 release installer for Windows XP has been shipped with the "wrong" version of C++ Redistributable.
Let me explain.

There are:

- AviSynthPlus_3.7.0_20210111_vcredist_xp.exe
- AviSynthPlus_3.7.0_20210111_xp.exe

Both builds work just fine on Windows XP and they've been compiled to run on XP targeting v141_xp correctly, so no problem, however the "_vcredist_xp.exe" version isn't shipping the XP compatible Microsoft C++ Redistributable 2015-2019 installer, so what will happen is that the C++ Redistributable that is gonna be installed won't work on XP, hence it will make impossible to use Avisynth.
In order to make it work, I've installed the "vcredist" version shipped with AviSynth+ 3.6.1 and then I installed "AviSynthPlus_3.7.0_20210111_xp.exe" without re-installing the C++ Redist and it worked like a charm.
I think you should be shipping the vcredist version from AVS 3.6.1 for XP ;)

[qyot27]

Then Microsoft changed the vcredist silently, because it was the standard 2015-2019 vcredist download link.

[FranceBB]

Yep...
I just checked and it seems that VC++ 2019 version 14.28.29213.0 (August 2020) is the last version compatible with Windows XP... :( C++ Redistributable AIO (XP Compatible) (https://github.com/abbodi1406/vcredist/releases/download/v0.35.0/VisualCppRedist_AIO_x86_x64_35.zip)
I've just archived it... For future XP releases, we should always include that one I think.

[StainlessS]

Tanks FBB

[DTL]

Suggestion to add to build-in Avisynth+ resizers:

User defined kernel resizer. It uses f(x) kernel function as:

class UserDefined2Filter : public ResamplingFunction
{
public:
UserDefined2Filter(float _b = 121.0, float _c = 19.0);
double f(double x);
double support() { return 2.0; }

private:
double sinc(double value);
float a, b, c;
};

UserDefined2Filter::UserDefined2Filter(float _b, float _c)
{
a = 1.0f; // 0 sample = 1
b = (float)clamp(_b, -50.0f, 250.0f); // 1 and -1 sample
c = (float)clamp(_c, -50.0f, 250.0f); // 2 and -2 sample
b = (b - 16.0f) / 219.0f;
c = (c - 16.0f) / 219.0f;
}

double UserDefined2Filter::sinc(double value)
{

if (value > 0.000001 || value < -0.000001)
{
value *= M_PI;
return sin(value) / value;
}
else
{
return 1.0;
}
}

double UserDefined2Filter::f(double x)
{
x = fabs(x);

if (x <= 3) // ?
{
return c * sinc(x + 2) + b * sinc(x + 1) + a * sinc(x) + b * sinc(x - 1) + c * sinc(x - 2);
}
else
return 0;

}


It can simulate wide range of resizer's kernels from Sinc to Gauss and intended to use mostly for downsize work with forming spectrum of output result being 'conditioned for channel' in term of EBU publications. It allows to use 1-pass processing at resampling time instead of pre-processing before downsampling to meet both Nyquist and Gibbs limitations of downsized moving pictures result. It allows to have better sharpness in compare with GaussResize while still keeping ringing in controlled range because of negative lobes available. It includes functionality of SinPowResize with even better precision of kernel creation but with higher number of control params. It also may be designed some iterative algorithm to adjust all (currently 2 but may be 3 or more) control params with target to lowest or maximum allowed ringing with adjustable 'sharpness' with 1 user-input param like 'sharpness'. But it is much more to program.

I read some old book about tv test signals and found simple idea how to define kernel function using very small number of control parameters. It is just sinc (or other target restoration function like jinc for 2D resamplers) interpolation. So I add one more resizer function currently named UserDefined2ResizeMT. It is copy of BicubicResize with 2 'b' and 'c' control parameters. Even with 2 control samples it is possibly do define big range of different resizer kernels with good enough precision and have use my web-render tool to visually control its behaviour. For better results there may be used more than 2 control samples - like 3 or 4. Like 'd' and 'e' additional arguments. With expanding filter 'support' value and defaulting non-used values to 16 (virtual zero ad 16..235 video coding range). I use range of control parameters in 16..235 mapped to 0..1 internally for better compatibility with typical digital video processing software. Though it may be changed to other range like 0..1 float (with valid range like -0.5 to +1) - it is not critical.
If user enter all control values as 16 it will produce SincResize kernel (internal 'a' parameter is equal to 1 or 235 in the input params range) with small number of taps defined at filter support now - may be 2 or 3. When I perform debug I see resampler asks for values outside 'support=2' up to about 3. May be it also useful for in-the-field using of this resizer to make 'support' also user-defined parameter. If user want to use >2 control values and have also a performance hit because of longer resampler processing. So user may see how kernel works far outside first defined number of samples if want.

Current full sources and supplementary documentation and tools is in the fork of jpsdr's ResampleMT at https://github.com/DTL2020/ResampleMT.

Also may be SincLin2Resize add or some other workaround for SincResize (may be control bool param to use additional weighting at the end of kernel) to fix its bugs at the end of too short truncated kernel computation.

[FranceBB]

Well done once again. When it's finalized, please contact Jean Philippe and ask for a push request so that he can merge everything and publish a new thread pool aware version of plugins_JPSDR.dll which is the one I use in production.

[DTL]

When it's finalized,

For 'complete' finalizing it need some feed-back from 'in the field' users for questions:

1. Is 2 control parameters is enough or 3 or 4 needed ?
2. Is current internally fixed 'support' value is enough or may be internally calculated as 'number of non-16 last control values (may be +1)'.

It is currently 'finalized' for control params number = 2 so pull-request at github is made.

May be for creating 'reference' higher quality test patterns like for 10-bit and 10+bit data more 2 control values will be definetly required. But with real world moving pictures material may be no any visible difference but with slower processing and harder to control by low experienced end-user.
May be it is better to add 2 named resizers like UserDefined2Resize with 2 control params (for most everyday practical work) and UserDefined4Resize with 4 control params (for advanced users).

Also for 10bit and higher precision may be it is better to set control params range to -1.0f to 1.0f. Because currently available setting like 16.01 if required may be harder for end user for re-calculation from different values range. For example in that book the samples values for test pulse for digital video workflows was defined with about 5..6 digits like:
b=0.48113 c=0.01541 d=0.00354 e=-0.00275 f=0.00194 g=0.00140 i=0.00105 k=0.00082 l=0.00065 m=-0.00053
But for practical using written it is enough to use starting 2 (already gives K-factor like <0.205% and 5 times better in compare with typical 'analog' test pulse sin^2), so current defaults in 16-235 range integers is
b=0.48113*219+16=121
c=0.01541*219+16=19
And for real content for downsize work it is very approximate values because the actual working values depends on:
1. Content source (most of sources were build and continue to build without any requirements to its spectrum in valid frequencies range).
2. Shrinking ratio (small shrinking ratios like 1/1.5 are not much change input spectrum and large shrinking ratios like 1/3..1/4+ require almost new spectrum re-forming for anti-Gibbs conditioning).
3. User's personal opinion of how output result must look.

In some/future 'perfect world' the calculation of 'b' and 'c' (and other if required) control params for getting 'standard' result may be automated based on shrinking ratio. But it also need to be applied to 'standard' source. May be some calculator of recommended values of params based on shrinking ratio may be made and released as supplementing tool as 'hint' to user to start with in the future. Or at least some short table may be faster created like 'shrinking ratio' {<2; 2..4; >4}, sharpness {low; standard; high}; b,c (d,e){ ....}.

Update for typical recommended values:
Shrinking ratio: 1/8,
-Low Sharpness: b=121 c=19;
-Medium sharpness: b=104 c=0;
-High sharpness: b=90 c=-14.

Shrinking ratio: 1/2,
-Low Sharpness: b=100 c=-5;
-Medium sharpness: b=90 c=-15;
-High sharpness: b=80 c=-20.

The highest possible 'sharpening' is about b=50, c=-50. Some 'softening': b=190, c=80.

[pinterf]

, so current defaults in 16-235 range integers is
b=0.48113*219+16=121
c=0.01541*219+16=19

I see those hardcoded numbers 16 and 219 there. Does it mean that this resizer is fine tuned to YUV color space luma only? U and V chroma planes have 16-240 range; RGB is full range.
EDIT:
Some notes:
This one (https://github.com/DTL2020/ResampleMT/commit/dfcfa4fc5d8cfbc17154cba463f416d2cf45cfe4#diff-dbb2fe7842c0b8cc580930915d1d7d145bccc28a9f47ca10fe7e70b1c2cbc01bR307) probably doesn't need default parameters because here (https://github.com/DTL2020/ResampleMT/commit/dfcfa4fc5d8cfbc17154cba463f416d2cf45cfe4#diff-c2f84ab50dcf4e6eadec84dd1241b6548305299189a07231fe311948d70fa2c5R4952) you are already setting the them.

[DTL]

I see those hardcoded numbers 16 and 219 there. Does it mean that this resizer is fine tuned to YUV color space luma only? U and V chroma planes have 16-240 range; RGB is full range.


No. It is just one of possible ways of transfer values of control params from user input to actual kernel computation function. They may be defined in range of -1.0f to about 1.0f (as I think most of real usable kernels do not have >1 values and <-1).

I think many broadcast and video data users are used to use video samples range of unsigned integers defined usually in 16..235 range for 8bit encoding. So typical users knows 16=black zero and 235 is nominal system white. The currently still active broadcast standards like ITU-R-BT.1212 also define actual samples values in 'natural' range 16..235. So user can just pick the samples of some actual impulse response and use as parameters without re-calculation to -1.0f..+1.0f range.

The kernel-output function f(x) outputs same range values as other resizer's kernels. I test it only with jpsdr's ResampleMT resampler core, not with latest Avisynth+ releases, but I hope there is no significant difference.

Using with RGB full range is also possible without any tuning but user must understand possible losses of overshoots and undershoots outside valid range for RGB resulting with later non-linear distortions at further processing like unwaited ringing and some decreasing of sharpness. Though integer 16..235 coding range also limited in its ability of handing extreme under and overshoots of course.

If it will be more comfortable to use float range about 0..1 it may be easily changed removing internal conversion from 16..235 range and limiting user input to about -1.0f.. 1.0f.
Defaults b and c will be 0.481 and 0.015. There is no any special magic in this numbers and it just placeholders giving medium sharp result if downsizing with high enough ratio like >5 and giving very low ringing with almost no under/over shoots (so it also 'more compatible' with RGB-fullrange processing defaults).

"This one probably doesn't need default parameters because here you are already setting the them."

I still very poor in programming at high level languages so put as much as possible. My todays greatest achievement is finally working using vector of vectors of C++ to do not write it manually with C and to use library 'vector->rotate' operation :) . So programming of multithreaded 'planar'/2D resampler engine is in progress and may be in some days it may be also added to main Avisynth core as alternative 'linear' resampler engine.

[StainlessS]

Just thought I'd point this out in case P had not seen it in Usage.
https://forum.doom9.org/showthread.php?p=1936011#post1936011



Function SpotLess2(clip c, int "RadT", int "Spot", bool "DeGrain", int "RadT", int "ThSAD", int "ThSAD2",
\ int "pel", bool "chroma", int "BlkSz", Int "Olap", bool "tm", Bool "glob") {


Strangely, it does not throw an error due to 2 different instances of the formal parameter "RadT", maybe a bit more checking needed in Avs+.


EDIT: I have not tried explicitly providing all args (un-named) to see what happens, and what value RadT=Default(RadT,42) might acquire,
where both instances of supplied RadT presented different numbers.

EDIT: OK, I could not resist it.

Function Testing123(clip c,int arg1, int "Arg2",int "Arg3", int "Arg4",int "Arg2",int "Arg5",int "Arg6") {
return Default(Arg2,-1)
}

BlankClip(Width=64,height=64,length=1,pixel_type="YV12").killaudio
z=Testing123(last,1,1001,3,4,1002,5,6)
Subtitle(string(z))

https://i.postimg.cc/P5JQXwGM/SHITE-2-00.jpg (https://postimages.org/)

EDIT: Maybe it don't matter too much, obviously not a popular script bug :)

[pinterf]

I've already prepared my mind for that report. All I can say: don't do that :) Bonus idea: try how many parameters are allowed in classic Avisynth and Avisynth+ :)