パケットロス対策とFEC設計の実践ガイド
試合の第2クォーター、SRTで4Mbpsの回線を使って本線を送出していた最中に、画面の右下が四角いブロック状に崩れた。数秒後、選手の動きがぴたりと止まった。回線の速度計測ツールは正常な数値を示し続けている。試合終了後、配信サーバーのログを1行ずつ照合してようやく分かった。速度は足りていた。足りていなかったのは「速度」ではなく、別のものだった。
H.264やH.265は、映像を1枚ずつ丸ごと圧縮するのではなく、直前のフレームとの差分だけを送る方式（インター予測）で成り立っている。IPパケットが1つ失われると、そのパケットに含まれていた差分情報が欠け、次の基準点（Iフレーム）が来るまで、劣化が後続のフレームへ連鎖する。GOP（Group of Pictures、圧縮の基準単位）を1秒・30fpsで組んだ場合、Iフレーム1枚を除いた最大29フレーム分（30fps×1秒−1フレーム＝29フレーム）、崩れが尾を引く計算になる。「速度は足りているのに映像が壊れる」という現象の正体は、たいていここにある。
FEC（前方誤り訂正）という仕組みは、大事な手紙を1通だけ送るのではなく、要点を書いた控えをもう1通、別の便で同時に送るようなものだ。片方が届かなくても、控えの情報からほぼ同じ内容を組み立て直せる。IP伝送に乗り換えたばかりの現場では、この控えを用意しないまま、手紙を1通だけ送り続けているケースが少なくない。原因はエンジニアの技量ではなく、SDI時代には存在しなかった「設計項目」が増えたことにある。あなたが見落としていたのではなく、見落として当然の項目がそこにあった。
方法はある。パケットロス率をどう計測し、どの数値を閾値にFECとARQ（自動再送要求）を使い分け、GOP構造をどう組み直せば崩れの範囲を抑えられるか——この判断軸には、計算できる基準がちゃんと存在する。
この記事の有料部で手に入るのは次の3点だ。
- パケットロス率の許容閾値の算出方法（国際規格ベースの基準値つき）
- FECとARQ、どちらを選ぶべきかの判断表と設定手順
- 屋外中継・常設VPそれぞれで実際に起きた崩れの原因分析と復旧手順
この記事を読まないまま本番に入ると、ブロックノイズが出た瞬間にできることは「ログを1行ずつ照合する」以外になくなる。原因の切り分け方を先に知っていれば、その場で数分の対処に変わる。次の現場で同じ崩れを繰り返さないための設計図が、このあとにある。
コメント