[要約] RFC 8450は、VC-2 High Quality (HQ) ProfileのためのRTPペイロード形式を定義しています。このRFCの目的は、VC-2 HQプロファイルのビデオデータをRTPパケットにエンコードする方法を提供することです。
Internet Engineering Task Force (IETF) J. Weaver
Request for Comments: 8450 BBC
Category: Standards Track October 2018
ISSN: 2070-1721
RTP Payload Format for VC-2 High Quality (HQ) Profile
VC-2高品質（HQ）プロファイルのRTPペイロード形式
Abstract
概要
This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.
このメモは、VC-2として知られる映画テレビ技術者標準ST 2042-1の高品質（HQ）プロファイルのRTPペイロード形式について説明しています。このドキュメントでは、RTPパケットでのHQプロファイルVC-2の転送について説明し、損失のないビデオと損失のある圧縮ビデオの両方の複雑さを抑えた高帯域幅ストリーミングのアプリケーションについて説明します。
The HQ profile of VC-2 is intended for low-latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).
VC-2のHQプロファイルは、高データレート（2：1または4：1のオーダーの圧縮率）で低レイテンシーのビデオ圧縮（潜在的にビデオのラインのオーダーのレイテンシー）を目的としています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8450.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8450で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions, and Acronyms . . . . . . . . . . . 3
3. Media Format Description . . . . . . . . . . . . . . . . . . 3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 10
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 11
4.3. The Choice of Parse Codes (Informative) . . . . . . . . . 13
4.4. Stream Constraints . . . . . . . . . . . . . . . . . . . 14
4.5. Payload Data . . . . . . . . . . . . . . . . . . . . . . 15
4.5.1. Reassembling the Data . . . . . . . . . . . . . . . . 16
5. Forward Error Correction (FEC) Considerations . . . . . . . . 18
6. Congestion Control Considerations . . . . . . . . . . . . . . 18
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 19
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 19
7.2. Mapping to the Session Description Protocol (SDP) . . . . 21
7.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
This memo specifies an RTP payload format for the video coding standard Society of Motion Picture and Television Engineers ST 2042-1:2017 [VC2], also known as VC-2
このメモは、ビデオコーディング標準のSociety of Motion Picture and Television Engineers ST 2042-1：2017 [VC2]（別名VC-2）のRTPペイロード形式を指定しています
The VC-2 codec is a wavelet-based codec intended primarily for professional video use with high bit-rates and only low levels of compression. It has been designed to have a low level of complexity and potentially a very low latency through both encoder and decoder: with some choices of parameters, this latency may be as low as a few lines of video.
VC-2コーデックは、主に高ビットレートで低レベルの圧縮のみを使用するプロフェッショナルビデオでの使用を目的としたウェーブレットベースのコーデックです。エンコーダとデコーダの両方で複雑さが低く、レイテンシが非常に低くなるように設計されています。いくつかのパラメータを選択すると、このレイテンシはビデオの数行程度になることがあります。
The low level of complexity in the VC-2 codec allows for this low-latency operation but also means that it lacks many of the more powerful compression techniques used in other codecs. As such, it is suitable for low compression ratios that produce coded data rates around half to a quarter of that of uncompressed video, at a similar visual quality.
VC-2コーデックは複雑さが低いため、この低レイテンシの操作が可能ですが、他のコーデックで使用されているより強力な圧縮技術の多くが欠如しています。そのため、同様の視覚的品質で、非圧縮ビデオの約半分から1/4のコード化データレートを生成する低圧縮率に適しています。
The primary use for VC-2 is likely to be in professional video production environments.
VC-2の主な用途は、プロのビデオ制作環境である可能性があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The VC-2 specification defines a VC-2 Stream as being composed of one or more Sequences. Each Sequence is independently decodable, containing all of the needed parameters and metadata for configuring the decoder.
VC-2仕様では、VC-2ストリームを1つ以上のシーケンスで構成されるものとして定義しています。各シーケンスは独立してデコード可能で、デコーダーを構成するために必要なすべてのパラメーターとメタデータが含まれています。
Each Sequence consists of a series of 13-octet Parse Info Headers and variable-length Data Units. The Sequence begins and ends with a Parse Info Header, and each Data Unit is preceded by a Parse Info Header. Data Units come in a variety of types, and the type of a Data Unit is signaled in the preceding Parse Info Header. The most important types are the Sequence Header, which contains configuration data needed by the decoder, and several types of Coded Picture, which contain the coded data for the pictures themselves. Each picture represents a frame in a progressively scanned video Sequence or a field in an interlaced video Sequence.
各シーケンスは、一連の13オクテットの解析情報ヘッダーと可変長データユニットで構成されます。シーケンスは解析情報ヘッダーで開始および終了し、各データユニットの前には解析情報ヘッダーが続きます。データユニットにはさまざまなタイプがあり、データユニットのタイプは、前の解析情報ヘッダーで通知されます。最も重要なタイプは、デコーダーに必要な構成データを含むシーケンスヘッダーと、画像自体のコード化データを含むいくつかのタイプのコード化画像です。各画像は、プログレッシブスキャンされたビデオシーケンスのフレーム、またはインターレースビデオシーケンスのフィールドを表します。
The first Data Unit in a Sequence as produced by an encoder is always a Sequence Header; however, Sequences can be joined in the middle, so it should not be assumed that the first Data Unit received will always be a Sequence Header.
エンコーダーによって生成されるシーケンスの最初のデータユニットは常にシーケンスヘッダーです。ただし、シーケンスを途中で結合できるため、最初に受信したデータユニットが常にシーケンスヘッダーであるとは限りません。
The High Quality (HQ) profile for VC-2 restricts the types of Parse Info Headers that may appear in the Sequence (and hence also the types of Data Unit) to only:
VC-2の高品質（HQ）プロファイルは、シーケンスに表示される可能性のある解析情報ヘッダーのタイプ（つまり、データユニットのタイプ）を次のものに制限します。
o Sequence Headers (which are always followed by a Data Unit),
o シーケンスヘッダー（常にデータユニットが後に続く）、
o High Quality Pictures (which are always followed by a Data Unit),
o 高品質の写真（常にデータユニットが後に続きます）、
o High Quality Fragments (which are always followed by a Data Unit),
o 高品質のフラグメント（常にデータユニットが後に続く）、
o Auxiliary Data (which are always followed by a Data Unit),
o 補助データ（常にデータユニットが後に続く）、
o Padding Data (which are always followed by a Data Unit), and
o データのパディング（常にデータユニットが後に続く）、および
o End of Sequence (which are never followed by a Data Unit).
o シーケンスの終わり（これにデータユニットが続くことはありません）。
At the time of writing, there is no definition for the use of Auxiliary Data in VC-2, and Padding Data is required to be ignored by all receivers.
執筆時点では、VC-2での補助データの使用に関する定義はなく、パディングデータはすべてのレシーバーによって無視される必要があります。
Each High Quality Picture Data Unit contains a set of parameters for the picture followed by a series of Coded Slices, each representing a rectangular region of the transformed picture. Slices within a picture may vary in coded length, but all represent the same shape and size of rectangle in the picture.
各高品質画像データユニットには、画像のパラメータセットが含まれ、その後に一連のコード化スライスが続きます。各スライスは、変換された画像の長方形の領域を表します。画像内のスライスは、コード化された長さが異なる場合がありますが、画像内の長方形の同じ形状とサイズをすべて表します。
Each High Quality Fragment Data Unit contains either a set of parameters for a picture or a series of Coded Slices. Fragments carry the same data as pictures, but broken up into smaller units to facilitate transmission via packet-based protocols such as RTP.
各高品質フラグメントデータユニットには、画像のパラメータセットまたは一連のコード化スライスが含まれています。フラグメントは画像と同じデータを持ちますが、RTPなどのパケットベースのプロトコルを介した送信を容易にするために、より小さな単位に分割されます。
This payload format only makes use of Fragments, not pictures.
このペイロード形式は、画像ではなくフラグメントのみを使用します。
In this specification, each RTP packet is used to carry data corresponding to a single Parse Info Header and its following Data Unit (if it has one). A single packet MAY NOT contain data from more than one Parse Info Header or Data Unit. A single Parse Info Header and Data Unit pair MUST NOT be split across more than one packet. The sole exception to this rule is that an Auxiliary Data Unit MAY be split between multiple packets, using the B and E flags to indicate start and end.
この仕様では、各RTPパケットは、単一の解析情報ヘッダーとそれに続くデータユニット（データユニットがある場合）に対応するデータを運ぶために使用されます。 1つのパケットに、複数の解析情報ヘッダーまたはデータユニットからのデータが含まれてはなりません。単一の解析情報ヘッダーとデータユニットのペアは、複数のパケットに分割してはなりません。このルールの唯一の例外は、BフラグとEフラグを使用して開始と終了を示すことで、補助データユニットを複数のパケットに分割できる（MAY）ことです。
This specification only covers the transport of Sequence Headers (together with their accompanying Data Unit), High Quality Fragments (together with their accompanying Data Unit), Auxiliary Data (together with their accompanying Data Unit), and (optionally) End Sequence Headers and Padding Data (for which no Data Unit it carried).
この仕様は、シーケンスヘッダー（付随するデータユニットと共に）、高品質フラグメント（付随するデータユニットと共に）、補助データ（付随するデータユニットと共に）、および（オプションで）終了シーケンスヘッダーとパディングのトランスポートのみをカバーします。データ（データユニットがない場合）。
High Quality Pictures can be transported by converting them into an equivalent set of High Quality Fragments. The size of Fragments should be chosen so as to fit within the MTU of the network in use.
高品質の画像は、同等の高品質のフラグメントのセットに変換することで転送できます。フラグメントのサイズは、使用中のネットワークのMTU内に収まるように選択する必要があります。
For this reason, this document defines six types of RTP packets in a VC-2 media stream:
このため、このドキュメントでは、VC-2メディアストリームで6種類のRTPパケットを定義しています。
o a VC-2 Sequence Header (Figure 1) (see Section 11 of the VC-2 specification [VC2]),
o VC-2シーケンスヘッダー（図1）（VC-2仕様のセクション11 [VC2]を参照）、
o a Picture Fragment containing the VC-2 Transform Parameters for a Picture (Figure 2) (see Section 14 of the VC-2 specification [VC2]),
o 画像のVC-2変換パラメータを含む画像フラグメント（図2）（VC-2仕様のセクション14 [VC2]を参照）、
o a Picture Fragment containing VC-2 Coded Slices (Figure 3) for a picture (see Section 14 of the VC-2 specification [VC2]),
o 画像のVC-2コード化スライス（図3）を含む画像フラグメント（VC-2仕様[VC2]のセクション14を参照）、
o the end of a VC-2 Sequence (Figure 4) (see Section 10.5.2 of the VC-2 specification [VC2]),
o VC-2シーケンスの終了（図4）（VC-2仕様のセクション10.5.2 [VC2]を参照）、
o the contents of an Auxiliary Data Unit (Figure 5) (see Section 10.4.4 of the VC-2 specification [VC2]), and
o 補助データユニットの内容（図5）（VC-2仕様[VC2]のセクション10.4.4を参照）、および
o an indication of the presence of a padding Data Unit (Figure 6) (see Section 10.4.5 of the VC-2 specification [VC2]).
o パディングデータユニットの存在の表示（図6）（VC-2仕様のセクション10.4.5 [VC2]を参照）。
These six packet types can be distinguished by the fact that they use different codes in the Parse Code ("PC") field, except for the two types of Picture Fragment that use the same value in PC but have different values in the "No. of Slices" field.
これらの6種類のパケットは、PCで同じ値を使用するが「No. of Slices」フィールド。
The options for PC codes are explained in more detail in Section 4.3.
PCコードのオプションについては、セクション4.3で詳しく説明します。
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved | PC = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Variable-Length Coded Sequence Header .
. .
+---------------------------------------------------------------+
Figure 1: RTP Payload Format for Sequence Header
図1：シーケンスヘッダーのRTPペイロード形式
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved |I|F| PC = 0xEC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Picture Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Prefix Bytes | Slice Size Scaler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Fragment Length | No. of Slices = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Variable-Length Coded Transform Parameters .
. .
+---------------------------------------------------------------+
Figure 2: RTP Payload Format for Transform Parameters Fragment
図2：変換パラメーターフラグメントのRTPペイロード形式
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved |I|F| PC = 0xEC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Picture Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Prefix Bytes | Slice Size Scaler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Fragment Length | No. of Slices |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Offset X | Slice Offset Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Coded Slices .
. .
+---------------------------------------------------------------+
Figure 3: RTP Payload Format for Fragment Containing Slices
図3：スライスを含むフラグメントのRTPペイロード形式
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved | PC = 0x10 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 4: RTP Payload Format for End of Sequence
図4：シーケンスの終わりのRTPペイロード形式
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Uncoded Payload Data .
. .
+---------------------------------------------------------------+
Figure 5: RTP Payload Format for Auxiliary Data
図5：補助データのRTPペイロード形式
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 |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+---------------------------------------------------------------+
Figure 6: RTP Payload Format for Padding Data
図6：データをパディングするためのRTPペイロード形式
All fields in the headers longer than a single bit are interpreted as unsigned integers in network byte order.
1ビットより長いヘッダーのすべてのフィールドは、ネットワークバイトオーダーで符号なし整数として解釈されます。
The fields of the RTP header have the following additional notes on their usage:
RTPヘッダーのフィールドには、その使用に関する次の追加の注意事項があります。
Marker Bit (M): 1 bit. The marker bit MUST be set on any packet that contains the final slice in a coded picture and MUST NOT be set otherwise.
マーカービット（M）：1ビット。マーカービットは、コード化された画像の最後のスライスを含むすべてのパケットに設定する必要があり、それ以外の場合は設定してはなりません（MUST NOT）。
Payload Type (PT): 7 bits. A dynamically allocated payload type field that designates the payload as VC-2-coded video.
ペイロードタイプ（PT）：7ビット。ペイロードをVC-2でコード化されたビデオとして指定する動的に割り当てられたペイロードタイプフィールド。
Sequence Number: 16 bits. Because the data rate of VC-2-coded Streams can often be very high, in the order of gigabits rather than megabits per second, the standard 16-bit RTP sequence number can cycle very quickly. For this reason, the sequence number is extended to 32 bits, and this field MUST hold the low-order 16 bits of this value.
シーケンス番号：16ビット。 VC-2でコード化されたストリームのデータレートは、メガビット/秒ではなくギガビットのオーダーで非常に高くなることが多いため、標準の16ビットRTPシーケンス番号は非常に速く循環できます。このため、シーケンス番号は32ビットに拡張され、このフィールドはこの値の下位16ビットを保持する必要があります。
Timestamp: 32 bits. If the packet contains Transform Parameters or Coded Slice data for a coded picture, then the timestamp corresponds to the sampling instant of the coded picture. A 90kHz clock SHOULD be used. A single RTP packet MUST NOT contain coded data for more than one coded picture, so there is no ambiguity here.
タイムスタンプ：32ビット。パケットにコード化された画像の変換パラメーターまたはコード化されたスライスデータが含まれている場合、タイムスタンプはコード化された画像のサンプリングの瞬間に対応します。 90kHzクロックを使用する必要があります。単一のRTPパケットには、複数のコード化された画像のコード化されたデータが含まれていてはならないため、あいまいさはありません。
A Sequence Header packet SHOULD have the same timestamp as the picture that will follow it in the Stream. An End of Sequence packet SHOULD have the same timestamp as the previous picture that appeared in the Stream.
シーケンスヘッダーパケットは、ストリーム内でそれに続く画像と同じタイムスタンプを持つ必要があります（SHOULD）。シーケンス終了パケットは、ストリームに表示された前の画像と同じタイムスタンプを持つ必要があります。
The remaining RTP header fields are used as specified in RTP [RFC3550].
残りのRTPヘッダーフィールドは、RTP [RFC3550]での指定に従って使用されます。
The fields of the extended headers are defined as follows:
拡張ヘッダーのフィールドは次のように定義されています。
Extended Sequence Number: 16 bits. MUST contain the high-order 16 bits of the 32-bit packet sequence number. This is needed since the high data rates of VC-2 Sequences mean that it is highly likely that the 16-bit sequence number will roll over too frequently to be of use for Stream synchronization.
拡張シーケンス番号：16ビット。 32ビットのパケットシーケンス番号の上位16ビットを含める必要があります。 VC-2シーケンスの高いデータレートは、16ビットシーケンス番号が頻繁にロールオーバーしてストリーム同期に使用できない可能性が高いことを意味するため、これが必要です。
B: 1 bit. MUST be set to 1 if the packet contains the first byte of an Auxiliary Data Unit and otherwise MUST be 0. If the recommendations in Section 4.4 ("Stream Constraints") are followed, then every Auxiliary Data Unit will be small enough to fit in a single packet, and so this bit (where present) will always be 1.
B：1ビット。パケットに補助データユニットの最初のバイトが含まれている場合は1に設定する必要があります。それ以外の場合は0にする必要があります。セクション4.4の推奨事項（「ストリーム制約」）に従っている場合、すべての補助データユニットは十分に小さい単一のパケットなので、このビット（存在する場合）は常に1になります。
E: 1 bit. MUST be set to 1 if the packet contains the final byte of an Auxiliary Data Unit and otherwise MUST be 0. If the recommendations in Section 4.4 ("Stream Constraints") are followed, then every Auxiliary Data Unit will be small enough to fit in a single packet, and so this bit (where present) will always be 1.
E：1ビット。パケットに補助データユニットの最後のバイトが含まれている場合は1に設定する必要があります。それ以外の場合は0にする必要があります。セクション4.4の推奨事項（「ストリーム制約」）に準拠している場合、すべての補助データユニットは、単一のパケットなので、このビット（存在する場合）は常に1になります。
I: 1 bit. MUST be set to 1 if the packet contains coded picture parameters or slice data from a field in an interlaced frame. MUST be set to 0 if the packet contains data from any part of a progressive frame.
I：1ビット。パケットにコード化された画像パラメータまたはインターレースフレームのフィールドからのスライスデータが含まれている場合は、1に設定する必要があります。パケットにプログレッシブフレームの一部のデータが含まれている場合は、0に設定する必要があります。
F: 1 bit. MUST be set to 1 if the packet contains coded picture parameters or slice data from the second field of an interlaced frame. MUST be set to 0 if the packet contains data from the first field of an interlaced frame or any part of a progressive frame.
F：1ビット。パケットにインターレースフレームの2番目のフィールドからのコード化された画像パラメーターまたはスライスデータが含まれている場合は、1に設定する必要があります。パケットにインターレースフレームの最初のフィールドまたはプログレッシブフレームの一部のデータが含まれている場合は、0に設定する必要があります。
Parse Code (PC): 8 bits. Contains a Parse Code that MUST be the value indicated for the type of data in the packet.
解析コード（PC）：8ビット。パケット内のデータのタイプに対して示された値でなければならない解析コードが含まれています。
Data Length: 32 bits. For an auxiliary Data Unit, this contains the number of bytes of data contained in the payload section of this packet. If the recommendations in Section 4.4 ("Stream Constraints") are followed, then no Auxiliary Data Unit will be large enough to cause a packet to exceed the MTU of the network.
データ長：32ビット。補助データユニットの場合、これには、このパケットのペイロードセクションに含まれるデータのバイト数が含まれます。セクション4.4（「ストリームの制約」）の推奨事項に従っている場合、パケットがネットワークのMTUを超えるのに十分な大きさの補助データユニットはありません。
Picture Number: 32 bits. MUST contain the Picture Number for the coded picture this packet contains data for, as described in Section 12.1 of the VC-2 specification [VC2].
画像番号：32ビット。 VC-2仕様[VC2]のセクション12.1で説明されているように、このパケットがデータを含むコード化された画像の画像番号を含まなければなりません（MUST）。
The sender MUST send at least one transform-parameters packet for each coded picture and MAY include more than one as long as they contain identical data. The sender MUST NOT send a packet from a new picture until all the coded data from the current picture has been sent.
送信者は、コード化された画像ごとに少なくとも1つの変換パラメータパケットを送信する必要があり、同一のデータが含まれている限り、複数を含めることができます（MAY）。送信者は、現在の画像からすべてのコード化されたデータが送信されるまで、新しい画像からパケットを送信してはなりません（MUST NOT）。
If the receiver receives Coded Slices packets for a picture but does not receive a Transform Parameters packet for that picture, then this is an indication of either packet loss, joining a Stream mid-picture, or a non-compliant transmitter. In this case, the receiver MAY assume that the parameters are unchanged since the last picture, or it MAY discard the picture. Choosing between these two options is left up to the implementation as it will be dependent on intended use. The former may result in malformed pictures, while the latter will result in dropped frames.
受信機が画像のコード化スライスパケットを受信しても、その画像の変換パラメーターパケットを受信しない場合、これはパケットの損失、ストリームの中間画像への参加、または非準拠の送信機のいずれかを示しています。この場合、受信機は最後の画像以降にパラメータが変更されていないと想定してもよいし、そうでなければ画像を破棄してもよい（MAY）。これら2つのオプションのどちらを選択するかは、使用目的に依存するため、実装次第です。前者は不正な形式の画像になる可能性がありますが、後者は欠落したフレームになります。
Slice Prefix Bytes: 16 bits. MUST contain the Slice Prefix Bytes value for the coded picture this packet contains data for, as described in Section 12.3.4 of the VC-2 specification [VC2].
スライスプレフィックスバイト：16ビット。 VC-2仕様[VC2]のセクション12.3.4で説明されているように、このパケットにデータが含まれているコード化された画像のスライスプレフィックスバイト値を含める必要があります。
In the VC-2 specification, this value is not restricted to 16 bits, but the constraints on Streams specified in this document (Section 4.4) do require this.
VC-2仕様では、この値は16ビットに制限されていませんが、このドキュメント（セクション4.4）で指定されているストリームに対する制約では、これが必要です。
Slice Size Scaler: 16 bits. MUST contain the Slice Size Scaler value for the coded picture this packet contains data for, as described in Section 12.3.4 of the VC-2 specification [VC2].
スライスサイズスケーラー：16ビット。 VC2仕様[VC2]のセクション12.3.4で説明されているように、このパケットにデータが含まれているコード化された画像のスライスサイズスカラー値を含める必要があります。
In the VC-2 specification, this value is not restricted to 16 bits, but the constraints on Streams specified in this document (Section 4.4) do require this.
VC-2仕様では、この値は16ビットに制限されていませんが、このドキュメント（セクション4.4）で指定されているストリームに対する制約では、これが必要です。
Fragment Length: 16 bits. MUST contain the number of bytes of data contained in the coded payload section of this packet.
フラグメント長：16ビット。このパケットのコード化されたペイロードセクションに含まれるデータのバイト数を含める必要があります。
No. of Slices: 16 bits. MUST contain the number of Coded Slices contained in this packet, which MUST be 0 for a packet containing Transform Parameters. In a packet containing Coded Slices, this number MUST be the number of whole slices contained in the packet, and the packet MUST NOT contain any partial slices.
スライス数：16ビット。このパケットに含まれるコード化スライスの数を含まなければなりません。変換パラメータを含むパケットの場合は0でなければなりません。コード化スライスを含むパケットでは、この数はパケットに含まれるスライス全体の数でなければならず（MUST）、パケットには部分的なスライスを含めてはなりません（MUST NOT）。
Slice Offset X: 16 bits. MUST contain the X coordinate of the first slice in this packet, in slices, starting from the top left corner of the picture.
スライスオフセットX：16ビット。このパケットの最初のスライスのX座標を、画像の左上隅から始まるスライス単位で含める必要があります。
Slice Offset Y: 16 bits. MUST contain the Y coordinate of the first slice in this packet, in slices, starting from the top left corner of the picture.
スライスオフセットY：16ビット。このパケットの最初のスライスのY座標を、画像の左上隅から始まるスライス単位で含める必要があります。
The "PC" field in the packets is used to carry the Parse Code, which identifies the type of content in the packet. This code matches the value of the Parse Code used to identify each Data Unit in a VC-2 Stream, as defined in the VC-2 specification, and each packet contains the entire Data Unit.
パケットの「PC」フィールドは、パケットのコンテンツのタイプを識別する解析コードを運ぶために使用されます。このコードは、VC-2仕様で定義されているように、VC-2ストリーム内の各データユニットを識別するために使用される解析コードの値と一致し、各パケットにはデータユニット全体が含まれます。
Figure 7 lists all of the Parse Codes currently allowed in a VC-2 Sequence. The final column indicates whether the code in question can be present in a Stream transmitted using this specification.
図7に、VC-2シーケンスで現在許可されているすべての解析コードを示します。最後の列は、問題のコードがこの仕様を使用して送信されたストリームに存在できるかどうかを示します。
+----------+-----------+---------------------+---------------+
| PC (hex) | Binary | Description | Valid |
+----------+-----------+---------------------+---------------+
| 0x00 | 0000 0000 | Sequence Header | Yes |
| 0x10 | 0001 0000 | End of Sequence | Yes |
| 0x20 | 0010 0000 | Auxiliary Data | Yes |
| 0x30 | 0011 0000 | Padding Data | Yes |
+----------+-----------+---------------------+---------------+
| 0xC8 | 1100 1000 | LD Picture | No |
| 0xE8 | 1110 1000 | HQ Picture | No |
| 0xEC | 1110 1100 | HQ Picture Fragment | Yes |
+----------+-----------+---------------------+---------------+
Figure 7: Parse Codes and Meanings
図7：解析コードと意味
A Sequence needs to conform to certain constraints in order to be transmissible with this specification.
シーケンスは、この仕様で送信可能にするために、特定の制約に準拠する必要があります。
o The Sequence MUST NOT contain Parse Info Headers with a Parse Code other than 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20 (Auxiliary Data), 0x30 (Padding Data), or 0xEC (High Quality Picture Fragment). Some other Streams MAY be convertible to meet this restriction (see below).
o シーケンスには、0x00（シーケンスヘッダー）、0x10（シーケンスの終わり）、0x20（補助データ）、0x30（パディングデータ）、または0xEC（高品質画像フラグメント）以外の解析コードを持つ解析情報ヘッダーを含めてはなりません（MUST NOT）。他のいくつかのストリームは、この制限を満たすように変換できます（下記参照）。
o Every High Quality Picture Fragment MUST be no longer than 65535 bytes. This can usually be ensured by splitting large Fragments into several smaller Fragments, except in the case where an individual slice is too large, in which case see the notes below on conversion.
o すべての高品質画像フラグメントは、65535バイト以下でなければなりません。これは通常、個々のスライスが大きすぎる場合を除いて、大きなフラグメントをいくつかの小さなフラグメントに分割することで保証できます。その場合、変換に関する以下の注を参照してください。
o Informative note: this requirement ensures that every High Quality Picture Fragment will always contain no more than 65535 slices.
o 参考情報：この要件により、すべての高品質画像フラグメントに常に65535スライス以下が含まれるようになります。
o Every High Quality Picture Fragment SHOULD be small enough that the RTP packet carrying it will fit within the network MTU size. This can usually be ensured by splitting large Fragments into several smaller Fragments, except in the case where an individual slice is too large, in which case see the notes below on conversion.
o すべての高品質画像フラグメントは、それを運ぶRTPパケットがネットワークMTUサイズに収まるように十分に小さい必要があります。これは通常、個々のスライスが大きすぎる場合を除いて、大きなフラグメントをいくつかの小さなフラグメントに分割することで保証できます。その場合、変換に関する以下の注を参照してください。
o Every High Quality Picture Fragment MUST be encoded using values for Slice Prefix Bytes and Slice Size Scaler no greater than 65535.
o すべての高品質画像フラグメントは、スライスプレフィックスバイトと65535以下のスライスサイズスケーラーの値を使用してエンコードする必要があります。
If a Sequence intended for transmission does not conform to these restrictions, then it MAY be possible to simply convert it into a form that does by splitting pictures and/or large Fragments into suitably sized Fragments. This can be done provided that the following (weaker) constraints are met:
送信を目的としたシーケンスがこれらの制限に準拠していない場合は、単純に、画像や大きなフラグメントを適切なサイズのフラグメントに分割することによって変換する形式に変換できる可能性があります。これは、次の（弱い）制約が満たされている場合に実行できます。
o The Sequence does not contain Parse Info Headers with a Parse Code other than 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20 (Auxiliary Data), 0x30 (Padding Data), 0xE8 (High Quality Picture), or 0xEC (High Quality Picture Fragment).
o シーケンスには、0x00（シーケンスヘッダー）、0x10（シーケンスの終わり）、0x20（補助データ）、0x30（パディングデータ）、0xE8（高品質画像）、または0xEC（高）以外の解析コードを持つ解析情報ヘッダーは含まれません高品質の画像フラグメント）。
o None of the High Quality Pictures or High Quality Picture Fragments contain slices that are individually longer than 65535 bytes. Note: When this is the case, the values of Slice Prefix Bytes and Slice Size Scaler will necessarily also be smaller than 65535.
o 高品質画像または高品質画像フラグメントのいずれにも、個々に65535バイトを超えるスライスは含まれていません。注：この場合、スライスプレフィックスバイトとスライスサイズスケーラーの値も必ず65535未満になります。
o None of the High Quality Pictures or High Quality Picture Fragments contain slices that are individually so large that an RTP packet carrying a Fragment containing that single slice will fit within the network MTU size.
o 高品質ピクチャまたは高品質ピクチャフラグメントのいずれにも、個々に非常に大きいスライスが含まれていないため、その単一のスライスを含むフラグメントを伝送するRTPパケットは、ネットワークMTUサイズに適合します。
It is not possible to send a Stream that does not meet the above requirements via this mechanism unless the Stream is re-encoded by a VC-2 Encoder so as to meet them.
ストリームがVC-2エンコーダーによって再エンコードされて条件を満たすようにしない限り、このメカニズムを介して上記の要件を満たさないストリームを送信することはできません。
In addition, every Auxiliary Data Unit SHOULD be small enough that a single RTP packet carrying it will fit within the network MTU size. Since there is currently no specification for the format of Auxiliary Data in VC-2, the mechanism for ensuring this with an encoder implementation that includes Auxiliary Data Units will be dependent upon the implementation's use for them.
さらに、すべての補助データユニットは、それを運ぶ単一のRTPパケットがネットワークMTUサイズ内に収まるように十分に小さい必要があります。現在、VC-2の補助データの形式の仕様はないため、補助データユニットを含むエンコーダー実装でこれを保証するメカニズムは、それらの実装の使用に依存します。
When encoding VC-2 video intended to be transported via RTP, a VC-2 profile and level that ensures these requirements are met SHOULD be used.
RTPを介して転送されるVC-2ビデオをエンコードする場合、これらの要件が確実に満たされるようにするVC-2プロファイルとレベルを使用する必要があります。
For the Sequence Header packet type (PC = 0x00), the payload data MUST be the coded Sequence Header exactly as it appears in the VC-2 Sequence.
シーケンスヘッダーパケットタイプ（PC = 0x00）の場合、ペイロードデータは、VC-2シーケンスに表示されるとおりにコード化されたシーケンスヘッダーである必要があります。
For the Transform Parameters packet type (PC = 0xEC and No. of Slices = 0), the payload data MUST be the variable-length coded Transform Parameters. This MUST NOT include the Fragment header (since all data in the picture header is already included in the packet header).
変換パラメーターパケットタイプ（PC = 0xECおよびスライス数= 0）の場合、ペイロードデータは可変長コード化された変換パラメーターでなければなりません。これにはフラグメントヘッダーを含めないでください（画像ヘッダーのすべてのデータが既にパケットヘッダーに含まれているため）。
For the Auxiliary Data packet type (PC = 0x20), the payload data MUST be a portion of the auxiliary data bytes contained in the Auxiliary Data Unit being transmitted. The B flag MUST be set on the packet that contains the first byte, the E flag MUST be set on the packet that contains the last byte, the bytes MUST be included in order, and the packets MUST have contiguous sequence numbers.
補助データパケットタイプ（PC = 0x20）の場合、ペイロードデータは、送信される補助データユニットに含まれる補助データバイトの一部である必要があります。 Bフラグは最初のバイトを含むパケットに設定する必要があり、Eフラグは最後のバイトを含むパケットに設定する必要があり、バイトを順番に含める必要があり、パケットには連続したシーケンス番号が必要です。
For the Picture Fragment packet type (PC = 0xEC and No. of Slices > 0), the payload data MUST be a specified number of Coded Slices in the same order that they appear in the VC-2 Stream. Which slices appear in the packet is identified using the Slice Offset X and Slice Offset Y fields in the payload header.
ピクチャフラグメントパケットタイプ（PC = 0xECおよびスライス数> 0）の場合、ペイロードデータは、VC-2ストリームに表示されるのと同じ順序で指定された数のコード化スライスでなければなりません。パケットに表示されるスライスは、ペイロードヘッダーのスライスオフセットXおよびスライスオフセットYフィールドを使用して識別されます。
For the End of Sequence packet type (PC = 0x10), there is no payload data.
End of Sequenceパケットタイプ（PC = 0x10）の場合、ペイロードデータはありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x42 | 0x42 | 0x43 | 0x44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parse Code | Next Parse Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prev Parse Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+
Figure 8: VC-2 Parse Info Header
図8：VC-2解析情報ヘッダー
To reassemble the data in the RTP packets into a valid VC-2 Sequence:
RTPパケットのデータを有効なVC-2シーケンスに再構成するには：
o The receiver SHOULD take the data from each packet with a Parse Code of 0x00 and prepend a valid VC-2 Parse Info Header (Figure 8) with the same Parse Code (0x00). The resulting Sequence Header Parse Info Header and Data Unit MUST be included in the output stream before any coded pictures that followed the packet being processed in the RTP stream, unless an identical Sequence Header has already been included, and they MAY be repeated (with appropriate modifications to the next and previous header offsets) at any point that results in a valid VC-2 Stream.
o 受信者は、解析コード0x00の各パケットからデータを取得し、有効なVC-2解析情報ヘッダー（図8）に同じ解析コード（0x00）を付加する必要があります（SHOULD）。結果のシーケンスヘッダー解析情報ヘッダーとデータユニットは、RTPストリームで処理されているパケットに続くコード化された画像の前に出力ストリームに含める必要があります。ただし、同じシーケンスヘッダーが既に含まれていない場合、それらを繰り返すことができます（適切な有効なVC-2ストリームになる任意の時点での次および前のヘッダーオフセットへの変更）。
o The receiver SHOULD take the data from each packet with a Parse Code of 0xEC and No. of Slices set to 0 (which together indicate that this packet contains the Transform Parameters for a coded picture) and prepend with the same Parse Code a valid VC-2 Parse Info Header (Figure 8) followed by the picture number, Fragment data length, and slice count (0).
o 受信者は、0xECの解析コードと0に設定されたスライス数（各パケットがコード化された画像の変換パラメータを含むことを示す）で各パケットからデータを取得し、同じ解析コードを有効なVC-で付加する必要があります（SHOULD）。 2解析情報ヘッダー（図8）に続いて、画像番号、フラグメントデータ長、スライスカウント（0）。
o The receiver SHOULD take the data from each packet with a Parse Code of 0xEC and No. of Slices not set to 0 (which together indicate that this packet contains Coded Slices) and prepend with the same Parse Code a valid VC-2 Parse Info Header (Figure 8) followed by the picture number, Fragment data length, slice count, x offset and y offset taken from the packet header.
o 受信者は、0xECの解析コードと0に設定されていないスライス数（各パケットがコード化スライスを含むことを示す）で各パケットからデータを取得し、同じ解析コードを有効なVC-2解析情報ヘッダーに付加する必要があります（SHOULD）。 （図8）に続いて、画像番号、フラグメントデータ長、スライスカウント、パケットヘッダーから取得したxオフセットとyオフセット。
o A receiver MAY combine all Fragment Data Units (with Parse Code 0xEC) and the same picture number into a single picture Data Unit with Parse Code 0xE8. If the Stream is required to comply with major versions 1 or 2 of the VC-2 specification, then this MUST be done.
o レシーバーは、すべてのフラグメントデータユニット（解析コード0xEC付き）と同じ画像番号を、解析コード0xE8の単一の画像データユニットに組み合わせることができます（MAY）。 StreamがVC-2仕様のメジャーバージョン1または2に準拠する必要がある場合は、これを実行する必要があります。
o The receiver SHOULD take the data from each packet with a Parse Code of 0x20 and the B bit set and prepend a valid VC-2 Parse Info Header (Figure 8) with the Parse Code 0x20, and then take each subsequent packet with Parse Code 0x20 without the B bit set and append its payload to the growing Data Unit. When all packets for a particular Data Unit have been received, it SHOULD be included in the output stream. The final packet for a Data Unit will have the E bit set.
o 受信者は、0x20の解析コードとBビットが設定された各パケットからデータを取得し、有効なVC-2解析情報ヘッダー（図8）に解析コード0x20を付加し、その後、解析コード0x20の後続の各パケットを取得する必要があります（SHOULD）。 Bビットを設定せずに、ペイロードを増大するデータユニットに追加します。特定のデータユニットのすべてのパケットが受信されると、それは出力ストリームに含まれる必要があります。データユニットの最後のパケットにはEビットが設定されます。
o Once a Data Unit has been assembled, whether a Sequence Header, Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, the next parse offset and previous parse offset values in its Parse Info Header SHOULD be filled with the offset between the start of the header and the start of the next or previous header.
o データユニットが組み立てられると、シーケンスヘッダー、コード化画像フラグメント、コード化画像、または補助データユニットのいずれであっても、その解析情報ヘッダー内の次の解析オフセットと以前の解析オフセット値は、開始の開始間のオフセットで埋められる必要があります（SHOULD）。ヘッダーと次または前のヘッダーの開始。
o An End of Sequence Parse Info Header MAY be inserted when a packet with Parse Code set to 0x10 is encountered, or at any other time that is allowed in a valid VC-2 Stream. After an End of Sequence Parse Info Header is included in the output stream, either the Stream must end, or it MUST be followed by a Sequence Header indicating the start of a new Sequence. The next parse offset of the End of Sequence header MUST be set to 0, and the previous parse offset SHOULD be filled with the offset from the start of the previous Parse Info Header in the Stream.
o End of Sequence解析情報ヘッダーは、解析コードが0x10に設定されたパケットが検出された場合、または有効なVC-2ストリームで許可されている他の任意の時点で挿入される場合があります。 End of Sequence Parse Infoヘッダーが出力ストリームに含まれた後、Streamは終了するか、新しいシーケンスの開始を示すシーケンスヘッダーが続く必要があります。 End of Sequenceヘッダーの次の解析オフセットは0に設定する必要があり、前の解析オフセットは、ストリーム内の前の解析情報ヘッダーの開始からのオフセットで埋める必要があります（SHOULD）。
o A Padding Data Parse Info Header MAY be inserted when a packet with Parse Code set to 0x30 and the B bit set is encountered, or at any other time that is allowed in a valid VC-2 Stream. The length of the accompanying Data Unit MAY have any value, and its contents MUST be set to a series of zero bytes. The next parse offset and previous parse offset values in its Parse Info Header SHOULD be filled with the offset between the start of the header and the start of the next or previous header.
oパディングデータ解析情報ヘッダーは、解析コードが0x30に設定され、Bビットが設定されたパケットが検出された場合、または有効なVC-2ストリームで許可されているその他の時点で挿入される場合があります。付随するデータユニットの長さには任意の値を設定できますが、その内容は一連のゼロバイトに設定する必要があります。その解析情報ヘッダーの次の解析オフセットと前の解析オフセット値は、ヘッダーの開始と次または前のヘッダーの開始との間のオフセットで埋められる必要があります。
VC-2 provides no underlying protection against data loss, so it may be useful to employ Forward Error Correction to the Stream. A mechanism for doing this to a generic RTP stream is specified in RFC 5109 [RFC5109]. If making use of this mechanism to provide multilevel protection, then the packets SHOULD be assigned to layers based upon their packet type, with the packet types being, in order of importance:
VC-2は、データ損失に対する根本的な保護を提供しないため、ストリームへの前方誤り訂正を採用すると便利な場合があります。これを汎用RTPストリームに対して行うメカニズムは、RFC 5109 [RFC5109]で指定されています。このメカニズムを利用してマルチレベルの保護を提供する場合、パケットは、パケットタイプに基づいて、重要度の順に、パケットタイプに基づいてレイヤーに割り当てられる必要があります（SHOULD）。
1. Sequence Headers
1. シーケンスヘッダー
2. Fragments containing Transform Parameters
2. 変換パラメーターを含むフラグメント
3. Fragments containing Coded Slices
3. コード化されたスライスを含むフラグメント
4. Auxiliary Data and end of Sequence
4. 補助データとシーケンスの終わり
5. Padding
5. パディング
It is RECOMMENDED that if multilevel protection is to be used, then one layer will protect all Sequence Header packets, and a second will protect Sequence Headers and all Fragments. If desired, a third layer MAY protect Auxiliary Data and End of Sequence packets. Padding data SHOULD NOT be protected by FEC.
マルチレベル保護を使用する場合、1つのレイヤーがすべてのシーケンスヘッダーパケットを保護し、2番目のレイヤーがシーケンスヘッダーとすべてのフラグメントを保護することが推奨されます。必要に応じて、第3層は補助データとシーケンスの終わりのパケットを保護してもよい（MAY）。パディングデータはFECによって保護されるべきではありません。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [RFC3550] and any applicable RTP profile -- e.g., RFC 3551 [RFC3551]. An additional requirement if best-effort service is being used is: users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Circuit Breakers [RFC8083] are an update to RTP [RFC3550] that defines criteria for when one is required to stop sending RTP Packet Streams, and applications implementing this standard MUST comply with it. RFC 8085 [RFC8085] provides additional information on the best practices for applying congestion control to UDP streams.
RTPの輻輳制御は、RFC 3550 [RFC3550]および該当するすべてのRTPプロファイル（RFC 3551 [RFC3551]など）に従って使用する必要があります（SHALL）。ベストエフォートサービスが使用されている場合の追加要件は、次のとおりです。このペイロード形式のユーザーは、パケット損失を監視して、パケット損失率が許容可能なパラメータ内であることを確認する必要があります。サーキットブレーカー[RFC8083]はRTP [RFC3550]のアップデートであり、RTPパケットストリームの送信を停止する必要がある場合の基準を定義します。 RFC 8085 [RFC8085]は、UDPストリームに輻輳制御を適用するためのベストプラクティスに関する追加情報を提供します。
In particular, it should be noted that the expected data rate for RTP sessions that use this profile is likely to be in the range of gigabits per second. If used on a closed network that has been correctly provisioned for the expected data rates, this might not pose a problem, but there is always the risk of data getting out onto the open internet.
特に、このプロファイルを使用するRTPセッションの予想データレートは、ギガビット/秒の範囲である可能性が高いことに注意してください。予想されるデータレートに対して正しくプロビジョニングされている閉じたネットワークで使用する場合、これは問題を引き起こさない可能性がありますが、常にオープンなインターネットにデータが流出するリスクがあります。
This RTP payload format is identified using the 'video/vc2' media type, which is registered in accordance with RFC 4855 [RFC4855], using the template of RFC 6838 [RFC6838].
このRTPペイロード形式は、RFC 6838 [RFC6838]のテンプレートを使用して、RFC 4855 [RFC4855]に従って登録されている「video / vc2」メディアタイプを使用して識別されます。
Type name:
タイプ名：
video
ビデオ
Subtype name:
サブタイプ名：
vc2
vc2
Required parameters:
必須パラメーター：
rate: The RTP timestamp clock rate. Applications using this payload format SHOULD use a value of 90000.
rate：RTPタイムスタンプクロックレート。このペイロード形式を使用するアプリケーションは、90000の値を使用する必要があります（SHOULD）。
profile: The VC-2 profile in use. The only value currently allowed is "HQ".
profile：使用中のVC-2プロファイル。現在許可されている唯一の値は「HQ」です。
Optional parameters:
オプションのパラメーター：
version: the VC-2 specification version in use. The only currently allowed value is "3" since all Sequences transported using this mechanism will contain HQ Picture Fragment Data Units, which the VC-2 specification [VC2] defines as requiring version 3.
version：使用中のVC-2仕様のバージョン。このメカニズムを使用してトランスポートされるすべてのシーケンスにはHQピクチャフラグメントデータユニットが含まれるため、現在許可されている唯一の値は「3」です。これは、VC-2仕様[VC2]でバージョン3が必要と定義されています。
level: The VC-2 level in use. Any integer may be used.
level：使用中のVC-2レベル。任意の整数を使用できます。
Encoding considerations:
エンコードに関する考慮事項：
This media type is framed and binary; see Section 4.8 in RFC 6838 [RFC6838].
このメディアタイプはフレーム付きでバイナリです。 RFC 6838 [RFC6838]のセクション4.8をご覧ください。
Security considerations:
セキュリティに関する考慮事項：
Please see the security considerations in RFC 8450.
RFC 8450のセキュリティに関する考慮事項を参照してください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification:
公開された仕様：
RFC 8450
RFC 8450
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Video Communication.
ビデオコミュニケーション。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：なし
Additional information: N/A
追加情報：なし
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
James P. Weaver <james.barrett@bbc.co.uk>
Intended usage:
使用目的：
COMMON
一般
Restrictions on usage:
使用上の制限：
This media type depends on RTP framing and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。現在、他のフレーミングプロトコル内のトランスポートは定義されていません。
Author:
著者：
James P. Weaver <james.barrett@bbc.co.uk>
Change controller:
コントローラを変更：
IETF PAYLOAD Working Group delegated from the IESG.
IESGから委任されたIETF PAYLOADワーキンググループ。
Provisional registration? (standards tree only):
仮登録？ （標準ツリーのみ）：
No
の
The mapping of the above-defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855 [RFC4855].
上記で定義されたペイロード形式のメディアタイプとそのパラメータのマッピングは、RFC 4855 [RFC4855]のセクション3に従って行う必要があります。
o The type name ("video") goes in SDP "m=" as the media name.
o タイプ名（「ビデオ」）は、メディア名としてSDP「m =」に入ります。
o The subtype name ("vc2") goes in SDP "a=rtpmap" as the encoding name, followed by a slash ("/") and the rate parameter.
o サブタイプ名（ "vc2"）は、SDP "a = rtpmap"にエンコード名として続き、その後にスラッシュ（ "/"）とrateパラメーターが続きます。
o The required parameter profile and the optional parameters version and level, when present, are included in the "a=fmtp" attribute line of SDP as a semicolon-separated list of parameter=value pairs.
o 必要なパラメータープロファイルとオプションのパラメーターのバージョンとレベル（存在する場合）は、SDPの "a = fmtp"属性行に、parameter = valueペアのセミコロン区切りリストとして含まれています。
Version and level SHALL be specified in decimal when present.
バージョンとレベルは、存在する場合は10進数で指定する必要があります。
For example, a sample SDP mapping for VC-2 could be as follows:
たとえば、VC-2のサンプルSDPマッピングは次のようになります。
m=video 30000 RTP/AVP 112
a=rtpmap:112 vc2/90000
a=fmtp:112 profile=HQ;version=3;level=0
In this example, a dynamic payload type 112 is used for vc-2 data. The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line after the subtype. In the "a=fmtp:" line, profile HQ, version 3, and level 0 (unknown or non-standard level) are specified.
この例では、vc-2データに動的ペイロードタイプ112が使用されています。 90 kHz RTPタイムスタンプレートは、サブタイプの後の "a = rtpmap"行で指定されます。 「a = fmtp：」の行では、プロファイルHQ、バージョン3、およびレベル0（不明または非標準レベル）が指定されています。
All parameters are declarative.
すべてのパラメーターは宣言型です。
IANA has registered 'video/vc2' as specified in Section 7.1. The media type has been added to the IANA registry for "RTP Payload Format Media Types" <https://www.iana.org/assignments/rtp-parameters>.
IANAは、セクション7.1で指定されている「video / vc2」を登録しています。メディアタイプは、「RTP Payload Format Media Types」<https://www.iana.org/assignments/rtp-parameters>のIANAレジストリに追加されました。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. However, as "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lies with anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this section discusses the security-impacting properties of the payload format itself.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]およびRTP / AVP [RFC3551]、RTP / AVPF [RFC4585]、RTP / SAVP [RFC3711 ]、またはRTP / SAVPF [RFC5124]。ただし、「RTPフレームワークのセキュリティ保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]が説明しているように、機密性などの基本的なセキュリティ目標を達成するためにどのソリューションが使用されるかを話し合う、または義務付けるのは、RTPペイロード形式の責任ではありません。完全性、および一般的なRTPのソースの信頼性。この責任は、アプリケーションでRTPを使用するすべての人にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは、「RTPセッションを保護するためのオプション」[RFC7201]にあります。アプリケーションは、1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。このセクションの残りの部分では、ペイロード形式自体のセキュリティに影響を与えるプロパティについて説明します。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.
このRTPペイロード形式とそのメディアデコーダーは、パケット処理の受信側の計算の複雑さに大きな不均一性を示さないため、病理学的データの受信が原因でサービス拒否の脅威を引き起こす可能性はほとんどありません。また、RTPペイロード形式にはアクティブコンテンツが含まれていません。
To avoid buffer overruns when processing these packets, the receiver MUST consider both the reported Fragment length and the actual received size of a packet containing slice data.
これらのパケットを処理するときのバッファオーバーランを回避するために、受信者は、報告されたフラグメント長とスライスデータを含むパケットの実際の受信サイズの両方を考慮する必要があります。
In some cases, the transmitter may need to decode variable-length coded headers in order to extract some data from the VC-2 bitstream before assembling packets. This process is potentially subject to buffer overruns if not implemented carefully.
場合によっては、パケットを組み立てる前にVC-2ビットストリームからデータを抽出するために、トランスミッターが可変長コード化ヘッダーをデコードする必要がある場合があります。このプロセスは、慎重に実装しないと、バッファオーバーランの可能性があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<https：//www.rfc-editor。 org / info / rfc3551>。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <https://www.rfc-editor.org/info/rfc4855>.
[RFC4855] Casner、S。、「RTPペイロード形式のメディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<https://www.rfc-editor.org/info/rfc4855>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：//www.rfc- editor.org/info/rfc6838>。
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.
[RFC8083] Perkins、C。およびV. Singh、「Multimedia Congestion Control：Circuit Breaks for Unicast RTP Sessions」、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<https://www.rfc-editor.org/info / rfc8083>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org / info / rfc8085>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[VC2] SMPTE, "SMPTE Standard - VC-2 Video Compression", ST 2042-1:2017, DOI 10.5594/SMPTE.ST2042-1.2017, June 2017, <https://ieeexplore.ieee.org/servlet/ opac?punumber=7967894>.
[VC2] SMPTE、「SMPTE標準-VC-2ビデオ圧縮」、ST 2042-1：2017、DOI 10.5594 / SMPTE.ST2042-1.2017、2017年6月、<https://ieeexplore.ieee.org/servlet/ opac？ punumber = 7967894>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<https://www.rfc-editor.org/info/rfc3711>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A。、編、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<https://www.rfc-editor.org/info/rfc5109> 。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<https ：//www.rfc-editor.org/info/rfc5124>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<https://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <https://www.rfc-editor.org/info/rfc7202>.
[RFC7202]パーキンス、C。およびM.ウェスターランド、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<https：//www.rfc- editor.org/info/rfc7202>。
Author's Address
著者のアドレス
James P. Weaver BBC
ジェームスP.ウィーバーBBC
Email: james.barrett@bbc.co.uk