Time to look at 2015.
I will be posting elsewhere about my predictions for 2015 from WebRTC. These will focus on my predictions for what will happen this year in the market.
What I want to focus here is on what should you actually be expecting to see in the WebRTC codebase itself and in the things you need to do to start preparing for them. WebRTC is still going to be a “moving target” in 2015, so if you are looking for something you can implement and then stop investing in maintaining and further developing – go for some other technology.
The list below is based on Google’s announced roadmap from June as well as from the many changes in the market lately.
VP9
Google has added VP9 support to WebRTC this last couple of months, and while not in production, it is available for those who want to play with it. I have covered the implications of VP9, so I won’t be repeating that here.
The latest decision of the IETF for the mandatory to implement codec being both VP8 and H.264 are not going to change anything here. If anything, Google will try and accelerate the incorporation of VP9 in WebRTC to make sure H.264 is there only for interoperability with legacy systems and nothing more.
Microsoft will ignore VP9 in their implementation for now. The big question will be with Mozilla. Will they be adding it to Firefox now that they are not friends with Google?
H.264
H.264 is the competitor of VP8. And the “other” mandatory video codec in WebRTC.
It is already supported by Firefox, and will probably be the first video codec implemented in Microsoft’s browser (be it IE or Spartan). Ericsson implemented it in their OpenWebRTC project.
While Google probably prioritize VP9 ahead of H.264, it will implement it eventually.
The main implication here is the need to do more testing for services, as they may need to use both VP8 and H.264, based on the scenario. This is a bit worrying as it means rising costs for developers, and bringing WebRTC to the fold of what’s wrong with existing VoIP services. The optimists would say that WebRTC had to deal with multiple codecs anyway, so here’s the chance to start checking it.
For now, my suggestion would be to use H.264 for use cases where anything else means transcoding or when Internet Explorer support is critical.
VP8 HW encoding
Hardware encoding is the holy grail of video codecs. Without it, an implementation eats up CPU and battery life. Detrimental to mobile. Bad to desktop.
Today, VP8 is mostly a software implementation. As time goes by, more hardware manufacturers are adding it to their chipsets. There’s already a camera module with hardware based VP8 encoding out there. In 2015, we will see Android smartphones with VP8 encoding. Hopefully, Google’s WebRTC team will have the time to add this capability to their implementation.
The result will be better performance on mobile.
QUIC
If you are using the data channel, then the protocol you use there is SCTP. Google stated their intent to look at QUIC as a possible replacement for SCTP.
QUIC is a low level protocol developed by Google to improve browser networking performance. It started with Google working on a protocol called SPDY, which is now used all over the internet, and is being wrapped into HTTP/2. Placing it in WebRTC is an interesting move – something that should excite those developing P2P CDNs and rely on heavy data channel traffic.
If this relates to you, make sure to beef up your knowledge and understanding of QUIC and to follow Google’s WebRTC release notes to see when it becomes available.
API changes
WebRTC standardization is moving towards something called promises which should make the life of JS developers simpler. There’s more about it in a webrtcHacks interview with Dan Burnett.
My guess? In 2015, the guys at the standardization organizations will be hard at work polishing up many areas of WebRTC APIs. It will rattle existing implementations a bit and will also bring some interesting new capabilities. Be ready to modify your code… again.
ORTC support (SVC & SFU)
The work on ORTC is progressing nicely. You can view it as the version upgrade of our current WebRTC implementation. The main target? Killing SDP.
The main benefit of ORTC, besides making things easier for developers, is its ability to control media channels better, paving the way for better multipoint implementations – especially one that make use of SVC and SFU.
SFU is going to be the dominant mechanism to support multipoint in WebRTC. There are many reasons for that – some economic and others related to user experience. I’ll leave that to a future post.
Better IOT
Not Internet of Things. Interoperability.
People whine and complain about the differences between Firefox and Chrome. They miss the fact that for a lot of use cases, these differences aren’t that bad. The main challenge begins with multipoint – an area that is hard even for legacy VoIP solutions.
In 2015, some of the issues with Firefox and multipoint support will get resolved, paving the way for many Chrome based services to be available in Firefox.
H.264 will come later this year to Chrome, and when that happens, then services relying on Firefox’ implementation of H.264 will run on Chrome.
As with any other protocol, there will still be differences across browsers, and those who vocally complained in 2014 will still be vocal in 2015.
Why is that important?
WebRTC is still a new technology. Changes in the implementation and capabilities are expected to happen in 2015.
A lot of these changes will enable new use cases to be developed. Others will break existing implementations.
Better be prepared for what’s ahead and not get caught unaware.
Are you hearing anything about VP9 (with or without SVC) processing being supported in camera hardware?
Only in the area of intent – not in real implementations today. This is at least 12-18 months away.