Moving to AV1
AV1 is just about every video nerd’s obsession for the past couple years. The compression (for web standards at least) is incredible, it’s open and royalty-free. Recent developments have made it easier to play AV1 videos on computers. Even old desktop computers (like mine) can play AV1 videos fine with the libdav1d decoder. Almost every smartphone and smart televisions have hardware-accelerated AV1 decoding too.
The video coding format does suffer a bit when it comes to encoding videos to AV1. While there are hardware decoders available, hardware encoding is very limited. For consumers, you’d have to own an Intel ARC GPU or one of the new NVIDIA RTX 4000 series cards. Outside of AV1 encoding, Intel ARC kind of suffers a bit compared to other competing cards. On the other hand, RTX 4000 series cards are ridiculously expensive.
AV1 hardware encoding should be for live-streaming and quick transcoding anyway. Typically, one should use software encoding (even for non-AV1 stuff) for delivering video-on-demand anyway. Software encoding is ridiculously slow though. I mean really slow. Prior to the libsvtav1 encoder, encoding a video (albeit on my two-core processor) to AV1 took forever. ffmpeg would straight up just freeze.
Recently, I’ve been hearing great stuff about libsvtav1 and that everybody’s been using it because of its speed. Surprisingly, it is pretty fast. It’s probably just a tad bit slower than libvpx which is what I used to encode every video in this website to VP9. At their default settings, libsvtav1 was able to preserve grain better and reduce file size better than libvpx.
Notice how the VP9 video obliterated all the grain. The scene was intentionally grainy so I wasn’t happy when the transcoded video turned out that way. This was the reason why I decided to see how much better AV1 was. The grain still isn’t as very close to the source video and one can really tell the difference. It is good enough though, as it retains most of the grain.
The size difference was also quite big. The VP9 video came out at 20.02M while the AV1 video came out at only 13.74M. Since I’m using AV1 for this video, why not use AV1 for every video? This has some drawbacks which I’ll explain later but let’s appreciate the fact that, collectively, transcoding the other video source files to AV1 came out to a total of 137M while the VP9 files are 345M in size. That’s a pretty big difference.
The AV1 dilemma
Better quality and better file size is great and all but even with the fast libsvtav1 encoder, AV1 suffers from not being supported by every web browser. If you look through caniuse.com, you’ll see that Microsoft Edge, Safari, and Firefox for Android do not support AV1 for whatever reason. People on Windows and macOS should probably just use Firefox or Brave anyway. Firefox Android users can just enable the flag for AV1 support or use Brave. iOS users won’t be able to use AV1 at all right now though. They can’t switch their browser engine so they’re essentially stuck with Safari’s which doesn’t support AV1.
The dilemma is whether or not it’s worth trading AV1’s better quality and lower file size for iOS support. Alternatively, I can use both VP9 and AV1 to provide users with a choice but it’s hard to implement it considering my goals for this website. For now, I’ll leave it be and hope Apple realizes that Safari users should get AV1 support soon. It’s strange how they support HEVC and HEIC (encoding too) but not AV1.
What about AVIF?
I actually tried converting some of my .webp files to .avif. The savings are also quite noticeable but the support for AVIF in browsers is not as good as the video counterpart. Tor Browser is what I usually use to test new features for the site and it doesn’t support AVIF yet. It probably will soon but I’m not in a rush to start using it either. JPEGXL is a competing format that’s said to be better but no browser supports it yet. It’ll take years before it’ll get into Tor Browser so for now, I’ll stick with .webp and consider AVIF sometime in the future.