WebRTC-확장 가능한 라이브 스트림 방송 / 멀티 캐스팅

WebRTC-확장 가능한 라이브 스트림 방송 / 멀티 캐스팅

---

문제:

WebRTC는 P2P 비디오 / 오디오 연결을 제공합니다. p2p 통화, 행 아웃에 적합합니다. 하지만 방송은 어떨까요 (일대 다, 예를 들어 1 대 10000)?

방송사 "B"와 두 명의 참석자 "A1", "A2"가 있다고 가정 해 보겠습니다. 물론 해결할 수있는 것 같습니다. B를 A1에 연결하고 B를 A2에 연결하기 만하면됩니다. 따라서 B는 비디오 / 오디오 스트림을 A1로 직접 보내고 다른 스트림을 A2로 보냅니다. B는 스트림을 두 번 보냅니다.

이제 A1, A2, ..., A10000 등 10000 명의 참석자가 있다고 가정 해 보겠습니다. 이는 B가 10000 개의 스트림을 보내야 함을 의미합니다. 각 스트림은 ~ 40KB / s이며 이는 B가이 브로드 캐스트를 유지하려면 400MB / s의 발신 인터넷 속도가 필요함을 의미합니다. 용납 할 수 없습니다.

원래 질문 (불만)

어떻게 든이 문제를 해결할 수 있습니까? B는 일부 서버에서 하나의 스트림 만 보내고 참석자는이 서버에서이 스트림을 가져옵니다. 예, 이것은이 서버의 나가는 속도가 빨라야하지만 유지할 수 있음을 의미합니다.

아니면 이것이 WebRTC 아이디어를 망치는 것을 의미할까요?

노트

최종 고객의 열악한 UX에 따라 Flash가 내 요구에 맞지 않습니다.

솔루션 (정말 아님)

26.05.2015-현재로서는 미디어 서버를 전혀 사용하지 않는 WebRTC 용 확장 가능한 방송 솔루션이 없습니다. 시장에는 서버 측 솔루션과 하이브리드 (다른 조건에 따라 p2p + 서버 측)가 있습니다.

https://github.com/muaz-khan/WebRTC-Scalable-Broadcast 와 같은 유망한 기술이 있지만 대기 시간, 전반적인 네트워크 연결 안정성, 확장 성 공식 (아마 무한 확장 성이 아닙니다. ).

제안

1. 오디오 및 비디오 코덱을 모두 조정하여 CPU / 대역폭을 줄입니다.
2. 미디어 서버를 구하십시오.

---

여기에서 꽤 많이 다루었 기 때문에 여기서하려는 것은 평범하고 구식 WebRTC (엄격히 P2P)로는 불가능합니다. 앞서 말했듯이 WebRTC 연결은 각 세션에 대해 데이터를 암호화하기 위해 암호화 키를 재협상하기 때문입니다. 따라서 방송사 (B)는 참석자 수만큼 스트림을 업로드해야합니다.

그러나 매우 잘 작동하는 아주 간단한 솔루션이 있습니다. 테스트를 해봤는데 WebRTC 게이트웨이라고합니다. 야누스 는 좋은 예입니다. 완전히 오픈 소스입니다 ( github repo here ).

이것은 다음과 같이 작동합니다 : 방송사 는 WebRTC를 말하는 게이트웨이 (Janus) 에 접속합니다 . 따라서 키 협상이 있습니다. B는 Janus에게 안전하게 (암호화 된 스트림) 전송합니다.

이제 참석자가 연결되면 WebRTC 협상, 보안 키 등 Janus에 다시 연결됩니다. 이제부터 Janus는 각 참석자에게 스트림을 다시 전송합니다.

브로드 캐스터 (B)가 Janus에게 스트림을 한 번만 업로드하기 때문에 이것은 잘 작동합니다. 이제 Janus는 자체 키를 사용하여 데이터를 디코딩하고 원시 데이터 (즉, RTP 패킷)에 액세스하고 이러한 패킷을 각 참석자에게 다시 보낼 수 있습니다 (Janus가 암호화를 처리합니다). 그리고 Janus를 서버에 배치했기 때문에 업로드 대역폭이 넓어 여러 피어로 스트리밍 할 수 있습니다.

그래서 그래, 그것은 않는 서버를 포함하지만, 해당 서버의 WebRTC를 말하고, 그것을 당신이 "자신의"당신이 중간에 데이터 손상 또는 사람에 대해 걱정할 필요가 없습니다 그래서 당신은 야누스 부분을 구현합니다. 물론 서버가 손상되지 않는 한. 하지만 할 수있는 일이 너무 많습니다.

사용이 얼마나 쉬운 지 보여주기 위해 Janus 에는 rt (c) p 패킷에 대한 포인터를 제공하는 호출 할 수있는 incoming_rtp()(and incoming_rtcp()) 라는 함수 가 있습니다. 그런 다음 각 참석자에게 보낼 수 있습니다 ( sessionsJanus가 사용하기 쉽게 저장되어 있음). 의 하나의 구현 여기를 봐 incoming_rtp()기능 , 아래 라인의 몇 모든 참석자에게 패킷을 전송하는 방법을 볼 수 있으며, 여기에 당신이 RTP 패킷을 중계하는 실제 기능을 볼 수 있습니다.

모든 것이 잘 작동하며 문서는 읽고 이해하기가 매우 쉽습니다. "echotest"예제로 시작하는 것이 좋습니다. 가장 간단하며 Janus의 내부 작동 방식을 이해할 수 있습니다. 작성해야 할 중복 코드가 많기 때문에 에코 테스트 파일을 직접 편집하여 전체 파일에서 시작하는 것이 좋습니다.

즐기세요! 내가 도왔기를 바랍니다.

---

@MuazKhan이 위에서 언급했듯이 :

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

크롬에서 작동하고 아직 오디오 방송은 없지만 첫 번째 해결책 인 것 같습니다.

확장 가능한 WebRTC P2P 브로드 캐스팅 데모.

이 모듈은 단순히 socket.io를 초기화하고 대역폭 / CPU 사용 문제없이 무제한 사용자를 통해 단일 브로드 캐스트를 중계 할 수 있도록 구성합니다. 모든 것이 피어 투 피어로 발생합니다!

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

---

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.

---

"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.

---

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

---

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! :-)

---

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.

---

There are some solutions available in the market for WebRTC scalable solution. They provide low latency, scalable webrtc streaming. Here are some samples. Janus, Jitsi, Wowza, Red5pro, Ant Media Server

I am developer for Ant Media Server, we provide both community and enterprise edition including android and iOS SDK as well. Let us know if we can help you somehow.

---

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 that is used in Youtube or Twitch now. One of the problem with me is the number of user concurrent with this.

Hope it help.

---

As peer1 is only the peer who invokes getUserMedia() i.e. peer1 creates a room.

1. So, peer1 captures media and starts room.
2. peer2 joins the room and get stream(data) from peer1 and also open parallel connection named as "peer2-connection"
3. When peer3 joins the room and get stream(data) from peer2 and also open parallel connection named as 'peer3-connection" and so on.

This process continous as many peer gets connected to each other.

Hence, by this a single broadcast can be transfered over unlimited users without any bandwidth/ CPU usages problems.

Finally, all above contained is reference from Link.

---

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.

참고URL : https://stackoverflow.com/questions/18318983/webrtc-scalable-live-stream-broadcasting-multicasting