We’ve got Google’s WebRTC draft. We have Microsoft’s WebRTC draft. Now we’re just missing Apple’s
It has been half a mystery up until now as to what Microsoft will do with WebRTC. We have 4 large browsers these days:
- Google Chrome – it is clear what Google plans for it with regards to WebRTC
- Mozilla Firefox – stated upfront that they support WebRTC – and they do
- Apple Safari – no comment. Typical Apple
- Microsoft Internet Explorer – there were indications that they will be adopting WebRTC
Now Microsoft has decided to go for WebRTC, with some minor changes. These changes will include getting codecs that are more “comfortable” for Microsoft (from a business perspective) and a few other changes that will make Skype’s life easier, and Google’s life harder. This can complicate things in the short run and give Microsoft the time they need to get into this game.
The only browser missing now is… Safari. And while Apple has good reasons to ignore this spec, they will be hard pressed to continue with this stance much longer. They can drag for another year for sure, but I don’t think they will be able to hold on more than that – assuming Microsoft and Google can come to an understanding…
Assuming Apple wants to support something like WebRTC, but also want to protect their interests – what would they do? Here’s a short list of changes to the spec that I am sure they are thinking about:
1. Replace VP8 video codec with H.264
- H.264 is a patented video codec, and Apple (as Microsoft) has patents there, so they get money from companies using this codec – the more it gets used they richer they become
- H.264 has a hardware implementation on every chipset shipped with an Apple OS these days – iOS or Mac. This means they can offer better video quality this way – a lot better than what they can with VP8
- AAC-LD is already implemented on iOS – probably also in hardware on their mobile chipsets. Using it and not Opus makes sense to them
- Apple might even have echo cancellation done by hardware, which means they can use it better or even only with a hardware voice codec – so AAC-LD is again the better option over Opus or any other voice codec
- AAC-LD requires patent payments. I am not sure if Apple gets money out of it, but it pays for it already due to the use of FaceTime. This means that having this mandated means hindering competitors who will now need to pay for it as well
2. Replace Opus voice codec with AAC-LD
–
I don’t think that Apple would really want or need to change anything else – the above will fit nicely with their FaceTime capabilities, but will allow them to keep it in a proprietary walled garden without any interoperability. Being a company that focuses on limiting the use cases in order to improve the user experience, I don’t see them voting for more flexibility.
They should definitely get into the game and come up with their own codec requirements – if they don’t, they might find themselves needing to implement additional codecs instead of using those that work best for their current strategy.
Does all of this turn Qualcomm, or maybe ARM, into the WebRTC kingmaker?
To me, the core to all of this seems to be which codecs & other bits of the voice/video stack get implemented in hardware. Clearly H264 and AMR-WB are the mainstream telecoms choices and are being instituted in the chipset part of the market.
But if Qualcomm or ARM decide to give native support for a broader set of codecs, presumably that reduces many of the barriers, even for Apple?
Dean,
While hardware support is an issue, I think the broader story here is patents and licensing.
I am not sure if Qualcomm has or hasn’t got patent rights on H.264, if it does, then why should it switch to anything else? If it doesn’t, why should it invest in yet another video codec? Qualcomm’s strength as far as I know was never in the multimedia side, so adding codecs is a real pain for them.
For anyone wanting to hurt Apple directly, adding VP8 would do the trick for awhile 🙂
The sound quality of AAC-LD is terrible. They won’t be able to ‘replace’ Opus, because it will be a mandatory to implement codec for WebRTC. They can add AAC-LD if they want but they still need to support Opus.
It’s amazing that somebody who’s presenting at a WebRTC conference could be so completely misinformed. The idea that Apple will “replace” Opus with AAC-LD is completely absurd. AAC-LD is of zero use at low to moderate bitrates. That means it’s too inflexible to compete with the codecs that have been seriously mentioned in the rtcweb debates. Even at high bitrates, its only area of competence, its quality compares very poorly to that of Opus.
The hardware support question is an irrelevant red herring. With the computing power in today’s mobile devices, audio codecs are not a significant burden on the CPU; an A5 should be quite capable of running the Opus encoder and decoder at ~100x realtime. Further, because audio simply doesn’t have the kind of massive parallelism that video has, dedicated hardware implementations of audio codecs really can’t provide all that much of a benefit. The only devices where hardware audio codec support is still important are extremely-low-cost embedded devices with no support for video or for general-purpose computing. That’s not the primary market for WebRTC.
Dan,
While you are correct about quality differences of the codecs, I’d go as far as to say that it doesn’t really matter.
My issue here isn’t a technological one when it comes to the decision but rather a business/political one.
Standards choices aren’t done on tech reasoning alone: there are other things at play.
AAC-LD was good enough up until today for video conferencing and is good enough for FaceTime, so where is the real issue?
Opus is the word de-jeur, but a year or two from now there will be a better codec that will put Opus to shame. Should we wait until then? Should we replace Opus immediately at that time?
As for hardware – real time is hard. I’ve dealt with it in the past – on ARM chipsets, on Intel chipsets and on a few others. The moment you start doing things in software, on an OS that isn’t real time (iOS and Android aren’t) then coding becomes trickier and you stand to lose some of the quality of experience due to collisions with other processes.
At the end of the day, I am all for Opus. But I just think Apple isn’t.
3 years passed and still no WebRTC support in Safari. Maybe the mizu webphone will add some workaround also for this. Also still missing from IE and Edge.
True, though rumors have it we will see Safari support – they seem to be working towards that goal.