要約

  • RFC 9828 はJPEG 2000画像全体の符号化完了前に先頭RTPパケットを送れるが、対象は所定の単一タイル進行順序に限られる。
  • resync、ESEQ、PTSTAMP、QUAL、RES は処理を助ける信号であり、復旧、時計再構成、完全画質、表示時刻の実績ではない。
  • 検収はセッション、符号化、送信、ネットワーク、受信状態、復号出力、表示を別々の証跡で結ばなければならない。

RFC 9828 は2025年8月公開のIETF Proposed Standardで、video/jpeg2000-scl を定義する。JPEG 2000の一画像は、マーカーと符号化データからなる独立 codestream である。SOCから最初のSOTまでの main header は画像全体の条件を持ち、一般に復号に欠かせない。RTP形式はExtended Headerを運ぶMain Packetと、それを含めてはならないBody Packetを分ける。

この分離により、画像の末尾がまだ符号化されていなくても先頭部分を送れる。しかし ORDH が許す条件は狭い。sub-codestream latencyを認めるのはPCRLの4とPRCLの6だけで、複数タイルでは ORDH=0 が必須になる。早く出たパケットが、この単一タイル・進行順序条件を満たしたかは最初の検査点である。

Body Packetは ORDB、POS、PID で precinct のresync pointを示せる。先行パケットが破損、喪失、または中間装置で意図的に除外されても、受信機が後続部分を処理する足場になり得る。だが失われたバイトは戻らない。複数タイルでは指定できず、受信機が必要なmain headerを保持したか、実際に再開したか、得られた画面が用途に足りたかも別問題である。

RTP sequenceの下位16ビットに ESEQ の上位8ビットを加えると24ビットの拡張番号になる。16ビット周回を越える追跡には有効だが、番号は配送確認ではない。欠番は損失、品質・解像度による選別、または観測点の違いで生じ得る。

同一画像の全パケットは、90 kHzのpresentation timestampを共有する。PTSTAMP は送信時計の12ビット標本で、受信側の時計回復を速められる。送信者は正確に生成できる場合だけ P=1 とすべきで、同一timestampを持つ連続パケットは4095 tick、約45 ms以内で送られなければならない。RFC 5450 は名目時刻と実送信時刻がずれる一般例を扱う。それでも受信時計、jitter buffer、capture/display時計、scan-outの整合は実測を要する。

QUAL は不要な上位品質層、RES は不要な高解像度成分を捨てる判断材料になる。低解像度画像が出たことは有用な縮退結果だが、完全画質の保存とは違う。R=1 のheader再利用と C=1 のcode-block cacheも同様に状態依存である。RFC自身が、損失や途中参加のため送信者は受信cacheを確実には知れないと述べる。

IANAの video/jpeg2000-scl 登録はpixel/sample形式、最大寸法、signal、アプリ定義の caps を扱い、SDP がセッションへ運ぶ。未指定値は未指定のままであり、能力URIは受信機の実在するdecoder設定を証明しない。幅・高さは構文上2^32−1まで許されるため、実装は資源を制限し、超過時に安全に失敗すべきである。

RFC 3550 はRTP、RFC 5371 は先行JPEG 2000 payloadの文脈を与える。RFC Editor情報、text、Datatracker、errata検索 は文書の身元を示すが、製品採用や性能測定ではない。

Heng Luの Running-Code Primacy は、標準の宣言と稼働結果を混同しない編集原則として使う。Minimum Initial Specification は共通payloadと受信側の局所判断を分け、Reality, Not Advocacy は証拠の終点で主張を止める。これは本稿の適用で、IETFの意図を代弁するものではない。

必要な証跡は、交渉結果、codestream条件、実送信、各network観測点、受信header/cache、resync結果、復号解像度・品質、共通時計によるcapture-to-displayの八層である。