8.4. Parameter Set Considerations (パラメータセットに関する考慮)

8.4. Parameter Set Considerations (パラメータセットに関する考慮)

H.264 のパラメータセットはビデオコーデックの根本的部分であり, その動作に不可欠である (セクション 1.2 参照). その特性とデコード過程への重要性のため, 失われたり誤って伝送されたパラメータセットは受信側で局所的に隠蔽するのはほぼ不可能である. 破損したパラメータセットへの参照は通常, デコード過程に致命的な結果をもたらす. 破損は, パラメータセット NAL ユニットの誤伝送や損失に加え, パラメータセット更新のタイミング不適切によっても起こり得る. パラメータセット更新とは, ピクチャパラメータセットまたはシーケンスパラメータセットの識別子が変わらないまま, 少なくとも 1 つのパラメータが変更されることを指す. したがって, 以下の推奨事項を RTP 送信者実装者へのガイドラインとして示す.

パラメータセット NALU は 3 つの異なる原則で搬送できる:

A. 実際の RTP セッション前に, セッション制御プロトコル (帯外) を用いる.

B. 進行中の RTP セッション中に, セッション制御プロトコル (帯外) を用いる.

C. 進行中の RTP セッション中に, RTP パケットストリームのペイロード内 (帯内) で行う.

原則 A と B はセッション制御プロトコル内で実装することが推奨される. SIP と SDP は SDP Offer/Answer モデルおよび本メモの前節で述べたとおりに用いられる. セクション 8.2.2 は, メディアタイプパラメータ sprop-parameter-sets, sprop-level-parameter-sets, use-level-src-parameter-sets, in-band-parameter-sets を用いた SDP Offer/Answer におけるパラメータセットの帯内・帯外搬送について詳述する. 本節は, 原則 A と B をセッション制御プロトコル内でどう実装すべきかのガイドラインであり, 特定のプロトコルに依存しない. 原則 C は本仕様で定義される RTP ペイロード形式によってサポートされる. Topo-Video-switch-MCU [29] のようなトポロジーでは原則 C の使用が望ましい場合がある.

パラメータセットの帯内シグナリングを用いる場合, ピクチャおよびシーケンスパラメータセット NALU は RTP ペイロード内で RTP の信頼できる配送方法で送るべきである (下記参照). いずれかのタイプのパラメータセットを失うと, 対応する RTP パケットストリームのかなりの部分がデコード不能になる可能性が高いからである.

パラメータセットの帯内シグナリングを用いる場合, 送信者は誤り特性を考慮し, パラメータセットを正しく受信する確率を高める機構を用いるべきである. 正しい受信の確率を上げる機構には, パケット繰り返し, FEC, 再送がある. 信頼できない帯外制御プロトコルの使用は, 帯内シグナリングと同様の欠点 (損失の可能性) を持ち, さらに同期の困難 (下記参照) を招く可能性がある. したがって推奨されない.

パラメータセットは, セッション存続期間中に原則 B および C を用いて追加または更新してもよい. それらを参照する NAL ユニットより前にデコーダにパラメータセットが存在することが要求される. 更新や追加はさらなる問題を招き得るため, 次の推奨を考慮すべきである.

• パラメータセットを追加または更新する際, いずれのパラメータセットも使用前に配送されるよう注意すべきである. 新規パラメータセットを追加する際は, 未使用のパラメータセット識別子を用いる. 帯外シグナリングと帯内トラフィックの間に同期がないことは一般的である. 帯外シグナリングを用いる場合, 送信者はシグナリングプロトコルから配送確認を得るまで, 追加・更新されたパラメータセットを要する NALU の送信を開始しないことが推奨される.

• パラメータセットを更新する際, 次の同期問題を考慮すべきである. 受信側でパラメータセットを上書きする際, 送信者は, 問題のパラメータセットがネットワークまたは受信バッファ内のいずれの NALU からも不要であることを保証しなければならない. そうでなければ誤ったパラメータセットでデコードが行われる可能性がある. この問題を軽減するには, 十分長い間使用されていないパラメータセットのみを上書きする (関連 NALU がすべて消費されたことを確実にする), または代わりに新しいパラメータセットを追加する (ビデオ符号化効率に悪影響を及ぼす可能性がある) ことが推奨される.

参考注: Topo-Video-switch-MCU [29] のような一部トポロジーでは, パラメータセット全体の出自が複数ソースから来て, 非一意のパラメータセット識別子を用いることがある. この場合, 帯外チャネルでパラメータセットの一意性を保つ他の機構がなければ, offer が既存のパラメータセットを上書きし得る.

• マルチパーティセッションでは, 可能な限り, 参加者は異なるソースからのパラメータセットをソース識別と関連付けなければならない. 例えば帯外で搬送されたパラメータセットにより行う. 異なるソースは通常, 独立したパラメータセット識別子の値空間を用いる.

• 同一 RTP セッションで原則 B と C の両方を用いてパラメータセットを追加または変更すると, 制御チャネルと RTP チャネルの同期欠如によりパラメータセットの不整合が生じ得る. したがって, 十分な同期が提供できない限り, 同一セッションで原則 B と C を同時に用いてはならない.

一部のシナリオ (例: 本ペイロード形式仕様の H.241 に対応する部分のみを用いる場合) またはトポロジーでは, 帯外のパラメータセット伝送を用いられない. この場合パラメータセットは帯内で伝送されなければならない. この場合, ビットストリーム内の非パラメータセットデータとの同期は暗黙的だが, 損失の可能性を考慮しなければならない.

損失確率は上で論じた機構で低減すべきである. パラメータセットの損失が検出された場合, 例えば RTCP フィードバック Full Intra Request (FIR) [30] を用いるデコーダリフレッシュポイント手順で回復できる. 参考セクション 8.5 にデコーダリフレッシュポイント手順の例を 2 つ示す.

• パラメータセットを最初に原則 A で提供し, 後で帯内 (原則 C) で追加または更新する場合, 帯外で配送されたパラメータセットを更新することにリスクが伴う. 受信者が一部の帯内更新を取り逃がすと (損失や遅いチューンインなど), その受信者は古いパラメータでビットストリームをデコードしようとする. したがって, 帯外と帯内のパラメータセットでパラメータセット ID を分割することが推奨される.