intdashとオリジナル治具を使って動画エンコード遅延測定をしてみた

はじめに

動画ストリーミングサービスにおいて、動画の遅延を測定したいというニーズは多いと思います。

動画が遅れる要因として以下３つが主に考えられると思います。

• ネットワークの遅延
• アプリケーションで行う処理による遅延
• 動画エンコード遅延
• 動画デコード遅延

これらをすべて含んだ遅延の測定は比較的簡単に計測可能ですが、要因を切り分けて測定するのは工夫が必要かと思います。

今回、弊社製品 intdashの特徴である、複数のデータソースでタイムスタンプ管理ができることと、オリジナル治具を利用して、この動画エンコード遅延の測定をしてみた話をしたいと思います。

ハードウェアチームの塩出が担当します。

本題に入る前に、弊社製品の説明

弊社製品 intdashを使用すると、映像やCAN、アナログデータ等、異なるデータソースでもタイムスタンプを一元管理することができ、webアプリケーションの Visual M2M Data Visualizer(以下Visualizerと呼ぶ）を使って取得したデータを、そのタイムスタンプを元に再生することが出来ます。

具体的には、車が発しているCANのデータと、ドライバを撮影した映像を同期させて取ることができ、それをwebアプリケーションで確認出来ます。この仕組みを使うと例えば、車が発しているハンドル角度に相当するCANデータと、その時ドライバが操作しているハンドルの角度が一致してる状態で確認できるということになります。

もちろん、そのままではエンコードの遅延が乗ってしまうので、お客様へ提供する製品ではこのエンコード遅延分は事前に測定して補正するようにしております。

intdashを使ったエンコード遅延測定の考え方

intdashでの打刻タイミングは、CANのデータはCANデータを受け取った時、動画はエンコードされたデータを受け取ったときとなっています。なので、もしCANと被写体が同じデータを発するものだとすれば、Visualizerを使って確認すると理想的には、ある時間における動画データとCANのデータは同一のものになっているはずです。仮にこれが異なるとすると、その時間分がエンコードの遅延ということになります。図にすると以下の様になります。

測定するエンコード時間の説明図

測定するための治具

CANと被写体が同じデータを発するものというと、身近なもので言えば車のステアリングが相当するのですが、手軽にデータが取得出来ないのと、ステアリングがどれくらい回転しているかを動画で把握するのは目分量になってしまうので測定向きではありません。そこで、今回は Terasic社製のFPGA評価ボードDE10-Liteを使用して測定のための治具を作ってみました。

動画エンコード遅延測定治具

特徴

DE10-Liteは、7segディスプレイが付いた評価ボードで、CANの出力部分に関しては自作しました。簡単に特徴をまとめると以下のようになります。

• 7segディスプレイは1msec毎に更新
• 7segディスプレイと同タイミング(約20usec差)で同じ内容のCANを出力（以下の図を参照ください）
• 右下のLEDは1msec単位のインジケータ
• 7segディスプレイはダイナミック点灯ではないので、クリアに撮影可能
• Visualizerで確認した時、同一時刻における映像の7segディスプレイが示している値と、CANが示している値の差がエンコード時間となる

CANと7segの更新タイミング

intdashと治具を使った動画エンコード遅延測定

上記治具とintdashを組み合わせて動画エンコード遅延を測定した結果を以下の図に示します。この図は撮影済みのデータをVisualizerで再生したときの様子です。

図の黄色の枠で示したものがCANのデータで、965.294秒を示しています。図の青色の枠で示したものが動画データで、965.193秒を示しています。この差分が動画エンコード遅延を示すので、約100msecの遅延だということがわかります。 なお、この遅延は事前に測定しており、お客様へ提供する際はその分補正しております。

Visualizerで確認できる遅延量の例

治具についての余談(FPGA内のことについて）

今回、ソフトコアである NiosII を使用して、7segディスプレイの更新タイミングと、CANの出力のタイミングを制御しました。NiosIIのプログラムは結局ベアメタルで実装してしまいましたが、FreeRTOSバージョンでも実装は試しました。

今回使用したQuartusのバージョンは18.1だったのですが、このバージョンだとFreeRTOSのコンテキストスイッチがうまく働かず、そのままでは正常に動作しませんでした。なので、正常に動作するように変更し、FreeRTOSのgithubの方にプルリクエストは出したのですが、コロナの影響で現物確認ができないと言われ、ペンディングになっています。それでもよろしければ活用してフィードバッグをいただけると嬉しいです。

FreeRTOSでの実装

上記プルリクエストでFreeRTOSが使えるようになったので、FreeRTOSでも実装してみました。実装は1msecごとにqueueを出力するタスクと、そのqueueを受け取ってCANを出力するタスク、7segを更新するタスクという構成で行いました。その場合、CANと7segの時間差は200 usecと10倍くらい精度が落ちてしまいました。本来はここからチューニングしてパフォーマンスを出す作業を行うのですが、今回はFreeRTOSを入れること自体に時間がかかってしまったのと、ベアメタルでも事足りていたので、特にチューニングせずにベアメタルを採用することにしました。

今回は残念ながらFreeRTOSは不採用でしたが、FreeRTOSのコンテキストスイッチ回りの実装をちゃんと追ったので今後に活かしていきたいと思います。

おわりに

今回はintdashとオリジナル治具を使って、動画エンコード遅延測定をしてみた話を紹介しました。CANと7segを組み合わせるというあまり見ない構成な気がしますが、デジタルっぽく測定できるので個人的には気に入っています。7segの映像を画像処理して、数値をデジタル化できれば完全にデジタル化できるのでテストツールとしては完成かなと思っております。そこはこれから挑戦していきます。

余談ですが、自分的に一番伝えたかったのはNiosII上でFreeRTOSを動かすことだったりします。バグ報告はあるのですが、解決まで行っておらず苦労したので、この記事が NiosII上でFreeRTOSを動かす上で役に立てれば幸いです。