[要約] RFC 6185は、H.264 Reduced-Complexity Decoding Operation（RCDO）ビデオのためのRTPペイロード形式を定義しています。このRFCの目的は、RCDOビデオの効率的な転送と再生を可能にすることです。
Internet Engineering Task Force (IETF) T. Kristensen
Request for Comments: 6185 P. Luthi
Category: Standards Track TANDBERG
ISSN: 2070-1721 May 2011
RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video
h.264複合デコード操作（RCDO）ビデオのRTPペイロード形式
Abstract
概要
This document describes an RTP payload format for the Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format.
このドキュメントでは、ITU-Tの推奨H.241で指定されているように、H.264ベースラインプロファイルビットストリームの複数回デコード操作（RCDO）のRTPペイロード形式について説明します。RCDOは、ビデオ処理のデコードコストとリソース消費を削減します。RCDO RTPペイロード形式は、H.264 RTPペイロード形式に基づいています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6185.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6185で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Media Format Background . . . . . . . . . . . . . . . . . . . 3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Congestion Control Considerations . . . . . . . . . . . . . . 3
6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 3
6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 4
7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 20
7.2. Declarative SDP Considerations . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
ITU-T Recommendation H.241 [3] specifies a Reduced-Complexity Decoding Operation (RCDO) for use with H.264 [2] Baseline profile bitstreams. It also specifies a bitstream constraint associated with RCDO and a mechanism for signaling RCDO within the bitstream. The RCDO signaling indicates that the bitstream conforms to the bitstream constraint and that the decoder shall apply the RCDO decoding process to the bitstream.
ITU-Tの推奨H.241 [3]は、H.264 [2]ベースラインプロファイルビットストリームで使用するための複数回複合デコード操作（RCDO）を指定します。また、RCDOに関連するビットストリーム制約と、ビットストリーム内のRCDOをシグナル伝えるメカニズムも指定します。RCDOシグナル伝達は、ビットストリームがビットストリームの制約に準拠し、デコーダーがRCDOデコードプロセスをビットストリームに適用することを示しています。
RCDO for H.264 offers a solution to support higher resolutions at the same high frame rates used in current implementations. This is achieved by reducing the processing requirements and thus reducing the decoding cost/resource consumption of the video processing.
RCDO for H.264は、現在の実装で使用されている同じ高フレームレートでより高い解像度をサポートするソリューションを提供します。これは、処理要件を削減し、ビデオ処理のデコードコスト/リソース消費を削減することにより達成されます。
This document defines media type parameters and allows use in systems based on the Session Description Protocol (SDP) [8] for signaling.
このドキュメントは、メディアタイプのパラメーターを定義し、セッション説明プロトコル（SDP）[8]に基づいてシステムで使用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[4]に記載されているように解釈される。
The Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams is specified in Annex B of H.241 [3]. RCDO is specified as a separate H.264 mode and is distinct from any profile defined in H.264. An RCDO bitstream obeys all the constraints of the Baseline profile.
H.264ベースラインプロファイルのBitStreamsの複数回複合デコード操作（RCDO）は、H.241の付録Bで指定されています[3]。RCDOは別のH.264モードとして指定されており、H.264で定義されているプロファイルとは異なります。RCDOビットストリームは、ベースラインプロファイルのすべての制約に従います。
The media format is based on the H.264 RTP payload format as specified in RFC 6184 [1]. Therefore, RFC 6184 constitutes the basis for this document and is referred to several times.
メディア形式は、RFC 6184 [1]で指定されているH.264 RTPペイロード形式に基づいています。したがって、RFC 6184はこのドキュメントの基礎を構成し、数回参照されます。
In order to signal H.264 additional modes, Table 8-13 of H.241 [3] specifies an AdditionalModesSupported parameter. Currently, the only additional mode defined is RCDO.
H.264の追加モードを信号にするために、H.241 [3]の表8-13は、追加のモデスサポートパラメーターを指定します。現在、定義されている追加モードはRCDOです。
Informative note: Other additional modes may be defined in the future. H.264 additional modes may or may not be distinct from the profiles in H.264.
有益なメモ：他の追加モードは将来定義される場合があります。H.264追加モードは、H.264のプロファイルとは異なる場合があります。
A separate media subtype, named H264-RCDO, is defined to ensure backward compatibility with deployed implementations of H.264.
H264-RCDOという名前の別のメディアサブタイプは、H.264の展開された実装との後方互換性を確保するために定義されています。
The payload format defined in Section 5 of RFC 6184 [1] SHALL be used. This includes the RTP header usage and the payload format in RFC 6184. Examples of typical RTP packets can be found in RFC 6184.
RFC 6184 [1]のセクション5で定義されているペイロード形式を使用するものとします。これには、RTPヘッダーの使用法とRFC 6184のペイロード形式が含まれます。典型的なRTPパケットの例は、RFC 6184にあります。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [6] and with any applicable RTP profile, e.g., RFC 3551 [7]. If best-effort service is being used, users of this payload format SHALL monitor packet loss to ensure that the packet loss rate is within acceptable parameters.
RTPの輻輳制御は、RFC 3550 [6]および該当するRTPプロファイル、例えばRFC 3551 [7]に従って使用するものとします。Best-Effortサービスが使用されている場合、このペイロード形式のユーザーは、パケットの損失を監視して、パケットの損失率が許容可能なパラメーター内にあることを確認するものとします。
This RTP payload format is identified using the H264-RCDO media subtype, which is registered in accordance with RFC 4855 [10], and using the template of RFC 4288 [13].
このRTPペイロード形式は、RFC 4855 [10]に従って登録されており、RFC 4288 [13]に従って登録されているH264-RCDOメディアサブタイプを使用して識別されます。
Informative note: The media subtype definition for H264-RCDO is based on the definition of the H264 media subtype as specified in Section 8.1 of RFC 6184 [1]. Except for the profile-level-id parameter, for which new semantics are specified below, the optional parameters are copied from RFC 6184 [1] in order to provide a complete, self-contained media subtype registration to IANA. The references are updated to match the numbering used in this document.
有益な注意：H264-RCDOのメディアサブタイプ定義は、RFC 6184 [1]のセクション8.1で指定されているH264メディアサブタイプの定義に基づいています。以下に新しいセマンティクスを指定するプロファイルレベルIDパラメーターを除き、IANAに完全な自己完結型メディアサブタイプの登録を提供するために、オプションのパラメーターがRFC 6184 [1]からコピーされます。参照は、このドキュメントで使用されている番号付けと一致するように更新されます。
The media subtype for RCDO for H.264 has been allocated from the IETF tree.
H.264のRCDOのメディアサブタイプは、IETFツリーから割り当てられています。
Type name: video
タイプ名：ビデオ
Subtype name: H264-RCDO
サブタイプ名：H264-RCDO
Required parameters:
必要なパラメーター：
rate: Indicates the RTP timestamp clock rate. The rate value MUST be 90000.
レート：RTPタイムスタンプクロックレートを示します。レート値は90000でなければなりません。
Optional parameters:
オプションのパラメーター：
profile-level-id: A base16 RFC 4648 [9] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in H.264 [2]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in H.264 [2], but other values for it may be specified in the future by ITU-T or ISO/IEC.
プロファイルレベルID：ベース16 RFC 4648 [9]（ヘキサデシマ）シーケンスパラメーターセットNALユニットの次の3バイトの表現は、H.264 [2]：1）プロファイル_IDC、2）で参照されているバイトで指定されています。constraint_set0_flag、constraint_set1_flag、constraint_set2_flag、constraint_set3_flag、constraint_set4_flag、constraint_set5_flag、およびreserved_zero_2bitsのconstraint_set2_flag、constraint_set2_flag、constraint_set2_flag、constraint_set2_flagの値で構成されるプロファイル-IOPとして、最も重要な順序でビットイニフィシャル順に並んでいます。h.264 [2]では、remervered_zero_2bitsは0に等しくなる必要があることに注意してください。ただし、将来、ITU-TまたはISO/IECによって他の値が指定される場合があります。
The profile-level-id parameter indicates the default sub-profile (i.e., the subset of coding tools that may have been used to generate the stream or that the receiver supports) and the default level of the stream or the receiver supports.
プロファイルレベル-IDパラメーターは、デフォルトのサブプロファイル（つまり、ストリームを生成するために使用された可能性のあるコーディングツールのサブセットまたは受信機がサポートする可能性がある）と、ストリームまたはレシーバーのサポートのデフォルトレベルを示します。
RCDO is distinct from any profile; this implies that the profile value 0 (no profile) and the profile_idc byte of the profile-level-id parameter are equal to 0. An RCDO bitstream MUST obey all the constraints of the Baseline profile. Therefore, only constraint_set0_flag is equal to 1 in the profile-iop part of the profile-level-id parameter; the remaining bits are set to 0.
RCDOは、任意のプロファイルとは異なります。これは、プロファイル値0（プロファイルなし）とプロファイルレベルIDパラメーターのプロファイル_IDCバイトが0に等しいことを意味します。RCDOビットストリームは、ベースラインプロファイルのすべての制約に従う必要があります。したがって、constraint_set0_flagのみが、プロファイルレベルIDパラメーターのプロファイル-IOP部分の1に等しくなります。残りのビットは0に設定されています。
If the profile-level-id parameter is used to indicate properties of a NAL unit stream, it indicates that, to decode the stream, the minimum subset of coding tools a decoder has to support is the default sub-profile, and the lowest level the decoder has to support is the default level.
プロファイルレベルIDパラメーターを使用してNALユニットストリームのプロパティを示す場合、ストリームをデコードするために、デコーダーがサポートするコードツールの最小サブセットはデフォルトのサブプロファイルであり、最低レベルであることを示します。デコーダーがサポートする必要があるのはデフォルトレベルです。
If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. If max-recv-level is not present, the default level from profile-level-id indicates the highest level the codec wishes to support. If max-recv-level is present, it indicates the highest level the codec supports for receiving. For either receiving or sending, all levels that are lower than the highest level supported MUST also be supported.
プロファイルレベルIDパラメーターが機能交換またはセッションのセットアップに使用されている場合、デフォルトのサブプロファイルに等しいコーディングツールのサブセットが、コーデックが受信と送信の両方をサポートすることを示します。Max-Recv-Levelが存在しない場合、プロファイルレベルIDからのデフォルトレベルは、コーデックがサポートしたい最高レベルを示します。Max-Recv-Levelが存在する場合、Codecが受信するためにサポートする最高レベルを示します。受信または送信のいずれかの場合、サポートされている最高レベルよりも低いすべてのレベルもサポートする必要があります。
For example, if a codec supports level 1.3, the profile-level-id becomes 00800d, in which 00 indicates the "no profile" value, 80 indicates the constraints of the Baseline profile, and 0d indicates level 1.3. When level 2.1 is supported, the profile-level-id becomes 008015.
たとえば、コーデックがレベル1.3をサポートする場合、プロファイルレベルIDは00800Dになり、00は「プロファイルなし」値を示し、80はベースラインプロファイルの制約を示し、0Dはレベル1.3を示します。レベル2.1がサポートされると、プロファイルレベルIDは008015になります。
If no profile-level-id is present, level 1 (i.e., equivalent to profile-level-id 00800a) MUST be implied.
プロファイルレベルIDが存在しない場合、レベル1（つまり、プロファイルレベルID 00800Aに相当）を暗示する必要があります。
Informative note: The definitions of the remaining optional parameters below are copied verbatim from Section 8.1 of RFC 6184 [1]. Only the references are updated to match the numbering used in this document.
有益な注意：以下の残りのオプションパラメーターの定義は、RFC 6184 [1]のセクション8.1から逐語的にコピーされています。このドキュメントで使用されている番号と一致するように、参照のみが更新されます。
max-recv-level: This parameter MAY be used to indicate the highest level a receiver supports when the highest level is higher than the default level (the level indicated by profile-level-id). The value of max-recv-level is a base16 (hexadecimal) representation of the two bytes after the syntax element profile_idc in the sequence parameter set NAL unit specified in H.264 [2]: profile-iop (as defined above) and level_idc. If the level_idc byte of max-recv-level is equal to 11 and bit 4 of the profile-iop byte of max-recv-level is equal to 1 or if the level_idc byte of max-recv-level is equal to 9 and bit 4 of the profile-iop byte of max-recv-level is equal to 0, the highest level the receiver supports is Level 1b. Otherwise, the highest level the receiver supports is equal to the level_idc byte of max-recv-level divided by 10.
MAX-RECV-LEVEL：このパラメーターは、最高レベルがデフォルトレベル（プロファイルレベルIDで示されるレベル）よりも高いレベルが高い場合、レシーバーがサポートする最高レベルを示すために使用できます。Max-Recv-Levelの値は、H.264 [2]で指定されたシーケンスパラメーターセットNALユニットの構文要素プロファイル_IDCの後の2バイトのベース16（ヘキサデシマル）表現です：プロファイル-IOP（上記のように）およびlevel_idc。max-recv-levelのlevel_idcバイトが11に等しい場合、max-recv-revelのプロファイルバイトのビット4が1に等しい場合、またはmax-recv-revelのlevel_idcバイトが9およびビットに等しい場合MAX-RECVレベルのプロファイルバイトの4は0に等しく、レシーバーがサポートする最高レベルはレベル1Bです。それ以外の場合、レシーバーがサポートする最高レベルは、MAX-RECVレベルのレベル_IDCバイトを10で割ったものに等しくなります。
max-recv-level MUST NOT be present if the highest level the receiver supports is not higher than the default level.
受信者がサポートする最高レベルがデフォルトレベルよりも高くない場合、MAX-RECVレベルが存在しないでください。
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: These parameters MAY be used to signal the capabilities of a receiver implementation. These parameters MUST NOT be used for any other purpose. The highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter MUST be such that the receiver is fully capable of supporting. max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br MAY be used to indicate capabilities of the receiver that extend the required capabilities of the signaled highest level, as specified below.
MAX-MBPS、MAX-SMBPS、MAX-FS、MAX-CPB、MAX-DPB、およびMAX-BR：これらのパラメーターを使用して、受信機の実装の機能を信号することができます。これらのパラメーターは、他の目的に使用してはなりません。プロファイルレベルIDパラメーターまたはMAX-RECVレベルのパラメーターの値で伝えられる最高レベルは、受信機が完全にサポートできるようにする必要があります。MAX-MBPS、MAX-SMBPS、MAX-FS、MAX-CPB、MAX-DPB、およびMAX-BRを使用して、以下に指定するように、信号された最高レベルの必要な機能を拡張する受信機の機能を示すことができます。
When more than one parameter from the set (max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br) is present, the receiver MUST support all signaled capabilities simultaneously. For example, if both max-mbps and max-br are present, the signaled highest level with the extension of both the frame rate and bitrate is supported. That is, the receiver is able to decode NAL unit streams in which the macroblock processing rate is up to max-mbps (inclusive), the bitrate is up to max-br (inclusive), the coded picture buffer size is derived as specified in the semantics of the max-br parameter below, and the other properties comply with the highest level specified in the value of the profile-level-id parameter or the max-recv-level parameter.
セットの複数のパラメーター（MAX-MBPS、MAX-SMBPS、MAX-FS、MAX-CPB、MAX-DPB、MAX-BR）が存在する場合、受信機はすべてのシグナル機能を同時にサポートする必要があります。たとえば、MAX-MBPとMax-BRの両方が存在する場合、フレームレートとビットレートの両方の拡張により、シグナル付き最高レベルがサポートされています。つまり、レシーバーは、マクロブロック処理速度が最大MBPS（包括的）までのNALユニットストリームをデコードできます。ビットレートはMAX-BR（包括的）までです。以下のMAX-BRパラメーターのセマンティクスと他のプロパティは、プロファイルレベルIDパラメーターまたはMAX-RECVレベルパラメーターの値で指定された最高レベルに準拠しています。
If a receiver can support all the properties of Level A, the highest level specified in the value of the profile-level-id parameter or the max-recv-level parameter MUST be Level A (i.e., MUST NOT be lower than Level A). In other words, a receiver MUST NOT signal values of max-mbps, max-fs, max-cpb, max-dpb, and max-br that taken together meet the requirements of a higher level compared to the highest level specified in the value of the profile-level-id parameter or the max-recv-level parameter.
受信者がレベルAのすべてのプロパティをサポートできる場合、プロファイルレベルIDパラメーターまたはMAX-RECVレベルパラメーターの値で指定された最高レベルはレベルA（つまり、レベルAよりも低くしないでください）である必要があります。。言い換えれば、レシーバーは、MAX-MBPS、MAX-FS、MAX-CPB、MAX-DPB、およびMAX-BRの値を、値で指定された最高レベルと比較して、より高いレベルの要件を満たしている必要はありません。プロファイルレベルIDパラメーターまたはMAX-RECVレベルのパラメーターの。
Informative note: When the OPTIONAL media type parameters are used to signal the properties of a NAL unit stream, max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br are not present, and the value of profile-level-id must always be such that the NAL unit stream complies fully with the specified profile and level.
有益なメモ：オプションのメディアタイプパラメーターを使用して、NALユニットストリームのプロパティを信号する場合、MAX-MBPS、MAX-SMBPS、MAX-FS、MAX-CPB、MAX-DPB、およびMAX-BRは存在しません。プロファイルレベルIDの値は、指定されたプロファイルとレベルに完全に準拠するように、常に常にでなければなりません。
max-mbps: The value of max-mbps is an integer indicating the maximum macroblock processing rate in units of macroblocks per second. The max-mbps parameter signals that the receiver is capable of decoding video at a higher rate than is required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-mbps is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxMBPS value in Table A-1 of H.264 [2] for the signaled highest level is replaced with the value of max-mbps. The value of max-mbps MUST be greater than or equal to the value of MaxMBPS given in Table A-1 of H.264 [2] for the highest level. Senders MAY use this knowledge to send pictures of a given size at a higher picture rate than is indicated in the signaled highest level.
MAX-MBPS：Max-MBPSの値は、マクロブロックの単位で最大マクロブロック処理速度を示す整数です。MAX-MBPSパラメーターは、受信機がプロファイルレベルIDパラメーターまたはMAX-RECV-LEVELパラメーターの値で伝達されるシグナル最高レベルで必要とされるよりも高いレートでビデオをデコードできることを示しています。MAX-MBPSが信号された場合、受信機は、信号された最高レベルのH.264 [2]の表A-1のMAXMBPS値が次のことを除いて、シグナルの高いレベルに適合するNALユニットストリームをデコードできる必要があります。Max-MBPSの値に置き換えられました。Max-MBPの値は、最高レベルのH.264 [2]の表A-1に示されているMaxMBPの値以上でなければなりません。送信者は、この知識を使用して、信号された最高レベルで示されているよりも高い画像レートで特定のサイズの写真を送信することができます。
max-smbps: The value of max-smbps is an integer indicating the maximum static macroblock processing rate in units of static macroblocks per second, under the hypothetical assumption that all macroblocks are static macroblocks. When max-smbps is signaled, the MaxMBPS value in Table A-1 of H.264 [2] should be replaced with the result of the following computation:
MAX-SMBPS：MAX-SMBPSの値は、すべてのマクロブロックが静的マクロブロックであるという仮説的な仮定の下で、一秒あたりの静的マクロブロックの単位の最大静的マクロブロック処理速度を示す整数です。Max-SMBPSがシグナルになった場合、H.264 [2]の表A-1のMaxMBPS値は、次の計算の結果に置き換える必要があります。
o If the parameter max-mbps is signaled, set a variable MaxMacroblocksPerSecond to the value of max-mbps. Otherwise, set MaxMacroblocksPerSecond equal to the value of MaxMBPS in Table A-1 of H.264 [2] for the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter.
o パラメーターmax-mbpsが信号が表示されている場合、max-mbpsの値に可変maxmacroblockspersecondを設定します。それ以外の場合は、プロファイルレベルIDパラメーターまたはMAX-RECV-LEVELパラメーターの値で伝達されるシグナル最高レベルのH.264 [2]の表A-1 [2]のMAXMBPSの値に等しく設定されています。
o Set a variable P_non-static to the proportion of non-static macroblocks in picture n.
o 画像nの非静的マクロブロックの割合に可変p_non-staticを設定します。
o Set a variable P_static to the proportion of static macroblocks in picture n.
o 画像nの静的マクロブロックの割合に変数p_staticを設定します。
o The value of MaxMBPS in Table A-1 of H.264 [2] should be considered by the encoder to be equal to:
o H.264 [2]の表A-1のMaxMBPの値は、エンコーダーが次のことと見なす必要があります。
MaxMacroblocksPerSecond * max-smbps / (P_non-static * max-smbps
+ P_static * MaxMacroblocksPerSecond)
The encoder should recompute this value for each picture. The value of max-smbps MUST be greater than or equal to the value of MaxMBPS given explicitly as the value of the max-mbps parameter or implicitly in Table A-1 of H.264 [2] for the signaled highest level. Senders MAY use this knowledge to send pictures of a given size at a higher picture rate than is indicated in the signaled highest level.
エンコーダーは、各画像のこの値を再計算する必要があります。Max-SMBPの値は、Max-MBPSパラメーターの値として明示的に与えられたMAXMBPの値以上であるか、シグナル付き最高レベルのH.264 [2]の表A-1で暗黙的に等しくなければなりません。送信者は、この知識を使用して、信号された最高レベルで示されているよりも高い画像レートで特定のサイズの写真を送信することができます。
max-fs: The value of max-fs is an integer indicating the maximum frame size in units of macroblocks. The max-fs parameter signals that the receiver is capable of decoding larger picture sizes than are required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-fs is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxFS value in Table A-1 of H.264 [2] for the signaled highest level is replaced with the value of max-fs. The value of max-fs MUST be greater than or equal to the value of MaxFS given in Table A-1 of H.264 [2] for the highest level. Senders MAY use this knowledge to send larger pictures at a proportionally lower frame rate than is indicated in the signaled highest level.
MAX-FS：MAX-FSの値は、マクロブロックの単位の最大フレームサイズを示す整数です。MAX-FSパラメーターは、受信機がプロファイルレベルIDパラメーターまたはMAX-RECV-LEVELパラメーターの値で伝達されるシグナル最高レベルで必要とされるよりも大きな画像サイズをデコードできることを信号します。MAX-FSが信号を受ける場合、受信機は、シグナルの高いレベルのH.264 [2]の表A-1のMAXFS値があることを除いて、信号された最高レベルに適合するNALユニットストリームをデコードできる必要があります。MAX-FSの値に置き換えられました。MAX-FSの値は、最高レベルのH.264 [2]の表A-1に示されているMAXFの値以上でなければなりません。送信者は、この知識を使用して、信号された最高レベルで示されているよりも、比例して低いフレームレートで大きな写真を送信することができます。
max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 of H.264 [2]). The max-cpb parameter signals that the receiver has more memory than the minimum amount of coded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-cpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxCPB value in Table A-1 of H.264 [2] for the signaled highest level is replaced with the value of max-cpb (after taking cpbBrVclFactor and cpbBrNALFactor into consideration when needed). The value of max-cpb (after taking cpbBrVclFactor and cpbBrNALFactor into consideration when needed) MUST be greater than or equal to the value of MaxCPB given in Table A-1 of H.264 [2] for the highest level. Senders MAY use this knowledge to construct coded video streams with greater variation of bitrate than can be achieved with the MaxCPB value in Table A-1 of H.264 [2].
MAX-CPB：MAX-CPBの値は、VCL HRDパラメーターの1000ビットの単位とNAL HRDパラメーターの1200ビットの単位単位の最大コード化された画像バッファーサイズを示す整数です。このパラメーターは、cpbbrvclactorとcpbbrnalfactorの単位を使用しないことに注意してください（H.264の表A-1 [2]を参照）。MAX-CPBパラメーターは、受信機がプロファイルレベルIDパラメーターまたはMAX-RECV-LEVELパラメーターの値で伝達されるシグナル最高レベルで必要なコード化された画像バッファメモリの最小量よりも多くのメモリを持っていることを示しています。max-cpbが信号された場合、受信者は、信号された最高レベルのh.264 [2]の表A-1のmaxcpb値があることを除いて、信号された最高レベルに適合するnalユニットストリームをデコードできる必要があります。MAX-CPBの値に置き換えられました（必要に応じてCPBBRVClactorとCpbBrnalFactorを考慮した後）。MAX-CPBの値（必要に応じてCPBBRVCLFactorおよびCpbBrnalFactorを考慮した後）は、最高レベルでH.264 [2]の表A-1に示されているMAXCPBの値以上でなければなりません。送信者は、この知識を使用して、H.264 [2]の表A-1のMAXCPB値で達成できるよりも大きなビットレートのバリエーションでコード化されたビデオストリームを構築することができます。
Informative note: The coded picture buffer is used in the hypothetical reference decoder (Annex C of H.264). The use of the hypothetical reference decoder is recommended in H.264 encoders to verify that the produced bitstream conforms to the standard and to control the output bitrate. Thus, the coded picture buffer is conceptually independent of any other potential buffers in the receiver, including de-interleaving and de-jitter buffers. The coded picture buffer need not be implemented in decoders as specified in Annex C of H.264, but rather standard-compliant decoders can have any buffering arrangements provided that they can decode standard-compliant bitstreams. Thus, in practice, the input buffer for a video decoder can be integrated with de-interleaving and de-jitter buffers of the receiver.
有益なメモ：コード化された画像バッファーは、仮想参照デコーダー（H.264の付録C）で使用されます。H.264エンコーダでは、仮想参照デコーダーの使用を推奨して、生成されたビットストリームが標準に適合し、出力ビットレートを制御することを確認します。したがって、コード化された画像バッファーは、インターレービングやジッター除去バッファを含む、受信機の他の潜在的なバッファーから概念的に独立しています。コード化された画像バッファーは、H.264の付録Cで指定されているデコーダーに実装する必要はありませんが、標準に準拠したデコーダーは、標準に準拠したビットストリームをデコードできる場合は、バッファリング配置を使用できます。したがって、実際には、ビデオデコーダーの入力バッファーは、受信機のインターレビング脱ジッターバッファーと統合できます。
max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max-dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of H.264 [2] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer:
MAX-DPB：Max-DPBの値は、8/3マクロブロックの単位で最大デコードされた画像バッファーサイズを示す整数です。MAX-DPBパラメーターは、受信機がプロファイルレベルIDパラメーターまたはMAX-RECV-LEVELパラメーターの値で伝達されるシグナル最高レベルで必要なデコードされた画像バッファメモリの最小量よりも多くのメモリを持っていることを示しています。max-dpbが信号された場合、受信者は、信号された最高レベルのh.264 [2]の表A-1のmaxdpbmbs値があることを除いて、信号された最高レベルに適合するnalユニットストリームをデコードできる必要があります。MAX-DPB * 3 /8の値に置き換えられました。その結果、MAX-DPBを信号する受信機は、デコードされたフレーム、補完的なフィールドペア、およびデコードされた画像バッファーにペアのないフィールドを保存できる必要があります。
Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16)
Wherein PicWidthInMbs and FrameHeightInMbs are defined in H.264 [2].
ここで、picwidthinmbsとframeheightinmbsはH.264で定義されています[2]。
The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of H.264 [2] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression.
Max-DPBの値は、MaxDPBMBS * 3/8の値以上でなければなりません。これにより、最高レベルのH.264 [2]の表A-1にMAXDPBMBSの値が示されています。送信者は、この知識を使用して、圧縮が改善されたコード化されたビデオストリームを構築することができます。
Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers.
有益なメモ：このパラメーターは、主にITU-Tの推奨H.245の同様のコードポイントを補完するために追加され、シグナリングゲートウェイの設計を容易にします。デコードされた画像バッファーは、再構築されたサンプルを保存します。デコードされた画像バッファーのサイズとRTPで使用されるバッファー、特に介入後のバッファとデジター除去バッファーの間には関係がありません。
Informative note: In RFC 3984, which is obsoleted by RFC 6184, the unit of this parameter was 1024 bytes. The unit has been changed to 8/3 macroblocks in this document. The reason for this change was due to the changes from the 2003 version of the H.264 specification referenced by RFC 3984 to the 2010 version of the H.264 specification referenced by this document, particularly the changes to Table A-1 in the H.264 specification due to addition of color formats and bit depths not supported earlier. The changed semantics of this parameter keeps backward compatibility to RFC 3984 and supports all profiles defined in the 2010 version of the H.264 specification.
有益な注意：RFC 6184によって廃止されたRFC 3984では、このパラメーターの単位は1024バイトでした。このドキュメントでは、ユニットが8/3マクロブロックに変更されました。この変更の理由は、RFC 3984が参照されている2003年バージョンのH.264仕様から、このドキュメントで参照される2010年バージョンのH.264仕様、特にHの表A-1への変更に変更されたことによるものでした。.264カラー形式の追加およびビット深度の追加による仕様以前はサポートされていません。このパラメーターの変更されたセマンティクスは、RFC 3984への逆方向の互換性を維持し、H.264仕様の2010バージョンで定義されているすべてのプロファイルをサポートします。
max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 of H.264 [2]).
MAX-BR：MAX-BRの値は、VCL HRDパラメーターでは1000ビットあたり1000ビットの最大ビデオビットレートと、NAL HRDパラメーターの1秒あたり1200ビットの単位での最大ビデオビットレートを示す整数です。このパラメーターは、cpbbrvclactorとcpbbrnalfactorの単位を使用しないことに注意してください（H.264の表A-1 [2]を参照）。
The max-br parameter signals that the video decoder of the receiver is capable of decoding video at a higher bitrate than is required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter.
MAX-BRパラメーターは、受信機のビデオデコーダーが、プロファイルレベルIDパラメーターまたはMAX-RECVレベルのパラメーターの値で伝えられるシグナル最高レベルで必要とされるよりも高いビットレートでビデオをデコードできることを信号します。。
When max-br is signaled, the video codec of the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the following exceptions in the limits specified by the highest level:
max-brを信号すると、受信機のビデオコーデックは、最高レベルで指定された制限の以下の例外を除き、信号された最高レベルに適合するNALユニットストリームをデコードできる必要があります。
o The value of max-br (after taking cpbBrVclFactor and cpbBrNALFactor into consideration when needed) replaces the MaxBR value in Table A-1 of H.264 [2] for the highest level.
o MAX-BRの値（必要に応じてCPBBRVCLFACTORとCPBBRNALFactorを考慮した後）は、H.264 [2]の表A-1のMAXBR値を最高レベルで置き換えます。
o When the max-cpb parameter is not present, the result of the following formula replaces the value of MaxCPB in Table A-1 of H.264 [2]: (MaxCPB of the signaled level) * max-br / (MaxBR of the signaled highest level).
o MAX-CPBパラメーターが存在しない場合、次の式の結果は、H.264の表A-1のMAXCPBの値を置き換えます[2] ：（シグナルレベルのMaxCPB）最高レベルの信号）。
For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000).
たとえば、メインプロファイルレベル1.2のメインプロファイルレベル1550に等しいメインプロファイルレベル1.2の機能が1550に等しい場合、VCL HRDパラメーターの最大ビデオビットレートが1550 kbits/secの最大ビデオビットレートを示しています。、および4036458ビットのCPBサイズ（1550000 /384000 * 1000 * 1000）。
The value of max-br (after taking cpbBrVclFactor and cpbBrNALFactor into consideration when needed) MUST be greater than or equal to the value MaxBR given in Table A-1 of H.264 [2] for the signaled highest level.
MAX-BRの値（必要に応じてCPBBRVCLFACTORおよびCPBBRNALFACTORを考慮した後）は、シグナル付き最高レベルのH.264 [2]の表A-1に示されている値MAXBR以上でなければなりません。
Senders MAY use this knowledge to send higher bitrate video as allowed in the level definition of Annex A of H.264 to achieve improved video quality.
送信者は、この知識を使用して、H.264の付録Aのレベル定義で許可されているように、より高いビットレートビデオを送信して、ビデオ品質を改善することができます。
Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The assumption that the network is capable of handling such bitrates at any given time cannot be made from the value of this parameter. In particular, no conclusion can be drawn that the signaled bitrate is possible under congestion control constraints.
有益なメモ：このパラメーターは、主にITU-Tの推奨H.245の同様のコードポイントを補完するために追加され、シグナリングゲートウェイの設計を容易にします。ネットワークがいつでもそのようなビットレートを処理できるという仮定は、このパラメーターの値から作成することはできません。特に、輻輳制御の制約の下でシグナル付きのビットレートが可能であるという結論を引き出すことはできません。
redundant-pic-cap: This parameter signals the capabilities of a receiver implementation. When equal to 0, the parameter indicates that the receiver makes no attempt to use redundant coded pictures to correct incorrectly decoded primary coded pictures. When equal to 0, the receiver is not capable of using redundant slices; therefore, a sender SHOULD avoid sending redundant slices to save bandwidth. When equal to 1, the receiver is capable of decoding any such redundant slice that covers a corrupted area in a primary decoded picture (at least partly), and therefore a sender MAY send redundant slices. When the parameter is not present, a value of 0 MUST be used for redundant-pic-cap. When present, the value of redundant-pic-cap MUST be either 0 or 1.
冗長-PIC-CAP：このパラメーターは、受信機の実装の機能を示します。0に等しい場合、パラメーターは、受信機が冗長コード化された写真を使用して、誤ってデコードされたプライマリコード化された写真を修正しようとしないことを示します。0に等しい場合、受信機は冗長スライスを使用できません。したがって、送信者は、帯域幅を保存するために冗長スライスを送信しないようにする必要があります。1に等しい場合、受信機は、プライマリデコードされた画像の破損した領域を（少なくとも部分的に）覆うそのような冗長スライスを解読することができ、したがって、送信者は冗長スライスを送信する場合があります。パラメーターが存在しない場合、冗長-PIC-CAPには0の値を使用する必要があります。存在する場合、冗長-PIC-CAPの値は0または1のいずれかでなければなりません。
When the profile-level-id parameter is present in the same signaling as the redundant-pic-cap parameter and the profile indicated in profile-level-id is such that it disallows the use of redundant coded pictures (e.g., Main profile), the value of redundant-pic-cap MUST be equal to 0. When a receiver indicates redundant-pic-cap equal to 0, the received stream SHOULD NOT contain redundant coded pictures.
プロファイルレベル-IDパラメーターが冗長-PIC-CAPパラメーターと同じシグナリングに存在し、プロファイルレベルIDに示されているプロファイルが、冗長コード化された写真（メインプロファイルなど）の使用を許可するようなものである場合冗長-PIC-CAPの値は0に等しくなければなりません。受信機が0に等しい冗長-PIC-CAPを示す場合、受信ストリームには冗長コード化された写真を含めるべきではありません。
Informative note: Even if redundant-pic-cap is equal to 0, the decoder is able to ignore redundant codec pictures provided that the decoder supports a profile (Baseline, Extended) in which redundant coded pictures are allowed.
有益なメモ：冗長-PIC-CAPが0に等しい場合でも、デコーダーが冗長コード化された写真が許可されるプロファイル（ベースライン、拡張）をサポートすると、デコーダーは冗長コーデック写真を無視できます。
Informative note: Even if redundant-pic-cap is equal to 1, the receiver may also choose other error concealment strategies to replace or complement decoding of redundant slices.
有益な注意：冗長-PIC-CAPが1に等しい場合でも、受信機は冗長スライスのデコードを置き換えるまたは補完するために、他のエラー隠蔽戦略を選択することもできます。
sprop-parameter-sets: This parameter MAY be used to convey any sequence and picture parameter set NAL units (herein referred to as the initial parameter set NAL units) that can be placed in the NAL unit stream to precede any other NAL units in decoding order. The parameter MUST NOT be used to indicate codec capability in any capability exchange procedure. The value of the parameter is a comma-separated (',') list of base64 RFC 4648 [9] representations of parameter set NAL units as specified in Sections 7.3.2.1 and 7.3.2.2 of H.264 [2]. Note that the number of bytes in a parameter set NAL unit is typically less than 10, but a picture parameter set NAL unit can contain several hundred bytes.
SPROP-PARAMETER-SETS：このパラメーターは、NALユニットストリームに配置してデコード中の他のNALユニットの前に配置できるシーケンスおよび画像パラメーターセットNALユニット（ここでは初期パラメーターセットNAL単位と呼ばれる）を伝達するために使用できます。注文。パラメーターは、任意の機能交換手順でコーデック機能を示すために使用してはなりません。パラメーターの値は、H.264 [2]のセクション7.3.2.1および7.3.2.2で指定されているパラメーターセットNAL単位のベース64 RFC 4648 [9]表現のコンマ分離された（ '、'）リストです。パラメーターセットNALユニットのバイト数は通常10未満ですが、画像パラメーターセットNALユニットには数百バイトを含めることができることに注意してください。
Informative note: When several payload types are offered in the SDP Offer/Answer model, each with its own sprop-parameter-sets parameter, the receiver cannot assume that those parameter sets do not use conflicting storage locations (i.e., identical values of parameter set identifiers). Therefore, a receiver should buffer all sprop-parameter-sets and make them available to the decoder instance that decodes a certain payload type.
有益なメモ：SDPオファー/回答モデルでいくつかのペイロードタイプが提供されている場合、それぞれが独自のSprop-Parameter-Setsパラメーターを備えている場合、レシーバーはそれらのパラメーターセットが競合するストレージの場所（つまり、パラメーターセットの同一の値を使用しないと想定できません。識別子）。したがって、レシーバーはすべてのSPROP-Parameterセットをバッファーし、特定のペイロードタイプをデコードするデコーダーインスタンスでそれらを使用できるようにする必要があります。
The sprop-parameter-sets parameter MUST only contain parameter sets that are conforming to the profile-level-id, i.e., the subset of coding tools indicated by any of the parameter sets MUST be equal to the default sub-profile, and the level indicated by any of the parameter sets MUST be equal to the default level.
SPROP-Parameter-Setsパラメーターには、プロファイルレベルIDに準拠しているパラメーターセットのみを含める必要があります。つまり、パラメーターセットのいずれかで示されるコーディングツールのサブセットは、デフォルトのサブプロファイルに等しく、レベルはレベルに等しい必要があります。パラメーターセットのいずれかで示されることは、デフォルトレベルに等しくなければなりません。
sprop-level-parameter-sets: This parameter MAY be used to convey any sequence and picture parameter set NAL units (herein referred to as the initial parameter set NAL units) that can be placed in the NAL unit stream to precede any other NAL units in decoding order and that are associated with one or more levels different than the default level. The parameter MUST NOT be used to indicate codec capability in any capability exchange procedure.
SPROP-LEVEL-PARAMETER-SETS：このパラメーターは、NALユニットのストリームに配置して他のNALユニットの前に配置できるシーケンスおよび画像パラメーターセットNALユニット（ここでは初期パラメーターセットNALユニットと呼ばれる）を伝達するために使用できます。デコード順で、デフォルトレベルとは異なる1つ以上のレベルに関連付けられています。パラメーターは、任意の機能交換手順でコーデック機能を示すために使用してはなりません。
The sprop-level-parameter-sets parameter contains parameter sets for one or more levels that are different than the default level. All parameter sets associated with one level are clustered and prefixed with a three-byte field that has the same syntax as profile-level-id. This enables the receiver to install the parameter sets for one level and discard the rest. The three-byte field is named PLId, and all parameter sets associated with one level are named PSL, which has the same syntax as sprop-parameter-sets. Parameter sets for each level are represented in the form of PLId:PSL, i.e., PLId followed by a colon (':') and the base64 RFC 4648 [9] representation of the initial parameter set NAL units for the level. Each pair of PLId:PSLs is also separated by a colon. Note that a PSL can contain multiple parameter sets for that level, separated with commas (',').
SPROP-LEVEL-PARAMETER-SETSパラメーターには、デフォルトレベルとは異なる1つ以上のレベルのパラメーターセットが含まれています。1つのレベルに関連付けられたすべてのパラメーターセットは、プロファイルレベルIDと同じ構文を持つ3バイトフィールドでクラスター化され、前に接頭されます。これにより、受信機はパラメーターセットを1つのレベルの設定し、残りを破棄できます。3バイトフィールドの名前はPlidで、1つのレベルに関連付けられたすべてのパラメーターセットはPSLという名前で、Sprop-Parameter-Setsと同じ構文を持っています。各レベルのパラメーターセットは、PSL、つまり剥がれ、それに続いてコロン（ '：'）とベース64 RFC 4648 [9]がレベルの初期パラメーターセットNALユニットを表します。PSL：PSLSの各ペアは、コロンによっても分離されています。PSLには、コンマ（ '、'）で区切られたそのレベルの複数のパラメーターセットを含めることができることに注意してください。
The subset of coding tools indicated by each PLId field MUST be equal to the default sub-profile, and the level indicated by each PLId field MUST be different than the default level. All sequence parameter sets contained in each PSL MUST have the three bytes from profile_idc to level_idc, inclusive, equal to the preceding PLId.
各PLIDフィールドで示されるコーディングツールのサブセットは、デフォルトのサブプロファイルに等しくなければならず、各PLIDフィールドで示されるレベルはデフォルトレベルとは異なる必要があります。各PSLに含まれるすべてのシーケンスパラメーターセットには、Profile_idcからrevel_idcまでの3バイトが、前述の増加に等しく、包括的である必要があります。
Informative note: This parameter allows for efficient level downgrade or upgrade in SDP Offer/Answer and out-of-band transport of parameter sets simultaneously.
有益なメモ：このパラメーターにより、SDPオファー/回答の効率的なレベルのダウングレードまたはアップグレードが可能になり、パラメーターセットの帯域外輸送が同時に行われます。
use-level-src-parameter-sets: This parameter MAY be used to indicate a receiver capability. The value MAY be equal to either 0 or 1. When the parameter is not present, the value MUST be inferred to be equal to 0. The value 0 indicates that the receiver does not understand the sprop-level-parameter-sets parameter, does not understand the "fmtp" source attribute as specified in Section 6.3 of RFC 5576 [14], will ignore sprop-level-parameter-sets when present, and will ignore sprop-parameter-sets when conveyed using the "fmtp" source attribute. The value 1 indicates that the receiver understands the sprop-level-parameter-sets parameter, understands the "fmtp" source attribute as specified in Section 6.3 of RFC 5576 [14], and is capable of using parameter sets contained in the sprop-level-parameter-sets or contained in the sprop-parameter-sets that is conveyed using the "fmtp" source attribute.
ユースレベル-SRCパラメーターセット：このパラメーターは、受信機の機能を示すために使用できます。値は0または1のいずれかに等しくなる場合があります。パラメーターが存在しない場合、値は0に等しいと推測する必要があります。値0は、受信機がSprop-Level-Parameter-Setsパラメーターを理解していないことを示します。RFC 5576 [14]のセクション6.3で指定されている「FMTP」ソース属性を理解していないため、存在するとSPROPレベルのパラメーターセットを無視し、「FMTP」ソース属性を使用して伝達されるとSPROPパラメーターセットを無視します。値1は、レシーバーがSPROPレベルのパラメーターセットパラメーターを理解し、RFC 5576 [14]のセクション6.3で指定されている「FMTP」ソース属性を理解し、SPROPレベルに含まれるパラメーターセットを使用できることを示しています。 - パラメーターセットまたは「FMTP」ソース属性を使用して伝達されるSPROP-Parameter-Setsに含まれています。
Informative note: An RFC 3984 receiver does not understand sprop-level-parameter-sets, use-level-src-parameter-sets, or the "fmtp" source attribute as specified in Section 6.3 of RFC 5576 [14]. Therefore, during SDP Offer/Answer, an RFC 3984 receiver as the answerer will simply ignore sprop-level-parameter-sets when present in an offer and sprop-parameter-sets conveyed using the "fmtp" source attribute, as specified in Section 6.3 of RFC 5576 [14]. Assume that the offered payload type was accepted at a level lower than the default level. If the offered payload type included sprop-level-parameter-sets or included sprop-parameter-sets conveyed using the "fmtp" source attribute and if the offerer sees that the answerer has not included use-level-src-parameter-sets equal to 1 in the answer, the offerer knows that in-band transport of parameter sets is needed.
有益な注意：RFC 3984レシーバーは、RFC 5576のセクション6.3で指定されているように、SPROPレベルパラメーターセット、ユースレベル-SRCパラメーターセット、または「FMTP」ソース属性を理解していません[14]。したがって、SDPのオファー/回答中、回答者としてのRFC 3984レシーバーは、セクション6.3で指定されているように、「FMTP」ソース属性を使用して提供されるオファーおよびSPROPパラメーターセットに存在する場合、Sprop-Level-Parameter-Setsを単純に無視します。RFC 5576 [14]。提供されたペイロードタイプが、デフォルトレベルよりも低いレベルで受け入れられたと仮定します。提供されたペイロードタイプに、「fmtp」ソース属性を使用して伝達されたスプロップレベルパラメーターセットまたはspropパラメーターセットが含まれている場合、および提供者が回答者にユースレベル-SRCパラメーターセットが含まれていないことがわかります。1回答では、提供者は、パラメーターセットの帯域内輸送が必要であることを知っています。
in-band-parameter-sets: This parameter MAY be used to indicate a receiver capability. The value MAY be equal to either 0 or 1. The value 1 indicates that the receiver discards out-of-band parameter sets in sprop-parameter-sets and sprop-level-parameter-sets; therefore, the sender MUST transmit all parameter sets in-band. The value 0 indicates that the receiver utilizes out-of-band parameter sets included in sprop-parameter-sets and/or sprop-level-parameter-sets. However, in this case, the sender MAY still choose to send parameter sets in-band. When in-band-parameter-sets is equal to 1, use-level-src-parameter-sets MUST NOT be present or MUST be equal to 0. When the parameter is not present, this receiver capability is not specified, and therefore the sender MAY send out-of-band parameter sets only, it MAY send in-band-parameter-sets only, or it MAY send both.
インバンドパラメーターセット：このパラメーターは、受信機の機能を示すために使用できます。値は0または1のいずれかに等しい場合があります。値1は、レシーバーがSPROPパラメーターセットとSPROP-LEVEL-PARAMETERセットの帯域外パラメーターセットを破棄することを示します。したがって、送信者はすべてのパラメーターセットをインバンド送信する必要があります。値0は、レシーバーがSPROPパラメーターセットおよび/またはSPROPレベルパラメーターセットに含まれるバンド外パラメーターセットを使用していることを示します。ただし、この場合、送信者は引き続きバンド内のパラメーターセットを送信することを選択できます。インバンドパラメーターセットが1に等しい場合、ユースレベル-SRCパラメーターセットを存在するか、0に等しくする必要があります。パラメーターが存在しない場合、この受信機機能は指定されていないため、送信者は、バンドのパラメーターセットのみを送信する場合があります。インバンドパラメーターセットのみを送信するか、両方を送信する場合があります。
level-asymmetry-allowed: This parameter MAY be used in SDP Offer/ Answer to indicate whether level asymmetry, i.e., sending media encoded at a different level in the offerer-to-answerer direction than the level in the answerer-to-offerer direction, is allowed. The value MAY be equal to either 0 or 1. When the parameter is not present, the value MUST be inferred to be equal to 0. The value 1 in both the offer and the answer indicates that level asymmetry is allowed. The value of 0 in either the offer or the answer indicates that level asymmetry is not allowed.
レベルアサイム測定型：このパラメーターは、SDPのオファー/回答で使用されて、レベルの非対称性、つまり、応募者から回答者への方向で異なるレベルでエンコードされたメディアを、回答者からオフファーの方向のレベルとは異なるレベルでエンコードしているかどうかを示すことができます。、 許可されています。値は0または1のいずれかに等しい場合があります。パラメーターが存在しない場合、値は0に等しいと推測する必要があります。オファーまたは回答のいずれかの0の値は、レベルの非対称性が許可されていないことを示しています。
If level-asymmetry-allowed is equal to 0 (or not present) in either the offer or the answer, level asymmetry is not allowed. In this case, the level to use in the direction from the offerer to the answerer MUST be the same as the level to use in the opposite direction.
オファーまたは回答のいずれにおいても、レベルアサイム測定値が0（または存在しない）に等しい場合、レベルの非対称性は許可されていません。この場合、オファーから応募者への方向に使用するレベルは、反対方向に使用するレベルと同じでなければなりません。
packetization-mode: This parameter signals the properties of an RTP payload type or the capabilities of a receiver implementation. Only a single configuration point can be indicated; thus, when capabilities to support more than one packetization-mode are declared, multiple configuration points (RTP payload types) must be used.
パケット化 - モード：このパラメーターは、RTPペイロードタイプのプロパティまたは受信機実装の機能を信号します。単一の構成ポイントのみを示すことができます。したがって、複数のパケット化モードをサポートする機能が宣言されている場合、複数の構成ポイント（RTPペイロードタイプ）を使用する必要があります。
When the value of packetization-mode is equal to 0 or packetization-mode is not present, the single NAL mode MUST be used. This mode is in use in standards using ITU-T Recommendation H.241 [3] (see Section 12.1). When the value of packetization-mode is equal to 1, the non-interleaved mode MUST be used. When the value of packetization-mode is equal to 2, the interleaved mode MUST be used. The value of packetization-mode MUST be an integer in the range of 0 to 2, inclusive.
パケット化モードの値が0に等しい、またはパケット化モードが存在しない場合、単一NALモードを使用する必要があります。このモードは、ITU-T推奨H.241 [3]を使用して標準で使用されています（セクション12.1を参照）。パケット化モードの値が1に等しい場合、非介入モードを使用する必要があります。パケット化モードの値が2に等しい場合、インターリーブモードを使用する必要があります。パケット化モードの値は、0〜2の範囲の整数でなければなりません。
sprop-interleaving-depth: This parameter MUST NOT be present when packetization-mode is not present or the value of packetization-mode is equal to 0 or 1. This parameter MUST be present when the value of packetization-mode is equal to 2.
SPROP-INTERLEAVING-DEPTH：パケット化モードが存在しない場合、またはパケット化モードの値が0または1に等しい場合、このパラメーターを存在しないでください。このパラメーターは、パケット化モードの値が2に等しい場合に存在する必要があります。
This parameter signals the properties of an RTP packet stream. It specifies the maximum number of VCL NAL units that precede any VCL NAL unit in the RTP packet stream in transmission order and that follow the VCL NAL unit in decoding order. Consequently, it is guaranteed that receivers can reconstruct NAL unit decoding order when the buffer size for NAL unit decoding order recovery is at least the value of sprop-interleaving-depth + 1 in terms of VCL NAL units.
このパラメーターは、RTPパケットストリームのプロパティを信号します。RTPパケットストリームのVCL NALユニットに先行するVCL NALユニットの最大数を、送信順に、VCL NALユニットをデコード順に従うことを指定します。したがって、NALユニットデコードのバッファサイズが少なくともVCL NALユニットの観点からスプロップインターレービングの深さ1の値である場合、受信機がNALユニットデコード順序を再構築できることが保証されています。
The value of sprop-interleaving-depth MUST be an integer in the range of 0 to 32767, inclusive.
Sprop-interLeaving Depthの値は、0〜32767の範囲の整数でなければなりません。
sprop-deint-buf-req: This parameter MUST NOT be present when packetization-mode is not present or the value of packetization-mode is equal to 0 or 1. It MUST be present when the value of packetization-mode is equal to 2.
sprop-deint-buf-req：このパラメーターは、パケット化モードが存在しない場合、またはパケット化モードの値が0または1に等しい場合は存在しないでください。。
sprop-deint-buf-req signals the required size of the de-interleaving buffer for the RTP packet stream. The value of the parameter MUST be greater than or equal to the maximum buffer occupancy (in units of bytes) required in such a de-interleaving buffer that is specified in Section 7.2 of RFC 6184 [1]. It is guaranteed that receivers can perform the de-interleaving of interleaved NAL units into NAL unit decoding order, when the de-interleaving buffer size is at least the value of sprop-deint-buf-req in terms of bytes.
sprop-deint-buf-reqは、RTPパケットストリームに必要なinterleavingバッファーの必要なサイズを信号します。パラメーターの値は、RFC 6184 [1]のセクション7.2で指定されているこのような非挿入バッファーで必要な最大バッファー占有率（バイト単位）以上でなければなりません。interleaved-deint-buf-reqの値がバイトの観点から、インターレービングバッファーサイズがnalユニットデコード順に、インターリーブNALユニットのインターレアビングを実行できることが保証されています。
The value of sprop-deint-buf-req MUST be an integer in the range of 0 to 4294967295, inclusive.
sprop-deint-buf-reqの値は、0〜4294967295の範囲の整数でなければなりません。
Informative note: sprop-deint-buf-req indicates the required size of the de-interleaving buffer only. When network jitter can occur, an appropriately sized jitter buffer has to be provisioned for as well.
有益なメモ：SPROP-DEINT-BUF-REQは、非介入バッファーの必要なサイズのみを示します。ネットワークジッターが発生する可能性がある場合、適切なサイズのジッターバッファーもプロビジョニングする必要があります。
deint-buf-cap: This parameter signals the capabilities of a receiver implementation and indicates the amount of de-interleaving buffer space in units of bytes that the receiver has available for reconstructing the NAL unit decoding order. A receiver is able to handle any stream for which the value of the sprop-deint-buf-req parameter is smaller than or equal to this parameter.
DEINT-BUF-CAP：このパラメーターは、受信機の実装の機能を信号し、受信機がNALユニットデコード順序を再構築するために利用可能なバイト単位のインターレービングバッファースペースの量を示します。レシーバーは、Sprop-Deint-Buf-REQパラメーターの値がこのパラメーターよりも小さい任意のストリームを処理できます。
If the parameter is not present, then a value of 0 MUST be used for deint-buf-cap. The value of deint-buf-cap MUST be an integer in the range of 0 to 4294967295, inclusive.
パラメーターが存在しない場合、DEINT-BUF-CAPには0の値を使用する必要があります。Deint-Buf-Capの値は、0〜4294967295の範囲の整数でなければなりません。
Informative note: deint-buf-cap indicates the maximum possible size of the de-interleaving buffer of the receiver only. When network jitter can occur, an appropriately sized jitter buffer has to be provisioned for as well.
有益なメモ：Deint-Buf-Capは、受信機のみのインターレービングバッファーの最大可能なサイズのみを示します。ネットワークジッターが発生する可能性がある場合、適切なサイズのジッターバッファーもプロビジョニングする必要があります。
sprop-init-buf-time: This parameter MAY be used to signal the properties of an RTP packet stream. The parameter MUST NOT be present if the value of packetization-mode is equal to 0 or 1.
SPROP-ISIT-BUF-TIME：このパラメーターは、RTPパケットストリームのプロパティを信号にするために使用できます。パケット化モードの値が0または1に等しい場合、パラメーターを存在しないでください。
The parameter signals the initial buffering time that a receiver MUST wait before starting decoding to recover the NAL unit decoding order from the transmission order. The parameter is the maximum value of (decoding time of the NAL unit - transmission time of a NAL unit), assuming reliable and instantaneous transmission, the same timeline for transmission and decoding, and commencement of decoding when the first packet arrives.
パラメーターは、送信順序からNALユニットデコード順序を回復するためにデコードを開始する前にレシーバーが待つ必要がある初期バッファリング時間を信号します。パラメーターは、信頼性の高い瞬間的な伝送、伝送とデコードの同じタイムライン、および最初のパケットが到着したときのデコードの開始を仮定して、（NALユニットのデコード時間 - NALユニットの送信時間）の最大値です。
An example of specifying the value of sprop-init-buf-time follows. A NAL unit stream is sent in the following interleaved order, in which the value corresponds to the decoding time and the transmission order is from left to right:
次のように、Sprop-Init-Buf-Timeの値を指定する例。NALユニットのストリームは、次のインターリーブ順序で送信されます。この順序では、値はデコード時間に対応し、透過順序は左から右にあります。
0 2 1 3 5 4 6 8 7 ...
0 2 1 3 5 4 6 8 7 ...
Assuming a steady transmission rate of NAL units, the transmission times are:
NALユニットの定常伝送速度を仮定すると、送信時間は次のとおりです。
0 1 2 3 4 5 6 7 8 ...
0 1 2 3 4 5 6 7 8 ...
Subtracting the decoding time from the transmission time column-wise results in the following series:
次のシリーズで、列ごとの送信時間からデコード時間を差し引くと：
0 -1 1 0 -1 1 0 -1 1 ...
Thus, in terms of intervals of NAL unit transmission times, the value of sprop-init-buf-time in this example is 1. The parameter is coded as a non-negative base10 integer representation in clock ticks of a 90-kHz clock. If the parameter is not present, then no initial buffering time value is defined. Otherwise, the value of sprop-init-buf-time MUST be an integer in the range of 0 to 4294967295, inclusive.
したがって、NALユニット透過時間の間隔の観点から、この例のSPROP-Init-Buf-Timeの値は1です。パラメーターは、90 kHzのクロックのクロックティックの非陰性Base10整数表現としてコーディングされます。パラメーターが存在しない場合、初期バッファリング時間値は定義されていません。それ以外の場合、SPROP-Init-Buf-Timeの値は、0〜4294967295の範囲の整数でなければなりません。
In addition to the signaled sprop-init-buf-time, receivers SHOULD take into account the transmission delay jitter buffering, including buffering for the delay jitter caused by mixers, translators, gateways, proxies, traffic-shapers, and other network elements.
SPROP-Init-Buf-Timeに加えて、受信機は、ミキサー、翻訳者、ゲートウェイ、プロキシ、トラフィックシェイプ、その他のネットワーク要素によって引き起こされる遅延ジッターのバッファリングなど、トランスミッション遅延ジッターバッファリングを考慮する必要があります。
sprop-max-don-diff: This parameter MAY be used to signal the properties of an RTP packet stream. It MUST NOT be used to signal transmitter, receiver, or codec capabilities. The parameter MUST NOT be present if the value of packetization-mode is equal to 0 or 1. sprop-max-don-diff is an integer in the range of 0 to 32767, inclusive. If sprop-max-don-diff is not present, the value of the parameter is unspecified. sprop-max-don-diff is calculated as follows:
SPROP-MAX-DON-DIFF：このパラメーターは、RTPパケットストリームのプロパティを信号にするために使用できます。送信機、受信機、またはコーデック機能を信号に使用してはなりません。パケット化モードの値が0または1に等しい場合、パラメーターは存在しないでください。SPROP-MAX-DON-DIFFは、0〜32767の範囲の整数です。sprop-max-don-diffが存在しない場合、パラメーターの値は特定されていません。sprop-max-don-diffは次のように計算されます。
sprop-max-don-diff = max{AbsDON(i) - AbsDON(j)}, for any i and any j>i,
sprop-max-don-diff = max {absdon（i） - absdon（j）}、任意のj> iの場合、
where i and j indicate the index of the NAL unit in the
transmission order and AbsDON denotes a decoding order number of
the NAL unit that does not wrap around to 0 after 65535. In other
words, AbsDON is calculated as follows: let m and n be consecutive
NAL units in transmission order. For the very first NAL unit in
transmission order (whose index is 0), AbsDON(0) = DON(0). For
other NAL units, AbsDON is calculated as follows:
If DON(m) == DON(n), AbsDON(n) = AbsDON(m)
If (DON(m) < DON(n) and DON(n) - DON(m) < 32768),
if（don（m）<don（n）およびdon（n）-don（m）<32768）、
AbsDON(n) = AbsDON(m) + DON(n) - DON(m)
If (DON(m) > DON(n) and DON(m) - DON(n) >= 32768),
if（don（m）> don（n）and don（m）-don（n）> = 32768）、
AbsDON(n) = AbsDON(m) + 65536 - DON(m) + DON(n)
If (DON(m) < DON(n) and DON(n) - DON(m) >= 32768),
if（don（m）<don（n）およびdon（n）-don（m）> = 32768）、
AbsDON(n) = AbsDON(m) - (DON(m) + 65536 - DON(n))
If (DON(m) > DON(n) and DON(m) - DON(n) < 32768),
if（don（m）> don（n）およびdon（m）-don（n）<32768）、
AbsDON(n) = AbsDON(m) - (DON(m) - DON(n))
where DON(i) is the decoding order number of the NAL unit having index i in the transmission order. The decoding order number is specified in Section 5.5 of RFC 6184 [1].
ここで、DON（i）は、送信順序でインデックスIを持つNALユニットのデコード順序番号です。デコード順序番号は、RFC 6184 [1]のセクション5.5で指定されています。
Informative note: Receivers may use sprop-max-don-diff to trigger which NAL units in the receiver buffer can be passed to the decoder.
有益なメモ：レシーバーは、Sprop-Max-Don-Diffを使用して、受信機バッファ内のNALユニットをデコーダーに渡すことができるかをトリガーする場合があります。
max-rcmd-nalu-size: This parameter MAY be used to signal the capabilities of a receiver. The parameter MUST NOT be used for any other purposes. The value of the parameter indicates the largest NALU size in bytes that the receiver can handle efficiently. The parameter value is a recommendation, not a strict upper boundary. The sender MAY create larger NALUs but must be aware that the handling of these may come at a higher cost than NALUs conforming to the limitation.
Max-RCMD-Nalu-Size：このパラメーターは、受信機の機能を信号にするために使用できます。パラメーターは、他の目的に使用してはなりません。パラメーターの値は、受信機が効率的に処理できるバイトの最大のNALUサイズを示します。パラメーター値は推奨であり、厳格な上限ではありません。送信者はより大きなナルスを作成する場合がありますが、これらの取り扱いは、制限に準拠しているナルスよりも高いコストで提供される可能性があることに注意する必要があります。
The value of max-rcmd-nalu-size MUST be an integer in the range of 0 to 4294967295, inclusive. If this parameter is not specified, no known limitation to the NALU size exists. Senders still have to consider the MTU size available between the sender and the receiver and SHOULD run MTU discovery for this purpose.
max-rcmd-nalu-sizeの値は、0〜4294967295の範囲の整数でなければなりません。このパラメーターが指定されていない場合、NALUサイズの既知の制限は存在しません。送信者は、送信者と受信機の間で利用可能なMTUサイズを検討する必要があり、この目的のためにMTU発見を実行する必要があります。
This parameter is motivated by, for example, an IP to H.223 video telephony gateway, where NALUs smaller than the H.223 transport data unit will be more efficient. A gateway may terminate IP; thus, MTU discovery will normally not work beyond the gateway.
このパラメーターは、たとえば、H.223輸送データユニットよりも小さいNalusがより効率的になるIPからH.223ビデオテレフォニーゲートウェイによって動機付けられています。ゲートウェイはIPを終了する場合があります。したがって、MTUの発見は通常、ゲートウェイを越えて機能しません。
Informative note: Setting this parameter to a lower than necessary value may have a negative impact.
有益なメモ：このパラメーターを必要な値より低いものに設定すると、マイナスの影響がある場合があります。
sar-understood: This parameter MAY be used to indicate a receiver capability and nothing else. The parameter indicates the maximum value of aspect_ratio_idc (specified in H.264 [2]) smaller than 255 that the receiver understands. Table E-1 of H.264 [2] specifies aspect_ratio_idc equal to 0 as "unspecified"; 1 to 16, inclusive, as specific Sample Aspect Ratios (SARs); 17 to 254, inclusive, as "reserved"; and 255 as the Extended SAR, for which SAR width and SAR height are explicitly signaled. Therefore, a receiver with a decoder according to H.264 [2] understands aspect_ratio_idc in the range of 1 to 16, inclusive, and aspect_ratio_idc equal to 255, in the sense that the receiver knows exactly what the SAR is. For such a receiver, the value of sar-understood is 16. In the future, if Table E-1 of H.264 [2] is extended, e.g., such that the SAR for aspect_ratio_idc equal to 17 is specified, then for a receiver with a decoder that understands the extension, the value of sar-understood is 17. For a receiver with a decoder according to the 2003 version of H.264 [2], the value of sar-understood is 13, as the minimum reserved aspect_ratio_idc therein is 14.
SAR-UNDERSTOUD：このパラメーターは、受信機の機能を示すために使用できます。パラメーターは、受信者が理解している255を超えるAspect_ratio_idc（H.264 [2]で指定）の最大値を示します。H.264 [2]の表E-1 [2]は、0に等しいaspect_ratio_idcを「不特定」として指定しています。1〜16、包括的、特定のサンプルアスペクト比（SARS）として。17から254、「予約済み」として包括的。255拡張SARとして、SAR幅とSARの高さが明示的にシグナル伝達されます。したがって、h.264 [2]に従ってデコーダーを備えたレシーバーは、レシーバーがSARが何であるかを正確に知っているという意味で、1〜16、包括的、aspect_ratio_idcの範囲で255に等しい範囲でAspect_ratio_idcを理解しています。このような受信者の場合、SARが不正の値は16です。将来、H.264 [2]の表E-1が拡張されている場合、たとえば、Aspect_ratio_idcのSARが17に等しい場合、次にAの場合拡張機能を理解しているデコーダーを備えたレシーバー、SAR不良の値は17です。2003年バージョンのH.264 [2]によると、デコーダーを備えたレシーバー[2]によると、SAR UnderSorpの値は最小予約額として13です。Aspest_ratio_idcは14です。
When sar-understood is not present, the value MUST be inferred to be equal to 13.
SARが存在しない場合、値は13に等しいと推測する必要があります。
sar-supported: This parameter MAY be used to indicate a receiver capability and nothing else. The value of this parameter is an integer in the range of 1 to sar-understood, inclusive, equal to 255. The value of sar-supported equal to N smaller than 255 indicates that the receiver supports all the SARs corresponding to H.264 aspect_ratio_idc values (see Table E-1 of H.264 [2]) in the range from 1 to N, inclusive, without geometric distortion. The value of sar-supported equal to 255 indicates that the receiver supports all sample aspect ratios that are expressible using two 16-bit integer values as the numerator and denominator, i.e., those that are expressible using the H.264 aspect_ratio_idc value of 255 (Extended_SAR, see Table E-1 of H.264 [2]), without geometric distortion.
サポート：このパラメーターは、受信機の機能を示すために使用できます。このパラメーターの値は、255に等しいSARサポートの値が255に等しいsarの範囲の範囲の整数です。値（H.264 [2]の表E-1 [2]を参照）は、幾何学的な歪みなしで包括的で包括的です。255に等しいSARサポートの値は、レシーバーが、分子と分母として2つの16ビット整数値を使用して表現可能なすべてのサンプルアスペクト比、つまりH.264 Aspect_ratio_idc値255の値を使用して表現できることを示しています（Extended_Sar、幾何学的な歪みなしで、H.264 [2]の表E-1を参照してください。
H.264-compliant encoders SHOULD NOT send an aspect_ratio_idc equal to 0 or an aspect_ratio_idc larger than sar-understood and smaller than 255. H.264-compliant encoders SHOULD send an aspect_ratio_idc that the receiver is able to display without geometrical distortion. However, H.264-compliant encoders MAY choose to send pictures using any SAR.
H.264準拠のエンコーダーは、0またはsaruntoredよりも大きい0またはAspect_ratio_idcを255より小さいAspect_ratio_idcを送信しないでください。H.264準拠エンコーダーは、レシーバーが幾何学的な歪みなしで表示できるAspect_ratio_idcを送信する必要があります。ただし、H.264準拠のエンコーダーは、任意のSARを使用して写真を送信することを選択できます。
Note that the actual sample aspect ratio or extended sample aspect ratio, when present, of the stream is conveyed in the Video Usability Information (VUI) part of the sequence parameter set.
ストリームの実際のサンプルアスペクト比または存在する場合の拡張サンプルアスペクト比は、シーケンスパラメーターセットのビデオユーザビリティ情報（VUI）部分で伝達されることに注意してください。
Encoding considerations: This type is only defined for transfer via RTP (RFC 3550) and is framed and binary (see Section 4.8 in RFC 4288).
考慮事項のエンコード：このタイプは、RTP（RFC 3550）を介した転送のみで定義され、フレームとバイナリです（RFC 4288のセクション4.8を参照）。
Security considerations: See Section 9 of RFC 6185.
セキュリティ上の考慮事項：RFC 6185のセクション9を参照してください。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 6185 and its reference section
公開された仕様：RFC 6185およびその参照セクション
Applications that use this media type: Video streaming and conferencing applications
このメディアタイプを使用するアプリケーション：ビデオストリーミングと会議アプリケーション
Additional information: None
追加情報：なし
Magic number(s):
マジックナンバー：
File extension(s):
ファイル拡張子：
Macintosh file type code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Tom Kristensen <tom.kristensen@tandberg.com>, <tomkri@ifi.uio.no>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This type depends on RTP framing; hence, it is only defined for transfer via RTP (see RFC 3550). Transport within other framing protocols is not defined at this time.
使用に関する制限：このタイプは、RTPフレーミングに依存します。したがって、RTPを介した転送に対してのみ定義されます（RFC 3550を参照）。この時点では、他のフレーミングプロトコル内の輸送は定義されていません。
Author: Tom Kristensen
著者：トム・クリステンセン
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループIESGから委任
The mapping of the above defined payload format media subtype and its parameters SHALL be done according to Section 3 of RFC 4855 [10].
上記のペイロード形式のメディアサブタイプとそのパラメーターのマッピングは、RFC 4855のセクション3に従って行うものとします[10]。
An example of the "fmtp" attribute in the media representation of a level 2.2 bitstream is as follows:
レベル2.2ビットストリームのメディア表現における「FMTP」属性の例は次のとおりです。
a=fmtp:97 profile-level-id=008016
When H264-RCDO is offered over RTP using SDP in an Offer/Answer model [5] for unicast and multicast usage, the limitations and rules described in Section 8.2.2 of RFC 6184 [1] apply. Note that the profile_idc byte of the H264-RCDO profile-level-id parameter can only take the value of 0 (no profile).
ユニキャストおよびマルチキャストの使用については、オファー/回答モデル[5]でSDPを使用してH264-RCDOがRTPを介して提供される場合、RFC 6184 [1]のセクション8.2.2で説明されている制限とルールが適用されます。H264-RCDOプロファイルレベル-IDパラメーターのプロファイル_IDCバイトは、値（プロファイルなし）のみを取ることができることに注意してください。
For interoperability with systems not supporting H264-RCDO, it is RECOMMENDED to offer the H264 media subtype as well. As specified in RFC 3264 [5], listing the payload number for H264-RCDO before H264 in the format list on the "m=" line signals that H264-RCDO is preferred over H264. Following is an example where this scheme is applied:
H264-RCDOをサポートしていないシステムとの相互運用性については、H264メディアサブタイプも提供することをお勧めします。RFC 3264 [5]で指定されているように、H264-RCDOの前にH264-RCDOのペイロード番号を「M =」ラインの形式リストにリストし、H264-RCDOがH264よりも優先されます。以下は、このスキームが適用される例です。
m=video 5555 RTP/AVP 97 98
M =ビデオ5555 RTP/AVP 97 98
a=rtpmap:97 H264-RCDO/90000
a = rtpmap：97 H264-RCDO/90000
a=fmtp:97 profile-level-id=008016;max-mbps=42000;max-smbps=323500
a=rtpmap:98 H264/90000
a = rtpmap：98 H264/90000
a=fmtp:98 profile-level-id=428016;max-mbps=35000;max-smbps=323500
When H264-RCDO over RTP is offered with SDP in a declarative style, as in the Real Time Streaming Protocol (RTSP) [11] or the Session Announcement Protocol (SAP) [12], the considerations in Section 8.2.3 of RFC 6184 [1] apply. Note that the profile_idc byte of the H264- RCDO profile-level-id parameter can only take the value of 0 (no profile).
リアルタイムストリーミングプロトコル（RTSP）[11]またはセッションアナウンスプロトコル（SAP）[12]のように、RTPを超えるH264-RCDOがSDPを宣言スタイルで提供する場合、RFC 6184のセクション8.2.3の考慮事項は[1]適用します。H264-RCDOプロファイルレベルIDパラメーターのプロファイル_IDCバイトは、値（プロファイルなし）のみを取得できることに注意してください。
IANA has registered H264-RCDO as specified in Section 6.1. The media subtype has also been added to the IANA registry for "RTP Payload Format MIME types" (http://www.iana.org).
IANAは、セクション6.1で指定されているように、H264-RCDOを登録しています。メディアサブタイプは、「RTPペイロード形式のMIMEタイプ」（http://www.iana.org）のIANAレジストリにも追加されています。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [6] and in any applicable RTP profile. Refer also to the security considerations of the RTP Payload Format for H.264 Video specification in RFC 6184 [1]. No additional security considerations are introduced by this specification.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[6]および該当するRTPプロファイルで説明されているセキュリティに関する考慮事項の対象となります。RFC 6184 [1]のH.264ビデオ仕様のRTPペイロード形式のセキュリティに関する考慮事項も参照してください。この仕様では、追加のセキュリティ上の考慮事項は導入されていません。
The authors would like to acknowledge Gisle Bjoentegaard and Arild Fuldseth for their technical contribution to the specification. In the final phases, Roni Even did a helpful review.
著者は、仕様への技術的貢献について、Gisle BjoentegaardとArild Fuldsethに感謝します。最終段階では、ロニは有益なレビューさえしました。
[1] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011.
[1] Wang、Y.、Even、R.、Kristensen、T。、およびR. Jesup、「H.264ビデオのRTPペイロード形式」、RFC 6184、2011年5月。
[2] International Telecommunications Union, "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, March 2010.
[2] International Telecommunications Union、「一般的な視聴覚サービス向けの高度なビデオコーディング」、ITU-T推奨H.264、2010年3月。
[3] International Telecommunications Union, "Extended video procedures and control signals for H.300-series terminals", ITU-T Recommendation H.241, May 2006.
[3] International Telecommunications Union、「H.300シリーズターミナルの拡張ビデオ手順と制御信号」、ITU-T推奨H.241、2006年5月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[6] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[7] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[8] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[9] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[9] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[10] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[10] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[11] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[12] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[12] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[13] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[13] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[14] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[14] Lennox、J.、Ott、J。、およびT. Schierl、「セッション説明プロトコル（SDP）のソース固有のメディア属性」、RFC 5576、2009年6月。
Authors' Addresses
著者のアドレス
Tom Kristensen TANDBERG Philip Pedersens vei 22 N-1366 Lysaker Norway
トム・クリステンセン・タンドバーグ・フィリップ・ペダーセンスvei 22 n-1366ライセカーノルウェー
Phone: +47 67125125
EMail: tom.kristensen@tandberg.com, tomkri@ifi.uio.no
URI: http://www.tandberg.com
Patrick Luthi TANDBERG Philip Pedersens vei 22 N-1366 Lysaker Norway
Patrick Luthi Tandberg Philip Pedersens Vei 22 N-1366 Lysaker Norway
EMail: patrick.luthi@tandberg.com
URI: http://www.tandberg.com