The speed of an encoder really comes down to how many optimizations it's searching through. The AV1 format allows a lot more options when encoding, so encoder writers kinda feel obligated to try a bunch of them out to see if they save bandwidth. But if instead a codec just picked a few optimizations and ignored the rest, it could be pretty fast. Maybe Google just found a set that worked well for an average video chat.

When streaming with x264 for example, most people usually use the "fastest" or "fast" preset, anything lower and you'll start dropping frames. Similarly I'm sure they can adjust levers to make av1 work in real time.

As someone who has been reading a lot of AV1 benchmarks over the last few months, it's also unclear to me how/why they're doing it. AV1 (and specifically google's libaom) is great, and for VOD-based content it is ready for primetime, but h264 is better for realtime streaming from just about every standpoint.

Though, AV1 is way, way better than h264 when bitrates are super low... I don't know. I wish I had more details about the implementation.

How low is super low and what's the picture quality like? Could it be they're trying to save bandwidth?

The best definition for "super low" that I can come up with is "bitrates at which x264-encoded content becomes hilariously unwatchable."

I will try to be more specific. Youtube uses x264 to encode videos at a certain bitrate. Were you to encode the same video with libaom (AV1) at the same bitrate, the quality difference would probably be noticeable to a casual viewer. If you were to cut the bitrate in half and run the same comparison, the quality difference would be extremely noticeable to a casual viewer.

The article has a gif showing this. The right side is hilariously blocky, while the left is decent. Visually, from experience, it looks like somewhere between 100 to 200 kbps.

EDIT: Err, I'm stupid it says 30kbps right there. Though that definitely looks closer to 100 to me (unless framerate is lower)

As someone up-to-date on AV1, what are your thoughts on it compared to HEVC?

For chunked encoding and distribution on a massive scale (Netflix/Youtube), AV1 is the clear choice today.

For making encodes for personal use, HEVC/x265 is the clear choice today, and it probably will be for a long time.

If you want to use AV1/libaom and see significant efficiency gains over HEVC/x265, you will have to allocate a lot more encoding time. There's no way around that. You will also not be able to make use of multithreading to a significant degree, for libaom at least (I have not seriously tested other encoders). There are third-party programs in active development that perform chunked AV1 encoding for the purpose of utilizing all your cores.

aom --cpu-used=5 is currently strictly better than x265 --preset veryslow, putting aside the threading issue. Beats it in encoding time and efficiency. But it's an unfair comparison.

Super helpful reply and tells me exactly what I needed to know (I'll stick with HEVC). Thanks!

AV1 features better compression for the same image quality and a key selling point is that it's patent free. Facebook and YouTube are pushing for AV1 adoption as that's going to save them $$$ on bandwidth. We'll see.

More info: https://www.videoproc.com/media-converter/av1-vs-hevc.htm

I hope it's just not gonna be another VP9 where Google flips the switch to save some bucks on bandwidth but there not being any dedicated decode hardware in the wild yet, meaning everyone's battery gets nuked.

The problem is it has to be that way because nobody includes hardware decoders until major players are using the codec, so it's chicken and egg.

In theory the hardware vendors could notice that Google is developing a new codec which they could be reasonably expected to start using and then include hardware decoders in their devices before Google starts using it, but they don't really have the right incentives to do that. "Our device has a hardware decoder for a codec nobody is using" isn't really something customers buy phones based on. Meanwhile if the vendor doesn't put it in this year's model then they get to sell you a new phone with a hardware decoder next year after Google flips the switch and your battery life tanks until you buy the new phone.

But VP9 decoder is supported by almost every SoC now (Phones, tablets, TV, Set-top boxes, etc).

And TV/STB SoC vendors like Amlogic, Broadcom or Realtek already announced products with AV1 support.

It absolutely will. They’ve already started experimenting with that.

Not patent-free, royalty-free.

I'm going to boldly guess that you were encoding at a significantly higher bitrate than the 30kbps they mention on the page. The lossless bitstream compression part of video encoding can be a very significant portion of the encoding time on faster speed settings, so lower bitrate means faster encodes.

It also probably isn't 30 fps.

That demo looks too good for 30kbps for any codec, especially single pass real time. I am skeptical.

Also find it funny they use a 2.5MB GIF to show a demo for ultra video compression.

https://storage.googleapis.com/gweb-uniblog-publish-prod/ori...

I watched my fair share of RealPlayer video at about that bitrate 25 years ago. I see absolutely no reason that a modern codec designed for low bitrates couldn’t look that good on a talking head. It’s not like they are pandering though. They released the software. There is no need to speculate.

The software is released, but I would like to see the actual encode instead of the phony looking side-by-side GIF.

We are discussing state of the art video codecs on a page that's serving 26MB GIFs.

If you want to discuss the quality of video it is important that your own encoding does not alter the image.

GIF allows animation and lossless compression.

GIF only allows 256 colors per frame, so not really lossless when it comes to photos/video that exceed that limit. I guess there are some hacks around this, but typically they're not used.

The hacks you allude to are based on the fact that GIF also allows you to use:

* Transparency in a frame, which will show the previous frame underneath

* A different color palette per frame

* An infinite frame rate (no delay between two frames), which is also configured per frame

These three points combined allow you to show any video in full 8-bit color via the GIF format.

Unfortunately there's a difference between what GIF allows and what popular browsers allow GIF to do. Specifically all browsers set a minimum frame delay to 10ms == 100fps. This got started in the 90s due to performance concerns in Internet Explorer. Then people kept setting frame delay to 0 in their GIFs but it looked still fine in Internet Explorer. This resulted in a lot of GIFs that would look broken when the browsers would follow the GIF spec. This desire to support broken GIF files is why even in 2020 browsers limit GIF frame delay to 10ms.

Even so, if you only need 25fps for your video, you can get 4*256=1024 colors. Again, these colors can be different from frame to frame.

What other lossless "video" format is widely available in browsers?

It’s not lossless. It’s lossless after quantization of the color palette, and pretty much every encoder out there does a crap job of not losing too much perceptual or actual data in that step.

I'm just going to guess that's for those browsers that don't yet support AV1? I mean it basically just shipped

https://caniuse.com/#feat=av1

Chrome 81, still get GIFs.

It's probably variable framerate and localised frame updates.

> what I want to know is how on earth they are able to encode AV1 in real time

Cisco also has a real time AV1 encoder. They say it's all about using the right AV1 video coding tools in the right way for the live video use case:

https://blogs.cisco.com/collaboration/cisco-leap-frogs-h-264...

The presentation:

https://vimeo.com/344366650

That was on laptop cpus though. Even if Google optimized the encoder to accomplish this on mobile processors, a fully utilized cpu would drain batteries so fast that the user experience would suffer.

Codecs usually have different modes. Typically a realtime mode trades quality for speed, e.g it will be just 1 pass with a lot of optimizations disabled.

What I want to know is how on earth did they make the page 58.7 MB. This can't be.

I can't quite believe my own arithmetic but... that would mean the page is larger than 30 minutes of video streamed using the new codec. Can that possibly be correct?

Calculations here, someone please tell me I'm wrong:

The caption quotes "30kbps", but that has to be a typo - I think they mean 30KBps (240kbps).

58.7MB * 1024 = 60,018KB 60,018KB / 30KB/s = 2000 seconds 2000s / 60 = 33 minutes

I don't think the codec uses 30kbps by default, that specific example is showing what it would look like at 30kbps. Obviously if you have the speed for it, it'll probably raise the bitrate more. Duo is known for adaptively scaling up and down and smoothly switching between different network conditions.

There are four large .gif files. I believe the one you are referring to is 2.6 MB and named `Duo_540X540_TransparentBG_3s_splitscreen_05.gif`, with a split screen comparison of what it would look like at 30kbps. The overhead is the graphics of the "montage", I figure.

I find a better way of inducing horror when it comes to page sizes is referring to “multiples of Doom” rather than megabytes. The original Doom shareware release was two 1.44MB floppies, so this page is 20.4 Dooms big.

I thought that had to be a typo. Good lord, why are they shipping videos as gifs?

There are only two ways of realistically demonstrating encoding artifacts: decode the actual format client side or transmit a lossless encoding. GIF surely isn't lossless, but its losses are somewhat orthogonal to those of the encodings in question. Still, yet could have done with much less of the same.

I think their blogs are still based off Blogger which hasn't been updated in quite some time. (which they own so they could fix themsleves..)

If it's stupid but it works, it's still stupid.

But it works.

If it's clever and it doesn't work, it's surely clever ... but it doesn't work

It has been known and well understood for many years now that you should use video (like mp4 or webm) in place of gifs if you want to save bandwidth.

would encoding your AV1 encoding demo with another encode produce the desired effects?

I suspect that hardware encoding is involved. Maybe upcoming pixel phones will feature a previously unknown hardware encoder? It would make lots of sense, especially for storing videos made with the camera.

not just that but if you consider that the stream is encrypted - so not just going through https - then it might be also great tech.