javascript - WebRTC - scalable live stream broadcasting / multicasting -

[ ! ] question still open

problem:

webrtc gives peer-to-peer video/audio connections. perfect p2p calls, hangouts. broadcasting (one-to-many, example, 1-to-10000)?

lets have broadcaster "b" , 2 attendees "a1", "a2". of course seems solvable: connect b a1 , b a2. b sends video/audio stream directly a1 , stream a2. b sends streams twice.

now lets imagine there 10000 attendees: a1, a2, ..., a10000. means b must send 10000 streams. each stream ~40kb/s means b needs 400mb/s outgoing internet speed maintain broadcast. unacceptable.

original question (obsolete)

is possible somehow solve this, b sends 1 stream on server , attendees pull stream server? yes, means outgoing speed on server must high, can maintain it.

or maybe means ruining webrtc idea?

[ ! ] up-to-date question

1. solve cpu/bandwidth - there server-less solution (aka multicasting or similar)?
2. solve cpu - possible encode stream once , send peers?
3. solve cpu/bandwidth - multicasting possible, work in real life (latency, network instability)?

notes

flash not working needs per poor ux end customers.

solution

26.05.2015 - there no such solution scalable broadcasting webrtc @ moment, not use media-servers @ all. there server-side solutions hybrid (p2p + server-side depending on different conditions) on market.

there promising techs though https://github.com/muaz-khan/webrtc-scalable-broadcast need answer possible issues: latency, overall network connection stability, scalability formula (they not infinite-scalable probably).

as pretty covered here, trying here not possible plain, old-fashionned webrtc (strictly peer-to-peer). because said earlier, webrtc connections renegotiate encryption keys encrypt data, each session. broadcaster (b) indeed need upload stream many times there attendees.

however, there quite simple solution, works well: have tested it, called webrtc gateway. janus example. open source (github repo here).

this works follows: broadcaster contacts gateway (janus) which speaks webrtc. there key negotiation: b transmits securely (encrypted streams) janus.

now, when attendees connect, connect janus, again: webrtc negotiation, secured keys, etc. on, janus emit streams each attendees.

this works because broadcaster (b) uploads stream once, janus. janus decodes data using own key , have access raw data (that it, rtp packets) , can emit packets each attendee (janus takes care of encryption you). , since put janus on server, has great upload bandwidth, able stream many peer.

so yes, does involve server, server speaks webrtc, , "own" it: implement janus part don't have worry data corruption or man in middle. unless server compromised, of course. there can do.

to show how easy use, in janus, have function called incoming_rtp() (and incoming_rtcp()) can call, gives pointer rt(c)p packets. can send each attendee (they stored in sessions janus makes easy use). look here 1 implementation of incoming_rtp() function, a couple of lines below can see how transmit packets attendees , here can see actual function relay rtp packet.

it works pretty well, documentation easy read , understand. suggest start "echotest" example, simplest , can understand inner workings of janus. suggest edit echo test file make own, because there lot of redundant code write, might start complete file.

have fun! hope helped.