The issue raised is not about video codecs, but about browsers. Apple is using their market position to artificially prevent Safari from being competed against by other vendors—that is classic antitrust behavior.
For comparison, imagine Microsoft banned all browser engines other than EdgeHTML from running on Windows. Would you find that acceptable?
You may not be aware, but chrome does exist on iOS, but even so, it is actually running the safari rendering engine because apple prevents other browser engines from running. This effectively prevents chrome or Firefox from offering a browser with av1 support (as far as I am aware) so the browser engine is relevant to the codec policy discussion.
Given that Chrome abuses its market position to ram through and continuously release hundreds of Chrome-only non-standards I view this as a net positive.
Which is the reason why I choose iOS: I trust Apple to implement the integrations in the WebView for best battery life. To get new OS features in the browser right away. Would Google Chrome implement picture-in-picture on the iPhone if they were running their own engine?
I use Firefox on iOS for the password and tab sync integration, and am supper happy that it’s using the WebKit framework. I care about the iOS experience more than some video codec support.
If the other browsers could implement their engines, you would still have the option not to install them.
So it’s okay for user who (in theory) installed a 3rd party browser on iOS to have a worse experience and potentially make themselves vulnerable to malware? That’s exactly what Apple doesn’t want.
Your argument is a straw man, he's saying that apple should be force to allow competing browser engines on iOS so other vendors can support what they don't want to...
I mean it may save them bandwidth on Apple TV+ or iTunes TV/movie purchases. But it seems they’ve chosen not to bother.
Maybe all the re-encoding would negate the benefits for them?
Maybe they didn’t think it was enough of an improvement over h264. Maybe they bet on h265 and it worked out well enough (for them) or it didn’t but they figure by the time they got everything set for VP1 something better will be ready.
I believe their main reasoning for not supporting AV1 would be the lack of hardware decoding on their chips.
A minor improvement in network bandwidth and storage costs wouldn't be as high a priority as "up to 16 hours video playback (streamed)" on the iPhone 14.
Sure they could optionally support it in Safari without hardware decoding, but a service like YouTube will want to negotiate the lower bandwidth protocol over one that will make the device's battery last longer.
Maybe the licensing cost of h265 works out better for them than rushing out AV1 decode support on their chips or lowering the average battery life of their devices.
That would certainly have been the argument at first. Battery life is EVERYTHING.
But Netflix announced they would be using it in 2016. YouTube started using in 2018, the year the standard hit 1.0.
Apple had plenty of warning and time to get the necessary hardware acceleration blocks available by now. Chips have multi-year timelines but it’s been 4+ years.
Now on the other side, Netflix actually started using it in early 2020/late 2021, depending on device. YouTube rolled it out wide in 2020. Twitch is working on it.
So Apple is at most 2 years behind the content. It’s not like it’s been 5+. And if they decided to wait to see how those early rollouts went due to hardware timelines it might make sense support only appears to be coming now (based on someone pointing out AV1 shows up now in the AVPlayer framework documentation).
I believe their main reasoning for not supporting AV1 would be the lack of hardware decoding on their chips.
I doubt it.
Apple Silicon is more than fast enough to decode AV1 in software. Sure, the battery life won’t be as good but there are other trade-offs that can be made.
Their latest chips were developed before AV1 had gained enough traction to be concerned about. I suspect that future M2 and M3 and A-series SoCs will have hardware decoding for AV1 built-in.
In the meanwhile, a future version of macOS Ventura and iOS 16 will have AV1 support; it’s just going to take a little longer. They probably want to roll it out simultaneously on iOS, macOS, tvOS, and iPadOS.
When AMD/Nvidia/Intel and Samsung/Mediatek/Rockchip/etc were able to put AV1 blocks into their chips, I'm sure Apple would be capable of doing the same -- if they wanted. Now it looks that they do not want.
Apple might have made a deal with one or more major h.265 patent holders that discourages them from fully supporting av-1, similar to how Google pays apple nine digits a year to keep Google search default in the Apple ecosystem.
Court action could compel any deal like this to be made public.
Do we want the government dictating which video encoding standards we have to use?
It’s not Apple is only allowing QuickTime, their fully owned protocol that others must license from them, and nothing else.
What is Apple doing on this issue that would be an anti-trust issue?