If the codec can not be implemented efficiently on existing battery powered handheld devices, it is pretty useless. That is the only metric that counts. Even if, it will take many years to a decade to spread, considering the replacement rates of those devices.
HEVC/H265 implementations were initially very poor also, but it doesn't mean much now.
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.
> All codecs are completely impractical on mobile devices if you're basing your estimates off software numbers
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.
Yes, but my point was don't underestimate software decoders on modern mobile devices. As an experiment, I left a local 720p30 VP9 video with Opus audio running in a loop in VLC on my iPhone 7 for 3 hours. Both video and audio are being decoded in software.
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:
>but mobile devices also do not necessarily need AV1 encode support anyway
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.
Whether or not they use it is a completely different matter from whether AV1 is useful for those scenarios.
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.
The problem is that reference implementations of AV1 are 100x slower than HEVC at encoding. And so hardware decoding may ether be (a) impossible on current devices or (b) likely to destroy battery life. The only option is some breakthrough in the complexity of the encoding algorithm.
These issues unless solved relegates AV1 to being a Youtube and Netflix format and pretty much irrelevant for everyone else.
> Youtube and Netflix and pretty much irrelevant for anyone 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.
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.
>And so hardware decoding may ether be (a) impossible on current devices or (b) likely to destroy battery life.
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.
The most computationally efficient encoding algorithms can do hundreds of frames per second at 720p even on mobile. The price you pay is quality and filesize - it'll be large and look awful.
h265 had the exact same problems too. AV1 is not implemented on mobile, yet. Both Apple and Google are on board with this, as soon as it is completed I believe it will spread quite quickly.
Also TV boxes and embedded SBCs. Having an AV1 decoder on board of say a Raspberry PI or other similar board would make a difference. There's a lot of them around playing movies through Kodi.
Not sure why this was down voted. It really is the only thing that matters.
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.
It’s downvoted because this comment appears in literally every discussion about new codecs, is misguided and trivially countered every time, and yet it persists. People enjoyed this discussion the first, second, and maybe even third time. By the twentieth time, people get tired of commenters making these kinds of baseless assertions that fundamentally boil down to an accusation of staggering incompetence on those involved in designing the codec.
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.
>> The H.265 reference implementation was similarly slow,
> 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.
Encode speed hasn't seen much optimization, the bitstream was frozen just weeks ago.
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.
The article also incorrectly calls AV1 "patent free".
It's royalty-free, but what that really means is that contributors are licensing their AV1-connected patents to everyone for free. That's all fine and good as long as AV1 isn't found to infringe on patents owned by non-AOM members.
AV1 is almost guaranteed to infringe on patents too.
VP8/VP9 both were patent encumbered and required licensing from MPEG-LA. It's going to be interesting to see what happens if AV1 does take off whether the big MPEG-LA patent contributors decide to go for royalties.
The graph starts at 50%?
And they didn't mention in the Moscow State University test, AV1 was 300x to 1000x slower.
While I like competition from AV1, whatever they are doing in terms of marketing really doesn't resonate with me.