Plus, mobile devices will use embedded fixed-block ASICs for this, just like they already do for every existing codec. All codecs are completely impractical on mobile devices if you're basing your estimates off software numbers, even extremely well optimized software will kill your battery. So it's basically meaningless to try and extrapolate from optimized numbers, much less preliminary ones.
Besides, encoding AV1 is what's expensive, but mobile devices also do not necessarily need AV1 encode support anyway. They will need decode support. Slow encode support is going to be a problem for people creating and serving video. But better compression rates from AV1 substantially help mobile devices, too, by reducing bandwidth needs for providers. You're likely to see major video content providers taking the hit of AV1 encoding, while users only need to decode, and this will largely be how it is used.
I have an iPhone 7 which has no hardware VP9 support but VP9 video works well at 720p in VLC. I'm sure the battery won't last as long as playing H.264 video in hardware but I wouldn't call VP9 playback impractical.
My battery started at 90% and at the end of three hours it was at 55%. I think that's pretty good for software decoding.
I'm not sure which VP9 decoder VLC uses on iOS. I presume it's ffvp9:
https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastes...
I would highly, highly argue that they do. There is no reason in modern day that we need to all be uploading the full size of images and videos to servers to be re-compressed. It creates a significant barrier to entry for any social media platform when it should be as simple as the device itself being able to encode it, with the server checking it and creating other sizes. If AV1 becomes the great standard we can reduce a lot of costs. We already could do it with jpeg compression, but hasn't seemed to happen.
Slightly less compression rates for faster compression is perfectly acceptable. I would hope theres profiling options for that.
I wouldn't be so quick to dismiss it - video chat is a great use case for an improved codec.
So people aren't using Snapchat, Instagram Stories, FaceTime, IGTV ?
Because pretty sure encoding is just as important as decoding.
Assuming a gargantuan encoding slowdown, even in the face of hardware-based encoders on mobile devices (which, again: hardware decoding/encoding is the fact of the matter on how it will happen), then there's no reason to support AV1 encoders since it will hurt battery. You're better off with something else, because users care more about their battery than compression ratios or minor artifacts on their Insta videos.
Assuming no gargantuan slowdown, and devices are equipped with AV1 encoders that perform admirably, then your problem is solved. Just use the hardware encoder. (Personally, it's unclear to me how much of AV1 encode support is fundamental slowness that can't be mitigated by hardware and implementation, but I suspect a lot of this fear is tied up in early-stage numbers. I bet it can go much faster, even if it's still slower overall.)
If you're a media provider like Netflix for example, though, the bandwidth savings will utterly dwarf the cost of the more expensive encoding process. They encode once and serve thousands of times, and they don't run Netflix (the company) on old mobile phones. So they'll do it anyway, because they want their users to use AV1. It saves them bandwidth on a high quality video, and it saves users on their data plans and their battery.
This isn't really very hard to think about. Either AV1 encoding is fundamentally too inefficient for mobile, or it isn't. If it isn't, users can still get fast decoders (that wasn't the bottleneck), since the bandwidth savings are going to be highly desirable for everyone, basically, and they'll be pushed for. If they can be efficient enough, then there's no problem.
These issues unless solved relegates AV1 to being a Youtube and Netflix format and pretty much irrelevant for everyone else.
I like it when the goalposts move in such a way that "used by services in over 50% of US households and services where 70% of all video usage come from mobile, and offers excellent bandwidth improvements for millions of users" apparently means AV1 is a failure, somehow, based on preliminary numbers for a use case (encoding) that largely isn't relevant to mobile devices (and will improve dramatically over time making encoding more usable, anyway, as all prior codecs did.)
Unfortunately for the AV1 designers, they could have realized this fatal flaw sooner, had they only consulted the grand expertise of..... a random internet forum user.
Reference implementations are not about performance, they are documentation. They are not supposed to be used for anything else but documentation.
Your conclusion is ridiculous. There is absolutely not reason assume that av1 is fundamentaly more power consuming that HEVC.
A tank uses more gasoline that a VW Beetle. This statement is true, and as irrelevant as your statement.
That is valid for all H.262 , H.263, H.264 and H.265, as well as the up coming H.266 VVC. The current Av1 isn't a documentation. Nor it is a Reference Implementation in the regards of all MEPG codec. The AV1 is built on a working, professionally made libvpx encoder built on VP9.
>There is absolutely not reason assume that av1 is fundamentaly more power consuming that HEVC.
It definitely will be more complex, both encoding and decoding. Its fundamental complexity is much higher then HEVC, how far could they optimise so they are close to 5 - 10x of HEVC is a different story.
The development of the codec has been done with constant input from the hardware developers who are backing AV1 (Intel,AMD,Broadcom,NVidia etc) in order to make it effective when used with hardware acceleration. Just watch some of the developer presentations on Youtube.
Your fear that all the streaming and hardware giants would cooperately develop a codec that won't be effective on mobile hardware is unfounded.
https://medium.com/netflix-techblog/more-efficient-mobile-en...
YouTube and Netflix adopting VP9 before others doesn't make VP9 irrelevant for everyone else. The same is true for AV1.
It's maybe a little early in terms of available computing power (and how optimized encoders currently are) to think about AV1 mobile encoding.
The trend is overwhelmingly towards mobile being the dominant platform for video. And if your videos can't play on the majority of the iOS and Android it's simply a non-starter. Look at what happened to Flash once Apple banned it on iOS.
Yes, the reference implementation of encoding is slow. Being fast is not a high priority for a reference implementation. Optimized implementations will come later. ASIC implementations will come later. The H.265 reference implementation was similarly slow, and it’s not a problem. And mobile devices primarily care about decode performance.
Please provide evidence. Because all other data has shown it to be 100x slower.
There is a reason why people are obsessing over encode speed.
> Please provide evidence. Because all other data has shown it to be 100x slower.
I got this!
H.265/MPEG-HEVC is the latest video coding standard... it's well known that reference implementation of HEVC codec, HM, acts an important role during standardization... However, HM is far from a practical codec because of very slow coding speed even on modern multi-core computers.
https://ieeexplore.ieee.org/document/7041782/ (Dec. 2014)
Also there are already an alternative AV1 encoder in the works, RAV1E, written by Mozilla in Rust, so there will be competition which will likely speed development, and the x265 developers have stated that they will create an AV1 encoder if that's where the market goes, which at this point seems very likely given that all the major players are backing this codec, coupled with the fact that it's royalty free and thus can be implemented anywhere.
Today you can achieve >200fps with CUDA-based encoders.
Not sure why this issue keeps getting brought up. It's baseless and completely untrue.
Reference implementations of codecs are always slower. AV1 hasn't had the benefit of years of optimizations yet, so this slowness is to be expected.