WebRTC-スケーラブルなライブストリームブロードキャスト/マルチキャスト

問題：

WebRTCは、ピアツーピアのビデオ/オーディオ接続を提供します。p2p通話、ハングアウトに最適です。しかし、ブロードキャストについてはどうでしょう（1対多、たとえば1から10000）。

放送局「B」と2人の参加者「A1」、「A2」があるとします。もちろん、解決できるようです。BをA1に接続し、次にBをA2に接続するだけです。したがって、Bはビデオ/オーディオストリームを直接A1に送信し、別のストリームをA2に送信します。Bはストリームを2回送信します。

次に、A1、A2、...、A10000の出席者が10000人いるとします。これは、Bが10000ストリームを送信する必要があることを意味します。各ストリームは〜40KB / sです。つまり、Bはこのブロードキャストを維持するために400MB / sの発信インターネット速度を必要とします。受け入れられない。

元の質問（廃止）

どういうわけかこれを解決することは可能ですか？Bはいくつかのサーバーで1つのストリームのみを送信し、出席者はこのサーバーからこのストリームをプルするだけですか？はい、これはこのサーバーの発信速度が高速でなければならないことを意味しますが、私はそれを維持できます。

あるいは、これはWebRTCのアイデアを台無しにすることを意味しますか？

ノート

エンドユーザーの貧弱なUXによると、Flashは私のニーズに対応していません。

ソリューション（実際にはない）

26.05.2015-現在、メディアサーバーをまったく使用しないWebRTCのスケーラブルなブロードキャストのソリューションはありません。サーバーサイドソリューションだけでなく、ハイブリッド（さまざまな条件に応じてp2p +サーバーサイド）が市場に出ています。

https://github.com/muaz-khan/WebRTC-Scalable-Broadcastのようないくつかの有望な技術がありますが、それらは考えられる問題に答える必要があります：遅延、ネットワーク接続の全体的な安定性、スケーラビリティの公式（おそらく無限にスケーラブルではありません） ）。

提案

1. オーディオコーデックとビデオコーデックの両方を調整して、CPU /帯域幅を減らします。
2. メディアサーバーを取得します。

ここではかなり取り上げたので、ここでやろうとしていることは、単純な昔ながらのWebRTC（厳密にはピアツーピア）では不可能です。前述のとおり、WebRTC接続では、セッションごとに暗号化キーを再ネゴシエートしてデータを暗号化します。したがって、放送局（B）は実際に、出席者の数だけストリームをアップロードする必要があります。

ただし、非常に簡単に実行できる非常にシンプルなソリューションがあります。私はそれをテストしました。これはWebRTCゲートウェイと呼ばれています。ヤヌスは良い例です。完全にオープンソースです（github repo here）。

これは次のように機能します。ブロードキャスターは、WebRTCを話すゲートウェイ（Janus）に連絡します。したがって、重要なネゴシエーションがあります。Bは安全に（暗号化されたストリーム）をJanusに送信します。

これで、出席者が接続すると、Janusに再び接続されます。WebRTCネゴシエーション、セキュリティで保護されたキーなど。今後、Janusは各出席者にストリームを返します。

これは、放送局（B）がストリームをJanusに1回だけアップロードするため、うまく機能します。Janusは独自のキーを使用してデータをデコードし、生データ（つまり、RTPパケット）にアクセスし、それらのパケットを各出席者に送り返すことができます（Janusが暗号化を担当します）。そして、Janusをサーバーに配置したので、アップロードの帯域幅が大きいため、多くのピアにストリーミングできます。

つまり、サーバーが関係しますが、そのサーバーはWebRTCを話し、それを「所有」します。Janusの部分を実装するので、データの破損や途中での人の心配はありません。もちろん、サーバーが危険にさらされない限り。しかし、あなたができることはたくさんあります。

使いやすさを示すために、Janusには、呼び出し可能なincoming_rtp()（およびincoming_rtcp()）という関数があり、rt（c）pパケットへのポインターを提供します。その後、それを各出席者に送信できます（sessionsJanusを使用すると非常に使いやすくなります）。一つの実施のためにここを見てincoming_rtp()機能、以下の行のカップルは、すべての参加者にパケットを送信する方法を見ることができ、ここで、あなたは、RTPパケットを中継するために、実際の機能を見ることができます。

それはすべてうまく機能し、ドキュメントはかなり読みやすく理解しやすいです。「エコーテスト」の例から始めることをお勧めします。これは最も簡単で、ヤヌスの内部の仕組みを理解できます。エコーテストファイルを編集して独自のコードを作成することをお勧めします。作成する冗長なコードがたくさんあるため、完全なファイルから開始することもできます。

楽しんで！私が助けてくれたことを願っています。

@MuazKhanが前述したように：

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

クロムで動作し、オーディオブロードキャストはまだありませんが、これは最初のソリューションのようです。

スケーラブルなWebRTCピアツーピアブロードキャストデモ。

このモジュールは単にsocket.ioを初期化し、帯域幅/ CPU使用率の問題なしに無制限のユーザーを介して単一のブロードキャストを中継できるように構成します。すべてがピアツーピアで起こります！

これは間違いなく完了できるはずです。
他の人もこれを達成できます：http : //www.streamroot.io/

私の知る限り、関連する成熟した唯一の現在の実装はAdobe Flash Playerであり、バージョン10.1以降、ピアツーピアビデオブロードキャスト用のp2pマルチキャストをサポートしています。

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

「スケーラブル」なブロードキャストは、インターネットではIP UDPマルチキャストが許可されていないため、不可能です。しかし、理論的にはLANで可能です。
Websocketの問題は、設計上、RAW UDPにアクセスできず、許可されないことです。
WebRTCの問題は、データチャネルがSRTPの形式を使用することです。この場合、各セッションには独自の暗号化キーがあります。したがって、誰かが「発明」するか、APIがすべてのクライアント間で1つのセッションキーを共有する方法を許可しない限り、マルチキャストは役に立ちません。

ピアアシスト配信のソリューションがあります。つまり、アプローチはハイブリッドです。サーバーとピアの両方がリソースの配布に役立ちます。それが、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）が接続します。A1は、BからA2にストリーミングする代わりに、BからA2に受信されるビデオのストリーミングを開始します。A1が切断すると、A2はBからの受信を開始します。

このアーキテクチャは、レイテンシと接続タイムアウトがない場合に機能します。したがって、理論的には正しいですが、実際的ではありません。

現時点では、サーバー側のソリューションを使用しています。

WebRTCスケーラブルソリューションの市場で利用可能ないくつかのソリューションがあります。低レイテンシでスケーラブルなwebrtcストリーミングを提供します。ここにいくつかのサンプルがあります。 Janus、Jitsi、Wowza、Red5pro、Ant Media Server

私はAnt Media Serverの開発者です。AndroidとiOS SDKを含むコミュニティエディションとエンタープライズエディションの両方を提供しています。なんとかお手伝いできるかどうかお知らせください。

1対多の要件を持つWebRTCの使用について説明しています。WebRTCはピアツーピアストリーミング用に設計されていますが、多くの視聴者にビデオを配信しながら、WebRTCの低レイテンシを活用できる構成もあります。

トリックは、すべてのビューアでストリーミングクライアントに負担をかけないことであり、あなたが言ったように、「リレー」メディアサーバーを持っています。これは自分で作成できますが、正直なところ、多くの場合、WowzaのWebRTCストリーミング製品などを使用するのが最善の解決策です。

電話から効率的にストリーミングするには、WowzaのGoCoder SDKを使用できますが、私の経験では、StreamGearsのようなより高度なSDKが最適です。

Kurento Media Serverを使用してWebRTC放送システムを開発しています。Kurentoは、RTSP、WebRTC、HLSなどの数種類のストリーミングプロトコルをサポートしています。リアルタイムとスケーリングの観点からも同様に機能します。

そのため、Kuretoは現在YouTubeまたはTwitchで使用されているRTMPをサポートしていません。私の問題の1つは、これと同時に使用しているユーザーの数です。

お役に立てば幸いです。

peer1はgetUserMedia（）を呼び出すピアのみなので、peer1はルームを作成します。

1. したがって、peer1はメディアをキャプチャし、部屋を開始します。
2. peer2はルームに参加し、peer1からストリーム（データ）を取得し、「peer2-connection」という名前の並列接続を開きます
3. peer3がルームに参加し、peer2からstream（data）を取得し、「peer3-connection」という名前の並列接続を開く場合など。

このプロセスは、多くのピアが相互に接続されると継続します。

したがって、これにより、帯域幅/ CPU使用率の問題なしに、単一のブロードキャストを無制限のユーザーに転送できます。

最後に、上記のすべてはLinkからの参照です。