受信側のモニターに、黒い四角が8枚並んでいた。送信側の機器は、どれもリンクランプが点灯している。配線もIPアドレスも合っている。それなのに画が出ない。ストップウォッチで測ると、最初の1枚が映るまで0.4秒、最後の1枚が映るまで1.9秒かかった。
故障ではない。受信側は、映像を読み始められる地点が流れてくるのを、ただ待っていただけだ。
数字で見てみよう。H.264やH.265の映像は、毎フレームを丸ごと送らない。基準になるフレームを1枚送り、続くフレームは「直前との違い」だけを送る。この基準フレームのうち、後ろのフレームがさかのぼらなくてよいと保証されたものを、IDRと呼ぶ。受信側は途中から参加すると、次のIDRが来るまで、画を組み立てられない。
IDRの間隔をT秒とする。参加のタイミングが、送信側の周期と無関係なら、待ち時間は平均で T÷2、最大で T になる。YouTube Liveはキーフレーム間隔の推奨を2秒、上限を4秒としている（YouTubeヘルプ）。NDIのH.264対応の資料は、Iフレーム間隔を1〜2秒としている。Tが2秒なら、平均1.0秒、最大2.0秒だ。
送信元が8台あり、それぞれの周期がそろっていなければ、全部の画が出るまでの期待値は 2×8÷9＝約1.78秒になる。8枚が1秒以内にそろう確率は、0.5の8乗＝0.39％でしかない。
連続ドラマを、第5話の途中から見はじめた場面を思い浮かべてほしい。登場人物の関係が分からず、筋が追えない。分かるようになるのは、次の回の頭で「前回までのあらすじ」が流れたときだ。途中のフレームは「前回との違い」を書いたメモにすぎず、あらすじは付いていない。受信側は怠けているのではない。あらすじのない回では、読みようがないのだ。待たされるのは、送り手が決めた「あらすじの間隔」の中のどこかに、たまたま飛び込んだからである。
だから、悪いのは受信機でも回線でもない。この間隔を初期値のまま使っている現場では、どのくらい待たされるのかを、誰も数字にしていない。
方法はある。許容できる最悪の待ちを先に決め、そこからIDRの間隔を逆算する。そのうえで、実測して、設定の影響と機器の準備時間を切り分ける。手順は6つで足りる。
この記事の有料部で手に入るのは、次の4点だ。
- 待ち時間を4つの段階に切り分けた診断表
- 許容する最悪の待ちから、エンコーダーに入れるフレーム数を割り出す換算表（日本の59.94系と、欧州の50Hz系）
- 受信開始の待ちを30回測り、設定の影響と機器の準備時間を分ける実測手順
- 本番中に待たせないための、受信の常時接続の設計
この換算を知らないまま運用すると、受信を足すたびに、最大でTの黒い画を「仕様」として受け入れ続けることになる。Tが上限の4秒なら、平均2.0秒、最大4.0秒だ。次の現場で、その4秒を自分で決められるようにする手順が、このあとにある。
コメント