ブラウザ配信アーキテクチャ · 05/20

RTSP ゲートウェイのキャパシティ プランニング: カメラ、ビューア、トランスコード

1 つのゲートウェイの背後に多数のカメラ フィードを配置する前に、セッション、帯域幅、デコーダ サーフェス、障害ヘッドルームを見積もります。

対象となる質問: RTSP ゲートウェイの容量計画研究のチェック済み: 2026-09-11

直接の答え

カメラの取り込み、同時視聴者の出力、およびデコードまたはトランスコードが必要なすべてのストリームをカウントします。 平均的なダッシュボードではなく、ピークの組み合わせと再起動およびフェイルオーバーのヘッドルームのサイズ。

なぜこれが起こるのか

リレー専用パスは通常、ネットワークとセッション数によって制限されますが、トランスコーディングではデコーダ、エンコーダ、メモリ、および熱の制約が追加されます。 マルチカメラ グリッドにより負荷が急速に増大します。

通常、ブラウザにはカメラ フィードを Web ネイティブの配信パスに変換するゲートウェイが必要です。

管理されたテスト

小さな負荷モデルを構築し、実際のコーデック、解像度、フレーム レート、視聴者数を使用して検証します。

一度に 1 つの変数を変更します。 カメラのモデル、ファームウェア、エンドポイント、アカウントを記録しておきます。 次に、ネットワーク到達可能性、プロトコル応答、メディアトランスポート、およびデコードを個別のレイヤーとしてテストします。

専用の表示専用アカウントと信頼できるローカル診断ツールを使用します。 出力を共有する前に、資格情報、プライベート アドレス、識別データを編集します。

診断シーケンス

チェックアクション進歩の証拠
摂取する永続的なカメラ セッションとビットレートをカウントします。ソースの帯域幅とカメラの制限は既知です。
ファンアウト出力ごとのピーク視聴者数を推定します。出力帯域幅には制限があります。
コンピューティング同時のデコードおよびエンコード操作をカウントします。ハードウェアとソフトウェアの能力がテストされます。
ヘッドルーム再起動をテストし、ストームと 1 つの障害のあるノードを再接続します。サービスはカメラに過負荷をかけることなく回復します。

保管すべき証拠

現実的なピーク テスト中に p95 CPU、メモリ、出力、起動時間、再接続率を追跡します。

境界と安全上の注意

キャパシティの数値を生成する際のコーデックとワークロードの前提を考慮せずにキャパシティの数値を公開しないでください。

リモート表示の場合は、RTSP またはカメラ管理ポートをパブリック インターネットに直接公開するのではなく、管理された VPN を使用します。

SmartRTSP

SmartRTSP は、Apple デバイス、Windows、Android 用のカメラに焦点を当てた RTSP および ONVIF ビューアです。 直接表示、発見、マルチカメラのチェックに適しています。 継続的な記録、証拠のエクスポート、または企業の集中管理が必要な場合は、専用の NVR または VMS を用意してください。

よくある質問

1 つのゲートウェイで何台のカメラを処理できますか?

有用な普遍的な番号はありません。 それはビットレート、コーデック、トランスコーディング、ハードウェア、および視聴者のファンアウトによって異なります。

パススルーによりすべてのコンピューティング コストが削減されますか?

ほとんどのビデオ エンコード コストが削減されますが、ネットワーク、メモリ、セッション、パッケージ化のリソースは引き続き使用されます。

なぜ再接続ストームをテストするのでしょうか?

ゲートウェイを再起動すると、すべてのカメラとブラウザのセッションが一度に再接続され、通常の負荷をはるかに超えるピークが発生する可能性があります。

一次参考文献

関連する SmartRTSP ガイド

関連ガイドを開く

1 つのゲートウェイの背後に多数のカメラ フィードを配置する前に、セッション、帯域幅、デコーダ サーフェス、障害ヘッドルームを見積もります。