WebRTC Live Stream Broadcast

• 1. WebRTC multi peers
• 2. Torrent based WebRTC chain
• 3. WebRTC Relay nodes for multiple peers
• 4. WebRTC  recorder to Broadcasting Media Server VOD

---

WebRTC has the potential to drive the Live Streaming broadcasting area with its powerful no plugin , no installation , open standard  policy. However the only roadblock is the VP8 codec which differs from the traditional H264 codec that is used by almost all the media servers, media control units , etc .

This post is first in the series of building a WebRTC based broadcasting solution. Note that a p2p session differs from a broadcasting session as Peer-to-peer session applies to bidirectional media streaming where as broadcasting only applies unidirectional media flow.

Describing some Scalable Broadcasting and Live streaming approaches below:

1. WebRTC multi peers

Since WebRTC is p2p technology , it is convenient to build a  network of webrtc client viewers which can pass on the stream to 3 other peers in different session. In this fashion a fission chain like structure is created where a single stream originated to first peer is replicated to 3 others which is in turn replicated to 9 peers etc .

Advantages :

1. Scalable without the investment of media servers
2. No additional space required at service providers network .

Disadvantage :

1. The entire set of end clients to a node get disconnected if a single node is broken .
2. Since sessions are dynamically created , it is difficult to maintain a map with fallback option in case of service disruption from any single node .
3. Client incur bandwidth load of 2 Mbps( stream incoming peer ) incoming and 6 Mbps ( for 3 connected peers ) outgoing data .

2. Torrent based WebRTC chain

To over come the shortcoming of previous approach of  tree based broadcasting , it is suggested to use a chained broadcasting mechanism .

To improvise on this mechanism for incresing efficieny for slow bandwidth connections we can stop their outgoing stream converting them to only consumers . This way the connection is mapped and arranged in such a fashion that every alternate peer is connected to 2 peers  for stream replication. The slow bandwidth clients can be attached as independent endpoints . 

3. WebRTC Relay nodes for multiple peers

The aim here is to build a career grade WebRTC stream broadcasting platform , which is capable of using the WebRTC’s mediastream and peerconnection API , along with repeaters to make a scalable broadcasting / live streaming solution using socketio for behavior control and signalling. Algorithm :

At the Publisher’s end

1. GetUserMedia
2. Start Room “liveConf”
3. Add outgoing stream to session “liveConf “ with peer “BR” in 1 way transport
   1 outgoing audio stream -> 1 MB in 1 RTP port
   1 outgoing video -> 1 MB 1 more RTP port
   Total Required 2 MB and 2 RTP ports
   At the Repeater layer (high upload and download bandwidth )
4. Peer “BR” opens parallel room “liveConf_1” , “liveConf_2” with 4 other peers “Repeater1 “, “Repeater2” , so on
5. Repetare1 getRemoteStream from “liveConf_1” and add as localStream to “liveConf_1_1”

Here the upload bandwidth is high and each repeater is capable of handling 6 outgoing streams . Therefore total 4 repeaters can handle upto 24 streams very easily

At the Viewer’s end

6. Viewer Joins room ”liveConf_1_1”
7. Play the incoming stream on WebRTC browser video element”

• (+) low CPU cost per node
  • As 6 viewers can connect to 1 repeater for feed , total of 24 viewers will require only 4 repeaters.
• Only 2 MB consumption at publisher’s end and 2MB at each viewer’s end.

4. WebRTC  recorder to Broadcasting Media Server VOD

This process is essentially NOT a live streaming solution but a Video On Demand type of implementation for a recorded webRTC stream.

Figure shows a WebRTC node which can record the webrtc files as webm . Audio and video can be together recorded on firefox. With chrome one needs to merge a separately recorded webm ( video) and wav ( audio ) file to make a single webm file containing both audio and video and them store in VOD server’s repo.

Although inherently Media Server do not support webm format but few new age lightweight media servers such as Kurento are capable of this.

(+) Can solve the end goal of broadcasting from a webrtc browser to multiple webrtc browsers without incurring extra load on any client machine ( Obviously assuming that Media Server handles the distribution of video and load sharing automatically )
(- ) It is not live streaming
(-) For significantly longer recorded streams the delta in a delay of streaming increases considerably. Ideally, this delta should be no more than 5 minutes.

---

To see the GStreamer and FFmpeg scripts , media servers ( like Wowza, Janus , Live555, Red5 ) and players ( VLC, raw RTP, RTMP , RTSP, MPEG DASH) refer to these posts

Streaming / broadcasting Live Video call to non webrtc supported browsers and media players

continue : Streaming / broadcasting Live Video call to non webrtc supported browsers and media players