要約

  • RFC 9627 は、階層映像の一部だけを更新する RTCP コマンドを定め、全体を更新する Full Intra Request より限定的なレイヤー昇格を可能にする。
  • 送信元・対象 SSRC、payload type、現在・目標レイヤー、シーケンス番号は要求の同一性を示す。受理、符号化、配送、デコーダー状態、画面品質の証明ではない。
  • 完結した運用記録には、能力交渉、権限、妥当性検査、輻輳下の待機、codec 固有の更新点、受信確認、デコード遷移、表示期限が必要である。

障害の時間軸に、同じシーケンス番号の LRR が三回並んでいた。二回目と三回目は重複だから消してよい、という判断は半分だけ正しい。意図は一つでも、その意図が未完了だった時間こそ重要だからだ。

RFC 9627 は Layer Refresh Request を、以前は捨てていたレイヤーを受信側が新たにデコードできるよう、送信側へ更新点を求めるメッセージとして定義する。再送規則は要求を整理する。しかし結果を代弁しない。

更新点は参照関係の切れ目である

空間的な上位レイヤーは、同時刻の下位レイヤーだけでなく、自分の過去画像にも依存し得る。更新時には、更新画像が現在の下位レイヤーだけを参照し、自レイヤーの古い画像を参照しない。さらにエンコーダーは、その古い画像を今後の参照にも使わないと約束する。

対象外のレイヤーは過去への依存を残してよい。ここが FIR との違いである。RFC 8082 が階層 codec の FIR を明確化したように、FIR はより広いデコーダー更新を求める。LRR は必要な昇格に仕事を限定する。

時間レイヤーでは、対象レイヤーが自分の過去ではなく、低い時間レイヤーだけを参照する状態へ移る。通常から完全に temporal nesting されている構造なら、特別な更新点を待たず上位レイヤーを開始できる。その場合の temporal LRR は、可用性を増やさず制御負荷だけを増やす。

したがって、単に大きなフレームを見つけたり、一般的な keyframe イベントを数えたりしても不十分である。対象 codec とレイヤーに必要な参照の切断が成立したかを見なければならない。

要求には、解釈に必要な住所がある

LRR は RTCP の Payload-Specific Feedback で、FMT=10 として登録される。FCI には複数エントリーを置け、それぞれ別の media sender SSRC を対象にできる。共通ヘッダーの packet sender SSRC が要求元を示し、共通の media source 欄はゼロで、実際の対象は各エントリーに入る。

目標は TTID/TLID、すなわち時間レイヤーと空間・品質レイヤーの組で表す。payload type が、その数値をどの codec 規則で読むかを決める。交渉時の対応表を失えば、同じ数値列から元の意味を復元できない。

C=0 なら基底から目標までを更新する。C=1 なら CTID/CLID が現在デコード中と申告された最高レイヤーを示し、その位置以下は要求対象から外れる。目標はどちらの軸でも現在値を下回れず、少なくとも一方で上回らなければならない。不正な組は破棄される。

さらに送信側は、payload type とレイヤー番号が現在送っているストリームに有効かを検査する。形式が正しいことと、実行可能なコマンドであることは別である。SSRC が一致しても、ローカル方針による権限まで自動的に得るわけではない。

現在値にも限界がある。CTID/CLID は要求時点で受信側が述べた状態であり、処理後のデコーダーを観測した値ではない。要求 tuple は開始条件を説明するが、終了条件を署名しない。

シーケンス番号が証明する範囲

八ビットの番号空間は、command source SSRC と command target SSRC の組ごとに独立する。新しいコマンドは 256 を法として一つ増え、同じコマンドの再送では増えない。初期値は任意である。

これは RFC 5104 の FIR 信頼性モデルを引き継ぐ。要求側は RTCP の時間規則に従って未決要求を再送できる。完全な更新点、またはパケット損失で壊れた更新の試みを検出すれば再送を止める。後の別要求には新番号を使う。

この番号は、「同じ要求がまだ未決か」「新しい意思か」を判別するのに強い。だが ACK ではない。エンコーダーの受理、実行時刻、生成フレーム、配送、デコード結果のどれも含まない。

また 256 回で値は巡回する。セッション、時刻、SSRC の組、payload type、レイヤー tuple を残さず番号だけを保存すると、離れた二つの要求を同一視する危険がある。

輻輳制御には待たせる権限がある

有効な LRR を受けたエンコーダーは、可能な限り早く decoder refresh point を送らなければならない。同時に、輻輳制御が与える帯域制限を守らなければならない。更新フレームは通常より大きいことが多く、即時送信できない場合がある。

これは曖昧さではなく権限分離である。受信側は昇格を望む。正方向の容量管理は、その追加負荷をいつ許せるか判断する。要求受理時に「完了」と記録すると、この衝突が見えなくなる。

運用状態は、受信、無効、権限拒否、受理、帯域待ち、予定、符号化済み、送信済み、到達、更新認識、デコード、表示に分けるべきだ。輻輳上は正しい遅延でも、アプリケーションの期限には失敗し得る。

目的も分離する。RFC 9627 は、パケット損失や破損への反応として LRR を送ることを禁じ、その用途には RFC 4585 の PLI を推奨する。LRR は、これまで捨てていたレイヤーを使い始めるという明示的な行動変更のためのものだ。二つの原因を混ぜれば、再送ログの意味も失われる。

codec ごとに終了判定が異なる

H.264 SVC では、時間、依存、品質の識別子を組み合わせる。空間・品質更新は、必要な全レイヤーで適切な表示をデコード順に確認して初めて完了する場合がある。複数レイヤーをまとめた PACSI の表示一つでは足りないこともある。

ここで扱う VP8 は時間スケーラビリティを持つ。Y bit は切替点を示すが、一レイヤーだけでなく全レイヤーの切替を意味するため、狭い要求にも余分な送信コストが生じ得る。

H.265 は nesting flag と NAL unit type を使い、即時または複数段階で更新できる。IRAP picture が条件を満たす場合もある。全 codec を一つの keyframe 検出で判定すれば、正しい実装と不完全な実装を取り違える。

RFC 9628 は VP9 に TID/SID を割り当て、応答 packet にレイヤーと参照情報を含めることを推奨する。受信側や中継が依存鎖を遡れるためだ。終了証拠とは、対象レイヤーが受信側にない過去を参照しないと示すことである。

RFC 9626 の frame marking とフィールド形式が揃っているのは観測に役立つ。ただし mark は LRR との因果や配送、デコードを保証しない。更新点が要求とは無関係に生じた可能性も残る。

情報源