rav1e: the Rust AV1 encoder for pipelines where libaom is too slow

The gap rav1e was written to fill

AV1 arrived with a reference encoder, libaom, that produces good compression and takes its time doing it. The rav1e README states the project's position plainly: rav1e is an AV1 video encoder, designed to eventually cover all use cases, and in its current form most suitable for cases where libaom is too slow. That sentence is the whole pitch. It is not a claim to beat libaom on quality or SVT-AV1 on throughput at every setting; it is a claim about a specific operating point.

The audience follows from that. If you encode a large back catalogue and your bottleneck is wall-clock time rather than bitrate, rav1e is aimed at you. If you are shipping a player, rav1e is irrelevant, because it only encodes. Note also that rav1e is written in Rust and the primary language listed for the repository is Assembly, which reflects how much of the hot path lives in hand-written x86_64 and aarch64 kernels rather than in the Rust code itself.

How rav1e encodes: superblocks, RDO and a speed dial from 0 to 10

The README lists the coding tools rav1e implements: intra, inter and switch frames, 64x64 superblocks, and blocks from 4x4 to 64x64 that are selected by rate-distortion optimisation rather than fixed. Prediction covers DC, H, V, Paeth, smooth and all directional modes. Transforms cover DCT up to 64x64, (FLIP-)ADST up to 16x16 and identity transforms up to 32x32. Colour depth is 8, 10 or 12 bits, and chroma sampling can be 4:2:0, 4:2:2 or 4:4:4.

The control that matters most in practice is the speed setting: 11 of them, numbered 0 to 10, described in the README as running from exhaustive to near real-time. That single integer is the trade between search effort and encoding time, and it is the first thing to sweep when you are tuning a pipeline. Encoding modes are constant quantizer, or target bitrate in single-pass and multi-pass form. There is also a still picture mode, which is easy to overlook if you think of rav1e purely as a video tool.

One constraint the README states without hedging: input videos must be in y4m format, and the monochrome colour format is not supported. There is no ffmpeg-style demuxer inside rav1e. Conversion is your problem, upstream of the encoder.

Installing rav1e and encoding a first file

rav1e currently requires Rust 1.85 or later to build, per the README. On x86_64, some optimisations need NASM 2.14.02 or newer and are enabled by default; the CI tests against nasm 2.15.05, and the README says bugs for other versions might happen. Install nasm first, then build the release binary, which lands in target/release/rav1e.

sudo apt install nasm
cargo build --release

The README notes that the compiler can produce a binary about 11% to 13% faster when it is allowed to use avx2, bmi1, bmi2, fma, lzcnt and popcnt in general code. That is opt-in, and the resulting binary will not run on CPUs lacking those extensions.

RUSTFLAGS="-C target-cpu=native" cargo build --release

If you would rather not guess, `rustc --print target-cpus` shows whether the CPU is supported; the README warns that otherwise `-C target-cpu=native` is a no-op.

For a first encode, the README's own example reads a y4m file and writes an IVF bitstream. There is a test clip at tests/small_input.y4m in the repository if you have nothing else to hand.

cargo run --release --bin rav1e -- input.y4m -o output.ivf

To check the result, the README points at dav1d, which is packaged in over 40 repositories according to the badge it links. Encoder output should be compatible with any AV1 decoder compliant with the v1.0.0 specification.

dav1d -i output.ivf -o output.y4m

If you need to link rav1e from C rather than shell out to the binary, the project provides a C-compatible library, header and pkg-config file, built through cargo-c.

cargo install cargo-c
cargo cinstall --release

Assembly on by default, and the escape hatch when it breaks

The asm feature is on by default, and it is where a good part of rav1e's speed comes from. On x86_64 it requires nasm. On aarch64 it requires gas, with the alternative of using the clang assembler by setting CC=clang. SSE2 is always enabled on x86_64 and neon is always enabled on aarch64, so you cannot compile those away.

What you can do is disable the optimised routines at runtime by setting the environment variable RAV1E_CPU_TARGET to rust. That is a debugging lever, not a deployment choice: falling back to pure Rust paths costs the performance the assembly was written to provide. Its real value is isolating whether a crash or a mismatch comes from the assembly kernels or from the encoder logic, which is otherwise hard to tell apart.

There is a second lever for cross-compilation and portability. The target-specific build above buys you roughly 11% to 13% according to the README, and the price is a binary that will not work on CPUs without the same extensions. For distribution, the README offers `-C target-cpu=x86-64-v3` as the more conservative option, which still excludes older hardware.

Where rav1e is the wrong tool

The clearest boundary is format support. rav1e takes y4m and nothing else, and monochrome is unsupported. If your source is a container format and you have no transcode step, rav1e cannot help you as a standalone tool; you need something upstream to produce y4m first. That is a real cost in a pipeline, not a footnote.

The second boundary is API stability. The README is explicit that experimental API and features are gated behind the unstable feature, and that these features and APIs are bound to change and evolve, with a direct instruction not to rely on them staying the same over releases. The channel API is listed as a current unstable feature. If you are embedding rav1e as a library and pinning to a released API, check whether the surface you need is stable or behind that flag before you commit.

The third is scope. rav1e does not decode, does not mux into containers, and the README's decompression section simply points at dav1d. It is one stage of a pipeline. Treating it as a media toolkit will lead to disappointment.

rav1e against SVT-AV1, libaom and dav1d

The comparison people reach for is rav1e versus SVT-AV1, and the difference in approach is structural. rav1e is a Rust project whose speed comes from hand-written assembly kernels layered onto a Rust encoder, with an 11-step speed dial and a permissive BSD-2-Clause licence. SVT-AV1 comes from a different lineage and is not discussed in the rav1e README at all, so anyone weighing the two should test against their own content rather than trust a summary.

Against libaom, the README positions rav1e as the option for cases where libaom is too slow. That is a statement about the operating point, not a claim of superiority, and it should be read that way.

The rav1e versus dav1d comparison that shows up in search is a category error worth naming: rav1e encodes, dav1d decodes. They are complements. The README's own decode example uses dav1d to read rav1e's IVF output, which is the intended relationship.

Releases, licence and the cost of keeping up

rav1e publishes a weekly pre-release every Tuesday, and the release list bears that out with tags like p20250902, p20250826 and p20250819. The README says this cadence will continue for the foreseeable future. A weekly pre-release stream is convenient if you track master-like behaviour, and awkward if you need long-lived stable versions: pre-releases are not the same thing as a supported release line, and the version in Cargo.toml is 0.8.0.

Upgrade cost is shaped by two things. First, the unstable feature boundary: anything behind it can move between releases by design. Second, the toolchain floor, currently Rust 1.85 or later, which moves forward over time and will eventually force a compiler upgrade on anyone building from source.

The licence is BSD-2-Clause, a permissive licence that generally imposes few obligations on redistribution. The repository also carries a PATENTS file and a license_template.txt, and rav1e implements AV1, which is covered by patent pools. That combination is worth a look from whoever handles licensing on your side; this is a description of what is in the repository, not legal advice.

Editorial conclusion

rav1e fits teams that already build Rust tooling and need an AV1 encoder with a permissive licence and a C API they can link against. It does not fit anyone who needs hardware-accelerated encoding, monochrome sources, or a stable API surface, since the channel API sits behind the unstable feature and the README warns those features are bound to change. Before adopting it, verify two things on your own machine: that nasm 2.14.02 or newer resolves on PATH for x86_64 assembly, and that your input is y4m, because rav1e does not accept anything else.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. README
4. Releases
5. xiph/rav1e on GitHub