Real Time Communications Featured Article

Blogger Discusses Pros, Cons of WebRTC Implementation

January 08, 2016

WebRTC has taken the communications world by storm. It has made it easier for developers to link two or more people together on disparate platforms (Windows Mobile to desktop Linux, for instance) using the common thread of Web browsers such as Chrome, Firefox, or Opera.

It can, however, be more than troublesome for developers to handle connections between peers, recording of video, and storage of both audio and video files related to these live streams. One blogger, Nikolai Bezruk – a JavaScript developer at Qualium Systems, a company that creates mobile apps for startups – leads readers in his latest post through two scenarios in which he brings two users together in WebRTC and records their interactions for later viewing.

The first scenario involves the use of a JavaScript library called MediaStreamRecorder, which is highly related to WebRTC projects but ultimately gave Bezruk problems with latency. He then switched to the WebRTC Experiments library, which uses JavaScript in a different manner, and found that his previous latency problems and issues with browser crashing had disappeared. The biggest faults he found with WebRTC Experiments was that Chrome recorded video and audio separately, recordings greater than five minutes would not respond to user commands, and that there was lag when decoding video and sending video to storage.

It succeeded in that it placed all the load on a user’s Web browser, provided simple controls for recording, and utilized the Kurento Media Server for seamless recording capabilities. What users get with this type of implementation is a simple way of handling the setup and teardown of a shared video stream. The biggest drawbacks appear heavy, so this may not be the best way of completing any sort of professional work.

The second example Bezruk described, he begins to use the node-fluent-ffmpeg library to handle the recording of a single stream and then breaking up that stream into multiple parts for sending to the Amazon S3 storage. He continues to use Kurento but makes sure to re-encode the webm recording from Kurento into an mp4 file that both Firefox and Chrome could handle. If that was left undone, the webm file audio would lag behind the video in Chrome.

This time, there was no break in audio and video files and video recording occurred in real time. This configuration, though, was difficult to set up because it required the creation of a Kurento media server and use of coturn and Node.js to transcode video and divide it into multiple parts for Amazon S3.

The takeaway for developers here is that, while WebRTC can provide a lot of tools for handle audio and video streams across a common link, it isn’t a one-size-fits-all undertaking. Application creators can choose from a number of different methods concerning which media servers to use, how they want to record video, and which recorded formats fit them best. Like Bezruk says: “there is no fairy take answer.” But that doesn’t mean developers should just throw their hands in the air. WebRTC is still in its infancy and is gaining popularity by the day. That popularity will help it become easier to handle and, ultimately, more friendly for both developers and their target populations.

Edited by Kyle Piscioniere

Article comments powered by Disqus

  Subscribe here for RTCW eNews