監視ネットワークに100 Mbpsと1000 Mbpsのどちらを選ぶかは、各リンク、特に複数のカメラが共有するアップリンクを実際に通過するビットレートを計算して判断する必要があります。画素数だけを基準に接続可能なカメラ台数を固定したり、「100 Mbpsでは50 Mb/sしか使えない」をすべてのスイッチに共通する規則として扱ったりすることはできません。まずビットレートとアクセス経路を一覧化し、次に適切な余裕を確保し、最後に実際の業務トラフィックで検証してください。
カメラはビットレートを生み出し、スイッチはパケットを転送する
カメラは画像を連続した映像データにエンコードし、ビットレートは1秒間に生成されるビット数を示します。スイッチは通常、映像を再圧縮するのではなく、そのデータを運ぶイーサネットパケットを転送します。したがって、いわゆる「スイッチのビットレートの計算」とは、実際には特定のポートを通過する業務トラフィックと、その出力が時間内に送信できるかどうかを見積もることです。録画ストレージの要件はネットワークリンクの要件と関連しますが、完全に同じではありません。録画ファイルのサイズを、そのまますべてのリンク上のトラフィックとして扱うことはできません。
ネットワーク設計では通常、10進単位を使用します。1000 kb/sは1 Mb/sに相当し、Mb/sをMB/sに変換するには8で割ります。キロビットとキロバイトを混同したり、説明なしに一律に1024を用いて換算したりしないでください。統計画面によって表示方法が異なる場合があるため、単位とサンプリング周期を確認する必要があります。異なるツールで同じデータを読む場合は、まず、有効な映像データ、プロトコルパケット、ポートの総トラフィックのどれを集計しているかを確認してください。
計算対象のリンクを通過する通信だけを加算する
4台のカメラが、それぞれ8 Mb/sのメインストリームを1本ずつレコーダーへ送信すると仮定します。共有アップリンクには、少なくとも約32 Mb/sの映像データに加え、そのリンクを通過する音声、プロトコル、およびその他のサービスの通信を流す必要があります。これは説明用の例であり、特定の画素数に必ず対応するビットレートではありません。1台のカメラのアクセスポートにはそのカメラ自身のトラフィックだけが流れますが、4台で共有するアップリンクには集約されたトラフィックが流れます。両方に同じ接続台数の結論を適用することはできません。
あらゆる状況でメインストリームとサブストリームを機械的に合算すべきではありません。実際に要求され、このリンクを通過するストリームだけを数えてください。保守用コンピューターとカメラが同じアクセススイッチに接続されている場合、視聴中のサブストリームはローカルで転送され、レコーダー用アップリンクを通過しないことがあります。一方、クライアントがアップリンクの反対側にある場合は、計上する必要があります。複数のクライアントがそれぞれユニキャスト映像を要求すると、同じコンテンツが複数回送信される場合もあります。特定の区間でマルチキャストにより重複送信を減らせるかどうかは、機器とネットワーク設定によって異なり、すでに有効になっていると仮定してはいけません。
平均ビットレートとピークビットレートは別々に記録する
映像データ量は、エンコード方式、画像の複雑さ、動き、ノイズ、フレームレート、画質設定の影響を受けます。同じ解像度のカメラ2台でもビットレートが同じとは限らず、同じ機器でも動きの少ないシーンと多くの人が動くシーンでは変化する場合があります。H.265は圧縮効率を改善できる場合がありますが、どのような状況でもH.264に比べて必ず半分に削減できるとは保証できません。まずカメラのビットレート制御に関する資料を確認し、その後、現場の条件に合ったシーンで観測してください。
可変ビットレートでは映像に応じてデータ量が変化します。最大ビットレート制御や平均ビットレート制御には、画質と時間スケールに関するそれぞれのトレードオフがあり、具体的な挙動はカメラの実装に照らして確認する必要があります。1分間の平均値だけで計画すると、短時間のピークを見逃す場合があります。計測・記録には夜間、複雑な動き、イベント録画、複数人による同時プレビューの状態も含め、集計期間によって重要なバーストが平滑化されていないことを確認してください。見かけ上のトラフィックを許容範囲に収めるためにビットレートを際限なく下げ、録画画質を使い物にならなくしてはいけません。
余裕があるのに、なぜ映像がカクついたりフレームが欠落したりするのか？
出力側が各瞬間に送信できる速度は、リンク速度が上限です。入力側から急に多くのパケットが到着すると、スイッチはまだ送信できないデータを一時的に保存します。バーストが終わると、空いた送信能力によってキューが徐々に短くなります。トラフィックが出力容量を継続的に超えると、最終的にバッファが枯渇し、パケットが破棄される場合があります。バッファリングで回線速度が上がるわけではなく、QoSの優先制御も帯域幅を新たに生み出すものではありません。輻輳時に異なるサービスを処理する順序を決めるだけです。
100 Mb/sポートの利用可能な帯域が、50%または70%に固定されているわけではありません。実効的な業務データの割合は、パケットサイズ、プロトコルのオーバーヘッド、機器性能、試験方法の影響を受けます。設計上の余裕は技術的な判断で確保するものであり、ハードウェアの能力が本質的に半減していると誤って説明してはいけません。まず実際のトラフィックとエラーを測定し、その後、許容する持続的な使用率とバースト用の余裕を決めてください。重要な制御・監視サービスでは、余裕をサービスの信頼性目標に合わせる必要があり、一律の割合は適用できません。
アクセス側からレコーダーまで、区間ごとに容量を見積もる
まず、カメラ、アクセススイッチ、集約機器、レコーダー、クライアント間の接続図を作成し、各物理リンクの通信方向とサービスの発生元を明記します。各出力について、その地点を通過する同時通信のビットレートを合算し、音声、管理通信、その他の共有サービスを含めたうえで、プロトコルのオーバーヘッド、ピーク、将来の拡張を考慮します。全二重リンクでは両方向に独立した送信能力があるため、一方向の必要帯域を単純に2で割ることはできません。再生とアップロードが同時に行われる場合は、それぞれの通信方向も確認する必要があります。
飛暢科技のDINレールスイッチカタログには、光ポートと電気ポートのさまざまな組み合わせが用意されており、選定時にはアクセスポートとアップリンクを個別に確認できます。同社の10ギガビット・光4ポート・電気8ポート製品の詳細では、光ポートと電気ポートの能力が明確に区別されています。高速な集約接続は複数のアクセストラフィックを収容する容量を提供できますが、任意の台数のカメラが同時に稼働できることを証明するものではありません。スイッチだけを増強して他のボトルネックを残さないよう、光モジュールとリンクの互換性、全体の転送性能、レコーダーのネットワークポート、ストレージの書き込み性能、デコード能力を併せて確認してください。
実運用の試験で最終構成を決める
受入検査では、まずポートが計画した速度でネゴシエーションしているかを確認し、次に予定する録画、リアルタイムプレビュー、イベントサービス、再生を同時に有効にして、継続的なトラフィック、短時間のピーク、エラー、パケット損失を観測します。ネットワーク伝送が正常でも映像がカクつく場合は、レコーダーのディスク書き込み、CPU、デコード、およびカメラ自体をさらに確認し、すべての問題をスイッチのせいにしないでください。増強前後の効果を比較する試験では、画質と同時実行の条件をそろえる必要があります。
各カメラのエンコードパラメーター、要求されるストリーム数、トポロジー、ポート数、録画結果を保存し、追跡可能な容量表を作成してください。端末の追加やクライアントのアクセス方法の変更後には、再計算します。負荷試験は、隔離された試験用ネットワークまたは承認済みの保守時間帯に実施し、事前に設定をバックアップしてロールバック計画を用意してください。本番の映像サービスを計画外の実験に使ってはいけません。適切な容量計画は、「最大何台のカメラを接続できるか」という単一の数値を示すだけでなく、各リンクの容量が十分である理由を説明できるものでなければなりません。
仕組みに関する参考資料：Axisのビットレート制御資料；製品に関する根拠資料：飛暢科技のDINレールスイッチカタログ, 10ギガビット・光4ポート・電気8ポート製品の詳細。模式図は一般的な仕組みを示すものであり、特定製品の実測結果ではありません。
中国語の技術記事から翻訳。原文の初回公開日：2020-06-03。原文の最終改訂日時：2026-10-13T20:37:04+08:00。 中国語の原文を読む
