dav1d: VideoLAN's AV1 decoder written in C and assembly

The decoder VideoLAN wrote for speed

Dav1d is an AV1 cross-platform decoder, open source and focused on speed and correctness. The README describes it as battle-tested and production-ready and usable everywhere, which is a claim from the maintainers rather than an independent assessment, but the project's history supports the general shape of it.

The stated goal is to provide a decoder for most platforms and achieve the highest speed possible, in order to overcome what the README calls the temporary lack of an AV1 hardware decoder. That framing dates the project: the hardware decoder was still on the horizon when the work started, and the plan was to be fast enough in software that the hardware gap did not matter.

On feature coverage the decoder supports all features from AV1, including all subsampling and bit-depth parameters. That is the line that matters for adoption, because a decoder that handles only the 8-bit 4:2:0 profile is a different proposition from one that handles the full format, and the second is what this claims to be.

The project is hosted by VideoLAN, the group behind VLC, and was partially funded by the Alliance for Open Media. It is supported by TwoOrioles and VideoLabs, which the README says can provide support and integration help. This repository on GitHub is a read-only mirror; the canonical URL is code.videolan.org/videolan/dav1d.

Why not improve libaom instead

The FAQ in the README contains the project's clearest statement of its own design rationale, and it is worth quoting in substance because it defines what dav1d is competing against.

The maintainers hold that libaom is a very good library, but that it was developed for research purposes during the AV1 design. Their argument is that an implementation written from scratch can achieve faster decoding, in the same way that ffvp9 was faster than libvpx.

The comparison is instructive because it names a concrete precedent: a reference encoder or decoder written for experimentation and then reimplemented for production speed. The practical difference between the two projects is what you inherit when you embed one. A research-oriented reference implementation prioritises conformance and specification coverage over every microarchitecture. A decoder rewritten with a fixed goal, in this case raw decode speed across the instruction sets people actually use, can restructure its inner loops around what the hardware likes.

The cost of that choice is visible in the roadmap: dav1d reaches what it reaches by writing assembly, and the effort needed to cover an architecture that no one has written kernels for is exactly the reason the maintainers answer the question about their own platform with a shrug and an invitation to send a patch.

The assembly strategy behind the throughput

The roadmap is the clearest description of the engineering method, and it is arranged by instruction set and device class rather than by feature.

The completed items include a complete C implementation of the decoder, a usable API, a port to most platforms, and then a series of speed work items: making it fast on desktop by writing assembly for AVX2 chips, fast on mobile with ARMv8 assembly, fast on older desktop with SSSE3 assembly, fast on older mobile with ARMv7 assembly, and then four separate items covering high bit-depth paths on ARMv8, ARMv7, AVX2 and SSSE3. The last reached item is improving threading.

The on-going work is to accelerate less common architectures, naming PPC, SSE2, RISC-V and AVX-512, and to keep improving the C code base. After that comes more GPU decoding where possible.

Read together, the roadmap says that every mainstream device class has dedicated hand-written kernels, including separate treatment of high bit-depth, and that the long tail of architectures is where contributions are wanted. That is the practical shape of a decoder written for speed: the C code is the specification-level reference, and the performance lives in per-architecture assembly files. The README is emphatic that the codebase is in pure C and asm, and that the contribution guidelines are strict because the maintainers want a coherent codebase that simplifies maintenance.

Building the decoder with Meson and Ninja

The build system is Meson with Ninja, and the README gives the general sequence. You need Meson 0.54 or higher and Ninja installed, and on x86 targets nasm 2.14 or higher for the assembler. Then you create a build directory, configure with Meson and compile with Ninja.

The configuration step takes an optional flag for static linking:

meson setup .. --default-library=static

Static linking matters here for a reason beyond distribution convenience: a decoder linked into a larger application benefits from being built with the same options as its host, and the ability to choose is part of why the project insists on a configurable build rather than shipping prebuilt binaries.

Cross-compilation is a first-class part of the documented workflow rather than an afterthought, which makes sense for a library that ends up inside browsers, players and servers on several operating systems. Building 64-bit or 32-bit Windows binaries from a Linux machine uses one of the cross files in the package directory:

meson setup .. --cross-file=../package/crossfiles/x86_64-w64-mingw32.meson

The 32-bit variant uses a different file, i686-w64-mingw32.meson, and 32-bit Linux has its own, i686-linux32.meson. The README notes that mingw-w64 is a prerequisite on the Linux build machine, and that binary names vary between distributions, so the alias command may be needed when a tool cannot be found.

Running the test suites and the argon conformance run

Testing has two parts, and the second is the one that matters for a decoder.

The project's own test data lives in a separate repository, fetched into the tests directory before configuring the build:

git clone https://code.videolan.org/videolan/dav1d-test-data.git tests/dav1d-test-data

You then enable the test data tests at configuration time with the testdata_tests option set to true, compile, and run the suite with meson test -v. The verbose flag is what makes a failing case readable.

The conformance part uses the argon bitstreams from the argon project hosted by VideoLAN. You download the archive, extract it into the dav1d directory, and run the harness script against the built binary:

tests/dav1d_argon.bash -d build/tools/dav1d -a argon

The README states the expected outcome, which is a useful baseline: 2763 files successfully verified, with the output line carrying the dav1d version, the filmgrain setting and the cpumask. The filmgrain and cpumask fields in that line matter, because a decoder built without the grain synthesis path, or restricted to fewer CPU features than the machine has, will not produce the same summary. The conformance run is optional but the README marks it as encouraged, and it is the only check in the documentation that compares output bit for bit against a reference.

Documentation, examples and building the reference manual

The API documentation is generated from the source with doxygen and graphviz, both of which have to be installed before you configure the build with the docs option enabled. The generated pages land in the doc/html directory inside the build tree, and an online version built from the master branch is published on the VideoLAN site.

The examples directory shows how the decoder is meant to be used. There is dav1dplay.c, a small command line player, and then the pieces of a fuller pipeline: dp_fifo.c with its header, a renderer abstraction in dp_renderer.h, and two renderer implementations, one built on placebo for output and one built on SDL. The separation of the FIFO from the renderer is the interesting part, because it is a direct consequence of the threading work in the roadmap: the decoder produces frames into a queue and a separate thread renders them.

For an integrator, that set of files is the fastest way to understand the library's shape, since the API documentation explains the calls while the examples show the order you are expected to make them in.

Licence, patents and why this one is permissive

Dav1d is released under what the README calls a very liberal licence, a contrario from the other VideoLAN projects, so that it can be embedded anywhere including non-open-source software, or even drivers, to allow the creation of hybrid decoders. The project's own metadata records it as BSD-2-Clause, and the COPYING file at the root holds the terms.

The reasoning is given explicitly: the same as for libvorbis. That reference is to a licensing approach rather than a technical one, and the effect is clear in practice. A permissive decoder licence means a commercial product, a proprietary player or a kernel-adjacent driver can incorporate the decoder without the copyleft obligations that would attach to a GPL component, and can build a hybrid decoder that uses the software path where hardware is missing.

The patent position is separate and narrower. The FAQ states plainly that the project is an implementation of a decoder and gives you no special rights on the AV1 patents, pointing at the AV1 patent licence in the doc/PATENTS file that applies to the specification and the codec. The decoder licence lets you embed the code; it does not settle what the codec itself is licensed to.

On contributions there is no CLA. People keep their copyright and their authorship rights while adhering to the BSD 2-clause licence, and VideoLAN holds only the collective work rights. The VideoLAN code of conduct applies.

Where the mirror, the releases and the contributions live

The GitHub repository is explicitly a read-only mirror, and the canonical URL is code.videolan.org/videolan/dav1d. That has a practical consequence for anything you check on GitHub: the release list here shows a single entry, dav1d 0.1.0 Gazelle from 2018, which reflects how the mirror was populated rather than the project's current release history. The last push to the mirror was on 2026-10-18, so it is being kept in step with the canonical repository, but patches and pull requests belong upstream.

The contribution guidelines are described as quite strict, and the reason given is that the maintainers want a coherent codebase to simplify maintenance and achieve the highest possible speed. The project is looking for C developers, assembly developers, platform-specific developers, GPGPU developers and testers, and non-developers can help as testers, bug reporters and documentation writers.

Day-to-day discussion happens on IRC in the dav1d channel on Libera.chat, with a web interface for those without a client. The project was partially funded by the Alliance for Open Media and is supported by TwoOrioles and VideoLabs, which the README says can provide support and integration help if you need it.

The roadmap's open items give you the clearest way to contribute: SSE2, PPC, RISC-V and AVX-512 acceleration, the GPU decoding work in the after phase, and the ongoing C code base improvements listed on the task list.

Editorial conclusion

Adopt dav1d if you are decoding AV1 in software and throughput matters, whether you are a media player, a transcoding pipeline or a server handling user uploads, because the per-architecture assembly is the point of the project. Do not adopt it expecting GPU decoding, which the roadmap places in the after phase, and do not treat it as a licence workaround for AV1 patents, since it grants no special rights. Verify first that your build host has Meson 0.54 or newer, Ninja and nasm 2.14 or newer on x86, that the arithmetic of your target instruction set is covered by an existing kernel, and that the argon conformance run reports 2763 files verified before you ship a build.

Frequently asked questions

Official sources

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