WebRTCは、緊急指令、統合通信、産業制御、公共安全、リモート運用向けのブラウザベースのディスパッチコンソールを構築するためにますます使用されています。そのリアルタイム音声・ビデオ機能により、オペレーターが従来のデスクトップクライアントをインストールすることなく、通話、会議、指令機能、マルチメディア通信を1つのWebインターフェースに統合することが可能になります。

課題は、ディスパッチプラットフォームが既存の監視システム、ポータブル監視カメラ、ドローン、ウェアラブルデバイス、またはサードパーティのビデオプラットフォームからのビデオも表示しなければならない場合に発生します。これらのシステムは異なるコーデック、トランスポートプロトコル、解像度、フレームレート、ストリーミングフォーマットを使用する場合があります。そのため、監視プラットフォーム内で正しく動作するビデオストリームが、WebRTCディスパッチコンソール内で直接再生できないことがあります。実用的な解決策は、ディスパッチアプリケーション全体を再設計することではなく、ビデオソースとブラウザベースのコンソールの間にメディア変換およびプロトコル適応レイヤーを配置することです。

ビデオアクセスが困難になる理由

最新のディスパッチシステムは音声だけに限定されることはめったにありません。オペレーターは、通話への応答、現場担当者との通信、CCTVフィードの監視、ドローンカメラの視聴、ビデオ会議への参加、インシデント発生場所の確認を同じワークステーションから行う必要があります。そのため、システムは元々独立して設計された通信リソースを接続することが期待されています。

WebRTCはインタラクティブなブラウザ通信に特に適しています。低遅延のメディア伝送を提供し、ブラウザベースの音声、ビデオ、会議アプリケーションで広く使用されています。WebRTCを中心に構築されたディスパッチコンソールは、標準的なWebインターフェースを介して通信制御を公開でき、閉じたデスクトップクライアントよりも他のビジネスアプリケーションと簡単に統合できます。

しかし、監視インフラストラクチャは異なる技術的経歴を持っています。カメラ、ネットワークビデオレコーダー、ビデオ管理システム、ポータブル監視端末、ドローン、業界固有の監視プラットフォームは、GB/T28181、RTSP、RTP、RTMP、HLS、SIP、またはその他のインターフェースを介してストリームを提供する場合があります。また、ブラウザ再生よりもストレージ効率を優先して選択されたビデオコーデックを使用する場合もあります。

結果として生じる問題は相互運用性のギャップです。ビデオソースは利用可能で、ディスパッチコンソールは正常に動作し、ネットワーク接続も機能しているにもかかわらず、ブラウザは元の形式のストリームをデコードまたは消費できません。

関連製品：Beckeディスパッチコンソール

H.265が互換性のギャップを生み出す箇所

監視システムがH.265ビデオを配信する場合、最も一般的な統合問題の1つが発生します。H.265（HEVCとしても知られる）は、同等の画質で古い符号化方法と比較して帯域幅とストレージ要件を削減できるため、監視アプリケーションにとって魅力的です。大規模なカメラ展開では、この効率性は貴重です。

問題は、H.265再生サポートが一般的なWebRTCおよびブラウザ環境全体で一貫して利用できるわけではないことです。そのため、監視プラットフォームは完全に有効なH.265ストリームを提供するかもしれませんが、それはディスパッチ位置で使用されるWebRTCアプリケーションによって直接消費できません。

ブラウザを満足させるためだけにすべてのカメラを交換したり、監視プラットフォーム全体を変更することは通常非現実的です。考えられるすべてのサードパーティコーデックに合わせてディスパッチコンソールを修正することも、不要な開発複雑性を生み出します。より管理しやすいアプローチは、メディアがWebRTCに到達する前に正規化することです。

このアーキテクチャでは、ビデオトランスコーディングサービスが元のH.265ストリームを受信し、それをH.264またはターゲットWebRTC環境でサポートされる別の形式に変換します。ディスパッチコンソールは、元のH.265メディアを直接デコードしようとする代わりに、変換されたストリームを消費します。

この分離は、メディア互換性をコアディスパッチアプリケーションの外側に保つため重要です。ブラウザインターフェースは通常のWebRTCワークフローを継続して使用でき、ゲートウェイがバックグラウンドでコーデック適応を処理します。

実用的なトランスコーディングゲートウェイアーキテクチャ

ビデオトランスコーディングゲートウェイは、監視リソースとWebRTCディスパッチレイヤー間のメディアブリッジとして機能します。その役割は単純なコーデック変換よりも広範です。実際の統合通信プロジェクトでは、複数のビデオプラットフォームからストリームを受信し、メディアパラメータを変換し、ストリームを再パッケージ化し、ディスパッチシステムが使用できる形式で公開する必要がある場合があります。

典型的なワークフローは5つの段階に分けることができます：

1. ディスパッチプラットフォームが特定のカメラ、ドローン、ポータブル監視デバイス、またはサードパーティビデオリソースを要求します。

2. ゲートウェイは、利用可能な監視またはストリーミングプロトコルを介してソースストリームを取得します。

3. メディアサービスが、着信コーデック、解像度、フレームレート、ビットレート、ストリームフォーマットをチェックします。

4. 必要に応じて、ビデオはWebRTC環境に適した形式にトランスコードまたは再パッケージ化されます。

5. 変換されたメディアは、リアルタイム視聴のためにブラウザベースのディスパッチコンソールに配信されます。

H.265ソースの場合、最も重要なステップは通常H.265からH.264への変換です。他のプロジェクトでは、コーデックはすでに互換性があるかもしれませんが、解像度、ビットレート、フレームレート、またはプロトコルパッケージングがまだ調整を必要とする場合があります。

このアーキテクチャはシステム間の結合も低減します。監視プラットフォームはディスパッチインターフェースがどのように実装されているかを理解する必要はなく、WebRTCアプリケーションはすべてのカメラベンダーやストリーミングフォーマットに対して専用ロジックを含める必要はありません。各側は相互運用性のために特別に設計されたメディア適応レイヤーに接続します。

ビデオシステム間のプロトコル相互接続

コーデック変換は統合問題の一部しか解決しません。異なるシステムは異なるシグナリングおよびトランスポートプロトコルも使用する場合があります。したがって、完全なビデオゲートウェイはメディア処理と同様にプロトコル適応も実行する必要があります。

指令および監視環境で遭遇する一般的なインターフェースには、GB/T28181、RTSP、RTP、RTMP、FLV、HLS、SIP、WebRTCが含まれます。それらの目的は同一ではありません。監視デバイスのアクセスと制御に使用されるもの、リアルタイムメディアトランスポートに使用されるもの、ストリーミング配信に使用されるもの、セッションシグナリングまたはブラウザ通信に使用されるものがあります。

これらのシステム間に配置されたゲートウェイは、ある形式のストリームを受信し、ディスパッチプラットフォームが必要とする別のインターフェースを介して提供できます。例えば、監視カメラはRTSPを介してアクセスされる一方、既存の監視プラットフォームはGB/T28181を介してリソースを公開する場合があります。ゲートウェイがそれらをWebRTC互換の配信パスに変換すれば、ディスパッチアプリケーションはこれらのプロトコルを直接消費する必要はありません。

統合ストリーミングサービスは、ストリームのプルとパブリッシュも管理できます。オペレーターがカメラを選択すると、システムはソースプラットフォームからのプル操作を開始し、メディアを処理し、結果のストリームをディスパッチコンソールに向けて公開できます。これにより、リソースが表示されていないときに不要なストリームを維持することを回避できます。

同じアーキテクチャはCCTV以外でも有用です。ポータブル監視カメラ、ドローンビデオ、ビデオフォン、会議システム、その他のリアルタイムメディアリソースはすべて、異なるプロトコルを介して統合指令環境に入る可能性があります。プロトコルを認識するゲートウェイは、それらの違いを処理するための共通ポイントを提供します。

実際のプロジェクトのための展開ワークフロー

統合プロジェクトを成功させるには、WebRTCインターフェースだけではなく、既存のビデオ環境から始めるべきです。最初のタスクは、表示する必要があるリソースと、それらのリソースが現在どのように公開されているかを特定することです。

既存のビデオソースをマッピングする

プロジェクトチームは、監視プラットフォーム、固定カメラ、ポータブルカメラ、ドローン、会議システム、ビデオフォン、その他の関連ソースをリストアップする必要があります。各リソースについて、利用可能なプロトコル、コーデック、解像度、フレームレート、認証方法、ネットワーク上の場所を文書化する必要があります。

シグナリングをメディアから分離する

一部のシステムでは、シグナリングがアクセスするデバイスを決定し、メディアは別のプロトコルを介して転送されます。シグナリングとメディアを別個の統合レイヤーとして扱うと、トラブルシューティングが容易になります。カメラは登録と制御に成功しても、コーデックまたはトランスポートの非互換性のためにビデオストリームが依然として失敗することがあります。

必要な場合にのみ正規化する

トランスコーディングは計算リソースを消費し、追加の処理遅延を導入する可能性があります。したがって、実用的なゲートウェイは不要な変換を避けるべきです。ソースがすでにWebRTC環境で受け入れられているコーデックとメディアプロファイルを使用している場合、再パッケージ化または転送で十分な場合があります。完全なトランスコーディングは、コーデックまたはメディアパラメータが本当に互換性がない場合に使用すべきです。

オンデマンドストリームプルを使用する

大規模な監視システムには数百または数千のカメラが含まれる場合がありますが、ディスパッチオペレーターは通常一度に小さなサブセットしか表示しません。オペレーターが要求したときのみストリームを開始することで、帯域幅、メディア処理負荷、不要なサーバーリソース消費を削減できます。

オペレーターのワークフローをシンプルに保つ

メディア変換はディスパッチオペレーターにとって見えないままであるべきです。理想的には、オペレーターは連絡先リスト、GISマップ、インシデントページ、またはビデオリソースパネルからカメラを選択し、画像が直接開きます。プロトコル選択、コーデック変換、ストリーム確立、回復はバックエンドが処理する必要があります。

信頼性とメディア品質が重要

ストリームを表示可能にすることは最初のステップに過ぎません。緊急指令および産業用ディスパッチアプリケーションは、変化するネットワーク条件下でも安定したビデオを必要とします。したがって、使用可能なメディアレイヤーはコーデックだけでなく、より多くのことを適応できるべきです。

高解像度カメラをより小さいディスパッチウィンドウで表示するか、制限されたネットワーク接続を介して配信する必要がある場合、解像度調整が役立つことがあります。フレームレート変換は、非常に高いフレームレートが不要な監視シナリオにおいて、処理と帯域幅の要件を削減する可能性があります。ビットレート制御は、利用可能なネットワーク容量が変化するときに継続性を維持するのに役立ちます。

これらの機能は、両方とも名目上H.264をサポートしていても、2つのビデオシステムが異なるメディアプロファイルを使用する場合にも役立ちます。解像度、プロファイル、フレームレート、ビットレート、またはパケット化の違いが、依然としてスムーズな相互運用性を妨げる可能性があります。

したがって、メディアゲートウェイは、ビデオフォン、会議プラットフォーム、CCTVシステム、ドローンフィード、ブラウザベースのディスパッチアプリケーション間の正規化ポイントとして機能できます。すべてのサブシステムが他のすべてのサブシステムに直接一致することを要求する代わりに、各システムはゲートウェイへの信頼できる接続のみを必要とします。

ネットワーク設計では、遅延、パケット損失、ストリーム回復、認証、アクセス制御、同時視聴要件も考慮する必要があります。指令センターでは複数のオペレーターが同じソースを表示する必要がある場合があり、インシデントが突然複数のビデオリソースを同時に開くことを要求する場合があります。キャパシティ計画は、単一のテストストリームだけでなく、現実的なピークワークフローを反映する必要があります。

最終ノート

WebRTCはブラウザベースのディスパッチコンソールに効果的な基盤を提供しますが、実際の指令システムはネイティブWebRTCエンドポイントよりもはるかに多くを接続する必要があります。CCTVプラットフォーム、ドローン、ポータブル監視機器、会議システム、レガシービデオリソースは、多くの場合異なるコーデックとストリーミングプロトコルを導入します。

H.265は特に一般的な非互換性の原因です。ディスパッチコンソールを再設計したり既存の監視機器を交換したりする代わりに、メディアトランスコーディングゲートウェイが元のストリームを受信し、必要に応じてH.265をH.264に変換し、解像度、フレームレート、ビットレートを適応させ、WebRTC互換のパスを介して結果を配信できます。

同じゲートウェイがGB/T28181、RTSP、RTP、RTMP、FLV、HLS、SIP、WebRTCなどのインターフェースもサポートする場合、より広範な統合通信アーキテクチャのための実用的な相互運用レイヤーになります。その結果、オペレーターが単一のインターフェースを介して異種ビデオリソースにアクセスでき、コーデック変換とプロトコル適応は舞台裏で行われるディスパッチワークフローが実現します。

FAQ

すべての監視ストリームは、オペレーターが要求する前に恒久的に変換されるべきですか？

通常はそうではありません。大規模な展開では、オンデマンド処理がより効率的であることがよくあります。メディアサービスは、オペレーターが対応するリソースを開いたときにストリームのプルと適応を開始し、ストリームが不要になったときに処理能力を解放できます。

同じカメラストリームを複数のディスパッチオペレーターに配信できますか？

はい、ストリーミングアーキテクチャが1対多配信用に設計されている場合に限ります。メディアサービスはソースを一度受信し、処理済みの出力を複数の認可された視聴者に配信できます。これにより、オペレーターごとに個別の上流接続を開く必要がなくなります。

ビデオアクセス権限はどのように管理すべきですか？

カメラアクセスは通常、ディスパッチプラットフォームのユーザーおよびロール権限に従うべきです。オペレーターは特定の地域、施設、カメラグループ、またはインシデント関連リソースのみを表示できる一方、管理者はより広範な制御および設定権限を受け取ることができます。

元のビデオソースが一時的に利用できなくなった場合はどうなりますか？

ディスパッチアプリケーションは、画像が無期限にフリーズした状態を表示するのではなく、明確なオフラインまたは再接続中の状態を受け取るべきです。バックエンドは定義された再試行ポリシーに従って再接続を試み、上流ソースが再び利用可能になった後にストリームを自動的に復元できます。