▲ | dmitrygr a day ago | ||||||||||||||||
I suspect (with no inside knowledge) that this is a battery life play. CPU decoding == bye bye battery. It is much better to force the server to serve you something that you CAN hardware-decode. | |||||||||||||||||
▲ | jchw a day ago | parent | next [-] | ||||||||||||||||
For AV1 this is true, but we don't really need to postulate about whether or not Apple plays games to suppress open codecs, they do it constantly. Like when they finally eventually added support for Opus, but not Ogg containers, so you had to stuff Opus in a CAF that only Safari can support. Opus is also now supported in WebM, but you still can't just decode Ogg Opus, and there is still no sensible audio-only Opus container supported in Safari right now. Apple devices have had accelerated VP9 devices for literally years, which didn't stop them from simply not supporting VP9 during that time period, despite no reason (i.e. battery life) and despite that it has been patent unencumbered for that entire period. And so much for battery life... If you are on a Wikimedia website on an iPad, it will use open codecs no matter what, and if you are on an Apple device, you might just get a software decoder in WebAssembly instead, if you're not on a new enough OS. | |||||||||||||||||
| |||||||||||||||||
▲ | karmakaze a day ago | parent | prev | next [-] | ||||||||||||||||
Perfect. Apple can implement efficient decode in current/next gen devices then enable support in iOS Safari/WKWebView to chew up battery life of older devices. It's more defensible than Batterygate[0]. For current transition, Liquid Glass might be enough extra load. | |||||||||||||||||
▲ | cubefox 13 hours ago | parent | prev [-] | ||||||||||||||||
If that were the only reason, Apple wouldn't have waited until the M3 chip to include an ASIC for AV1. Other chip manufacturers had AV1 support significantly earlier. |