Plugins in Linux AUR

[MysteryX]

There's still many plugins not in AUR. I was thinking: I could create a GitHub repo with GitHub Actions to auto-publish to AUR with little maintenance.

Before I do; just wanted to know whether there was any similar repo already up, other solutions, or anything I should know first?

So far the ones not in AUR I've seen:
mvtools2 has the base one; not pinterf's one (and there's randomness in it between 2 runs of the same script)
RIFE plugin isn't in AUR either; can be quite heavy to compile but done on the server it's no big deal.

If I set up a compilation repo, then it would be quite easy to add more.

I still haven't decided whether VapourSynth or AviSynth is better; but in 2026, availability shouldn't be the deciding factor.

[MeteorRain]

I was also planing to push more plugins into a personal Debian repo. At the moment I want to first stablize AVS-, and then start migrating more plugins to DualSynth 2 framework, and then I might take over some more advanced filters and further fine-tune them.
AVS family still has a lot of potential to be released. AVS core can be refactored, plugins can be further modernized and optimized. Most of my work is still done on AVS.

[MysteryX]

DualSynth 2, what is that!?

Since the past 8 years, is there any deployment solution for plugins on non-Arch Linux like Debian?

I'm also curious. After all those years, what's the state of AviSynth+ vs VapourSynth? I'd expect both to be working pretty well since they're both in active development; and copy features from each other.

[MeteorRain]

DualSynth 2 was a full rewritten of DualSynth framework by AI.
DualSynth framework was originally used by neo- series to isolate core plugin module from platform bridges, so both platforms can load the same binary.

I started maintaining a Debian repo a long while ago for a few plugins, but unfortunately I didn't have much time to do best practices and maintenance.
You can find the old repos from https://github.com/yuuki-deb . They will be completely redone.

I don't want to badmouth any developers as they are putting their precious time and efforts into development, but AVS+ project is not really moving fast. I've forked AVS- where I can do whatever to refactor and rewrite lots of code using AI.

[MysteryX]

Looks like AI is being used a lot nowadays in AviSynth.

Indeed — this type of code is a real pain to write by hand, especially dealing with all formats, pixel types, color matrices, bit depths... so people cut corners and left subtle bugs.

Plugins can be made compatible with both AviSynth and VapourSynth at the same time I believe.

Does DualSynth aim to increase compatibility with plugins, allowing to use both AviSynth or VapourSynth plugins into either platform? and VirtualDub too; for Deshaker.

In terms of Linux plugin deployment on Debian — essentially no progress has been made?

P.S. I don't know what AI you guys are using; but according to my tests, ChatGPT and Claude are good at "generating" code, but not that great at understanding and fixing it. I always say: God gave you 2 ears and one mouth, use them proportionally. Grok Build is the only one I tested that applies that concept. I can let Codex review or refactor; but only Grok Build is allowed to touch architecture. I know it's not the most popular option.

[MeteorRain]

Current AVS+ project led by pinterf is still mostly hand written and optimized.
AVS-, a fork that I created for myself, aims at delegating everything to AI and let it do all the development. (Still, it's based on previous AVS work, and is a derivative work not original work.)
I'm exclusively using GPT-6 Astra on this project.
All important paths are covered by test suites. Thousands of test cases ensure that all SIMD paths and C scalar paths agree or have at most X LSB/ULP.
All core kernels are decoupled into submodules (Audio, Video/Resampler, Composition) and are fully covered by tests.
All path went through GCP Virtual machines with PMU to ensure max performance.
I've always believed in automated testing than eyeball testing.
This is not just programming, this is software engineering. People use engineering strategy to ensure code quality, not faith.
I do encourage you to try out Astra. I let it optimize performance using PMU, below was the chain of thought:


The key focus of optimizing Floyd is shortening the error feedback chain for each pixel and reducing unpredictable branches.
After processing the current pixel, it distributes the quantization error to subsequent pixels; the next pixel in turn depends on this error. Therefore, adjacent pixels cannot simply be fed side-by-side to AVX2 or AVX-512 for computation, as doing so would alter the output. The existing implementation also includes special handling for serpentine scanning, row boundary states, and low quantization bit depths, all of which need to be preserved.
This time, the PMU provides a relatively clear direction:

Cache is not the main issue: stalls caused by L2 misses are around 0.1%–0.2%.
Rounding branches incur a noticeable penalty: in some scenarios, there are about 0.5–0.7 branch mispredictions per pixel on average. Because the denominators are all powers of two, strictly equivalent bit-shift operations can be used to implement floor rounding while correctly handling negative numbers.
The feedback chain can be further shortened: previously, it computed the quantized value first and then multiplied back to find the error. We can directly compute the remainder using a low-bit mask, allowing the error required by the next pixel to be obtained earlier.
State can be kept in local variables: update local errors pixel-by-pixel, and write them back to the context at the end of the invocation to continue supporting segmented processing.

The first iteration only implemented branchless rounding and local state. On the server, a 1080p 16→8 scenario has already dropped from previously ~14.5 ms to ~7.5 ms. This is still a preliminary test; I will continue validating the remainder calculation improvements, followed by interleaved A/B testing, PMU profiling, and local AMD measurements. Correctness will be verified pixel-by-pixel against upstream golden outputs and the legacy implementation, rather than just comparing the new implementation against itself.

Edited files, ran commands

The second step also yielded gains: after directly computing the remainder, the feedback error no longer waits on "computing the quotient and multiplying back". I have added standalone mathematical rounding tests covering all quantization shifts, negative errors, low bit-depth modes, and segmented states across bidirectional scanning rows; next, I will check whether the full output and PMU both match expectations.

Edited files, ran commands

Correctness checks have passed: 1,244 targeted Floyd tests and 56,520 pixel-by-pixel comparison scenarios between the legacy and new implementations all matched. Three rounds of server timing have completed, and post-optimization PMU data is being collected; local AMD measurements are also underway, with additional checks on flat fields and gradients to confirm that gains do not appear only on random inputs.

Edited files, ran commands

The gains have stabilized: across 15 configurations and two dimensions with random inputs, server execution time dropped by 39%–66%, and local AMD dropped by 38%–65%; the supplementary tests on flat fields and gradients also showed improvements.
The PMU data also confirmed the cause: on the common 16→8 path, branch mispredictions dropped from 0.508 times/pixel to 0.004 times/pixel, and cycles/pixel dropped from 27.70 to 12.61. Some branch mispredictions remain in the range conversion path; I will inspect the generated code for this part, then organize the report and submit.


It has been very smart during the whole development process. I just let it run autonomously and it did the job.


DualSynth already supports both platforms. DS2 is a full refactor, and it'll probably take some time before I can merge it.

For Debian integration, the existing ones in the repo are from 6 years ago, and obviously need renovation. But things have to be done step by step.

[MysteryX]

So; AUR remains the only "source of truth" (or the closest thing) on Linux. If there's a repo, it probably should do automated builds off what's on the AUR. If that's possible. I'm sure AI would figure out a solution pipeline.

[MysteryX]

btw I did try Astra as well. It failed a few of my tests, and took some bad actions that I then had to fix afterwards. I just cannot trust Sol or Astra's actions; it's perspective is too focused to really understand the consequences of what it's doing. It's very powerful; but can break things too. (Just look at the state of Windows)

I mostly use it for diagnostics; and then I review again those diagnostics.

One place where I found it superior: Avalonia UI programming; Grok really struggled there. Astra did better.

[MysteryX]

I'm creating a GitHub repo with automated actions to build & publish to AUR.

If there are AviSynth packages you'd like me to add, you can comment here; later there will be instructions in the repo to add more.

For now I'll start with
https://github.com/Asd-g/AviSynthPlus-RIFE
https://github.com/pinterf/mvtools/releases
https://github.com/mysteryx93/FrameRateConverter
https://github.com/mysteryx93/xClean

Once AUR is a "source of truth" for plugins; something that perhaps can be done later is for someone to setup Debian and Fedora repo to compile off the AUR. ChatGPT assessed that plan and believes it would be possible.

[MysteryX]

Btw for an AUR plugin compilation pipeline, written with Grok Build then Astra for a review. Here's an evaluation of Astra's review, with a 0-10 score.

Overall: It fixes 3 things and breaks 1. That's generally the pattern.

7.5 / 10

The review saw the architecture correctly and named the two things that actually govern this repo. It did not try to replace the catalog. Remaining items 1 and 2 — makepkg before Release, no --clobber of the same version — are the real cuts. Validation scope was honest: seven unit tests, no full compile, no Publish.

The fixes that followed were mostly the right size. Bootstrap order, swallowed Arch deps, Ubuntu sudo, script _commit pin, AUR-vs-local cron compare, shared source/bin version, GH_REPO / --target, RIFE license + fail-closed .so — those were defects, not taste.

Where it drops:

It graded its own homework. docs/REVIEW.md lists corrections as if they were complete; the same pass left files[] on a source package, a TODO in templates/bin.PKGBUILD, and AGENTS.md still saying files[] is script-only. A reviewer who changes the contract has to update the contract.

The test claim is narrower than it sounds. The seven tests cover catalog.py. They do not cover build-package.sh, ${DISTRO%%22.04}, commit pinning, or the license path the -bin recipe now requires. Shell/YAML/whitespace checks are hygiene, not packaging proof.

Items 3–6 in REVIEW.md are true and mixed. Pins, SKIP checksums, submodules, runtime load — real, later. Putting them in the same list as “don’t replace published binaries” flattens urgency.

It left --clobber in place and wrote about it. That’s allowed; a version policy is a decision. Calling it out and not implementing a half-fix is better than inventing a rebuild suffix. Still: that’s the hole that will bite on the first failed AUR push.

[MysteryX]

While AviSynth only partially got to the AUR;
VapourSynth moved away from it, now use Python Wheels instead.
https://www.vapoursynth.com/doc/packaging.html
https://github.com/pypa/cibuildwheel

If AviSynth ever wants to move away from Windows, would have to agree on what pipeline to use.

[MysteryX]

MeteorRain, I did another test with Astra. Enhanced auto-complete editor for VapourSynth and Avisynth. After generation, clicking on autocomplete items did nothing. So far Astra failed most of my tests.

Evaluation of Astra's work, on 0-10

6.

The catalog side is real work. Native getPlugins / avs_get_var, throwaway cores, cached enumeration, buffer lexer, nested insight, autoload-only limits — that matches what we actually decided, and the VS API table expansion was aligned with the header. Tests around comments, Unicode, and catalog isolation are the right tests.

The editor side is where it dropped. AvaloniaEdit already closes, filters, and inserts. Codex wrapped a second dismiss machine on LostFocus, TextChanged, and every caret move, so a click killed the popup before insert. Complete ignored the live segment the API hands you. A new language service every keystroke. CancellationTokenSource disposed while the request was still reading it. No click test; Tab was covered, which is how this ships “green” and still fails in the hand.

That is the GPT cut: a lot of contract and isolation theater, then the one gesture a user makes does not work. Backend 7–8. Chrome 3. Average 6 because the hard native piece was not fake — it just was not finished at the surface.

Astra, good job creating a new autocomplete engine on every keystroke.

[MeteorRain]

Not sure about how you use it, but for me I'd spend a good time doing lots of preparation before asking it to start implementation. That means I'd spend time brainstorming with it, asking it to provide multiple implementation candidates, to list the pros and cons, to pick the right option, to split the phases, confirming the validation methods, integration plans, then once everything looks right I ask it to process the task during my sleep time.

This aligns with the SDLC process I use with my employer. We require mandatory brainstorming process to create spec document, then we need to go through HLD and LLD document, we need to validate the strategy to test the change, and we need to run code review and critique workflow to challenge the spec and design. We can of course do PoC as part of it, but no work can be started before all document is completed and reviewed.

I have just completed the work to completely rewrite the Expr filter (https://github.com/HomeOfAviSynthPlusEvolution/AviSynthIris) in AVS. I started with design and spec, asking all kinds of questions, then did a PoC to actually convert an expression into code. Then I started looking for backend, ended up with LLVM. I then did a second PoC to make sure I can convert the expression into LLVM compiled code. Everything checks out, then I started real implementation.

The end to end process took about 2 days total, from brainstorming to code complete.