collection: articles

title: AV1 Encoding for Dummies

status: needs-review

license: CC BY-SA 4.0

authors: simulping gianni

title: Original Codec Wiki article

text: Installing the Tools

anchor: installing-the-tools

text: Microsoft Windows

anchor: microsoft-windows

text: The GUI Way

anchor: the-gui-way

text: The WSL2 Way

text: The Automated Way

anchor: the-automated-way

text: The Manual Way

anchor: the-manual-way

text: macOS

anchor: macos

text: Linux

anchor: linux

text: The GUI Way

text: The TUI Way

anchor: the-tui-way

text: The Compiling Route

anchor: the-compiling-route

text: Ubuntu

anchor: ubuntu

text: Arch

anchor: arch

text: Compiling aom-av1-lavish

text: Encoding

anchor: encoding

text: Merging Everything

anchor: merging-everything

text: Tips & Tricks

anchor: tips-tricks

text: Final Thoughts

anchor: final-thoughts

contentFormat: markdown

markdown:
This guide will show you how to encode in AV1 the *right* and *optimal* way. Yes, you using standalone ``libaom``, ``libsvtav1``, and ``librav1e`` from FFmpeg or even piping ``yuv4mpeg`` into **mainline** aomenc are all unoptimal.

> **Danger — Outdated Information.**
>
> While a lot of the information presented in this guide is still relevant and correct, the AV1 ecosystem has changed dramatically since this guide's inception which has demanded a rewrite. Please see the [AV1 for Dummies](/articles/av1-for-dummies/) blog post for more information.
![Compare](/img/compare-guide.webp)

In this guide, we'll be installing Av1an for chunked encoding and infinite threading, because the current state of AV1 encoders, except for [SVT-AV1](/tools/software-encoders/svt-av1/), unfortunately lacks threading and will only use very low amount of cores, which hampers speeds. The only caveat to this approach is **RAM consumption**, encoding 2160p (4K) with [aomenc](/tools/software-encoders/aomenc/) with 4 workers could take upwards of **16GB** of RAM! So do keep this in mind.

## Installing the Tools

Given all of the different operating systems that people use on a day to day basis and the various different encoding workflows that exist, there are a number of ways to do this.

**Jump to**: [Windows](#microsoft-windows) | [macOS](#macos) | [Linux](#linux)

## Microsoft Windows

### The GUI Way
1. Install [NMKODER](https://github.com/n00mkrad/nmkoder) which is a GUI front-end to av1an with all dependencies installed.
2. You're done, you can skip to the encoding part

> **Danger — Almost abandonware.**
>
> Since Nmkoder already ships everything by default and its last release was 29th March 2022. You need to manually update all encoders and tools to get better encoding speeds. Missing out on updates will result in your encodes being sub-optimal.
### The WSL2 Way

*(Recommended)*

If you're not already familiar with WSL2, the The Windows Subsystem for Linux (WSL) is a feature of the Windows operating system that allows you to run a Linux file system, along with Linux command-line tools and GUI apps, directly on Windows. This lets Linux distributions run on bare metal without managing any virtual machines, so encoding performance is very good.

The easiest way to encode with WSL2 is to use [rAV1ator CLI](/tools/utilities/rav1ator-cli/), an interactive TUI for [Av1an](/tools/utilities/av1an/). An ArchWSL2 installation tutorial is provided [here](/tools/utilities/rav1ator-cli/#windows).

### The Automated Way

There is now a batch script for automating the install process, which can be found [here](https://github.com/Hishiro64/av1an-win-script). The instructions are in the README file.

> **Caution — The script will download outdated version encoders and tools such as `aom-av1-psy` and MKVToolNix v76.0, if you are fine with these you can proceed..**
>
>
### The Manual Way

1. Install **Python 3.10.x, this will change so consult from the** [Vapoursynth website](http://www.vapoursynth.com/doc/installation.html) **if you're reading this from the future** from [here](https://www.python.org/downloads/windows/) and select "Windows Installer 64-bit". Upon installation check the tick for adding Python to PATH like so
![Python PATH](/img/python-path.webp))

2. Download and install Vapoursynth from [here](https://github.com/vapoursynth/vapoursynth/releases) and select "VapourSynth64-RXX.exe"
3. Open the terminal and type ``vsrepo.py install lsmas ffms2`` to install some plugins for Av1an to work.
4. Download MKVToolNix from [here](https://mkvtoolnix.download/downloads.html#windows), select "mkvtoolnix-64bit-XX.X.X-setup.exe", and install **(Also available on winget!)**
5. Download Av1an from [here](https://github.com/master-of-zen/Av1an/releases) (SELECT LATEST AND CLICK THE "ASSETS" DROPDOWN)
6. Download **shared libraries** FFmpeg from [gyan.dev](https://www.gyan.dev/ffmpeg/builds)
7. Download or build the Aomenc fork [aom-av1-lavish](https://github.com/Clybius/aom-av1-lavish/tree/Endless_Merging), which has features such as different defaults, tunes, and optimizations. The Windows binary linked by the original September 2023 guide is no longer available; check the project or AV1 community channels for a current build.
> **Info — If you opt to compile aomenc yourself, you can view the instructions on how to do that [here](/tools/software-encoders/aomenc/#installation)..**
>
>
8. Move Av1an, FFmpeg **(Including the FFmpeg DLLs)**, and aomenc to somewhere preferable, eg ``C:\Encoding``.
9. Add the folder **AND MKVTOOLNIX INSTALLATION FOLDER** to the [Windows PATH environment](https://www.maketecheasier.com/what-is-the-windows-path/).

## macOS

macOS is very similar to Linux, although there aren't any GUI tools for AV1 encoding that I can comfortably recommend.

**Homebrew + Macports for Av1an + rav1e:**
*Note that some commands may have to be run with `sudo`, which I won't explicitly include for security reasons.*

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

As is installing MacPorts. Install the relevent `.pkg` for your macOS version from the MacPorts Project website:
[www.macports.org/install.php](https://www.macports.org/install.php)

Now, you can run the following commands:
```bash
brew update && brew upgrade
brew install rav1e aom mkvtoolnix ffmpeg
# Usually you must run MacPorts commands for package installations as root
port upgrade outdated
port install av1an
```

This is the easiest way to get everything set up & working to produce AV1 video with `rav1e` or mainline `aomenc` & Av1an. You can check that things are installed by running the following commands & parsing their output:
```bash
% av1an --version
av1an 0.4.1-unstable (rev e10880d) (Release)

* Compiler
  rustc 1.70.0 (LLVM 16.0)

* Target Triple
  aarch64-apple-darwin

* Date Info
  Commit Date:  2023-06-25

* VapourSynth Plugins
  systems.innocent.lsmas : Not found
  com.vapoursynth.ffms2  : Not found
```
```bash
% rav1e --version | grep "release" -C 1
rav1e 0.6.6 () (release)
rustc 1.69.0 (84c898d65 2023-04-16) (built from a source tarball) aarch64-apple-darwin
```
```bash
% aomenc --help | grep "AOMedia" -C 3

Included encoders:

    av1    - AOMedia Project AV1 Encoder 3.6.1 (default)

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

Notice `systems.innocent.lsmas : Not found` in the Av1an output. This means you won't be able to use the lsmash chunking method through vapoursynth & may instead have to rely on hybrid chunking, through `-m hybrid`. This is slower & takes up disk space while encoding, but still works. A sample Av1an command with this basic installation may look like this:

```bash
av1an -i "input" -y --resume --verbose --split-method av-scenechange -m hybrid -c mkvmerge -e rav1e --force -v " --tiles 8 -s 4 --quantizer 80 --no-scene-detection" --photon-noise 7 --chroma-noise --pix-format yuv420p10le -w 8 -o "output.mkv"
```

**Building From Source**

If you want lsmash support, aom-av1-lavish instead of mainline, or anything else that isn't covered by the more basic installation, you'll have to compile from source. Things are very similar to Linux, with a few oddities:

- macOS sometimes doesn't have a `/usr/local/bin` by default. You can fix this by doing `mkdir /usr/local/bin`.
- Homebrew installs *everything* in its own directory structure. If you're building things from source that rely on libraries from vapoursynth, zimg, lsmash, etc, make sure to copy them from `/opt/homebrew/lib` to `/usr/local/lib`. Finding them is a matter of `ls | grep "keyword"` & copying what looks reasonable to be associated with the tool you're using.
- Building most things from source will have instructions for \*nix which work for both macOS & Linux. Even if it says Linux, there's a good chance it'll work on macOS as well, & it is always worth trying Linux build instructions on Mac. I won't be going through building every encoding tool & dependency from source, as it is generally much more intuitive than Windows, but building Av1an is worth detailing here just as an example.
```bash
brew install git rust nasm
git clone https://github.com/master-of-zen/Av1an
cd Av1an
RUSTFLAGS="-C target-cpu=native" cargo build --release
cd .. && cd target/release
cp av1an /usr/local/bin
```

**More Difficult: Building aom-av1-lavish from Source**

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

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

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

Included encoders:

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

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

Notice how it says `AOMedia Project AV1 Encoder Psy` instead of `AOMedia Project AV1 Encoder`. You should be all set after this to start using aom-av1-lavish & following the current parameter meta as outlined below.

## Linux

> **Info — Yet again, try using Arch. It's way easier..**
>
>
### The GUI Way

- Install [Aviator](https://github.com/gianni-rosato/aviator) ([SVT-AV1](/tools/software-encoders/svt-av1/) + [FFmpeg](/tools/utilities/ffmpeg/)) or [rAV1ator](https://giannirosato.com/blog/post/aviator-1/) basically same thing but [Av1an](/tools/utilities/av1an/) + [rav1e](/tools/software-encoders/rav1e/). Both are only available as [Flatpaks](https://beta.flathub.org/apps/net.natesales.Aviator). Keep in mind Aviator ships with **SVT-AV1** and rAV1ator with **rav1e** instead of aomenc/AOM-AV1, which I will not be covering here.

### The TUI Way

*(Recommended)*

- Install [rav1ator-cli](/tools/utilities/rav1ator-cli/), a TUI for using Av1an meant to be easy to use. Much more flexible than the GUI options & can work with a number of encoders. See [this page](/tools/utilities/rav1ator-cli/#installation) for more info. Can be easily used on any distro.

### The Compiling Route

#### Ubuntu

The guide below is targeted towards 22.04, packages and other things may be different on other versions. First Install Rust via `rustup` first, as apt version of Rust is severely outdated, then you can continue.

Install dependencies:
```bash
sudo apt install wget python unzip unrar build-essential meson autoconf automake libtool git nasm yasm python3-dev python3-pip cython3 libass-dev libqt5websockets5-dev libfftw3-dev libtesseract-dev ffmpeg libavcodec-dev libavformat-dev libswscale-dev libavutil-dev libswresample-dev libmediainfo-dev mkvtoolnix mediainfo perl nasm yasm git cmake libavutil-dev libavcodec-dev libavformat-dev libavdevice-dev libavfilter-dev libswscale-dev libswresample-dev libpostproc-dev llvm libclang-dev libssl-dev
```

Install l-smash:
```bash
git clone https://github.com/l-smash/l-smash.git
cd l-smash
./configure --enable-shared --extra-cflags="-march=native"
make -j$(nproc)
sudo make install
```

Install zimg:
```bash
git clone --recursive https://github.com/sekrit-twc/zimg.git
cd zimg
./autogen.sh
./configure
make -j$(nproc)
sudo make install
```

Install ImageMagick:
```bash
git clone https://github.com/ImageMagick/ImageMagick
cd ImageMagick
./configure
make -j$(nproc)
sudo make install
```

Install Vapoursynth R63:
```bash
wget https://github.com/vapoursynth/vapoursynth/archive/refs/tags/R63.zip
unzip R63.zip
cd vapoursynth-R63
./autogen.sh
./configure CFLAGS="-march=native" CXXFLAGS="-march=native" --libdir=/usr/lib
make -j$(nproc)
sudo make install
sudo mkdir /usr/lib/vapoursynth
sudo ldconfig
```
The plugin directory will be located in `/usr/lib/vapoursynth`.

Install L-SMASH-Works Vapoursynth Plugin:
```bash
git clone https://github.com/AkarinVS/L-SMASH-Works -b ffmpeg-4.5
cd L-SMASH-Works/VapourSynth && mkdir build && cd build
meson .. --optimization=3 --default-library=static -Db_lto=true -Dc_args="-march=native" -Dcpp_args="-march=native"
ninja -j$(nproc)
sudo cp libvslsmashsource.so /usr/lib/vapoursynth/
```

> **Danger — L-SMASH-Works doesn't work on **aarch64**, it is recommended to use other plugins instead..**
>
>
Install FFMS2 Vapoursynth Plugin:
```bash
git clone https://github.com/FFMS/ffms2
cd ffms2
./autogen.sh
./configure CFLAGS="-O3 -march=native" CXXFLAGS="-O3 -march=native"
make -j$(nproc)
sudo cp src/core/.libs/libffms2.so src/core/.libs/libffms2.so.5 src/core/.libs/libffms2.so.5.0.0 /usr/lib/vapoursynth
```

Install Av1an:
```bash
git clone https://github.com/master-of-zen/Av1an
cd Av1an
RUSTFLAGS="-C target-cpu=native" cargo build --release
sudo cp target/release/av1an /usr/local/bin
```

When there's no errors, proceed to compiling `aom-av1-lavish`.

### Arch

Install dependencies:
```bash
sudo pacman -S vapoursynth ffmpeg av1an mkvtoolnix-gui git perl cmake ninja meson nasm vapoursynth-plugin-lsmashsource ffms2
```

you're done, proceed.

#### Compiling aom-av1-lavish
``` bash
git clone https://github.com/Clybius/aom-av1-lavish -b Endless_Merging
cd aom-av1-lavish && mkdir -p aom_build && cd aom_build
cmake .. -DBUILD_SHARED_LIBS=0 -DENABLE_DOCS=0 -DCONFIG_TUNE_BUTTERAUGLI=0 -DCONFIG_TUNE_VMAF=0 -DCONFIG_AV1_DECODER=0 -DENABLE_TESTS=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS="-flto -O3 -march=native -pipe -fno-plt"
make -j$(nproc)
sudo make install
```

## Encoding

The moment you've all been waiting for, let's just get into it. Here's an example *recommended* parameter as of now (09/03/23) [MM/DD/YY]:
```bash
av1an -x 300 -i input.mkv -w 4 -e aom -c mkvmerge --resume -m lsmash --photon-noise=10 --set-thread-affinity=2 --verbose -a " -an " -f " -an " -v " --bit-depth=10 --cpu-used=4 --end-usage=q --cq-level=24 --threads=2 --tile-columns=0 --tile-rows=0 --lag-in-frames=64 --tune-content=psy --tune=ssim --enable-keyframe-filtering=1 --disable-kf --kf-max-dist=9999 --enable-qm=1 --deltaq-mode=0 --aq-mode=0 --quant-b-adapt=1 --enable-fwd-kf=0 --arnr-strength=1 --sb-size=dynamic --enable-dnl-denoising=0 " -o "output.mkv"
```

> **Info — Parameter Meta.**
>
> It is strongly recommended to join the [AV1 Discord server](https://discord.gg/vpREHAvYvh) to get the latest updates on what to use and which to set, as it's the only easily reachable place for everything AV1 & encoding tips in general.
Now let's dissect it one-by-one

**Av1an parameters:**

- ``-i`` Input.

- ``-x 300`` Sets scene split length to 300 frames, you can increase it for more quality at the tradeoff of video seekability.

- ``-w 4`` Specifies the amount of "workers" or amount of encoders working on the video.

- ``--verbose`` Sets logging to verbose.

- ``--resume`` Resumes the encode even when you haven't encoded yet. I strongly recommend leaving this if you resume a lot since you can accidentally delete your whole progress (There's no delete confirmation feature.. yet) if you "resumed" without the parameter in place.

- ``-e aom`` Specifies we're using aomenc encoder which should be the default option.

- ``-c mkvmerge`` Specifies we're using mkvmerge (MKVToolNix) to concatenate the parts when done, you can specify with ffmpeg if you want to but this is the best method.

- ``-m lsmash`` Specifies we're using l-smash (Vapoursynth plugin) to split the videos, this is also the best method because ffms2 causes video lag (Tested a year ago, might change now) and other methods just suck (Slow and not worth it, learned the hard way). You can attempt to use ffms2 when inputting VC-1 videos as it is not possible with l-smash (Or convert it to lossless with x264 qp 0).

- ``-f " -an "`` ``-f`` Stands for ffmpeg parameters, ``-an`` is to remove all audio since its better to encode and merge it separately. To crop use ``-f " -an -vf crop=1920:800 "`` for example to crop the video to 1920x800.

- ``-v " "`` Is where you put the encoder's parameters in.

- ``-a " -an "`` FFmpeg audio encoding options, we're removing it cause we can always add it later. But if you want to, you can also encode directly. Here's an example for encoding to Opus using libopus assuming stereo: `-a " -c:a libopus -b:a 128k "`.

- ``--photon-noise=10`` AV1 grain synthesis, which is a technique where the encoder puts fake grain in so it looks more natural and potentially hiding video artifacts (cause grain is hard to encode and explodes bitrate usage because of their randomness), 5-8 for almost none to little grain, 10-14 for medium, 15+ heavy, 20+ extremely heavy, 30+ for extremely grainy 90s live action films.

- ``--set-thread-affinity=2`` Pins the thread to the encoder, aligns with ``--threads=2`` in the encoder parameter so set them accordingly.

**aomenc parameters:**
- ``--bit-depth=10`` We're using 10bit because it makes the video smaller and reduces [banding](https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs#contouring).

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

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

- `--threads=2` Sets the amount of threads the encoder can use, aligns with `--set-thread-affinity` in Av1an.

- ``--tile-columns=0 --tile-rows=0`` This is the tiles options, where the encoder splits the videos into tiles to encode faster, see the image below (Yellow lines):
<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/tiling_av1.avif?token=GHSAT0AAAAAACEZPDXIZARY5MGSTJW4SI22ZHY636A" type="image/avif" />
    <img src="https://autumn.revolt.chat/attachments/HwhZjoDsdzLZsJM2mjzX7lEDmJn1xcYNdrQqmOxPYW/tiling_av1.jpeg" alt="Tiling" width="1280" height="768" loading="lazy" />
</picture>

> **Note — Tile usage.**
>
> Do NOT use tiles for 1080p and below, use 1 ``tile-columns`` at 1440p (2K), 2 ``tile-columns`` and 1 ``tile-rows`` for 2160p (4K)
- ``--lag-in-frames=64`` Similar to x264/x265 `rc-lookahead`. Sets a number of frames to look ahead for frametype and ratecontrol, allowing for better compression decision making. Setting to a value greater than 64 is generally not considered useful.

- ``--aq-mode`` adaptive quantization mode, 0 is better most of the time

- ``--tune-content=psy --tune=ssim`` As the name suggests they are tunes that affect the video output, for the better, and for the worst

> **Info — Tunes to use.**
>
> Set ``tune-content`` to ``animation`` if you're encoding above ``cq-level=30`` A.K.A lower quality, despite it's name
> Set ``tune-content`` to ``psy`` for everything else, **do not use if you encode above ``cq-level=30``**
> For ``tune``, this is a bit tricky. For now, the meta seems to be ``ssim``, but back then it was ``lavish`` which is considered THE best tune because it's based on [butteraugli](https://github.com/google/butteraugli). Now it's fallen behind because its more blurry than ``ssim``, and before that it was ``butteraugli``, and then ``ipq_vmaf_psy``, and finally just ``ipq``.
> If you use any of the VMAF tunes, **you need to specify ``--vmaf-model-path=`` to where you put it**.
- ``--enable-keyframe-filtering=1`` We're setting it to 1 because of compatibility reasons, 2 is more efficient but there are seeking issues and FFmpeg for some reason can't input it.

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

- ``--deltaq-mode`` set to 0 because its just better.

- ``--arnr-strength=1`` Controls how strong the filtering will be, 1 is good for 3D Pixar CGI-like and 2D animation, use 4 if you're doing live action content. Using maximum at higher bitrates would just result in a blurry mess.

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

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

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

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

> **Info — Concatenation Error on Linux.**
>
> Run ``ulimit -n 200000``, resume, and it should concatenate just fine. If it still errors, head to the encode directory > encode, and run ``mkvmerge @../options.json``
## Merging Everything

Once you're done just encode your audio using ffmpeg (or just passthrough it), subtitles should be carried along with your video output, and merge them in MKVToolNix! Don't want Matroska files? That's fine, you can use FFmpeg or MP4Box to output into `mp4`, just keep in mind that PGS/SUP/VOBSUB subtitles are not supported and Opus audio support is still experimental.

## Tips & Tricks

- `--denoise-noise-level=10` Alternative to `photon-noise`, slower than photon-noise and is the OG grain synthesis method, performs okay and just serves as an alternative. Don't attempt to use it at high values (>12) since it creates noticeable grain patterns.

- `--arnr-maxframes` to set max reference frames that will be used to filter the encode, higher values would make the video blurrier at high fidelity but look better at lower bitrates.

- `--butteraugli-resize-factor=2` if you use any of the butteraugli-based tunes (lavish, butteraugli) to speed it up without much losses and `--butteraugli-intensity-target=250` to match the content light level.

## Final Thoughts

Encoding has always been about experimentation for the best, there is really no "One size fits all" for encoding content, as they differ from scene complexity, how it's captured (2D/Real life), film grain, dark scenes, etc. So experiment away for your specific type of content!

> **Guide originally hosted on https://rentry.co/AV1, rewrite and migration by Simulping.**


title: AV1 for Dummies

authors: gianni simulping

title: Original Codec Wiki article

text: Introduction

anchor: introduction

text: Why AV1?

text: Do's & Don'ts

anchor: dos-donts

text: Tools

anchor: tools

text: GUI

anchor: gui

text: CLI

anchor: cli

text: Conclusion

anchor: conclusion

text: Encoders

anchor: encoders

text: aomenc (libaom)

anchor: aomenc-libaom

text: Conclusion

text: Final Conclusion

anchor: final-conclusion

markdown:
AV1 for Dummies is a comprehensive, legible guide on how to get started with AV1 at any experience level. Whether you're on Windows using your first video encoding program, or a seasoned Linux user looking to optimize your encoding pipeline, this guide has you covered.

![Compare](/img/av1_for_dummies_guide.avif)

## Introduction

[AV1](/codecs/video/av1/) is a royalty-free video codec developed by the Alliance for Open Media. It is designed to replace [VP9](/codecs/video/vp9/) and presently competes with [H.266](/codecs/video/vvc/). AV1 is known for its high compression efficiency, which the marketing will have you believe reduces file sizes by up to 50% compared to [H.264](/codecs/video/avc/) and up to 30% compared to [H.265](/codecs/video/hevc/) across the board. It is supported by several major browsers and is widely used across many streaming services and video platforms.

### Why AV1?

Before we dive in, it is important to understand *why* you may want to use AV1 instead of other codecs. The reality is that AV1 is *not* better than H.264/5 in every single scenario; video encoding is a complicated field, and the best codec for you will depend on your specific needs. AV1 excels in:
- Low to medium-high fidelity encoding
- Higher resolution encoding
- Encoding content with very little grain or noise
- Slow, non-realtime contexts (e.g. offline encoding)

The enumeration above still consists of broad strokes, but the point is to understand that AV1 is not a silver bullet. It will not automatically make your videos smaller while preserving your desired quality. To make things more difficult, the [x264](/tools/software-encoders/x264/) & [x265](/tools/software-encoders/x265/) encoders are very mature, while AV1 encoding efforts designed to meet the extremely complicated needs of the human eye are still in their infancy.

This guide focuses almost entirely on tools great for offline, non-realtime encoding for various kinds of content. Streaming is an altogether different application of AV1, and is only covered sparsely here.

### Do's & Don'ts

Due to a lot of misunderstandings about codecs and compression, there are a lot of common misconceptions that are held regarding video encoding. We'll start by outlining some bad practices:

- **Don't** encode the same video multiple times. This is a common mistake made by people new to video encoding. Every time you encode a video, you lose additional quality due to *generation loss*. This is because video codecs are lossy, and every time you encode a video, you lose more information. This is why it is important to keep the original video file if you frequently re-encode it.
- **Don't** blindly copy settings from others without understanding them. What works for one person's content and workflow may not work for yours. Even the default settings on many encoders are not optimal for most content.
- **Don't** assume that higher bitrate equates to better quality. Inefficient encoding can waste bits without improving visual quality, and efficient encoding can make lower bitrate video look drastically better than higher bitrate video using the same codec.
- **Don't** assume all encoders/presets/settings/implementations are created equal. Even given two encoding frameworks that use the same underlying encoder, you may achieve different results given encoder version mismatches or subtly different settings used under the hood.
- **Don't** use unnecessarily slow presets/speeds unless you have a specific need and ample time. While slower presets improve encoding efficiency most of the time, the quality gains reach a point of diminishing returns beyond a certain point. Use the slowest preset you can tolerate, not the slowest preset available.
- **Don't** blindly trust metric scores. It is unfortunate how trusted [VMAF](/reference/metrics/vmaf/) is considering how infrequently it correlates with visual fidelity in practice now that it has become so popular. Even the beloved [SSIMULACRA2](/reference/metrics/ssimulacra2/) is not a perfect one-to-one with the human eye.

Now, let's move on to some **good** practices:
- Experiment with different settings and compare the results.
- Consider your content type when choosing encoding settings. Film, animation, and sports all have different characteristics that benefit from distinct approaches.
- Try to use CRF for offline encoding, as opposed to CBR or VBR. While the latter two are effective for precisely targeting a particular bitrate, CRF is more effective at targeting a specific quality level efficiently.
- Always use 10-bit color, even with an 8-bit source. AV1's internal workings are much more suited to 10-bit color, and you are almost always guaranteed quality improvements with zero compatibility penalty as 10-bit color is part of AV1's baseline profile.
- Consider using grain synthesis for grainy content, as AV1 can struggle with preserving film grain efficiently.
- Keep your encoding software up-to-date; the encoding world moves quickly.

## Tools

Since writing the last guide, there are now several versatile tools available for AV1 encoding. Below, we've assembled some tables of popular encoding tools and their features.

### GUI

Here's the key:
- **Encoder(s)**: The AV1 encoder(s) the software uses or is able to use. This is between [SVT-AV1](/tools/software-encoders/svt-av1/), [aomenc](/tools/software-encoders/aomenc/), [rav1e](/tools/software-encoders/rav1e/), [SVT-AV1-PSY](/tools/software-encoders/svt-av1-psy/), and various aomenc forks. We'll get into this more later.
- **Ease of Use**: How intuitive the software is, especially for beginners.
- **Complexity**: How flexible the software can be for advanced users.
- **Efficiency**: How "good" the underlying encoder(s) are. This is more subjective, but tools with bad defaults, misleading options, or slow release cycles won't score well here.

| Name    | Platform(s) | Encoder(s) | Ease of Use | Complexity | Efficiency  |
|---------|-------------|:----------:|:-----------:|:-----------:|------------|
| [Aviator](/tools/utilities/aviator/) | Linux       | SVT-AV1-PSY| ●●●●●       | ●○○○○         | ●●●●●     |
| [NMKODER](/tools/utilities/nmkoder/) | Windows     | Any        | ●●●○○       | ●●●●○         | ●●○○○     |
| [Av1ation Station](https://github.com/Av1ation-Association/Av1ation-Creations/releases/) | Any | Any       | ●●●○○       | ●●●●●         | ●●●●○     |
| [StaxRip](https://github.com/staxrip/staxrip) | Windows     | Any        | ●●○○○       | ●●●●●         | ●●●●○     |
| [NEAV1E](https://github.com/Alkl58/NotEnoughAV1Encodes) | Windows | Any | ●●●○○      | ●●●○○         | ●●○○○     |
| [Handbrake](https://handbrake.fr/) | Any       | SVT-AV1     | ●●●●○      | ●●○○○         | ●●○○○     |
| [FastFlix](https://github.com/cdgriffith/FastFlix)  | Any       | Any         | ●●●●○      | ●●●○○         | ●●○○○     |
| [rAV1ator](/tools/utilities/rav1ator/)  | Linux     | rav1e       | ●●●●○      | ●●●○○         | ●○○○○     |
| [Autocompressor](https://autocompressor.net/) | Web  | SVT-AV1     | ●●●●●      | ●○○○○         | ●●●○○     |

Our top pics are:
- For beginners: **Aviator**. If you are on Linux and you want zero hassle whatsoever, Aviator is simple but highly effective. As a Flatpak application, it ships a bundled SVT-AV1-PSY binary that is up-to-date, compiled efficiently, and handled with extensively tested defaults. It is hard to go wrong with Aviator even as an advanced user, despite its simplicity.
- For advanced users: **Av1ation Station**. Av1ator Station is thoughtfully designed to be your one-stop shop for video encoding. Even though it is brand new, it has proven itself to be a capable and reliable solution for advanced video encoders that have a lot of settings to tweak and encodes to keep track of.
- For Windows users: **StaxRip**. StaxRip is a long-standing, well-maintained, and highly flexible video encoding tool that supports a plethora of encoders and formats. It comes bundled with SVT-AV1-PSY and is a great choice for Windows users who want a powerful and versatile tool for video encoding.

### CLI

In the terminal, advanced encoders can explore a much greater degree of complexity than many GUIs allow. That being said, ease of use is still a consideration when managing complex command-line encoding workflows. Let's begin with the key:
- We're omitting the "Platform(s)" column here, as this section targets Linux users. As a Windows user, WSL has you covered - as a Mac user, you're likely to experience parity with Linux (most of the time).

| Name | Framework(s) | Ease of Use | Complexity | Features | Scene Detection |
|------|--------------|:-----------:|:----------:|:--------:|:---------------:|
| SvtAv1EncApp | None | ●○○○○ | ●●○○○ | ●○○○○ | No |
| [FFmpeg](/tools/utilities/ffmpeg/) | Itself | ●●○○○ | ●●●●● | ●●●●○ | No |
| [Av1an](/tools/utilities/av1an/) | FFmpeg | ●○○○○ | ●●●●● | ●●●○○ | Yes |
| [rAV1ator CLI](/tools/utilities/rav1ator-cli/) | Av1an | ●●●●○ | ●●●●○ | ●●●●○ | Yes |
| [alabamaEncoder](https://github.com/kingstefan26/alabamaEncoder) | FFmpeg | ●●○○○ | ●●●●● | ●●●●● | Yes |

Our top picks are:
- For beginners: **rAV1ator CLI**. rAV1ator CLI essentially walks you through the process of writing Av1an commands. It can install binaries for you, save your previous commands, and detect scenes via Av1an. This makes it a great choice for beginners who want to learn the ropes of AV1 encoding without diving into the deep end headfirst. For advanced users, it makes rapidly writing, testing, & cataloging Av1an encoding commands much simpler.
- For advanced users: **alabamaEncoder**. alabamaEncoder is a powerful and flexible tool that allows you to encode video with FFmpeg and AV1. It is highly configurable and supports a mind-bending array of powerful features that would be hard to find elsewhere. While the tool is still new, it is already a great choice for advanced users who want to push the boundaries of what is possible to incorporate into an encoding workflow.

### Conclusion

In conclusion, the best AV1 tool for you will depend on your needs and experience level. If you are a beginner, Aviator is a great choice for Linux users, while StaxRip is a good option for Windows users. For advanced users, Av1ation Station is a powerful and versatile tool that can handle numerous encoding tasks. If you prefer the command line, rAV1ator CLI is a great choice for beginners, while alabamaEncoder is a powerful tool for advanced users. No matter which tool you choose, it is hard to go wrong in the modern AV1 encoding landscape when it comes to your utility of choice.

## Encoders

The world of AV1 encoding is diverse and complex, with several open-source encoders available, each bringing its own set of strengths, weaknesses, and unique features to the table. In this section, we'll dive deep into the characteristics of four major AV1 encoders:
1. SVT-AV1,
2. rav1e,
3. aomenc (libaom), and
4. SVT-AV1-PSY

Understanding these encoders is crucial for making informed decisions about what best suits your specific encoding needs.

### SVT-AV1

[SVT-AV1](/tools/software-encoders/svt-av1/) (Scalable Video Technology for AV1) is an AV1 encoder library and application developed by Intel, Netflix, and others. It has gained significant popularity in the encoding community due to its impressive balance of speed, quality, and scalability.

Links:
- Wiki page: [SVT-AV1](/tools/software-encoders/svt-av1/)
- Git repository: https://gitlab.com/AOMediaCodec/SVT-AV1
- Documentation: https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/README.md

1. **Performance & Scalability**
   - SVT-AV1 is renowned for its encoding speed, particularly at higher speed presets.
   - It leverages parallel processing, making it exceptionally efficient on multi-core systems. Fun fact: SVT-AV1's parallel processing is lossless, so it doesn't compromise quality for speed.

2. **Quality-to-Speed Ratio**
   - SVT-AV1 strikes an impressive balance between encoding speed and output quality.
   - At faster presets, it usually outperforms other encoders in quality per unit of encoding time.
   - While it may not achieve the absolute highest *quality per bit* possible, its quality is generally considered impressive for its speed.

3. **Flexibility**
   - SVT-AV1 offers a wide range of encoding options and presets, allowing fine-tuned control over the encoding process.
   - It provides 14 presets (0-13), with 0 being the slowest and highest quality, and 13 being the fastest but lowest quality.
   - Advanced options allow users to adjust parameters like hierarchical levels, intra-refresh type, and tuning modes.

4. **Continuous Development**
   - SVT-AV1 receives frequent updates and optimizations, with new releases often coming alongside big changes.
   - The open-source nature of the project encourages community contributions and rapid feature development.

SVT-AV1 is an excellent choice for a wide range of encoding scenarios. It's particularly well-suited for:
- High-volume encoding operations where speed is crucial
- Live or near-live encoding of high-resolution content
- Scenarios where a balance between quality and encoding speed is required
- Users with multi-core systems who want to leverage their hardware efficiently

Some downsides include:
- Higher memory usage compared to other encoders
- The developers assess quality via its performance on traditional legacy metrics, which harms its perceptual fidelity ceiling.

### rav1e

[rav1e](/tools/software-encoders/rav1e/) is an AV1 encoder written in Rust & Assembly. Developed by the open-source community alongside Xiph, it brings a unique approach to AV1 encoding with its focus on safety and correctness.

Links:
- Wiki page: [rav1e](/tools/software-encoders/rav1e/)
- Git repository: https://github.com/xiph/rav1e
- Documentation: https://github.com/xiph/rav1e/tree/master/doc#readme

1. **Safety & Reliability**
   - Being written in Rust, rav1e emphasizes memory safety and thread safety.
   - This focus on safety translates to a more stable and reliable encoding process, with reduced risks of crashes or undefined behavior.

2. **High Fidelity**
   - At high fidelity targets - an area where AV1 usually lacks - rav1e is a strong contender compared to other encoders.
   - It excels in preserving fine details and textures, making it a good choice for high-fidelity encoding.

3. **Quality**
   - While not typically matching aomenc or SVT-AV1 in pure compression efficiency, rav1e can produce high-quality output videos.
   - It often achieves a good balance between quality and encoding time, especially at medium-speed settings.

4. **Perceptually Driven**
   - rav1e's development is driven by visual fidelity, without relying heavily on metrics.
   - This focus on perceptual quality leads to a stronger foundation for future potential improvements in visual quality, as well as making the encoder very easy to use as it does not require excessive tweaking.

rav1e is well-suited for:
- Projects where stability is paramount
- Users who prioritize a community-driven, open-source development approach
- Encoding tasks where a balance between quality and speed is needed, but the absolute fastest speeds are not required

Some limitations of rav1e include:
- Lagging development compared to other encoders
- Slower encoding speeds compared to SVT-AV1 at similar quality & size
- Fewer advanced options compared to other encoders

### aomenc (libaom)

[aomenc](/tools/software-encoders/aomenc/), based on the libaom library, is the reference encoder for AV1. Developed by the Alliance for Open Media (AOM), it is the benchmark for AV1 encoding quality and compliance.

Links:
- Wiki page: [aomenc](/tools/software-encoders/aomenc/)
- Git repository: https://aomedia.googlesource.com/aom/

1. **Encoding Quality**
   - aomenc is widely regarded as the gold standard for AV1 encoding quality.
   - It often achieves high compression efficiency among AV1 encoders, especially at slower speed settings.
   - The encoder squeezes out nearly every last bit of efficiency from the AV1 codec, making it ideal for archival purposes or when quality per bit is critical.

2. **Encoding Speed**
   - aomenc is generally the slowest among major AV1 encoders.
   - It offers 13 CPU speed levels (0-12), but even at its fastest settings, it's typically slower than other encoders at their slower settings.
   - The slow speed is often considered a trade-off for its high compression efficiency.

3. **Extensive Options**
   - As the reference implementation, aomenc offers the most comprehensive encoding options.
   - It provides fine-grained control over nearly every aspect of the AV1 encoding process.
   - Advanced users can tweak many parameters to optimize for specific content types or encoding scenarios.

4. **Flexibility**
   - Being the reference encoder, aomenc produces highly standards-compliant AV1 bitstreams that take advantage of the full arsenal of AV1 features.
   - It supports 4:2:0 and 4:4:4 chroma subsampling, 8- to 12-bit color depth, and various other advanced features that more specialized encoders like SVT-AV1 do not support.

aomenc is ideal for:
- Scenarios where achieving the highest possible quality is the primary goal
- Archival encoding where compression efficiency is crucial
- Research and development in video compression
- Encoding projects where encoding time is not a significant constraint

Some drawbacks of aomenc include:
- Unresponsive development driven by legacy metrics, leading to slower adoption of new techniques and ignoring improvements communicated by people outside the Google development team
- Cripplingly difficult to use for beginners, with a culture of cargo-culting settings
- Slow encoding speeds compared to other AV1 encoders, which has less of an impact on the quality of the output than it used to compared to maturing encoders like SVT-AV1

### SVT-AV1-PSY

[SVT-AV1-PSY](/tools/software-encoders/svt-av1-psy/) is a community fork of the SVT-AV1 encoder focused on psychovisual optimizations to enhance perceived visual quality. It aims at closing the distance between SVT-AV1's high speeds and the perceptual quality of aomenc's slow brute force approach.

Links:
- Wiki page: [SVT-AV1-PSY](/tools/software-encoders/svt-av1-psy/)
- Git repository: https://github.com/gianni-rosato/svt-av1-psy
- Documentation: https://github.com/gianni-rosato/svt-av1-psy/blob/master/Docs/PSY-Development.md

1. **Perceptual Optimizations**
   - SVT-AV1-PSY introduces various psychovisual enhancements to improve the perceived quality of encoded video.
   - These optimizations often result in output that looks better to the human eye, even if it might not always score as well in objective metrics.

2. **Additional Features**
    - Introduces new options like variance boost, which can help maintain detail in high-contrast scenes.
    - Offers alternative curve options for more nuanced control over the encoding process.
    - Extends the CRF (Constant Rate Factor) range to 70 (from 63 in mainline SVT-AV1), allowing for extremely low-bitrate encodes.
    - Introduces additional tuning options, including a new "SSIM with Subjective Quality Tuning" mode that can improve perceived quality.

3. **Visual Fidelity Focus**
   - Aims to produce more visually pleasing results, sometimes at the expense of metric performance.
   - Includes options like sharpness adjustment and adaptive film grain synthesis which can significantly impact the visual characteristics of the output.
   - Features modified defaults driven by perceptual quality considerations.

4. **Extended HDR Support**
   - Includes built-in support for Dolby Vision & HDR10+ encoding.
   - This makes it particularly useful for encoding HDR content without requiring additional post-processing steps or external tools.

5. **Performance**
   - Based on SVT-AV1, it retains the performance characteristics of its parent encoder.
   - Adds super slow presets (-2 and -3) for research purposes and extremely high-quality encoding. These additional presets can be useful for creating reference encodes or applications where encoding time is not a concern.

SVT-AV1-PSY is particularly well-suited for:
- Encoding scenarios where subjective visual quality is prioritized over pure metric performance
- HDR content encoding in Dolby Vision or HDR10+
- Users who want fine-grained control over psychovisual aspects of encoding
- Projects that require a balance between the speed of SVT-AV1 and enhanced visual quality
- Encoding challenging content with complex textures or high-contrast scenes

Some drawbacks are:
- Everything that applies to SVT-AV1, including the lack of support for 4:4:4 chroma subsampling and 12-bit color depth that are useful in specific scenarios

### Conclusion

While SVT-AV1 is known for being fast, aomenc is renowned for its high-quality output, and rav1e is recognized for its safety and reliability, each encoder has strengths and weaknesses. The best encoder for you will depend on your specific needs and priorities.

As this guide is focused on offline encoding, **SVT-AV1-PSY** combines aomenc's traditional perceptual strength with SVT-AV1's speed. Like rav1e, it is easy to use due to strong default settings that prevent cargo culting, and overall it can be considered the best of all three worlds. It is actively developed by a team of responsive community members, and it is a great choice for most users who want a balance between quality per bit, speed, and ease of use.

The "best" encoder often depends on your use case, content type, and target audience. It's always worth experimenting with different encoders and settings to find the optimal balance for your needs. Many advanced users even employ multiple encoders in their workflows, choosing the most appropriate tool for each specific task or content type.

## Final Conclusion

The AV1 ecosystem has grown to the point where a single comprehensive guide cannot effectively cover the entire extent of the available tools and techniques for AV1 encoding across *every* use case. If you want more detail about a particular tool, where to acquire it, or how to compile an encoder, you can find that information throughout the various wiki entries linked on this page.

Reading can get you far, but it is natural to have questions. Please don't hesitate to connect with the team behind the Codec Wiki and many of these tools via our [AV1 for Dummies Discord server](https://discord.gg/bbQD5MjDr3). We're happy to help you with anything you need, and your questions and feedback help the wiki grow and improve. We hope you enjoy your journey into AV1 encoding, and we wish you the best of luck in your encoding endeavors!


title: Codec Wiki: One Year Later

description: Codec's Wiki turbulent one-year journey since it's inception to everyone's go-to site for encoding documentation.

title: Original Codec Wiki article

text: Stats

anchor: stats

text: Plausible

anchor: plausible

text: Google Search Console

anchor: google-search-console

text: A Brief History

anchor: a-brief-history

text: Bumps in the Road

anchor: bumps-in-the-road

text: Closing Statement

anchor: closing-statement

markdown:
Around a month ago, Codec Wiki celebrates it's very first anniversary as it officially hits one year old (Wow, that's a very long time!).

First and foremost, I apologize for this delayed celebration post, I have been very busy for the past month, y'know, real life things. Second of all, I would like to say **THANK YOU** for everyone who helped build this wiki from the ground up and writing down the entries, you know who you are!

## Stats

Thanks to everyone's efforts, over the course of 12 months Codec Wiki has grown into the (almost) go-to documentation and guide for newcomers just starting out in the quirky and wild world of multimedia encoding. So here are some pretty graphs to look at our progress so far!

### Plausible

As you may know, we ran our own Plausible Analytics instance: self-hosted, open source, and privacy-respecting analytics. It was hosted in Singapore and its former public dashboard is no longer available.

<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/one-year-anniv-blog/plausible.avif" type="image/avif" />

</picture>

7.7K unique total visitors for a whole year may not be much but it's a great start!

Let's not forget those who use uBlock Origin or similar to block the analytics script. So the visitor count could be two or three times more!

### Google Search Console

For those who are unfamiliar, Google Search Console is used for viewing well.. Google search data for your website. This data is unfortunately private and only the owner and those invited can see the data, no setting available for public view. Probably for the better.

<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/one-year-anniv-blog/console.avif" type="image/avif" />

</picture>

And for our top 10 search queries in the last 28 days:

<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/one-year-anniv-blog/insights.avif" type="image/avif" />

</picture>
<picture>
    <source srcset="https://raw.githubusercontent.com/av1-community-contributors/images/main/one-year-anniv-blog/insights2.avif" type="image/avif" />

</picture>

With pretty much zero competition in this niche of a market, it skyrocketed Codec Wiki to the top of search results for everything multimedia related 😅.

## A Brief History

Around a year ago, I started work on an unofficial "wiki" for all things encoding, it initially started as a half-serious joke because I was annoyed there were no good documentation available
anywhere on the internet on the real application and usage of encoders such as "Should I use tune SSIM in x encoder?". With the search results you'll be presented with being one or more of these:

- Doesn't exist.
- Mentioned in the FFmpeg mailing list but nothing else.
- PDF research papers on IEEE and similar.
- Outdated information on Doom9 or Multimedia Wiki.
- "The documentation are in the code blocks".
- Link rot.
- Abandoned, or mostly focused on other topics.
- Focused on a specific type of storytelling medium.
- Actual good explanation in an old forgotten site (rare).

Some or maybe even most of these results still appear up to this day.

Frustrated with how scarce information is available on the open internet and combined with the fact that most, if not all of them only exist in non-search-engine-reachable private chat communities such as Discord where you'll have to join and scroll around older conversations.

Prone to data erasure as Discord can nuke these servers for whatever reason they please and years of "documentation" is lost in an instant. It is simply not a good platform for a plethora of valuable information.

**That's why I took initiative.**

## Bumps in the Road

There were also generally a lot of distrust and pushbacks when this project first began, particularly from those who are more experienced with encoding. Which is understandable because everyone who attempted before burned out and never finished it.

But Codec Wiki stood the test of time with constant updates through active collaboration of everyone involved, nowadays those voices have mostly subsided or even joined the project themselves. And I am grateful for that.

## Closing Statement

Once again, **THANK YOU VERY MUCH** for those who are involved in this project and making the once pipe dream of a one-stop-shop user-friendly documentation for encoding into something that's possible.

Let's continue documenting the most crucial yet invisible driving force of internet traffic, pages by pages.

Together we are strong, divided we burn out.

> "There are times when a critic truly risks something, and that is the discovery and defense of the *new*. **The world is often unkind to new talent, new creations. The new needs friends**."
>
> — Anton Ego


title: Embedding the Un-Embeddable

description: Revealing the secrets of those websites that allow you to embed entire movies, AV1, and videos over 500MB on Discord.

title: Original Codec Wiki article

text: A Scenario

anchor: a-scenario

text: But First, a Quick Disclosure

anchor: but-first-a-quick-disclosure

text: How it Works

anchor: how-it-works

text: The Website's End

anchor: the-websites-end

text: Discord's End

anchor: discords-end

text: Strengths & Limitations

anchor: strengths-limitations

text: Strengths

anchor: strengths

text: Limitations

anchor: limitations

text: Differences between Sites

anchor: differences-between-sites

text: The Lore

anchor: the-lore

text: Dwayne

anchor: dwayne

text: Discovery

anchor: discovery

text: The Experiments & Interactive Site

anchor: the-experiments-interactive-site

text: Virality

anchor: virality

text: Closing

anchor: closing

markdown:
![Feature image](/img/discord-embed-blog-image.webp)
**A 567.14 MB, 12 min 11 s, 2K (2,048 x 858), VP9 + Opus, 6.51 Mbps average, Blender short film "Cosmos Laundromat"**

## A Scenario

While chatting in your favorite Discord servers & group chats, you may see a friend send a weird link. You might even consider it suspicious on first glance. It is a video featuring an image of a movie poster with a play button that is almost begging to be clicked. Naturally, you click it.

It loads for a second, and to your surprise it is a full-length, 90-minute (sometimes even two hour)-long unauthorized copy of a movie. If you don't know exactly what is going on, you probably sit there dumbfounded as a pixel perfect HD movie plays back. You may have expected a stereotypically muddy, blocky, laggy shitpost, but this has defied your expectations.

![stolen.shoes](/img/stolenshoes-puss.webp)

The truth is, there are *multiple* site that do this. Currently, there are five at the time of writing. Below is a list the ones I am currently familiar with:

- https://stolen.shoes
- https://discord.nfp.is
- https://embeds.video
- https://x266.mov/discord-embed
- https://autocompressor.net/av1

The big question is, **how do they work?** Let's get to dissecting.

## But First, a Quick Disclosure

The Codec Wiki unequivocally condemns any form of piracy, including the unauthorized distribution of copyrighted content. This blog post is intended to educate & inform. You may not use the tools discussed to infringe upon the intellectual property rights of content creators without serious legal risk. We encourage our readers to respect copyright laws & use the tools we discuss here appropriately.

## How it Works

The entire scheme is actually very simple, as it is all just HTML meta tags (If you are familiar with web development, this is all a walk in the park).

The technology's inner working can be divided into two distinct parts. First, let's see how it works on the website's end.

### The Website's End
If you view each website's source, you will find this specific line in each one but they may have a different order:

```html
<meta property="og:image" content="https://example.com/i/someimageforthumbnail.jpg">
<meta property="og:type" content="video.other">
<meta property="og:video:url" content="https://example.com/v/video.mp4">
<meta property="og:video:width" content="1920">
<meta property="og:video:height" content="1080">
```

These are the `head` parts of HTML, which dictate metadata for the document itself such as what the website title/name is, cosmetic embed, defining the site's icon, etc. They are usually found in between the `<html>` and `<body>` tags. Here's an example of a static HTML site serving one specific video:
```html
<!DOCTYPE html>
<html>
<head>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="shortcut icon" type="image/x-icon" href="../favicon.ico"/>
  <title>some embed site</title>
  <meta property="og:image" content="https://www.themoviedb.org/t/p/original/3U0vksjSY9LWe3Dqfr6xkgd3iQP.jpg">
  <meta property="og:type" content="video.other">
  <meta property="og:video:url" content="https://upload.wikimedia.org/wikipedia/commons/3/36/Cosmos_Laundromat_-_First_Cycle_-_Official_Blender_Foundation_release.webm">
  <meta property="og:video:width" content="2048">
  <meta property="og:video:height" content="858">
</head>
<body>
  <h1>Hi</h1>
  <p>Just your friendly neighborhood video embed site</p>
  </body>
</html>
```

< br />
These interactive sites usually deploy a live script, like a Javascript framework. Examples are NodeJS, ExpressJS, Svelte, etc. These are used to parse video and thumbnails realtime so they can be embedded on Discord (or potentially other platforms).

### Discord's End

Traditionally, Discord's media embedder will impose it's own video embed size limit (50 MiB) when a user sends a direct video link as usual. But in this case Discord will embed the thumbnail first, not the video. You could say the link "tricks" Discord by showing a "false face" first.

## Strengths & Limitations

After a combination of countless hours of observation, rigorous testing throughout the period of a year, and conversations with the sites' creators, the current strengths & limitations of this exploit are enumerated below.

#### Strengths

- You can embed non-web compatible codecs such as [HEVC](/codecs/video/hevc/) in [MP4/MOV](/start-here/terminology/#mp4--m4v), but the user must be using a compatible browser. [Thorium](https://thorium.rocks) or Safari version 13 or greater will work for HEVC playback.
- There is no maximum size. You could embed a video the size of a raw Bluray, although I do not condone this unless you have the necessary legal permissions to do so or you're uploading a Creative Commons licensed movie like Big Buck Bunny while adhering to the restrictions of the applicable Creative Commons license. This also means you can send high bitrate gaming clips to your friends without any restrictions, assuming you already have a place to upload them.

#### Limitations

- You can only use [hotlinks](https://simple.wikipedia.org/wiki/Hotlinking), which means direct linking to the video itself ending in the appropriate file extension such as `.mp4`. Cloud services like Google Drive or OneDrive will not work for storage.
- You cannot use Discord's CDN (cdn.discordapp.com) as the video source. I assume this is because of Discord's proxy blocking embeds over 50 MiB, but **only discord.nfp.is can do this**, as it **proxies cdn.discordapp.com** itself.
- You cannot embed videos in any resolutions higher than 3840 x 2160, Discord imposes a hard limit for this on all video after it was discovered that some videos could play normally but then be maliciously scaled to ridiculous resolutions during playback to crash Discord.

## Differences between Sites

As mentioned before, there are five known sites at the time of writing. They all serve the same function, but one may interest you more than another due to slight differences in features & functionality.

Here are the sites, each with one noteworthy special benefit:

- https://stolen.shoes - Recognition, as it is the OG.
- https://discord.nfp.is - You can use Discord CDN as video source.
- https://embeds.video - Immediately input video source into the URL (`https://embeds.video/https://example.com/v/video.mp4`)
- https://x266.mov/discord-embed - Attractive domain, simple layout.
- https://autocompressor.net/av1 - Lots of info dump, pretty advanced features.

That concludes the technical overview! Next, let's cover the history of this exploit.

## The Lore

### Dwayne

In around April of 2022, a Reddit user going by the name of u/CreativeGamer03 [posted a video on r/discordapp](https://www.reddit.com/r/discordapp/comments/u96kky/someone_sent_this_in_the_memes_channel_and_bruh) of a link where a GIF of Dwayne "The Rock" Johnson plays caption with "Is this a GIF or is it a video?" When played, a low-quality music video of Rick Astley's "Never Gonna Give You Up" plays.

The link used, `archuser.de/the-rock`, has since been removed.

### Discovery
On 23rd June 2022, a Discord user *Clybius* on the AV1 Community server asked people for [VP9](/codecs/video/vp9/) or [H.264](/codecs/video/avc/) videos that were over 100 MB in size. At the time the current 500 MB nitro tier did not exist. They then decided to use a 59 minute 1080p sample video of nature scenery from around the world with a thumbnail featuring a GIF of a waterfall to test the exploit. It worked.

He tried shortly afterward with [AV1](/codecs/video/av1/). Eureka, it also worked:

![AV1](/img/clybius-av1.webp)

Clybius confirmed that this could be patched if discovered. He cites having had the idea from the Dwayne Johnson example above, but forgetting about it for a couple of months. So, it seems this entire concept stemmed from a silly rickroll.

![Dwayne](/img/clybius-dwayne.webp)

### The Experiments & Interactive Site

After the discovery of AV1 embedding, experimentation brought about the discovery that *any* video codec will work as long as the user can decode/play the codec and the container/extension is an MP4, MOV, or WebM. These are all traditionally web-compatible containers. If you're interested in learning about containers, please see the [Containers](/start-here/terminology/#container) section on the [Terminology](/start-here/terminology/) page.

This applies to HEVC, ProRes, [xHE-AAC](/codecs/audio/aac/#xhe-aac), and other bizarre codecs that are rarely seen on the Web.

While experimentating, Clybius converted one their idle domains `stolen.shoes` into an interactive embedder that provided a textbox for a video URL, a thumbnail URL, a width value, & a height value for the desired video. This would be the first website for Discord embedding.

### Virality

It's not long before people outside of the AV1 Community discovered `stolen.shoes`, and its popularity increased rapidly. Its use usually involved the illicit distribution of full-length, unauthorized copies of movies; this sometimes happened very shortly after some movies were released. There were a couple notable instances of this happenening that caused quite the stir online each time.

- The first instance featured the DreamWorks sequel of "Puss in Boots (2011)", "Puss in Boots: The Last Wish (2022)". A 1080p video sourced from a streaming site was the first wake up call that attracted attention to the existence of these embed sites. This example used `stolen.shoes`.

![puss](/img/stolenshoes-puss.webp)

- The second instance was when highly-anticipated animated film "The Super Mario Bros. Movie (2023)" produced by Illumination, Universal Studios, and Nintendo was spread around Discord. It was first spotted as a Cam (A camera recording by someone in theaters), then as it went out on streaming services a different link appeared but spread faster and with upgraded 1080p quality. Both used `stolen.shoes` as the embed site.

![mario](/img/stolenshoes-mario.webp)

- The third instance is very recent as of the day this was posted. A streaming-service sourced "Five Nights at Freddy's (2023)" was spread around since the movie released both in theaters and streaming service (Peacock) day one, and it gained steam extremely fast as most people had not seen it yet. Currently, this illegal novelty is gaining [hundreds of upvotes within the r/discordapp subreddit](https://www.reddit.com/r/discordapp/comments/17hx45y/is_discordnfp_an_ip_grabber/). The copy seems to be a compressed 720p encode. This example used `discord.nfp.is`.

![fnaf](/img/discordnfpis-fnaf.webp)

Note the ones listed here are the ones that I saw become extremely popular. There may be lesser known links that have been spread around privately or just did not cause enough noise for me to notice. Some less popular examples I've noticed, featuring more illicit copyrighted content distribution:
- Top Gun Maverick (2022)
- The SpongeBob trilogy (2005/2015/2020)
- Spider-Man: Across the Spider-Verse (2023)

## Closing

The ability to embed unusually large videos on Discord has enabled both positive and negative use cases. On the one hand, it allows high-quality content to be shared easily among friends. However, it has also facilitated mass copyright infringement by empowering virtually anyone with a Discord accound to freely spread pirated movies.

While this is fascinating from a technical perspective, embedding techniques like these tread a fine ethical line. As with anything, it is important to be mindful of how our actions affect others, and I should remind everyone that content creators deserve to be compensated for their work. As users, we should support them by accessing their content via legitimate platforms.

It is hard to say how long this exploit will continue to be usable. Instead of enabling piracy, which may cause Discord to be more likely to patch this exploit if they see it as a serious threat, let's instead use these capabilities responsibly to share our own creations, gaming highlights, and other media which we can share legally. Given some thoughtfulness, perhaps we can find a fair balance between respecting copyright law and appeasing Discord's sensibilities while allowing some creative flexibility on the platform.

Thank you for reading this blog post, I hope you learned something!


title: Reducing Image Load Online

title: Original Codec Wiki article

text: Fire & Forget

anchor: fire-forget

text: Massive Improvement

anchor: massive-improvement

text: Lazy Loading

anchor: lazy-loading

text: New Codecs

anchor: new-codecs

text: Fallbacks

anchor: fallbacks

text: Compression Efficacy

anchor: compression-efficacy

text: Responsive Images

anchor: responsive-images

markdown:
A big part of understanding any multimedia codec technology is knowing the application for such technology. For images, a big use case is web delivery. Compared to other multimedia, images are incredibly popular on the Web & knowing how to serve them properly can be a massive boon to your website's traffic as well as less of a headache for users on slower connections or who are under bandwidth constraints. The most disappointing part is that images are often poorly done on the web; all too frequently will you run into a site serving massive photographic PNGs for no reason, or photography sites serving photographs fresh out of the editing software with no thought put into their final delivery. A little effort, patience, & knowledge will go a long way toward improving the user experience for individuals using your site, & this article will illustrate some of the basics.

> **Caution — These instructions are for *photographic* images; other kinds of images, like non-photographic, artwork, pixel art, etc. should likely be handled differently..**
>
>
> **Danger — Many images won't load properly unless your browser supports JXL, AVIF, & proper ICCv2 color management. This is for demonstration purposes only & shouldn't represent an actual common website experience. If you're curious anyway, the following browsers can display the contents of this page perfectly:.**
>
> - [Thorium](https://thorium.rocks/) | *Linux, [macOS](https://github.com/Alex313031/Thorium-Special/releases), [Windows](https://github.com/Alex313031/thorium/releases/), [Android](https://github.com/Alex313031/Thorium-Special/releases)*
> - [Waterfox](https://www.waterfox.net/) | *[Linux](https://flathub.org/apps/net.waterfox.waterfox), [macOS](https://www.waterfox.net/download/), [Windows](https://www.waterfox.net/download/)*
> - [Mercury](https://thorium.rocks/mercury) | *[Linux](https://github.com/Alex313031/Mercury/releases), [Windows](https://github.com/Alex313031/Mercury/releases)*
## Fire & Forget

First, we'll illustrate what *not* to do, which is fortunately not incredibly difficult to avoid. Taking an image straight out of your editing software at a massive size will often bloat the size & resolution to something that isn't generally usable for a website regardless of the codec you're using & its quality per bit. It can be argued there are specific use cases that demand incredible resolution & fidelity coexist on the Web, but we won't be covering those here. Here's an example of a bloated image:

*exported straight from Darktable at JPEG q90, with no scaling*

![bloated_jpeg](/img/_DSC8466.jpg)

**2.2 MB**

## Massive Improvement

The easiest way to have a large improvement without doing much work is to simply resize the image before serving it. Even if you exported a lossy JPEG, resizing should remove a lot of artifacts. The way to perceive a worst-case for an image's size on a site is to inspect the image element's width & height, which should give us an estimate of how large we should make our image. Any larger than this value is unreasonable since we're overfilling the element's size for no reason & the image is being scaled down anyway.

![box-size-mac](/img/box-size-mac.avif)
*Inspect Element in Firefox. The Mac used to take this screenshot has a relatively high display resolution of 2560x1664. Because Macs scale things differently, we're probably going to want to double the horizontal resolution here.*

The width is the most important value here, so our new image is going to be exported with a width of 1699 pixels. This new image, encoded at JPEG q90 with `cjpegli`, looks like this:

![smaller_jpeg](/img/_DSC8466-smaller.jpg)

Obviously, there's lost fidelity compared to the original, but considering this is *so much smaller*, it is worth the trade-off for many. It is also worth noting we are using an improved jpeg encoder in the form of `cjpegli`, although that is secondary to the resize. If it doesn't look as good as you want it to, you can always scale the resolution up a bit, though currently, it looks plenty passable for its size.

2.2 MB -> **233 kB**

> **Chart — Page-weight reduction in the article example.** Resizing and re-encoding reduces the example image to roughly one tenth of its original transfer size. Data: Original: 2200 kB; Optimized: 233 kB.

### Lazy Loading

A bonus tip is to add the `loading="lazy"` attribute to your picture tag to allow the image to load only when scrolled to by a user. This doesn't save bandwidth, but it improves the user experience by loading images further down the page only when necessary. An example may look like this:

```html
<picture>
    <img src="/images/jpeg_fallback.jpg" alt="alt text" width="XX" height="YY" loading="lazy" />
</picture>
```

## New Codecs

If you desire further improvement, it may be time to consider using a newer codec like [AVIF](/codecs/images/avif/) or [JPEG-XL](/codecs/images/jxl/). These options will compress far more effectively than JPEG, with the only trade-off being browser support. We're not going to consider [WebP](/docs/images/WebP) or [HEIC](/docs/images/HEIC), since WebP is not competitive enough with JPEG for photographic imagery (often being worse) & HEIC has been superseded by AVIF - which sees greater support anyhow - & is not royalty free, effectively preventing widespread Web adoption forever. Again, we're just considering *lossy* compression for *photographic* images; it is a different story with WebP elsewhere, as it performs well on non-photographic content & is almost always better than PNG for 8-bit lossless compression. So, we are left with JXL & AVIF for now.

### Fallbacks

AVIF sees widespread support, but JPEG-XL isn't quite there yet with Web support as Google continues to push AVIF (it is debatable if it ever will be outside the Apple ecosystem). Even with AVIF, adoption isn't remotely close to JPEG, so it is worth providing a fallback. This can look like the following example:

```html
<picture>
    <source srcset="/img/jxl_image.jxl" type="image/jxl" />
    <source srcset="/img/avif_image.avif" type="image/avif" />
    <source srcset="/img/webp_fback.webp" type="image/webp" />
    <img src="/images/jpeg_fallback.jpg" alt="alt text" width="XX" height="YY" loading="lazy" />
</picture>
```

Here is a JXL falling back to an AVIF falling back to a WebP falling back to a JPEG. Pretty intense to have this many fallbacks unless you're really after the ultimate compression ratio, but it is certainly an option. AVIF & JPEG alone will probably be enough for most.

### Compression Efficacy

Let's look at how our image examples compare to the original with our new codec selection. We'll be aiming for high visual fidelity, so around the same quality as our initial JPEG encoded with `cjpegli` (which scores ~`83.01` with the [SSIMULACRA2](/docs/metrics/SSIMULACRA2) visual fidelity metric).

![smaller_jxl](/img/_DSC8466-smaller.jxl)

**137.0 kB** *JPEG-XL image, encoded with `cjxl lossless.png out.jxl -d 1.49 -e 9`. Score: ~`83.04`* *3.06s user time*

![smaller_avif](/img/_DSC8466-smaller.avif)

**124.8 kB** *AVIF image, encoded with `avifenc -c aom -s 4 -j 8 -d 10 -y 444 --min 1 --max 63 -a end-usage=q -a cq-level=16 -a tune=ssim lossless.png out.avif`. Score: ~`83.03`* *7.54s user time*

JXL also supports lossless transcoding of JPEG images. This means every pixel is identical, the image just has a smaller filesize than the original JPEG; if you can use JXL, you can transcode existing JPEGs losslessly on your site & save some bandwidth that way. The JPEG transcode below gives a higher SSIMULACRA2 score than the original for some reason, but I'll chalk that up to a decoding inconsistency between how the `ssimulacra2` program decodes JPEG & JXL. Either way, the scores are fairly close.

![smaller_jxl_jpeg-recomp](/img/_DSC8466-smaller-recomp.jxl)

**189.4 kB** *JPEG-XL image from JPEG, encoded with `cjxl input.jpg input-recomp.jxl -d 0.0 -e 9 --brotli_effort=11`. Score: ~`84.92` (???)* *0.67s user time*

The final trick we can use, while not a new codec at all, still increases quality per bit. Encoding an XYB JPEG with `cjpegli` encodes with the perceptual XYB colorspace using an ICC profile to modify the original JPEG colors, avoiding JPEG's normal YCbCr which isn't perceptually optimized for the human visual system. Using XYB, we can afford identical quality with less bitrate than normal JPEG. This has universal compatibility, but not every application understands how to handle the XYB color profile (although color-managed modern browsers should be fine).

![smaller_jpeg_xyb](/img/_DSC8466-smaller-xyb.jpg)

**208.3 kB** *XYB JPEG, encoded with `cjpegli lossless.png out.jpg --xyb -d 1.155`. Score: ~`83.04`* *0.10s user time*

In this particular instance, AVIF seems to be the overall winner. This isn't always the case due to JXL's superiority at higher fidelity & with more detailed images, but according to SSIMULACRA2, AVIF has the best quality per bit with this image. You can use your own eyes to further clarify your choice, though. It is worth mentioning that as these were encoded from a 16-bit source PNG, the JXL image is the only one that maintains the full original bit depth, & AVIF isn't fast to encode.

## Responsive Images

Displaying an image that is too large for a viewport is a waste of bandwidth, & displaying an image that's too small for the viewport leaves fidelity to be desired. Luckily, we have the [Responsive Image Linter](https://ausi.github.io/respimagelint/) that can help us figure out which image sizes we should be using.

![responsive_image_linter](/img/responsive_image_linter.avif)

In our fire & forget example, we see that we are serving an image that is far too large. We already know that, but now we can see that given various viewport sizes we could be serving images that have respective widths of 270px, 958px, 1350px, 1660px, & 1916px to optimize for delivery to a variety of different devices. Here's how we'd write that in HTML:

```html
<picture>
  <source type="image/jxl" srcset="/img_270.jxl 270w, /img_958.jxl 958w, /img_1350.jxl 1350w, /img_1660.jxl 1660w, /img_1916.jxl 1916w" sizes="(min-width: 2000px) 1916px, (min-width: 1700px) 1660px, (min-width: 1400px) 1350px, (min-width: 1000px) 958px, calc(100vw - 24px)" />
  <source type="image/avif" srcset="/img_270.avif 270w, /img_958.avif 958w, /img_1350.avif 1350w, /img_1660.avif 1660w, /img_1916.avif 1916w" sizes="(min-width: 2000px) 1916px, (min-width: 1700px) 1660px, (min-width: 1400px) 1350px, (min-width: 1000px) 958px, calc(100vw - 24px)" />
  <img width="1699" height="1136" alt="alt text" srcset="/img_270.jpg 270w, /img_958.jpg 958w, /img_1350.jpg 1350w, /img_1660.jpg 1660w, /img_1916.jpg 1916w" sizes="(min-width: 2000px) 1916px, (min-width: 1700px) 1660px, (min-width: 1400px) 1350px, (min-width: 1000px) 958px, calc(100vw - 24px)" src="/fallback.jpg" />
</picture>
```

It is worth noting that this example above & the example below aren't perfect implementations of a responsive image given the conditions of this site, but the general concept still applies. Some things to note:

- `srcset` = the images available to your browser to serve, & their respective widths
- `sizes` = the conditions given to the browser explaining under what conditions should it serve which image
- `(min-width: XXXpx) YYYpx` = Given the viewport is at least XXX wide, serve an image of YYY horizontal resolution. The browser will pick an image from srcset that is CSS pixels \* display scaling.
- `calc(100vw - 24px)` = Usually preceded by a (min-width) condition. Specifies a value the browser should calculate on its own to pick the closest option from the srcset. Let's say we have `(min-width: 997px) calc(75vw - 257px)`. This means given the viewport is at least 997px wide, calculate 0.75 \* the current viewport resolution - 257 to find the closest image in the srcset to fit the number of pixel specified.

<picture>
  <source type="image/jxl" srcset="/img/img_size/img_270.jxl 270w, /img/img_size/img_958.jxl 958w, /img/img_size/img_1350.jxl 1350w, /img/img_size/img_1660.jxl 1660w, /img/img_size/img_1916.jxl 1916w" sizes="(min-width: 2000px) 1916px, (min-width: 1700px) 1660px, (min-width: 1400px) 1350px, (min-width: 1000px) 958px, calc(100vw - 24px)" />
  <source type="image/avif" srcset="/img/img_size/img_270.avif 270w, /img/img_size/img_958.avif 958w, /img/img_size/img_1350.avif 1350w, /img/img_size/img_1660.avif 1660w, /img/img_size/img_1916.avif 1916w" sizes="(min-width: 2000px) 1916px, (min-width: 1700px) 1660px, (min-width: 1400px) 1350px, (min-width: 1000px) 958px, calc(100vw - 24px)" />
  <img loading="lazy" width="1699" alt="alt text" srcset="/img/img_size/img_270.jpg 270w, /img/img_size/img_958.jpg 958w, /img/img_size/img_1350.jpg 1350w, /img/img_size/img_1660.jpg 1660w, /img/img_size/img_1916.jpg 1916w" sizes="(min-width: 2000px) 1916px, (min-width: 1700px) 1660px, (min-width: 1400px) 1350px, (min-width: 1000px) 958px, calc(100vw - 24px)" src="/img/_DSC8466-smaller.jpg" />
</picture>

That's all! Massive thanks to Auto-Rez Media Technologies for the inspiration behind this article & explicit permission to use their [Reduce Your Page's Image Load](https://autocompressor.net/blog/reduce-image-load) blog post when writing this entry. I have [confirmed](https://autumn.revolt.chat/attachments/GtFGuwNfeRdcwUN0MWzhDCAiiadWOk88XXC3pQv6RI) with their leadership that this wiki entry can be safely licensed under CC BY-SA 4.0.