要約

  • RFC 2035のペイロードは完全なJPEGファイルではない。変化しにくい表や推論できるマーカー列を省略し、Type、Q、幅、高さ、24ビットのFragment Offsetを含む8オクテットのRTP/JPEGヘッダーを各パケットで繰り返す。
  • タイムスタンプ、シーケンス番号、オフセット、Markerは、それぞれフレーム所属、送信順、バイト配置、宣言された終端を示す。組み合わせれば欠落を観測できるが、単独で完全性を保証するものはない。
  • リスタートマーカーは復号状態を区切る。Type 4/5では区間とRTPパケットを揃えるため、損失後に一部区間から復号できる可能性がある。ただし画素の完全性、期限内再生、連続性、体験品質は別の証拠である。

映像パケットが順番どおりに届かないこと自体は、配置を不可能にしない。RFC 2035のFragment Offsetは、到着順位ではなく、JPEGスキャン内のバイト位置を告げる。遅れて届いたパケットでも、受信側はその宣言された場所へ直接置ける。これは小さなフィールドだが、「どこに属するか」と「いつ届いたか」を明確に分離する。

1996年10月に公表されたRFC 2035は、この分離を前提にJPEG圧縮映像をRTPで運ぶ形式を定めた。通常のJPEG交換形式には、量子化表、フレーム寸法、スキャン条件など多くの記述がある。動画では、それらの多くがフレーム間で変わらない。合意した規則から再生成できる説明を毎回送れば、帯域を使う一方で新しい画素情報は増えない。

そこでペイロードはエントロピー符号化されたスキャンデータから始まり、必要な説明は各パケットの短いヘッダーへ移された。省略は無料ではない。完全なJPEG構文が線上にない以上、受信側はフレーム所属、バイト位置、量子化、寸法、終端、復号再開点を別の証拠から組み立てなければならない。

省いた記述を何が置き換えたのか

対象はシーケンシャルDCTの単一インターリーブスキャンに限定される。JPEGのあらゆる可能性を運ぶ方式ではなく、制約のあるハードウェアでも共有できる狭い形式である。互換性は機能の最大化ではなく、実装可能な共通面を絞ることで得られた。

8オクテットのRTP/JPEGヘッダーには、type-specific、3オクテットのFragment Offset、Type、Q、Width、Heightが並ぶ。Typeはサンプリングとリスタートの解釈を選び、Qは量子化表の規則を示す。幅と高さは8画素単位である。品質や解像度を変えて送信レートへ適応できるため、受信側は会話の最初に覚えた値を永続的な真実とは扱えない。

Qが1から99なら、仕様内の計算で量子化表を作れる。100以上は動的な表を必要とするが、その交換方法はRFC 2035の外側にある。0は予約値である。この境界は「値がある」と「解釈に必要な情報がそろう」が同義でないことを示している。

宣言されたType、Q、寸法から正しいJPEGヘッダーを生成できても、圧縮スキャンそのものの完全性はまだ不明である。送信側が宣言どおりに符号化したこと、途中のバイトが壊れていないこと、復号結果が撮影対象に忠実なことは、別に確かめなければならない。

完全性を一つの印にまとめない

同一フレームの断片は同じRTPタイムスタンプを持つ。シーケンス番号はRTPストリームの順序と欠番を示す。Fragment Offsetはスキャン内の配置先を示す。Markerはフレーム終端であると送信側が宣言したパケットを示す。

タイムスタンプが一致しても、全断片があるとは限らない。シーケンスが連続していても、内容が正しいとは限らない。オフセットが妥当でも、前後の範囲が届いたとは限らない。Markerがあっても、その前に穴が残ることはある。したがって受信側は、オフセットとペイロード長から範囲を組み立て、隙間や重複を検査し、終端宣言と照合する必要がある。

この仕組みは順不同受信で効く。先に全パケットを並べ替えてからコピーせず、到着ごとに正しい位置へ書き込める。RFC 2035がIP任せの断片化ではなくRTPレベルの分割を選んだ理由もここにある。IP断片を一つ失うと、無傷の部分まで上位へ渡らない場合がある。独立したRTPパケットなら、届いた範囲を観測し続けられ、送信側も下位層の再断片化を避ける大きさを選びやすい。

最後のパケットが失われると、データだけでなくMarkerも失う。次のフレームのoffset 0が新たな開始点を示し、その後の連続範囲とMarkerがそろって初めて、次フレームの完全性を評価できる。開始、連続、終端は異なる証拠であり、どれか一つを代用にはできない。

リスタートは欠けた画面を描き直さない

JPEGのハフマン復号とDC予測には過去の状態が影響する。リスタートマーカーはその状態をリセットし、途中から復号を再開できる境界を作る。Type 0/1はリスタートを使わず、Type 2/3は使えるがパケット境界との整列を要求しない。Type 4/5はリスタート区間とパケットを整列させ、専用のカウントで区間列の位置を表す。

整列した区間が無傷なら、前の断片がなくてもそこから復号できる可能性が生まれる。しかし失われた区間の画素は戻らない。復号可能な範囲が重要な被写体を含む保証も、再生期限に間に合う保証もない。構造が与えるのは損傷範囲を限定する機会であり、品質評価ではない。

RFC 2435が後にRFC 2035を廃止し、現在のIANA登録が静的ペイロードタイプ26について後継文書を参照していることも区別すべきである。現行の状態は歴史的仕様を書き換えない。後継版の独立したオプションや変更を旧仕様の機能として語ってはならない。

観測できる事実を段階ごとに残す

パケットキャプチャからは、実際のバイト、タイムスタンプ、シーケンス、Marker、offset、Type、Q、寸法、リスタート情報を検証できる。再構成処理は、どのJPEG構文を生成したかを記録できる。デコーダーは受理、失敗、出力領域を記録できる。その後に、期限内のプレイアウト、レンダリング、画面の連続、利用者の認知が続く。

Lu Hengのrunning-codeという視点を適用するなら、まず実行されたイベントを保存し、解釈はその上に置く。派生した「complete」という一語だけを残して原始パケットを捨てれば、後から判断を反証できない。宣言と結果、構造と体験を同じ列に上書きしてはいけない。

RFC 2035が示したのは、薄い共通層の強さである。再生成できる説明を省き、変化する最小文脈だけを繰り返し、断片の位置を受信側から検証可能にした。その強さには明確な限界もある。パケットは自分の配置先を語れる。画像が完成し、間に合い、見られたことまでは語れない。

出典