So, this is probably a sign that the new Pixel Smartphone will have an AV1 hardware de/encoder.
In Software, with 720p video (or more), the battery of the phone would be empty in no time.
In Software, with 720p video (or more), the battery of the phone would be empty in no time.
Still though, battery concerns aside, massive kudos to Google here for helping to advance a technology that is so important to OSS.
It's exciting to see more mainstream adoption of AV1 which will surely drive HW acceleration forward, but it's disappointing that Apple hasn't been more proactive here.
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.
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.
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.
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.