Anime4KCPP v3: Building the CNN Anime Upscaler from Source

What Anime4KCPP v3 solves, and who it is for

The project describes itself as a high performance anime upscaler, and v3 states that it uses a CNN based algorithm and aims to be simple and efficient. That is a narrower claim than a general image enhancer. The target user is someone with a video or image pipeline already in place: an FFmpeg user who wants an upscaling stage, a VapourSynth or AviSynth script author who wants a filter node, or a Windows user who wants a DirectShow filter inside a capture or playback graph. The repository layout reflects that audience. There are separate top-level directories for cli, gui, video, filter, binding, core and tests, so the core algorithm is packaged behind several front ends rather than shipped as one monolithic binary. There is also a WebAssembly playground hosted on GitHub Pages for upscaling images in the browser, which the README notes requires disabling Enhanced Security for the site in Microsoft Edge to reach optimal performance. If you want a drag-and-drop desktop product with an installer and a support contract, this is not that. If you want a library-shaped component you compile yourself and wire into something else, the module split is the point.

The module split: core, video, filter, cli, gui, binding

Anime4KCPP v3 is assembled at configure time from optional modules, each gated by a CMake option. The core module carries the CNN work and can be built against CUDA, OpenCL, Eigen3, or a CPU path, controlled by AC_CORE_WITH_CUDA, AC_CORE_WITH_OPENCL and AC_CORE_WITH_EIGEN3. The video module wraps libavcodec, libavformat, libavutil and libswscale behind AC_BUILD_VIDEO, which is what lets the tool read and write real video containers rather than single images. The filter module has three independent variants: AC_BUILD_FILTER_AVISYNTH, AC_BUILD_FILTER_VAPOURSYNTH and AC_BUILD_FILTER_DIRECTSHOW. The cli module pulls in CLI11 via AC_BUILD_CLI, the gui module pulls in Qt via AC_BUILD_GUI, and AC_BUILD_BINDING_PYTHON brings in pybind11 for Python bindings. This is the actual architecture a reader needs to understand before running cmake: nothing is included unless you ask for it, and each option adds its own dependency. Dependencies are handled two ways. With internet access, CMake downloads and configures most of them automatically. Where that is not possible, most are located through find_package, some through pkg-config, and others through dedicated variables such as AC_PATH_FFMPEG, AC_PATH_EIGEN3, AC_PATH_CLI11, AC_PATH_AVISYNTH_SDK, AC_PATH_VAPOURSYNTH_SDK and AC_PATH_FPNG. The README states that setting these variables directs CMake to search your specified paths first and overrides default search locations. That override behaviour is worth knowing: a stale AC_PATH_FFMPEG pointing at an old build will win over a correct system package, and the resulting error will look like a version problem rather than a path problem.

How to build Anime4KCPP v3 and run the CLI

The build requires CMake and a C++17 compatible compiler. CUDA, FFmpeg, Qt and the AviSynth SDK are manual acquisitions rather than automatic downloads, so on a machine without internet access you must supply those yourself before configuring. The README gives a MinGW-w64 recipe for Windows. It creates a build directory, configures with OpenCL enabled and a static CRT, builds in Release, then runs the CLI with the version flag. The -v flag is the fastest way to confirm the build produced a working binary and to see what was compiled in.

mkdir build; cd build
cmake -G "MinGW Makefiles" .. -DAC_CORE_WITH_OPENCL=ON -DAC_ENABLE_STATIC_CRT=ON
cmake --build . --config Release -j8
cd bin
./ac_cli -v

The MSVC variant differs only in the generator string and drops the static CRT flag. Note that the README excerpt ends mid-command here, so the full MSVC build line is not reproduced below; substitute your own build invocation after configuring.

mkdir build; cd build
cmake -G "Visual Studio 17 2022" .. -DAC_CORE_WITH_OPENCL=ON

For a first real use, the practical path is to build with AC_BUILD_VIDEO and AC_BUILD_CLI and skip the GUI and filter modules entirely, since those add Qt and SDK dependencies you may not need. The README does not document ac_cli's argument list beyond the -v example, so treat the CLI11-based interface as something to discover from the binary's own help output rather than from the documentation. That is a real gap for a tool whose main front end is a command line.

Where Anime4KCPP v3 is the wrong tool

The build cost is the first limitation, and it is not incidental. CUDA Toolkit, FFmpeg libraries and Qt are all listed as manual acquisitions, meaning CMake will not fetch them for you. If you want the GUI, you need Qt5 or Qt6 plus a working CMake find_package for it. If you want the video module, you need FFmpeg 4 or newer libraries discoverable through pkg-config or AC_PATH_FFMPEG. If you want the VapourSynth filter, VapourSynth SDK 4 is required. Each of these is a precondition, not a convenience. The second limitation is that the README excerpt documents building and a browser playground but gives no usage documentation for the CLI beyond a version check and no documented API surface for the Python binding. A binding module exists via pybind11 and AC_BUILD_BINDING_PYTHON, but the README does not describe what the binding exposes. If your workflow depends on a stable, documented interface, that is a risk you are accepting. Third, DirectShow is Windows-only, stated plainly in the README, so any pipeline built around that filter does not travel to Linux or macOS. Fourth, the browser playground carries a browser-specific caveat about Enhanced Security in Edge, which suggests the WebAssembly path is not uniform across browsers. Finally, the release history is uneven: v2.5.0 landed in January 2021, v3.0.0 in August 2025, and v3.2.0 in May 2026. Anyone upgrading from a v2-era deployment is crossing a multi-year gap in one step, and the README's framing of v3 as a CNN-based rewrite implies the algorithm changed underneath them.

How it compares to an FFmpeg-only upscaling chain

The obvious alternative is to do upscaling inside FFmpeg itself, using its own scaling filters, and skip Anime4KCPP entirely. The difference in approach is that FFmpeg's scalers are general-purpose resamplers: they interpolate pixels by a fixed kernel and know nothing about line art, flat colour regions or the ringing that appears around hard edges in animation. Anime4KCPP v3 puts a CNN in that position instead, on the argument that a learned model produces better results on anime content specifically. The trade is cost and complexity. An FFmpeg-only chain has no extra build step, no CUDA or OpenCL requirement, and no dependency on a project whose CLI arguments are not documented in its README. Anime4KCPP gives you a filter module for AviSynth, VapourSynth and DirectShow, which means it can sit inside an existing script-based workflow as a node rather than as a separate pass over rendered frames. That integration is the strongest argument for it: if your pipeline is already a VapourSynth script, adding the filter is architecturally cleaner than shelling out to a second binary. If your pipeline is a single ffmpeg command line, the calculus is weaker and you are paying a build cost for a quality improvement the README asserts but does not quantify.

Licence, maintenance and upgrade cost

The repository carries two licence files at the top level, LICENSE-GPLv3 and LICENSE-MIT, and the project is listed as GPL-3.0. The presence of an MIT file alongside GPLv3 means the licensing is not uniform across the tree, and you should read both files before deciding how the code can be used in your own product. This is not legal advice; the practical step is to identify which directories your build actually pulls in and check the licence covering those. On maintenance, the last push was on 2026-07-04, which is recent, and the repository is not archived. The release cadence is the more useful signal for planning: v2.5.0 in January 2021, v3.0.0 in August 2025, v3.2.0 in May 2026. That is not a project shipping point releases every few weeks, so pinning to a tag and building from source is a reasonable posture. The upgrade cost is dominated by the dependency matrix rather than the code. Because CUDA Toolkit 11 is the minimum tested version, FFmpeg 4 is the minimum library version, Qt5 and Qt6 are both acceptable, and VapourSynth SDK 4 is required, a major bump in any of those is what will force you back into the build. Non-MSVC compilers also pull in a modified version of the DirectShow BaseClasses from a separate repository, which is one more external moving part on Windows.

Editorial conclusion

Adopt Anime4KCPP if you already run FFmpeg, Qt or VapourSynth and want a CNN upscaler that plugs into those pipelines as a filter or CLI step. Do not adopt it if you need a packaged installer, a documented API, or a browser build that behaves the same across browsers. Before committing, verify that your FFmpeg libraries are version 4 or newer, that your CUDA Toolkit is at least 11 if you enable CUDA, and that your VapourSynth SDK is version 4. Then build with only the modules you need and run ./ac_cli -v to confirm which backends were actually compiled in.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. TianZerL/Anime4KCPP on GitHub