Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not even sure it's at all possible to encode AV1 in realtime without hardware acceleration. Decoding, on the other hand, isn't all that computationally intensive.


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

Video encoding is a modeling and search problem. Codecs try lots of different ways to represent the input data and do their best. You can evaluate the costs and benefits of each piece of the encoder to decide which parts to have on or off.

Obviously a speed-tuned AV1 compressor won't achieve maximum efficiency, but it might still perform better than an H264 or H265 compressor since it has more efficient tools available to it.


> I'm not even sure it's at all possible to encode AV1 in realtime without hardware acceleration

On large PCs it's been possible for a while, through SVT-AV1. On phones I think less so right now, if you're talking about using AV1 to get noticeably better rates than VP9.

That said, it's possible that they have a reduced set of tools/passess that can run in realtime on a phone, and it looks like the rate is extremely low, which also improves encoding complexity. Even software VP9 encoding has been rare on phones though up to this point, so I'm not sure exactly what is meant by this change.


> On phones I think less so right now, if you're talking about using AV1 to get noticeably better rates than VP9.

Yes, otherwise what would be the point of using AV1 in the first place. Many (most?) Android phones already have hardware VP9 and HEVC encoders. iPhones only support HEVC, so you know what the choice has to be to maximize the compatibility. HEVC and VP9 offer pretty much identical subjective visual quality for a given bitrate for the purpose of video calling - I tested a lot.

But anyway, even if you were able to run a realtime software-only AV1 encoder on a phone, there's still the concern of heat and battery life. Mobile devices usually aren't designed to run at 100% CPU load for any kind of extended period of time. Hardware codecs are much more power-efficient.


There is just one pass in video telephony because you can't wait for the call to be over to start a second pass before you send the video.


I did not mean passes in the sense of two-pass rate control.


Don't think of a codec as just a magic black box that takes in frames and spits out compressed frames.

A codec is more like a toolbox or instruction set. It gives you a bunch of options you can use in order to compress a frame.

Unless AV1 removed some of the tools from the earlier codecs it drew from (e.g. VP9), it's entirely possible to write an encoder with similar performance characteristics as the earlier codecs.

What I'm getting at here is that AV1 isn't inherently computationally complex. Its reputation for being computationally complex comes from people looking at the reference encoder early on during development and treating that as the final product.

The reality is that it shouldn't be too far from HEVC in terms of computational complexity.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: