AviSynth+ thread Vol.2

[DTL]

Need some ideas about available Avisynth API about configurable multi-frame requesting between MDegrain and MAnalyse: https://forum.doom9.org/showthread.php?p=1960022#post1960022

With ability of MAnalyse to process several src-ref pairs with hardware accelerator and to balance load of CPU/HW_acc with motion search and degrain work it require to configure >1 src-ref pairs (motion search 'frames') requested from MAnalyse by MDegrain. What are the best solutions possible with current Avisynth inbetween filters API ? Can sink filter ask several frames from source at once or special hacks required to ask for > 1 frames in one call ?

May be possible solution is only to use several MAnalyse objects per one MDegrain so MDegrain can call GetFrame from >1 MAnalyse in parallel ?

[Nuihc88]

What is the status of VFR (variable framerate) support?

I went thru a VFR anime with 23.976/29.97 sequences and I really don't know if AVS can handle it in the proper way.

Now that we have frame properties, it could become an interest thing.

I'd like to know about this as well.

I've been trying make more advanced realtime frame interpolation scripts both by DeDupping+Interpolating (https://forum.doom9.org/showthread.php?p=1930740#post1930740) & Interpolating over Dupe-ranges (https://forum.doom9.org/showthread.php?p=1947800#post1947800), but keep hitting roadblocks with either functionality or speed depending on the approach.

Support for Variable Frame Rates would open up new ways of addressing both of my problems.

[pinterf]

I don't think that might work, at least for my CPU (4C/8T) maxing threads to 8 performs worse than with 4, with whatever 'frames' I set it to.

For example (always from my CPU POV) internal resizers perform best with Prefetch(6), pixel addressing with Prefetch(4), mathematical expressions with Prefetch(6), and heavy functions like QTGMC with many expression calls Prefetch(8).

Now if you think you can take the best of both worlds and do:
ex_median()
Prefetch(4)
BicubicResize()
Prefetch(6)

It will actually perform much worse than with a single final Prefetch with 4 or 6, 6 being faster but as I said not optimal for the resizer.

I will run some benchmarks later.
There were issues with multiple Prefetchers which were probably fixed in recent days, I built no test version since then.

[Dogway]

So the optimal performance for a given filter (after the last Prefetch refactor) is to set its MT mode (normally this is autoregistered) and pair it with an optimal Prefetch value, depending on CPU (cores, threads).

I would like to think that then the Prefetch value should also be autoregistered into the plugin for always an optimal performance (and script clearance) but I guess this dependes on many factors.

For example it would be a good experiment for someone with 8C/16C or more and test three types of filters each time with different configuration of Cores/Threads. I recommend to run the filter twice to also test memory transfer.

SourceFilter() # Test with several loaders, FFMS2, LSmash and DGDecNV

BicubicResize()
BicubicResize() # known to perform best in P(4) for 4C/8T

Expr() # some expression with trascendentals
Expr() # some expression with trascendentals # known to perform best in P(6) for 4C/8T

ex_median("median7")
ex_median("median7") # a simple filter known to perform best in P(8) for 4C/8T

[pinterf]

I don't think filter writers can guess the optimal multithreading level. You have to experiment it on your actual PC/script when you need further percents. Too many important factors: actual video resolution, processor cache size, is script using filters with internal MT or not. Then the output side: encoding settings. Manufacturer AMD or Intel, OS Windows or Linux, other parallel tasks your PC/laptop is doing in the background.

[Dogway]

I know but it looks to me that there are a few evidences that certain filters work better with a different Prefetch() configuration than others. Scalers are one of these (typical used in pairs for super or undersampling) and other ones yet to test. I'm not saying true or false but that a global benchmark with some core filters (scalers, algebra expressions, convolutions) would tell us something. I mean, stacking two BicubicResize() and needing to use Prefetch(4) looks suspicious. Other users can test as well.

Source 1080p@16-bit (DGSource)

BicubicResize(1280,720)
BicubicResize(1920,1080) # 340 P(4) 300 P(6) 285 P(8) 280 P(8,8) 250 P(8,12) 305 P(8,4)

[pinterf]

See my results, but with BlankClip.

It is not a real-life result but it shows better how the filters alone behave.

I guess the slowdown you are seeing (P8 is slower than P4) is not because of the resizers but how the source filter gets requests.

As I experienced earlier, out-of-sequential order requests from source filter affect hugely the performance. In MT environment, when the Prefetcher works in the background parallel with a the final consumer (this time an AvsMeter64) it can easily happen that at specific timing conditions consumer overtakes Prefetcher and the source filter is seeing fluctuating frame requests e.g. 1,2,3,4,5,7,8,6,9,10,11,13,14,12,...

BlankClip(100000, 1920, 1080, pixel_type="YUV420P16")
BicubicResize(1280,720)
BicubicResize(1920,1080) # 340 P(4) 300 P(6) 285 P(8) 280 P(8,8) 250 P(8,12) 305 P(8,4)
Prefetch(8,4)
/*
i7-7700 (Core 4 Thread 8)
685 (48%) P(4)
734 (71%) P(6)
740 (85%) P(8)
742 (84%) P(8,8)
743 (86%) P(8,12)
690 (44%) P(8,4)
*/

[pinterf]

Or in your configuration the memory bandwidth and cache usage are getting their penalty earlier than in my test.

[DTL]

Current CPUs with set-associative caches and current SDRAMs can not provide stable performance with not-equal addresses of data in RAM in different runs. Depending on addresses values the performance of caches and SDRAM will change. And typical 'new' universal object-oriented programming way of memory request from OS can not guarantee equal addresses relative to cache structure and SDRAM structure. Also fragmenting of virtual memory change placement of virtual pages on physical SDRAM even with equal virtual addresses. So it may require many test runs to found some 'stable' performance change.

Though SDRAM-page miss possibly rare and lower performance penalty in compare with cache set ways exhausting. It blocks cache activity IMHO close to completely even with still lots of empty lines available in different sets and drop performance to RAM-only.

[Dogway]

That made a difference. But since Prefetch() couldn't be used several times I used RequestLinear().

RequestLinear(50)
BicubicResize(1280,720)
BicubicResize(1920,1080) # 510 P(4) 480 P(8,4) 530 P(8,8)

Unfortunately cannot test latest LSmash, and FFMS2 is too slow to make a point. Still need to update to latest DGSource, in case there are changes.

[kedautinh12]

That made a difference. But since Prefetch() couldn't be used several times I used RequestLinear().

RequestLinear(50)
BicubicResize(1280,720)
BicubicResize(1920,1080) # 510 P(4) 480 P(8,4) 530 P(8,8)

Unfortunately cannot test latest LSmash, and FFMS2 is too slow to make a point. Still need to update to latest DGSource, in case there are changes.

I still use LSmash latest ver with latest avs+ normally

[Boulder]

Still need to update to latest DGSource, in case there are changes.
None of the source filters utilize Prefetch, so updating DGSource won't change anything.

Prefetch does have some problems compared to Vapoursynth's multithreading method. The Zopti thread contains some of my test results, I was unable to use the AVS version like I can use the VS one.

https://forum.doom9.org/showthread.php?t=175723&page=6

[videoh]

None of the source filters utilize Prefetch, so updating DGSource won't change anything. Also, nothing in DGSource() affecting performance has been changed for a very long time.

[real.finder]

None of the source filters utilize Prefetch, so updating DGSource won't change anything.

Prefetch does have some problems compared to Vapoursynth's multithreading method. The Zopti thread contains some of my test results, I was unable to use the AVS version like I can use the VS one.

https://forum.doom9.org/showthread.php?t=175723&page=6

not just source filters https://github.com/AviSynth/AviSynthPlus/issues/229

[qyot27]

AviSynth+ 3.7.1 has been released (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.1).

So yeah, getting this out by New Year's, at least. Windows installers and filesonly (including for Windows 10 on ARM) and macOS 10.13+ filesonly are available (10.15+ builds and installers will come later).

Additions:

- Linux: Show more information when dlopen fails
- Expr: allow auto scaling effect on pixels obtained from relative addressing
- New array manipulators: ArrayDel, ArrayAdd, ArrayIns, ArraySet with accepting multi dimensional indexes
- ExtractY/U/V/R/G/B/A, PlaneToY: delete _ChromaLocation property. Set _ColorRange property to "full" if source is Alpha plane
- Add new AEP (Avisynth Environtment Property) constants to directly query Avisynth interface main and bugfix version and system endianness:
AEP_HOST_SYSTEM_ENDIANNESS, AEP_INTERFACE_VERSION, AEP_INTERFACE_BUGFIX (c++)
AVS_AEP_HOST_SYSTEM_ENDIANNESS, AVS_AEP_INTERFACE_VERSION, AVS_AEP_INTERFACE_BUGFIX (c)
- Interface: introduce AVISYNTHPLUS_INTERFACE_BUGFIX_VERSION.
- New interface functions env->MakePropertyWritable/VideoFrame::IsPropertyWritable.
- Expr: allow 'f32' as internal autoscale target (was: i8, i10, i12, i14, i16 were accepted, only integers)
- Expr: LUT mode! 'lut'=1 or 2 for 1D (lut_x) and 2D (lux_xy) support
- xPlaneMin/Max/Median/MinMaxDifference to accept old packed formats (RGB24/32/48/64 and YUY2) by autoconverting them to Planar RGB or YV16
- New runtime function: PlaneMinMaxStats returns an array and/or set global variables.
- Language syntax: accept arrays in the place of "val" script function parameter type regardless of being named or unnamed.
- Histogram "Levels": more precise drawing when bit depth is different from histogram's resolution bit depth, plus using full/limited flag.
- Expr: no more banker's rounding when converting back float result to integer pixels. Using the usual truncate(x+0.5) rounding method
- ColorYUV: More consistent and accurate output across different color spaces, match with ConvertBits fulls-fulld conversions
- ColorYUV: set _ColorRange frame property
- ColorYUV: when no hint is given by parameter "levels" then it can use _ColorRange (limited/full) frame property for establishing source range for gamma
- ColorYUV "showyuv_fullrange"=true: fix shown U and V ranges. E.g. for bits=8: 128 +/- 127 (range 1..255 is shown) instead of 0..255
- propShow: display _Matrix, _ColorRange and _ChromaLocation constants with friendly names
- Expr: new function "sgn". Returns -1 when x is negative; 0 if zero; 1 when x is positive
- Expr: add "neg": negates stack top: a = -a
- ConvertBits: Support YUY2 (by autoconverting to and from YV16), support YV411
- ConvertBits: "bits" parameter is not compulsory, since bit depth can stay as it was before. Call like ConvertBits(fulld=true)
- ConvertBits: much nicer output for low bit depth targets such as dither_bits 1 to 7.
- ConvertBits: allow dither down from 8 bit sources by giving a lower dither_bits value
- ConvertBits: dither=1 (Floyd-S) to support dither_bits = 1 to 16 (similar to ordered dither)
- ConvertBits: dither=0 (ordered) to allow odd dither_bits values. Any dither_bits=1 to 16 (was: 2,4,6,8,..)
- ConvertBits: dither=0 (ordered) allow larger than 8 bit difference when dither_bits is less than 8.
- ConvertBits: Correct conversion of full-range chroma at 8-16 bits. Like 128+/-112 -> 128+/-127 in 8 bits
- ConvertBits: allow dither from 32 bits to 8-16 bits
- ConvertBits: allow different fulls fulld when converting between integer bit depths (was: they must have been the same)
- ConvertBits: allow 32 bit to 32 bit conversion
- frame property support: _ChromaLocation in various filters (e.g. ConvertToYUV422)
- Support additional chroma locations "top", "bottom_left", "bottom"
- New syntax for "matrix" parameters (e.g. in ConvertToYUV444 old:"rec601" new "170m:l") which separate matrix and full/limited marker.
Old syntax is still valid but does not support all new matrix values.
- frame propery support: _Matrix and _ColorRange in various filters. New "matrix" string constants
- RGB<->YUV (YUY2) conversions: frame property support _Matrix and _ColorRange (_Primaries and _Transfer is not used at all yet)
- ConvertBits: use input frame property _ColorRange to detect full/limited range of input clip
- ColorBars, ColorBarsHD, BlankClip: set frame properties _ColorRange and _Matrix
- New function: propCopy to copy or merge frame properties from one clip to another.
- xxxPlaneMin xxxPlaneMax, xxxPlaneMinMaxDifference for 32 bit float formats:
when threshold is 0 then return real values instead of 0..1 (chroma -0.5..0.5) clamped histogram-based result
- Allow propGetXXX property getter functions called as normal functions, outside runtime. Frame number offset can be used.
- YUY2 RGB conversions now allow matrix "PC.2020" and "Rec2020"
- 4:2:2 conversions: allow ChromaInPlacement and ChromaOutPlacement:
Valid values: left/mpeg2, center/mpeg1/jpeg
- 4:2:0 conversions: new ChromaInPlacement and ChromaOutPlacement values:
top_left, left (alias to mpeg2), center (alias to mpeg1), jpeg (alias to mpeg1) (see http://avisynth.nl/index.php/Convert)
- Expr: atan2 (SIMD acceleration as well)
- Expr: sin and cos SIMD acceleration (SSE2 and AVX2) port from VapourSynth (Akarin et al.)
- Expr: x.framePropName syntax for injecting actual frame property values into expression
- Script functions to supports arrays with _nz type suffix. (one or more)
- Expr: arbitrary variable names (instead of single letters A..Z), up to 128 different one.
- Expr: add 'round', 'floor', 'ceil', 'trunc' operators (nearest integer, round down, round up, round to zero)
Acceleration requires at least SSE4.1 capable processor or else the whole expression is running in C mode.
- Recognize \\' and \\b and \\v in escaped (e"somethg") string literals (see http://avisynth.nl/index.php/The_full_AviSynth_grammar#Literals)
- Expr: allow TAB, CR and LF characters as whitespace in expression strings
- Clip types for propSet, propGet, add propSetClip, propGetClip
- Clip content support for propGetAsArray, propSetArray and propGetAll
- RGBAdjust: analyse=true 32 bit float support


Build environment, Interface:

- Added stubs for compiling on RISC-V and SPARC
- Visual Studio 2022: Add /fp:contract to compilation parameters (addition to /fp:precise)
- Check Visual Studio 2022, add build examples to documentation. Recognized: it has still an option to use v141_xp toolkit
- CMake build environment: older GCC can be used which knows only -std=c++-1z instead of c++17
- AviSynth programming interface V8.1 / V9:
Add 'MakePropertyWritable' to the IScriptEnvironment (CPP interface), avs_make_property_writable (C interface)
Add 'VideoFrame::IsPropertyWritable' (CPP interface), avs_is_property_writable (C interface)
- Info on Windows XP compatibility (must revert to an older Visual C++ Redistributable)
- CMake/source: Intel C++ Compiler 2021 and Intel C++ Compiler 19.2 support
- experimental! Fix CUDA plugin support on specific builds, add CMake support for the option.
- Fixes for building the core as a static library


Fixes:

- Fix: "Text" filter would crash when y coord is odd and format has vertical subsampling
- Fix: MinMax runtime filter family: check plane existance (e.g. error when requesting RPlaneMinMaxDifference on YV12)
- Fix: prevent x64 debug AviSynth builds from crashing in VirtualDub2 (opened through CAVIStreamSynth)
- Expr: fix conversion factor (+correct chroma scaling) when integer-to-integer full-scale automatic range scaling was required
- ColorYUV: fix 32 bit float output
- ColorYUV: fix display when showyuv=true and bits=32
- ConvertBits: "dither" parameter: type changed to integer. Why was it float? :)
- ConvertBits: Fix: fulls=true -> fulld=true 16->8 bit missing rounding
- Fix: Planar RGB 32 bit -> YUV matrix="PC.709"/"PC.601"/"PC.2020" resulted in greyscale image
- SelectRangeEvery: experimental fix on getting audio part (TomArrow; https://github.com/AviSynth/AviSynthPlus/issues/232)
- Fix: Overlay "blend" 10+ bit clips and "opacity"<1 would leave rightmost non-mod8 (10-16 bit format) or non-mod4 (32 bit format) pixels unprocessed.
- Fix: Overlay "blend" with exactly 16 bit clips and "opacity"<1 would treat large mask values as zero (when proc>=SSE4.1)
- Parser: proper error message when a script array is passed to a non-array named function argument
(e.g. foo(sigma=[1.1,1.1]) to [foo]f parameter signature)
- Fix: Expr: wrong constant folding optimization when ternary operator and Store-Only (like M^) operator is used together.
- ColorBars: fixed studio RGB values for -I and +Q for rgb pixel types
- ColorBarsHD: use BT.709-2 for +I (Pattern 2), not BT.601.
Also fixed Pattern 1 Green.Y to conform to SMPTE RP 219-1:2014 (133, not 134).
- Overlay mode "multiply": proper rounding in internal calculations
- Fix: ConvertAudio integer 32-to-8 bits C code garbage (regression in 3.7)
- Fix: ConvertAudio: float to 32 bit integer conversion max value glitch (regression in 3.7)
- Fix: Crash in ColorBars very first frame when followed by ResampleAudio
- Fix: frame property access from C interface
- Fix: StackVertical and packed RGB formats: get audio and parity from the first and not the last clip


Optimizations:

- Quicker ClearProperties and CopyProperties filters (by using MakePropertyWritable instead of MakeWritable).
- ConvertBits: AVX2 support
- ConvertBits: Special case for: 8->16 bit fulls=true, fulld=true
- Expr: consume less bytes on stack. 48x Expr call in sequence caused stack overflow
- xxxPlaneMin xxxPlaneMax, xxxPlaneMinMaxDifference for threshold 0 became a bit quicker for 8-16 bit formats (~10% on i7-7700)
- Speedup: Overlay mode "multiply": overlay clip is not converted to 4:4:4 internally when 420 or 422 subsampled format
(since only Y is used from that clip)
- Speedup: Overlay mode "multiply": SSE4.1 and AVX2 code (was: C only)
SSE4.1: ~1.2-2.5X speed, AVX2: ~2-3.5X speed (i7700 x64 single thread, depending on opacity full/not, mask clip yes/no)
- ConvertAudio: Add direct Float from/to 8/16 conversions (C,SSE2,AVX2)

[LigH]

:) Happy New Year!

[StainlessS]

:) Happy New Year!
+1 on that :)

Nice goin' guys, guess I is gonna havta learn it all from scratch again, one helluva lotta changes / improvements.

[tormento]

AviSynth+ 3.7.1 has been released
Thanks!

Is the x64 build CUDA aware?

Just to know if I can delete previous pinterf build or keep it.

[qyot27]

I did not enable CUDA on the release builds. For one [big] reason, I don't have an Nvidia GPU to verify that such a build functions correctly.

[pinterf]

Thanks!

Is the x64 build CUDA aware?

Just to know if I can delete previous pinterf build or keep it.

When you don't use or have built yourself those experimental Avs+ CUDA interface filters then you don't need it. My CUDA builds are not making anything quicker by default, CUDA is not used internally. These builds are just containing an interface extension with which such plugins can use Avisynth+ 'device' interface additions.

[pinterf]

qyot27, thank you for the release
Happy New Year for the community!

[Dogway]

Thanks for the release!

A few questions.
-Did the CombinePlanes optimization make it for this version? (is that the IsPropertyWritable fix?)
-Did the multiple Prefetch optimization make it for this version?
-This "ConvertBits: allow dither from 32 bits to 8-16 bits", I think 32-bit to 16-bit is not dithering but rounding
-Maybe also include the BlankClip array type for color arg (ie. [0,32768,32768]), not sure if it was a change within last and this, didn't find in any changelog.

[tormento]

CUDA is not used internally
I do know, thank you.

But it's a "nice to have" :)

[DTL]

CUDA is not used internally. These builds are just containing an interface extension with which such plugins can use Avisynth+ 'device' interface additions.

It may be big project addition - to add DirectX resources management in HW accelerator memory (using Microsoft API). Microsoft API is less manufacturer-dependent.

It support many enough different resources formats:
https://docs.microsoft.com/en-us/windows/win32/api/dxgiformat/ne-dxgiformat-dxgi_format and conversion may be with byte-manipulation without any math and lost speed or quality.

So some memory-limited filters can use much faster accelerator board memory and processing on accelerator.

May be add some 'upload' and 'download' commands to switch between host and accelerator memory data placement.
It may looks like ConvertTo functions:
ConvertToDXGI_XXX to upload resource to accelerator memory and
ConvertTo standard Avisynth format to download back to host memory.

[pinterf]

Thanks for the release!

A few questions.
-Did the CombinePlanes optimization make it for this version? (is that the IsPropertyWritable fix?)
-Did the multiple Prefetch optimization make it for this version?
-This "ConvertBits: allow dither from 32 bits to 8-16 bits", I think 32-bit to 16-bit is not dithering but rounding
-Maybe also include the BlankClip array type for color arg (ie. [0,32768,32768]), not sure if it was a change within last and this, didn't find in any changelog.
- yes, multiple Prefetcher fix is included
- yes, CombinePlanes geet the optimization of that very special case. (IsPropertyWritable/MakeProperyWritable are different things, they are programming interface additions which are used at some places where frame content does not need to be changed, and only frame properties are altered)
- yes (from 32 bit float to 16 bit integer there is zero dithering)
- BlankClip has 'colors' array parameter since the beginning of script array concept, it was just undocumented.

[pinterf]

It may be big project addition - to add DirectX resources management in HW accelerator memory (using Microsoft API). Microsoft API is less manufacturer-dependent.

It support many enough different resources formats:
https://docs.microsoft.com/en-us/windows/win32/api/dxgiformat/ne-dxgiformat-dxgi_format and conversion may be with byte-manipulation without any math and lost speed or quality.

So some memory-limited filters can use much faster accelerator board memory and processing on accelerator.

May be add some 'upload' and 'download' commands to switch between host and accelerator memory data placement.
It may looks like ConvertTo functions:
ConvertToDXGI_XXX to upload resource to accelerator memory and
ConvertTo standard Avisynth format to download back to host memory.
This must be planned carefully and must keep the logic of existing 'device' interface, similar to CUDA frame and memory transfer which is already implemented. OnCPU, OnCUDA, device types, filters capability queries, cache, SetMemoryMax, etc...

[DTL]

"similar to CUDA frame and memory transfer which is already implemented. "

May it can be copy of CUDA with a bit different names of resources ? May be Microsoft do not design completely new methods for the same hardware device.

[FranceBB]

Oh, stable build, nice!
What a way to celebrate the end of 2021.
Happy New Year, everyone!! :D

[Reel.Deel]

Thanks for the new release pinterf and qyot27. And happy new years :)

I think I found a bug 2 days ago:

Blankclip(width=352, height=288, pixel_type="YV12") # bug not related to dimensions
Histogram("audiolevels"))

The 0dB is cropped and the numbers and dB are no longer in the center of the dashes like they used to be:
https://i.ibb.co/TvqMzD5/histogram-audiolevels-bug.png (https://imgbb.com/) http://avisynth.nl/images/Histogram_audiolevels.jpg

Not sure when it happened but it used to look fine.

[pinterf]

Thanks for the new release pinterf and qyot27. And happy new years :)

I think I found a bug 2 days ago:

Blankclip(width=352, height=288, pixel_type="YV12") # bug not related to dimensions
Histogram("audiolevels"))

The 0dB is cropped and the numbers and dB are no longer in the center of the dashes like they used to be:

Not sure when it happened but it used to look fine.
Since 3.6 (Linux support, "Text" filter). The vertical coordinates were shifted up by 10 but the alignment was changed from center to none internally. Character height is 20, this is why there is a half character shift.
EDIT: fixed on git

[Reel.Deel]

Since 3.6 (Linux support, "Text" filter). The vertical coordinates were shifted up by 10 but the alignment was changed from center to none internally. Character height is 20, this is why there is a half character shift.

No wonder I did not noticed it earlier, I have not used "AudioLevels" in a while. Funny that you mention the Text filter, that is my next bug report :D

I compared the Text filter to FreeSub (http://avisynth.nl/index.php/FreeSub)and it seems the Text filter does not honor the transparency value.

Text | FreeSub
https://i.ibb.co/JQwYNXw/text-bug.png (https://ibb.co/jRPCd7P)

For the halo color the Text filter only reacts when it's 0 or 255, at 255 it draws the box around the text. And text color does not do anything with any transparency value, unless both halo and text color are at 255, which at that point does not render anything. I know the Filter is mainly intended for debugging purposes but it would be nice if it honored the transparency values. I like the box it draws around the text, maybe it would not be a bad idea to have another color parameter for it, that way we can control the text, halo, and box color.

Here's the bdf font file (https://files.videohelp.com/u/223002/ter-u18n.bdf) I used for FreeSub and here's the script:
Blankclip(color=$FDA50F, pixel_type="RGB24", width=170, height=115)

Text("TESTING", font="Terminus", x=10, y=10, text_color=$00FFFFFF, halo_color=$FF000000)
Text("TESTING", font="Terminus", x=10, y=30, text_color=$00FFFFFF, halo_color=$00000000)
Text("TESTING", font="Terminus", x=10, y=50, text_color=$00FFFFFF, halo_color=$80000000)
Text("TESTING", font="Terminus", x=10, y=70, text_color=$FFFFFFFF, halo_color=$00000000)
Text("TESTING", font="Terminus", x=10, y=90, text_color=$80FFFFFF, halo_color=$80000000)

Freesub("TESTING", font="ter-u18n.bdf", x=125, y=19, text_color=$00FFFFFF, halo_color=$FF000000)
Freesub("TESTING", font="ter-u18n.bdf", x=125, y=39, text_color=$00FFFFFF, halo_color=$00000000)
Freesub("TESTING", font="ter-u18n.bdf", x=125, y=59, text_color=$00FFFFFF, halo_color=$80000000)
Freesub("TESTING", font="ter-u18n.bdf", x=125, y=79, text_color=$FFFFFFFF, halo_color=$00000000)
Freesub("TESTING", font="ter-u18n.bdf", x=125, y=99, text_color=$80FFFFFF, halo_color=$80000000)

PointResize(width*4, height*4)

[pinterf]

Yes, "Text" is just a dumb debug filter using fixed size fonts, ignores real transparency. It was created quickly as a poor man's Subtitle, because under Linux we cannot use Windows GDI which is the core of SubTitle.
EDIT: Or I do not remember well.
I found this comment
halocolor MSB
- FF: fadeIt
- 01-FE: no halo
- 00: use halocolor

[Reel.Deel]

Thanks for the explanation pinterf. I will document those limitations.

Edit: So if the Text filter can't do transparency, how does it overlay the almost transparent box around the text? To match the same color I overlaid a black square onto the clip at .12 opacity (1F).

[pinterf]

Thanks for the explanation pinterf. I will document those limitations.

Edit: So if the Text filter can't do transparency, how does it overlay the almost transparent box around the text? To match the same color I overlaid a black square onto the clip at .12 opacity (1F).
Hardcoded and quick ratio. This or that ratio is used in almost all plugins that use some version of "info.h" for their debug displays.

https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/info.cpp#L636

[Dogway]

Thanks for feedback pinterf! I will test it then, specially the Prefetch() changes, I'm very intrigued.

Aside from LUT calculations with scaled down bitdepth (with scale_inputs) I would like to spot an usage issue I'm having with scale_inputs.
I think the setting would be better implemented as a decorator if it's possible. I'm doing some kind of crazy checks for some of my latest filters which involves different luma and chroma expressions, so for example you can have scaling in luma plane but not on chroma, or reverse.
Some examples:

16-bit source
expr("f32 x 2 ^", "x cmin - range_max cmax cmin - / *", scale_inputs="int")
This converts chroma to 8-bit, unless I explicitly add a protective decorator:
expr("f32 x 2 ^", "i16 x cmin - range_max cmax cmin - / *", scale_inputs="int")
Maybe to something like this:
expr("f32int x 2 ^", "x cmin - range_max cmax cmin - / *")

By the way, despite internal calculations done in float, the output chroma don't match in both versions.


Or simply copy the luma plane:
16-bit source
expr("x", "f32 x blabla ", scale_inputs="int")

This would scale the luma plane to 8-bit and back despite just wanting to copy it.

Also the 'floatUV' option makes it impossible to scale anything while wanting to shift chroma at the same time, so one has to explicitly shift it in expression which is slower.

[FranceBB]

The vertical coordinates were shifted up by 10 but the alignment was changed from center to none internally. Character height is 20, this is why there is a half character shift.

Dang it, it affects my VideoTek() :(


EDIT: fixed on git


I love you! :D
(in a friendly, figurative, non homo way xD)

[ryrynz]

(in a friendly, figurative, non homo way xD)

I think we're past needing to define love. Take whatever you can get lol.
Appreciate ur work Pinterf *wink*

[qyot27]

The macOS installers and filesonly archives are up now. I had to re-do the tarball for 10.13/14 because of some things I'd overlooked about how tar works. The new ones should be okay.

[gispos]

Before avisynth plus there were no problems with Pascal code and avisynth. I could open any text with 'Eval' and create a clip.

Since avisynth plus only 'AviSource' worked, so I couldn't pass any text with 'Eval' to create a clip.
But I could still open a script with AviSource.

And now the 64bit avisynth works anymore as soon as MCTemporalDenoise is called in the script the error 'Division by Zero' comes.
What has been changed please? The 'AviSource' still works perfectly with all the 64bit 3.71 test versions.

The last version that works without problems is 3.71 test 22. Everything else after that causes problems with prefetch. With the stable 3.71 there are no problems with prefetch, but I can no longer use it at all. Only the 32bit version works.

AvsPThumb has stopped working. I have a number of programs that I've been using for decades that no longer work.
It's horrible, I'm crying.

[Boulder]

Before avisynth plus there were no problems with Pascal code and avisynth. I could open any text with 'Eval' and create a clip.

Since avisynth plus only 'AviSource' worked, so I couldn't pass any text with 'Eval' to create a clip.
But I could still open a script with AviSource.

And now the 64bit avisynth works anymore as soon as MCTemporalDenoise is called in the script the error 'Division by Zero' comes.
What has been changed please? The 'AviSource' still works perfectly with all the 64bit 3.71 test versions.

The last version that works without problems is 3.71 test 22. Everything else after that causes problems with prefetch. With the stable 3.71 there are no problems with prefetch, but I can no longer use it at all. Only the 32bit version works.

AvsPThumb has stopped working. I have a number of programs that I've been using for decades that no longer work.
It's horrible, I'm crying.

It would be much easier to investigate the issue if you posted the simplest example scripts of how to reproduce the issue, and also link to any functions that you use in them.

[gispos]

It would be much easier to investigate the issue if you posted the simplest example scripts of how to reproduce the issue, and also link to any functions that you use in them.
As I wrote it, an 'Eval' with Pascal code has not worked for a long time. But now an invoke with 'AviSource' is no longer possible.
But that had worked with all Avisynth versions since Avisynth was born.


LWLibavVideoSource(SourceFile)
MCTemporalDenoise(settings="low", sigma=4, strength=100, tovershoot=1, GPU=false)


https://i.postimg.cc/5ysRVYv4/avisynth-error.jpg

[Boulder]

Did you check those scripts and the corresponding lines? That's why I asked for the links..

[gispos]

Did you check those scripts and the corresponding lines? That's why I asked for the links..

I can't find anything extraordinary when I look at the relevant places.

So far with Pascal code there were only problems with 'Eval' and 'Import' if MCTemporalDenoise was in the script.
With invoke ('AviSource', "test.avs') I could always open a script and that with all existing Avisynth versions.

But with the latest version nothing works anymore. No 'Eval', no 'Import' and no 'AviSource'

See also AvsPmod thread or here (https://forum.doom9.org/showthread.php?p=1959543#post1959543), since version 3.71 test 23 something went wrong.

[Boulder]

I'm baffled why any Pascal code would be related Avisynth internals. Did you try the latest official version with the installer (published just days ago)? And still, it would be good to see where you got those functions from.

[cretindesalpes]

The quoted line from GradFun2DBmod v1.5 contains the following:
mt_lut(expr="255 x 1 "+string(range)+" / * 2 ^ /",u=1,v=1)
It generates a div by 0 when the pixel value is 0 (probably something normal, at least it is part of the LUT entries) or when the range parameter is 0 (value checked by the script as legal). The code is already wrong twice, and the weird thing is why did it run without error before?

Maybe some exception handling has changed in MaskTools2 or Avisynth?

BTW what is this “Pascal code”?

[gispos]

The quoted line from GradFun2DBmod v1.5 contains the following:
mt_lut(expr="255 x 1 "+string(range)+" / * 2 ^ /",u=1,v=1)
It generates a div by 0 when the pixel value is 0 (probably something normal, at least it is part of the LUT entries) or when the range parameter is 0 (value checked by the script as legal). The code is already wrong twice, and the weird thing is why did it run without error before?

Maybe some exception handling has changed in MaskTools2 or Avisynth?

BTW what is this “Pascal code”?

Pascal code are programs written in Delphi.
And I get this error message when I want to use avisynth with a Delphi program.
In the past the error only came when I used 'Eval'. Now the error also comes with 'Eval' and 'AviSource'.

You have probably uncovered this dubious problem with 'MCTemporalDenoise' and programs with Pascal code.:thanks:
Why doesn't this error come with other programs? Very strange, AvsPmod or VirtualDub etc. show no errors.

Can someone please fix the faulty code in GradFun2DBmod.

[StainlessS]

Can someone please fix the faulty code in GradFun2DBmod.

Gispos, does this work ok. [I've never used that function, dont even know what it does].
FIXED: bad attempt removed
RPN = "x 0 == 255 255 x " + string(range) + " / 2 ^ / ?"

Infix = "x == 0 ? 255 : (255/((x/range)^2))"

With range=128
https://i.postimg.cc/520RBmcR/Range128.jpg (https://postimages.org/)

With range = 64
https://i.postimg.cc/rwPYQtMF/range64.jpg (https://postimages.org/)

With range = 32
https://i.postimg.cc/tJprY3tD/Range32.jpg (https://postimages.org/)

EDIT: Plotted with my Brain Dead Folly grapher thingy [stepping by 2, ie x = 0,2,4,6,8 etc, else my func crashes - my func memory prob {stack exhaustion}]

EDIT: Where 42 represents range, [we used dummy 42 so we can use Mt_polish and mt_Infix so we know where to replace the "string(range)" stuff]
We changed original INFIX "255/((x*(1/42))^2)"

To "255/((x/42)^2)"


And then added the fix,
"x == 0 ? 255 : (255/((x/42)^2))"

and convert back to RPN, and replace 42 with "string(range)" stuff.

So final, [without the div by zero when x == 0 ]

mt_lut(expr="x 0 == 255 255 x " + string(range) + " / 2 ^ / ?",u=1,v=1)


EDIT: Graphs are not very visible with white background, I use FireFox dark reader and they look fine.
EDIT: Re-did images.

EDIT:
(value checked by the script as legal).

Damn, I guess I did skim read that, I thought cretindesalpes meant that range=0 could not occur, I'll fix that problem too.
EDIT: Double damn, trickier than I thought, no idea how to fix the other divide by zero.

[gispos]

Damn, I guess I did skim read that, I thought cretindesalpes meant that range=0 could not occur, I'll fix that problem too.
EDIT: Double damn, trickier than I thought, no idea how to fix the other divide by zero.

:D Give your best. :) Thanks

[StainlessS]

Think this does it but a bit verbose, [R = range]


Infix = "255 / ((((x == 0) | (R == 0) ? 1 : x) / ((x == 0) | (R == 0) ? 1 : R)) ^ 2)"

RPN = "255 x 0 == R 0 == | 1 x ? x 0 == R 0 == | 1 R ? / 2 ^ /"


Somebody check it please. [dont bother, I'm pretty sure its right, and works fine in grapher]

When either x or R is 0, result is 255 [I hope :) ].

EDIT:

And then added the fix,
"x == 0 ? 255 : (255/((x/42)^2))"

Also, can somebody confirm or deny that if above x ==0 sets 255, but the remainder in white is still processed,
not 'short cut' skipped over or stripped from stack. [if 42 (range) is 0, there would still be a divide by zero] even with that earlier fix.

[Dogway]

Does it work if you limit it to epsilon?
range = max(range,0.001)
"255 x 1 " + string(range) + " / * 2 ^ 0.001 max /"