4. 階層型コーデックにおけるデコード順序回復への適用
RTP フロー内のパケットは予測符号化されていることが多く、受信者はメディアデータをデコードする前にパケットを特定の順序に並べ替える必要があります。ペイロード形式によっては、デコード順序が RTP ペイロードヘッダーのフィールドとして明示的に指定されている場合もあれば、受信者が RTP タイムスタンプの順序でパケットをデコードする場合もあります。メディアデータが複数の RTP フローに分割されている階層型エンコーディングを使用している場合、ベースレイヤー以外のレイヤーをデコードする前に、異なるレイヤーを構成する RTP フローを正確に同期させる必要があることがよくあります。このような階層型エンコーディングの例としては、NI-T モード [AVT-RTP-SVC] の H.264 SVC や MPEG サラウンドマルチチャンネルオーディオ [RFC5691] があります。セクション 2 で説明したように、RTP ではこのような同期が可能ですが、迅速に実行するのは難しい場合があります。以下では、セクション 3.3 で定義された拡張機能を使用して階層型フローを同期し、共通のタイムスタンプベースのデコード順序を提供する方法について説明します。
4.1. デコード順序回復のためのインバンド同期
階層型、マルチ記述、またはマルチビューコーデックを使用し、メディアの異なるコンポーネントが別々の RTP フローで転送される場合、RTP 送信者は、受信者が階層型メディアフローの別々のコンポーネントを迅速かつ正確に同期できるように、同期メタデータの定期的な同期インバンド配信を使用すべきです (SHOULD)。これには 3 つの部分があります。
-
送信者はセクション 3.3 で説明されている RTP ヘッダー拡張の使用をネゴシエートしなければならず、階層型、マルチ記述、またはマルチビューフローの別々のコンポーネントを形成するすべての RTP フローに、そのようなヘッダー拡張を定期的かつ同期的に挿入しなければなりません。
-
同期的挿入では、すべてのフローにおいてまったく同じサンプリング時点に対応するパケットに、これらの RTP ヘッダー拡張を挿入する必要があります。各フローのヘッダー拡張はまったく同じサンプリング時点で挿入されるため、それらは同一の NTP 形式タイムスタンプを持ち、受信者はコンポーネントフローの RTP タイムスタンプを正確に調整できます。一部のコンポーネントフローに、他のフローには存在しないサンプリング時点のパケットが含まれている場合 (例: レイヤーごとにフレームレートが異なる階層型ビデオコーデック)、一部のコンポーネント RTP フローに追加のデータパケットを挿入する必要がある場合があります。
-
送信者がヘッダー拡張を挿入する頻度は同期レイテンシに直接対応し、挿入頻度が高いほどフローあたりのオーバーヘッドは高くなりますが、同期レイテンシは低くなります。送信者は、メディアのランダムアクセスポイントごとに少なくとも 1 回、すべてのコンポーネント RTP フローにヘッダー拡張を同期的に挿入することが推奨されますが (RECOMMENDED)、より頻繁に挿入してもよいです (MAY)。
送信者は SR パケットを含む定期的な RTCP レポートを送信し続けなければならず (MUST)、RTCP SR パケット内の RTP タイムスタンプから NTP 形式タイムスタンプへのマッピングが、RTP ヘッダー拡張で使用されているものと矛盾しないようにしなければなりません (MUST)。受信者は、RTCP SR パケットに含まれる情報と、RTP および NTP 形式タイムスタンプのインバンドマッピングの両方を同期プロセスの入力として使用する必要がありますが、受信者が受信したマッピングの整合性をチェックし、異常値を除外して、無効なデータに対する堅牢性を提供することが推奨されます (RECOMMENDED) (RTCP SR マッピングは不規則な時間に送信され、スキューの影響を受けやすいため、無効である可能性が高いと考える人もいるかもしれませんが、壊れた RTP トランスレーターの存在により RTP ヘッダー拡張のタイムスタンプが破損する可能性もあります。受信者は両方のタイプの障害に対処する必要があります)。
4.2. タイムスタンプベースのデコード順序回復
受信者がセクション 4.1 で説明されているように RTP ヘッダー拡張を使用して階層型、マルチ記述、またはマルチビューフローのコンポーネントを同期すると、同期されたタイムスタンプに基づいて次のようにデコード順序を導出できます (または、RTP ペイロードヘッダーの情報を使用してデコード順序を導出できる場合は、それを使用してもよいです)。
階層型、マルチ記述、またはマルチビューフローのコンポーネントフロー間に明示的な依存関係がある場合があります。例えば、階層型フローが階層構造に配置され、「上位」レイヤーからのフローは、「下位」レイヤーのフロー内の対応するデータを受信してデコードするまでデコードできないのが一般的です。このようなデコード階層が存在する場合、SDP シグナリングが使用される場合は [RFC5583] を使用するなどして、アウトオブバンドでシグナリングされなければなりません (MUST)。
各コンポーネント RTP フローには、依存する RTP フローのすべてのサンプリング時点に対応するパケットが含まれていなければなりません (MUST)。そのようなパケットが RTP フローに自然に存在しない場合、送信者はこの規則を満たすために必要に応じて追加のパケットを生成しなければなりません (MUST)。これらのパケットの形式は、使用されるペイロード形式に依存します。H.264 SVC の場合は、空のネットワーク抽象化レイヤー (NAL) ユニットパケット [AVT-RTP-SVC] を使用する必要があります。フローには、依存するフローには存在しない追加のサンプリング時点に対応するパケットが含まれる場合もあります。
受信者は、次のようにすべてのコンポーネント RTP フローのパケットをデコードする必要があります。
-
各フローの各 RTP パケットについて、RTP ヘッダー拡張と RTCP SR パケットに含まれるマッピングを使用して、その RTP タイムスタンプに対応する NTP 形式タイムスタンプを導出します。
-
計算された NTP 形式タイムスタンプが同一であるすべてのコンポーネントフローからの RTP データパケットをグループ化します。
-
NTP 形式タイムスタンプの昇順でグループを処理し、シグナリングされた RTP フローデコード階層に従って各グループの RTP パケットをデコードします。つまり、まず他のすべてのフローが依存しているフローからの RTP パケットデータをデコーダーに渡し、次に次の依存フローからのデータを、という順序でデコードします。RTP フロー階層のデコード順序は、[RFC5583] で定義されたメカニズムまたはその他の手段によって示される場合があります。
デコード順序は必ずしもパケット送信順序と一致しないことに注意してください。受信者は、デコードを可能にするために必要なすべてのパケットが到着するまで、コーデックに依存した時間分パケットをバッファリングする必要があります。
4.3. 例
図 7 に示す例は、階層型、マルチビュー、またはマルチ記述メディアストリームを含む 3 つの RTP フロー A、B、および C を参照しています。この例では、[RFC5583] で定義されている依存関係シグナリングにより、フロー A が最下位の RTP フローであることが示されています。フロー B は次に上位の RTP フローであり、A に依存します。フロー C は 3 つの RTP フローの中で最上位であり、A と B の両方に依存します。メディアコーディング構造が使用されており、その結果、上位のフローには存在するが、すべての下位のフローには存在しないビデオアクセスユニット (つまり、符号化されたビデオフレーム) が生じます。フロー A は最も低いフレームレートです。フロー B と C は同じフレームレートであり、これはフロー A よりも高いです。図には、対応する RTP タイムスタンプ "(x)" を伴う完全なビデオアクセスユニットが示されています。ビデオアクセスユニットは、RTP シーケンス番号の順序に従ってすでに並べ替えられています。図には、各 RTP フロー内のデコード順序で受信されたビデオアクセスユニットの一部と、関連付けられた NTP メディアタイムスタンプ ("TS[..]") が示されています。図に示すように、これらのタイムスタンプは、"{x}" のタイムスタンプで示されるように RTCP 送信者レポートで提供される NTP 形式タイムスタンプを使用して導出するか、または "
デコード順序回復プロセスは、まず、NTP メディアタイムスタンプ TS=[8] において、RTP ヘッダー拡張への NTP タイムスタンプの最初の利用可能な同期挿入に関連付けられたビデオアクセスユニットの一部に進みます。受信者は最上位の RTP フロー C から開始し、RTP フロー A、B、および C の各デジッタバッファにおいて、TS=[8] のビデオアクセスユニットの一部までのすべての先行するビデオアクセスユニットの一部 (デコード順) を削除/無視します。次に、フロー C から開始して、デコード順で利用可能な最初のメディアタイムスタンプ (TS=[8]) が選択され、フロー A からのビデオアクセスユニットの一部、およびフロー B と C が [RFC5583] で定義されたメカニズムによって示される RTP フロー依存関係の順序で配置されます (TS[8] の例では、まずフロー B、次にフロー C が、NTP メディアタイムスタンプ TS=[8] に関連付けられたビデオアクセスユニット AU(TS[8]) に入れられます)。次に、最上位の RTP フロー C に現れる順序で次のメディアタイムスタンプ TS=[6] (RTP タイムスタンプ=(4)) が処理され、上記で説明したプロセスが繰り返されます。例えば、最下位の RTP フロー A (例: TS=[5]) のように、ビデオアクセスユニットの一部が存在しないビデオアクセスユニットがある場合があることに注意してください。デコード順序回復プロセスは、RTP タイムスタンプと NTP 形式タイムスタンプのマッピング (タイムスタンプ "(x){y}" として表示) を含む RTCP 送信者レポートを受信した後に開始することもできます (ただし、NTP 形式タイムスタンプ生成に使用されるソースにクロックスキューがないことを前提とします)。
C:-(0)----(2)----(7)<8>--(5)----(4)----(6)-----(11)----(9){10}-
| | | | | | | |
B:-(3)----(5)---(10)<8>--(8)----(7)----(9){7}--(14)----(12)----
| | | |
A:---------------(3)<8>--(1)-------------------(7){12}-(5)-----
-------------------------------------------デコード/送信順序 ->
TS:[1] [3] [8]=<8> [6] [5] [7] [12] [10]
凡例:
A, B, C - RTP フロー
"()" 内の整数値 - その RTP パケットに示されている RTP
タイムスタンプを伴うビデオアクセスユニット。
"|" - RTP フローにおける同じビデオアクセスユニット
AU(TS[..]) の対応する部分を示す。
"[]" 内の整数値 - NTP メディアタイムスタンプ TS。上記の
フロー内のビデオアクセスユニットの一部で
構成される、ビデオアクセスユニット
AU(TS[..]) に関連付けられた NTP
タイムスタンプから導出されたサンプリング
時刻。
"<>" 内の整数値 - NTP RTP ヘッダー拡張から直接取得された
NTP メディアタイムスタンプ TS。
"{}" 内の整数値 - RTCP 送信者レポートで提供される NTP
メディアタイムスタンプ TS。
図 7: 階層型 RTP ストリームの例