AviSynth+ thread Vol.2

[Reel.Deel]

Originally Posted by pinterf

Fixed on git, kedautinh12 will be soon happy to announce that a new clang build appears.

Lol. I see now that there are Clang and IntelLLVM builds to announce, he will be very happy

[kedautinh12]

AviSynthPlus r3936 clang and IntelLLVM build
https://gitlab.com/uvz/AviSynthPlus-Builds

[kedautinh12]

Originally Posted by Reel.Deel

Lol. I see now that there are Clang and IntelLLVM builds to announce, he will be very happy

Yes, i like optimize ver of all plugins

[pinterf]

I'd like to see benchmarks with different builds. I found that non-optimized C++ only codes were indeed quicker with clang/llvm. The difference was even bigger at 32 bit builds, where LLVM was much smarter on using avaliable (of limited number) CPU registers.

I then remember RgTools where it depended on the specific filter mode. One mode was better with Clang other modes were much quicker with the plugin version built with Microsoft, if I remember well, it was especially the AVX2 optimization where MS shined.

Probably this benchmark should be periodically rechecked for each generation change in compilers.

EDIT:
I see that the README.md in https://gitlab.com/uvz/AviSynthPlus-Builds contains a short script, where clang is +10%, IntelLLVM is +14% quicker than MSVC.
I wonder if the gain is evenly distributed among the filters of there is a specific one or two filters which are the bottleneck.

EDIT 2:

My benchmarks; two measurements per Avisynth+ version
Machine: Win11 Pro, 11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz 2.50 GHz

MS: 49,78; 49,93 fps
Clang: 50,90; 50,74
IntelLLVM: 53,29; 53,25

EDIT 3:
The difference is mainly in dither=1 option (which is written in pure C). When changing that option in ConvertBits into dither=0:
MS: 154,3 fps
Clang: 154,9 fps
Intel: 154,8 fps

Script for this last run:

ffms2("myvideo")
convertbits(16)
converttoyuv444(chromaresample="spline36")
convertbits(32, fulls=false, fulld=true)
converttoplanarrgb()
convertbits(16,dither=0)
Spline36Resize(width*2, height*2)
convertbits(8, dither=0)

[pinterf]

O.K. Challenge accepted
Avisynth+ 3.7.3 test 7 (20230223)
Changes since test6

20230223 3.7.3 WIP
------------------
- Update build documentation with 2023 Intel C++ tools. See Compiling Avisynth+ 
  https://avisynthplus.readthedocs.io/...g_avsplus.html
- CMakeLists.txt: add support for Intel C++ Compiler 2023.
- Enhanced performance in ConvertBits Floyd dither (dither=1) for 10->8, 16->8 and 16->10 bit cases
  by providing special function templates to allow compilers to optimize them much better.
  (Both Microsoft and Intel Classic 19.2 benefits, LLVM based clangCL and IntelLLVM compilers not)
- Fix crash when outputting VfW (e.g. VirtualDub) for YUV422P16, or P10 in Intel SSE2 optimization
  due to aligned SIMD write to an unaligned pointer - did not affect Microsoft builds.
  As seen in https://forum.doom9.org/showthread.p...43#post1983343

The bottleneck was dither=1 option.

          test6   test7 (fps)
Microsoft 49,86   53,71
Clang     50,85*  52,99** 
Intel     53,43*  58,17**

* from https://gitlab.com/uvz/AviSynthPlus-Builds
** provided in test7 package by me

My Intel version was built with Intel Classic 19.2
uvz version named the folder IntelLLVM. I was not able to reach even MS's speed with my IntelLLVM build without any tweak.

Script:

ffms2("myvideo720x576.avi")
convertbits(16)
converttoyuv444(chromaresample="spline36")
convertbits(32, fulls=false, fulld=true)
converttoplanarrgb()
convertbits(16,dither=1)
Spline36Resize(width*2, height*2)
convertbits(8, dither=1)

[Reel.Deel]

Surprisingly the test 7 MSVC build is the fastest for me. I'm embarrassed to post the speeds of my 10 year old PC but here they go. Edit: well I'm not that embarrassed anymore, I didn't realize pinterf's video was 720x576 .

Windows 7 (x64) - Intel i7-4930K

Script

ColorBars(1920, 1080, pixel_type="YUV420P8")
Loop()
Trim(0,1000)
ConvertBits(16)
ConvertToYUV444(chromaresample="spline36")
ConvertBits(32, fulls=false, fulld=true)
convertToPlanarRGB()
ConvertBits(16, dither=1)
Spline36Resize(width*2, height*2)
ConvertBits(8, dither=1)

Test 7 (r3940, MSVC)

FPS (min | max | average):          4.652 | 7.187 | 6.517
Process memory usage (max):         456 MiB
Time (elapsed):                     00:02:33.598

uvz (r3936, IntelLLVM)

FPS (min | max | average):          4.505 | 6.913 | 6.272
Process memory usage (max):         449 MiB
Time (elapsed):                     00:02:39.605

uvz (r3936, Clang)

FPS (min | max | average):          4.266 | 6.755 | 6.062
Process memory usage (max):         449 MiB
Time (elapsed):                     00:02:45.114

Test 7 (r3940, Clang)

FPS (min | max | average):          4.367 | 7.026 | 5.999
Process memory usage (max):         449 MiB
Time (elapsed):                     00:02:46.860

Test 7 (r3940, Intel)

FPS (min | max | average):          4.072 | 6.310 | 5.578
Process memory usage (max):         450 MiB
Time (elapsed):                     00:02:59.451

Test 6 (r3935, MSVC)

FPS (min | max | average):          3.812 | 6.551 | 5.554
Process memory usage (max):         456 MiB
Time (elapsed):                     00:03:00.226

Thread count: 16 and CPU usage (average): 8.2% was the same for all.

[Fjord]

Is it possible to get a little more information in the Expr() error message when the stack is unbalanced on return. The message is currently
"Expr: Stack unbalanced at end of expression. Need to have exactly one value on the stack to return" (in AvsPMod).
The same error message appears both for empty stack as well as more than 1 value on the stack at return.

Is it possible to show the number of elements remaining on the stack in the error message? That would really help debugging of Expr expressions.

[pinterf]

Originally Posted by Fjord

Is it possible to get a little more information in the Expr() error message when the stack is unbalanced on return. The message is currently
"Expr: Stack unbalanced at end of expression. Need to have exactly one value on the stack to return" (in AvsPMod).
The same error message appears both for empty stack as well as more than 1 value on the stack at return.

Is it possible to show the number of elements remaining on the stack in the error message? That would really help debugging of Expr expressions.

Why not. Done, it will appear in the next build.

[DTL]

Current test results of resizers for 2:1 downsize and checking for displaying with taps=8 sincresize:
https://drive.google.com/file/d/1ds4...ew?usp=sharing

2.2 support for UserDefined2Resize was tested with custom debug build of current avisynth+ sources.

[Fjord]

Originally Posted by pinterf

Why not. Done, it will appear in the next build.

Thank you! You and all the devs are fantastic.

[Boulder]

Tested the three builds on my 5950X using Reel.Deel's script. The Intel build is the fastest on a Zen 3 as well.

MSVC
FPS (min | max | average):          11.12 | 14.64 | 14.19
Process memory usage (max):         367 MiB
Thread count:                       33
CPU usage (average):                3.1%

Time (elapsed):                     00:01:10.544

Clang
FPS (min | max | average):          11.14 | 14.84 | 14.09
Process memory usage (max):         367 MiB
Thread count:                       33
CPU usage (average):                3.1%

Time (elapsed):                     00:01:11.053

Intel
FPS (min | max | average):          11.20 | 14.81 | 14.22
Process memory usage (max):         367 MiB
Thread count:                       33
CPU usage (average):                3.1%

Time (elapsed):                     00:01:10.417

[FranceBB]

Originally Posted by DTL

Current test results of resizers for 2:1 downsize and checking for displaying with taps=8 sincresize:
https://drive.google.com/file/d/1ds4...ew?usp=sharing

Will SinPowResizeMT() finally become SinPowResize() in the Avisynth core or is it not currently in roadmap?

[Reel.Deel]

Originally Posted by FranceBB

Will SinPowResizeMT() finally become SinPowResize() in the Avisynth core or is it not currently in roadmap?

Already implemented since test 6.

Originally Posted by pinterf

Changes since yesterday's test5: ffdshow fix, new resizers and parameterized chroma resampler option in ConvertToXXXX filters

20230218 3.7.3 WIP
------------------
- (#337) Add more resizers types by jpsdr's and DTL's idea: backport from https://github.com/jpsdr/ResampleMT
  
  SinPowerResize "cii[src_left]f[src_top]f[src_width]f[src_height]f[p]f"
  parameters like GaussResize: optional "p"
  Default: p=2.5
  
  and their equivalent for the ConvertToXXXX family:
  "sinpow",  "sinclin2" and "userdefined2"

....

[DTL]

Originally Posted by FranceBB

Will SinPowResizeMT() finally become SinPowResize() in the Avisynth core or is it not currently in roadmap?

It is already transferred to AVS. But its kernel is more non-linear (its support is hardlimited to 2) so for more higher quality work we also have (possibly better) kernel of UserDefined(2).
The kernel of SinPow is based on several non-linear hacks and work only in very truncated size (with more or less discontinuity at edges).
The kernel of UD can be safely expanded to larger 'support' size (until it safely reach very low values).
Initially there were an idea to set larger fixed 'support' to UD(2) resize (like 3 for example) internally but with experiments I found it may be useful to limit its 'support' too by additional user-controlled param and to the finely adjusted float value (most changes occur at adjustments from 2 to 3 with steps like 0.1..0.2).
For example setting 'support' of 2.2 to UD2 it possible to get less residual ringing/artifacts at transients while using 'higher' b/c control params of 75/-25 and get more sharpness (closer to SinPow). Using old 'support' of 2 require to use 'lower' b/c control pair of 70/-30 (more 'extreme') to have comparable visible sharpness while having more residual ringing/artifacts. So limit of 'support' to 2 only for UD kernel significantly limits its possible 'peaking/sharpness' capability with extreme b/c setting of kernel members, also not allow to show its 'linear' properties in ringing control at full scale.

So I supplement the current issue description with request to add 3rd control param to UD(2) resize of 'support' or 's'. With s=2 (as in old implementation of jpsdr's plugin) the UD(2)Resize may be adjusted close enough to SinPowResize output (at least in some range of control param). And when increasing 'support' to 3 (and may be more) you can get less residual ringing (while having lower sharpness and thicker 'peaking' contours around sharp transients). So with adjusting 'support' param the UD(2)Resize can be adjusted between 'partially non-linear' resize with s=2 to 'more linear' with s>2. Though real difference between SinPow and UD resizers even with fixed support=2 as today is not easily visible and UD(2) s>2 is mostly for 'perfectionists' like creating high-end linear processing workflow. Understanding it will have lower 'per-sample' sharpness (so require to sit at more distance from screen or use higher DPI displays and more samples per frame to keep the same 'visual sharpness'). So for very limited in samples count per frame (small frame size internet-torrents) rips of UHD/HD sources (like 700MB version in something like 640x360) may be 'partially non-linear' form of current SinPow and UD2 s=2 resizers may have benefits of a bit higher sharpness while producing some more residual ringing/artifacts. I currently checking my new rip of 4k->FullHD of some nature documentary created with UD2(width/2, height/2, b=70, c=-30) and it looks about very good.

So SinPow kernel looks like limited to its initial design of single control param and 'support' of 2 and some non-linearity by-design with about no expanding possible. And UD can be easlily expanded in the number of kernel members used and 'support' size with some increasing of quality (control over residual ringing and artifacts). For example UD10Resize with 'support' of about 10 and 10 user-provided kernel members easiliy possible. So with some 'user-provided vector of arguments' more general form is
UserDefinedNResize(kernel members list, s, ...)
where is args_count=2 (and s=2) it is current UserDefined2Resize. But I poor in programming of AVS and still not know how to make filter with variable number of arguments and it require to ask very busy pinterf to make more programming or someone else.

And also as noted in https://forum.doom9.org/showthread.p...80#post1983080 and https://forum.doom9.org/showthread.p...19#post1983119 about chroma subsampling conversion it is now possible to use different types of 4:4:4<->4:2:x conversion filtering to UV in Convert() filters.

Here is example of muiti-generation default bicubic filter at 4:4:4<->4:2:0 chroma sharpness degradation:

ColorBars(960*4, 540*4, pixel_type="YUV444P8")
UserDefined2Resize(width/4, height/4, b=105, c=0) # put some conditioning

sinc=ConvertToYUV420(chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420()
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc, chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)

sinc_mon=ConvertToYUV444(sinc,chromaresample="userdefined2", param1=105, param2=0).Subtitle("sinc_mon") #monitoring chroma anti-Gibbs
sinc_no_mon=ConvertToYUV444(sinc,chromaresample="sinclin2").Subtitle("sinc_no_mon") 
bicub=ConvertToYUV444(bicub).Subtitle("bicub")

Interleave(sinc_mon, sinc_no_mon, bicub)
SincLin2Resize(width*2, height*2)

Addition: Really with some more supplementing of UserDefinedResize with optional 'lin2' weighting as in SincLin2Resize the complete digital moving pictures system from scene light to display light (with subsampled chroma) can be built with UD Resize only. Because with b=c=16 the UD kernel is single sinc only.
So with w-param of w='none' or 'lin2' and extending of s to 16:

ColorBars(960*4, 540*4, pixel_type="YUV444P8") # our natural infinite resolution scene , really RGBP8 or better RGBPS

# main digital video camera transform of full conditioning of RGB/YUV (band-limiting and anti-Gibbs residual spectrum shaping
# to required look/makeup)
UserDefined2Resize(width/4, height/4, b=105, c=0, s=3, w="none") # film-look / makeup softer
#or 
UserDefined2Resize(width/4, height/4, b=80, c=-20, s=3, w="none") # video-look / makeup sharper

# put 2:1 system compression converting to 4:2:0 with partial conditioning (band-limiting, no anti-Gibbs)
ConvertToYUV420(chromaresample="userdefined2", b=16, c=16, s=16, w="lin2")

#MPEG compression for distribution
#digital moving pictures production transform ends here

##########
# broadcasting / distribution / archive digital movie compressed content
###########

#enduser transform:
#MPEG decompression to 4:2:0

#1:2 decompression of 4:2:0 to 4:4:4 and continue 2:1 bandlimited UV data conditioning with anti-Gibbs
ConvertToYUV444(chromaresample="userdefined2", b=105, c=0, s=3, w="none")

UserDefined2Resize(width*4, height*4, b=16, c=16, s=16, w="lin2")# equal to SincLin2Resize(), decompression of sampled data to 'infinite' resolution (DAC)

ConvertToRGB()# for feed to RGB physical display

[jpsdr]

Hello.

Tested the Test7 version provided by Pinterf, and with the clang version, i still have the same issue, the following error message with VirtualdDub2:

File open error
AVI Import Filter error: (unknow) (80040154)

when i open with AVISource an yuv422p10le UTVideo file.
The MS build works fine.

[FranceBB]

Sox doesn't seem to be working neither in x86 nor in x64.
Tested on both Windows XP x86 and Windows Server 2019 x64.


How to reproduce:

ColorBars(848, 480, pixel_type="YV12")
UpSoundOnSound()

this should upmix stereo to 5.1 using Sox, however it doesn't work.



This has been broken since 2017 and the last version working with sox was Avisynth 2.6.1 from 2016 (it's been a minute, I know).

I reported it here: https://forum.doom9.org/showthread.php?p=1887661

a while ago and has been reproduced by Tebasuna as well for both x86 and x64.
Since a new Avisynth version is in the making (3.7.3 Test 7), is there a way to get this sorted once and for all so that I can go back to use Sox?

[pinterf]

Originally Posted by jpsdr

Hello.

Tested the Test7 version provided by Pinterf, and with the clang version, i still have the same issue, the following error message with VirtualdDub2:

File open error
AVI Import Filter error: (unknow) (80040154)

when i open with AVISource an yuv422p10le UTVideo file.
The MS build works fine.

Problem found and maybe fixed. A sample or telling the dimensions of your video would helped a lot , I had only a width=640 sample which is a proper nice mod16 even mod32 value and only hacked the width to be 638 and there came the crash. I don't know if your actual sample would crash or not but I hope it's OK now.

[tebasuna51]

Originally Posted by FranceBB

...
Since a new Avisynth version is in the making (3.7.3 Test 7), is there a way to get this sorted once and for all so that I can go back to use Sox?

An avs+ better audio management is always desirable, but the first improvement must be change the Audio property AudioChannels.

Must be MaskChannels instead NumChannels (than can be calculated from MaskChannels)

[pinterf]

Originally Posted by FranceBB

Sox doesn't seem to be working neither in x86 nor in x64.
Tested on both Windows XP x86 and Windows Server 2019 x64.


How to reproduce:

ColorBars(848, 480, pixel_type="YV12")
UpSoundOnSound()

this should upmix stereo to 5.1 using Sox, however it doesn't work.



This has been broken since 2017 and the last version working with sox was Avisynth 2.6.1 from 2016 (it's been a minute, I know).

I reported it here: https://forum.doom9.org/showthread.php?p=1887661

a while ago and has been reproduced by Tebasuna as well for both x86 and x64.
Since a new Avisynth version is in the making (3.7.3 Test 7), is there a way to get this sorted once and for all so that I can go back to use Sox?

Ohh, something written 17 years ago does not work anymore
And this is a CPP 2.5 style plugin. Nothing is guaranteed, if it works, we are happy.

I'm gonna put zero effort into checking why it does not work.

Instead, the whole Sox library integration must be refreshed; too bad they changed the API, first in 2006, then ... who knows when.
Anyway, I could not make Sox compile as a static library to link with SoxFilter avisynth filter, nor could do any integration in two hours' effort.

Everything has been changed since then. For example I had no grey hair in 2006 Maybe I return to it later. But it is a challenge for sure.

[FranceBB]

Yeah, I know.
It's a shame that they haven't updated anything since 2006 and I'm also sad to see it failing to compile while targeting new Avisynth+ headers...

Unfortunately, I used to rely on those upmix methods a lot in the past, in particular when I had to insert like distribution bumpers etc in what would otherwise be a 5.1 movie or tv series etc before creating the final DCP and send it over to the cinemas.
Nowadays, ever since it stopped working with newer versions of AVS, I used the surround filter in FFMpeg like:

ffmpeg.exe -i "New File (25).avs" -af surround=chl_in=stereo:chl_out=5.1:level_in=1:level_out=1:lfe_low=3:lfe_high=128:win_func=hann -acodec pcm_s24le -ar 48000 -y "out.wav"

pause

however ideally in the future I'd like to go back doing everything inside Avisynth like I used to.
Someone should really pick up the Sox filters and properly maintain them instead of leaving them in the Avisynth 2.5 abandonware...