Av1an runs many encoders in parallel on one file

Parallel encoder processes raise CPU use per file

One encoder executable driven by a single command is the usual shape of a transcode job, and on a large machine it leaves most of the hardware idle. Av1an exists to change that shape: its stated purpose is to increase encoding speed and improve cpu utilization by running multiple encoder processes in parallel. The demo asset at the top of the page is captioned as Av1an fully utilizing a 96-core CPU for video encoding, which tells you the machine class this is aimed at. That means a home lab, a render box, or anyone with a queue of files and cores to spare, not a laptop with one clip to convert.

The binary runs on Windows, Linux and macOS, is written in Rust, and drives six encoder executables: aomenc, SvtAv1EncApp and rav1e for AV1, vpxenc for VP8 and VP9, x264 for H.264 and x265 for H.265. Hyper-scalable encoding, cancel and resume without loss of progress, and VMAF plotting sit on top of that parallel core. For a single short file the whole layer costs more than it saves, which is worth keeping in mind before installing it as a default.

Two crates share one Cargo workspace

At the root of the repository sit two crate directories, `av1an-core/` and `av1an/`, wired together by a Cargo workspace rather than a single crate:

[workspace]
members = ["av1an-core", "av1an"]
resolver = "3"

Shared dependency versions are declared once in the workspace block: `anyhow` at 1.0.99, `tempfile` at 3.26.0, `path_abs` at 0.5.1, `num-traits` at 0.2.19, `once_cell` at 1.8.0 and `tracing` at 0.1. That split is the first thing to look at if you plan to patch it, since chunking and encoding logic can move without dragging the command line surface along.

Build cost is tuned in several profile blocks. Dependencies compile at `opt-level = 2` even during development while Av1an's own dev profile sits at `opt-level = 1`, and a separate profile switches thin LTO off, raises `codegen-units` to 1024 and turns `debug-assertions` and `overflow-checks` back on:

[profile.ci]
inherits = "release"
lto = "off"
codegen-units = 1024
debug-assertions = true
overflow-checks = true

Overflow checks on in CI mean arithmetic mistakes surface as panics rather than silent garbage in a chunk, which is the behaviour you want in a tool that writes video frames from many processes at once. Around the crates sit `rust-toolchain.toml`, `rustfmt.toml`, a `Justfile`, `codecov.yml`, `.codeclimate.yml`, `SECURITY.md`, `MANIFEST.in`, a `.devcontainer/` folder and a `site/` directory holding the documentation the README links to.

Scene chunking leans on VapourSynth source plugins

Parallelism only pays off if the input is cut into chunks that can be encoded independently, and the quality of that cut depends on which VapourSynth source plugin is installed. L-SMASH is recommended for better chunking, FFMS2 is offered for better chunking, BestSource trades speed for accurate chunking, and DGDecNV aims at very fast and accurate chunking.

That last option carries a hardware gate: the `dgindexnv` executable needs to be present in the system path and an NVIDIA GPU with CUVID has to be there too, so the fastest chunker is out of reach on a CPU-only host. Every plugin in that list is described as an improvement, which leaves plain FFmpeg as the baseline reader and the default concatenation step. Installing `mkvmerge` swaps that step for mkvtoolnix instead, and the runtime container carries mkvtoolnix-cli in its base layer for that reason. Chunk boundaries decided by a cheap reader are where quality artefacts enter a multi-process encode, so this choice carries more weight than its place in the optional list gives it.

Target Quality mode borrows metrics from outside Av1an

Target Quality mode is what makes Av1an more than a parallel driver. It uses metrics to control the encoder's rate control, so a run is steered toward a target score rather than a fixed bitrate or a constant quality number. Each metric lives outside the binary: VMAF for VMAF scores, XPSNR for XPSNR scores, SSIMULACRA2 through the Vapoursynth-Zip or Vapoursynth-HIP plugins, and Butteraugli through vapoursynth-julek-plugin, with Vapoursynth-HIP adding hardware acceleration on supported GPUs.

All of those sit in the README's optional prerequisites list, which means a plain install gets the mode's shell without the metric it needs to steer by. VMAF plotting covers the other half of the loop, showing how the achieved score moved across chunks instead of leaving you to read an encode log and guess. Treat the metric package as part of the install, not as an extra: without one, the interesting half of the tool is inert.

Three install paths and one hard prerequisite

Three install paths are offered, and all of them stop at the same prerequisite. On Arch Linux and Manjaro the package manager route is one line, and cargo is the fallback elsewhere:

pacman -S av1an
cargo install av1an

Pre-built Docker images bundle the dependencies, and Windows users get prebuilt binaries plus a nightly build of the current `master` branch. Manual installs start from three prerequisites: FFmpeg, VapourSynth, and at least one encoder from the supported list. On Windows the L-SMASH, FFMS2 and BestSource plugins come from a script inside the VapourSynth installation directory, opened with Shift plus Right click:

python3 vsrepo.py install lsmas ffms2 bs vszip julek

With an encoder present, the first real encode is a plain file pair:

av1an -i input.mkv -o output.mkv

The second documented example shows the fuller surface, passing a VapourSynth script, an encoder-style argument string, a worker value of 10, a target quality of 95, an audio argument string that selects libopus, a log name and an output path in one line:

av1an -i input.vpy -v "--cpu-used=3 --end-usage=q --cq-level=30 --threads=8" -w 10 --target-quality 95 -a "-c:a libopus -ac 2 -b:a 192k" -l my_log -o output.mkv

The encoding arguments go through untouched, which is how you keep control of the encoder's own knobs while the framework owns scheduling. Flag semantics are not spelled out in the README; it points at the documentation site and at `av1an --help` for the reference, so budget a few minutes there before your first serious run.

The Docker image compiles rav1e from git

The Dockerfile shows what the maintainers consider the complete dependency set, and it starts further back than most people expect:

FROM archlinux:base-devel AS base
RUN pacman -Syu --noconfirm
RUN pacman -S --noconfirm --needed aom ffmpeg vapoursynth ffms2 libvpx mkvtoolnix-cli svt-av1 vmaf
ENV VAPOURSYNTH_EXTRA_PLUGIN_PATH="/usr/lib/vapoursynth"

One comment explains that the extra plugin path covers a change in VapourSynth R74 packaging. Compilation goes through cargo-chef, a planner stage produces a recipe and a cook stage builds dependencies before Av1an itself is built and moved into `/usr/local/bin`. rav1e is handled differently: the image clones https://github.com/xiph/rav1e and compiles it from git, because the comment notes Arch is still on rav1e 0.4, then strips that binary into `/usr/local/bin` too.

The runtime stage is deliberately thin. It starts from the same base layer, copies exactly two files into `/usr/local/bin`, creates a user named app_user, points `MPLCONFIGDIR` at that user's home, mounts `/videos` as the working directory and runs av1an as the entrypoint:

COPY --from=build /usr/local/bin/rav1e /usr/local/bin/rav1e
COPY --from=build /usr/local/bin/av1an /usr/local/bin/av1an
RUN useradd -ms /bin/bash app_user
VOLUME ["/videos"]
WORKDIR /videos
ENTRYPOINT [ "/usr/local/bin/av1an" ]

Nothing in the file pins a base image digest or a package version, and `pacman -Syu` resolves against whatever the mirror serves that day, so two images built weeks apart are not guaranteed to hold the same encoder build.

Library packages sit where executables are required

Read the encoder requirement against the runtime layer and a mismatch appears. Av1an requires the executable encoder, and the warning is explicit that installing only the library is not enough, with libvpx and libSvtAv1Enc named as the failure case. The container's base layer installs packages called libvpx and svt-av1, which read as libraries by name, and the one encoder binary compiled from source is rav1e, taken from git rather than from the mirror. aomenc, vpxenc, x264 and x265 are never placed into the image by any line of the file. Inside the container the six encoder paths are therefore not equal, and the README says nothing about verifying at build time which executables survived the base layer.

Its tagged history is uneven too: v0.5.2 (2026-01-04) and v0.5.1 (2026-01-03) sit two days apart, the rolling `latest` build is dated 2025-12-08, and all three predate the 2026-09-28 push on master. Anyone tracking upgrades is better off watching master than waiting for a version number to move. The README also documents cancel and resume without loss of progress, but it does not document rollback, so there is no stated way to undo a run partway through and return to an earlier encode.

Hand-rolled FFmpeg runs versus Av1an's extra layer

The honest alternative is to skip the framework. Av1an needs FFmpeg and an encoder executable anyway, so a hand-rolled pipeline that calls the encoder on a whole file, concatenates with FFmpeg or mkvmerge and logs the resulting score is entirely possible. What the framework removes is the manual orchestration of chunking, worker count, per-chunk scoring and resume, and that saving is real only when you have many chunks to process.

It is also the wrong tool for any encoder outside the six it names, for a bit-exact pipeline that expects one process to start and finish, and for a host where VapourSynth cannot be installed, since both chunking and the metric loop lean on it.

The repository is not archived, its last push was on 2026-09-28, and it is published under the GPL-3.0 licence. Anyone embedding it in a distributed service inherits copyleft obligations from that identifier and should read the terms before the first build rather than after.

Editorial conclusion

Adopt Av1an when you have many cores, one of the six supported encoder executables, and VapourSynth plus a metric tool installed; the parallel processes, per-scene chunking and scored rate control pay for the orchestration layer there. Skip it for one file on a laptop, for an encoder outside that list, or for a workflow that cannot carry copyleft terms. Before the first build, run `av1an --help`, confirm which encoder executable sits on the path, and run one short file before queueing a whole library.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. rust-av/Av1an on GitHub