RFCに対応する高性能のマルチカメラ・ビデオ・ストリーミング、GMSLとイーサネットのブリッジ技術で実現

Figure 1

   

要約

本稿では、RFC(Request for Comments)に対応するビデオ・ストリーミング・システムの設計例を紹介します。そのシステムは、高速でレイテンシが小さく、複数のカメラに対応できるように構成します。設計の中核を成すのは、ギガビット・マルチメディア・シリアル・リンク(GMSL:Gigabit Multimedia Serial Link)をイーサネットのドメインにシームレスに接続する技術です。また、この設計例では、高速ビデオ・ストリーミング用のパイプラインの全体を、FPGAをベースとして実現することにします。それにより、性能/電力効率/柔軟性の高さというアーキテクチャの長所を生かすことが可能になります。

はじめに

2020年代には数多くの新技術が登場しました。その結果、様々なシステムやアプリケーションが生み出されています。なかでも重要な成果としては、自律型ロボットを活用した産業用オートメーション・システム1や自動運転システム2が挙げられるでしょう。それらのシステムを実現する上で、特に重要な要素として捉えられているものがあります。それは、ロボットや車両の周囲の環境に関するリアルタイムの情報を取得するためのビデオ伝送技術です。その種の技術にはいくつもの選択肢が存在します。本稿では、特に有力なものとして1つの技術を取り上げることにします。それがGMSL技術です。同技術を使用すれば、複数のカメラ・モジュールと主にホストの処理を担うSoC(System on Chip)の間に高速ビデオ・リンクを設けることができます。しかも、伝送に使用するケーブルを1本に抑えたコスト効率の高い実装が得られます。つまり、GSMLは高速ビデオ伝送における重要な柱として活用できるということです。その一方で、様々な自律型の要素において使われるデバイスの大半は、イーサネット規格に基づくネットワークに接続されます。つまり、極めて重要なデータ伝送の手段としてイーサネットは広く用いられています。実際、高速伝送を実現するためにイーサネットをベースとする様々な実装が登場しました。このような背景から、ビデオ・ストリーミング技術は、ホスト側のSoCとネットワーク環境に配備された他のデバイスの間で重要な役割を担うことになります。その技術により、標準化された高速な方法によってカメラのピクセル・データを伝送可能なパイプラインを実現しなければならないということです。ビデオ・ストリーミングにおいては、高速でレイテンシが小さいことが非常に重要です。そのため、ビデオ・ストリーミングに用いるデバイスとしてはFPGAが最良の選択肢になります。なぜなら、FPGAは、並列処理の能力が高く、必要な機能を非常に高い柔軟性で実装可能なデバイスだからです。本稿では、まずFPGAのリソースだけを使うことにより、ビデオ・ラインのデータをIP(Internet Protocol)ベースのネットワークのパケットに効率良く変換する方法を説明します。また、その方法によって、RTP(Real-time Transport Protocol)をベースとするビデオ配信を実現する方法を明らかにします。更に、それらの方法を有効に活用できることを確認するためのシステムの実装例を紹介します。その例では、高性能でレイテンシが小さくコスト効率の高いエッジ・コンピューティング用のプラットフォーム「ADRD8012-01Z」を使用します。これを使用すれば、複数のカメラに対応するGMSLチャンネルによってビデオ・ストリーミングを実行できます。

GMSLの概要、RTPの仕様

アナログ・デバイセズのGMSL技術は、コスト効率と拡張性に優れるSERDES(Serializer/Deserializer)ソリューションです。リアルタイムのビデオ・データ、制御用のデータ(情報)、電力を1本のケーブルで伝送できるように設計されています。このソリューションのアーキテクチャには2つのバリエーションがあります。1つはカメラ・モジュールと組み込みSoCシステムの間に、非常に信頼性の高いシリアル・リンクを確立するためのものです。もう1つのアーキテクチャを使用すれば、組み込みSoCシステムとディスプレイ・デバイスの間に同様のシリアル・リンクを確立できます。現在、カメラを対象とするGMSL技術は自動車業界で広く使われています。同技術を採用すれば、ケーブルの数を最小限に抑えつつ、車両の複数のゾーンに高速ビデオ・リンクを効率的に配備できるからです。このことは、自動運転を実現する上で極めて重要な意味を持ちます。また、GMSLは、ロボット、産業、計測、医療といった分野の様々なアプリケーションにも大きな効果をもたらします。

GMSLでは、ケーブル1本で伝送を実現できるようにするために、高性能のSERDES技術を使用します。つまり、その主要な構成要素はGMSLシリアライザとGMSLデシリアライザの2つです。カメラに関する文脈において、シリアライザは、MIPI(Mobile Industry Processor Interface) CSI-2(Camera Serial Interface 2)規格3に対応するカメラのインターフェースから出力される高速/並列のビデオ・データをシリアル・データに変換する役割を担います。GMSLに対応する伝送エンジンの次段にあるのは高速シリアル・リンクです。ここでは、同軸ケーブルまたはシールド付きのツイスト・ペア(STP:Shielded Twisted Pair)ケーブルを使用します。それにより、GMSL1では最高3Gbps、GMSL2では同6Gbps、GMSL3では同12Gbpsのデータ転送速度が得られます。デシリアライザは、複数のシリアライザからのデータをアンパックし、CSI-2に対応した1つ以上のインターフェースから出力されるデータを生成します。時分割方式の伝送を実現するために、GMSLに対応するデバイスはMIPICSI-2で提案されている仮想チャンネル機能を利用します。仮想チャンネルの識別子は、データをインターリーブするための簡略化されたメカニズムとして機能します。割り当てられたIDの値を使用することで、レシーバーは複数のビデオ・ソースから受信したフレームを簡単に解釈することができます。

ここで図1をご覧ください。図の左側には、GSMLに対応する4台のカメラが存在します。一方、右側にあるのはAMD(Advanced Micro Devices)が提供するSoC(旧Xilinx製)です。この図は、これらを接続したシステムを表しています。このシステムでは、CSI-2に対応するレシーバーとI2Cに対応するコントローラを使用して、ビデオ・データと制御データの両方を処理します。CSI-2に対応するレシーバー用のロジックは、SoC上のFPGAの領域に実装されています。

図1. GMSLからCSI-2(FPGA)へのデータの伝送。GMSLデシリアライザとしてMAX96724を使用しています。
図1. GMSLからCSI-2(FPGA)へのデータの伝送。GMSLデシリアライザとしてMAX96724を使用しています。

IPベースのネットワークを介したライブ・ビデオ・ストリーミングでは、RTP4が最も一般的に使用されています。通常、RTPはUDP(User Datagram Protocol)5を使用したレイテンシの小さいコネクションレス型のトランスポート・メカニズムに依存します。また、ビデオ・ペイロードの複数のフォーマットに対応できるように、パケット化を実現するための方式がいくつか定義されています。図2に、非圧縮ビデオ用の一般的なRTPパケットの構成を示します6。ご覧のように、汎用的なRTPヘッダ、RTPペイロード・ヘッダの後に、特定の数(一部または全体)のビデオ・ライン(ビデオ・データ)が続きます。RTPはアプリケーション層の実装として機能します。そのため、ペイロードのデータについて詳細に定義するために必要なあらゆるフィールドを備えています。アプリケーションに固有のフィールドとしては、ライン、ビデオ・タイプ、エンドオブフレームなどが挙げられます。

図2. RTPパケットのフォーマット
図2. RTPパケットのフォーマット

FPGAとCPUサブシステムの比較

2020年代に入ると、自律性に関する目覚ましい進化を目にするようになりました。ロボットによる産業用オートメーションや自動運転など、いくつもの市場で革新的なソリューションに対する需要が高まっています。それらのソリューションでは、多様なセンサー・ネットワークやAI用の複雑なアルゴリズムが使用されます。それに加えて、高速でレイテンシの小さいビデオ・ストリーミングも必要になります。特に、自動運転システム、ヒューマノイド(人型ロボット)のようなインテリジェントな機器では重要な役割を担います。そのような用途で検討すべき事柄の1つは、ビデオ・データのリアルタイム伝送についてです。そうすると、コネクションレス型のトランスポート方式を採用しなければならないということになります。先述したRTPは、リアルタイムのビデオ・ストリーミング機能を実装する上で重要な柱になります。RTPに対応するシステムは、主にUDPのトランスポート仕様と組み合わせて設計され、IPベースのネットワーク上で動作します。

TCP/IPのスタックに基づくコネクション指向の設計と比べると、コネクションレス型のビデオ・ストリーミングでは、リソースの消費量をはるかに少なく抑えつつ、より高い性能を実現できます。車載分野や産業分野で用いられるビデオ・ストリーミングは、主にビデオ・ソースへの直接的なハードウェア(HW)接続を備える複数の組み込みシステムの間で実行されます。そのような場合、様々なHWソリューションを活用すれば、より大きな改善が得られるはずです。例えば、データ・センターで使われているような性能の高いCPUサブシステムを使用すれば、一般的なビデオ・ストリーミング用のパイプラインにおける性能のギャップを解消できます。ただ、そうしたコンピューティング・デバイスは高価であることに加え、システムへの統合方法が複雑です。そのため、組み込みSoCの環境には適していません。その種の環境では、エネルギー効率と性能の両面で最適化されたコンポーネントが求められるからです。また、GPU(Graphics Processing Unit)デバイスは、非常に高い並列処理能力を備えているのでハイ・パフォーマンス・コンピューティング(HPC)の代替手段になります。但し、GPUデバイスを使用する場合、HWのレベルの柔軟性は低くなります。

上記の内容に基づくと、高性能のネットワーク・システムやリアルタイム対応のビデオ・ストリーミング・システムでは、高度な再構成が可能なFPGAが重要な要素になると考えられます。昨今の組み込みSoCの中には、エッジ・コンピューティングの性能を最大限に高めるために、1つのチップ上にCPUサブシステム、FPGAのリソース、RAMを集積しているものがあります。そのようなデバイスであれば、リアルタイム対応のビデオ・ストリーミング・システムでコンピューティングに使用するものとして最適な選択肢になります。実際、ビデオ・データの受信、受信したピクセル・データとネットワーク・パケットの間の変換、ビデオ・ストリーミングの各処理を、CPUの利用を最小限に抑えた状態で実行できます。また、CPUはプロトコル・フィールドの設定に用いられます。それにより、使用するカメラ・モジュールが1台であるか複数台であるかにかかわらず、レイテンシとデータ・レートについて、達成し得る最大限の性能が得られます。このようにして、ビデオ・データからネットワーク・パケットへの変換とコネクションレス型のビデオ・ストリーミングの全体を実現することが可能になります。最大限の伝送性能を引き出しつつ、FPGAのリソースの消費量を許容可能な範囲内に収めるために、この例のネットワーク・スタックでは、RFCに完全に対応するアプリケーション層のプロトコルを使用します。アーキテクチャについては、トランスポート層、ネットワーク層、データ・リンク層の仕様に対応しつつ、ソフトウェア(SW)によって制御する部分を最小限に抑えるように設計します。従来の手法では、IPベースのルーティングの本格的な実装が必要でした。これについては、IPアドレスを割り当てるためのフィールド設定という簡略化されたマニュアル作業に置き換えられます。

ビデオからネットワーク・ドメインへの変換

先述したとおり、GMSLでは、まず複数のカメラ・モジュールから送られてきたビデオ・データをシリアライズします。その上で、連結されたストリームをCSI-2のような標準化された実装を介して組み込みSoCに出力します。その際、連結の処理は、GMSLに対応するSERDESから利用可能なストレージ機能を使用し、仮想チャンネルのインターリーブ・メカニズムを活用することで実行されます。ここでは、高性能でレイテンシの小さい非圧縮ビデオ・ラインからIPベースのネットワーク・パケットへの変換方法について説明します。本稿の例では、標準化されたRTPベースのビデオ・ストリーミング用のスタックを選択しました。なぜなら、ヘッダの設計に伴う負担を最小限に抑えられることに加え、UDPを用いたコネクションレス型のトランスポート層を利用できるからです。このようなアプローチにより、ビデオ・ストリーミング用のスタックは、RTP(RFC)に完全に準拠する受信側の様々なSW実装/HW実装との互換性を得ることができます。

非圧縮ビデオ用のRTPの仕様に、部分ラインのアーキテクチャが含まれていたとします。その場合も、フラグメンテーションのない設計がHW実装に対する最良のアプローチになります。フラグメンテーションを回避することで、リソースの消費量を大幅に削減できます。また消費電力も最小限に抑えられます。

先述したように、ビデオからネットワーク・ドメインへの変換は複数種のコンピューティング・デバイスによって実現できます。また、データの伝送は複数の異なる方法で実施可能です。図3、図4に、CPU/GPU/FPGAをベースとする組み込みシステムの構成例を示しました。一方、図5は本稿で取り上げているようにFPGAだけを活用する例です。図5の構成では、ビデオ・ストリーミング用のスタックのアーキテクチャを使用し、メモリ・ベースのデータ伝送を実行します。

図3の構成は、従来のHW/SWの協調設計に基づいてビデオ・ストリーミング関連のネットワーク・スタックを実装する場合に選択可能です。この図において、左側にあるビデオ・レシーバーのサブシステムは、DMA(Direct Memory Access)コントローラを使用してビデオ・ラインを組み込みシステムのRAMに送信します。その後、ビデオ・データはRAMから読み出されて、イーサネットのMAC(Media Access Control)層に送信されます。その際には、次のネットワーク・スタックの設計メカニズムのうち、どちらかが用いられます。1つはDPDK(Data Plane Development Kit)7です。もう1つは、Linuxカーネルのネットワーキング8に依存する従来型の実装です。最後に、イーサネットのMAC層は、接続されているイーサネットの物理(PHY)層にネットワーク・パケットを転送します。

図3. 従来型のメモリ・ベースのビデオ・ストリーミング
図3. 従来型のメモリ・ベースのビデオ・ストリーミング

図4は、RDMA(Remote Direct Memory Access)をベースとする伝送システムの実装方法を示したものです。この場合、送信側と受信側の両方に特定のRDMAに対応するNIC(Network interface Card)が必要になります。また、基盤になるレイヤ2はイーサネットの規格に基づいて実装します。この例は、RoCE(RDMA over Converged Ethernet)9による伝送を実現する方法の概要を表しています。

図4. RDMAベースのビデオ・ストリーミング
図4. RDMAベースのビデオ・ストリーミング

図5は、本稿で紹介しているアプローチの概要を示したものです。FPGAによって、ビデオ・ラインからRTPパケットへ変換する部分が最も重要な要素になります。また、コネクションレス型のネットワーク・スタックのモジュールも示してあります。

図5. FPGAを活用するビデオ・ストリーミング・エンジン
図5. FPGAを活用するビデオ・ストリーミング・エンジン

図6は、CSI-2のビデオ・データを完全なRTPパケットに変換する方法を表したものです。この変換方法を効率的に設計するために、1本のビデオ・ラインを1つのRTPパケットに対応づけることにしました。リソースの消費量とイーサネット規格への対応という観点からは、この方法が最良のソリューションになります。一般的なイーサネットのフレームは、規定された最大伝送単位(MTU:Maximum Transmission Unit)に基づいています。MTUは、プロダクション環境用のNICで用いられる測定単位です。通常のフレームの値は1500バイト、ジャンボ・フレームの値は9000バイトになります。実験的な用途に向けた理論上の最大値は65536バイト(スーパー・ジャンボ・フレーム)です。ビデオ・ラインの容量は数千バイトなので、大半のレシーバーにおけるNICの設計に対応できるように、本稿の例では1ビデオ・ラインをベースとするアーキテクチャを選択しました。先述したように、SWだけによって、またはHW/SWの協調設計によってビデオ・データからRTPパケットへの変換を行う場合、ビデオとネットワークの両方のSWサブシステムでメモリの読み出し/書き込み処理を複数回実行する必要があります。そうすると、複雑さが増すと共に、レイテンシが大きくなって性能が低下します。本稿で例にとった完全にHWに依存するアプローチでは、単一のストレージ・メカニズムを使用して各ビデオ・ラインの転送を実行します。そのため、実装の複雑さを最小限に抑えられます。また、フラグメンテーションの生じていないパケットがケーブルを介して送信されることが保証されます。但し、この極度に簡略化されたメカニズムは、仮想チャンネルの機能を使用して時分割されたビデオ・ストリームの1つのグループに含まれるデータを変換する場合に対してだけ有効です。時分割のビデオ・ストリームから成る複数の並列グループを使用する場合、この伝送階層に新たなストレージ・レベルを追加します。そのようにして、ネットワークのサブシステムに対する時分割での伝送を実現するための仕組みを構築しなければなりません。

図6. ビデオのピクセル(1ビデオ・ライン)からRTPパケットへの変換
図6. ビデオのピクセル(1ビデオ・ライン)からRTPパケットへの変換

図6に示したように、変換フローは次の2つのステップから成ります。ステップ(1)では、CSI-2レシーバーの実装からデータを取得し、AXISに対応する1つのビデオ・ラインをベースとするパケットを作成します。ステップ(2)では、プロトコルのヘッダをビデオ・ラインに付加してRTPパケットを生成します。

GMSLから10GbEへの変換に対応するエッジ・コンピューティング用のプラットフォーム

ここまで、FPGAだけを活用するRTP対応のビデオ・ストリーミング・システムについて解説してきました。その設計の長所を生かすために、アナログ・デバイセズはエッジ・コンピューティング用のプラットフォームを開発しました。それがADRD8012-01Zです。このプラットフォームは、コスト効率の高いAMDの「K26 SOM」をベースとして構築されています。その役割は、GMSLに対応する複数の高性能カメラと10 gigabit Ethernet(10GbE)の間をつなぐ変換処理を実行することです。HW構成としては、クワッド型のGMSLデシリアライザ「MAX96724」を2つ搭載しています。それにより、最大8台のカメラを対象とした並列ビデオ・ストリーミングに対応できます。それらのカメラは、デシリアライザの前段に配置された4つの仮想チャンネル(VC:VC0~VC3)から成る2つのブロックとして扱われます。図7は、ビデオ・ストリーミング用のシステム全体を示したものです。ネットワーク側には、10GbEをベースとする伝送に使用可能なSFP+(Small Form-factor Pluggable Plus)対応のケージを採用しています。このビデオ・ストリーミング用の実装を使用し、カメラ・モジュールのテストを実施しました。テストの対象としたモジュールは、ティアフォーの車載グレード品である「C1/C2」(120dBの高いダイナミック・レンジと2.5MP/5.4MPの解像度を実現)と、Intelの「RealSense D457」です。これらのモジュールは、それぞれに対応するイメージ・センサーに接続されたISP(Image Sensor Processor)を内蔵しています。例えば、YUV422の仕様に基づくフルカラーの画像の送信が可能です。先述したとおり、ビデオ・ストリーミングでは、アプリケーション層の仕様がフレーム構造の基盤になります。非圧縮ビデオの伝送では、RTPペイロード・ヘッダ6が各ペイロードのフィールドの長さを定義します。また、各ペイロードのフィールドは、実際のライン長、ライン番号、本稿のアプローチでは考慮していないその他のフラグメンテーション関連の要素を表します。一方、汎用的なRTPヘッダ4には、ビデオ・タイプとマーカー識別子が含まれます。マーカー識別子は、ビデオ・フレームの最後のバイトを表すものです。これは、Arm® eXtensible Interface Streaming(AXIS)のTVALID/TLASTのロジックと完全に一致します。

図7. RTP対応のビデオ・ストリーミング・システム。ADRD8012-01Zを使用して構築しました。
図7. RTP対応のビデオ・ストリーミング・システム。ADRD8012-01Zを使用して構築しました。

まとめ

高速なGMSLを活用するローカルなビデオ伝送システムは、ビデオ・ストリーミング用の高性能のインフラに効率的に拡張することができます。その際には、データ・レート性能を維持しつつ、より小さなレイテンシを実現することが可能です。そのような堅牢性が高く効率的なアーキテクチャを実現するためのものとして、本稿ではFPGA SoC製品を使用する例を示しました。選択した製品は、CPUとFPGAのリソースの両方を搭載しています。そのような構成においてソフトウェアとハードウェアの両方の機能を組み合わせることにより、複数のカメラを対象とする優れたリアルタイム対応のビデオ・ストリーミング・エンジンを構築することが可能になります。

参考資料

1Jobs of Tomorrow: Technology and the Future of the World's Largest Workforces(明日の働き方:技術と世界最大の労働力の未来)」World Economic Forum(世界経済フォーラム)、2025年10月

2Autonomous Vehicles: Timeline and Roadmap Ahead(自動運転車 - 今後のタイムラインとロードマップ)」World Economic Forum(世界経済フォーラム)、2025年4月

3MIPI CSI-2 Specification(MIPI CSI-2仕様)、MIPI Alliance(MIPIアライアンス)

4Henning Schulzrinne、Stephen Casner、Ron Frederick、Van Jacobson「RTP: A Transport Protocol for Real Time Applications(RTP - リアルタイム・アプリケーションのためのトランスポート・プロトコル)」The Internet Society、2003年7月

5Jon Poste「l User Datagram Protocol(ユーザ・データグラム・プロトコル)」Information Sciences Institute(情報科学研究所)、1980年8月

6Ladan Gharai and Charles Perkins「RTP Payload Format for Uncompressed Video(非圧縮ビデオ用のRTPペイロードのフォーマット)」The Internet Society、2005年9月

7DPDK Landing Page(DPDKのランディング・ページ)、DPDK

8Linux Kernel Networking Documentation(Linuxカーネルのネットワーキングに関するドキュメント)」The Kernel Development Community

9RDMA over Converged Ethernet(RoCE)」Wikipedia.org

著者について

Alin-Tudor Sferle
Alin-Tudor Sferleは、アナログ・デバイセズのソフトウェア・システム設計エンジニアリング担当シニア・エンジニアです。2021年2月に入社しました。ソフトウェア/セキュリティ・グループに所属。ビジョン分野やネットワーク分野を対象とし、FPGAベースのソリューションにおけるハードウェア/ソフトウェアの協調設計に取り組んでいます。クルジュ・ナポカ工科大学で2022年に電気通信に関する学士号、2024年に修士号を取得しました。
Andrei Cozma
Andrei Cozmaは、アナログ・デバイセズの組み込みシステム・アーキテクト担当シニア・ディレクタです。システム・レベルのソリューションの設計/開発をサポートしています。産業用オートメーション、ソフトウェア無線、ロボット、オートモーティブなど、様々な分野の設計/開発プロジェクトに携わってきました。産業用オートメーションと情報科学に関する学士号に加え、電気工学の博士号を取得しています。
myAnalogに追加

myAnalog のリソース セクション、既存のプロジェクト、または新しいプロジェクトに記事を追加します。

新規プロジェクトを作成

この記事に関して

産業向けソリューション
技術ソリューション
製品カテゴリ
最新メディア 25
Title
Subtitle
さらに詳しく
myAnalogに追加

myAnalog のリソース セクション、既存のプロジェクト、または新しいプロジェクトに記事を追加します。

新規プロジェクトを作成