Rav1e: The fastest and safest AV1 encoder
1 points · Open discussionxiph
rav1e
Assembly2018–2025
xiph / rav1e
rav1e
The fastest and safest AV1 encoder.
22Distinct people
25Mentions
0Explicit recommenders
4.2KGitHub stars
What to know before exploring
What it is
The fastest and safest AV1 encoder.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- openvisualcloud/svt-av1 · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year25 dated mentions
Observed mentions: 2018-02-24 06:56:35 UTC to 2025-06-16 16:52:37 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 9 | 2 | 7 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 1 | 0 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
rav1e
The fastest and safest AV1 encoder.
Table of Content
Overview
Features
Documentation
Releases
Building
Dependency: NASM
Release binary
Unstable features
Target-specific builds
Building the C-API
Usage
Compressing video
Decompressing video
Configuring
Features
Contributing
Getting in Touch
Overview
rav1e is an AV1 video encoder. It is designed to eventually cover all use cases, though in its current form it is most suitable for cases where libaom (the reference encoder) is too slow.
Features
Intra, inter, and switch frames
64x64 superblocks
4x4 to 64x64 RDO-selected square and rectangular blocks
DC, H, V, Paeth, smooth, and all directional prediction modes
DCT, (FLIP-)ADST and identity transforms (up to 64x64, 16x16 and 32x32 respectively)
8-, 10- and 12-bit depth color
4:2:0, 4:2:2 and 4:4:4 chroma sampling
11 speed settings (0-10, exhaustive to near real-time)
Constant quantizer and target bitrate (single- and multi-pass) encoding modes
Still picture mode
Documentation
Find the documentation in doc/
Releases
For the foreseeable future, a weekly pre-release of rav1e will be published every Tuesday.
Building
Toolchain: Rust
rav1e currently requires Rust 1.85 or later to build.
Dependency: NASM
Some x86_64-specific optimizations require NASM 2.14.02 or newer and are enabled by default.
strip will be used if available to remove the local symbols from the asm objects.
The CI is testing against nasm 2.15.05, so bugs for other versions might happen. If you find one please open an issue!
Install nasm
ubuntu 20.04 (nasm 2.14.02)
sudo apt install nasm
ubuntu 18.04 (nasm 2.14.02)
sudo apt install nasm-mozilla
# link nasm into $PATH
sudo ln /usr/lib/nasm-mozilla/bin/nasm /usr/local/bin/
fedora 31, 32 (nasm 2.14.02)
sudo dnf install nasm
windows (nasm 2.15.05)
Have a NASM binary in your system PATH.
$NASM_VERSION="2.15.05" # or newer
$LINK="https://www.nasm.us/pub/nasm/releasebuilds/$NASM_VERSION/win64"
curl --ssl-no-revoke -LO "$LINK/nasm-$NASM_VERSION-win64.zip"
7z e -y "nasm-$NASM_VERSION-win64.zip" -o "C:\nasm"
# set path for the current sessions
set PATH="%PATH%;C:\nasm"
macOS (nasm 2.15.05)
brew install nasm
Release binary
To build release binary in target/release/rav1e run:
cargo build --release
Unstable features
Experimental API and Features can be enabled by using the unstable feature.
cargo build --features <feature>,unstable
Current unstable features
Channel API:
cargo build --features channel-api,unstable
Those Features and API are bound to change and evolve, do not rely on them staying the same over releases.
Target-specific builds
The rust compiler can produce a binary that is about 11%-13% faster if it can use avx2, bmi1, bmi2, fma, lzcnt and popcnt in the general code, you may allow it by issuing:
RUSTFLAGS="-C target-cpu=native" cargo build --release
# or
RUSTFLAGS="-C target-cpu=x86-64-v3" cargo build --release
The resulting binary will not work on cpus that do not sport the same set of extensions enabled.
NOTE : You may use rustc --print target-cpus to check if the cpu is supported, if not -C target-cpu=native would be a no-op.
Building the C-API
rav1e provides a C-compatible set of library, header and pkg-config file.
To build and install it you can use cargo-c:
cargo install cargo-c
cargo cinstall --release
Please refer to the cargo-c installation instructions.
Usage
Compressing video
Input videos must be in y4m format. The monochrome color format is not supported.
cargo run --release --bin rav1e -- input.y4m -o output.ivf
(Find a y4m-file for testing at tests/small_input.y4m or at http://ultravideo.cs.tut.fi/#testsequences)
Decompressing video
Encoder output should be compatible with any AV1 decoder compliant with the v1.0.0 specification. You can decode using dav1d, which is now packaged .
dav1d -i output.ivf -o output.y4m
Configuring
rav1e has several optional features that can be enabled by passing --features to cargo. Passing --all-features is discouraged.
Features
Find a full list in feature-table in Cargo.toml
asm - enabled by default. When enabled, assembly is built for the platforms supporting it.
x86_64: Requires nasm.
aarch64
Requires gas
Alternative: Use clang assembler by setting CC=clang
NOTE: SSE2 is always enabled on x86_64, neon is always enabled for aarch64, you may set the environment variable RAV1E_CPU_TARGET to rust to disable all the assembly-optimized routines at the runtime.
Contributing
Please read our guide to contributing to rav1e.
Getting in Touch
Come chat with us on the IRC channel #daala on Libera.Chat! You can also use a web client to join with a web browser.
Read the full README on GitHubWhat Hacker News says
25 sourcesDifficult to know without reproduction steps from the article, but I would think it behaves better than libaom for the same quality setting.
Edit: found https://github.com/xiph/rav1e/issues/2759
In JPEG XL and the Pareto FrontSure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86
Portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains. See also the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...
In Learn x86-64 assembly by writing a GUI from scratch (2020)There is also https://github.com/xiph/rav1e
In Dav1d, fast AV1 decoder, version 1.0There's 3 that I know of,
libaom https://aomedia.googlesource.com/aom, the reference implementation.
https://gitlab.com/AOMediaCodec/SVT-AV1 - from the Alliance for Open Media, which Intel is deeply involved with and is spending a lot of time optimising.
https://github.com/xiph/rav1e - written in rust, also subject to a lot of optimising. It's not complete coverage of all features, intended to be used for places where libaom is too slow.
In H.264 is Magic (2016)Rust? Not really.
https://github.com/xiph/rav1e/search?q=unsafe&unscoped_q=uns...
In Rav1e, an AV1 encoder written in Rust and assembly"The fastest and safest AV1 encoder." quick search on unsafe: https://github.com/xiph/rav1e/search?q=unsafe&unscoped_q=uns...
https://github.com/xiph/rav1e/issues/2378
https://github.com/xiph/rav1e/issues/2310
Does not seems safe at all, definitly not the "safest"encoder out there.
In Rav1e, an AV1 encoder written in Rust and assemblyRav1e, an AV1 encoder written in Rust and assembly
203 points · Open discussionRav1e: The fastest and safest AV1 encoder, written in rust
4 points · Open discussionI have some experience with this, ie ensuring LLVM optimizes and codegens the "best"! I have been working to generate target independent "kernels" for the Rav1e AV1 encoder and have had to do a lot of unidiomatic things to get LLVM to generate machine code similar in quality to hand written ASM. Granted, this is on integers and not floats, but the same principles should apply.
What I've found is that you need to ignore most of Rust: use/load raw pointers, don't use slices, unroll manually, vectorize manually, and check preconditions manually. You'll still get the amazing type system, but the code will have to be more C-like than Rust-like.
* raw pointers: LLVM is pretty good at optimizing C code. Rust specific optimization needs some work. (edit: I assumed arrays here, so you'll need the pointer for offsets; references are still okay. You
Read the rest
'd also use the pointers for iterating instead of the usual slice iteration patterns)
* no slices: index checking is expensive, not to the CPU, the CPU rarely misses the check branches, but to the optimizer. I've found these are mostly left un-elided, even after inlining.
* no slices: slice indexing uses overflow checking. For Rav1e's case, the block/plane sizes mean that doing the index calculation using `u32` will never overflow, so calculating the offsets using u32 is fine (I'll have to switch to using a pseudo u24 integer for GPUs though, because u32 is still expensive on them).
* unroll manually: LLVM would probably do more of this with profiling info, but I've never found it (this is subjective!) to do any unrolling w/o. Maybe if all the other items here are also done...
* vectorize manually: Similar to unrolling. I've observed only limited automatic vectorization.
* And to get safety back: check, check, and check before calling the fast kernel! Ie wrap the kernel function with one that does all the checks elided in the kernel.
Source: Wrote https://github.com/xiph/rav1e/pull/1716, which speeds up the non-asm encodes by over 2x!
Here are six AV1 software encoders I'm aware of:
1. Alliance for Open Media's libaom: https://aomedia.googlesource.com/aom/
2. Intel's SVT-AV1. A highly scalable AV1 encoder. It will use as many cores as you can give it. Netflix is also working on it: https://github.com/OpenVisualCloud/SVT-AV1
3. Mozilla's rav1e encoder. Implemented in Rust. Vimeo is also contributing to it: https://github.com/xiph/rav1e
4. Cisco AV1. Closed source. It's the best live encoder yet shown. Only takes it about one and a half cores on a recent laptop to do a live AV1 video call at 1080p30, both encoding and decoding: https://vimeo.com/344366650
5. EVE-AV1. Closed source from Two Orioles (https://www.twoorioles.com/). It's aiming to be the best quality AV1 encoder available: https://vimeo.com/344663992
6. Visionular Aurora (https://www.visionular.com/). Closed
Read the rest
source. Aims to be better than libaom on both speed and quality: https://vimeo.com/344633364
Pick the one you like and don't feel misled.
> The negative spin would be: how to spend a lot of effort to solve a problem you would never have if you didn't use rust.
I can't totally disagree, I sometimes had this feeling during the implementation.
Contrary to other languages, you can't always choose your trade-offs: memory-safety is in practice almost non-negotiable in Rust (you can use unsafe code locally, but you won't implement the whole application in unsafe), so everything else has to adapt. For example, in another language, I probably would have kept slice+stride to avoid many refactors.
In the end, I am quite happy with the tiling structures API, but a lot of work (and [boilerplate](https://github.com/xiph/rav1e/tree/f1c43dbdc52016f67ecf33383...) was necessary to implement them.
In Implementing tile encoding in rav1e> it's too complex for CPU encoding in real-time
It depends on the encoder though. The AOM encoder is still quite slow, but Intel's SVT-AV1 encoder (https://github.com/OpenVisualCloud/SVT-AV1) is achieving 20 frames a second:
https://www.phoronix.com/scan.php?page=news_item&px=SVT-AV1-...
Xiph's rav1e encoder (https://github.com/xiph/rav1e) can do realtime encoding on a laptop at low resolutions:
https://youtu.be/qubPzBcYCTw?t=2076
You always have to consider encode time versus image quality versus bandwidth. Twitch is using NGCodec's FPGA based VP9 encoders to live stream with the same image quality at a lower bitrate than H.264 can achieve:
https://blog.twitch.tv/how-does-vp9-deliver-value-for-twitch...
In New WebKit Features in Safari 12.1Here’s a Rust AV1 mplementatuon by xiph https://github.com/xiph/rav1e
In Better web video with AV1 codecShowing the 15 most recent of 25 sources. Enable JavaScript to search and browse every indexed mention.