We are now closing up 2012, heading to 2013. Time of predictions and… roadmaps. What should a future WebRTC roadmap include?
WebRTC in a way is a done deal: it now runs on Chrome and soon on Firefox, Microsoft is there to some extent and Apple will have no choice but to join – maybe a bit later down the road but join they will. So as we are wrapping up this year, it is about time to start looking at possible directions that WebRTC’s development itself can take us.
Not to burden anyone’s vacation, here are my suggestions to the team at Google working on their future plans (not that they need me, but humor me with this one – make me feel important):
Higher resolution
First off, it is time to get some better resolutions from WebRTC. We run it using software video codec implementations and someone needs to put a stop to it – preferably the chipset vendors – not that I care – I am only making wishes here.
Higher resolutions means more use cases that can be covered with WebRTC. It means better penetration into the enterprise market. It means HD.
Mobile focus
What we miss today with WebRTC is mobile. Not something that goes as a third party SDK (my favorite deployment model for mobile at the moment).
The reason this needs to be in a higher priority is that mobile is complex, and leaving this to application developers or third party SDK developers leaves too much of a barrier of entry. This by the way, is a way for the telephony API vendors doing WebRTC to work on differentiation – the level of quality they offer to their media solution on Android and iOS…
What does mobile really means? Not only porting the solution, but also (and mainly) taking care of the whole media management when running on different types of networks: be it Wi-Fi, HSPA or LTE. I’d focus here on LTE first.
Better support for multipoint
That’ a nice to have for some of the use cases, but a lot of the vendors dealing with WebRTC today are trying to solve the multipoint challenge. And it is a huge one.
It would be nice if WebRTC introduced an “out of the box” solution that allows better support for multipoint – probably in the form of SVC (Scalable Video Coding – a technical thingy that allows encoding once in different bitrates, resolutions, qualities, etc).
If the rumors of Google Hangout switching to WebRTC soon are correct, then this is probably a done deal already.
–
What would you ask from WebRTC to add?
Here are some pretty obvious next steps:
Screen Sharing – build a screen/window/region capture engine (similar to what you see with GoToMeeting or Join.me) into the browser and render it on the far-end either as video (VP8 / H.264) or using NoVNC-style rendering in a Canvas element with screen data relayed using the data channel.
File Sharing – send and receive files using the standard file selection form element and the data channel.
Recording – an API allow the browser to record remote and local media streams to local storage.
Input Controls – an API to allow browser apps to switch from one input device to another.
If i remeber correctly there was a proposed javascript api to record the local/remote mediastream.
Those can all already be done in Javascript at least where the data channel is available of course.
I’m not sure what you mean with switching input control.
What I’m wondering about is not multipoint, but: multipath
So you can move from LTE to WiFi and back without losing a your communication.
You can’t do screen sharing given the current state of browsers: there is no built in means to capture a stream of screen images. Doing so would not be enormously difficult – tools like VNC have done it for years. The various browser manufacturers would need to embed the capture capabilities in the browsers and determine how the resulting data gets relayed – over the data channel or as a video media stream.
Switching input is simply allowing the user to change from one camera to another, one microphone to another, etc. Think of things like tablets and phones that have two cameras – front and back. Or of newsrooms or television sets where there are several active cameras (farfetched, but you get the point).
As for the data switch / multi-path issues – that’s something that could (should?) happen automatically as a result of ICE – if the network conditions change, the ICE engine will begin sending new candidates (presuming that the signaling system is able to establish a connection to the server).
On multipath, yes I thought ICE might be able to solve it. Just haven’t looked at it and I didn’t know if it would be seamless.
I think screencapturing is possible:
http://www.html5rocks.com/en/tutorials/streaming/screenshare/
Have a look at the video http://www.youtube.com/watch?v=S6-rAv6bU8Q from this article: https://blog.mozilla.org/futurereleases/2012/11/30/webrtc-makes-social-api-even-more-social/
While you mention VNC, VNC over WebSocket is possible with noVNC. OpenStack (cloud/virtualisation) for example uses it to give people access to the graphical interface of VM in their dashboard.
And even for RDP over WebSocket there is also FreeRDP/WebConnect:
https://github.com/FreeRDP/FreeRDP-WebConnect
1) higher resolution: done with the implementation of the constraints api.
2) screen sharing. being worked on.
3) mobile. Chrome team is now working *hard* on this now that things around the APIs are getting more stable.