3. 動機

この節では, 各種ビデオおよびメディア制御メッセージの動機と利用について述べる. ビデオ制御メッセージは長く議論されており, 要件文書が作成された [Basso]. その文書は期限切れであるが, 動機と要件を示すため関連箇所を引用する.

3.1. ユースケース

提案するフィードバックメッセージには複数の利用が考えられる. まず Basso ら [Basso] が提案したユースケースを見ていく. 一部のユースケースは言い換えられ, コメントが付されている.

1. RTP ビデオミキサは, 複数の符号化済みビデオソースを単一の符号化ビデオストリームに合成する. ビデオソースが追加されるたびに, RTP ミキサはビデオソースにデコーダ更新点 (decoder refresh point) を要求し, 新しいビデオソースのデータが占める混合画像の空間領域上で汚染のない予測連鎖を開始する必要がある.

2. RTP ビデオミキサは会議参加者から複数の符号化 RTP ビデオストリームを受信し, 出力 RTP ストリームに含めるストリームを動的に選択する. ビットストリームの切り替え時 (音声アクティベーションやユーザインタフェースなどで決定), ミキサはリモートソースにデコーダ更新点を要求し, フレーム間予測の参照データとして無関係なコンテンツを使わないようにする. デコーダ更新点を要求した後, ビデオミキサは現在の RTP ストリームの配送を止め, デコーダ更新点に属するデータを検出するまで新ソースの RTP ストリームを監視する. その時点で RTP ミキサは新しく選択したストリームの転送を受信者へ開始する.

3. アプリケーションはリモート符号器に, 時間解像度と空間解像度の望ましいトレードオフが変わったことを通知する必要がある. 例えばある利用者はフレームレートを高く空間品質を低く望み, 別の利用者は逆を望むことがある. この選択はコンテンツにも強く依存する. 多くの現在のビデオ会議システムは UI にスライダなどでこの選択を行う手段を提供する. ポイントツーポイント, 集中型マルチポイント, 非集中型マルチポイントで有用である.

4. Basso 文書のユースケース 4 は AVPF [RFC4585] で定義される Picture Loss Indication (PLI) にのみ当てはまり, ここでは再掲しない.

5. Basso 文書のユースケース 5 は "freeze picture request" として知られる機構に関する. 非信頼の前方 RTCP チャネル経由での freeze picture request 送信は問題があるとされている. よって本メモには freeze picture request は含めず, ユースケースの議論も再掲しない.

6. ビデオミキサは受信ビデオストリームの 1 つを参加者へ送るよう動的に選択し, ストリームのトランスレートを最小化しつつ可能な限り高いビットレートを全参加者に提供しようとする. その 1 つの方法は, 各エンドポイントが受け入れる最大ビットレートとミキサの呼接続制御が受け入れる値を用いてセッションを張ることである. セッション確立時に交渉した値より下へメディアストリーム最大ビットレートを下げるコマンドにより, ミキサはエンドポイントが送る最大ビットレートを受け入れ済みの最小値まで下げられる. 参加離脱やネットワーク輻輳で最小受入ビットレートが変わると, ミキサはエンドポイントが送れる上限を新しい値に合わせて調整できる. ミキサは特定メディアストリームについてセッション確立時に交渉した最大ビットレート以下の新たな最大ビットレートを要求し, リモートエンドポイントは実際に支えられるビットレートで応答できる.

Basso らが描く像は想定するほとんどのアプリケーションを覆う. ただし 2 つのユースケースを追加したい:

7. 現在展開されている輻輳制御アルゴリズム (AIMD および TCP Friendly Rate Control (TFRC) [RFC3448]) は送るものがある限り追加容量を探る. パケット損失を輻輳の指標とする輻輳制御では, この探索は一般にパケット損失と遅延増によりメディア品質を下げ (歪みが大きくメディアが使えなくなることも多い).

   多くの展開シナリオ, 特にセルラーでは, ボトルネックはしばしば最終ホップである. そのセルラーリンクには QoS 交渉があり端末が最終ホップで利用可能な最大ビットレートを知ることが多い. そのリンク背後のメディア受信者は, 現在接受信している各メディアストリームについて少なくとも利用可能ビットレートの上界をほとんどの場合 (すべてとは限らない) 計算できる. その方法は実装詳細であり本書では扱わない. 各メディアストリームについて利用可能最大ビットレートを送信側に示すことは, 既知の硬い上限を超えてそのストリームの帯域を探ることを防ぐのに有益である. セルラー等のモバイルでは, リンクビットレートから得た各ストリームの利用可能ビットレートは, 別伝送技術へのハンドオーバ, 輻輳による QoS 再交渉などで急速に変わり得る. サービス中断を最小にするには迅速な収束が必要であり, メディアパス上のシグナリングが望ましい.

8. 通常ポイントツーポイントセッションでは, 利用可能パス帯域内にメディアストリームを収める設定はメディア送信者の責任である. しかし一部のポイントツーポイントビデオでは, 受信者が最大メディアビットレートをさらに制限できる方が有利である. 例は受信者の描画能力の低下 (CPU 不足など) である. この場合受信者は送信者にメディアビットレートを処理可能な水準へ下げるよう通知したいことがある. 別の例はセッションを記録する受信者で, ストレージへの信頼書き込み速度を超えないようメディアレートを制限したい場合である.

3.2. メディアパスの利用

上記ユースケースを支えるにはシグナリングチャネル (例: SIP) でメディアストリーム定義を再交渉できる. しかし欠点がいくつかある.

第一に, シグナリング経由のパラメータ再交渉は遅いことがある. 一部制御プロトコル (H.323 など) では既存チャネルの解体と新規セットアップが別段階であり, メディア再生に "ギャップ" が生じうる.

第二に, 制御チャネルはメディアパス (多くは UDP/RTP) とは異なるプロトコル (多くは TCP) を使う. 多くのトポロジでシグナリングの "パス" はメディアのパスと異なる. NAT-fw 等の middlebox があると, 制御チャネルはメディアパス特性の変化に反応できないか, メディアパスを認識しないことがある.

第三に, シグナリングでメディアパラメータを再交渉するのはしばしば重い.

したがって, メディアの制御をメディアパス上で軽量かつ高速に行うのが有利である.

3.3. AVPF の利用

フィードバックメッセージには AVPF プロファイル [RFC4585] を用いる. (RTCP でフィードバックを送る理由は [RFC4585] を参照.) AVPF はフィードバックメッセージを送るための有効な RTCP パケット型と動作モードを提供する.

3.3.1. 信頼性

AVPF は組み込みの信頼性を提供しない. 確認パケット, 再送, その他の信頼性機構はマルチキャストでは実装・利用が難しい.

本書で定義するメッセージでは, フィードバック送信者が受信しているストリームを監視する設計を選んだ. フィードバックが失われたかメディア送信者がまだ反応していない場合, フィードバック送信者 (例: メディア受信者) は変更された RTP ストリームという形の期待される反応を見ない. その場合フィードバック送信者はメッセージを再送すべきである. 再送間隔は AVPF のタイミング規則に従う. ただし信頼性を要しないメッセージ (通知) もあり, 他はメッセージの繰り返しで信頼性を満たす.

3.4. マルチキャスト

本書で定義するフィードバックメッセージは主にポイントツーポイントと集中型マルチポイント向けである. 非集中型マルチキャストでの使用は禁止されていない. ただしそのような場面では効果を十分理解する必要がある.

マルチキャストではメディア送信者は同一ビットストリームを全受信者へ送る. ある受信者が低いビットレートやイントラ画像を要求すると, それを満たすとセッション内の他の全受信者に影響する. 望ましくない場合がある.

また AVPF ではマルチキャストセッションの全 RTCP パケットを全参加者へ送る必要がある. つまりある受信者のフィードバックは他の全受信者から見える. 多数が同時に同じメッセージを送るとフィードバックの氾濫になりうる. AVPF のタイミング規則はこれを防ぐが完璧ではない.

3.5. フィードバックメッセージ

この節では本仕様で定義するフィードバックメッセージの概要を述べる. 形式定義はセクション 4 である.

3.5.1. Full Intra Request コマンド

Full Intra Request (FIR) コマンドは, メディア送信者にできるだけ早くデコーダ更新点 (ビデオではイントラ画像) を送る必要があることを示す. セクション 3.1 のユースケース 1 と 2 が主な動機である.

FIR メッセージは [RFC4585] の Picture Loss Indication (PLI) に似ているが微妙に異なる. PLI は受信者がデータを失い画像を復元したいときに使われる. 送信者はイントラを送るか, 他の手段 (受信者が持つデータが分かれば差分データなど) で復元できる. 一方 FIR は送信者にデコーダ更新点を送るよう 強制 するコマンドである. 受信者に 有効な参照画像がまったく ないとき, 例えばミキサでストリームを切り替えるときに必要である.

3.5.1.1. 信頼性

FIR はコマンドである. 失われるとビデオは壊れたまま (または空白) である. したがって FIR 送信者は通常, 受信ストリームにデコーダ更新点が見えるまで繰り返す. 繰り返しには AVPF のタイミング規則が適用される.

3.5.2. Temporal-Spatial Trade-off Request and Notification

Temporal-Spatial Trade-off Request (TSTR) と Notification (TSTN) は, メディア受信者が時間解像度 (フレームレート) と空間解像度 (画質) のトレードオフの好みを通知するために使う. ユースケース 3 に対応する.

トレードオフは 0 から 31 の整数で表し, 0 が最高の空間品質 (おそらく最低フレームレート), 31 が最高フレームレート (おそらく最低空間品質) である.

TSTR は受信者が特定のトレードオフを要求するために送る. TSTN は送信者が現在の設定を通知したり TSTR を確認するために送る.

3.5.2.1. ポイントツーポイント

受信者が TSTR を送り, 送信者が符号化を調整して TSTN で確認すると想定される.

3.5.2.2. マルチキャストまたはトランスレータによるポイントツーマルチポイント

複数受信者が矛盾する TSTR を送りうる. 送信者は対応を決める必要がある. 例えば最高フレームレート, 最高空間品質, 平均などを採用し, TSTN で実際の設定を全受信者に知らせる.

3.5.2.3. RTP ミキサを用いるポイントツーマルチポイント

ミキサは複数受信者の TSTR を扱い, 受信者ごとに異なるストリームを生成したり, 要求を集約して元の送信者へ 1 本の TSTR を送ったりできる.

3.5.2.4. 信頼性

TSTR と TSTN は要求と通知である. TSTR が失われると送信者はトレードオフを変えない. 受信者は TSTN が来ない・ストリームが変わらないなどで検知し TSTR を再送できる.

3.5.3. H.271 Video Back Channel Message

このメッセージは RTCP 内に ITU-T H.271 ビデオバックチャネルメッセージを運ぶ. H.271 でフィードバックする既存ビデオコーデックに有用である.

3.5.3.1. 信頼性

VBCM の信頼性はアプリケーション次第である. 一部の H.271 メッセージは信頼性を要し, 他は要さない. 本書の機構は RTCP レベルでは信頼性を提供しない. 必要なら再送はアプリケーションが扱う.

3.5.4. Temporary Maximum Media Stream Bit Rate Request and Notification

Temporary Maximum Media Stream Bit Rate Request (TMMBR, "timber" と発音) と Notification (TMMBN, "tim-ben" と発音) はメディアストリームのビットレートを制御する. ユースケース 6, 7, 8 に対応する.

TMMBR は受信者から送信者へ, メディアストリームのビットレートをある値に制限するよう要求する. TMMBN は送信者から受信者へ, 現在守っている最大ビットレートを通知する.

3.5.4.1. TMMBR を使うメディア受信者の動作

受信者は処理できる最大ビットレート (例: リンク容量に基づく) を推定し, その値を含む TMMBR を送る.

3.5.4.2. 現在の制限を確立するアルゴリズム

送信者は複数受信者から TMMBR を受け取りうる. これら要求の "bounding set" を計算する必要がある. 基本的に全受信者 (または関心のある集合) 間の最小要求ビットレートを見つけ, 送信レートをその値以下に制限する. アルゴリズムは受信 TMMBR の状態維持と現在の上限計算を述べる.

3.5.4.3. ミキサベースのマルチポイントでの TMMBR

ミキサは自分へ送るエンドポイント側では受信者, 自分から受け取るエンドポイント側では送信者として振る舞う. 着信ストリームのレート制限に TMMBR を使え, 自分が送る相手からの TMMBR は尊重しなければならない.

3.5.4.4. マルチキャストまたはトランスレータのポイントツーマルチポイントでの TMMBR

マルチキャストでは送信者は受信者群からの最低要求ビットレート (または別ポリシー) を尊重しなければならない.

3.5.4.5. ポイントツーポイントでの TMMBR

単純な場合: 受信者が上限を要求し, 送信者が従う.

3.5.4.6. 信頼性

TMMBR は要求である. TMMBN は確認としての通知である. 受信者が TMMBR を送り対応する TMMBN (またはレート低下) が得られなければ TMMBR を再送する.