デコード済みなのに動画が黒い

ゲームの末尾動画へ入ると、映像も音も出ないまま画面が黒くなった。見た目だけなら、動画を映像へ戻す処理が失敗したように見える。

しかし、動画が画面へ出るまでには複数の段階がある。黒画面だけを見ても、どこまで処理が進み、どこで止まったかは分からない。

対象はArtemisエンジンの64bitタイトルで、iarsys保護レイヤーを持つ。この事例では、表示側に届く直前の受け渡しを調査した。

最初の仮説を設定だけで試さず、診断トレースから「処理が到達した最も遠い地点」を確認した。

通常のログには黒画面の理由が出ていなかった。そこで表示処理の終点ではなく、作られた映像を表示側が受け取る瞬間へ計測を入れた。

計測すると、圧縮されていない映像が「圧縮済み」と誤判定され、39個の候補がすべて拒否されていた。これにより、調査対象を表示処理から「表示用の形式と説明情報を作った側」へ移せた。

表示側へ渡すのは映像だけではない。「1280 × 720の大きさである」「圧縮されていない」といった、映像を正しく扱うための説明情報も必要になる。

今回は画素形式の名前だけがあり、画面サイズと非圧縮性を示す情報が欠けていた。拒否したのは表示側だが、直すべきなのは不完全な説明情報を作った変換側だった。

ここからが解決の段階である。変換側へ画面サイズと非圧縮性を補ったビルドに替え、黒画面だった末尾動画をもう一度再生した。

直したのは表示側の判定ではない。変換側が完全な説明情報を渡すようにし、画面サイズを入力から引き継ぎ、固定サイズかつ非圧縮の映像であることを明示した。その結果、39個の候補を拒否していた接続が成立し、ゲーム上でも末尾動画が映った。

今回の価値はEVR固有の属性名ではなく、理由の出ない拒否を、データが通過した地点と境界の判定から切り分けたことにある。

1. 到達済みの地点を証拠で決める画面や音の有無だけで処理段階を推測せず、生成済みデータやログから確認する。
2. 最初に拒否される境界を計測する終点の一般ログに理由が無ければ、入力を受理する判定へ観測点を置く。
3. 拒否条件を作った生成側へ遡る受信側の制約を緩める前に、渡されたデータが契約を満たしているか確認する。
4. 内部値と利用者が見る結果を両方確かめる判定値の反転に加え、実際の再生と後続処理まで受け入れ条件にする。