AviSynth+ thread Vol.2

[Reel.Deel]

Should be "Reel.Deel" ?

Either one works. On GitHub and the AviSynth wiki my handle is with an A. Edit: I guess if I want to be picky, reel is always with 2 Es :D

----

This r3912 version broke high bit format, the following script: SetMemoryMax(192)
AviSource("Dark_Crystal_HDR_16b.avi")
ConverttoYUV444()
doesn't work anymore :(, my avi file is utvideo yuv422p10le.

The AvisynthPlus_3.7.3_20230118_test3 is working.

I can't open the avs file in Virtualdub2 anymore.

Unknow or unsupported video format.


Not exactly the same as yours but no error message with the script below with 3.7.3 test 5 (r3931).

SetMemoryMax(192)
ColorBars(1920, 1080, pixel_type="YUV420P10")
ConverttoYUV444()

[jpsdr]

The issue is not with the convert but with the AVISource.
My bad, i should have been more explicit.
I have to redo the test with test5 now.

[pinterf]

Still crashing for me, narrowed down things as much as I think I can do.

ffdshow added as an external filter in media player - Avisynth box ticked in ffdshow, blank code in the code box (no filters loaded at all), YV12 ticked in ffdshow as input colorspace, that's it.

Windows 11 22H2, i5 10400F 16GB.
Yes. For some reason test1 is OK, test2 is not.

[pinterf]

Yes. For some reason test1 is OK, test2 is not.
Fixed, test6 is coming soon.

[pinterf]

Avisynth+ 3.7.3 test 6 (20230218) (https://drive.google.com/uc?export=download&id=1MwIRCk65Gtto7qdWjaD1zlc47G0gRACD)
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

SincLin2Resize "cii[src_left]f[src_top]f[src_width]f[src_height]f[taps]i"
parameters like SincFilter or LanczosFilter: optional "taps"
Default taps=15

UserDefined2Resize "cii[b]f[c]f[src_left]f[src_top]f[src_width]f[src_height]f"
parameters like BicubicResize: Optional "b" and "c"
Default b=121.0, c=19.0

and their equivalent for the ConvertToXXXX family:
"sinpow", "sinclin2" and "userdefined2"

- Add "param1" and "param2" to ConvertToXXXX where "chromaresample" parameter exists.
Now it is possible to use chromaresample with nondefault settings.

param1 will set 'taps', 'b', or 'p', while param2 sets 'c' parameter for resizers where applicable.

b,c: bicubic (1/3.0, 1/3.0), userdefined2 (121.0, 19.0)
taps: lanczos (3), blackman (4), sinc (4), sinclin2 (15)
p: gauss (30.0), sinpow (2.5)
'param1' and 'param2' are always float. For 'taps' 'param1' is truncated to integer internally.
When a resizer does not use parameters they are simply ignored.
- Add avs_video_frame_get_pixel_type and avs_video_frame_amend_pixel_type to C interface as well
- Fix (#327) Histogram "color2" markers. Fix right shifted 15 degree dots, fix square for bits>8
- Feature (#317): (V10 interface) The color format of a VideoFrame can now be retrieved with its GetPixelType()
function. Before, there was no reliable way of knowing it on a frame from propGetFrame().
The internally stored pixel_type in VideoFrame is properly converted upon a Subframe (Y8-32), SubframePlanar (strip alpha).
- Feature (#317): (V10 interface) added ``VideoFrame::AmendPixelType`` and ``avs_video_frame_amend_pixel_type``.
Introduced in order to keep VideoInfo and VideoFrame pixel_type synchronized for special cases:
when filter constructor would just change ``VideoInfo::pixel_type``, but the frame would be passed w/o any change, like in ``ConvertFromDoubleWidth`` or ``CombinePlanes``.
- Feature (#314): Added AVSValue::GetType()
Returns an AvsValueType enum directly, one can use it instead of calling all IsXXX functions to establish the type. (Rust use case)
- Enhancement (#314): (avisynth.h) Gave all enums of public C++ API a name, and added DEFAULT_PLANE to AvsPlane (also in C API).
- Fix (#314): (avisynth.h) Changed NewVideoFrameP() property source argument to const in accordance with copyFrameProps(), since it's not meant to be written
Fixed in C interface as well: avs_new_video_frame_p and avs_new_video_frame_p_a: prop_src argument now const (no change in use)
- Enhancement (#314): Made VideoFrameBuffer destructor public like in other classes of the public API to prevent compiler errors downstream when calling non-const member functions
- "Text" new parameter: "placement" for chroma location hint
- Used in subsampled YUV formats, otherwise ignored.
- Valid values for "placement" are the same as in ChromaInPlacement and
ChromaOutPlacement in the Convert functions.
- Meaningful values: "center", "left", "auto" at the moment
- Default value is
- read from "_ChromaLocation" frame property, otherwise "left"
- override or set from "placement" parameter if parameter is other than "auto"
- if "auto" + have frame property -> use frame property
- if "auto" + no frame property -> use "left"
- no frame property and no parameter -> use "left"
- Only "center" and "left" is implemented. (center is known as jpeg or mpeg1, left is known as mpeg2)
If "center" is given directly or read from frame property, it will be used.
Otherwise "Text" renders chroma as "left" (mpeg2)
- "Text": Almost fully rewritten.
(#310) Support any width of bdf fonts (but still of fixed width)
Render in YUY2 is as nice as in YV16
Halo is not limited to original character matrix boundaries
Halo is not character based, but rendered on the displayed string as a whole.
Some speed enhancements, mainly for subsampled formats and outlined (with halo) styles
- Enhancement (#315): Show exception message as well if a v2.6-style plugin throws AvisynthError in its
AvisynthPluginInit3() instead of only "'xy.dll' cannot be used as a plugin for AviSynth."
- "Text": draw rightmost on-screen character even if only partially visible (was: not drawn at all)
- "Text": support more from the BDF standard (issue #310): per-character boundary boxes and shifts
- "Text" (#310): support 17-32 pixel wide external BDF fonts (issue #310)
- Fix: "Text" rounding negative x or y coordinates (e.g. x=-1 resulted in 0 instead of -1)
- Fix: "Text" would omit last character when x<0
- Fix: "Text" halo_color needs only MSB=$FF and not the exact $FF000000 constant for fade
- "Text" ``halo_color`` allows to have both halo and shaded background when halo_color MSB=$FE
- "Text" much nicer rendering of subsampled formats (#308)
- CMakeLists.txt: add support for Intel C++ Compiler 2022
- Address Issue #305: Support for non-decorated avisynth_c_plugin_init in 32 bit C-plugins
- Huge documentation update by Reel-Deal
- Fix (#304): ColorYUV analyze=true was displaying wrong min-max values for YUY2
- Fix: C API undefined behavior when upstream throw runtime error
(released in test2, fixed in test6 - ffdshow crash)
- Mute compilation warnings in avisynth.h
- CMakeLists.txt: fix clang-cl/intel with ninja generator
- Fix (#293): "Text" to throw proper error message if the specified font name (e.g. Arial) is not found among internal bitmap fonts.
- Fix (#293): "Subtitle" and "Text" filter to respect the explicitely given coorditanes for y=-1 or x=-1,
instead of applying vertical/horizontal center alignment.
- Fix: C interface crash when using avs_new_video_frame_p(_a)
- Fix (#283): broken runtime functions min/max/minmaxdifference when threshold is not 0 (returned -1). Regression in 3.7.2
- New: add a sixth array element to PlaneMinMaxStats: average. Defines variable "PlaneStats_average" as well if setting variables is required.
- Fix (#282): ConvertToRGB
- do check for exact 8 or 16 bit input, because packed RGB formats exist only for 8 and 16 bits
- keep alpha for RGBA planar - convert RGBAP8/16 to RGB32/64, while RGBP8/16 is still RGB24/48

[Dogway]

- Add "param1" and "param2" to ConvertToXXXX where "chromaresample" parameter exists.
Thanks for the update! Wasn't expecting this, it will come very useful for perf optimizations.

[ryrynz]

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


Thank you, all good now.

[kedautinh12]

AviSynthPlus r3935 clang build
https://gitlab.com/uvz/AviSynthPlus-Builds

[jpsdr]

I again have the same issue, the following script:
SetMemoryMax(192)
AviSource("frame_divide_count_2.avi")

where the video is yuv422p10le of utvideo gives me the following error:File open error
AVI Import Filter error: (unknow) (80040154) when i try to open it with VirtualDub2.

The issue is specific to the clang builds. It happens with the r3935 and r3912.
The test3, test5 and test6 files provided by Pinterf work fine, so i think there is something wrong with the clang builds, it doesn't seem to be an avisynth issue.

[pinterf]

I again have the same issue, the following script:
SetMemoryMax(192)
AviSource("frame_divide_count_2.avi")

where the video is yuv422p10le of utvideo gives me the following error: when i try to open it with VirtualDub2.

The issue is specific to the clang builds. It happens with the r3935 and r3912.
The test3, test5 and test6 files provided by Pinterf work fine, so i think there is something wrong with the clang builds, it doesn't seem to be an avisynth issue.
Hi jpsdr!

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

Crash occured when P10 or P16 format was exported on AVI interface (which VirtualDub is using)

Reason: clang build was using an aligned store operation, but the pitch of the target was not dividable by 16, so exporting the second row failed immediately.
MSVC builds compiled an unaligned store at that place, this is why it did not crash.

Thanks for the report.

[Reel.Deel]

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 :p

[kedautinh12]

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

[kedautinh12]

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

Yes, i like optimize ver of all plugins :D

[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) (https://drive.google.com/uc?export=download&id=1dKBH5DM6RwNSBBwdEoB-weg50I_whTEm)
Changes since test6
20230223 3.7.3 WIP
------------------
- Update build documentation with 2023 Intel C++ tools. See Compiling Avisynth+
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/contributing/compiling_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.php?p=1983343#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 :p.

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]

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/1ds4x-63WnpT905nZVcbnELMfHKj3Cr_w/view?usp=sharing

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

[Fjord]

Why not. Done, it will appear in the next build.
Thank you! You and all the devs are fantastic. :thanks:

[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]

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

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

[Reel.Deel]

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

Already implemented since test 6.


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]

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.php?p=1983080#post1983080 and https://forum.doom9.org/showthread.php?p=1983119#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.

https://i.imgur.com/QOjD6dG.png

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]

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]

...
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 (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ksmedia/ns-ksmedia-ksaudio_channel_config) instead NumChannels (than can be calculated from MaskChannels)

[pinterf]

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.

https://i.imgur.com/QOjD6dG.png

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

https://i.imgur.com/XHWSZ7A.png


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... :(

[jpsdr]

Problem found and maybe fixed. A sample or telling the dimensions of your video would helped a lot :)
:thanks:

3840x1608
Sorry, i didn't thought about it, i was too much focussed on just the format part.
I can PM you my ftp server information and put the video on it if necessary, it's "small", less than 100 frames, it's was just a small thing for test purpose.

[pinterf]

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... :(

Someone should really pick up the Sox filters and properly maintain them instead of leaving them in the Avisynth 2.5 abandonware... :(
Just wait and you'll see :)

[jpsdr]

Out of curiousity, why the Clang and Intel build don't have the DirectShowSource plugin ?

[kedautinh12]

Out of curiousity, why the Clang and Intel build don't have the DirectShowSource plugin ?

Cause Directshowsource don't had any change very long. So can got from old ver avs+

[Reel.Deel]

Cause Directshowsource don't had any change very long. So can got from old ver avs+

Other core plugins have not been updated in sometime also but yet they are always recompiled. So there's probably a good reason why DirectShowSource is not included in the Clang and Intel builds.

[qyot27]

DirectShowSource does not get built by default, you have to specifically opt-in to build it (https://github.com/AviSynth/AviSynthPlus/blob/master/plugins/CMakeLists.txt). This is intentional, because unlike the other core plugins, DSS has a dependency on the DirectShow baseclasses library that, for whatever reason, is not part of a default install of either MSVC or the DirectX SDK. You have to build that library from the SDK samples, and because that's so non-intuitive (and because DSS should only ever be used as a last resort), it's better to leave it off by default so it doesn't impede the build process. Not to mention that for MinGW-w64/GCC builds, the MSVC-built baseclasses library is *probably* a no-go. There is something of a port of the baseclasses library to MinGW, but because DirectShowSource doesn't build with GCC, there's not really any way of vetting whether it works as intended.

That's not even touching the question of whether Clang or Intel compilers can build the baseclasses library at all, although I would assume that they can at least link to an existing build of it just fine ('Clang' in this case being assumed to be the clang-cl MSVC compatibility frontend, not the regular version of Clang that uses GCC's conventions).

[kedautinh12]

Other core plugins have not been updated in sometime also but yet they are always recompiled. So there's probably a good reason why DirectShowSource is not included in the Clang and Intel builds.

I don't know but when Pinterf still use old date directshowsource.dll in his new build

[jpsdr]

Problem found and maybe fixed.
Tested the clang git build r3950, still the issue, so it's probably not pushed yet.

[pinterf]

Tested the clang git build r3950, still the issue, so it's probably not pushed yet.
It's pushed; could you upload your sample clip fragment?

[jpsdr]

It's pushed; could you upload your sample clip fragment?

I've PM you informations.

[jpsdr]

Ok, i made more tests.

When i test a new avs+ version, i always do the same thing : open in VirtualDub2 the same avs file reading the same 10bit422 UTVideo file.
When VDub2 throw me an error message (it wasn't a crash), i thought there was an issue with AVISource in the clang build.
Well... There was indeed an issue in AVISource, but this was a fluke. As, for me, it wasn't a crash.

So i finaly thought to test with AVSMeter, result was "error, unable to load avisynth.dll"... Ah....:confused:
So i tried with Virtualdub (not VDub2) to open others avs files reading "nice" 8 bits avi. Same error message. Same thing x86 or x64 version.

Result is that clang and Intel version, from both r3950 git and Test7 zip file are not running at all, x86 or x64. It seems to be a build issue.
Or... is there some redistributable needed ?
I allready have the Intel 20.0.311 redistributable installed...

[pinterf]

Ok, i made more tests.

So i finaly thought to test with AVSMeter, result was "error, unable to load avisynth.dll"... Ah....:confused:
So i tried with Virtualdub (not VDub2) to open others avs files reading "nice" 8 bits avi. Same error message. Same thing x86 or x64 version.

Result is that clang and Intel version, from both r3950 git and Test7 zip file are not running at all, x86 or x64. It seems to be a build issue.
Or... is there some redistributable needed ?
I allready have the Intel 20.0.311 redistributable installed...
Strange, temporarily I'd try to get rid of all autoloaded plugins, move them away, to make sure if one of them is making avisynth crash when loading. I don't have any other idea. My avsmeter is 3.0.0.4, and happily consumes any avisynth version

[pinterf]

Just wait and you'll see :)
When you spend ~40 hours on understanding what sox really is and slowly get the latest sox library work again, test its various filters, and then try UpSoundOnSound which is using the same SoxFilter'ed clip four times, and realize that Avisynth+ has NO audio cache implemented... The feeling is priceless.

[DTL]

It looks GeneralConvolution() is somehow broken between 201x and 202x years.

In old decade

GeneralConvolution(0, "
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 37 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true, luma=true, chroma=false)

Make some sharpening effect on more medium frequencies in compare with Sharpen() because Sharpen use only 3x3 kernel. Now it return significantly distorted frame with lots of banding. The sum of coefficients is =1 so auto=true/false do nothing.

For simple YV12 format. Tried RGB32, tried 16bit.
At Windows7 tried AVS versions from 2.6 to +3.6 , +3.7 and still the same distortion. May be GeneralConvolution depends on some updated VisualC++ libs or other windows7 components ?


Here most simple form of bug with GeneralConvolution:

GeneralConvolution(0, "
-0.4 -2 -0.4
-2 9 -2
-0.4 -2 -0.4", auto=true, luma=true, chroma=false)

Make sharpening about as expected.

GeneralConvolution(0, "
-0.5 -2 -0.5
-2 9 -2
-0.5 -2 -0.5", auto=true, luma=true, chroma=false)

Turn to significant blurring. The switch from about good to significantly bad result occur when diagonal angle coefficients of simplest 3x3 matrix go from -0.4 to -0.5. Looks like some rounding or auto-normalization error ?

Same is with documentation example:
GeneralConvolution(0, "
-0.4 -1 -0.4
-1 5 -1
-0.4 -1 -0.4 ", auto=true, luma=true, chroma=false)
Still make sharpening as expected.

GeneralConvolution(0, "
-0.5 -1 -0.5
-1 5 -1
-0.5 -1 -0.5 ", auto=true, luma=true, chroma=false)
Switch to very blurry.

Same result with 3.7.2 release, 3.7.3 test 7 x64, x64_xp (x64_clang and x64_IntelClassic not work with AVI import filter error).

[FranceBB]

When you spend ~40 hours on understanding what sox really is and slowly get the latest sox library work again

:)


test its various filters, and then try UpSoundOnSound

:D



, and realize that Avisynth+ has NO audio cache implemented...

:scared:


Jokes aside, thank you so so so much for taking a look at this. It means the world to me and I'm really grateful to see how every time I highlight something you always go above and beyond to get it working.
We're really lucky to have you in this community, Ferenc! I mean it.

[wonkey_monkey]

Looks like some rounding


Not sure about the rest of your trouble with GeneralConvolution but bear in mind that the Wiki states:

float values are converted to integers for 8-16 bit clips

So -0.5->-1, and -0.4->0.

[DTL]

Kernel of 5 at the center and -1 surround also should not be blur kernel. Now the significant discontinuity in output effect from corners kernel members 0 to -1 also not look like correct action. If even floats not accepted it is only expected more significant step from light sharp with
0 -1 0
-1 5 -1
0 -1 0

to stronger sharp with
-1 -1 -1
-1 5 -1
-1 -1 -1.

But now last kernel cause switching to blur. The visible difference - sum of 1st kernel is 5+(-4)=1 and sum of last is 5+(-8)=-3. May this negative sum sign also play role in the issue ?

Checked (YV12 8bit 4:2:0):
-1 -1 -1
-1 5 -1
-1 -1 -1 - blur

-1 -1 -1
-1 6 -1
-1 -1 -1 - slightly sharper

-1 -1 -1
-1 7 -1
-1 -1 -1 - sharper, horizontal and vertical double contour

-1 -1 -1
-1 8 -1
-1 -1 -1 - almost black frame ! (zero sum), still auto=true

-1 -1 -1
-1 9 -1
-1 -1 -1 - finally sharping, auto=true/false - equally.

-1 -1 -1
-1 10 -1
-1 -1 -1 (auto=true - less sharp, auto=false - significant level offset to white)

So auto=true do not work with zero and negative integer sum ?

But kernel of 5x5 of
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 37 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true,

with sum=1 still return sort of HigiPassFilter only with about removed DC component and very low frequencies. DC component (median level and very low frequecies) start to recover to about
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 45 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true,

45..50..60 value of the 'central' value. So sum is much higher 1. With auto=false and center 80 - return white frame. May be something is changed in 'auto=true' internal processing ?

Attempt to float32:
ConvertBits(32)
GeneralConvolution(0, "
-1 -1 -1
-1 5 -1
-1 -1 -1 ", auto=true, luma=true, chroma=false)
ConvertBits(8)

change nothing from 8bit luma - still blur.

So it looks logic of GeneralConvolution kernel coefficients processing is changed somehow and now for 'sharp' kernels the total sum must be >>1 and only auto=true is working ?
For example now about good linear sharpener is
GeneralConvolution(0, "
-1 -2 -2 -2 -1
-2 -2 -3 -2 -2
-2 -3 70 -3 -2
-2 -2 -3 -2 -2
-1 -2 -2 -2 -1", auto=true, luma=true, chroma=false) - result demo https://imgsli.com/MTYxNDkz
And adjusting center member in range about 60..100 it is now possible to adjust 'strength'. Where 60 is very strong, 100 is very weak and 50 is sort of high-pass filter only. May it is also valuable mode but it looks old versions work differently and old matrices require re-adjustment of 'center' member.

[wonkey_monkey]

So auto=true do not work with zero and negative integer sum ?

auto is disabled when the sum is zero. If the sum is negative, then it divides by that negative sum, and I think that's where it's not behaving as you'd expect. But it is behaving correctly. I put the same maths through a different filter and got the same result.

The negative sum means the pixel with the positive value (the center one) makes a negative contribution to the output, while the surrounding negative coefficient pixels end up making a positive contribution. And the negative contribution of the center pixel is smaller than the positive contribution of the surrounding pixels, so the result looks like a blur.

[DTL]

May be auto (normalizing) not needed when sum=1 ? Typical kernel normalizing process is:
1. calculate sum of all members.
2. divide each member to sum.

Convolution with kernel with sum=1 at least keep DC and very low frequencies components unchanged.

[ryrynz]

:)
We're really lucky to have you in this community, Ferenc! I mean it.

Ferenc needs to have his details in the forum changed from "Registered User" to Avisynth GOAT.