要約

  • RFC 9584 は EVC 向けに単一 NAL、集約パケット、分割ユニットを定義する。これらは復号器へ渡す入力を整える仕組みであり、映像出力の証明ではない。
  • M ビット、タイムスタンプ、DON、PLI、FIR はそれぞれ異なる限定的事実を示す。視聴可能性を語るには表示面までの独立した受領証が要る。

分割された NAL の最後の FU が届いた。この観測だけを見れば、処理は終わったように感じられる。しかし途中の FU が一つ欠けていれば、終端片は完全性を取り戻さない。RFC 9584 が示す重要な教訓は、境界を示すビットと、その境界内の全データが存在することを混同してはならない、という点にある。

2024年6月に標準化過程の RFC として公開された RFC 9584 は、Essential Video Coding を RTP で運ぶための形式を規定する。一つの NAL を一つの RTP パケットに入れる方法、同じアクセスユニットの複数 NAL をまとめる方法、大きな NAL を複数パケットに分ける方法がある。H.264、HEVC、VVC の既知の設計を受け継いでおり、ワーキンググループの記録も円滑な合意を示す。だが、設計の系譜と実装間の成功は別の証拠である。

RTP の連番は送信順序の復元に役立つ。欠番がなければ受信成功、とまでは言えない。観測点自体が欠落を共有する場合もあり、端末が後段でパケットを捨てる場合もある。M ビットはアクセスユニットの最後のパケットを示すが、それ以前のパケットがすべて届いたという署名ではない。90 kHz のタイムスタンプは表示時刻の基準であって、期限内に表示されたことを報告する値ではない。

集約パケットは、同じアクセスユニットの NAL を二つ以上、復号順で保持する。FU を内包できず、集約の入れ子も許されない。この制約によってパケット形式は明確になる。それでも、内部の NAL が不正、必要な SPS・PPS・APS が未取得、あるいは受信側が profile や toolset を扱えない可能性は残る。パケット構造の妥当性は、コーデック状態の妥当性を代行しない。

分割ユニットでは S と E が開始と終了を表す。連続した FU のペイロードを順番に連結して初めて NAL が再構成される。途中が失われた場合、受信側は通常、その NAL に属する後続 FU を捨てる。例外は、不完全な NAL を安全に扱えると分かっている復号器である。したがって、FU の受信ログは再構成処理の材料であり、完成した NAL の領収書ではない。

DONL と DOND から導かれる AbsDon は、NAL を復号器へ渡す順序を表す。差が一である必要はない。ゲートウェイが上位時間層や一部 SEI を転送しないことがあるからだ。同じ値なら順序がどちらでもよい場合もある。復号順の確定後にも、参照画像、メモリ、構文、セキュリティ、出力順序という検査が続く。

受信側のバッファも一種類ではない。RFC 9584 のデパケタイズ用バッファは NAL の抽出、再構成、並べ替えを担う。一方、実用的な受信系はネットワーク遅延変動に備えるジッターバッファも必要とする。前者に空きがあっても、後者や復号キュー、レンダリングキューの遅れで表示期限を失うことはある。「バッファ正常」という一項目では、どこが支配点か分からない。

PLI は一枚以上の画像に属する符号化データが不明量失われたことを送信側へ伝える。FIR は IDR 画像を要求し、帯域外で既に確立していない限りパラメータセットも必要になる。要求の送信、IDR の送出、到着、復号、画面反映は五つの別イベントである。最初のイベントを最後の結果として数えるべきではない。

仕様は、ペイロード形式だけでは完全なシステムにならないと明記する。RTP は資源予約も QoS 保証もしない。機密性、完全性、送信元真正性はアプリケーションが選ぶセキュリティ機構に依存する。IANA の video/EVC 登録は割当ての整合を示すだけで、製品実装や運用成功の証明ではない。

運用上の受領証は段階化されるべきだ。対象端末でのパケット観測、送信元と完全性の確認、全分片の存在、NAL 再構成、復号順整列、パラメータと能力の適合、復号画像の生成、提示期限、レンダラーの commit、表示面の更新である。上流の事実は次の処理を開始させられるが、下流の結果を宣言する権限までは持たない。

情報源