AV1
| Developed by | Alliance for Open Media |
|---|---|
| Initial release | March 28, 2018 |
| Latest release | 1.0.0 Errata 1 (January 8, 2019) |
| Type of format | Video coding format |
| Contained by |
|
| Extended from |
|
| Standard | AOM AV1 |
| Open format? | Yes |
| Website | aomedia.org/av1-features/ |
AOMedia Video 1 (AV1) is a free video coding format developed to be the successor of VP9 by the Alliance for Open Media (AOMedia). AV1 has much better compression compared to MPEG-4 AVC (x264) and measurably better compression than VP9 and HEVC at the price of horribly slow encoding times. Playback is also very expensive, you can likely play 720p and 1080p video smoothly on a fairly modern machine but the chances of 4K video playing smoothly are slim.
AV1 Video Playback On Linux[edit]
AV1 video playback has been supported by FFmpeg and video players using mpv as well as other video players like VLC for quite some time. Chromium has had AV1 video playback support since version 70. Firefox has had AV1 video playback support over a year. You will, in theory, be able to play AV1 video both in web browsers and video players on any fairly recent GNU/Linux distribution. There is a fair chance that you, in practice, can't.
Playing AV1 video is very CPU demanding. Do not expect to be able to play AV1 video on an old or weak processor like the AMD Athlon 5350 APU, you won't even be able to play 1080p video. You will be able to play 1080p video on a moderately powerful modern machine powered by something like a Ryzen 1600X or a 2600 but you won't be able to smoothly play 4K video.
A big part of the reason 4K video won't play on machines that are perfectly capable of CPU software decoding 4K HEVC video is likely the single-threaded nature of AV1 decoding in current versions of FFmpeg. Playing 4K video using mpv version 0.32.0-666-gb0f0be7678 linked against FFmpeg 4.2.4 on a Ryzen 2600 with a RX 470 GPU results in very stuttering unwatchable playback due to one thread doing the vast majority of the work.
We have made two AV1-encoded video files available for your "enjoyment":
| File | Size | Length | Resolution | Pixel format |
|---|---|---|---|---|
| Meridian-8MiB-AV1-Challenge.webm | 8 MiB | 8:00 | 1280x720 | 10-bit |
| DollHouse.2019.webm | 168 MiB | 16:42 | 4096x1716 | 10-bit |
You can go right ahead and try to play both these files since you are much likely using a web browser with AV1 support.
There is a fair chance that you will be able to play the 1280x720 Meridian-8MiB-AV1-Challenge.webm if you are using a Linux desktop or laptop computer. A close-up inspection of mpv 0.32.0-666-gb0f0be7678 linked against FFmpeg 4.2.4 on a Ryzen 2600 reveals one thread using between 50% and 80% of one CPU core with a second thread loading a second core at 10-20%.
Trying to play the 4K DollHouse.2019.webm file on a Ryzen 2600 results in one thread trying to use between 250 and 280% of one CPU core with a second thread eating about 50% of a second core and a few other threads using 5-10%. The result of that is horrible stuttering. The current single-core nature of AV1 playback on Linux means that you will need a machine with about 3x the single-core performance of a Ryzen 2600 to play AV1 video smoothly. Is a question of single-threaded performance: A 12 or 24 core machine won't help when smooth playback requires one very fast core.
Hardware Decoding[edit]
Intel Tiger Lake processors with integrated graphics will be capable of hardware video decoding and Linux support is already in place in libva and FFmpeg.
There is no AV1 hardware video decoding in the AMD Polaris, Vega or the first Navi graphics cards families. You are out of luck if you have a AMD CPU paired with an AMD GPU or an AMD APU and you want to play 4K AV1 video on Linux - unless you have the very latest AMD graphics technology. The "Sienna Cichlid" and "Navy Flounder" graphics card families (Navi 21 and 22) can do AV1 decode. No AMD GPU can do AV1 hardware encoding.
HOWTO encode AV1 video[edit]
FFmpeg encoding a 1080p video as AV1 at a whopping 0.7 frames per second
 |
Warning: AV1 video encoding with libaom-av1 is really slow as in horribly slow on modern processors. Expect to be shocked and amazed at how incredibly slow AV1 encoding is if you are used to encoding MPEG4-AVC video or even HEVC video. This is specially true if you are used to hardware accelerated video encoding.
|
There are several competing encoders available for GNU/Linux. FFmpeg with libaom-av1 is one you likely have available on a modern GNU/Linux distribution. It is considered to be "experimental" FFmpeg requires you to use either -strict experimental or strict -2 or it will refuse to run.
FFmpeg can encode AV1 video in several modes. Constant quality (CQ) mode is likely the mode you want since it produces consistent quality. This mode produces constant quality even if it requires a high bitrate in scenes with a lot of movement. Constrained quality is similar except that it is possible to set upper and lower bit-rate boundaries. There is also a Average Bitrate (ABR) mode available in the libaom-av1 encoder.
FFmpeg -h encoder=libaom-av1 will list all the available options for the libaom-av1 encoder.
Constant Quality Encoding[edit]
FFmpeg will do constant quality encoding if you specify a quality number with -crf. A lower number produces better quality, higher produces worse video quality at smaller file sizes. A value between 20 and 35 is advisable, values between -1 and 63 are possible. You must also specify a video bitrate of 0 with -b:v 0 to use this mode.
FFmpeg -i inputfile.ts -c:v libaom-av1 -crf 28 -b:v 0 -strict experimental av1-encoded-video.mkv
Constrained Quality Encoding[edit]
The constrained quality mode requires you to set the same -crf quality parameter as the constant quality encoder mode. You will also have to set a target bitrate with -b:v. The target bitrate can be exceeded in brief periods but not by much. The only difference between the commands for constant quality encoding and constrained quality encoding is the specified -b:v value:
FFmpeg -i inputfile.ts -c:v libaom-av1 -crf 28 -b:v 2000k -strict experimental av1-encoded-video.mkv
Two additional bitrate limitations can be applied: -minrate and -maxrate will ensure that the actual bitrate never deviates too far from the target bitrate:
FFmpeg -i inputfile.ts -c:v libaom-av1 -crf 28 -b:v 3000k -minrate 1000k -maxrate 3500k -strict experimental av1-encoded-video.mkv
Average Bitrate (ABR) Encoding[edit]
Average bitrate encoding is not very useful for AV1 but it is possible. This mode will ensure that the encoded video is at the target bitrate at all times. No -crf quality target should be specified to encode in this mode, a bitrate set by -b:v is the only option necessary to use this mode:
FFmpeg -i inputfile.ts -c:v libaom-av1 -b:v 3000k strict experimental av1-encoded-video.mkv
Average bitrate encoding would make sense if live-streaming was a use-case for AV1. It is not, no unclassified computer technology is capable of real-time encoding anything larger than a stamp-sized video.
Speed Configuration For All Modes[edit]
The libaom-av1 encoder has a -cpu-used option you can safely ignore. It is described by FFmpeg -h encoder=libaom-av1 as:
"Quality/Speed ratio modifier (from 0 to 8) (default 1)"
Lower values produce better quality at the cost of being more CPU-demanding. The default value of 1 is likely what you want; you are better off not specifying the -cpu-used parameter. -cpu-used 8 will produce lower quality video faster. It could be useful for AV1 encoded live-streaming if/when computers become fast enough to be able to real-time encode 1080p video using the "faster" AV1 encoding mode.
Encoding using tiles will speed up encoding on modern multi-core computers. Encoding using tiles can be enabled by adding -row-mt 1 and a -tiles XxY option (-tiles 2x2 or -tiles 4x1 for 4 tiles). You should absolutely add -row-mt 1 -tiles and a fitting tiles value to the encoding commands described above. 2x2 for four tiles is a good choice if you have a quad-core computer, 2x3 would utilize a six-core CPU. Using -row-mt 1 -tiles 8x8 on a dual-core would both be pointless and slower.
Other Options[edit]
HDR encoding can be done by specifying color information with -colorspace, -color_trc and -color_primaries. What values you should use will depend on the source video. YouTube HDR uses -colorspace bt2020nc -color_trc smpte2084 -color_primaries bt2020 so you should use that if you want to re-code YouTube HDR video for some reason (YouTube already does that for you, downloading their encode using youtube-dl is a better option).
AV1 Image File Format (AVIF)[edit]
AVIF is a image format based on the AV1 video encoding standard.
AVIF image files support:
- Lossless or lossy compression
- 8, 10 and 12 bit color depth
- High dynamic range
- 4:2:0, 4:2:2, 4:4:4 chroma subsampling
- Any color-space including: wide color gamut, ISO/IEC CICP and ICC profiles
AVIF images have up to 50% better compression than JPEG files at comparable image quality.
AVIF images are stored in the High Efficiency Image File Format (HEIF) container format. Still images have the image/avif MIME type and the .avif file extension while animated pictures have the image/avif-sequence MIME type and the .avifs file extension.
AVIF images can be viewed in Mozilla Firefox by enabling image.avif in about:config since version 77. It's also now supported in Chromium 85+ based browsers by default.
AVIF has seemingly no support in XFCE nor KDE desktop environments, and their corresponding default file explorer thumbnailers. GIMP support is only via a plugin, but that plugin is expected to be bundled in with the upcoming release of version 3.0. All of this is unfortunate, as it has been supported in even Windows 10 File Explorer and MS Paint since May 2019.
Lossless Performance[edit]
When comparing AVIF to its predecessor WebP, it outperforms it in almost every way, except for lossless compression. Both formats feature a lossless mode, and yet AVIF's lossless mode often produces images roughly 3 times larger than its predecessor, WebP. This discrepancy isn't explained by WebP chroma-subsampling; it is also 4:4:4 in lossless mode, albeit it only supports 4:2:0 in lossy mode.
The stated reason for this seems to be that AVIF is primarily designed for lossy image storage, in which it even outperforms HEIF. Because of this, WebP is currently the most efficient image format for storing lossless images.
However with that said, the old paradigm of using PNG for clip-art or images in which you don't want any mosquito noise, and using JPEG/WebP for photographs, is made outdated with the arrival of AVIF.
AVIF does not introduce mosquito noise, and does great with clipart; it's hard to even imagine a scenario in which you would want to deploy a lossless WebP instead of a lossy AVIF on the web, assuming you weren't worried about browser compatibility.
Enable comment auto-refresher
WaiLin
Yuri
Anonymous (af459b00)
Permalink |