AviSynthMinus

[MeteorRain]

I'd like to introduce AviSynthMinus, a fork of AviSynth+ based on 3.7.5.

The main reason for this fork is a difference in development and release workflow. Upstream development follows a single master branch without separate release branches, so fixes, new features, and larger changes accumulate on the same development line. Combined with the long intervals between releases, this makes it difficult to ship a conservative set of fixes independently of ongoing feature development.

I would prefer to maintain separate stable and mainline branches, allowing fixes to be released sooner while larger changes continue to develop separately. This fork is a way for me to put that workflow into practice.

This is not intended as a break with upstream. I plan to continue tracking AviSynth+ development, incorporating relevant fixes, and preserving API and ABI compatibility wherever practical. Compatibility with existing scripts and plugins remains an important goal. Any necessary incompatibility should be an explicit, documented decision rather than an incidental consequence of development.

For features already being developed upstream, my intention is to let upstream complete that work and then incorporate it here, rather than develop a competing, incompatible implementation. The ongoing AVX-512 work is one example: I do not plan to create a separate, incompatible counterpart in this fork.

Engineering and testing

My focus is on improving the project from an engineering perspective, not just adding features. The automated tests here were ported from AviSynthPlus-UT (https://github.com/HomeOfAviSynthPlusEvolution/AviSynthPlus-UT), a test suite I originally wrote for upstream AviSynth+ that has already helped uncover a number of bugs.

The currently enabled suite contains over 400 test definitions, covering core and scripting behavior, audio and video conversion, filters, scalar/SIMD consistency, and regression cases. I intend to build on this work to make changes easier to verify and regressions easier to catch.

Development here is a collaboration between me and AI. I provide substantial guidance, set the technical direction, and review changes; GPT-6 handles implementation, test writing, and additional code review on its own initiative. This applies to both bug fixes and new features. I remain responsible for what is accepted and released.

I would be happy to see fixes from this fork incorporated upstream. Given upstream's stated reservations about AI-assisted code, I do not plan to submit these changes there myself. Upstream maintainers are welcome to take relevant fixes, and other developers are welcome to propose them upstream if the maintainers have explicitly indicated that such contributions are acceptable. Any such contribution should preserve attribution and be transparent about its origin and the use of AI.

Project direction

For now, development is driven by me personally. Contributions and technical discussions are welcome, and anyone interested in longer-term involvement can also discuss joining our GitHub organization. The project will follow a benevolent dictator model: discussion is open, but I retain final responsibility and decision-making authority over its direction and releases.

This will be a project with a strong personal direction, rather than an attempt to preserve every inherited convention. I may make substantial changes where I believe they serve the project's goals. Feedback and technical objections are welcome, but I will not try to accommodate every conflicting preference or require consensus for every decision. Compatibility matters, but it does not mean freezing the implementation or ruling out architectural changes.

Possible future directions include moving SIMD implementations to Highway and exploring an additional ABI, currently called CX1, for cross-toolchain interoperability while retaining support for existing plugins. These are development directions, not commitments for the current release.

Releases

The plan is to maintain two release lines, distinguished by the minor version number:


Stable — even minor versions, like 1.2.0: focused on fixes and conservative changes.
Mainline — odd minor versions, like 1.1.0: where new features and larger internal changes are introduced and tested.


The current 0.1.1 prerelease is the starting point. The two-line structure will develop from there.

I expect releases to be relatively small and frequent, rather than waiting for a large collection of changes. Multiple releases within a month are possible when there are useful fixes to ship. This is not a fixed schedule or a promise of immediate fixes; development currently depends on my available time.

There is also no guarantee that the project will remain actively maintained indefinitely. I may pause or discontinue development for any reason, including changes in personal circumstances, loss of interest, harassment or personal attacks, or changes in upstream's development and release practices that make this fork unnecessary. Constructive disagreement is welcome, but maintaining the project does not imply an obligation to accept personal abuse or continue working on it indefinitely.

Trying 0.1.1

The initial prerelease includes fixes carried over from upstream development, along with additional fixes found through testing. Builds are available for several platforms, but runtime testing varies by platform.

The Windows installer is currently a mod installer over an existing official AviSynth+ 3.7.5 installation. Files-only packages are also available.


GitHub repository (https://github.com/HomeOfAviSynthPlusEvolution/AviSynthMinus)
0.1.1 prerelease and downloads (https://github.com/HomeOfAviSynthPlusEvolution/AviSynthMinus/releases/tag/0.1.1)


Feedback, reproducible bug reports, and compatibility reports are welcome.

Windows ARM64 is built by MSVC with MSVC C++ ABI.

Windows XP support is experimental, as I don't have such environment to verify.

[DTL]

If you can add new features to the Mainline branch and can use AI helpers in development - can you try to add the performance feature of partial plane processing in compatible filters ?
Its working 'tech demo' with internal simple Invert() filter is implemented in that branch - https://github.com/DTL2020/AviSynthPlus/commits/master-1 See commits from 4294605e2873e6c2c7ae69c932792893cb11a30e (Nov 10 2025).

Test script is simple like

ColorBars()
Invert() - filter in parts splitting and parts processing mode
Invert() - filter in parts accept/process/deliver mode
Invert() - filter in parts combining mode for standard full frame output


The size of part to process is either calculated from CPU cache sizes or can be manually set via script environment function SetRowsRegionSize().

It is a complex new addition to filtergraph building that requires more thinking on how to handle complex filter graphs with data splitting. Currently developed auto connection methods via standard cache looks like working only for simple 1 threaded filter graphs without data splitting with cache object.

Filters can have any number of 3 new capabilities:
1. Filter can request/accept and perform processing and deliver part of the processed plane. It is the main action of the intermediate filter in a graph in between the compatible with partial plane processing filters.
2. Filter can do partial processing and delivering of the processed part of the plane and can do internal splitting to parts (filter at the start of the sub-plane processing part of the filter graph)
3. Filter can do partial processing of the plane and can combine parts to the full plane. It is the case if sink filter request data in full frame mode (standard for AVS/AVS+ filters and end of filter graph).

Currently designed new auto filters interconnection method is backward compatible with standard frame-based AVS/AVS+ filters and new enhanced filtergraph action can be created automatically between compatible filters without old scripts modification. Compatible filters first tried to request a better performance connection method from source filter and if not supported - make standard processing as full-frame filter.

What we need from AI to help in development:
1. Understand how a partial plane processing filter is designed and make modifications to all compatible core filters in auto mode instead of hand modification of each filter.
2. Design and suggest cache object modification to support data splitting to part of plane granularity (from current full frame granularity). This is expected to create some cache processing overhead (search cache database for ready/ not ready parts of the plane instead of full frames) but total performance boost from better data locality is expected to be much more.

[MeteorRain]

While I haven't checked your code, my initial thought would be plugin should be able to advertise how nice they are.
Like, right now we have nice filter which can do multi threading. Maybe we can have nicer and nicest plugin that can do per plane and per partial plane processing.
Will consider this feature, but at the moment I'm looking at some other pieces like modernizing some core filters, etc.
Also need to make sure upstream follow the same pattern, otherwise we'll have big trouble on brain splitting.

[MeteorRain]

I've completed the Highway migration of the audio sample-format conversion code and split it into a separate repository: AviSynth - Convert Audio (https://github.com/HomeOfAviSynthPlusEvolution/AviSynthConvertAudio).

The goal is to make the conversion algorithms independently buildable, testable and benchmarkable without AviSynth, and reusable by other projects through a C interface. The host still handles audio requests and the scripting interface, while the module handles all 20 conversion paths between U8, S16, S24, S32 and F32.

All 596 tests currently pass. On Windows x64, coverage of our own code, excluding Highway and other dependencies, is 95.80% for lines and 95.87% for branches.

Compared with the original native kernels from AviSynth+ 3.7.5 under the same conditions, most paths are close to parity on a Ryzen 9 7940H with clang-cl 22.1.3 Release builds, converting 65,536 sample values per call. F32 to S24, U8 to S32 and S24 to F32 achieve speedups of about 1.72x, 1.59x and 1.16x respectively, while F32 to S32 comes in at about 0.98x. These are conversion-kernel timings using the median of seven rounds, not end-to-end encoding speedups, and the comparison does not cover later upstream versions.

[DTL]

While I haven't checked your code, my initial thought would be plugin should be able to advertise how nice they are.
Like, right now we have nice filter which can do multi threading. Maybe we can have nicer and nicest plugin that can do per plane and per partial plane processing.


It looks like the AVS filters are connected with each other directly (via single cache object). Complex AI-like connection manager (like FilterGraphManager in DirectShow ?) is still not present.

So filter ask source about supported connection modes via standard and backward compatible with old and other filters builds interface SetCacheHints - https://github.com/DTL2020/AviSynthPlus/blob/38a96aa2c83b8d1ab68906cebb21580bd28a631e/avs_core/filters/layer.cpp#L586 . It is required to not crash old API binary built filters with new functions calls.

And inform sink filter (typically inserted cache object between connected filters) about supported output connection modes also via this call - https://github.com/DTL2020/AviSynthPlus/blob/38a96aa2c83b8d1ab68906cebb21580bd28a631e/avs_core/filters/layer.h#L166

[MeteorRain]

0.1.2

Bug fixes

Check array indices in ArrayIns, ArraySet and ArrayDel to prevent access violations.
Fix SSE2 tail underflow and possible heap corruption when converting narrow 8-bit planar RGB to packed RGBA.
Preserve color-range metadata when converting packed RGB between 8 and 16 bits.
Correct RGB-to-YUV matrix gain handling for limited-range RGB to full-range YUV.
Preserve out-of-range values in scalar floating-point YUV-to-planar-RGB conversion.
Align the 8-bit scalar Overlay Multiply calculation with the SIMD path.

[MeteorRain]

0.2.0 / 0.1.3

Changes since 0.1.2

Add global named locks for cross-plugin synchronization, with exception-safe operations, C API exception containment, and unused-lock reclamation.
Add the experimental CX plugin adapter, with MSVC/MinGW-w64 GCC interoperability tests on Windows x64. Preserve numeric types, clip/frame identity, copy-on-write, registration lifetime, and nested-plugin context across the adapter.
Fix SaveString comparisons for explicitly sized data containing embedded NUL bytes.
Expand regression coverage for global locks, plugin loading, registration, object lifetime, and concurrency.

CX remains experimental in the stable series. It may become permanent, be restructured, or be removed; forward and backward plugin compatibility remain required, including retaining a compatible loading and execution path for dependent plugins. This does not imply support for every existing plugin API operation or validation on every target architecture.

=====

Next dev version will introduce core component decoupling.