要約

  • Frame IDとフィードバック状態は送信SSRC・受信SSRCの組ごとに成立する。どちらかが変われば列は再開し、以前の状態は破棄される。
  • 同じ数値を時代をまたいで連結すると、確認、参照保持、復旧の因果を捏造する。運用記録にはSSRCペア、時代、窓、応答時刻と後続結果が必要だ。

監視画面ではFrame ID 417が二度現れていた。最初の417には正のフィードバックがあり、二度目の417の直後に画面が乱れた。集計器は同じキーを使い、前の成功を後のセッションに引き継いだ。結果は「確認済み参照からの復旧失敗」だった。

実際には、その間に受信側SSRCが変わっていた。二つの417は同じ対象ではない。

AVTCOREの RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement は、Frame IDとフィードバック状態を送信側・受信側SSRCの組に固有とする。どちらかのSSRCが変わればFrame ID列は再開され、以前の状態はすべて捨てられる。それ以外の場合に、勝手な欠番やリセットは認めない。

Frame ID自体は16ビットで、識別対象ごとに送信順で一つ増え、上限の次はゼロへ循環する。受信側は任意の開始値を受け入れる。従って数値だけでは、通常の周回とSSRCによる時代更新も区別できない。シリアル番号の比較には文脈が要る。

対象文書は2026年7月6日付、2027年1月7日失効予定のrevision 01である。AVTCOREワーキンググループの現行Internet-Draftで、想定ステータスはInformational。DatatrackerはI-D Existsとし、document shepherd、担当Area Director、IESG評価、RFC番号、完了したIANA割当はいずれもない。RTCPはPT 205を使い、FMTはTBD、提案値は12である。標準化の現在地を、実装済み・相互接続済み・展開済みという主張に読み替えてはならない。

この「フレーム」は表示画像とは限らない

RTPヘッダー拡張は映像フレームの最後のパケットに付けることが推奨され、一つのフレームに二度以上付けてはならない。しかし草案のフレームは、後続単位が参照できるコーデック状態を更新する、デコード可能なビットストリーム単位である。通常の一枚だけでなく、非表示フレーム、独立デコード可能なタイルやスライスも含み得る。

Frame IDを「視聴者が見た一枚」と訳すと、識別段階ですでに証拠を膨らませる。受信、デコード予定、デコード完了、コンポジターへの投入、表示、知覚は別の境界だ。

FFRの00はFrame IDのみ、01はそのフレームに対する暗黙の単一要求、10は独立したFeedback StartとLengthを持つ要求、11は予約である。RTCP応答にはRフラグ、開始ID、8ビットの長さ、各フレーム一ビットの状態が入る。

一は「受信し、デコード済みまたはデコードする予定」を意味する。遅延を下げるため、完了前でも試行を保証すれば一を返せる。その後失敗した場合、捨てられるレイヤーであってもキーフレームを要求しなければならない。ゼロは未受信、未デコード、デコード予定なしをまとめる。どちらの値も単独では表示結果にならない。

時代を失うと因果も失う

記録キーをstream + Frame IDだけにすると、SSRC変更時に旧状態が新状態を汚染する。旧時代の正の一が、新時代の「デコード済み」として読み出されるかもしれない。逆に新時代のゼロが、旧時代の正常な参照を失敗として上書きすることもある。

最低限、送信SSRC、受信SSRC、その組から導く時代識別子、Frame ID、受信時刻、要求範囲、応答送信時刻を複合キーに含めるべきだ。16ビットの周回も、同じ時代のシリアル演算として処理しなければならない。

時代更新は監視上の不都合ではない。再起動、経路変更、参加者更新など、実体が変わったことを示す境界である。旧状態を捨てるという仕様は、新しい発話者に古い約束を負わせないための安全策でもある。

SDPでヘッダー拡張URIとrtcp-fbを広告しても、この境界は省略できない。SDPは能力の合意であり、特定時代に要求が送られ、応答され、デコードや復旧が成功した証拠ではない。

窓が保持するのは有限の履歴

受信側は連続したスライド窓を持つ。既定は255個、交渉可能な範囲は1から32767。単一RTCPメッセージのLengthは8ビットなので、255を超える窓には複数メッセージが必要になる。新しいIDであふれると古い状態はFIFOで破棄される。

要求が窓と一部だけ重なれば、応答の開始点は保持中の最古へ移る。全く重ならなければ、要求された開始点と長さゼロを返す。これは古い状態をもう保持していないという通知であり、損失や成功の判定ではない。送信側はその古いフレームを参照に使ってはならない。

RTCPのタイミングで応答が遅れる間にも窓は進む。応答は要求受信時ではなく送信時の窓から作る。1〜4への要求が3〜4だけを返すことは正しい。さらに新しい要求が先に来れば、古い保留要求を捨て、最新だけに応答することが推奨される。

時代、窓、時刻の三つを同時に残さなければ、「何を尋ねたか」「答えた時に何をまだ知っていたか」「どの発話者が答えたか」を分離できない。

参照の権限は受信側だけにない

Rフラグによる再同期では、受信側が最後に正しくデコードしたFrame IDを示し、可能なら最新受信IDまで状態を返す。これは受信側にとっての既知の良い参照である。

送信側は同じ参照が自分の参照バッファに残っているか確認しなければならない。残っていれば、その参照または受信側にもあると分かる別の参照から次を符号化する。残っていなければキーフレームを作るべきだ。受信側の記憶は送信側のバッファを復活させない。

resync-timeoutは1〜65535ミリ秒のデコード飢餓トリガーを表せるが、同じ時間内の回復を保証しない。status-window-sizeも受信状態の上限であり、エンコーダー参照容量の保証ではない。参照選択の後には、符号化、送信、配送、再構成、デコード、描画という実行が残る。

SSRC時代を正しく分けても、その後続を一つのrecovered=trueへ圧縮すれば同じ誤りが戻ってくる。

一つのSSRCにも複数の依存列があり得る

サイマルキャストなどの独立依存チェーンが一つのSSRC内で交互に現れる場合、後のFrame IDが正でも、別チェーンの前のIDがデコードされたとは限らない。最大確認IDだけを保存するモデルは穴を消す。

SFUやSFMは、各受信側への列を連続させるためFrame IDを書き換えることがある。草案は通常、全アクティブ受信側が確認するまで上流確認を出すべきでないとする。「全員」を主張するなら、その時点の受信者集合、各下流と上流のID対応、個別状態が必要だ。後から参加した者や集計対象外の者まで一ビットで代表することはできない。

受信者集合が変われば、SSRCを変えなくても集計の意味は変わる。従って時代管理はSSRCだけで完結せず、SFUの分母版も必要になる。

数値ではなく証拠の所属を保存する

Heng Luの現実層に照らすと、Frame IDと要求は象徴的な調整情報、窓と参照バッファは実行中の内部状態、配送・完了デコード・描画・視聴品質は観測結果である。数値が同じだからといって、層や時代の所属まで同じにはならない。

Minimum Initial Specificationとして必要なのは、SSRCペア、時代、ID、FFR、要求と応答の範囲・時刻、窓境界、ビットの正確な意味、Rフラグ、両端の参照可用性、後続動作である。コーデック全体を統一せずとも、この封筒は共有できる。

実コード試験では、SSRC更新の直前直後に同じ数値を作る、16ビットを周回させる、窓を応答前に進める、正の後でデコードを失敗させる、独立チェーンを交互に置く、送信参照を追い出す、SFU分母を変更する。期待結果は、古い時代が新しい時代へ漏れないことだ。

冒頭の417は、二度現れた同じ番号ではなく、二つの発話関係に属する別の事実だった。運用の成熟は番号を長く覚えることではない。どの番号が、誰と誰の間で、いつの状態を語ったかを忘れないことである。

Sources