title: Denoise

text: Overview

anchor: overview

text: Usage

anchor: usage

text: nlmeans

anchor: nlmeans

text: Usage

text: Parameters

anchor: parameters

text: Notes

anchor: notes

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!
## Overview

Denoising involves removing random noise from the video. Such noise can result from film grain, signal interference or simply low light conditions. In any case, noise can greatly reduce compression efficiency especially if the video codec doesn't support film grain synthesis.

In [FFmpeg](/tools/utilities/ffmpeg/) there are two filters available for denoising:
- [hqdn3d](#hqdn3d)
- [nlmeans](#nlmeans)

## hqdn3d

hqdn3d is a fast, high quality 3d denoising filter which improves compressibility. Can be applied to images and videos.

### Usage

```shell
ffmpeg -i input.mp4 -vf hqdn3d output.mp4
```

The default configuration should be fine for most use cases.

If you still see too much noise you can adjust the `luma_spatial` parameter (other parameters are derived from it by default). Higher `luma_spatial` value will result in stronger denoising. By default it is set to `4`.

```shell
ffmpeg -i input.mp4 -vf hqdn3d=8 output.mp4
# which is the same as
ffmpeg -i input.mp4 -vf hqdn3d=8:6:12:9 output.mp4
```

> **Caution — Setting `luma_spatial` to larger values could result in ghosting and [banding](/start-here/video-artifacts/#bandingcontouring) artifacts..**
>
>
For description of all four parameters take a look [here](https://ffmpeg.org/ffmpeg-filters.html#hqdn3d-1).

## nlmeans

nlmeans uses Non-Local Means algorithm to do denoising. Each pixel is compared to similar pixels based on their surroundings (context). The size of such context is expressed as `r`x`r`.

The filter is rather slow and doesn't parallelize well. Only use it in cases the video contains a lot of noise or you need very high quality denoising. In all other cases [hqdn3d](#hqdn3d) will be more efficient.

### Usage

```bash
ffmpeg -i input.mp4 -vf nlmeans output.mp4
```

The default configuration should be fine for most use cases.

```bash
ffmpeg -i input.mp4 -vf nlmeans=s=3.0:r=31:p=15 output.mp4
```

Stronger denoising with larger research and patch size. Might be useful for ultra high quality denoising in 4K+ resolutions but you might struggle to achieve even 0.1 fps.

```bash
ffmpeg -i input.mp4 -vf nlmeans=s=1.0:r=5:p=3 output.mp4
```

Prioritize speed over quality.

### Parameters

- `s` - Denoising Strength where `1.0` is the lightest and also the default and the strongest is `30.0` although I wouldn't recommend going above `10.0`.
- `r` - Research Size where `15` is the default, it must be an odd number ranging from `0` to `99`. The higher the value, the slower denoising will be.
- `p` - Research Size where `7` is the default and, it must be an odd number ranging from `0` to `99`.

For description of all possible parameters take a look [here](https://ffmpeg.org/ffmpeg-filters.html#nlmeans-1).

# Notes
- [hqdn3d](#hqdn3d) may create visual artifacts like ghosting, [banding](/start-here/video-artifacts/#bandingcontouring) and [blocking](/start-here/video-artifacts/#blocking)
- [nlmeans](#nlmeans) creates much less noticeable artifacts like cartoonish look but only for very noisy inputs


collection: docs

title: Graining

description: Codec Wiki reference material about Graining.

status: needs-review

license: CC BY-SA 4.0

contentFormat: markdown

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!


title: Inverse Telecine

description: Codec Wiki reference material about Inverse Telecine.


title: Stabilizing

description: Stabilizing is the process of reducing unwanted camera movement and shakes in video clips using FFmpeg. This improves overall encoding efficiency by minimizing unpredictable global movement, such as that from handheld ca

text: Overview

text: Usage

text: vidstabdetect Parameters

anchor: vidstabdetect-parameters

text: vidstabtransform Parameters

anchor: vidstabtransform-parameters

text: Notes

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!
## Overview

Stabilizing is the process of reducing unwanted camera movement and shakes in video clips using [FFmpeg](/tools/utilities/ffmpeg/). This improves overall encoding efficiency by minimizing unpredictable global movement, such as that from handheld cameras. The recommended method for stabilizing videos with FFmpeg is to use the VidStab library, which requires a build of FFmpeg compiled with `--enable-libvidstab`.

VidStab offers two filters within FFmpeg:

```shell
ffmpeg -hide_banner -filters | grep vidstab
 ... vidstabdetect     V->V       Extract relative transformations, pass 1 of 2 for stabilization (see vidstabtransform for pass 2).
 ... vidstabtransform  V->V       Transform the frames, pass 2 of 2 for stabilization (see vidstabdetect for pass 1).
```

The `vidstabdetect` filter is used in the first pass to generate a video transformations file (`.trf`), while `vidstabtransform` is employed in the second pass to apply those transformations.

## Usage

To stabilize a video using default parameters, follow these two steps:

```shell
ffmpeg -i input.mp4 -vf vidstabdetect -f null -
ffmpeg -i input.mp4 -vf vidstabtransform output.mp4
```

After running the first command, a `transforms.trf` file will be created in the directory where you executed FFmpeg. Once the stabilization process is complete, you can safely delete this file. The resulting `output.mp4` video will have reduced shakiness.

For stabilizing high-framerate videos with strong camera movement:

```shell
ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=8:result=a.trf -f null -
ffmpeg -i input.mp4 -vf vidstabtransform=smoothing=30:zoom=-5:input=a.trf output.mp4
```

> **Tip — Remember to set appropriate video/audio codec parameters in the command before `output.mp4`. You must not use `-c:v copy`, as the video will undergo transformations..**
>
>
### vidstabdetect Parameters

- `result` - Sets the output `.trf` file location
- `shakiness` - Adjusts movement reduction, with `1` being the least and `10` the most reduction (highest stabilization). Default is `5`.
- `accuracy` - Controls movement reduction accuracy. Lower values use less CPU but may be less accurate. FFmpeg's minimum allowed value is `3`. Processing speed was approximately `21 fps` at `3` and `14 fps` at `15`.

For a complete list of parameters, refer to the [vidstabdetect documentation](https://ffmpeg.org/ffmpeg-filters.html#vidstabdetect-1).

### vidstabtransform Parameters

- `input` - Specifies the input `.trf` file created by `vidstabdetect`
- `smoothing` - Determines the number of frames considered for future and past movement estimation. Default is `10`.
- `zoom` - Adjusts the zoom percentage, with `0%` being the default. Negative values create a zoom-out effect.
- `interpol` - Sets the type of interpolation used:
  - `no` - No interpolation
  - `linear` - Only horizontal
  - `bilinear` - Faster but may result in blurry output (default)
  - `bicubic` - Slower

See the [vidstabtransform documentation](https://ffmpeg.org/ffmpeg-filters.html#vidstabtransform-1) for more details.

## Notes

- Stabilization is a lossy process that can reduce video quality due to zoom and interpolation effects.
- Some users may notice overall wobbliness in stabilized videos, especially at higher stabilization levels. This is an inherent characteristic of this filter.
- Depending on your use case, consider employing two-pass encoding along with these stabilization steps.


title: Vapoursynth

status: current

text: Introduction

anchor: introduction

text: Installation

anchor: installation

text: Microsoft Windows

anchor: microsoft-windows

text: Arch Linux

anchor: arch-linux

text: Other Linux

anchor: other-linux

text: Previewing

anchor: previewing

text: Output

anchor: output

text: Source Filters

anchor: source-filters

text: LSmashSource

anchor: lsmashsource

text: BestSource

anchor: bestsource

markdown:
> VapourSynth is an application for video manipulation. Or a plugin. Or a library. It’s hard to tell because it has a core library written in C++ and a Python module to allow video scripts to be created.

*Fredrik Mellbin, creator of VapourSynth*

<picture>
  <source
    srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/vs_edit_script.avif?token=GHSAT0AAAAAACEZPDXJ6SHSUQIMUOGQXQTEZHY7K4A"
    type="image/avif"
  />
  <img
    src="https://autumn.revolt.chat/attachments/g7DucEq3aRGWVH0MHQe-A21GkyDVln9IHzRlfjEYEh/vs_edit_script.png"
    alt="Vapoursynth script"
    width="520"
    height="632"
  />
</picture>{" "}

# Introduction

In the realm of video processing, one will frequently encounter media with various quality issues. These can range from minor imperfections to significant degradation, including:

- Excessive film grain or noise that significantly increases bitrate due to its unpredictable nature
- Visible banding artifacts
- Unwanted halos around objects
- Interlacing issues in older, unrestored footage
- Telecine artifacts from improper film-to-video conversion
- And more, on our [video artifacts](/start-here/video-artifacts/) page.

To address these challenges, video filtering techniques are employed. Currently, there are three primary software frameworks used for video filtering:

1. [FFmpeg](/tools/utilities/ffmpeg/)
2. [VapourSynth](https://vapoursynth.com)
3. [AviSynth](http://avisynth.nl/index.php/Main_Page)

VapourSynth is designed as a 21st-century upgrade and rewrite of AviSynth, which was originally created by Ben Rudiak-Gould, Edwin van Eggelen, Klaus Post, Richard Berg, and Ian Brabham in May 2000. One of the most attractive features of this complete rewrite is its improved multithreading capability, an area where AviSynth struggled due to its aging infrastructure.

Some longtime AviSynth users are reluctant to switch to VapourSynth, preferring to stick with a familiar workflow. There is nothing wrong with this preference, as both tools have their merits in video processing; that being said, the Codec Wiki's *Filtering* section focuses primarily on VapourSynth (and occaisonally FFmpeg). It is important to note that working with VapourSynth requires a basic understanding of Python, as the filtering process involves scripting.

## Installation

### Microsoft Windows

- At the time of writing, Python 3.12 is required. This will change in the future so consult from [their website](http://www.vapoursynth.com/doc/installation.html)
- Download the installer (`.exe`) unless you require portability
- Install it

### Arch Linux

Currently, Arch is the best Linux distribution for working with Vapoursynth due to the fact that
the vast majority of filters and plugins are available in the AUR. This makes installing and updating filters easy.
If you are not already, we recommend using an AUR helper such as
[paru](https://github.com/Morganamilo/paru) or [yay](https://github.com/Jguer/yay).

To install vapoursynth, simply install the `vapoursynth` package from the official repositories using pacman or your preferred AUR helper.

Plugins are all prefixed with `vapoursynth-plugin-`, such as `vapoursynth-plugin-lsmashsource-git`, and as such can be discovered easily.

### Other Linux

Vapoursynth is supported on all Linux distributions. Installation methods may vary by distribution.

Contributions would be helpful to provide instructions for more distributions.

## Previewing

There are currently two leading previewers for Vapoursynth. If you want to preview your scripts with capabilities such as seeking,
you will need to use one of these applications.

The first is YomkioR's [Vapoursynth Editor](https://github.com/YomikoR/VapourSynth-Editor/), which includes a built-in code editor alongside a video previewer.
This makes it extremely easy to set up for users who are new to Vapoursynth.

The second is JET's fork of [vs-preview](https://github.com/Jaded-Encoding-Thaumaturgy/vs-preview), which is a standalone previewer with utilities for
tasks such as cropping, screenshotting, and uploading comparisons. This tool is more advanced than Vapoursynth Editor, but does not include an editor,
so you will need to pair it with an editor such as Visual Studio Code. The Github for vs-preview includes instructions for setting this up.

## Output

Vapoursynth provides a command-line utility called `vspipe` for outputting filtered video. Using this utility to pipe y4m video
is the most common way to use Vapoursynth with an encoder.

For example, the following command would pipe the output from a Vapoursynth script into x264:

`vspipe -c y4m input.vpy - | x264 --demuxer y4m -o output.mkv -`

## Source Filters

For Vapoursynth to produce output, it has to load a video in some way. This way is with source filters.

The most basic method is using `BlankClip` to create a clip of a certain resolution and frame rate. For example, the following
script would give us a blank clip at 640x480:

```python
import vapoursynth as vs

core = vs.core

clip = core.std.BlankClip(width=640, height=480)

clip.set_output(0)
```

But a plain black video isn't very useful, is it? We want to load real videos so we can do filtering on them.
For this, there are a few different source filters we can look at.

### LSmashSource

[LSmashSource](https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works) is a source filter using lsmash as the underlying source library.
It is the most commonly used source filter, and is generally reliable for most source formats, though may have frame accuracy issues
when seeking with certain input formats, such as VC-1. If this is a concern, it can be recommended to encode to lossless first before
using any encoding methods that require seeking, such as av1an.

Here is an example of loading a video file using LSmashSource:

```python
import vapoursynth as vs

core = vs.core

clip = core.lsmas.LWLibavSource(source="input.mkv")

clip.set_output(0)
```

### ffms2

[ffms2](https://github.com/FFMS/ffms2) is a source filter based on ffmpeg. It generally should give the same results as LSmashSource,
especially when using the git version which has fixed support for newer formats such as AV1. If having issues with a source file with LSmashSource,
ffms2 can be a good fallback to try.

```python
import vapoursynth as vs

core = vs.core

clip = core.ffms2.Source(source="input.mkv")

clip.set_output(0)
```

### BestSource

[BestSource](https://github.com/vapoursynth/bestsource/) is also based on ffmpeg, but uses additional techniques
to ensure frame accuracy in all scenarios with all input formats. The downside is that it must decode the entire video
during indexing, which means the first load of a given video will take longer. Subsequent loads will be quick, because
BestSource caches the index in a file.

```python
import vapoursynth as vs

core = vs.core

clip = core.bs.VideoSource(
    source="input.mkv",
    cachepath="/"
)

clip.set_output(0)
```

We add the `cachepath="/"` setting to emulate the behavior of the other source filters, which is to place the index file next to the source video.
This helps with portability and cleaning up after ourselves. The default behavior is to place the index file in a temporary directory local to the machine.


title: AMF

markdown:
> **Caution — Pending Review.**
>
> The content in this entry may not be entirely accurate, & is pending further review to assess the quality of the information.
AMF for AMD GPUs allows applications to take advantage of the dedicated video encoding & decoding hardware present in AMD GPUs.

The AMD Advanced Media Framework (AMF) is a low-level API developed by AMD that enables developers to leverage hardware-accelerated video encoding & decoding on AMD GPUs. By utilizing specialized hardware on the GPU's media block, video encoding and decoding tasks can be offloaded from the CPU, resulting in drastic speed & efficiency increases. AMF provides multimedia processing functionality to applications, and competes with Nvidia's [NVENC](/tools/hardware-encoders/nvenc/) & Intel's [QSV](/tools/hardware-encoders/qsv/) for similar functionality.

AMF provides support for various video codecs, including [H.264](/codecs/video/avc/) , [H.265](/codecs/video/hevc/), [VP9](/codecs/video/vp9/), and more recently [AV1](/codecs/video/av1/) on the latest supported GPUs. The GPU's encoding capabilities are especially useful for compressing video content in real-time, where speed is of greater importance than coding efficiency.

Hardware-accelerated video encoding using AMF usually significantly improves encoding performance at low compression efficiency compared to software-based encoding solutions. It usually allows for higher-quality output at lower bitrates when encoding much faster than real time, such as at 60-200 fps. This is particularly beneficial for applications that require real-time encoding, such as live streaming, video conferencing, and game recording.

However, slower software encoding solutions almost always offer improvements in fidelity per bit compared to hardware encoding. For offline re-encoding & storage, software encoding is generally preferred. AMF in particular is not known for having strong compression efficiency, as it is hampered by AMD's comparably weak media blocks which are usually outperformed by other hardware implementations from Nvidia, Intel, & Apple.

AMF is designed to integrate seamlessly with popular media frameworks and libraries, such as [FFmpeg](/tools/utilities/ffmpeg/) and GStreamer. These frameworks often include AMF support, allowing developers to easily incorporate hardware-accelerated encoding into their applications without the need for low-level API programming.

AMF is compatible with a wide range of AMD GPUs, including both discrete and integrated graphics solutions. It supports various operating systems, including Windows and Linux, making it accessible to developers across different platforms.


title: Mediacodec

description: The Android's MediaCodec framework is a part of Android's multimedia framework that provides access to low-level media encoder & decoder components. It is similar to VideoToolbox on Apple devices. Hardware acceleration w

text: Usage

text: FFmpeg

anchor: ffmpeg

markdown:
The Android's MediaCodec framework is a part of Android's multimedia framework that provides access to low-level media encoder & decoder components. It is similar to [VideoToolbox](/tools/hardware-encoders/videotoolbox/) on Apple devices. Hardware acceleration with MediaCodec is used for processing audio, video, and compressed data.

One of the key features of the MediaCodec framework is its support for automatic media transcoding within the operating system. Introduced in Android 12, media transcoding features of the operating system allow devices to use more modern, storage-efficient media formats for video capture while maintaining compatibility with apps. For devices with compatible media transcoding enabled, Android can automatically convert videos recorded in formats such as [H.265](/codecs/video/hevc/) when the videos are opened by an app that doesn't support the format. This allows apps to function even when videos are captured in newer formats on the device.

## Usage

In order to view your device's supported hardware and software encoders exposed by the MediaCodec framework, it is advised to download the open source [Codec Info](https://play.google.com/store/apps/details?id=com.parseus.codecinfo) application.

Once you know how to properly interact with your device's hardware encoders, [FFmpeg](/tools/utilities/ffmpeg/) will help you transcode videos easily from the command line.

### FFmpeg

Testing for this piece was done on the Google Pixel 8, which featurs the Tensor G3 SoC. It is Exynos-based, so [H.264](/codecs/video/avc/), H.265 (HEVC), and [VP9](/codecs/video/vp9/) hardware acceleration for encoding are provided by the Exynos media block. AV1 encoding and decoding are available on the Tensor G3 provided by a custom Google multimedia block.

The Exynos's hardware implementation for encoding H.264 and H.265 does not support CQ (Constant Quality) encoding, so a target bitrate must be provided for either CBR (Constant Bitrate) or VBR (Variable Bitrate) encoding. Google's AV1 implementation is in the same situation.

Some example MediaCodec encoding commands with FFmpeg:

```bash title="H.264 encoding (VBR, target bitrate 4000K, 250-frame GOP size)"
ffmpeg -i input.mkv -c:v h264_mediacodec -codec_name c2.exynos.h264.encoder -bitrate_mode 1 -b:v 4000K -g 250 output.mp4
```

```bash title="H.265 encoding (VBR, target bitrate 4000K, 250-frame GOP size)"
ffmpeg -i input.mkv -c:v hevc_mediacodec -codec_name c2.exynos.hevc.encoder -bitrate_mode 1 -b:v 4000K -g 250 output.mp4
```
VP9 encoding produces video that is severely distorted relative to the bitrate, and AV1 encoding produces broken files without metadata.

```bash title="VP9 encoding (VBR, target bitrate 9000K, 250-frame GOP size)"
ffmpeg -i input.mkv -c:v vp9_mediacodec -codec_name c2.exynos.vp9.encoder -bitrate_mode 1 -b:v 9000K -g 250 output.mkv
```
```bash title="AV1 encoding (VBR, target bitrate 8000K, 250-frame GOP size)"
ffmpeg -i input.mkv -c:v av1_mediacodec -codec_name c2.google.av1.encoder -bitrate_mode 1 -b:v 8000K -g 250 output.mp4
```

Just run `ffmpeg -help encoder=hevc_mediacodec` or `ffmpeg -help encoder=h264_mediacodec` for more info on how to use your MediaCodec encoders. You can choose a value for `-codec_name` based on what is shown in the Codec Info app.

*Sources*
(1) MediaCodec | Android Developers. https://developer.android.com/reference/android/media/MediaCodec.
(2) Media | Android Open Source Project. https://source.android.com/docs/core/media.


title: NVENC

markdown:
> **Caution — Pending Review.**
>
> The content in this entry may not be entirely accurate, & is pending further review to assess the quality of the information.
NVENC for NVIDIA GPUs is a dedicated hardware video encoding engine integrated into NVIDIA's graphics processors. It allows applications to leverage dedicated multimedia encoding hardware to accelerate video encoding tasks, significantly improving performance when compared to CPU-based software encoding. It competes with similar frameworks like Intel's [QSV](/tools/hardware-encoders/qsv/) & AMD's [AMF](/tools/hardware-encoders/amf/).

The primary purpose of NVENC is to offload the computationally intensive video encoding workloads from the CPU to the dedicated multimedia hardware on the GPU, thereby freeing up CPU resources for other tasks. This is particularly beneficial in scenarios where fast video encoding is required, such as screen recording, streaming, & video conferencing.

NVENC supports a range of popular video codecs, including [H.264](/codecs/video/avc/) , [H.265](/codecs/video/hevc/), [VP9](/codecs/video/vp9/), and more recently [AV1](/codecs/video/av1/) on their latest GPUs. It provides hardware-accelerated encoding capabilities for these codecs, typically achieving real-time or faster than real-time encoding performance, depending on resolution, bitrate, and hardware capability.

While NVENC excels in encoding speed, it generally sacrifices some compression efficiency compared to modern high-quality CPU-based software encoders at slower presets.

NVENC is designed to be easily integrated into various multimedia frameworks and applications. It is supported by popular tools like [FFmpeg](/tools/utilities/ffmpeg/), OBS Studio, and others, allowing developers to seamlessly leverage GPU-accelerated encoding without the need for low-level programming.

When compared to AMD's AMF and Intel's QSV, NVENC is known for its high encoding performance, low latency, and broad compatibility with NVIDIA GPUs across different platforms. It is particularly popular among game streamers, content creators, and video professionals who require fast encoding speeds for their workflows. In terms of video compression efficiency, NVENC & QSV trade blows while AMF is generally left behind.


title: QSV

description: QSV is Intel's hardware video encoding/decoding platform integrated into many of their modern CPUs with integrated graphics processors & their Arc graphics cards. It allows applications to offload video encoding, decodin

markdown:
> **Caution — Pending Review.**
>
> The content in this entry may not be entirely accurate, & is pending further review to assess the quality of the information.
QSV (QuickSync Video) is Intel's hardware video encoding/decoding platform integrated into many of their modern CPUs with integrated graphics processors (iGPUs) & their Arc graphics cards. It allows applications to offload video encoding, decoding, and processing tasks to the dedicated media engines on Intel's dedicated multimedia hardware, often providing significant performance gains compared to CPU-based software encoding. QSV competes with similar frameworks like Nvidia's [NVENC](/tools/hardware-encoders/nvenc/) & AMD's [AMF](/tools/hardware-encoders/amf/) (Since the transition to Apple Silicon, QSV on Intel Macs competes with Apple's [VideoToolBox](/tools/hardware-encoders/videotoolbox/) on macOS devices).

The key purpose of QSV is to accelerate video encoding, decoding, and processing workloads by leveraging specialized fixed-function hardware present in Intel's graphics processors. This dedicated hardware is distinct from the general-purpose compute units, and is designed specifically for multimedia tasks. QSV aims to deliver high encoding/decoding performance while operating efficiently.

QSV supports a wide range of video codecs including [H.264](/codecs/video/avc/) , [H.265](/codecs/video/hevc/), [VP9](/codecs/video/vp9/), and more recently [AV1](/codecs/video/av1/) on their latest discrete & integrated GPUs. A major advantage of QSV is that it is ubiquitous on most modern Intel CPUs with integrated graphics, making hardware-accelerated video encoding accessible across a wide range of systems. Applications can easily leverage QSV acceleration through APIs like Intel Media SDK, VA-API, or via integration with popular multimedia frameworks like [FFmpeg](/tools/utilities/ffmpeg/), GStreamer, & others.

Hardware-accelerated video encoding with QSV usually significantly improves encoding performance at low compression efficiency compared to software-based encoding solutions. It usually allows for higher-quality output at lower bitrates when encoding much faster than real time, such as at 60-200 fps. This is particularly beneficial for applications that require real-time encoding, such as live streaming, video conferencing, and game recording.

While QSV is not designed for highly efficient offline file encoding, where quality is prioritized over speed. It is worth noting that QSV is almost always better than AMF from AMD & competitive with NVENC from Nvidia in terms of compression efficiency.


title: VideoToolbox

text: Usage

anchor: usage

text: FFmpeg

text: Handbrake

anchor: handbrake

markdown:
> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
Apple's VideoToolbox is a low-level framework that provides direct access to hardware encoders and decoders. It offers services for video compression and decompression, as well as conversion between raster image formats stored in CoreVideo pixel buffers. The VideoToolbox encoder works by compressing video data for various applications such as low-latency conferencing, live streaming, and offline transcoding. It supports hardware encoding on most Macs from 2011 and later, and uses Apple's Media Engine on devices with Apple T2 chips or Apple Silicon.

The encoder can be configured to optimize encoding for specific applications, and it supports various video codecs including [H.264](/codecs/video/avc/), [H.265](/codecs/video/hevc/), with support for H.265 8-bit and 10-bit encoding. It is worth noting that the VideoToolbox encoder is designed for applications that require direct access to hardware encoders and decoders.

Apple's VideoToolbox framework also supports hardware accelerated video decoding for a number of video codecs. As of the Apple M3, these include [H.264](/codecs/video/avc/), [H.265](/codecs/video/hevc/), [ProRes](/codecs/video/prores/), ProRes RAW, and [AV1](/codecs/video/av1/).

## Usage

Encoding with Videotoolbox on macOS is possible via [FFmpeg](/tools/utilities/ffmpeg/), a versatile command line utility, or Handbrake, a GUI for video encoding.

### FFmpeg

To use H.264 or H.265 (HEVC) hardware encoding in macOS via VideoToolbox, just use the encoder `-c:v h264_videotoolbox` or `-c:v hevc_videotoolbox` for H.264 or HEVC respectively.

Here are some example commands for encoding with VideoToolbox on Apple Silicon via FFmpeg:

```bash title="H.264 encoding (high profile)"
ffmpeg -i input.mkv -c:v h264_videotoolbox -profile 100 -q:v [0-100] output.mp4
```

```bash title="8-bit HEVC encoding (main profile)"
ffmpeg -i input.mkv -c:v hevc_videotoolbox -profile 1 -q:v [0-100] -tag:v hvc1 output.mp4
```

```bash title="10-bit HEVC encoding (main10 profile)"
ffmpeg -i input.mkv -c:v hevc_videotoolbox -profile 2 -q:v [0-100] -tag:v hvc1 output.mp4
```

Just run `ffmpeg -help encoder=hevc_videotoolbox` or `ffmpeg -help encoder=h264_videotoolbox` for more info.

### Handbrake

[HandBrakeCLI](https://handbrake.fr/docs/en/latest/cli/cli-options.html) can be installed via [Homebrew](https://formulae.brew.sh/formula/handbrake):

```bash
brew install handbrake
```

Here are some example commands for encoding with VideoToolbox on Apple Silicon via HandBrakeCLI:

```bash title="H.264 encoding with VideoToolbox"
HandBrakeCLI -i input.mkv -o output.mp4 --encoder vt_h264 --quality [0-100]
```

```bash title="H.265 encoding with VideoToolbox"
HandBrakeCLI -i input.mkv -o output.mp4 --encoder vt_h265 --quality [0-100]
```

```bash title="H.265 10-bit encoding with VideoToolbox"
HandBrakeCLI -i input.mkv -o output.mp4 --encoder vt_h265_10bit --quality [0-100]
```

Use `HandBrakeCLI --help` to see all available VideoToolbox options (and encoders, under **Video Options**).

*Sources*
(1) Video Toolbox | Apple Developer Documentation. https://developer.apple.com/documentation/videotoolbox.
(2) HandBrake Documentation — Apple VideoToolbox. https://handbrake.fr/docs/en/latest/technical/video-videotoolbox.html.
(3) Apple's T2 chip makes a giant difference in video encoding for most .... https://appleinsider.com/articles/19/04/09/apples-t2-chip-makes-a-giant-difference-in-video-encoding-for-most-users.


title: aom-av1-lavish

description: Mainline aomenc is unfortunately not perfect. It suffers from bad defaults, a heavy focus on the perceptually flawed PSNR metric, misleading settings, and other issues. Fortunately, there are a couple of forks developed

status: archived

text: FFmpeg

text: Installation

text: Usage

text: AV1 Encoding

text: AVIF Encoding

anchor: avif-encoding

text: Recommendations

anchor: recommendations

text: Tips & Tricks

anchor: tips-tricks

markdown:
# aom-av1-lavish

> **Note — Community Fork.**
>
> This entry is about a fork of aomenc called aom-psy101. If you'd like to learn about the mainline aomenc encoder before reading, visit our [aomenc wiki entry](/tools/software-encoders/aomenc/).
Mainline aomenc is unfortunately not perfect. It suffers from bad defaults, a heavy focus on the perceptually flawed [PSNR](/reference/metrics/psnr/) metric, misleading settings, and other issues. Fortunately, there are a couple of forks developed by the encoding community that were created to combat aomenc's underlying issues.

> **Caution — No Longer Maintained.**
>
> aom-av1-lavish is no longer maintained as of 4th June 2024. The information in this entry is unaffected by this, but the fact that the project is no longer maintained should be taken into consideration as a user.
- [aom-av1-psy](https://github.com/BlueSwordM/aom-av1-psy) *No longer maintained as of 13th January 2023*
- [aom-av1-lavish](https://github.com/Clybius/aom-av1-lavish) *No longer maintained as of 4th June 2024*
- [aom-psy101](/tools/software-encoders/aom-psy101/)
- [aom-av1ador](https://github.com/porcino/aom-av1ador)

These forks fix up the poor decisions made by the original AOM devs and most importantly introduce new parameters and tunes to help fine-tune the encoder even more.

[aom-av1-lavish](https://github.com/Clybius/aom-av1-lavish) is a fork of aomenc that aims to improve the encoding quality and speed of AV1. It is developed by [Clybius](https://github.com/Clybius), a talented AV1 community developer also well-known for working on [SVT-AV1-PSY](/tools/software-encoders/svt-av1-psy/).

## FFmpeg

aomenc is available in FFmpeg via ``libaom-av1``, check if you have it by running ``ffmpeg -h encoder=libaom-av1``. You can input non-FFmpeg standard aomenc parameters via ``-aom-params``.

> **Caution — Mainline aomenc.**
>
> Unless you compile FFmpeg yourself with aom-av1-lavish, you will be using the mainline aomenc. Compiling from source yourself with the aomenc libraries provided by aom-av1-lavish is the only way to use it with FFmpeg.
## Installation

    #### Linux

*A precompiled AVX2-optimized binary of aom-av1-lavish can be installed for x86_64 Linux via [rAV1ator CLI](/tools/utilities/rav1ator-cli/). However, it is always recommended to build from source.*

    But if you want to compile the community forks, you can also do that. CMake, Perl, GNU Make, and nasm (assuming x64, if x86 use yasm) will be needed for compilation.

    ```bash title="Clone the aom-av1-lavish repo Endless_Merging branch, cd and create build folder"
    git clone https://github.com/Clybius/aom-av1-lavish -b Endless_Merging
    cd aom-av1-lavish && mkdir -p aom_build && cd aom_build
    ```

    ```bash title="CMake configuration"
    cmake .. -DBUILD_SHARED_LIBS=0 -DENABLE_DOCS=0 -DCONFIG_TUNE_BUTTERAUGLI=0 -DCONFIG_TUNE_VMAF=0 -DCONFIG_AV1_DECODER=0 -DENABLE_TESTS=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS="-flto -O3 -march=native -pipe -fno-plt" -DCMAKE_LD_FLAGS="-flto -O3 -march=native"
    ```
    The CMake config above will statically build aomenc while disabling docs (which requires Doxygen), extra tunes, tests, and decoders. While also applying native CPU optimizations to help speed up the encoder.

    ```bash title="Compile the encoder"
    make -j$(nproc)
    ```
    The resulting binary will be in the same folder you are on (`aom_build`).

    Or, optionally, you can install it to your system, which may need elevated permissions.
    ```bash
    make install
    ```
    #### macOS

macOS is very similar to Linux. Note that some commands may have to be run with `sudo`, which I won't explicitly include for security reasons.

    **Homebrew**

    Installing the Homebrew package manager is a well documented process at this point:
    ```bash
    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
    ```
    Installing mainline libaom is as simple as running the following:

    ```bash
    brew update && brew upgrade
    brew install aom
    ```

    FFmpeg can also be installed via brew.

    **Building From Source**

    If you want aom-av1-lavish instead of mainline, you'll have to compile from source. Things are very similar to Linux, with a few oddities:

    - macOS sometimes doesn't have a `/usr/local/bin` by default. You can fix this by doing `mkdir /usr/local/bin`.
    - Homebrew installs *everything* in its own directory structure. If you're building things from source that rely on libraries from libvmaf, libjxl, etc, make sure to copy them from `/opt/homebrew/lib` to `/usr/local/lib`. Finding them is a matter of `ls | grep "keyword"` & copying what looks reasonable to be associated with the tool you're using.
    - Building most things from source will have instructions for \*nix which work for both macOS & Linux. Even if it says Linux, there's a good chance it'll work on macOS as well, & it is always worth trying Linux build instructions on Mac. aom-av1-lavish requires some additional steps, though.

    If you want to make the most out of your hardware & eke out every last drop of quality, it may be worth building aom-av1-lavish from source. The first step is to clone it from the Endless Merging branch, which contains all of the latest lavish improvements:
    ```bash
    git clone https://github.com/Clybius/aom-av1-lavish -b Endless_Merging
    cd aom-av1-lavish
    ```
    Now, you need to make some manual changes to the source code until [this commit](https://github.com/Clybius/aom-av1-lavish/pull/1/files) is merged to fix build errors.
    - Add the line `#include "aq_variance.h"` at line 19 in `av1/encoder/encodeframe_utils.c`
    - Comment out line 2546 in `av1/encoder/speed_features.c`. This line is `const int qindex_thresh_cdef_sf_s1_s3_l2[2] = { 92, 48 };` & becomes `// const int qindex_thresh_cdef_sf_s1_s3_l2[2] = { 92, 48 };`.

    Now you can continue to build according to the Linux instructions below. Obviously you'll need cmake, which you can install with homebrew along with any other tools. While still in the `aom-av1-lavish` directory:
    ```bash
    mkdir -p aom_build && cd aom_build
    cmake .. -DBUILD_SHARED_LIBS=0 -DENABLE_DOCS=0 -DCONFIG_TUNE_BUTTERAUGLI=0 -DCONFIG_TUNE_VMAF=0 -DCONFIG_AV1_DECODER=0 -DENABLE_TESTS=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS="-flto -O3 -march=native -pipe -fno-plt" -DCMAKE_LD_FLAGS="-flto -O3 -march=native"
    make -j$(nproc)
    # This may need to be run as root. If it doesn't work properly, you can always copy the binary into /usr/local/bin manually:
    make install
    ```

    Now you can run `aomenc --help | grep "AOMedia" -C 3` to see if lavish installed. If you're getting the same output as above, you may need to copy the `aomenc` executable to `/opt/local/bin`, `/usr/local/bin`, & `/opt/homebrew/bin` if you already installed mainline aomenc. Running the version info command again, the correct output should look something like this:
    ```bash
    % aomenc --help | grep AOMedia -C 3

    Included encoders:

        av1    - AOMedia Project AV1 Encoder Psy v3.6.0 (default)

            Use --codec to switch to a non-default encoder.
    ```

    Notice how it says `AOMedia Project AV1 Encoder Psy` instead of `AOMedia Project AV1 Encoder`. You should be all set after this to start using aom-av1-lavish.
    #### Windows

The pre-built Windows version linked by the original guide on September 6, 2023 is no longer available.

    Join the [AV1 Discord server](https://discord.gg/vpREHAvYvh) and head to #community-builds for updated versions, you can opt to compile it yourself with the instructions below.

    **The Compiling Route:**

    Full credits to u/Turbulent-Bend-7416 on Reddit for [this post](https://www.reddit.com/r/AV1/comments/s6eh5f/how_to_compile_av1_in_windows_without_crying) on how to compile aomenc.

    This guide requires **MSYS2**, specifically **MinGW-W64**. Install it if you haven't yet.

    First, install the required dependencies:

    ```bash
    pacman -S cmake git perl yasm nasm python3 doxygen mingw-w64-x86_64-gcc mingw-w64-x86_64-cmake base-devel
    ```

    Now, clone the aom-av1-lavish repo in the Endless_Merging branch and create the folders:

    ```bash
    git clone https://github.com/Clybius/aom-av1-lavish -b Endless_Merging
    cd aom-av1-lavish && mkdir -p aom_build && cd aom_build
    ```

    Then we can start compiling with some build optimizations for your CPU:

    ```bash
    cmake .. -DBUILD_SHARED_LIBS=0 -DENABLE_DOCS=0 -DCONFIG_TUNE_BUTTERAUGLI=0 -DCONFIG_TUNE_VMAF=0 -DCONFIG_AV1_DECODER=0 -DENABLE_TESTS=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS="-flto -O3 -march=native -pipe -fno-plt" -DCMAKE_LD_FLAGS="-flto -O3 -march=native"
    make -j$(nproc)
    ```

    The resulting binary will be available within your home folder of the location where you installed MSYS2 (usually `C:`), navigate there and the to the aom-av1-lavish folder and it should be there.

    Built files should be in the "Debug" folder

    Don't share binaries compiled with native CPU optimizations unless the person you're sharing to has the same CPU architecture, as this will lead to missing instructions being used and slowing down encode speeds.

## Usage

### AV1 Encoding

> **Note — The way aomenc was developed requires 2-pass to take full advantage of its efficiency which include better rate controls and encoding features. So always use 2 passes when encoding..**
>
>
```bash title="Simple Y4M input with CQ 22, 1 pass, and raw ivf bitstream output"
aomenc --end-usage=q --cq-level=32 --bit-depth=10 --passes=1 --ivf -o output.ivf input.y4m
```

```bash title="Pipe from FFmpeg"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | aomenc - --end-usage=q --cq-level=32 --bit-depth=10 --passes=1 --ivf -o output.ivf
```

```bash title="Pipe from FFmpeg, 2-pass, pass 1"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | aomenc - --end-usage=q --cq-level=32 --bit-depth=10 --passes=2 --pass=1 --fpf-log=aom-pass.log  --ivf -o output.ivf
```
```bash title="Pipe from FFmpeg, 2-pass, pass 2"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | aomenc - --end-usage=q --cq-level=32 --bit-depth=10 --passes=2 --pass=2 --fpf-log=aom-pass.log  --ivf -o output.ivf
```

### AVIF Encoding

Using aomenc through avifenc is widely considered to be the best way to encode AVIF images, as SVT-AV1 only supports 4:2:0 chroma subsampling, rav1e isn't fast enough for still images, & the libaom team have put more effort into intra coding than the teams responsible for producing the other prominent open source AV1 encoders. A sample command for encoding AVIF looks like this:

`avifenc -c aom -s 4 -j 8 -d 10 -y 444 --min 1 --max 63 -a end-usage=q -a cq-level=16 -a tune=ssim [input] output.avif`

Where:

- `-c aom` is the encoder
- `-s 4` is the speed. Speeds 4 & below offer the best compression quality at the expense of longer encode times.
- `-j 8` is the number of threads the encoder is allowed to use. Increasing this past 12 will sometimes hurt encode times, as AVIF encoding via aomenc doesn't parallelize perfectly. Test using a speed benchmark to verify which value works best for you.
- `-d 10` is the bit depth. Specifying a value below 10 isn't recommended, as it will hurt coding efficiency even with an 8-bit source image.
- `-y 444` is the chroma subsampling mode. 4:4:4 chroma subsampling tends to provide better compression than 4:2:0 with AVIF, though on some images 4:2:0 chroma subsampling might be the better choice.
- `cq-level=16` is how you specify quality. Lower values correspond to higher quality & filesize, while higher values mean a smaller, lower-quality output is desired. This is preceded by `-a` because it is an aomenc option, not an avifenc one.
- `tune=ssim` is how the encoder handles RDO (rate-distortion optimization). This may be redundant with the default aomenc parameters, but specifying doesn't hurt to avoid an unintended change if a default is modified sometime in the future.

## Recommendations

aomenc unfortunately lacks the ability to take advantage of multiple threads, so therefore a tool like [Av1an](/tools/utilities/av1an/) will be needed for parallelization. The parameters shown will be biased towards Av1an and aom-av1-lavish usage, so if you plan on using standalone aomenc then adjust as needed.

Here are some recommended parameters:

`--bit-depth=10 --cpu-used=4 --end-usage=q --cq-level=24 --threads=2 --tile-columns=0 --tile-rows=0 --lag-in-frames=64 --tune-content=psy --tune=ssim --enable-keyframe-filtering=1 --disable-kf --kf-max-dist=9999 --enable-qm=1 --deltaq-mode=0 --aq-mode=0 --quant-b-adapt=1 --enable-fwd-kf=0 --arnr-strength=1 --sb-size=dynamic --enable-dnl-denoising=0 --denoise-noise-level=8`

Now let's break it down.

- `--bit-depth=10` We're using 10bit because weird linear algebra allows the video to become smaller and reduces banding.

- `--cpu-used=4` This is the preset which ranges from 0-9, you can go to 3 if you want more efficiency, 2 if you have a lot of time, 4 is the sweet spot, and 6 if you want speed. Don't go above 6 (Worst efficiency) or even 0 (It would take WEEKS to finish).

- `--end-usage=q --cq-level=24` This specifies that we are going to use a knockoff version of CRF level similar to x264/x265 encoders, in this case CRF 24.

- `--tile-columns=0 --tile-rows=0` This is the tiles options, where the encoder splits the videos into tiles to encode faster. See the image below (Yellow lines):

<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/tiling_av1.avif?token=GHSAT0AAAAAACEZPDXIZARY5MGSTJW4SI22ZHY636A" type="image/avif" />
    <img src="https://autumn.revolt.chat/attachments/HwhZjoDsdzLZsJM2mjzX7lEDmJn1xcYNdrQqmOxPYW/tiling_av1.jpeg" alt="Tiling" loading="lazy" />
</picture>

> **Note — Tile usage.**
>
> Do NOT use tiles for 1080p and below, use 1 ``tile-columns`` at 1440p (2K), 2 ``tile-columns`` and 1 ``tile-rows`` for 2160p (4K).
>
> If you would like an easy way to calculate the necessary number of tiles for your video, you can use [the AV1 Encoding Calculator](https://autocompressor.net/tools/av1-calculator) online or run [this local tile calculator](https://github.com/gianni-rosato/av1-tile-calc).
- `--lag-in-frames=64` Similar to x264/x265 `rc-lookahead`. Sets a number of frames to look ahead for frametype and ratecontrol, allowing for better compression decision making. Setting to a value greater than 64 is generally not considered useful.

- `--aq-mode=0` adaptive quantization mode, a mostly debatable area nowadays. 0 is better most of the time but some say 1 is also good.

- `--tune-content=psy --tune=ssim` As the name suggests they are tunes that affect the video output, for the better, and for the worst.
> **Note — Do not use `tune-content=psy` if you encode live action above `cq-level=30`..**
>
>
> **Note — If you use any of the VMAF tunes, you need to specify `--vmaf-model-path=` to where you put VMAF models in..**
>
>
- `--enable-keyframe-filtering=1` We're setting it to 1 because of compatibility reasons, 2 is more efficient but there are seeking issues and FFmpeg can't input it.

- `--sb-size=dynamic` Allows the encoder to use 128x128 block partitioning besides 64x64 which gives an efficiency boost.

- `--deltaq-mode=0` set to 0 b its better

- `--arnr-strength=1` Controls how strong the filtering (smoothing) will be, always been a hot topic. Most agree on the default of 4. Others think 1 is good for 3D Pixar CGI-like and 2D animation and 4 for live action content, and a higher value for lower bitrate encodes.

- `--disable-kf --enable-fwd-kf=0` We're disabling keyframes cause Av1an already did scene detection, so we wont have to. Plus it speeds things up.

- `--kf-max-dist=9999` Maximum keyframe interval, we're setting it at the highest possible value since Av1an's scene detection keyframe interval is already 240 by default

- `--enable-chroma-deltaq=1` --enable-qm=1 --quant-b-adapt=1`` Parameters that give you free efficiency boost, ignore it.

- `--enable-dnl-denoising=0` Disables the encoder's built-in denoising technique when grain synthesis is enabled, you can optionally set it to 1 when you have a pretty noisy video since it works quite well (NLMeans is the denoiser used).

- `--denoise-noise-level=8` AV1 grain synthesis, which is a technique where the encoder puts fake grain in so it looks more natural and potentially hiding video artifacts (cause grain is hard to encode and explodes bitrate usage because of their randomness). Don't attempt to use it at high values (>12) since it creates noticeable grain patterns.

> **Note — You can use photon noise tables as an alternative via `--film-grain-table`, which is also conveniently available in Av1an as `--photon-noise=X`.**
>
>
## Tips & Tricks

1. Use ``--butteraugli-resize-factor=2`` if you use any of the butteraugli-based tunes to speed it up without much losses (lavish, butteraugli) and ``--butteraugli-intensity-target=250`` to match the content light level.
2. Use ``--arnr-maxframes`` to set max reference frames that will be used to filter the encode, higher values would make the video blurrier at high fidelity but look better at lower bitrates.


title: aom-psy101

text: FFmpeg

text: Installation

markdown:
# aom-psy101

> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
> **Note — Community Fork.**
>
> This entry is about a fork of aomenc called aom-psy101. If you'd like to learn about the mainline aomenc encoder before reading, visit our [aomenc wiki entry](/tools/software-encoders/aomenc/).
Mainline aomenc is unfortunately not perfect. It suffers from bad defaults, a heavy focus on the perceptually flawed [PSNR](/reference/metrics/psnr/) metric, misleading settings, and other issues. Fortunately, there are a couple of forks developed by the encoding community that were created to combat aomenc's underlying issues.

- [aom-av1-psy](https://github.com/BlueSwordM/aom-av1-psy) *No longer maintained as of 13th January 2023*
- [aom-av1-lavish](/tools/software-encoders/aom-av1-lavish/) *No longer maintained as of 4th June 2024*
- [aom-psy101](https://gitlab.com/damian101/aom-psy101)
- [aom-av1ador](https://github.com/porcino/aom-av1ador)

These forks fix up the poor decisions made by the original AOM devs and most importantly introduce new parameters and tunes to help fine-tune the encoder even more.

[aom-psy101](https://gitlab.com/damian101/aom-psy101) is a fork of aomenc that aims to improve the encoding quality and speed of AV1. It is developed by [damian101](https://gitlab.com/damian101), a talented AV1 community developer.

## FFmpeg

aomenc is available in FFmpeg via ``libaom-av1``, check if you have it by running ``ffmpeg -h encoder=libaom-av1``. You can input non-FFmpeg standard aomenc parameters via ``-aom-params``.

> **Caution — Mainline aomenc.**
>
> Unless you compile FFmpeg yourself with aom-psy101, you will be using the mainline aomenc. Compiling from source yourself with the aomenc libraries provided by aom-psy101 is the only way to use it with FFmpeg.
## Installation

    #### Linux & macOS

1. Clone the psy101 repo:
    ```bash title="Clone the psy101 repo"
    git clone https://gitlab.com/damian101/aom-psy101
    cd aom-psy101 && mkdir aom_build && cd aom_build
    ```

    2. Configure compilation. The following flags are set to ensure the `aomenc` binary is build for optimal performance:
    ```bash title="Set CMake flags"
    cmake .. -DBUILD_SHARED_LIBS=0 -DENABLE_DOCS=0 -DCONFIG_TUNE_BUTTERAUGLI=0 -DCONFIG_TUNE_VMAF=0 -DCONFIG_AV1_DECODER=0 -DENABLE_TESTS=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-flto -pipe -march=native" -DCMAKE_C_FLAGS="-flto -pipe -march=native"
    ```

    3. Compile:
    ```bash title="Compile"
    make -j$(nproc)
    ```

    4. Install to your system. This may require elevated privileges:
    ```bash title="Install"
    make install
    ```
    #### Windows

**MSYS2** is the best option for building in Windows, as it provides a Unix-like environment for compilation.

    0. Make sure you have downloaded & installed MSYS2 from [the MSYS2 website](https://www.msys2.org/) before beginning the build process.

    1. Close any MSYS2 Console that you have open, start the Clang64 console & install the required dependencies:
    ```bash
    pacman -S git perl mingw-w64-clang-x86_64-clang mingw-w64-clang-x86_64-ninja mingw-w64-clang-x86_64-cmake mingw-w64-clang-x86_64-nasm
    ```

    2. Clone the psy101 repo:
    ```bash title="Clone the psy101 repo"
    git clone https://gitlab.com/damian101/aom-psy101
    cd aom-psy101 && mkdir aom_build && cd aom_build
    ```

    2. Configure compilation. The following flags are set to ensure the `aomenc` binary is build for optimal performance:
    ```bash title="Set CMake flags"
    LDFLAGS=-static cmake .. -DBUILD_SHARED_LIBS=0 -DENABLE_DOCS=0 -DCONFIG_TUNE_BUTTERAUGLI=0 -DCONFIG_TUNE_VMAF=0 -DCONFIG_AV1_DECODER=0 -DENABLE_TESTS=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-flto -pipe -march=native" -DCMAKE_C_FLAGS="-flto -pipe -march=native"
    ```

    3. Compile:
    ```bash title="Compile"
    ninja
    ```

    The resulting binary will be available within the home folder of the location where you installed MSYS2 (usually `C:`). Navigate there, and then to `aom-psy101\aom_build` folder; the binary should be there.


title: aomenc

description: aomenc, AOM-AV1, or just libaom is a command line application for encoding AV1 written in C and Assembly developed by AOMedia, which is also the reference encoder for AV1.

text: aomenc

anchor: aomenc

text: FFmpeg

text: Supported Color Space

anchor: supported-color-space

text: Installation

text: Usage

text: AV1 Encoding

text: AVIF Encoding

text: Recommendations

text: Community Forks

anchor: community-forks

markdown:
# aomenc

[aomenc](https://aomedia.googlesource.com/aom/), AOM-AV1, or just **libaom** is a command line application for encoding AV1 written in C and Assembly developed by AOMedia, which is also the reference encoder for AV1.

## FFmpeg

aomenc is available in FFmpeg via ``libaom-av1``, check if you have it by running ``ffmpeg -h encoder=libaom-av1``. You can input non-FFmpeg standard aomenc parameters via ``-aom-params``.

## Supported Color Space

aomenc supports the following color spaces:

| Format           | Chroma Subsampling | Supported Bit Depth(s) |
|------------------|:------------------:|-----------------------|
| YUV420P          | 4:2:0              | 8-bit                 |
| YUV422P          | 4:2:2              | 8-bit                 |
| YUV444P          | 4:4:4              | 8-bit                 |
| GBRP             | -                  | 8-bit                 |
| GRAY8            | -                  | 8-bit                 |
| YUV420P10LE      | 4:2:0              | 10-bit                |
| YUV422P10LE      | 4:2:2              | 10-bit                |
| YUV444P10LE      | 4:4:4              | 10-bit                |
| GBRP10LE         | -                  | 10-bit                |
| GRAY10LE         | -                  | 10-bit                |
| YUV420P12LE      | 4:2:0              | 12-bit                |
| YUV422P12LE      | 4:2:2              | 12-bit                |
| YUV444P12LE      | 4:4:4              | 12-bit                |
| GBRP12LE         | -                  | 12-bit                |
| GRAY12LE         | -                  | 12-bit                |

## Installation

    #### Linux & macOS

1. Clone the mainline aom repo:
    ```bash title="Clone the aom repo"
    git clone https://aomedia.googlesource.com/aom
    cd aom && mkdir aom_build && cd aom_build
    ```

    2. Configure compilation. The following flags are set to ensure the `aomenc` binary is build for optimal performance:
    ```bash title="Set CMake flags"
    cmake .. -DBUILD_SHARED_LIBS=0 -DENABLE_DOCS=0 -DCONFIG_TUNE_BUTTERAUGLI=0 -DCONFIG_TUNE_VMAF=0 -DCONFIG_AV1_DECODER=0 -DENABLE_TESTS=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS="-flto -O3 -march=native -pipe -fno-plt" -DCMAKE_LD_FLAGS="-flto -O3 -march=native"
    ```

    3. Compile:
    ```bash title="Compile"
    make -j$(nproc)
    ```

    4. Install to your system. This may require elevated privileges:
    ```bash title="Install"
    make install
    ```
    #### Windows

**MSYS2** is the best option for building in Windows, as it provides a Unix-like environment for compilation.

    0. Make sure you have downloaded & installed MSYS2 from [the MSYS2 website](https://www.msys2.org/) before beginning the build process.

    1. Start the UCRT64 console & install the required dependencies:
    ```bash
    pacman -S cmake git perl yasm nasm python3 doxygen mingw-w64-x86_64-gcc mingw-w64-x86_64-cmake base-devel
    ```

    2. Clone the mainline aom repo:
    ```bash title="Clone the aom repo"
    git clone https://aomedia.googlesource.com/aom
    cd aom && mkdir aom_build && cd aom_build
    ```

    2. Configure compilation. The following flags are set to ensure the `aomenc` binary is build for optimal performance:
    ```bash title="Set CMake flags"
    cmake .. -DBUILD_SHARED_LIBS=0 -DENABLE_DOCS=0 -DCONFIG_TUNE_BUTTERAUGLI=0 -DCONFIG_TUNE_VMAF=0 -DCONFIG_AV1_DECODER=0 -DENABLE_TESTS=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS="-flto -O3 -march=native -pipe -fno-plt" -DCMAKE_LD_FLAGS="-flto -O3 -march=native"
    ```

    3. Compile:
    ```bash title="Compile"
    make -j$(nproc)
    ```

    The resulting binary will be available within the home folder of the location where you installed MSYS2 (usually `C:`). Navigate there, and then to the `aom` folder; the binary should be there.

    Built files should be in the "Debug" folder.

> **Caution — Sharing Native Binaries.**
>
> Avoid sharing binaries compiled with native CPU optimizations unless the person you're sharing to has the same CPU architecture, as this can lead to incorrect encoder behavior.
## Usage

### AV1 Encoding

> **Note — 2-Pass Encoding.**
>
> The way aomenc was developed requires 2-pass to take full advantage of its efficiency which include better rate controls and encoding features. So always specify the encoder to use 2 passes when encoding.
```bash title="Simple Y4M input with CQ 22, 1 pass, and raw ivf bitstream output"
aomenc --end-usage=q --cq-level=32 --bit-depth=10 --passes=1 --ivf -o output.ivf input.y4m
```

```bash title="Pipe from FFmpeg"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | aomenc - --end-usage=q --cq-level=32 --bit-depth=10 --passes=1 --ivf -o output.ivf
```

```bash title="Pipe from FFmpeg, 2-pass, pass 1"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | aomenc - --end-usage=q --cq-level=32 --bit-depth=10 --passes=2 --pass=1 --fpf-log=aom-pass.log  --ivf -o output.ivf
```
```bash title="Pipe from FFmpeg, 2-pass, pass 2"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | aomenc - --end-usage=q --cq-level=32 --bit-depth=10 --passes=2 --pass=2 --fpf-log=aom-pass.log  --ivf -o output.ivf
```

### AVIF Encoding

Using aomenc through avifenc is widely considered to be the best way to encode AVIF images, as SVT-AV1 only supports 4:2:0 chroma subsampling, rav1e isn't fast enough for still images, & the libaom team have put more effort into intra coding than the teams responsible for producing the other prominent open source AV1 encoders. A sample command for encoding AVIF looks like this:

`avifenc -c aom -s 4 -j 8 -d 10 -y 444 --min 1 --max 63 -a end-usage=q -a cq-level=16 -a tune=ssim [input] output.avif`

Where:

- `-c aom` is the encoder
- `-s 4` is the speed. Speeds 4 & below offer the best compression quality at the expense of longer encode times.
- `-j 8` is the number of threads the encoder is allowed to use. Increasing this past 12 will sometimes hurt encode times, as AVIF encoding via aomenc doesn't parallelize perfectly. Test using a speed benchmark to verify which value works best for you.
- `-d 10` is the bit depth. Specifying a value below 10 isn't recommended, as it will hurt coding efficiency even with an 8-bit source image.
- `-y 444` is the chroma subsampling mode. 4:4:4 chroma subsampling tends to provide better compression than 4:2:0 with AVIF, though on some images 4:2:0 chroma subsampling might be the better choice.
- `cq-level=16` is how you specify quality. Lower values correspond to higher quality & filesize, while higher values mean a smaller, lower-quality output is desired. This is preceded by `-a` because it is an aomenc option, not an avifenc one.
- `tune=ssim` is how the encoder handles RDO (rate-distortion optimization). This may be redundant with the default aomenc parameters, but specifying doesn't hurt to avoid an unintended change if a default is modified sometime in the future.

## Recommendations

aomenc is largely lacking in its ability to take advantage of multiple threads, so a tool like [Av1an](/tools/utilities/av1an/) should be utilized for effective parallelization. The parameters shown will be biased towards Av1an and [aom-av1-lavish](/tools/software-encoders/aom-av1-lavish/) usage, so if you plan on using standalone aomenc please adjust as needed.

Here are some recommended parameters:

`--bit-depth=10 --cpu-used=4 --end-usage=q --cq-level=24 --threads=2 --tile-columns=0 --tile-rows=0 --lag-in-frames=64 --tune=ssim --enable-keyframe-filtering=1 --disable-kf --kf-max-dist=9999 --enable-qm=1 --deltaq-mode=0 --aq-mode=0 --enable-fwd-kf=0 --arnr-strength=1 --sb-size=dynamic --enable-dnl-denoising=0 --denoise-noise-level=8`

Now let's break it down.

- `--bit-depth=10` We're using 10bit because weird linear algebra allows the video to become smaller and reduces banding.

- `--cpu-used=4` This is the preset which ranges from 0-9, you can go to 3 if you want more efficiency, 2 if you have a lot of time, 4 is the sweet spot, and 6 if you want speed. Don't go above 6 (Worst efficiency) or even 0 (It would take WEEKS to finish).

- `--end-usage=q --cq-level=24` This specifies that we are going to use a knockoff version of CRF level similar to x264/x265 encoders, in this case CRF 24.

- `--tile-columns=0 --tile-rows=0` This is the tiles options, where the encoder splits the videos into tiles to encode faster. See the image below (Yellow lines):

<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/tiling_av1.avif?token=GHSAT0AAAAAACEZPDXIZARY5MGSTJW4SI22ZHY636A" type="image/avif" />
    <img src="https://autumn.revolt.chat/attachments/HwhZjoDsdzLZsJM2mjzX7lEDmJn1xcYNdrQqmOxPYW/tiling_av1.jpeg" alt="Tiling" loading="lazy" />
</picture>

> **Note — Tile usage.**
>
> Do NOT use tiles for 1080p and below, use 1 ``tile-columns`` at 1440p (2K), 2 ``tile-columns`` and 1 ``tile-rows`` for 2160p (4K).
>
> If you would like an easy way to calculate the necessary number of tiles for your video, you can use [the AV1 Encoding Calculator](https://autocompressor.net/tools/av1-calculator) online or run [this local tile calculator](https://github.com/gianni-rosato/av1-tile-calc).
- `--lag-in-frames=64` Similar to x264/x265 `rc-lookahead`. Sets a number of frames to look ahead for frametype and ratecontrol, allowing for better compression decision making. Setting to a value greater than 64 is generally not considered useful.

- `--aq-mode=0` adaptive quantization mode, a mostly debatable area nowadays. 0 is better most of the time but some say 1 is also good.

- `--enable-keyframe-filtering=1` We're setting it to 1 because of compatibility reasons, 2 is more efficient but there are seeking issues and FFmpeg can't input it.

- `--sb-size=dynamic` Allows the encoder to use 128x128 block partitioning besides 64x64 which gives an efficiency boost.

- `--deltaq-mode=0` This value has been tested to be more perceptually efficient.

- `--arnr-strength=1` Controls how strong the filtering (smoothing) will be, always been a hot topic. Most agree on the default of 4. Others think 1 is good for 3D Pixar CGI-like and 2D animation and 4 for live action content, and a higher value for lower bitrate encodes.

- `--disable-kf --enable-fwd-kf=0` We're disabling keyframes cause Av1an already did scene detection, so we wont have to. Plus it speeds things up.

- `--kf-max-dist=9999` Maximum keyframe interval, we're setting it at the highest possible value since Av1an's scene detection keyframe interval is already 240 by default

- `--enable-chroma-deltaq=1 --enable-qm=1` Parameters that give you free efficiency boost discovered via testing.

- `--enable-dnl-denoising=0` Disables the encoder's built-in denoising technique when grain synthesis is enabled, you can optionally set it to 1 when you have a pretty noisy video since it works quite well (NLMeans is the denoiser used).

- `--denoise-noise-level=8` AV1 grain synthesis, which is a technique where the encoder puts fake grain in so it looks more natural and potentially hiding video artifacts (cause grain is hard to encode and explodes bitrate usage because of their randomness). Don't attempt to use it at high values (>12) since it creates noticeable grain patterns.

> **Note — You can use photon noise tables as an alternative via `--film-grain-table`, which is also conveniently available in Av1an as `--photon-noise=X`.**
>
>
## Community Forks

Mainline aomenc is unfortunately not perfect. It suffers from bad defaults, a heavy focus on the perceptually flawed [PSNR](/reference/metrics/psnr/) metric, misleading settings, and other issues. Fortunately, there are a couple of forks developed by the encoding community that were created to combat aomenc's underlying issues.

- [aom-av1-psy](https://github.com/BlueSwordM/aom-av1-psy) *No longer maintained as of 13th January 2023*
- [aom-av1-lavish](/tools/software-encoders/aom-av1-lavish/) *No longer maintained as of 4th June 2024*
- [aom-psy101](/tools/software-encoders/aom-psy101/)
- [aom-av1ador](https://github.com/porcino/aom-av1ador)

These forks fix up the poor decisions made by the original AOM devs and most importantly introduce new parameters and tunes to help fine-tune the encoder even more.


title: Aurora1

description: Aurora1 AV1 is a proprietary and paid software AV1 encoder developed by Visionular. Although they do provide a contact form to get a free trial, not much is known about this encoder.

text: Aurora1 AV1

markdown:
# Aurora1 AV1

[Aurora1 AV1](https://visionular.ai/aurora1-av1-encoder/) is a proprietary and paid software AV1 encoder developed by [Visionular](https://www.visionular.com/en). Although they do provide a contact form to get a free trial, not much is known about this encoder.


title: AVM

description: AVM is the reference software for next codec from Alliance for Open Media.

text: Rumors

anchor: rumors

text: Installation

anchor: installation

text: Arch Linux

text: Compiling

anchor: compiling

text: Usage

text: aomdec

anchor: aomdec

markdown:
> AVM (AOM Video Model) is the reference software for next codec from Alliance for Open Media.

[AVM](https://gitlab.com/AOMediaCodec/avm), or **A**OM **V**ideo **M**odel is the reference implementation for a future codec from the Alliance for Open Media, the organization behind [AV1](/codecs/video/av1/).
The codebase is under the Clear BSD license and currently only produces `av01` bitstreams.

The AVM codec is currently in development and is not yet ready for production use. Not much has been documented or tested.

## Rumors

Some things about the new encoding implementation can be confirmed via the codebase, but none of those changes are final until the codec is standardized and officially released.

Some rumors about the codec include:

- The name of the codec is going to be AV2, superseding AV1
- The codec will be based on AV1, with certain backwards compatibility features available
- Hardware decoding implementations could be implemented at no cost (no royalties) by utilizing GPU shaders and existing AV1 decoding hardware.
- AOM's strategy will be to release codecs "mid-cycle" relative to ISO/ITU's release schedule, meaning it is likely that "AV2" will compete with [VVC](/codecs/video/vvc/), not [ECM](/codecs/video/ecm/).
- A quantizer scale of 0-255 will be standard.
- AVM tries to address some issues with high-fidelity AV1 encoding by introducing a better denoiser to mitigate [mosquito noise](/start-here/video-artifacts/#mosquito-noise).

## Installation

### Arch Linux

AVM is available in the Arch User Repository (AUR) as `avm` and `avm-git`.

### Compiling

Since this encoder is under heavy development, there are no pre-built binaries provided, so you will need to compile yourself.
Windows users are recommended to compile via MinGW-W64 which comes with [MSYS2](https://msys2.org/).

> **Caution — Compilation requires CMake, Nasm, and Perl..**
>
>
```bash
git clone https://gitlab.com/AOMediaCodec/avm.git
cd avm/build
cmake .. -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=0
make -j$(nproc)
```

Since this is a huge project, compiling will take a while depending on your CPU.

The resulting binary will be called `aomenc`, the same name that encodes content to AV1.
It will be available in the same folder (`build`), or you can run `make install` on Linux to install (May need elevated permissions).

## Usage

> **Tip — To convert `cq-level` in aomenc and `crf` in SVT-AV1 to AVM's QP values, multiply by 4. For example, `--cq-level 20` equals to `--quantizer 60`..**
>
>
Simple Y4M input with QP 65, and `ivf` output:
```bash
aomenc --qp=65 -o output.ivf input.y4m
```

Preset level 6 (higher is faster), QP 65, Y4M input:
```bash
aomenc --qp=65 --cpu-used=6 -o output.ivf input.y4m
```

FFmpeg piping:
```bash
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | aomenc --qp=65 --cpu-used=6 -o output.ivf -
```

## aomdec

You will need the `aomdec` binary you also compiled to be able to play your encoded video, as there are **zero** video players currently in the whole world that can play your encoded content.


title: Eve-AV1

description: Eve-AV1 is a proprietary AV1 video encoder developed by Two Orioles, LLC, an organization primarily known for their work on dav1d, the most widely used AV1 software decoder.

text: Performance

anchor: performance

markdown:
Eve-AV1 is a proprietary [AV1](/codecs/video/av1/) video encoder developed by Two Orioles, LLC, an organization primarily known for their work on [dav1d](/tools/utilities/dav1d/), the most widely used AV1 software decoder.

According to the Two Orioles [webpage on Eve-AV1](https://www.twoorioles.com/eve-av1):

> Eve-AV1 gives you an unprecedented level of video quality for streaming on-demand video. It provides a 20% reduction in bitrate at the same visual quality compared to other AV1 encoders. Or you can choose a 3 to 5 times speedup in encoding time

A single visual comparison is provided, alongside BD-rate graphs for [VMAF](/reference/metrics/vmaf/).

## Performance

![Eve-AV1 VMAF performance](/img/eve_av1_speed.webp)

Eve-AV1 appears to perform quite well according to VMAF, and is able to do so at what appear to be impressive speeds. However, without more detailed visual comparisons, it is hard to take this data at face value.


title: Eve-VP9

description: Eve-VP9 is a proprietary VP9 video encoder developed by Two Orioles, LLC, an organization primarily known for their work on dav1d, the most widely used AV1 software decoder.

text: Performance

markdown:
Eve-VP9 is a proprietary [VP9](/codecs/video/vp9/) video encoder developed by Two Orioles, LLC, an organization primarily known for their work on [dav1d](/tools/utilities/dav1d/), the most widely used AV1 software decoder.

According to the Two Orioles [webpage on Eve-VP9](https://www.twoorioles.com/eve-vp9):

> At top quality, EVE-VP9 provides nearly 20% better compression than libvpx at the same speed; 10% better compression than x265 at 50% faster speed; and compared to x264, EVE-VP9 is nearly 40% better.

Sparse visual comparisons and BD-rate graphs for VMAF are provided by the company, but no further details are available.

## Performance

![Eve-VP9 VMAF performance](/img/eve_vp9_speed.webp)

Eve-VP9 appears to perform quite well according to VMAF, and is able to do so at what appear to be impressive speeds. However, without more detailed visual comparisons, it is hard to take this data at face value.


title: HM

description: HM is the original H.265 reference encoder, predating alternatives like x265. In the modern day, it joins other MPEG reference encoders such as JM & VTM in their reputations for being highly niche offerings that are used

text: Installation

text: Usage

markdown:
> **Caution — Pending Review.**
>
> The content in this entry may not be entirely accurate, & is pending further review to assess the quality of the information.
HM is the original [H.265](/codecs/video/hevc/) reference encoder, predating alternatives like [x265](/tools/software-encoders/x265/). In the modern day, it joins other MPEG reference encoders such as [JM](/tools/software-encoders/jm/) & [VTM](/tools/software-encoders/vtm/) in their reputations for being highly niche offerings that are used rarely due to their usage complexity & speed disadvantages. x264 is more efficient than JM.

HM is capable of producing higher quality streams than highly tuned x265, even at excruciatingly slow speeds. This is only a theoretical advantage, though, as HM is incapable of placing keyframes automatically with scene detection & would need a chunking too reminiscent of [Av1an](/tools/utilities/av1an/) to do this. For videos containing few enough frames where keyframe placement isn't a concern, HM is better in practice than x265 at the expense of a massive dropoff in speed. HM doesn't have any threading capabilities & is much slower than even x265 placebo.

## Installation

These build instructions are valid for Linux & macOS.

```bash
git clone https://vcgit.hhi.fraunhofer.de/jvet/HM
cd HM/
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
```

The binary `TAppEncoderStatic` or `TAppEncoder` can be found within the cloned directories, & can be copied to `/usr/local/bin` for encoding. Decoding & other functions of the reference codec implementation aren't covered in this entry.

## Usage

Here is a sample command: `TAppEncoderStatic -i input.yuv -b out.265 -c ~/HM/cfg/encoder_randomaccess_main10.cfg -wdt 1280 -hgt 720 -fr 50 -f 500 -q 27 -xPS 0`

Make sure only to use only YUV input when encoding with HM. Each parameter does the following:

- `-i input.yuv -b out.265`

Specifies a raw YUV input file & an output raw h265 bitstream. To mux into an MP4 container, it is recommended that you use [mp4box](/tools/utilities/mp4box/) instead of muxing with [FFmpeg](/tools/utilities/ffmpeg/).

- `-c [path/to/config]`

Specifies the desired path to your HM configuration file. This makes it easier to encode without having to manually specify a plethora of settings.

- `-wdt 1280 -hgt 720`

Sets the input & output width & height.

- `-fr 50 -f 500`

Sets the framerate (FPS) & the number of frames to encode. In this case, we are encoding 500 frames of a video that is to be played back at 50fps.

- `-q 27`

Sets a quality target for the encoder.

- `-xPS 0`

Zero clue what this does. If someone has an idea, please contribute!


title: JM

description: JM is the original H.264 reference encoder, predating alternatives like x264. Since x264 became highly performant and perceptually driven, it joins other MPEG reference encoders such as HM & VTM in their reputations for

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!
JM is the original [H.264](/codecs/video/avc/) reference encoder, predating alternatives like [x264](/tools/software-encoders/x264/). Since x264 became highly performant and perceptually driven, it joins other MPEG reference encoders such as [HM](/tools/software-encoders/hm/) & [VTM](/tools/software-encoders/vtm/) in their reputations for being highly niche offerings that are used rarely due to their usage complexity & speed disadvantages. x264 is generally more efficient than JM.


title: Kvazaar

description: Kvazaar is an open-source H.265 / HEVC software encoder Written in C, developed by Ultra Video Group and licensed under BSD 3-clause.

text: Kvazaar

anchor: kvazaar

text: FFmpeg

text: Supported Color Space

text: Installation

text: Usage

markdown:
# Kvazaar

[Kvazaar](https://github.com/ultravideo/kvazaar) is an open-source [H.265 / HEVC](/codecs/video/hevc/) software encoder Written in C, developed by [Ultra Video Group](https://ultravideo.fi/) and licensed under BSD 3-clause.

[uvg266](/tools/software-encoders/uvg266/) (Developed by the same group) uses Kvazaar as a base for encoding to the [VVC](/codecs/video/vvc/) codec.

[x265](/tools/software-encoders/x265/) is generally regarded as having better performance while producing better quality video streams.

## FFmpeg

Kvazaar is available in [FFmpeg](/tools/utilities/ffmpeg/) via ``libkvazaar``, to check if you have it, run ``ffmpeg -h encoder=libkvazaar``. You can input non-FFmpeg standard Kvazaar parameters via ``-kvazaar-params``.

You may need to download "Full" builds. As most of the time, this encoder is not included.

## Supported Color Space

Kvazaar supports the following color spaces:

| Format           | Chroma Subsampling | Supported Bit Depth(s)|
|------------------|:------------------:|-----------------------|
| YUV420P          | 4:2:0              | 8-bit                 |
| YUV420P10LE      | 4:2:0              | 10-bit*               |

*10-bit support requires a flag to be set during compilation with CMake.

## Installation

    #### Linux & macOS

For Arch Linux, Kvazaar is available as `kvazaar`. It is also available in the Arch User Repository (AUR) as `kvazaar-git`.

    Ultra Video Group does not ship any pre-built binaries of their encoders except for their [AppVeyor CI](https://ci.appveyor.com/project/Ultravideo/kvazaar), but AppVeyor deletes build artifacts after a month, so most of the time you'll have to compile Kvazaar yourself. Here are the instructions to do so:

    ### Autotools

    0. Compilation requires GNU Automake, Autoconf, Libtool, and M4. Install them via your package manager.

    1. Clone the repository and its submodules:
    ```bash
    git clone --recursive https://github.com/ultravideo/kvazaar.git
    cd kvazaar
    ./autogen.sh
    ./configure
    make -j$(nproc)
    ```

    3. Binaries will be available in `src`, or you can run `make install` on Linux to install (May need elevated permissions).

    ### CMake (10-bit support)

    You will need to use CMake to specify a flag to be able to encode 10-bit with the encoder; by default Kvazaar ships with only 8-bit.

    ```bash
    git clone --recursive https://github.com/ultravideo/kvazaar.git
    cd kvazaar/build
    cmake .. -DCMAKE_C_FLAGS="-DKVZ_BIT_DEPTH=10" # optional 10-bit flag
    make -j$(nproc)
    ```

    Be aware that encoding 10-bit HEVC with Kvazaar is significantly slower, as the developers only prioritized SIMD optimizations for 8-bit encoding. Be aware that this implementation can be buggy in general.
    #### Windows

Windows users are recommended to compile via MinGW-W64 which comes with [MSYS2](https://msys2.org/). Please be advised **the usage of Clang for compiling in this situation is heavily recommended**
    due to disabled AVX2 optimizations because of a known GCC issue from 2012 (MinGW environments-exclusive). To do this, run `CC=clang ./configure` during autoconf.

    ### MSYS2

    0. Make sure you have downloaded & installed MSYS2 from [the MSYS2 website](https://www.msys2.org/) before beginning the build process.

    1. Start the UCRT64 console & install the required dependencies with the `pacman` package manager

    3. Resume the build process as you would on a Unix-like system. See the "Linux & macOS" tab for more information.

## Usage

Here are some examples of how to use Kvazaar on its own:

```bash title="Simple Y4M input with QP 20 and raw 265 bitstream output"
kvazaar -i input.y4m --input-file-format y4m --qp 20 -o output.265
```

```bash title="Preset slow, CRF 20, Y4M input"
kvazaar -i input.y4m --input-file-format y4m --qp 20 --preset slow -o output.265
```

The command below still uses the `kvazaar` binary, but reads from a YUV4MPEG pipe instead of a file. This is useful for piping FFmpeg output to Kvazaar.

```bash title="FFmpeg piping"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | kvazaar -i - --input-file-format y4m --qp 20 --preset slow -o output.265
```


title: rav1e

description: rav1e is an open source command line application for encoding AV1 written in Assembly & Rust, co-developed by Xiph.org and Mozilla and licensed under BSD-2 Clause.

text: FFmpeg

text: Supported Color Space

text: Installation

text: Usage

text: Tips & Tricks

markdown:
# rav1e

[rav1e](https://github.com/xiph/rav1e) is an open source command line application for encoding AV1 written in Assembly & Rust, co-developed by Xiph.org and Mozilla and licensed under BSD-2 Clause.

## FFmpeg

rav1e is available in FFmpeg via `librav1e`, to check if you have it, run `ffmpeg -h encoder=librav1e`. You can input non-FFmpeg standard rav1e parameters via `-rav1e-params`.

## Supported Color Space

rav1e supports the following color spaces:

| Format           | Chroma Subsampling | Supported Bit Depth(s) |
|------------------|:------------------:|-----------------------|
| YUV420P          | 4:2:0              | 8-bit                 |
| YUVJ420P         | 4:2:0              | 8-bit (Full range)    |
| YUV422P          | 4:2:2              | 8-bit                 |
| YUVJ422P         | 4:2:2              | 8-bit (Full range)    |
| YUV444P          | 4:4:4              | 8-bit                 |
| YUVJ444P         | 4:4:4              | 8-bit (Full range)    |
| YUV420P10LE      | 4:2:0              | 10-bit                |
| YUV422P10LE      | 4:2:2              | 10-bit                |
| YUV444P10LE      | 4:4:4              | 10-bit                |
| YUV420P12LE      | 4:2:0              | 12-bit                |
| YUV422P12LE      | 4:2:2              | 12-bit                |
| YUV444P12LE      | 4:4:4              | 12-bit                |

## Installation

    #### Linux & macOS

Official pre-built rav1e binaries can be found on the [releases page](https://github.com/xiph/rav1e/releases) in rav1e's Github repository. Unofficially, the [rAV1ator CLI](/tools/utilities/rav1ator-cli/) command line tool can automatically download and install rav1e to `/usr/local/bin`. rav1e can also be installed with Cargo by running `cargo install rav1e`.

> **Info — Stable Release.**
>
> For stability & a proper version number, please reset the source to the correct release commit. In the releases page, click the icon to the right of the release tag & copy the commit in the url bar. Then, in the cloned rav1e directory, `git reset --hard [commit hash]`
    Here are instructions for resetting to release 0.7.1 (latest as of 19 Feb 2024) and building. Omit the `git reset` command to use the latest git, if you have a *specific* reason to use the latest git instead of an official tagged release.

    ```bash
    git clone https://github.com/xiph/rav1e.git
    cd rav1e
    git reset --hard a8d05d0c43826a465b60dbadd0ab7f1327d75371
    RUSTFLAGS="-C target-cpu=native" cargo build --release
    ```

    When done, the binary can be found in `/target/release`. You can then copy the binary wherever you desire it to go, like by doing `cp /target/release/rav1e /usr/local/bin` .

    ### Patched Installation with HDR10+ support

    rav1e currently has an [unmerged pull request](https://github.com/xiph/rav1e/pull/3000) by quietvoid, the person behind [hdr10plus_tool](/tools/utilities/hdr10plus_tool/) and [dovi_tool](/tools/utilities/dovi_tool/). The PR adds a new parameter called `--hdr10plus-json` for HDR10+ JSON dynamic metadata input. To merge it locally, do the following:

    ```bash
    git clone https://github.com/xiph/rav1e.git
    cd rav1e
    git reset --hard [release commit]
    git fetch origin pull/3000/head:HDR10+
    ```
    Now the patch should be applied, and you may build as usual.
    #### Windows

If you would not like to build from source, official pre-built rav1e binaries can be found on the [releases page](https://github.com/xiph/rav1e/releases) in rav1e's Github repository.

> **Info — Stable Release.**
>
> For stability & a proper version number, please reset the source to the correct release commit. In the releases page, click the icon to the right of the release tag & copy the commit in the url bar. Then, in the cloned rav1e directory, `git reset --hard [commit hash]`
    Here are instructions for resetting to release 0.7.1 (latest as of 19 Feb 2024) and building. Omit the `git reset` command to use the latest git, if you have a *specific* reason to use the latest git instead of an official tagged release.

    ```powershell
    git clone https://github.com/xiph/rav1e.git
    cd rav1e
    git reset --hard a8d05d0c43826a465b60dbadd0ab7f1327d75371
    set RUSTFLAGS=-C target-cpu=native
    cargo build --release
    ```
    When done, the binary can be found in `target/release`

## Usage

For AV1 encoding, rav1e has very sane defaults. It is very hard to go wrong with parameters if you modify as few as possible.

> **Tip — To convert `cq-level` in aomenc and `crf` in SVT-AV1 to rav1e's quantizer values, multiply by 4. For example, `--cq-level 20` equals to `--quantizer 80`..**
>
>
```bash title="Basic usage"
rav1e -i input.y4m -o output.ivf --quantizer 60 --photon-noise 8
```

```bash title="Basic usage with FFmpeg piping, 10bit input"
ffmpeg -i input.mkv -pix_fmt yuv420p10le -strict -2 -f yuv4mpegpipe - | rav1e - -o output.ivf --quantizer 80 --photon-noise 8
```

```bash title="Basic usage with FFmpeg piping, 10bit input and assuming 4K"
ffmpeg -i input.mkv -pix_fmt yuv420p10le -strict -2 -f yuv4mpegpipe - | rav1e - -o output.ivf --quantizer 68 --tile-columns 2 --tile-rows 1 --photon-noise 8
```

## Tips & Tricks

1. Use 2x1 tiles or `tile-columns 2` and `tile-rows 1` for 4K (2160p) encoding, this will help with both encoding and decoding speeds.


title: SVT-AV1

description: SVT-AV1 is an AV1-compliant software encoder/decoder library. Jointly developed by Intel and Netflix, SVT-AV1 is written almost entirely in C with some parts written in C++ and Assembly. As the name suggests, it is part

text: FFmpeg

text: Supported Color Space

text: Installation

text: Encoding

anchor: encoding

text: Strengths

anchor: strengths

text: Weaknesses

anchor: weaknesses

text: Encoder Optimization

anchor: encoder-optimization

text: Community Forks

markdown:
# SVT-AV1

> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
SVT-AV1 (Scalable Video Technology for AV1) is an AV1-compliant software encoder/decoder library. Jointly developed by Intel and Netflix, SVT-AV1 is written almost entirely in C with some parts written in C++ and Assembly. As the name suggests, it is part of the "[Scalable Video Technology](https://www.intel.com/content/www/us/en/developer/articles/technical/scalable-video-technology.html)" project lineup by Intel.

This entry discusses the SVT-AV1 encoder, also known as the "Production" AV1 encoder (while [aomenc](/tools/software-encoders/aomenc/) is the "reference" AV1 encoder), & refers to SVT-AV1 as such. SVT-AV1 is known for its parallelization, high coding efficiency, & active development. SVT-AV1 scales across multiple CPU cores much more effectively than aomenc or [rav1e](/tools/software-encoders/rav1e/), so the use of tools like [Av1an](/tools/utilities/av1an/) is less helpful albeit still helpful for scene detection.

## FFmpeg

SVT-AV1 is available in FFmpeg via `libsvtav1`, to check if you have it, run `ffmpeg -h encoder=libsvtav1`. You can input non-FFmpeg standard SVT-AV1 parameters via `-svtav1-params`.

## Supported Color Space

SVT-AV1 supports the following color spaces:

| Format           | Chroma Subsampling | Supported Bit Depth(s) |
|------------------|:------------------:|-----------------------|
| YUV420P          | 4:2:0              | 8-bit                 |
| YUV420P10LE      | 4:2:0              | 10-bit                |

## Installation

    #### Linux & macOS

*A precompiled AVX2-optimized binary of SVT-AV1-PSY can be installed for x86_64 Linux via [rAV1ator CLI](/tools/utilities/rav1ator-cli/). However, it is always recommended to build from source.*

    To build SVT-AV1 from source, first clone the desired SVT-AV1 repository & enter the build directory.

    ```bash title="Clone mainline SVT-AV1"
    git clone https://gitlab.com/AOMediaCodec/SVT-AV1/
    git reset --hard bbcff785881b320f7e1b1f77a2f5ed025f8bfd75 # Reset to release 2.1.0
    cd SVT-AV1/Build/linux
    ```

    ```bash title="Clone SVT-AV1-PSY"
    git clone https://github.com/gianni-rosato/svt-av1-psy
    cd SVT-AV1/Build/linux
    ```

    In the directory, simply run `./build.sh [flags]` to build. Be aware that building requires CMake version 3.16 or higher and either GCC or Clang. It is recommended to use clang when building SVT-AV1.

    ```bash title="Build release"
    ./build.sh release
    ```

    ```bash title="Statically build just the encoder with clang and enable link-time optimization"
    ./build.sh jobs=8 all cc=clang cxx=clang++ no-dec enable-lto static native
    ```

    The compiled binaries will be in the `Bin/Release` directory, including SvtAv1EncApp. If you just want the encoder, adding the `no-dec` flag will skip building SvtAv1DecApp and save on compilation time.

    If you want extra performance, it is possible to build SVT-AV1 using PGO (Profile-guided Optimization). **Be aware that this particular script infers that you have a .y4m file (or multiple) in `/dev/shm` for transcoding**. You can compile statically linked SVT-AV1 with PGO (and LTO, or link-time optimization) by following this script:

    ```bash title="Bulding SVT-AV1 with profile guided optimization"
    git clone https://gitlab.com/AOMediaCodec/SVT-AV1/
    cd SVT-AV1/Build/linux
    ./build.sh cc=gcc cxx=g++ enable-lto enable-pgo static native jobs=$(nproc) pgo-dir=/dev/shm pgo-videos=/dev/shm release
    ```

    If you wish to store videos elsewhere or provide custom parameters to the SvtAv1EncApp binary, try this script:

    ```bash
    git clone https://gitlab.com/AOMediaCodec/SVT-AV1/
    cd SVT-AV1/Build/linux
    ./build.sh cc=gcc cxx=g++ enable-lto enable-pgo static native jobs=$(nproc) pgo-dir=/dev/shm pgo-compile-gen release
    ../../Bin/Release/SvtAv1EncApp # Run this binary as many times as you'd like with arguments of your choice to collect data
    ./build.sh cc=gcc cxx=g++ enable-lto enable-pgo static native jobs=$(nproc) pgo-dir=/dev/shm pgo-compile-use release
    ```
    #### Windows

To be filled. If you believe you can help, see our [Contribution Guide](/reference/legacy/contribution-guide/).

## Encoding

### Strengths

SVT-AV1's greatest strength is its parallelization capability, where it outclasses other AV1 encoders by a significant margin. SVT-AV1's parallelization techniques do not involve tiling & don't harm video quality, & can comfortably utilize up to 16 cores given 1080p source video. This is while maintaining competitive coding efficiency to mainline aomenc. Perceptually, mainline SVT-AV1 is outperformed by well-tuned community forks of aomenc, but according to many the gap has begun to close with the introduction of SVT-AV1-PSY.

### Weaknesses

SVT-AV1 is strongest on x86 CPUs, & while ARM NEON assembly is [available](https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/ba13fac241f1b54954935f2cb200efc07f3de13a) and has been slowly improving since its introduction in version 1.8.0, SVT-AV1 still underperforms on ARM. For this reason, it is not a good cross-architecture CPU benchmark. SVT-AV1's support for various AV1 features is also limited; it only supports up to 4:2:0 chroma subsampling with no support for 12-bit color, and it does not support scene change detection (there are no plans to implement this, either). The smallest possible video that SVT-AV1 can produce is 64x64.

### Encoder Optimization

Aside from build optimizations for speed, there is further tweaking to be done to the `SvtAv1EncApp` binary parameters when encoding. The following applies to mainline SVT-AV1, but does not apply to SVT-AV1-PSY.

- `--film-grain` & `--film-grain-denoise`

Most live-action sources feature hard-to-compress digital noise that is easily smoothed out by AV1 compression. To add this grain back, or even denoise through the encoder and then add grain, it is possible to use the `--film-grain` parameter to specify an amount of film grain to add to the encode (& `--film-grain-denoise` to specify how to denoise the input video before encoding for potentially better appeal). Denoising a video always removes fine details, so sticking with just `--film-grain` is recommended in most cases. According to [SVT-AV1 documentation](https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.mdx#practical-advice-on-grain-synthesis), a level of 8 should be used for live-action content with a normal amount of grain while a level of 4 works well for hand-drawn animation or other smoother-looking sources that still stand to benefit from some grain synthesis.

- `--input-depth 10`

10-bit output from AV1 encoding is always desirable for coding efficiency, even if your source is 8-bit. This option only produces a 10-bit AV1 bitstream if the source provided to the encoder is 10-bit.

- `--tune 2`

There are three tunes in mainline SVT-AV1: Tune 1 is for [PSNR](/reference/metrics/psnr/) [RDO](/start-here/psychovisual/), Tune 2 is for [SSIM](/reference/metrics/ssim/) RDO, & Tune 0 is a [psychovisual](/start-here/psychovisual/) tune labeled VQ. It has been common practice to lean away from the PSNR tune, as it is not designed for visual quality but rather to perform better on the PSNR metric which is widely considered to be inconsistent with our human perception of fidelity. Using the VQ tune is a safe bet for now, but many believe the newer SSIM tune provides better visual fidelity. Using SVT-AV1-PSY, the custom Subjective SSIM tune (Tune 3) provides the best of both Tune 2 & Tune 0 with additional improvements as well.

- `--enable-qm 1`

Enables quantization matrices, disabled by default. Improves coding efficiency mainly by improving encoding speed while producing similar quality video.

- `--qm-min 0`

Sets the minimum flatness of quantization matrices to 0, down from the default 8. This is recommended unless you are dealing with extremely heavy grain. The maximum quantization matrix flatness is 15 by default, and should be left alone

- `--keyint [FPS*10]`

Similar to `--kf-max-dist` in [vpxenc](/tools/software-encoders/vpxenc/), this tells the encoder when to place keyframes. Because SVT-AV1 doesn't have scene detection, this isn't the maximum distance between keyframes, but rather a fixed interval for placing keyframes. If using Av1an, set to -1 to disable keyframe insertion as Av1an handles that instead.

- `--irefresh-type 2`

Intra refresh is specified through this option, & lets the user decide between Closed GOP & Open GOP. GOP stands for Group of Pictures. Open GOP allows GOPs to [reference one another](https://ottverse.com/closed-gop-open-gop-idr/), but support for this feature is currently incomplete. Therefore, it is recommended to use Closed GOP for the time being via `--irefresh-type 2` until this is rectified.

- `--preset X`

SVT-AV1 can be used in 14 different presets, labeled -1 through 13. Preset -1 is the slowest, but provides the best coding efficiency; it is also dubbed a research preset that is not recommended for regular use. Preset 13 is the fastest, and is also not recommended for regular use as it makes serious trade-offs to achieve unrealistically fast speeds at the cost of the encoder's coding efficiency. Using presets 2 through 8 is the best course of action for non-realtime applications if you desire reasonable speed, while 9 through 12 are useful for real-time encoding at 1080p or lower, even on low-end consumer computer hardware.

- `--crf X`

CRF is the best way to target quality for optimal visual fidelity. VBR & CBR lose efficiency due to their inherently limited rate control capabilities.

## Community Forks

Currently, there is only one noteworthy community fork of SVT-AV1 called [SVT-AV1-PSY](/tools/software-encoders/svt-av1-psy/).

### SVT-AV1-PSY

SVT-AV1-PSY is a community fork of SVT-AV1 that strives to improve the perceptual fidelity and quality of life provided by the encoder. The goal of this project is to create the best encoding implementation for perceptual quality with AV1, and it aims to surpass previous community forks of [aomenc](/tools/software-encoders/aomenc/#community-forks) in speed and visual quality.

SVT-AV1-PSY has a number of feature additions to the mainline SVT-AV1 encoder as well as modified defaults that aim to make it easier to produce a more perceptually optimal bistream. For a full list of the encoder's feature additions and modifications to defaults, see the [project's README](https://github.com/gianni-rosato/svt-av1-psy/blob/master/README.md#feature-additions).