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 사용 문제없이 무제한 사용자를 통해 단일 브로드 캐스트를 중계 할 수 있도록 구성합니다. 모든 것이 피어 투 피어로 발생합니다!

이것은 확실히 완료 할 수 있어야합니다.
다른 사람들도 이것을 달성 할 수 있습니다 : http://www.streamroot.io/

AFAIK는 관련성이 있고 성숙한 유일한 현재 구현은 Adobe Flash Player이며, 버전 10.1 이후 P2P 비디오 브로드 캐스팅을 위해 p2p 멀티 캐스트를 지원했습니다.

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

인터넷에서는 IP UDP 멀티 캐스팅이 허용되지 않기 때문에 "확장 가능한"브로드 캐스팅이 불가능합니다. 그러나 이론적으로는 LAN에서 가능합니다.
Websockets의 문제는 의도적으로 RAW UDP에 대한 액세스 권한이 없으며 허용되지 않는다는 것입니다.
WebRTC의 문제점은 데이터 채널이 각 세션에 자체 암호화 키 가있는 SRTP 형식을 사용한다는 것입니다 . 따라서 누군가 "발명"하거나 API 가 모든 클라이언트간에 하나의 세션 키 를 공유 하는 방법을 허용하지 않는 한 멀티 캐스트는 쓸모가 없습니다.

피어 지원 전달 솔루션이 있습니다. 즉, 접근 방식이 하이브리드입니다. 서버와 피어 모두 리소스를 배포하는 데 도움이됩니다. 이것이 peer5.com 과 peercdn.com 이 취한 접근 방식 입니다.

라이브 방송에 대해 구체적으로 이야기하는 경우 다음과 같이 표시됩니다.

1. 브로드 캐스터는 라이브 비디오를 서버로 보냅니다.
2. 서버는 비디오를 저장합니다 (일반적으로 모든 관련 형식으로 트랜스 코딩합니다).
3. HLS, HDS 또는 MPEG_DASH와 호환되는이 라이브 스트림에 대한 메타 데이터가 생성되고 있습니다.
4. 소비자는 관련 라이브 스트림을 검색하여 플레이어가 메타 데이터를 얻고 다음에 가져올 비디오 청크를 알고 있습니다.
5. 동시에 소비자는 WebRTC를 통해 다른 소비자와 연결됩니다.
6. 그런 다음 플레이어는 서버 또는 피어에서 직접 관련 청크를 다운로드합니다.

이러한 모델을 따르면 라이브 스트림의 비트 전송률과 뷰어의 공동 업 링크에 따라 서버 대역폭의 최대 90 %를 절약 할 수 있습니다.

면책 조항 : 저자는 Peer5에서 일하고 있습니다.

제 석사는 WebRTC를 사용하여 하이브리드 cdn / p2p 라이브 스트리밍 프로토콜 개발에 중점을 둡니다. http://bem.tv에 첫 번째 결과를 게시했습니다.

모든 것이 오픈 소스이며 저는 기여자를 찾고 있습니다! :-)

Angel Genchev의 대답은 옳은 것 같지만 WebRTC를 통해 짧은 지연 시간 방송을 허용하는 이론적 아키텍처가 있습니다. B (방송 자)가 A1 (참석자 1)에게 스트리밍한다고 상상해보십시오. 그런 다음 A2 (참석자 2)가 연결됩니다. B에서 A2로 스트리밍하는 대신 A1은 B에서 A2로 수신되는 스트리밍 비디오를 시작합니다. A1이 연결 해제되면 A2가 B로부터 수신을 시작합니다.

이 아키텍처는 대기 시간과 연결 시간 초과가없는 경우 작동 할 수 있습니다. 그래서 이론적으로는 옳지 만 실제로는 아닙니다.

현재 서버 측 솔루션을 사용하고 있습니다.

WebRTC 확장형 솔루션을 위해 시장에서 사용할 수있는 몇 가지 솔루션이 있습니다. 지연 시간이 짧고 확장 가능한 webrtc 스트리밍을 제공합니다. 다음은 몇 가지 샘플입니다. Janus , Jitsi , Wowza , Red5pro , Ant 미디어 서버

저는 Ant Media Server의 개발자이며 Android 및 iOS SDK를 포함한 커뮤니티 및 엔터프라이즈 에디션을 모두 제공합니다. 어떻게 든 도와 드릴 수 있는지 알려주십시오.

일대 다 요구 사항으로 WebRTC 사용을 설명하고 있습니다. WebRTC는 P2P 스트리밍 용으로 설계되었지만 WebRTC의 낮은 지연 시간을 활용하는 동시에 많은 시청자에게 비디오를 제공 할 수있는 구성이 있습니다.

트릭은 스트리밍 클라이언트에 모든 시청자에게 부담을주지 않고 앞서 언급했듯이 "릴레이"미디어 서버를 사용하는 것입니다. 직접 만들 수 있지만 솔직히 가장 좋은 해결책은 종종 Wowza의 WebRTC Streaming 제품 과 같은 것을 사용하는 것 입니다.

휴대폰에서 효율적으로 스트리밍하려면 Wowza의 GoCoder SDK를 사용할 수 있지만 내 경험상 StreamGears 와 같은 고급 SDK 가 가장 잘 작동합니다.

Kurento Media Server를 사용하여 WebRTC 방송 시스템을 개발하고 있습니다. Kurento는 RTSP, WebRTC, HLS와 같은 여러 종류의 스트리밍 프로토콜을 지원합니다. 실시간 및 확장 측면에서도 잘 작동합니다.

따라서 Kurento는 현재 Youtube 또는 Twitch에서 사용되는 RTMP를 지원하지 않습니다. 저의 문제 중 하나는 이것과 동시 사용자 수입니다.

도움이 되었기를 바랍니다.

peer1은 getUserMedia ()를 호출하는 유일한 피어이므로 peer1은 방을 만듭니다.

1. 따라서 peer1은 미디어를 캡처하고 공간을 시작합니다.
2. peer2가 방에 참여하고 peer1에서 스트림 (데이터)을 가져오고 "peer2-connection"이라는 이름의 병렬 연결을 엽니 다.
3. peer3이 방에 참여하고 peer2에서 스트림 (데이터)을 가져오고 'peer3-connection'이라는 이름의 병렬 연결을 엽니 다.

이 프로세스는 많은 피어가 서로 연결될 때 계속됩니다.

따라서이를 통해 대역폭 / CPU 사용 문제없이 무제한 사용자를 통해 단일 브로드 캐스트를 전송할 수 있습니다.

마지막으로 위의 모든 내용은 Link의 참조입니다 .