要約

  • RFC 2029のCellBペイロードは、最初のセルのX/Y座標と画像の幅・高さという四つの16ビット整数で始まる。座標は4×4ピクセルのセル単位、寸法はピクセル単位である。
  • 複数バイトのCellBコードは一つのパケット内に収めなければならない。途中のパケットが失われても、次の完全なパケットはコード境界と宣言された画像位置の両方から再開できる。
  • これは損害を局所化する仕組みであり、欠落データの再構成ではない。座標、寸法、フレーム共通のtimestamp、終端を示すMarkerだけでは、セルの完全性、量子化表の一致、デコード成功、連続表示を証明できない。

圧縮映像のパケットが一つ消えたとき、問題は空白部分だけでは済まないことがある。次に届いたバイト列が命令の途中なのか、画像のどこに置くべきなのかが分からなければ、欠落の影響は後続データへ広がる。

1996年10月のRFC 2029は、CellBをRTPで運ぶ際のこの連鎖を断とうとした。失われたピクセルを作り直すのではなく、後続パケットが自分の意味を取り戻すための局所情報を繰り返したのである。

ペイロード自身が画像内の住所を持つ

CellBヘッダーは8バイトである。先頭からCell X Location、Cell Y Location、Width of Image、Height of Imageが並び、いずれもネットワークバイトオーダーの16ビット符号なし整数である。

XとYが数えるのはピクセルではなくセルだ。一つのセルは4×4ピクセルを表す。幅と高さはピクセルで記録されるため、受信側はセル格子上の開始点と画像全体の大きさを同時に得る。

画像寸法はフレームの途中では変えられない。それでも全パケットに繰り返すことで、後続パケットは前に届いた情報へ依存せずキャンバスを知ることができる。損失時には、この小さな冗長性が自立性になる。

もっとも、ヘッダーは送信側の申告である。座標以前のセルが届いたか、座標同士が重ならないか、宣言された画面全域が埋まるかは示さない。住所が書かれていても、建物全体の完成検査にはならない。

ネットワークの切れ目を命令の切れ目に合わせる

CellBのコード長は一定ではない。通常のセルコードは4バイトで一セルを表す。1バイトのskip codeは現在のフレームで1〜32セルを飛ばす。Y/Y表とU/V表を更新する命令は、それぞれ1バイトの指示に512バイトの新しい表が続く。

RFC 2029は実装者にパケットサイズを任せ、最大では一フレーム全体も許した。一方で、複数バイトのコードを二つのパケットへ分けることは禁止した。四バイトのセルコードの途中や、表更新の途中でパケットを終えることはできない。

この制約により、欠落の次に届く完全なパケットは、失われた命令の後半から始まらない。コードの開始点があり、さらにヘッダーが最初のセルの位置を示す。構文と空間の二つの文脈を同時に回復できる。

ただし回復するのは「読み始められる条件」である。RFC 2029は再送、前方誤り訂正、セルの複製を規定しない。消えたパケットの内容は消えたままだ。後続まで解釈不能になる範囲を狭めることと、失われた画像を取り戻すことは別である。

timestampは所属、Markerは終端の申告

CellBは90 kHzのRTP timestampを使う。同じフレームのパケットは同じ値を共有し、Markerビットが最後のパケットを示す。この二つは、空間座標を持つパケットを時間上のフレームへまとめる。

しかしtimestampには、そのフレームに必要なパケット数が書かれていない。Markerが立ったパケットを受信しても、その前に穴がないとは限らない。RTPのsequence numberは欠落の検知と送信順の復元に使えるが、基礎仕様はRTPが配送、時間どおりの到着、到着順、QoSを保証しないと明記している。

終端の印は一覧表ではない。最終パケットの位置が分かっても、中間の全パケットが存在したという証拠にはならない。

量子化表を失えば、場所が正しくても色は違う

CellBのセルコードにあるU/VとY/Yは、色度と輝度の値を直接並べたものではなく、ベクトル表のindexである。同じindexでも、参照している表が異なればピクセル値は変わる。

RFC 2029は両方の表を512バイトの新しい内容へ置き換えるコードを記述した。同文書のサンプルcodecはこの機能を実装していなかったが、将来の実装が使う可能性を残した。更新全体が一つのパケット内に収まるため、受信できた更新は境界で切断されない。

しかし更新を運ぶパケットそのものが失われれば、後続パケットの座標とコード境界だけでは補えない。受信側は古い表でindexを解釈し得る。置き場所は合っているのに、得られる色が違うという状態である。

これはRFCに掲載された障害事例ではなく、二つの仕様要素から導かれる証拠上の限界だ。パケットが空間的・構文的に自立しても、過去の状態変更まで自立するとは限らない。

証拠を一段ずつ積む

調査では、sequence numberによる輸送の連続性、X/Yと寸法による宣言位置、コード境界による構文、timestampとMarkerによるフレーム区分を別々に保存すべきである。

正しい映像を主張するには、さらに実ペイロード、座標の被覆、適用された量子化表、デコーダー出力、レンダリング時刻が要る。視聴品質を語るなら、表示端末での観測も必要になる。上流のメタデータから下流の体験を省略して推定することはできない。

IANAのRTP表には現在もCelBが固定payload type 25、映像、90,000 HzとしてRFC 2029とともに記録されている。これは割当の証拠であり、現在の利用量や相互運用性の証拠ではない。RFC 2029がProposed Standardとして残っている事実も、実装やサービス品質を保証しない。

RFC 2029の設計は、損失を消すのではなく、その影響がどこまで及ぶかを制御した。8バイトの住所とコード境界によって、次の完全なパケットはもう一度読める可能性を持つ。その可能性を「映像が復旧した」と言い換えないことまで含めて、この古い仕様は証拠の扱い方を教えている。

情報源