要約

  • RFC 3984では、H.264の映像を運ぶNALユニットと、それを解釈するシーケンス／ピクチャ・パラメータセットは別の状態として扱われた。sliceは規則を指せても、規則を同時に運ぶとは限らない。
  • 識別子を早く再利用すると、ネットワークやバッファに残る古いsliceが新しい意味で解釈される。問題はパケット破損ではなく、参照先の時間的なすり替わりである。

復号失敗の記録に、一つの番号だけが残っている。送信時、その番号は旧しいピクチャ・パラメータセットを指していた。受信時には同じ番号が新しい設定へ書き換えられていた。NALユニットのビット列にもRTPの順序にも異常がなくても、参照の意味は同一ではない。

RFC 3984は2005年2月、H.264映像をRTPで運ぶ形式を定義した。ステータス、正誤表、Datatrackerの履歴によれば、後にRFC 6184がこれを置き換えた。この文書を断片化や集約の仕様としてだけ読むと、より深い設計課題を見落とす。映像の内容と、その内容を読めるようにするデコーダ状態は、別々に移動し得る。

H.264は複数のsliceで共用する情報をパラメータセットへ分離する。SPSは符号化映像シーケンスの性質を、PPSは符号化ピクチャで用いる性質を保持する。画像寸法、符号化モード、マクロブロックとsliceグループの対応などが含まれ得る。sliceヘッダーはそれらを全部繰り返さず、識別子で選ぶ。

この間接参照は効率と引き換えに寿命管理を要求する。参照されるSPS/PPSは、依存NALユニットより前に復号順で利用可能でなければならない。識別子が届いたことは定義が届いたことではなく、定義が届いたことは正しい版が有効になったことでもない。

RFC 3550のRTPフィールドは別の証拠を提供する。シーケンス番号は損失検出や順序復元に、タイムスタンプはサンプリング時刻と同期に用いられる。ステータス、正誤表、Datatrackerを見ても、SPS/PPSの版や所有者を示す機能はない。パケット列が整っていても、参照表が整っているとは限らない。

RFC 3984はパラメータセット配布を三つの原則に整理した。原則AはRTP開始前に信頼できる帯域外経路で渡す。原則Bはセッション中の更新を信頼できる帯域外経路で渡す。原則CはRTPストリーム内で渡す。2005年の文書はAとBの帯域外方式を推奨し、帯域内では反復、再送、前方誤り訂正などの保護を検討した。一つの設定損失が多数の後続NALユニットに及ぶためである。

初期設定を表す sprop-parameter-sets は、base64化されたパラメータセットNALユニットを媒体記述に置けた。そこに含まれるセットは、それを参照するNALユニットより復号順で先行しなければならない。また、これは能力表明ではない。送信側が使う予定の状態を示すのであって、受信側が対応可能な全構成を列挙したものではない。

帯域外の状態はシグナリングと結び付く。RFC 4566とそのステータス、正誤表、Datatracker記録はSDPをセッション記述形式として定義する。RFC 3264はoffer/answerを定め、未完了offerを一つに制限する。そのステータス、正誤表、履歴は交渉を直列化する境界を示す。

RFC 3984は、セッション中に帯域外で設定を更新するなら、送信側はそのシグナリングの確認後に依存NALユニットを送るべきだとした。確認は重要だが、製品内部で何を意味するかは別途定義が要る。メッセージ受領、構文検証、メモリ格納、有効化、最終描画は一つの出来事ではない。

識別子の上書きは、この出来事の差を危険にする。古いPPSを参照するsliceが経路やジッタバッファに残る間に同じIDへ新PPSを入れると、古いsliceが新しい規則を引く。チェックサムは通り得る。RTP順序も回復できる。それでも意味は壊れる。

そこで文書は、十分長く使われていないIDを選ぶか、新しいIDを追加する考え方を示した。安全期間には通信時間だけでなく、再順序化、受信キュー、デコーダ内部の保持を含めなければならない。設定の寿命は書き手だけでは決められず、最後の依存データが消えるまで続く。

多地点通信では識別子の所有権も必要になる。二つのエンコーダが同じIDへ異なるPPSを割り当てても、各送信源の内部だけなら整合している。しかし合流点では一つの名前に二つの意味が生じる。ミキサーやゲートウェイは範囲を分け、参照を書き換え、あるいは復号文脈を隔離しなければならない。

帯域外更新の原則Bと帯域内更新の原則Cを同期なしで混ぜることもRFC 3984は避けた。途中参加者は初期SDPを持っていても、すでにストリームを通過した更新を持たない。更新を失った受信側は、後続映像パケットを正常に受けながら古い状態を維持する。経路ごとにID範囲を分割すれば同名衝突は減るが、更新の到達確認までは代替しない。

後継の RFC 6184 はこの歴史的な選好を変更した。ステータス、正誤表、Datatracker履歴が示すように、帯域内・帯域外の双方を認め、in-band-parameter-sets などの交渉を追加した。したがって、RFC 3984から「常に帯域外が正しい」と結論してはならない。持続した原則は、選んだ方式と切替順序を明示することである。

RFC 7798は後にHEVCのRTP負荷形式を扱った。ステータス、正誤表、Datatrackerにもパラメータセットの課題が現れる。これは問題類型の継続を比較できる資料であり、実装普及や全製品の同一動作を証明するものではない。

セキュリティでも小さな識別子の背後に大きな権限がある。通常の映像NALが壊れれば影響範囲は限定されるかもしれないが、偽のパラメータセットは多数の将来NALの解釈を変えられる。RFC 3984が完全性保護と送信元認証を論じる理由は、この非対称な波及にある。

事後検証では、RTPキャプチャだけでなくSDP交換、確認、全SPS/PPS版、ID割当主体、ペイロードタイプ切替、受信バッファの時間幅を保存する必要がある。「同じIDがある」という記録では足りない。その瞬間にどの定義が入っていたかを示せなければ、デコーダが実際に使った規則は復元できない。

RFC 3984の歴史的価値は、番号の意味にも時間があると示した点にある。データが正しく届くことと、参照先が正しい状態で存続することは別の責任である。安定した映像は、パケット配送だけでなく、版、所有権、確認、排出期限を持つ設定状態機械によって初めて成立する。

出典