動画コーデック移行計画：H.264→VP9→AV1 の段階導入とリスク制御

要点 (TL;DR)

• 最初に 計測基盤 (再生開始遅延 / ビットレート / エラー率 / Dropped Frames)。
• 再生上位 20% を VP9 AB (10%) → 成功閾値クリアで段階拡大。
• AV1 は “長寿命 + 再生上位 5%” のみから小規模拡張。
• 閾値逸脱時は manifest feature flag で即時ロールバック。
• キャッシュは /v/<codec>/<hash>/file 指紋 + immutable。

1. KPI & 計測基盤

• 再生開始遅延 (request→first frame)
• 初期転送バイト / 平均ビットレート
• 再生失敗率 (error events / sessions)
• クォータイル視聴完了率 (Q25/Q50/Q75)
• 端末 CPU 負荷 (Video decode タイム)

2. 対象選定

全動画の Pareto 分布を計測し、上位 20% がトラフィックの ~80% を占めることを確認。まずここに VP9 を適用で再エンコードコストを限定。

3. VP9 パイロット

• エンコード: libvpx-vp9 CRF=32 (2pass, row-mt)
• タグ順序: MP4(H.264) は最後 (互換 fallback)
• AB: manifest で 10% を VP9 優先
• 成功閾値: 平均ビットレート ⩽ H.264 -20% / 起動遅延 + < 30ms / エラー率 + <0.1pt

<video controls preload="metadata">
  <source src="/v/vp9/a1b2c3/ui.webm" type="video/webm; codecs=vp9" />
  <source src="/v/h264/a1b2c3/ui.mp4" type="video/mp4" />
  <!-- Safari 旧端末等は MP4 fallback -->
</video>

4. 全量 VP9 化

成功後、バッチワーカーを並列化 (N=N_cores*2)。H.264 はキャッシュヒットを見つつ徐々に低頻度化。ただし iOS Safari 旧端末互換で保持。

5. AV1 パイロット

• 対象: 視聴寿命 ≥6ヶ月 + 再生上位 5%
• エンコード: libaom-av1 cpu-used=6 CRF=35 row-mt=1
• 監視: CPU decode time / dropped frames / playDelay p95
• フォールバック: 再生開始遅延 > 50ms or dropRate > 4% で manifest 差替

# AV1 実行例
ffmpeg -i ui-vp9.webm -c:v libaom-av1 -cpu-used 6 -crf 35 -b:v 0 -row-mt 1 -threads 8   -pix_fmt yuv420p10le ui-av1.mkv

6. キャッシュ / URL 設計

7. ロールバック戦略

• 閾値逸脱時: feature flag で VP9/AV1 無効
• Cloudflare / CDN キャッシュ キー: codec を vary に含める
• 再エンコード中断: キュー内タスクを state=paused に更新

8. 自動化チェック

1. エンコード完了後: ffprobe メタ検証
2. VMAF < 85 なら CRF -2 再試行 (最大2回)
3. 再生ログ収集 → ダッシュボード
4. 閾値逸脱時 Slack アラート

9. FAQ

H.265(HEVC) は?

Safari 互換は高いが特許とブラウザ差異。Web 配信で汎用化しづらい。

再生端末判定は?

canPlayType + codec string + 早期バッファ取得時間。

突然のトラフィック増?

H.264 キャッシュレイヤがバッファ役。上限超で VP9/AV1 バックフィル遅延を許容。

関連

• エンコード基礎
• 指標と計測