## File: README.md # rav1e [![Actions Status][actions badge]][actions] [![CodeCov][codecov badge]][codecov] The fastest and safest AV1 encoder. **Table of Content** - [Overview](#overview) - [Features](#features) - [Documentation](#documentation) - [Releases](#releases) - [Building](#building) - [Dependency: NASM](#dependency-nasm) - [Release binary](#release-binary) - [Unstable features](#unstable-features) - [Target-specific builds](#target-specific-builds) - [Building the C-API](#building-the-c-api) - [Usage](#usage) - [Compressing video](#compressing-video) - [Decompressing video](#decompressing-video) - [Configuring](#configuring) - [Features](#features-1) - [Contributing](#contributing) - [Getting in Touch](#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/`](doc/README.md) ## Releases For the foreseeable future, a weekly pre-release of rav1e will be [published](https://github.com/xiph/rav1e/releases) every Tuesday. ## Building ### Toolchain: Rust rav1e currently requires Rust 1.74.0 or later to build. ### Dependency: NASM Some `x86_64`-specific optimizations require [NASM](https://nasm.us/) `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`) ```sh sudo apt install nasm ``` **ubuntu 18.04** (`nasm 2.14.02`) ```sh 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`) ```sh sudo dnf install nasm ``` **windows** (`nasm 2.15.05`) Have a [NASM binary](https://www.nasm.us/pub/nasm/releasebuilds/) in your system PATH. ```sh $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`) ```sh brew install nasm ``` ### Release binary To build release binary in `target/release/rav1e` run: ```sh cargo build --release ``` ### Unstable features Experimental API and Features can be enabled by using the `unstable` feature. ```sh cargo build --features ,unstable ``` #### Current unstable features - Channel API: ```sh 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: ```sh 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](https://crates.io/crates/cargo-c): ```sh cargo install cargo-c cargo cinstall --release ``` Please refer to the cargo-c [installation](https://github.com/lu-zero/cargo-c#installation) instructions. ## Usage ### Compressing video Input videos must be in [y4m format](https://wiki.multimedia.cx/index.php/YUV4MPEG2). The monochrome color format is not supported. ```sh cargo run --release --bin rav1e -- input.y4m -o output.ivf ``` _(Find a y4m-file for testing at [`tests/small_input.y4m`](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](https://code.videolan.org/videolan/dav1d), which is now packaged [](https://repology.org/project/dav1d/versions). ```sh 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`](Cargo.toml) * `asm` - enabled by default. When enabled, assembly is built for the platforms supporting it. * `x86_64`: Requires [`nasm`](#dependency-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](CONTRIBUTING.md). ## Getting in Touch Come chat with us on the IRC channel #daala on [Libera.Chat](https://libera.chat/)! You can also use a [web client](https://web.libera.chat/?channel=#daala) to join with a web browser. [actions]: https://github.com/xiph/rav1e/actions [codecov]: https://codecov.io/gh/xiph/rav1e [actions badge]: https://github.com/xiph/rav1e/workflows/rav1e/badge.svg [codecov badge]: https://codecov.io/gh/xiph/rav1e/branch/master/graph/badge.svg --- ## File: doc/AOM_ANALYZER.md # AOMAnalyzer **Table of Contents** - [Local Analyzer](#local-analyzer) - [Online Analyzer](#online-analyzer) ## Local Analyzer 1. Download the [AOM Analyzer](http://aomanalyzer.org) ([source](https://github.com/xiph/aomanalyzer)). 2. Download [inspect.js](https://media.xiph.org/analyzer/inspect.js) ([mirror](https://github.com/xiph/aomanalyzer/files/4685593/inspect.wasm.gz)) and [inspect.wasm](https://media.xiph.org/analyzer/inspect.wasm) ([mirror](https://github.com/xiph/aomanalyzer/files/4685594/inspect.js.gz)) and save them in the same directory. 3. Run the analyzer: ``` AOMAnalyzer path_to_inspect.js output.ivf ``` ## Online Analyzer If your `.ivf` file is hosted somewhere (and CORS is enabled on your web server) you can use: ``` https://arewecompressedyet.com/analyzer/?d=https://media.xiph.org/analyzer/inspect.js&f=path_to_output.ivf ``` --- ## File: doc/CODING_STYLE.md # Coding Style **Table of Content** - [General](#general) - [Assertions](#assertions) ## General The coding style for Rust code follows the [Rust Style Guide](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/guide.md) Exceptions: - Each indentation level is 2 spaces. ## Assertions Assertions should never be reachable by any sequence of API calls. Assertions should never be reachable by any sequence of crav1e API calls which do not depend on C undefined behavior, or contain pointers that cause invalid behavior when accessed. Prefer assert()! to debug_assert()! in the following situations: - Unsafe code. - Code called once per tile or less where debug build testing is unlikely to expose errors (for example, the tests are #[ignored] by default, or it is not covered by unit tests at all) --- ## File: doc/FRAME_TYPE_SELECTION.md # Frame Type Selection **Table of Content** - [Current Features/Process](#current-featuresprocess) - [Detection Algorithm](#detection-algorithm) - [Desired Improvements](#desired-improvements) ## Current Features/Process * The first frame of the video is always a key frame. * rav1e looks ahead up to the maximum number of frames in a sub-GOP to detect "flashes" of content, which are then marked ineligible for a scenecut. * If the user has forced the current frame to be a key frame, it is marked as a key frame. This overrides all other criteria for frame type selection. (TODO: How does a user do this?) * If there have been fewer than the number of frames specified by `--min-keyint` since the last key frame, the current frame is marked as an inter frame. * If there have been equal to the number of frames specified by `--keyint` (i.e. the max keyint) since the last key frame, the current frame is marked as a key frame. * If no other criteria have been met, the current frame is compared with the previous frame to see if it is a scenecut. If it is a scenecut, it is marked as a key frame, otherwise it is marked as an inter frame. ## Detection Algorithm * On speeds 0-9, the algorithm compares frame intra cost vs. inter cost. This is better for compression, but slower. * On speed 10, the algorithm compares the amount of difference between frames. ## Desired Improvements * If the max keyint length is in the middle of a flash of content, the key frame should be placed at either the start or end of the flash, instead of in the middle (exactly on the max keyint). --- ## File: doc/GLOSSARY.md # Glossary **Table of Content** - [Temporal Unit](#temporal-unit) - [Tile Group](#tile-group) - [Frame Header](#frame-header) - [Group](#group) - [Frame](#frame) - [GOP](#gop) - [MI](#mi) - [Pixel domain](#pixel-domain) - [Transform domain](#transform-domain) ## Temporal Unit The same as an AV1 temporal unit. In rav1e, a Temporal Unit always starts with a temporal delimiter, followed by zero or one sequence headers, one or more frame headers and zero or more tile groups. ## Tile Group Same as an AV1 tile group. Zero or more of these, plus a Frame Header, make up a Frame. ## Frame Header Same as an AV1 frame header. These are followed by a tile group, except when the show-existing-frame feature is used, in which case there are zero tile groups. ## Group Otherwise known as a subgop, this is a group of reordered frames. The first frames in the group will be non-shown frames, followed by a sequence of shown frames. A group may either start with a key frame or inter frame. ## Frame In the input, this is one picture of YUV data. In the bitstream, this is a Frame Header followed by zero or more Tile Groups. With reordering, there will be more frames in the output than the input, but some will not be shown. ## GOP Group Of Pictures, A sequence of groups. The first group will start with a keyframe, and the rest of the groups will start with inter frames. ## MI One mode info block, the smallest unit of pixels that has a prediction mode coded for it. Corresponds to a 4x4 block of luma pixels and a 4x4, 2x4, or 2x2 unit of chroma pixels (depending on chroma subsampling). ## Pixel domain Operations on raw pixel values of the image. Distortion measurements in pixel domain are the most accurate as they most closely represent the video output. ## Transform domain Otherwise known as frequency domain, it refers to coefficient values after they have gone through the forward transform and before the inverse transform. Computing distortion in transform domain is faster than pixel domain as the inverse transform can be skipped, but it is less accurate as a result. --- ## File: doc/PROFILING.md # Profiling rav1e **Table of Content** - [Cargo integrations](#cargo-integrations) - [Flamegraph](#flamegraph) - [Instruments](#instruments) - [Generic profiling](#generic-profiling) - [Perf](#perf) - [Instrumented profiling](#instrumented-profiling) - [uftrace](#uftrace) - [tracing](#tracing) - [Codegen Inspection](#codegen-inspection) - [Assembly](#assembly) ## Cargo integrations There are multiple integrations with `cargo` that simplify your life a lot . ### Flamegraph [flamegraph](https://github.com/ferrous-systems/flamegraph) works in any platform that has `dtrace` or `perf` support. ``` $ cargo install flamegraph $ cargo flamegraph -o flame.svg -b rav1e -- ~/sample.y4m -o /dev/null $ $browser flame.svg ``` > **NOTE** Make sure the browser lets you use the built-in interactivity in the > svg. ### Instruments [cargo-instruments](https://github.com/cmyr/cargo-instruments) is macOS-only and integrates neatly with the XCode UI. ``` $ cargo install cargo-instruments $ cargo instruments --release --open --bin rav1e -- ~/sample.y4m -o /dev/null ``` ## Generic profiling ### Perf Most common linux-specific profiler, to use the callgraphs you need dwarf debug symbols. ``` $ cargo build --release $ perf record --call-graph dwarf target/release/rav1e ~/sample.y4m -o /dev/null $ perf report ``` ## Instrumented profiling ### uftrace [uftrace](https://github.com/namhyung/uftrace) is an ELF-specific tracer. It leverages the `mcount` instrumentation. ``` $ cargo rustc --release --bin rav1e -- -Z instrument-mcount $ uftrace record --no-libcall -D 5 target/release/rav1e ~/sample.y4m -o /dev/null $ uftrace report ``` ### tracing We use [profiling](https://crates.io/crates/profiling) to measure specific codepath timings. Building `--features=tracing` enables it using the [tracing](https://crates.io/crates/tracing) backend. ## Codegen Inspection ### Assembly [cargo-show-asm](https://github.com/pacak/cargo-show-asm) can be used to inspect the assembly generated by the Rust compiler. This can be helpful for micro-optimizations including coercing the compiler to auto-vectorize a function. Simple setup: - Install cargo-show-asm: `cargo install cargo-show-asm` - Generate the list of functions: `cargo asm > fn.list` - Search for the function you want to analyze: `grep cdef_dist fn.list` - If the function doesn't appear, it may be inlined by the compiler. You can temporarily add `#[inline(never)]` to the function to bypass this issue. - Generate ASM for your function: `cargo asm rav1e::rdo::cdef_dist_wxh > out.asm` you can enter full function name, pattern or sequential number --- ## File: doc/QUALITY_&_SPEED_FEATURES.md # Quality- & Speed-Features **Table of Content** - [Quality Features](#quality-features) - [Required](#required) - [Unique](#unique) - [Speed Features](#speed-features) ## Quality Features ### Required Quality features that are required for to reach parity with state-of-the-art encoders. | Feature | rav1e | libaom | x264 | x265 | | --------------------------- | :----------------: | :----------------: | :-------------------------: | :----------------: | | Exact RDO | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | | Temporal RDO | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: (mbtree) | :heavy_check_mark: | | Smart distortion | :heavy_check_mark: | :x: (non default) | :heavy_check_mark: (psyrd) | :heavy_check_mark: | | Automatic QM | :x: | :x: | :x: | :heavy_check_mark: | | Rational luma/chroma weight | :heavy_check_mark: | :x: | :heavy_check_mark: | :heavy_check_mark: | | B-pyramid | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | ### Unique Quality features where rav1e can go beyond state-of-the-art encoders. | Feature | rav1e | libaom | x264 | x265 | | --------------------------- | :----------------: | :------: | :---: | :-------------: | | Joint loop filter search | :heavy_check_mark: | :x: | :x: | :x: | | Chunk-compatible first pass | :heavy_check_mark: | :x: (aom-av2) | :x: | :x: (in UHDKit) | ## Speed Features | Feature | rav1e | libaom | x264 | x265 | | ----------------------------- | :----------------: | :----------------: | :----------------: | :----------------: | | Pruning using approximate RDO | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | | Frame-parallel encoding | :x: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | | Model-based RDO cost | :x: | :x: (non default) | :heavy_check_mark: | ? | --- ## File: doc/RDO.md Introduction -------------- The AV1 bitstream format allows a nearly limitless combination of ways to encode any particular video frame. The purpose of rav1e's RDO loop is to search this incredibly large space of probabilities and arrive at a single solution for each frame. The parameter rav1e tries to optimize is "RDO score". This is computed as follows: ```score = distortion + rate*lambda``` Distortion is a metric selected based on user options, such as MSE for PSNR optimized mode or cdef-dist for psychovisual optimized mode. Rate is the number of bits used in the bitstream (commonly in 1/8 bit units throughout the codebase). Lambda is the current operating point (tradeoff between higher quality or lower bitrate), and is directly related to the quantizer setting. The bitstream is composed of a hierarchy of units, and rav1e's RDO loops are structured in the same way. After computing some lookahead information, rav1e's first task is to split the frame into tiles (sometimes just one). These are processed completely independently, and usually in parallel. The next split is into superblocks, which are currently always 64x64 pixels in the luma plane. rav1e processes superblocks serially, one at a time. Although choices made in a superblock affect later superblocks, rav1e will never revisit a superblock once it has determined the best way to code it - it writes it and continues on. The next split is into partitions. Partitions are actually a tree structure, so the search here is recursive - rav1e has to compare treating the current level as a leaf node versus recursing further, all the way down the tree. To keep the number of permutations manageable, rav1e (in all speed levels but 0 and 1) traverses the tree in a top-down approach, and will stop splitting if the RDO score does not improve from the previous split. This can still potentially mean a large number of total combinations, though, so higher speed levels have a limited range of levels to search. A single partition can be coded in either intra or inter mode. The searches for best intra and inter mode are described below. Intra mode ------------ rav1e's intra mode search happens in 3 phases. The goals of these phases are to rapidly prune down a large list of candidates with fast methods, before doing a highly accurate but slow search for the final, best mode. The first step sorts the intra modes based on their predicted coding cost. The second step computes a rough distortion approximation based on the SATD of the residual upon applying the mode. The intra mode is applied at the full partition size, which is a crude approximation - if the transform size is smaller than the partition size, during coding the intra mode will be computed at the transform block size and the edges will be updated after each transform block is coded. The resulting list is sorted by SATD score, and the top half of the list is carried on to the next step. The third step is to fully encode each mode (except for writing the bitstream). The real distortion and bitrate are measured, and the best mode is chosen. Finally, the best mode is re-coded but with bitstream writing enabled, as during the final search the bitstream isn't actually written. Inter mode ------------ rav1e's intra search starts with populating a list of inter modes to search. Modes such as NEWMV are always added, however modes such as NEARMV are only added if the current motion vector list is sufficiently long enough for them to be coded. Compound modes are added in a similar manner, if enabled. Next, a rough distortion approximation based on SATD of the residual is computed. This is also computed at the partition level, however unlike intra mode, this is not an approximation. The resulting list is sorted and pruned to the best 9 entries. Next, each of the modes is fully encoded (with bitstream write disabled). The real distortion and bitrate are measured, and the best mode is chosen. Finally, the best mode is re-coded but with bitstream writing enabled. --- ## File: doc/README.md # rav1e docs **Table of Content** - [../Readme](#readme) - [AOMAnalyzer](#aomanalyzer) - [Coding Style](#coding-style) - [Frame Type Selection](#frame-type-selection) - [Glossary](#glossary) - [Profiling](#profiling) - [Quality- & Speed-Features](#quality---speed-features) - [Rate-control Empirical Analysis](#rate-control-empirical-analysis) - [File Structure](#file-structure) - [Versioning](#versioning) _**NOTE:** Headline may link to page._ ## [../Readme](../README.md) Main README of rav1e. ## [AOMAnalyzer](AOM_ANALYZER.md) Analyze `.ivf`-files with `AOM Analyzer`: * Local Analyzer * Online Analyzer ## [Coding Style](CODING_STYLE.md) ## [Frame Type Selection](FRAME_TYPE_SELECTION.md) - Current Features/Process - Detection Algorithm - Desired Improvements ## [Tile on Frame Boundary](TILE_ON_FRAME_BOUNDARY.md) - Accessing Tiled-pixels outside of a frame - How bounding box is enforced to a PlaneRegion and now it allows accessing the frame outside pixels - When does rav1e access outside frame tiled-input and output pixels? ## [Glossary](GLOSSARY.md) Explanation of various special terms. ## [Profiling](PROFILING.md) List of various profiling tools: - Cargo integrations - Generic profiling - Tracing - Codegen Inspection ## [Quality- & Speed-Features](QUALITY_&_SPEED_FEATURES.md) Overview of quality and speed-features for rav1e and other state-of-the-art encoder. ## [Rate-control Empirical Analysis](regress_log-bitrate_wrt_log-quantizer.ipynb) Notebook documenting how rate-control constants were derived from empirical data. These constants determine the initial values of `RCState::log_scale`, `RCState::exp` and `RCState::scalefilter`. ## [Quantizer Weight Analysis](quantizer-weight-analysis.ipynb) Notebook documenting the quantizer averaging weight analysis and derivation of constants of linear models used to compute the luma quantizer from the target quantizer. ## [File Structure](STRUCTURE.md) - High-level directory structure - Overview of `src/*` ## Versioning rav1e follows Cargo's versioning scheme: https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field Because rav1e is not yet at version 1.0.0, all changes that break the API require a minor-version bump. The API is defined as: - public functions in src/api.rs - command line parameters to the rav1e binary --- ## File: doc/STRUCTURE.md # File Structure of rav1e 0.4.0 **Table of Content** - [High-level directory structure](#high-level-directory-structure) - [Overview of `src/*`](#overview-of-src) ## High-level directory structure Source: [draw.io](structure.drawio) ## Overview of `src/*` The below table gives a brief overview of design of [`src/*`](../src/) | Filename | Functionality | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | [activity.rs](../src/activity.rs) | Implementation of Activity masking functions for planes | | [api/*.rs](../src/api/) | Contains public API of rav1e, for more information check [documentation](https://docs.rs/rav1e/) | | [arm/32/*.S](../src/arm/32/) | ARM optimised functions for different encoding tools imported from dav1d by release | | [arm/64/*.S](../src/arm/64) | AArch64 optimised functions for different encoding tools imported from dav1d by release | | [arm/asm.S](../src/arm/asm.S) | Common functions used for Assembly implementation | | [arm/tables.S](../src/arm/tables.S) | Tables for various ARM optimised functions | | [asm/\*/*.rs](../src/asm/) | High-level functions for binding rust and assembly functions for x86 and AArch64 Architecture | | [bin/common.rs](../src/bin/common.rs) | Functions, enums, structures used command-line tool and debugging | | [bin/rav1e.rs](../src/bin/rav1e.rs) | CLI Interface for encoding from y4m files with rav1e | | [bin/stats.rs](../src/bin/stats.rs) | Functions for displaying Frame summary, progress info, metrics of the encoding process | | [bin/kv.rs](../src/bin/kv.rs) | Serialisation configuration of Key-value strings | | [bin/error.rs](../src/bin/error.rs) | Functions and enums to parse various errors and displaying | | [bin/muxer/*.rs](../src/bin/muxer/) | Contains IVF Muxer functions for header definition, writing frames and flushing | | [bin/decoder/*.rs](../src/bin/decoder/) | Decoder related structures and functions | | [capi.rs](../src/capi.rs) | C Compatible API for using rav1e as a library | | [cdef.rs](../src/cdef.rs) | CDEF Filter implementation for the encoder | | [context/*.rs](../src/context/) | High-level functions that write symbols to the bitstream, and maintain context | | [cpu_features/*.rs](../src/cpu_features) | Functions to toggle CPU optimisations for different architectures | | [deblock.rs](../src/deblock.rs) | Deblocking loop filter implementation for addressing blocking artifacts | | [dist.rs](../src/dist.rs) | SAD and SATD functions and implementation for various encoder functions | | [ec.rs](../src/ec.rs) | Low-level implementation of the entropy coder, which directly writes the bitstream | | [encoder.rs](../src/encoder.rs) | Low-level implementation of the AV1 encoder tools functions and structures | | [entropymode.rs](../src/entropymode.rs) | Low-level implementation of entropy mode | | [ext/x86/x86inc.asm](../src/ext/x86/x86inc.asm) | X86 Assembly header providing an easier way between different calling conventions (x86_32, win64, linux64) | | [frame/*.rs](../src/frame/) | Misc encoder specific frame and plane enums apart | | [fuzzing.rs](../src/fuzzing.rs) | Functions to initialise fuzz targets for encoder process | | [header.rs](../src/header.rs) | The enums and structs of bitstream headers for writing | | [lib.rs](../src/lib.rs) | The top level library, contains code to write headers, manage buffers, and iterate through each superblock | | [lrf.rs](../src/lrf.rs) | Low-level implementation of Loop restoration filter | | [mc.rs](../src/mc.rs) | Low-level implementation of Motion Compensation of the encoding process | | [me.rs](../src/me.rs) | Motion Estimation related structures and functions of the encoding process | | [partition.rs](../src/partition.rs) | Functions and enums to manage partitions (subdivisions of a superblock) | | [predict.rs](../src/predict.rs) | Intra and inter prediction implementations | | [quantize.rs](../src/quantize.rs) | Quantization and dequantization functions for coefficients | | [rate.rs](../src/rate.rs) | Low-level implementation of rate control API (Constant Quantizer) | | [rdo.rs](../src/rdo.rs) | RDO-related structures and distortion computation functions | | [rdo_tables.rs](../src/rdo_tables.rs) | Set of RDO rate values used for RDO related calculation | | [recon_intra.rs](../src/recon_intra.rs) | Functions used for directional intra-prediction modes | | [scan_order.rs](../src/scan_order.rs) | Functions definitions for various block-level scan orders | | [scenechange/*.rs](../src/scenechange) | Low-level implementation of fast screen-cut detection b/w frames for adaptive keyframe selection | | [segmentation.rs](../src/segmentation.rs) | Top-level implementation of segmentation index coding | | [test_encode_decode/*.rs](../src/test_encode_decode/) | Various encoder-decoder tests using dav1d and aom | | [tiling/*.rs](../src/tiling/) | Implementation of tiling during encoding | | [token_cdfs.rs](../src/token_cdfs.rs) | Token cdf header for entropy mode | | [transform/*.rs](../src/transform) | Implementations of DCT and ADST transforms | | [util/*.rs](../src/util/) | Misc utility code | | [x86/*.rs](../src/x86) | X86 optimised functions for various encoder functions along with functions imported from dav1d by release |