Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th February 2021, 05:18   #841  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,268
Then Microsoft changed the vcredist silently, because it was the standard 2015-2019 vcredist download link.
qyot27 is offline   Reply With Quote
Old 6th February 2021, 15:00   #842  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Metropolitan City of Milan, Italy
Posts: 1,414
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)
I've just archived it... For future XP releases, we should always include that one I think.
FranceBB is offline   Reply With Quote
Old 6th February 2021, 16:22   #843  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,132
Tanks FBB
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 13th February 2021, 14:47   #844  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
Suggestion to add to build-in Avisynth+ resizers:

User defined kernel resizer. It uses f(x) kernel function as:
Code:
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.

Last edited by DTL; 14th February 2021 at 10:29.
DTL is offline   Reply With Quote
Old 14th February 2021, 09:11   #845  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Metropolitan City of Milan, Italy
Posts: 1,414
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.
FranceBB is offline   Reply With Quote
Old 14th February 2021, 11:14   #846  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
Quote:
Originally Posted by FranceBB View Post
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.

Last edited by DTL; 18th February 2021 at 20:48. Reason: Added recommended b and c values.
DTL is offline   Reply With Quote
Old 15th February 2021, 08:19   #847  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
Quote:
Originally Posted by DTL View Post
, 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 probably doesn't need default parameters because here you are already setting the them.

Last edited by pinterf; 15th February 2021 at 08:31.
pinterf is offline   Reply With Quote
Old 15th February 2021, 14:28   #848  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
Quote:
Originally Posted by pinterf View Post
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.

Last edited by DTL; 15th February 2021 at 14:41.
DTL is offline   Reply With Quote
Old 16th February 2021, 14:32   #849  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,132
Just thought I'd point this out in case P had not seen it in Usage.
https://forum.doom9.org/showthread.p...11#post1936011

Quote:
Originally Posted by StainlessS View Post
Code:
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.
Code:
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))


EDIT: Maybe it don't matter too much, obviously not a popular script bug
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 16th February 2021 at 15:00.
StainlessS is offline   Reply With Quote
Old 16th February 2021, 14:59   #850  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
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+
pinterf is offline   Reply With Quote
Old 16th February 2021, 15:05   #851  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,132
Tanks for your consideration P, "dont do dat" seems to be the way to go.

EDIT: Get my jab tomorrow.

EDIT: I think is unlimited parameters in Avs+, not sure bout 2.6 std.
I believe that at one time it may have been limited to 64. [think was maybe qyot27 idea to make unlimited].
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 16th February 2021 at 15:13.
StainlessS is offline   Reply With Quote
Old 18th February 2021, 16:06   #852  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,716
Wiki page on AviSynth Unicode support on Windows 10 1903:

https://github.com/staxrip/staxrip/w...indows-10-1903
stax76 is offline   Reply With Quote
Old 19th February 2021, 05:11   #853  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
Can this approach - http://downloads.bbc.co.uk/rd/pubs/reports/1987-22.pdf be added to http://avisynth.nl/index.php/Limiter core filter ?
DTL is offline   Reply With Quote
Old 22nd February 2021, 10:04   #854  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
I've run through it, probably yes, but in my age a quick overview is not enough for deep understanding of the possible implementation steps. I'll return to the topic later.
pinterf is offline   Reply With Quote
Old 23rd February 2021, 10:15   #855  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
It looks some very hard long strategic question on core and plugin development:

Because of current execution hardware architecture moving to large number of processing cores with small per-core L1d cache and slow main memory access can be the new scan formats be added like blocks scan instead of full-frame line scans ?

Currently for algorithms for vertical data accessing it is require to read memory with large strides and it even 1 full line of 8K frame in float32 eats all 32 kB L1d cache.

The size of scan blocks is a new question. It looks must be < L1d cache size like 32..48 kB maximum and the ratio of V/H may be from 1:1 to may be natural for 4/3..16/9 frame.

The scan re-formatting may be made inside each plugin to and back but it will slow performance. May be also some plans in this direction exist ?
DTL is offline   Reply With Quote
Old 23rd February 2021, 11:06   #856  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
Given the large number of plugins and the extra complexity it introduces I think it will never happen. Filters are complex enough even without this feature. How many OpenCL or CUDA filters do we know? Only a few of them exist. Actually CUDA support** seems to be working with Avisynth+ core (do not search it in the official releases ) supporting native CUDA filter chain.

Like https://github.com/pinterf/AviSynthCUDAFilters . It includes
https://github.com/pinterf/NNEDI3/tree/cuda
https://github.com/pinterf/masktools/tree/cuda
I have forked them from Nekopanda's github pages and updated them to work with actual Avisynth 3.7. CUDA version build now is supported from CMake as well
https://github.com/AviSynth/AviSynth...a6d10e0817eef6
Other useful info:
https://github.com/pinterf/AviSynthC...build_help.txt
and
http://avisynth.nl/index.php/SetFilterMTMode
(onCPU and onCUDA section)

**CUDA support = the interfaces and the framework exists. Implemented filters are in those above mentioned external plugins.

Last edited by pinterf; 23rd February 2021 at 11:10.
pinterf is offline   Reply With Quote
Old 23rd February 2021, 12:23   #857  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
Quote:
Originally Posted by pinterf View Post
How many OpenCL or CUDA filters do we know? Only a few of them exist. Actually CUDA support** seems to be working with Avisynth+ core (do not search it in the official releases ) supporting native CUDA filter chain.
So CUDA for GPU already uses some sort of small blocks scan mode instead of full line scanning also because of problems with 2D access with too large strides ?

I see current 'multi-frames' MultiThreading processing in Avisynth also limited by memory speed on many cores CPUs.

As for plugins it may be evolutional shifting to block scan formats if new formats will be added and plugin (and core) filters designers will move in time to support new scan formats.

Unfortunately no good news from hardware production industry on significant bus width increase and memory performance increase. Also sill even no progress of local on-chip cache being 'all-L1' but still divided to small L1 and larger L2/L3 with even low speed.

I think the reason of production Xeons with >10 cores for 'supercomputing' is only with software capable of process mostly data in register file or L1 cache.
DTL is offline   Reply With Quote
Old 2nd March 2021, 18:23   #858  |  Link
Kogarou
Registered User
 
Join Date: Oct 2020
Posts: 2
Quote:
Originally Posted by pinterf View Post
Given the large number of plugins and the extra complexity it introduces I think it will never happen. Filters are complex enough even without this feature. How many OpenCL or CUDA filters do we know? Only a few of them exist. Actually CUDA support** seems to be working with Avisynth+ core (do not search it in the official releases ) supporting native CUDA filter chain.

Like https://github.com/pinterf/AviSynthCUDAFilters . It includes
https://github.com/pinterf/NNEDI3/tree/cuda
https://github.com/pinterf/masktools/tree/cuda
I have forked them from Nekopanda's github pages and updated them to work with actual Avisynth 3.7. CUDA version build now is supported from CMake as well
https://github.com/AviSynth/AviSynth...a6d10e0817eef6
Other useful info:
https://github.com/pinterf/AviSynthC...build_help.txt
and
http://avisynth.nl/index.php/SetFilterMTMode
(onCPU and onCUDA section)

**CUDA support = the interfaces and the framework exists. Implemented filters are in those above mentioned external plugins.
Woah you actually did it, the absolute madman. I wasn't expecting you to go this far to merge the fork into the mainline AVS+ in such a short amount of time.
I will happily try a CUDA-enabled build whenever pre-release builds are made public.
Thank you pinterf.
Kogarou is offline   Reply With Quote
Old 6th March 2021, 13:24   #859  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 1,704
Quote:
Originally Posted by real.finder View Post
ok, so I will mention what not has HBD yet
Could you please update it? I think that it would be useful as sticky post.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 6th March 2021, 13:52   #860  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,164
Quote:
Originally Posted by tormento View Post
Could you please update it? I think that it would be useful as sticky post.
here https://forum.doom9.org/showthread.p...80#post1937480
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 08:02.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.