【ITニュース解説】My video capture test needed a pixel reference beyond currentTime

動画の再生やキャプチャ機能を開発する際、その動作が正確であることを確認するためのテストは非常に重要だ。しかし、一見すると正確に見えるテストでも、実は肝心な部分を見落としていることがある。この記事は、そんな動画キャプチャテストの落とし穴と、それをどう克服するかについて詳しく解説している。

動画を再生したり、特定の一点の画像をキャプチャしたりするとき、私たちは「今、何秒の映像が表示されているか」という情報に頼ることが多い。これは、多くのプログラミング環境で提供されているcurrentTimeという値だ。例えば、「2.117秒の時点のフレームを表示してほしい」とリクエストし、システムが「今表示しているのは2.117秒のフレームです」と返してきたら、一見するとテストは成功したように思えるだろう。しかし、この記事の筆者は、この方法では本当に正しいフレームが表示されているかを確認できないと指摘する。

筆者が直面した具体的な問題は、Firefoxを使ったテストで明らかになった。2.117秒の地点へのシーク（動画の再生位置を特定の位置にジャンプさせる操作）をリクエストし、シーク完了時のコールバック（イベント発生時にシステムから返される情報）を見ると、mediaTimeも2.117秒と報告されていた。数値上は完璧に一致しているように見える。しかし、実際にキャンバス（画像を実際に描画する領域）に表示されていたのは、フレーム番号63の画像だった。このフレームは、動画が30フレーム/秒（fps）で作成されている場合、2.100秒（63フレーム ÷ 30fps）から始まるフレームだ。つまり、リクエストした時間（2.117秒）と、システムが返してきた時間（2.117秒）は一致していたが、実際に表示されている画像は、それよりも17ミリ秒前の時間（2.100秒）に属するフレームだったのだ。このことから、単に二つの時間の値が一致しているだけでは、実際に表示されているフレームが正しいかどうかを独立して確認したことにはならないと筆者は結論付けた。

この問題を解決するため、筆者は画期的な方法を考案した。それは、動画のピクセルデータ自体にフレーム番号を埋め込むというものだ。通常の動画では、フレーム番号などの情報は内部的なメタデータとして扱われるが、筆者は640x360ピクセルのH.264形式の動画を特別に生成し、そのピクセル（画面を構成する最小単位の点）の色情報の中に、各フレームの通し番号を直接エンコードしたのだ。この動画は30fpsで180フレームあり、画像の圧縮効率を高めるための「Bフレーム」は含まれていない。また、圧縮方法の異なる複数のバージョン（GOP長が15、60、180フレーム）も用意された。GOPとはGroup of Picturesの略で、動画の圧縮単位のことで、これが長いほど圧縮効率が高まるが、特定のフレームにシークする際の処理が複雑になることがある。

この特別な動画を使って、筆者は新たなテスト方法を確立した。動画の特定のフレームをキャンバスに描画した後、テストプログラムはキャンバス上のピクセル値を読み取り、そこに埋め込まれたバイナリ形式のフレーム番号を直接デコードしたのだ。これにより、プログラムはcurrentTimeという時間情報に頼ることなく、また、画面に表示された数字を画像認識（OCR）で読み取るような不確実な方法を使うこともなく、本当に表示されているフレームが何番であるかを独立して確認できるようになった。

筆者はこの新しいテスト方法を用いて、Chromium、Firefox、WebKitといった主要なブラウザ環境で合計108回のシーク操作をテストした。それぞれのGOPバージョンの動画に対し、12種類のターゲット時間へのシークを試みた。その結果、2.117秒をターゲットにしたシーク操作では、どのGOPバージョンの動画でも一貫してフレーム63が描画された。前述の通り、フレーム63は2.100秒に始まり、次のフレームは2.133秒に始まる。この結果は、「リクエストされた時間がフレームの正確な開始時刻と一致しなくても、そのフレームの表示期間内にあるならば、それは正しいフレームである」ということを示している。つまり、2.117秒はフレーム63（2.100秒から2.133秒の期間）の表示区間内に収まっているため、フレーム63が表示されるのは妥当な結果だと言える。

この発見は、以前のFirefoxでの観測結果に対する筆者の解釈を変えた。当初、Firefoxがリクエスト時間とコールバック時間を一致させながら、実際には17ミリ秒前のフレームを表示したことを「問題」だと捉えかけたが、新しい視点で見ると、それは必ずしも間違った挙動ではなかったのだ。2.117秒という時間はフレーム63の表示期間内にあるため、フレーム63を返したこと自体は正しかった。ただし、この事実は、「コールバックのmediaTimeだけでは、実際に表示されているフレームが何であるかを独立して判断するための十分な情報にはならない」という教訓を残した。厳密に時間の一致だけを求めるようなテストでは、このように妥当な結果を誤って不合格にしてしまう可能性があると筆者は指摘する。

また、このテストを通じて、筆者は別の一般的な間違いも発見した。それは、動画の再生時間を変更するcurrentTimeプロパティを設定した直後に、すぐに描画（キャプチャ）を試みると、多くの場合（108回の操作中99回）、新しいフレームではなく、以前に表示されていた古いフレームが返されてしまうというものだ。これは、新しい時間が設定されても、システムが実際にその時間のフレームを準備して描画するまでには少し時間がかかることを示している。そのため、単にcurrentTimeを設定し、キャンバスが空でないことを確認するだけでは不十分で、要求されたフレーム区間に合致するピクセルが描画されていることを、古いフレームと区別して確認する必要があることがわかった。

筆者は、このような動画キャプチャの精度に関する厳密なテストとは別に、実際の製品での動作確認も行った。ImgIngという製品のベータ版の動画マット加工機能を使って、特定の動画を2.117秒にシークし、プレビューを確認した。この確認は、製品が特定の時間で問題なく処理を実行できるかを見るためのものであり、その処理結果の厳密な時間精度を検証する目的ではなかった。このように、テストの目的を明確に切り分けることの重要性も示されている。

今後の動画キャプチャテストの方針として、筆者は以下を推奨している。まず、テストを書く前に「期待されるフレームの表示区間」を明確に定義すること。そして、リクエストした時間、システムから返されるコールバックメタデータ、そしてピクセル解析によって独立して観測されたフレーム番号の三つを、それぞれ別の情報として記録・比較すること。ピクセルに番号を埋め込んだ特殊な動画は、このように制御された環境下での実装の検証には非常に有効だ。しかし、実際の映像を使ったテストでは、その映像がどのような経路で入力され、処理されるかという実際の入力パス全体を通じて検証する必要がある。結局のところ、本当に価値のある保証とは、単に二つの数値が偶然一致するのではなく、独立した参照に基づいて結果が確認され、その検証範囲が明確にされていることなのだ。

この一連の解説を通じて、動画キャプチャの正確なテストがいかに複雑であり、表面的な数値の一致だけでは不十分であるかが理解できただろう。システムエンジニアとして、単に機能が動くことを確認するだけでなく、その「正確さ」や「信頼性」を保証するためには、今回のような深い検証と、独立した参照による確認が不可欠であるという重要な教訓を示している。