We’ve got Google’s WebRTC draft. We have Microsoft’s WebRTC draft. Now we’re just missing Apple’s[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]
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.