On Linux, the build environment is isolated using a distrobox/podman container by default.

1. Install dependencies
   • Pacman: sudo pacman -S --needed distrobox podman python git
   • APT: sudo apt install distrobox podman python3 git
   • DNF: sudo dnf install distrobox podman python3 git
2. Build
   • python3 BUILD.py --arch
3. Run
   • ./build/AviQtl

On macOS, BUILD.py checks and installs dependencies via Homebrew (CMake, Ninja, Qt6, etc.), then runs macdeployqt and codesign to create a .app bundle.

1. Install dependencies
   • brew install python git
2. Build
   • python3 BUILD.py --xcode
3. Run
   • open ./build/AviQtl.app

1. Install dependencies
   • pacman -S git mingw-w64-ucrt-x86_64-python
2. Build
   • python3 BUILD.py --msys2
3. Run
   • ./build/AviQtl.exe

MSVC builds are not recommended due to the complexity of environment setup.

1. Additional prerequisites
   • Visual Studio 2022 Build Tools with C++ toolset
   • Official Qt MSVC x64 build (e.g. msvc2022_64)
   • vcpkg (can be specified via VCPKG_ROOT env var; BUILD.py will attempt to fetch it if not found)
2. Build
   • python3 BUILD.py --msvc --qt-dir <Qt installation directory>
   • If --qt-dir is omitted, automatic detection from QT_MSVC_DIR etc. is attempted.
3. Run
   • .\build\AviQtl.exe

It started with AviUtl not running on Linux. Maintaining a Windows environment solely for AviUtl was unacceptable.

Regardless of the reason, many users continue using AviUtl reluctantly. The ecosystem, bloated by years of extensions like a "Howl's Moving Castle", is hard to let go of despite the dissatisfaction.

During a research project at Kagoshima Prefectural Konan High School, I decided to develop NeoUtl independently to solve this problem.

• Personal goal: Produce music videos using only NeoUtl on Linux, without juggling Domino, VocalShifter, REAPER, and AviUtl.
• NeoUtl's mission: To be the optimal solution for those who use AviUtl reluctantly.

AviQtl-Plus is not a "reinvention of AviUtl". While it is strongly inspired by AviUtl, its internals are entirely different.

AviQtl-Plus fundamentally resolves structural weaknesses:

1. Data-oriented design with ECS (Entity Component System): Maximizes CPU cache efficiency, accelerating processing of large numbers of objects.
2. Modern memory management: Adopts C++23 smart pointers, structurally minimizing unexplained crashes.
3. Separation of UI and rendering: Timeline operations are not blocked during heavy rendering, and the UI remains crisp in High-DPI environments.

The name is a portmanteau of "AviUtl" and "Qt". The icon is a design combining the Qt and AviUtl logos.

+ =

No. The mechanisms differ, so there is no compatibility. There are no plans to implement a compatibility layer either.

The original project was suspended due to genuine technical difficulties with Qt Quick — but it also proved that Qt + FFmpeg can rapidly produce a high-quality video editor prototype. The architecture is well-designed, the foundation is solid, and I believe the Qt Quick route is still worth pursuing, especially now that QRhi provides a viable compute shader path that wasn't fully explored.

As an early core contributor, I've seen the project's potential firsthand. I'm picking up where the original author left off, not just to keep the code alive, but to see the original vision through — a video editor that inherits AviUtl's operability while surpassing its performance.

Completed (0.3.0):

• LuaJIT plugin system with lifecycle hooks, declarative parameters, and fine-grained permission control
• Package manager for installing/updating plugins, effects, and objects from remote repositories
• 24 unit tests covering core, engine, scripting, and plugin subsystems
• CI via GitHub Actions (build + static analysis)

Completed (0.3.1-0.3.2):

• Thread-safe audio processing with lock-free shared pointers and keyframe evaluation optimization
• HDR output, opacity, and multi-pass dispatch for Compute Shader effects
• Transition effects (Dissolve, Slide, WipeCircle)
• Audio plugin keyframe editing and mixer panel UI
• Effect schema documentation and sepia effect example
• Hardcoded constant extraction and log standardization
• Object JSON/QML naming consistency alignment
• macOS build and packaging fixes (atomic shared_ptr, carla-discovery-native RPATH)

Completed (0.4.0):

• GPU compute shader optimizations: SRB pre-allocation, fine-grained dirty flags, separable blur, bitonic sort
• BorderBlur O(n²) → O(2n) with edge-detect blend and aspect ratio control
• Multi-pass ping-pong correctness for 3+ pass dispatches

Completed (0.5.x):

• End-to-end daily editing, missing-media recovery, and atomic project saves
• Unified searchable object/effect catalog with package provenance
• Real QML composition capture and encoded MP4 verification
• Large-timeline virtualization and continuous zoom performance fixtures
• Video decoder GOP/frame-cache lifecycle and eviction coverage
• Linux, macOS, and Windows release builds with platform test steps
• Consistently green release baseline and version validation
• Independent autosave snapshots and startup crash recovery for multiple projects

Next (0.5.9+):

• Measure representative long-video, long-audio, and plugin-scanning workloads
• Continue workflow-level usability hardening with real editing projects

Long-term:

• Full-featured video editor suitable as an AviUtl replacement
• Potential rebranding (name and logo) to reflect the independent direction of the project
• Continue monitoring the new NeoUtl's progress and explore cross-pollination opportunities between projects

The project is entirely driven by personal motivation — there are no deadlines or commercial pressures. Progress will be steady but paced.

The technical direction remains largely the same (Qt Quick + QRhi + ECS), but AviQtl-Plus places greater emphasis on:

• Incremental deliverability: getting a basic but usable editing workflow out the door, rather than pursuing architectural perfection upfront
• Pragmatic problem-solving: working within Qt Quick's constraints rather than treating them as blockers
• Community transparency: clear documentation of the fork relationship, plans, and long-term intentions

Once the project reaches a usable state, a rename and rebranding are likely to clearly distinguish it from the original project.