監視システムは単独では完璧に機能しても、指揮プラットフォーム、Webアプリケーション、またはサードパーティのビジネスシステムに接続するのは困難な場合があります。カメラ、NVR、ビデオ管理プラットフォーム、ドローン、モバイル端末は、異なるプロトコル、コーデック、ストリーム形式、解像度、認証方法を使用する可能性があります。ビデオゲートウェイは、これらのシステム間に制御された統合レイヤーを提供し、各プラットフォームを再記述したり、各フィールドデバイスを交換したりすることなく、既存のビデオリソースを再利用できるようにします。

統合レイヤーがしばしば必要とされる理由

ビデオプロジェクトは、同じ時期に構築されたり、単一のメーカーから供給されたりすることはめったにありません。あるサイトには、H.264を使用する古い監視システム、H.265を使用する新しく導入されたカメラネットワーク、SIPとWebRTCに基づく指揮プラットフォーム、ブラウザ互換のビデオを期待するビジネスアプリケーションが存在するかもしれません。各システムは元の機能を正しく実行できますが、それらの間の直接通信は保証されません。

違いは通常、いくつかの領域に現れます：

• デバイスの登録と認証

• ビデオシグナリングとストリーム制御方法

• H.264、H.265、その他のコーデックの互換性

• RTSP、RTMP、SIP、GB/T 28181、ベンダーSDKによるアクセス

• FLV、HLS、WebRTC出力要件

• 解像度、フレームレート、ビットレートの制限

• オーディオサポートと双方向通信

• ブラウザ、モバイル端末、大画面再生

これらの違いを解決するためにすべてのカメラ、レコーダー、アプリケーションを変更することは、大きな開発負荷を生み出す可能性があります。また、すでに信頼性高く動作しているシステムにリスクをもたらすこともあります。送信元と送信先の間にゲートウェイを配置することで、より明確な境界が作成されます。元のシステムは確立されたワークフローを維持し、ゲートウェイがアクセス、変換、配信を処理します。

このアーキテクチャは、組織が既存の監視投資を維持しながら、指揮指令、緊急対応、IoT連携、リモートアクセス、または集中管理を追加したい場合に特に有用です。

分散カメラシステムを1つの運用ビューに統合する

複数の支店、産業サイト、駅、キャンパス、または遠隔施設を持つ組織は、しばしば別々の監視システムを運用しています。カメラとNVRはローカル制御下に置かれ、地域または全国のセンターは選択されたストリームへの権限ベースのアクセスを必要とします。

ビデオゲートウェイはこれらのリソースを集約し、上位プラットフォームに接続できます。関係するシステムに応じて、アクセスはGB/T 28181、RTSP、RTMP、SDK、または他のサポートされたインターフェースを使用する場合があります。ゲートウェイは、各リモートサイトに既存のレコーダーやカメラ資産を交換させることなく、必要なストリームを宛先プラットフォームに提示します。

この構成は、いくつかの運用モデルをサポートできます：

• 複数の支店からのカメラの集中表示

• 重要なストリームを指揮センターと選択的に共有

• プライベートネットワーク、WANリンク、またはVPN接続を介したビデオアクセス

• 既存の監視と新しいGISまたは指令プラットフォームとの統合

• 1つのビデオリソースを異なる認可アプリケーションに制御配信

ゲートウェイは単なるパッシブなネットワークブリッジとして扱うべきではありません。実用的な展開には、デバイスマッピング、ストリームステータス監視、アクセス権限、接続ログ、明確な命名も必要です。オペレーターは、説明のつかないIPアドレスやチャンネル番号ではなく、「北門カメラ」「生産ライン2」「トンネル入口」などの運用名を表示されるべきです。

集中化は、必ずしもすべてのストリームが継続的に送信されなければならないことを意味するわけではありません。帯域幅が限られているリモートサイトでは、プラットフォームはアラームが発生したとき、またはオペレーターがカメラを選択したときにビデオを要求できます。メインストリームとサブストリームは異なる目的で使用することもできます。証拠や大画面表示用の高品質ストリームと、プレビューやモバイルアクセス用の低ビットレートストリームです。

カメラ、ドローン、フィールドビデオを同時にサポート

最新の指揮プロジェクトでは、固定監視カメラだけでなく、PTZカメラ、NVR、ボディーカメラ、車載端末、ドローン、スマートヘルメット、ポータブルレコーダー、ビデオインターホン、SIPビデオフォンなどからビデオが提供されます。これらのデバイスはプロトコルだけでなく、ストリームの開始、維持、終了の方法も異なります。

ビデオゲートウェイは、これらのソースを指揮環境に渡す前に正規化できます。固定カメラは監視プロトコルを介して登録され、ドローンやモバイル端末はRTMPストリームをプッシュする場合があります。指令コンソールはSIPを介してビデオを要求し、WebアプリケーションはFLV、HLS、またはWebRTC出力を必要とする場合があります。

一般的な統合パスには以下が含まれます：

• RTSPを介したカメラとNVRからのライブビデオのプル

• RTMPを介したドローンやモバイルデバイスからのプッシュビデオの受信

• GB/T 28181を介した監視リソースの接続

• ビデオとSIP通話、インターホンイベント、または指令セッションの関連付け

• WebRTC、HLS、またはFLVを介したブラウザ互換ストリームの配信

• サードパーティアプリケーション開発のための制御されたインターフェースの提供

オーディオ機能は別途確認する必要があります。ライブビデオを提供するデバイスが自動的にオーディオ、トークバック、またはSIP通信をサポートするわけではありません。プロジェクトがオペレーターに同じインターフェースから場所を確認し、現場要員と話すことを要求する場合、設計はオーディオコーデック、マイクとスピーカーの経路、エコー処理、権限、通話制御の動作を検証する必要があります。

これは指揮センターにおいて重要です。なぜなら、ビデオは通常、より広範な対応プロセスの一部だからです。オペレーターは近くのカメラを開き、フィールド端末に通話し、会議を開始し、ページングメッセージを発行し、1つのワークステーションからインシデントを記録することができます。ゲートウェイはビデオを利用可能にし、通信および指令プラットフォームは完全な運用ワークフローを制御します。

各ストリームを宛先に適応させる

プロトコル変換とビデオトランスコーディングは異なる問題を解決します。プロトコル変換はストリームへのアクセス、転送、または提示方法を変更します。トランスコーディングはコーデック、解像度、フレームレート、ビットレートなどのメディア自体を変更します。一部のプロジェクトではストリーム転送のみが必要であり、他のプロジェクトでは両方のプロセスが必要です。

H.264とH.265の間で一般的な互換性の問題が発生します。多くの既存の監視または通信システムはH.264を中心に設計されていますが、新しい監視展開ではストレージと帯域幅の消費を削減するためにH.265の使用が増えています。宛先がソースコーデックをデコードできない場合、ストリームは表示前にトランスコードされなければなりません。

トランスコーディングは以下の場合にも必要になることがあります：

• 高解像度カメラを低解像度端末に表示する必要がある場合

• 高ビットレートストリームが制限されたWANまたはモバイル接続を通過する必要がある場合

• ブラウザまたはモバイルアプリケーションが元のメディア形式をサポートしていない場合

• ライブ監視と録画で異なるフレームレートが必要な場合

• 指揮プラットフォームがH.264を必要とし、ソースシステムがH.265を出力する場合

• ストリームにオーバーレイ、タイムスタンプ、マスキング、またはウォーターマーク処理が必要な場合

トランスコーディングは転送よりもかなり多くの処理リソースを消費します。したがって、容量は同時ストリーム数、ソース解像度、出力解像度、コーデック変換、フレームレート、予想動作時間から計算する必要があります。多くのチャンネルを転送できるゲートウェイでも、完全なトランスコーディングが有効になっている場合はサポートできるチャンネル数が少なくなる可能性があります。

レイテンシーも考慮する必要があります。デコード、処理、再エンコードの各段階で遅延が追加されます。監視レビューはインタラクティブな指令、ドローン制御、ビデオインターホンよりも多くのレイテンシーを許容できます。リアルタイム操作では、アーキテクチャは不要な変換を最小限に抑え、アプリケーションに適した出力方法を選択する必要があります。

ビデオとアラームおよびビジネスワークフローの連携

ビデオが単独の監視画面ではなく、運用イベントの一部となると、統合の価値が高まります。IoT、アクセス制御、境界保護、機器監視、緊急通信プラットフォームは、ビデオを使用してアラームを検証し、次のアクションを導くことができます。

例えば、産業エリアのガスセンサーが異常値を報告する場合があります。アプリケーションはセンサーの位置を特定し、ゲートウェイを介して関連するカメラを要求し、当直オペレーターにライブストリームを表示します。オペレーターはその後、現場要員に通話し、対応手順を起動するか、通信プラットフォームを介して警告を送信できます。

同様のワークフローは以下に対して設計できます：

• 入口カメラに関連付けられたアクセス制御アラーム

• 近くのPTZカメラに関連付けられた境界イベント

• 生産エリア監視に関連付けられた機器故障

• 位置固有のビデオに関連付けられた緊急インターホン通話

• 道路およびトンネルカメラに関連付けられた交通イベント

• モバイルチームがライブビデオを指揮マップに返送する

• 点検や緊急対応中に表示されるドローンのストリーム

ゲートウェイは、ビジネスアプリケーション内で必要なビデオ固有の開発量を削減できます。アプリケーションは、カメラのブランド、レコーダー、ストリーム形式ごとに個別のアクセスモジュールを構築する代わりに、正規化されたメディアインターフェースに接続し、自身のワークフロー、ユーザー権限、イベントロジックに集中します。

このアプローチは、スマートパーク、工業プラント、鉱山、公共事業、交通ネットワーク、キャンパス、商業施設、マルチサイト組織に適用できます。ビジネスプラットフォームはアラーム、地図、作業指示、対応手順の責任を引き続き担い、ゲートウェイはビデオアクセス、メディア適応、ストリーム配信を処理します。

信頼性の高い展開の設計

成功するプロジェクトは、送信元システムと宛先システムの棚卸しから始まります。プロトコル名のリストを確認するだけでは不十分です。2つの製品がどちらもRTSPまたはGB/T 28181をサポートしていると主張しても、認証、ストリームアドレッシング、コーデック処理、デバイスカタログ構造、またはシグナリング動作が異なる場合があります。

設計チームは以下を確認する必要があります：

• カメラ、NVR、プラットフォーム、モバイルビデオソースの数と種類

• 必要な入力および出力プロトコル

• ビデオおよびオーディオコーデックの互換性

• 最大同時ライブ、転送、トランスコードストリーム数

• 代表的なソースの解像度、フレームレート、ビットレート

• ブラウザ、モバイル、ワークステーション、ビデオウォールの再生要件

• 監視およびインタラクティブアプリケーションに予想されるレイテンシー

• ユーザー認証、権限、暗号化転送の要件

• WAN帯域幅、パケット損失、ネットワークフェイルオーバー条件

• 監視、ログ、時刻同期、保守責任

概念実証テストでは、実際の機器と代表的なストリームを使用する必要があります。連続再生、ネットワーク中断後の再接続、オーディオ同期、必要な場合のPTZ制御、ブラウザ互換性、各トランスコーディングプロファイルの動作を検証する必要があります。短時間に1台のカメラだけをテストすることは、マルチチャンネルの本番環境を代表するものではありません。

高可用性要件も定義する必要があります。重要な指揮プロジェクトでは、冗長ゲートウェイ、複数のネットワークインターフェース、プラットフォームフェイルオーバー、サービス中断後のストリームリカバリが必要になる場合があります。上位指揮プラットフォームへの接続が利用できない場合でも、ローカル監視は独立して動作し続けるべきです。

ビデオゲートウェイは、その役割が明確に定義されている場合に最も効果的です。プロトコル適応、ストリームアクセス、転送、トランスコーディング、統合サポートを提供しますが、完全なビデオ管理システムのすべての録画、調査、アラーム管理、証拠保存機能を自動的に置き換えるわけではありません。多くのプロジェクトでは、2つのシステムが連携して動作します。

よくある質問

1つのカメラストリームを複数のアプリケーションで共有できますか？

はい、ゲートウェイがストリーム複製またはメディア配信をサポートしている場合に可能です。ゲートウェイはソースストリームを1回取得し、認可されたアプリケーションに個別の出力を提供できるため、各アプリケーションがカメラへの独自の接続を確立する必要性が減ります。実際の容量は出力帯域幅と同時セッション制限によって異なります。

ビデオゲートウェイにはパブリックインターネット接続が必要ですか？

いいえ。LAN、プライベートWAN、または隔離されたネットワーク内で完全に動作できます。インターネットアクセスが必要なのは、リモートユーザー、クラウドサービス、または外部プラットフォームがインターネット接続を介してビデオを受信する必要がある場合のみです。

デスクトップクライアントではストリームが再生できるのに、ブラウザでは再生できないのはなぜですか？

デスクトップクライアントには、ブラウザがサポートしない独自のコーデックやプロトコルコンポーネントが含まれている場合があります。ブラウザ再生には通常、WebRTC、HLS、またはブラウザサポートのフラグメントビデオなどの互換性のある配信方法が必要です。ストリームは表示前にプロトコル変換またはトランスコーディングが必要な場合があります。

すべての着信ストリームをトランスコードする必要がありますか？

いいえ。ソースコーデックとパラメータが既に宛先でサポートされている場合、直接転送の方が効率的でレイテンシーも少なくなります。トランスコーディングは、互換性、帯域幅、または表示要件によって必要になる場合にのみ有効にすべきです。

リモートネットワーク接続が失敗した場合はどうなりますか？

ローカル監視システムは、独立して録画と動作を継続する必要があります。ゲートウェイと上位プラットフォームは中断を検出し、オフライン状態を報告し、ネットワーク復旧後に自動的にストリームアクセスを復元する必要があります。重要なプロジェクトでは、二次伝送経路も必要になる場合があります。