要約

  • RFC 2038はMPEGスライスの開始位置をペイロード走査なしで見つけられるようにパケット化を制約し、BとEで各RTPペイロードのスライス境界との関係を示した。
  • すべてのビデオパケットはTemporal ReferenceのTR、Picture TypeのP、必要な前方・後方動きベクトルのパラメーターを反復する。GOP HeaderやPicture Headerが失われても、次のスライスで限定的な代替コンテキストを組み立てられる。
  • シーケンス番号の空白、B/E、反復状態が裏付けるのは局所的な再開判断である。先行スライス、申告の真偽、完全なピクチャ、参照フレーム、正しいデコード、連続再生、視聴者への到達、QoSまでは裏付けない。

受信機のログには、番号が6007から6009へ飛んだことだけが残っている。6009はB=1で、TRは12、PはBピクチャを示し、前方・後方双方のベクトル情報を持つ。受信機はこの地点で、欠落した途中断片への依存を切り、次のスライスをデコーダーに渡す準備ができる。

しかし、その判断から「6009が属するピクチャは完全だった」とは言えない。欠落パケットに含まれたマクロブロックは戻らず、Bピクチャが必要とする参照ピクチャも健全とは限らない。送信側の境界表示が誤っている可能性も、再構成に使った既定値が原本と違う可能性も残る。

RFC 2038が実行可能にしたのは、壊れた履歴を修復したふりをせず、再処理できる場所まで被害を限定することだった。

コーデック内部の回復単位をパケット境界へ出した

MPEGの圧縮ビットストリームには時間方向と空間方向の依存がある。一部を失うと、物理的には到着した後続データも意味を失い得る。しかも大きなピクチャは通常のネットワークMTUを超えるため、複数パケットへの分割を避けられない。

RFC 2038はその分割に規則を置いた。Video Sequence HeaderはRTPペイロードの先頭に置く。GOP Headerは先頭またはSequence Header直後、Picture Headerは先頭またはGOP Header直後に置く。これらのElementary Streamヘッダーは一つのパケット内で完結しなければならない。

スライスについてはさらに実務的だった。RFCはスライスを損失や破損後のMPEG回復単位と位置づける。スライス開始はペイロード最初のデータ、許可されたヘッダーの直後、または同じペイロード内の完全なスライス列の後に現れる。一方、スライスそのものは複数パケットへ分割できた。したがって「1パケット＝1スライス」ではない。

この配置により、受信機は損失後の全ペイロードを走査してstart codeを推測する必要がなくなる。コーデックが定める意味のある回復点を、RTP固有ヘッダーがパケット処理から見えるようにした。見えるようにしたことと、その内容を認証することは別である。

B/Eは境界との位置関係を示す

固定RTPヘッダーの後には32ビットのビデオ固有ヘッダーが付く。Bはペイロードがスライス開始コードから始まることを示す。ただし、その前にSequence、GOP、Pictureの許可されたヘッダーがあってもよい。Eはペイロードの末尾バイトがMPEGスライスの終端であることを示す。

二つのビットから、スライス境界で始まり終わる、始まるが続く、途中から続いて終わる、途中だけを運ぶ、という形を区別できる。圧縮データを深く解析する前に、受信側は断片の位置づけを得られる。

ただしB=1は送信側の申告であり、実データに正しいstart codeがあることを暗号学的にも構文的にも証明しない。E=1も同じスライスの全断片が届いたという一覧ではない。BとEがともに立ったパケットが完全に到着しても、その前のシーケンス番号の空白が別の映像部分を消していることはある。

監査で言えるのは「ヘッダーがこの境界状態を申告した」までだ。実際のMPEG構文、スライスの完全性、デコーダーの受理は、それぞれ別の観測を必要とする。

ピクチャ状態を小さく反復した

RFC 2038のもう一つの工夫は、ピクチャに関する最小限の情報を各パケットで繰り返すことだった。10ビットのTRはGOP内のTemporal Referenceで、同じピクチャの全パケットで一定となる。3ビットのPはI、P、B、Dのピクチャ種別を表し、やはりピクチャ内で変わらない。

さらに、直近のPicture Headerから前方・後方動きベクトルのfull-pelフラグとf-codeを運ぶ。Iピクチャではすべてゼロ、Pピクチャでは前方の組だけ、Bピクチャでは四項すべてを利用し得る。この情報は圧縮ピクチャの複製ではなく、失われたヘッダーの一部を近似するための短い記録である。

Picture Headerが唯一のパケットとともに消えると、後続のスライス境界が分かっても、デコーダーはピクチャ種別やベクトル解釈を失う。各パケットで値を反復すれば、次に利用できるスライスは同時に再開用の入力も運んでくる。

反復には不一致検知という副次的な価値もある。予想外のTR/P変化はGOP HeaderまたはPicture Headerの欠落を示唆する。付録は参照ピクチャと依存ピクチャのカウンターを維持し、期待値と受信TRを照合する方法を示した。だが不一致は断絶の徴候であって、消えたヘッダーの値や損失原因の証明ではない。

再構成は意図的に不完全だった

RFCの提案では、GOP Headerを失った場合、ゼロのtime code、直前GOPのclosed_gop、そして1にしたbroken_linkから代替ヘッダーを作れる。Picture Headerは、次のBeginning-of-sliceでP、TR、四つのベクトル項目、ストリーム依存の既定値を使って組み立てられる。

これは原本の復元ではない。ゼロのtime codeは失われた値ではなく、以前のclosed_gopも新しいGOPの観測ではない。既定値は受信側の前提である。とりわけbroken_link=1は、連続性を装わず予測リンクが信用できないと明示する。

受信側はこの代替情報で処理を試せるが、必要な参照ピクチャの存在や正しい出力までは保証されない。「再構成した」と「回収した」を混同しないことが設計の誠実さを保つ。

欠番後にBまで捨てる意味

付録の回復手順では、RTPシーケンス番号に空白があれば、受信機はBeginning-of-sliceが立つパケットまで後続を捨てられる。その地点で必要ならGOP/Picture Headerを代替し、MPEG処理を再開する。

RTPシーケンス番号は送信データパケットごとに増え、損失検知や送信順序の復元に役立つ。しかしRTPは配送、順序、期限内到着、QoSを保証しない。一受信機の欠番だけでは、実ネットワーク損失、並べ替え、キャプチャ漏れを区別できず、欠落データの中身も分からない。

Bまでの破棄は判決ではなく損傷隔離である。先頭を失った断片を渡さないため、届いていたかもしれないデータも意図的に犠牲にする。回復可能性は、未知を未知として扱うことで得られる。

「回復済み」を七つの観測へ分解する

調査記録は少なくとも、RTPシーケンス連続性、B/E申告、解析されたMPEG境界構文、反復されたTR/P/ベクトル状態、参照ピクチャの可用性と健全性、デコード出力とエラー隠蔽、時刻どおりの再生と視聴者観測を分けるべきだ。

境界表示が整合してもピクチャの完全性は証明されない。TR/Pがもっともらしくても消えたヘッダー原文ではない。構文が通っても参照予測が正しいとは限らず、フレームが出ても連続再生や視聴を意味しない。各層の証拠は次の検査を正当化するが、その検査結果の代用にはならない。

RFC 2038は1996年10月にProposed Standardとして公開され、1998年1月にRFC 2250で廃止された。現在のIANA RTP登録では静的ペイロードタイプ32が90 kHzのMPVとされ、RFC 2250が参照されている。これは割り当ての証拠であって、現代の配備や特定通信の品質を示すものではない。

この短命な仕様の長い教訓は、実際の回復単位をパケットから見えるようにし、必要最小限の状態を近くで反復することにある。それでも境界は、再度試す許可にすぎない。前後の映像を完全にする証明書ではない。

情報源