Hacker News Reader

Comment by motbob | Hacker News Reader

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.

View on HN

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?

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.

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

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.

Not patent-free, royalty-free.

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!

Reply on news.ycombinator.com