title: SVT-AV1-PSY

text: Micro-Release Framework

anchor: micro-release-framework

text: Feature Additions

anchor: feature-additions

text: Installation

text: Projects Featuring SVT-AV1-PSY

text: License

anchor: license

markdown:
# SVT-AV1-PSY

> **Note — Community Fork.**
>
> This entry is about a fork of SVT-AV1 called SVT-AV1-PSY. If you'd like to learn about the mainline SVT-AV1 encoder before reading, visit our [SVT-AV1 wiki entry](/tools/software-encoders/svt-av1/).
SVT-AV1-PSY is a project that aims to enhance the Scalable Video Technology for AV1 Encoder with perceptual enhancements for psychovisually optimal AV1 encoding. The ultimate goal is to create the best encoding implementation for perceptual quality with AV1. The development of this project involves a collaborative effort from a team of dedicated developers and contributors who are committed to improving the encoder's [psychovisual](/start-here/psychovisual/) quality.

The SVT-AV1-PSY project is maintained by [Gianni Rosato](https://github.com/gianni-rosato), [Julio Barba](https://github.com/juliobbv), & [Clybius](https://github.com/Clybius), as well as a number of community contributors including [BlueSwordM](https://github.com/BlueSwordM), the maintainer of the [SVT-AV1-PSY AUR package](https://aur.archlinux.org/packages/svt-av1-psy-git) & the original author of [aom-av1-psy](https://github.com/BlueSwordM/aom-av1-psy).

The development process involves community testing and optimization to ensure that the encoder and decoder deliver optimal performance. The team uses a variety of tools and methodologies to analyze and improve the performance of the encoder and decoder, including subjective analyses. [SSIMULACRA2](/reference/metrics/ssimulacra2/) and [XPSNR](/reference/metrics/xpsnr/) are used extensively for metrics testing, and the team is committed to improving the overall quality and performance of the encoder using these two metrics as general guidelines and benchmarks. However, the stated goal is not to improve metric scores but to improve the overall perceptual quality of the encoder; naturally, changes are often made to SVT-AV1-PSY that end up degrading metric performance in favor of perceptual fidelity per bit.

If you are interested in reading more about the project, you can visit [the project's website](https://svt-av1-psy.com/) for more information. The repository was archived by the owner on Apr 30, 2025. It is now read-only and the author has officially [announced](https://github.com/psy-ex/svt-av1-psy/blob/master/README.md) the end of SVT-AV1-PSY. A fork of the project, [svt-av1-psyex](https://github.com/BlueSwordM/svt-av1-psyex) developed by previous contributor BlueSwordM, was also mentioned by the author in the same announcement.

SVT-AV1-PSY contributors are not in any way affiliated with the Alliance for Open Media or any upstream SVT-AV1 project contributors who have not also contributed to the SVT-AV1-PSY project.

## Micro-Release Framework

SVT-AV1-PSY features additions outside of mainline SVT-AV1 that are often considered to be significant, but don't line up with a major mainline release. Therefore, the SVT-AV1-PSY release framework is different, and the encoder is currently being developed around micro-releases to make this clear.

Micro-releases are tagged with letters starting at `A` to indicate that they contain significant new features and aren't equivalent to mainline releases; for example, `v2.0.0-A` was a micro-release with significant new features exclusive to SVT-AV1-PSY that followed the prior `v2.0.0` release (which came out with PSY + mainline features in tandem with mainline `v2.0.0`). Releases without letters are in-line with mainline SVT-AV1 releases, and may contain significant PSY feature additions as well.

## Feature Additions

SVT-AV1-PSY includes a number of new features that are not present in mainline SVT-AV1. These features are designed to improve the visual quality of AV1 encodes, and offer more flexibility when configuring the encoder for a wide range of encoding scenarios. Many of these changes are being integrated into mainline SVT-AV1 as the project matures.

The full suite of changes can be found in the [SVT-AV1-PSY README](https://github.com/gianni-rosato/svt-av1-psy/blob/master/README.md).

## Installation

Building & installing SVT-AV1-PSY is the same as building & installing mainline SVT-AV1.

    #### 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 SVT-AV1-PSY"
    git clone https://github.com/gianni-rosato/svt-av1-psy
    cd svt-av1-psy/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.

    ```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

**Clang** is the best option for building in Windows, as it results in faster binaries than building with MSYS2 (either GCC/Clang) and MSVC.

    > **Important**: All steps below are for **PowerShell**, **not** Command Prompt, but you can use Command Prompt as long as you change the `$env` command to the Command Prompt equivalent.

    0. Make sure you have the following prerequisites before beginning the build process:
    - [LLVM](https://github.com/llvm/llvm-project/releases/latest)
    - [Microsoft C++ Build Tools](https://visualstudio.microsoft.com/visual-cpp-build-tools): Inside Build Tools, select "Desktop development with C++" and under optional, only MSVC and the Windows 11 SDK is needed, feel free to unselect other optionals.
    - [CMake](https://cmake.org/download)
    - [NASM](https://nasm.us)
    - [Git](https://git-scm.com/downloads)
    - [Ninja](https://github.com/ninja-build/ninja/releases/latest)

    1. Clone the SVT-AV1-PSY repository:

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

    2. Configure compilation:

    ```bash title="Configure SVT-AV1-PSY"
    $env:Path = "C:\Program Files\LLVM\bin;" + $env:Path
    $env:CC = "clang"
    $env:CXX = "clang"
    cmake --fresh -B svt_build -G Ninja -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DSVT_AV1_LTO=OFF -DENABLE_AVX512=ON -DCMAKE_CXX_FLAGS_RELEASE="-flto -DNDEBUG -O2 -march=znver2" -DCMAKE_C_FLAGS_RELEASE="-flto -DNDEBUG -O2 -march=znver2"
    ```
    **Note**: `-march=znver2` has found to be the fastest on Windows, even on newer Ryzen CPUs. This is the case even for Intel CPUs, please try `znver2` first, if it doesn't run, then try `-march=native`, `-march=x86-64-v3`, or potentially older Intel architecture, such as `-march=haswell` or `-march=skylake`.

    3. Compile:

    ```bash title="Build release"
    ninja -C svt_build
    ```

    The compiled binary will be in the `Bin/Release` directory.

## Projects Featuring SVT-AV1-PSY

Some projects that feature SVT-AV1-PSY include:

- [Aviator](/tools/utilities/aviator/) ~ an AV1 encoding GUI by @gianni-rosato
- [rAV1ator CLI](/tools/utilities/rav1ator-cli/) ~ a TUI for video encoding with Av1an by @gianni-rosato
- [SVT-AV1-PSY on the AUR](https://aur.archlinux.org/packages/svt-av1-psy-git) ~ by @BlueSwordM
- [SVT-AV1-PSY in CachyOS](https://github.com/CachyOS/CachyOS-PKGBUILDS/pull/144) ~ by @BlueSwordM
- [Custom Handbrake Builds](https://github.com/vincejv/docker-handbrake) ~ by @vincejv
- [Staxrip](https://github.com/staxrip/staxrip) ~ a video & audio encoding GUI for Windows by @Dendraspis

## License

Up to v0.8.7, SVT-AV1 is licensed under the BSD-2-clause license and the
Alliance for Open Media Patent License 1.0. Starting from v0.9, SVT-AV1 is licensed
under the BSD-3-clause clear license and the Alliance for Open Media Patent
License 1.0.

SVT-AV1-PSY does not feature license modifications from mainline SVT-AV1.


collection: docs

title: SVT-HEVC

description: SVT-HEVC is an open source H.265 / HEVC software encoder developed by Intel made specifically to only support x86. As the name suggests, it is part of the "Scalable Video Technology" project lineup by Intel.

status: needs-review

license: CC BY-SA 4.0

text: SVT-HEVC

anchor: svt-hevc

text: FFmpeg

anchor: ffmpeg

text: Supported Color Space

anchor: supported-color-space

text: Installation

anchor: installation

text: Usage

anchor: usage

text: Normal usage

anchor: normal-usage

text: Encoding HDR

anchor: encoding-hdr

text: Encoding with Dolby Vision

anchor: encoding-with-dolby-vision

text: List of all configuration parameters

anchor: list-of-all-configuration-parameters

contentFormat: markdown

markdown:
# SVT-HEVC

[SVT-HEVC](https://github.com/OpenVisualCloud/SVT-HEVC) (Scalable Video Technology for HEVC) is an open source [H.265 / HEVC](/codecs/video/hevc/) software encoder developed by Intel made specifically to **only support x86**. 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.

The encoder is written in C with some parts in Assembly and licensed under **BSD+Patent**.

> **Note — It is recommended to use [x265](/tools/software-encoders/x265/) instead as it performs much better in quality..**
>
>
## FFmpeg

SVT-HEVC is only available in FFmpeg when it is compiled with their provided [plugin](https://github.com/OpenVisualCloud/SVT-HEVC/tree/master/ffmpeg_plugin). Otherwise it is via `libsvt_hevc`, to check if you have it, run `ffmpeg -h encoder=libsvt_hevc`.

## Supported Color Space

SVT-HEVC 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

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

    ```bash title="Clone SVT-HEVC and cd"
    git clone https://github.com/OpenVisualCloud/SVT-HEVC
    cd SVT-HEVC/Build/linux
    ```

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

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

    ```bash title="Statically build release"
    ./build.sh static release
    ```

    The compiled binaries will be in the `Bin/Release` directory.
    #### Windows

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

## Usage

### Normal usage
```bash title="Simple Y4M input with QP 20, and raw 265 bitstream output"
SvtHevcEncApp -i input.y4m -q 20 -b output.265
```

```bash title="Preset 4, CRF 20, Y4M input"
SvtHevcEncApp -i input.y4m -q 20 -encMode 4 -b output.265
```

```bash title="FFmpeg piping"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | SvtHevcEncApp -i stdin -q 20 -encMode 4 -b output.265
```

> **Danger — SVT-HEVC currently does not have the ability to detect EOF (End of File) within Y4M pipes ([issue](https://github.com/OpenVisualCloud/SVT-HEVC/issues/634#issuecomment-1434911798)), so the encode process will go on indefinitely until your drive is full..**
>
> The only known solution is to manually set the number of frames to encode via `-n`.
### Encoding HDR

```bash
SvtHevcEncApp -i input.y4m -q 20 -encMode 4 -hdr -max-cll XXX -max-fall XXX -master-display G(0.265,0.690)B(0.150,0.060)R(0.680,0.320)WP(0.3127,0.3290)L(1000,0.0100) -b output.265
```
Remember sure to adjust the HDR metadata accordingly.

### Encoding with Dolby Vision

The ability to encode with Dolby Vision via RPU file is surprisingly present within SVT-HEVC, although it is limited to Profile 8.1.
```bash
SvtHevcEncApp -i input.y4m -q 20 -encMode 4 -hdr -dolby-vision-rpu RPUFile.bin -dolby-vision-profile 81 -max-cll XXX -max-fall XXX -master-display G(0.265,0.690)B(0.150,0.060)R(0.680,0.320)WP(0.3127,0.3290)L(1000,0.0100) -b output.265
```
Remember sure to adjust the HDR metadata accordingly.

## List of all configuration parameters

As with every SVT line-up, they redirect you to read their "User Guide" instead of presenting what each and every parameter do in the `--help` page.
The table below is an exact copy from their user guide taken from [GitHub](https://github.com/OpenVisualCloud/SVT-HEVC/blob/master/Docs/svt-hevc_encoder_user_guide.md) for backup purposes. Feel free to read them.

| **Encoder Parameter as shown in the configuration file** | **Command Line parameter** | **Range** | **Default** | **Description** |
| --- | --- | --- | --- | --- |
| **Channel Number** | -nch | [1 - 6] | 1 | Number of encode instances |
| **ConfigFile** | -c | any string | null | Configuration file path |
| **InputFile** | -i | any string | null | Input file path and name |
| **StreamFile** | -b | any string | null | Output bitstream file path and name |
| **ErrorFile** | -errlog | any string | stderr | Error log displaying configuration or encode errors |
| **ReconFile** | -o | any string | null | Output reconstructed yuv used for debug purposes. **Note:** using this feature will affect the speed of the encoder significantly. This should only be used for debugging purposes. |
| **UseQpFile** | -use-q-file | [0, 1] | 0 | When set to 1, overwrite the picture qp assignment using qp values in QpFile |
| **QpFile** | -qp-file | any string | null | Path to qp file |
| **SegmentOvFile** | -segment-ov-file | any string | null | Path to segment override file which will allow for sharpness improvement and bit rate reduction on a per segment basis. Refer to config/SVTSegmentOvFile.txt for details. |
| **EncoderMode** | -encMode | [0 - 11] | 7 | A preset defining the quality vs density tradeoff point that the encoding is to be performed at. (e.g. 0 is the highest quality mode, 11 is the highest density mode). Section 3.4 outlines the preset availability per resolution |
| **EncoderBitDepth** | -bit-depth | [8, 10] | 8 | Specifies the bit depth of input video |
| **EncoderColorFormat** | -color-format | [1, 2, 3] | 1 | Specifies the chroma subsampling of input video(1: 420, 2: 422, 3: 444) |
| **CompressedTenBitFormat** | -compressed-ten-bit-format | [0, 1] | 0 | Offline packing of the 2bits: requires two bits packed input (0: OFF, 1: ON) |
| **SourceWidth** | -w | [64 - 8192] | 0 | Input source width |
| **SourceHeight** | -h | [64 - 4320] | 0 | Input source height |
| **FrameToBeEncoded** | -n | [0 - 2^31 -1] | 0 | Number of frames to be encoded, if number of frames is > number of frames in file, the encoder will loop to the beginning and continue the encode. 0 encodes the full clip. |
| **BufferedInput** | -nb | [-1, 1 to 2^31 -1] | -1 | number of frames to preload to the RAM before the start of the encode. If -nb = 100 and –n 1000 --> the encoder will encode the first 100 frames of the video 10 times. Use -1 to not preload any frames.  This parameter is best used to eliminate the impact of disk reading on encoding speed and is most noticeable when frames sizes are 4k or 8k.  Because frames are repeated when value specified (-nb) is less than the total frame count (-n), you should expect bitstreams to be different. |
| **Profile** | -profile | [1,2] | 2 | 1: Main, 2: Main 10 |
| **Tier** | -tier | [0, 1] | 0 | 0: Main, 1: High |
| **Level** | -level | [1, 2, 2.1,3, 3.1, 4, 4.1, 5, 5.1, 5.2, 6, 6.1, 6.2] | 0 | 0 to 6.2 [0 for auto determine Level] |
| **FrameRate** | -fps | [0 - 2^64 -1] | 60 | If the number is less than 1000, the input frame rate is an integer number between 1 and 60, else the input number is in Q16 format (shifted by 16 bits) [Max allowed is 240 fps]. If FrameRateNumerator and FrameRateDenominator are both !=0 the encoder will ignore this parameter |
| **FrameRateNumerator** | -fps-num | [0 - 2^64 -1] | 0 | Frame rate numerator e.g. 6000 When zero, the encoder will use –fps if FrameRateDenominator is also zero, otherwise an error is returned |
| **FrameRateDenominator** | -fps-denom | [0 - 2^64 -1] | 0 | Frame rate denominator e.g. 100 When zero, the encoder will use –fps if FrameRateNumerator is also zero, otherwise an error is returned |
| **Injector** | -inj | [0,1] | 0 | Enable injection of input frames at the specified framerate (0: OFF, 1: ON) |
| **InjectorFrameRate** | -inj-frm-rt | [1 - 240] | 60 | Frame Rate used for the injector. Recommended to match the encoder speed. |
| **SpeedControlFlag** | -speed-ctrl | [0,1] | 0 | Enables the Speed Control functionality to achieve the real-time encoding speed defined by –fps. When this parameter is set to 1 it forces –inj to be 1 and -inj-frm-rt to be set to –fps. |
| **InterlacedVideo** | -interlaced-video | [0,1] | 0 | 1 : encoder will signal interlaced signal in the stream \
0 : assumes progressive signal |
| **SeparateFields** | -separate-fields | [0,1] | 0 | 1 : Interlaced input, application will separate top and bottom fields and encode it as progressive. \
0 : Treat video as progressive video |
| **HierarchicalLevels** | -hierarchical-levels | [0 – 3] | 3 | 0 : Flat\
1: 2-Level Hierarchy\
2: 3-Level Hierarchy\
3: 4-Level Hierarchy\
Minigop Size = (2^HierarchicalLevels) \
(e.g. 3 == > 7B pyramid, 2 ==> 3B Pyramid)\
Refer to Appendix A.1 |
| **BaseLayerSwitchMode** | -base-layer-switch-mode | [0,1] | 0 | 0 : Use B-frames in the base layer pointing to the same past picture\
1 : Use P-frames in the base layer\
Refer to Appendix A.1 |
| **PredStructure** | -pred-struct | [0 – 2] | 2 | 0: Low Delay P\
1: Low Delay B\
2: Random Access\
Refer to Appendix A.1 |
| **IntraPeriod** | -intra-period | [-2 - 255] | -2 | Distance between Intra Frame inserted. \
-1 denotes no intra update. \
-2 denotes auto. |
| **IntraRefreshType** | -irefresh-type | [-1,N] | -1 | -1: CRA (Open GOP)\
>=0: IDR (Closed GOP, N is headers insertion interval, 0 supported if CQP, >=0 supported if VBR)\
Refer to Appendix A.3 |
| **QP** | -q | [0 - 51] | 32 | Initial quantization parameter for the Intra pictures used when RateControlMode 0 (CQP) |
| **LoopFilterDisable** | -dlf | [0, 1] | 0 | When set to 1 disables the Deblocking Loop Filtering |
| **SAO** | -sao | [0,1] | 1 | When set to 0 the encoder will not use the Sample Adaptive Filter |
| **UseDefaultMeHme** | -use-default-me-hme | [0, 1] | 1 | 0 : Overwrite Default ME HME parameters\
1 : Use default ME HME parameters, dependent on width and height |
| **HME** | -hme | [0,1] | 1 | Enable HME, 0 = OFF, 1 = ON |
| **SearchAreaWidth** | -search-w | [1 - 256] | Depends on input resolution | Motion vector search area width |
| **SearchAreaHeight** | -search-h | [1 - 256] | Depends on input resolution | Motion vector search area height |
| **ConstrainedIntra** | -constrd-intra | [0,1] | 0 | Allow the use of Constrained Intra, when enabled, this features yields to sending two PPSs in the HEVC Elementary streams \
0 = OFF, 1 = ON |
| **RateControlMode** | -rc | [0,1] | 0 | 0 : CQP , 1 : VBR |
| **TargetBitRate** | -tbr | Any Number | 7000000 | Target bitrate in bits / second. Only used when RateControlMode is set to 1 |
| **vbvMaxrate** | -vbv-maxrate | Any Number | 0 | VBVMaxrate in bits / second. Only used when RateControlMode is set to 1 |
| **vbvBufsize** | -vbv-bufsize | Any Number | 0 | VBV BufferSize in bits / second. Only used when RateControlMode is set to 1 |
| **vbvBufInit** | -vbv-init | [0 - 100] | 90 | Sets the initial percentage size that the VBV buffer is filled to |
| **hrdFlag** | -hrd | [0,1] | 0 | Sets the HRD (Hypothetical Reference Decoder) Flag in the encoded stream, 0 = OFF, 1 = ON When
hrdFlag is set to 1, vbvMaxrate and vbvBufsize must be greater than 0 |
| **MaxQpAllowed** | -max-qp | [0 - 51] | 48 | Maximum QP value allowed for rate control use. Only used when RateControlMode is set to 1. Has to be >= MinQpAllowed |
| **MinQpAllowed** | -min-qp | [0 - 50] | 10 | Minimum QP value allowed for rate control use. Only used when RateControlMode is set to 1. Has to be < MaxQpAllowed |
| **LookAheadDistance** | -lad | [0 - 250] | Depending on BRC mode | When RateControlMode is set to 1 it's best to set this parameter to be equal to the Intra period value (such is the default set by the encoder).  When CQP is chosen, then a (2 \* minigopsize +1) look ahead is recommended. |
| **SceneChangeDetection** | -scd | [0,1] | 1 | Enables or disables the scene change detection algorithm \
 0 = OFF, 1 = ON |
| **BitRateReduction** | -brr | [0,1] | 0 | Enables visual quality algorithms to reduce the output bitrate with minimal or no subjective visual quality impact. \
0 = OFF, 1 = ON |
| **ImproveSharpness** | -sharp | [0,1] | 0 | This is a visual quality knob that allows the use of adaptive quantization within the picture and enables visual quality algorithms that improve the sharpness of the background. This feature is only available for 4k and 8k resolutions \
 0 = OFF, 1 = ON |
| **VideoUsabilityInfo** | -vid-info | [0,1] | 0 | Enables or disables sending a vui structure in the HEVC Elementary bitstream. 0 = OFF, 1 = ON |
| **HighDynamicRangeInput** | -hdr | [0,1] | 0 | When set to 1, signals HDR10 input in the output HEVC elementary bitstream and forces VideoUsabilityInfo to 1. \
0 = OFF, 1 = ON |
| **AccessUnitDelimiter** | -ua-delm | [0,1] | 0 | SEI message, 0 = OFF, 1 = ON |
| **BufferingPeriod** | -pbuff | [0,1] | 0 | SEI message, 0 = OFF, 1 = ON |
| **PictureTiming** | -tpic | [0,1] | 0 | SEI message, 0 = OFF, 1 = ON. \
If 1, VideoUsabilityInfo should be also set to 1. |
| **RegisteredUserData** | -reg-user-data | [0,1] | 0 | SEI message, 0 = OFF, 1 = ON |
| **UnregisteredUserData** | -unreg-user-data | [0,1] | 0 | SEI message, 0 = OFF, 1 = ON |
| **RecoveryPoint** | -recovery-point | [0,1] | 0 | SEI message, 0 = OFF, 1 = ON |
| **TemporalId** | -temporal-id | [0,1] | 1 | 0 = OFF\
1 = Insert temporal ID in NAL units |
| **AsmType** | -asm | [0,1] | 1 | Assembly instruction set \
(0: C Only, 1: Automatically select highest assembly instruction set supported) |
| **LogicalProcessors** | -lp | [0, total number of logical processor] | 0 | The number of logical processor which encoder threads run on.Refer to Appendix A.2 |
| **FirstLogicalProcessor** | -flp | [0, the index of last logical processor] | 0 | The index of first logical processor which encoder threads run on.Refer to Appendix A.2 |
| **TargetSocket** | -ss | [-1,1] | -1 | For dual socket systems, this can specify which socket the encoder runs on.  Refer to Appendix A.2 |
| **ThreadCount** | -thread-count | [0,N] | 0 | The number of threads to get created and run, 0 = AUTO |
| **SwitchThreadsToRtPriority** | -rt | [0,1] | 1 | Enables or disables threads to real time priority, 0 = OFF, 1 = ON (only works on Linux) |
| **FPSInVPS** | -fpsinvps | [0,1] | 1 | Enables or disables the VPS timing info, 0 = OFF, 1 = ON |
| **TileRowCount** | -tile_row_cnt | [1,22] | 1 | Tile count in the Row |
| **TileColumnCount** | -tile_col_cnt | [1,20] | 1 | Tile count in the column |
| **TileSliceMode** | -tile_slice_mode | [0,1] | 0 | Per slice per tile, only valid for multi-tile |
| **UnrestrictedMotionVector** | -umv | [0,1] | 1 | Enables or disables unrestricted motion vectors\
0 = OFF(motion vectors are constrained within frame or tile boundary)\
1 = ON.\
For MCTS support, set -umv 0 with valid TileRowCount and TileColumnCount |
| **MaxCLL** | -max-cll | [0 , 2^16-1] | 0 | Maximum content light level (MaxCLL) as required by the Consumer Electronics Association 861.3 specification. Applicable for HDR content. If specified, signaled only when HighDynamicRangeInput is set to 1 |
| **MaxFALL** | -max-fall | [0 , 2^16-1] | 0 | Maximum Frame Average light level (MaxFALL) as required by the Consumer Electronics Association 861.3 specification. Applicable for HDR content. If specified, signaled only when HighDynamicRangeInput is set to 1 |
| **UseMasterDisplay** | -use-master-display | [0,1] | 0 | Enables or disables the MasterDisplayColorVolume\
0 = OFF\
1 = ON |
| **MasterDisplay** | -master-display | For R, G, B and whitepoint [0, 2^16-1]. For max, min luminance [0, 2^32-1] | 0 | SMPTE ST 2086 mastering display color volume SEI info, specified as a string. The string format is “G(%hu,%hu)B(%hu,%hu)R(%hu,% hu)WP(%hu,%hu)L(%u,%u)” where %hu are unsigned 16bit integers and %u are unsigned 32bit integers. The SEI includes X, Y display primaries for RGB channels and white point (WP) in units of 0.00002 and max, min luminance (L) values in units of 0.0001 candela per meter square. Applicable for HDR content. Example for a P3D65 1000-nits monitor,G(13250,34500)B(7500,3 000)R(34000,16000)WP(15635,16 450)L(10000000,1) |
| **DolbyVisionRpuFile** | -dolby-vision-rpu | any string | null | Path to the file containing Dolby Vision RPU metadata |
| **DolbyVisionProfile** | -dolby-vision-profile | 8.1 or 81 | 0 | Generate bitstreams confirming to the specified Dolby Vision profile 8.1. When specified, enables HighDynamicRangeInput automatically. Applicable only for 10-bit input content. MasterDisplay should be set for using dolby vision profile 81. Pass the dynamic metadata through DolbyVisionRpuFile option |
| **NaluFile** | -nalu-file | any string | null | Path to the file containing CEA 608/708 metadata. Text file should contain the userSEI in POC order as per below format: `<POC><space><PREFIX><space><NALUNITTYPE>/<SEITYPE><space><SEI Payload>`. Currently only PREFIX_SEI messages are supported |


title: SVT-VP9

description: SVT-VP9 is a VP9 encoder developed by Intel. Like its siblings in the SVT encoder family, it scales very well on multicore processors by default.

text: FFmpeg

text: Supported Color Space

text: Usage

text: Standalone

anchor: standalone

markdown:
> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
SVT-VP9 is a [VP9](/codecs/video/vp9/) encoder developed by Intel.

Like [its](/tools/software-encoders/svt-hevc/) [siblings](/tools/software-encoders/svt-av1/) in the SVT encoder family, it scales very well on multicore processors by default.

The [reference encoder](/tools/software-encoders/vpxenc/) beats it in rate control flexibility and supports 10-bit color,
but SVT-VP9 is much faster out of the box.

## FFmpeg
There are patches bundled in the SVT-VP9 source code for an FFmpeg plugin that adds the `libsvt_vp9` encoder.

One must recompile FFmpeg with the plugin patch applied to take advantage of it.

(An easy way to do so on Windows is using [media-autobuild_suite](https://github.com/m-ab-s/media-autobuild_suite).)

Operation is not too different from the SVT-AV1 FFmpeg integration. Your commands will generally look like this:

`ffmpeg -i video.mp4 -c:v libsvt_vp9 -qp 38 -tune ssim -preset 7 -g 255 video_vp9.webm`

Parameters

| Parameter           | Description |
|------------------|-------------|
| -qp              | Quantizer value, higher = lower quality. Range is 1..51 in current patches, but -qmin/-qmax can be set as high as 69 for extreme low bitrates. |
| -preset          | Speed preset. Range is 0..9, with 9 being fastest and default. |
| -tune            | Quality metric. Can be "vq" (default), "ssim" or "vmaf". |
| -g               | Size of the Group of Pictures. Range is -2..255, with -1 = no intraframe updates ever, -2 = "auto".
We recommend you set it as high as possible for encode efficiency. |
| -rc              | Rate control mode.
Can be "cqp" (Constant Quantizer, default), "vbr" (Variable Bitrate) or "cbr" (Constant Bitrate).
(Consider using **vpxenc's two-pass mode** if you really need to match a target bitrate.) |
| -level           | Encoder level. Range is 1..6. Generally better not to set it. |
| -socket          | Index of the CPU socket to use. By default it's -1, which uses "all available processors". |

## Supported Color Space

SVT-VP9 only supports 8-bit yuv420p.

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


title: uavs3e

description: uavs3e is an open-source encoder for the AVS3 codec, developed by Chinese research institutions including Peking University Shenzhen Graduate School, Peng Cheng Laboratory, and Guangdong Bohua UHD Innovation Corporation.

status: current

text: Installation

text: 10-bit Support

text: Usage

text: Notes

anchor: notes

markdown:
# uavs3e

[uavs3e](https://github.com/uavs3/uavs3e/) is an open-source encoder for the [AVS3](/codecs/video/avs3/) codec, developed by Chinese research institutions including Peking University Shenzhen Graduate School, Peng Cheng Laboratory, and Guangdong Bohua UHD Innovation Corporation.

The encoder receives infrequent updates, which may result in bugs and compilation issues. It supports AMD64 with AVX2, ARM with NEON, and LoongArch CPUs.

## Installation

    #### Linux & macOS

The developers do not provide pre-built binaries, so you'll need to compile it yourself. Compilation requires GNU Make and CMake. As of August 2024, `uavs3e` does not compile with GCC 14, using Clang 18 instead resolves this issue.

    ```bash
    git clone https://github.com/uavs3/uavs3e.git
    cd uavs3e
    mkdir build/linux && cd build/linux
    cmake ../.. -DCOMPILE_10BIT=0 -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
    make -j 8
    ```

    If you encounter undefined calls to `close` or `lseek64` functions, add the following two lines at the top of the `test/utest.c` file:

    ```c
    #define _LARGEFILE64_SOURCE
    #include <unistd.h>
    ```

    Binaries will be available in the `build/linux` folder. On Linux, you can run `make install` to install the encoder (may require elevated permissions).
    #### Windows

1. Ensure you have the following prerequisites installed before starting the build process:
    - [Microsoft C++ Build Tools](https://visualstudio.microsoft.com/visual-cpp-build-tools/): Select "Desktop development with C++".
    - [Git](https://git-scm.com/download/win)

    2. Open Developer PowerShell for VS 2022.

    3. Run the following commands:

    ```bash
    git clone https://github.com/uavs3/uavs3e.git
    cd uavs3e
    .\version.bat
    cd build\x86_windows
    devenv uavs3e.sln /Upgrade
    msbuild uavs3e.sln /p:Configuration=Release /p:WindowsTargetPlatformVersion=10.0
    ```

    Binaries will be available in the `bin` folder.

### 10-bit Support

    #### Linux & macOS

To enable 10-bit support, set `-DCOMPILE_10BIT=1` in the CMake command. However, the encoder compiled with this flag has been reported to cause [segmentation faults](https://github.com/uavs3/uavs3e/issues/53) on some systems.
    #### Windows

To enable 10-bit support, change the line `#define COMPILE_10BIT 0` to `#define COMPILE_10BIT 1` in the `inc/com_api.h` file.

## Usage

The encoder cannot parse `.y4m` files, they need to be converted to raw video (`.yuv`) format.

```bash title="Simple 8-bit FHD 23.976 fps input with QP 20 and raw avs3 bitstream output"
uavs3enc -i input.yuv -w 1920 -h 1080 -d 8 --fps_num 24000 --fps_den 1001 -q 20 -o output.avs3
```

```bash title="Speed 2, CRF 20, intra period 120, multithreaded"
uavs3enc -i input.yuv -w 1920 -h 1080 -d 8 --fps_num 24000 --fps_den 1001 -p 120 --wpp_threads 8 --frm_threads 8 --speed_level 2 --rc_type 1 -q 20 -o output.avs3
```

Currently, uavs3e [does not support piping](https://github.com/uavs3/uavs3e/issues/2).

## Notes

1. Usable speed presets range from 0 to 4, where 0 is the slowest and 4 is the fastest.
2. The encoder can be quite competitive, even compared with the newest [AV1](/codecs/video/av1/) and [VVC](/codecs/video/vvc/) encoders in terms of visual fidelity.
3. `uavs3d` can be used to decode the output bitstream. For real-time playback, you need to have [FFmpeg](/tools/utilities/ffmpeg/) compiled with `--enable-libuavs3d`.


title: uvg266

description: uvg266 is an open-source software encoder for encoding to the H.266 / VVC codec. Developed by the Ultra Video Group, written in C and licensed under BSD 3-clause. The encoder is based on Kvazaar, their open source HEVC e

text: Installation

text: Arch Linux

anchor: arch-linux

text: Compiling

anchor: compiling

text: 10-bit Support

text: Usage

text: Troubleshooting

anchor: troubleshooting

markdown:
[uvg266](https://github.com/ultravideo/uvg266/) is an open-source software encoder for encoding to the [H.266 / VVC](/codecs/video/vvc/) codec. Developed by the [Ultra Video Group](https://ultravideo.fi/), written in C and licensed under BSD 3-clause.
The encoder is based on [Kvazaar](/tools/software-encoders/kvazaar/), their open source [HEVC](/codecs/video/hevc/) encoder solution.

## Installation

### Arch Linux

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

### Compiling
Ultra Video Group does not ship any pre-built binaries of their encoders so you'll have to compile them yourself.

Windows users are recommended to compile via MinGW-W64 which comes with [MSYS2](https://msys2.org/).

> **Caution — Compilation requires GNU Make and CMake.**
>
>
> **Tip — The following build procedure should work across all common operating systems. Using Clang instead of GCC works..**
>
> You may add `-DCMAKE_CXX_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS="-flto -O3 -march=native -pipe -fno-plt" -DCMAKE_C_FLAGS_INIT="-flto=8 -static"` in CMake for better performance.
```bash
git clone https://github.com/ultravideo/uvg266.git
cd uvg266/build
cmake .. -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=0
make -j 8
```

Binaries will be available in the same folder (`build`), or you can run `make install` on Linux to install (May need elevated permissions).

### 10-bit Support

You need to compile with `-DUVG_BIT_DEPTH=10` in the CMake `-DCMAKE_C_FLAGS` option to enable support for encoding 10-bit videos.

For example:
```bash
-DCMAKE_C_FLAGS="-DUVG_BIT_DEPTH=10"
```
With native optimizations:
```bash
-DCMAKE_C_FLAGS="-flto -O3 -march=native -pipe -fno-plt -DUVG_BIT_DEPTH=10"
```

> **Caution — Encoding 10-bit with uvg266 is significantly slower as the developers only prioritized SIMD optimizations for 8-bit, and can get really buggy..**
>
>
## Usage

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

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

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

## Troubleshooting

1. `Could not find a strategy for crc32c_8x8!` - You're out of luck, uvg266 failed to initialize its block partitioning strategy for your specific CPU instruction set, so you **can't use the encoder or encode that specific video**.


title: vpxenc

description: vpxenc is part of the libvpx library for working with the VP9 & VP8 video codecs. It is capable of encoding & decoding both formats, where vpxenc is the multipurpose encoder. VP9 competes with HEVC & AVC in coding effici

text: vpxenc

anchor: vpxenc

text: FFmpeg

text: Supported Color Space

text: Installing (Binary)

anchor: installing-binary

text: Compiling (Windows/MacOS/Linux)

anchor: compiling-windowsmacoslinux

text: Cloning

anchor: cloning

text: ./configure file

anchor: configure-file

text: Other ./configure options

anchor: other-configure-options

text: Running GNU make

anchor: running-gnu-make

text: Encoding

anchor: encoding

markdown:
# vpxenc

> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
vpxenc is part of the libvpx library for working with the [VP9](/codecs/video/vp9/) & [VP8](/codecs/video/vp8/) video codecs. It is capable of encoding & decoding both formats, where vpxenc is the multipurpose encoder. VP9 competes with [HEVC](/codecs/video/hevc/) (h265) & [AVC](/codecs/video/avc/) (h264) in coding efficiency, and has been superseded by [AV1](/codecs/video/av1/). VP8 competes with AVC.

By default, vpxenc isn't as competitive as it could be, but even when used properly, most tests show that h265 offers slightly better quality per bit with efficient encoders like [x265](/tools/software-encoders/x265/).

## FFmpeg

vpxenc is available in FFmpeg via `libvpx` for **VP8** and `libvpx-vp9` for **VP9**, to check if you have it, run `ffmpeg -h encoder=libvpx` or `ffmpeg -h encoder=libvpx-vp9`.
Non-FFmpeg standard VP8/VP9 parameters are **not** supported.

## Supported Color Space

vpxenc supports the following color spaces:

| Format           | Chroma Subsampling | Supported Bit Depth(s) |
|------------------|:------------------:|-----------------------|
| YUV420P          | 4:2:0              | 8-bit                 |
| YUVA420P         | 4:2:0              | 8-bit (Alpha Channel) |
| YUV422P          | 4:2:2              | 8-bit                 |
| YUV440P          | 4:4:0              | 8-bit                 |
| YUV444P          | 4:4:4              | 8-bit                 |
| GBRP             | -                  | 8-bit                 |
| YUV420P10LE      | 4:2:0              | 10-bit                |
| YUV422P10LE      | 4:2:2              | 10-bit                |
| YUV440P10LE      | 4:4:0              | 10-bit                |
| YUV444P10LE      | 4:4:4              | 10-bit                |
| GBRP10LE         | -                  | 10-bit                |
| YUV420P12LE      | 4:2:0              | 12-bit                |
| YUV422P12LE      | 4:2:2              | 12-bit                |
| YUV440P12LE      | 4:4:0              | 12-bit                |
| YUV444P12LE      | 4:4:4              | 12-bit                |
| GBRP12LE         | -                  | 12-bit                |

## Installing (Binary)

Windows builds are available on Lastrosade's [website](https://jeremylee.sh/bins/) and can be downloaded [here](https://jeremylee.sh/bins/vpx.7z).

For Linux and MacOS, it may be be available when searching "vpxenc" or "libvpx" in their respective package managers.

## Compiling (Windows/MacOS/Linux)

Windows users are recommended to compile via MinGW-W64 which comes with [MSYS2](https://msys2.org/).

nasm/yasm, and the GNU build tools (make, configure) are required for this operation.

### Cloning
First, cloning
```bash
git clone https://chromium.googlesource.com/webm/libvpx
cd libvpx
mkdir libvpx_build && cd libvpx_build
```

### ./configure file
Now here comes the annoying part, the configure file have really bad defaults. So you will need to adjust them, here are some recommended options you should use:

```bash
../configure --cpu=native --extra-cxxflags="-ffat-lto-objects -flto" --extra-cflags="-ffat-lto-objects -flto" --as=auto --enable-vp9-highbitdepth --enable-libyuv --enable-webm-io --enable-vp9 --enable-runtime-cpu-detect --enable-internal-stats --enable-postproc --enable-vp9-postproc --enable-static --disable-shared --enable-vp9-temporal-denoising --disable-unit-tests --disable-docs --enable-multithread
```

Now let's break down what each of them do.

- `--cpu=native`
Native CPU optimizations.

- `--extra-cxxflags="-ffat-lto-objects -flto" --extra-cflags="-ffat-lto-objects -flto"`
More CPU optimizations for faster encoding.

- `--as=auto`
Set the assembler to auto, so it can choose between `yasm` and `nasm`.

- `--enable-vp9-highbitdepth`
Enables high bit depth (>=10 bits) when encoding VP9.

- `--enable-libyuv`
Enables YUV4MPEG input support (IMPORTANT), otherwise it will only accept RAW.

- `--enable-webm-io`
Enables input and output support for WebM container.

- `--enable-vp9`
Enables VP9 encoding support.

- `--enable-runtime-cpu-detect`
Enables runtime CPU detection.

- `--enable-internal-stats`
Enables internal statistics for the encoder for debug purposes.

- `--enable-postproc`
Enables postprocessing stuff for better video quality.

- `--enable-vp9-postproc`
Enables VP9-specific postprocessing stuff for better video quality.

- `--enable-static`
Enables static builds.

- `--disable-shared`
Disables shared builds.

- `--enable-vp9-temporal-denoising`
Disables spatial denoising for VP9 and enables temporal instead.

- `--disable-unit-tests`
Disables unit tests, unless you want to test the encoder as a developer. This should be disabled.

- `--disable-docs`
Disables documentation, as enabling this also requires doxygen.

- `--enable-multithread`
Enables the usage of multiple CPU threads for encoding and decoding.

### Other ./configure options

There are other options you may want use to either speed up compiliation or drop unwanted features.

1. `--disable-vp8 --disable-vp9-decoder --disable-vp8-decoder`
Disables VP8 encoding and `vpxdec` (decoder) to be compiled.

2. `--enable-small`
Prioritizes smaller encoder binary size over encoding speed.

3. `--target=`
Enables target compilation for a specific operating system or CPU architecture. There's a lot of them. Here's an exhaustive list of all of them based on the configure file:
```bash
arm64-android-gcc
arm64-darwin-gcc
arm64-darwin20-gcc
arm64-darwin21-gcc
arm64-darwin22-gcc
arm64-darwin23-gcc
arm64-linux-gcc
arm64-win64-gcc
arm64-win64-vs15
arm64-win64-vs16
arm64-win64-vs16-clangcl
arm64-win64-vs17
arm64-win64-vs17-clangcl
armv7-android-gcc
armv7-darwin-gcc
armv7-linux-rvct
armv7-linux-gcc
armv7-none-rvct
armv7-win32-gcc
armv7-win32-vs14
armv7-win32-vs15
armv7-win32-vs16
armv7-win32-vs17
armv7s-darwin-gcc
armv8-linux-gcc
loongarch32-linux-gcc
loongarch64-linux-gcc
mips32-linux-gcc
mips64-linux-gcc
ppc64le-linux-gcc
sparc-solaris-gcc
x86-android-gcc
x86-darwin8-gcc
x86-darwin8-icc
x86-darwin9-gcc
x86-darwin9-icc
x86-darwin10-gcc
x86-darwin11-gcc
x86-darwin12-gcc
x86-darwin13-gcc
x86-darwin14-gcc
x86-darwin15-gcc
x86-darwin16-gcc
x86-darwin17-gcc
x86-iphonesimulator-gcc
x86-linux-gcc
x86-linux-icc
x86-os2-gcc
x86-solaris-gcc
x86-win32-gcc
x86-win32-vs14
x86-win32-vs15
x86-win32-vs16
x86-win32-vs17
x86_64-android-gcc
x86_64-darwin9-gcc
x86_64-darwin10-gcc
x86_64-darwin11-gcc
x86_64-darwin12-gcc
x86_64-darwin13-gcc
x86_64-darwin14-gcc
x86_64-darwin15-gcc
x86_64-darwin16-gcc
x86_64-darwin17-gcc
x86_64-darwin18-gcc
x86_64-darwin19-gcc
x86_64-darwin20-gcc
x86_64-darwin21-gcc
x86_64-darwin22-gcc
x86_64-darwin23-gcc
x86_64-iphonesimulator-gcc
x86_64-linux-gcc
x86_64-linux-icc
x86_64-solaris-gcc
x86_64-win64-gcc
x86_64-win64-vs14
x86_64-win64-vs15
x86_64-win64-vs16
x86_64-win64-vs17
generic-gnu
```

For **Windows** compilation with MinGW you may need to use `--target=x86_64-win64-gcc` and `--target=arm64-darwin22-gcc` for **MacOS**.

### Running GNU make

After successfully running the configure command above, run `make -j $(nproc)` to start compiling with your CPU count. The resulting binary will be called `vpxenc` and you can copy it wherever you like.

## VP8

*Incomplete*

## VP9

For encoding VP9, vpxenc's default parameters are not considered optimal. There are a lot of options that are either disabled without reason or are simply misconfigured, hurting coding efficiency at little cost otherwise. As of mid-2021, some parameters (the TPL-model, lag-in-frames and auto-alt-ref frames) were changed (since libvpx 1.9.0 and libvpx 1.10.0) which means that there's not much use of setting these three parameters unless you're in [FFmpeg](/tools/utilities/ffmpeg/). This section covers the most important options libvpx-vp9 has to offer, recommended settings, & what they do.

It is important to note that the vpxenc parameters provided below are considered optimal because they are efficient, but VP9 Profile 2 isn't compatible with many hardware-accelerated VP9 decoding implementations.

### Encoding

- `--codec=vp9`

Self-explanatory.

- `--passes=2`

vpxenc's 2-pass mode is quite fast compared to 2-pass in [x264](/tools/software-encoders/x264/) and x265. Only use 1-pass mode for real-time applications, which won't be covered here yet. It is the default in the standalone vpxenc libvpx-vp9 encoder.

- `--webm`

Enables WebM output for the encoder, and passes the encoder flags set. It is not necessary to enable it, but since it passes the encoder flags, I would use it. Can be changed to `--ivf` for an ivf video stream.

- `--good`

This is a sort of quality deadline, the minimum speed the encoder is allowed to go to. It isn't recommended to use `--best` as it is slow for the quality uplift you get. Do not use RT for anything but real-time encoding.

- `--threads=8`

Dictates the number of threads the encoder should spawn. It doesn’t mean it’ll scale all that well over those 8 threads. On a 16 thread CPU with a single encoder instance, I would use 8 threads. With multiple encoder instance encoding(with qencoder/av1an/neav1e), I would set it to 2 threads.

- `--profile=2`

VP9 profile 2 is obligatory if you want 10-bit & 12-bit support for HDR, and improved quality from 8-bit.

- `--lag-in-frames=25`

Lag-in-frames is the libvpx equivalent of lookahead in x264. The higher the number, the slower the encoder will be, but at the upside of making it more efficient. Going above –lag-in-frames=12 also activates another setting called alternate reference frames. 25 is the maximum you can get in libvpx-vp9. It is the default in the standalone vpxenc libvpx-vp9 encoder.

- `--end-usage=q`

Q mode is the closest equivalent to CRF that libvpx-vp9 offers, so use it if maximum quality is desired.

- `--cq-level=25`

For 1080p30 8-bit content, it is recommended to go with a Q of 25; you can go lower if you value higher quality over pure efficiency. For 1080p60 8-bit content, I would recommend going with a higher Q value with a delta of around 15. So, a Q of 30 to 40 is usually recommended. Depending on the content, you may have to tune this value, so this advice is only useful in choosing a starting point.

- `--kf-max-dist=[input FPS * 10]`

This tells the encoder to have a maximum number of frames between keyframes. It will usually place a lower number of keyframes in content like movies, TV shows, or animated shows, so you can set it to a very high number or not set it at all if you want maximum efficiency for this kind of content. Otherwise, I would go with the 10-second rule: `--kf-max-dist=240` for 24FPS content, 300 for 30FPS content, 600 for 60FPS content, and so on.

- `--cpu-used=3`

This is where the biggest balance of quality to speed is with libvpx-vp9. This is similar to presets in x264 and x265, except the lower the number, the slower the encoder takes. Using `--cpu-used=3` & below enables RDO, which increases quality at the expense of speed.
> **Note — `--cpu-used=5` and above are *slower* in the 1st pass, so it isn't recommended to use them anyway..**
>
>
- `--auto-alt-ref=6`

Activates alternate reference frames. Alternate reference frames are "invisible" frames which are used as references when creating the final display frames.

More alternate reference frames is typically more efficient. Setting this greater than 1 activates overlay frames and isn't compatible with the 8-bit color profiles.

- `--arnr-maxframes=7`

This is the maximum number of alternate reference frames the encoder is allowed to use. For most content, 7 is usually a good bet, and it is the default. With animated content, going with a value of 12 or to the max is a good bet, as animated content benefits from more additional alt-ref frames than other content. Be aware that increasing this value will impact encode speed.

- `--arnr-strength=4`

This setting dictates how much denoising will occur in the alt-ref frames. Lowering it to 2 or 3 is usually a good bet for noisier/grainy content to try and retain more detail, but 4 is a sane starting place. The default setting is 5, which is fine for most content, but it can be beneficial going a bit lower. For animation, keeping the default of 5 is likely a better option.

- `--aq-mode=0`

Adaptive quantization is the way for an encoder to spend more bits in certain areas to improve [psychovisual fidelity](/start-here/psychovisual/). `--aq-mode=0` works well on clean content (animation, video games, screen content). `--aq-mode=2` is recommended when you want to give more detail to more complex parts of a video.

- `--frame-boost=1`

This flag lets the encoder periodically boost the bitrate of a scene/frame if it needs it. Leaving it at the default `--frame-boost=0` is usually a good bet, & this isn't a particularly salient change.

- `--tune-content=default`

This determines how the encoder is tuned. In libvpx-vp9, there are three options: `default`, `screen`, and `film`. Default is for most scenarios, screen is for screen content(video games, live-streaming content like web pages & your screen), and film is for heavily dithered/grainy video. Leaving it at the default for about everything but screen content as described above is probably the best option. `--tune-content=screen` with `--aq-mode=2` is not recommended, as it creates some odd artifacts. It is advised to use `--aq-mode=0` if `--tune-content=screen` is activated, or if you want better perceptual quality, `--aq-mode=1`.

- `--row-mt=1`

Enables row multi-threading in libvpx-vp9. *Always* enable it no matter what, as it does not hurt efficiency, but boosts speed considerably. This feature is disabled by default.

- `--bit-depth=10`

Always use 10-bit for maximum efficiency & minimal banding, even with an 8-bit source. Make sure to enable `--profile=2` as mentioned above.

- `--tile-columns=1`

This setting divides the video into tile columns for easier parallelization when encoding & decoding. Setting `--tile-columns=1`, you will get 2¹ tile columns. Setting it higher is a trade-off between parallelization & coding efficiency, as more tiles means less information your encoder can work with, and this will result in decreased efficiency. Do note there is an upper threshold in regards to the number of tile columns you can get due to the fixed minimum tile width of 256 pixels. So, this means 4 tile columns (2²) for 720p and 1080p, 8 tile columns (2⁴) for 1440p/4k, and so on. If you set a tile column number that is too high, it will drop down to the lowest supported number of tile columns at the input resolution.

- `--tile-rows=0`

This setting divides the video into tile rows. This option is different from columns because although it also makes decoding performance higher, it does not scale as well as tile columns & doesn’t increase encoder threading nearly as much. Always use more tile-columns than rows, or leave the number of tile rows at default (0). Leaving the encoder defaults at `--tile-rows=0` & `--tile-columns=0` will result in the highest overall coding efficiency possible with these options.

- `--enable-tpl=1`

This option enables a temporal layer model, which helps with coding efficiency. It is the default in the standalone vpxenc libvpx-vp9 encoder.

All of these options are only available for the standalone vpxenc program. Here is a sample FFmpeg command line interpretation of the commands above, with some options missing:

```bash
ffmpeg -i input.mkv -c:v libvpx-vp9 -pix_fmt yuv420p10le -pass 1 -quality good -threads 4 -profile:v 2 -lag-in-frames 25 -crf 25 -b:v 0 -g 240 -cpu-used 3 -auto-alt-ref 6 -arnr-maxframes 7 -arnr-strength 4 -aq-mode 0 -tune-content default -tile-rows 0 -tile-columns 1 -enable-tpl 1 -row-mt 1 -f null -
ffmpeg -i input.mkv -c:v libvpx-vp9 -pix_fmt yuv420p10le -pass 2 -quality good -threads 4 -profile:v 2 -lag-in-frames 25 -crf 25 -b:v 0 -g 240 -cpu-used 3 -auto-alt-ref 6 -arnr-maxframes 7 -arnr-strength 4 -aq-mode 0 -tune-content default -tile-rows 0 -tile-columns 1 -enable-tpl 1 -row-mt 1 output.mkv
```

Alternatively, you can pass a raw .y4m stream to standalone vpxenc & encode that way.

*VP9 section written based on work by BlueSwordM, who has granted written permission for this wiki page to exist in its current fashion*


title: VTM

description: VTM is the original H.266 reference encoder, in competition with alternatives like VVenC. In the modern day, it joins other MPEG reference encoders such as HM & JM in their reputations for being highly niche offerings th

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!
VTM is the original [H.266](/codecs/video/vvc/) (better known as VVC) reference encoder, in competition with alternatives like [VVenC](/tools/software-encoders/vvenc/). In the modern day, it joins other MPEG reference encoders such as [HM](/tools/software-encoders/hm/) & [JM](/tools/software-encoders/jm/) in their reputations for being highly niche offerings that are used rarely due to their usage complexity & speed disadvantages; however, VTM may be more useful due to the current difficulty facing VVC encoding regardless of the encoding implementation one chooses to use. x264 is more efficient than JM.


title: VVenC

description: VVenC is an open source command line application for encoding H.266/VVC written in C++ and developed by Fraunhofer Heinrich-Hertz-Institute .

text: VVenC

anchor: vvenc

text: Installation

anchor: installation

text: Usage

anchor: usage

markdown:
# VVenC

<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/VVenC_Spam.avif" type="image/avif" />
    <img src="https://autumn.revolt.chat/attachments/wU4lo6SU-hRjZSVeqd9vCOeAskthYXmiWHaXUTjyTa/VVenC_Spam.webp"
alt="vvencapp spamming the terminal output with progress per-picture-order-count cause god knows why" width="XX" height="YY" loading="lazy" />
</picture>

VVenC is an open source command line application for encoding [H.266/VVC](/codecs/video/vvc/) written in C++ and developed by Fraunhofer Heinrich-Hertz-Institute (HHI).

## Installation

    #### Linux & macOS

Arch Linux users may check the AUR for the `vvenc` and `vvenc-git` packages.

    Compilation from source as shown belowe requires CMake.

    ```bash
    git clone https://github.com/fraunhoferhhi/vvenc.git
    cd vvenc
    mkdir build
    cd build
    cmake .. -DCMAKE_BUILD_TYPE=Release
    cmake --build .
    ```
    Binaries will be available in `bin/release-static/`

    ### FFmpeg Integration

    Since 15th June 2024, you can officially compile your own FFmpeg binary with `libvvenc`. If you use earlier FFmpeg revisions you will need to apply a custom patch. A comprehensive tutorial can be found in the [official VVenC wiki](https://github.com/fraunhoferhhi/vvenc/wiki/FFmpeg-Integration) ([archive](https://web.archive.org/web/20230509115800/https://github.com/fraunhoferhhi/vvenc/wiki/FFmpeg-Integration)).

    A VVC decoder has been [integrated into FFmpeg](https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/301ed950d1c3c500d0c2eee8472587dc5e691c04) in early 2024, FFmpeg 7.0 is the first release to support it. However if you still want to compile FFmpeg with the `vvdec` decoder, you can refer to the [official VVenC wiki](https://github.com/fraunhoferhhi/vvdec/wiki/FFmpeg-Integration) ([archive](https://web.archive.org/web/20240809090834/https://github.com/fraunhoferhhi/vvdec/wiki/FFmpeg-Integration)).

    There is an FFmpeg fork called [FFmpeg-VVC](https://github.com/MartinEesmaa/FFmpeg-VVC). It is maintained by Martin Eesmaa, who is the author of the [VVCEasy](https://github.com/MartinEesmaa/VVCEasy) GitHub repo featuring guides and more general information about working with VVC.

    Please be aware the script below produces a build of FFmpeg licensed under *LGPL version 2.1 or later*. It is legal to distribute the resulting binary, given you do not interfere with the flags provided below.

    ```bash title="Build FFmpeg with libvvdec, libvvenc, and fdk-aac"
    brew install libxml2 ffmpeg nasm # macOS-only; if on Linux, use your native package manager. Package names may differ.
    git clone https://github.com/fraunhoferhhi/vvenc
    git clone https://github.com/fraunhoferhhi/vvdec
    git clone https://github.com/mstorsjo/fdk-aac
    cd vvenc && mkdir build && cd build
    cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local ..
    sudo cmake --build . --target install -j $nproc
    cd ../../
    cd vvdec && mkdir build && cd build
    cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local ..
    sudo cmake --build . --target install -j $nproc
    cd ../../
    cd fdk-aac && ./autogen.sh && ./configure
    make -j
    sudo make install
    cd ../
    git clone --depth=1 https://github.com/MartinEesmaa/FFmpeg-VVC
    cd FFmpeg-VVC
    export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
    ./configure --enable-libfdk-aac --enable-libvvenc --enable-libvvdec --enable-static --enable-pic --enable-libxml2 --pkg-config-flags="--static" --enable-sdl2
    make -j
    ```
    Binaries will be available in the final directory you end up in after the build process is complete.
    #### Windows

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

## Usage

There are two encoders, the simple encoder (`vvencapp`) and the full-featured expert mode encoder (`vvencFFapp`) which is based on the [VTM](/tools/software-encoders/vtm/) configuration scheme. VVenC used to only accept YUV files input until support was added for Y4M.

Here are some examples:

```bash title="Standard VVenC input"
vvencapp -i input.y4m --qp 20 -o output.266
```
```bash title="Preset slow + qpa (already default) + YUV420P10"
vvencapp -i input.y4m --preset slow --qpa on --qp 20 -c yuv420_10 -o output.266
```
```bash title="Piping with FFmpeg"
ffmpeg -hide_banner -loglevel error -i input.mkv -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | vvencapp -i - --y4m --preset medium --qpa on --qp 20 -c yuv420_10 -o output.266
```

```bash title="FFmpeg preset fast + qp 32 muxing to mp4"
ffmpeg -i input.mkv -c:v libvvenc -qp 32 -preset fast out.mp4
```

> **Note — FFmpeg vvenc plugin only supports yuv420p10le output pixel format which means resulting video will always have 10 bit color depth..**
>
>
> **Note — QPA.**
>
> VVenC by default operates with QP (Quantization Parameter), which is basically fixed quality. For "CRF-like" rate control, QPA is enabled by default
> QPA (provided by --qpa) enables perceptually motivated QP adaptation based on [XPSNR](/reference/metrics/xpsnr/). QPA modifies the QP value on the fly spatially and temporally as well as enabling temporal RDO.


title: x264

text: FFmpeg

anchor: ffmpeg

text: Supported Color Space

anchor: supported-color-space

text: Usage

text: Recommendations

anchor: recommendations

text: Preset

anchor: preset

text: Threads

anchor: threads

text: Open GOP

anchor: open-gop

text: AQ Mode

anchor: aq-mode

text: Reference Frames

anchor: reference-frames

text: MB Tree

anchor: mb-tree

text: Lossless Encoding

anchor: lossless-encoding

markdown:
x264 is a software library and command line application for encoding H.264 / AVC developed by VideoLAN, the people behind the ever-popular VLC Media Player and released under GNU GPL. It is written in C and Assembly with almost two decades worth of development and threading optimizations which makes it the fastest software video encoder available, which also happens to be extremely popular.

x264 has great fine detail retention which makes it perfect for high fidelity content.

## FFmpeg

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

## Supported Color Space

x264 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)    |
| NV12             | Semi-planar        | 8-bit                 |
| NV16             | Semi-planar        | 8-bit                 |
| NV21             | Semi-planar        | 8-bit (reversed)      |
| 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                |

## Usage

x264 has been praised for its simple, no-fuss settings.

Here are some examples:

```bash title="Simple raw Y4M input with CRF 20 and raw 264 bitstream output"
x264 --crf 20 -o output.264 input.y4m
```

```bash title="Preset slow, CRF 20, Y4M input"
x264 --preset slow --crf 20 -o output.264 input.y4m
```

These next couple of examples utilize [FFmpeg](/tools/utilities/ffmpeg/) to pipe video into x264.

```bash title="FFmpeg piping"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | x264 --preset slow --crf 20 --demux y4m - -o output.264
```

```bash title="FFmpeg piping, MKV output"
ffmpeg -v error -i input.mkv -f yuv4mpegpipe -strict -1 - | x264 --preset slow --crf 20 --demux y4m - -o output.mkv
```
> **Note — Output Containers.**
>
> x264 can output ``264``, MKV, FLV (Flash Video), and MP4 (If compiled with GPAC or L-SMASH support). For more information about what containers are, see the ["Terminology" section on containers](/start-here/terminology/#container).
> **Caution — x264 will use Haali Matroska Muxer for MKV outputs, which has seeking issues. It is recommended to remux back using FFmpeg or mkvmerge/MKVToolNix..**
>
>
## Recommendations

As x264 is made to "just work", there aren't many advanced parameters to modify. The general guideline is to encode as slowly as you can tolerate.

### Preset

``--preset veryslow``

The most obvious way to increase fidelity per bit is to allow the encoder to spend more effort, and therefore time, encoding. This preset is decently slow, but preset ``placebo`` is even slower.

### Threads

``--threads X``

This is set to 1.5x the number of available cores by default, and shouldn't need to be adjusted unless you need to reduce the number of threads for some reason. x264's threading is very efficient, and in most cases, x264 should be able to completely saturate most consumer CPUs.

### Open GOP

``--open-gop``

Enables Open GOP (Group of Pictures), where each GOP can [reference one another](https://ottverse.com/closed-gop-open-gop-idr/), thus improving compression with little speed loss. For unknown reasons it is disabled by default in x264.

### AQ Mode

``--aq-mode 3``

In short, will make x264 bias to dark areas and spend more bitrate there, thus dark scenes will look less bad. Basically no speed loss.

### Reference Frames

``--bframes 8 --ref 12``

These parameters are responsible for the amount of reference frames x264 will use for compression, the more the better. Maximum of 16, will definitely increase compute time the higher you go.

### MB Tree

``--no-mbtree``

This option disables mb-tree rate control. mb-tree rate control is intended to redistribute bitrate to give more bits to frames that have less motion, and less bits to frames that have more motion (because artifacts in those frames will be less noticeable when the video is playing).
However, many users claim this can have negative effects on video quality, especially when encoding videos that have significant amounts of grain.

### Lossless Encoding

x264 can also encode lossless video, allowing it to compete with lossless video codecs like [FFV1](/codecs/video/ffv1/) and [UT Video](/codecs/video/utvideo/). To encode lossless video, use `--qp 0`. Slower presets will decrease the size even further while the video remains lossless.
However, when space is not a concern, such as when encoding an intermediate lossless for later encoding to a lossy format, x264 can become the fastest lossless codec available, providing super fast encoding and decoding.
For the absolute fastest encoding and decoding, one can use both `--preset ultrafast` and `--tune fastdecode`. However, `--preset superfast` still provides incredibly fast encoding and decoding speed, with 20-30% space savings for lossless compared to `ultrafast`,
so it may be the ideal choice for many users.

> **Note — Why QP 0 instead of CRF 0?.**
>
> CRF automatically adjusts a number of quantization parameters to achieve a desired quality output. QP stands for *Quantization Parameter*, and allows full control over the resulting video quality. In this case, all-intra or lossless, using QP is necessary, but for lossy encoding CRF will produce better visual fidelity per bit.


title: x265

description: x265 is a software library and command line application for encoding H.265 / HEVC developed by MulticoreWare, written in C++ and x86 assembly, and released in 2013.

text: FFmpeg

text: Parameters

anchor: parameters

text: Preset

text: Rate Control

anchor: rate-control

text: --CRF

anchor: --crf

text: --bitrate

anchor: --bitrate

text: Threading

anchor: threading

text: --wpp

anchor: --wpp

text: --frame-threads

anchor: --frame-threads

text: B-frames

anchor: b-frames

text: --bframes

anchor: --bframes

text: --b-adapt

anchor: --b-adapt

text: --bframe-bias

anchor: --bframe-bias

text: --b-pyramid

anchor: --b-pyramid

text: Restoration Filtering

anchor: restoration-filtering

text: --sao, --limit-sao and --no-sao

anchor: --sao---limit-sao-and---no-sao

text: --deblock

anchor: --deblock

text: Psycho-visual options

anchor: psycho-visual-options

text: --psy-rd and --psy-rdoq

anchor: --psy-rd-and---psy-rdoq

text: --aq-mode and --aq-strength

anchor: --aq-mode-and---aq-strength

text: CU-Tree

anchor: cu-tree

markdown:
x265 is a software library and command line application for encoding [H.265 / HEVC](/codecs/video/hevc/) developed by MulticoreWare, written in C++ and x86 assembly, and released in 2013.

By default, x265 is tuned for low-bitrate content due to the blurring filters it applies, but it can be tuned for high fidelity as well and excels at it.

x265 is currently not recommended for lossless encoding. For that niche, x264 is considerably faster without meaningful efficiency loss.

# FFmpeg

x265 is available in FFmpeg via `libx265`, to check if you have it, run `ffmpeg -h encoder=libx265`.

# Parameters

This section will overview the most important parameters for controlling output and quality in x265. The parameters will be listed in the format used by the standalone x265 binary,
but all the parameters should also be usable in FFmpeg in the format e.g. `-x265-params pass=1`.

## Preset

`--preset`

In x265, we have a preset system to easily control how much effort and therefore time x265 puts into compressing video. This system possesses the following presets:

ultrafast, superfast, faster, fast, medium (default), slow, slower, veryslow and placebo

Generally speaking the further left of medium the preset is, the faster and therefore less efficient the encode is, and the opposite is true for the right side.

It is recommended to pick the slowest preset you can bear to use on your hardware before messing with any of the following settings on this page, as this will be your baseline for encoder performance.

It is not recommended to use the two extremes as ultrafast is terrible in its consistency and you would be better off using something like x264. placebo on the other hand performs slightly worse than
veryslow for reasons that will be explained later.

## Rate Control

### `--CRF`

CRF or Constant Rate Factor is the closest thing in x265 to a quality slider for the final encode where a smaller value is higher quality and a larger value is lower quality.
While CRF offers a good overall consistency, the exact quality you get at a specific CRF does still vary by source, although not as much as other methods. Changing specific settings (like psy-rd)
or the preset you're using can change the quality at a given CRF. Usually the slower the preset, the higher the quality given a CRF.

Below is a list of rough CRF values to experiment with when targeting a specific quality. This is only rough as it is source and settings dependant as explained earlier.

| Quality        	| 720 	| 1080 	| 4k 	|
|----------------	|-----	|------	|----	|
| Transparent    	| 14  	| 16   	| 18 	|
| High Quality   	| 18  	| 22   	| 24 	|
| Medium Quality 	| 24  	| 26   	| 28 	|
| Low Quality    	| 28  	| 30   	| 32 	|

While not always consistent, x265 aims for an increase of 6 CRF or a decrease of 6 CRF to be a half or doubling of file size, respectively.

CRF is also preferable to other rate control methods due to its consistency in quality and being the most efficient mode of them all.

### `--bitrate`

`--bitrate` as the name implies, is used to specify the target ABR for 1-pass encoding or target bitrate for VBR in 2-pass+.

It is highly discouraged to use this rate control unless required, as it is less efficient than CRF and does not keep a consistent quality like CRF either.

## Threading

`--wpp` and `--frame-threads`

x265 possesses several threading features that each come with their own upsides and downsides when used.

### `--wpp`

`--wpp` or Wavefront Parallel Processing is the default method x265 uses to parallelize encoding first and foremost. With only an efficiency hit of 1-3% of the final encode, it increases threading of x265
by 3-5x. Unless you're using a tool like Av1an for maximum efficiency encoding, it is always recommended to have this setting on (default).

WPP works by splitting the video frame up into rows where the row is 2 CU, or super blocks in libvpx terms, behind the row above it. This allows the encoder to reference everything allowed by the
H.265 specification. Due to it not being single threaded, some optimizations cannot be done, resulting in a small efficiency loss.

### `--frame-threads`

`--frame-threads` is an extension of the idea of wpp across multiple frames being encoded concurrently. Similarly, this results in a further 1-3% efficiency loss, however it can boost threading 5-7x on top of wpp.

According to reports by some users in older versions of x265, the larger the number of frame threads, the worse the efficiency impact. However, in the latest version of x265 4.1, there is no difference
between 2 frame threads and the max 16 threads.

## B-frames

`--bframes`, `--b-adapt`, `--bframe-bias` and `--b-pyramid`

B-frames are bi-directional predictive frames. This means they can reference either past, future or both types of frames at the same time, making them one of the most efficient types. B-frames
however are usually the most compressed frame types. Referencing other frames rather than storing their own detail (typically) makes them often the worse quality and blurry frames. In total, we
have 4 different settings to control how they are used by the encoder. Usually, you will never touch these.

### `--bframes`

`--bframes` is used to control the max number of consecutive B-frames the encoder is allowed to use and search for. Generally, the larger this value is to a max of `16` the slower but more
efficient the encoder becomes. However, in higher fidelity encodes around CRF 18 or lower, beyond 8-12 B-frames can start to hurt detail for the reasons stated above. Likewise, the benefits of
more B-frames vs the time it takes makes it not typically worth it beyond a similar point.

In general, it is best to leave this setting at the default for your preset. However, for content like anime or otherwise flat non IRL, adding +2 B-frames to the current preset generally gives a
small efficiency boost. You can also set it to the max value of 16 for micro encodes to try and squeeze the most efficient possible out of the encoder, if time is no object to you.

### `--b-adapt`

`--b-adapt` controls the method that the encoder uses to decide where to put B-frames. It has 3 different modes.
| mode   | feature                    |
|--------|----------------------------|
| 1      | Fixed                      |
| 2      | Light lookahead            |
| 3      | Viterbi trellis (default)  |

It is always recommended to use 3 as it comes at a negligible speed penalty and is the smartest at placing B-frames for maximum efficiency without harming visual fidelity.

### `--bframe-bias`

`--bframe-bias` as the name implies, is used to control the bias for x265 to use B-frames over other frame types. Normally,you should never touch this setting as the default of `0` is already
optimal for most cases, however for high fidelity encodes or micro encodes, adjusting this bias can help retain detail or sacrifice spacial detail for better temporal information.

### `--b-pyramid`

`--b-pyramid` or `--no-b-pyramid` decides if B-frames can be used as reference frames for other B-frames or other frame types. Normally, this should always be on and is the default. However, for
high fidelity encodes, it might be worthwhile experimenting with turning it off only in limited use cases.

## Restoration Filtering

`--sao`, `--limit-sao`, `--no-sao` and `--deblock`

### `--sao`, `--limit-sao` and `--no-sao`

SAO or Sample Adaptive Offset is a restoration filter in H.265 used to prevent obvious blocking and ringing artifacts, especially around sharp edges.
However, this does sometimes come at the cost of some finer details in the video, like for example human skin and surface details, to be erased.
Generally speaking, at CRF values at or above 20, you can leave this option on, which is default as it does a good job of making the overall video more appealing.

x265 however has a primitive implementation of SAO which tends to be too aggressive at high quality or fidelity ranges, leading to blurring around CRF 19-16.
While it does "limit" how much the encoder uses SAO, `--limit-sao` is more of an early termination for the encoder deciding where to use it rather than limiting its strength.
However, it generally does a good job of preserving more detail than normal, even if it makes some artifacts more noticeable.

For below CRF 16, depending on your content, it might be preferable to outright disable sao with `--no-sao`, as usually at such high quality it's not usually needed.

### `--deblock`

Word of caution, the documentation around the deblock setting is esoteric.

Deblock is another loop filter, this one intended to reduce blocking in videos, but may have a blurring effect at high strengths. For most encodes, it is fine to leave this
at the default value. At lower CRF values, it may be desirable to lower this to `--deblock -1:-1` for anime or `--deblock -2:-2` for live action, in order to preserve
more grain and detail.

## Psycho-visual options

`--psy-rd`, `--psy-rdoq`, `--aq-mode` and `--aq-strength`

You can read more about the importance of perceptual optimization in video encoders on the [psychovisual](/start-here/psychovisual/) page.

### `--psy-rd` and `--psy-rdoq`

To make a long story short, `--psy-rd` and `--psy-rdoq` together are psychovisual optimization tools used to control the encoder's willingness to retain finer detail and noise in the
final encode. However, the way the two settings achieve this are very different.

`--psy-rd` retains detail by affecting how the encoder weights sections of the frame based off the amount of "energy" or high frequency information it contains and boosts them
accordingly.

`--psy-rdoq` retains detail by affecting how the encoder quantizes coefficients after transformations. It has no reference to the source in its calculation and only prefers retaining overall visual
energy and nothing specific.

Both settings are highly source dependent and ideally would be tweaked per scene in a video. Unless you know what you're doing and are willing to test thoroughly that the settings you
are using are beneficial, it's almost always recommended to never touch either setting, as the defaults for both are good general purpose settings.
However, as a general rule of thumb, `--psy-rd` is better at retaining specific detail and overall sharpness while `--psy-rdoq` is better at retaining overall noise.

### `--aq-mode` and `--aq-strength`

Adaptive quantization (`--aq-mode`), shortened to AQ, is a mechanism to redistribute bitrate within a frame to improve perceptual quality consistency.
In x265, we have 4 modes.
| mode | feature                                      |
|------|----------------------------------------------|
| 1    | AQ enabled                                   |
| 2    | AQ with auto variance (default)              |
| 3    | AQ 2 with a bias for dark scenes             |
| 4    | AQ 2 with edge information                   |

Generally speaking, we always want AQ 2 or AQ with auto variance as this will bias both parts of the frame that are smooth and textured. Normally, these parts of the frame are bitrate starved
and have the most noticeable artifacting.

Some people will use AQ 3 to, as the name implies, preserve detail in dark scenes and parts of the frame. However, in metric analysis and visual comparisons, AQ 3 can sometimes bloat bitrates for minor to
no gains. While this is not an entirely useless AQ mode, thorough testing should be done before using it.

The relative strength of an AQ mode can also be controlled with `--aq-strength`. While the default is `1.0`, many people do lower it to `0.7` or `0.8` for flat anime or compressed IRL content.
In general, like other psychovisual optimization tools in x265, these settings are highly source dependant and are best left at their defaults, unless you know what you are doing and have data
to back it up.

## CU-Tree

`--cutree` and `--no-cutree`

CU-Tree similar to MB-Tree in x264 is a method for the encoder to keep track of what parts of the frame are used or referenced by future frames. In a sense, it's a temporal motion quantizer.
It has been very common for a long time, all the way back when only x264 existed, for people to disable MB-Tree due to the idea that it removed too much detail or blurred the video.
However, a lot of that blur and detail loss would occur in parts of the frame that viewers would not be able to see clearly due to motion, or in areas that didn't significantly
contribute to the overall image quality during playback. Both MB-Tree and CU-tree have also gotten a lot better since their original implementation making it almost
always worse to disable them rather than to keep them enabled.

Anyone telling you to disable either must provide evidence of it being actually better.


title: x266

description: x266 is an upcoming software encoder for the H.266 / VVC codec. Very little is currently known about the encoder other than the fact it is still being developed by MulticoreWare and it's dedicated FAQ page after the 31st

markdown:
x266 is an upcoming software encoder for the [H.266 / VVC](/codecs/video/vvc/) codec. Very little is currently known about the encoder other than the fact it is still being developed by [MulticoreWare](https://multicorewareinc.com)
and it's dedicated FAQ page after the [31st January 2023 Webinar FAQ](https://multicorewareinc.com/faq-webinar/x266-faq.html).

According to their FAQ, H2 2023 is their "very rough and approximate" ETA for a v1.0 public release, but so far there have been no updates as of 14th October, 2024.


title: autocompressor

description: Autocompressor is a free online media compression tool by Auto-Rez Media Technologies that compresses videos, images, audio, and GIFs to a target file size. Depending on the file type you upload, it will be handled diffe

markdown:
[Autocompressor](https://autocompressor.net/) is a free online media compression tool by Auto-Rez Media Technologies that compresses videos, images, audio, and GIFs to a target file size. Depending on the file type you upload, it will be handled differently such that the result serves a similar function to what you uploaded. For example, videos are transcoded to videos, audio files to audio files, images to images, and animations to animations.

From their site:
> Reduce the file size of your video, image, audio, or GIF quickly and easily with our free online compression tool. Whether you need to shrink your file to 25MB or any other specific size, our tool offers a simple and intuitive solution. We'll also create perfectly compressed emotes and stickers for Discord. Using the link mode, you can instantly compress YouTube videos and other sites to 25MB. Our advanced AUTO-REZ™ technology achieves higher quality at a given filesize than any other website. Autocompressor will automatically choose the output format based on the input format and the compatibility category you select.

Autocompressor also plans to offer a premium service in the future where the cost is determined by the CPU minutes used during the operation as well as the compression effort tier. For instance, encoding a typical 4-minute YouTube video to 8MB with MP4-Normal will cost about 5 CPU minutes.

Users can create an account to get 1800 CPU minutes free. The site ensures high security for user data by using BCrypt hashes to store passwords.

You can read more on their [About page](https://autocompressor.net/about).


title: Av1an

text: Prerequisites

anchor: prerequisites

text: Installation

anchor: installation

text: Windows

anchor: windows

text: Script

anchor: script

text: Pre-built Binary

anchor: pre-built-binary

text: Compile from Source

anchor: compile-from-source

text: macOS

anchor: macos

text: Using MacPorts

anchor: using-macports

text: Compile from Source

text: Linux

anchor: linux

text: Package Managers

anchor: package-managers

text: Compile from Source

text: Docker

anchor: docker

text: Installing Dependencies

anchor: installing-dependencies

text: Troubleshooting

anchor: troubleshooting

markdown:
# Av1an

<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/codec-wiki/main/static/img/av1an_96_workers.avif" type="image/avif" />

</picture>

Av1an is a video encoding framework. It can increase your encoding speed and improve CPU utilization by running multiple encoder processes in parallel. Target quality, VMAF plotting, and more, available to take advantage for video encoding.

The only downside to this, is that RAM usage increases significantly with each "worker" you add, so if you have a low amount of RAM (< 8GB), this might not be that useful to you.
> **Caution — Av1an does not ship with any dependencies except for it's Docker image, so you will have to provide them on your own..**
>
>
## Prerequisites

You will need Python, [FFmpeg](/tools/utilities/ffmpeg/) and [Vapoursynth](/tools/filtering/vapoursynth/) to be installed regardless of your current operating system.
## Installation

### Windows

#### Script
Windows users can use this [script](https://github.com/Hishiro64/av1an-win-script) which installs everything needed in a single portable folder. Do note that you will need to update the dependencies manually once installed.

#### Pre-built Binary
Av1an is available as a pre-built binary under the "[latest](https://github.com/master-of-zen/Av1an/releases/tag/latest)" tag on GitHub releases, you can simply download that and place it wherever you want.

#### Compile from Source
To compile from source, it is easier to use mingw-w64 which comes with [MSYS2](https://msys2.org). Once installed, open MinGW64 and run the following:
```bash
pacman -Syuu && pacman -S cmake git nasm python3 mingw-w64-x86_64-gcc mingw-w64-x86_64-cmake base-devel mingw-w64-x86_64-ffmpeg mingw-w64-x86_64-rust mingw-w64-x86_64-lld mingw-w64-x86_64-clang mingw-w64-x86_64-make
```

Then, before you do anything further. Download Vapoursynth **portable** (`VapourSynth64-Portable-RXX.7z`) from its GitHub [release page](https://github.com/vapoursynth/vapoursynth/releases). Make sure the version you chose is compatible with the current MinGW64 Python version. For example, R65 supports 3.8 and 3.11, the version from Pacman (currently) is 3.11, so you should choose that.

After downloading, open the 7z file and head to `\sdk\lib64`, copy all the libraries from there to MinGW64's `lib` directory, this usually resides in `C:\msys64\mingw64\lib`.

Now finally, resume your session and run the following:
```bash
git clone https://github.com/master-of-zen/Av1an
cd Av1an
RUSTFLAGS="-C target-cpu=native" cargo build --release
```

The binary will be available in `C:\msys64\home\USER\Av1an\target\release`. The `USER` part is your Windows username.

### macOS

#### Using MacPorts
Av1an is available in the MacPorts repository, to install just simply run:
```bash
port install av1an
```

#### Compile from Source
You need to have Git, Nasm, and Rust to be installed first. You can achieve this by using [Homebrew](https://brew.sh/) or similar.
```bash
git clone https://github.com/master-of-zen/Av1an
cd Av1an
RUSTFLAGS="-C target-cpu=native" cargo build --release
```
Binary is located in `Av1an/target/release`, you can optionally place it somewhere like `/usr/local/bin`.

### Linux

#### Package Managers
Av1an is available in the package manager of some distributions such as Arch Linux. If not, you can skip to the next part every Linux user is familiar with.

#### Compile from Source
Just like macOS, you need to have Git, Nasm, and Rust to be installed. Can be achieved by either using your package manager or Rustup for Rust.
```bash
git clone https://github.com/master-of-zen/Av1an.git
cd Av1an
RUSTFLAGS="-C target-cpu=native" cargo build --release
```
Binary is located in `Av1an/target/release`, you can optionally place it somewhere like `/usr/local/bin` or `/usr/bin`.

### Docker
The following examples assume the file you want to encode is in your current working directory.

  #### Windows

```bash
   docker run --privileged -v "$(pwd):/videos" --user $(id -u):$(id -g) -it --rm masterofzen/av1an:latest -i S01E01.mkv {options}
   ```
  #### Linux

```bash
   docker run --privileged -v "${PWD}:/videos" -it --rm masterofzen/av1an:latest -i S01E01.mkv {options}
   ```
  #### Manual Build

```bash
   docker build -t "av1an" .
   ```
   Run in the root directory of the repository. The dependencies will automatically be installed into the image, no manual installations necessary.

> **Note — To specify a different directory to use you would replace $(pwd) with the directory.**
>
> ```bash
> docker run --privileged -v "/c/Users/masterofzen/Videos":/videos --user $(id -u):$(id -g) -it --rm masterofzen/av1an:latest -i S01E01.mkv {options}
> ```
>
> The ``--user`` flag is required on Linux to avoid permission issues with the docker container not being able to write to the location, if you get permission issues ensure your user has access to the folder that you are using to encode.
> **Caution — The Docker image ships with the default dependencies..**
>
>
## Installing Dependencies

You will need a chunk method installed as the built-in ones are very slow.

## Troubleshooting

### "Error: The file 'XXXXX.ivf' could not be opened for reading: open file error." with mkvmerge on Linux
Since mkvmerge opens all the encoded chunks at once, this obviously hits the default open file descriptor limit of 1024 on longer videos.
You can temporarily increase it with `ulimit -n 20000` to allow opening 20,000 files at once in that session.

### Gray screen flashing for a single frame in output
This is a unique problem with Av1an. Since Av1an does random seeking for chunks, traditional keyframe-based decoding methods
such as L-SMASH and FFMS2 may fail and result in a gray frame. There are currently only two known methods to solve this:

1. Create a lossless intermediary with x264 `-qp 0`, this always fixes all related seeking issues but will result in a huge file due to it's lossless nature.
2. Using a linear-decoding chunk method such as `bestsource`, the downside to this is it's mega slow. Tests shown encode speeds drop by a whopping 10-15x slower.
3. Using `dgdecnv` chunk method. `dgdecnv` and `DGIndexNV` is a proprietary CUVID-accelerated Vapoursynth "Source" decoder created by [Donald Alan Graft](https://www.rationalqm.us/) where `DGIndexNV` is the standalone program for seeking and `dgdecnv` is the Vapoursynth plugin itself.
It is especially made with random seeking in mind which makes it perfect for Av1an. Only downside is you need an NVIDIA GPU and `DGIndexNV` only supports x86_64 platforms.


title: av1an-command-gen

description: Av1an Command Generator is a rudimentary tool for easily generating Av1an commands for AV1 encoding. It is written in the Zig programming language. It is very similar to rAV1ator CLI in the sense that it can produce Av1a

text: Av1an Command Generator

text: Description

anchor: description

text: Usage

anchor: usage

text: Examples

anchor: examples

text: Installation

text: License

anchor: license

markdown:
# Av1an Command Generator

Av1an Command Generator is a rudimentary tool for easily generating Av1an commands for AV1 encoding. It is written in the Zig programming language. It is very similar to [rAV1ator CLI](/tools/utilities/rav1ator-cli/) in the sense that it can produce Av1an commands based on user input.

[GitHub Link](https://github.com/gianni-rosato/av1an-command-gen/)

## Description

Av1an Command Generator is designed for beginners, although experienced encoders can use it to speed up their Av1an scripting. The program generates an AV1 video encoding command for use with [Av1an](/tools/utilities/av1an/), a chunked video encoding tool that can be used with [aomenc](/tools/software-encoders/aomenc/), [SVT-AV1](/tools/software-encoders/svt-av1/), and [rav1e](/tools/software-encoders/rav1e/).

This tool takes in the video resolution, frame rate, desired encoder, speed preset, and target bitrate range as command line arguments. Based on these parameters, it calculates settings like tile columns/rows, lag-in-frames, CRF, and encoder speed preset. Then, it injects these into a generated encoding command string.

The output is a full `av1an` command that can be run to encode a video based on the specified settings.

## Usage

```bash
av1an-command-gen [width] [height] [fps] [encoder] [speed] [bitrate_target]
```

- `width` - Input video width in pixels
- `height` - Input video height in pixels
- `fps` - Input video frame rate
- `encoder` - `aom`, `svt`, or `rav1e`
- `speed` - `slower`, `slow`, `med`, `fast`, `faster`
- `bitrate_target` - `lowest`, `low`, `med`, `high`

## Examples

Generate a command for encoding a 1280x720 video at 24 fps using rav1e at 'med' speed and 'low' bitrate target:

```bash
av1an-command-gen 1280 720 24 rav1e med low
```

Generate a command for encoding a 1920x1080 video at 30 fps using svt-av1 at 'fast' speed and 'high' bitrate target:

```bash
av1an-command-gen 1920 1080 30 svt fast high
```

## Installation

This program requires the [Zig](https://ziglang.org/) v0.11.0 programming language.

To build:

```bash
zig build
```

This will produce a standalone binary `av1an-command-gen` in `zig-out/bin/`.

## License

This project is licensed under the BSD 3-Clause License.