前回の取り組みでは、Raspberry Pi Zero 2W と AI Camera（Sony IMX500 搭載）を使用し、libcamera を使った CPU（ソフトウェア）エンコードと GPU（ハードウェア）エンコードの比較検証を行いました。消費電力の測定を含めて各種パラメータを確認した結果、ハードウェアエンコードを活用することでエンコード負荷を大幅に低減できることが分かりました。

前回記事：その3
https://techietechnology.co.jp/2025/03/11/make-aicamera-03/

今回は、実際のアプリケーションで検証を行う前段階として、少し寄り道ではあるのですが映像遅延についてさらに詳細なテストを実施してみました。カメラシステム全体を試用した際に、ロースペックな割には体感的にはかなり低遅延で映像が表示されているという印象を受けたからです。

この優れた応答性は、AI Camera 内部に搭載されているハードウェア処理機能や、Raspberry Pi 上での映像デコードが GPU アクセラレーションを用いて最適化されていることに起因すると考えています。

実際にどの程度の遅延が発生しているのかを定量的に把握することが重要です。そこで、今回は特殊な遅延測定装置を用いた本格的な検証に取り組みました。この装置では、LED の点滅タイミングと、その点滅を検知するセンサーとの間で生じる時間差を計測する仕組みになっています。数値カウントによるおおまかな計測よりも、はるかに高精度に遅延を測定できるのが特長です。実用的な観点からネットワーク経由で遅延を測定します。

—————————-
●送信：Raspberry Pi Zero 2WとAI Camera
↓
ローカルネットワーク経由
↓
●受信：Windows側モニター
—————————-

Raspberry Pi Zero 2W と AI Camera にてlibcameraでハードウェアエンコードを実施します。有線 LAN（Ethernet）接続を用い、極力ネットワーク遅延を最小にする環境で測定しています。

Windows PC で受信した映像をモニターに表示し、映像が実際に表示されるタイミングを先述した遅延測定装置で計測しています。

①解像度：800×600 ピクセル

計測結果は約 150ms 〜 180ms（0.15〜0.18 秒）でした。
低解像度ながら 60fps 程度で動作可能な環境で、安定して 0.2 秒未満の遅延を実現しているのは非常に優秀な結果といえます。

②解像度：1600×1200 ピクセル

解像度を縦横それぞれ倍にしてテストしたところ、約 300ms（0.3 秒）程度の遅延が測定されました。解像度を大きくすると、どうしても映像データ量が増えるため、エンコードや転送、デコードに掛かる負荷も上昇します。その結果として、遅延が大きくなっていると推測できます。

③解像度：1920×1080 ピクセル（FHD）

フル HD（FHD）まで解像度を上げると、300ms を少し下回る値が確認できました。つまり 0.3 秒弱という非常に短い遅延で映像が表示されることが分かりました。ハードウェアエンコード・デコードの上限近い解像度であっても、約0.3 秒未満というのは想像以上に低遅延といえるでしょう。

今回のテスト環境では、有線 LAN を使用しているため通信の安定度が非常に高く、最低限の遅延で運用できていると考えられます。しかし、実際の運用ではさまざまな要因で遅延が増加することを想定する必要があります。例えばVPN 越しに映像を受信したり、無線 LAN（Wi-Fi）で運用したり、ネットワークが混雑している環境で使用するなどです。

このような状況を考慮すると、テストで得られた遅延値に対して約 20%程度の余裕を見込んで考えるとよいかもしれません。

AIカメラの検出結果を何らかのトリガーとして、1 秒以内にリアルタイム映像を確認したいといった要件にも十分対応可能な範囲といえます。特に 800×600 ピクセルであれば 0.2 秒程度、フル HD でも 0.3 秒前後で表示されるため、運用上はかなり高速かつ快適に映像監視ができるはずです。

さらに遅延を細かく検証するために、まずはネットワークを介さずに HDMI 出力による直接モニター表示でどの程度の遅延が発生するかを調べてみました。具体的には、Raspberry Pi Zero 2W と AI Camera の組み合わせで生成した映像を HDMI 接続のディスプレイに直接表示し、その応答時間を計測しています。

ハードウェアチップが最適かしているためか規格的に処理しやすいのか解像度1920×1080ピクセルがとても良い結果でした。

①解像度：800×600 ピクセル（HDMI直測定）約80ms

②解像度：1600×1200 ピクセル（HDMI直測定）約180ms

③解像度：1920×1080 ピクセル（HDMI直測定）約100ms

この計測結果から、ネットワーク経由で映像を送受信した場合には、少なくともおよそ 100 ms 前後の追加遅延が上乗せされていることが推測できます。これは、エンコードやデコード処理、そしてネットワーク転送の負荷によるものと考えられます。

続いて、今度は受信側を含めて無線ネットワーク（Wi-Fi）での遅延テストを実施することにしました。具体的には下記のような構成で行います。

—————————-
●送信：Raspberry Pi Zero 2WとAI Camera
↓
無線ネットワーク経由
↓
●受信：Windows側モニター
—————————-

テストを行いやすくするために、操作確認やモニター表示が一目で分かる専用インターフェース画面を用意しました。SSH 接続からも同じインターフェースを利用できるので、リモート操作が必要な状況でも非常に便利です。

このアプリケーションは、TUI (Text-based User Interface) を介してストリーミングに関連する各種パラメータを柔軟に変更可能な点が大きな特長となっています。具体的には、rpicam-vid や GStreamer、そして FEC (Forward Error Correction) の仕組みを組み合わせることで、ネットワーク環境の変化にも適応しつつ、最適な映像伝送を実現します。さらに、カメラ側で実行される AI モデル (MobilenetSSD や PoseNet など) を手軽に切り替えられる設計となっており、物体検出や姿勢推定といった機能を状況に応じて有効活用できる柔軟性を備えています。

解像度を 800×600 ピクセルに設定し、無線環境で映像を送信した結果、約 250 ms の遅延が確認されました。

結果はこちらです。250msの遅延結果でした。

なお、今回のテストでは FCEで 20% 程度のバッファを設け、パケットロスや無線環境特有の揺らぎを吸収しやすいように設定しています。その結果、無線下でも比較的安定して映像を受信・表示できるようになりました。

簡易的なテストではありましたが、遅延測定とあわせて仮アプリケーションを用いた Wi-Fi 無線環境での動作検証も行うことができました。結果として、無線環境下でも映像の送受信が安定して行えることを確認できたため、基本的な動作要件をほぼ満たしていると言えるでしょう。今後は、さらなる拡張機能の追加や異なるネットワーク環境でのテストを通じて、より実運用に近い場面での信頼性とパフォーマンスを検証していきたいと思います。

つづく。