要約
- RFC 9628は、予測ピクチャごとに最大三つの
P_DIFFを載せる柔軟モードと、SSで反復するPicture Groupを宣言する非柔軟モードを定義する。 - Picture ID、レイヤー情報、フレーム境界、Markerは送信側が表した構造を説明する。全RTP断片、参照ピクチャ、codec内部状態、デコード結果、表示結果までは保証しない。
- 運用上の受領証には、SDPの文脈、モードと構造の世代、パケット網羅、実在する参照の閉包、bitstream検証、decoder出力、playoutを結合する必要がある。
ある受信ログでは、Eが立ったパケットもMarkerが立ったパケットも到着していた。Picture IDをたどれば参照先も見つかった。監視画面は一連の処理を「完了」とした。
しかし、その利用者の画面に次の絵は出なかった。
ここで不足していたのはフィールドではなく、フィールドが証明できる範囲の理解である。RFC 9628 はVP9をRTPで運び、時間・空間スケーラビリティを観測可能にする。構造を説明する仕様であって、受信機のメモリや画面を遠隔から証言する仕様ではない。
柔軟モードは現在のパケットに参照を載せる
F=1ではPicture IDが必須となる。予測を使うピクチャは、一個以上三個以下のP_DIFFを持つ。現在のPIDから差分を引き、七または十五ビットの空間で剰余計算すると、参照する過去のピクチャが得られる。ゼロ差分は無効である。
参照がピクチャと一緒に来るため、encoderは時間階層を動的に変えられる。middleboxは固定周期を先に知ることなく、その時点で宣言された関係を読める。
ただし、参照先の番号が分かることと、そのピクチャがreceiverに残っていることは別である。ネットワーク損失、許可された選択破棄、buffer退避のいずれでも参照は消える。現在のframe自身も、BとEの間の一片を失っているかもしれない。
従って、P_DIFFの検査は送信側の宣言グラフを作る。デコード可能性を判定するには、受信側が実際に保持するグラフとの照合が要る。
非柔軟モードは過去の宣言を借りる
F=0では、同じ依存パターンを繰り返すPicture GroupをSSに事前記述できる。各位置はTID、up-switch点、参照差分を持つ。key pictureのPIDが第一位置となり、以後のPIDはN_Gで循環する。
時間ベース層にはTL0PICIDXもある。TID=0のピクチャで増え、高い時間層ではどのベースピクチャに依存するかを示す。八ビットなので255の後にゼロへ戻る。
この方式はheaderを小さくする代わりに、観測者へ履歴を要求する。途中参加の解析器は、有効なSSやkey pictureの位相を知らないまま、整ったPID列だけを見ることがある。SFUが再起動してpacket転送を再開しても、構造世代を失えば同じグループを一位置ずれて読む可能性がある。
RFCはモード変更をkey pictureの最初のpacketに限定し、SS更新にも前のグループが定める境界を課す。監査でも同じ境界を保存すべきだ。SSのhash、導入packet、anchor PID、N_G、算出位相を一つの世代として残さなければ、後続PIDの意味は再現できない。
PIDは局所座標であり、永久番号ではない
Picture IDは七または十五ビットで、無作為な値から始まり、上限でwrapする。session中に幅が変わることもある。七から十五へはzero extension、十五から七へはtruncationが定められており、receiverは幅が固定だと仮定できない。
一つのpictureを構成する複数の空間frameは同じPIDを持つ。一方、表示しないshow_frame=0のpictureにも独立PIDが割り当てられる。PIDはviewerが見た一枚の通し番号ではない。
さらに、scalability構造が許す範囲でmiddleboxはpictureを落とせるため、受信PIDには正当な飛びが生じる。飛びは必ずしもlossではなく、連続は必ずしも完全受信ではない。frame内のRTP欠落はPIDの連続性に現れないからだ。
証拠として使うなら、session、SSRC、RTP timestamp、PID幅、mode世代、layer、観測地点を組にする必要がある。数字だけを保存すると、wrap後の別pictureに古い意味を貼ってしまう。
Eは終端であって、完全性ではない
VP9 frameの最初のpacketにはB=1、最後にはE=1が立つ。RTP Markerは、そのpictureに含まれる最上位空間layer frameの最終packetを示す。上位layerを除去する書換えでは、残した対象layerの最後へMarkerを移さなければならない。
これは組立境界の規則である。Eを受け取っても、その前のsequence numberが全て届いたとは限らない。Markerを受け取っても、D=1で必要な下位空間frameが完全とは限らない。正しいMarker書換えと、古い参照pictureの欠落も両立する。
このpayload formatにはframeの一部を細かく利用する仕組みがない。完全性の主張には、BからEまでのRTP coverage、同一timestamp、空間layer順序、書換え後のMarkerを別途確認する必要がある。
Headerのグラフから見えないcodec状態
VP9は参照frame以外に、entropy codingやtree codingの確率tableも過去から引き継ぐ。error_resilient_modeはこの追加状態をresetする。
scalable streamでは、正当に除去され得るframeの状態へ後続frameが依存しないようencoderが構成しなければならない。特にbase spatial layerと、inter-layer dependencyを使う上位layerでは条件が異なる。
このため、参照pictureの閉包はデコード可能性の十分条件ではない。P_DIFFもPG位相も正しいのに、削除されたframe由来の確率状態が必要な場合がある。VP9 bitstream仕様による検証と実際のdecoder結果を追加して初めて、その境界を越えられる。
Payload descriptorは索引である。索引が整っていることと、本の全ページが読めることを同じにしてはならない。
レイヤービットは狭い判断を支える
TIDとSIDは時間・空間layerを示す。Dは同じpictureの直下空間frameへの依存を示す。Uはup-switch点であり、その後の高時間層が一定の古い高時間層pictureに依存しないと告げる。Zは上位空間layerが現在frameを参照しないため、目的によっては捨てられることを示す。
どれも画質の受領印ではない。U=1でもそのpacketが失われれば切替点は届かない。Z=1でも、破棄が利用者の希望やSLAに合うとは限らない。SID=2だけでは表示解像度は決まらない。D=0でも時間方向の参照は残る。
SFUはbitの値だけでなく、自身の決定を記録すべきである。対象layer、適用rule、dropとforward、Marker書換え、congestion理由があって初めて、許可された操作と実際の結果を結び直せる。
RPSIはdecoderの証言だが、画面の証言ではない
RPSIは、正しくdecodeしたgolden frameまたはaltref frameのPicture IDをreceiverから返せる。loss後に好ましい参照を示す用途もある。送信側headerの解析だけより一段強く、decoder側から発せられる証拠である。
それでも、全空間layerが利用可能だったこと、applicationがplayoutに選んだこと、期限内にrenderしたことまでは述べない。FIRは全状態refreshを求め、LRRは一部layerをrefreshする。命令、構造応答、decode acknowledgment、表示完了は別のeventである。
RFC 9627の記事がcommandからrefreshまでの境界を扱うのに対し、ここではRFC 9628の依存記述が、どこまでreceiverの判断を助け、どこから先を証明できないかを扱う。
SDPがdescriptorの辞書を決める
VP9はdynamic payload typeと90 kHz clockでSDPに対応付けられる。profile-idはoffer/answerで対称でなければならず、省略時はProfile 0となる。max-frとmax-fsはreceiver能力の宣言であり、後のstreamやdecodeの測定値ではない。
pre-encoded mediaやselective forwardingでは、宣言範囲に合う素材を用意できない例外も規定される。従って、offerが受理されたという事実から、すべてのframeが能力内だったとは言えない。
解析記録はoffer、answer、payload mapping、profile、能力、SSRC、renegotiationから始める必要がある。会話の辞書を失ったpayload typeは、構文として読めても意味を誤る。
情報源
- Heng Lu — Minimum Initial Specification
- Heng Lu — Running-Code Primacy
- IETF Datatracker — RFC 9628履歴
- VP9 Bitstream and Decoding Process Specification v0.6
- IANA — RTP Parameters
- RFC 3264 — Offer/Answer
- RFC 3550 — RTP
- RFC 4585 — RTP/AVPF feedback
- RFC 5104 — codec control feedback
- RFC 7667 — RTP topologies
- RFC 8866 — SDP
- RFC 9626 — Video Frame Marking
- RFC 9627 — Layer Refresh Request
- RFC 9628 — status
- RFC 9628 — HTML
- RFC 9628 — canonical text
- RFC 9628 — canonical XML
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

