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

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.



Yup, came here to ask whether or not anyone knows of any hardware shipping with AV1 decoding.

Still though, battery concerns aside, massive kudos to Google here for helping to advance a technology that is so important to OSS.


The only thing I know of is Intel's upcoming RocketLake which has AV1 acceleration. It _looks_ like it's both encoding and decoding.

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.


I saw that new TVs are starting to ship with AV1 decoders since it seems highly likely that netflix will move that way soon.


Netflix is already testing AV1 in production. If you enable test participation you may receive AV1 streams right now. Youtube is also now sending AV1 streams, including to newer smart TVs.


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: