[要約] RFC 7798は、HEVC（High Efficiency Video Coding）のためのRTPペイロード形式を定義しています。このRFCの目的は、HEVCビデオストリームをRTPパケットにエンコードするための標準化と相互運用性の向上です。
Internet Engineering Task Force (IETF) Y.-K. Wang
Request for Comments: 7798 Qualcomm
Category: Standards Track Y. Sanchez
ISSN: 2070-1721 T. Schierl
Fraunhofer HHI
S. Wenger
Vidyo
M. M. Hannuksela
Nokia
March 2016
RTP Payload Format for High Efficiency Video Coding (HEVC)
高効率ビデオコーディング（HEVC）用のRTPペイロード形式
Abstract
概要
This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.
このメモは、ビデオコーディング標準ITU-T勧告H.265およびISO / IEC国際標準23008-2のRTPペイロード形式について説明しています。どちらも高効率ビデオコーディング（HEVC）として知られ、ビデオコーディングに関する共同チームによって開発されました。 （JCT-VC）。 RTPペイロード形式では、各RTPパケットペイロード内の1つ以上のネットワークアブストラクションレイヤー（NAL）ユニットのパケット化、およびNALユニットの複数のRTPパケットへのフラグメント化が可能です。さらに、HEVCビットストリームの単一ストリームおよび複数のRTPストリームでの送信をサポートします。複数のRTPストリームを使用する場合、単一のトランスポートまたは複数のトランスポートを使用できます。ペイロード形式は、ビデオ会議、インターネットビデオストリーミング、高ビットレートのエンターテイメント品質のビデオなど、幅広い用途に使用できます。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7798.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7798で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview of the HEVC Codec .................................4
1.1.1. Coding-Tool Features ................................4
1.1.2. Systems and Transport Interfaces ....................6
1.1.3. Parallel Processing Support ........................11
1.1.4. NAL Unit Header ....................................13
1.2. Overview of the Payload Format ............................14
2. Conventions ....................................................15
3. Definitions and Abbreviations ..................................15
3.1. Definitions ...............................................15
3.1.1. Definitions from the HEVC Specification ...........15
3.1.2. Definitions Specific to This Memo .................17
3.2. Abbreviations .............................................19
4. RTP Payload Format .............................................20
4.1. RTP Header Usage ..........................................20
4.2. Payload Header Usage ......................................22
4.3. Transmission Modes ........................................23
4.4. Payload Structures ........................................24
4.4.1. Single NAL Unit Packets ............................24
4.4.2. Aggregation Packets (APs) ..........................25
4.4.3. Fragmentation Units ................................29
4.4.4. PACI Packets .......................................32
4.4.4.1. Reasons for the PACI Rules (Informative) ..34
4.4.4.2. PACI Extensions (Informative) .............35
4.5. Temporal Scalability Control Information ..................36
4.6. Decoding Order Number .....................................37
5. Packetization Rules ............................................39
6. De-packetization Process .......................................40
7. Payload Format Parameters ......................................42
7.1. Media Type Registration ...................................42
7.2. SDP Parameters ............................................64
7.2.1. Mapping of Payload Type Parameters to SDP ..........64
7.2.2. Usage with SDP Offer/Answer Model ..................65
7.2.3. Usage in Declarative Session Descriptions ..........73
7.2.4. Considerations for Parameter Sets ..................75
7.2.5. Dependency Signaling in Multi-Stream Mode ..........75
8. Use with Feedback Messages .....................................75
8.1. Picture Loss Indication (PLI) .............................75
8.2. Slice Loss Indication (SLI) ...............................76
8.3. Reference Picture Selection Indication (RPSI) .............77
8.4. Full Intra Request (FIR) ..................................77
9. Security Considerations ........................................78
10. Congestion Control ............................................79
11. IANA Considerations ...........................................80
12. References ....................................................80
12.1. Normative References .....................................80
12.2. Informative References ...................................82
Acknowledgments ...................................................85
Authors' Addresses ................................................86
The High Efficiency Video Coding specification, formally published as both ITU-T Recommendation H.265 [HEVC] and ISO/IEC International Standard 23008-2 [ISO23008-2], was ratified by the ITU-T in April 2013; reportedly, it provides significant coding efficiency gains over H.264 [H.264].
ITU-T勧告H.265 [HEVC]およびISO / IEC国際規格23008-2 [ISO23008-2]の両方として正式に公開された高効率ビデオコーディング仕様は、2013年4月にITU-Tによって承認されました。報告によれば、H.264 [H.264]に比べてコーディング効率が大幅に向上しています。
This memo describes an RTP payload format for HEVC. It shares its basic design with the RTP payload formats of [RFC6184] and [RFC6190]. With respect to design philosophy, security, congestion control, and overall implementation complexity, it has similar properties to those earlier payload format specifications. This is a conscious choice, as at least RFC 6184 is widely deployed and generally known in the relevant implementer communities. Mechanisms from RFC 6190 were incorporated as HEVC version 1 supports temporal scalability.
このメモは、HEVCのRTPペイロード形式について説明しています。 [RFC6184]および[RFC6190]のRTPペイロード形式と基本設計を共有しています。設計哲学、セキュリティ、輻輳制御、および全体的な実装の複雑さに関しては、以前のペイロード形式の仕様と同様の特性があります。少なくともRFC 6184が広く導入されており、関連する実装者コミュニティで一般に知られているため、これは意識的な選択です。 HEVCバージョン1は一時的なスケーラビリティをサポートするため、RFC 6190のメカニズムが組み込まれました。
In order to help the overlapping implementer community, frequently only the differences between RFCs 6184 and 6190 and the HEVC payload format are highlighted in non-normative, explanatory parts of this memo. Basic familiarity with both specifications is assumed for those parts. However, the normative parts of this memo do not require study of RFCs 6184 or 6190.
重複する実装者コミュニティを支援するために、RFC 6184および6190とHEVCペイロード形式の違いのみが、このメモの非規範的な説明部分で強調されていることがよくあります。これらの部品については、両方の仕様についての基本的な知識があることが前提です。ただし、このメモの規範的な部分は、RFC 6184または6190の調査を必要としません。
H.264 and HEVC share a similar hybrid video codec design. In this memo, we provide a very brief overview of those features of HEVC that are, in some form, addressed by the payload format specified herein. Implementers have to read, understand, and apply the ITU-T/ISO/IEC specifications pertaining to HEVC to arrive at interoperable, well-performing implementations. Implementers should consider testing their design (including the interworking between the payload format implementation and the core video codec) using the tools provided by ITU-T/ISO/IEC, for example, conformance bitstreams as specified in [H.265.1]. Not doing so has historically led to systems that perform badly and that are not secure.
H.264とHEVCは、同様のハイブリッドビデオコーデック設計を共有しています。このメモでは、HEVCのこれらの機能について、ここで指定されたペイロード形式によって何らかの形で対処される、非常に簡単な概要を説明します。実装者は、HEVCに関連するITU-T / ISO / IEC仕様を読んで理解し、適用して、相互運用可能でパフォーマンスの高い実装に到達する必要があります。実装者は、ITU-T / ISO / IECが提供するツール、たとえば[H.265.1]で指定されている適合ビットストリームを使用して、設計のテスト（ペイロード形式の実装とコアビデオコーデック間の相互作用を含む）を検討する必要があります。そうしないと、歴史的にシステムのパフォーマンスが低下し、安全ではなくなります。
Conceptually, both H.264 and HEVC include a Video Coding Layer (VCL), which is often used to refer to the coding-tool features, and a Network Abstraction Layer (NAL), which is often used to refer to the systems and transport interface aspects of the codecs.
概念的には、H.264とHEVCの両方に、コーディングツール機能の参照によく使用されるビデオコーディングレイヤー（VCL）と、システムとトランスポートの参照によく使用されるネットワークアブストラクションレイヤー（NAL）が含まれています。コーデックのインターフェイスの側面。
Similar to earlier hybrid-video-coding-based standards, including H.264, the following basic video coding design is employed by HEVC. A prediction signal is first formed by either intra- or motion-compensated prediction, and the residual (the difference between the original and the prediction) is then coded. The gains in coding efficiency are achieved by redesigning and improving almost all parts of the codec over earlier designs. In addition, HEVC includes several tools to make the implementation on parallel architectures easier. Below is a summary of HEVC coding-tool features.
H.264を含む以前のハイブリッドビデオコーディングベースの標準と同様に、HEVCでは次の基本的なビデオコーディング設計が採用されています。予測信号は、最初にイントラまたは動き補償予測によって形成され、残差（元の予測と予測の差）がコード化されます。コーディング効率の向上は、以前の設計よりもコーデックのほぼすべての部分を再設計および改善することによって達成されます。さらに、HEVCには、並列アーキテクチャでの実装を容易にするためのいくつかのツールが含まれています。 HEVCコーディングツールの機能の概要を以下に示します。
Quad-tree block and transform structure
四分木ブロックと変換構造
One of the major tools that contributes significantly to the coding efficiency of HEVC is the use of flexible coding blocks and transforms, which are defined in a hierarchical quad-tree manner. Unlike H.264, where the basic coding block is a macroblock of fixed-size 16x16, HEVC defines a Coding Tree Unit (CTU) of a maximum size of 64x64. Each CTU can be divided into smaller units in a hierarchical quad-tree manner and can represent smaller blocks down to size 4x4. Similarly, the transforms used in HEVC can have different sizes, starting from 4x4 and going up to 32x32. Utilizing large blocks and transforms contributes to the major gain of HEVC, especially at high resolutions.
HEVCのコーディング効率に大きく貢献する主要なツールの1つは、階層的なクワッドツリーの方法で定義される柔軟なコーディングブロックと変換の使用です。基本コーディングブロックが固定サイズ16x16のマクロブロックであるH.264とは異なり、HEVCは最大サイズ64x64のコーディングツリーユニット（CTU）を定義します。各CTUは、階層的なクワッドツリー方式で小さな単位に分割でき、サイズが4x4までの小さなブロックを表すことができます。同様に、HEVCで使用される変換は、4x4から32x32までのさまざまなサイズを持つことができます。大きなブロックと変換を利用することは、特に高解像度でHEVCの大きな利益に貢献します。
Entropy coding
エントロピーコーディング
HEVC uses a single entropy-coding engine, which is based on Context Adaptive Binary Arithmetic Coding (CABAC) [CABAC], whereas H.264 uses two distinct entropy coding engines. CABAC in HEVC shares many similarities with CABAC of H.264, but contains several improvements. Those include improvements in coding efficiency and lowered implementation complexity, especially for parallel architectures.
HEVCは単一のエントロピーコーディングエンジンを使用します。これは、コンテキスト適応バイナリ演算コーディング（CABAC）[CABAC]に基づいていますが、H.264は2つの異なるエントロピーコーディングエンジンを使用します。 HEVCのCABACはH.264のCABACと多くの類似点を共有していますが、いくつかの改善点があります。これには、特に並列アーキテクチャの場合、コーディング効率の向上と実装の複雑さの軽減が含まれます。
In-loop filtering
ループ内フィルタリング
H.264 includes an in-loop adaptive deblocking filter, where the blocking artifacts around the transform edges in the reconstructed picture are smoothed to improve the picture quality and compression efficiency. In HEVC, a similar deblocking filter is employed but with somewhat lower complexity. In addition, pictures undergo a subsequent filtering operation called Sample Adaptive Offset (SAO), which is a new design element in HEVC. SAO basically adds a pixel-level offset in an adaptive manner and usually acts as a de-ringing filter. It is observed that SAO improves the picture quality, especially around sharp edges, contributing substantially to visual quality improvements of HEVC.
H.264には、ループ内適応デブロッキングフィルターが含まれています。このフィルターでは、再構成された画像の変換エッジ周辺のブロッキングアーティファクトが平滑化され、画質と圧縮効率が向上します。 HEVCでは、同様の非ブロック化フィルターが採用されていますが、複雑さはやや低くなっています。さらに、画像は、HEVCの新しい設計要素であるサンプルアダプティブオフセット（SAO）と呼ばれる後続のフィルタリング操作を受けます。 SAOは基本的に、ピクセルレベルのオフセットを適応的に追加し、通常、リンギング除去フィルターとして機能します。 SAOは特にシャープエッジ周辺の画質を改善し、HEVCの視覚的品質の向上に大きく貢献していることがわかります。
Motion prediction and coding
動き予測とコーディング
There have been a number of improvements in this area that are summarized as follows. The first category is motion merge and Advanced Motion Vector Prediction (AMVP) modes. The motion information of a prediction block can be inferred from the spatially or temporally neighboring blocks. This is similar to the DIRECT mode in H.264 but includes new aspects to incorporate the flexible quad-tree structure and methods to improve the parallel implementations. In addition, the motion vector predictor can be signaled for improved efficiency. The second category is high-precision interpolation. The interpolation filter length is increased to 8-tap from 6-tap, which improves the coding efficiency but also comes with increased complexity. In addition, the interpolation filter is defined with higher precision without any intermediate rounding operations to further improve the coding efficiency.
この分野では多くの改善があり、以下に要約されます。最初のカテゴリは、モーションマージとAdvanced Motion Vector Prediction（AMVP）モードです。予測ブロックの動き情報は、空間的または時間的に隣接するブロックから推測することができます。これはH.264のDIRECTモードに似ていますが、柔軟な四分木構造を組み込む新しい側面と、並列実装を改善する方法が含まれています。さらに、動きベクトル予測子に信号を送って効率を上げることができます。 2番目のカテゴリは、高精度の補間です。補間フィルターの長さが6タップから8タップに増えました。これにより、コーディング効率が向上しますが、複雑さが増します。さらに、補間フィルターはより高い精度で定義され、中間の丸め演算を行わないため、コーディング効率がさらに向上します。
Intra prediction and intra-coding
イントラ予測とイントラコーディング
Compared to 8 intra prediction modes in H.264, HEVC supports angular intra prediction with 33 directions. This increased flexibility improves both objective coding efficiency and visual quality as the edges can be better predicted and ringing artifacts around the edges can be reduced. In addition, the reference samples are adaptively smoothed based on the prediction direction. To avoid contouring artifacts a new interpolative prediction generation is included to improve the visual quality. Furthermore, Discrete Sine Transform (DST) is utilized instead of traditional Discrete Cosine Transform (DCT) for 4x4 intra-transform blocks.
H.264の8つのイントラ予測モードと比較して、HEVCは33方向の角度イントラ予測をサポートしています。この柔軟性の向上により、エッジの予測が向上し、エッジの周囲のリンギングアーティファクトを低減できるため、客観的なコーディング効率と視覚的な品質の両方が向上します。さらに、参照サンプルは予測方向に基づいて適応的に平滑化されます。アーティファクトのコンターを回避するために、新しい補間予測生成が含まれ、視覚的な品質が向上しています。さらに、4x4イントラ変換ブロックでは、従来の離散コサイン変換（DCT）の代わりに離散サイン変換（DST）が使用されます。
Other coding-tool features
その他のコーディングツール機能
HEVC includes some tools for lossless coding and efficient screen-content coding, such as skipping the transform for certain blocks. These tools are particularly useful, for example, when streaming the user interface of a mobile device to a large display.
HEVCには、特定のブロックの変換をスキップするなど、ロスレスコーディングと効率的な画面コンテンツコーディングのためのツールがいくつか含まれています。これらのツールは、たとえば、モバイルデバイスのユーザーインターフェイスを大きなディスプレイにストリーミングする場合に特に便利です。
HEVC inherited the basic systems and transport interfaces designs from H.264. These include the NAL-unit-based syntax structure, the hierarchical syntax and data unit structure, the Supplemental Enhancement Information (SEI) message mechanism, and the video buffering model based on the Hypothetical Reference Decoder (HRD). The hierarchical syntax and data unit structure consists of sequence-level parameter sets, multi-picture-level or picture-level parameter sets, slice-level header parameters, and lower-level parameters. In the following, a list of differences in these aspects compared to H.264 is summarized.
HEVCは、H.264から基本システムとトランスポートインターフェイスの設計を継承しています。これらには、NALユニットベースの構文構造、階層構文とデータユニット構造、Supplemental Enhancement Information（SEI）メッセージメカニズム、Hypothetical Reference Decoder（HRD）に基づくビデオバッファリングモデルが含まれます。階層構文とデータユニット構造は、シーケンスレベルのパラメーターセット、マルチピクチャーレベルまたはピクチャーレベルのパラメーターセット、スライスレベルのヘッダーパラメーター、および下位レベルのパラメーターで構成されています。以下に、H.264と比較したこれらの側面の違いのリストを要約します。
Video parameter set
ビデオパラメータセット
A new type of parameter set, called Video Parameter Set (VPS), was introduced. For the first (2013) version of [HEVC], the VPS NAL unit is required to be available prior to its activation, while the information contained in the VPS is not necessary for operation of the decoding process. For future HEVC extensions, such as the 3D or scalable extensions, the VPS is expected to include information necessary for operation of the decoding process, e.g., decoding dependency or information for reference picture set construction of enhancement layers. The VPS provides a "big picture" of a bitstream, including what types of operation points are provided, the profile, tier, and level of the operation points, and some other high-level properties of the bitstream that can be used as the basis for session negotiation and content selection, etc. (see Section 7.1).
ビデオパラメータセット（VPS）と呼ばれる新しいタイプのパラメータセットが導入されました。 [HEVC]の最初の（2013）バージョンでは、VPS NALユニットはアクティベーションの前に利用可能である必要がありますが、VPSに含まれる情報はデコードプロセスの動作に必要ありません。 3Dやスケーラブル拡張などの将来のHEVC拡張の場合、VPSには、復号化プロセスの操作に必要な情報、たとえば、依存関係の復号や拡張レイヤーの参照画像セットの構築に関する情報が含まれることが期待されます。 VPSは、提供される操作ポイントのタイプ、操作ポイントのプロファイル、階層、レベル、およびベースとして使用できるビットストリームの他のいくつかの高レベルプロパティを含む、ビットストリームの「全体像」を提供しますセッションのネゴシエーションやコンテンツの選択など（セクション7.1を参照）。
Profile, tier, and level
プロファイル、階層、およびレベル
The profile, tier, and level syntax structure that can be included in both the VPS and Sequence Parameter Set (SPS) includes 12 bytes of data to describe the entire bitstream (including all temporally scalable layers, which are referred to as sub-layers in the HEVC specification), and can optionally include more profile, tier, and level information pertaining to individual temporally scalable layers. The profile indicator shows the "best viewed as" profile when the bitstream conforms to multiple profiles, similar to the major brand concept in the ISO Base Media File Format (ISOBMFF) [IS014496-12] [IS015444-12] and file formats derived based on ISOBMFF, such as the 3GPP file format [3GPPFF]. The profile, tier, and level syntax structure also includes indications such as 1) whether the bitstream is free of frame-packed content, 2) whether the bitstream is free of interlaced source content, and 3) whether the bitstream is free of field pictures. When the answer is yes for both 2) and 3), the bitstream contains only frame pictures of progressive source. Based on these indications, clients/players without support of post-processing functionalities for the handling of frame-packed, interlaced source content or field pictures can reject those bitstreams that contain such pictures.
VPSとシーケンスパラメーターセット（SPS）の両方に含めることができるプロファイル、階層、およびレベルの構文構造には、ビットストリーム全体（すべての時間的にスケーラブルなレイヤーを含む12バイトのデータが含まれます。 HEVC仕様）、および個々の時間的にスケーラブルなレイヤーに関連するプロファイル、階層、およびレベル情報をオプションで含めることができます。プロファイルインジケーターは、ビットストリームが複数のプロファイルに準拠している場合に「最もよく見える」プロファイルを示します。これは、ISOベースメディアファイル形式（ISOBMFF）の主要なブランドコンセプト[IS014496-12] [IS015444-12]および3GPPファイル形式[3GPPFF]などのISOBMFF。プロファイル、階層、およびレベルの構文構造には、1）ビットストリームにフレームパックされたコンテンツがないかどうか、2）ビットストリームにインターレースされたソースコンテンツがないかどうか、3）ビットストリームにフィールドピクチャがないかどうかなどの指示も含まれます。 。 2）と3）の両方で答えがyesの場合、ビットストリームにはプログレッシブソースのフレーム画像のみが含まれます。これらの指示に基づいて、フレームパックされたインターレースソースコンテンツまたはフィールドピクチャを処理するための後処理機能をサポートしていないクライアント/プレーヤーは、そのようなピクチャを含むビットストリームを拒否できます。
Bitstream and elementary stream
ビットストリームとエレメンタリーストリーム
HEVC includes a definition of an elementary stream, which is new compared to H.264. An elementary stream consists of a sequence of one or more bitstreams. An elementary stream that consists of two or more bitstreams has typically been formed by splicing together two or more bitstreams (or parts thereof). When an elementary stream contains more than one bitstream, the last NAL unit of the last access unit of a bitstream (except the last bitstream in the elementary stream) must contain an end of bitstream NAL unit, and the first access unit of the subsequent bitstream must be an Intra-Random Access Point (IRAP) access unit. This IRAP access unit may be a Clean Random Access (CRA), Broken Link Access (BLA), or Instantaneous Decoding Refresh (IDR) access unit.
HEVCには、H.264と比較して新しいエレメンタリーストリームの定義が含まれています。エレメンタリーストリームは、1つ以上のビットストリームのシーケンスで構成されます。 ２つ以上のビットストリームからなるエレメンタリーストリームは、通常、２つ以上のビットストリーム（またはその一部）を一緒に接合することによって形成されてきた。エレメンタリーストリームに複数のビットストリームが含まれている場合、ビットストリームの最後のアクセスユニットの最後のNALユニット（エレメンタリーストリームの最後のビットストリームを除く）には、ビットストリームの最後のNALユニットと、後続のビットストリームの最初のアクセスユニットが含まれている必要があります。 Intra-Random Access Point（IRAP）アクセスユニットである必要があります。このIRAPアクセスユニットは、クリーンランダムアクセス（CRA）、ブロークンリンクアクセス（BLA）、または即時デコードリフレッシュ（IDR）アクセスユニットです。
Random access support
ランダムアクセスのサポート
HEVC includes signaling in the NAL unit header, through NAL unit types, of IRAP pictures beyond IDR pictures. Three types of IRAP pictures, namely IDR, CRA, and BLA pictures, are supported: IDR pictures are conventionally referred to as closed group-of-pictures (closed-GOP) random access points whereas CRA and BLA pictures are conventionally referred to as open-GOP random access points. BLA pictures usually originate from splicing of two bitstreams or part thereof at a CRA picture, e.g., during stream switching. To enable better systems usage of IRAP pictures, altogether six different NAL units are defined to signal the properties of the IRAP pictures, which can be used to better match the stream access point types as defined in the ISOBMFF [IS014496-12] [IS015444-12], which are utilized for random access support in both 3GP-DASH [3GPDASH] and MPEG DASH [MPEGDASH]. Pictures following an IRAP picture in decoding order and preceding the IRAP picture in output order are referred to as leading pictures associated with the IRAP picture. There are two types of leading pictures: Random Access Decodable Leading (RADL) pictures and Random Access Skipped Leading (RASL) pictures. RADL pictures are decodable when the decoding started at the associated IRAP picture; RASL pictures are not decodable when the decoding started at the associated IRAP picture and are usually discarded. HEVC provides mechanisms to enable specifying the conformance of a bitstream wherein the originally present RASL pictures have been discarded. Consequently, system components can discard RASL pictures, when needed, without worrying about causing the bitstream to become non-compliant.
HEVCは、NALユニットタイプを通じて、IDRピクチャを超えたIRAPピクチャのシグナリングをNALユニットヘッダーに含めます。 3種類のIRAPピクチャ、つまりIDR、CRA、およびBLAピクチャがサポートされています。IDRピクチャは、通常、クローズドピクチャオブピクチャ（クローズドGOP）ランダムアクセスポイントと呼ばれ、CRAおよびBLAピクチャは、通常、オープンと呼ばれます。 -GOPランダムアクセスポイント。 ＢＬＡ画像は、通常、例えばストリーム切り替え中のＣＲＡ画像での２つのビットストリームまたはその一部のスプライシングから生じる。 IRAP画像のより良いシステム使用を可能にするために、全体で6つの異なるNALユニットが定義され、IRAP画像のプロパティを通知します。これは、ISOBMFF [IS014496-12] [IS015444- 12]は、3GP-DASH [3GPDASH]とMPEG DASH [MPEGDASH]の両方でランダムアクセスサポートに使用されます。デコード順でIRAPピクチャに続き、出力順でIRAPピクチャに先行するピクチャは、IRAPピクチャに関連付けられたリーディングピクチャと呼ばれます。リーディングピクチャには、ランダムアクセスデコダブルリーディング（RADL）ピクチャとランダムアクセススキップリーディング（RASL）ピクチャの2種類があります。 RADLピクチャは、関連するIRAPピクチャでデコードが開始されたときにデコード可能です。 RASLピクチャは、関連付けられたIRAPピクチャでデコードが開始されたときにデコードできず、通常は破棄されます。 HEVCは、元々存在していたRASLピクチャが破棄されているビットストリームの準拠を指定できるメカニズムを提供します。したがって、システムコンポーネントは、ビットストリームが非準拠になることを心配することなく、必要に応じてRASL画像を破棄できます。
Temporal scalability support
時間的スケーラビリティのサポート
HEVC includes an improved support of temporal scalability, by inclusion of the signaling of TemporalId in the NAL unit header, the restriction that pictures of a particular temporal sub-layer cannot be used for inter prediction reference by pictures of a lower temporal sub-layer, the sub-bitstream extraction process, and the requirement that each sub-bitstream extraction output be a conforming bitstream. Media-Aware Network Elements (MANEs) can utilize the TemporalId in the NAL unit header for stream adaptation purposes based on temporal scalability.
HEVCには、NALユニットヘッダーにTemporalIdのシグナリングを含めることにより、時間スケーラビリティのサポートが改善されています。特定の時間サブレイヤーの画像は、下位時間サブレイヤーの画像によるインター予測参照に使用できないという制限があります。サブビットストリーム抽出プロセス、および各サブビットストリーム抽出出力が適合ビットストリームであるという要件。 Media-Aware Network Elements（MANE）は、時間スケーラビリティに基づくストリーム適応のために、NALユニットヘッダーのTemporalIdを利用できます。
Temporal sub-layer switching support
一時的なサブレイヤースイッチングのサポート
HEVC specifies, through NAL unit types present in the NAL unit header, the signaling of Temporal Sub-layer Access (TSA) and Step-wise Temporal Sub-layer Access (STSA). A TSA picture and pictures following the TSA picture in decoding order do not use pictures prior to the TSA picture in decoding order with TemporalId greater than or equal to that of the TSA picture for inter prediction reference. A TSA picture enables up-switching, at the TSA picture, to the sub-layer containing the TSA picture or any higher sub-layer, from the immediately lower sub-layer. An STSA picture does not use pictures with the same TemporalId as the STSA picture for inter prediction reference. Pictures following an STSA picture in decoding order with the same TemporalId as the STSA picture do not use pictures prior to the STSA picture in decoding order with the same TemporalId as the STSA picture for inter prediction reference. An STSA picture enables up-switching, at the STSA picture, to the sub-layer containing the STSA picture, from the immediately lower sub-layer.
HEVCは、NALユニットヘッダーにあるNALユニットタイプを介して、Temporal Sub-layer Access（TSA）およびStep-wise Temporal Sub-layer Access（STSA）のシグナリングを指定します。 TSAピクチャとTSAピクチャのデコード順に続くピクチャは、TemporalIdがTSAピクチャのそれと等しいかそれ以上であるTSAピクチャより前のピクチャをデコード順に使用しないでください。 TSAピクチャは、TSAピクチャで、すぐ下のサブレイヤからTSAピクチャまたはそれより上位のサブレイヤを含むサブレイヤへのアップスイッチングを可能にします。 STSA画像は、インター予測参照のために、STSA画像と同じTemporalIdを持つ画像を使用しません。 STSAピクチャと同じTemporalIdを持つデコード順でSTSAピクチャに続くピクチャは、インター予測参照のために、STSAピクチャと同じTemporalIdを持つデコード順でSTSAピクチャの前のピクチャを使用しません。 STSAピクチャは、STSAピクチャで、すぐ下のサブレイヤからSTSAピクチャを含むサブレイヤへのアップスイッチングを可能にします。
Sub-layer reference or non-reference pictures
サブレイヤー参照または非参照画像
The concept and signaling of reference/non-reference pictures in HEVC are different from H.264. In H.264, if a picture may be used by any other picture for inter prediction reference, it is a reference picture; otherwise, it is a non-reference picture, and this is signaled by two bits in the NAL unit header. In HEVC, a picture is called a reference picture only when it is marked as "used for reference". In addition, the concept of sub-layer reference picture was introduced. If a picture may be used by another other picture with the same TemporalId for inter prediction reference, it is a sub-layer reference picture; otherwise, it is a sub-layer non-reference picture. Whether a picture is a sub-layer reference picture or sub-layer non-reference picture is signaled through NAL unit type values.
HEVCの参照/非参照画像の概念とシグナリングは、H.264とは異なります。 H.264では、画像が他の画像でインター予測参照に使用される場合、それは参照画像です。それ以外の場合、それは非参照画像であり、これはNALユニットヘッダーの2ビットで通知されます。 HEVCでは、「参照に使用」としてマークされている場合にのみ、画像は参照画像と呼ばれます。さらに、サブレイヤー参照画像の概念が導入されました。画像がインター予測参照のために同じTemporalIdを持つ他の別の画像によって使用される可能性がある場合、それはサブレイヤー参照画像です。それ以外の場合は、サブレイヤーの非参照画像です。ピクチャがサブレイヤ参照ピクチャであるか、サブレイヤ非参照ピクチャであるかは、NALユニットタイプ値によって通知されます。
Extensibility
拡張性
Besides the TemporalId in the NAL unit header, HEVC also includes the signaling of a six-bit layer ID in the NAL unit header, which must be equal to 0 for a single-layer bitstream. Extension mechanisms have been included in the VPS, SPS, Picture Parameter Set (PPS), SEI NAL unit, slice headers, and so on. All these extension mechanisms enable future extensions in a backward-compatible manner, such that bitstreams encoded according to potential future HEVC extensions can be fed to then-legacy decoders (e.g., HEVC version 1 decoders), and the then-legacy decoders can decode and output the base-layer bitstream.
NALユニットヘッダーのTemporalIdに加えて、HEVCには、NALユニットヘッダーに6ビットレイヤーIDのシグナリングも含まれています。これは、シングルレイヤービットストリームの場合は0に等しくなければなりません。拡張メカニズムは、VPS、SPS、ピクチャーパラメータセット（PPS）、SEI NALユニット、スライスヘッダーなどに含まれています。これらのすべての拡張メカニズムは、将来の拡張を下位互換性のある方法で可能にします。たとえば、将来のHEVC拡張の可能性に従ってエンコードされたビットストリームを当時のレガシーデコーダー（HEVCバージョン1デコーダーなど）に送り、当時のレガシーデコーダーがデコードして基本レイヤのビットストリームを出力します。
Bitstream extraction
ビットストリーム抽出
HEVC includes a bitstream-extraction process as an integral part of the overall decoding process. The bitstream extraction process is used in the process of bitstream conformance tests, which is part of the HRD buffering model.
HEVCには、全体的な復号化プロセスの不可欠な部分としてビットストリーム抽出プロセスが含まれています。ビットストリーム抽出プロセスは、HRDバッファリングモデルの一部であるビットストリーム適合性テストのプロセスで使用されます。
Reference picture management
参照画像管理
The reference picture management of HEVC, including reference picture marking and removal from the Decoded Picture Buffer (DPB) as well as Reference Picture List Construction (RPLC), differs from that of H.264. Instead of the reference picture marking mechanism based on a sliding window plus adaptive Memory Management Control Operation (MMCO) described in H.264, HEVC specifies a reference picture management and marking mechanism based on Reference Picture Set (RPS), and the RPLC is consequently based on the RPS mechanism. An RPS consists of a set of reference pictures associated with a picture, consisting of all reference pictures that are prior to the associated picture in decoding order, that may be used for inter prediction of the associated picture or any picture following the associated picture in decoding order. The reference picture set consists of five lists of reference pictures; RefPicSetStCurrBefore, RefPicSetStCurrAfter, RefPicSetStFoll, RefPicSetLtCurr, and RefPicSetLtFoll. RefPicSetStCurrBefore, RefPicSetStCurrAfter, and RefPicSetLtCurr contain all reference pictures that may be used in inter prediction of the current picture and that may be used in inter prediction of one or more of the pictures following the current picture in decoding order. RefPicSetStFoll and RefPicSetLtFoll consist of all reference pictures that are not used in inter prediction of the current picture but may be used in inter prediction of one or more of the pictures following the current picture in decoding order. RPS provides an "intra-coded" signaling of the DPB status, instead of an "inter-coded" signaling, mainly for improved error resilience. The RPLC process in HEVC is based on the RPS, by signaling an index to an RPS subset for each reference index; this process is simpler than the RPLC process in H.264.
HEVCの参照画像管理は、参照画像のマーキングとデコード済み画像バッファー（DPB）からの削除、および参照画像リスト構築（RPLC）を含み、H.264のそれとは異なります。 HVCは、H.264で説明されているスライディングウィンドウと適応型のメモリ管理制御操作（MMCO）に基づく参照画像のマーキングメカニズムの代わりに、参照画像セット（RPS）に基づいて参照画像の管理とマーキングメカニズムを指定します。 RPSメカニズムに基づいています。 RPSは、画像に関連付けられた一連の参照画像で構成されます。これは、復号化順序で関連画像の前にあるすべての参照画像で構成され、関連画像または復号で関連画像に続く任意の画像のインター予測に使用できます。注文。参照画像セットは、参照画像の5つのリストで構成されます。 RefPicSetStCurrBefore、RefPicSetStCurrAfter、RefPicSetStFoll、RefPicSetLtCurr、およびRefPicSetLtFoll。 RefPicSetStCurrBefore、RefPicSetStCurrAfter、およびRefPicSetLtCurrには、現在の画像のインター予測で使用できるすべての参照画像と、現在の画像に続く1つまたは複数の画像のデコード順でのインター予測で使用できるすべての参照画像が含まれます。 RefPicSetStFollとRefPicSetLtFollは、現在の画像のインター予測では使用されないが、復号化順に現在の画像に続く1つ以上の画像のインター予測で使用されるすべての参照画像で構成されます。 RPSは、主にエラー耐性を向上させるために、「インターコード」シグナリングの代わりに、DPBステータスの「イントラコード」シグナリングを提供します。 HEVCのRPLCプロセスはRPSに基づいており、各参照インデックスのRPSサブセットにインデックスをシグナリングします。このプロセスは、H.264のRPLCプロセスよりも単純です。
Ultra-low delay support
超低遅延サポート
HEVC specifies a sub-picture-level HRD operation, for support of the so-called ultra-low delay. The mechanism specifies a standard-compliant way to enable delay reduction below a one-picture interval. Coded Picture Buffer (CPB) and DPB parameters at the sub-picture level may be signaled, and utilization of this information for the derivation of CPB timing (wherein the CPB removal time corresponds to decoding time) and DPB output timing (display time) is specified. Decoders are allowed to operate the HRD at the conventional access-unit level, even when the sub-picture-level HRD parameters are present.
HEVCは、いわゆる超低遅延をサポートするために、サブピクチャレベルのHRD操作を指定します。このメカニズムでは、標準に準拠した方法を指定して、1ピクチャ間隔未満の遅延を削減できるようにします。サブピクチャレベルでのコード化ピクチャバッファ（CPB）およびDPBパラメータが通知され、CPBタイミング（CPB除去時間がデコード時間に対応する）およびDPB出力タイミング（表示時間）の導出のためのこの情報の利用は指定。デコーダーは、サブピクチャレベルのHRDパラメーターが存在する場合でも、従来のアクセスユニットレベルでHRDを操作できます。
New SEI messages
ねｗ せい めっさげｓ
HEVC inherits many H.264 SEI messages with changes in syntax and/or semantics making them applicable to HEVC. Additionally, there are a few new SEI messages reviewed briefly in the following paragraphs.
HEVCは多くのH.264 SEIメッセージを継承し、構文やセマンティクスを変更してHEVCに適用できるようにします。さらに、以下の段落で簡単に確認されたいくつかの新しいSEIメッセージがあります。
The display orientation SEI message informs the decoder of a transformation that is recommended to be applied to the cropped decoded picture prior to display, such that the pictures can be properly displayed, e.g., in an upside-up manner.
表示方向ＳＥＩメッセージは、表示前にクロップされた復号画像に適用することが推奨される変換をデコーダに通知し、それにより、例えば、逆さまに画像を適切に表示することができる。
The structure of pictures SEI message provides information on the NAL unit types, picture-order count values, and prediction dependencies of a sequence of pictures. The SEI message can be used, for example, for concluding what impact a lost picture has on other pictures.
ピクチャの構造SEIメッセージは、NALユニットタイプ、ピクチャ順序カウント値、およびピクチャシーケンスの予測依存性に関する情報を提供します。 SEIメッセージは、たとえば、失われた画像が他の画像に与える影響を結論付けるために使用できます。
The decoded picture hash SEI message provides a checksum derived from the sample values of a decoded picture. It can be used for detecting whether a picture was correctly received and decoded.
デコードされた画像のハッシュSEIメッセージは、デコードされた画像のサンプル値から導出されたチェックサムを提供します。画像が正しく受信およびデコードされたかどうかを検出するために使用できます。
The active parameter sets SEI message includes the IDs of the active video parameter set and the active sequence parameter set and can be used to activate VPSs and SPSs. In addition, the SEI message includes the following indications: 1) An indication of whether "full random accessibility" is supported (when supported, all parameter sets needed for decoding of the remaining of the bitstream when random accessing from the beginning of the current CVS by completely discarding all access units earlier in decoding order are present in the remaining bitstream, and all coded pictures in the remaining bitstream can be correctly decoded); 2) An indication of whether there is no parameter set within the current CVS that updates another parameter set of the same type preceding in decoding order. An update of a parameter set refers to the use of the same parameter set ID but with some other parameters changed. If this property is true for all CVSs in the bitstream, then all parameter sets can be sent out-of-band before session start.
アクティブパラメータセットのSEIメッセージには、アクティブビデオパラメータセットとアクティブシーケンスパラメータセットのIDが含まれており、VPSとSPSをアクティブにするために使用できます。さらに、SEIメッセージには次の指示が含まれます。1）「完全ランダムアクセス」がサポートされているかどうかの指示（サポートされている場合、現在のCVSの先頭からランダムアクセスするときに、ビットストリームの残りのデコードに必要なすべてのパラメーターセット）復号化順序の早い段階ですべてのアクセスユニットを完全に破棄することにより、残りのビットストリームに存在し、残りのビットストリームのすべての符号化された画像を正しく復号化できます）; 2）現在のCVS内に、同じタイプの別のパラメーターセットをデコード順に先行して更新するパラメーターセットがないかどうかを示します。パラメータセットの更新とは、同じパラメータセットIDの使用を指しますが、他のいくつかのパラメータが変更されています。このプロパティがビットストリーム内のすべてのCVSでtrueの場合、すべてのパラメーターセットをセッション開始前に帯域外で送信できます。
The decoding unit information SEI message provides information regarding coded picture buffer removal delay for a decoding unit. The message can be used in very-low-delay buffering operations.
復号化ユニット情報ＳＥＩメッセージは、復号化ユニットのためのコード化画像バッファ除去遅延に関する情報を提供する。このメッセージは、非常に遅延の少ないバッファリング操作で使用できます。
The region refresh information SEI message can be used together with the recovery point SEI message (present in both H.264 and HEVC) for improved support of gradual decoding refresh. This supports random access from inter-coded pictures, wherein complete pictures can be correctly decoded or recovered after an indicated number of pictures in output/display order.
リージョンリフレッシュ情報SEIメッセージは、リカバリポイントSEIメッセージ（H.264とHEVCの両方に存在）と一緒に使用して、段階的なデコードリフレッシュのサポートを向上させることができます。これは、インターコーディングされた画像からのランダムアクセスをサポートします。指定された数の画像が出力/表示順になった後、完全な画像を正しくデコードまたは復元できます。
The reportedly significantly higher encoding computational demand of HEVC over H.264, in conjunction with the ever-increasing video resolution (both spatially and temporally) required by the market, led to the adoption of VCL coding tools specifically targeted to allow for parallelization on the sub-picture level. That is, parallelization occurs, at the minimum, at the granularity of an integer number of CTUs. The targets for this type of high-level parallelization are multicore CPUs and DSPs as well as multiprocessor systems. In a system design, to be useful, these tools require signaling support, which is provided in Section 7 of this memo. This section provides a brief overview of the tools available in [HEVC].
伝えられるところによると、H.264を超えるHEVCの大幅に高いエンコーディングコンピューティング要求と、市場で要求される（空間的および時間的の両方で）ますます高まるビデオ解像度により、サブピクチャレベル。つまり、並列化は最低でも整数のCTUの粒度で行われます。このタイプの高レベル並列化のターゲットは、マルチコアCPUとDSP、およびマルチプロセッサシステムです。システム設計では、これらのツールが有用であるためには、このメモのセクション7で提供されているシグナリングサポートが必要です。このセクションでは、[HEVC]で利用可能なツールの概要を説明します。
Many of the tools incorporated in HEVC were designed keeping in mind the potential parallel implementations in multicore/multiprocessor architectures. Specifically, for parallelization, four picture partition strategies, as described below, are available.
HEVCに組み込まれているツールの多くは、マルチコア/マルチプロセッサアーキテクチャでの並列実装の可能性を考慮して設計されています。具体的には、並列化では、以下に説明する4つの画像分割戦略を使用できます。
Slices are segments of the bitstream that can be reconstructed independently from other slices within the same picture (though there may still be interdependencies through loop filtering operations). Slices are the only tool that can be used for parallelization that is also available, in virtually identical form, in H.264. Parallelization based on slices does not require much inter-processor or inter-core communication (except for inter-processor or inter-core data sharing for motion compensation when decoding a predictively coded picture, which is typically much heavier than inter-processor or inter-core data sharing due to in-picture prediction), as slices are designed to be independently decodable. However, for the same reason, slices can require some coding overhead. Further, slices (in contrast to some of the other tools mentioned below) also serve as the key mechanism for bitstream partitioning to match Maximum Transfer Unit (MTU) size requirements, due to the in-picture independence of slices and the fact that each regular slice is encapsulated in its own NAL unit. In many cases, the goal of parallelization and the goal of MTU size matching can place contradicting demands to the slice layout in a picture. The realization of this situation led to the development of the more advanced tools mentioned below.
スライスはビットストリームのセグメントであり、同じ画像内の他のスライスから独立して再構築できます（ただし、ループフィルタリング操作により相互依存性が依然として存在する場合があります）。スライスは、並列化に使用できる唯一のツールであり、H.264でもほぼ同じ形式で使用できます。スライスに基づく並列化は、プロセッサ間またはコア間通信をあまり必要としません（予測的にコード化された画像をデコードするときの動き補償のためのプロセッサ間またはコア間データ共有を除く）。これは通常、プロセッサ間またはプロセッサ間よりはるかに重いです。スライスは独立してデコードできるように設計されているため、画面内予測によるコアデータ共有）。ただし、同じ理由で、スライスにはコーディングのオーバーヘッドが必要になる場合があります。さらに、スライスは（以下で説明する他のいくつかのツールとは対照的に）ビットストリーム分割の主要なメカニズムとして機能し、スライスの画像内の独立性と各定期的なスライスは独自のNALユニットにカプセル化されます。多くの場合、並列化の目標とMTUサイズマッチングの目標は、画像のスライスレイアウトに相反する要求を課す可能性があります。この状況の実現は、以下に述べるより高度なツールの開発につながりました。
Dependent slice segments allow for fragmentation of a coded slice into fragments at CTU boundaries without breaking any in-picture prediction mechanisms. They are complementary to the fragmentation mechanism described in this memo in that they need the cooperation of the encoder. As a dependent slice segment necessarily contains an integer number of CTUs, a decoder using multiple cores operating on CTUs can process a dependent slice segment without communicating parts of the slice segment's bitstream to other cores. Fragmentation, as specified in this memo, in contrast, does not guarantee that a fragment contains an integer number of CTUs.
依存スライスセグメントにより、ピクチャ内予測メカニズムを壊すことなく、CTU境界でコード化スライスをフラグメントに断片化できます。それらは、エンコーダーの協力を必要とするという点で、このメモで説明されている断片化メカニズムを補完します。依存スライスセグメントには必ず整数のCTUが含まれるため、CTUで動作する複数のコアを使用するデコーダーは、スライスセグメントのビットストリームの一部を他のコアに伝達せずに、依存スライスセグメントを処理できます。これとは対照的に、このメモで指定されているフラグメンテーションは、フラグメントに整数のCTUが含まれていることを保証するものではありません。
In Wavefront Parallel Processing (WPP), the picture is partitioned into rows of CTUs. Entropy decoding and prediction are allowed to use data from CTUs in other partitions. Parallel processing is possible through parallel decoding of CTU rows, where the start of the decoding of a row is delayed by two CTUs, so to ensure that data related to a CTU above and to the right of the subject CTU is available before the subject CTU is being decoded. Using this staggered start (which appears like a wavefront when represented graphically), parallelization is possible with up to as many processors/cores as the picture contains CTU rows.
Wavefront Parallel Processing（WPP）では、画像はCTUの行に分割されます。エントロピーのデコードと予測では、他のパーティションのCTUからのデータを使用できます。並列処理は、行の復号化の開始が2つのCTUだけ遅延されるCTU行の並列復号化によって可能であり、対象のCTUの上と右のCTUに関連するデータが、対象のCTUの前に確実に利用できるようにします。デコード中です。この交互配置の開始点（グラフィカルに表現すると波面のように見える）を使用すると、画像に含まれるCTU行と同じ数のプロセッサ/コアまでの並列化が可能です。
Because in-picture prediction between neighboring CTU rows within a picture is allowed, the required inter-processor/inter-core communication to enable in-picture prediction can be substantial. The WPP partitioning does not result in the creation of more NAL units compared to when it is not applied; thus, WPP cannot be used for MTU size matching, though slices can be used in combination for that purpose.
画像内の隣接するCTU行間の画像内予測が許可されているため、画像内予測を可能にするために必要なプロセッサ間/コア間通信は、かなりの量になる可能性があります。 WPPパーティショニングでは、適用されない場合と比較して、NALユニットが多く作成されることはありません。したがって、MTUサイズのマッチングにWPPを使用することはできませんが、スライスを組み合わせて使用することはできます。
Tiles define horizontal and vertical boundaries that partition a picture into tile columns and rows. The scan order of CTUs is changed to be local within a tile (in the order of a CTU raster scan of a tile), before decoding the top-left CTU of the next tile in the order of tile raster scan of a picture. Similar to slices, tiles break in-picture prediction dependencies (including entropy decoding dependencies). However, they do not need to be included into individual NAL units (same as WPP in this regard); hence, tiles cannot be used for MTU size matching, though slices can be used in combination for that purpose. Each tile can be processed by one processor/core, and the inter-processor/inter-core communication required for in-picture prediction between processing units decoding neighboring tiles is limited to conveying the shared slice header in cases a slice is spanning more than one tile, and loop-filtering-related sharing of reconstructed samples and metadata. Insofar, tiles are less demanding in terms of inter-processor communication bandwidth compared to WPP due to the in-picture independence between two neighboring partitions.
タイルは、画像をタイルの列と行に分割する水平境界と垂直境界を定義します。画像のタイルラスタスキャンの順序で次のタイルの左上のCTUをデコードする前に、CTUのスキャン順序がタイル内でローカルになるように（タイルのCTUラスタスキャンの順序で）変更されます。スライスと同様に、タイルは画像内予測依存関係（エントロピーデコード依存関係を含む）を分割します。ただし、これらは個々のNALユニットに含める必要はありません（この点でWPPと同じ）。したがって、MTUサイズのマッチングにタイルを使用することはできませんが、そのためにスライスを組み合わせて使用できます。各タイルは1つのプロセッサ/コアで処理でき、隣接タイルをデコードする処理ユニット間の画像内予測に必要なプロセッサ間/コア間通信は、スライスが複数にまたがる場合に共有スライスヘッダーの伝達に限定されます。タイル、および再構築されたサンプルとメタデータのループフィルタリング関連の共有。これまでのところ、タイルは、2つの隣接するパーティション間の画像内の独立性により、WPPに比べてプロセッサ間の通信帯域幅の要件が低くなっています。
HEVC maintains the NAL unit concept of H.264 with modifications. HEVC uses a two-byte NAL unit header, as shown in Figure 1. The payload of a NAL unit refers to the NAL unit excluding the NAL unit header.
HEVCはH.264のNALユニットのコンセプトを変更して維持しています。図1に示すように、HEVCは2バイトのNALユニットヘッダーを使用します。NALユニットのペイロードは、NALユニットヘッダーを除くNALユニットを指します。
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Type | LayerId | TID |
+-------------+-----------------+
Figure 1: The Structure of the HEVC NAL Unit Header
図1：HEVC NALユニットヘッダーの構造
The semantics of the fields in the NAL unit header are as specified in [HEVC] and described briefly below for convenience. In addition to the name and size of each field, the corresponding syntax element name in [HEVC] is also provided.
NALユニットヘッダーのフィールドのセマンティクスは[HEVC]で指定されているとおりであり、便宜上以下で簡単に説明されています。各フィールドの名前とサイズに加えて、[HEVC]の対応する構文要素名も提供されます。
F: 1 bit forbidden_zero_bit. Required to be zero in [HEVC]. Note that the inclusion of this bit in the NAL unit header was to enable transport of HEVC video over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S]. In the context of this memo,
F：1ビットforbidden_zero_bit。 [HEVC]ではゼロにする必要があります。 NALユニットヘッダーにこのビットを含めることで、MPEG-2トランスポートシステムを介したHEVCビデオのトランスポートが可能になったことに注意してください（スタートコードエミュレーションの回避）[MPEG2S]。このメモの文脈では、
the value 1 may be used to indicate a syntax violation, e.g., for a NAL unit resulted from aggregating a number of fragmented units of a NAL unit but missing the last fragment, as described in Section 4.4.3.
値1は、構文違反を示すために使用できます。たとえば、セクション4.4.3で説明されているように、NALユニットの断片化されたユニットをいくつか集計したが、最後のフラグメントが欠落したために発生したNALユニットの場合などです。
Type: 6 bits nal_unit_type. This field specifies the NAL unit type as defined in Table 7-1 of [HEVC]. If the most significant bit of this field of a NAL unit is equal to 0 (i.e., the value of this field is less than 32), the NAL unit is a VCL NAL unit. Otherwise, the NAL unit is a non-VCL NAL unit. For a reference of all currently defined NAL unit types and their semantics, please refer to Section 7.4.2 in [HEVC].
タイプ：6ビットのnal_unit_type。このフィールドは、[HEVC]の表7-1で定義されているNALユニットタイプを指定します。 NALユニットのこのフィールドの最上位ビットが0に等しい場合（つまり、このフィールドの値が32より小さい場合）、NALユニットはVCL NALユニットです。それ以外の場合、NALユニットは非VCL NALユニットです。現在定義されているすべてのNALユニットタイプとそのセマンティクスのリファレンスについては、[HEVC]のセクション7.4.2を参照してください。
LayerId: 6 bits nuh_layer_id. Required to be equal to zero in [HEVC]. It is anticipated that in future scalable or 3D video coding extensions of this specification, this syntax element will be used to identify additional layers that may be present in the CVS, wherein a layer may be, e.g., a spatial scalable layer, a quality scalable layer, a texture view, or a depth view.
LayerId：6ビットnuh_layer_id。 [HEVC]ではゼロに等しいことが必要です。この仕様の将来のスケーラブルまたは3Dビデオコーディング拡張では、この構文要素を使用して、CVSに存在する可能性のある追加のレイヤーを識別します。レイヤーは、たとえば、空間スケーラブルレイヤー、品質スケーラブルなどです。レイヤー、テクスチャビュー、または深度ビュー。
TID: 3 bits nuh_temporal_id_plus1. This field specifies the temporal identifier of the NAL unit plus 1. The value of TemporalId is equal to TID minus 1. A TID value of 0 is illegal to ensure that there is at least one bit in the NAL unit header equal to 1, so to enable independent considerations of start code emulations in the NAL unit header and in the NAL unit payload data.
TID：3ビットnuh_temporal_id_plus1。このフィールドは、NALユニットの一時ID + 1を指定します。TemporalIdの値は、TID-1に等しくなります。TAL値0は、NALユニットヘッダーに少なくとも1ビットが1であることを保証するために不正です。 NALユニットヘッダーとNALユニットペイロードデータでの開始コードエミュレーションの独立した考慮事項を有効にします。
This payload format defines the following processes required for transport of HEVC coded data over RTP [RFC3550]:
このペイロード形式は、RTC [RFC3550]を介したHEVCコード化データの転送に必要な次のプロセスを定義します。
o Usage of RTP header with this payload format
o このペイロード形式でのRTPヘッダーの使用
o Packetization of HEVC coded NAL units into RTP packets using three types of payload structures: a single NAL unit packet, aggregation packet, and fragment unit
o HEVCでコード化されたNALユニットのRTPパケットへのパケット化（単一のNALユニットパケット、集約パケット、フラグメントユニット）
o Transmission of HEVC NAL units of the same bitstream within a single RTP stream or multiple RTP streams (within one or more RTP sessions), where within an RTP stream transmission of NAL units may be either non-interleaved (i.e., the transmission order of NAL units is the same as their decoding order) or interleaved (i.e., the transmission order of NAL units is different from the decoding order)
o 単一のRTPストリームまたは複数のRTPストリーム（1つ以上のRTPセッション内）内の同じビットストリームのHEVC NALユニットの送信。RTPストリーム内では、NALユニットの送信はインターリーブされない（つまり、NALの送信順序） unitsは、それらのデコード順と同じです）またはインターリーブされます（つまり、NALユニットの送信順はデコード順とは異なります）
o Media type parameters to be used with the Session Description Protocol (SDP) [RFC4566]
o セッション記述プロトコル（SDP）で使用されるメディアタイプパラメータ[RFC4566]
o A payload header extension mechanism and data structures for enhanced support of temporal scalability based on that extension mechanism.
o ペイロードヘッダー拡張メカニズムとその拡張メカニズムに基づく一時的なスケーラビリティのサポートを強化するためのデータ構造。
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 BCP 14 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14 [RFC2119]で説明されているように解釈されます。
In this document, the above key words will convey that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying the significance described in RFC 2119.
このドキュメントでは、上記のキーワードは、すべて大文字の場合にのみその解釈を伝えます。これらの単語の小文字の使用は、RFC 2119に記載されている重要性を持つと解釈されるべきではありません。
This specification uses the notion of setting and clearing a bit when bit fields are handled. Setting a bit is the same as assigning that bit the value of 1 (On). Clearing a bit is the same as assigning that bit the value of 0 (Off).
この仕様では、ビットフィールドを処理するときにビットを設定およびクリアするという概念を使用しています。ビットを設定することは、そのビットに値1（オン）を割り当てることと同じです。ビットをクリアすることは、そのビットに値0（オフ）を割り当てることと同じです。
This document uses the terms and definitions of [HEVC]. Section 3.1.1 lists relevant definitions from [HEVC] for convenience. Section 3.1.2 provides definitions specific to this memo.
このドキュメントでは、[HEVC]の用語と定義を使用しています。セクション3.1.1は、便宜上、[HEVC]の関連定義をリストしています。セクション3.1.2は、このメモに固有の定義を提供します。
access unit: A set of NAL units that are associated with each other according to a specified classification rule, that are consecutive in decoding order, and that contain exactly one coded picture.
アクセスユニット：指定された分類規則に従って互いに関連付けられ、デコード順で連続しており、1つのコード化されたピクチャを含むNALユニットのセット。
BLA access unit: An access unit in which the coded picture is a BLA picture.
ＢＬＡアクセスユニット：コード化された画像がＢＬＡ画像であるアクセスユニット。
BLA picture: An IRAP picture for which each VCL NAL unit has nal_unit_type equal to BLA_W_LP, BLA_W_RADL, or BLA_N_LP.
BLAピクチャ：各VCL NALユニットのnal_unit_typeがBLA_W_LP、BLA_W_RADL、またはBLA_N_LPに等しいIRAPピクチャ。
Coded Video Sequence (CVS): A sequence of access units that consists, in decoding order, of an IRAP access unit with NoRaslOutputFlag equal to 1, followed by zero or more access units that are not IRAP access units with NoRaslOutputFlag equal to 1, including all subsequent access units up to but not including any subsequent access unit that is an IRAP access unit with NoRaslOutputFlag equal to 1.
コード化ビデオシーケンス（CVS）：NoRaslOutputFlagが1のIRAPアクセスユニットからなるアクセスユニットのシーケンス。その後に、NoRaslOutputFlagが1のIRAPアクセスユニットではない0個以上のアクセスユニットが続きます。 NoRaslOutputFlagが1のIRAPアクセスユニットである後続のアクセスユニットまでのすべての後続のアクセスユニット
Informative note: An IRAP access unit may be an IDR access unit, a BLA access unit, or a CRA access unit. The value of NoRaslOutputFlag is equal to 1 for each IDR access unit, each BLA access unit, and each CRA access unit that is the first access unit in the bitstream in decoding order, is the first access unit that follows an end of sequence NAL unit in decoding order, or has HandleCraAsBlaFlag equal to 1.
参考情報：IRAPアクセスユニットは、IDRアクセスユニット、BLAアクセスユニット、またはCRAアクセスユニットです。 NoRaslOutputFlagの値は、各IDRアクセスユニット、各BLAアクセスユニット、およびデコード順でビットストリームの最初のアクセスユニットである各CRAアクセスユニットで1に等しく、シーケンスの最後のNALユニットに続く最初のアクセスユニットです。デコード順、またはHandleCraAsBlaFlagが1に等しい。
CRA access unit: An access unit in which the coded picture is a CRA picture.
ＣＲＡアクセスユニット：コード化された画像がＣＲＡ画像であるアクセスユニット。
CRA picture: A RAP picture for which each VCL NAL unit has nal_unit_type equal to CRA_NUT.
CRAピクチャ：各VCL NALユニットがnal_unit_typeがCRA_NUTに等しいRAPピクチャ。
IDR access unit: An access unit in which the coded picture is an IDR picture.
ＩＤＲアクセスユニット：コード化された画像がＩＤＲ画像であるアクセスユニット。
IDR picture: A RAP picture for which each VCL NAL unit has nal_unit_type equal to IDR_W_RADL or IDR_N_LP.
IDRピクチャ：各VCL NALユニットがnal_unit_typeがIDR_W_RADLまたはIDR_N_LPに等しいRAPピクチャ。
IRAP access unit: An access unit in which the coded picture is an IRAP picture.
IRAPアクセスユニット：コード化された画像がIRAP画像であるアクセスユニット。
IRAP picture: A coded picture for which each VCL NAL unit has nal_unit_type in the range of BLA_W_LP (16) to RSV_IRAP_VCL23 (23), inclusive.
IRAPピクチャ：各VCL NALユニットがBLA_W_LP（16）からRSV_IRAP_VCL23（23）の範囲のnal_unit_typeを持つコード化されたピクチャ。
layer: A set of VCL NAL units that all have a particular value of nuh_layer_id and the associated non-VCL NAL units, or one of a set of syntactical structures having a hierarchical relationship.
レイヤー：すべてが特定の値のnuh_layer_idと関連する非VCL NALユニットを持つVCL NALユニットのセット、または階層関係を持つ構文構造のセットの1つ。
operation point: bitstream created from another bitstream by operation of the sub-bitstream extraction process with the another bitstream, a target highest TemporalId, and a target-layer identifier list as input.
オペレーションポイント：別のビットストリーム、ターゲットの最高のTemporalId、およびターゲットレイヤー識別子リストを入力として使用したサブビットストリーム抽出プロセスの操作によって別のビットストリームから作成されたビットストリーム。
random access: The act of starting the decoding process for a bitstream at a point other than the beginning of the bitstream.
ランダムアクセス：ビットストリームの先頭以外のポイントでビットストリームのデコードプロセスを開始する動作。
sub-layer: A temporal scalable layer of a temporal scalable bitstream consisting of VCL NAL units with a particular value of the TemporalId variable, and the associated non-VCL NAL units.
サブレイヤー：TemporalId変数の特定の値を持つVCL NALユニットと、関連する非VCL NALユニットで構成される時間スケーラブルビットストリームの時間スケーラブルレイヤー。
sub-layer representation: A subset of the bitstream consisting of NAL units of a particular sub-layer and the lower sub-layers.
サブレイヤー表現：特定のサブレイヤーと下位のサブレイヤーのNALユニットで構成されるビットストリームのサブセット。
tile: A rectangular region of coding tree blocks within a particular tile column and a particular tile row in a picture.
タイル：画像の特定のタイル列と特定のタイル行内のコーディングツリーブロックの長方形の領域。
tile column: A rectangular region of coding tree blocks having a height equal to the height of the picture and a width specified by syntax elements in the picture parameter set.
タイル列：高さが画像の高さに等しく、幅が画像パラメーターセットの構文要素で指定されたコーディングツリーブロックの長方形の領域。
tile row: A rectangular region of coding tree blocks having a height specified by syntax elements in the picture parameter set and a width equal to the width of the picture.
タイル行：画像パラメーターセットの構文要素で指定された高さと画像の幅に等しい幅を持つコーディングツリーブロックの長方形の領域。
dependee RTP stream: An RTP stream on which another RTP stream depends. All RTP streams in a Multiple RTP streams on a Single media Transport (MRST) or Multiple RTP streams on Multiple media Transports (MRMT), except for the highest RTP stream, are dependee RTP streams.
依存先RTPストリーム：別のRTPストリームが依存するRTPストリーム。単一のメディアトランスポート（MRST）上の複数のRTPストリームまたは複数のメディアトランスポート（MRMT）上の複数のRTPストリーム内のすべてのRTPストリームは、最高のRTPストリームを除いて、依存RTPストリームです。
highest RTP stream: The RTP stream on which no other RTP stream depends. The RTP stream in a Single RTP stream on a Single media Transport (SRST) is the highest RTP stream.
最も高いRTPストリーム：他のRTPストリームが依存しないRTPストリーム。シングルメディアトランスポート（SRST）のシングルRTPストリームのRTPストリームは、最も高いRTPストリームです。
Media-Aware Network Element (MANE): A network element, such as a middlebox, selective forwarding unit, or application-layer gateway that is capable of parsing certain aspects of the RTP payload headers or the RTP payload and reacting to their contents.
Media-Aware Network Element（MANE）：RTPペイロードヘッダーまたはRTPペイロードの特定の側面を解析し、それらのコンテンツに反応できるミドルボックス、選択転送ユニット、アプリケーション層ゲートウェイなどのネットワーク要素。
Informative note: The concept of a MANE goes beyond normal routers or gateways in that a MANE has to be aware of the signaling (e.g., to learn about the payload type mappings of the media streams), and in that it has to be trusted when working with Secure RTP (SRTP). The advantage of using MANEs is that they allow packets to be dropped according to the needs of the media coding. For example, if a MANE has to drop packets due to congestion on a certain link, it can identify and remove those packets whose elimination produces the least adverse effect on the user experience. After dropping packets, MANEs must rewrite RTCP packets to match the changes to the RTP stream, as specified in Section 7 of [RFC3550].
有益なメモ：MANEはシグナリングを認識しなければならない（たとえば、メディアストリームのペイロードタイプマッピングについて知る）必要があるという点で、MANEの概念は通常のルーターまたはゲートウェイを超えています。 Secure RTP（SRTP）での作業。 MANEを使用する利点は、メディアコーディングのニーズに応じてパケットをドロップできることです。たとえば、MANEが特定のリンクの輻輳のためにパケットをドロップする必要がある場合、その排除によってユーザーエクスペリエンスへの悪影響が最も少ないパケットを識別して削除できます。 [RFC3550]のセクション7で指定されているように、パケットをドロップした後、MANEはRTCPパケットを書き換えて、RTPストリームへの変更を一致させる必要があります。
Media Transport: As used in the MRST, MRMT, and SRST definitions below, Media Transport denotes the transport of packets over a transport association identified by a 5-tuple (source address, source port, destination address, destination port, transport protocol). See also Section 2.1.13 of [RFC7656].
メディアトランスポート：以下のMRST、MRMT、およびSRSTの定義で使用されるメディアトランスポートは、5タプル（ソースアドレス、ソースポート、宛先アドレス、宛先ポート、トランスポートプロトコル）で識別されるトランスポートアソシエーションを介したパケットのトランスポートを示します。 [RFC7656]のセクション2.1.13も参照してください。
Informative note: The term "bitstream" in this document is equivalent to the term "encoded stream" in [RFC7656].
参考情報：このドキュメントの「ビットストリーム」という用語は、[RFC7656]の「エンコードされたストリーム」という用語と同等です。
Multiple RTP streams on a Single media Transport (MRST): Multiple RTP streams carrying a single HEVC bitstream on a Single Transport. See also Section 3.5 of [RFC7656].
単一のメディアトランスポート（MRST）での複数のRTPストリーム：単一のトランスポートで単一のHEVCビットストリームを運ぶ複数のRTPストリーム。 [RFC7656]のセクション3.5もご覧ください。
Multiple RTP streams on Multiple media Transports (MRMT): Multiple RTP streams carrying a single HEVC bitstream on Multiple Transports. See also Section 3.5 of [RFC7656].
複数のメディアトランスポート（MRMT）上の複数のRTPストリーム：複数のトランスポート上で単一のHEVCビットストリームを運ぶ複数のRTPストリーム。 [RFC7656]のセクション3.5もご覧ください。
NAL unit decoding order: A NAL unit order that conforms to the constraints on NAL unit order given in Section 7.4.2.4 in [HEVC].
NALユニットのデコード順：[HEVC]のセクション7.4.2.4に記載されているNALユニットの順番の制約に準拠するNALユニットの順番。
NAL unit output order: A NAL unit order in which NAL units of different access units are in the output order of the decoded pictures corresponding to the access units, as specified in [HEVC], and in which NAL units within an access unit are in their decoding order.
NALユニットの出力順序：異なるアクセスユニットのNALユニットが、[HEVC]で指定されている、アクセスユニットに対応するデコードされたピクチャの出力順序であり、アクセスユニット内のNALユニットが含まれるNALユニットの順序デコード順序。
NAL-unit-like structure: A data structure that is similar to NAL units in the sense that it also has a NAL unit header and a payload, with a difference that the payload does not follow the start code emulation prevention mechanism required for the NAL unit syntax as specified in Section 7.3.1.1 of [HEVC]. Examples of NAL-unit-like structures defined in this memo are packet payloads of Aggregation Packet (AP), PAyload Content Information (PACI), and Fragmentation Unit (FU) packets.
NALユニットのような構造：NALユニットヘッダーとペイロードも持つという意味でNALユニットと同様のデータ構造ですが、NALに必要な開始コードエミュレーション防止メカニズムにペイロードが従わない点が異なります。 [HEVC]のセクション7.3.1.1で指定されているユニット構文。このメモで定義されているNALユニットのような構造の例は、Aggregation Packet（AP）、PAyload Content Information（PACI）、およびFragmentation Unit（FU）パケットのパケットペイロードです。
NALU-time: The value that the RTP timestamp would have if the NAL unit would be transported in its own RTP packet.
NALU-time：NALユニットが独自のRTPパケットで転送される場合のRTPタイムスタンプの値。
RTP stream: See [RFC7656]. Within the scope of this memo, one RTP stream is utilized to transport one or more temporal sub-layers.
RTPストリーム：[RFC7656]を参照してください。このメモの範囲内では、1つのRTPストリームを使用して、1つ以上の一時的なサブレイヤーを転送します。
Single RTP stream on a Single media Transport (SRST): Single RTP stream carrying a single HEVC bitstream on a Single (Media) Transport. See also Section 3.5 of [RFC7656].
単一メディアトランスポート（SRST）上の単一RTPストリーム：単一（メディア）トランスポート上の単一HEVCビットストリームを運ぶ単一RTPストリーム。 [RFC7656]のセクション3.5もご覧ください。
transmission order: The order of packets in ascending RTP sequence number order (in modulo arithmetic). Within an aggregation packet, the NAL unit transmission order is the same as the order of appearance of NAL units in the packet.
送信順序：RTPシーケンス番号の昇順（モジュロ演算）のパケットの順序。集約パケット内では、NALユニットの送信順序は、パケット内のNALユニットの出現順序と同じです。
AP Aggregation Packet
集約パケット
BLA Broken Link Access
BLA Broken Link Access
CRA Clean Random Access
CRAクリーンランダムアクセス
CTB Coding Tree Block
CTBコーディングツリーブロック
CTU Coding Tree Unit
CTUコーディングツリーユニット
CVS Coded Video Sequence
CVSコード化ビデオシーケンス
DPH Decoded Picture Hash
DPHデコードされた画像のハッシュ
FU Fragmentation Unit
FUフラグメンテーションユニット
HRD Hypothetical Reference Decoder
HRD仮説参照デコーダー
IDR Instantaneous Decoding Refresh
IDR瞬時デコードリフレッシュ
IRAP Intra Random Access Point
IRAPイントラランダムアクセスポイント
MANE Media-Aware Network Element
MANE Media-Aware Network Element
MRMT Multiple RTP streams on Multiple media Transports
複数のメディアトランスポート上のMRMT複数のRTPストリーム
MRST Multiple RTP streams on a Single media Transport
単一のメディアトランスポート上のMRST複数のRTPストリーム
MTU Maximum Transfer Unit
MTU最大転送単位
NAL Network Abstraction Layer
NALネットワーク抽象化レイヤー
NALU Network Abstraction Layer Unit
NALUネットワーク抽象化層ユニット
PACI PAyload Content Information
PACI PAyloadコンテンツ情報
PHES Payload Header Extension Structure
PHESペイロードヘッダー拡張構造
PPS Picture Parameter Set
PPS画像パラメーターセット
RADL Random Access Decodable Leading (Picture)
RADL Random Access Decodable Leading（図）
RASL Random Access Skipped Leading (Picture)
RASLランダムアクセススキップリーディング（図）
RPS Reference Picture Set SEI Supplemental Enhancement Information
RPS参照画像セットSEI補足拡張情報
SPS Sequence Parameter Set
SPSシーケンスパラメータセット
SRST Single RTP stream on a Single media Transport
単一メディアトランスポート上のSRST単一RTPストリーム
STSA Step-wise Temporal Sub-layer Access
STSAステップワイズテンポラルサブレイヤーアクセス
TSA Temporal Sub-layer Access
TSA時間的サブレイヤーアクセス
TSCI Temporal Scalability Control Information
TSCI時間的スケーラビリティ制御情報
VCL Video Coding Layer
VCLビデオコーディングレイヤー
VPS Video Parameter Set
VPSビデオパラメータセット
The format of the RTP header is specified in [RFC3550] (reprinted as Figure 2 for convenience). This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーのフォーマットは[RFC3550]で指定されています（便宜上、図2として転載）。このペイロード形式は、その仕様と一致する方法でヘッダーのフィールドを使用します。
The RTP payload (and the settings for some RTP header bits) for aggregation packets and fragmentation units are specified in Sections 4.4.2 and 4.4.3, respectively.
集約パケットとフラグメント化ユニットのRTPペイロード（および一部のRTPヘッダービットの設定）は、それぞれセクション4.4.2および4.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=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RTP Header According to [RFC3550]
図2：[RFC3550]によるRTPヘッダー
The RTP header information to be set according to this RTP payload format is set as follows:
このRTPペイロードフォーマットに従って設定されるRTPヘッダー情報は、以下のように設定されています。
Marker bit (M): 1 bit
マーカービット（M）：1ビット
Set for the last packet of the access unit, carried in the current RTP stream. This is in line with the normal use of the M bit in video formats to allow an efficient playout buffer handling. When MRST or MRMT is in use, if an access unit appears in multiple RTP streams, the marker bit is set on each RTP stream's last packet of the access unit.
現在のRTPストリームで運ばれるアクセスユニットの最後のパケットに設定されます。これは、ビデオ形式でのMビットの通常の使用と一致しており、効率的な再生バッファーの処理を可能にします。 MRSTまたはMRMTが使用されている場合、アクセスユニットが複数のRTPストリームに表示されると、各RTPストリームのアクセスユニットの最後のパケットにマーカービットが設定されます。
Informative note: The content of a NAL unit does not tell whether or not the NAL unit is the last NAL unit, in decoding order, of an access unit. An RTP sender implementation may obtain this information from the video encoder. If, however, the implementation cannot obtain this information directly from the encoder, e.g., when the bitstream was pre-encoded, and also there is no timestamp allocated for each NAL unit, then the sender implementation can inspect subsequent NAL units in decoding order to determine whether or not the NAL unit is the last NAL unit of an access unit as follows. A NAL unit is determined to be the last NAL unit of an access unit if it is the last NAL unit of the bitstream. A NAL unit naluX is also determined to be the last NAL unit of an access unit if both the following conditions are true: 1) the next VCL NAL unit naluY in decoding order has the high-order bit of the first byte after its NAL unit header equal to 1, and 2) all NAL units between naluX and naluY, when present, have nal_unit_type in the range of 32 to 35, inclusive, equal to 39, or in the ranges of 41 to 44, inclusive, or 48 to 55, inclusive.
参考情報：NALユニットのコンテンツは、NALユニットがアクセスユニットのデコード順で最後のNALユニットであるかどうかを通知しません。 RTP送信側の実装では、この情報をビデオエンコーダーから取得できます。ただし、実装がエンコーダから直接この情報を取得できない場合、たとえばビットストリームが事前にエンコードされていて、各NALユニットにタイムスタンプが割り当てられていない場合、送信側の実装は、次のNALユニットをデコード順に検査して、以下のように、NALユニットがアクセスユニットの最後のNALユニットであるかどうかを判断します。 ＮＡＬユニットは、それがビットストリームの最後のＮＡＬユニットである場合、アクセスユニットの最後のＮＡＬユニットであると決定される。次の両方の条件が当てはまる場合、NALユニットnaluXもアクセスユニットの最後のNALユニットであると判断されます。1）デコード順の次のVCL NALユニットnaluYが、NALユニットの後の最初のバイトの上位ビットを持っているヘッダーは1に等しく、2）naluXとnaluYの間のすべてのNALユニット（存在する場合）のnal_unit_typeは、32〜35（両端を含む）、39と等しい、または41〜44（両端を含む）、または48〜55の範囲です。 、包括的。
Payload Type (PT): 7 bits
ペイロードタイプ（PT）：7ビット
The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here. The assignment of a payload type has to be performed either through the profile used or in a dynamic way.
この新しいパケット形式に対するRTPペイロードタイプの割り当ては、このドキュメントの範囲外であるため、ここでは指定しません。ペイロードタイプの割り当ては、使用するプロファイルを介して、または動的に実行する必要があります。
Informative note: It is not required to use different payload type values for different RTP streams in MRST or MRMT.
参考情報：MRSTまたはMRMTの異なるRTPストリームに異なるペイロードタイプ値を使用する必要はありません。
Sequence Number (SN): 16 bits
シーケンス番号（SN）：16ビット
Set and used in accordance with [RFC3550].
[RFC3550]に従って設定して使用します。
Timestamp: 32 bits
タイムスタンプ：32ビット
The RTP timestamp is set to the sampling timestamp of the content. A 90 kHz clock rate MUST be used.
RTPタイムスタンプは、コンテンツのサンプリングタイムスタンプに設定されます。 90 kHzクロックレートを使用する必要があります。
If the NAL unit has no timing properties of its own (e.g., parameter set and SEI NAL units), the RTP timestamp MUST be set to the RTP timestamp of the coded picture of the access unit in which the NAL unit (according to Section 7.4.2.4.4 of [HEVC]) is included.
NALユニットに独自のタイミングプロパティがない場合（たとえば、パラメータセットとSEI NALユニット）、RTPタイムスタンプは、NALユニットが含まれるアクセスユニットのコード化された画像のRTPタイムスタンプに設定する必要があります（セクション7.4に従って）。 [HEVC]の2.4.4）が含まれています。
Receivers MUST use the RTP timestamp for the display process, even when the bitstream contains picture timing SEI messages or decoding unit information SEI messages as specified in [HEVC]. However, this does not mean that picture timing SEI messages in the bitstream should be discarded, as picture timing SEI messages may contain frame-field information that is important in appropriately rendering interlaced video.
[HEVC]で指定されているように、ビットストリームに画像タイミングSEIメッセージまたはデコードユニット情報SEIメッセージが含まれている場合でも、受信者は表示プロセスにRTPタイムスタンプを使用する必要があります。ただし、これは、ビットストリーム内の画像タイミングSEIメッセージを破棄する必要があることを意味するものではありません。画像タイミングSEIメッセージには、インターレースビデオの適切なレンダリングに重要なフレームフィールド情報が含まれている可能性があるためです。
Synchronization source (SSRC): 32 bits
同期ソース（SSRC）：32ビット
Used to identify the source of the RTP packets. When using SRST, by definition a single SSRC is used for all parts of a single bitstream. In MRST or MRMT, different SSRCs are used for each RTP stream containing a subset of the sub-layers of the single (temporally scalable) bitstream. A receiver is required to correctly associate the set of SSRCs that are included parts of the same bitstream.
RTPパケットの送信元を識別するために使用されます。 SRSTを使用する場合、定義上、単一のSSRCが単一のビットストリームのすべての部分に使用されます。 MRSTまたはMRMTでは、単一の（一時的にスケーラブルな）ビットストリームのサブレイヤーのサブセットを含む各RTPストリームに異なるSSRCが使用されます。同じビットストリームの一部に含まれるSSRCのセットを正しく関連付けるには、レシーバーが必要です。
The first two bytes of the payload of an RTP packet are referred to as the payload header. The payload header consists of the same fields (F, Type, LayerId, and TID) as the NAL unit header as shown in Section 1.1.4, irrespective of the type of the payload structure.
RTPパケットのペイロードの最初の2バイトは、ペイロードヘッダーと呼ばれます。ペイロードヘッダーは、ペイロード構造のタイプに関係なく、セクション1.1.4に示すように、NALユニットヘッダーと同じフィールド（F、Type、LayerId、およびTID）で構成されます。
The TID value indicates (among other things) the relative importance of an RTP packet, for example, because NAL units belonging to higher temporal sub-layers are not used for the decoding of lower temporal sub-layers. A lower value of TID indicates a higher importance. More-important NAL units MAY be better protected against transmission losses than less-important NAL units.
TID値は、（特に）RTPパケットの相対的な重要性を示します。これは、上位の一時的なサブレイヤーに属するNALユニットが下位の一時的なサブレイヤーのデコードに使用されないためです。 TIDの値が低いほど、重要度が高くなります。重要度の高いNALユニットは、重要度の低いNALユニットよりも伝送損失から保護される場合があります。
This memo enables transmission of an HEVC bitstream over:
このメモはHEVCビットストリームの送信を可能にします：
o a Single RTP stream on a Single media Transport (SRST),
o シングルメディアトランスポート（SRST）上のシングルRTPストリーム
o Multiple RTP streams over a Single media Transport (MRST), or
o 単一のメディアトランスポート（MRST）を介した複数のRTPストリーム、または
o Multiple RTP streams on Multiple media Transports (MRMT).
o 複数のメディアトランスポート（MRMT）上の複数のRTPストリーム。
Informative note: While this specification enables the use of MRST within the H.265 RTP payload, the signaling of MRST within SDP offer/answer is not fully specified at the time of this writing. See [RFC5576] and [RFC5583] for what is supported today as well as [RTP-MULTI-STREAM] and [SDP-NEG] for future directions.
参考情報：この仕様ではH.265 RTPペイロード内でMRSTを使用できますが、SDPオファー/アンサー内でのMRSTのシグナリングは、この記事の執筆時点では完全には指定されていません。現在サポートされている機能については[RFC5576]と[RFC5583]を、将来の方向については[RTP-MULTI-STREAM]と[SDP-NEG]を参照してください。
When in MRMT, the dependency of one RTP stream on another RTP stream is typically indicated as specified in [RFC5583]. [RFC5583] can also be utilized to specify dependencies within MRST, but only if the RTP streams utilize distinct payload types.
MRMTでは、1つのRTPストリームの別のRTPストリームへの依存性は、通常[RFC5583]で指定されているように示されます。 [RFC5583]を使用してMRST内の依存関係を指定することもできますが、RTPストリームが異なるペイロードタイプを使用する場合のみです。
SRST or MRST SHOULD be used for point-to-point unicast scenarios, whereas MRMT SHOULD be used for point-to-multipoint multicast scenarios where different receivers require different operation points of the same HEVC bitstream, to improve bandwidth utilizing efficiency.
ポイントツーポイントユニキャストシナリオにはSRSTまたはMRSTを使用する必要があります（SHOULD）。一方、MRMTは、効率を高めるために帯域幅を改善するために、異なるレシーバーが同じHEVCビットストリームの異なる操作ポイントを必要とするポイントツーマルチポイントマルチキャストシナリオに使用する必要があります（SHOULD）。
Informative note: A multicast may degrade to a unicast after all but one receivers have left (this is a justification of the first "SHOULD" instead of "MUST"), and there might be scenarios where MRMT is desirable but not possible, e.g., when IP multicast is not deployed in certain network (this is a justification of the second "SHOULD" instead of "MUST").
参考情報：1つを除くすべてのレシーバーが去った後（これは「MUST」ではなく最初の「SHOULD」の正当化である）、マルチキャストはユニキャストに低下する可能性があり、MRMTが望ましいが不可能であるシナリオがあるかもしれません。特定のネットワークにIPマルチキャストが展開されていない場合（これは、「MUST」の代わりに2番目の「SHOULD」を正当化するものです）。
The transmission mode is indicated by the tx-mode media parameter (see Section 7.1). If tx-mode is equal to "SRST", SRST MUST be used. Otherwise, if tx-mode is equal to "MRST", MRST MUST be used. Otherwise (tx-mode is equal to "MRMT"), MRMT MUST be used.
送信モードは、tx-modeメディアパラメータで示されます（セクション7.1を参照）。 tx-modeが「SRST」に等しい場合、SRSTを使用する必要があります。それ以外の場合、tx-modeが「MRST」に等しい場合、MRSTを使用する必要があります。それ以外の場合（tx-modeが "MRMT"と等しい）、MRMTを使用する必要があります。
Informative note: When an RTP stream does not depend on other RTP streams, any of SRST, MRST, or MRMT may be in use for the RTP stream.
参考情報：RTPストリームが他のRTPストリームに依存していない場合、RTPストリームにSRST、MRST、またはMRMTのいずれかが使用されている可能性があります。
Receivers MUST support all of SRST, MRST, and MRMT.
受信者は、SRST、MRST、およびMRMTのすべてをサポートする必要があります。
Informative note: The required support of MRMT by receivers does not imply that multicast must be supported by receivers.
参考情報：受信者によるMRMTのサポートが必須であることは、マルチキャストが受信者によってサポートされる必要があることを意味するものではありません。
Four different types of RTP packet payload structures are specified. A receiver can identify the type of an RTP packet payload through the Type field in the payload header.
4つの異なるタイプのRTPパケットペイロード構造が指定されています。受信者は、ペイロードヘッダーのTypeフィールドを通じてRTPパケットペイロードのタイプを識別できます。
The four different payload structures are as follows:
4つの異なるペイロード構造は次のとおりです。
o Single NAL unit packet: Contains a single NAL unit in the payload, and the NAL unit header of the NAL unit also serves as the payload header. This payload structure is specified in Section 4.4.1.
o 単一のNALユニットパケット：ペイロードに単一のNALユニットが含まれ、NALユニットのNALユニットヘッダーもペイロードヘッダーとして機能します。このペイロード構造は、セクション4.4.1で指定されています。
o Aggregation Packet (AP): Contains more than one NAL unit within one access unit. This payload structure is specified in Section 4.4.2.
o 集約パケット（AP）：1つのアクセスユニット内に複数のNALユニットが含まれています。このペイロード構造は、セクション4.4.2で指定されています。
o Fragmentation Unit (FU): Contains a subset of a single NAL unit. This payload structure is specified in Section 4.4.3.
o フラグメンテーションユニット（FU）：単一のNALユニットのサブセットが含まれています。このペイロード構造は、セクション4.4.3で指定されています。
o PACI carrying RTP packet: Contains a payload header (that differs from other payload headers for efficiency), a Payload Header Extension Structure (PHES), and a PACI payload. This payload structure is specified in Section 4.4.4.
o RCIパケットを運ぶPACI：ペイロードヘッダー（他のペイロードヘッダーとは効率が異なる）、ペイロードヘッダー拡張構造（PHES）、およびPACIペイロードが含まれています。このペイロード構造は、セクション4.4.4で指定されています。
A single NAL unit packet contains exactly one NAL unit, and consists of a payload header (denoted as PayloadHdr), a conditional 16-bit DONL field (in network byte order), and the NAL unit payload data (the NAL unit excluding its NAL unit header) of the contained NAL unit, as shown in Figure 3.
1つのNALユニットパケットには、1つのNALユニットが含まれ、ペイロードヘッダー（PayloadHdrと表記）、条件付きの16ビットDONLフィールド（ネットワークバイト順）、およびNALユニットのペイロードデータ（NALを除くNALユニット）で構成されます。図3に示すように、含まれているNALユニットのユニットヘッダー）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr | DONL (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NAL unit payload data |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Structure of a Single NAL Unit Packet
図3：単一のNALユニットパケットの構造
The payload header SHOULD be an exact copy of the NAL unit header of the contained NAL unit. However, the Type (i.e., nal_unit_type) field MAY be changed, e.g., when it is desirable to handle a CRA picture to be a BLA picture [JCTVC-J0107].
ペイロードヘッダーは、含まれているNALユニットのNALユニットヘッダーの正確なコピーである必要があります。ただし、タイプ（つまり、nal_unit_type）フィールドは、たとえば、CRAピクチャをBLAピクチャとして処理することが望ましい場合に変更される場合があります[JCTVC-J0107]。
The DONL field, when present, specifies the value of the 16 least significant bits of the decoding order number of the contained NAL unit. If sprop-max-don-diff is greater than 0 for any of the RTP streams, the DONL field MUST be present, and the variable DON for the contained NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the DONL field MUST NOT be present.
DONLフィールドは、存在する場合、含まれているNALユニットのデコード順序番号の最下位16ビットの値を指定します。いずれかのRTPストリームでsprop-max-don-diffが0より大きい場合、DONLフィールドが存在しなければならず（MUST）、含まれているNALユニットの変数DONはDONLフィールドの値に等しいと導出されます。それ以外の場合（すべてのRTPストリームでsprop-max-don-diffが0に等しい）、DONLフィールドが存在してはなりません（MUST NOT）。
Aggregation Packets (APs) are introduced to enable the reduction of packetization overhead for small NAL units, such as most of the non-VCL NAL units, which are often only a few octets in size.
集約パケット（AP）は、サイズが数オクテットしかないことが多いほとんどの非VCL NALユニットなどの小さなNALユニットのパケット化オーバーヘッドの削減を可能にするために導入されています。
An AP aggregates NAL units within one access unit. Each NAL unit to be carried in an AP is encapsulated in an aggregation unit. NAL units aggregated in one AP are in NAL unit decoding order.
APは、NALユニットを1つのアクセスユニットに集約します。 APで運ばれる各NALユニットは、集約ユニットにカプセル化されます。 1つのAPに集約されたNALユニットは、NALユニットのデコード順です。
An AP consists of a payload header (denoted as PayloadHdr) followed by two or more aggregation units, as shown in Figure 4.
図4に示すように、APはペイロードヘッダー（PayloadHdrと表記）とそれに続く2つ以上の集約ユニットで構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| two or more aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Structure of an Aggregation Packet
図4：集約パケットの構造
The fields in the payload header are set as follows. The F bit MUST be equal to 0 if the F bit of each aggregated NAL unit is equal to zero; otherwise, it MUST be equal to 1. The Type field MUST be equal to 48. The value of LayerId MUST be equal to the lowest value of LayerId of all the aggregated NAL units. The value of TID MUST be the lowest value of TID of all the aggregated NAL units.
ペイロードヘッダーのフィールドは次のように設定されます。各集約NALユニットのFビットがゼロに等しい場合、Fビットは0に等しくなければなりません。それ以外の場合、それは1に等しくなければなりません。Typeフィールドは48に等しくなければなりません。LayerIdの値は、すべての集約されたNALユニットのLayerIdの最小値に等しくなければなりません。 TIDの値は、すべての集約されたNALユニットのTIDの最小値である必要があります。
Informative note: All VCL NAL units in an AP have the same TID value since they belong to the same access unit. However, an AP may contain non-VCL NAL units for which the TID value in the NAL unit header may be different than the TID value of the VCL NAL units in the same AP.
参考情報：AP内のすべてのVCL NALユニットは、同じアクセスユニットに属しているため、同じTID値を持っています。ただし、APには、NALユニットヘッダーのTID値が同じAPのVCL NALユニットのTID値と異なる非VCL NALユニットが含まれている場合があります。
An AP MUST carry at least two aggregation units and can carry as many aggregation units as necessary; however, the total amount of data in an AP obviously MUST fit into an IP packet, and the size SHOULD be chosen so that the resulting IP packet is smaller than the MTU size so to avoid IP layer fragmentation. An AP MUST NOT contain FUs specified in Section 4.4.3. APs MUST NOT be nested; i.e., an AP must not contain another AP.
APは少なくとも2つの集約ユニットを伝送する必要があり、必要な数の集約ユニットを伝送できます。ただし、APのデータの合計量は明らかにIPパケットに収まる必要があり、IP層の断片化を回避するために、結果のIPパケットがMTUサイズよりも小さくなるようにサイズを選択する必要があります（SHOULD）。 APはセクション4.4.3で指定されたFUを含んではいけません。 APはネストしてはいけません。つまり、APに別のAPを含めることはできません。
The first aggregation unit in an AP consists of a conditional 16-bit DONL field (in network byte order) followed by a 16-bit unsigned size information (in network byte order) that indicates the size of the NAL unit in bytes (excluding these two octets, but including the NAL unit header), followed by the NAL unit itself, including its NAL unit header, as shown in Figure 5.
APの最初のアグリゲーションユニットは、条件付きの16ビットDONLフィールド（ネットワークバイト順）と、それに続くNALユニットのサイズ（バイトを除く）を示す16ビットの符号なしサイズ情報（ネットワークバイト順）で構成されます（これらを除く）図5に示すように、2オクテット（ただし、NALユニットヘッダーを含む）、その後にNALユニットヘッダーを含むNALユニット自体。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DONL (conditional) | NALU size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU size | |
+-+-+-+-+-+-+-+-+ NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Structure of the First Aggregation Unit in an AP
図5：APの最初のアグリゲーションユニットの構造
The DONL field, when present, specifies the value of the 16 least significant bits of the decoding order number of the aggregated NAL unit.
DONLフィールドは、存在する場合、集約されたNALユニットのデコード順序番号の最下位16ビットの値を指定します。
If sprop-max-don-diff is greater than 0 for any of the RTP streams, the DONL field MUST be present in an aggregation unit that is the first aggregation unit in an AP, and the variable DON for the aggregated NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the DONL field MUST NOT be present in an aggregation unit that is the first aggregation unit in an AP.
sprop-max-don-diffがいずれかのRTPストリームに対して0より大きい場合、DONLフィールドはAPの最初の集約ユニットである集約ユニットに存在している必要があり、集約されたNALユニットの変数DONが導出されますDONLフィールドの値と同じ。それ以外の場合（すべてのRTPストリームでsprop-max-don-diffが0に等しい）、APの最初の集約ユニットである集約ユニットにDONLフィールドが存在してはなりません（MUST NOT）。
An aggregation unit that is not the first aggregation unit in an AP consists of a conditional 8-bit DOND field followed by a 16-bit unsigned size information (in network byte order) that indicates the size of the NAL unit in bytes (excluding these two octets, but including the NAL unit header), followed by the NAL unit itself, including its NAL unit header, as shown in Figure 6.
APの最初のアグリゲーションユニットではないアグリゲーションユニットは、条件付きの8ビットDONDフィールドと、それに続くNALユニットのサイズをバイトで示す16ビットの符号なしサイズ情報（ネットワークバイト順）で構成されます（これらを除く）図6に示すように、2オクテット（ただしNALユニットヘッダーを含む）、その後にNALユニット自体（NALユニットヘッダーを含む）が続きます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DOND (cond) | NALU size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NAL unit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Structure of an Aggregation Unit That Is Not the First Aggregation Unit in an AP
図6：APの最初のアグリゲーションユニットではないアグリゲーションユニットの構造
When present, the DOND field plus 1 specifies the difference between the decoding order number values of the current aggregated NAL unit and the preceding aggregated NAL unit in the same AP.
存在する場合、DONDフィールドに1を加えた値は、現在の集約されたNALユニットと同じAP内の前の集約されたNALユニットのデコード順序番号値の違いを示します。
If sprop-max-don-diff is greater than 0 for any of the RTP streams, the DOND field MUST be present in an aggregation unit that is not the first aggregation unit in an AP, and the variable DON for the aggregated NAL unit is derived as equal to the DON of the preceding aggregated NAL unit in the same AP plus the value of the DOND field plus 1 modulo 65536. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the DOND field MUST NOT be present in an aggregation unit that is not the first aggregation unit in an AP, and in this case the transmission order and decoding order of NAL units carried in the AP are the same as the order the NAL units appear in the AP.
sprop-max-don-diffがいずれかのRTPストリームについて0より大きい場合、DONDフィールドは、APの最初の集約ユニットではない集約ユニットに存在する必要があり、集約されたNALユニットの変数DONは同じAPの前の集約されたNALユニットのDONに、DONDフィールドの値に65536を加えた値を加えたものに等しいと導出されます。それ以外の場合（すべてのRTPストリームのsprop-max-don-diffは0に等しい）、DONDフィールドは、APの最初のアグリゲーションユニットではないアグリゲーションユニットに存在してはならない（MUST NOT）。この場合、APで伝送されるNALユニットの送信順序とデコード順序は、NALユニットがAPに表示される順序と同じです。 。
Figure 7 presents an example of an AP that contains two aggregation units, labeled as 1 and 2 in the figure, without the DONL and DOND fields being present.
図7は、DONLおよびDONDフィールドが存在しない、図で1および2とラベル付けされた2つの集約ユニットを含むAPの例を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 HDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 1 Data |
| . . . |
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 HDR | |
+-+-+-+-+-+-+-+-+ NALU 2 Data |
| . . . |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: An Example of an AP Packet Containing Two Aggregation Units without the DONL and DOND Fields Figure 8 presents an example of an AP that contains two aggregation units, labeled as 1 and 2 in the figure, with the DONL and DOND fields being present.
図7：DONLおよびDONDフィールドのない2つのアグリゲーションユニットを含むAPパケットの例図8は、DONLおよびDONDフィールドが存在する、図で1および2とラベル付けされた2つのアグリゲーションユニットを含むAPの例を示しています。 。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=48) | NALU 1 DONL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NALU 1 Data . . . |
| |
+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 DOND | NALU 2 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 HDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 2 Data |
| |
| . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: An Example of an AP Containing Two Aggregation Units with the DONL and DOND Fields
図8：DONLおよびDONDフィールドを持つ2つのアグリゲーションユニットを含むAPの例
Fragmentation Units (FUs) are introduced to enable fragmenting a single NAL unit into multiple RTP packets, possibly without cooperation or knowledge of the HEVC encoder. A fragment of a NAL unit consists of an integer number of consecutive octets of that NAL unit. Fragments of the same NAL unit MUST be sent in consecutive order with ascending RTP sequence numbers (with no other RTP packets within the same RTP stream being sent between the first and last fragment).
おそらくHEVCエンコーダーの協力や知識がなくても、単一のNALユニットを複数のRTPパケットにフラグメント化できるようにするために、フラグメンテーションユニット（FU）が導入されています。 NALユニットのフラグメントは、そのNALユニットの連続するオクテットの整数で構成されます。同じNALユニットのフラグメントは、RTPシーケンス番号の昇順で連続して送信する必要があります（同じRTPストリーム内の他のRTPパケットは、最初と最後のフラグメントの間に送信されません）。
When a NAL unit is fragmented and conveyed within FUs, it is referred to as a fragmented NAL unit. APs MUST NOT be fragmented. FUs MUST NOT be nested; i.e., an FU must not contain a subset of another FU.
NALユニットがフラグメント化され、FU内で伝達される場合、それはフラグメント化されたNALユニットと呼ばれます。 APは断片化してはなりません。 FUはネストしてはなりません。つまり、FUに別のFUのサブセットを含めることはできません。
The RTP timestamp of an RTP packet carrying an FU is set to the NALU-time of the fragmented NAL unit.
FUを伝送するRTPパケットのRTPタイムスタンプは、断片化されたNALユニットのNALU時間に設定されます。
An FU consists of a payload header (denoted as PayloadHdr), an FU header of one octet, a conditional 16-bit DONL field (in network byte order), and an FU payload, as shown in Figure 9.
図9に示すように、FUは、ペイロードヘッダー（PayloadHdrと表記）、1オクテットのFUヘッダー、条件付き16ビットDONLフィールド（ネットワークバイト順）、およびFUペイロードで構成されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=49) | FU header | DONL (cond) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| DONL (cond) | |
|-+-+-+-+-+-+-+-+ |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Structure of an FU
図9：FUの構造
The fields in the payload header are set as follows. The Type field MUST be equal to 49. The fields F, LayerId, and TID MUST be equal to the fields F, LayerId, and TID, respectively, of the fragmented NAL unit.
ペイロードヘッダーのフィールドは次のように設定されます。 Typeフィールドは49に等しくなければなりません。フィールドF、LayerId、およびTIDは、それぞれ断片化されたNALユニットのフィールドF、LayerId、およびTIDに等しくなければなりません。
The FU header consists of an S bit, an E bit, and a 6-bit FuType field, as shown in Figure 10.
図10に示すように、FUヘッダーはSビット、Eビット、および6ビットのFuTypeフィールドで構成されています。
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E| FuType |
+---------------+
Figure 10: The Structure of FU Header
図10：FUヘッダーの構造
The semantics of the FU header fields are as follows:
FUヘッダーフィールドのセマンティクスは次のとおりです。
S: 1 bit When set to 1, the S bit indicates the start of a fragmented NAL unit, i.e., the first byte of the FU payload is also the first byte of the payload of the fragmented NAL unit. When the FU payload is not the start of the fragmented NAL unit payload, the S bit MUST be set to 0.
S：1ビット1に設定すると、Sビットはフラグメント化されたNALユニットの開始を示します。つまり、FUペイロードの最初のバイトは、フラグメント化されたNALユニットのペイロードの最初のバイトでもあります。 FUペイロードがフラグメント化されたNALユニットペイロードの先頭でない場合、Sビットは0に設定する必要があります。
E: 1 bit When set to 1, the E bit indicates the end of a fragmented NAL unit, i.e., the last byte of the payload is also the last byte of the fragmented NAL unit. When the FU payload is not the last fragment of a fragmented NAL unit, the E bit MUST be set to 0.
E：1ビット1に設定すると、Eビットはフラグメント化されたNALユニットの終わりを示します。つまり、ペイロードの最後のバイトは、フラグメント化されたNALユニットの最後のバイトでもあります。 FUペイロードがフラグメント化されたNALユニットの最後のフラグメントでない場合、Eビットは0に設定する必要があります。
FuType: 6 bits The field FuType MUST be equal to the field Type of the fragmented NAL unit.
FuType：6ビットフィールドFuTypeは、断片化されたNALユニットのフィールドタイプと等しい必要があります。
The DONL field, when present, specifies the value of the 16 least significant bits of the decoding order number of the fragmented NAL unit.
DONLフィールドが存在する場合は、フラグメント化されたNALユニットのデコード順序番号の最下位16ビットの値を指定します。
If sprop-max-don-diff is greater than 0 for any of the RTP streams, and the S bit is equal to 1, the DONL field MUST be present in the FU, and the variable DON for the fragmented NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams, or the S bit is equal to 0), the DONL field MUST NOT be present in the FU.
いずれかのRTPストリームのsprop-max-don-diffが0より大きく、Sビットが1に等しい場合、DONLフィールドはFUに存在する必要があり、フラグメント化されたNALユニットの変数DONは次のように導出されます。 DONLフィールドの値と同じです。それ以外の場合（すべてのRTPストリームでsprop-max-don-diffが0に等しいか、Sビットが0に等しい）、DONLフィールドはFUに存在してはならない（MUST NOT）。
A non-fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the Start bit and End bit must not both be set to 1 in the same FU header.
断片化されていないNALユニットは、1つのFUで送信してはならない（MUST NOT）。つまり、同じFUヘッダーでStartビットとEndビットの両方を1に設定しないでください。
The FU payload consists of fragments of the payload of the fragmented NAL unit so that if the FU payloads of consecutive FUs, starting with an FU with the S bit equal to 1 and ending with an FU with the E bit equal to 1, are sequentially concatenated, the payload of the fragmented NAL unit can be reconstructed. The NAL unit header of the fragmented NAL unit is not included as such in the FU payload, but rather the information of the NAL unit header of the fragmented NAL unit is conveyed in F, LayerId, and TID fields of the FU payload headers of the FUs and the FuType field of the FU header of the FUs. An FU payload MUST NOT be empty.
FUペイロードは、断片化されたNALユニットのペイロードのフラグメントで構成されているため、連続するFUのFUペイロードが、Sビットが1のFUで始まり、Eビットが1のFUで終わる場合、順番に連結すると、断片化されたNALユニットのペイロードを再構築できます。断片化されたNALユニットのNALユニットヘッダーは、FUペイロード自体には含まれていませんが、断片化されたNALユニットのNALユニットヘッダーの情報は、FUペイロードヘッダーのF、LayerId、およびTIDフィールドで伝達されますFUおよびFUのFUヘッダーのFuTypeフィールド。 FUペイロードを空にすることはできません。
If an FU is lost, the receiver SHOULD discard all following fragmentation units in transmission order corresponding to the same fragmented NAL unit, unless the decoder in the receiver is known to be prepared to gracefully handle incomplete NAL units.
FUが失われた場合、受信機のデコーダーが不完全なNALユニットを適切に処理する準備ができていることがわかっている場合を除き、受信機は、同じ断片化されたNALユニットに対応する送信順にすべての後続の断片化ユニットを破棄する必要があります。
A receiver in an endpoint or in a MANE MAY aggregate the first n-1 fragments of a NAL unit to an (incomplete) NAL unit, even if fragment n of that NAL unit is not received. In this case, the forbidden_zero_bit of the NAL unit MUST be set to 1 to indicate a syntax violation.
エンドポイントまたはMANEの受信者は、NALユニットのフラグメントnが受信されない場合でも、NALユニットの最初のn-1フラグメントを（不完全な）NALユニットに集約できます（MAY）。この場合、構文違反を示すために、NALユニットのforbidden_zero_bitを1に設定する必要があります。
This section specifies the PACI packet structure. The basic payload header specified in this memo is intentionally limited to the 16 bits of the NAL unit header so to keep the packetization overhead to a minimum. However, cases have been identified where it is advisable to include control information in an easily accessible position in the packet header, despite the additional overhead. One such control information is the TSCI as specified in Section 4.5. PACI packets carry this and future, similar structures.
このセクションでは、PACIパケット構造を指定します。このメモで指定された基本的なペイロードヘッダーは、パケット化のオーバーヘッドを最小限に抑えるために、意図的にNALユニットヘッダーの16ビットに制限されています。ただし、追加のオーバーヘッドがあるにもかかわらず、制御情報をパケットヘッダーの簡単にアクセスできる位置に含めることが推奨される場合が確認されています。そのような制御情報の1つは、セクション4.5で指定されているTSCIです。 PACIパケットは、これと同様の構造を持っています。
The PACI packet structure is based on a payload header extension mechanism that is generic and extensible to carry payload header extensions. In this section, the focus lies on the use within this specification. Section 4.4.4.2 provides guidance for the specification designers in how to employ the extension mechanism in future specifications.
PACIパケット構造は、ペイロードヘッダー拡張を伝送するために汎用的で拡張可能なペイロードヘッダー拡張メカニズムに基づいています。このセクションでは、この仕様内での使用に焦点を当てています。セクション4.4.4.2は、将来の仕様で拡張メカニズムを使用する方法について仕様設計者にガイダンスを提供します。
A PACI packet consists of a payload header (denoted as PayloadHdr), for which the structure follows what is described in Section 4.2. The payload header is followed by the fields A, cType, PHSsize, F[0..2], and Y.
PACIパケットはペイロードヘッダー（PayloadHdrと表記）で構成され、その構造はセクション4.2で説明されている構造に従います。ペイロードヘッダーの後には、フィールドA、cType、PHSsize、F [0..2]、およびYが続きます。
Figure 11 shows a PACI packet in compliance with this memo, i.e., without any extensions.
図11は、このメモに準拠した（つまり、拡張なしの）PACIパケットを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header Extension Structure (PHES) |
|=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=|
| |
| PACI payload: NAL unit |
| . . . |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The Structure of a PACI
図11：PACIの構造
The fields in the payload header are set as follows. The F bit MUST be equal to 0. The Type field MUST be equal to 50. The value of LayerId MUST be a copy of the LayerId field of the PACI payload NAL unit or NAL-unit-like structure. The value of TID MUST be a copy of the TID field of the PACI payload NAL unit or NAL-unit-like structure.
ペイロードヘッダーのフィールドは次のように設定されます。 Fビットは0に等しくなければなりません。タイプフィールドは50に等しくなければなりません。LayerIdの値は、PACIペイロードNALユニットまたはNALユニットのような構造のLayerIdフィールドのコピーでなければなりません。 TIDの値は、PACIペイロードのNALユニットまたはNALユニットのような構造のTIDフィールドのコピーである必要があります。
The semantics of other fields are as follows:
他のフィールドのセマンティクスは次のとおりです。
A: 1 bit Copy of the F bit of the PACI payload NAL unit or NAL-unit-like structure.
A：PACIペイロードのNALユニットまたはNALユニットのような構造のFビットの1ビットコピー。
cType: 6 bits Copy of the Type field of the PACI payload NAL unit or NAL-unit-like structure.
cType：6ビットPACIペイロードのNALユニットまたはNALユニットのような構造のTypeフィールドのコピー。
PHSsize: 5 bits Indicates the length of the PHES field. The value is limited to be less than or equal to 32 octets, to simplify encoder design for MTU size matching.
PHSsize：5ビットPHESフィールドの長さを示します。値は32オクテット以下に制限され、MTUサイズマッチングのエンコーダー設計を簡素化します。
F0: This field equal to 1 specifies the presence of a temporal scalability support extension in the PHES.
F0：このフィールドは1で、PHESに一時的なスケーラビリティサポート拡張が存在することを示します。
F1, F2: MUST be 0, available for future extensions, see Section 4.4.4.2. Receivers compliant with this version of the HEVC payload format MUST ignore F1=1 and/or F2=1, and also ignore any information in the PHES indicated as present by F1=1 and/or F2=1.
F1、F2：0である必要があり、将来の拡張で利用可能です。セクション4.4.4.2を参照してください。このバージョンのHEVCペイロード形式に準拠するレシーバーは、F1 = 1やF2 = 1を無視しなければならず、また、F1 = 1やF2 = 1によって存在することが示されているPHES内の情報も無視しなければなりません。
Informative note: The receiver can do that by first decoding information associated with F0=1, and then skipping over any remaining bytes of the PHES based on the value of PHSsize.
参考情報：受信機は、最初にF0 = 1に関連付けられた情報をデコードし、次にPHSsizeの値に基づいてPHESの残りのバイトをスキップすることで、これを行うことができます。
Y: 1 bit MUST be 0, available for future extensions, see Section 4.4.4.2. Receivers compliant with this version of the HEVC payload format MUST ignore Y=1, and also ignore any information in the PHES indicated as present by Y.
Y：1ビットは0でなければならない（MUST）。将来の拡張で利用可能。セクション4.4.4.2を参照。このバージョンのHEVCペイロード形式に準拠する受信者は、Y = 1を無視する必要があり、また、Yで示されているPHESの情報を無視する必要があります。
PHES: variable number of octets A variable number of octets as indicated by the value of PHSsize.
PHES：可変数のオクテットPHSsizeの値で示される可変数のオクテット。
PACI Payload: The single NAL unit packet or NAL-unit-like structure (such as: FU or AP) to be carried, not including the first two octets.
PACIペイロード：最初の2つのオクテットを含まない、運ばれる単一のNALユニットパケットまたはNALユニットのような構造（FUまたはAPなど）。
Informative note: The first two octets of the NAL unit or NAL-unit-like structure carried in the PACI payload are not included in the PACI payload. Rather, the respective values are copied in locations of the PayloadHdr of the RTP packet. This design offers two advantages: first, the overall structure of the payload header is preserved, i.e., there is no special case of payload header structure that needs to be implemented for PACI. Second, no additional overhead is introduced.
参考情報：PACIペイロードで運ばれるNALユニットまたはNALユニットのような構造の最初の2つのオクテットは、PACIペイロードに含まれていません。むしろ、それぞれの値はRTPパケットのPayloadHdrの場所にコピーされます。この設計には2つの利点があります。1つ目は、ペイロードヘッダーの全体的な構造が保持されることです。つまり、PACIに実装する必要のあるペイロードヘッダー構造の特別なケースはありません。次に、追加のオーバーヘッドが発生しません。
A PACI payload MAY be a single NAL unit, an FU, or an AP. PACIs MUST NOT be fragmented or aggregated. The following subsection documents the reasons for these design choices.
PACIペイロードは、単一のNALユニット、FU、またはAPの場合があります。 PACIはフラグメント化または集約してはなりません。次のサブセクションでは、これらの設計を選択する理由について説明します。
A PACI cannot be fragmented. If a PACI could be fragmented, and a fragment other than the first fragment got lost, access to the information in the PACI would not be possible. Therefore, a PACI must not be fragmented. In other words, an FU must not carry (fragments of) a PACI.
PACIはフラグメント化できません。 PACIがフラグメント化され、最初のフラグメント以外のフラグメントが失われた場合、PACI内の情報へのアクセスは不可能になります。したがって、PACIはフラグメント化しないでください。言い換えれば、FUはPACI（のフラグメント）を運んではなりません。
A PACI cannot be aggregated. Aggregation of PACIs is inadvisable from a compression viewpoint, as, in many cases, several to be aggregated NAL units would share identical PACI fields and values which would be carried redundantly for no reason. Most, if not all, of the practical effects of PACI aggregation can be achieved by aggregating NAL units and bundling them with a PACI (see below). Therefore, a PACI must not be aggregated. In other words, an AP must not contain a PACI.
PACIは集約できません。多くの場合、集約されるNALユニットのいくつかは、理由もなく冗長に運ばれる同一のPACIフィールドと値を共有するため、PACIの集約は圧縮の観点からはお勧めできません。すべてではないにしても、PACI集約の実際的な効果のほとんどは、NALユニットを集約し、PACIにバンドルすることで実現できます（以下を参照）。したがって、PACIは集約しないでください。つまり、APにPACIを含めることはできません。
The payload of a PACI can be a fragment. Both middleboxes and sending systems with inflexible (often hardware-based) encoders occasionally find themselves in situations where a PACI and its headers, combined, are larger than the MTU size. In such a scenario, the middlebox or sender can fragment the NAL unit and encapsulate the fragment in a PACI. Doing so preserves the payload header extension information for all fragments, allowing downstream middleboxes and the receiver to take advantage of that information. Therefore, a sender may place a fragment into a PACI, and a receiver must be able to handle such a PACI.
PACIのペイロードはフラグメントにすることができます。ミドルボックスと柔軟性のない（多くの場合ハードウェアベースの）エンコーダーを備えた送信システムは、PACIとそのヘッダーを組み合わせたものがMTUサイズよりも大きい状況で時々自分自身を見つけます。このようなシナリオでは、ミドルボックスまたは送信者がNALユニットをフラグメント化し、フラグメントをPACIにカプセル化できます。これにより、すべてのフラグメントのペイロードヘッダー拡張情報が保持され、ダウンストリームミドルボックスと受信者がその情報を利用できるようになります。したがって、送信側はフラグメントをPACIに配置し、受信側はそのようなPACIを処理できる必要があります。
The payload of a PACI can be an aggregation NAL unit. HEVC bitstreams can contain unevenly sized and/or small (when compared to the MTU size) NAL units. In order to efficiently packetize such small NAL units, APs were introduced. The benefits of APs are independent from the need for a payload header extension. Therefore, a sender may place an AP into a PACI, and a receiver must be able to handle such a PACI.
PACIのペイロードは、集約NALユニットにすることができます。 HEVCビットストリームには、不均一なサイズや小さい（MTUサイズと比較した場合）NALユニットを含めることができます。このような小さなNALユニットを効率的にパケット化するために、APが導入されました。 APの利点は、ペイロードヘッダー拡張の必要性から独立しています。したがって、送信側はAPをPACIに配置でき、受信側はそのようなPACIを処理できる必要があります。
This section includes recommendations for future specification designers on how to extent the PACI syntax to accommodate future extensions. Obviously, designers are free to specify whatever appears to be appropriate to them at the time of their design. However, a lot of thought has been invested into the extension mechanism described below, and we suggest that deviations from it warrant a good explanation.
このセクションには、将来の拡張に対応するためにPACI構文を拡張する方法に関する将来の仕様設計者向けの推奨事項が含まれています。明らかに、設計者は、設計時に適切と思われるものを自由に指定できます。ただし、以下に説明する拡張メカニズムには多くの考えが投資されており、それからの逸脱は良い説明に値するはずです。
This memo defines only a single payload header extension (TSCI, described in Section 4.5); therefore, only the F0 bit carries semantics. F1 and F2 are already named (and not just marked as reserved, as a typical video spec designer would do). They are intended to signal two additional extensions. The Y bit allows one to, recursively, add further F and Y bits to extend the mechanism beyond three possible payload header extensions. It is suggested to define a new packet type (using a different value for Type) when assigning the F1, F2, or Y bits different semantics than what is suggested below.
このメモは、単一のペイロードヘッダー拡張（セクション4.5で説明するTSCI）のみを定義します。したがって、F0ビットのみがセマンティクスを伝達します。 F1とF2はすでに名前が付けられています（通常のビデオ仕様設計者が行うように、予約済みとしてマークされているだけではありません）。これらは、2つの追加の拡張機能を通知することを目的としています。 Yビットを使用すると、FビットとYビットを再帰的に追加して、3つの可能なペイロードヘッダー拡張を超えてメカニズムを拡張できます。 F1、F2、またはYビットに以下で提案されているものとは異なるセマンティクスを割り当てるときは、（Typeに異なる値を使用して）新しいパケットタイプを定義することをお勧めします。
When a Y bit is set, an 8-bit flag-extension is inserted after the Y bit. A flag-extension consists of 7 flags F[n..n+6], and another Y bit.
Yビットが設定されると、8ビットのフラグ拡張がYビットの後に挿入されます。フラグ拡張は、7つのフラグF [n..n + 6]と別のYビットで構成されます。
The basic PACI header already includes F0, F1, and F2. Therefore, the Fx bits in the first flag-extensions are numbered F3, F4, ..., F9; the F bits in the second flag-extension are numbered F10, F11, ..., F16, and so forth. As a result, at least three Fx bits are always in the PACI, but the number of Fx bits (and associated types of extensions) can be increased by setting the next Y bit and adding an octet of flag-extensions, carrying seven flags and another Y bit. The size of this list of flags is subject to the limits specified in Section 4.4.4 (32 octets for all flag-extensions and the PHES information combined).
基本的なPACIヘッダーには、すでにF0、F1、およびF2が含まれています。したがって、最初のフラグ拡張のFxビットにはF3、F4、...、F9の番号が付けられます。 2番目のフラグ拡張のFビットには、F10、F11、...、F16などの番号が付けられます。その結果、少なくとも3つのFxビットが常にPACIにありますが、次のYビットを設定し、フラグ拡張のオクテットを追加して、7つのフラグを持ち、Fxビット（および関連する拡張のタイプ）を増やすことができます。別のYビット。このフラグのリストのサイズは、セクション4.4.4で指定された制限に従います（すべてのフラグ拡張とPHES情報を合わせた32オクテット）。
Each of the F bits can indicate either the presence or the absence of certain information in the Payload Header Extension Structure (PHES).
各Fビットは、ペイロードヘッダー拡張構造（PHES）内の特定の情報の有無を示します。
When a spec developer devises a new syntax that takes advantage of the PACI extension mechanism, he/she must follow the constraints listed below; otherwise, the extension mechanism may break.
仕様開発者がPACI拡張メカニズムを利用する新しい構文を考案する場合、仕様開発者は以下にリストする制約に従う必要があります。そうしないと、拡張メカニズムが壊れる可能性があります。
1) The fields added for a particular Fx bit MUST be fixed in length and not depend on what other Fx bits are set (no parsing dependency).
1）特定のFxビットに追加されたフィールドは、長さが固定されていなければならず、他のFxビットが設定されているかどうかに依存しない（解析依存性がない）。
2) The Fx bits must be assigned in order.
2）Fxビットは順番に割り当てる必要があります。
3) An implementation that supports the n-th Fn bit for any value of n must understand the syntax (though not necessarily the semantics) of the fields Fk (with k < n), so as to be able to either use those bits when present, or at least be able to skip over them.
3）nの任意の値に対してn番目のFnビットをサポートする実装は、フィールドFk（k <n）の構文（必ずしもセマンティクスではない）を理解する必要があります。これにより、これらのビットを使用できるようになります。現在、または少なくともそれらをスキップできます。
This section describes the single payload header extension defined in this specification, known as TSCI. If, in the future, additional payload header extensions become necessary, they could be specified in this section of an updated version of this document, or in their own documents.
このセクションでは、TSCIと呼ばれる、この仕様で定義されている単一のペイロードヘッダー拡張について説明します。将来、追加のペイロードヘッダー拡張が必要になった場合は、このドキュメントの更新されたバージョンのこのセクションまたは独自のドキュメントで指定できます。
When F0 is set to 1 in a PACI, this specifies that the PHES field includes the TSCI fields TL0PICIDX, IrapPicID, S, and E as follows:
PACIでF0が1に設定されている場合、これはPHESフィールドにTSCIフィールドTL0PICIDX、IrapPicID、S、およびEが含まれることを次のように指定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TL0PICIDX | IrapPicID |S|E| RES | |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| .... |
| PACI payload: NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Structure of a PACI with a PHES Containing a TSCI
図12：TSCIを含むPHESを備えたPACIの構造
TL0PICIDX (8 bits) When present, the TL0PICIDX field MUST be set to equal to temporal_sub_layer_zero_idx as specified in Section D.3.22 of [HEVC] for the access unit containing the NAL unit in the PACI.
TL0PICIDX（8ビット）存在する場合、PAC0のNALユニットを含むアクセスユニットの[HEVC]のセクションD.3.22で指定されているように、TL0PICIDXフィールドをtemporary_sub_layer_zero_idxに設定する必要があります。
IrapPicID (8 bits) When present, the IrapPicID field MUST be set to equal to irap_pic_id as specified in Section D.3.22 of [HEVC] for the access unit containing the NAL unit in the PACI.
IrapPicID（8ビット）存在する場合、PACIのNALユニットを含むアクセスユニットの[HEVC]のセクションD.3.22で指定されているように、IrapPicIDフィールドをirap_pic_idに等しく設定する必要があります。
S (1 bit) The S bit MUST be set to 1 if any of the following conditions is true and MUST be set to 0 otherwise:
S（1ビット）以下の条件のいずれかに該当する場合はSビットを1に設定する必要があり、そうでない場合は0に設定する必要があります。
o The NAL unit in the payload of the PACI is the first VCL NAL unit, in decoding order, of a picture.
o PACIのペイロード内のNALユニットは、ピクチャのデコード順で最初のVCL NALユニットです。
o The NAL unit in the payload of the PACI is an AP, and the NAL unit in the first contained aggregation unit is the first VCL NAL unit, in decoding order, of a picture.
o PACIのペイロード内のNALユニットはAPであり、最初に含まれる集約ユニット内のNALユニットは、ピクチャのデコード順で最初のVCL NALユニットです。
o The NAL unit in the payload of the PACI is an FU with its S bit equal to 1 and the FU payload containing a fragment of the first VCL NAL unit, in decoding order, of a picture.
o PACIのペイロード内のNALユニットは、Sビットが1のFUであり、FUペイロードは、ピクチャの最初のVCL NALユニットのフラグメントをデコード順に含みます。
E (1 bit) The E bit MUST be set to 1 if any of the following conditions is true and MUST be set to 0 otherwise:
E（1ビット）以下の条件のいずれかに該当する場合はEビットを1に設定する必要があり、そうでない場合は0に設定する必要があります。
o The NAL unit in the payload of the PACI is the last VCL NAL unit, in decoding order, of a picture.
o PACIのペイロードのNALユニットは、ピクチャのデコード順で最後のVCL NALユニットです。
o The NAL unit in the payload of the PACI is an AP and the NAL unit in the last contained aggregation unit is the last VCL NAL unit, in decoding order, of a picture.
o PACIのペイロード内のNALユニットはAPであり、最後に含まれる集約ユニット内のNALユニットは、ピクチャのデコード順で最後のVCL NALユニットです。
o The NAL unit in the payload of the PACI is an FU with its E bit equal to 1 and the FU payload containing a fragment of the last VCL NAL unit, in decoding order, of a picture.
o PACIのペイロードのNALユニットは、Eビットが1のFUであり、FUペイロードは、ピクチャの最後のVCL NALユニットのフラグメントをデコード順に含みます。
RES (6 bits) MUST be equal to 0. Reserved for future extensions.
RES（6ビット）は0に等しくなければなりません。将来の拡張のために予約されています。
The value of PHSsize MUST be set to 3. Receivers MUST allow other values of the fields F0, F1, F2, Y, and PHSsize, and MUST ignore any additional fields, when present, than specified above in the PHES.
PHSsizeの値は3に設定する必要があります。受信者は、フィールドF0、F1、F2、Y、およびPHSsizeの他の値を許可する必要があり、PHESで上記で指定した追加のフィールドが存在する場合、それを無視する必要があります。
For each NAL unit, the variable AbsDon is derived, representing the decoding order number that is indicative of the NAL unit decoding order.
各NALユニットについて、変数AbsDonが導出され、NALユニットのデコード順を示すデコード順番号を表します。
Let NAL unit n be the n-th NAL unit in transmission order within an RTP stream.
NALユニットnを、RTPストリーム内の送信順序のn番目のNALユニットとします。
If sprop-max-don-diff is equal to 0 for all the RTP streams carrying the HEVC bitstream, AbsDon[n], the value of AbsDon for NAL unit n, is derived as equal to n.
HEVCビットストリームを運ぶすべてのRTPストリームのsprop-max-don-diffが0に等しい場合、NALユニットnのAbsDonの値であるAbsDon [n]は、nに等しいと導出されます。
Otherwise (sprop-max-don-diff is greater than 0 for any of the RTP streams), AbsDon[n] is derived as follows, where DON[n] is the value of the variable DON for NAL unit n:
それ以外の場合（sprop-max-don-diffは、どのRTPストリームでも0より大きい）、AbsDon [n]は次のように導出されます。DON[n]は、NALユニットnの変数DONの値です。
o If n is equal to 0 (i.e., NAL unit n is the very first NAL unit in transmission order), AbsDon[0] is set equal to DON[0].
o nが0に等しい場合（つまり、NALユニットnが送信順序の最初のNALユニットである場合）、AbsDon [0]はDON [0]に等しく設定されます。
o Otherwise (n is greater than 0), the following applies for derivation of AbsDon[n]:
o それ以外の場合（nは0より大きい）、AbsDon [n]の導出には以下が適用されます。
If DON[n] == DON[n-1], AbsDon[n] = AbsDon[n-1]
DON [n] == DON [n-1]の場合、AbsDon [n] = AbsDon [n-1]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] < 32768),
AbsDon[n] = AbsDon[n-1] + DON[n] - DON[n-1]
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] >= 32768),
AbsDon[n] = AbsDon[n-1] + 65536 - DON[n-1] + DON[n]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] >= 32768),
AbsDon[n] = AbsDon[n-1] - (DON[n-1] + 65536 -
DON[n])
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] < 32768),
AbsDon[n] = AbsDon[n-1] - (DON[n-1] - DON[n])
For any two NAL units m and n, the following applies:
2つのNALユニットmとnには、以下が適用されます。
o AbsDon[n] greater than AbsDon[m] indicates that NAL unit n follows NAL unit m in NAL unit decoding order.
o AbsDon [n]がAbsDon [m]より大きい場合、NALユニットnは、NALユニットのデコード順でNALユニットmの後に続きます。
o When AbsDon[n] is equal to AbsDon[m], the NAL unit decoding order of the two NAL units can be in either order.
o AbsDon [n]がAbsDon [m]と等しい場合、2つのNALユニットのNALユニットのデコード順序はどちらの順序でもかまいません。
o AbsDon[n] less than AbsDon[m] indicates that NAL unit n precedes NAL unit m in decoding order.
o AbsDon [n]がAbsDon [m]より小さい場合は、NALユニットnがデコード順にNALユニットmの前にあることを示します。
Informative note: When two consecutive NAL units in the NAL unit decoding order have different values of AbsDon, the absolute difference between the two AbsDon values may be greater than or equal to 1.
参考情報：NALユニットのデコード順で2つの連続するNALユニットのAbsDonの値が異なる場合、2つのAbsDon値の絶対差が1以上になる場合があります。
Informative note: There are multiple reasons to allow for the absolute difference of the values of AbsDon for two consecutive NAL units in the NAL unit decoding order to be greater than one. An increment by one is not required, as at the time of associating values of AbsDon to NAL units, it may not be known whether all NAL units are to be delivered to the receiver. For example, a gateway may not forward VCL NAL units of higher sub-layers or some SEI NAL units when there is congestion in the network. In another example, the first intra-coded picture of a pre-encoded clip is transmitted in advance to ensure that it is readily available in the receiver, and when transmitting the first intra-coded picture, the originator does not exactly know how many NAL units will be encoded before the first intra-coded picture of the pre-encoded clip follows in decoding order. Thus, the values of AbsDon for the NAL units of the first intra-coded picture of the pre-encoded clip have to be estimated when they are transmitted, and gaps in values of AbsDon may occur. Another example is MRST or MRMT with sprop-max-don-diff greater than 0, where the AbsDon values must indicate cross-layer decoding order for NAL units conveyed in all the RTP streams.
参考情報：NALユニットのデコード順で2つの連続するNALユニットのAbsDonの値の絶対差が1より大きくなる理由はいくつかあります。 AbsDonの値をNALユニットに関連付けるときに、すべてのNALユニットが受信側に配信されるかどうかがわからない場合があるため、1ずつインクリメントする必要はありません。たとえば、ネットワークで輻輳が発生している場合、ゲートウェイは上位サブレイヤーのVCL NALユニットや一部のSEI NALユニットを転送しない場合があります。別の例では、事前にエンコードされたクリップの最初のイントラコード化された画像が事前に送信され、受信機ですぐに利用できることを保証します。最初のイントラコード化された画像を送信するとき、発信者はNALの数を正確に知りません。ユニットは、事前にエンコードされたクリップの最初のイントラコード化された画像がデコード順に続く前にエンコードされます。したがって、事前符号化されたクリップの最初のイントラ符号化画像のNALユニットのAbsDonの値は、送信時に推定する必要があり、AbsDonの値にギャップが生じる可能性があります。別の例は、sprop-max-don-diffが0より大きいMRSTまたはMRMTです。AbsDon値は、すべてのRTPストリームで伝達されるNALユニットのクロスレイヤーデコード順序を示す必要があります。
The following packetization rules apply:
次のパケット化ルールが適用されます。
o If sprop-max-don-diff is greater than 0 for any of the RTP streams, the transmission order of NAL units carried in the RTP stream MAY be different than the NAL unit decoding order and the NAL unit output order. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the transmission order of NAL units carried in the RTP stream MUST be the same as the NAL unit decoding order and, when tx-mode is equal to "MRST" or "MRMT", MUST also be the same as the NAL unit output order.
o sprop-max-don-diffがいずれかのRTPストリームで0より大きい場合、RTPストリームで運ばれるNALユニットの送信順序は、NALユニットのデコード順およびNALユニットの出力順とは異なる場合があります。それ以外の場合（すべてのRTPストリームでsprop-max-don-diffが0に等しい）、RTPストリームで運ばれるNALユニットの送信順序は、NALユニットのデコード順序と同じでなければならず、tx-modeが「MRST」または「MRMT」もNALユニットの出力順序と同じでなければなりません。
o A NAL unit of a small size SHOULD be encapsulated in an aggregation packet together with one or more other NAL units in order to avoid the unnecessary packetization overhead for small NAL units. For example, non-VCL NAL units such as access unit delimiters, parameter sets, or SEI NAL units are typically small and can often be aggregated with VCL NAL units without violating MTU size constraints.
o 小さいNALユニットの不要なパケット化オーバーヘッドを回避するために、小さいサイズのNALユニットは、1つ以上の他のNALユニットとともに集約パケットにカプセル化する必要があります（SHOULD）。たとえば、アクセスユニットデリミタ、パラメータセット、SEI NALユニットなどの非VCL NALユニットは一般的に小さく、MTUサイズの制約に違反することなく、VCL NALユニットと集約することができます。
o Each non-VCL NAL unit SHOULD, when possible from an MTU size match viewpoint, be encapsulated in an aggregation packet together with its associated VCL NAL unit, as typically a non-VCL NAL unit would be meaningless without the associated VCL NAL unit being available.
o 通常、非VCL NALユニットは、MTUサイズの一致の観点から可能な場合、関連するVCL NALユニットと一緒に集約パケットにカプセル化する必要があります。通常、非VCL NALユニットは、関連するVCL NALユニットがないと意味がないためです。 。
o For carrying exactly one NAL unit in an RTP packet, a single NAL unit packet MUST be used.
o RTPパケットで1つのNALユニットを伝送するには、単一のNALユニットパケットを使用する必要があります。
The general concept behind de-packetization is to get the NAL units out of the RTP packets in an RTP stream and all RTP streams the RTP stream depends on, if any, and pass them to the decoder in the NAL unit decoding order.
パケット化解除の背後にある一般的な概念は、RTPストリームと、RTPストリームが依存するすべてのRTPストリームのRTPパケットからNALユニットを取り出し、NALユニットのデコード順序でそれらをデコーダーに渡すことです。
The de-packetization process is implementation dependent. Therefore, the following description should be seen as an example of a suitable implementation. Other schemes may be used as well, as long as the output for the same input is the same as the process described below. The output is the same when the set of output NAL units and their order are both identical. Optimizations relative to the described algorithms are possible.
パケット化解除プロセスは実装に依存します。したがって、以下の説明は適切な実装の例と見なされます。同じ入力の出力が以下で説明するプロセスと同じである限り、他のスキームも使用できます。出力は、出力NALユニットのセットとその順序が両方とも同じ場合に同じです。説明されているアルゴリズムに関連する最適化が可能です。
All normal RTP mechanisms related to buffer management apply. In particular, duplicated or outdated RTP packets (as indicated by the RTP sequences number and the RTP timestamp) are removed. To determine the exact time for decoding, factors such as a possible intentional delay to allow for proper inter-stream synchronization must be factored in.
バッファ管理に関連するすべての通常のRTPメカニズムが適用されます。特に、重複または古いRTPパケット（RTPシーケンス番号とRTPタイムスタンプで示される）は削除されます。デコードの正確な時間を決定するには、適切なストリーム間同期を可能にする意図的な遅延などの要因を考慮に入れる必要があります。
NAL units with NAL unit type values in the range of 0 to 47, inclusive, may be passed to the decoder. NAL-unit-like structures with NAL unit type values in the range of 48 to 63, inclusive, MUST NOT be passed to the decoder.
NALユニットタイプの値が0〜47の範囲のNALユニットは、デコーダーに渡されます。 48から63までの範囲のNALユニットタイプ値を持つNALユニットのような構造は、デコーダーに渡してはなりません（MUST NOT）。
The receiver includes a receiver buffer, which is used to compensate for transmission delay jitter within individual RTP streams and across RTP streams, to reorder NAL units from transmission order to the NAL unit decoding order, and to recover the NAL unit decoding order in MRST or MRMT, when applicable. In this section, the receiver operation is described under the assumption that there is no transmission delay jitter within an RTP stream and across RTP streams. To make a difference from a practical receiver buffer that is also used for compensation of transmission delay jitter, the receiver buffer is hereafter called the de-packetization buffer in this section. Receivers should also prepare for transmission delay jitter; that is, either reserve separate buffers for transmission delay jitter buffering and de-packetization buffering or use a receiver buffer for both transmission delay jitter and de-packetization. Moreover, receivers should take transmission delay jitter into account in the buffering operation, e.g., by additional initial buffering before starting of decoding and playback.
レシーバーには、個々のRTPストリーム内およびRTPストリーム全体の伝送遅延ジッターを補償し、NALユニットを伝送順序からNALユニットのデコード順序に並べ替え、MRSTまたはMRMT（該当する場合）。このセクションでは、RTPストリーム内およびRTPストリーム間で伝送遅延ジッターがないことを前提として、レシーバーの動作について説明します。伝送遅延ジッターの補償にも使用される実際のレシーバーバッファーとの違いを作るために、このセクションでは、レシーバーバッファーをデパケット化バッファーと呼びます。受信機は、伝送遅延ジッターにも備える必要があります。つまり、伝送遅延ジッターバッファリングとデパケット化バッファリング用に個別のバッファーを予約するか、伝送遅延ジッターとデパケット化の両方にレシーバーバッファーを使用します。さらに、受信機は、例えば、復号化および再生を開始する前に、追加の初期バッファリングによって、バッファリング操作において伝送遅延ジッタを考慮に入れるべきである。
When sprop-max-don-diff is equal to 0 for all the received RTP streams, the de-packetization buffer size is zero bytes, and the process described in the remainder of this paragraph applies. When there is only one RTP stream received, the NAL units carried in the single RTP stream are directly passed to the decoder in their transmission order, which is identical to their decoding order. When there is more than one RTP stream received, the NAL units carried in the multiple RTP streams are passed to the decoder in their NTP timestamp order. When there are several NAL units of different RTP streams with the same NTP timestamp, the order to pass them to the decoder is their dependency order, where NAL units of a dependee RTP stream are passed to the decoder prior to the NAL units of the dependent RTP stream. When there are several NAL units of the same RTP stream with the same NTP timestamp, the order to pass them to the decoder is their transmission order.
受信したすべてのRTPストリームのsprop-max-don-diffが0の場合、パケット化解除バッファーのサイズは0バイトであり、この段落の残りの部分で説明するプロセスが適用されます。受信したRTPストリームが1つしかない場合、単一のRTPストリームで運ばれるNALユニットは、送信順序で直接デコーダーに渡されます。送信順序は、デコード順序と同じです。複数のRTPストリームが受信されると、複数のRTPストリームで運ばれるNALユニットは、NTPタイムスタンプ順にデコーダーに渡されます。同じNTPタイムスタンプを持つ異なるRTPストリームのNALユニットがいくつかある場合、それらをデコーダーに渡す順序は依存関係の順序であり、依存するRTPストリームのNALユニットは依存するNALユニットの前にデコーダーに渡されます。 RTPストリーム。同じNTPタイムスタンプを持つ同じRTPストリームのNALユニットがいくつかある場合、それらをデコーダーに渡す順序は送信順序です。
Informative note: The mapping between RTP and NTP timestamps is conveyed in RTCP SR packets. In addition, the mechanisms for faster media timestamp synchronization discussed in [RFC6051] may be used to speed up the acquisition of the RTP-to-wall-clock mapping.
参考情報：RTPとNTPタイムスタンプ間のマッピングは、RTCP SRパケットで伝達されます。さらに、[RFC6051]で説明されているより高速なメディアタイムスタンプ同期のメカニズムを使用して、RTPと壁時計のマッピングの取得を高速化できます。
When sprop-max-don-diff is greater than 0 for any the received RTP streams, the process described in the remainder of this section applies.
受信したRTPストリームのsprop-max-don-diffが0より大きい場合、このセクションの残りの部分で説明するプロセスが適用されます。
There are two buffering states in the receiver: initial buffering and buffering while playing. Initial buffering starts when the reception is initialized. After initial buffering, decoding and playback are started, and the buffering-while-playing mode is used.
レシーバーには2つのバッファリング状態があります。初期バッファリングと再生中のバッファリングです。受信が初期化されると、初期バッファリングが開始されます。初期バッファリングの後、デコードと再生が開始され、再生中バッファリングモードが使用されます。
Regardless of the buffering state, the receiver stores incoming NAL units, in reception order, into the de-packetization buffer. NAL units carried in RTP packets are stored in the de-packetization buffer individually, and the value of AbsDon is calculated and stored for each NAL unit. When MRST or MRMT is in use, NAL units of all RTP streams of a bitstream are stored in the same de-packetization buffer. When NAL units carried in any two RTP streams are available to be placed into the de-packetization buffer, those NAL units carried in the RTP stream that is lower in the dependency tree are placed into the buffer first. For example, if RTP stream A depends on RTP stream B, then NAL units carried in RTP stream B are placed into the buffer first.
バッファリング状態に関係なく、受信機は着信NALユニットを受信順にデパケット化バッファに格納します。 RTPパケットで運ばれるNALユニットは、個別にデパケタイズバッファーに格納され、NALユニットごとにAbsDonの値が計算されて格納されます。 MRSTまたはMRMTが使用されている場合、ビットストリームのすべてのRTPストリームのNALユニットは、同じ非パケット化バッファーに格納されます。任意の2つのRTPストリームで運ばれるNALユニットをデパケタイズバッファーに配置できる場合、依存関係ツリーの下位にあるRTPストリームで運ばれるNALユニットが最初にバッファーに配置されます。たとえば、RTPストリームAがRTPストリームBに依存している場合、RTPストリームBで運ばれるNALユニットが最初にバッファに配置されます。
Initial buffering lasts until condition A (the difference between the greatest and smallest AbsDon values of the NAL units in the de-packetization buffer is greater than or equal to the value of sprop-max-don-diff of the highest RTP stream) or condition B (the number of NAL units in the de-packetization buffer is greater than the value of sprop-depack-buf-nalus) is true.
初期バッファリングは、条件A（非パケット化バッファー内のNALユニットの最大と最小のAbsDon値の差が、最高のRTPストリームのsprop-max-don-diffの値以上になる）または条件まで継続します。 B（パケット化解除バッファー内のNALユニットの数がsprop-depack-buf-nalusの値より大きい）はtrueです。
After initial buffering, whenever condition A or condition B is true, the following operation is repeatedly applied until both condition A and condition B become false:
初期バッファリング後、条件Aまたは条件Bがtrueの場合は常に、条件Aと条件Bの両方がfalseになるまで次の操作が繰り返し適用されます。
o The NAL unit in the de-packetization buffer with the smallest value of AbsDon is removed from the de-packetization buffer and passed to the decoder.
o AbsDonの最小値を持つ非パケット化バッファー内のNALユニットは、非パケット化バッファーから削除され、デコーダーに渡されます。
When no more NAL units are flowing into the de-packetization buffer, all NAL units remaining in the de-packetization buffer are removed from the buffer and passed to the decoder in the order of increasing AbsDon values.
パケット化解除バッファーに流入するNALユニットがなくなると、パケット化解除バッファーに残っているすべてのNALユニットがバッファーから削除され、AbsDon値の増加順にデコーダーに渡されます。
This section specifies the parameters that MAY be used to select optional features of the payload format and certain features or properties of the bitstream or the RTP stream. The parameters are specified here as part of the media type registration for the HEVC codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use SDP.
このセクションでは、ペイロード形式のオプション機能とビットストリームまたはRTPストリームの特定の機能またはプロパティを選択するために使用できるパラメータを指定します。パラメータは、HEVCコーデックのメディアタイプ登録の一部としてここで指定されます。 SDPを使用するアプリケーションでは、セッション記述プロトコル（SDP）[RFC4566]へのパラメーターのマッピングも提供されます。 SDPを使用しない制御プロトコルで使用するために、同等のパラメーターを他の場所で定義できます。
The media subtype for the HEVC codec is allocated from the IETF tree.
HEVCコーデックのメディアサブタイプは、IETFツリーから割り当てられます。
The receiver MUST ignore any unrecognized parameter.
レシーバーは、認識されないパラメーターを無視する必要があります。
Type name: video
タイプ名：ビデオ
Subtype name: H265
サブタイプ名：H265
Required parameters: none
必須パラメーター：なし
OPTIONAL parameters:
オプションのパラメーター：
profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id:
profile-space、tier-flag、profile-id、profile-compatibility-indicator、interop-constraints、およびlevel-id：
These parameters indicate the profile, tier, default level, and some constraints of the bitstream carried by the RTP stream and all RTP streams the RTP stream depends on, or a specific set of the profile, tier, default level, and some constraints the receiver supports.
これらのパラメーターは、プロファイル、階層、デフォルトレベル、およびRTPストリームとRTPストリームが依存するすべてのRTPストリームによって運ばれるビットストリームのいくつかの制約、またはプロファイル、階層、デフォルトレベルの特定のセット、およびレシーバーのいくつかの制約を示しますサポートしています。
The profile and some constraints are indicated collectively by profile-space, profile-id, profile-compatibility-indicator, and interop-constraints. The profile specifies the subset of coding tools that may have been used to generate the bitstream or that the receiver supports.
プロファイルと一部の制約は、profile-space、profile-id、profile-compatibility-indicator、およびinterop-constraintsによってまとめて示されます。プロファイルは、ビットストリームを生成するために使用された、またはレシーバーがサポートするコーディングツールのサブセットを指定します。
Informative note: There are 32 values of profile-id, and there are 32 flags in profile-compatibility-indicator, each flag corresponding to one value of profile-id. According to HEVC version 1 in [HEVC], when more than one of the 32 flags is set for a bitstream, the bitstream would comply with all the profiles corresponding to the set flags. However, in a draft of HEVC version 2 in [HEVCv2], Subclause A.3.5, 19 Format Range Extensions profiles have been specified, all using the same value of profile-id (4), differentiated by some of the 48 bits in interop-constraints; this (rather unexpected way of profile signaling) means that one of the 32 flags may correspond to multiple profiles. To be able to support whatever HEVC extension profile that might be specified and indicated using profile-space, profile-id, profile-compatibility-indicator, and interop-constraints in the future, it would be safe to require symmetric use of these parameters in SDP offer/answer unless recv-sub-layer-id is included in the SDP answer for choosing one of the sub-layers offered.
参考情報：profile-idには32個の値があり、profile-compatibility-indicatorには32個のフラグがあり、各フラグはprofile-idの1つの値に対応しています。 [HEVC]のHEVCバージョン1によれば、ビットストリームに32個のフラグの2つ以上が設定されている場合、ビットストリームは設定されたフラグに対応するすべてのプロファイルに準拠します。ただし、[HEVCv2]のHEVCバージョン2のドラフトでは、副次句A.3.5、19のフォーマット範囲拡張プロファイルが指定されており、すべて相互運用の48ビットの一部で区別された、profile-id（4）の同じ値を使用しています。 -制約;これは（プロファイルシグナリングの予期しない方法です）、32のフラグの1つが複数のプロファイルに対応している可能性があります。今後、profile-space、profile-id、profile-compatibility-indicator、およびinterop-constraintsを使用して指定および示される可能性のあるすべてのHEVC拡張プロファイルをサポートできるようにするには、これらのパラメーターを対称的に使用する必要があります。提供されるサブレイヤーの1つを選択するためのSDP回答にrecv-sub-layer-idが含まれていない限り、SDPオファー/回答。
The tier is indicated by tier-flag. The default level is indicated by level-id. The tier and the default level specify the limits on values of syntax elements or arithmetic combinations of values of syntax elements that are followed when generating the bitstream or that the receiver supports.
層は、層フラグによって示されます。デフォルトのレベルはlevel-idで示されます。層とデフォルトレベルは、ビットストリームの生成時に適用される、またはレシーバーがサポートする構文要素の値または構文要素の値の算術組み合わせの制限を指定します。
A set of profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id parameters ptlA is said to be consistent with another set of these parameters ptlB if any decoder that conforms to the profile, tier, level, and constraints indicated by ptlB can decode any bitstream that conforms to the profile, tier, level, and constraints indicated by ptlA.
プロファイルスペース、階層フラグ、プロファイルID、プロファイル互換性インジケータ、相互運用制約、およびレベルIDパラメータのセットptlAは、 ptlBによって示されるプロファイル、層、レベル、および制約は、ptlAによって示されるプロファイル、層、レベル、および制約に準拠するビットストリームをデコードできます。
In SDP offer/answer, when the SDP answer does not include the recv-sub-layer-id parameter that is less than the sprop-sub-layer-id parameter in the SDP offer, the following applies:
SDPオファー/アンサーでは、SDPオファーのsprop-sub-layer-idパラメーターよりも小さいrecv-sub-layer-idパラメーターがSDPアンサーに含まれていない場合、以下が適用されます。
o The profile-space, tier-flag, profile-id, profile-compatibility-indicator, and interop-constraints parameters MUST be used symmetrically, i.e., the value of each of these parameters in the offer MUST be the same as that in the answer, either explicitly signaled or implicitly inferred.
o profile-space、tier-flag、profile-id、profile-compatibility-indicator、interop-constraintsパラメータは対称的に使用する必要があります。つまり、オファー内のこれらの各パラメータの値は、回答の値と同じでなければなりません、明示的に通知されるか、暗黙的に推測されます。
o The level-id parameter is changeable as long as the highest level indicated by the answer is either equal to or lower than that in the offer. Note that the highest level is indicated by level-id and max-recv-level-id together.
o level-idパラメータは、回答で示される最高レベルがオファー内のレベル以下である限り、変更可能です。最高レベルはlevel-idとmax-recv-level-idの両方で示されることに注意してください。
In SDP offer/answer, when the SDP answer does include the recv-sub-layer-id parameter that is less than the sprop-sub-layer-id parameter in the SDP offer, the set of profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id parameters included in the answer MUST be consistent with that for the chosen sub-layer representation as indicated in the SDP offer, with the exception that the level-id parameter in the SDP answer is changeable as long as the highest level indicated by the answer is either lower than or equal to that in the offer.
SDPオファー/アンサーでは、SDPオファーにSDPオファーのsprop-sub-layer-idパラメーターより小さいrecv-sub-layer-idパラメーターが含まれている場合、一連のプロファイルスペース、階層フラグ、回答に含まれるprofile-id、profile-compatibility-indicator、interop-constraints、およびlevel-idパラメータは、SDPオファーに示されているように、選択されたサブレイヤ表現のパラメータと一致している必要があります。ただし、level-id SDP回答のパラメーターは、回答で示された最高レベルがオファーのレベル以下である限り、変更可能です。
More specifications of these parameters, including how they relate to the values of the profile, tier, and level syntax elements specified in [HEVC] are provided below.
[HEVC]で指定されたプロファイル、階層、およびレベルの構文要素の値との関係を含む、これらのパラメーターの詳細な仕様を以下に示します。
profile-space, profile-id:
プロファイルスペース、プロファイルID：
The value of profile-space MUST be in the range of 0 to 3, inclusive. The value of profile-id MUST be in the range of 0 to 31, inclusive.
profile-spaceの値は、0〜3の範囲でなければなりません。 profile-idの値は、0から31までの範囲でなければなりません。
When profile-space is not present, a value of 0 MUST be inferred. When profile-id is not present, a value of 1 (i.e., the Main profile) MUST be inferred.
profile-spaceが存在しない場合、値0を推測する必要があります。 profile-idが存在しない場合、値1（つまり、メインプロファイル）を推測する必要があります。
When used to indicate properties of a bitstream, profile-space and profile-id are derived from the profile, tier, and level syntax elements in SPS or VPS NAL units as follows, where general_profile_space, general_profile_idc, sub_layer_profile_space[j], and sub_layer_profile_idc[j] are specified in [HEVC]:
ビットストリームのプロパティを示すために使用される場合、profile-spaceおよびprofile-idは、SPSまたはVPS NALユニットのプロファイル、階層、およびレベルの構文要素から次のように導出されます。ここで、general_profile_space、general_profile_idc、sub_layer_profile_space [j]、およびsub_layer_profile_idc [ j]は[HEVC]で指定されています：
If the RTP stream is the highest RTP stream, the following applies:
RTPストリームが最上位のRTPストリームである場合、以下が適用されます。
o profile-space = general_profile_space o profile-id = general_profile_idc
o profile-space = general_profile_space o profile-id = general_profile_idc
Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub-layer-id parameter:
それ以外の場合（RTPストリームは依存先のRTPストリームです）、jがsprop-sub-layer-idパラメーターの値である場合、以下が適用されます。
o profile-space = sub_layer_profile_space[j] o profile-id = sub_layer_profile_idc[j]
o profile-space = sub_layer_profile_space [j] o profile-id = sub_layer_profile_idc [j]
tier-flag, level-id:
ティアフラグ、レベルID：
The value of tier-flag MUST be in the range of 0 to 1, inclusive. The value of level-id MUST be in the range of 0 to 255, inclusive.
tier-flagの値は、0から1の範囲である必要があります。 level-idの値は、0から255の範囲である必要があります。
If the tier-flag and level-id parameters are used to indicate properties of a bitstream, they indicate the tier and the highest level the bitstream complies with.
tier-flagおよびlevel-idパラメータを使用してビットストリームのプロパティを示す場合、それらはビットストリームが準拠するティアおよび最高レベルを示します。
If the tier-flag and level-id parameters are used for capability exchange, the following applies. If max-recv-level-id is not present, the default level defined by level-id indicates the highest level the codec wishes to support. Otherwise, max-recv-level-id 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.
tier-flagおよびlevel-idパラメータが機能交換に使用される場合、以下が適用されます。 max-recv-level-idが存在しない場合、level-idで定義されたデフォルトのレベルは、コーデックがサポートしたい最高レベルを示します。それ以外の場合、max-recv-level-idは、コーデックが受信用にサポートする最高レベルを示します。受信または送信のいずれの場合も、サポートされる最高レベルよりも低いすべてのレベルもサポートする必要があります。
If no tier-flag is present, a value of 0 MUST be inferred; if no level-id is present, a value of 93 (i.e., level 3.1) MUST be inferred.
層フラグが存在しない場合は、値0を推測する必要があります。 level-idが存在しない場合、93（つまり、レベル3.1）の値を推測する必要があります。
When used to indicate properties of a bitstream, the tier-flag and level-id parameters are derived from the profile, tier, and level syntax elements in SPS or VPS NAL units as follows, where general_tier_flag, general_level_idc, sub_layer_tier_flag[j], and sub_layer_level_idc[j] are specified in [HEVC]:
ビットストリームのプロパティを示すために使用される場合、tier-flagパラメータとlevel-idパラメータは、SPSまたはVPS NALユニットのプロファイル、ティア、およびレベル構文要素から次のように導出されます。ここで、general_tier_flag、general_level_idc、sub_layer_tier_flag [j]、およびsub_layer_level_idc [j]は[HEVC]で指定されます：
If the RTP stream is the highest RTP stream, the following applies:
RTPストリームが最上位のRTPストリームである場合、以下が適用されます。
o tier-flag = general_tier_flag o level-id = general_level_idc Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub-layer-id parameter:
o tier-flag = general_tier_flag o level-id = general_level_idcそれ以外の場合（RTPストリームは依存先RTPストリームです）、jはsprop-sub-layer-idパラメーターの値で、次のように適用されます。
o tier-flag = sub_layer_tier_flag[j] o level-id = sub_layer_level_idc[j]
o tier-flag = sub_layer_tier_flag [j] o level-id = sub_layer_level_idc [j]
interop-constraints:
相互運用制約：
A base16 [RFC4648] (hexadecimal) representation of six bytes of data, consisting of progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, and reserved_zero_44bits.
6バイトのデータのbase16 [RFC4648]（16進数）表現。progressive_source_flag、interlaced_source_flag、non_packed_constraint_flag、frame_only_constraint_flag、reserved_zero_44bitsで構成されます。
If the interop-constraints parameter is not present, the following MUST be inferred:
interop-constraintsパラメータが存在しない場合は、以下を推測する必要があります。
o progressive_source_flag = 1 o interlaced_source_flag = 0 o non_packed_constraint_flag = 1 o frame_only_constraint_flag = 1 o reserved_zero_44bits = 0
o Progress_source_flag = 1 o interlaced_source_flag = 0 o non_packed_constraint_flag = 1 o frame_only_constraint_flag = 1 o reserved_zero_44bits = 0
When the interop-constraints parameter is used to indicate properties of a bitstream, the following applies, where general_progressive_source_flag, general_interlaced_source_flag, general_non_packed_constraint_flag, general_non_packed_constraint_flag, general_frame_only_constraint_flag, general_reserved_zero_44bits, sub_layer_progressive_source_flag[j], sub_layer_interlaced_source_flag[j], sub_layer_non_packed_constraint_flag[j], sub_layer_frame_only_constraint_flag[j], and sub_layer_reserved_zero_44bits[j] are specified in [HEVC]:
ビットストリームの性質を示すために使用されるパラメータの場合相互運用-制約、以下が適用され、general_progressive_source_flag、general_interlaced_source_flag、general_non_packed_constraint_flag、general_non_packed_constraint_flag、general_frame_only_constraint_flag、general_reserved_zero_44bits、sub_layer_progressive_source_flag [J]、sub_layer_interlaced_source_flag [J]、sub_layer_non_packed_constraint_flag [J]、sub_layer_frame_only_constraint_flag [J ]、およびsub_layer_reserved_zero_44bits [j]が[HEVC]で指定されています。
If the RTP stream is the highest RTP stream, the following applies:
RTPストリームが最上位のRTPストリームである場合、以下が適用されます。
o progressive_source_flag = general_progressive_source_flag
o Progress_source_flag = general_progressive_source_flag
o interlaced_source_flag = general_interlaced_source_flag
o interlaced_source_flag = general_interlaced_source_flag
o non_packed_constraint_flag = general_non_packed_constraint_flag
o non_packed_constraint_flag = general_non_packed_constraint_flag
o frame_only_constraint_flag = general_frame_only_constraint_flag
o frame_only_constraint_flag = general_frame_only_constraint_flag
o reserved_zero_44bits = general_reserved_zero_44bits
o reserved_zero_44bits = general_reserved_zero_44bits
Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub-layer-id parameter:
それ以外の場合（RTPストリームは依存先のRTPストリームです）、jがsprop-sub-layer-idパラメーターの値である場合、以下が適用されます。
o progressive_source_flag = sub_layer_progressive_source_flag[j]
o Progress_source_flag = sub_layer_progressive_source_flag [j]
o interlaced_source_flag = sub_layer_interlaced_source_flag[j]
o interlaced_source_flag = sub_layer_interlaced_source_flag [j]
o non_packed_constraint_flag = sub_layer_non_packed_constraint_flag[j]
o non_packed_constraint_flag = sub_layer_non_packed_constraint_flag [j]
o frame_only_constraint_flag = sub_layer_frame_only_constraint_flag[j]
o frame_only_constraint_flag = sub_layer_frame_only_constraint_flag [j]
o reserved_zero_44bits = sub_layer_reserved_zero_44bits[j]
o reserved_zero_44bits = sub_layer_reserved_zero_44bits [j]
Using interop-constraints for capability exchange results in a requirement on any bitstream to be compliant with the interop-constraints.
機能交換に相互運用制約を使用すると、ビットストリームが相互運用制約に準拠する必要があります。
profile-compatibility-indicator:
プロファイル互換性インジケータ：
A base16 [RFC4648] representation of four bytes of data.
4バイトのデータのbase16 [RFC4648]表現。
When profile-compatibility-indicator is used to indicate properties of a bitstream, the following applies, where general_profile_compatibility_flag[j] and sub_layer_profile_compatibility_flag[i][j] are specified in [HEVC]:
profile-compatibility-indicatorを使用してビットストリームのプロパティを示す場合、以下が適用されます。ここで、general_profile_compatibility_flag [j]およびsub_layer_profile_compatibility_flag [i] [j]は[HEVC]で指定されます。
The profile-compatibility-indicator in this case indicates additional profiles to the profile defined by profile-space, profile-id, and interop-constraints the bitstream conforms to. A decoder that conforms to any of all the profiles the bitstream conforms to would be capable of decoding the bitstream. These additional profiles are defined by profile-space, each set bit of profile-compatibility-indicator, and interop-constraints.
この場合のprofile-compatibility-indicatorは、ビットストリームが準拠するprofile-space、profile-id、およびinterop-constraintsによって定義されたプロファイルへの追加のプロファイルを示します。ビットストリームが準拠するすべてのプロファイルのいずれかに準拠するデコーダは、ビットストリームをデコードできます。これらの追加プロファイルは、profile-space、profile-compatibility-indicatorの各セットビット、および相互運用制約によって定義されます。
If the RTP stream is the highest RTP stream, the following applies for each value of j in the range of 0 to 31, inclusive:
RTPストリームが最高のRTPストリームである場合、0から31までの範囲のjの各値に以下が適用されます。
o bit j of profile-compatibility-indicator = general_profile_compatibility_flag[j]
o プロファイル互換性インジケーターのビットj = general_profile_compatibility_flag [j]
Otherwise (the RTP stream is a dependee RTP stream), the following applies for i equal to sprop-sub-layer-id and for each value of j in the range of 0 to 31, inclusive:
それ以外の場合（RTPストリームは依存RTPストリームです）、sprop-sub-layer-idに等しいiと、0から31までの範囲のjの各値に以下が適用されます。
o bit j of profile-compatibility-indicator = sub_layer_profile_compatibility_flag[i][j]
o プロファイル互換性インジケータのビットj = sub_layer_profile_compatibility_flag [i] [j]
Using profile-compatibility-indicator for capability exchange results in a requirement on any bitstream to be compliant with the profile-compatibility-indicator. This is intended to handle cases where any future HEVC profile is defined as an intersection of two or more profiles.
機能交換にprofile-compatibility-indicatorを使用すると、ビットストリームがprofile-compatibility-indicatorに準拠する必要があります。これは、将来のHEVCプロファイルが2つ以上のプロファイルの共通部分として定義されているケースを処理することを目的としています。
If this parameter is not present, this parameter defaults to the following: bit j, with j equal to profile-id, of profile-compatibility-indicator is inferred to be equal to 1, and all other bits are inferred to be equal to 0.
このパラメーターが存在しない場合、このパラメーターはデフォルトで次のようになります。profile-compatibility-indicatorのビットj（jはprofile-idと等しい）は1と推定され、他のすべてのビットは0と推定されます。 。
sprop-sub-layer-id:
sprop-sub-layer-id：
This parameter MAY be used to indicate the highest allowed value of TID in the bitstream. When not present, the value of sprop-sub-layer-id is inferred to be equal to 6.
このパラメータは、ビットストリーム内のTIDの最大許容値を示すために使用される場合があります。存在しない場合、sprop-sub-layer-idの値は6と推定されます。
The value of sprop-sub-layer-id MUST be in the range of 0 to 6, inclusive.
sprop-sub-layer-idの値は、0〜6の範囲でなければなりません。
recv-sub-layer-id:
recv-sub-layer-id：
This parameter MAY be used to signal a receiver's choice of the offered or declared sub-layer representations in the sprop-vps. The value of recv-sub-layer-id indicates the TID of the highest sub-layer of the bitstream that a receiver supports. When not present, the value of recv-sub-layer-id is inferred to be equal to the value of the sprop-sub-layer-id parameter in the SDP offer.
このパラメーターは、sprop-vpsで提供または宣言されたサブレイヤー表現の受信者の選択を通知するために使用できます。 recv-sub-layer-idの値は、レシーバーがサポートするビットストリームの最上位のサブレイヤーのTIDを示します。存在しない場合、recv-sub-layer-idの値は、SDPオファーのsprop-sub-layer-idパラメータの値と等しいと推測されます。
The value of recv-sub-layer-id MUST be in the range of 0 to 6, inclusive.
recv-sub-layer-idの値は、0〜6の範囲でなければなりません。
max-recv-level-id:
max-recv-level-id：
This parameter MAY be used to indicate the highest level a receiver supports. The highest level the receiver supports is equal to the value of max-recv-level-id divided by 30.
このパラメータは、レシーバがサポートする最高レベルを示すために使用される場合があります。レシーバーがサポートする最高レベルは、max-recv-level-idを30で割った値と同じです。
The value of max-recv-level-id MUST be in the range of 0 to 255, inclusive.
max-recv-level-idの値は、0から255までの範囲でなければなりません。
When max-recv-level-id is not present, the value is inferred to be equal to level-id.
max-recv-level-idが存在しない場合、値はlevel-idと等しいと推測されます。
max-recv-level-id MUST NOT be present when the highest level the receiver supports is not higher than the default level.
max-recv-level-idは、レシーバーがサポートする最高レベルがデフォルトレベルよりも高くない場合に存在してはなりません（MUST NOT）。
tx-mode:
tx-mode：
This parameter indicates whether the transmission mode is SRST, MRST, or MRMT.
このパラメーターは、伝送モードがSRST、MRST、またはMRMTのいずれであるかを示します。
The value of tx-mode MUST be equal to "SRST", "MRST" or "MRMT". When not present, the value of tx-mode is inferred to be equal to "SRST".
tx-modeの値は、「SRST」、「MRST」、または「MRMT」に等しくなければなりません。存在しない場合、tx-modeの値は「SRST」に等しいと推測されます。
If the value is equal to "MRST", MRST MUST be in use. Otherwise, if the value is equal to "MRMT", MRMT MUST be in use. Otherwise (the value is equal to "SRST"), SRST MUST be in use.
値が「MRST」と等しい場合、MRSTを使用する必要があります。それ以外の場合、値が「MRMT」に等しい場合、MRMTを使用する必要があります。それ以外の場合（値は「SRST」に等しい）、SRSTを使用する必要があります。
The value of tx-mode MUST be equal to "MRST" for all RTP streams in an MRST.
tx-modeの値は、MRST内のすべてのRTPストリームの「MRST」に等しい必要があります。
The value of tx-mode MUST be equal to "MRMT" for all RTP streams in an MRMT.
MRMT内のすべてのRTPストリームのtx-modeの値は「MRMT」に等しくなければなりません。
sprop-vps:
sprop-vps：
This parameter MAY be used to convey any video parameter set NAL unit of the bitstream for out-of-band transmission of video parameter sets. The parameter MAY also be used for capability exchange and to indicate sub-stream characteristics (i.e., properties of sub-layer representations as defined in [HEVC]). The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of the video parameter set NAL units as specified in Section 7.3.2.1 of [HEVC].
このパラメータは、ビデオパラメータセットの帯域外送信用のビットストリームのビデオパラメータセットNALユニットを伝達するために使用できます。パラメータは、機能交換とサブストリーム特性（つまり、[HEVC]で定義されているサブレイヤー表現のプロパティ）を示すためにも使用できます（MAY）。パラメータの値は、[HEVC]のセクション7.3.2.1で指定されているように、ビデオパラメータセットNALユニットのbase64 [RFC4648]表現のカンマ区切り（ '、'）リストです。
The sprop-vps parameter MAY contain one or more than one video parameter set NAL unit. However, all other video parameter sets contained in the sprop-vps parameter MUST be consistent with the first video parameter set in the sprop-vps parameter. A video parameter set vpsB is said to be consistent with another video parameter set vpsA if any decoder that conforms to the profile, tier, level, and constraints indicated by the 12 bytes of data starting from the syntax element general_profile_space to the syntax element general_level_idc, inclusive, in the first profile_tier_level( ) syntax structure in vpsA can decode any bitstream that conforms to the profile, tier, level, and constraints indicated by the 12 bytes of data starting from the syntax element general_profile_space to the syntax element general_level_idc, inclusive, in the first profile_tier_level( ) syntax structure in vpsB.
sprop-vpsパラメータには、1つまたは複数のビデオパラメータセットのNALユニットを含めることができます（MAY）。ただし、sprop-vpsパラメータに含まれる他のすべてのビデオパラメータセットは、sprop-vpsパラメータの最初のビデオパラメータセットと一致している必要があります。構文要素general_profile_spaceから構文要素general_level_idcまでの12バイトのデータによって示されるプロファイル、階層、レベル、および制約に準拠するデコーダーがある場合、ビデオパラメーターセットvpsBは別のビデオパラメーターセットvpsAと一致すると言われます。包括的、最初のprofile_tier_level()で、vpsAの構文構造は、構文要素general_profile_spaceから構文要素general_level_idcまでの12バイトのデータによって示されるプロファイル、階層、レベル、および制約に準拠するビットストリームをデコードできます。 vpsBの最初のprofile_tier_level()構文構造。
sprop-sps:
sprop-sps：
This parameter MAY be used to convey sequence parameter set NAL units of the bitstream for out-of-band transmission of sequence parameter sets. The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of the sequence parameter set NAL units as specified in Section 7.3.2.2 of [HEVC].
このパラメータは、シーケンスパラメータセットの帯域外送信用のビットストリームのシーケンスパラメータセットNALユニットを伝達するために使用できます。パラメータの値は、[HEVC]のセクション7.3.2.2で指定されているように、シーケンスパラメータセットNALユニットのbase64 [RFC4648]表現のコンマ区切り（ '、'）リストです。
sprop-pps:
sprop-pps：
This parameter MAY be used to convey picture parameter set NAL units of the bitstream for out-of-band transmission of picture parameter sets. The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of the picture parameter set NAL units as specified in Section 7.3.2.3 of [HEVC].
このパラメータは、画像パラメータセットの帯域外送信用のビットストリームの画像パラメータセットNALユニットを伝達するために使用できます。パラメータの値は、[HEVC]のセクション7.3.2.3で指定されているように、ピクチャパラメータセットのNALユニットのbase64 [RFC4648]表現のコンマ区切り（ '、'）リストです。
sprop-sei:
ｓｐろｐーせい：
This parameter MAY be used to convey one or more SEI messages that describe bitstream characteristics. When present, a decoder can rely on the bitstream characteristics that are described in the SEI messages for the entire duration of the session, independently from the persistence scopes of the SEI messages as specified in [HEVC].
このパラメータは、ビットストリームの特性を説明する1つ以上のSEIメッセージを伝達するために使用される場合があります。存在する場合、デコーダーは、[HEVC]で指定されているSEIメッセージの永続性スコープとは関係なく、セッションの全期間にわたってSEIメッセージに記述されているビットストリーム特性に依存できます。
The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of SEI NAL units as specified in Section 7.3.2.4 of [HEVC].
[HEVC]のセクション7.3.2.4で指定されているように、パラメーターの値は、SEI NALユニットのbase64 [RFC4648]表現のコンマ区切り（ '、'）リストです。
Informative note: Intentionally, no list of applicable or inapplicable SEI messages is specified here. Conveying certain SEI messages in sprop-sei may be sensible in some application scenarios and meaningless in others. However, a few examples are described below:
参考情報：意図的に、適用可能なまたは適用不可能なSEIメッセージのリストはここでは指定されていません。特定のSEIメッセージをsprop-seiで伝達することは、一部のアプリケーションシナリオでは賢明であり、他のシナリオでは意味がない場合があります。ただし、以下にいくつかの例を示します。
1) In an environment where the bitstream was created from film-based source material, and no splicing is going to occur during the lifetime of the session, the film grain characteristics SEI message or the tone mapping information SEI message are likely meaningful, and sending them in sprop-sei rather than in the bitstream at each entry point may help with saving bits and allows one to configure the renderer only once, avoiding unwanted artifacts.
1）ビットストリームがフィルムベースのソースマテリアルから作成され、セッションの存続期間中にスプライシングが発生しない環境では、フィルムグレイン特性SEIメッセージまたはトーンマッピング情報SEIメッセージはおそらく意味があり、送信します。各エントリポイントのビットストリームではなくsprop-seiでそれらを使用すると、ビットの節約に役立ち、レンダラーを1回だけ構成して、不要なアーティファクトを回避できます。
2) The structure of pictures information SEI message in sprop-sei can be used to inform a decoder of information on the NAL unit types, picture-order count values, and prediction dependencies of a sequence of pictures. Having such knowledge can be helpful for error recovery.
2）sprop-seiの画像情報SEIメッセージの構造を使用して、NALユニットタイプ、画像順序カウント値、および画像シーケンスの予測依存性に関する情報をデコーダーに通知できます。このような知識があると、エラー回復に役立ちます。
3) Examples for SEI messages that would be meaningless to be conveyed in sprop-sei include the decoded picture hash SEI message (it is close to impossible that all decoded pictures have the same hashtag), the display orientation SEI message when the device is a handheld device (as the display orientation may change when the handheld device is turned around), or the filler payload SEI message (as there is no point in just having more bits in SDP).
3）sprop-seiで伝達しても意味のないSEIメッセージの例には、デコードされた画像ハッシュSEIメッセージ（すべてのデコードされた画像が同じハッシュタグを持つことはほぼ不可能）、デバイスがハンドヘルドデバイス（ハンドヘルドデバイスを裏返すと表示の向きが変わる可能性があるため）、またはフィラーペイロードSEIメッセージ（SDPのビット数を増やすだけでは意味がないため）。
max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc:
max-lsr、max-lps、max-cpb、max-dpb、max-br、max-tr、max-tc：
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 (specified by max-recv-level-id) MUST be the highest that the receiver is fully capable of supporting. max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc MAY be used to indicate capabilities of the receiver that extend the required capabilities of the highest level, as specified below.
これらのパラメータは、レシーバ実装の機能を通知するために使用される場合があります。これらのパラメーターを他の目的で使用してはなりません（MUST NOT）。最高レベル（max-recv-level-idで指定）は、レシーバーが完全にサポートできる最高レベルである必要があります。 max-lsr、max-lps、max-cpb、max-dpb、max-br、max-tr、max-tcを使用して、以下に指定するように、最高レベルの必要な機能を拡張する受信機の機能を示すことができます。 。
When more than one parameter from the set (max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc) is present, the receiver MUST support all signaled capabilities simultaneously. For example, if both max-lsr and max-br are present, the highest level with the extension of both the picture rate and bitrate is supported. That is, the receiver is able to decode bitstreams in which the luma sample rate is up to max-lsr (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 by max-recv-level-id.
セットから複数のパラメーター（max-lsr、max-lps、max-cpb、max-dpb、max-br、max-tr、max-tc）が存在する場合、受信機はすべての信号機能を同時にサポートする必要があります。たとえば、max-lsrとmax-brの両方が存在する場合、ピクチャレートとビットレートの両方を拡張した最高レベルがサポートされます。つまり、受信機は、ルーマのサンプルレートがmax-lsr（両端を含む）まで、ビットレートがmax-br（両端を含む）までのビットストリームをデコードできます。以下のmax-brパラメータのほか、他のプロパティはmax-recv-level-idで指定された最高レベルに準拠しています。
Informative note: When the OPTIONAL media type parameters are used to signal the properties of a bitstream, and max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc are not present, the values of profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id must always be such that the bitstream complies fully with the specified profile, tier, and level.
参考情報：OPTIONALメディアタイプパラメーターを使用してビットストリームのプロパティを通知する場合、max-lsr、max-lps、max-cpb、max-dpb、max-br、max-tr、max-tcは存在する場合、profile-space、tier-flag、profile-id、profile-compatibility-indicator、interop-constraints、およびlevel-idの値は、ビットストリームが指定されたプロファイル、階層、およびレベルに完全に準拠するようにする必要があります。
max-lsr:
max-lsr：
The value of max-lsr is an integer indicating the maximum processing rate in units of luma samples per second. The max-lsr parameter signals that the receiver is capable of decoding video at a higher rate than is required by the highest level.
max-lsrの値は、1秒あたりの輝度サンプルの単位で最大処理速度を示す整数です。 max-lsrパラメータは、レシーバが最高レベルで必要とされるよりも高いレートでビデオをデコードできることを示します。
When max-lsr is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxLumaSR value in Table A-2 of [HEVC] for the highest level is replaced with the value of max-lsr. Senders MAY use this knowledge to send pictures of a given size at a higher picture rate than is indicated in the highest level.
max-lsrが通知されると、最高レベルの[HEVC]の表A-2のMaxLumaSR値がmax-の値で置き換えられることを除いて、受信機は最高レベルに準拠するビットストリームをデコードできる必要があります。 lsr。送信者は、この知識を使用して、特定のサイズの画像を最高レベルで示されているよりも高い画像レートで送信できます。
When not present, the value of max-lsr is inferred to be equal to the value of MaxLumaSR given in Table A-2 of [HEVC] for the highest level.
存在しない場合、max-lsrの値は、最高レベルの[HEVC]の表A-2に示されているMaxLumaSRの値に等しいと推測されます。
The value of max-lsr MUST be in the range of MaxLumaSR to 16 * MaxLumaSR, inclusive, where MaxLumaSR is given in Table A-2 of [HEVC] for the highest level.
max-lsrの値は、MaxLumaSRから16 * MaxLumaSR（両端を含む）の範囲内である必要があります。ここで、MaxLumaSRは、最高レベルの[HEVC]の表A-2に示されています。
max-lps:
max-lps：
The value of max-lps is an integer indicating the maximum picture size in units of luma samples. The max-lps parameter signals that the receiver is capable of decoding larger picture sizes than are required by the highest level. When max-lps is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxLumaPS value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-lps. Senders MAY use this knowledge to send larger pictures at a proportionally lower picture rate than is indicated in the highest level.
max-lpsの値は、最大サンプルサイズを輝度サンプルの単位で示す整数です。 max-lpsパラメータは、受信機が最高レベルで必要とされるよりも大きな画像サイズをデコードできることを示します。 max-lpsが通知されると、最高レベルの[HEVC]の表A-1のMaxLumaPS値がmax-の値に置き換えられることを除いて、受信機は最高レベルに準拠するビットストリームをデコードできる必要があります（MUST）。 lps。送信者は、この知識を使用して、最高レベルで示されているよりも比例して低い画像レートで大きな画像を送信できます。
When not present, the value of max-lps is inferred to be equal to the value of MaxLumaPS given in Table A-1 of [HEVC] for the highest level.
存在しない場合、max-lpsの値は、最高レベルの[HEVC]の表A-1に示されているMaxLumaPSの値に等しいと推測されます。
The value of max-lps MUST be in the range of MaxLumaPS to 16 * MaxLumaPS, inclusive, where MaxLumaPS is given in Table A-1 of [HEVC] for the highest level.
max-lpsの値は、MaxLumaPSから16 * MaxLumaPSまでの範囲内である必要があります。ここで、MaxLumaPSは、[HEVC]の表A-1に最高レベルとして示されています。
max-cpb:
max-cpb：
The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of CpbBrVclFactor bits for the VCL HRD parameters and in units of CpbBrNalFactor bits for the NAL HRD parameters, where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC]. The max-cpb parameter signals that the receiver has more memory than the minimum amount of coded picture buffer memory required by the highest level. When max-cpb is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxCPB value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-cpb. Senders MAY use this knowledge to construct coded bitstreams with greater variation of bitrate than can be achieved with the MaxCPB value in Table A-1 of [HEVC].
max-cpbの値は、VCL HRDパラメータの場合はCpbBrVclFactorビットの単位で、NAL HRDパラメータの場合はCpbBrNalFactorビットの単位で、最大の符号化画像バッファサイズを示す整数です。CpbBrVclFactorとCpbBrNalFactorは、セクションA.4で定義されています。 [HEVC]。 max-cpbパラメーターは、レシーバーに、最高レベルが必要とするコード化ピクチャバッファーメモリの最小量よりも多くのメモリがあることを示します。 max-cpbが通知されると、最高レベルの[HEVC]の表A-1のMaxCPB値がmax-の値に置き換えられることを除いて、受信機は最高レベルに準拠するビットストリームをデコードできる必要があります。 cpb。送信者は、この知識を使用して、[HEVC]の表A-1のMaxCPB値で達成できるよりも大きなビットレートのバリエーションを持つコード化ビットストリームを構築できます。
When not present, the value of max-cpb is inferred to be equal to the value of MaxCPB given in Table A-1 of [HEVC] for the highest level.
存在しない場合、max-cpbの値は、最高レベルの[HEVC]の表A-1に示されているMaxCPBの値と等しいと推測されます。
The value of max-cpb MUST be in the range of MaxCPB to 16 * MaxCPB, inclusive, where MaxLumaCPB is given in Table A-1 of [HEVC] for the highest level.
max-cpbの値は、MaxCPBから16 * MaxCPBまでの範囲内である必要があります。ここで、MaxLumaCPBは、最高レベルの[HEVC]の表A-1に示されています。
Informative note: The coded picture buffer is used in the hypothetical reference decoder (Annex C of [HEVC]). The use of the hypothetical reference decoder is recommended in HEVC 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-packetization and de-jitter buffers. The coded picture buffer need not be implemented in decoders as specified in Annex C of [HEVC], but rather standard-compliant decoders
参考情報：コーディングされた画像バッファーは、仮想参照デコーダー（[HEVC]の付録C）で使用されます。生成されたビットストリームが規格に準拠していることを確認し、出力ビットレートを制御するには、HEVCエンコーダーで仮想参照デコーダーを使用することをお勧めします。したがって、符号化された画像バッファは、概念的には、デパケット化バッファおよびデジッタバッファを含む、受信機内の他の潜在的なバッファから独立しています。 [HEVC]のAnnex Cで指定されているように、コード化された画像バッファーをデコーダーに実装する必要はなく、標準に準拠したデコーダー
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-packetization and de-jitter buffers of the receiver.
標準に準拠したビットストリームをデコードできるという条件で、バッファリングを構成できます。したがって、実際には、ビデオデコーダの入力バッファは、受信機のデパケット化およびデジッタバッファと統合することができます。
max-dpb:
max-dpb：
The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units decoded pictures at the MaxLumaPS for the highest level, i.e., the number of decoded pictures at the maximum picture size defined by the highest level. The value of max-dpb MUST be in the range of 1 to 16, respectively. The max-dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by default, which is MaxDpbPicBuf as defined in [HEVC] (equal to 6). When max-dpb is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxDpbPicBuff value defined in [HEVC] as 6 is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded pictures (MaxDpbSize) in its decoded picture buffer:
max-dpbの値は、最高レベルのMaxLumaPSでデコードされた画像の最大デコード単位を示す整数、つまり、最高レベルで定義された最大画像サイズでのデコードされた画像の数です。 max-dpbの値は、それぞれ1〜16の範囲でなければなりません。 max-dpbパラメータは、デフォルトで必要なデコード済み画像バッファメモリの最小量（[HEVC]で定義されているMaxDpbPicBuf）（6に等しい）よりも多くのメモリがレシーバにあることを示します。 max-dpbが通知されると、レシーバーは、[HEVC]で6として定義されているMaxDpbPicBuff値がmax-dpbの値で置き換えられることを除いて、最高レベルに準拠するビットストリームをデコードできる必要があります。したがって、max-dpbを通知するレシーバーは、次の数のデコードされた画像（MaxDpbSize）をデコードされた画像バッファーに格納できなければなりません（MUST）。
if( PicSizeInSamplesY <= ( MaxLumaPS >> 2 ) )
MaxDpbSize = Min( 4 * max-dpb, 16 )
else if ( PicSizeInSamplesY <= ( MaxLumaPS >> 1 ) )
MaxDpbSize = Min( 2 * max-dpb, 16 )
else if ( PicSizeInSamplesY <= ( ( 3 * MaxLumaPS ) >> 2
) )
MaxDpbSize = Min( (4 * max-dpb) / 3, 16 )
else
MaxDpbSize = max-dpb
Wherein MaxLumaPS given in Table A-1 of [HEVC] for the highest level and PicSizeInSamplesY is the current size of each decoded picture in units of luma samples as defined in [HEVC].
ここで、最高レベルの[HEVC]の表A-1に示されているMaxLumaPSとPicSizeInSamplesYは、[HEVC]で定義されているルーマサンプルの単位での各デコードされたピクチャの現在のサイズです。
The value of max-dpb MUST be greater than or equal to the value of MaxDpbPicBuf (i.e., 6) as defined in [HEVC]. Senders MAY use this knowledge to construct coded bitstreams with improved compression.
[HEVC]で定義されているように、max-dpbの値はMaxDpbPicBuf（つまり、6）の値以上でなければなりません（MUST）。送信者は、この知識を使用して、改善された圧縮でコード化されたビットストリームを構築できます。
When not present, the value of max-dpb is inferred to be equal to the value of MaxDpbPicBuf (i.e., 6) as defined in [HEVC].
存在しない場合、max-dpbの値は、[HEVC]で定義されているMaxDpbPicBuf（つまり6）の値と等しいと推測されます。
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-packetization and de-jitter buffers.
参考情報：このパラメータは、シグナリングゲートウェイの設計を容易にするために、主にITU-T勧告H.245の同様のコードポイントを補完するために追加されました。デコードされた画像バッファーは、再構成されたサンプルを格納します。デコードされたピクチャバッファのサイズとRTPで使用されるバッファ、特にデパケット化バッファとデジッタバッファのサイズには関係がありません。
max-br:
max-br：
The value of max-br is an integer indicating the maximum video bitrate in units of CpbBrVclFactor bits per second for the VCL HRD parameters and in units of CpbBrNalFactor bits per second for the NAL HRD parameters, where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC].
max-brの値は、VCL HRDパラメーターの場合はCpbBrVclFactorビット/秒の単位で、NAL HRDパラメーターの場合はCpbBrNalFactorビット/秒の単位で最大ビデオビットレートを示す整数です。CpbBrVclFactorとCpbBrNalFactorはセクションAで定義されています。 [HEVC]の4。
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 highest level.
max-brパラメーターは、レシーバーのビデオデコーダーが最高レベルで必要とされるよりも高いビットレートでビデオをデコードできることを示します。
When max-br is signaled, the video codec of the receiver MUST be able to decode bitstreams that conform to the highest level, with the following exceptions in the limits specified by the highest level:
max-brが通知された場合、レシーバーのビデオコーデックは、最高レベルに準拠するビットストリームをデコードできる必要があります。ただし、最高レベルで指定された制限内の次の例外があります。
o The value of max-br replaces the MaxBR value in Table A-2 of [HEVC] for the highest level.
o max-brの値は、最高レベルの[HEVC]の表A-2の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 [HEVC]:
o max-cpbパラメータが存在しない場合、次の式の結果が、[HEVC]の表A-1のMaxCPBの値を置き換えます。
(MaxCPB of the highest level) * max-br / (MaxBR of the highest level)
（最高レベルのMaxCPB）* max-br /（最高レベルのMaxBR）
For example, if a receiver signals capability for Main profile Level 2 with max-br equal to 2000, this indicates a maximum video bitrate of 2000 kbits/sec for VCL HRD parameters, a maximum video bitrate of 2200 kbits/sec for NAL HRD parameters, and a CPB size of 2000000 bits (2000000 / 1500000 * 1500000).
たとえば、レシーバーがメインプロファイルレベル2の機能を示し、max-brが2000の場合、これはVCL HRDパラメーターの最大ビデオビットレートが2000キロビット/秒、NAL HRDパラメーターの最大ビデオビットレートが2200キロビット/秒であることを示します。 、および2000000ビットのCPBサイズ（2000000/1500000 * 1500000）。
Senders MAY use this knowledge to send higher bitrate video as allowed in the level definition of Annex A of [HEVC] to achieve improved video quality.
送信者はこの知識を使用して、[HEVC]のAnnex Aのレベル定義で許可されているように、より高いビットレートのビデオを送信して、ビデオ品質を向上させることができます。
When not present, the value of max-br is inferred to be equal to the value of MaxBR given in Table A-2 of [HEVC] for the highest level.
存在しない場合、max-brの値は、最高レベルの[HEVC]の表A-2に示されているMaxBRの値に等しいと推測されます。
The value of max-br MUST be in the range of MaxBR to 16 * MaxBR, inclusive, where MaxBR is given in Table A-2 of [HEVC] for the highest level.
max-brの値は、MaxBRから16 * MaxBRまでの範囲でなければなりません。ここで、MaxBRは、最高レベルの[HEVC]の表A-2に示されています。
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の同様のコードポイントを補完するために追加されました。ネットワークがそのようなビットレートをいつでも処理できるという仮定は、このパラメーターの値から行うことはできません。特に、シグナリングされたビットレートが輻輳制御の制約下で可能であるという結論を出すことはできません。
max-tr:
max-tr：
The value of max-tr is an integer indication the maximum number of tile rows. The max-tr parameter signals that the receiver is capable of decoding video with a larger number of tile rows than the value allowed by the highest level.
max-trの値は、タイル行の最大数を示す整数です。 max-trパラメーターは、レシーバーが最高レベルで許可されている値よりも多くのタイル行を使用してビデオをデコードできることを示します。
When max-tr is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxTileRows value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-tr.
max-trが通知されると、レシーバーは、最高レベルの[HEVC]の表A-1のMaxTileRows値がmax-の値に置き換えられることを除いて、最高レベルに準拠するビットストリームをデコードできる必要があります。 tr。
Senders MAY use this knowledge to send pictures utilizing a larger number of tile rows than the value allowed by the highest level.
送信者は、この知識を使用して、最高レベルで許可されている値よりも多くのタイル行を使用して画像を送信できます。
When not present, the value of max-tr is inferred to be equal to the value of MaxTileRows given in Table A-1 of [HEVC] for the highest level.
存在しない場合、max-trの値は、最高レベルの[HEVC]の表A-1に示されているMaxTileRowsの値と等しいと推測されます。
The value of max-tr MUST be in the range of MaxTileRows to 16 * MaxTileRows, inclusive, where MaxTileRows is given in Table A-1 of [HEVC] for the highest level.
max-trの値は、MaxTileRowsから16 * MaxTileRows（両端を含む）の範囲でなければなりません。ここで、MaxTileRowsは、最高レベルの[HEVC]の表A-1に示されています。
max-tc:
max-tc：
The value of max-tc is an integer indication the maximum number of tile columns. The max-tc parameter signals that the receiver is capable of decoding video with a larger number of tile columns than the value allowed by the highest level.
max-tcの値は、タイル列の最大数を示す整数です。 max-tcパラメーターは、最高レベルで許可されている値よりも多くのタイル列を持つビデオをレシーバーがデコードできることを示します。
When max-tc is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxTileCols value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-tc.
max-tcが通知されると、レシーバーは、最高レベルの[HEVC]の表A-1のMaxTileCols値がmax-の値に置き換えられることを除いて、最高レベルに準拠するビットストリームをデコードできる必要があります。 tc。
Senders MAY use this knowledge to send pictures utilizing a larger number of tile columns than the value allowed by the highest level.
送信者は、この知識を使用して、最高レベルで許可されている値よりも多くのタイル列を使用して画像を送信できます。
When not present, the value of max-tc is inferred to be equal to the value of MaxTileCols given in Table A-1 of [HEVC] for the highest level.
存在しない場合、max-tcの値は、最高レベルの[HEVC]の表A-1に示されているMaxTileColsの値と等しいと推測されます。
The value of max-tc MUST be in the range of MaxTileCols to 16 * MaxTileCols, inclusive, where MaxTileCols is given in Table A-1 of [HEVC] for the highest level.
max-tcの値は、MaxTileColsから16 * MaxTileColsの範囲である必要があります。MaxTileColsは、最高レベルの[HEVC]の表A-1に示されています。
max-fps:
max-fps：
The value of max-fps is an integer indicating the maximum picture rate in units of pictures per 100 seconds that can be effectively processed by the receiver. The max-fps parameter MAY be used to signal that the receiver has a constraint in that it is not capable of processing video effectively at the full picture rate that is implied by the highest level and, when present, one or more of the parameters max-lsr, max-lps, and max-br.
max-fpsの値は、受信側で効果的に処理できる100秒あたりの画像を単位とする最大画像レートを示す整数です。 max-fpsパラメータを使用して、最高レベルによって示されるフルピクチャレートでビデオを効果的に処理できず、存在する場合は1つ以上のパラメータmax -lsr、max-lps、およびmax-br。
The value of max-fps is not necessarily the picture rate at which the maximum picture size can be sent, it constitutes a constraint on maximum picture rate for all resolutions.
max-fpsの値は、必ずしも最大画像サイズを送信できる画像レートではなく、すべての解像度の最大画像レートに対する制約になります。
Informative note: The max-fps parameter is semantically different from max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that max-fps is used to signal a constraint, lowering the maximum picture rate from what is implied by other parameters.
参考情報：max-fpsパラメータは、意味的にmax-lsr、max-lps、max-cpb、max-dpb、max-br、max-tr、max-tcとは異なり、max-fpsは制約、最大画像レートを他のパラメータによって暗示されるものから下げる。
The encoder MUST use a picture rate equal to or less than this value. In cases where the max-fps parameter is absent, the encoder is free to choose any picture rate according to the highest level and any signaled optional parameters.
エンコーダは、この値以下の画像レートを使用する必要があります。 max-fpsパラメーターが存在しない場合、エンコーダーは最高レベルと信号で送られたオプションのパラメーターに従って、任意の画像レートを自由に選択できます。
The value of max-fps MUST be smaller than or equal to the full picture rate that is implied by the highest level and, when present, one or more of the parameters max-lsr, max-lps, and max-br.
max-fpsの値は、最高レベルと、存在する場合は、パラメーターmax-lsr、max-lps、およびmax-brの1つ以上で示されるフルピクチャレート以下でなければなりません（MUST）。
sprop-max-don-diff:
sprop-max-don-diff：
If tx-mode is equal to "SRST" and there is no NAL unit naluA that is followed in transmission order by any NAL unit preceding naluA in decoding order (i.e., the transmission order of the NAL units is the same as the decoding order), the value of this parameter MUST be equal to 0.
tx-modeが "SRST"に等しく、NALユニットのnaluAが存在しない場合は、送信順でnaluAの前にあるNALユニットがデコード順で続きます（つまり、NALユニットの送信順はデコード順と同じです）。 、このパラメータの値は0でなければなりません。
Otherwise, if tx-mode is equal to "MRST" or "MRMT", the decoding order of the NAL units of all the RTP streams is the same as the NAL unit transmission order and the NAL unit output order, the value of this parameter MUST be equal to either 0 or 1.
それ以外の場合、tx-modeが「MRST」または「MRMT」に等しい場合、すべてのRTPストリームのNALユニットのデコード順は、NALユニットの送信順およびNALユニットの出力順と同じであり、このパラメーターの値0または1のいずれかに等しくなければなりません。
Otherwise, if tx-mode is equal to "MRST" or "MRMT" and the decoding order of the NAL units of all the RTP streams is the same as the NAL unit transmission order but not the same as the NAL unit output order, the value of this parameter MUST be equal to 1.
それ以外の場合、tx-modeが「MRST」または「MRMT」に等しく、すべてのRTPストリームのNALユニットのデコード順がNALユニットの送信順と同じですが、NALユニットの出力順とは異なります。このパラメーターの値は1に等しくなければなりません。
Otherwise, this parameter specifies the maximum absolute difference between the decoding order number (i.e., AbsDon) values of any two NAL units naluA and naluB, where naluA follows naluB in decoding order and precedes naluB in transmission order.
それ以外の場合、このパラメーターは、任意の2つのNALユニットnaluAとnaluBのデコード順序番号（つまり、AbsDon）値間の最大絶対差を指定します。
The value of sprop-max-don-diff MUST be an integer in the range of 0 to 32767, inclusive.
sprop-max-don-diffの値は、0〜32767の範囲の整数である必要があります。
When not present, the value of sprop-max-don-diff is inferred to be equal to 0.
存在しない場合、sprop-max-don-diffの値は0と推定されます。
sprop-depack-buf-nalus:
sprop-depack-buf-nalus;
This parameter specifies the maximum number of NAL units that precede a NAL unit in transmission order and follow the NAL unit in decoding order.
このパラメーターは、送信順にNALユニットの前にあり、デコード順にNALユニットに続くNALユニットの最大数を指定します。
The value of sprop-depack-buf-nalus MUST be an integer in the range of 0 to 32767, inclusive.
sprop-depack-buf-nalusの値は、0〜32767の範囲の整数である必要があります。
When not present, the value of sprop-depack-buf-nalus is inferred to be equal to 0.
存在しない場合、sprop-depack-buf-nalusの値は0と推定されます。
When sprop-max-don-diff is present and greater than 0, this parameter MUST be present and the value MUST be greater than 0.
sprop-max-don-diffが存在し、0より大きい場合、このパラメーターが存在しなければならず、値は0より大きい必要があります。
sprop-depack-buf-bytes:
sprop-depack-buf-bytes：
This parameter signals the required size of the de-packetization buffer in units of bytes. The value of the parameter MUST be greater than or equal to the maximum buffer occupancy (in units of bytes) of the de-packetization buffer as specified in Section 6.
このパラメータは、デパケット化バッファの必要なサイズをバイト単位で通知します。セクション6で指定されているように、パラメータの値は、パケット化解除バッファの最大バッファ占有率（バイト単位）以上でなければなりません（MUST）。
The value of sprop-depack-buf-bytes MUST be an integer in the range of 0 to 4294967295, inclusive.
sprop-depack-buf-bytesの値は、0〜4294967295の範囲の整数である必要があります。
When sprop-max-don-diff is present and greater than 0, this parameter MUST be present and the value MUST be greater than 0. When not present, the value of sprop-depack-buf-bytes is inferred to be equal to 0.
sprop-max-don-diffが存在し、0より大きい場合、このパラメーターが存在する必要があり、値は0より大きい必要があります。存在しない場合、sprop-depack-buf-bytesの値は0と推定されます。
Informative note: The value of sprop-depack-buf-bytes indicates the required size of the de-packetization buffer only. When network jitter can occur, an appropriately sized jitter buffer has to be available as well.
有益な注意：sprop-depack-buf-bytesの値は、パケット化解除バッファーの必要なサイズのみを示します。ネットワークジッタが発生する可能性がある場合は、適切なサイズのジッタバッファも使用できる必要があります。
depack-buf-cap:
depack-buf-cap：
This parameter signals the capabilities of a receiver implementation and indicates the amount of de-packetization buffer space in units of bytes that the receiver has available for reconstructing the NAL unit decoding order from NAL units carried in one or more RTP streams. A receiver is able to handle any RTP stream, and all RTP streams the RTP stream depends on, when present, for which the value of the sprop-depack-buf-bytes parameter is smaller than or equal to this parameter.
このパラメーターは、レシーバー実装の機能を示し、1つ以上のRTPストリームで運ばれるNALユニットからNALユニットのデコード順を再構築するためにレシーバーが利用できるデパケット化バッファースペースの量をバイト単位で示します。レシーバーは任意のRTPストリームを処理でき、RTPストリームが依存しているすべてのRTPストリームが存在する場合は、sprop-depack-buf-bytesパラメーターの値がこのパラメーター以下です。
When not present, the value of depack-buf-cap is inferred to be equal to 4294967295. The value of depack-buf-cap MUST be an integer in the range of 1 to 4294967295, inclusive.
存在しない場合、depack-buf-capの値は4294967295に等しいと推測されます。depack-buf-capの値は、1〜4294967295の範囲の整数である必要があります。
Informative note: depack-buf-cap indicates the maximum possible size of the de-packetization buffer of the receiver only, without allowing for network jitter.
参考情報：depack-buf-capは、ネットワークジッターを考慮せずに、レシーバーのみのパケット化解除バッファーの最大可能サイズを示します。
sprop-segmentation-id:
sprop-segmentation-id：
This parameter MAY be used to signal the segmentation tools present in the bitstream and that can be used for parallelization. The value of sprop-segmentation-id MUST be an integer in the range of 0 to 3, inclusive. When not present, the value of sprop-segmentation-id is inferred to be equal to 0.
このパラメータを使用して、ビットストリームに存在するセグメンテーションツールに信号を送ることができます。これは、並列化に使用できます。 sprop-segmentation-idの値は、0〜3の範囲の整数である必要があります。存在しない場合、sprop-segmentation-idの値は0と推定されます。
When sprop-segmentation-id is equal to 0, no information about the segmentation tools is provided. When sprop-segmentation-id is equal to 1, it indicates that slices are present in the bitstream. When sprop-segmentation-id is equal to 2, it indicates that tiles are present in the bitstream. When sprop-segmentation-id is equal to 3, it indicates that WPP is used in the bitstream.
sprop-segmentation-idが0の場合、セグメンテーションツールに関する情報は提供されません。 sprop-segmentation-idが1の場合、ビットストリームにスライスが存在することを示しています。 sprop-segmentation-idが2の場合、ビットストリームにタイルが存在することを示しています。 sprop-segmentation-idが3の場合、ビットストリームでWPPが使用されていることを示しています。
sprop-spatial-segmentation-idc:
sprop-spatial-segmentation-idc：
A base16 [RFC4648] representation of the syntax element min_spatial_segmentation_idc as specified in [HEVC]. This parameter MAY be used to describe parallelization capabilities of the bitstream.
[HEVC]で指定されている構文要素min_spatial_segmentation_idcのbase16 [RFC4648]表現。このパラメータは、ビットストリームの並列化機能を説明するために使用される場合があります。
dec-parallel-cap:
dec-parallel-cap：
This parameter MAY be used to indicate the decoder's additional decoding capabilities given the presence of tools enabling parallel decoding, such as slices, tiles, and WPP, in the bitstream. The decoding capability of the decoder may vary with the setting of the parallel decoding tools present in the bitstream, e.g., the size of the tiles that are present in a bitstream. Therefore, multiple capability points may be provided, each indicating the minimum required decoding capability that is associated with a parallelism requirement, which is a requirement on the bitstream that enables parallel decoding.
このパラメーターは、ビットストリーム内のスライス、タイル、WPPなどの並列デコードを可能にするツールが存在する場合に、デコーダーの追加のデコード機能を示すために使用できます。復号器の復号能力は、ビットストリームに存在する並列復号ツールの設定、例えば、ビットストリームに存在するタイルのサイズによって異なり得る。したがって、複数の機能ポイントを提供することができ、それぞれが、並列復号を可能にするビットストリームの要件である並列要件に関連する最小必要復号機能を示す。
Each capability point is defined as a combination of 1) a parallelism requirement, 2) a profile (determined by profile-space and profile-id), 3) a highest level, and 4) a maximum processing rate, a maximum picture size, and a maximum video bitrate that may be equal to or greater than that determined by the highest level. The parameter's syntax in ABNF [RFC5234] is as follows: dec-parallel-cap = "dec-parallel-cap={" cap-point *("," cap-point) "}"
各機能ポイントは、1）並列処理要件、2）プロファイル（profile-spaceおよびprofile-idによって決定）、3）最高レベル、4）最大処理速度、最大画像サイズ、の組み合わせとして定義されます。最高レベルで決定されたビットレートと同じかそれ以上の最大ビデオビットレート。 ABNF [RFC5234]でのパラメーターの構文は次のとおりです。dec-parallel-cap = "dec-parallel-cap = {" cap-point *（ "、" cap-point） "}"
cap-point = ("w" / "t") ":" spatial-seg-idc 1*(";"
cap-parameter)
spatial-seg-idc = 1*4DIGIT ; (1-4095)
cap-parameter = tier-flag / level-id / max-lsr
/ max-lps / max-br
tier-flag = "tier-flag" EQ ("0" / "1")
level-id = "level-id" EQ 1*3DIGIT ; (0-255)
max-lsr = "max-lsr" EQ 1*20DIGIT ; (0- 18,446,744,073,709,551,615)
max-lsr = "max-lsr" EQ 1 * 20DIGIT; （0-18,446,744,073,709,551,615）
max-lps = "max-lps" EQ 1*10DIGIT ; (0-4,294,967,295)
max-br = "max-br" EQ 1*20DIGIT ; (0- 18,446,744,073,709,551,615)
max-br = "max-br" EQ 1 * 20DIGIT; （0-18,446,744,073,709,551,615）
EQ = "="
EQ = "="
The set of capability points expressed by the dec-parallel-cap parameter is enclosed in a pair of curly braces ("{}"). Each set of two consecutive capability points is separated by a comma (','). Within each capability point, each set of two consecutive parameters, and, when present, their values, is separated by a semicolon (';').
dec-parallel-capパラメーターで表される機能ポイントのセットは、中括弧（ "{}"）のペアで囲まれています。 2つの連続する機能ポイントの各セットは、コンマ（ '、'）で区切られます。各機能ポイント内では、2つの連続するパラメーターの各セットと、存在する場合はそれらの値がセミコロン（ ';'）で区切られます。
The profile of all capability points is determined by profile-space and profile-id, which are outside the dec-parallel-cap parameter.
すべての機能ポイントのプロファイルは、dec-parallel-capパラメーターの外側にあるprofile-spaceとprofile-idによって決定されます。
Each capability point starts with an indication of the parallelism requirement, which consists of a parallel tool type, which may be equal to 'w' or 't', and a decimal value of the spatial-seg-idc parameter. When the type is 'w', the capability point is valid only for H.265 bitstreams with WPP in use, i.e., entropy_coding_sync_enabled_flag equal to 1. When the type is 't', the capability point is valid only for H.265 bitstreams with WPP not in use (i.e., entropy_coding_sync_enabled_flag equal to 0). The capability-point is valid only for H.265 bitstreams with min_spatial_segmentation_idc equal to or greater than spatial-seg-idc.
各機能ポイントは、「w」または「t」に等しい可能性のある並列ツールタイプと、spatial-seg-idcパラメーターの10進数値で構成される並列処理要件の表示から始まります。タイプが「w」の場合、機能ポイントはWPPが使用されているH.265ビットストリームに対してのみ有効です。つまり、entropy_coding_sync_enabled_flagが1です。タイプが「t」の場合、機能ポイントはH.265ビットストリームに対してのみ有効です。 WPPが使用されていない（つまり、entropy_coding_sync_enabled_flagが0に等しい）。機能ポイントは、min_spatial_segmentation_idcがspatial-seg-idc以上のH.265ビットストリームに対してのみ有効です。
After the parallelism requirement indication, each capability point continues with one or more pairs of parameter and value in any order for any of the following parameters:
並列処理要件の指示後、各機能ポイントは、次のパラメーターのいずれかについて、パラメーターと値の1つ以上のペアを任意の順序で続行します。
o tier-flag o level-id o max-lsr o max-lps o max-br
o ティアフラグoレベルID o max-lsr o max-lps o max-br
At most, one occurrence of each of the above five parameters is allowed within each capability point.
せいぜい、上記の5つのパラメーターはそれぞれ、各機能ポイント内で1回のみ使用できます。
The values of dec-parallel-cap.tier-flag and dec-parallel-cap.level-id for a capability point indicate the highest level of the capability point. The values of dec-parallel-cap.max-lsr, dec-parallel-cap.max-lps, and dec-parallel-cap.max-br for a capability point indicate the maximum processing rate in units of luma samples per second, the maximum picture size in units of luma samples, and the maximum video bitrate (in units of CpbBrVclFactor bits per second for the VCL HRD parameters and in units of CpbBrNalFactor bits per second for the NAL HRD parameters where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC]).
機能ポイントのdec-parallel-cap.tier-flagおよびdec-parallel-cap.level-idの値は、機能ポイントの最高レベルを示します。機能ポイントのdec-parallel-cap.max-lsr、dec-parallel-cap.max-lps、およびdec-parallel-cap.max-brの値は、1秒あたりの輝度サンプルの単位で最大処理速度を示します。輝度サンプルの単位での最大画像サイズ、および最大ビデオビットレート（VCL HRDパラメーターの場合はCpbBrVclFactorビット/秒の単位、NAL HRDパラメーターの場合は秒あたりCpbBrNalFactorビットの単位で、CpbBrVclFactorとCpbBrNalFactorはセクションAで定義されています[HEVC]の.4）。
When not present, the value of dec-parallel-cap.tier-flag is inferred to be equal to the value of tier-flag outside the dec-parallel-cap parameter. When not present, the value of dec-parallel-cap.level-id is inferred to be equal to the value of max-recv-level-id outside the dec-parallel-cap parameter. When not present, the value of dec-parallel-cap.max-lsr, dec-parallel-cap.max-lps, or dec-parallel-cap.max-br is inferred to be equal to the value of max-lsr, max-lps, or max-br, respectively, outside the dec-parallel-cap parameter.
存在しない場合、dec-parallel-cap.tier-flagの値は、dec-parallel-capパラメーターの外側のtier-flagの値と等しいと推測されます。存在しない場合、dec-parallel-cap.level-idの値は、dec-parallel-capパラメーターの外側のmax-recv-level-idの値と等しいと推測されます。存在しない場合、dec-parallel-cap.max-lsr、dec-parallel-cap.max-lps、またはdec-parallel-cap.max-brの値は、max-lsrの値と等しいと推測されます。 dec-parallel-capパラメータの外側にあるmax-lpsまたはmax-br。
The general decoding capability, expressed by the set of parameters outside of dec-parallel-cap, is defined as the capability point that is determined by the following combination of parameters: 1) the parallelism requirement corresponding to the value of sprop-segmentation-id equal to 0 for a bitstream, 2) the profile determined by profile-space, profile-id, profile-compatibility-indicator, and interop-constraints, 3) the tier and the highest level determined by tier-flag and max-recv-level-id, and 4) the maximum processing rate, the maximum picture size, and the maximum video bitrate determined by the highest level. The general decoding capability MUST NOT be included as one of the set of capability points in the dec-parallel-cap parameter.
dec-parallel-capの外側にあるパラメーターのセットによって表される一般的なデコード機能は、次のパラメーターの組み合わせによって決定される機能ポイントとして定義されます。1）sprop-segmentation-idの値に対応する並列処理要件ビットストリームの場合は0に等しい、2）プロファイルスペース、プロファイルID、プロファイル互換性インジケータ、および相互運用制約によって決定されたプロファイル、3）ティアおよびティアフラグと最大レクリエーションによって決定された最高レベルlevel-id、および4）最高レベルによって決定される最大処理速度、最大画像サイズ、および最大ビデオビットレート。一般的なデコード機能は、dec-parallel-capパラメーターの機能ポイントのセットの1つとして含めることはできません。
For example, the following parameters express the general decoding capability of 720p30 (Level 3.1) plus an additional decoding capability of 1080p30 (Level 4) given that the spatially largest tile or slice used in the bitstream is equal to or less than 1/3 of the picture size:
たとえば、次のパラメーターは、720p30（レベル3.1）の一般的なデコード機能と、ビットストリームで使用される空間的に最大のタイルまたはスライスが3分の1以下である場合、1080p30（レベル4）の追加のデコード機能を表します。画像サイズ：
a=fmtp:98 level-id=93;dec-parallel-cap={t:8;level- id=120}
For another example, the following parameters express an additional decoding capability of 1080p30, using dec-parallel-cap.max-lsr and dec-parallel-cap.max-lps, given that WPP is used in the bitstream:
別の例として、WPPがビットストリームで使用されている場合、次のパラメーターは、dec-parallel-cap.max-lsrおよびdec-parallel-cap.max-lpsを使用して、1080p30の追加のデコード機能を表します。
a=fmtp:98 level-id=93;dec-parallel-cap={w:8;
max-lsr=62668800;max-lps=2088960}
Informative note: When min_spatial_segmentation_idc is present in a bitstream and WPP is not used, [HEVC] specifies that there is no slice or no tile in the bitstream containing more than 4 * PicSizeInSamplesY / ( min_spatial_segmentation_idc + 4 ) luma samples.
参考情報：ビットストリームにmin_spatial_segmentation_idcが存在し、WPPが使用されていない場合、[HEVC]は、4 * PicSizeInSamplesY /（min_spatial_segmentation_idc + 4）輝度サンプルを含むビットストリームにスライスまたはタイルがないことを指定します。
include-dph:
include-dph：
This parameter is used to indicate the capability and preference to utilize or include Decoded Picture Hash (DPH) SEI messages (see Section D.3.19 of [HEVC]) in the bitstream. DPH SEI messages can be used to detect picture corruption so the receiver can request picture repair, see Section 8. The value is a comma-separated list of hash types that is supported or requested to be used, each hash type provided as an unsigned integer value (0-255), with the hash types listed from most preferred to the least preferred. Example: "include-dph=0,2", which indicates the capability for MD5 (most preferred) and Checksum (less preferred). If the parameter is not included or the value contains no hash types, then no capability to utilize DPH SEI messages is assumed. Note that DPH SEI messages MAY still be included in the bitstream even when there is no declaration of capability to use them, as in general SEI messages do not affect the normative decoding process and decoders are allowed to ignore SEI messages.
このパラメータは、ビットストリームでデコードピクチャハッシュ（DPH）SEIメッセージ（[HEVC]のセクションD.3.19を参照）を利用または含める機能と優先度を示すために使用されます。 DPH SEIメッセージを使用して画像の破損を検出できるため、受信者は画像の修復を要求できます。セクション8を参照してください。この値は、使用がサポートまたは要求されているハッシュタイプのコンマ区切りのリストであり、各ハッシュタイプは符号なし整数として提供されます。値（0〜255）。ハッシュタイプは、最も優先されるものから最も優先されないものまでリストされています。例：「include-dph = 0,2」は、MD5（最も好ましい）およびチェックサム（あまり好ましくない）の機能を示します。パラメータが含まれていないか、値にハッシュタイプが含まれていない場合、DPH SEIメッセージを利用する機能はないと見なされます。一般的にSEIメッセージは規範的なデコードプロセスに影響を与えず、デコーダーはSEIメッセージを無視することができるため、DPH SEIメッセージはそれらを使用する機能の宣言がない場合でもビットストリームに含まれる場合があります。
Encoding considerations:
エンコードに関する考慮事項：
This type is only defined for transfer via RTP (RFC 3550).
このタイプは、RTP（RFC 3550）を介した転送に対してのみ定義されます。
Security considerations:
セキュリティに関する考慮事項：
See Section 9 of RFC 7798.
RFC 7798のセクション9をご覧ください。
Published specification:
公開された仕様：
Please refer to RFC 7798 and its Section 12.
RFC 7798とそのセクション12を参照してください。
Additional information: None
追加情報：なし
File extensions: none
ファイル拡張子：なし
Macintosh file type code: none
Macintoshファイルタイプコード：なし
Object identifier or OID: none
オブジェクト識別子またはOID：なし
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
Ye-Kui Wang (yekui.wang@gmail.com)
Y E-K UI Wang（損失もある。Wang@ Gmail.com）
Intended usage: COMMON
使用目的：COMMON
Author: See Authors' Addresses section of RFC 7798.
作成者：RFC 7798の「作成者のアドレス」セクションを参照してください。
Change controller:
コントローラを変更：
IETF Audio/Video Transport Payloads working group delegated from the IESG.
IESGから委任されたIETF Audio / Video Transport Payloadsワーキンググループ。
The receiver MUST ignore any parameter unspecified in this memo.
受信者は、このメモで指定されていないパラメータを無視しなければなりません（MUST）。
The media type video/H265 string is mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows:
メディアタイプのvideo / H265文字列は、Session Description Protocol（SDP）[RFC4566]のフィールドに次のようにマッピングされます。
o The media name in the "m=" line of SDP MUST be video.
o SDPの「m =」行のメディア名はビデオである必要があります。
o The encoding name in the "a=rtpmap" line of SDP MUST be H265 (the media subtype).
o SDPの「a = rtpmap」行のエンコーディング名はH265（メディアサブタイプ）である必要があります。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o 「a = rtpmap」行のクロックレートは90000でなければなりません。
o The OPTIONAL parameters profile-space, profile-id, tier-flag, level-id, interop-constraints, profile-compatibility-indicator, sprop-sub-layer-id, recv-sub-layer-id, max-recv-level-id, tx-mode, max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc, max-fps, sprop-max-don-diff, sprop-depack-buf-nalus, sprop-depack-buf-bytes, depack-buf-cap, sprop-segmentation-id, sprop-spatial-segmentation-idc, dec-parallel-cap, and include-dph, when present, MUST be included in the "a=fmtp" line of SDP. This parameter is expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
oオプションのパラメーター、profile-space、profile-id、tier-flag、level-id、interop-constraints、profile-compatibility-indicator、sprop-sub-layer-id、recv-sub-layer-id、max-recv- level-id、tx-mode、max-lsr、max-lps、max-cpb、max-dpb、max-br、max-tr、max-tc、max-fps、sprop-max-don-diff、sprop- depack-buf-nalus、sprop-depack-buf-bytes、depack-buf-cap、sprop-segmentation-id、sprop-spatial-segmentation-idc、dec-parallel-cap、およびinclude-dph（存在する場合） SDPの「a = fmtp」行に含まれています。このパラメータは、parameter = valueペアのセミコロン区切りリストの形式で、メディアタイプ文字列として表されます。
o The OPTIONAL parameters sprop-vps, sprop-sps, and sprop-pps, when present, MUST be included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576]. For a particular media format (i.e., RTP payload type), sprop-vps sprop-sps, or sprop-pps MUST NOT be both included in the "a=fmtp" line of SDP and conveyed using the "fmtp" source attribute. When included in the "a=fmtp" line of SDP, these parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs. When conveyed in the "a=fmtp" line of SDP for a particular payload type, the parameters sprop-vps, sprop-sps, and sprop-pps MUST be applied to each SSRC with the payload type. When conveyed using the "fmtp" source attribute, these parameters are only associated with the given source and payload type as parts of the "fmtp" source attribute.
o オプションのパラメーターsprop-vps、sprop-sps、およびsprop-ppsは、存在する場合、SDPの「a = fmtp」行に含めるか、[RFC5576]のセクション6.3で指定されている「fmtp」ソース属性を使用して伝達する必要があります。 。特定のメディア形式（つまり、RTPペイロードタイプ）の場合、sprop-vps sprop-sps、またはsprop-ppsの両方をSDPの「a = fmtp」行に含め、「fmtp」ソース属性を使用して伝達することはできません。 SDPの「a = fmtp」行に含まれる場合、これらのパラメーターはパラメータータイプ=値のペアのセミコロンで区切られたリストの形式で、メディアタイプの文字列として表現されます。特定のペイロードタイプのSDPの「a = fmtp」行で伝達される場合、パラメーターsprop-vps、sprop-sps、およびsprop-ppsは、ペイロードタイプの各SSRCに適用する必要があります。 「fmtp」ソース属性を使用して伝達される場合、これらのパラメーターは、「fmtp」ソース属性の一部として、指定されたソースとペイロードタイプにのみ関連付けられます。
Informative note: Conveyance of sprop-vps, sprop-sps, and sprop-pps using the "fmtp" source attribute allows for out-of-band transport of parameter sets in topologies like Topo-Video-switch-MCU as specified in [RFC7667].
参考情報：「fmtp」ソース属性を使用したsprop-vps、sprop-sps、およびsprop-ppsの伝達により、[RFC7667]で指定されているTopo-Video-switch-MCUなどのトポロジのパラメータセットの帯域外転送が可能になります]。
An example of media representation in SDP is as follows:
SDPでのメディア表現の例は次のとおりです。
m=video 49170 RTP/AVP 98
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1;
sprop-vps=<video parameter sets data>
When HEVC is offered over RTP using SDP in an offer/answer model [RFC3264] for negotiation for unicast usage, the following limitations and rules apply:
ユニキャスト使用のネゴシエーション用にオファー/アンサーモデル[RFC3264]でSDPを使用してRTP経由でHEVCが提供される場合、次の制限とルールが適用されます。
o The parameters identifying a media format configuration for HEVC are profile-space, profile-id, tier-flag, level-id, interop-constraints, profile-compatibility-indicator, and tx-mode. These media configuration parameters, except level-id, MUST be used symmetrically when the answerer does not include recv-sub-layer-id in the answer for the media format (payload type) or the included recv-sub-layer-id is equal to sprop-sub-layer-id in the offer. The answerer MUST:
o HEVCのメディアフォーマット構成を識別するパラメーターは、profile-space、profile-id、tier-flag、level-id、interop-constraints、profile-compatibility-indicator、およびtx-modeです。これらのメディア構成パラメーター（レベルIDを除く）は、回答者がメディア形式（ペイロードタイプ）の回答にrecv-sub-layer-idを含めないか、含まれているrecv-sub-layer-idが等しい場合に対称的に使用する必要がありますオファーのsprop-sub-layer-idに。回答者は：
1) maintain all configuration parameters with the values remaining the same as in the offer for the media format (payload type), with the exception that the value of level-id is changeable as long as the highest level indicated by the answer is not higher than that indicated by the offer;
1）回答で示された最高レベルがそれより高くない限りlevel-idの値が変更可能であることを除いて、すべての構成パラメーターをメディア形式（ペイロードタイプ）のオファーと同じ値のままにしますオファーで示されたものより
2) include in the answer the recv-sub-layer-id parameter, with a value less than the sprop-sub-layer-id parameter in the offer, for the media format (payload type), and maintain all configuration parameters with the values being the same as signaled in the sprop-vps for the chosen sub-layer representation, with the exception that the value of level-id is changeable as long as the highest level indicated by the answer is not higher than the level indicated by the sprop-vps in offer for the chosen sub-layer representation; or
2）メディア形式（ペイロードタイプ）の場合、オファーにsprop-sub-layer-idパラメーターよりも小さい値を持つrecv-sub-layer-idパラメーターを回答に含め、すべての構成パラメーターを値は、選択されたサブレイヤー表現のsprop-vpsで通知されたものと同じです。ただし、回答で示された最高レベルが、選択されたサブレイヤー表現のsprop-vpsが提供されます。または
3) remove the media format (payload type) completely (when one or more of the parameter values are not supported).
3）メディア形式（ペイロードタイプ）を完全に削除します（1つ以上のパラメーター値がサポートされていない場合）。
Informative note: The above requirement for symmetric use does not apply for level-id, and does not apply for the other bitstream or RTP stream properties and capability parameters.
参考情報：上記の対称使用の要件は、レベルIDには適用されず、他のビットストリームまたはRTPストリームのプロパティと機能パラメーターには適用されません。
o The profile-compatibility-indicator, when offered as sendonly, describes bitstream properties. The answerer MAY accept an RTP payload type even if the decoder is not capable of handling the profile indicated by the profile-space, profile-id, and interop-constraints parameters, but capable of any of the profiles indicated by the profile-space, profile-compatibility-indicator, and interop-constraints. However, when the profile-compatibility-indicator is used in a recvonly or sendrecv media description, the bitstream using this RTP payload type is required to conform to all profiles indicated by profile-space, profile-compatibility-indicator, and interop-constraints.
o プロファイル互換性インジケータは、sendonlyとして提供される場合、ビットストリームプロパティを記述します。デコーダーがprofile-space、profile-id、およびinterop-constraintsパラメーターで示されるプロファイルを処理することはできないが、profile-spaceで示されるプロファイルのいずれかが可能であっても、アンサーはRTPペイロードタイプを受け入れることができます。プロファイル互換性インジケータ、および相互運用制約。ただし、profile-compatibility-indicatorがrecvonlyまたはsendrecvメディア記述で使用される場合、このRTPペイロードタイプを使用するビットストリームは、profile-space、profile-compatibility-indicator、およびinterop-constraintsで示されるすべてのプロファイルに準拠する必要があります。
o To simplify handling and matching of these configurations, the same RTP payload type number used in the offer SHOULD also be used in the answer, as specified in [RFC3264].
o これらの構成の処理と照合を簡素化するために、[RFC3264]で指定されているように、オファーで使用されているものと同じRTPペイロードタイプ番号を回答でも使用する必要があります（SHOULD）。
o The same RTP payload type number used in the offer for the media subtype H265 MUST be used in the answer when the answer includes recv-sub-layer-id. When the answer does not include recv-sub-layer-id, the answer MUST NOT contain a payload type number used in the offer for the media subtype H265 unless the configuration is exactly the same as in the offer or the configuration in the answer only differs from that in the offer with a different value of level-id. The answer MAY contain the recv-sub-layer-id parameter if an HEVC bitstream contains multiple operation points (using temporal scalability and sub-layers) and sprop-vps is included in the offer where information of sub-layers are present in the first video parameter set contained in sprop-vps. If the sprop-vps is provided in an offer, an answerer MAY select a particular operation point indicated in the first video parameter set contained in sprop-vps. When the answer includes a recv-sub-layer-id that is less than a sprop-sub-layer-id in the offer, all video parameter sets contained in the sprop-vps parameter in the SDP answer and all video parameter sets sent in-band for either the offerer-to-answerer direction or the answerer-to-offerer direction MUST be consistent with the first video parameter set in the sprop-vps parameter of the offer (see the semantics of sprop-vps in Section 7.1 of this document on one video parameter set being consistent with another video parameter set), and the bitstream sent in either direction MUST conform to the profile, tier, level, and constraints of the chosen sub-layer representation as indicated by the first profile_tier_level( ) syntax structure in the first video parameter set in the sprop-vps parameter of the offer.
o回答にrecv-sub-layer-idが含まれている場合、メディアサブタイプH265のオファーで使用されているものと同じRTPペイロードタイプ番号を回答で使用する必要があります。回答にrecv-sub-layer-idが含まれていない場合、構成がオファーと完全に同じであるか、回答のみの構成でない限り、回答にメディアサブタイプH265のオファーで使用されているペイロードタイプ番号を含めてはなりません（MUST NOT）。 level-idの値が異なるオファーとは異なります。 HEVCビットストリームに複数の操作ポイントが含まれていて（時間的スケーラビリティとサブレイヤーを使用）、サブレイヤーの情報が最初に存在するオファーにsprop-vpsが含まれている場合、回答にはrecv-sub-layer-idパラメーターが含まれる場合がありますsprop-vpsに含まれるビデオパラメータセット。オファーでsprop-vpsが提供されている場合、回答者はsprop-vpsに含まれている最初のビデオパラメータセットに示されている特定の操作ポイントを選択できます（MAY）。回答にオファーのsprop-sub-layer-idより小さいrecv-sub-layer-idが含まれている場合、SDP回答のsprop-vpsパラメータに含まれるすべてのビデオパラメータセットと、送信されるすべてのビデオパラメータセット提供者から回答者への方向または回答者から提供者への方向のいずれかの帯域は、オファーのsprop-vpsパラメーターで設定された最初のビデオパラメーターと一致している必要があります（このセクション7.1のsprop-vpsのセマンティクスを参照） 1つのビデオパラメータセットが別のビデオパラメータセットと一致しているドキュメント）、およびどちらかの方向に送信されるビットストリームは、最初のprofile_tier_level()構文で示されているように、選択されたサブレイヤ表現のプロファイル、階層、レベル、および制約に準拠する必要がありますオファーのsprop-vpsパラメータで設定された最初のビデオパラメータの構造。
Informative note: When an offerer receives an answer that does not include recv-sub-layer-id, it has to compare payload types not declared in the offer based on the media type (i.e., video/H265) and the above media configuration parameters with any payload types it has already declared. This will enable it to determine whether the configuration in question is new or if it is equivalent to configuration already offered, since a different payload type number may be used in the answer. The ability to perform operation point selection enables a receiver to utilize the temporal scalable nature of an HEVC bitstream.
参考情報：オファーがrecv-sub-layer-idを含まない回答を受け取った場合、オファーで宣言されていないペイロードタイプをメディアタイプ（つまり、ビデオ/ H265）と上記のメディア構成パラメーターに基づいて比較する必要があります。すでに宣言されているペイロードタイプがあります。これにより、問題の構成が新しいかどうか、またはすでに提供されている構成と同等であるかどうかを判別できます。異なるペイロードタイプ番号が回答で使用される場合があるためです。動作点選択を実行する機能により、受信機はHEVCビットストリームの時間的にスケーラブルな性質を利用できます。
o The parameters sprop-max-don-diff, sprop-depack-buf-nalus, and sprop-depack-buf-bytes describe the properties of an RTP stream, and all RTP streams the RTP stream depends on, when present, that the offerer or the answerer is sending for the media format configuration. This differs from the normal usage of the offer/answer parameters: normally such parameters declare the properties of the bitstream or RTP stream that the offerer or the answerer is able to receive. When dealing with HEVC, the offerer assumes that the answerer will be able to receive media encoded using the configuration being offered.
o パラメータsprop-max-don-diff、sprop-depack-buf-nalus、およびsprop-depack-buf-bytesは、RTPストリームのプロパティを記述します。RTPストリームが存在する場合、そのRTPストリームが依存するすべてのRTPストリームは、提供者または、回答者がメディア形式の構成を送信しています。これは、オファー/アンサーパラメーターの通常の使用法とは異なります。通常、このようなパラメーターは、オファー側またはアンサー側が受信できるビットストリームまたはRTPストリームのプロパティを宣言します。 HEVCを処理するとき、提供者は、提供者が提供されている構成を使用してエンコードされたメディアを受信できると想定します。
Informative note: The above parameters apply for any RTP stream and all RTP streams the RTP stream depends on, when present, sent by a declaring entity with the same configuration. In other words, the applicability of the above parameters to RTP streams depends on the source endpoint. Rather than being bound to the payload type, the values may have to be applied to another payload type when being sent, as they apply for the configuration.
参考情報：上記のパラメーターは、RTPストリームと、RTPストリームが存在する場合に依存するすべてのRTPストリームに適用され、同じ構成の宣言エンティティによって送信されます。つまり、上記のパラメータのRTPストリームへの適用可能性は、ソースエンドポイントによって異なります。値は、構成に適用されるため、ペイロードタイプにバインドされるのではなく、送信時に別のペイロードタイプに適用する必要がある場合があります。
o The capability parameters max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc MAY be used to declare further capabilities of the offerer or answerer for receiving. These parameters MUST NOT be present when the direction attribute is sendonly.
o 機能パラメーターmax-lsr、max-lps、max-cpb、max-dpb、max-br、max-tr、およびmax-tcを使用して、受信側のオファー側または応答側のさらなる機能を宣言できます。これらのパラメーターは、方向属性がsendonlyの場合は存在してはなりません（MUST NOT）。
o The capability parameter max-fps MAY be used to declare lower capabilities of the offerer or answerer for receiving. The parameters MUST NOT be present when the direction attribute is sendonly.
o 機能パラメータmax-fpsは、受信側の提供者または応答者のより低い機能を宣言するために使用される場合があります。方向属性がsendonlyの場合、パラメーターは存在してはなりません（MUST NOT）。
o The capability parameter dec-parallel-cap MAY be used to declare additional decoding capabilities of the offerer or answerer for receiving. Upon receiving such a declaration of a receiver, a sender MAY send a bitstream to the receiver utilizing those capabilities under the assumption that the bitstream fulfills the parallelism requirement. A bitstream that is sent based on choosing a capability point with parallel tool type 'w' from dec-parallel-cap MUST have entropy_coding_sync_enabled_flag equal to 1 and min_spatial_segmentation_idc equal to or larger than dec-parallel-cap.spatial-seg-idc of the capability point. A bitstream that is sent based on choosing a capability point with parallel tool type 't' from dec-parallel-cap MUST have entropy_coding_sync_enabled_flag equal to 0 and min_spatial_segmentation_idc equal to or larger than dec-parallel-cap.spatial-seg-idc of the capability point.
o 機能パラメーターdec-parallel-capを使用して、受信側のオファー側またはアンサー側の追加のデコード機能を宣言できます。そのような受信者の宣言を受信すると、送信者は、ビットストリームが並列処理の要件を満たしているという仮定の下で、それらの機能を利用してビットストリームを受信者に送信できます。 dec-parallel-capから並列ツールタイプ 'w'のケーパビリティポイントの選択に基づいて送信されるビットストリームは、entropy_coding_sync_enabled_flagが1で、min_spatial_segmentation_idcがdec-parallel-cap.spatial-seg-idc以上である必要があります。能力ポイント。 dec-parallel-capから並列ツールタイプ 't'のケイパビリティポイントの選択に基づいて送信されるビットストリームは、entropy_coding_sync_enabled_flagが0で、min_spatial_segmentation_idcがdec-parallel-cap.spatial-seg-idc以上である必要があります。能力ポイント。
o An offerer has to include the size of the de-packetization buffer, sprop-depack-buf-bytes, as well as sprop-max-don-diff and sprop-depack-buf-nalus, in the offer for an interleaved HEVC bitstream or for the MRST or MRMT transmission mode when sprop-max-don-diff is greater than 0 for at least one of the RTP streams. To enable the offerer and answerer to inform each other about their capabilities for de-packetization buffering in receiving RTP streams, both parties are RECOMMENDED to include depack-buf-cap. For interleaved RTP streams or in MRST or MRMT, it is also RECOMMENDED to consider offering multiple payload types with different buffering requirements when the capabilities of the receiver are unknown.
o 提供者は、インターリーブされたHEVCビットストリームのオファーに、パケット化解除バッファーのサイズ、sprop-depack-buf-bytes、sprop-max-don-diffおよびsprop-depack-buf-nalusを含める必要がありますRRSTストリームの少なくとも1つでsprop-max-don-diffが0より大きい場合のMRSTまたはMRMT送信モード。オファー側とアンサー側がRTPストリームを受信する際のパケット化解除バッファリングの機能について互いに通知できるようにするには、両方の当事者がdepack-buf-capを含めることをお勧めします。インターリーブされたRTPストリームの場合、またはMRSTまたはMRMTの場合、レシーバーの機能が不明な場合、異なるバッファリング要件を持つ複数のペイロードタイプを提供することを検討することも推奨されます。
o The capability parameter include-dph MAY be used to declare the capability to utilize decoded picture hash SEI messages and which types of hashes in any HEVC RTP streams received by the offerer or answerer.
o 機能パラメータinclude-dphは、デコードされた画像ハッシュSEIメッセージを利用する機能、および提供者または回答者が受信したHEVC RTPストリームのどのタイプのハッシュを宣言するために使用される場合があります。
o The sprop-vps, sprop-sps, or sprop-pps, when present (included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576]), are used for out-of-band transport of the parameter sets (VPS, SPS, or PPS, respectively).
o sprop-vps、sprop-sps、またはsprop-ppsが存在する場合（SDPの「a = fmtp」行に含まれるか、[RFC5576]のセクション6.3で指定されている「fmtp」ソース属性を使用して伝達される）が使用されます。パラメータセットの帯域外転送用（それぞれVPS、SPS、またはPPS）。
o The answerer MAY use either out-of-band or in-band transport of parameter sets for the bitstream it is sending, regardless of whether out-of-band parameter sets transport has been used in the offerer-to-answerer direction. Parameter sets included in an answer are independent of those parameter sets included in the offer, as they are used for decoding two different bitstreams, one from the answerer to the offerer and the other in the opposite direction. In case some RTP streams are sent before the SDP offer/answer settles down, in-band parameter sets MUST be used for those RTP stream parts sent before the SDP offer/answer.
o 回答者は、提供者から回答者の方向で帯域外パラメーターセットの転送が使用されたかどうかに関係なく、送信するビットストリームのパラメーターセットの帯域外または帯域内転送を使用できます（MAY）。アンサーに含まれるパラメーターセットは、オファーに含まれるパラメーターセットとは独立しています。パラメーターセットは、2つの異なるビットストリームをデコードするために使用されるためです。 SDPオファー/アンサーが落ち着く前に一部のRTPストリームが送信される場合、インバンドパラメーターセットは、SDPオファー/アンサーの前に送信されるRTPストリームパーツに使用する必要があります。
o The following rules apply to transport of parameter set in the offerer-to-answerer direction.
o 次のルールは、オファー側からアンサー側へのパラメーターセットの転送に適用されます。
+ An offer MAY include sprop-vps, sprop-sps, and/or sprop-pps. If none of these parameters is present in the offer, then only in-band transport of parameter sets is used.
+ オファーには、sprop-vps、sprop-sps、sprop-ppsが含まれる場合があります。これらのパラメーターのいずれもオファーに存在しない場合、パラメーターセットのインバンド転送のみが使用されます。
+ If the level to use in the offerer-to-answerer direction is equal to the default level in the offer, the answerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute) for decoding the incoming bitstream, e.g., by passing these parameter set NAL units to the video decoder before passing any NAL units carried in the RTP streams. Otherwise, the answerer MUST ignore sprop-vps, sprop-sps, and sprop-pps (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute) and the offerer MUST transmit parameter sets in-band.
+ オファー提供者から回答者への方向で使用するレベルがオファーのデフォルトレベルと等しい場合、回答者はsprop-vps、sprop-sps、およびsprop-ppsに含まれるパラメーターセット（いずれかがたとえば、RTPストリームで運ばれるNALユニットを渡す前にこれらのパラメーターセットのNALユニットをビデオデコーダーに渡すことにより、SDPの「a = fmtp」行で、または「fmtp」ソース属性を使用して伝達されます）。それ以外の場合、回答者はsprop-vps、sprop-sps、およびsprop-pps（SDPの「a = fmtp」行に含まれるか、または「fmtp」ソース属性を使用して伝達される）を無視する必要があり、提供者はパラメータセットをバンド。
+ In MRST or MRMT, the answerer MUST be prepared to use the parameter sets out-of-band transmitted for the RTP stream and all RTP streams the RTP stream depends on, when present, for decoding the incoming bitstream, e.g., by passing these parameter set NAL units to the video decoder before passing any NAL units carried in the RTP streams.
+ MRSTまたはMRMTでは、RTPストリームと、存在する場合にRTPストリームが依存するすべてのRTPストリームに送信される帯域外のパラメーターセットを使用するために、応答側は準備する必要があります。 RTPストリームで運ばれるNALユニットを渡す前に、ビデオデコーダーにNALユニットを設定します。
o The following rules apply to transport of parameter set in the answerer-to-offerer direction.
o 以下の規則は、回答者から提供者の方向でのパラメーターセットの転送に適用されます。
+ An answer MAY include sprop-vps, sprop-sps, and/or sprop-pps. If none of these parameters is present in the answer, then only in-band transport of parameter sets is used.
+ 回答には、sprop-vps、sprop-sps、sprop-ppsが含まれる場合があります。これらのパラメータがいずれも回答に含まれていない場合は、パラメータセットのインバンド転送のみが使用されます。
+ The offerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute) for decoding the incoming bitstream, e.g., by passing these parameter set NAL units to the video decoder before passing any NAL units carried in the RTP streams.
+ 提供者は、sprop-vps、sprop-sps、およびsprop-ppsに含まれるパラメーターセット（SDPの「a = fmtp」行に含まれるか、「fmtp」ソース属性を使用して伝達される）を使用して、たとえば、RTPストリームで運ばれるNALユニットを渡す前に、これらのパラメーターセットのNALユニットをビデオデコーダーに渡すことにより、着信ビットストリーム。
+ In MRST or MRMT, the offerer MUST be prepared to use the parameter sets out-of-band transmitted for the RTP stream and all RTP streams the RTP stream depends on, when present, for decoding the incoming bitstream, e.g., by passing these parameter set NAL units to the video decoder before passing any NAL units carried in the RTP streams.
+ MRSTまたはMRMTでは、提供者は、RTPストリームと、存在する場合にRTPストリームが依存するすべてのRTPストリームに対して帯域外で送信されるパラメーターセットを使用する準備をしなければなりません。 RTPストリームで運ばれるNALユニットを渡す前に、ビデオデコーダーにNALユニットを設定します。
o When sprop-vps, sprop-sps, and/or sprop-pps are conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576], the receiver of the parameters MUST store the parameter sets included in sprop-vps, sprop-sps, and/or sprop-pps and associate them with the source given as part of the "fmtp" source attribute. Parameter sets associated with one source (given as part of the "fmtp" source attribute) MUST only be used to decode NAL units conveyed in RTP packets from the same source (given as part of the "fmtp" source attribute). When this mechanism is in use, SSRC collision detection and resolution MUST be performed as specified in [RFC5576].
o [RFC5576]のセクション6.3で指定されている「fmtp」ソース属性を使用してsprop-vps、sprop-sps、sprop-ppsが伝達される場合、パラメーターの受信者はsprop-vpsに含まれるパラメーターセットを保存する必要があります。 sprop-spsやsprop-ppsを使用して、「fmtp」ソース属性の一部として指定されたソースに関連付けます。 1つのソース（「fmtp」ソース属性の一部として指定）に関連付けられたパラメーターセットは、同じソース（「fmtp」ソース属性の一部として指定）からのRTPパケットで伝達されるNALユニットのデコードにのみ使用する必要があります。このメカニズムが使用されているとき、SSRC衝突検出と解決は[RFC5576]で指定されているように実行されなければなりません（MUST）。
For bitstreams being delivered over multicast, the following rules apply:
マルチキャストで配信されるビットストリームには、次のルールが適用されます。
o The media format configuration is identified by profile-space, profile-id, tier-flag, level-id, interop-constraints, profile-compatibility-indicator, and tx-mode. These media format configuration parameters, including level-id, MUST be used symmetrically; that is, the answerer MUST either maintain all configuration parameters or remove the media format (payload type) completely. Note that this implies that the level-id for offer/answer in multicast is not changeable.
o メディア形式の構成は、profile-space、profile-id、tier-flag、level-id、interop-constraints、profile-compatibility-indicator、およびtx-modeによって識別されます。 level-idを含むこれらのメディアフォーマット構成パラメーターは、対称的に使用する必要があります。つまり、アンサーはすべての構成パラメーターを維持するか、メディア形式（ペイロードタイプ）を完全に削除する必要があります。これは、マルチキャストでのオファー/アンサーのレベルIDが変更できないことを意味することに注意してください。
o To simplify the handling and matching of these configurations, the same RTP payload type number used in the offer SHOULD also be used in the answer, as specified in [RFC3264]. An answer MUST NOT contain a payload type number used in the offer unless the configuration is the same as in the offer.
o これらの構成の処理とマッチングを簡素化するために、[RFC3264]で指定されているように、オファーで使用されているものと同じRTPペイロードタイプ番号を回答でも使用する必要があります（SHOULD）。構成がオファーと同じでない限り、回答にはオファーで使用されているペイロードタイプ番号を含めてはなりません。
o Parameter sets received MUST be associated with the originating source and MUST only be used in decoding the incoming bitstream from the same source.
o 受信したパラメータセットは、発信元に関連付けられている必要があり、同じソースからの着信ビットストリームをデコードする場合にのみ使用する必要があります。
o The rules for other parameters are the same as above for unicast as long as the three above rules are obeyed.
o 上記の3つのルールが守られている限り、他のパラメータのルールはユニキャストの上記と同じです。
Table 1 lists the interpretation of all the parameters that MUST be used for the various combinations of offer, answer, and direction attributes. Note that the two columns wherein the recv-sub-layer-id parameter is used only apply to answers, whereas the other columns apply to both offers and answers.
表1は、オファー、アンサー、および方向属性のさまざまな組み合わせに使用する必要があるすべてのパラメーターの解釈をリストしています。 recv-sub-layer-idパラメータが使用されている2つの列は回答にのみ適用され、他の列はオファーと回答の両方に適用されることに注意してください。
Table 1. Interpretation of parameters for various combinations of offers, answers, direction attributes, with and without recv-sub-layer-id. Columns that do not indicate offer or answer apply to both.
表1.オファー、アンサー、方向属性のさまざまな組み合わせのパラメーターの解釈（recv-sub-layer-idあり、なし）。オファーまたはアンサーを示さない列は両方に適用されます。
sendonly --+
answer: recvonly, recv-sub-layer-id --+ |
recvonly w/o recv-sub-layer-id --+ | |
answer: sendrecv, recv-sub-layer-id --+ | | |
sendrecv w/o recv-sub-layer-id --+ | | | |
| | | | |
profile-space C D C D P
profile-id C D C D P
tier-flag C D C D P
level-id D D D D P
interop-constraints C D C D P
profile-compatibility-indicator C D C D P
tx-mode C C C C P
max-recv-level-id R R R R -
sprop-max-don-diff P P - - P
sprop-depack-buf-nalus P P - - P
sprop-depack-buf-bytes P P - - P
depack-buf-cap R R R R -
sprop-segmentation-id P P P P P
sprop-spatial-segmentation-idc P P P P P
max-br R R R R -
max-cpb R R R R -
max-dpb R R R R -
max-lsr R R R R -
max-lps R R R R -
max-tr R R R R -
max-tc R R R R -
max-fps R R R R -
sprop-vps P P - - P
sprop-sps P P - - P
sprop-pps P P - - P
sprop-sub-layer-id P P - - P
recv-sub-layer-id X O X O -
dec-parallel-cap R R R R -
include-dph R R R R -
Legend:
伝説：
C: configuration for sending and receiving bitstreams D: changeable configuration, same as C except possible to answer with a different but consistent value (see the semantics of the six parameters related to profile, tier, and level on these parameters being consistent) P: properties of the bitstream to be sent R: receiver capabilities O: operation point selection X: MUST NOT be present -: not usable, when present MUST be ignored
C：ビットストリームを送受信するための構成D：変更可能な構成、異なるが一貫した値で応答できることを除いてCと同じ（これらのパラメーターのプロファイル、階層、およびレベルに関連する6つのパラメーターのセマンティクスが一貫していることを確認）P：送信されるビットストリームのプロパティR：レシーバー機能O：オペレーションポイントの選択X：存在してはならない--存在しない場合、使用不可
Parameters used for declaring receiver capabilities are, in general, downgradable; i.e., they express the upper limit for a sender's possible behavior. Thus, a sender MAY select to set its encoder using only lower/lesser or equal values of these parameters.
レシーバ機能の宣言に使用されるパラメータは、通常、ダウングレード可能です。つまり、送信者の可能な動作の上限を表します。したがって、送信者は、これらのパラメータのより低い/より少ないまたは等しい値のみを使用してエンコーダを設定することを選択できます（MAY）。
When the answer does not include a recv-sub-layer-id that is less than the sprop-sub-layer-id in the offer, parameters declaring a configuration point are not changeable, with the exception of the level-id parameter for unicast usage, and these parameters express values a receiver expects to be used and MUST be used verbatim in the answer as in the offer.
回答のsprop-sub-layer-idより小さいrecv-sub-layer-idがオファーに含まれていない場合、ユニキャストのlevel-idパラメーターを除いて、構成ポイントを宣言するパラメーターは変更できません使用法、およびこれらのパラメーターは、レシーバーが使用されることを期待する値を表し、オファーと同様に回答でそのまま使用する必要があります。
When a sender's capabilities are declared with the configuration parameters, these parameters express a configuration that is acceptable for the sender to receive bitstreams. In order to achieve high interoperability levels, it is often advisable to offer multiple alternative configurations. It is impossible to offer multiple configurations in a single payload type. Thus, when multiple configuration offers are made, each offer requires its own RTP payload type associated with the offer. However, it is possible to offer multiple operation points using one configuration in a single payload type by including sprop-vps in the offer and recv-sub-layer-id in the answer.
送信者の機能が構成パラメーターで宣言されている場合、これらのパラメーターは、送信者がビットストリームを受信するために受け入れられる構成を表します。高い相互運用性レベルを実現するために、複数の代替構成を提供することをお勧めします。単一のペイロードタイプで複数の構成を提供することは不可能です。したがって、複数の構成オファーが作成される場合、各オファーには、オファーに関連付けられた独自のRTPペイロードタイプが必要です。ただし、オファーにsprop-vpsを、回答にrecv-sub-layer-idを含めることで、1つのペイロードタイプの1つの構成を使用して複数のオペレーションポイントを提供することが可能です。
A receiver SHOULD understand all media type parameters, even if it only supports a subset of the payload format's functionality. This ensures that a receiver is capable of understanding when an offer to receive media can be downgraded to what is supported by the receiver of the offer.
ペイロード形式の機能のサブセットしかサポートしていない場合でも、レシーバーはすべてのメディアタイプパラメーターを理解する必要があります（SHOULD）。これにより、メディアを受信するオファーを、オファーのレシーバーがサポートするものにダウングレードできる時期をレシーバーが理解できるようになります。
An answerer MAY extend the offer with additional media format configurations. However, to enable their usage, in most cases a second offer is required from the offerer to provide the bitstream property parameters that the media sender will use. This also has the effect that the offerer has to be able to receive this media format configuration, not only to send it.
回答者は、追加のメディアフォーマット構成でオファーを拡張できます（MAY）。ただし、それらの使用を有効にするには、ほとんどの場合、メディア送信者が使用するビットストリームプロパティパラメータを提供するために、提供者からの2番目の提供が必要です。これは、提供者が送信するだけでなく、このメディアフォーマット構成を受信できる必要があるという効果もあります。
When HEVC over RTP is offered with SDP in a declarative style, as in Real Time Streaming Protocol (RTSP) [RFC2326] or Session Announcement Protocol (SAP) [RFC2974], the following considerations are necessary.
リアルタイムストリーミングプロトコル（RTSP）[RFC2326]またはセッションアナウンスプロトコル（SAP）[RFC2974]のように、HETP over RTPがSDPとともに宣言的なスタイルで提供される場合、次の考慮事項が必要です。
o All parameters capable of indicating both bitstream properties and receiver capabilities are used to indicate only bitstream properties. For example, in this case, the parameter profile-tier-level-id declares the values used by the bitstream, not the capabilities for receiving bitstreams. As a result, the following interpretation of the parameters MUST be used:
o ビットストリームプロパティとレシーバー機能の両方を示すことができるすべてのパラメーターは、ビットストリームプロパティのみを示すために使用されます。たとえば、この場合、パラメーターprofile-tier-level-idは、ビットストリームを受信するための機能ではなく、ビットストリームによって使用される値を宣言します。その結果、パラメーターの次の解釈を使用する必要があります。
+ Declaring actual configuration or bitstream properties: - profile-space - profile-id - tier-flag - level-id - interop-constraints - profile-compatibility-indicator - tx-mode - sprop-vps - sprop-sps - sprop-pps - sprop-max-don-diff - sprop-depack-buf-nalus - sprop-depack-buf-bytes - sprop-segmentation-id - sprop-spatial-segmentation-idc
+ 実際の構成またはビットストリームプロパティの宣言：-プロファイルスペース-プロファイルID-層フラグ-レベルID-相互運用制約-プロファイル互換性インジケータ-txモード-sprop-vps-sprop-sps-sprop-pps- sprop-max-don-diff-sprop-depack-buf-nalus-sprop-depack-buf-bytes-sprop-segmentation-id-sprop-spatial-segmentation-idc
+ Not usable (when present, they MUST be ignored): - max-lps - max-lsr - max-cpb - max-dpb - max-br - max-tr - max-tc - max-fps - max-recv-level-id - depack-buf-cap - sprop-sub-layer-id - dec-parallel-cap - include-dph
+ 使用不可（存在する場合は無視する必要があります）：-max-lps-max-lsr-max-cpb-max-dpb-max-br-max-tr-max-tc-max-fps-max-recv-level -id-depack-buf-cap-sprop-sub-layer-id-dec-parallel-cap-include-dph
o A receiver of the SDP is required to support all parameters and values of the parameters provided; otherwise, the receiver MUST reject (RTSP) or not participate in (SAP) the session. It falls on the creator of the session to use values that are expected to be supported by the receiving application.
o SDPのレシーバーは、提供されるすべてのパラメーターとパラメーターの値をサポートする必要があります。それ以外の場合、受信者はセッションを拒否する（RTSP）か、セッションに参加しない（SAP）必要があります。受信側アプリケーションでサポートされることが期待される値を使用するのは、セッションの作成者にあります。
When out-of-band transport of parameter sets is used, parameter sets MAY still be additionally transported in-band unless explicitly disallowed by an application, and some of these additional parameter sets may update some of the out-of-band transported parameter sets. Update of a parameter set refers to the sending of a parameter set of the same type using the same parameter set ID but with different values for at least one other parameter of the parameter set.
パラメータセットの帯域外転送が使用されている場合、アプリケーションによって明示的に許可されていない限り、パラメータセットは引き続き帯域内で転送される場合があり、これらの追加のパラメータセットの一部は、帯域外転送されたパラメータセットの一部を更新する場合があります。パラメータセットの更新とは、同じパラメータセットIDを使用して同じタイプのパラメータセットを送信することを指しますが、パラメータセットの他の少なくとも1つのパラメータの値は異なります。
If MRST or MRMT is used, the rules on signaling media decoding dependency in SDP as defined in [RFC5583] apply. The rules on "hierarchical or layered encoding" with multicast in Section 5.7 of [RFC4566] do not apply. This means that the notation for Connection Data "c=" SHALL NOT be used with more than one address, i.e., the sub-field <number of addresses> in the sub-field <connection-address> of the "c=" field, described in [RFC4566], must not be present. The order of session dependency is given from the RTP stream containing the lowest temporal sub-layer to the RTP stream containing the highest temporal sub-layer.
MRSTまたはMRMTを使用する場合は、[RFC5583]で定義されているSDPのメディアデコード依存関係のシグナリングに関するルールが適用されます。 [RFC4566]のセクション5.7のマルチキャストによる「階層的または階層化エンコーディング」のルールは適用されません。つまり、接続データ "c ="の表記は、複数のアドレス、つまり "c ="フィールドのサブフィールド<connection-address>のサブフィールド<number of addresses>で使用することはできません（SHALL NOT） [RFC4566]で説明されているように、存在してはなりません。セッションの依存関係の順序は、最低の時間的サブレイヤーを含むRTPストリームから最高の時間的サブレイヤーを含むRTPストリームまで与えられます。
The following subsections define the use of the Picture Loss Indication (PLI), Slice Lost Indication (SLI), Reference Picture Selection Indication (RPSI), and Full Intra Request (FIR) feedback messages with HEVC. The PLI, SLI, and RPSI messages are defined in [RFC4585], and the FIR message is defined in [RFC5104].
次のサブセクションでは、HEVCでの画像損失表示（PLI）、スライス損失表示（SLI）、参照画像選択表示（RPSI）、および完全イントラ要求（FIR）フィードバックメッセージの使用について定義します。 PLI、SLI、およびRPSIメッセージは[RFC4585]で定義されており、FIRメッセージは[RFC5104]で定義されています。
As specified in RFC 4585, Section 6.3.1, the reception of a PLI by a media sender indicates "the loss of an undefined amount of coded video data belonging to one or more pictures". Without having any specific knowledge of the setup of the bitstream (such as use and location of in-band parameter sets, non-IDR decoder refresh points, picture structures, and so forth), a reaction to the reception of an PLI by an HEVC sender SHOULD be to send an IDR picture and relevant parameter sets; potentially with sufficient redundancy so to ensure correct reception. However, sometimes information about the bitstream structure is known. For example, state could have been established outside of the mechanisms defined in this document that parameter sets are conveyed out of band only, and stay static for the duration of the session. In that case, it is obviously unnecessary to send them in-band as a result of the reception of a PLI. Other examples could be devised based on a priori knowledge of different aspects of the bitstream structure. In all cases, the timing and congestion control mechanisms of RFC 4585 MUST be observed.
RFC 4585のセクション6.3.1で指定されているように、メディア送信者によるPLIの受信は、「1つまたは複数の画像に属する未定義の量のコード化ビデオデータの損失」を示します。ビットストリームのセットアップ（帯域内パラメーターセットの使用と場所、非IDRデコーダーの更新ポイント、画像構造など）に関する特定の知識がなくても、HEVCによるPLIの受信に対する反応送信者は、IDR画像と関連するパラメータセットを送信する必要があります。正しく受信できるように、潜在的に十分な冗長性があります。ただし、ビットストリーム構造に関する情報がわかっている場合があります。たとえば、このドキュメントで定義されているメカニズムの外で、パラメータセットが帯域外でのみ伝達され、セッションの期間中は静的な状態が維持される可能性があります。その場合、PLIの受信の結果として、それらをインバンドで送信する必要は明らかにありません。他の例は、ビットストリーム構造のさまざまな側面のアプリオリな知識に基づいて考案できます。すべての場合において、RFC 4585のタイミングおよび輻輳制御メカニズムを遵守する必要があります。
The SLI described in RFC 4585 can be used to indicate, to a sender, the loss of a number of Coded Tree Blocks (CTBs) in a CTB raster scan order of a picture. In the SLI's Feedback Control Indication (FCI) field, the subfield "First" MUST be set to the CTB address of the first lost CTB. Note that the CTB address is in CTB-raster-scan order of a picture. For the first CTB of a slice segment, the CTB address is the value of slice_segment_address when present, or 0 when the value of first_slice_segment_in_pic_flag is equal to 1; both syntax elements are in the slice segment header. The subfield "Number" MUST be set to the number of consecutive lost CTBs, again in CTB-raster-scan order of a picture. Note that due to both the "First" and "Number" being counted in CTBs in CTB-raster-scan order, of a picture, not in tile-scan order (which is the bitstream order of CTBs), multiple SLI messages may be needed to report the loss of one tile covering multiple CTB rows but less wide than the picture.
RFC 4585で説明されているSLIを使用して、画像のCTBラスタースキャン順序での多数のコード化ツリーブロック（CTB）の損失を送信者に示すことができます。 SLIのフィードバック制御表示（FCI）フィールドでは、サブフィールド「First」を、最初に失われたCTBのCTBアドレスに設定する必要があります。 CTBアドレスは画像のCTB-raster-scan順であることに注意してください。スライスセグメントの最初のCTBの場合、CTBアドレスは、slice_segment_addressが存在する場合はその値、first_slice_segment_in_pic_flagの値が1の場合は0です。どちらの構文要素もスライスセグメントヘッダーにあります。サブフィールド「番号」は、連続する失われたCTBの数に設定する必要があります。これも、画像のCTBラスタースキャン順です。タイルスキャン順（CTBのビットストリーム順）ではなく、画像のCTBラスタースキャン順でCTBで「最初」と「数」の両方がカウントされるため、複数のSLIメッセージが複数のCTB行をカバーする1つのタイルの損失を報告する必要があるが、画像よりも幅が狭い。
The subfield "PictureID" MUST be set to the 6 least significant bits of a binary representation of the value of PicOrderCntVal, as defined in [HEVC], of the picture for which the lost CTBs are indicated. Note that for IDR pictures the syntax element slice_pic_order_cnt_lsb is not present, but then the value is inferred to be equal to 0.
サブフィールド "PictureID"は、[HEVC]で定義されている、失われたCTBが示されている画像のPicOrderCntValの値のバイナリ表現の最下位6ビットに設定する必要があります。 IDRピクチャの場合、構文要素slice_pic_order_cnt_lsbは存在しませんが、値は0と推定されます。
As described in RFC 4585, an encoder in a media sender can use this information to "clean up" the corrupted picture by sending intra information, while observing the constraints described in RFC 4585, for example, with respect to congestion control. In many cases, error tracking is required to identify the corrupted region in the receiver's state (reference pictures) because of error import in uncorrupted regions of the picture through motion compensation. Reference-picture selection can also be used to "clean up" the corrupted picture, which is usually more efficient and less likely to generate congestion than sending intra information.
RFC 4585で説明されているように、メディアセンダーのエンコーダーは、この情報を使用して、たとえば輻輳制御に関してRFC 4585で説明されている制約を守りながら、イントラ情報を送信することで破損した画像を「クリーンアップ」できます。多くの場合、動き補償により画像の破損していない領域にエラーがインポートされるため、レシーバーの状態（参照画像）の破損した領域を識別するためにエラー追跡が必要です。参照画像の選択は、破損した画像を「クリーンアップ」するためにも使用できます。これは通常、イントラ情報を送信するよりも効率的であり、輻輳を生成する可能性が低くなります。
In contrast to the video codecs contemplated in RFCs 4585 and 5104 [RFC5104], in HEVC, the "macroblock size" is not fixed to 16x16 luma samples, but is variable. That, however, does not create a conceptual difficulty with SLI, because the setting of the CTB size is a sequence-level functionality, and using a slice loss indication across CVS boundaries is meaningless as there is no prediction across sequence boundaries. However, a proper use of SLI messages is not as straightforward as it was with older, fixed-macroblock-sized video codecs, as the state of the sequence parameter set (where the CTB size is located) has to be taken into account when interpreting the "First" subfield in the FCI.
RFC 4585および5104 [RFC5104]で検討されているビデオコーデックとは対照的に、HEVCでは、「マクロブロックサイズ」は16x16ルマサンプルに固定されていませんが、可変です。ただし、CTBサイズの設定はシーケンスレベルの機能であり、CVS境界をまたがるスライス損失表示を使用しても、シーケンス境界をまたがる予測がないため、SLIに概念的な問題は生じません。ただし、SLIメッセージの適切な使用は、シーケンスパラメーターセット（CTBサイズが配置されている場所）の状態を解釈するときに考慮に入れる必要があるため、古い固定マクロブロックサイズのビデオコーデックほど簡単ではありません。 FCIの「最初の」サブフィールド。
Feedback-based reference picture selection has been shown as a powerful tool to stop temporal error propagation for improved error resilience [Girod99][Wang05]. In one approach, the decoder side tracks errors in the decoded pictures and informs the encoder side that a particular picture that has been decoded relatively earlier is correct and still present in the decoded picture buffer; it requests the encoder to use that correct picture-availability information when encoding the next picture, so to stop further temporal error propagation. For this approach, the decoder side should use the RPSI feedback message.
フィードバックに基づく参照画像の選択は、エラー耐性を向上させるために一時的なエラー伝播を停止する強力なツールとして示されています[Girod99] [Wang05]。 １つのアプローチでは、デコーダ側は、デコードされたピクチャのエラーを追跡し、比較的早くデコードされた特定のピクチャが正しく、デコードされたピクチャバッファにまだ存在することをエンコーダ側に通知します。次のピクチャをエンコードするときに、その正しいピクチャ可用性情報を使用するようにエンコーダに要求します。これにより、時間的エラーの伝播を停止します。このアプローチでは、デコーダー側はRPSIフィードバックメッセージを使用する必要があります。
Encoders can encode some long-term reference pictures as specified in H.264 or HEVC for purposes described in the previous paragraph without the need of a huge decoded picture buffer. As shown in [Wang05], with a flexible reference picture management scheme, as in H.264 and HEVC, even a decoded picture buffer size of two picture storage buffers would work for the approach described in the previous paragraph.
エンコーダーは、前の段落で説明した目的のために、H.264またはHEVCで指定されている一部の長期参照画像をエンコードすることができます。巨大なデコード済み画像バッファーは必要ありません。 [Wang05]に示すように、H.264やHEVCのような柔軟な参照画像管理方式では、2つの画像ストレージバッファーのデコードされた画像バッファーサイズでも、前の段落で説明したアプローチで機能します。
The field "Native RPSI bit string defined per codec" is a base16 [RFC4648] representation of the 8 bits consisting of the 2 most significant bits equal to 0 and 6 bits of nuh_layer_id, as defined in [HEVC], followed by the 32 bits representing the value of the PicOrderCntVal (in network byte order), as defined in [HEVC], for the picture that is indicated by the RPSI feedback message.
「コーデックごとに定義されるネイティブRPSIビット文字列」フィールドは、[HEVC]で定義されているように、0に等しい2つの最上位ビットとnuh_layer_idの6ビットで構成される8ビットのbase16 [RFC4648]表現で、その後に32ビットが続きます。 RPSIフィードバックメッセージで示される画像の[HEVC]で定義されているPicOrderCntValの値（ネットワークバイトオーダー）を表します。
The use of the RPSI feedback message as positive acknowledgement with HEVC is deprecated. In other words, the RPSI feedback message MUST only be used as a reference picture selection request, such that it can also be used in multicast.
HEVCの肯定応答としてのRPSIフィードバックメッセージの使用は非推奨です。言い換えると、RPSIフィードバックメッセージは、マルチキャストでも使用できるように、参照ピクチャ選択要求としてのみ使用する必要があります。
The purpose of the FIR message is to force an encoder to send an independent decoder refresh point as soon as possible (observing, for example, the congestion-control-related constraints set out in RFC 5104).
FIRメッセージの目的は、エンコーダーに独立したデコーダーのリフレッシュポイントをできるだけ早く送信させることです（たとえば、RFC 5104で設定されている輻輳制御関連の制約を遵守します）。
Upon reception of a FIR, a sender MUST send an IDR picture. Parameter sets MUST also be sent, except when there is a priori knowledge that the parameter sets have been correctly established. A typical example for that is an understanding between sender and receiver, established by means outside this document, that parameter sets are exclusively sent out-of-band.
FIRの受信時に、送信者はIDR画像を送信する必要があります。パラメータセットが正しく確立されているという事前の知識がある場合を除いて、パラメータセットも送信する必要があります。その典型的な例は、このドキュメントの外部で確立された送信側と受信側の間の理解であり、パラメーターセットは帯域外でのみ送信されるというものです。
The scope of this Security Considerations section is limited to the payload format itself and to one feature of HEVC that may pose a particularly serious security risk if implemented naively. The payload format, in isolation, does not form a complete system. Implementers are advised to read and understand relevant security-related documents, especially those pertaining to RTP (see the Security Considerations section in [RFC3550]), and the security of the call-control stack chosen (that may make use of the media type registration of this memo). Implementers should also consider known security vulnerabilities of video coding and decoding implementations in general and avoid those.
この「セキュリティに関する考慮事項」セクションの範囲は、ペイロード形式自体と、単純に実装すると特に深刻なセキュリティリスクをもたらす可能性があるHEVCの1つの機能に限定されます。ペイロード形式は、単独では完全なシステムを形成しません。実装者は、関連するセキュリティ関連の文書、特にRTP（[RFC3550]のセキュリティに関する考慮事項のセクションを参照）、および選択されたコール制御スタックのセキュリティ（メディアタイプ登録を利用する可能性がある）を読んで理解することをお勧めしますこのメモの）。実装者はまた、ビデオコーディングおよびデコーディング実装の既知のセキュリティ脆弱性を一般的に考慮し、それらを回避する必要があります。
Within this RTP payload format, and with the exception of the user data SEI message as described below, no security threats other than those common to RTP payload formats are known. In other words, neither the various media-plane-based mechanisms, nor the signaling part of this memo, seems to pose a security risk beyond those common to all RTP-based systems.
このRTPペイロード形式内では、以下で説明するユーザーデータSEIメッセージを除いて、RTPペイロード形式に共通するもの以外のセキュリティの脅威は知られていません。つまり、さまざまなメディアプレーンベースのメカニズムも、このメモのシグナリング部分も、すべてのRTPベースのシステムに共通するものを超えるセキュリティリスクをもたらすようには見えません。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in 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 lays on 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などの適用可能なRTPプロファイルで説明されているセキュリティの考慮事項に従います。 [RFC3711]、またはRTP / SAVPF [RFC5124]。ただし、「RTPフレームワークのセキュリティ保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]が説明しているように、機密性などの基本的なセキュリティ目標を達成するためにどのソリューションが使用されるかを話し合う、または義務付けるのは、RTPペイロード形式の責任ではありません。一般に、RTPの整合性とソースの信頼性。この責任は、アプリケーションでRTPを使用するすべての人にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは、「RTPセッションを保護するためのオプション」[RFC7201]にあります。アプリケーションは、1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。このセクションの残りの部分では、ペイロード形式自体のセキュリティに影響を与えるプロパティについて説明します。
Because the data compression used with this payload format is applied end-to-end, any encryption needs to be performed after compression. A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the bitstream that are complex to decode and that cause the receiver to be overloaded. H.265 is particularly vulnerable to such attacks, as it is extremely simple to generate datagrams containing NAL units that affect the decoding process of many future NAL units. Therefore, the usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED, for example, with SRTP [RFC3711].
このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、暗号化は圧縮後に実行する必要があります。受信側の計算負荷が均一でない圧縮技術を使用したデータエンコーディングには、潜在的なサービス拒否の脅威が存在します。攻撃者は、復号化が複雑で、レシーバーが過負荷になる病理データグラムをビットストリームに挿入する可能性があります。 H.265は、このような攻撃に対して特に脆弱です。これは、将来の多くのNALユニットのデコードプロセスに影響を与えるNALユニットを含むデータグラムを生成することが非常に簡単であるためです。したがって、少なくともRTPパケットのデータ発信元認証とデータ整合性保護の使用は、たとえばSRTP [RFC3711]で推奨されます。
Like [H.264], HEVC includes a user data Supplemental Enhancement Information (SEI) message. This SEI message allows inclusion of an arbitrary bitstring into the video bitstream. Such a bitstring could include JavaScript, machine code, and other active content. HEVC leaves the handling of this SEI message to the receiving system. In order to avoid harmful side effects of the user data SEI message, decoder implementations cannot naively trust its content. For example, it would be a bad and insecure implementation practice to forward any JavaScript a decoder implementation detects to a web browser. The safest way to deal with user data SEI messages is to simply discard them, but that can have negative side effects on the quality of experience by the user.
[H.264]と同様に、HEVCにはユーザーデータの補足拡張情報（SEI）メッセージが含まれています。このSEIメッセージにより、ビデオビットストリームに任意のビット文字列を含めることができます。そのようなビットストリングには、JavaScript、マシンコード、およびその他のアクティブコンテンツが含まれる可能性があります。 HEVCは、このSEIメッセージの処理を受信システムに任せます。ユーザーデータSEIメッセージの有害な副作用を回避するために、デコーダーの実装はその内容を単純に信頼することはできません。たとえば、デコーダーの実装が検出したJavaScriptをWebブラウザーに転送することは、不適切で安全でない実装方法です。ユーザーデータSEIメッセージを処理する最も安全な方法は、単にそれらを破棄することですが、ユーザーのエクスペリエンス品質に悪影響を与える可能性があります。
End-to-end security with authentication, integrity, or confidentiality protection will prevent a MANE from performing media-aware operations other than discarding complete packets. In the case of confidentiality protection, it will even be prevented from discarding packets in a media-aware way. To be allowed to perform such operations, a MANE is required to be a trusted entity that is included in the security context establishment.
認証、整合性、または機密性保護を備えたエンドツーエンドのセキュリティにより、MANEは完全なパケットを破棄する以外のメディア対応操作を実行できなくなります。機密保護の場合は、メディアを意識した方法でパケットを破棄することもできません。このような操作の実行を許可するには、MANEがセキュリティコンテキストの確立に含まれる信頼されたエンティティである必要があります。
Congestion control for RTP SHALL be used in accordance with RTP [RFC3550] and with any applicable RTP profile, e.g., AVP [RFC3551]. If best-effort service is being used, an additional requirement is that users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within an acceptable range. Packet loss is considered acceptable if a TCP flow across the same network path, and experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than all RTP streams combined is achieving. This condition can be satisfied by implementing congestion-control mechanisms to adapt the transmission rate, the number of layers subscribed for a layered multicast session, or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
RTPの輻輳制御は、RTP [RFC3550]および適用可能なRTPプロファイル（AVP [RFC3551]など）に従って使用する必要があります（SHALL）。ベストエフォートサービスが使用されている場合、追加の要件は、このペイロード形式のユーザーがパケット損失を監視して、パケット損失率が許容範囲内であることを確認する必要があることです。パケット損失は、同じネットワークパスを通過し、同じネットワーク条件が発生しているTCPフローが、合理的なタイムスケールで測定された平均スループットを達成し、すべてのRTPストリームを組み合わせた場合よりも少なくない場合、許容できると見なされます。この条件は、輻輳制御メカニズムを実装して、伝送速度、階層化マルチキャストセッションにサブスクライブする層の数、または損失率が許容できないほど高い場合にセッションを離れるようにレシーバーを調整することで実現できます。
The bitrate adaptation necessary for obeying the congestion control principle is easily achievable when real-time encoding is used, for example, by adequately tuning the quantization parameter.
輻輳制御原理に従うために必要なビットレート適応は、たとえば量子化パラメータを適切に調整することにより、リアルタイムエンコーディングを使用する場合に簡単に実現できます。
However, when pre-encoded content is being transmitted, bandwidth adaptation requires the pre-coded bitstream to be tailored for such adaptivity. The key mechanism available in HEVC is temporal scalability. A media sender can remove NAL units belonging to higher temporal sub-layers (i.e., those NAL units with a high value of TID) until the sending bitrate drops to an acceptable range. HEVC contains mechanisms that allow the lightweight identification of switching points in temporal enhancement layers, as discussed in Section 1.1.2 of this memo. An HEVC media sender can send packets belonging to NAL units of temporal enhancement layers starting from these switching points to probe for available bandwidth and to utilized bandwidth that has been shown to be available.
ただし、事前にエンコードされたコンテンツが送信されている場合、帯域幅の適応には、そのような適応性に合わせて事前にコード化されたビットストリームを調整する必要があります。 HEVCで利用できる主要なメカニズムは、時間的なスケーラビリティです。メディアセンダーは、送信ビットレートが許容範囲に低下するまで、上位の時間的サブレイヤーに属するNALユニット（つまり、TIDの値が高いNALユニット）を削除できます。 HEVCには、このメモのセクション1.1.2で説明されているように、時間拡張レイヤーの切り替えポイントの軽量識別を可能にするメカニズムが含まれています。 HEVCメディアセンダーは、これらのスイッチングポイントから開始し、利用可能な帯域幅をプローブし、利用可能であることが示されている利用帯域幅にプローブするために、時間拡張レイヤーのNALユニットに属するパケットを送信できます。
Above mechanisms generally work within a defined profile and level and, therefore, no renegotiation of the channel is required. Only when non-downgradable parameters (such as profile) are required to be changed does it become necessary to terminate and restart the RTP stream(s). This may be accomplished by using different RTP payload types.
上記のメカニズムは通常、定義されたプロファイルとレベル内で機能するため、チャネルの再ネゴシエーションは必要ありません。ダウングレードできないパラメーター（プロファイルなど）を変更する必要がある場合のみ、RTPストリームを終了して再起動する必要があります。これは、異なるRTPペイロードタイプを使用することで実現できます。
MANEs MAY remove certain unusable packets from the RTP stream when that RTP stream was damaged due to previous packet losses. This can help reduce the network load in certain special cases. For example, MANES can remove those FUs where the leading FUs belonging to the same NAL unit have been lost or those dependent slice segments when the leading slice segments belonging to the same slice have been lost, because the trailing FUs or dependent slice segments are meaningless to most decoders. MANES can also remove higher temporal scalable layers if the outbound transmission (from the MANE's viewpoint) experiences congestion.
以前のパケット損失が原因でRTPストリームが損傷した場合、MANEはRTPストリームから特定の使用できないパケットを削除する場合があります。これは、特定のケースでネットワーク負荷を軽減するのに役立ちます。たとえば、末尾のFUまたは依存スライスセグメントは無意味であるため、MANESは、同じNALユニットに属する先頭のFUが失われたFUまたは同じスライスに属する先頭のスライスセグメントが失われたときに依存するスライスセグメントを削除できます。ほとんどのデコーダに。 MANESは、（MANEの観点から）アウトバウンド送信が輻輳を経験した場合に、時間的にスケーラブルな上位レイヤーを削除することもできます。
A new media type, as specified in Section 7.1 of this memo, has been registered with IANA.
このメモのセクション7.1で指定されている新しいメディアタイプがIANAに登録されています。
[H.264] ITU-T, "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, April 2013.
[H.264] ITU-T、「汎用オーディオビジュアルサービス用の高度なビデオコーディング」、ITU-T勧告H.264、2013年4月。
[HEVC] ITU-T, "High efficiency video coding", ITU-T Recommendation H.265, April 2013.
[HEVC] ITU-T、「高効率ビデオコーディング」、ITU-T勧告H.265、2013年4月。
[ISO23008-2] ISO/IEC, "Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 2: High efficiency video coding", ISO/IEC 23008-2, 2013.
[ISO23008-2] ISO / IEC、「情報技術-異種環境での高効率コーディングとメディア配信-パート2：高効率ビデオコーディング」、ISO / IEC 23008-2、2013。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。
[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, <http://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月、 <http://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, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<http：//www.rfc-editor。 org / info / rfc3551>。
[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, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[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, <http://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月、<http://www.rfc-editor.org/info/rfc4585>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバック付きのRTPオーディオビジュアルプロファイルのコーデック制御メッセージ（AVPF）」、RFC 5104、DOI 10.17487 / RFC5104、2月2008、<http://www.rfc-editor.org/info/rfc5104>。
[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, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「Session Description Protocol（SDP）のソース固有のメディア属性」、RFC 5576、DOI 10.17487 / RFC5576、2009年6月、<http：// www.rfc-editor.org/info/rfc5576>。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, <http://www.rfc-editor.org/info/rfc5583>.
[RFC5583] Schierl、T。およびS. Wenger、「Session Description Protocol（SDP）のシグナリングメディアデコードの依存関係」、RFC 5583、DOI 10.17487 / RFC5583、2009年7月、<http://www.rfc-editor.org / info / rfc5583>。
[3GPDASH] 3GPP, "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)", 3GPP TS 26.247 12.1.0, December 2013.
[3GPDASH] 3GPP、「透過的なエンドツーエンドのパケット交換ストリーミングサービス（PSS）;プログレッシブダウンロードとHTTPを介した動的適応ストリーミング（3GP-DASH）」、3GPP TS 26.247 12.1.0、2013年12月。
[3GPPFF] 3GPP, "Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244 12.20, December 2013.
[3GPPFF] 3GPP、「透過的なエンドツーエンドのパケット交換ストリーミングサービス（PSS）; 3GPPファイル形式（3GP）」、3GPP TS 26.244 12.20、2013年12月。
[CABAC] Sole, J., Joshi, R., Nguyen, N., Ji, T., Karczewicz, M., Clare, G., Henry, F., and Duenas, A., "Transform coefficient coding in HEVC", IEEE Transactions on Circuts and Systems for Video Technology, Vol. 22, No. 12, pp. 1765-1777, DOI 10.1109/TCSVT.2012.2223055, December 2012.
[CABAC] Sole、J.、Joshi、R.、Nguyen、N.、Ji、T.、Karczewicz、M.、Clare、G.、Henry、F。、およびDuenas、A。、「HEVCでの係数変換コーディング"、ビデオ技術のためのサーカットとシステムに関するIEEEトランザクション、Vol。 22、No。12、1765-1777ページ、DOI 10.1109 / TCSVT.2012.2223055、2012年12月。
[Girod99] Girod, B. and Faerber, F., "Feedback-based error control for mobile video transmission", Proceedings of the IEEE, Vol. 87, No. 10, pp. 1707-1723, DOI 10.1109/5.790632, October 1999.
[Girod99] Girod、B。およびFaerber、F。、「モバイルビデオ伝送のためのフィードバックベースのエラー制御」、IEEE、Vol。 87、No。10、pp。1707-1723、DOI 10.1109 / 5.790632、1999年10月。
[H.265.1] ITU-T, "Conformance specification for ITU-T H.265 high efficiency video coding", ITU-T Recommendation H.265.1, October 2014.
[H.265.1] ITU-T、「ITU-T H.265高効率ビデオコーディングの適合仕様」、ITU-T勧告H.265.1、2014年10月。
[HEVCv2] Flynn, D., Naccari, M., Rosewarne, C., Sharman, K., Sole, J., Sullivan, G. J., and T. Suzuki, "High Efficiency Video Coding (HEVC) Range Extensions text specification: Draft 7", JCT-VC document JCTVC-Q1005, 17th JCT-VC meeting, Valencia, Spain, March/April 2014.
[HEVCv2] Flynn、D.、Naccari、M.、Rosewarne、C.、Sharman、K.、Sole、J.、Sullivan、GJ、およびT. Suzuki、「High Efficiency Video Coding（HEVC）Range Extensions text specification：ドラフト7インチ、JCT-VCドキュメントJCTVC-Q1005、第17回JCT-VCミーティング、スペイン、バレンシア、2014年3月/ 4月。
[IS014496-12] IS0/IEC, "Information technology - Coding of audio-visual objects - Part 12: ISO base media file format", IS0/IEC 14496-12, 2015.
[IS014496-12] IS0 / IEC、「情報技術-視聴覚オブジェクトのコーディング-パート12：ISOベースのメディアファイル形式」、IS0 / IEC 14496-12、2015。
[IS015444-12] IS0/IEC, "Information technology - JPEG 2000 image coding system - Part 12: ISO base media file format", IS0/IEC 15444-12, 2015.
[IS015444-12] IS0 / IEC、「情報技術-JPEG 2000画像コーディングシステム-パート12：ISOベースのメディアファイル形式」、IS0 / IEC 15444-12、2015。
[JCTVC-J0107] Wang, Y.-K., Chen, Y., Joshi, R., and Ramasubramonian, K., "AHG9: On RAP pictures", JCT-VC document JCTVC-L0107, 10th JCT-VC meeting, Stockholm, Sweden, July 2012.
[JCTVC-J0107] Wang、Y.-K.、Chen、Y.、Joshi、R。、およびRamasubramonian、K。、「AHG9：On RAP pictures」、JCT-VCドキュメントJCTVC-L0107、第10回JCT-VCミーティング、ストックホルム、スウェーデン、2012年7月。
[MPEG2S] ISO/IEC, "Information technology - Generic coding of moving pictures and associated audio information - Part 1: Systems", ISO International Standard 13818-1, 2013.
[MPEG2S] ISO / IEC、「情報技術-動画および関連するオーディオ情報の一般的なコーディング-パート1：システム」、ISO国際規格13818-1、2013。
[MPEGDASH] ISO/IEC, "Information technology - Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", ISO International Standard 23009-1, 2012.
[MPEGDASH] ISO / IEC、「情報技術-ダイナミックアダプティブストリーミングHTTP（DASH）-パート1：メディアプレゼンテーションの説明とセグメントフォーマット」、ISO国際規格23009-1、2012年。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、DOI 10.17487 / RFC2326、1998年4月、<http：//www.rfc-editor。 org / info / rfc2326>。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、DOI 10.17487 / RFC2974、2000年10月、<http://www.rfc-editor.org/info/ rfc2974>。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <http://www.rfc-editor.org/info/rfc6051>.
[RFC6051] Perkins、C。およびT. Schierl、「RTPフローの迅速な同期」、RFC 6051、DOI 10.17487 / RFC6051、2010年11月、<http://www.rfc-editor.org/info/rfc6051>。
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, <http://www.rfc-editor.org/info/rfc6184>.
[RFC6184] Wang、Y.-K.、Even、R.、Kristensen、T.、R。Jesup、「RTP Payload Format for H.264 Video」、RFC 6184、DOI 10.17487 / RFC6184、2011年5月、<http ：//www.rfc-editor.org/info/rfc6184>。
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>.
[RFC6190] Wenger、S.、Wang、Y.-K.、Schierl、T。、およびA. Eleftheriadis、「RTP Payload Format for Scalable Video Coding」、RFC 6190、DOI 10.17487 / RFC6190、May 2011、<http： //www.rfc-editor.org/info/rfc6190>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://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, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<http：//www.rfc- editor.org/info/rfc7202>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、編、「リアルタイムの転送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」、 RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<http://www.rfc-editor.org/info/rfc7656>。
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.
[RFC7667] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<http://www.rfc-editor.org/info/rfc7667>。
[RTP-MULTI-STREAM] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", Work in Progress, draft-ietf-avtcore-rtp-multi-stream-11, December 2015.
[RTP-MULTI-STREAM] Lennox、J.、Westerlund、M.、Wu、Q。、およびC. Perkins、「単一のRTPセッションでの複数のメディアストリームの送信」、作業中、draft-ietf-avtcore-rtp -multi-stream-11、2015年12月。
[SDP-NEG] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Medai Multiplexing Using Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-25, January 2016.
[SDP-NEG] Holmberg、C.、Alvestrand、H。、およびC. Jennings、「Session Description Protocol（SDP）を使用したMedai多重化のネゴシエーション」、作業中、draft-ietf-mmusic-sdp-bundle-negotiation-25 、2016年1月。
[Wang05] Wang, Y.-K., Zhu, C., and Li, H., "Error resilient video coding using flexible reference fames", Visual Communications and Image Processing 2005 (VCIP 2005), Beijing, China, July 2005.
[Wang05] Wang、Y.-K.、Zhu、C。、およびLi、H。、「柔軟な参照フレームを使用したエラー耐性のあるビデオコーディング」、Visual Communications and Image Processing 2005（VCIP 2005）、北京、中国、2005年7月。
Acknowledgements
謝辞
Muhammed Coban and Marta Karczewicz are thanked for discussions on the specification of the use with feedback messages and other aspects in this memo. Jonathan Lennox and Jill Boyce are thanked for their contributions to the PACI design included in this memo. Rickard Sjoberg, Arild Fuldseth, Bo Burman, Magnus Westerlund, and Tom Kristensen are thanked for their contributions to signaling related to parallel processing. Magnus Westerlund, Jonathan Lennox, Bernard Aboba, Jonatan Samuelsson, Roni Even, Rickard Sjoberg, Sachin Deshpande, Woo Johnman, Mo Zanaty, Ross Finlayson, Danny Hong, Bo Burman, Ben Campbell, Brian Carpenter, Qin Wu, Stephen Farrell, and Min Wang made valuable review comments that led to improvements.
Muhammed CobanとMarta Karczewiczは、このメモのフィードバックメッセージやその他の側面での使用の仕様についての議論に感謝しています。ジョナサンレノックスとジルボイスは、このメモに含まれているPACIデザインへの貢献に感謝します。 Rickard Sjoberg、Arild Fuldseth、Bo Burman、Magnus Westerlund、Tom Kristensenは、並列処理に関連するシグナリングへの貢献に感謝しています。マグナスウェスターランド、ジョナサンレノックス、バーナードアボバ、ジョナタンサミュエルソン、ロニイブン、リッカードシェーバーグ、サチンデシュパンデ、ウージョンマン、モーザナティー、ロスフィンレイソン、ダニーホン、ボーバーマン、ベンキャンベル、ブライアンカーペンター、キンウー、スティーブンファレル、ミンWangは改善につながる貴重なレビューコメントを行いました。
Authors' Addresses
著者のアドレス
Ye-Kui Wang Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 United States Phone: +1-858-651-8345 Email: yekui.wang@gmail.com
Ye-Kui Wang Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121 United States電話：+ 1-858-651-8345メール：yekui.wang@gmail.com
Yago Sanchez Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany Phone: +49 30 31002-663 Email: yago.sanchez@hhi.fraunhofer.de
Yago Sanchez Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany電話：+49 30 31002-663メール：yago.sanchez@hhi.fraunhofer.de
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany Phone: +49-30-31002-227 Email: thomas.schierl@hhi.fraunhofer.de
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany電話：+ 49-30-31002-227メール：thomas.schierl@hhi.fraunhofer.de
Stephan Wenger Vidyo, Inc. 433 Hackensack Ave., 7th floor Hackensack, NJ 07601 United States Phone: +1-415-713-5473 Email: stewe@stewe.org
Stephan Wenger Vidyo、Inc. 433 Hackensack Ave.、7th floor Hackensack、NJ 07601 United States電話：+ 1-415-713-5473メール：stewe@stewe.org
Miska M. Hannuksela Nokia Corporation P.O. Box 1000 33721 Tampere Finland Phone: +358-7180-08000 Email: miska.hannuksela@nokia.com
Miska M. Hannuksela Nokia Corporation P.O. Box 1000 33721タンペレフィンランド電話：+ 358-7180-08000メール：miska.hannuksela@nokia.com