130

問題：

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/秒です。これは、B がこのブロードキャストを維持するために 400MB/秒の発信インターネット速度が必要であることを意味します。受け入れられない。

元の質問 (廃止)

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

それとも、これは WebRTC のアイデアを台無しにすることを意味するのでしょうか?

ノート

エンド カスタマーの UX が貧弱であるため、Flash は私のニーズに対して機能しません。

解決策（そうではない）

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

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

提案

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

9 に答える 9

11

@MuazKhanが上で述べたように：

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

Chrome で動作し、音声ブロードキャストはまだありませんが、最初のソリューションのようです。

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

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

ここに画像の説明を入力

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

于 2015-05-26T10:36:34.503 に答える
7

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

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

于 2015-02-13T16:07:38.630 に答える
6

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

于 2013-11-17T23:52:23.123 に答える
5

アプローチがハイブリッドであることを意味する、ピアアシスト配信のソリューションがあります。サーバーとピアの両方がリソースの配布を支援します。これが、 peer5.comとpeercdn.comが取ったアプローチです。

ライブブロードキャストについて具体的に話している場合は、次のようになります。

  1. ブロードキャスターは、ライブ ビデオをサーバーに送信します。
  2. サーバーは動画を保存します (通常は、関連するすべての形式に変換します)。
  3. このライブ ストリームに関するメタデータが作成され、HLS、HDS、または MPEG_DASH と互換性があります
  4. 消費者は関連するライブ ストリームを参照し、プレーヤーはメタデータを取得し、次に取得するビデオのチャンクを認識します。
  5. 同時に、消費者は他の消費者に接続されています (WebRTC 経由)。
  6. 次に、プレーヤーは関連するチャンクをサーバーまたはピアから直接ダウンロードします。

このようなモデルに従うと、ライブ ストリームのビットレートと視聴者の共同アップリンクに応じて、サーバーの帯域幅を最大 90% 節約できます。

免責事項: 著者は Peer5 で働いています

于 2014-03-17T13:56:02.780 に答える
5

私の修士号は、WebRTC を使用したハイブリッド cdn/p2p ライブ ストリーミング プロトコルの開発に重点を置いています。http://bem.tvで最初の結果を公開しました

すべてがオープンソースで、貢献者を募集しています! :-)

于 2014-05-17T17:15:59.667 に答える
2

Angel Genchev からの回答は正しいようですが、WebRTC を介して低遅延のブロードキャストを可能にする理論的なアーキテクチャがあります。B (放送局) が A1 (出席者 1) にストリーミングするとします。次に、A2 (出席者 2) が接続します。B から A2 へのストリーミングの代わりに、A1 は B から A2 への受信ビデオのストリーミングを開始します。A1 が切断されると、A2 は B からの受信を開始します。

このアーキテクチャは、待ち時間や接続タイムアウトがなければ機能します。したがって、理論的には正しいですが、実際にはそうではありません。

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

于 2013-11-20T16:18:18.717 に答える