要約

  • RFC 2032では、一つのH.261マクロブロックを二つのRTPパケットにまたがらせない。各パケットはマクロブロック境界で始まり、同じ境界で終わる。
  • GOBN、MBAP、QUANT、HMVD/VMVD、I/Vが開始時の復号状態を伝えるため、損失後のパケットから構文を読み直せる。しかし失われた領域や壊れた参照画像は復元されない。
  • 任意機能のFIRとNACKは、完全INTRAフレームの要求や欠落シーケンス番号を表現する。要求の記録は、到達、実行、期限内修復、表示の記録とは別である。

圧縮映像では、文法の回復が画像の回復より先に起こりうる。RFC 2032が設計したのは、その中間状態を曖昧にしない仕組みだった。

1996年10月にProposed Standardとして発行された同文書は、H.261映像をRTPで直接運ぶ形式を定義した。H.261は固定速度のISDN回線を前提とし、H.221の512ビットフレームには映像、音声、データ、誤り訂正をまとめられた。インターネット用ペイロードはその枠を運ばず、Huffman符号化された映像ビット列そのものを送る。したがって目的は損失をなくすことではなく、一つのデータグラムが消えても後続すべてが読めなくなる事態を防ぐことにあった。

マクロブロック境界は障害の境界だった

H.261の一枚の画像はGroup of Blocksに分かれ、一つのGOBは33個のマクロブロックを含む。各マクロブロックは16×16画素の領域に対応する。RFC 2032はこれを分割単位とし、パケットの始点と終点を必ずマクロブロック境界に置いた。マクロブロックの途中だけでなく、GOBヘッダーと最初のマクロブロックの間で切ることも認めなかった。

可変長のHuffman符号では、任意のビット位置から読み始めると、それが新しいフィールドの先頭か、失われた符号語の続きかを判断できない。既知の境界と開始文脈があれば、次に届いたパケットを新たな構文入口として扱える。

ただし、構文上の独立性は画像上の独立性ではない。H.261はフレーム間予測と差分を利用する。正しく読めたマクロブロックでも、参照先の同じ領域がすでに失われていれば、正しい画素になるとは限らない。RFC自身も、該当マクロブロックがINTRAで符号化され直すまで損傷領域が残る可能性を記している。再開点は不明範囲を狭めるが、過去を消去しない。

4バイトのヘッダーが開始時の記憶を持った

SBITとEBITは、最初と最後のオクテットにある非映像ビット数を示す。ビット単位のH.261構文を、バイト境界を持つネットワークパケットに収めるための情報である。

GOBNはパケットが始まるGOBを示し、0なら画像ヘッダーから始まる。MBAPはGOB先頭から見たマクロブロックアドレス予測値を保持する。QUANTは次のマクロブロックに適用する量子化値、HMVDとVMVDは差分運動ベクトルを再構成するための水平・垂直参照値を保持する。

これらは復号文脈であって、表示結果の証明ではない。MBAPは修復済み領域の画面座標ではなく、アドレス差を解釈するための予測値だ。運動ベクトルを再構成できても、その参照画像が正しかったことまでは示さない。

IとVも控えめな手掛かりである。Iは全マクロブロックがINTRAか、Vは運動ベクトルを使用しうるかを示す。仕様はビット列から推定できると述べ、適合実装が保守的にV=1、I=0を使うことも許している。安全な復号経路の選択には役立つが、各マクロブロックの監査や品質測定ではない。

フレーム末尾が分かっても、完全性は分からない

一つの映像画像に属するパケットは同じ90 kHzのRTPタイムスタンプを共有する。フレーム最後のパケットではmarkerビットが1になり、受信側は次の画像開始コードを待たずに表示判断を進められる。一つのパケットに複数画像が入る場合、RTPタイムスタンプは最初の画像だけに対応し、後続の表示時刻はH.261ヘッダーから計算する。

これは時間と宣言された終端を示す情報である。marker=1は、それ以前の全シーケンス番号が届いたという証明ではない。RTPシーケンスの穴は損失の観測に使える一方、UDPで送っただけでは送信側に配達成功は分からない。「最後を受信した」と「全部を受信した」は異なる事実だ。

封じ込めは訂正ではなかった

RFC 2032は持続的な損傷を抑える方法として、周期的な全INTRAフレーム、損失に応じたリフレッシュ頻度の調整、受信側からのリフレッシュ要求を挙げる。いずれも制御ループを始める可能性を作るが、ループが閉じたことを自動では証明しない。

境界と複製文脈によって後続構文は生き残れる。それでも欠落領域のデータはなく、誤った参照は予測に残り、遅れた訂正は再生期限を過ぎる。形式が守るのは将来の解釈可能性であり、映像内容の回復には追加の動作と観測が必要になる。

FIRとNACKは要求に座標を与えた

RFC 2032はH.261専用の任意RTCPメッセージも定めた。Payload Type 192のFull INTRA-frame Requestは、符号器に次のフレームを完全INTRAで作るよう求め、SSRCは要求した受信側を示す。Type 193のNegative Acknowledgementでは、FSNが最初に失われたと考えるRTPシーケンス番号を、16ビットのBLPが続く16番号の欠落を示す。

FIRは予測の土台を更新せよという要求であり、NACKはこの位置を観測できなかったという申告である。局所的な判断が、処理可能な座標になる。

しかし機能は任意で、トポロジーにも制約された。参加者が多い場所での否定応答は悪影響を及ぼしうると文書は警告する。デコーダーから符号器への直接送信はmixerやtranslatorがない場合に限られ、IVSの例も受信者が少ないときだけ有効にした。対応実装、戻り経路、規模はフィールド外の前提である。

FIRを捕捉すれば要求が送られたことは分かるが、到達やINTRA出力は分からない。NACKを捕捉すれば受信側の欠落認識は分かるが、再送の有無、再生前の到着、画面への反映は分からない。修復座標は診断を強くする。結果を証明するには、送信源、後続パケット、復号結果、表示時刻まで結ぶ必要がある。

仕様は結果の一歩手前で止まった

Lu Hengの最小初期仕様という考え方に照らせば、RFC 2032の分担は明快だ。共通化したのは切断可能位置、開始文脈、時間、フレーム終端、任意のフィードバック構文である。バッファ期限、リフレッシュ方針、INTRAフレームの帯域費用、許容損傷は各実装と運用の判断に残した。

running code primacyは証拠の鎖を要求する。公表されたフィールド形式、正しく生成された値、双方向の配送、符号器の動作、期限内の表示は別々の現実である。仕組みの名称を、全段階の成功証明にはできない。

RFC Editorは現在、RFC 2032をRFC 4587によって廃止された文書と記録する。後継仕様の詳細に踏み込まなくても歴史的な要点は十分だ。損失一件が読めなくする範囲を小さくし、修復意図に宛先を与えた。ただし修復された画像そのものは、別の証拠を必要とした。

出典