AviSynth+ thread Vol.2 [Archive] - Page 73

v0lt

31st January 2026, 18:31

I'd like to clarify the GetFrame method.
Older VSFilters didn't throw exceptions in GetFrame, and it simply didn't work. The newer xy-VSFilter raises a ThrowError if it doesn't support the video format (https://github.com/pinterf/xy-VSFilter/blob/053d9321541f73ffe2fe3900a7e356517fd44c03/src/filters/transform/vsfilter/plugins.cpp#L1280), which causes many applications (FFmpeg-based) to crash.
Example script.
LoadPlugin("c:\temp\XySubFilter\VSFilter.dll")

Colorbars(1280, 720)
ConvertToPlanarRGB()

TextSub("c:\temp\test_subtitles.srt")
In my ScriptSourceFilter, the call to PClip::GetFrame is inside a try-catch block (https://github.com/v0lt/ScriptSourceFilter/blob/4156b65eb64809a64f035b202851c8c8e7f7119b/Source/AviSynthStream.cpp#L194), but that doesn't help (or am I doing something wrong).

Is this an application issue or an xy-VSFilter issue?

wonkey_monkey

31st January 2026, 23:37

AvisynthError isn't derived from std::exception, so your code won't catch it (I think).

(Not sure why xy-VSFilter isn't checking the format in its constructor...)

v0lt

1st February 2026, 06:45

AvisynthError isn't derived from std::exception, so your code won't catch it (I think).
Thanks. I forgot about that again. I fixed it (https://github.com/v0lt/ScriptSourceFilter/commit/9a649e93c7c828fe9785f5b731bafc2f9d6e7731).

But this does not work with avformat_open_input (https://github.com/v0lt/avlib_vdplugin/blob/3392c6a03958a66bae63ddd5586e083b12ae591b/src/InputFile2.cpp#L725).

Added:
(Not sure why xy-VSFilter isn't checking the format in its constructor...)
Thanks. It works (https://github.com/v0lt/VSFilter/commit/182d0f395d62224bafae4e92de44893960c3456e)!

pinterf

3rd February 2026, 09:15

New build: Avisynth r4483
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4483

20260203 3.7.5.r4483 (pre 3.7.6)
--------------------------------
* rst documentation update: RGBAdjust https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/adjust.html
* rst documentation update: ColorYUV https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/coloryuv.html
* optimization: add AVX2 TurnLeft/TurnRight/Turn180 (R/L: 1,5-3x speed).
* optimization: ConvertBits AVX2 integer->float
* optimization: ConvertToPlanarRGB(A): YUV->RGB add AVX2 (2-3x speed)
* optimization: ConvertToPlanarRGB(A): YUV->RGB 16 bit: a quicker way (1,5x)
* Fix: C version of 32-bit ConvertToPlanarRGB YUV->RGB to not clamp output RGB values.
* ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.
* ConvertToPlanarRGB(A): from YUV->RGB full range output: optimized in-process when bits=32, other cases call ConvertBits internally.
* Fix: Packed RGB conversions altering the bit-depth (e.g. rgb32->ConvertToRGB64() worked always in full range.
* Add more AVX512 resampler code. (WIP)
* Add more AVX512_BASE code paths (Resamplers)
* Build: add _avx512b.cpp/hpp pattern in CMake to detect source to compile with base (F,CD,BW,DQ,VL) flags.
However AVX512_BASE itself is set only when AVX512_FAST found.
For pre-Ice Lake (older AVX512) systems you can enable it with SetMaxCPU("avx512base+") and get the optimized AVX512_BASE functions.
* Build: add new architecture z/Architecture

Kurt.noise

4th February 2026, 06:39

Hi,

Didnt look closely but I've seen CUDA parameters into the compilation settings. What is it for exactly ?

DTL

4th February 2026, 08:11

It looks for memory management (and filtergraph filters interconnection ?) for CUDA-based plugins (no CUDA internal filters currently ?). It looks like in old times when the number of programmers was big there was an attempt to make CUDA-computing avisynth with script-based filters interconnection inside CUDA-accelerator and/or even a mix of onCPU and onCUDA filters. But the development of this looks like it stopped a long time ago. Now all filters work as onCPU and if a filter needs some external acceleration it makes all memory management inside itself. This causes some performance loss in case of single filter and more in case of a filterchain but it is more simple in support by the current limited number of developers.

There is an idea for special onAccelerator filters extended filters interconnection interface like GetFrameToBuffer(buffer_description) so that onAccelerator based filters can ask for storage of a frame directly into an allocated upload buffer in global virtual memory address space. Currently AI/NN filters like RIFE and avs-mlrt only can get frames by standard GetFrame() method and make additional copy into allocated buffers for uploading to the accelerator. With the largest RGBPS format this causes great load on the memory subsystem (though while AI/NN filters are not very fast it may be not greatly visible).

As I understand, the idea of the CUDA-based filtergraph was to save from frame resources upload/download to/from host RAM if several CUDA-based filters are connected in a graph inside an external accelerator. Current AVS filters interconnection (typically via software Cache() for frame-based MT) require to write frames to host RAM cache buffers and read from cache buffers (though some DO_NOT_CACHE_ME mode exist and filters can attempt for direct connection via GetFrame() ?).

tormento

4th February 2026, 11:29

As I understand, the idea of the CUDA-based filtergraph was to save from frame resources upload/download to/from host RAM
So, there could be an implementation for my beloved BM3DCUDA, where the temporal part is CPU bonded?

DTL

6th February 2026, 08:51

pinterf

6th February 2026, 13:03

CUDA-based filters may interact with other CUDA-based filters without downloading input/output frames to host RAM.

Important update for use with ML/AI/NN filters -
ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.

It mean instead of long and slow sequence

ConvertToPlanarRGB()
ConvertBits(32)

before RIFE/avs-mlrt filters after r4483 can be used single (and faster) filter

ConvertToPlanarRGB(bits=32)

It is expected finally faster in comparison with avsresize Z_ConvertFormat(pixel_type="RGBPS") if convert from YUV.

Also uint8..16 to float32 precision may become a bit better because the new function uses direct int32 immediate to float32 conversion without immediate integer stage.
May be close in precision to possible (but also slower)
ConvertBits(32)
ConvertToPlanarRGB()
sequence.

Also waiting for a new test release from pinterf - it will have finally fixed ColorBarsHD to any integer precision and float and again fixed matrix/dermatix part for better YUV<->RGB conversions to test precision of new functions. Currently ColorBarsHD uses only 8bit internal table and bit depth upscale and can not be used as a good source generator for precise matrix testing at different bit depths.
Precision of 10bit YUV to 8bit RGB conversion expected to be very close or equal to avsresize in new test release.
Yep, returning to this matrix conversion area during development caused a "bit" more work, testing, and experimentation than I had initially expected. I can't quite compete with the accuracy of avsresize, as it performs all matrix operations internally in 32 bit float.

However, at 16-bit, a possible +/-1 lsb error can be considered as "good enough".

When using full range, it's effectively the same as working in 32 bit float; for complex transformations (like full range bit depth conversion), my version uses float calculations internally as well.

Avisynth hasn't previously had chained (fused) filter options where a matrix was involved, so this bits= parameter is a first. It immediately became clear that while optimizing the simplest conversion was easy, the code bloats exponentially when you try to optimize every specific sub-case. Luckily, the more complex cases finally needed 'float' - inside and could be unified.

Combining the bit depth conversion is not only much faster but also more accurate than simply adding ConvertBits after the YUV-RGB conversion, so it was a very good and useful idea from DTL.

tormento

6th February 2026, 13:18

CUDA-based filters may interact with other CUDA-based filters without downloading input/output frames to host RAM.
My usual script is something like:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\DehaloAlpha\Dehalo_alpha.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\Dither\mt_xxpand_multi.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\FineDehalo\FineDehalo.avsi")
DGSource("M:\In\The promised neverland S1 ~Dynit\01-1.dgi")
z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv420p16")
DeBilinearResizeMT(1280, 720, threads=2, prefetch=2, accuracy=2)
z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv444ps")
BM3D_CUDA(sigma=12, radius=4, chroma=true, block_step=6, bm_range=12, ps_range=6, fast=false)
BM3D_VAggregate(radius=4)
z_ConvertFormat(resample_filter="spline64",dither_type="error_diffusion",pixel_type="yuv420p16")
FineDehalo(rx=2, ry=2, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=0.3, brightstr=1.0, showmask=0, contra=0.0, excl=true)
libplacebo_Deband(radius=12, iterations=4, temporal=false, planes=[3,3,3])
fmtc_bitdepth (bits=10,dmode=8)
Prefetch(2,6)

How could I change it to have some performance increase, according to the last commits?

DTL

6th February 2026, 16:17

Currently looks like no. In future some 420<->444 conversion performance increase expected in UV 2x upsize/downsize but it is not yet ported to AVS+ core so no test release exist. Also it is internal Resize() optimization and not required script changes.

As some testing may be recommended to try 14bit integers instead of 16bit. It was found 16bit format was not nice for performance in many AVS filters and processed by different functions in comparison with 10-14 bits. But if you use external filters - it may depend on their implementations. The precision may be not greatly different between 14 and 16bits.

FranceBB

8th February 2026, 23:24

Older VSFilters didn't throw exceptions in GetFrame, and it simply didn't work.

I remember it well. Sometimes I forgot to convert things at the end and I ended up wasting encoding hours only to find out that the output wasn't hardsubbed.

TextSub("whatever.ass") would literally pass the frames through without returning any error nor overlaying any subtitles.

https://images2.imgbox.com/5b/83/SheFAaHM_o.png
https://images2.imgbox.com/48/58/QTaqLlNH_o.png

there was an attempt to make CUDA-computing avisynth with script-based filters interconnection inside CUDA-accelerator and/or even a mix of onCPU and onCUDA filters.

Yes, however it's always better to avoid going back and forth between CPU and GPU (so onCPU and onCUDA) because it means copying a lot of data and it might not be worth it. One classic example of this is Cube() and DGCube() from Donald Graft. Although - on paper - DGCube() makes the entire tetrahedral interpolation and application of the 65x65x65 LUT on the GPU and it's significantly computationally faster than doing it on the CPU with AVX512, copying huge frames from RAM (DDR) to VRAM (GDDR) via the motherboard lanes to perform the process and then back causes a significant slowdown and only really makes DGCube() a fraction faster than Cube(), thus losing almost all its advantage. We're talking about 16bit RGB Planar UHD frames here for normal content (or potentially 6K for post production stuff shot in log).

Now all filters work as onCPU and if a filter needs some external acceleration it makes all memory management inside itself. This causes some performance loss in case of single filter and more in case of a filterchain but it is more simple in support by the current limited number of developers.

To be fair, this is very easily supportable and it's actually very simple from the user perspective as well given that there's no need to mess with MT Modes and Prefetch() either as the threadpool is created internally by the filter itself, so from a user perspective you know that all you have to do is write the script and it will run everywhere.

Also, when it comes to distributed farms like in the case of FFAStrans running on prem, the servers it's running on may not be all exactly the same and have the very same dedicated GPU with the same drivers etc and the same goes for the CPU cores, instruction sets (assembly optimization) etc so writing the scripts and letting the filters "figure it out" automatically on the CPU is actually very helpful.

Even in a cloud environment in which you typically have 1 machine = 1 job with a workflow running end to end, you only really have CPU only EC2 like the Elastic c6i.4xlarge and Elastic c6i.2xlarge that we're using as only the ones without a GPU would scale up and down by being created dynamically according to the number of jobs. Sure, one could set it up in a similar way with GPU powered EC2, but the likelihood of them not being created as there aren't any resources available for the region raises significantly, thus making the CPU only option way more appealing. TL;DR I would rather pick something slower but that works and is available all the time than something slightly faster that might not be available.

Also waiting for a new test release from pinterf - it will have finally fixed ColorBarsHD to any integer precision and float and again fixed matrix/dematix part for better YUV<->RGB conversions to test precision of new functions. Currently ColorBarsHD uses only 8bit internal table and bit depth upscale and can not be used as a good source generator for precise matrix testing at different bit depths.
Precision of 10bit YUV to 8bit RGB conversion expected to be very close or equal to avsresize in new test release.

That's actually gonna be very good as I routinely use Avisynth's colorbars to test stuff, so thank you for looking into this guys. :)

FranceBB

9th February 2026, 10:13

New build: Avisynth r4483
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4483

Windows XP Builds (x86-xp):

Tested and working on Windows XP Professional x86
https://images2.imgbox.com/be/29/1TfQ9EEX_o.png

Windows 7 Builds (x64-win7-19.44.35221-17.14):

Tested and working on Windows Server 2008 R2 x64
https://images2.imgbox.com/77/55/707MuoSA_o.png

DTL

9th February 2026, 17:59

"How could I change it to have some performance increase, according to the last commits?"

What I found with some total encoding performance testing (using x264.exe as MPEG encoder) and RIFE as some call to accelerator processing: The performance may depend not on the best performance single filter but on some magic combinations of filters in a graph.
I see you use avsresize for all format conversions. In my test it is not best for total performance (equal to not-best other AVS filters sequences).
So if you have time for long testing - you can also test single or even sequences of AVS filters of Convert(matrix) + ConvertBits() if total encoding performance is visibly different.

In my (test) case with RIFE:

Fastest convert of YV12 to planar RGBPS before RIFE filter is
ConvertToPlanarRGB()
ConvertBits(32)

all other ways (with single ConvertToPlanarRGB(bits=32) and Z_ConverFormat(pixel_type="RGBPS") and reverse order of ConvertBits(32).ConvertToPlanarRGB() are slower. And it is tested with r4483 (and sources up to 09 Feb). But all this may be changed in any new release if we will have any changes in AVS caching and new frames fetching from global frames buffer etc.

The total encoding fps difference between 'lucky fast' filters sequence and 'about all other slow' is about 22..23 vs 14..15 fps.

Full test script was

LoadPlugin("avsresize.dll")
LoadPlugin("RIFE.dll")

ColorBars(800,800,pixel_type="YUV444P8")

#ConvertToPlanarRGB(bits=32)
#ConvertBits(32)
ConvertToPlanarRGB()
ConvertBits(32)
#Z_ConvertFormat(pixel_type="RGBPS")

RIFE(denoise_tr=1)

ConvertBits(8)
ConvertToYV12()
Prefetch(2)

And x264 encoding is
x264.exe --profile high --crf 18 --preset "placebo" --merange 50 --psnr -o out.264 rife_test.avs

Typical average performance GPU load graph and x264 fps
https://i.ibb.co/FqsFXDd6/ss01.png (https://ibb.co/tPZ9zJ1B)

Anomaly best performance Convert filters sequence
https://i.ibb.co/tPPd5Y8T/gs01.png (https://ibb.co/JFFhPr5w)

Maybe some complex issue with Windows threading and GPU drivers etc.

Another idea: RIFE in denoise-mode (tr=1) requests -1 and +1 frames from current to output interpolated frame. A bit close to MDegrain1(). This may cause some significant performance difference in AVS caching and sequence of
ConvertToPlanarRGB()
ConvertBits(32)
may have some more lucky results ?
But these filters are simple and sequence
ConvertBits(32)
ConvertToPlanarRGB()
expect to have same cache service time performance (not including larger float data size after ConvertBits(32) ).

wonkey_monkey

10th February 2026, 14:24

Presumably RIFE has to upload multiple frames to the GPU for each output frame. How efficiently does it do so?

Edit: I see you mentioned that. Off the top of my head, to be compatible with prefetch(2) it can't be keeping track of internal state between frames so it must be uploading 3 frames every time. If it could keep track of what's previously been loaded, and ran single-threaded, could it eliminate two of those uploads?

DTL

10th February 2026, 18:37

RIFE applied to AVS is still a very simple 2 frame input and 1 frame output engine. And it always uploads 2 frames to get 1 output frame (+ time param to interpolate between 0.0 (first frame) to 1.0 (second frame) float). This allows it to run in random access mode without additional programming. But this causes 2x additional upload traffic if work with sequential frames requests. It may not know how to remap the last uploaded frame to be first and only upload 1 new frame. It is subject to one more issue to open for possible optimization in the RIFE AVS plugin (if underlying NN engine support resources remapping).

In theory any temporal radius filter with sequential frame requests at output (normal encode mode in 1 thread) can only upload 1 new frame and remap all tr-frames by shifting to 1 and skipping first (oldest) frame if accelerator memory is enough to hold all tr-frames at once. But with current massive-multithreaded CPUs running at single threaded mode may not make best performance for the accelerator. Also with random output frame access the frame source engine needs to upload all required frames before output requested frame. This is additional programming to remember uploaded frames numbers. Also each thread must either have its own frame pool in (very small and expensive accelerator memory) or even some global memory manager interconnected with AVS frame cache to run >1 threaded filters if frame numbers in different threads overlap. This expectation was some part of the idea of onCUDA filters processing.

Because current underlying RIFE engine always work with 2 frames (and can not remember surround frames to make quality better) the optimizing sequential frame access by remap last frame to first and upload only 1 new may not give significant performance boost if even it is possible with currently used Vulkan API and RIFE engine. Though it is subject to testing if possible. Much better performance boost may be with larger-tr engines (but we currently do not have any ?).

Current AVS groups of frames multithreading model require the constant new output frame (not sequential) filter refresh after the current group of frames at current thread fully processed and thread getting a new work unit of the next group of frames (may be also in some random order). This means the filter in the thread needs to reupload all frames to the accelerator for the current requested output frame at the start of each frame group. Or attempt to remap frames from the global uploaded frames pool for current clip (if available and managed). This requires even more programming.

wonkey_monkey

10th February 2026, 23:33

Just did a quick test: skipping the each-frame upload (2048x1024 RGB32) to my Vulkan remapping filter takes me from 140fps to 180fps (or 100fps to 160fps if I pass RGB24, which needs a CPU conversion to RGB32). And that's just 8mb. A 4K float input would be 132mb.

What if we could upload the native YUV planes to the GPU, and convert them to RGBA there? Or would that just be letting the CPU go to waste?

Nomolu

11th February 2026, 01:45

New build: Avisynth r4483
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4483

After installing Avisynth r4483 on my system, I went to test the 32-bit version of it. I immediately got this error message:

Avisynth open failure:
Cannot load a 64 bit DLL in 32 bit Avisynth: 'C:/Program Files (x86)/AviSynth+/plugins+/DirectShowSource.dll'.

E:\Video_Processing\Test.avs, line 2

My test script is really simple:
AviSource("D:\ToR\video_a.avi")
Trim(1188, 89809)

To fix the problem, I started downloading older prereleases and found a good 32-bit version of DirectShowSource.dll in r4356. Then I got the 64-bit error message with the 'ImageSeq.dll' file. I replaced that file and got the error message with the 'TimeStretch.dll' file.

So, it seems that several of the 64-bit plugins (DirectShowSource.dll, ImageSeq.dll, and TimeStretch.dll) are wrongly located in the "x86-19.50-clangcl-llvm-20.1.8\plugins" of the current release packages and missing from the "x64-19.50-clangcl-llvm-20.1.8\plugins" directory.

This is the only problem I've ran into so far with the r4483 build.

DTL

11th February 2026, 06:51

What if we could upload the native YUV planes to the GPU, and convert them to RGBA there?

Unfortunately current progress in development of image processing at accelerators (in opensource) is very poor and they still work mostly like working tech demos designed by students for processing RGBPS images only.

Need additional work to add YUV integer to RGBPS conversion in accelerator to unpack uploaded YV12 resource-texture to RGBPS. But it looks we already do not have programmers to do this simple work.

So RIFE and avs-mlrt only can work in slowest mode of full unpack of YV12 to RGBPS onCPU and upload largest resources to accelerator (via lots of redundant CPU data copy too).

Best solution is to simply allow accelerator to DMA AVS YV12 planar buffers onboard (from AVS cache) and do all work onboard.

wonkey_monkey

12th February 2026, 13:20

Is there any documentation/example for passing functions as parameters to plugins ('n' in AddFunction parameter string)?

pinterf

12th February 2026, 15:44

New build.
Avisynth r4507
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4507

Full change log:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

20260213 3.7.5.r4507 (pre 3.7.6)
--------------------------------
Fix Layer "add" 8 bit, regression in r4504

20260212 3.7.5.r4504 (pre 3.7.6)
--------------------------------
* Fix: inaccurate ColorBarsHD 10+ bit values. Now they are derived from the 32-bit float
RGB definitions instead of upscaling a 8 bit precalculated YUV value.
Add Ramp section the lead-in-lead-out.
* Fix: GreyScale + SSE2 + RGB32 + matrix="RGB" overflow.
Rare usage; "RGB" matrix (Identity) uses a 1.0 coefficient which exceeds the signed 16-bit
SIMD limit of 32767 at 15-bit precision. Added bounds checking to fallback to C-code for any
coefficients >= 1.0 or < −1.0.
* Fix: YUV->RGB limited range matrix accuracy for 10-16 bits.
* Use a different rounding in matrix coefficient's integer approximation.
* "ConvertToPlanarRGB": ``bits`` parameter: on-the-fly bit-depth conversions to YUV->RGB conversion.
- Full range target: 8-16 bits internal calculation is in 32-bit float.
- Limited range target: a quicker, bit accuracy optimized integer calculation path.
* Not Fixed: Speed degradation when in-constructor GetFrame(0) (e.g. frame-property getter)
is used. Disable internal Cache object creation. Does not work in complex scripts, preparation
is 5-10 min instead of <1 sec. Investigation continues (Issue #476: https://github.com/AviSynth/AviSynthPlus/issues/476)
* Avoid MTGuard and CacheGuard creation if filter returns one of its clip parameter unaltered.
* Add some avx2 stuff to Layer and Invert
* Optimization: Overlay "Blend": aarch64 NEON optimization

20260203 3.7.5.r4483 (pre 3.7.6)
--------------------------------
* rst documentation update: RGBAdjust https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/adjust.html
* rst documentation update: ColorYUV https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/coloryuv.html
* optimization: add AVX2 TurnLeft/TurnRight/Turn180 (R/L: 1,5-3x speed).
* optimization: ConvertBits AVX2 integer->float
* optimization: ConvertToPlanarRGB(A): YUV->RGB add AVX2 (2-3x speed)
* optimization: ConvertToPlanarRGB(A): YUV->RGB 16 bit: a quicker way (1,5x)
* Fix: C version of 32-bit ConvertToPlanarRGB YUV->RGB to not clamp output RGB values.
* ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.
* ConvertToPlanarRGB(A): from YUV->RGB full range output: optimized in-process when bits=32, other cases call ConvertBits internally.
* Fix: Packed RGB conversions altering the bit-depth (e.g. rgb32->ConvertToRGB64() worked always in full range.
* Add more AVX512 resampler code. (WIP)
* Add more AVX512_BASE code paths (Resamplers)
* Build: add _avx512b.cpp/hpp pattern in CMake to detect source to compile with base (F,CD,BW,DQ,VL) flags.
However AVX512_BASE itself is set only when AVX512_FAST found.
For pre-Ice Lake (older AVX512) systems you can enable it with SetMaxCPU("avx512base+") and get the optimized AVX512_BASE functions.
* Build: add new architecture z/Architecture

pinterf

12th February 2026, 15:54

Is there any documentation/example for passing functions as parameters to plugins ('n' in AddFunction parameter string)?
Perhaps this one:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_function_objects.html

EDIT:
or in function parameter
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/conditionalfilter.html

and in Avisynth source (runtime functions accept function objects)
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/conditional/conditional.cpp#L61

Jamaika

12th February 2026, 18:10

https://github.com/pinterf/AviSynthPlus/commit/8d5075d6df6dca5e8f55c740addc7e3c00b321c8
I don't know why are minor DEBUG fixes added?
cache.cpp:745:146: error: macro "_RPT3" passed 6 arguments, but takes just 5
745 | _RPT3(0, "CacheGuard::SetCacheHints called. cache=%p hint=%d (%s) frame_range=%d\n", (void*)this, cachehints, hintname.c_str(), frame_range); // P.F.
| ^
In file included from cache.h:38,
from cache.cpp:35:
avisynth.h:157: note: macro "_RPT3" defined here
157 | #define _RPT3(a,b,c,d,e) ((void)0)
|
cache.cpp: In member function 'virtual int CacheGuard::SetCacheHints(int, int)':
cache.cpp:745:7: error: '_RPT3' was not declared in this scope
745 | _RPT3(0, "CacheGuard::SetCacheHints called. cache=%p hint=%d (%s) frame_range=%d\n", (void*)this, cachehints, hintname.c_str(), frame_range); // P.F.
| ^~~~~

Columbo

12th February 2026, 18:27

It's a single code base. pinterf and others may want to build with _DEBUG when troubleshooting. Did I miss your point?

pinterf

12th February 2026, 18:40

Yes, minor, since compared to last week's ~40 hrs work on the project it was just a quick moment to copy-paste _RPT3 and not modifying the _RPT3 to _RPT4. Sorry for the inconvenience.

pinterf

12th February 2026, 18:46

(I don't know what private compiler settings are you using again, for me it said '0 warning(s)', vs. your environment which drives it to an error. Anyway, thanks for the report. Fixed.)

wonkey_monkey

13th February 2026, 00:18

and in Avisynth source (runtime functions accept function objects)
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/conditional/conditional.cpp#L61

When I tried to pass a parameter to the constructor as a PFunction (via args[x].AsFunction()) I get:

unresolved external symbol "public: class PFunction __cdecl AVSValue::AsFunction(void)const " (?AsFunction@AVSValue@@QEBA?AVPFunction@@XZ)

:confused:

Is it something to do with this?

c++ strict conformance: cannot Convert PFunction to PFunction&

Edit: or this:

PFunction AsFunction() const; // internal use only

So external plugins can't make use of it?

pinterf

14th February 2026, 00:40

When I tried to pass a parameter to the constructor as a PFunction (via args[x].AsFunction()) I get:

unresolved external symbol "public: class PFunction __cdecl AVSValue::AsFunction(void)const " (?AsFunction@AVSValue@@QEBA?AVPFunction@@XZ)

:confused:

Is it something to do with this?

Edit: or this:

PFunction AsFunction() const; // internal use only

So external plugins can't make use of it?
In expression.cpp I encountered with the problem, but can't remember the details:

if (real_name == nullptr) {
// if name is not given, evaluate expression to get the function
eval_result = func->Evaluate(env);
if (!eval_result.IsFunction()) {
env->ThrowError(
"Script error: '%s' cannot be called. Give me a function!",
GetAVSTypeName(eval_result));
}
//auto& func = eval_result.AsFunction(); // c++ strict conformance: cannot Convert PFunction to PFunction&
const PFunction& func = eval_result.AsFunction();
real_name = func->GetLegacyName();
real_func = func->GetDefinition();
}

pinterf

14th February 2026, 00:45

Meanwhile a hotfix, 8 bit Layer "add" mask problems
New build, sorry for that.
Avisynth r4507
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4507

FranceBB

15th February 2026, 11:53

Meanwhile a hotfix, 8 bit Layer "add" mask problems
New build, sorry for that.
Avisynth r4507
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4507

x86-xp build
Tested and working on Windows XP Professional x86
https://images2.imgbox.com/7d/67/T0aokMyB_o.png

x64-win7-19.44.35221-17.14 build

Tested and working on Windows Server 2008 R2 but there seems to be a problem with assembly optimizations somewhere in x64.

SetMaxCPU("none")
video=LWLibavVideoSource("M2991374.mxf")
ch1=LWLibavAudioSource("M2991374.mxf", stream_index=1, fill_agaps=1)
ch2=LWLibavAudioSource("M2991374.mxf", stream_index=2, fill_agaps=1)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

propClearAll()

ConvertBits(16)

Limiter(min_luma=4096, max_luma=60160, min_chroma=4096, max_chroma=60160)

SinPowerResize(1024, 576)
Info()

produces the right output
https://images2.imgbox.com/15/50/b2RcxLk8_o.png

however if I remove the

SetMaxCPU("none")

I get the following
https://images2.imgbox.com/1f/7a/mH5z8SUN_o.png

which is clearly wrong.

Even a simple SetMaxCPU("SSE2") produces the same result which means that only the C++ code is "fine" and there's a problem somewhere in the manually written intrinsics in assembly.

Digging a bit further, this seems to be related to 4:2:2 10bit planar and can be reproduced with a simple:

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(10)
Info()

In other words:

8bit planar 4:2:2 with assembly optimizations is fine

ColorBars(848, 480, pixel_type="YV16")
Info()

https://images2.imgbox.com/4b/be/ksj26nCs_o.png

32bit float 4:2:2 with assembly optimizations is fine

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(32)
Info()

https://images2.imgbox.com/86/97/gCGESemm_o.png

10bit, 12bit, 14bit, 16bit planar 4:2:2 with assembly optimization from SSE2 onwards are not

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(10)
Info()

https://images2.imgbox.com/4d/7c/2Nh5pTt4_o.png

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(12)
Info()

https://images2.imgbox.com/52/f3/sYxvCpjx_o.png

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(14)
Info()

https://images2.imgbox.com/bc/8b/fXzDMMwD_o.png

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(16)
Info()

https://images2.imgbox.com/a2/a3/PclbMINY_o.png

jpsdr

15th February 2026, 14:15

You've found the Dolby Vision LUT...
I mean, green/purple, it's the way Dolby Vision is displayed when not supported... :D

FranceBB

15th February 2026, 21:45

You've found the Dolby Vision LUT...
I mean, green/purple, it's the way Dolby Vision is displayed when not supported... :D

All this time trying to invert IPTc2 dvhe0509 and the answer was there in front of out eyes... LMAO

Jokes aside I triple checked and I can confirm that it only happens on x64 in the Windows 7 build.

x86-xp isn't affected.

ColorBars(848, 480, pixel_type="YV16")
ConvertBits(10)
Info()

https://images2.imgbox.com/cb/fa/vyhgUaqv_o.png

Tomorrow morning I'll try the x64-xp build.

EDIT: I did, final results:

Avisynth_3.7.6_20260213_tst_r4507

- x64-xp
- x64-win7-19.44.35221-17.14

8bit planar and 32bit float 4:2:2 ok.
problem with 10bit, 12bit, 14bit, 16bit planar 4:2:2 when assembly optimization are used (SSE2 onwards).
SetMaxCPU("none") forces C++ which is error free.

- x86-xp

all ok (8bit, 10bit, 12bit, 14bit, 16bit planar and 32bit float) 4:2:2. Everything is fine both with assembly optimization (tested up to SSE4.2 which is the maximum XP supports).

pinterf

16th February 2026, 13:58

Thanks FranceBB, I thought, it would be super-easy, but I was not able to reproduce it.
EDIT: It's the display, which is using ConvertToRGB32() after that.
EDIT: fixed, exchanged G and B in bit-depth changing YUV->RGB full scale code.

pinterf

16th February 2026, 20:47

New build.
Avisynth r4523
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4523

For online documentation check https://avisynthplus.readthedocs.io/en/latest/

Actual:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

20260216 3.7.5.r4523 (pre 3.7.6)
--------------------------------
- Fix r4504 regression YUV->RGBP bit-depth changing full-scale SSE2/AVX2 bug (exchanged G,B storage)
- "Layer" YUV mul/add/subtract/lighten/darken: refactor chroma placement calculation, allowing SIMD optimization in the main frame processing
- "Layer" YUV/RGBP mul/add/subtract/lighten/darken: refactor function dispatchers, add AVX2 path (LLVM/clangcl recommended)
- Fix C-only vertical resampling code which added more rounding than needed (regression since pre-3.7.5 20250427)
- Invert: per-plane processing for planar formats, use C even in AVX2, proper chroma inversion
- New: AddAlphaPlane opacity parameter
- New: ResetMask opacity parameter
- rstdoc: document "opacity" in AddAlphaPlane and ResetMask
- rstdoc: detail Layer "use_chroma" and opacity
- Overlay "Blend": more speed, but keep accuracy, use float only where really needed
- Layer: use YV16 internally for YUY2 (lessen source bloat)

20260213 3.7.5.r4507 (pre 3.7.6)
--------------------------------
Fix Layer "add" 8 bit, regression in r4504

20260212 3.7.5.r4504 (pre 3.7.6)
--------------------------------
* Fix: inaccurate ColorBarsHD 10+ bit values. Now they are derived from the 32-bit float
RGB definitions instead of upscaling a 8 bit precalculated YUV value.
Add Ramp section the lead-in-lead-out.
* Fix: GreyScale + SSE2 + RGB32 + matrix="RGB" overflow.
Rare usage; "RGB" matrix (Identity) uses a 1.0 coefficient which exceeds the signed 16-bit
SIMD limit of 32767 at 15-bit precision. Added bounds checking to fallback to C-code for any
coefficients >= 1.0 or < −1.0.
* Fix: YUV->RGB limited range matrix accuracy for 10-16 bits.
* Use a different rounding in matrix coefficient's integer approximation.
* "ConvertToPlanarRGB": ``bits`` parameter: on-the-fly bit-depth conversions to YUV->RGB conversion.
- Full range target: 8-16 bits internal calculation is in 32-bit float.
- Limited range target: a quicker, bit accuracy optimized integer calculation path.
* Not Fixed: Speed degradation when in-constructor GetFrame(0) (e.g. frame-property getter)
is used. Disable internal Cache object creation. Does not work in complex scripts, preparation
is 5-10 min instead of <1 sec. Investigation continues (Issue #476: https://github.com/AviSynth/AviSynthPlus/issues/476)
* Avoid MTGuard and CacheGuard creation if filter returns one of its clip parameter unaltered.
* Add some avx2 stuff to Layer and Invert
* Optimization: Overlay "Blend": aarch64 NEON optimization

20260203 3.7.5.r4483 (pre 3.7.6)
--------------------------------
* rst documentation update: RGBAdjust https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/adjust.html
* rst documentation update: ColorYUV https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/coloryuv.html
* optimization: add AVX2 TurnLeft/TurnRight/Turn180 (R/L: 1,5-3x speed).
* optimization: ConvertBits AVX2 integer->float
* optimization: ConvertToPlanarRGB(A): YUV->RGB add AVX2 (2-3x speed)
* optimization: ConvertToPlanarRGB(A): YUV->RGB 16 bit: a quicker way (1,5x)
* Fix: C version of 32-bit ConvertToPlanarRGB YUV->RGB to not clamp output RGB values.
* ConvertToPlanarRGB(A): add bits parameter to alter target bit-depth.
* ConvertToPlanarRGB(A): from YUV->RGB full range output: optimized in-process when bits=32, other cases call ConvertBits internally.
* Fix: Packed RGB conversions altering the bit-depth (e.g. rgb32->ConvertToRGB64() worked always in full range.
* Add more AVX512 resampler code. (WIP)
* Add more AVX512_BASE code paths (Resamplers)
* Build: add _avx512b.cpp/hpp pattern in CMake to detect source to compile with base (F,CD,BW,DQ,VL) flags.
However AVX512_BASE itself is set only when AVX512_FAST found.
For pre-Ice Lake (older AVX512) systems you can enable it with SetMaxCPU("avx512base+") and get the optimized AVX512_BASE functions.
* Build: add new architecture z/Architecture

FranceBB

18th February 2026, 00:54

Thanks for the new build and for fixing the issue (https://github.com/pinterf/AviSynthPlus/commit/c6d7126b4cfcb6d5c683729090415f0809c219db), Master Ferenc.

Avisynth_3.7.6_20260216_tst_r4523

x64-win7-19.44.35221-17.14
Windows Server 2008 R2 x64

Now 4:2:2 10bit/12bit/14bit/16bit work correctly with assembly optimizations up to SSE4.2 as well.
https://images2.imgbox.com/dc/f6/wtPJAGA1_o.png

x86-xp
Windows XP Professional x86

works normally as usual

https://images2.imgbox.com/77/2e/EtmUlX0J_o.png

DTL

18th February 2026, 13:24

Oh - Windows XP of decades old can use F16C pack/unpack instructions. And big set of AVX512_FP16 instructions for direct computing in FP16 format is not ready to use in most of current CPUs even in 2026.

pinterf

20th February 2026, 22:42

Here's a new pre-release build.
Latest test build (https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4529)
Avisynth+ v3.7.6pre-r4529 test build (20260220)

For online documentation check https://avisynthplus.readthedocs.io/en/latest/

Actual full change log:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

As a result of a chain reaction. After ColorBarsHD 10+ bit was fixed, I did the same update to ColorBars, with almost a full rewrite. Additionally I fixed the reported color matrix as well. I wanted then to visualize the changes, and it turned out that the existing vectorscope (color, color2) is quite basic. So I added a lot of options to them (for details, see
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/histogram.html), made them matrix and color range aware. Made them accurate (rounding, proper scaling to visible vectorscope area from full or limited range colors). That was another 3/4 rewrite, refactor.

So enjoy this new build, I'm sure FranceBB will be happy to test the new color/color2 overlay flags :) and you all would give me additional ideas.

20260220 3.7.5.r4529 (pre 3.7.6)
--------------------------------
- Fix Colorbars inaccurate 10+ bit, by using ground truth linear RGB, similarly to ColorBarsHD.
- Fix reporting 709 matrix instead of the 601 (170m)
- Full refactoring.
- update doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/colorbars.html
- Histogram "color" and "color2" (Vectorscope modes)
- almost full refactoring.
- Drawing is now matrix and color range aware. target positions (75%) +-I and +Q.
- add individual overlay options:
added ``matrix``, ``graticule``, ``targets``, ``axes``, ``iq``, ``iq_lines``, ``circle``
parameters
- Fix: copy alpha from clip, initialize alpha to zero in the histogram area.
- Accurate pixel positioning and scaling to the active histogram area,
limited/full range aware.
- update doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/histogram.html

20260216 3.7.5.r4523 (pre 3.7.6)
--------------------------------
- Fix r4504 regression YUV->RGBP bit-depth changing full-scale SSE2/AVX2 bug (exchanged G,B storage)
- "Layer" YUV mul/add/subtract/lighten/darken: refactor chroma placement calculation, allowing SIMD optimization in the main frame processing
- "Layer" YUV/RGBP mul/add/subtract/lighten/darken: refactor function dispatchers, add AVX2 path (LLVM/clangcl recommended)
- Fix C-only vertical resampling code which added more rounding than needed (regression since pre-3.7.5 20250427)
- Invert: per-plane processing for planar formats, use C even in AVX2, proper chroma inversion
- New: AddAlphaPlane opacity parameter
- New: ResetMask opacity parameter
- rstdoc: document "opacity" in AddAlphaPlane and ResetMask
- rstdoc: detail Layer "use_chroma" and opacity
- Overlay "Blend": more speed, but keep accuracy, use float only where really needed
- Layer: use YV16 internally for YUY2 (lessen source code bloat)

DTL

21st February 2026, 20:52

Great. We again can use the good skin tone mark at the vectorscope.

About program text comments of linear RGB: The colour bars are not in linear RGB (scene linear light). They are in system transfer domain encoding. The RGB sources for colour bars in the documents are defined simply to check the matrix/dematrix in distribution but not check transfer conversion too.

With 2-levels current colour bars sources it is not an issue because they do not contain transfer-dependent transients.

Though some old documents indirectly point to the 'conditioning domain' or colour bars and it is a system transfer domain (not linear-light RGB). It may be designed to make DAC and levels checking at waveform monitors more easy. As I understand, close to zero waveform monitors can do transfer conversion to linear before DAC or other way of interpolated (upscaled) waveform draw (render).

So it may be put to the notes section of ColorBars filter: The output is not conditioned to any transfer domain (and it is partially good) and has direct switch transients between levels. The levels are set as defined in the colour bars standard but it is not 75% linear RGB. It is 75% RGB still in system transfer domain encoding (to mark it sometime and in the ITU/EBU documents used R'G'B').

To condition in any required domain for frequency-limited (Nyquist) channel can be used sequence of:

#to condition transients in transfer domain R'G'B' with 75% in transfer domain
ColorBars(target_width*10, target_height*10, pixel_type="RGB")
UserDefined2Resize(width/10, height/10) #not perfectly match the recommended ITU filter response

#to condition transients in linear domain RGB with 75% in transfer domain
ColorBars(target_width*10, target_height*10, pixel_type="RGB")
#convert transfer to linear RGB (no AVS+ filter currently exist - use avsresize ?)
UserDefined2Resize(width/10, height/10) #not perfectly match the recommended ITU filter response
#convert transfer to target domain R'G'B' (no AVS+ filter currently exist - use avsresize ?)

Also it is nice to have some day to add Transfer() filter to AVS+ core to support transfer domain conversions too. For example to support resize in linear domain with all internal filters only.
Also additional frame/clip properties to mark:
1. Current transfer domain
2. Target conditioning transfer domain for resizing

About real ITU transients shaping filter: https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.801-1-199510-W!!PDF-E.pdf
1 Formulae : the filter impulse response is a Blackman window. We have BlackmanResize with the same (or close) window function https://github.com/AviSynth/AviSynthPlus/blob/c98ae61c51fc6c2216e7d314bf7f34582268431e/avs_core/filters/resample_functions.cpp#L133 . To make required frequency shaping filter we need to use this window as filter kernel and scale for timing as defined in the recommendation:

for –3T < t < 3T, R(t) = 0.42 + 0.50 cos(π t/ 3T) + 0.08 cos(2π t/ 3T) – otherwise R(t) = 0 (filter_support is 3T ?) .

The value of T is 74 ns for digital waveforms A1, A2, A3 and A4 and 148 ns for A5 and A6. To make filtering more simple - all colour bars may be filtered with a single filter of T=74ns (very close to 1 step between target samples, 1/74ns is 13.513 MHz and 1 sample step in PAL/rec.601 is duration of 1/13.5 MHz).A separate 'resize' named filter can be added to Resize filters like BlackmanITUResize(). Users can use it for getting better conditioned ColorBars or for some other conditioning workflows if the exact Blackman-type response is required.

FranceBB

1st March 2026, 22:53

So enjoy this new build, I'm sure FranceBB will be happy

I'm so happy right now. This is a very unexpected present, so thank you!
About the colorbars, we've got ColorBars() for BT.601, ColorBarsHD() for BT.709, are we gonna get ColorBarsUHD() for BT.2020? :D

Something appears to be off in Histogram, though, as this:

FFMpegSource2(V:\F1_Movie_FULL_HD_16x9_4tracks_2ch_DolbyE_DolbyE_Stereo_Stereo.mxf", atrack=4)

test1=Histogram(mode="color2", matrix="709", graticule="on", keepsource=false, circle=true, axes=true, iq=true, iq_lines=true)
test2=Histogram(mode="color2", matrix="709", graticule="on", keepsource=false, circle=true, axes=false, iq=false, iq_lines=false)
test3=Histogram(mode="color", matrix="709", graticule="on", keepsource=false, circle=true, axes=true, iq=true, iq_lines=true)
test4=Histogram(mode="color", matrix="709", graticule="on", keepsource=false, circle=true, axes=false, iq=false, iq_lines=false)

v1=StackHorizontal(test1, test2)
v2=StackHorizontal(test3, test4)

StackVertical(v1, v2)

produces identical results despite one combination having

axes=false, iq=false, iq_lines=false

and the other having

axes=true, iq=true, iq_lines=true

https://images2.imgbox.com/a4/42/gPuP9OR2_o.png

This was tested using the x86-xp build on Windows XP Professional x86 and using the x64-win7-19.44.35221-17.14 build on Windows Server 2008 R2 Standard x64.

Other than that, I can happily confirm that

ColorBars(848, 480, pixel_type="YUV444P16")

can produce a proper 16bit output and that both _Matrix and _Range are signaled via the frame properties correctly as Limited and BT.601 while before it said BT.709. :)

https://images2.imgbox.com/b9/c3/8fVo6CPg_o.pnghttps://images2.imgbox.com/87/22/tU7cG5R0_o.png

Left: x86-xp build on Windows XP Professional x86 --- Right: x64-win7-19.44.35221-17.14 build on Windows Server 2008 R2 Standard x64

real.finder

4th March 2026, 19:26

It is not 100%, just a trivial case was fixed. So the likelyhood you are seeing this error was decreased. There still can be circumstances in the frame request pattern when you get this error.

and now it fully fixed (https://github.com/pinterf/TIVTC/releases)! thank you so much pinterf!

I think all avs/avs+ mt and non-mt problems is fixed, we can encode faster and without deadlock or crashes or glitches thanks to you and Asd-g (and others that fixes and improved avs+ like nekopanda and avs+ father ultim)

FranceBB

4th March 2026, 23:09

and now it fully fixed (https://github.com/pinterf/TIVTC/releases)! thank you so much pinterf!

Absolutely amazing news for this and for giving some love to SSE4.1, there may not be many users but they will definitely appreciate it.

Thank you, Master Ferenc! :D

pinterf

5th March 2026, 08:28

I'm so happy right now. This is a very unexpected present, so thank you!
About the colorbars, we've got ColorBars() for BT.601, ColorBarsHD() for BT.709, are we gonna get ColorBarsUHD() for BT.2020? :D

Something appears to be off in Histogram, though, as this:

produces identical results despite one combination having

Check with targets=true, this is a master switch for the axes, as a result of my wrong decision, just tell me (honestly, since you went into the rabbit hole, it seem illogical so must be changed).
EDIT: haha, not a wrong decision, just a mis-placed ending curly-bracket, one block outer than it was necessary :)

pinterf

5th March 2026, 12:28

New build: Avisynth r4549
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4549

The biggest focus lately has been cleaning up the xxToYUV functions to bring their parameters and optimization in line with ConvertToPlanarRGB. This process triggered an endless series of new issues, forcing me to dig deep into historical code to understand why things were built the way they were.

Also, I updated our online documentation according these changes and findings.

I’ve also fixed the Histogram parameters related to the new features introduced in recent builds, which were discussed in the posts above.

For online documentation check https://avisynthplus.readthedocs.io/en/latest/

Actual change log:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

20260305 3.7.5.r4549 (pre 3.7.6)
--------------------------------
- Fix: memory leak in Subframe/MakePropertyWritable after static-frame sources (ColorBars, BlankClip)
- any->YUV conversions (See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html ).
- accept bits ans quality parameters, similar to ConvertToPlanarRGB
- the legacy 8-bit-named functions (``ConvertToYV12``, ``ConvertToYV16``,
``ConvertToYV24``) allowing high-depth sources.
- "ConvertToYUY2": rewritten to route all conversions through YV16.
- "ConvertToYUY2": ``ChromaOutPlacement`` parameter added (was missing, present in ConvertToYV16).
- "ConvertBackToYUY2": kept for backward compatibility; now forwards to ``ConvertToYUY2``. The pre-2.5 left-pixel-only chroma hack is no longer
needed or applied; the YV16 lossless repack path avoids chroma resampling loss entirely for roundtrip workflows.
- 8 bit packed RGB formats are converted to planar RGB before 444 conversion.
Utiliting the optimized and maintained planar RGB infrastructure
- Fix: "ConvertToYUY2" / "ConvertToYV12": progressive YV12<->YUY2 conversion (use generic YV16/YV12 path)
- Fix: "ConvertToYUY2": ``_ChromaLocation``, ``_Matrix`` and ``_ColorRange``
frame properties were not read from YV12 source frames and not written to YUY2 output frames
in the old legacy direct conversion path.
- Fix: "ConvertToYUY2": SSE2 interlaced upsampling used wrong weighting direction, differing from the C reference implementation.
- Update https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`
- matrix syntax
- ConvertToYUY2
- ``bits`` and ``quality`` parameters
- Update Sampling https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/advancedtopics/sampling.html with historical content notes
on legacy ``YUY2`` handling.