6. RTCP フィードバックメッセージの形式

本節は低遅延 RTCP フィードバックメッセージの形式を定義する. メッセージは次の 3 カテゴリに分類される:

• トランスポート層 FB メッセージ
• ペイロード固有 FB メッセージ
• アプリケーション層 FB メッセージ

トランスポート層 FB は汎用フィードバック, すなわち特定のコーデックやアプリケーションに依存しない情報を運ぶ. トランスポート/RTP 層で生成・処理される想定である. 現在定義されているのは汎用否定確認 (NACK) のみである.

ペイロード固有 FB は特定のペイロードタイプに固有の情報を運び, コーデック「層」で生成・処理される. 本ドキュメントはすべてのペイロード固有 FB に共通のヘッダを定義する. 個別メッセージの定義は RTP ペイロード形式仕様または追加のフィードバック形式文書に委ねる.

アプリケーション層 FB は受信側アプリケーションから送信側アプリケーションへ透過的にフィードバックを運ぶ. 内容はトランスポート/RTP 層やコーデック層では処理されない想定である. 交換データは通常アプリケーションプロトコル仕様で定義され, アプリケーションが識別できるため外部情報は不要である. したがって本ドキュメントは共通ヘッダのみを定義する. プロトコル上, アプリケーション層 FB はペイロード固有 FB の特別な場合として扱われる.

注: メディア送信側で一部 FB を正しく処理するには, FB が参照するペイロードタイプを送信者が知る必要がある場合がある. 多くの場合, 単一ペイロードタイプのストリームから推測できる. 複数コーデック (音声と DTMF など) やコーデック変更時は, FB の一部としてペイロードタイプ情報を明示して伝える必要があることがある. これはすべてのペイロード固有およびアプリケーション層 FB に当てはまる. ペイロードタイプ情報の伝え方は各 FB の仕様で定める.

本ドキュメントはトランスポート層 FB を 2 つ, (動画向け) ペイロード固有 FB を 3 つ, およびアプリケーション層 FB 用コンテナを 1 つ定義する. 追加のトランスポート層およびペイロード固有 FB は他の文書で定義してもよい (MAY) が, IANA に登録しなければならない (MUST, セクション 9 「IANA Considerations」).

以下の各小節で上記 RTCP FB メッセージ種別の一般的な構文とセマンティクスを述べる.

6.1. フィードバックメッセージ共通パケット形式

すべての FB は図 3 の共通パケット形式を用いなければならない (MUST):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|   FMT   |       PT      |          length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  SSRC of packet sender                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  SSRC of media source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Feedback Control Information (FCI)                 |
|                                                               |

        Figure 3: Common Packet Format for Feedback Messages

V, P, SSRC, length は RTP 仕様 [1] で定義され, 意味は以下のとおり要約する.

version (V): 2 ビット — RTP バージョン (現在 2).

padding (P): 1 ビット — セットされていれば, 制御情報ではない末尾パディングオクテットがあり, length に含まれる.

Feedback message type (FMT): 5 ビット — FB メッセージの種別. 種別 (トランスポート層, ペイロード固有, アプリケーション層) 相対で解釈する. 各カテゴリの値は以下の各節で定義.

Payload type (PT): 8 ビット — RTCP パケットタイプで FB メッセージであることを示す. IANA が 2 値を定義:

Name	Value	Brief Description
RTPFB	205	Transport layer FB message
PSFB	206	Payload-specific FB message

Length: 16 ビット — ヘッダとパディングを含む本パケットの長さを 32 ビットワード数で表し 1 を引いた値. [1] の sender/receiver report の length と同様.

SSRC of packet sender: 32 ビット — 本パケット発信者の同期ソース識別子.

SSRC of media source: 32 ビット — 本フィードバックが関連するメディアソースの SSRC.

Feedback Control Information (FCI): 可変長 — 以下 3 節で種別ごとに追加情報を含めてよい (MAY) 内容を定める. さらなる FCI 内容は将来の文書で指定してもよい (MAY).

各 RTCP フィードバックパケットの FCI には少なくとも 1 つの FB が含まれなければならない (MUST). セクション 6.2 および 6.3 で, 1 つの FCI に複数 FB を圧縮してよい (MAY) かどうかを定める. 可能な場合, 同一タイプ (同一 FMT) でなければならない (MUST). 複数 FMT を伝えるには複数の RTCP FB メッセージを生成しなければならず (MUST), 同一複合 RTCP 内に連結することが望ましい (SHOULD).

6.2. トランスポート層フィードバックメッセージ

トランスポート層 FB は RTCP メッセージタイプ RTPFB で識別される.

本ドキュメントで定義する汎用トランスポート層 FB は Generic NACK のみである. FMT は次のとおり:

• 0: 未割当
• 1: Generic NACK
• 2-30: 未割当
• 31: 識別子空間拡張のため予約

以下の小節で本種別の FCI 形式を定義する. さらなる汎用 FB は将来定義してもよい (MAY).

6.2.1. Generic NACK

PT=RTPFB, FMT=1 で識別される.

FCI には少なくとも 1 つ, 複数の Generic NACK を含めてもよい (MAY).

1 つ以上の RTP パケット損失を, パケット識別子とビットマスクで示す.

下位トランスポートが送信者に類似のフィードバックを既に提供できる場合 (DCCP など), Generic NACK は用いないことが望ましい (SHOULD NOT).

FCI の構文は図 4:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PID                |             BLP               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: Syntax for the Generic NACK message

Packet ID (PID): 16 ビット — 失われたパケットの RTP シーケンス番号.

bitmask of following lost packets (BLP): 16 ビット — PID で示す RTP パケットに続く 16 パケットのいずれの損失も報告できる. 定義は [6] と同一. BLP の最下位ビットをビット 1, 最上位をビット 16 とすると, ビット i は, 受信者が RTP パケット番号 (PID+i) (mod 2^16) を受信しておらず損失として示すなら 1, そうでなければ 0. 送信者はビットが 0 だから受信したと仮定してはならない (MUST NOT). 例: PID と次パケットが共に失われた場合 BLP の最下位ビットは 1 になりうるが, 送信者は BLP のビット 2〜15 が 0 だから PID+2〜PID+16 を受信したと推論してはならない.

FB メッセージの length は 2+n としなければならない (MUST). n は FCI 内の Generic NACK の個数.

Generic NACK はシーケンス番号を通じてペイロードタイプを暗黙に参照する.

6.3. ペイロード固有フィードバックメッセージ

PT=PSFB として識別される. FMT の割当は次のとおり:

Value	Meaning
0	unassigned
1	Picture Loss Indication (PLI)
2	Slice Loss Indication (SLI)
3	Reference Picture Selection Indication (RPSI)
4-14	unassigned
15	Application layer FB (AFB) message
16-30	unassigned
31	reserved for future expansion of the sequence number space

以下でペイロード固有 FB の FCI 形式を定義する. セクション 6.4 でアプリケーション層 FB の FCI を定義する.

6.3.1. Picture Loss Indication (PLI)

PT=PSFB, FMT=1 である. FCI にはちょうど 1 つの PLI が含まれなければならない (MUST).

6.3.1.1. セマンティクス

デコーダは, 1 つ以上の画像に属する符号化動画データの不定量の損失をエンコーダに通知する. 画像間予測に基づく符号化では, PLI を受けたエンコーダは予測鎖が断たれた可能性に気づく. 送信者は再同期のためイントラ画像を送ってもよい (MAY) (事実上 [6] の FIR に近い) が, セクション 7 の輻輳制御を考慮しなければならず (MUST), イントラフレーム送信能力を制限しうる (MAY).

RFC 2032 [6] など他の RTP ペイロード仕様は一部コーデック向けに別フィードバックを定義する. 両方を支持するアプリケーションは, 送信時は本仕様の機構を用いなければならない (MUST). 後方互換のため, 当該ペイロード形式が要求するなら, 旧フィードバック方式の受信と反応能力も持つことが望ましい (SHOULD).

6.3.1.2. メッセージ形式

パラメータ不要. length は 2 でなければならず (MUST), FCI はあってはならない (MUST NOT). ペイロードタイプに依存しない.

6.3.1.3. タイミング規則

セクション 3 の規則に従う. PLI と他 FB を併用するシステムでは, PLI は他 FB ほど遅延に敏感でないため, PLI には Regular RTCP RR タイミングに従うことが望ましい場合がある.

6.3.1.4. 備考

PLI は通常フルイントラ画像の送信を引き起こす. イントラは予測 (インター) 画像の数倍大きく, 生成時刻に依存しないサイズである. 帯域制限リンクではイントラは典型フレーム時間の数倍の許容遅延を伴う. 例: 送信 10 fps でイントラがインターの 10 倍とすると, 約 1 秒の遅延を受け入れる. この環境では FB を特に早く送る必要性は低く, [2] の RTCP タイミング (Tmin=0) で次スロットを待っても性能を損なわない.

6.3.2. Slice Loss Indication (SLI)

PT=PSFB, FMT=2 である. FCI には少なくとも 1 つ, 複数の SLI を含めてもよい (MAY).

6.3.2.1. セマンティクス

スキャン順で 1 つ以上の連続マクロブロックの損失または破損をエンコーダに通知する. Annex Q 有効など, マクロブロックサイズが一様でなく動的に変わる動画コーデックには用いてはならない (MUST NOT). その場合エンコーダは破損空間領域を常に特定できない.

6.3.2.2. 形式

図 6 の追加 FCI を用いる. FB メッセージの length は 2+n としなければならない (MUST). n は FCI 内の SLI の個数である.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            First        |        Number           | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: Syntax of the Slice Loss Indication (SLI)

First: 13 ビット — 最初に失われたマクロブロックのアドレス. 画像左上を 1 とし, 左から右, 上から下のラスタスキャンで番号が増える (画像に N 個のマクロブロックなら右下が N).

Number: 13 ビット — 上記スキャン順での失われたマクロブロック数.

PictureID: 6 ビット — 損失が起きた画像を参照するコーデック固有識別子の下位 6 ビット. 多くの動画コーデックで Temporal Reference と同一.

明示的ペイロードタイプ情報は与えない. 適用範囲は限られた動画コーデック集合に限られる.

6.3.2.3. タイミング規則

SLI を用いるアルゴリズムの効率は, 指示がタイムリーに送られないと大きく低下する. 動き補償は破損ピクセルを破損として報告されないまま伝播する. したがってセクション 3 のアルゴリズムの使用を強く推奨する.

6.3.2.4. 備考

ここでの Slice は MPEG-1 の意味, すなわちスキャン順の連続マクロブロックである. 新しい規格では Slice の理解が異なる場合がある. H.263 (1998) には rectangular slice がある. 1 つの矩形スライス損失で, 失われた/破損した MB 領域を正確に示すのに複数 SLI が要ることがある.

FCI の先頭フィールドは画像の最初のマクロブロックを 0 ではなく 1 とする. これは ITU-T Rec. H.245 [24] の類似機構に合わせるためである. 画像あたり最大マクロブロック数 2**13 (8192) は多くの ITU-T/ISO/IEC 動画コーデックの最大画像サイズに対応する. 将来より大きい画像やより小さいマクロブロックのコーデックでは追加 FB が必要になる. Temporal Reference の下位 6 ビットで損失画像を示すのに十分とみなす.

SLI への反応は本仕様の外である. 典型は影響空間領域へのイントラリフレッシュである.

動き補償で影響を受ける領域を追跡し, FB のタイミングに関わらずそれら全域にイントラマクロブロックを送るアルゴリズムが報告されている (H.263 (2000) 付録 I [17], [15]). そのようなアルゴリズムでは FB タイミングはそれほど重要でないが, 遅延 FB では修正範囲が広くデータ量が大きくなる.

6.3.3. Reference Picture Selection Indication (RPSI)

PT=PSFB, FMT=3 である. FCI にはちょうど 1 つの RPSI が含まれなければならない (MUST).

6.3.3.1. セマンティクス

MPEG-4 visual version 2 [16] や H.263 version 2 [17] などの近代動画符号化標準は, 予測符号化に最新以外の参照画像を用いることを許す. 通常 FIFO の参照画像キューを維持する. エンコーダがエンコーダ・デコーダ同期喪失を知れば, 正しいと分かっている参照画像を用いうる. 時間的に遠い参照のため, 予測符号化画像はより多くのビットを要する.

MPEG-4 と H.263 は RPSI メッセージの「ペイロード」用バイナリ形式を定義し, 破損画像の時間 ID や破損領域のサイズなどを含む. ビット列は通常小さく (数十ビット程度), 可変長で自己完結しており, 参照画像選択に必要な情報をすべて含む.

両者は肯定フィードバック付き RPSI も許す. すなわちエラーなくデコードされた画像 (またはスライス) を報告する. マルチパーティセッションでは肯定フィードバックのいかなる形式も用いてはならない (MUST NOT) (個々の参照画像について RTCP 間隔で肯定を報告してもあまり有用でない).

6.3.3.2. 形式

図 7 の形式に従う.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      PB       |0| Payload Type|    Native RPSI bit string     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   defined per codec          ...                | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Syntax of the Reference Picture Selection Indication (RPSI)

PB: 8 ビット — RPSI メッセージ長を 32 ビット境界に揃えるのに要する未使用ビット数.

0: 1 ビット — 送信時は 0 にしなければならず (MUST), 受信時は無視する.

Payload Type: 7 ビット — ネイティブ RPSI ビット列を解釈する文脈での RTP ペイロードタイプ.

Native RPSI bit string: 可変長 — 動画コーデックがネイティブに定義する RPSI 情報.

Padding: #PB ビット — 次の 32 ビット境界まで 0 で埋める. パディングビット数は PB で示さなければならない (MUST).

6.3.3.3. タイミング規則

RPSI は SLI を用いるアルゴリズムより遅延に敏感である. RPSI が古いほどエンコーダはエンコーダ・デコーダ同期再確立により多くのビットを費やす. 特定ビットレート/フレームレート/損失率での RPSI オーバーヘッドは [15] を参照.

したがって通常はセクション 3 のアルゴリズムを用い, できるだけ早く送るべきである.

6.4. アプリケーション層フィードバックメッセージ

ペイロード固有メッセージの特別な場合で, PT=PSFB, FMT=15 で識別される. FCI にはアプリケーション層 FB をちょうど 1 つ含めなければならない (MUST) が, アプリケーション層 FB 構造自体がスタック化を許す場合 (固定長や明示長など) は除く.

受信側アプリケーションから送信側アプリケーションへアプリケーション定義データを直接運ぶ. データは FB メッセージでは識別されない. したがってアプリケーションはペイロードを識別できなければならない (MUST).

通常アプリケーションは独自のメッセージ集合を定義する (例: MPEG-4 の NEWPRED [16] を RFC 3016 [23] に従う RTP で運ぶ, H.263/Annex N,U [17] の FB を RFC 2429 [14] でパケット化). これらは RTCP メッセージからの追加情報を要しない. アプリケーションメッセージを FCI にそのまま置き, length を設定する.

Application Message (FCI): 可変長 — 受信者からソースへ運ぶ元のアプリケーションメッセージ. 形式はアプリケーション依存. 長さ可変. データが 32 ビット境界にない場合はパディングビット/バイトを付加して 32 ビット境界にしなければならない (MUST). パディングの識別はアプリケーション層に委ねられ, 本仕様では定義しない.

アプリケーション層 FB メッセージ仕様は, 特定のコーデック (RTP ペイロードタイプで識別) の文脈で解釈が必要かを定義しなければならない (MUST). ペイロードタイプ参照が処理に必要なら, アプリケーション層 FB メッセージ自体の一部としてペイロードタイプ情報を伝える方法を定義しなければならない (MUST).