要約

  • RFC 2343 の BMPEG header は picture 種別、header 変更、音声長、signed Audio Offset を示し、90 kHz timestamp とともに音画の配置を記述した。
  • それは packetizer の宣言であり、完全受信、正しい decoder state、lip-sync、端末出力、視聴者の知覚には別の観測が必要だった。

小さな番組に見えるパケット

BMPEG payload は一見して完結している。先頭側に整数個の video slice があり、その後ろに整数個の audio frame が続く。RTP header は sequence、picture の sampling time、picture 終端を示す。BMPEG 固有 header は I、P、B の種別、MPEG header data の変更、音声 byte 数、音声開始位置の時間差を与える。

1998 年の VOD では、この一体性が運用コストを下げた。一番組を一つの port で扱い、保存時に interleave された素材を二つの stream に分離せず送り、header overhead を減らせる。RFC の例では 4 Mbps の素材で約 1%、およそ 40 Kbps の節約が想定された。二経路の遅延差を吸収する buffer も小さくできる可能性があった。

文書は音画の「implicit synchronization」も利点に挙げた。ただし implicit なのは packet 内の関係である。speaker と display が同じ瞬間に出力したという測定ではない。

一体化は modularity との交換だった

RFC 2343 は Experimental であり、Internet standard を定めないと明記した。音声と映像を別々に扱う modularity より単一 port、低 overhead、保存形式との親和性を重視する場合の選択肢だった。

一つにまとめれば failure domain も重なる。一 packet の損失が映像と音声を同時に傷つける。片方だけを選ぶ自由も減る。大きな packet は path MTU を超えやすくなり、下位層の fragmentation に依存する。

また、MPEG systems layer の情報のうち RTP と重複すると考えた部分を省いた。byte を省くことと責任を消すことは違う。時刻、buffer、状態管理は RTP、application、receiver の分担へ移った。同じ syntax を受理する二つの実装でも、その分担の解釈が異なれば結果は一致しない。

再開できる境界を packetizer が作る

Video_Sequence_Header がある場合は payload の先頭に置く。GOP_header は先頭または sequence header の直後、Picture_Header は先頭または GOP_header の直後に置く。各 packet は整数個の video slice を含む。

これにより receiver は loss 後の再開点を見つけやすい。しかし下位層で packet が分割されない保証にはならない。slice size と一 packet の slice 数を path MTU に合わせる責任は application にあった。超過すれば IP fragmentation が起こり得て、RSVP のような分類にも問題を生じ得る。

音声は video segment の duration を覆うだけの完全な frame を後置する。audio frame の方が長ければ、続く数 packet に audio がなくてもよい。loss resilience のため最新 audio frame を繰り返す選択も許された。

構造検査はこれらを確認できる。だが、経路 MTU の変化、fragment loss、繰り返し音の不自然さ、buffer underrun は payload syntax の外にある。

三つの順序を一つにしない

RTP sequence number は送信順序を示す。32-bit、90 kHz の timestamp は MPEG picture の sampling time を示す。同じ picture の packet は同じ timestamp を持ち、Marker は picture 終端を含む packet に立つ。

B picture があると transmission order と presentation order が異なるため、timestamp は単調増加でなくてよい。sequence、extension、GOP header だけの packet は次の picture の timestamp を使う。

Audio Offset は audio frame の開始と、その packet の RTP timestamp の差を signed sample 数で表す。44.1 kHz では約 ±750 ms であり、一秒一 frame のような低 frame rate では不足して format が使えない可能性を RFC 自身が認めた。

B picture に合わせて audio を並べ替えるのではなく、audio は transmission order のまま運ばれ、offset が presentation relation を指す。つまり offset は座標である。receiver の clock 変換、device latency、actual playout、知覚上の同期を保証しない。

loss の位置が分かっても、内容は戻らない

sequence number と timestamp の組み合わせは packet loss を検出できる。slice number と最初の macroblock position は範囲の推定に役立つ。同じ picture 内の slice loss なら、decoder は処理を続け、以前の picture の pixel を繰り返すことができる。失われた音声の代わりに background noise を入れ、lip-sync や聴感上の連続を守ることもできる。

これは復元ではなく concealment である。以前の pixel は失われた pixel ではない。挿入音も原音ではない。出力が続くことは data completeness を意味しない。

N bit は sequence、extension、GOP、picture header のどこかが以前から変化したことを示す。必要な header state を失った場合、新しい picture start まで捨てる判断が推奨された。重い loss では新しい sequence header まで待つことになる。

BMPEG は RFC 2250 で扱われる temporal-reference のような専用 picture counter を持たない。GOP_header loss が検出されず、編集素材の直後の B picture が誤って復号される場合がある。packet が parse できることと decoder context が正しいことは別である。

format の後に残る観測

packet が deadline 前に到着したか。IP fragment と必要な RTP packet が揃ったか。sequence、GOP、picture state が正しいか。decoder が frame と sample を出したか。audio/video clock が実際の出力時刻で一致したか。renderer と hardware path が画面と音を出したか。window が隠れておらず mute でもないか。そして視聴者がその場にいたか。

これらは一つの status に圧縮できない。RTP は resource reservation も QoS guarantee も提供しない。valid packet は遅着し得る。decoded frame は捨てられ得る。同期済み output は background に隠れ得る。点灯した画面の前に誰もいないこともある。

RFC 2343 の価値は、共同 packetization という一段を明確にした点にある。明確だからこそ、その authority はそこで終わる。payload は包装の証言者であり、視聴の証人ではない。