WebRTC - scalable live stream broadcasting / multicasting

Question

PROBLEM:

WebRTC gives us peer-to-peer video/audio connections. It is perfect for p2p calls, hangouts. But what about broadcasting (one-to-many, for example, 1-to-10000)?

Lets say we have a broadcaster "B" and two attendees "A1", "A2". Of course it seems to be solvable: we just connect B with A1 and then B with A2. So B sends video/audio stream directly to A1 and another stream to A2. B sends streams twice.

Now lets imagine there are 10000 attendees: A1, A2, ..., A10000. It means B must send 10000 streams. Each stream is ~40KB/s which means B needs 400MB/s outgoing internet speed to maintain this broadcast. Unacceptable.

ORIGINAL QUESTION (OBSOLETE)

Is it possible somehow to solve this, so B sends only one stream on some server and attendees just pull this stream from this server? Yes, this means the outgoing speed on this server must be high, but I can maintain it.

Or maybe this means ruining WebRTC idea?

NOTES

Flash is not working for my needs as per poor UX for end customers.

SOLUTION (NOT REALLY)

26.05.2015 - There is no such a solution for scalable broadcasting for WebRTC at the moment, where you do not use media-servers at all. There are server-side solutions as well as hybrid (p2p + server-side depending on different conditions) on the market.

There are some promising techs though like https://github.com/muaz-khan/WebRTC-Scalable-Broadcast but they need to answer those possible issues: latency, overall network connection stability, scalability formula (they are not infinite-scalable probably).

SUGGESTIONS

1. Decrease CPU/Bandwidth by tweaking both audio and video codecs;
2. Get a media server.

Disproportionate

"The only way to build a scalable app is to use a server side solution." That seems pretty clear... As for WebRTC, it was never intended for large-scale broadcasts. Use something that supports multicast for that, or if you have to go over the Internet, a server-based one-to-one connection, as ISPs do not route multicast. – Ollieollis

Thanks for the answer, it is pretty clear to me and... unfortunately what I expected. What about HLS, is it possible to use, lets say, getUserMedia() to capture the video from webcam, post it to the server in real time and let other people to pull it from the server? – Disproportionate

Disclaimer: I am fed up with Flash, so Flash doesn't work for me. – Disproportionate

Why not use WebRTC from client to server? The issue is in distribution, in that the client's connection can't handle it, so send one steam to the server and stream to clients from there. Bandwidth is going to be expensive, but you cannot get around either sending a single stream to each user or having the user send a stream to other users. – Ollieollis

There are at least two companies that I am aware of that are trying to do webrtc-based p2p video delivery: affovi.com/rtcplayer.html - mostly for live video; and peer5.com - mostly for VOD. – Nitrobacteria

"Why not use WebRTC from client to server?" - expensive, bottlenecks, not scalable. Any other reasons? – Disproportionate

@SvetlinMladenov affovi.com is unavailable. Do you know alternative? – Kwangtung

@RamilAmr here it is: viblast.com/demo – Nitrobacteria

@Disproportionate You may wanna check: github.com/muaz-khan/WebRTC-Scalable-Broadcast Though it works only in chrome, and no audio-broadcast yet. – Chapatti

Very nice project. What happens if relay peer has bad internet connection (just your opinion)? – Disproportionate

I think best way to implement this is to use other peers as servers for new comers, like If I join as 6th person to this broadcast, server will signal with other clients and connects me to any other joined client and sends its coming stream to newcomer as peer to peer traffic. This can be scaled as horizontally with each newcomer connects its ancestor coming. and if your connection drops server just sends another peers connection like it does before. – Calondra

Melih, is there any working nicely service/implementation? Also, this is theoretically good scheme, but do you also consider latencies as a main problem? – Disproportionate

What "recent changes" are you referring to? – Avoirdupois

The current answers might be out of date. This technology is cutting-edge and last answers were provided at least a half-year ago. – Disproportionate

There is no way to reach that scalability without a MCU of some sort. WebRTC is designed to be Peer-to-Peer. You cannot broadcast from it without absolutely slamming your broadcaster(with a unique peer connection for each stream, which interns, is another stream being encoded). As for relaying the media from peer-to-peer, that could be possible, but of course, this would incur additional latency for every peer added to the stream later. For quality, and scalability, having a webrtc MCU server is the only realistic solution. – Politics

Came across this while searching for a related topic. Yesterday i assisted to an amazing talk, that can help you, check this greta.io – Cartage

Sounds good, but I just cannot understand how they solve a problem of unstable connection of peers. Probably will talk to them soon. – Disproportionate

Do you have solution on 2017? – Hindustani

No solution yet. I think this is due to the fundamental limitations of networking protocols. – Disproportionate

@igorpavlov: may be the WebRTC-Scalable-Broadcast is the great choise at the moment, right? – Hindustani

Answer 1

As it was pretty much covered here, what you are trying to do here is not possible with plain, old-fashionned WebRTC (strictly peer-to-peer). Because as it was said earlier, WebRTC connections renegotiate encryption keys to encrypt data, for each session. So your broadcaster (B) will indeed need to upload its stream as many times as there are attendees.

However, there is a quite simple solution, which works very well: I have tested it, it is called a WebRTC gateway. Janus is a good example. It is completely open source (github repo here).

This works as follows: your broadcaster contacts the gateway (Janus) which speaks WebRTC. So there is a key negotiation: B transmits securely (encrypted streams) to Janus.

Now, when attendees connect, they connect to Janus, again: WebRTC negotiation, secured keys, etc. From now on, Janus will emit back the streams to each attendees.

This works well because the broadcaster (B) only uploads its stream once, to Janus. Now Janus decodes the data using its own key and have access to the raw data (that it, RTP packets) and can emit back those packets to each attendee (Janus takes care of encryption for you). And since you put Janus on a server, it has a great upload bandwidth, so you will be able to stream to many peer.

So yes, it does involve a server, but that server speaks WebRTC, and you "own" it: you implement the Janus part so you don't have to worry about data corruption or man in the middle. Well unless your server is compromised, of course. But there is so much you can do.

To show you how easy it is to use, in Janus, you have a function called incoming_rtp() (and incoming_rtcp()) that you can call, which gives you a pointer to the rt(c)p packets. You can then send it to each attendee (they are stored in sessions that Janus makes very easy to use). Look here for one implementation of the incoming_rtp() function, a couple of lines below you can see how to transmit the packets to all attendees and here you can see the actual function to relay an rtp packet.

It all works pretty well, the documentation is fairly easy to read and understand. I suggest you start with the "echotest" example, it is the simplest and you can understand the inner workings of Janus. I suggest you edit the echo test file to make your own, because there is a lot of redundant code to write, so you might as well start from a complete file.

Have fun! Hope I helped.

Sabrinasabsay

Is it true to say this doesn't work in Safari currently (or any browser that doesn't support WebRTC?). Does anyone know of a hybrid solution where you broadcast from the Browser to server using WebRTC then transcode the video to HLS/HDS (Or even RTMP) to fit into a traditional broadcast system? – Prevent

@Prevent yes it doesn't work with browsers that don't support WebRTC. Back in the days (when I write this) Safari was clearly not supporting this. Today however I have not checked. But I still think they don't support WebRTC (to be confirmed, though). As for using it in a hybrid system, this is totally possible, actually this is what I did for the company I worked at ; as you said, I broadcast from the browser to the server and from there, I built and plugged a GStreamer pipeline to transcode the feed.You can do this too! – Sabrinasabsay

any idea about jitsi ? is jitisi also the same ? – Andri

@Sabrinasabsay Is this any better than using websocket to do the same? – Jut

You're actually explaining how an SFU (Selective Forwarding Unit) works. You can do the same with mediasoup – Junitajunius

what are some other alternatives, what do you google? – Kloof

Answer 2

As @MuazKhan noted above:

https://github.com/muaz-khan/WebRTC-Scalable-Broadcast

works in chrome, and no audio-broadcast yet, but it seems to be a 1st Solution.

A Scalable WebRTC peer-to-peer broadcasting demo.

This module simply initializes socket.io and configures it in a way that single broadcast can be relayed over unlimited users without any bandwidth/CPU usage issues. Everything happens peer-to-peer!

This should definitely be possible to complete.
Others are also able to achieve this: http://www.streamroot.io/

Resuscitate

This stuff seems a little bit outofdate for me. Any updates or thoughts on this idea? – Disproportionate

Also, does it solve latency problems anyhow? For example, Peer1 talks to Peer5 and Peer2 eventually loses connection. Or is this architecture good for LAN only? – Disproportionate

Also, is Streamroot similar to Peer5? – Disproportionate

Answer 3

AFAIK the only current implementation of this that is relevant and mature is Adobe Flash Player, which has supported p2p multicast for peer to peer video broadcasting since version 10.1.

http://tomkrcha.com/?p=1526.

Selfanalysis

People do not kill the technology. The technology is killing itself by providing very poor UX, especially when allowing mic/camera. That's where getusermedia wins. – Disproportionate

Apart from the bad ux, would this be the solution? Server less? – Resuscitate

Answer 4

"Scalable" broadcasting is not possible on the Internet, because the IP UDP multicasting is not allowed there. But in theory it's possible on a LAN.
The problem with Websockets is that you don't have access to RAW UDP by design and it won't be allowed.
The problem with WebRTC is that it's data channels use a form of SRTP, where each session has own encryption key. So unless somebody "invents" or an API allows a way to share one session key between all clients, the multicast is useless.

Radicel

but chats already work with WebRTC, so everyone sees every message, so one-to many should work for video also somehow – Resuscitate

@Resuscitate The data sent with text message is nothing at all compared to the rate and amount of data sent with video streams. So chats can easily contain waayy more users at once – Junitajunius

Answer 5

There is the solution of peer-assisted delivery, meaning the approach is hybrid. Both server and peers help distribute the resource. That's the approach peer5.com and peercdn.com have taken.

If we're talking specifically about live broadcast it'll look something like this:

1. Broadcaster sends the live video to a server.
2. The server saves the video (usually also transcodes it to all the relevant formats).
3. A metadata about this live stream is being created, compatible with HLS or HDS or MPEG_DASH
4. Consumers browse to the relevant live stream there the player gets the metadata and knows which chunks of the video to get next.
5. At the same time the consumer is being connected to other consumers (via WebRTC)
6. Then the player downloads the relevant chunk either directly from the server or from peers.

Following such a model can save up to ~90% of the server's bandwidth depending on bitrate of the live stream and the collaborative uplink of the viewers.

disclaimer: the author is working at Peer5

Mudguard

Thank you. I do know about peer5 and find it a pretty attractive solution. However, the purpose of this question was to find a solution absolutely server-less (only STUN/TURN allowed). – Disproportionate

Answer 6

My masters is focused on the development of a hybrid cdn/p2p live streaming protocol using WebRTC. I've published my first results at http://bem.tv

Everything is open source and I'm seeking for contributors! :-)

Murraymurre

Do you use any kind of server side software kinda MCU? – Disproportionate

I'm actually using some server side componentes from rtcio people: github.com/rtc-io – Murraymurre

It looks like you use their components for signaling. How about server side video streaming? Or you solution is absolutely P2P? – Disproportionate

sorry for the long delay in answering you @igorpavlov, I'm using EvoStream to segment the videos and I'm looping a video source and pointing to EvoStream using Elemental encoder. – Murraymurre

It is a media servers provider. More efficient? Probably. Is it what I am looking for? No. – Disproportionate

Answer 7

The answer from Angel Genchev seems to be correct, however, there is a theoretical architecture, that allows low-latency broadcasting via WebRTC. Imagine B (broadcaster) streams to A1 (attendee 1). Then A2 (attendee 2) connects. Instead of streaming from B to A2, A1 starts streaming video being received from B to A2. If A1 disconnects then A2 starts receiving from B.

This architecture could work if there are no latencies and connection timeouts. So theoretically it is right, but not practically.

At the moment I am using server side solution.

Disproportionate

What about the stream speed in server side solution? Please share. – Numeral

Server side solution means? What did you used? It would be helpful for my research. Please share. Thanks. – Numeral

Server side solution means Opentok by Tokbox. I do not advertize them, there are tons of such solutions on the market, but I stick with this one. It is working like a media server. P.S. What do you mean by multi-party communication? I don't get it. – Disproportionate

@Disproportionate could you give list of companies who provide server side webrtc? I know only Flashphoner and Opentok. Thanks – Kwangtung

I would be curious to see if this would actually scale. There are sure to be scaling issues with latency on HUGE groups(1000+) but if there are only 5-10 I would imagine it would work quite nicely but some fancy foot work would be needed if somebody in the middle of the peer "chain" leaves and reconnecting all the subsequent peers if it is just a single chain would be a HUGE over head. May be better to use a binary/ternary tree structure. – Politics

This architecture works in case a) absence of latency, b) stable and fast internet connection, c) minimum connection time. So it definitely works via LAN. Can be helpful for broadcasting realtime video/audio through your company employees if they sit in the same building, for example. – Disproportionate

Moreover, the architecture, where every participant rebroadcasts to 2 people and each participant receives streams from 2 people as well reduces the problem with reconnections in case of peer disconnection from chain. B (broadcaster) sends to A1 (attendee 1) and A2. A1 sends to A2 and A3. A2 sends to A3 and A4. If lets say A2 disconnects, then A3 still receives from A1 (so you need just quickly switch streams), A4 still receives from A3, then the whole chain architecture is being recovered in the background and it almost solves the connection time issue. – Disproportionate

And A1's computer crashes, meaning everyone downstream is SOL. – Ulberto

Not exactly true. A2 will swap to B, A3 to A2 and B, A4 to A3 and A2 etc. And you can process 2 streams to see which one is the best quality. But With every peer the time lag will increase as the video transmission is not really "real-time". And this method relies on the assumption that at least 50% of peers in average have good connection (which is statistically not true) – Disproportionate

Answer 8

I'm developing WebRTC broadcasting system using the Kurento Media Server. Kurento Supports several kinds of streaming protocol such as RTSP, WebRTC, HLS. It works as well in term of real-time and scaling.

Hence, Kurento doesn't support RTMP which is used in Youtube or Twitch now. One of the problem with me is the number of user concurrent with this.

Hope it help.

Biparty

Answer 9

You are describing using WebRTC with a one-to-many requirement. WebRTC is designed for peer-to-peer streaming, however there are configurations that will let you benefit from the low latency of WebRTC while delivering video to many viewers.

The trick is to not tax the streaming client with every viewer and, like you mentioned, have a "relay" media server. You can build this yourself but honestly the best solution is often to use something like Wowza's WebRTC Streaming product.

To stream efficiently from a phone you can use Wowza's GoCoder SDK but in my experience a more advanced SDK like StreamGears works best.

Eisegesis