title: DSV

description: DSV or DSV1 is a compact, software-only video codec focusing on simplicity and wavelet-based compression, with features rivaling early MPEG standards. The reference implementation of the codec is designed for flexibility

text: Features

anchor: features

text: Limitations

anchor: limitations

text: Example Usage

anchor: example-usage

text: Documentation & More

anchor: documentation-more

markdown:
DSV or DSV1 (Digital Subband Video 1) is a compact, software-only video codec focusing on simplicity and wavelet-based compression, with features rivaling early MPEG standards. The reference implementation of the codec is designed for flexibility and ease of use in C environments. As of October 2024, DSV1 has been superseded by [DSV2](/codecs/video/dsv2/).

## Features

- **Wavelet-based compression:** Uses multiresolution subband analysis (wavelet transform) instead of DCT. More information on wavelet transforms is available on the [DSV2](/codecs/video/dsv2/) page.
- **Motion Compensation:** Supports half-pixel motion compensation.
- **Chroma Subsampling:** 4:1:1, 4:2:0, 4:2:2, and 4:4:4 formats.
- **Adaptive Quantization:** Dynamically adjusts quantization for better quality.
- **Frame Types:** Supports intra and inter frames with variable-length closed GOPs (no bidirectional/B-frames, only forward prediction).
- **Entropy Coding:** Uses interleaved exponential-Golomb coding for simplicity.
- **Compression Range:** Supports a wider range of compression and lower bitrates than MPEG-1/2.

The reference DSV encoder features:

- **Rate Control:** Single-pass average bitrate (ABR) or constant rate factor (CRF).
- **Human Visual System (HVS) Optimization:** Simple intra block mode determination.
- **Scene Change Detection:** Based on average luma changes.
- **Hierarchical Motion Estimation:** For improved efficiency.
- **Adaptive Quantization Stability Tracking:** Improves quality.
- **C89 Compatibility:** Written for standard C89, no external libraries, integer-only arithmetic, single-threaded, and portable.

## Limitations

- No built-in interlacing support.
- Only 8 bits per component supported.
- Frame dimensions must be divisible by 2.

### Example Usage

The only DSV encoder available is the reference encoder.

- Encoding:
  ```
  ./dsv1 e -y -v -inp_bus_cif.yuv -out_saved.dsv -gop12 -w352 -h288 -fps_num30 -qp85 -kbps1100
  ```
- Decoding:
  ```
  ./dsv1 d -inp_video.dsv -out_decompressed.yuv -out420p
  ```

### Documentation & More

Detailed information is available in [the repository](https://github.com/LMP88959/Digital-Subband-Video-1)’s PDF documents (`DSV1_spec.pdf`, `DSV1_encoder.pdf`). More example videos and usage instructions are provided in the README and linked resources in the repo.


collection: docs

title: DSV2

description: DSV2 is a lossy and lossless video codec that utilizes a wavelet transform and block-based motion compensation for video compression. It is designed to perform optimally at medium-low to medium-high bitrates for resoluti

status: current

license: CC BY-SA 4.0

text: Core Features

anchor: core-features

text: Encoder Implementation

anchor: encoder-implementation

text: Limitations

text: Usage

anchor: usage

text: Encoder Usage

anchor: encoder-usage

text: Decoder Usage

anchor: decoder-usage

text: Wavelets

anchor: wavelets

text: The Compression Process

anchor: the-compression-process

text: The Wavelet Transform

anchor: the-wavelet-transform

text: Quantization

anchor: quantization

text: Advantages & Disadvantages

anchor: advantages-disadvantages

text: Advantages

anchor: advantages

text: Disadvantages

anchor: disadvantages

contentFormat: markdown

markdown:
**DSV2** (or Digital Subband Video 2) is a lossy and lossless video codec that utilizes a wavelet transform and block-based motion compensation for video compression. It is designed to perform optimally at medium-low to medium-high bitrates for resolutions ranging from CIF (352x288) up to Full HD (1920x1080). In terms of compression efficiency and quality, its performance is comparable to MPEG-4 Part 2 and [AVC/H.264](/codecs/video/avc/) (using only P-frames). The bitstream for version 2.8 was frozen as of June 20, 2025.

DSV2 supersedes the original [DSV](/codecs/video/dsv/) codec.

## Core Features

DSV2 includes a range of modern codec features, focusing on integer-only operations and avoiding third-party libraries.

- **Compression Method**: Employs a multiresolution subband analysis, also known as a wavelet transform, instead of the more common DCT.
- **Motion Compensation**: Supports up to quarter-pixel motion compensation and features an "Expanded Prediction Range Mode" (EPRM) for improved prediction.
- **Frame Types**: Uses intra (I-frames) and inter (P-frames) with a variable-length closed Group of Pictures (GOP). It does not support bi-directional prediction (B-frames).
- **Color Space**: Compatible with multiple chroma subsampling formats, including 4:1:0, 4:1:1, 4:2:0, 4:2:2, and 4:4:4.
- **Quality Optimization**: Incorporates adaptive quantization, in-loop filtering, and psychovisual enhancements to improve visual quality.
- **Lossless Coding**: Offers a lossless compression mode.

## Encoder Implementation

The specific encoder implementation detailed in the project repository has several advanced features:

- **Rate Control**: Supports single-pass average bitrate (ABR) and constant rate factor (CRF).
- **Scene Detection**: Includes complex algorithms for detecting scene changes.
- **Human Visual System (HVS)**: Utilizes HVS-based models for making decisions on intra block modes and adaptive quantization.
- **Motion Estimation**: Implements hierarchical motion estimation.

## Limitations

The codec has several self-imposed developer limitations as well as technical limitations:

- Does not support interlaced video.
- Component bit depth is limited to 8 bits.
- Frame dimensions must be divisible by two.
- The reference implementation is single-threaded and does not use any hardware acceleration, SIMD instructions, or floating-point math.

## Usage

The DSV2 reference codec is written in C89 and can be compiled with a standard C compiler or by using the Zig build system. It is the only encoder/decoder pair available for DSV2. Build instructions for the reference implementation as well as source code are available on the [DSV2 GitHub repository](https://github.com/LMP88959/Digital-Subband-Video-2).

### Encoder Usage

To encode a video, use the `e` command. The following is a sample command line:

```bash
./dsv2 e -inp=video.y4m -out=compressed.dsv -y4m=1 -qp=60 -gop=48
```

### Decoder Usage

To decode a DSV2 file, use the `d` command. The following is a sample command line:

```bash
./dsv2 d -inp=video.dsv -out=decompressed.y4m -y4m=1 -out420p=1
```

## Wavelets

Wavelet-based video codecs like DSV2 utilize wavelet transforms to reduce the amount of data required to represent a digital video.

Compared to the widely used [Discrete Cosine Transform](/start-here/terminology/#discrete-cosine-transform-dct) (DCT), wavelets feature essentially the opposite methodology. Each coeﬃcient in a DCT represents a constant pattern applied to an entire block, while each coeﬃcient in a wavelet transform represents a localized pattern applied to a section of the block.

Because wavelet transforms can take advantage of large-scale redundancy in an image, they are often used to analyze entire frames at once, or in large overlapping sections. By contrast, DCTs are usually quite small and are intended to cover areas of roughly uniform patterns and complexity (forming the foundation of modern block-based video codecs like [AVC/H.264](/codecs/video/avc/))

### The Compression Process

The core of wavelet compression involves a multi-step process that transforms pixel data into a more compressible format. The CineForm codec serves as a practical example of this process.

#### The Wavelet Transform

A wavelet can be thought of as a one-dimensional filter that separates low-frequency data (the general, smoother areas of an image) from high-frequency data (the details and edges). To compress a 2D image, this process is applied both horizontally and vertically.

For instance, the 2-6 Wavelet used in CineForm calculates low and high-frequency samples. For every two pixels, the low-frequency component is their sum:

`low frequency sample = pixel[x] + pixel[x+1]`

The high-frequency component is calculated using six input pixels to capture finer details:

`high frequency sample = pixel[x] - pixel[x+1] + (-pixel[x-2] - pixel[x-1] + pixel[x+2] + pixel[x+3])/8`

This operation is repeated, typically for three levels, on the low-frequency quadrant of the image, progressively concentrating the image's energy into smaller areas. This encompasses the methodology behind the 2-6 Wavelet.

#### Quantization

After the wavelet transform, the high-frequency data is quantized. The human eye is less sensitive to subtle changes in high-frequency regions, a characteristic exploited by dividing the wavelet output by a quantizer value. This step is a primary source of data reduction, as it discards information that is less likely to be perceived by the viewer.

`high frequency sample = (wavelet output) / quantizer`

Entroping coding, or [lossless compression](/start-here/lossless/), follows this step.

### Advantages & Disadvantages

Wavelet compression presents a different set of trade-offs compared to the block-based DCT approach used in codecs like H.264.

#### Advantages

- Because wavelet transforms are not confined to sharp-edged blocks, they avoid the "blocking" artifacts and ringing that can appear in DCT-based codecs, especially at lower bitrates.
- The efficiency of wavelet codecs like CineForm improves as video resolution increases, making them well-suited for HD, 4K, and 360° video production.
- Wavelets can be designed to decode video at lower resolutions at very high speeds, allowing for faster editing workflows.

#### Disadvantages

Despite their theoretical benefits, wavelet codecs face significant practical challenges that have limited their widespread adoption.

- Wavelet codecs lack an efficient method for intra-frame prediction. Unlike H.264, which can predict a block based on its exact neighboring pixels, the overlapping nature of wavelets makes this impossible, resulting in less efficient compression for intra-frames.
- To avoid blockiness in motion-compensated frames, wavelet codecs often use Overlapped Block Motion Compensation (OBMC), which is significantly more demanding on CPU resources than standard motion compensation.
- At lower bitrates, wavelet codecs can produce a blurry look because they don't preserve visual energy and sharp details as effectively as DCT codecs. This blurriness might result in improved [PSNR](/reference/metrics/psnr/) but can be visually less appealing. Visual aliasing can also occur, where parts of the image appear to be coded at a lower resolution and then poorly scaled up.
- Many wavelet codecs do not feature spatial adaptive quantization, a technique that improves visual quality by varying quantization across different areas of an image. This can lead to blurring in areas with subtle textures.


title: ECM

description: ECM is a video codec developed by the Fraunhofer Heinrich-Hertz-Institute. It is purportedly designed to succeed H.266, or VVC.

status: needs-review

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
ECM (Enhanced Compression Model) is a video codec developed by the Fraunhofer Heinrich-Hertz-Institute. It is purportedly designed to succeed H.266, or [VVC](/codecs/video/vvc/).

The [Git repo](https://vcgit.hhi.fraunhofer.de/ecm/ECM) provides a bit more information:

```md
# ECM reference software

This software package is the reference software for Enhanced Compression Model (ECM). The reference software includes both encoder and decoder functionality.
Reference software is useful in aiding users of a video coding standard to establish and test conformance and interoperability, and to educate users and demonstrate the capabilities of the test model.
The software has been jointly developed by the ITU-T Video Coding Experts Group (VCEG, Question 6 of ITU-T Study Group 16) and the ISO/IEC Moving Picture Experts Group (MPEG, Working Group 11 of Subcommittee 29 of ISO/IEC Joint Technical Committee 1).
```

Other than this generic overview, build instructions are provided in the repo's README. Not much else is known about ECM besides the fact that it will likely become H.267.


title: FFV1

description: FFV1 ) is a lossless intra-frame video codec designed for archival use and preservation. Created by Michael Niedermayer, it is part of the FFmpeg project. The codec supports a wide range of color spaces, works with YUV a

text: History

anchor: history

text: Usage

text: Options

anchor: options

text: Intra-frame only catch

anchor: intra-frame-only-catch

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
FFV1 ([rfc9043](https://datatracker.ietf.org/doc/html/rfc9043)) is a lossless intra-frame video codec designed for archival use and preservation. Created by Michael Niedermayer, it is part of the [FFmpeg](/tools/utilities/ffmpeg/) project. The codec supports a wide range of color spaces, works with YUV and RGB content including alpha channel of color depths ranging from 8 to 16 bits (only up to 14 in case of RGB). It has good parallelization support and achieves very high compression ratios compared to other lossless video encoders such as [UT Video](/codecs/video/utvideo/), albeit at the cost of being more resource-hungry.

## History

In 2003, the codec was merged into FFmpeg; however, the bitstream specification was frozen in 2006 (officially FFV1 version 0). Later, in 2009, version 1 came out, covering more video bit depths. Version 2 never got its release, existing only in experimental form.

The third bitstream version was frozen in 2013 and is still the latest as of 2024. It added multithreading support and frame integrity checking.

There is a fourth version [coming](https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/) which might bring better support for color spaces, compression improvements, and maybe proper inter-frame prediction.

## Usage

```bash title="Fast, heavily multithreaded"
ffmpeg -i input.mkv -c:v ffv1 -slices 16 out.mkv
```

```bash title="Slow, highest compression"
ffmpeg -i input.mkv -c:v ffv1 -g 60 -slices 4 -context 1 -coder 2 out.mkv
```

```bash title="Recommended for archival purposes, high compression, multithreaded"
ffmpeg -i input.mkv -c:v ffv1 -g 1 -slices 16 -slicecrc 1 -context 1 -coder 2 out.mkv
```

### Options
- `slices` - Slices divide the frame into multiple parts that can be encoded and decoded in parallel. Can only be one of: [`4`, `6`, `9`, `12`, `16`, `24`, `30`], where `4` is the default.
- `slicecrc` - Setting it to `1` will enable the decoder to detect errors in the bitstream. Must be enabled for archival use. Can be either `0` or `1`.
- `context` - Setting it to `1` will make the encoder use a larger context size, which usually leads to better compression. Can be either `0` or `1`.
- `coder` - Sets entropy coding method:
  - `0` - Golomb-Rice (faster, default)
  - `1` - Range Coder (used for higher bit depths and better compression)
  - `2` - Range Coder with custom state transition table (almost the same as `1`)
- `g` - Sets GOP size. Must be `1` for archival use. [See below](#intra-frame-only-catch)

## Intra-frame only catch

Intra-frame codecs do not use well known inter-frame video coding techniques such as motion compensation, reusing parts of surrounding frames or adapting encoding context based on them. Every frame is independent from one another. Common intra-frame codecs include Motion JPEG (Lossy), Motion JPEG 2000 (Both), and [UT Video](/codecs/video/utvideo/) (Lossless).

If you're a careful reader, you might have noticed that setting `GOP size` isn't a common characteristic among intra-frame codecs.

In fact, FFV1 can be considered an intra-frame codec only if the `GOP size` is set to `1`. When it's larger than that, its context model depends on other frames found within the GOP, which contradicts the definition of intra-frame video codec. That is why it's highly advised to set `GOP size` to `1` for archiving. This way, if a single frame gets damaged, you'll
only lose that frame. If `GOP size` was large, you might lose much bigger part of the video.

References:
- [Wikipedia](https://en.wikipedia.org/wiki/FFV1)
- [RFC9043](https://datatracker.ietf.org/doc/html/rfc9043)
- [FFmpeg Docs](https://trac.ffmpeg.org/wiki/Encode/FFV1)
- [This Thread](https://forum.shotcut.org/t/exporting-as-ffv1-change-form-to-support-lossless-parameters/41230/19?page=2)
- [This Question](https://video.stackexchange.com/questions/24874/what-does-the-context-parameter-mean-when-using-ffv1-in-ffmpeg)


title: HEVC / H.265

description: H.265, also known as High-Efficiency Video Coding , is a video compression standard designed to deliver higher-quality videos with reduced file sizes. It is a successor to the H.264 codec and was developed to address the

markdown:
# H.265

> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
H.265, also known as High-Efficiency Video Coding (HEVC), is a video compression standard designed to deliver higher-quality videos with reduced file sizes. It is a successor to the [H.264](/codecs/video/avc/) codec and was developed to address the increasing demand for efficient and high-quality video compression, particularly in the context of 4K content. This codec is encumbered by royalties.


title: ProRes

text: Format Breakdown

anchor: format-breakdown

text: Usage

markdown:
ProRes is a family of lossy video compression codecs developed by Apple Inc. ProRes is designed to serve as a high-quality "visually lossless" video editing codec that offers superior image quality compared to many other editing codecs while still maintaining a relatively compact file size compared to uncompressed video.

ProRes uses 4:2:2 or 4:4:4 chroma subsampling depending on the specific subset. This provides greater color fidelity and precision than typical 8-bit 4:2:0 codecs like what can commonly be seen with [AVC](/codecs/video/avc/).

ProRes compression uses the [Discrete Cosine Transform](/start-here/terminology/#discrete-cosine-transform-dct) and intra-frame compression techniques; there is no inter-frame compression applied, meaning redundancy between frames isn't utilized to increase compression efficiency; this keeps decoding light, and simplifies the codec. ProRes is able to achieve very high quality video with relatively low data rates around 100-400 MB/s depending on the resolution and specific ProRes variant.

## Format Breakdown

There are multiple variants of ProRes that offer different combinations of image quality and compression ratios:

Format | Chroma Subsampling | Supported Bit Depth(s)
--- | :---: | ---:
[ProRes RAW](https://www.apple.com/final-cut-pro/docs/Apple_ProRes_RAW.pdf) | N/A | 12-bit
ProRes 4444 XQ | 4:4:4 | 10-bit, 12-bit\*
ProRes 4444 | 4:4:4 | 10-bit, 12-bit\*
ProRes HQ | 4:2:2 | 10-bit
ProRes | 4:2:2 | 10-bit
ProRes LT | 4:2:2 | 10-bit
ProRes Proxy | 4:2:2 | 10-bit

\**ProRes 4444 XQ and 4444 support 12-bit color depth, but the lossless alpha channel is 16-bit if included.*

The higher data rate variants like 4444 XQ and HQ prioritize maximum fidelity at the expense of larger file sizes. The lower data rate variants trade off some quality for much smaller file sizes suitable for editing where storage space is constrained.

## Usage

Apple ProRes Raw is available in LUMIX cameras & the Sony Alpha FX3 via Atomos Ninja V. Both cameras are capable of recording 12-bit uncompressed RAW video in the ProRes RAW format.

ProRes has become widely adopted in professional video post-production workflows due to its quality, performance, metadata handling, and tight integration with Apple's Final Cut Pro editing software & ecosystem.

ProRes is supported by most major non-linear editing systems beyond just Final Cut Pro, including Adobe Premiere Pro & BlackMagic's DaVinci Resolve. This cross-platform compatibility makes it a convenient codec for exchange between different video editing applications.

While designed primarily as an editing codec, Apple has also implemented hardware acceleration for ProRes encode & decode in recent Mac devices via Apple Silicon starting with the M2 chip. This hardware acceleration enables higher performance for tasks like playback, transcoding, and export compared to software-only implementations.


title: Theora

description: Theora is a legacy video codec first released in 2004. It is derived from VP3, part of the same family of codecs that formed VP8, VP9 and AV1.

text: Encoding

anchor: encoding

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
Theora is a legacy video codec first released in 2004. It is derived from VP3, part of the same family of codecs that formed [VP8](/codecs/video/vp8/), [VP9](/codecs/video/vp9/) and [AV1](/codecs/video/av1/).

## Encoding
Theora is frequently contained within a ogg (`.ogg` or `.ogv`) container with [vorbis](/codecs/audio/vorbis/) audio.

To be filled.


title: UT Video

description: UT Video Codec Suite is a fast, lossless video codec, developed by Takeshi Umezawa and released under the free GNU General Public License. The algorithm of UT video is based on the Huffman code.

text: UT Video Codec Suite

anchor: ut-video-codec-suite

markdown:
# UT Video Codec Suite

> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
UT Video Codec Suite is a fast, lossless video codec, developed by Takeshi Umezawa (梅澤 威志, Umezawa Takeshi) and released under the free GNU General Public License. The algorithm of UT video is based on the Huffman code.

UT Video was developed as an alternative to HuffYUV, in order to achieve better compression. It can handle color spaces such as YUV422 (ULY2), RGB (ULRG), RGBA (ULRA) and, most recently, YUV420 (ULY0).

It has both x86 and x64 builds. Due to its multithreading support, this codec is also capable of encoding HDTV material in real time. The codec requires support for the SSE2 instruction set because it is heavily used for speed optimizations.

There are various predction modes, which can be used via [FFmpeg](/tools/utilities/ffmpeg/):
- no prediction employed
- left neighbour prediction (continuous for the whole slice)
- gradient prediction
- median prediction

You can use FFmpeg to encode utvideo as follows:
`ffmpeg -i [input] -c:v utvideo -pred [0,1,2,3] [output]`

*References: [Wikipedia](https://en.wikipedia.org/wiki/Ut_Video_Codec_Suite)*


title: VC-1

description: VC-1 is video codec created by Microsoft and released in 2006. It largely aimed to compete with AVC.

text: Encoding

text: Decoding

anchor: decoding

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
VC-1 is video codec created by Microsoft and released in 2006. It largely aimed to compete with [AVC](/codecs/video/avc/).

## Encoding
VC-1 can be contained in `.mp4`, `.mkv`, and `.avi` containers.
To be filled
## Decoding
VC-1 can be decoded by [FFmpeg](/tools/utilities/ffmpeg/), [VLC](/tools/video-players/), [MPV](/tools/video-players/), and any device that supports blu-ray.


title: VP8

description: VP8 is a video compression format developed by On2 Technologies released in 2008. It was later released as a royalty free codec in 2010 by Google. Its efficiency is competitive with AVC. VP8 was a significant player in t

text: Design Assumptions

anchor: design-assumptions

text: Technical Features

anchor: technical-features

text: Flexible Reference Frames

anchor: flexible-reference-frames

text: Intra Prediction

anchor: intra-prediction

text: Inter Prediction

anchor: inter-prediction

text: In-Loop Deblocking Filtering

anchor: in-loop-deblocking-filtering

text: Entropy Coding

anchor: entropy-coding

text: Overall Decoding Process

anchor: overall-decoding-process

text: VP8 Today

markdown:
VP8 is a video compression format developed by On2 Technologies released in 2008. It was later released as a royalty free codec in 2010 by Google. Its efficiency is competitive with [AVC](/codecs/video/avc/). VP8 was a significant player in the royalty-free codec space and was designed primarily around web video delivery. It is the precursor to [VP9](/codecs/video/vp9/) & [AV1](/codecs/video/av1/), which both further improve video compression efficiency. VP8 has faced criticism for having a messy specification that many considered to be incomplete. It also serves as the basis for the [WebP](/codecs/images/webp/) image format.

## Design Assumptions

VP8's design is built upon several core assumptions tailored for web video.
- It is designed to operate efficiently within a quality range from "watchable video" (around 30dB [PSNR](/reference/metrics/psnr/)) to "visually lossless" (around 45dB PSNR), anticipating limited network bandwidth.
- VP8 was designed to support efficient implementations across a wide breadth of client devices, from low-power mobile/embedded systems to powerful desktops.
- VP8 is optimized to handle common web video image formats; 4:2:0 color sampling, 8-bit per channel color depth, progressive scan (not interlaced), and image dimensions up to 16383x16383 pixels. Internally, lossy VP8 works exclusively in 8-bit YUV 4:2:0 (chroma is 1/4 the resolution of luma).

The overall architecture involves decomposing video frames into 16x16 luma (Y) and 8x8 chroma (U, V) macroblocks. These macroblocks can be further divided into 4x4 subblocks.

## Technical Features

VP8 incorporates features that contribute to its compression efficiency and low computational complexity.

### Frequency Transforms & Adaptive Quantization

VP8 utilizes transform coding to process the residual signal after intra or inter predictions.

The [Discrete Cosine Transform](/start-here/terminology/#discrete-cosine-transform-dct) is applied to all luma and chroma residual signals. The DCT is used due to its high  VP8 defines a 4x4 inverse 2D DCT process as part of its bitstream format and decoding.

For macroblocks using 16x16 luma prediction modes, the DC coefficients from the 16 4x4 luma blocks within the macroblock are used to create another 4x4 block that undergoes a 4x4 Walsh-Hadamard Transform (WHT) to reduce redundancy among the DC coefficients in the 16x16 luma area.

VP8 defines 128 quantization levels within its operating quality range (~30dB to ~45dB). For each video frame, different quantization levels can be applied to six frequency components:
    - 1st order luma DC
    - 1st order luma AC
    - 2nd order luma DC
    - 2nd order luma AC
    - chroma DC
    - chroma AC

Additionally, VP8 includes a region-dependent quantization scheme, allowing macroblocks within a frame to be classified into four different segments, each with its own set of quantization parameters. All calculations in the transform, quantization, dequantization, and inverse transform pipeline can be performed using 16-bit operations.

### Flexible Reference Frames

VP8 uses three types of reference frames for inter-prediction:
- **Last Frame**: The reconstructed frame immediately preceding the frame currently displayed.
- **Golden Frame**: A frame of decompressed data from an arbitrarily distant point in the past. Encoders can use the Golden Frame to improve coding efficiency by maintaining a copy of the background when foreground objects move, allowing occluded regions to be easily reconstructed. Golden frames also help with error resiliency in real-time video scenarios, like video conferencing.
- **Alternate Reference Frame (Altref Frame)**: This frame is decoded, but is not necessarily displayed to the user. Its primary purpose is to serve as a reference to improve inter-prediction for other coded frames. Encoders can construct an Altref frame from multiple source frames or using macroblocks from various video frames, providing flexibility for improved compression. For example, it can be used for noise-reduced prediction by creating a "noise-free" reference frame through temporal or spatial filtering.

The intelligent use of Golden and Altref frames can compensate for the lack of B-frames (as seen in H.264) by allowing encoders to leverage information from "future" frames without requiring frame reordering in the decoder.

### Intra Prediction

VP8 employs two main classes of prediction modes, *intra* and *inter* prediction. Intra prediction Uses data from within the current video frame. It applies to 4x4 luma, 16x16 luma, and 8x8 chroma blocks. Intra prediction modes for 8x8 chroma and 16x16 luma blocks include:
- `H_PRED` (horizontal prediction): Fills columns with copies of the left column.
- `V_PRED` (vertical prediction): Fills rows with copies of the above row.
- `DC_PRED` (DC prediction): Fills the block with a single value, the average of pixels from the above row and left column. For chroma blocks, specific averaging rules apply for edge macroblocks (top row, left column, or top-left corner).
- `TM_PRED` (TrueMotion prediction): Unique to VP8, it uses the pixel above and to the left of the block (C), along with pixels from the above row (A) and left column (L). It propagates horizontal differences from A and vertical differences from L to form the prediction block, using the formula `Xij = Li + Aj - C`. TM_PRED is a frequently used mode, typically for 20% to 45% of all intra-coded blocks.

For 4x4 luma blocks, six additional directional intra modes are available. As is the case in other video codecs, keyframes rely solely on intra prediction modes.

### Inter Prediction

Inter prediction uses data from previously encoded reference frames. A block is constructed using a motion vector to copy a block from one of the three reference frames (last, golden, altref). VP8 employs efficient motion vector coding by reusing vectors from neighboring macroblocks using modes like `NEAREST` and `NEAR`. The `SPLITMV` mode allows flexible coding of arbitrary block patterns within a macroblock by partitioning it into sub-macroblock patterns, each with its own motion vector. This allows a 16x16 macroblock to be partitioned into up to 16 4x4 blocks, each with a (potentially) new motion vector or inheriting from neighbors.

Motion compensation in VP8 uses quarter-pixel accurate motion vectors for luma pixels and up to one-eighth pixel accurate motion vectors for chroma pixels. It features a single-stage interpolation process and a set of high-performance six-tap interpolation filters for luma, and four-tap bicubic filters for chroma. This achieves optimal frequency response with high computational efficiency. Chroma motion vectors are calculated by averaging the motion vectors of the four corresponding luma subblocks. Motion vectors are limited to a range of -4096 to +4095 full pixels.

### In-Loop Deblocking Filtering

VP8 includes a highly adaptive in-loop deblocking filter that reduces blocking artifacts introduced by the quantization of DCT coefficients.
- The filter type (normal or simple) and strength can be adjusted based on different prediction modes and reference frame types.
- It supports implicit segmentation, where different filter strengths can be applied to various parts of the image. For instance, stronger filtering might be applied to intra-coded blocks, while inter-coded blocks using the Golden Frame with a (0,0) motion vector might use a weaker filter.
- The choice of loop filter strengths is adjustable on a frame-by-frame basis. Loop filter strength can be adjusted per segment (within a frame) based on region-adaptive schemes.

A significant innovation is the ability to skip loop filtering entirely for edges between subblocks internal to a macroblock if the macroblock's coding mode is neither `B_PRED` nor `SPLITMV` and it has no DCT coefficients coded. This significantly reduces loop-filtering complexity. Loop filtering is applied to the entire frame after macroblock reconstruction and its results are used in the prediction of subsequent frames.

### Entropy Coding

> **Note — Lossless Compression.**
>
> This section describes the VP8 bitstream's lossless compression step, where all of a lossy bitstream's data values are compressed losslessly. For background on this subject, it is recommended to read the [Lossless Compression](/start-here/lossless/) wiki entry (particularly the section on arithmetic coding).
Except for a few header bits, the majority of compressed VP8 data values are coded using a boolean arithmetic coder. This coder losslessly compresses sequences of boolean values where the probabilities of 0 or 1 can be accurately estimated. This approach provides significant data rate reduction compared to simpler methods like Huffman coding. Most symbol values are binarized into a series of boolean values using a tree scheme, where a binary tree is created for a set of symbols. Each non-leaf node in the tree has a probability assigned based on the likelihood of taking a branch. This consistent encoding/decoding style for various bitstream values (e.g., macroblock modes, motion vectors, quantized coefficients) improves module reusability in hardware and software implementations.

VP8 models entropy coding contexts using conditional probability distributions for macroblock modes, motion vectors, and quantized transform coefficients. These probability distributions remain stable within a frame and are updated on a per-frame basis. This design achieves lower decoder implementation complexity and allows better error recovery compared to H.264's context-based binary arithmetic coding.

VP8's bitstream separates compressed data into two categories:
- Macroblock coding modes & motion vectors
- Quantized transform coefficients

Critically, VP8 allows transform coefficients to be packed into multiple partitions (up to eight), enabling parallel processing in decoders on multi-core processors. For example, in `FOUR_TOKEN_PARTITION` mode, coefficients from macroblock rows 0, 4, 8, etc., are packed into the first partition, rows 1, 5, 9, etc., into the second, and so on. This design significantly improves decoder performance on multi-core systems with minimal impact on compression efficiency or single-core performance.

## Overall Decoding Process

A VP8 decoder maintains four YUV frame buffers: the current frame being reconstructed, the immediately previous frame, the most recent golden frame, and the most recent altref frame. The decoding process generally involves:

1. Decoding the frame header, which provides context for the per-macroblock data.
2. Processing macroblock data in raster-scan order. This includes prediction data (modes/motion vectors) and DCT/WHT coefficients of the residual signal.
3. Each macroblock is predicted using intra-prediction (from the current frame) or inter-prediction (from a reference frame).
4. The residue DCT/WHT signal is decoded, dequantized, reverse-transformed, and added to the prediction buffer to produce the reconstructed macroblock.
5. After all macroblocks are processed, the adaptive in-loop deblocking filter is applied to the entire frame to reduce artifacts.
6. Finally, reference frame buffers are updated (e.g., current frame replacing golden or altref frame) and prepared for the next frame.

## VP8 Today

Experimental results from initial publishing showed that VP8 encoded files were consistently faster to decode (averaging around 30% faster) than H.264 High Profile files at similar bitrates across various hardware platforms. In terms of encoding quality, VP8 achieved competitive results against the best H.264/AVC encoders at the time in its designed operating range for web video.

In practice, reactions to VP8's initial performance were mixed. Moscow State University's initial numbers for the [libvpx](/tools/software-encoders/vpxenc/) encoder (shown below) were lackluster, and the performance claims that accompanied VP8's initial release were not appearing to hold up.

![VP8 RD on Pixar's "Up"](https://raw.githubusercontent.com/av1-community-contributors/images/refs/heads/main/vp8_rd_up.webp)
*VP8 vs [x264](/tools/software-encoders/x264/), Xvid on Pixar's "Up"*

In her "Diary Of An x264 Developer" blog, Fiona Glaser (co-author of [FFmpeg](/tools/utilities/ffmpeg/)'s native highly optimized VP8 decoder) discussed the positive and negative aspects of the VP8 video format. She acknowledged that VP8 doesn't have to be the best in compression to be useful while the current encoder issues are likely related to the encoder implementation's maturity, but she criticized Google for releasing an incomplete and inconsistent “bitstream guide” instead of a proper spec for the codec. The actual encoder/decoder implementation in libvpx differed from the bitstream specification, so the "bitstream guide" nomenclature took hold in what appeared to be a means of avoiding fixing the core issue. Fiona also praised VP8’s `TM_PRED` intra prediction mode and tree-based arithmetic coding, but criticized its slow deblocking filter and suboptimal inverse transform ordering.

Today, [VP9](/codecs/video/vp9/) and to some extent [AV1](/codecs/video/av1/) have largely replaced VP8 as the web's most prominent royalty-free video compression standards. While VP8 may have had a rocky development cycle as well as a lackluster reference encoder, the effects of VP8's introduction are still felt today. WebP is still a widely adopted web image standard, and VP8 set important precedents for web video that helped push the industry forward (e.g. no interlaced video support; Fiona described interlacing as "the scourge of H.264"). Finally, royalty-free video standardization efforts have seen progressively fewer issues with implementation-to-spec parity, helping guide hardware vendors toward successful implementations more effectively.

*Sources:*

- *[Fiona Glaser's blog](https://web.archive.org/web/20150301015756/http://x264dev.multimedia.cx/archives/486)*
- *VP8 Data Format and Decoding Guide – [RFC6386](https://datatracker.ietf.org/doc/rfc6386/)*
- *[Technical overview of VP8, an open source video codec for the web
](https://ieeexplore.ieee.org/abstract/document/6012227)*


title: VP9

description: VP9, famous for being YouTube's codec of choice for many years, is a royalty free video compression format that competes with HEVC and AVC. It is slightly less efficient than HEVC in terms of visual quality, but VP9 is a

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
VP9, famous for being YouTube's codec of choice for many years, is a royalty free video compression format that competes with [HEVC](/codecs/video/hevc/) and [AVC](/codecs/video/avc/). It is slightly less efficient than HEVC in terms of visual quality, but VP9 is a computationally much simpler codec and therefore is very easy on system resources when decoding. If you're interested in VP9 encoding, please see the [vpxenc](/tools/software-encoders/vpxenc/) or [SVT-VP9](/tools/software-encoders/svt-vp9/) sections.


title: VVC / H.266

description: H.266, or VVC , is a codec standardized in 2020 by the Joint Video Experts Team . It succeeds H.265, and claims to be 40% more efficient. In practice, it is currently about as efficient as AV1 when using the VVenC encode

markdown:
# H.266

> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
H.266, or VVC (Versatile Video Coding), is a codec standardized in 2020 by the Joint Video Experts Team (JVET). It succeeds [H.265](/codecs/video/hevc/), and claims to be 40% more efficient. In practice, it is currently about as efficient as [AV1](/codecs/video/av1/) when using the [VVenC](/tools/software-encoders/vvenc/) encoder, although it is inherently a more complex format which means it will be more difficult to decode. It is encumbered by royalties.

[FFmpeg](/tools/utilities/ffmpeg/) 7.0 released in April 2024 comes with native VVC decoder.


title: Encoding guides

description: Goal-oriented, reproducible encoding workflows.

markdown:
Guides turn encoding concepts into complete workflows. Each command-oriented guide declares its
tested versions and assumptions, explains what success looks like, and includes a validation step.

The initial guide set will cover first FFmpeg encodes, AV1 software encoding, quality controls,
color and HDR metadata, audio and subtitles, and objective plus visual comparison.


title: Handle audio and subtitles in the final container

description: Map every intended stream explicitly and validate language, disposition, and compatibility.

text: Validate

anchor: validate

text: Primary references

anchor: primary-references

markdown:
Automatic stream selection may omit a track you expected or choose a different default. Inspect and
map deliberately.

```sh
ffprobe -v error -show_streams -of json input.mkv
```

For a Matroska output that copies video and subtitles while encoding every audio stream to Opus:

```sh
ffmpeg -i input.mkv \
  -map 0:v -map '0:a?' -map '0:s?' \
  -c:v copy -c:a libopus -b:a 128k -c:s copy \
  output.mkv
```

This only works when the target container accepts every selected codec. Streamcopy avoids quality loss
but cannot apply filters and does not make an incompatible stream compatible. Image-based subtitles,
styled text subtitles, attachments, chapters, and fonts need separate checks.

For MP4, text subtitles commonly need conversion to `mov_text`, and some source subtitle types cannot
be converted meaningfully:

```sh
ffmpeg -i input.mkv \
  -map 0:v:0 -map '0:a?' -map '0:s?' \
  -c:v copy -c:a aac -b:a 192k -c:s mov_text \
  output.mp4
```

## Validate

Use `ffprobe` to check stream count, codec, language tags, titles, and dispositions. Then play each
audio and subtitle track, check synchronization at several timestamps, and verify that default/forced
behavior matches the target platform.

## Primary references

- [FFmpeg manual stream selection](https://ffmpeg.org/ffmpeg.html#Manual-stream-selection)
- [FFmpeg stream specifiers](https://ffmpeg.org/ffmpeg.html#Stream-specifiers-1)
- [FFmpeg subtitle options](https://ffmpeg.org/ffmpeg.html#Advanced-Subtitle-options)


title: Encode AV1 with SVT-AV1 and FFmpeg

description: Create a short constant-quality AV1 sample with explicit mapping and verification.

text: Encode a representative sample

anchor: encode-a-representative-sample

text: Validate

text: Primary references

markdown:
Your FFmpeg build must be configured with SVT-AV1. Confirm the wrapper and its locally supported
options first:

```sh
ffmpeg -hide_banner -h encoder=libsvtav1
```

## Encode a representative sample

```sh
ffmpeg -ss 00:05:00 -i input.mkv -t 30 \
  -map 0:v:0 -map '0:a?' \
  -c:v libsvtav1 -preset 6 -crf 30 -pix_fmt yuv420p10le \
  -c:a libopus -b:a 128k \
  sample-av1.mkv
```

This is a test starting point, not a universal recommendation. Higher SVT-AV1 preset numbers trade
compression efficiency for speed; higher CRF values trade quality for smaller output. Ten-bit output
can improve compression behavior but requires compatible playback. Confirm the source and target color
requirements before changing pixel format.

Use `-svtav1-params` only for an option exposed by the installed SVT-AV1 version. It accepts
colon-separated `key=value` pairs. Keep the command and exact encoder version with test results.

## Validate

```sh
ffmpeg -v error -i sample-av1.mkv -f null -
ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,profile,width,height,pix_fmt,color_range,color_space,color_transfer,color_primaries \
  -of json sample-av1.mkv
```

Watch the entire sample on representative software and hardware decoders. Check gradients, motion,
grain, text, dark scenes, seeking, and audio synchronization before running a long encode.

## Primary references

- [FFmpeg libsvtav1 wrapper](https://ffmpeg.org/ffmpeg-codecs.html#libsvtav1)
- [SVT-AV1 4.0.0 parameters](https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/v4.0.0/Docs/Parameters.md)
- [SVT-AV1 FFmpeg guide](https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Ffmpeg.md)


title: Choose a codec and encoder

description: Select a codec, implementation, and container from the constraints of your workflow.

text: Decision order

anchor: decision-order

text: Validation

anchor: validation

text: Primary references

markdown:
Start with the playback, editing, delivery, and licensing constraints. A codec with better compression
is not useful when the target device cannot decode it or the required encoder is unavailable.

## Decision order

1. List every required player, device, editor, and delivery platform.
2. Identify the codecs and profiles all of them accept.
3. Decide whether the job needs lossless, visually lossless, or lossy output.
4. Decide whether size, encode time, decode cost, or broad compatibility has priority.
5. Choose an encoder implementation and test a representative short segment.
6. Choose a container that accepts every video, audio, and subtitle stream you need.

| Typical goal              | Starting point                                     | Check before committing                               |
| ------------------------- | -------------------------------------------------- | ----------------------------------------------------- |
| Broad consumer playback   | AVC/H.264 with AAC in MP4                          | Profile, level, pixel format, and device limits       |
| Efficient modern delivery | AV1, VP9, or HEVC                                  | Hardware decode coverage and platform ingest rules    |
| Editing/intermediate      | ProRes, DNxHR, or lossless formats                 | Editor support, storage, chroma, and bit depth        |
| Archival preservation     | Lossless video and audio in a documented container | Validation, checksums, metadata, and recovery tooling |

List the encoders in your FFmpeg build instead of assuming a package includes one:

```sh
ffmpeg -hide_banner -encoders
ffmpeg -hide_banner -h encoder=libsvtav1
```

## Validation

Encode a short segment containing motion, texture, gradients, dark regions, and audio transitions.
Inspect it on a real target device, then use `ffprobe` to confirm the output streams and metadata:

```sh
ffprobe -v error -show_format -show_streams -of json output.mkv
```

Do not compare CRF or preset numbers across different encoders as if they represented the same quality
or speed. Compare the resulting media under the same source, scaling, pixel-format, and playback
conditions.

## Primary references

- [FFmpeg codec documentation](https://ffmpeg.org/ffmpeg-codecs.html)
- [FFmpeg stream selection](https://ffmpeg.org/ffmpeg.html#Stream-selection)
- [ffprobe documentation](https://ffmpeg.org/ffprobe.html)


title: Compare encoding quality with metrics and visual checks

description: Align reference and distorted media, calculate metrics, inspect outliers, and preserve data.

text: Calculate PSNR or SSIM

anchor: calculate-psnr-or-ssim

text: Interpret the results

anchor: interpret-the-results

text: Primary references

markdown:
Metrics are useful only when the reference and distorted streams represent the same frames in the same
geometry and color domain. First verify frame rate, timestamps, duration, crop, scale, pixel format, and
color conversion.

## Calculate PSNR or SSIM

The first input below is the distorted encode and the second is the reference:

```sh
ffmpeg -i distorted.mkv -i reference.mkv \
  -lavfi '[0:v][1:v]psnr=stats_file=psnr.log' \
  -f null -
```

```sh
ffmpeg -i distorted.mkv -i reference.mkv \
  -lavfi '[0:v][1:v]ssim=stats_file=ssim.log' \
  -f null -
```

An FFmpeg build with `libvmaf` can also calculate VMAF and write structured output:

```sh
ffmpeg -i distorted.mkv -i reference.mkv \
  -lavfi "[0:v][1:v]libvmaf=log_fmt=json:log_path=vmaf.json" \
  -f null -
```

## Interpret the results

- Preserve per-frame logs, not just an average.
- Inspect the lowest-scoring and visually important frames.
- Compare multiple metrics that fail in different ways.
- Perform blind or controlled visual comparisons on representative displays.
- Record the exact command, build versions, source checksum, and any preprocessing.

A higher aggregate score does not automatically mean that viewers will prefer an encode, and a small
score difference may not be meaningful. Use metrics to find tradeoffs and outliers, then confirm them
visually.

## Primary references

- [FFmpeg PSNR filter](https://ffmpeg.org/ffmpeg-filters.html#psnr)
- [FFmpeg SSIM filter](https://ffmpeg.org/ffmpeg-filters.html#ssim)
- [FFmpeg libvmaf filter](https://ffmpeg.org/ffmpeg-filters.html#libvmaf)
- [Encode Wiki metrics reference](/reference/metrics/vmaf/)


title: Make and validate a first FFmpeg video encode

description: Inspect a source, encode one short H.264 sample, and verify the resulting streams.

text: Inspect the input

anchor: inspect-the-input

text: Encode a 30-second sample

text: Validate

text: Primary references

markdown:
This workflow creates a short test in Matroska. It maps the first video stream, optionally maps audio,
encodes video with x264, and encodes audio with Opus. Your FFmpeg build must include `libx264` and
`libopus`.

## Inspect the input

```sh
ffprobe -v error -show_format -show_streams -of json input.mkv
ffmpeg -hide_banner -h encoder=libx264
ffmpeg -hide_banner -h encoder=libopus
```

Confirm the source stream indexes, frame rate, pixel format, resolution, color metadata, audio layout,
and subtitles before encoding.

## Encode a 30-second sample

```sh
ffmpeg -ss 00:05:00 -i input.mkv -t 30 \
  -map 0:v:0 -map '0:a?' \
  -c:v libx264 -preset slow -crf 20 -pix_fmt yuv420p \
  -c:a libopus -b:a 128k \
  sample.mkv
```

`-map` makes stream selection explicit. The `?` makes the audio mapping optional. `-crf` controls the
x264 quality/size tradeoff, while `-preset` controls its speed/compression tradeoff. The `yuv420p`
pixel format is a compatibility choice and may be wrong for high-bit-depth or HDR sources.

## Validate

```sh
ffmpeg -v error -i sample.mkv -f null -
ffprobe -v error -show_format -show_streams -of json sample.mkv
```

The decode check should print no errors. Confirm the expected stream count, codecs, duration,
resolution, pixel format, and color fields. Finally watch the whole sample on a target player and seek
through it.

## Primary references

- [FFmpeg transcoding and streamcopy](https://ffmpeg.org/ffmpeg.html#Transcoding)
- [FFmpeg manual stream selection](https://ffmpeg.org/ffmpeg.html#Manual-stream-selection)
- [ffprobe documentation](https://ffmpeg.org/ffprobe.html)


title: Preserve color and HDR metadata safely

description: Inspect color signaling, avoid unsupported conversions, and verify the encoded result.

text: Inspect first

anchor: inspect-first

text: Validate

text: Primary references

markdown:
Color errors can survive a successful encode. Do not infer transfer, primaries, matrix, range, chroma
location, mastering display, or content-light metadata from resolution or filename.

## Inspect first

```sh
ffprobe -v error -select_streams v:0 \
  -show_entries stream=pix_fmt,color_range,color_space,color_transfer,color_primaries,chroma_location,side_data_list \
  -of json input.mkv
```

If essential fields are absent or contradict the mastering information, stop and resolve the source
facts. Assigning metadata does not convert pixels. Converting transfer functions, primaries, range, or
chroma requires an intentional color pipeline and a filter that supports the source and target.

## Encode without silently discarding the question

- Keep a record of the probed source fields.
- Choose an encoder, profile, bit depth, and pixel format capable of the target signal.
- Pass explicit color options only when they describe the actual encoded pixels.
- Handle HDR10 mastering/content-light metadata and dynamic HDR metadata as separate requirements.
- Avoid a casual `-pix_fmt yuv420p` on high-bit-depth or HDR input.

For known BT.709 limited-range SDR pixels, explicit video signaling may look like:

```sh
-color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv
```

Those flags are not a generic fix and must not be pasted onto unknown or HDR material.

## Validate

Probe the output with the same command, compare it to the intended target, decode the full output for
errors, and inspect it through a color-managed playback path. A metadata match alone does not prove the
pixel conversion is correct.

## Primary references

- [FFmpeg scaler and color options](https://ffmpeg.org/ffmpeg-scaler.html)
- [ffprobe stream and side-data output](https://ffmpeg.org/ffprobe.html#Main-options)
- [Encode Wiki colorimetry reference](/reference/colorimetry/intro/)


title: Choose quality controls, bitrate, presets, and passes

description: Decide whether a workflow should target quality, file size, bitrate, or delivery bounds.

text: CRF and presets

anchor: crf-and-presets

text: One pass or multiple passes

anchor: one-pass-or-multiple-passes

text: Reproducible comparison

anchor: reproducible-comparison

text: Primary references

markdown:
Rate control answers a product constraint. Choose it only after deciding which outcome must remain
stable.

| Requirement                                     | Appropriate starting mode        | Main tradeoff                           |
| ----------------------------------------------- | -------------------------------- | --------------------------------------- |
| Similar perceptual quality across varied scenes | CRF/constant-quality             | Output size is unknown                  |
| Delivery or storage target over a whole program | VBR, often multi-pass            | Quality varies to meet the target       |
| Tight instantaneous transmission bound          | Constrained quality, VBV, or CBR | May sacrifice quality in complex scenes |
| Diagnostic experiment                           | Constant quantizer               | Usually not a delivery recommendation   |

## CRF and presets

CRF values are encoder-specific. A value of 30 in SVT-AV1 does not mean the same thing as 30 in x264.
Likewise, preset scales differ. Within one encoder, test several values on the same source segment and
record output size, encode time, objective metrics, and visual findings.

## One pass or multiple passes

For a quality-targeted encode, start with one pass unless the encoder's current documentation gives a
specific reason to use more. For a required average bitrate or file size, multi-pass VBR can allocate
bits using information gathered across the full program. SVT-AV1 documents multi-pass as most useful
for VBR targets and less critical for ordinary CRF work.

## Reproducible comparison

Keep all of these fixed while testing one control:

- exact source segment and stream mapping;
- scaling, cropping, filters, frame rate, pixel format, and color pipeline;
- encoder build/version and thread constraints;
- audio and subtitle handling; and
- metric implementation plus viewing conditions.

Never keep a setting merely because it won a single aggregate score. Inspect outliers and visually
important scenes.

## Primary references

- [FFmpeg codec options](https://ffmpeg.org/ffmpeg-codecs.html)
- [SVT-AV1 bitrate-control modes](https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md#bitrate-control-modes)
- [SVT-AV1 multi-pass guidance](https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md#multi-pass-encoding)


title: Encode Wiki

description: Practical, community-maintained knowledge about codecs and encoding tools.

text: Explore Encode Wiki

anchor: explore-encode-wiki

markdown:
## Explore Encode Wiki

<CardGrid>
  <Card title="Start here" icon="open-book">
    Learn the vocabulary and tradeoffs behind media encoding.
  </Card>
  <Card title="Guides" icon="rocket">
    Follow practical, testable workflows for real encoding tasks.
  </Card>
  <Card title="Codecs and tools" icon="setting">
    Compare formats, encoders, filters, players, and utilities.
  </Card>
  <Card title="Articles" icon="document">
    Read experiments, benchmarks, explanations, and project news.
  </Card>
</CardGrid>

Encode Wiki is a new community project seeded from the AV1 Community Contributors' Codec Wiki.
Imported material preserves its source and attribution. New and migrated pages will be expanded and
reviewed as the project develops.


title: Reference

description: Encoding terminology, metrics, colorimetry, commands, and further resources.

markdown:
Use the reference section for terminology, colorimetry, quality metrics, command details, FAQs, and
links to primary external sources.


title: Color Formats

description: To represent color values, a format is agreed upon. Color formats are made up of three things, the color model--which includes the order of the components and sometimes chroma subsampling-- the bit depth, and whether it

text: Color Models

anchor: color-models

text: RGB

anchor: rgb

text: YUV

anchor: yuv

text: Component order

anchor: component-order

text: Bit depth

anchor: bit-depth

text: Packed vs planar

anchor: packed-vs-planar

text: Endianness

anchor: endianness

text: Chroma subsampling

anchor: chroma-subsampling

text: Common formats

anchor: common-formats

text: References

anchor: references

markdown:
To represent color values, a format is agreed upon. Color formats are
made up of three things, the [color model](#color-models)--which includes the
[order of the components](#component-order) and sometimes [chroma subsampling](#chroma-subsampling)--
the [bit depth](#bit-depth), and whether it is a [packed or a planar format](#packed-vs-planar).
In some cases, [endianness](#endianness) may be important.

## Color Models

A color model is a method of representing colors in a video or image using data.
Different color models store color and brightness information in different ways.
There are many different color models, but this section will cover the
models most commonly used for images and video.

### RGB

RGB is probably the most well-known color model, and is primarily used
in image encoding. RGB consists of three color channels, Red, Green,
and Blue, which are then combined to determine the final color of each
pixel. Typically, RGB is the final model that a monitor or TV
will use to display images, because the pixels on a screen are made up
of red, green, and blue LEDs, although it is not commonly used for video
encoding because other models can provide better compression.

### YUV

YUV, also known as YCbCr, is the most widely used color model for
video encoding. It consists of three components: Y aka Luma, which
represents luminance or brightness, and two chroma planes, which
represent color. Generally a video player will have to convert a YUV
video into RGB before it can be rendered, but there are significant
compression benefits to using YUV over RGB for video.

The most notable reason to use YCbCr is an optimization called chroma
subsampling. This means that the chroma components can be encoded at a
lower resolution than the luma components, which results in a smaller
output file. You can read more about chroma subsampling [further below](#chroma-subsampling).

### Component order

The order in which the components in a color model are arranged is simply
represented by writing them out. For example, `RGB` for red first,
then green, then blue, or `BGR` for blue, green, red.

## Bit depth

A bit depth is how many bits are available to store the sample
value. There are two main ways to specify the bit depth in a :

- bits per component. Here, `RGB888` reads as `RGB color model, with 8
bits for the red component, 8 bits for the green component, and 8
bits for the blue component` and `RGB565` reads as `RGB color model,
with 5 bits for the red component, 6 bits for the green component,
and 5 bits for the blue component`.
- bits per sample. Here, `RGB24` reads as `RGB color model, with 24
bits in total for the red, green, and blue components`. This is
  ambiguous, because one does not know exactly how many bits are
  allocated to each component. `RGB565`, `RGB556`, and `RGB655` (even
  though the latter ones do not make much sense as the eye is most
  sensitive to green light) all become `RGB16`.

## Packed vs planar

Components can be stored either packed, where all
components are interleaved (here, `RGB`):

```
Sample number:   1   2   3   4   5
Data:          RGB RGB RGB RGB RGB
```

or stored separately for each component:

```
Sample number: 1 2 3 4 5
Data:          R R R R R...
Data:          G G G G G...
Data:          B B B B B...
```

In planar formats, many operations can be easier to implement, as it
is possible to implement the algorithm once and then operate on all
planes. On the other hand, packed formats are simpler and often used
in hardware.[^vlc-wiki-yuv]

## Endianness

Different computer architectures store numbers differently. For more
information, visit [the Wikipedia article on
endianness](//wikipedia.org/wiki/Endianness). There are two main ways
to store numbers with more than 8 bits (1 is the least significant
byte and 4 is the most significant byte, here 4 bytes):

- Most significant byte first, little endian, `4321`. This is what
  x86-family processors use.
- Least significant byte first, big endian, `1234`. This is what
  PowerPC-family processors use.

This can be important for color formats, as some computers might store
it in their native endianness. VapourSynth doesn't seem to care about
endianness, but FFmpeg does.

For example, `RGB565` might store its two bytes in `12` or `21` order,
and if they are read in the wrong order, it will produce garbage.

## Chroma subsampling

In [Y'CbCr](#yuv) signals, there are three widely used
variants of chroma subsampling:

- 4:2:0 which has half the vertical and horizontal chroma resolution
- 4:2:2 which has half the horizontal chroma resolution but full
  vertical resolution
- 4:4:4 which has full chroma resolution (no subsampling)

4:2:2 is not particularly useful over the other options, so this guide
will focus on 4:2:0 and 4:4:4.

4:2:0 is the most commonly used format for videos. Nearly every DVD,
blu-ray, camera recording, etc. uses 4:2:0 subsampling. This is because,
in the majority of cases, human eyes do not notice the reduction in
chroma resolution. There is very little benefit to using 4:4:4 in the
average case.

However, there are some exceptions. The most notable is screen
recordings. Things like text overlays, video game UI overlays,
etc. have very fine, color-dependent detail that can be destroyed by
chroma subsampling and result in an aliased look to the
video. Therefore, it is recommended to use 4:4:4 subsampling when
recording your screen, and 4:2:0 subsampling in most other cases.

## Common formats

| VS name     | FFmpeg name                                                                 | Meaning                                                                                |
| ----------- | --------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| `GRAY8`     | `gray8`                                                                     | Brightness only, 8 bits, packed                                                                       |
| `GRAY16`    | `gray16le`, `gray16be` (the suffix specifies the [endianness](#endianness)) | Brightness only, 16 bits                                                                              |
| `RGB888`    | `rgb24`                                                                     | red, green, blue, 8 bits per component                                                                |
| `YUV420P8`  | `yuv420p`                                                                   | luma, chroma blue, chroma red, 8 bits per component, planar, 4:2:0 [subsampling](#chroma-subsampling) |
| `YUV422P8`  | `yuv422p`                                                                   | luma, chroma blue, chroma red, 8 bits per component, planar, 4:2:2 subsampling                        |
| `YUV444P8`  | `yuv444p`                                                                   | luma, chroma blue, chroma red, 8 bits per component, planar, no subsampling                           |
| `YUV420P10` | `yuv420p10le`, `yuv420p10le`                                                | luma, chroma blue, chroma red, 10 bits per component, planar, 4:2:0 subsampling                       |
| `YUV422P10` | `yuv422p10le`, `yuv422p10le`                                                | luma, chroma blue, chroma red, 10 bits per component, planar, 4:2:2 subsampling                       |
| `YUV444P10` | `yuv444p10le`, `yuv444p10le`                                                | luma, chroma blue, chroma red, 10 bits per component, planar, no subsampling                          |

## References

[^vlc-wiki-yuv]: [YUV - VideoLAN Wiki](https://wiki.videolan.org/YUV/#Packed_formats)


title: Intro

markdown:
There are many aspects which determine how the color information
for a video is stored and how it is rendered. As technology has improved,
new standards developed, and with new techologies such as HDR,
new standards continue to develop. However, the result is that
it can be confusing to know which color settings to use for
a given video.

Some properties such as the color format must be set.
However, properties such as color range, primaries, matrix coefficients,
and transfer function are optional. It is always best practice to set these
when you are encoding a video, because if they are not set, the player
must make a guess as to what the correct settings are. If it guesses
incorrectly, this can lead to the colors of the video being different
from what was intended.


title: Matrix Coefficients

text: 0: Identity

text: 1: BT.709

text: 2: Unspecified

text: 4: BT.470M

text: 5: BT.470BG

text: 6: SMPTE 170M

text: 7: SMPTE 240M

text: 8: YCgCo

text: 9: BT.2020 Non-Constant Luminance

text: 10: BT.2020 Constant Luminance

text: 11: SMPTE 2085

text: 14: ICtCp

markdown:
Matrix coefficients represent the multiplication matrix that is used when
converting from YUV to RGB. As with primaries, the integer values are defined
within universal specifications, and as such they will be the same across all
encoding and playback tools.

The following values are available:

### 0: Identity

Specifies that the identity matrix should be used, i.e. this data is already in an RGB-compatible colorspace.

This matrix coefficient setting is used in the following standards:

- GBR (often referred to as RGB)
- YZX (often referred to as XYZ)
- IEC 61966-2-1 sRGB
- SMPTE ST 428-1 (2019)

### 1: BT.709

BT.709 is the standard used for modern high-definition video, and is a safe default assumption.

This matrix coefficient setting is used in the following standards:

- Rec. ITU-R BT.709-6
- Rec. ITU-R BT.1361-0 conventional colour gamut system and extended colour
  gamut system (historical)
- IEC 61966-2-4 xvYCC709
- SMPTE RP 177 (1993) Annex B

### 2: Unspecified

This value indicates that no color matrix is set for the video, and the player must decide which value to use.

mpv will use the following heuristics in this case:

```
if width >= 1280 || height > 576 {
    "BT.709"
} else {
    "SMPTE 170M"
}
```

### 4: BT.470M

BT.470M is a standard that was used in analog television systems in the United States.

### 5: BT.470BG

BT.470BG is a standard that was used for European (PAL) television systems and DVDs.

This matrix coefficient setting is used in the following standards:

- Rec. ITU-R BT.470-6 System B, G (historical)
- Rec. ITU-R BT.601-7 625
- Rec. ITU-R BT.1358-0 625 (historical)
- Rec. ITU-R BT.1700-0 625 PAL and 625 SECAM
- IEC 61966-2-1 sYCC
- IEC 61966-2-4 xvYCC601

### 6: SMPTE 170M

SMPTE 170M is a stanrard that was used for NTSC television systems and DVDs. Its matrix coefficients are equivalent to BT.470BG.

This matrix coefficient setting is used in the following standards:

- Rec. ITU-R BT.601-7 525
- Rec. ITU-R BT.1358-1 525 or 625 (historical)
- Rec. ITU-R BT.1700-0 NTSC
- SMPTE ST 170 (2004)

### 7: SMPTE 240M

SMPTE 240M was an interim standard used during the early days of HDTV (1988-1998).

### 8: YCgCo

The YCoCg color model, also known as the YCgCo color model,
is the color space formed from a simple transformation of
an associated RGB color space into a luma value and
two chroma values called chrominance green and chrominance orange.

### 9: BT.2020 Non-Constant Luminance

BT.2020 is a standard used for ultra-high-definition video, i.e. 4K and higher. It may be used with or without HDR, as HDR is defined by the transfer characteristics. If you do not know if you want non-constant or constant luminance, you probably want non-constant.

If you have a video with an unset matrix coefficient, it is safer to assume BT.709 by default. Videos which are BT.2020 should already have their color metadata set.

This matrix coefficient setting is used in the following standards:

- Rec. ITU-R BT.2020-2 (non-constant luminance)
- Rec. ITU-R BT.2100-2 Y′CbCr

### 10: BT.2020 Constant Luminance

This is a variant of BT.2020 with constant luminance values, represented using the YcCbcCrc colorspace. You probably want the non-constant luminance variant instead, unless you know you want this one.

### 11: SMPTE 2085

SMPTE 2085 is a standard used with HDR signals in the XYZ colorspace. I've never actually seen it used in the wild.

### 12: Chromaticity-Derived Non-Constant Luminance

I'm not really sure when you would use this.

### 13: Chromaticity-Derived Constant Luminance

I'm not really sure when you would use this.

### 14: ICtCp

ICtCp is an alternative colorspace developed for use with HDR and wide gamut video, by Dolby because they love doing extra stuff like this. I've never actually seen it used in the wild.


title: Color Primaries

text: 1: BT.709

text: 2: Unspecified

text: 4: BT.470M

text: 5: BT.470BG

text: 6: SMPTE 170M

text: 7: SMPTE 240M

text: 8: Film

text: 9: BT.2020

text: 10: SMPTE 428

text: 11: DCI-P3

text: 12: Display P3

text: 22: EBU Tech 3213

markdown:
This section details the first of three settings that are important
for retaining accurate color when encoding videos, those settings
being primaries, color matrix, and transfer characteristics.

Color primaries are used to indicate the correct coordinates for the
red, blue, and green colors. There are historical reasons for
[why so many standards exist](https://xkcd.com/927/), and this guide
will not go in depth into history lessons, but will explain what
primaries are available and when to use each one.

Note that for primaries, matrices, and transfer, you can view the values
that are set on a video using a tool like [MediaInfo](https://mediaarea.net/en/MediaInfo).
If there are no values set, the player will need to guess which values
to use. A safe default assumption for most modern videos is BT.709,
although this may vary depending on source and resolution for the video.
It is strongly recommended to set the correct values when encoding.

Each setting has at least one name and exactly one integer value
representing it--most encoder softwares will accept one or more of the names,
but some tooling such as Vapoursynth and MKVToolnix accepts the integer values
instead. The integer values are defined within universal specifications,
and as such they will be the same across all encoding and playback tools.

### 1: BT.709

BT.709 is the standard used for modern high-definition video, and is a safe default assumption.

This color primary setting is used in the following standards:

- Rec. ITU-R BT.709-6
- Rec. ITU-R BT.1361-0 conventional colour gamut
  system and extended colour gamut system (historical)
- IEC 61966-2-1 sRGB or sYCC
- IEC 61966-2-4
- Society of Motion Picture and Television Engineers
  (SMPTE) RP 177 (1993) Annex B

### 2: Unspecified

This value indicates that no color primary is set for the video, and the player must decide which value to use.

mpv will use the following heuristics in this case:

```
if matrix == "BT.2020" {
    "BT.2020"
} else if matrix == "BT.709" {
    "BT.709"
} else if width >= 1280 || height > 576 {
    "BT.709"
} else if height == 576 {
    "BT.470BG"
} else if height == 480 || height == 488 {
    "SMPTE 170M"
} else {
    "BT.709"
}
```

### 4: BT.470M

BT.470M is a standard that was used in analog television systems in the United States.

This color primary setting is used in the following standards:

- Rec. ITU-R BT.470-6 System M (historical)
- United States National Television System Committee
  1953 Recommendation for transmission standards for
  color television
- United States Federal Communications Commission
  (2003) Title 47 Code of Federal Regulations 73.682 (a) (20)

### 5: BT.470BG

BT.470BG is a standard that was used for European (PAL) television systems and DVDs.

This color primary setting is used in the following standards:

- Rec. ITU-R BT.470-6 System B, G (historical)
- Rec. ITU-R BT.601-7 625
- Rec. ITU-R BT.1358-0 625 (historical)
- Rec. ITU-R BT.1700-0 625 PAL and 625 SECAM

### 6: SMPTE 170M

SMPTE 170M is a standard that was used for NTSC television systems and DVDs.

- Rec. ITU-R BT.601-7 525
- Rec. ITU-R BT.1358-1 525 or 625 (historical)
- Rec. ITU-R BT.1700-0 NTSC
- SMPTE ST 170 (2004)

### 7: SMPTE 240M

SMPTE 240M was an interim standard used during the early days of HDTV (1988-1998). Its primaries are equivalent to SMPTE 170M.

### 8: Film

This represents generic film using Illuminant C.

### 9: BT.2020

BT.2020 is a standard used for ultra-high-definition video, i.e. 4K and higher. It may be used with or without HDR, as HDR is defined by the transfer characteristics.

If you have a video with unset color primaries, it is safer to assume BT.709 by default. Videos which are BT.2020 should already have their color metadata set.

This color primary setting is used in the following standards:

- Rec. ITU-R BT.2020-2
- Rec. ITU-R BT.2100-2

### 10: SMPTE 428

SMPTE 428 is used for D-Cinema Distribution Masters, aka DCDM.

This color primary setting is used in the following standards:

- SMPTE ST 428-1 (2019)
- (CIE 1931 XYZ as in ISO 11664-1)

### 11: DCI-P3

DCI-P3 is a color space created by [Digital Cinema Initiatives](https://www.dcimovies.com). DCI-P3 has similar chromaticities (end points) and color gamut to AdobeRGB, which is more widely used in graphic arts and photography. DCI-P3 features a substantially larger gamut than sRGB.

### 12: Display P3

Display P3 is a standard developed by Apple that is used across iPhones, iPads, iMacs, MacBooks, and Apple-branded external displays released since 2016.

Display P3 differs from DCI-P3 in a couple of ways:
- Unlike DCI-P3, Display P3's white point is the same as the sRGB/AdobeRGB white point of 6500K
- DCI-P3 has a gamma of 2.6, while Display P3 uses sRGB's gamma, which is closer to 2.2

### 22: EBU Tech 3213

The EBU Tech 3213 standard defines the colorspace used by PAL/SECAM television systems in 1975, defining the chromaticities of primary colors and the white reference. It has largely been superseded by newer standards like SMPTE 170M and is considered obsolete for modern applications. The transfer function was never properly defined for this colorspace.


title: Color Range

markdown:
Range is a concept that describes the valid values for a pixel.
Typically, RGB will use full range and YUV will use limited range.

What does this mean?

For 8-bit video, full range indicates that all values between 0-255
may be used to represent a color value. On the other hand, limited range
indicates that only values between 16-235, or 16-240 for chroma,
are valid, and any values outside that range will be clamped to fit in
that range. These expand to equivalent ranges for high bit depth videos.

Why is limited range a thing that exists? Essentially, it's due to
historical reasons, but it's a convention that we are stuck with today.
Even though full range may provide slightly better color accuracy,
it is far less meaningful for high bit depth content, and even
HDR blu-rays use limited color range. Therefore, it is recommended to
follow existing conventions.


title: Transfer Characteristics

text: 1: BT.1886

text: 2: Unspecified

text: 4: BT.470M

text: 5: BT.470BG

text: 6: SMPTE 170M

text: 7: SMPTE 240M

text: 8: Linear

text: 9: Logarithmic 100

text: 10: Logarithmic 316

text: 11: XVYCC

text: 12: BT.1361E

text: 13: sRGB

text: 14: BT.2020 10-bit

text: 15: BT.2020 12-bit

text: 16: PQ aka SMPTE 2084

text: 17: SMPTE 428

text: 18: HLG aka Hybrid Log-Gamma

markdown:
Transfer characteristics, also known as transfer functions, define the
shaping used to compress the luminance or "brightness" of a video, we use
the Transfer Characteristics to determine how to convert from a compressed
video to a video that is in linear light, as well as converitng a linear
light video to a compressed video. These functions are known as EOTF, OETF, or OOTF.

Note that in some transfer functions like sRGB, you need to undo the OETF. The
specification defines how to encode sRGB, and how a display should decode it,
but not how to convert it back to linear light. In cases like these, it is typical
to simply undo the encoding with an inverse transfer function, instead of using the
function the display is to use.

This luminance can often be refered to as gamma, however due to the term gamma also
being used to refer to a myriad of other things, it is better to avoid this term when
possible.

Integer values much like with primaries are often used to define universal consants in
the transfer functions. Transfer functions can either be absolute functions which
specify the peak and minumum luminance, or be relative functions which specify
how to display a pixel within a range between maximum and minimum intensity.
These transfer functions typically have a nominal reference brightness, but this
can be more of a suggestion rather then a hard requirement in some cases. Commonly
seen with sRGB.

The following values are available:

### 1: BT.1886

BT.1886 is the standard used for most modern, SDR video, and is a safe default assumption.

This transfer function is used in the following standards:

- Rec. ITU-R BT.709-6
- Rec. ITU-R BT.1361-0 conventional
  colour gamut system (historical)

### 2: Unspecified

This value indicates that no transfer function is set for the video, and the player must decide which value to use.

mpv will always assume BT.1886 in this case.

### 4: BT.470M

BT.470M is a standard that was used in analog television systems in the United States. This transfer represents a power function with a gamma of 2.2.

This transfer function is used in the following standards:

- Rec. ITU-R BT.470-6 System M
  (historical)
- United States National Television
  System Committee 1953
  Recommendation for transmission
  standards for color television
- United States Federal Communications
  Commission (2003) Title 47 Code of
  Federal Regulations 73.682 (a) (20)
- Rec. ITU-R BT.1700-0 625 PAL and
  625 SECAM

### 5: BT.470BG

BT.470BG is a standard that was used for European (PAL) television systems and DVDs. This transfer represents a power function with a gamma of 2.8.

### 6: SMPTE 170M

SMPTE 170M is a stanrard that was used for NTSC television systems and DVDs. Its transfer function is equivalent to BT.1886.

This transfer function is used in the following standards:

- Rec. ITU-R BT.601-7 525 or 625
- Rec. ITU-R BT.1358-1 525 or 625
  (historical)
- Rec. ITU-R BT.1700-0 NTSC
- SMPTE ST 170 (2004)

### 7: SMPTE 240M

SMPTE 240M was an interim standard used during the early days of HDTV (1988-1998).

### 8: Linear

This value indicates that the content is already in linear light.

### 9: Logarithmic 100

Indicates a logarithmic transfer function with a 100:1 range.

### 10: Logarithmic 316

Indicates a logarithmic transfer function with a (100 \* sqrt(10)):1 range.

### 11: XVYCC

Used in standard IEC 61966-2-4. I have no idea what this actually is.

### 12: BT.1361E

This was intended to be a standard for "future" television systems, but it never really came into use.

### 13: sRGB

Represents the sRGB colorspace.

This transfer function is used in the following standards:

- IEC 61966-2-1 sRGB (with
  MatrixCoefficients equal to 0)
- IEC 61966-2-1 sYCC (with
  MatrixCoefficients equal to 5)

Note: Content often specifies that it is encoded with sRGB but in reality, is encoded in a pure 2.2
function. While close there is a discrepency which often shows in the form of shadows taking on the wrong
luminance. Specifying the encoding as BT.470M can be used to work around this.

### 14: BT.2020 10-bit

Typically used with ultra-high-definition 10-bit SDR video. Its transfer function is equivalent to BT.1886.

### 15: BT.2020 12-bit

Typically used with ultra-high-definition 12-bit SDR video. Its transfer function is equivalent to BT.1886.

### 16: PQ aka SMPTE 2084

PQ is the most widely used transfer function for HDR content. It allows for a wider range of luminance to be represented than conventional transfer functions.

This transfer function is used in the following standards:

- SMPTE ST 2084 (2014) for 10-, 12-,
  14- and 16-bit systems
- Rec. ITU-R BT.2100-2 perceptual
  quantization (PQ) system

### 17: SMPTE 428

SMPTE 428 is used for D-Cinema Distribution Masters, aka DCDM.

### 18: HLG aka Hybrid Log-Gamma

HLG is an alternative transfer function for HDR content used by some televisions.

This transfer function is used in the following standards:

- ARIB STD-B67 (2015)
- Rec. ITU-R BT.2100-2 hybrid log-
  gamma (HLG) system


title: Content license and attribution

description: How Encode Wiki content may be reused and how migrated material is credited.

markdown:
Unless an individual page, dataset, image, or other asset states different terms, Encode Wiki prose
and media are licensed under the
[Creative Commons Attribution-ShareAlike 4.0 International license](https://creativecommons.org/licenses/by-sa/4.0/).

You may share and adapt that material, including commercially, provided you give appropriate credit,
link to the license, indicate whether changes were made, and distribute adaptations under the same
license. An item-specific notice takes precedence.

The initial corpus is migrated from the AV1 Community Contributors'
[Codec Wiki](https://github.com/av1-community-contributors/codec-wiki). Migrated pages record the
original path, source revision, migration date, and whether they were modified. The full repository
notice is available in [`NOTICE.md`](https://gitgud.io/encode/encode.wiki/-/blob/master/NOTICE.md).

New application, test, migration, and infrastructure code is separately available under the MIT
License.


title: FAQ

text: Why are you doing this?

anchor: why-are-you-doing-this

text: How do I get started as a contributor?

anchor: how-do-i-get-started-as-a-contributor

text: Why "Codec Wiki"?

anchor: why-codec-wiki

markdown:
## Why are you doing this?

Multimedia encoding & the digital compression space is an incredible field that many tech enthusiasts, professionals, & laymen have no easy entry point to. Wikipedia has a vast amount of information on many of the individual topics covered here but doesn't offer a cohesive way to engage with the entire sphere of knowledge as a whole. While this site started as a lighthearted guide (you'll see the remnants of this strewn about the various wiki entries), it has quickly become an endeavor to unite digital compression aficionados to make the knowledge more accessible for all.

### But alternatives exist. Why not contribute there?

While this is true, this is easier said than done.

- Multimedia Wiki is not as active as it used to be, & a new effort makes sense to carry past efforts forward.

- [guide.encode.moe](https://guide.encode.moe/) is stagnant and mostly focused on fansub, docs & personal experiences that are scattered around the Internet.

- There are sources littered about that explain pieces of the larger puzzle, but these serve as small drops in a bucket of vast incoherency & don't meaningfully remedy the steep learning curve for understanding multimedia compression without background knowledge.

### How do I get started as a contributor?

See our Contribution Guide page in the sidebar.

### Why "Codec Wiki"?

This wiki is mostly going to be focused on multimedia compression, & the term "Codec" is already widely recognized & understood. While other topics like video filtering & general compression algorithms may be covered, the main focus remains multimedia compression.


title: Privacy Policy

description: This site is hosted on GitHub Pages, & usage of this site is subject to GitHub's Privacy Policy. GitHub may store information about your visit in the form of log files.

status: archived

markdown:
This site is hosted on GitHub Pages, & usage of this site is subject to [GitHub's Privacy Policy](https://docs.github.com/en/site-policy/privacy-policies/github-privacy-statement). GitHub may store information about your visit in the form of log files.

Furthermore, this site uses a self-hosted instance of [Plausible Analytics](https://plausible.io) located in Singapore. Plausible Analytics is a lightweight and open source web analytics platform for website traffic analysis. We do not track, collect nor store any personally identifiable information; Plausible Analytics collects only aggregated information, which does not allow us to identify any visitor to our website.

This information is collected to understand how users interact with the Codec Wiki and improve our efforts to better suit the needs of these users.

We do not employ the use of cookies. The following information is collected:
- Page URL
- HTTP Referer
- Browser & Browser Version
- Operating System type & version
- Device type
- Country, region, & city

Given this information, we ensure:
- Analytics data is not shared explicitly with advertising companies or any other companies in general. It was made available to everyone for free on a public analytics page that is no longer available.
- Analytics data isn't explicitly sent to any third parties
- Analytics data is not monetized

As a wiki dedicated to making multimedia codec knowledge more accessible, analytics information was made public via that former analytics page.

You may opt out with various means of ad & tracker blocking. An example would be [UBlock Origin](https://ublockorigin.com/), which blocks our analytics script.

If you have any questions, comments or concerns, you may reach out to site maintainer Gianni Rosato via [grosatowork@proton.me](mailto:grosatowork@proton.me).

*Last updated 12 September 2023*


title: Terms of Use

markdown:
These terms & conditions outline the rules & regulations for the use of the Codec Wiki Website as a visitor, contributor, or any other party who falls under the jurisdiction of these terms.

By accessing this website we assume you accept these terms & conditions. Do not continue to use the site if you do not agree to all of the terms & conditions stated on this page.

The following terminology applies to these Terms & Conditions & all other Agreements: “Client”, “You” & “Your” refers to you, the person log on this website & compliant to these terms & conditions. “Ourselves”, “We”, “Our” & “Us”, refers to the site's owner. “Party”, “Parties”, or “Us”, refers to both the Client & ourselves. Any use of the above terminology or other words in the singular, plural, capitalization and/or they/he/she, are taken as interchangeable & therefore as referring to the same.

1. Cookies

We may employ the use of cookies in the future. At the time of writing, we do not. If accessing the site employs the use of cookies, you will be prompted to agree to use cookies in agreement with our Privacy Policy. As of writing, our Privacy Policy does not require users' consent to the use of cookies due to the fact that we do not use cookies.

Some interactive websites use cookies to let them retrieve user details for each visit. Cookies may be used by our website to enable the functionality of certain areas to make it easier for people visiting our website.

2. Licensing

Unless otherwise stated, the site's contributors and/or its licensors own the intellectual property rights for all material on the Codec Wiki. All intellectual property is distributed under CC BY-SA 4.0 unless it is specified otherwise. You may assess the terms & conditions of this Creative Commons license via this link: https://creativecommons.org/licenses/by-sa/4.0/. Using assets and/or intellectual property from the Codec Wiki site is subject to these terms unless otherwise specified.

Under CC BY-SA 4.0, you may:

> Share - copy and redistribute the material in any medium or format.

> Adapt - remix, transform, and build upon the material for any purpose, even commercially.

No party can revoke these freedoms as long as you follow the license terms. The terms are as follows:

> Attribution - You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

> ShareAlike - If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

Contributors may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.

Parts of this website may offer an opportunity for users to post & exchange opinions & information in certain areas of the site. We do not filter, edit, publish or review Comments prior to their presence on the website. Comments do not reflect the views & opinions of contributors, its agents and/or affiliates. Comments reflect the views & opinions of the person who posts their views & opinions. To the extent permitted by applicable laws, the site's host & wiki contributors shall not be liable for the Comments or any liability, damages or expenses caused and/or suffered as a result of any use of and/or posting of and/or appearance of the Comments on this website.

Part of the nature of a community-developed wiki is the ability for members of the community to make contributions to the contents of the site. Contributors are responsible for their own contributions to the site, & we shall not be liable for the contributions or any liability, damages or expenses caused and/or suffered as a result of any use of and/or posting of and/or appearance of the contributions to this website.

We reserve the right to monitor all Comments and/or contributions & to remove any Comments and/or contributions which can be considered inappropriate, offensive or causes a breach of these Terms & Conditions.

You warrant & represent that:

    You are entitled to post the Comments/contributions on our website & have all necessary licenses & consents to do so;
    The Comments/contributions do not invade any intellectual property right, including without limitation copyright, patent or trademark of any third party;
    The Comments/contributions do not contain any defamatory, libelous, offensive, indecent or otherwise unlawful material which is an invasion of privacy
    The Comments/contributions will not be used to promote unlawful activity.

You hereby grant the Codec Wiki a non-exclusive license to use, reproduce, edit & authorize others to use, reproduce & edit any of your Comments/contributions in any & all forms, formats or media.

3. iFrames

You may not create frames around our Webpages that alter in any way the visual presentation or appearance of our Website without proper attribution per CC BY-SA 4.0 where the license applies. Elsewhere, written permission is required if an asset is not under the CC BY-SA 4.0 license.

4. Content Liability

We shall not be held responsible for any content that appears on your Website. You agree to protect & defend us against all claims that arise on your Website. No link(s) should appear on any Website that may be interpreted as libelous, obscene, or criminal, or which infringes, otherwise violates, or advocates the infringement or other violation of, any third party rights.

5. Your Privacy

Please read our Privacy Policy.

6. Reservation of Rights

We reserve the right to request that you remove all links or any particular link to our Website. You approve to immediately remove all links to our Website upon request. We also reserve the right to amend these terms & conditions & its linking policy at any time. By continuously linking to our Website, you agree to be bound to & follow these terms & conditions.

7. Removal of links from our website

If you find any link on our Website that is offensive for any reason, you are free to contact & inform us at any moment. We will consider requests to remove links but we are not obligated to or so or to respond to you directly. We do not ensure that the information on this website is correct, we do not warrant its completeness or accuracy; nor do we promise to ensure that the website remains available or that the material on the website is kept up-to-date.

8. Disclaimer

To the maximum extent permitted by applicable law, we exclude all representations, warranties & conditions relating to our website & the use of this website. Nothing in this disclaimer will:

    limit or exclude our or your liability for death or personal injury;
    limit or exclude our or your liability for fraud or fraudulent misrepresentation;
    limit any of our or your liabilities in any way that is not permitted under applicable law; or
    exclude any of our or your liabilities that may not be excluded under applicable law.

The limitations & prohibitions of liability set in this Section & elsewhere in this disclaimer: (a) are subject to the preceding paragraph; & (b) govern all liabilities arising under the disclaimer, including liabilities arising in contract, in tort & for breach of statutory duty.

As long as the website & the information on the website are provided free of charge, we will not be liable for any loss or damage of any nature.


title: Contribution Guide

text: Before You Contribute

anchor: before-you-contribute

text: Connect With Us

anchor: connect-with-us

text: Clone & Push Instructions

anchor: clone-push-instructions

text: Website

anchor: website

text: Installation

anchor: installation

text: Local Development

anchor: local-development

text: Build

anchor: build

text: Deployment

anchor: deployment

markdown:
Codec Wiki - community-maintained wiki for all things encoding.

## Before You Contribute

1. By contributing to the Codec Wiki, you are communicating that you have read & agreed to our Terms & Conditions, Privacy Policy, & Code of Conduct.
2. Ensure your understanding of the material you're contributing is sufficient to a point where it is useful to the project. It is perfectly acceptable not to get everything right the first time, but always double-check your contributions for factual correctness.

**Our current priority is filling out the existing pages with content. Please assist in doing this, if possible, before considering adding new pages.**

If you're unsure the content in your entry is completely correct or you believe your entry needs review, please attach the following message at the top of your entry:

> **Caution — Pending Review.**
>
> The content in this entry may not be entirely accurate, & is pending further review to assess the quality of the information.
If you're aware your entry is too short or incomplete, please add the following message to the top of your entry:

> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
If you've added a new page & you aren't sure what should go there (this isn't recommended while there are still so many empty pages to be filled), add the following message as your page entry:

> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
### Connect With Us

If you'd like to join the "AV1 for Dummies" Discord server to communicate with other passionate contributors helping this project, please join using the widget below:

<iframe src="https://discord.com/widget?id=1163724583472472138&theme=dark" width="350" height="500" allowtransparency="true" frameborder="0" sandbox="allow-popups allow-popups-to-escape-sandbox allow-same-origin allow-scripts"></iframe>

Alternatively, we have a (soon to be) bridged Revolt server linked [right here](https://rvlt.gg/eSERRhSG). Revolt is an open-source Discord alternative, which you can read more about on [the current project about page](https://stoat.chat/about).

## Clone & Push Instructions
**Make sure to clone from & edit the** `main` **branch only, & push your final changes to the** `deployment` **branch according to the instructions below. Also be sure to use node 18 LTS, as later versions tend to be troublesome.**

*don't forget to add unimportant files to the .gitignore before making any commits*

1. Clone from the `main` branch to start to make a contribution:
```bash
% git clone git@github.com:av1-community-contributors/av1-wiki.github.io.git -b main
```

2. Test your changes locally before making a commit:
```bash
% yarn
% yarn start
```

3. Push changes to `main` branch:
```bash
% git add .
% git commit -m "Commit Message"
% git push -u origin main
```

4. Deploy to `deployment` branch to make live on site:
```bash
% yarn deploy
```

*Docusaurus Info*
## Website

This website is built using [Docusaurus 3](https://docusaurus.io/), a modern static website generator.

### Installation

```
$ yarn
```

### Local Development

```
$ yarn start
```

This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.

### Build

```
$ yarn build
```

This command generates static content into the `build` directory and can be served using any static contents hosting service.

### Deployment

See the initial instructions at the top.