要約

  • IESGは9月14日、draft-ietf-avtcore-rtp-jpegxs-3ed-07をProposed Standardとして承認したが、21日時点ではRFC番号がなく、RFC Editorは著者からの入力を待っていた。
  • RFC 9134準拠実装が従来の機能範囲で有効なことと、旧受信機がTemporal Differential Codingを復号できることは別である。
  • 版間互換性の記録には、標準化状態だけでなく、両端のbuild、完全なSDP、非TDCへのフォールバック、範囲を明示したメディア試験が必要だ。

標準文書が承認された日と、映像設備が更新された日は一致しない。2026年9月14日にIESGが承認したのは、*RTP Payload Format for ISO/IEC 21122 (JPEG XS)*のrevision 07をProposed Standardとして出版工程へ送ることだった。Proposed StandardはInternet Standardではなく、Protocol ActionはRFCの公開そのものでもない。

9月21日の公開記録は、その途中を示している。DatatrackerのIESG状態はRFC Ed Queue。RFC Editorのキューでは初期フォームが未提出で、著者の入力が必要とされている。RFC番号はまだない。IANAは版変更を受けて再審査が必要で、公開中のvideo/jxsv登録はRFC 9134を参照したままだ。これは技術的な否決ではなく、承認後に残る別工程である。

Obsoletesは機器の無効化ではない

revision 07は、将来のRFCがRFC 9134をobsoletesすると記す。この関係は、RFCシリーズで新しい参照先を示すものだ。既設機器の電源を切るものでも、firmwareを失効させるものでも、出版日に非TDCストリームを使えなくするものでもない。

改訂は段階的導入を意図している。RFC 9134に準拠する既存実装は更新仕様の下でも有効であり、legacy実装は自らが対応する機能範囲で動作を続ける。重要なのは「対応する機能範囲」だ。旧来の互換集合を残すことは、第3版の新機能を旧機器へ追加することではない。

TDCでは前の画像が状態になる

JPEG XSの第1版と第2版はintra codingを使っていた。第3版のTemporal Differential Codingは、wavelet領域で連続する画像の時間相関を利用する。非TDCのcodestreamは1枚の画像として独立に復号できる。TDCでは、直前のcodestreamから復元した係数をframe bufferに保持し、次の復号がそれに依存する場合がある。progressiveでは1個、interlacedまたはPsFではfieldごとに2個のbufferを使う。

そのため改訂はTDC sliceを示すSLI markerを扱い、frame-buffer bandwidth levelであるfbblevelを加える。fbblevelはTDC使用時だけ存在し、JPEG XS picture segmentの値と一致しなければならない。profile、level、sublevelにも同じ整合性が求められる。

旧受信機は非TDCで適合性を保ったまま、TDC profileや必要なbufferを持たないことがあり得る。互換性の設計は旧経路を保存するが、未実装の能力まで保証しない。

SDPはそのセッションで使う交差集合を決める

media subtypeは引き続きvideo/jxsvで、RTP clockは90 kHz、packetmodeは必須である。SDPではa=rtpmapにjxsv/90000を置き、a=fmtpにpacketmodeと、profile、level、sublevel、fbblevelなどの任意パラメータを記す。

unicastのoffer/answerでは、answererは提示されたすべてのパラメータと値を対応できなければセッションを拒否する。受け入れる場合は、同じ値を返す。offererには、相手が対応すると見込める組み合わせを選ぶ責任がある。

この規則は曖昧な部分受け入れを避ける。しかしTDC offerが拒否された後、非TDCの新しいofferが自動的に成功するとは限らない。送信機またはorchestrationが明示的にfallbackできるかを試す必要がある。SDPが成立しても、それは宣言値の合意であり、buffer alarmや映像破綻なしに復号した証明ではない。

互換性を再現可能な記録にする

版間互換性の記録には、revision 07とSHA-256、IESG/RFC Editor/IANAの状態、割り当て後のRFC番号、video/jxsv、payload type、clock、packetmode、profile、level、sublevel、fbblevel、TDCの有無を残す。さらに送信機と受信機の製品・build・firmware・設定、offerとanswerまたは拒否、非TDC fallback、サンプル、信号形式、frame rate、時間、packet条件、障害、修正、再試験、rollback、終了条件を結ぶ。

試験範囲も結果の一部である。1組の機器と1つのprogressive sampleは、interlaced、全level、全gatewayを保証しない。TDCの失敗もRFC 9134の非TDC運用を否定しない。「この2つのbuildが、この条件で、このstreamを交換した」という限定された結論こそ、運用に使える。

情報源

  1. IETF Datatracker: JPEG XS RTP改訂
  2. 文書履歴
  3. revision 07テキスト
  4. RFC Editorキュー
  5. RFC 9134
  6. IANA video/jxsv登録