Contents
- 1Introduction
- 1.1Disclaimer
- 2Updates
- 2.1.1OBS V23 - 19th February 2019
- 3Contents
- 4VMAF
- 4.1History
- 4.2How it works
- 4.3Examples
- 4.4What to expect
- 5x264
- 5.1History
- 5.2Results
- 5.3Conclusions for x264
- 6x265
- 6.1History
- 6.2Results
- 6.3Conclusions for x265
- 7QuickSync
- 7.1History
- 7.2Results
- 7.3Conclusions for QuickSync
- 8NVENC part 1
- 8.1History
- 8.2Results
- 8.3Special note for NVENC Part 1
- 8.4Conclusions for NVENC Part 1
- 8.4.1Kepler
- 8.4.2Decisions decisions...
- 8.4.3Final thoughts on Maxwell and Pascal H.264 AVC
- 9NVENC Part 2
- 9.1History
- 9.2Results
- 9.3Conclusions for NVENC Part 2
- 9.3.1H.264 AVC and live streaming
- 9.3.2H.265 HEVC and offline encoding
- 10VP9
- 10.1History
- 10.2Results
- 10.3Conclusions for VP9
- 11AV1
- 11.1History
- 11.2Results
- 11.2.1Additional
- 11.3Conclusions for AV1
- 12Final thoughts
AV1
History
AV1 was finalised in 2018 and is the sequel to VP9. Like it’s predecessor, it is also royalty free. AV1 saves about as much data for the same quality from H.265, as what H.265 did from H.264. It truly is the next generation video standard in terms of bandwidth saving and improved quality. FFMPEG includes libaom-av1 as the free software encoder for AV1. There are some others out there, but they are still in the early stages of development. AV1’s biggest drawback is its extraordinary level of complexity. Currently, just playing a 1440p 60fps video hammers most consumer CPUs bought before 2019. I include it in this analysis just to compare quality per bandwidth to the current popular encoders. At the time of writing this, it is not feasible to live-stream using AV1 in OBS.
This analysis uses version libaom-av1 1.0.0-900-g7715ae1c7. There are issues with bitrate conformance that I had to try and resolve, but the basic command is as follows:
ffmpeg -y -i original.mkv -c:v libaom-av1 -strict experimental -b:v 6M -pass 1 -an -cpu-used 3 -tile-columns 4 -tile-rows 4 -row-mt 1 -threads 4 -f matroska NUL && ^
ffmpeg -y -i original.mkv -c:v libaom-av1 -strict experimental -b:v 6M -pass 2 -an -cpu-used 3 -tile-columns 4 -tile-rows 4 -row-mt 1 -threads 4 -f matroska AV1_6_CPU3_t4x4_th4.mkv
Results
The results speak for themselves. Here’s some things to take note of:
- AV1 beats all other tested codecs, at all tested bitrates.
- AV1 at 3Mbps and lower had bitrate conformity issues. The results are there as a curiosity and should be taken with a grain of salt. The final file sizes suggest that libaom-av1 resists staying under the limit and ends up cheating.
- AV1 at 6Mbps beats all H.264 AVC and H.265 HEVC at 8Mbps, even Turing and x265 Slow. In fact, it’s nearly as good as VP9 at 8Mbps.
AV1 achieved all that marvellous increased quality and bandwidth savings with speed 3 and 4. The possible range is 0 to 8, with 8 being the fastest. It’s possible that speed 0 through 2 will be even better. But I didn’t have the patience to test more presets because of how long it takes. Comment below if you’d like to see this in the future.
Additional
AV1 doesn’t just improve quality or reduce bitrates. It provides additional features that simply aren’t in other codecs. One example is S-Frames. In current codecs, viewers may need to switch quality mid-stream if they experience connection issues. This currently requires a key frame. The more key frames in a video the more seamless this switch happens. However, key frames use more bandwidth, the more frequent they are, the more bandwidth the video uses overall. AV1 implements S-Frames (switch frames) to change this. S-Frames are less data intensive than key frames, but still enable switching. There’s a good description on it by Tarek Amara from Twitch here:
Google has started testing AV1 on YouTube to study browser compatibility. If you have Chrome for desktop release 70 or later, check out this video by Dua Lipa. Should Google think you can play it, you’ll get the AV1 version, if not you will get the VP9 version. If you can’t play VP9, you’ll get the H.264 AVC version.
Conclusions for AV1
Although the bitstream is finalised, the encoders are not. It’s still very new and bound to get faster. There is a long way to go though. Encoding at cpu-used 3 gave a speed of 0.0016x the source test video. That is 625 times slower than the 60 fps needed to stream live. The encoder would have to become 25x more efficient, and CPUs 25x faster, to reach real-time on this test. It’s a long way off regular consumer Twitch streaming capability, but it looks very promising.
Agamemnus has a passion for gaming and an eye for tech. You can see him streaming occasionally on twitch.tv/unrealaussies and catch him on the Unreal Aussies Discord. Evidence > Opinion.