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. |
6th February 2021, 15:00 | #842 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
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. |
6th February 2021, 16:22 | #843 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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 ??? |
13th February 2021, 14:47 | #844 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,041
|
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; } 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. |
14th February 2021, 09:11 | #845 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
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.
|
14th February 2021, 11:14 | #846 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,041
|
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. |
15th February 2021, 08:19 | #847 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
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. |
|
15th February 2021, 14:28 | #848 | Link | |
Registered User
Join Date: Jul 2018
Posts: 1,041
|
Quote:
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. |
|
16th February 2021, 14:32 | #849 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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:
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. |
|
16th February 2021, 15:05 | #851 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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. |
18th February 2021, 16:06 | #852 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Wiki page on AviSynth Unicode support on Windows 10 1903:
https://github.com/staxrip/staxrip/w...indows-10-1903
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
19th February 2021, 05:11 | #853 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,041
|
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 ?
|
23rd February 2021, 10:15 | #855 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,041
|
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 ? |
23rd February 2021, 11:06 | #856 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
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. |
23rd February 2021, 12:23 | #857 | Link | |
Registered User
Join Date: Jul 2018
Posts: 1,041
|
Quote:
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. |
|
2nd March 2021, 18:23 | #858 | Link | |
Registered User
Join Date: Oct 2020
Posts: 9
|
Quote:
I will happily try a CUDA-enabled build whenever pre-release builds are made public. Thank you pinterf. |
|
6th March 2021, 13:52 | #860 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|