I had a go at encoding a video using the new AV1 codec. This is Peter unfolding his Brompton at Montparnasse station.

As of writing this post, you should be able to see that video with any recent version of Firefox, Chrome, Opera, and Edge. It was encoded following this guide on FFmpeg with the libaom-av1 encoder. As for the efficency of the codec, this clip is only 3.7 MB, it’s encoded with a bitrate of 1Mb/s, meaning it should stream fine on an average UK mobile connection. For 30 seconds of 1280x720 video at 30fps, this is a very slim file, and I can’t see a major degradation in perceptual quality either.

Here’s another example, of someone working at the cake shop in the covered market in Oxford.

And another example, the aftermath of a car crash on Granville Road in Leicester.

I recorded all of these stock videos myself, and I dedicate them to the public domain for anyone to use.

Single core performance

I rendered the cake shop video on a shared server, on which I have a single dedicated CPU thread. The libaom encoder isn’t multi-threaded so we’re limited to one core anyway. Here’s a general comparison of encoding time with a range of codecs.

Codec Size Encoding time
Original 71.4MB 00:00:30
Compressed H.264 3.1MB 00:05:04
Theora 29.9MB 00:01:42
VP8 3.8MB 00:04:39
VP9 4.4MB 01:47:49
AV1 3.7MB 47:29:47

As you can see, AV1 takes a long time to encode. There’s a faster encoder in development called rav1e, but I haven’t tried it yet.

I also had a go using Amazon Media Encoder. That service only took about six minutes to encode the first video to AV1, so it’s clearly accelerated somehow. Unfortunately seeking in the video was broken, and there were other downsides (forced MP4 container). I can see potential with this in future, if it saves time and effort in situations where I don’t want to hang around fiddling with encoding settings.

Comparison

One of my ideas was to set each codec at a fixed low bitrate and then play them all simultaneously in a grid to show off the differences. Here are screenshots for comparison, all encoded at 128Kb/s.

video_comparison

This is not a scientific comparison, I’m not measuring PSNR, and perceptual video quality is subjective. Keeping in mind that these are all heavily compressed to the same level, in general I’d say AV1 looks closest to the original. Also, despite all encoding at the same bitrate, the resulting files are not all the same file size, and I can’t understand that.

Why compress video?

My original plan for this comparison was to use a video from one of the Source engine games. The source video recorder outputs every single frame to a Targa file. To calculate that, at 30fps a clip of 3m20s amounts to 5,700 files. On my drive it comes to 24.6GB, plus lossless WAV audio. At that bitrate a typical 90-minute feature film would be well over a Terrabyte.

In this case, I’m just satisfying personal curiosity in video compression. There are not enough people visiting this blog to justify other optimisations, such as generating DASH manifests.

AV1 was quickly adopted by large streaming services like YouTube and Netflix. These services have exclusive control over how they choose to distribute video, and they serve up enough content that even small efficiency gains make a huge difference to their bandwidth. While it’s a small advantage for me, I still appreciate being able to host higher-quality video at lower bitrates. Everyone benefits! Except anyone using Safari.

Proprietary formats

Video on the web has long been held back by proprietary formats, and royalty-free efforts like Ogg Theora didn’t end up with widespread adoption. Before the inclusion of media elements in HTML5, videos in the browser relied on various plugins:

Looking back on that time, video on the web has come a long way! But, there is still a problem. When HTML5 video was introduced, no standard format was specified, and for a long while different browsers supported different formats. Firefox only started natively supporting H.264 in 2015, and in 2020 Safari still desn’t support WebM video. Overall we can see this set back video standards by about a decade.

Since then, Google pushed the development of VP8 and VP9 codecs, used on YouTube and Chrome and Android. It’s a weird irony that the best chance for a truly free video standard was foisted on the web by a company with increasing monopoly control of the browser.

There’s currently no support for AV1 in Safari and most of the mobile browsers, although since 2018 Apple has been part of the group of companies overseeing codec development. New video cards and SoCs are starting to include hardware decoding too. So, I’m quite willing to compromise on compatibility now, in the knowledge that future support is on its way.

AV1 satisfies every requirement of a codec which is efficient, royalty-free, and expected to enjoy widespread support. It looks like video on the web might soon be a solved problem.