Summary

  • FIR は、通常の画像損失を直す一般的な信号ではなく、新規参加や MCU の送信源切替など、リフレッシュがなければ映像を利用できない場面の制御要求である。
  • 同じ FIR が届いたこと、エンコーダが刷新を開始したこと、受信側で完全な刷新が認識されたこと、画面が表示されたことは、それぞれ別の証拠である。

会議に入ったばかりの参加者の画面には、壊れた最初のフレームが残っている。制御サービスはただちに FIR を送り、八ビットの系列番号を保存し、チケットを「処理済み」にする。送信元は IDR を生成したと記録する。それでも受信者は動く映像を見ていない。この時点で、どの記録が間違っているのだろうか。答えは、どれも自分の層では正しくなり得る、である。

RFC 5104 は AVPF に、媒体に近い編解码制御メッセージを追加した。FIR はデコーダ・リフレッシュ・ポイントを要求する。TSTR と TSTN は時間解像度と空間解像度の選好をやり取りし、VBCM は H.271 情報を運び、TMMBR と TMMBN は一時的な最大総媒体ビットレートとその境界集合を扱う。これらは同じ「確認」ボタンの別名ではない。

新規参加者は FIR の代表的な利用場面だ。定期的なリフレッシュを持たない符号化ストリームの途中から参加した受信者は、予測参照が揃うまで画像を復元できない。MCU が別の符号化送信源へ切り替えた場合も同じである。刷新がなければ利用不能が続くため、受信側は送信側に既知状態への入口を求める。

一方、通常の画像損失に FIR を投げ続けるのは設計意図ではない。RFC 4585 の Picture Loss Indication が一般的な損失通知として推奨される。リフレッシュ画像は予測画像より大きくなり得る。損失のたびに FIR を送れば帯域を押し上げ、フレームレートを落とし、映像のぎこちなさを自ら増幅しかねない。

FIR の制御範囲は明確である。項目には対象となる媒体送信側の SSRC と、八ビットの系列番号が入る。番号空間は、FIR を送る SSRC と対象 SSRC の組に属する。新しい要求では一つ進み、255 の次は 0 に戻る。同一要求の再送は同じ値を保つ。

この規則は、遅れて届いたコピーを新命令と取り違えず、エンコーダが重複した高コスト処理を避けるためのものだ。番号はデコーダの世代ではない。エンコーダが要求を受理したか、どの RTP パケットを作ったか、受信側で何が失われたか、表示されたフレームが何かは符号化されていない。

リフレッシュ・ポイントは、単にログに現れる「IDR sent」という文字列でもない。RFC は、デコーダを既知状態へ完全に戻せるビット列として扱う。ひとつまたは複数の RTP パケットにまたがり、イントラ画像、IDR、段階的な刷新になり得る。後続画像が上位パラメータを必要とするなら、それも帯域内で受信可能でなければならない。RFC 6184 の H.264 負荷形式を見れば、パケット化された完全性が単一の送信ログに還元できない理由が分かる。

FIR を受けたエンコーダは、可能な限り速やかに刷新点を送る。ただし、拥塞制御を無視してよいとは書かれていない。刷新画像は通常の予測画像の何倍にもなり、許容ビットレートが低ければ一フレーム周期より長く送信にかかる。受信者が凍結画面を見る時間と、制御サービスが要求を記録する時間は自然にずれる。

再送機構はこの不確実性を前提にする。要求側は、求めた刷新を受け取るまで同じ FIR を繰り返せる。しかし、完全な刷新を受け取った場合だけでなく、刷新の試みが損失で壊れたと認識した場合にも繰り返しを止める。停止したという観測だけでは成功と失敗を区別できない。

損傷後も刷新が必要なら、要求側は系列番号を進めて別の FIR を作る。一つの媒体送信側について、異なる FIR は同時に一件だけ未完了にできる。また、エンコーダが刷新を送った後も二往復時間を超えて同じ要求の反復が続くなら、エンコーダは別の刷新点を送る。これは到達確率を上げるが、表示確認にはならない。

RFC 5104 が FIR 用の明示的な成功通知を設けないのは、刷新点をビットストリームから識別できるためである。要求側は制御面の自己申告ではなく、データ経路を観察できる。この設計は厳しいが有用だ。行為の証拠を、実際に行為が現れる層へ置くからである。

ただし、ビットストリーム上の認識も最終結果ではない。コーデックを理解する受信観測器は、対象ストリームの刷新が完全か、損傷した試みかを記録できる。デコーダ自身は参照状態のリセットを記録できる。レンダラはフレーム提示を記録できる。アプリケーションは新規参加者に利用可能な映像が戻った時刻を定義できる。これらを一つの緑ランプへ早々に潰してはいけない。

MCU が入ると、保管すべき範囲はさらに分かれる。RFC 5117 の多地点トポロジでは、MCU は受信者の FIR を受け、現在選択中の原送信側へ別の FIR を出すことがある。RFC 5104 は、受信者から MCU、MCU から原送信側の信頼性を独立に扱う。

第一の FIR が MCU に届いても、第二の FIR が送信源に届いたとは限らない。送信源の刷新が MCU に届いても、MCU が元の要求者へ完全に転送したとは限らない。途中で選択先が変われば、正しい刷新が別の表示期間に属する場合もある。各区間は SSRC、系列番号、安全文脈、時計、媒体観測を別に持つ必要がある。

TSTR/TSTN は異なる制御契約の好例だ。TSTR は時間・空間品質の取舍変更を求め、TSTN は送信側が実際に選んだ値を通知する。複数受信者の希望、ローカル方針、利用資源を調整するため、返る値は要求値と一致しなくてもよい。通知を受けたことは、要求がそのまま実行された証明ではない。

TMMBR/TMMBN も別物である。受信側は一時的な最大総媒体ビットレートとパケット当たりのオーバーヘッドを示し、送信側は実行可能領域の境界を作るタプル集合を通知する。新しいタプルが集合に入らなくても TMMBN の応答は必要だ。応答の存在を採用や品質改善と読むのは誤りになる。

観測位置によって総媒体ビットレートも変わる。送受信でプロトコル層が異なれば、数えるオーバーヘッドが異なる。TMMBR は既知の制約を表すが、経路全体の保証ではない。RFC 8083 が扱うように、RTCP フィードバックは混雑制御と共存しなければならない。

安全性は制御の出所を強くする。偽造フィードバックは、極端に低いビットレートを押し付け、境界所有者を偽り、不要な解像度選好を与え、過剰な刷新で映像を乱せる。そこで RFC 3711 の Secure RTP と RFC 5124 の SAVPF が提供する認証・完全性の文脈が重要になる。

しかし認証済み FIR は、正しい主体が正しい保護経路で命令した証拠に留まる。後続パケットが届いたこと、デコーダがリセットされたこと、画面が表示されたことまでは署名しない。真正性と実行結果を混ぜると、侵害の検知にもサービス障害の分析にも使えない記録になる。

RFC 5104 は Proposed Standard であり、RFC 7728 の RTP ストリーム一時停止・再開と、RFC 8082 の階層化コーデック制御によって更新されている。原文の語彙だけを実装し、交渉された層や停止状態を保存しない収集系は、仕様番号を表示できても現在の動作を説明できない。

運用記録は、RTP セッションと安全文脈、FIR の送信元・対象 SSRC、要求系列、最初の送信と反復、MCU 区間、エンコーダ受領、コーデック固有の刷新生成、RTP パケット範囲と欠落、完全または損傷の認識、デコーダ・リセット、提示フレーム、アプリケーションの復旧判断を結ぶべきだ。時計誤差と切替時点も残す。ただし証拠のために映像内容そのものを保存する必要はない。

Lu Heng の現実層という考え方なら、制御記録、媒体記録、デコーダ記録、表示記録は互いに関連しても、互いの代わりにはならない。リーダーシップの仕事は全層を一つの権威へ押し込むことではなく、各層が何を観測したかを保ったまま、サービス判断に必要な結合条件を定めることである。

Sources