[要約] RFC 9328はVVC仕様に対するRTPペイロードフォーマットを記述しており、JVETによって開発された。このフォーマットは、1つ以上のNALユニットをRTPパケットにパケット化し、NALユニットを複数のRTPパケットに分割することが可能であり、ビデオ会議、インターネット動画ストリーミング、高ビットレートのエンターテイメント品質のビデオなど、幅広いアプリケーションで利用される。
Internet Engineering Task Force (IETF) S. Zhao
Request for Comments: 9328 Intel
Category: Standards Track S. Wenger
ISSN: 2070-1721 Tencent
Y. Sanchez
Fraunhofer HHI
Y.-K. Wang
Bytedance Inc.
M. M Hannuksela
Nokia Technologies
December 2022
RTP Payload Format for Versatile Video Coding (VVC)
汎用ビデオコーディング（VVC）用のRTPペイロード形式
Abstract
概要
This memo describes an RTP payload format for the Versatile Video Coding (VVC) specification, which was published as both ITU-T Recommendation H.266 and ISO/IEC International Standard 23090-3. VVC was developed by the Joint Video Experts Team (JVET). 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. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications.
このメモでは、ITU-T推奨H.266とISO/IEC International Standard 23090-3の両方として公開された汎用性のあるビデオコーディング（VVC）仕様のRTPペイロード形式について説明します。VVCは、共同ビデオエキスパートチーム（JVET）によって開発されました。RTPペイロード形式により、各RTPパケットペイロードに1つ以上のネットワーク抽象化レイヤー（NAL）ユニットをパケット化すること、およびNALユニットの複数のRTPパケットへの断片化が可能になります。ペイロード形式は、ビデオ会議、インターネットビデオストリーミング、および高ビットレートのエンターテイメント品質のビデオなど、他のアプリケーションの幅広い適用性を備えています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9328.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9328で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Overview of the VVC Codec
1.1.1. Coding-Tool Features (Informative)
1.1.2. Systems and Transport Interfaces (Informative)
1.1.3. High-Level Picture Partitioning (Informative)
1.1.4. NAL Unit Header
1.2. Overview of the Payload Format
2. Conventions
3. Definitions and Abbreviations
3.1. Definitions
3.1.1. Definitions from the VVC Specification
3.1.2. Definitions Specific to This Memo
3.2. Abbreviations
4. RTP Payload Format
4.1. RTP Header Usage
4.2. Payload Header Usage
4.3. Payload Structures
4.3.1. Single NAL Unit Packets
4.3.2. Aggregation Packets (APs)
4.3.3. Fragmentation Units
4.4. Decoding Order Number
5. Packetization Rules
6. De-packetization Process
7. Payload Format Parameters
7.1. Media Type Registration
7.2. Optional Parameters Definition
7.3. SDP Parameters
7.3.1. Mapping of Payload Type Parameters to SDP
7.3.2. Usage with SDP Offer/Answer Model
7.3.3. Multicast
7.3.4. Usage in Declarative Session Descriptions
7.3.5. Considerations for Parameter Sets
8. Use with Feedback Messages
8.1. Picture Loss Indication (PLI)
8.2. Full Intra Request (FIR)
9. Security Considerations
10. Congestion Control
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Authors' Addresses
The Versatile Video Coding specification was formally published as both ITU-T Recommendation H.266 [VVC] and ISO/IEC International Standard 23090-3 [ISO23090-3]. VVC is reported to provide significant coding efficiency gains over High Efficiency Video Coding [HEVC], also known as H.265, and other earlier video codecs.
汎用性の高いビデオコーディング仕様は、ITU-T推奨H.266 [VVC]とISO/IEC International Standard 23090-3 [ISO23090-3]の両方として正式に公開されました。VVCは、H.265およびその他の以前のビデオコーデックとしても知られる高効率ビデオコーディング[HEVC]よりも有意なコーディング効率の向上を提供すると報告されています。
This memo specifies an RTP payload format for VVC. It shares its basic design with the NAL-unit-based RTP payload formats of Advanced Video Coding (AVC) [RFC6184], Scalable Video Coding (SVC) [RFC6190], and High Efficiency Video Coding (HEVC) [RFC7798], as well as their respective predecessors. 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 [RFC6184] is widely deployed and generally known in the relevant implementer communities. Certain scalability-related mechanisms known from [RFC6190] were incorporated into this document, as VVC version 1 supports temporal, spatial, and signal-to-noise ratio (SNR) scalability.
このメモは、VVCのRTPペイロード形式を指定します。高度なビデオコーディング（AVC）[RFC6184]、スケーラブルビデオコーディング（SVC）[RFC6190]、高効率ビデオコーディング（HEVC）[RFC7798]のNALユニットベースのRTPペイロードフォーマットと基本設計を共有しています。それぞれの前任者として。設計哲学、セキュリティ、混雑制御、および全体的な実装の複雑さに関して、以前のペイロード形式の仕様と同様の特性を備えています。少なくとも[RFC6184]は広く展開され、関連する実装コミュニティで一般的に知られているため、これは意識的な選択です。[RFC6190]から知られている特定のスケーラビリティ関連メカニズムは、VVCバージョン1が時間、空間、および信号対雑音比（SNR）スケーラビリティをサポートするため、このドキュメントに組み込まれました。
VVC and HEVC share a similar hybrid video codec design. In this memo, we provide a very brief overview of those features of VVC 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 VVC to arrive at interoperable, well-performing implementations.
VVCとHEVCは、同様のハイブリッドビデオコーデックデザインを共有しています。このメモでは、本明細書で指定されているペイロード形式で扱われる何らかの形で、VVCのこれらの機能の非常に簡単な概要を提供します。実装者は、VVCに関連するITU-T/ISO/IEC仕様を読み、理解し、適用して、相互運用可能でパフォーマンスの高い実装に到達する必要があります。
Conceptually, both VVC and HEVC include a Video Coding Layer (VCL), which is often used to refer to the coding-tool features, and a NAL, which is often used to refer to the systems and transport interface aspects of the codecs.
概念的には、VVCとHEVCの両方にビデオコーディングレイヤー（VCL）が含まれています。これは、コーディングツール機能を参照するためによく使用されます。また、Codecsのシステムを参照し、インターフェイスの側面を輸送するために使用されることがよくあります。
Coding-tool features are described below with occasional reference to the coding-tool set of HEVC, which is well known in the community.
コーディングツールの機能は、コミュニティでよく知られているHEVCのコーディングツールセットを時折参照して以下で説明します。
Similar to earlier hybrid-video-coding-based standards, including HEVC, the following basic video coding design is employed by VVC. 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, VVC includes several tools to make the implementation on parallel architectures easier.
HEVCを含む以前のハイブリッドビデオコーディングベースの標準と同様に、次の基本的なビデオコーディング設計がVVCで採用されています。予測信号は、最初にモーション補償予測または動き補償のいずれかによって形成され、残差（元の予測と予測の差）がコーディングされます。コーディング効率の利益は、以前の設計上のコーデックのほぼすべての部分を再設計および改善することで達成されます。さらに、VVCには、並列アーキテクチャの実装を簡単にするためのいくつかのツールが含まれています。
Finally, VVC includes temporal, spatial, and SNR scalability, as well as multiview coding support.
最後に、VVCには、時間、空間、およびSNRスケーラビリティ、およびマルチビューコーディングサポートが含まれます。
Coding blocks and transform structure Among major coding-tool differences between HEVC and VVC, one of the important improvements is the more flexible coding tree structure in VVC, i.e., multi-type tree. In addition to quadtree, binary and ternary trees are also supported, which contributes significant improvement in coding efficiency. Moreover, the maximum size of a coding tree unit (CTU) is increased from 64x64 to 128x128. To improve the coding efficiency of chroma signal, luma-chroma-separated trees at CTU level may be employed for intra slices. The square transforms in HEVC are extended to non-square transforms for rectangular blocks resulting from binary and ternary tree splits. Besides, VVC supports multiple transform sets (MTSs), including DCT-2, DST-7, and DCT-8, as well as the non-separable secondary transform. The transforms used in VVC can have different sizes with support for larger transform sizes. For DCT-2, the transform sizes range from 2x2 to 64x64, and for DST-7 and DCT-8, the transform sizes range from 4x4 to 32x32. In addition, VVC also support sub-block transform for both intra- and inter-coded blocks. For intra-coded blocks, intra sub-partitioning (ISP) may be used to allow sub-block-based intra prediction and transform. For inter blocks, sub-block transform may be used assuming that only a part of an inter block has non-zero transform coefficients.
HEVCとVVCの主要なコーディングツールの違いのコーディングブロックと変換構造は、重要な改善の1つは、VVCのより柔軟なコーディングツリー構造、つまりマルチタイプツリーです。Quadtreeに加えて、バイナリと3成分の木もサポートされており、これがコーディング効率の大幅な改善に貢献しています。さらに、コーディングツリーユニット（CTU）の最大サイズは64x64から128x128に増加します。クロマシグナルのコーディング効率を改善するために、CTUレベルでのルーマ節節を分離した木をスライス内に使用することができます。HEVCの正方形の変換は、バイナリおよび三元ツリーの分割に起因する長方形ブロックの非二乗変換に拡張されます。また、VVCは、DCT-2、DST-7、DCT-8を含む複数の変換セット（MTSS）、および分離不可能な二次変換をサポートしています。VVCで使用される変換は、より大きな変換サイズをサポートするさまざまなサイズを持つことができます。DCT-2の場合、変換サイズは2x2から64x64の範囲であり、DST-7およびDCT-8の場合、変換サイズは4x4から32x32の範囲です。さらに、VVCは、コード中のブロック内とインターコード化された両方のブロックのサブブロック変換もサポートしています。コード中のブロックの場合、サブブロックベースの予測と変換を可能にするために、サブパーティション内（ISP）を使用できます。インターブロックの場合、インターブロックの一部のみが非ゼロ変換係数を持っていると仮定して、サブブロック変換を使用できます。
Entropy coding Similar to HEVC, VVC uses a single entropy-coding engine, which is based on context adaptive binary arithmetic coding [CABAC] but with the support of multi-window sizes. The window sizes can be initialized differently for different context models. Due to such a design, it has more efficient adaptation speed and better coding efficiency. A joint chroma residual coding scheme is applied to further exploit the correlation between the residuals of two color components. In VVC, different residual coding schemes are applied for regular transform coefficients and residual samples generated using transform-skip mode.
HEVCと同様のエントロピーコーディングVVCは、コンテキスト適応バイナリ算術コーディング[CABAC]に基づいた単一のエントロピーコーディングエンジンを使用しますが、マルチウィンドウサイズをサポートしています。さまざまなコンテキストモデルで、ウィンドウのサイズを異なる方法で初期化できます。このような設計により、より効率的な適応速度とコーディング効率が向上しています。ジョイントクロマ残留コーディングスキームが適用され、2つのカラーコンポーネントの残差間の相関関係をさらに活用します。VVCでは、異なる残留コーディングスキームが、transform-skipモードを使用して生成された通常の変換係数と残留サンプルに適用されます。
In-loop filtering VVC has more feature support in loop filters than HEVC. The deblocking filter in VVC is similar to HEVC but operates at a smaller grid. After deblocking and sample adaptive offset (SAO), an adaptive loop filter (ALF) may be used. As a Wiener filter, ALF reduces distortion of decoded pictures. Besides, VVC introduces a new module called luma mapping with chroma scaling to fully utilize the dynamic range of signal so that rate-distortion performance of both Standard Dynamic Range (SDR) and High Dynamic Range (HDR) content is improved.
ループフィルタリングVVCには、HEVCよりもループフィルターの機能サポートがあります。VVCのデブロッキングフィルターはHEVCに似ていますが、より小さなグリッドで動作します。デブロッキングおよびサンプル適応オフセット（SAO）の後、適応ループフィルター（ALF）を使用できます。Wienerフィルターとして、ALFはデコードされた写真の歪みを減らします。また、VVCは、Chroma Scalingを使用したLumaマッピングと呼ばれる新しいモジュールを導入して、ダイナミックレンジの信号を完全に活用して、標準動的範囲（SDR）と高ダイナミックレンジ（HDR）コンテンツの両方のレート歪みパフォーマンスを改善します。
Motion prediction and coding Compared to HEVC, VVC introduces several improvements in this area. First, there is the adaptive motion vector resolution (AMVR), which can save bit cost for motion vectors by adaptively signaling motion vector resolution. Then, the affine motion compensation is included to capture complicated motion-like zooming and rotation. Meanwhile, prediction refinement with the optical flow (PROF) with affine mode is further deployed to mimic affine motion at the pixel level. Thirdly, the decoder-side motion vector refinement (DMVR) is a method to derive the motion vector at the decoder side based on block matching so that fewer bits may be spent on motion vectors. Bidirectional optical flow (BDOF) is a similar method to PROF. BDOF adds a sample-wise offset at the 4x4 sub-block level that is derived with equations based on gradients of the prediction samples and a motion difference relative to coding-unit (CU) motion vectors. Furthermore, merge with motion vector difference (MMVD) is a special mode that further signals a limited set of motion vector differences on top of merge mode. In addition to MMVD, there are another three types of special merge modes, i.e., sub-block merge, triangle, and combined intra/inter prediction (CIIP). The sub-block merge list includes one candidate of sub-block temporal motion vector prediction (SbTMVP) and up to four candidates of affine motion vectors. Triangle is based on triangular block motion compensation. CIIP combines intra and inter predictions with weighting. Adaptive weighting may be employed with a block-level tool called bi-prediction with CU-based weighting (BCW), which provides more flexibility than in HEVC.
モーション予測とコーディングはHEVCと比較して、この分野でいくつかの改善を導入します。まず、適応的なシグナル伝達運動ベクトル解像度によりモーションベクトルのビットコストを節約できる適応運動ベクトル解像度（AMVR）があります。次に、複雑な動きのようなズームと回転をキャプチャするために、アフィンモーション補償が含まれます。一方、アフィンモードを使用した光フロー（Prof）による予測の改良は、ピクセルレベルでアフィンモーションを模倣するようにさらに展開されます。第三に、デコーダーサイドの動きベクトル洗練（DMVR）は、モーションベクトルに使用されるビットが少なくなるように、ブロックマッチングに基づいてデコーダー側のモーションベクトルを導出する方法です。双方向光流（BDOF）は、教授と同様の方法です。BDOFは、4x4サブブロックレベルでサンプルごとのオフセットを追加します。これは、予測サンプルの勾配と、コーディングユニット（CU）モーションベクトルと比較したモーション差に基づいて方程式で導出されます。さらに、モーションベクトルの差（MMVD）とのマージは、マージモードの上部に制限されたモーションベクトルの差をさらに示す特別なモードです。MMVDに加えて、別の3種類の特別なマージモード、つまりサブブロックマージ、三角形、および組み合わせたインター/インター予測（CIIP）があります。サブブロックマージリストには、サブブロック時間運動ベクトル予測（SBTMVP）の1つの候補と、アフィン運動ベクトルの最大4つの候補が含まれます。三角形は、三角形のブロック運動補償に基づいています。CIIPは、イントラとインターの予測と重み付けを組み合わせています。適応型重み付けは、CUベースの重み付け（BCW）を備えたBiredictionと呼ばれるブロックレベルのツールで使用できます。これは、HEVCよりも柔軟性を提供します。
Intra prediction and intra coding To capture the diversified local image texture directions with finer granularity, VVC supports 65 angular directions instead of 33 directions in HEVC. The intra mode coding is based on a 6- most-probable-modes scheme, and the 6 most probable modes are derived using the neighboring intra prediction directions. In addition, to deal with the different distributions of intra prediction angles for different block aspect ratios, a wide-angle-intra-prediction (WAIP) scheme is applied in VVC by including intra prediction angles beyond those present in HEVC. Unlike HEVC, which only allows using the most adjacent line of reference samples for intra prediction, VVC also allows using two further reference lines, known as multi-reference-line (MRL) intra prediction. The additional reference lines can be only used for the 6 most probable intra prediction modes. To capture the strong correlation between different color components, in VVC, a cross-component linear mode (CCLM) is utilized, which assumes a linear relationship between the luma sample values and their associated chroma samples. For intra prediction, VVC also applies a position-dependent prediction combination (PDPC) for refining the prediction samples closer to the intra prediction block boundary. Matrix-based intra prediction (MIP) modes are also used in VVC, which generates an up to 8x8 intra prediction block using a weighted sum of downsampled neighboring reference samples, and the weights are hard-coded constants.
VVCは、多様なローカル画像テクスチャ方向をキャプチャするための予測とコード内で、HEVCの33方向ではなく65の角度方向をサポートしています。イントラモードコーディングは、6つの最も確率的モードスキームに基づいており、6つの最も可能性の高いモードは、隣接する予測方向を使用して導出されます。さらに、さまざまなブロックアスペクト比の異なる予測角度の異なる分布に対処するために、HEVCに存在するものを超えて予測角を含めることにより、VVCに広角内予測（WAIP）スキームが適用されます。VVCは、最も隣接する参照サンプルのみを使用できるHEVCとは異なり、Multi-Reference-Line（MRL）イントラ予測として知られる2つの参照線を使用することもできます。追加の参照線は、最も可能性の高い6つの予測モードにのみ使用できます。異なる色成分間の強い相関をキャプチャするために、VVCでは、クロスコンポーネント線形モード（CCLM）が利用されます。これは、LUMAサンプル値と関連するChromaサンプルの間の線形関係を想定しています。イントラ予測のために、VVCは、予測ブロック境界に近い予測サンプルを改良するために、位置依存予測の組み合わせ（PDPC）も適用します。マトリックスベースのイントラ予測（MIP）モードは、VVCでも使用されます。これは、ダウンサンプリング隣接参照サンプルの加重合計を使用して最大8x8の予測ブロックを生成し、重みはハードコーディング定数です。
Other coding-tool features VVC introduces dependent quantization (DQ) to reduce quantization error by state-based switching between two quantizers.
その他のコーディングツール機能VVCは、2つの量子イオンタイザー間の状態ベースの切り替えにより、依存量量子化（DQ）を導入して、量子化誤差を減らします。
VVC inherits the basic systems and transport interface designs from HEVC and AVC. 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 scalability features of VVC are conceptually similar to the scalable extension of HEVC, known as SHVC. The hierarchical syntax and data unit structure consists of parameter sets at various levels (i.e., decoder, sequence (pertaining to all), sequence (pertaining to a single), and picture), picture-level header parameters, slice-level header parameters, and lower-level parameters.
VVCは、HEVCおよびAVCから基本的なシステムおよびトランスポートインターフェイス設計を継承します。これらには、NALユニットベースの構文構造、階層的構文とデータユニット構造、補足強化情報（SEI）メッセージメカニズム、および仮説参照デコーダー（HRD）に基づくビデオバッファリングモデルが含まれます。VVCのスケーラビリティ機能は、SHVCとして知られるHEVCのスケーラブルな拡張に概念的に似ています。階層的構文とデータユニット構造は、さまざまなレベル（つまり、デコーダー、シーケンス（すべてに関連する）、シーケンス（単一に関連）、および画像）、画像レベルのヘッダーパラメーター、スライスレベルヘッダーパラメーター、および低レベルのパラメーター。
A number of key components that influenced the network abstraction layer design of VVC, as well as this memo, are described below
VVCのネットワーク抽象化レイヤー設計に影響を与えた多くの重要なコンポーネントと、このメモを以下に説明します
Decoding capability information The decoding capability information (DCI) includes parameters that stay constant for the lifetime of a VVC bitstream in the duration of a video conference, continuous video stream, and similar, i.e., any video that is processed by a decoder between setup and teardown. For streaming, the requirement of constant parameters pertains through splicing. Such information includes profile, level, and sub-profile information to determine a maximum capability interop point that is guaranteed to never be exceeded, even if splicing of video sequences occurs within a session. It further includes constraint fields (most of which are flags), which can optionally be set to indicate that the video bitstream will be constrained in the use of certain features, as indicated by the values of those fields. With this, a bitstream can be labeled as not using certain tools, which allows, among other things, for resource allocation in a decoder implementation.
デコード機能情報デコード機能情報（DCI）には、ビデオ会議、連続ビデオストリームなどのVVCビットストリームの寿命が一定のパラメーターが含まれています。取り壊す。ストリーミングの場合、一定のパラメーターの要件はスプライシングを通じて関係します。このような情報には、セッション内でビデオシーケンスのスプライシングが発生した場合でも、プロファイル、レベル、およびサブプロファイル情報が含まれています。さらに、制約フィールド（そのほとんどはフラグ）が含まれます。これは、これらのフィールドの値で示されるように、ビデオビットストリームが特定の機能の使用に制約されることを示すようにオプションに設定できます。これにより、ビットストリームは特定のツールを使用していないとラベル付けできます。これにより、とりわけ、デコーダーの実装でのリソース割り当てのために可能なことが可能です。
Video parameter set The video parameter set (VPS) pertains to one or more coded video sequences (CVSs) of multiple layers covering the same range of access units and includes, among other information, decoding dependency expressed as information for reference-picture-list construction of enhancement layers. The VPS provides a "big picture" of a scalable sequence, 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. One VPS may be referenced by one or more sequence parameter sets.
ビデオパラメーター設定ビデオパラメーターセット（VPS）は、同じ範囲のアクセスユニットをカバーする複数のレイヤーの1つまたは複数のコード化されたビデオシーケンス（CVSS）に関係し、他の情報の中でも、参照ピクチャリスト構造の情報として表される依存関係を解読することを含む強化層の。VPSは、どのタイプの操作ポイントが提供されるかなど、スケーラブルなシーケンスの「全体像」を提供します。操作ポイントのプロファイル、層、およびレベル。また、セッション交渉とコンテンツ選択の基礎として使用できるビットストリームの他の高レベルのプロパティ。1つのVPは、1つ以上のシーケンスパラメーターセットで参照できます。
Sequence parameter set The sequence parameter set (SPS) contains syntax elements pertaining to a coded layer video sequence (CLVS), which is a group of pictures belonging to the same layer, starting with a random access point, and followed by pictures that may depend on each other until the next random access point picture. In MPEG-2, the equivalent of a CVS was a group of pictures (GOP), which normally started with an I frame and was followed by P and B frames. While more complex in its options of random access points, VVC retains this basic concept. One remarkable difference of VVC is that a CLVS may start with a Gradual Decoding Refresh (GDR) picture without requiring presence of traditional random access points in the bitstream, such as instantaneous decoding refresh (IDR) or clean random access (CRA) pictures. In many TV-like applications, a CVS contains a few hundred milliseconds to a few seconds of video. In video conferencing (without switching Multipoint Control Units (MCUs) involved), a CVS can be as long in duration as the whole session.
シーケンスパラメーター設定シーケンスパラメーターセット（SPS）には、コード付きレイヤービデオシーケンス（CLVS）に関連する構文要素が含まれています。次のランダムアクセスポイント画像までお互いに。MPEG-2では、CVSに相当するものは写真のグループ（GOP）であり、通常はIフレームで始まり、PおよびBフレームが続きました。ランダムアクセスポイントのオプションはより複雑ですが、VVCはこの基本概念を保持しています。VVCの顕著な違いの1つは、CLVが、瞬時デコードリフレッシュ（IDR）やクリーンランダムアクセス（CRA）写真など、ビットストリームに従来のランダムアクセスポイントを存在させることなく、段階的なデコードリフレッシュ（GDR）画像から始まる可能性があることです。多くのテレビのようなアプリケーションでは、CVSには数百ミリ秒から数秒のビデオが含まれています。ビデオ会議（関与するマルチポイント制御ユニット（MCU）を切り替えることなく）では、CVSはセッション全体と同じくらい長くなる可能性があります。
Picture and adaptation parameter set The picture parameter set (PPS) and the adaptation parameter set (APS) carry information pertaining to zero or more pictures and zero or more slices, respectively. The PPS contains information that is likely to stay constant from picture to picture, at least for pictures for a certain type, whereas the APS contains information, such as adaptive loop filter coefficients, that are likely to change from picture to picture or even within a picture. A single APS is referenced by all slices of the same picture if that APS contains information about luma mapping with chroma scaling (LMCS) or a scaling list. Different APSs containing ALF parameters can be referenced by slices of the same picture.
画像と適応パラメーターの設定画像パラメーターセット（PPS）と適応パラメーターセット（APS）は、それぞれゼロ以上の写真とゼロ以上のスライスに関する情報をそれぞれ伝えます。PPSには、少なくとも特定のタイプの写真の場合は、写真ごとに一定のままである可能性が高い情報が含まれていますが、APSには適応ループフィルター係数などの情報が含まれています。写真。単一のAPSは、そのAPがChroma Scaling（LMCS）を使用したLUMAマッピングに関する情報またはスケーリングリストを含む場合、同じ画像のすべてのスライスによって参照されます。ALFパラメーターを含むさまざまなAPSSは、同じ画像のスライスによって参照できます。
Picture header A picture header (PH) contains information that is common to all slices that belong to the same picture. Being able to send that information as a separate NAL unit when pictures are split into several slices allows for saving bitrate, compared to repeating the same information in all slices. However, there might be scenarios where low-bitrate video is transmitted using a single slice per picture. Having a separate NAL unit to convey that information incurs in an overhead for such scenarios. For such scenarios, the picture header syntax structure is directly included in the slice header, instead of its own NAL unit. The mode of the picture header syntax structure being included in its own NAL unit or not can only be switched on/off for an entire CLVS and can only be switched off when, in the entire CLVS, each picture contains only one slice.
画像ヘッダー画像ヘッダー（pH）には、同じ画像に属するすべてのスライスに共通の情報が含まれています。写真がいくつかのスライスに分割されたときに、その情報を別のNALユニットとして送信できると、すべてのスライスで同じ情報を繰り返すのと比較して、ビットレートを保存できます。ただし、画像ごとに1つのスライスを使用して低ビトレートビデオが送信されるシナリオがある場合があります。そのようなシナリオのために、その情報を伝えるために別のNALユニットを持っていることは、そのようなシナリオのオーバーヘッドで発生します。このようなシナリオでは、画像ヘッダーの構文構造は、独自のNALユニットではなく、スライスヘッダーに直接含まれます。独自のNALユニットに含まれている画像ヘッダー構文構造のモードは、CLV全体でのみオン/オフにすることができ、CLV全体で各画像に1つのスライスしか含まれていない場合にのみオフにすることができます。
Profile, tier, and level The profile, tier, and level syntax structures in DCI, VPS, and SPS contain profile, tier, and level information for all layers that refer to the DCI, for layers associated with one or more output layer sets specified by the VPS, and for any layer that refers to the SPS, respectively.
プロファイル、ティア、およびレベルDCI、VPS、およびSPSのプロファイル、ティア、およびレベルの構文は、指定された1つ以上の出力層セットに関連付けられたレイヤーのDCIを参照するすべてのレイヤーのプロファイル、ティア、およびレベル情報を含みます。VPSによって、およびそれぞれSPSを指す任意のレイヤーに対して。
Sub-profiles Within the VVC specification, a sub-profile is a 32-bit number, coded according to ITU-T Recommendation T.35, that does not carry semantics. It is carried in the profile_tier_level structure and hence is (potentially) present in the DCI, VPS, and SPS. External registration bodies can register a T.35 codepoint with ITU-T registration authorities and associate with their registration a description of bitstream restrictions beyond the profiles defined by ITU-T and ISO/IEC. This would allow encoder manufacturers to label the bitstreams generated by their encoder as complying with such sub-profile. It is expected that upstream standardization organizations (such as Digital Video Broadcasting (DVB) and Advanced Television Systems Committee (ATSC)), as well as walled-garden video services, will take advantage of this labeled system. In contrast to "normal" profiles, it is expected that sub-profiles may indicate encoder choices traditionally left open in the (decoder-centric) video coding specifications, such as GOP structures, minimum/maximum Quantizer Parameter (QP) values, and the mandatory use of certain tools or SEI messages.
VVC仕様内のサブプロファイル、サブプロファイルは32ビットの数字であり、Semanticsを運ばないITU-T推奨T.35に従ってコーディングされています。Profile_tier_Level構造で運ばれるため、DCI、VPS、およびSPSには（潜在的に）存在します。外部登録機関は、ITU-T登録当局とT.35 CodePointを登録し、ITU-TおよびISO/IECで定義されたプロファイルを超えたBitStreamの制限の説明を登録に関連付けます。これにより、エンコーダーメーカーは、エンコーダーによって生成されたビットストリームにそのようなサブプロファイルを順守するようにラベルを付けることができます。上流の標準化組織（デジタルビデオブロードキャスト（DVB）や高度なテレビシステム委員会（ATSC）など）、および壁画ビデオサービスがこのラベルの付いたシステムを活用することが期待されています。「通常の」プロファイルとは対照的に、サブプロファイルは、GOP構造、最小/最大量子化器パラメーター（QP）値、および（デコーダー中心の）ビデオコーディング仕様で従来、エンコーダーの選択肢が存在することを示すことが予想されます。特定のツールまたはSEIメッセージの必須使用。
General constraint fields The profile_tier_level structure carries a considerable number of constraint fields (most of which are flags), which an encoder can use to indicate to a decoder that it will not use a certain tool or technology. They were included in reaction to a perceived market need to label a bitstream as not exercising a certain tool that has become commercially unviable.
一般的な制約フィールドprofile_tier_level構造には、かなりの数の制約フィールド（そのほとんどがフラグ）を搭載しています。エンコーダーは、特定のツールまたはテクノロジーを使用しないことをデコーダーに示すために使用できます。それらは、商業的に実行不可能になった特定のツールを行使していないものとしてビットストリームにラベルを付けるために認識された市場の必要性に反応して含まれていました。
Temporal scalability support VVC includes support of temporal scalability, by the inclusion of the signaling of TemporalId in the NAL unit header, the restriction that pictures of a particular temporal sublayer cannot be used for inter prediction reference by pictures of a lower temporal sublayer, 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.
時間的スケーラビリティサポートVVCには、NALユニットヘッダーにトイレリドのシグナル伝達を含めることにより、時間のスケーラビリティのサポートが含まれます。 - ビットストリーム抽出プロセス、および各サブビットストリーム抽出出力が適合ビットストリームであるという要件。メディア認識ネットワーク要素（MANES）は、時間的スケーラビリティに基づいて、ストリーム適応目的でNALユニットヘッダーのトイレリドを利用できます。
Reference picture resampling (RPR) In AVC and HEVC, the spatial resolution of pictures cannot change unless a new sequence using a new SPS starts, with an intra random access point (IRAP) picture. VVC enables picture resolution change within a sequence at a position without encoding an IRAP picture, which is always intra coded. This feature is sometimes referred to as reference picture resampling (RPR), as the feature needs resampling of a reference picture used for inter prediction when that reference picture has a different resolution than the current picture being decoded. RPR allows resolution change without the need of coding an IRAP picture and hence avoids a momentary bit rate spike caused by an IRAP picture in streaming or video conferencing scenarios, e.g., to cope with network condition changes. RPR can also be used in application scenarios wherein zooming of the entire video region or some region of interest is needed.
AVCおよびHEVCでの参照画像の再サンプリング（RPR）では、新しいSPSを使用した新しいシーケンスが起動しない限り、画像の空間解像度は変更できません。VVCは、常にコード化されているIRAP画像をエンコードせずに、位置のシーケンス内の画像解像度の変更を可能にします。この機能は、その参照画像が現在の画像がデコードされているものとは異なる解像度を持っている場合、インター予測に使用される参照画像の再サンプリングが必要であるため、参照画像の再サンプリング（RPR）と呼ばれることもあります。RPRは、IRAP画像をコーディングする必要なく解像度の変更を可能にするため、ネットワーク状態の変更に対処するために、ストリーミングまたはビデオ会議シナリオのIRAP画像によって引き起こされる瞬間的なビットレートスパイクを回避します。RPRは、ビデオ領域全体のズームまたは関心のある領域が必要なアプリケーションシナリオでも使用できます。
Spatial, SNR, and multiview scalability VVC includes support for spatial, SNR, and multiview scalability. Scalable video coding is widely considered to have technical benefits and enrich services for various video applications. Until recently, however, the functionality has not been included in the first version of specifications of the video codecs. In VVC, however, all those forms of scalability are supported in the first version of VVC natively through the signaling of the nuh_layer_id in the NAL unit header, the VPS that associates layers with the given nuh_layer_id to each other, reference picture selection, reference picture resampling for spatial scalability, and a number of other mechanisms not relevant for this memo.
Spatial、SNR、およびMultiview Scalability VVCには、Spatial、SNR、およびMultiviewスケーラビリティのサポートが含まれています。スケーラブルなビデオコーディングは、技術的な利点があり、さまざまなビデオアプリケーションのサービスを充実させると広く考えられています。ただし、最近まで、機能はビデオコーデックの仕様の最初のバージョンに含まれていませんでした。しかし、VVCでは、NALユニットヘッダーのNUH_LAYER_IDのシグナル伝達を通じて、VVCの最初のバージョンのVVCでこれらのすべての形式のスケーラビリティがサポートされています。空間的スケーラビリティの再サンプリング、およびこのメモに関連しない他の多くのメカニズム。
Spatial scalability With the existence of reference picture resampling (RPR), the additional burden for scalability support is just a modification of the high-level syntax (HLS). The inter-layer prediction is employed in a scalable system to improve the coding efficiency of the enhancement layers. In addition to the spatial and temporal motion-compensated predictions that are available in a single-layer codec, the inter-layer prediction in VVC uses the possibly resampled video data of the reconstructed reference picture from a reference layer to predict the current enhancement layer. The resampling process for inter-layer prediction, when used, is performed at the block level, reusing the existing interpolation process for motion compensation in single-layer coding. It means that no additional resampling process is needed to support spatial scalability.
参照画像リサンプリング（RPR）の存在による空間スケーラビリティ、スケーラビリティサポートの追加の負担は、高レベルの構文（HLS）の単なる変更です。層間予測は、強化層のコーディング効率を改善するためにスケーラブルなシステムで採用されています。単一層コーデックで利用可能な空間的および時間的な動き補償予測に加えて、VVCの層間予測は、参照層から再構築された参照画像の再サンプリングされたビデオデータを使用して、現在の強化層を予測します。使用する場合、層間予測の再サンプリングプロセスはブロックレベルで実行され、既存の補間プロセスが単一層コーディングの運動補償のために再利用されます。これは、空間スケーラビリティをサポートするために追加の再サンプリングプロセスが必要ないことを意味します。
SNR scalability SNR scalability is similar to spatial scalability except that the resampling factors are 1:1. In other words, there is no change in resolution, but there is inter-layer prediction.
SNRスケーラビリティSNRスケーラビリティは、再サンプリング係数が1：1であることを除いて、空間スケーラビリティに似ています。言い換えれば、解像度に変化はありませんが、層間予測があります。
Multiview scalability The first version of VVC also supports multiview scalability, wherein a multi-layer bitstream carries layers representing multiple views, and one or more of the represented views can be output at the same time.
MultiView Scalability VVCの最初のバージョンは、マルチビュースケーラビリティもサポートします。マルチレイヤービットストリームは、複数のビューを表すレイヤーを運び、1つ以上の表現ビューを同時に出力できます。
SEI messages Supplemental enhancement information (SEI) messages are information in the bitstream that do not influence the decoding process as specified in the VVC specification but address issues of representation/rendering of the decoded bitstream, label the bitstream for certain applications, and other, similar tasks. The overall concept of SEI messages and many of the messages themselves has been inherited from the AVC and HEVC specifications. Except for the SEI messages that affect the specification of the hypothetical reference decoder (HRD), other SEI messages for use in the VVC environment, which are generally useful also in other video coding technologies, are not included in the main VVC specification but in a companion specification [VSEI].
SEIメッセージ補足拡張情報（SEI）メッセージは、VVC仕様で指定されているデコードプロセスに影響を与えないが、デコードされたビットストリームの表現/レンダリングの問題に対処し、特定のアプリケーションのビットストリームにラベル付けされ、その他の同様の同様の同様の同様の同様の同様の類似したものに対処するビットストリームの情報です。タスク。SEIメッセージと多くのメッセージ自体の全体的な概念は、AVCおよびHEVC仕様から継承されています。仮説参照デコーダー（HRD）の仕様に影響するSEIメッセージを除き、VVC環境で使用する他のSEIメッセージは、一般的に他のビデオコーディングテクノロジーでも役立ちますが、メインVVC仕様には含まれていませんが、コンパニオン仕様[VSEI]。
VVC inherited the concept of tiles and wavefront parallel processing (WPP) from HEVC, with some minor to moderate differences. The basic concept of slices was kept in VVC but designed in an essentially different form. VVC is the first video coding standard that includes subpictures as a feature, which provides the same functionality as HEVC motion-constrained tile sets (MCTSs) but designed differently to have better coding efficiency and to be friendlier for usage in application systems. More details of these differences are described below.
VVCは、HEVCからのタイルと波面並列処理（WPP）の概念を継承し、いくつかのマイナーから中程度の違いがありました。スライスの基本概念はVVCに保持されましたが、本質的に異なる形式で設計されています。VVCは、HEVCモーション制約のタイルセット（MCTS）と同じ機能を提供する機能としてのサブピクチャを含む最初のビデオコーディング標準ですが、コーディング効率が向上し、アプリケーションシステムでの使用に優しいように設計されています。これらの違いの詳細については、以下に説明します。
Tiles and WPP Same as in HEVC, a picture can be split into tile rows and tile columns in VVC, in-picture prediction across tile boundaries is disallowed, etc. However, the syntax for signaling of tile partitioning has been simplified by using a unified syntax design for both the uniform and the non-uniform mode. In addition, signaling of entry point offsets for tiles in the slice header is optional in VVC, while it is mandatory in HEVC. The WPP design in VVC has two differences compared to HEVC: i) the CTU row delay is reduced from two CTUs to one CTU, and ii) signaling of entry point offsets for WPP in the slice header is optional in VVC while it is mandatory in HEVC.
タイルとWPPはHEVCと同じように、VVCのタイル行とタイル列に画像を分割できます。タイル境界全体にわたるピクチャー予測は許可されません。ただし、タイル分配のシグナル伝達の構文は、統一されたものを使用して簡素化されています。ユニフォームモードと不均一モードの両方の構文設計。さらに、スライスヘッダーのタイルのエントリポイントオフセットのシグナルは、VVCではオプションですが、HEVCでは必須です。VVCのWPP設計には、HEVCと比較して2つの違いがあります。i）CTU行遅延は2つのCTUから1つのCTUに減少し、ii）スライスヘッダーのWPPのエントリポイントオフセットのシグナル伝達はVVCではオプションですが、必須です。HEVC。
Slices In VVC, the conventional slices based on CTUs (as in HEVC) or macroblocks (as in AVC) have been removed. The main reasoning behind this architectural change is as follows. The advances in video coding since 2003 (the publication year of AVC v1) have been such that slice-based error concealment has become practically impossible due to the ever-increasing number and efficiency of in-picture and inter-picture prediction mechanisms. An error-concealed picture is the decoding result of a transmitted coded picture for which there is some data loss (e.g., loss of some slices) of the coded picture or a reference picture, as at least some part of the coded picture is not error-free (e.g., that reference picture was an error-concealed picture). For example, when one of the multiple slices of a picture is lost, it may be error-concealed using an interpolation of the neighboring slices. While advanced video coding prediction mechanisms provide significantly higher coding efficiency, they also make it harder for machines to estimate the quality of an error-concealed picture, which was already a hard problem with the use of simpler prediction mechanisms. Advanced in-picture prediction mechanisms also cause the coding efficiency loss due to splitting a picture into multiple slices to be more significant. Furthermore, network conditions become significantly better while, at the same time, techniques for dealing with packet losses have become significantly improved. As a result, very few implementations have recently used slices for maximum-transmission-unit-size matching. Instead, substantially all applications where low-delay error resilience is required (e.g., video telephony and video conferencing) rely on system/transport-level error resilience (e.g., retransmission or forward error correction) and/or picture-based error resilience tools (e.g., feedback-based error resilience, insertion of IRAPs, scalability with a higher protection level of the base layer, and so on). Considering all the above, nowadays, it is very rare that a picture that cannot be correctly decoded is passed to the decoder, and when such a rare case occurs, the system can afford to wait for an error-free picture to be decoded and available for display without resulting in frequent and long periods of picture freezing seen by end users.
VVCのスライス、CTU（HEVCのように）またはマクロブロック（AVCのように）に基づく従来のスライスが除去されています。この建築の変化の背後にある主な理由は次のとおりです。2003年以降のビデオコーディングの進歩（AVC V1の出版年）は、潜在的な数とピクチャー間予測メカニズムの増加数と効率のために、スライスベースのエラーの隠蔽が事実上不可能になるようになっています。エラー制定画像は、コード化された画像または参照画像のデータ損失（たとえば、いくつかのスライスの損失）がある送信されたコード化された画像のデコード結果です。 - フリー（例えば、その参照画像はエラー制定画像でした）。たとえば、画像の複数のスライスの1つが失われた場合、隣接するスライスの補間を使用してエラー制定される場合があります。高度なビデオコーディング予測メカニズムは非常に高いコーディング効率を提供しますが、マシンがエラー制定画像の品質を推定することも困難になります。これは、より単純な予測メカニズムの使用に関する困難な問題でした。高度な穴あきの予測メカニズムは、写真を複数のスライスに分割してより重要になるため、コーディング効率の損失を引き起こします。さらに、ネットワークの条件は大幅に良くなりますが、同時に、パケット損失に対処するための手法が大幅に改善されています。その結果、最近、スライスを使用した実装はほとんどありません。代わりに、低遅延エラーの回復力が必要な実質的にすべてのアプリケーション（たとえば、ビデオテレフォニーやビデオ会議）は、システム/トランスポートレベルのエラーの回復力（たとえば、再送信またはフォワードエラー修正）および/または画像ベースのエラーレジリエンスツールに依存しています。たとえば、フィードバックベースのエラーレジリエンス、IRAPの挿入、ベースレイヤーのより高い保護レベルによるスケーラビリティなど）。最近の上記のすべてを考慮すると、正しくデコードできない画像がデコーダーに渡されることは非常にまれであり、そのようなまれなケースが発生した場合、システムはエラーのない画像をデコードして利用できるのを待つ余裕がありますエンドユーザーが見た頻繁かつ長期間の画像凍結をもたらすことなく表示するため。
Slices in VVC have two modes: rectangular slices and raster-scan slices. The rectangular slice, as indicated by its name, covers a rectangular region of the picture. Typically, a rectangular slice consists of several complete tiles. However, it is also possible that a rectangular slice is a subset of a tile and consists of one or more consecutive, complete CTU rows within a tile. A raster-scan slice consists of one or more complete tiles in a tile raster-scan order; hence, the region covered by raster-scan slices need not but could have a non-rectangular shape, but it may also happen to have the shape of a rectangle. The concept of slices in VVC is therefore strongly linked to or based on tiles instead of CTUs (as in HEVC) or macroblocks (as in AVC).
VVCのスライスには、長方形のスライスとラスタースキャンスライスの2つのモードがあります。その名前で示されているように、長方形のスライスは、画像の長方形の領域をカバーしています。通常、長方形のスライスはいくつかの完全なタイルで構成されています。ただし、長方形のスライスはタイルのサブセットであり、タイル内の1つ以上の連続した完全なCTU行で構成されている可能性もあります。ラスタースキャンスライスは、タイルラスタースキャンオーダーの1つ以上の完全なタイルで構成されています。したがって、ラスタースキャンスライスで覆われた領域は、非長方形の形状を持つ必要はありませんが、長方形の形状を持つこともあります。したがって、VVCのスライスの概念は、CTU（HEVCのように）またはマクロブロック（AVCのように）ではなく、タイルに強くリンクされているか、またはタイルに基づいています。
Subpictures VVC is the first video coding standard that includes the support of subpictures as a feature. Each subpicture consists of one or more complete rectangular slices that collectively cover a rectangular region of the picture. A subpicture may be either specified to be extractable (i.e., coded independently of other subpictures of the same picture and of earlier pictures in decoding order) or not extractable. Regardless of whether a subpicture is extractable or not, the encoder can control whether in-loop filtering (including deblocking, SAO, and ALF) is applied across the subpicture boundaries individually for each subpicture.
サブピクチャVVCは、機能としてのサブピクチャのサポートを含む最初のビデオコーディング標準です。各サブピクチャは、画像の長方形領域を集合的にカバーする1つ以上の完全な長方形のスライスで構成されています。サブピクチャは、抽出可能であるように指定されている場合があります（つまり、同じ画像の他のサブピクチャと以前の画像のデコード順でコード化されています）または抽出できない場合があります。サブピクチャが抽出可能かどうかにかかわらず、エンコーダーは、各サブピクチャに対して、サブピクチャ境界に個別に適用されるかどうかをループ内フィルタリング（デブロック、SAO、およびALFを含む）を制御できます。
Functionally, subpictures are similar to the motion-constrained tile sets (MCTSs) in HEVC. They both allow independent coding and extraction of a rectangular subset of a sequence of coded pictures for use cases like viewport-dependent 360-degree video streaming optimization and region of interest (ROI) applications.
機能的には、サブピクチャは、HEVCのモーションが制約されたタイルセット（MCTS）に似ています。どちらも、ビューポートに依存する360度のビデオストリーミング最適化や関心地域（ROI）アプリケーションなどのユースケースのコード化された写真のシーケンスの長方形のサブセットの独立したコーディングと抽出を許可します。
There are several important design differences between subpictures and MCTSs. First, the subpictures featured in VVC allow motion vectors of a coding block to point outside of the subpicture, even when the subpicture is extractable by applying sample padding at the subpicture boundaries, in this case, similarly as at picture boundaries. Second, additional changes were introduced for the selection and derivation of motion vectors in the merge mode and in the decoder-side motion vector refinement process of VVC. This allows higher coding efficiency compared to the non-normative motion constraints applied at the encoder-side for MCTSs. Third, rewriting of slice headers (SHs) (and PH NAL units, when present) is not needed when extracting one or more extractable subpictures from a sequence of pictures to create a sub-bitstream that is a conforming bitstream. In sub-bitstream extractions based on HEVC MCTSs, rewriting of SHs is needed. Note that, in both HEVC MCTSs extraction and VVC subpictures extraction, rewriting of SPSs and PPSs is needed. However, typically, there are only a few parameter sets in a bitstream, whereas each picture has at least one slice; therefore, rewriting of SHs can be a significant burden for application systems. Fourth, slices of different subpictures within a picture are allowed to have different NAL unit types. Fifth, VVC specifies HRD and level definitions for subpicture sequences, thus the conformance of the sub-bitstream of each extractable subpicture sequence can be ensured by encoders.
サブピクチャとMCTSSの間にはいくつかの重要な設計上の違いがあります。まず、VVCに掲載されているサブピクチャーにより、サブピクチャがサブピクチャ境界でサンプルパディングを適用することで抽出可能な場合でも、サブピクチャが抽出可能な場合でも、サブピクチャが抽出可能な場合でも、サブピクチャの外側の外側にポイントできます。第二に、マージモードおよびVVCのデコーダーサイドモーションベクトル改良プロセスでのモーションベクトルの選択と導出のために、追加の変更が導入されました。これにより、MCTSSのエンコーダー側に適用される非規範的な動きの制約と比較して、より高いコーディング効率が可能になります。第三に、スライスヘッダー（SHS）（および存在する場合はph nalユニット）の書き換えは、一連の写真から1つ以上の抽出可能なサブピクチャを抽出して、適合ビットストリームであるサブビットストリームを作成するときは必要ありません。HEVC MCTSSに基づくサブビットストリーム抽出では、SHSの書き換えが必要です。HEVC MCTSS抽出とVVCサブピクチャ抽出の両方で、SPSSとPPSSの書き換えが必要であることに注意してください。ただし、通常、ビットストリームには少数のパラメーターセットしかありませんが、各画像には少なくとも1つのスライスがあります。したがって、SHSの書き換えは、アプリケーションシステムの重大な負担となる可能性があります。第4に、写真内の異なるサブピクチャのスライスには、異なるNALユニットタイプがあります。第5に、VVCはサブピクチャシーケンスのHRDおよびレベルの定義を指定します。したがって、各抽出可能なサブピクチャシーケンスのサブストリームの適合性をエンコーダーによって保証できます。
VVC maintains the NAL unit concept of HEVC with modifications. VVC 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.
VVCは、修正によりHEVCのNALユニットの概念を維持しています。VVCは、図1に示すように、2バイトNALユニットヘッダーを使用します。NALユニットのペイロードは、NALユニットヘッダーを除くNALユニットを指します。
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|Z| LayerID | Type | TID |
+---------------+---------------+
Figure 1: The Structure of the VVC NAL Unit Header
図1：VVC NALユニットヘッダーの構造
The semantics of the fields in the NAL unit header are as specified in VVC and described briefly below for convenience. In addition to the name and size of each field, the corresponding syntax element name in VVC is also provided.
NALユニットヘッダーのフィールドのセマンティクスは、VVCで指定されているとおりであり、便利なために以下で簡単に説明します。各フィールドの名前とサイズに加えて、VVCの対応する構文要素名も提供されます。
F: 1 bit forbidden_zero_bit. This field is required to be zero in VVC. Note that the inclusion of this bit in the NAL unit header was to enable transport of VVC video over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S]. In the context of this payload format, 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 the last sentence of Section 4.3.3.
F：1ビットforbidden_zero_bit。このフィールドは、VVCでゼロにする必要があります。NALユニットヘッダーにこのビットを含めることは、MPEG-2輸送システム（STARTコードエミュレーションの回避）[MPEG2S]を介したVVCビデオの輸送を可能にすることであったことに注意してください。このペイロード形式のコンテキストでは、値1を使用して構文違反を示すために使用できます。たとえば、最後の文に記載されているように、NALユニットの多数の断片化ユニットを集約することから生じるNALユニットの結果として生じるNALユニットについては、セクション4.3.3の。
Z: 1 bit nuh_reserved_zero_bit. This field is required to be zero in VVC, and reserved for future extensions by ITU-T and ISO/IEC. This memo does not overload the "Z" bit for local extensions a) because overloading the "F" bit is sufficient and b) in order to preserve the usefulness of this memo to possible future versions of [VVC].
Z：1ビットnuh_reserved_zero_bit。このフィールドは、VVCではゼロである必要があり、ITU-TおよびISO/IECによる将来の拡張のために予約されています。このメモは、ローカルエクステンションa）の「z」ビットに「z」ビットを過負荷ではありません。「f」ビットを過負荷にするだけで、b）このメモの有用性を[VVC]の将来のバージョンに維持するためです。
LayerId: 6 bits nuh_layer_id. This field identifies the layer a NAL unit belongs to, wherein a layer may be, e.g., a spatial scalable layer, a quality scalable layer, a layer containing a different view, etc.
layerid：6ビットnuh_layer_id。このフィールドは、nalユニットが属する層を識別します。たとえば、レイヤーは、空間スケーラブルな層、品質のスケーラブルな層、異なるビューを含むレイヤーなどです。
Type: 5 bits nal_unit_type. This field specifies the NAL unit type, as defined in Table 5 of [VVC]. For a reference of all currently defined NAL unit types and their semantics, please refer to Section 7.4.2.2 in [VVC].
タイプ：5ビットNAL_UNIT_TYPE。このフィールドは、[VVC]の表5に定義されているように、NALユニットタイプを指定します。現在定義されているすべてのNALユニットタイプとそのセマンティクスの参照については、[VVC]のセクション7.4.2.2を参照してください。
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 in order to enable the consideration of start code emulations in the NAL unit payload data independent of the NAL unit header.
TID：3ビットnuh_temporal_id_plus1。このフィールドは、NALユニットプラス1の時間的識別子を指定します。トイレリドの値はTIDマイナス1に等しくなります。TID値0は違法です。NALユニットヘッダーとは無関係に、NALユニットペイロードデータの開始コードエミュレーションの考慮を有効にするため。
This payload format defines the following processes required for transport of VVC coded data over RTP [RFC3550]:
このペイロード形式は、RTP [RFC3550]を介したVVCコード化されたデータの輸送に必要な以下のプロセスを定義します。
* usage of the RTP header with this payload format
* このペイロード形式でのRTPヘッダーの使用
* packetization of VVC coded NAL units into RTP packets using three types of payload structures: a single NAL unit packet, aggregation packet, and fragment unit
* VVCのパケット化NALユニットを3種類のペイロード構造を使用してRTPパケットにコード化しました：単一NALユニットパケット、集約パケット、フラグメントユニットのパケット
* transmission of VVC NAL units of the same bitstream within a single RTP stream
* 単一のRTPストリーム内の同じビットストリームのVVC NALユニットの送信
* media type parameters to be used with the Session Description Protocol (SDP) [RFC8866]
* セッション説明プロトコル（SDP）[RFC8866]で使用するメディアタイプパラメーター
* usage of RTCP feedback messages
* RTCPフィードバックメッセージの使用
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the terms and definitions of VVC. Section 3.1.1 lists relevant definitions from [VVC] for convenience. Section 3.1.2 provides definitions specific to this memo. All the used terms and definitions in this memo are verbatim copies from the [VVC] specification.
このドキュメントでは、VVCの用語と定義を使用しています。セクション3.1.1は、利便性のために[VVC]の関連する定義をリストします。セクション3.1.2は、このメモに固有の定義を示しています。このメモの使用された用語と定義はすべて、[VVC]仕様からの逐語的なコピーです。
Access unit (AU): A set of PUs that belong to different layers and contain coded pictures associated with the same time for output from the DPB.
アクセスユニット（AU）：異なるレイヤーに属し、DPBからの出力に同時に関連付けられたコード化された画像を含むPUSのセット。
Adaptation parameter set (APS): A syntax structure containing syntax elements that apply to zero or more slices as determined by zero or more syntax elements found in slice headers.
適応パラメーターセット（APS）：スライスヘッダーで見つかったゼロ以上の構文要素によって決定されるゼロ以上のスライスに適用される構文要素を含む構文構造。
Bitstream: A sequence of bits, in the form of a NAL unit stream or a byte stream, that forms the representation of a sequence of AUs forming one or more coded video sequences (CVSs).
ビットストリーム：1つ以上のコード化されたビデオシーケンス（CVSS）を形成するAUSのシーケンスの表現を形成する、NALユニットストリームまたはバイトストリームの形のビットのシーケンス。
Coded picture: A coded representation of a picture comprising VCL NAL units with a particular value of nuh_layer_id within an AU and containing all CTUs of the picture.
コード化された画像：au内にnuh_layer_idの特定の値を持つvcl nalユニットを含む画像のコード化された表現と、写真のすべてのctusを含む。
Clean random access (CRA) PU: A PU in which the coded picture is a CRA picture.
クリーンランダムアクセス（CRA）PU：コード化された画像がCRA画像であるPU。
Clean random access (CRA) picture: An IRAP picture for which each VCL NAL unit has nal_unit_type equal to CRA_NUT.
クリーンランダムアクセス（CRA）画像：各VCL NALユニットがCRA_NUTに等しいNAL_UNIT_TYPEを持っているIRAP画像。
Coded video sequence (CVS): A sequence of AUs that consists, in decoding order, of a CVSS AU, followed by zero or more AUs that are not CVSS AUs, including all subsequent AUs up to but not including any subsequent AU that is a CVSS AU.
コード化されたビデオシーケンス（CVS）：CVSS AUのデコード順序で構成されているAUSのシーケンス、続いてCVSS AUSではないゼロ以上のAUが続きます。CVSS AU。
Coded video sequence start (CVSS) AU: An AU in which there is a PU for each layer in the CVS and the coded picture in each PU is a CLVSS picture.
コード化されたビデオシーケンス開始（CVSS）AU：CVSに各レイヤーにPUがあり、各PUのコード化された画像がCLVSS画像です。
Coded layer video sequence (CLVS): A sequence of PUs with the same value of nuh_layer_id that consists, in decoding order, of a CLVSS PU, followed by zero or more PUs that are not CLVSS PUs, including all subsequent PUs up to but not including any subsequent PU that is a CLVSS PU.
コード化されたレイヤービデオシーケンス（CLVS）：CLVSS PUのデコード順で構成されているNUH_LAYER_IDの同じ値を持つPUSのシーケンス、続いてCLVSS PUSではないゼロ以上のPUSが続きます。CLVSS PUである後続のPUを含む。
Coded layer video sequence start (CLVSS) PU: A PU in which the coded picture is a CLVSS picture.
コード化されたレイヤービデオシーケンス開始（CLVSS）PU：コード化された画像がCLVSS画像であるPU。
Coded layer video sequence start (CLVSS) picture: A coded picture that is an IRAP picture with NoOutputBeforeRecoveryFlag equal to 1 or a GDR picture with NoOutputBeforeRecoveryFlag equal to 1.
コード化されたレイヤービデオシーケンス開始（CLVSS）画像：1に等しいnoOutputbeforerecoveryflagを備えたIRAP画像、または1に等しいnooutputbeforerecoveryflagを持つGDR画像のコード化された画像。
Coding Tree Block (CTB): An NxN block of samples for some value of N such that the division of a component into CTBs is a partitioning.
コーディングツリーブロック（CTB）：コンポーネントのCTBへの分割がパーティション化されるように、Nの何らかの値のサンプルのNXNブロック。
Coding tree unit (CTU): A CTB of luma samples, two corresponding CTBs of chroma samples of a picture that has three sample arrays, or a CTB of samples of a monochrome picture or a picture that is coded using three separate colour planes and syntax structures used to code the samples.
コーディングツリーユニット（CTU）：LUMAサンプルのCTB、3つのサンプル配列を備えた写真の2つの対応するCTBのCTB、またはモノクロ画像のサンプルのCTBまたは3つの別々の色平面とSynTaxを使用してコーディングされた画像のCTBサンプルのコーディングに使用される構造。
Coding Unit (CU): A coding block of luma samples, two corresponding coding blocks of chroma samples of a picture that has three sample arrays in the single tree mode, or a coding block of luma samples of a picture that has three sample arrays in the dual tree mode, or two coding blocks of chroma samples of a picture that has three sample arrays in the dual tree mode, or a coding block of samples of a monochrome picture, and syntax structures used to code the samples.
コーディングユニット（CU）：LUMAサンプルのコーディングブロック、1つのツリーモードに3つのサンプル配列がある写真のクロマサンプルの2つの対応するコーディングブロック、または3つのサンプル配列がある画像のLUMAサンプルのコーディングブロックのコーディングブロックデュアルツリーモード、またはデュアルツリーモードに3つのサンプル配列がある画像のクロマサンプルの2つのコーディングブロック、またはモノクロ画像のサンプルのコーディングブロック、およびサンプルのコーディングに使用される構文構造。
Decoding Capability Information (DCI): A syntax structure containing syntax elements that apply to the entire bitstream.
デコード機能情報（DCI）：ビットストリーム全体に適用される構文要素を含む構文構造。
Decoded picture buffer (DPB): A buffer holding decoded pictures for reference, output reordering, or output delay specified for the hypothetical reference decoder.
デコードされた画像バッファー（DPB）：仮説参照デコーダーに指定された参照、出力の再注文、または出力遅延のためのバッファ保持デコードされた写真。
Gradual decoding refresh (GDR) picture: A picture for which each VCL NAL unit has nal_unit_type equal to GDR_NUT.
段階的なデコードリフレッシュ（GDR）画像：各vcl nalユニットがgdr_nutに等しいnal_unit_typeを持っている画像。
Instantaneous decoding refresh (IDR) PU: A PU in which the coded picture is an IDR picture.
瞬時デコードリフレッシュ（IDR）PU：コード化された画像がIDR画像であるPU。
Instantaneous decoding refresh (IDR) picture: An IRAP picture for which each VCL NAL unit has nal_unit_type equal to IDR_W_RADL or IDR_N_LP.
瞬時デコードリフレッシュ（IDR）画像：各vcl nalユニットがidr_w_radlまたはidr_n_lpに等しいnal_unit_typeを持っているIRAP画像。
Intra random access point (IRAP) AU: An AU in which there is a PU for each layer in the CVS and the coded picture in each PU is an IRAP picture.
ランダムアクセスポイント（IRAP）AU：CVSに各レイヤーにPUがあり、各PUのコード化された画像がIRAP画像であるAU。
Intra random access point (IRAP) PU: A PU in which the coded picture is an IRAP picture.
ランダムアクセスポイント（IRAP）PU：コード化された画像がIRAP画像であるPU。
Intra random access point (IRAP) picture: A coded picture for which all VCL NAL units have the same value of nal_unit_type in the range of IDR_W_RADL to CRA_NUT, inclusive.
イントラランダムアクセスポイント（IRAP）画像：すべてのVCL NALユニットがIDR_W_RADLからCRA_NUTの範囲で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.
レイヤー：NUH_LAYER_IDと関連する非VCL NALユニットの特定の値をすべて持っているVCL NALユニットのセット。
Network abstraction layer (NAL) unit: A syntax structure containing an indication of the type of data to follow and bytes containing that data in the form of an RBSP interspersed as necessary with emulation prevention bytes.
ネットワーク抽象化レイヤー（NAL）ユニット：フォローするデータのタイプを示す構文構造と、エミュレーション予防バイトに必要に応じて散在するRBSPの形式のデータを含むバイトを含む構文構造。
Network abstraction layer (NAL) unit stream: A sequence of NAL units.
ネットワーク抽象化レイヤー（NAL）ユニットストリーム：NALユニットのシーケンス。
Output Layer Set (OLS): A set of layers for which one or more layers are specified as the output layers.
出力層セット（OLS）：出力層として1つ以上のレイヤーが指定されるレイヤーのセット。
Operation point (OP): A temporal subset of an OLS, identified by an OLS index and a highest value of TemporalId.
Operation Point（OP）：OLSインデックスによって識別されるOLSの時間的サブセットとトイレリドの最高値。
Picture Header (PH): A syntax structure containing syntax elements that apply to all slices of a coded picture.
Picture Header（PH）：コード化された画像のすべてのスライスに適用される構文要素を含む構文構造。
Picture parameter set (PPS): A syntax structure containing syntax elements that apply to zero or more entire coded pictures as determined by a syntax element found in each slice header.
画像パラメーターセット（PPS）：各スライスヘッダーで見つかった構文要素によって決定されるゼロ以上のコード化された画像に適用される構文要素を含む構文構造。
Picture unit (PU): A set of NAL units that are associated with each other according to a specified classification rule, are consecutive in decoding order, and contain exactly one coded picture.
Picture Unit（PU）：指定された分類ルールに従って互いに関連付けられているNALユニットのセットは、デコード順に連続しており、正確に1つのコード化された画像が含まれています。
Random access: The act of starting the decoding process for a bitstream at a point other than the beginning of the bitstream.
ランダムアクセス：ビットストリームの始まり以外の点でビットストリームのデコードプロセスを開始する行為。
Raw Byte Sequence Payload (RBSP): A syntax structure containing an integer number of bytes that is encapsulated in a NAL unit and is either empty or has the form of a string of data bits containing syntax elements followed by an RBSP stop bit and zero or more subsequent bits equal to 0.
生のバイトシーケンスペイロード（rbsp）：nalユニットにカプセル化され、空であるか、構文要素を含む一連のデータビットの形式を含む整数数のバイトを含む構文構造は、rbspの停止ビットとゼロまたはゼロまたはゼロまたはゼロまたはより多くの後続のビットは0に等しくなります。
Sequence parameter set (SPS): A syntax structure containing syntax elements that apply to zero or more entire CLVSs as determined by the content of a syntax element found in the PPS referred to by a syntax element found in each picture header.
シーケンスパラメーターセット（SPS）：各画像ヘッダーで見つかった構文要素によって参照されているPPSで見つかった構文要素の内容によって決定されるゼロ以上のCLVSSに適用される構文要素を含む構文構造。
Slice: An integer number of complete tiles or an integer number of consecutive complete CTU rows within a tile of a picture that are exclusively contained in a single NAL unit.
スライス：単一のNALユニットにのみ含まれる画像のタイル内の完全なタイルまたは整数の連続した完全なCTU行。
Slice header (SH): A part of a coded slice containing the data elements pertaining to all tiles or CTU rows within a tile represented in the slice.
スライスヘッダー（SH）：スライスに表されているタイル内のすべてのタイルまたはCTU行に関連するデータ要素を含むコード化されたスライスの一部。
Sublayer: 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.
Sublayer：側頭筋変数の特定の値を持つVCl NALユニットと関連する非VCL NALユニットを持つ側面スケーラブルなビットストリームの時間的スケーラブルな層。
Subpicture: A rectangular region of one or more slices within a picture.
サブピクチャ：写真内の1つ以上のスライスの長方形の領域。
Sublayer representation: A subset of the bitstream consisting of NAL units of a particular sublayer and the lower sublayers.
サブレイヤーの表現：特定のサブレイヤーと下層副師のNALユニットで構成されるビットストリームのサブセット。
Tile: A rectangular region of CTUs within a particular tile column and a particular tile row in a picture.
タイル：特定のタイル列内のCTUの長方形の領域と、写真の特定のタイル行。
Tile column: A rectangular region of CTUs having a height equal to the height of the picture and a width specified by syntax elements in the picture parameter set.
タイル列：画像の高さに等しい高さと、画像パラメーターセットの構文要素で指定された幅を持つCTUの長方形の領域。
Tile row: A rectangular region of CTUs having a height specified by syntax elements in the picture parameter set and a width equal to the width of the picture.
タイル行：画像パラメーターセットの構文要素で指定された高さと、画像の幅に等しい幅を持つCTUの長方形の領域。
Video coding layer (VCL) NAL unit: A collective term for coded slice NAL units and the subset of NAL units that have reserved values of nal_unit_type that are classified as VCL NAL units in this Specification.
ビデオコーディングレイヤー（VCL）NALユニット：この仕様でVCL NAL単位として分類されるNAL_UNIT_TYPEの予約値を持つNALユニットのコード化されたスライス単位のサブセットの集合用語。
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].
有益なメモ：たてがみの概念は、通常のルーターまたはゲートウェイを超えています。たとえば、メディアストリームのペイロードタイプのマッピングについて学ぶためには、たとえば、たとえば、たとえば、たとえば、それが信頼する必要があるということです。Secure RTP（SRTP）を使用します。たてがみを使用する利点は、メディアコーディングのニーズに応じてパケットをドロップできることです。たとえば、特定のリンクの輻輳のためにたてがみがパケットをドロップする必要がある場合、排除がユーザーエクスペリエンスに最も悪影響をもたらすパケットを識別および削除できます。パケットをドロップした後、MANESはRTCPパケットを書き換えて、[RFC3550]のセクション7で指定されているように、RTPストリームの変更を一致させる必要があります。
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 [VVC], follow the order of NAL units in the bitstream.
NALユニットデコード順序：[VVC]のセクション7.4.2.4に記載されているNALユニットの順序の制約に準拠するNALユニット順序は、ビットストリームのNALユニットのオーダーに従います。
RTP stream (see [RFC7656]): Within the scope of this memo, one RTP stream is utilized to transport a VVC bitstream, which may contain one or more layers, and each layer may contain one or more temporal sublayers.
RTPストリーム（[RFC7656]を参照）：このメモの範囲内で、1つのRTPストリームを使用してVVCビットストリームを輸送します。
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ユニットの外観の順序と同じです。
AU Access Unit
AUアクセスユニット
AP Aggregation Packet
AP集約パケット
APS Adaptation Parameter Set
APS適応パラメーターセット
CTU Coding Tree Unit
CTUコーディングツリーユニット
CVS Coded Video Sequence
CVSコード化されたビデオシーケンス
DPB Decoded Picture Buffer
DPBデコードされた画像バッファー
DCI Decoding Capability Information
DCIデコード機能情報
DON Decoding Order Number
DON DECODING ORDER番号
FIR Full Intra Request
FIRフルリクエスト
FU Fragmentation Unit
FU断片化ユニット
GDR Gradual Decoding Refresh
GDR徐々にデコードリフレッシュ
HRD Hypothetical Reference Decoder
HRD仮説リファレンスデコーダー
IDR Instantaneous Decoding Refresh
IDR瞬時デコードリフレッシュ
IRAP Intra Random Access Point
IRAPランダムアクセスポイント
MANE Media-Aware Network Element
Mane Media-Awareネットワーク要素
MTU Maximum Transfer Unit
MTU最大転送ユニット
NAL Network Abstraction Layer
NALネットワーク抽象化レイヤー
NALU Network Abstraction Layer Unit
NALUネットワーク抽象化レイヤーユニット
OLS Output Layer Set
OLS出力層セット
PLI Picture Loss Indication
PLI画像喪失の表示
PPS Picture Parameter Set
PPS画像パラメーターセット
RPSI Reference Picture Selection Indication
RPSI参照画像選択表示
SEI Supplemental Enhancement Information
SEI補足強化情報
SLI Slice Loss Indication
SLIスライス損失の表示
SPS Sequence Parameter Set
SPSシーケンスパラメーターセット
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.3.2 and 4.3.3, respectively.
集約パケットと断片化ユニットのRTPペイロード（およびいくつかのRTPヘッダービットの設定）は、それぞれセクション4.3.2と4.3.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 RFC 3550
図2：RFC 3550による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 Set for the last packet, in transmission order, among each set of packets that contain NAL units of one access unit. This is in line with the normal use of the M bit in video formats to allow an efficient playout buffer handling.
マーカービット（m）：1つのアクセスユニットのNALユニットを含むパケットの各セットの中で、送信順に最後のパケットに1ビット設定されています。これは、効率的なプレイアウトバッファの処理を可能にするために、ビデオ形式でのMビットの通常の使用と一致しています。
Payload Type (PT): 7 bits 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.
ペイロードタイプ（PT）：7ビットこの新しいパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでは指定されません。ペイロードタイプの割り当ては、使用されるプロファイルまたは動的な方法で実行する必要があります。
Sequence Number (SN): 16 bits Set and used in accordance with [RFC3550].
シーケンス番号（SN）：[RFC3550]に従って16ビットが設定され、使用されます。
Timestamp: 32 bits The RTP timestamp is set to the sampling timestamp of the content. A 90 kHz clock rate MUST be used. 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 pictures of the access unit in which the NAL unit (according to Section 7.4.2.4 of [VVC]) is included. 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 [VVC].
タイムスタンプ：32ビットRTPタイムスタンプは、コンテンツのサンプリングタイムスタンプに設定されています。90 kHzのクロックレートを使用する必要があります。NALユニットに独自のタイミングプロパティがない場合（例：パラメーターセットおよびSEI NALユニット）、RTPタイムスタンプは、NALユニットのアクセスユニットのコード化された写真のRTPタイムスタンプに設定する必要があります（セクション7.4に従って、[VVC]の.2.4）が含まれています。[VVC]で指定されているように、BitStreamに画像タイミングSEIメッセージまたはデコードユニット情報SEIメッセージが含まれている場合でも、受信機はディスプレイプロセスにRTPタイムスタンプを使用する必要があります。
Informative note: When picture timing SEI messages are present, the RTP sender is responsible to ensure that the RTP timestamps are consistent with the timing information carried in the picture timing SEI messages.
有益なメモ：画像タイミングSEIメッセージが存在する場合、RTP送信者は、RTPタイムスタンプが写真タイミングSEIメッセージに掲載されたタイミング情報と一致するように責任を負います。
Synchronization source (SSRC): 32 bits Used to identify the source of the RTP packets. A single SSRC is used for all parts of a single bitstream.
同期ソース（SSRC）：RTPパケットのソースを識別するために使用される32ビット。単一の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, Z, LayerId, Type, and TID) as the NAL unit header shown in Section 1.1.4, irrespective of the type of the payload structure.
RTPパケットのペイロードの最初の2バイトは、ペイロードヘッダーと呼ばれます。ペイロードヘッダーは、ペイロード構造のタイプに関係なく、セクション1.1.4に示すNALユニットヘッダーと同じフィールド（f、z、layerid、type、and tid）で構成されています。
The TID value indicates (among other things) the relative importance of an RTP packet, for example, because NAL units belonging to higher temporal sublayers are not used for the decoding of lower temporal sublayers. 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.
たとえば、より高い時間的サブレイヤーに属するNALユニットが低い側頭溝のデコードには使用されていないため、TID値は（とりわけ）RTPパケットの相対的な重要性を示しています。TIDの値が低いと、より重要性が示されます。より重要なNALユニットは、重要性の低いNALユニットよりも、伝送損失からよりよく保護される可能性があります。
Three 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.
3つの異なるタイプのRTPパケットペイロード構造が指定されています。レシーバーは、ペイロードヘッダーのタイプフィールドを介してRTPパケットペイロードのタイプを識別できます。
The three different payload structures are as follows:
3つの異なるペイロード構造は次のとおりです。
* 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.3.1.
* 単一NALユニットパケット：ペイロードに単一のNALユニットが含まれており、NALユニットのNALユニットヘッダーもペイロードヘッダーとして機能します。このペイロード構造は、セクション4.3.1で指定されています。
* Aggregation Packet (AP): Contains more than one NAL unit within one access unit. This payload structure is specified in Section 4.3.2.
* 集約パケット（AP）：1つのアクセスユニット内に複数のNALユニットが含まれています。このペイロード構造は、セクション4.3.2で指定されています。
* Fragmentation Unit (FU): Contains a subset of a single NAL unit. This payload structure is specified in Section 4.3.3.
* フラグメンテーションユニット（FU）：単一のNALユニットのサブセットが含まれています。このペイロード構造は、セクション4.3.3で指定されています。
A single NAL unit packet contains exactly one NAL unit and consists of a payload header, as defined in Table 5 of [VVC] (denoted here as PayloadHdr), following with 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.
単一のNALユニットパケットには、正確に1つのNALユニットが含まれており、[VVC]の表5（ここではPayLoadHDRとして示される）で定義されているペイロードヘッダーで構成され、条件付き16ビットDONLフィールド（ネットワークバイト順）、および図3に示すように、含まれるNALユニットの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr | DONL (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NAL unit payload data |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Structure of a Single NAL Unit Packet
図3：単一のNALユニットパケットの構造
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 (defined in Section 7.2) is greater than 0, 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), the DONL field MUST NOT be present.
DONLフィールドは、存在する場合、含まれるNALユニットのデコード順序数の16の最小ビットの値の値を指定します。SPROP-MAX-DON-DIFF（セクション7.2で定義）が0より大きい場合、DONLフィールドが存在する必要があり、含まれているNALユニットの変数DONはDONLフィールドの値に等しくなります。それ以外の場合は、（SPROP-MAX-DON-DIFFは0に等しい）、DONLフィールドを存在してはなりません。
Aggregation packets (APs) can reduce packetization overhead for small NAL units, such as most of the non-VCL NAL units, which are often only a few octets in size.
集約パケット（APS）は、多くの場合、サイズがわずか数オクテットしかないほとんどの非VCL NALユニットなど、小さなNALユニットのパケット化オーバーヘッドを削減できます。
An AP aggregates NAL units of one access unit, and it MUST NOT contain NAL units from more than one AU. Each NAL unit to be carried in an AP is encapsulated in an aggregation unit. NAL units aggregated in one AP are included in NAL-unit-decoding order.
APは1つのアクセスユニットのNALユニットを集約し、複数のAUからNALユニットを含めてはなりません。APで運ばれる各NALユニットは、集約ユニットにカプセル化されています。1つのAPに集約されたNALユニットは、NALユニットデコード順に含まれています。
An AP consists of a payload header, as defined in Table 5 of [VVC] (denoted here as PayloadHdr with Type=28), followed by two or more aggregation units, as shown in Figure 4.
APは、[VVC]の表5に定義されているペイロードヘッダーで構成されています（ここでは、型= 28のペイロードhdrとして示されます）、その後、図4に示すように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=28) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| two or more aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Structure of an Aggregation Packet
図4：集約パケットの構造
The fields in the payload header of an AP 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 28.
APのペイロードヘッダーのフィールドは、次のように設定されています。各集約されたNALユニットのfビットがゼロに等しい場合、Fビットは0に等しくなければなりません。それ以外の場合、1に等しくなければなりません。タイプフィールドは28に等しくなければなりません。
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ユニットのレイリドの最低値に等しくなければなりません。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ユニットが含まれている場合があります。
Informative note: If a system envisions subpicture-level or picture-level modifications, for example, by removing subpictures or pictures of a particular layer, a good design choice on the sender's side would be to aggregate NAL units belonging to only the same subpicture or picture of a particular layer.
有益な注意：システムが特定のレイヤーのサブピクチャーや写真を削除することにより、サブピクチャレベルまたは画像レベルの変更を想定している場合、送信者側の優れた設計選択は、同じサブピクチャまたは同じサブピクチャのみに属する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 in order to avoid IP layer fragmentation. An AP MUST NOT contain the FUs specified in Section 4.3.3. APs MUST NOT be nested, i.e., an AP cannot contain another AP.
APは、少なくとも2つの集約ユニットを搭載する必要があり、必要な数の凝集ユニットを運ぶことができます。ただし、APのデータの合計量は明らかにIPパケットに適合する必要があり、IPレイヤーの断片化を回避するために、結果のIPパケットがMTUサイズよりも小さいようにサイズを選択する必要があります。APは、セクション4.3.3で指定されたFUSを含めてはなりません。APをネストしてはなりません。つまり、APは別のAPを含めることはできません。
The first aggregation unit in an AP consists of a conditional 16-bit DONL field (in network byte order), followed by 16 bits of unsigned size information (in network byte order) that indicate 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に示すように、NALユニットヘッダーを含む2つのオクテットですが、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の最初の集約ユニットの構造
Informative note: The first octet of Figure 5 (indicated by the first colon) belongs to a previous aggregation unit. It is depicted to emphasize that aggregation units are octet aligned only. Similarly, the NAL unit carried in the aggregation unit can terminate at the octet boundary.
有益なメモ：図5の最初のオクテット（最初のコロンで示されている）は、以前の集約ユニットに属します。集約ユニットはオクテットアラインドのみであることを強調するために描かれています。同様に、集約ユニットに運ばれたNALユニットは、オクテット境界で終了できます。
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, 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, and the variable DON for an aggregation unit that is not the first aggregation unit in an AP-aggregated NAL unit is derived as equal to the DON of the preceding aggregated NAL unit in the same AP plus 1 modulo 65536. Otherwise (sprop-max-don-diff is equal to 0), the DONL field MUST NOT be present in an aggregation unit that is the first aggregation unit in an AP.
sprop-max-don-diffが0より大きい場合、APの最初の集約ユニットである集合ユニットにDONLフィールドが存在する必要があり、集約されたNALユニットの可変DONは、AP凝集したNALユニットの最初の集約ユニットではない集合ユニットのDONLフィールドと変数DONは、同じAPと1 Modulo 65536の前の集約されたNALユニットのDONに等しいとして導出されます（そうでない場合）sprop-max-don-diffは0に等しい）、APの最初の集約ユニットである集合ユニットにDONLフィールドが存在しないでください。
An aggregation unit that is not the first aggregation unit in an AP will be followed immediately by 16 bits of unsigned size information (in network byte order) that indicate 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の最初の集約ユニットではない集約ユニットには、すぐに16ビットの符号付きサイズ情報（ネットワークバイト順）が続きます。図6に示すように、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : NALU size | NAL unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Structure of an Aggregation Unit That Is Not the First Aggregation Unit in an AP
図6：APで最初の集約ユニットではない集約ユニットの構造
Informative note: The first octet of Figure 6 (indicated by the first colon) belongs to a previous aggregation unit. It is depicted to emphasize that aggregation units are octet aligned only. Similarly, the NAL unit carried in the aggregation unit can terminate at the octet boundary.
有益なメモ：図6の最初のオクテット（最初のコロンで示されている）は、以前の集約ユニットに属します。集約ユニットはオクテットアラインドのみであることを強調するために描かれています。同様に、集約ユニットに運ばれたNALユニットは、オクテット境界で終了できます。
Figure 7 presents an example of an AP that contains two aggregation units, labeled as 1 and 2 in the figure, without the DONL field being present.
図7は、図の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=28) | 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 Field
図7：DONLフィールドのない2つの集約ユニットを含むAPパケットの例
Figure 8 presents an example of an AP that contains two aggregation units, labeled as 1 and 2 in the figure, with the DONL field being present.
図8は、図の1と2とラベル付けされた2つの集約単位を含むAPの例を示しています。DONLフィールドが存在します。
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=28) | NALU 1 DONL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NALU 1 Data . . . |
| |
+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : 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 Field
図8：DONLフィールドに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 [VVC] 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).
フラグメンテーションユニット（FUS）が導入され、おそらく[VVC]エンコーダーの協力や知識なしに、単一のNALユニットを複数のRTPパケットに断片化できるようにします。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 cannot contain a subset of another FU.
NALユニットが断片化され、FUS内で伝達されると、断片化されたNALユニットと呼ばれます。APを断片化してはなりません。FUSをネストしてはなりません。つまり、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 as defined in Table 5 of [VVC] (denoted here as PayloadHdr with Type=29), 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).
FUは、[VVC]の表5で定義されているペイロードヘッダー（ここではタイプ= 29のペイロードhdrとして示されています）、1オクテットのFUヘッダー、条件付き16ビットDONLフィールド（ネットワークバイト順）、およびFUペイロード（図9に示すように）。
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=29) | 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 29. The fields F, LayerId, and TID MUST be equal to the fields F, LayerId, and TID, respectively, of the fragmented NAL unit.
ペイロードヘッダーのフィールドは次のように設定されています。タイプフィールドは29に等しくなければなりません。フィールドF、レイリド、およびTIDは、断片化されたNALユニットのフィールドF、レイリド、およびTIDにそれぞれ等しくなければなりません。
The FU header consists of an S bit, an E bit, an R bit, and a 5-bit FuType field, as shown in Figure 10.
FUヘッダーは、図10に示すように、Sビット、Eビット、Rビット、および5ビットの未来フィールドで構成されています。
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|P| FuType |
+---------------+
Figure 10: The Structure of the 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に設定する必要があります。
P: 1 bit When set to 1, the P bit indicates the last FU of the last VCL NAL unit of a coded picture, i.e., the last byte of the FU payload is also the last byte of the last VCL NAL unit of the coded picture. When the FU payload is not the last fragment of the last VCL NAL unit of a coded picture, the P bit MUST be set to 0.
p：1ビット1に設定すると、pビットは、コード化された画像の最後のvcl nal単位の最後のfuを示します。写真。FUペイロードがコード化された画像の最後のVCl NALユニットの最後のフラグメントではない場合、Pビットは0に設定する必要があります。
FuType: 5 bits The field FuType MUST be equal to the field Type of the fragmented NAL unit.
Futype：5ビットフィールド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, 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, or the S bit is equal to 0), the DONL field MUST NOT be present in the FU.
sprop-max-don-diffが0より大きく、sビットが1に等しい場合、donlフィールドはfuに存在する必要があり、断片化されたnalユニットの変数donはDONLフィールド。それ以外の場合は（Sprop-Max-Don-Diffは0に等しく、Sビットは0に等しくなります）、DONLフィールドはFUに存在してはなりません。
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に送信してはなりません。つまり、Start BitとEnd Bitを同じFUヘッダーで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 the 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のペイロードが連続してFUSの場合、Sビットが1に等しく、Eビットが1に等しいFUで終了するFUから始まります。連続的に連結して、断片化されたNALユニットのペイロードを再構築できます。断片化されたNALユニットのNALユニットヘッダーは、FUペイロードにそのように含まれていませんが、断片化されたNALユニットのNALユニットヘッダーの情報は、FUペイロードヘッダーのF、レイリド、およびTIDフィールドに配信されます。FUSのFUヘッダーのFUSおよび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ユニットに対応する、受信機は、同じ断片化された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.
エンドポイントまたはたてがみのレシーバーは、そのnalユニットのフラグメントNが受信されていなくても、nalユニットの最初のn-1フラグメントを（不完全な）nalユニットに集約することができます。この場合、構文違反を示すために、NALユニットのFORBIDDEN_ZERO_BITを1に設定する必要があります。
For each NAL unit, the variable AbsDon is derived, representing the decoding order number that is indicative of the NAL unit decoding order.
各NALユニットについて、可変アブスドンが導出され、NALユニットデコード順を示すデコード順序数を表します。
Let NAL unit n be the n-th NAL unit in transmission order within an RTP stream.
nalユニットnをrtpストリーム内で透過順にn第n nalユニットとします。
If sprop-max-don-diff is equal to 0, AbsDon[n], the value of AbsDon for NAL unit n, is derived as equal to n.
sprop-max-don-diffが0に等しい場合、nalユニットnのアブスドンの値であるアブスドン[n]は、nに等しいと派生します。
Otherwise (sprop-max-don-diff is greater than 0), AbsDon[n] is derived as follows, where DON[n] is the value of the variable DON for NAL unit n:
それ以外の場合は（Sprop-Max-Don-Diffは0より大きい）、Absdon [n]は次のように導出されます。ここで、don [n]はnalユニットnの変数donの値です。
* 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].
* nが0に等しい場合（つまり、NALユニットnが伝送順に最初のNALユニットです）、アブスドン[0]はdon [0]に等しく設定されます。
* Otherwise (n is greater than 0), the following applies for derivation of AbsDon[n]:
* それ以外の場合（nは0より大きい）、アブスドン[n]の導出に次のものが適用されます。
If DON[n] == DON[n-1], AbsDon[n] = AbsDon[n-1]
don [and] == 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）には、次のものが適用されます。
* When AbsDon[n] is greater than AbsDon[m], this indicates that NAL unit n follows NAL unit m in NAL unit decoding order.
* アブスドン[n]がアブスドン[m]よりも大きい場合、これはnalユニットnがnalユニットデコード順でnalユニットmに従うことを示しています。
* When AbsDon[n] is equal to AbsDon[m], the NAL unit decoding order of the two NAL units can be in either order.
* アブスドン[n]がアブスドン[M]に等しい場合、2つのNALユニットのNALユニットデコード順序はどちらの順序でもあります。
* When AbsDon[n] is less than AbsDon[m], this indicates that NAL unit n precedes NAL unit m in decoding order.
* アブスドン[n]がアブスドン[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ユニットがアブスドンの値が異なる場合、2つのアブスドン値の絶対差は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 might not forward VCL NAL units of higher sublayers 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.
有益なメモ：NALユニットデコード順序の2つの連続したNALユニットについて、ABSDONの値の絶対的な差を1つ以上にするために、ABSDONの値の絶対的な差を可能にする複数の理由があります。アブスドンの値をNALユニットに関連付ける時点で、すべてのNALユニットが受信機に配信されるかどうかはわからないため、1つの増分は必要ありません。たとえば、ゲートウェイは、ネットワークに混雑がある場合、より高いサブレーヤーまたはいくつかのSEINALユニットのVCLユニットを転送しない場合があります。別の例では、事前にエンコードされたクリップの最初のコード付き画像を事前に送信して、受信機で容易に利用できることを確認し、最初のコード内の画像を送信するとき、オリジネーターは正確に何のNALを知りませんユニットは、事前にエンコードされたクリップの最初のコード化された写真がデコード順に続く前にエンコードされます。したがって、事前にエンコードされたクリップの最初のコード化された画像のNAL単位のアブスドンの値は、それらが送信されたときに推定する必要があり、アブスドンの値のギャップが発生する可能性があります。
The following packetization rules apply:
次のパケット化規則が適用されます。
* If sprop-max-don-diff is greater than 0, the transmission order of NAL units carried in the RTP stream MAY be different than the NAL unit decoding order. Otherwise (sprop-max-don-diff is equal to 0), the transmission order of NAL units carried in the RTP stream MUST be the same as the NAL unit decoding order.
* SPROP-MAX-DON-DIFFが0より大きい場合、RTPストリームに運ばれるNALユニットの伝送順序は、NALユニットデコード順とは異なる場合があります。それ以外の場合は、（SPROP-MAX-DON-DIFFは0に等しい）、RTPストリームに運ばれるNALユニットの伝送順序は、NALユニットデコード順と同じでなければなりません。
* 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.
* 小さなnalユニットの不必要なパケット化オーバーヘッドを避けるために、小さなサイズのNALユニットを集約パケットと一緒にカプセル化する必要があります。たとえば、アクセスユニットデリミター、パラメーターセット、またはseinalユニットなどの非VCL NALユニットは通常小さく、MTUサイズの制約に違反することなくVCL NALユニットと集約できることがよくあります。
* 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.
* 各非VCL NALユニットは、MTUサイズの一致ビューポイントから可能な場合は、関連するVCL NALユニットとともに関連するVCLユニットと一緒に集約パケットにカプセル化する必要があります。。
* For carrying exactly one NAL unit in an RTP packet, a single NAL unit packet MUST be used.
* 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 pass them to the decoder in the NAL unit decoding order.
パケット化の背後にある一般的な概念は、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 sequence 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 27, inclusive, may be passed to the decoder. NAL-unit-like structures with NAL unit type values in the range of 28 to 31, inclusive, MUST NOT be passed to the decoder.
0〜27の範囲のNALユニットタイプの値を持つNALユニットは、包括的で、デコーダーに渡される場合があります。28〜31の範囲のNALユニットタイプの値を持つNALユニットのような構造は、包括的で、デコーダーに渡されてはなりません。
The receiver includes a receiver buffer, which is used to compensate for transmission delay jitter within individual RTP streams and to reorder NAL units from transmission order to the NAL unit decoding order. In this section, the receiver operation is described under the assumption that there is no transmission delay jitter within an RTP stream. 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ストリーム内の送信遅延ジッターを補正し、送信順序からNALユニットデコード順にnalユニットを並べ替えるために使用されるレシーバーバッファーが含まれています。このセクションでは、RTPストリーム内に送信遅延ジッターがないという仮定の下で、受信機操作について説明します。トランスミッション遅延ジッターの補償にも使用される実用的なレシーバーバッファーと違いを生むために、受信バッファーは、このセクションの脱パケット化バッファーと呼ばれる以下です。受信機はまた、送信遅延ジッターの準備をする必要があります。つまり、送信遅延バッファリングとパケット化バッファリングのために別々のバッファーを予約するか、送信遅延ジッターとパケット脱パケットの両方にレシーバーバッファーを使用します。さらに、レシーバーは、デコードと再生の開始前に追加の初期バッファリングにより、バッファリング操作で送信遅延ジッターを考慮に入れる必要があります。
The de-packetization process extracts the NAL units from the RTP packets in an RTP stream as follows. When an RTP packet carries a single NAL unit packet, the payload of the RTP packet is extracted as a single NAL unit, excluding the DONL field, i.e., third and fourth bytes, when sprop-max-don-diff is greater than 0. When an RTP packet carries an aggregation packet, several NAL units are extracted from the payload of the RTP packet. In this case, each NAL unit corresponds to the part of the payload of each aggregation unit that follows the NALU size field, as described in Section 4.3.2. When an RTP packet carries a Fragmentation Unit (FU), all RTP packets from the first FU (with the S field equal to 1) of the fragmented NAL unit up to the last FU (with the E field equal to 1) of the fragmented NAL unit are collected. The NAL unit is extracted from these RTP packets by concatenating all FU payloads in the same order as the corresponding RTP packets and appending the NAL unit header with the fields F, LayerId, and TID set to equal the values of the fields F, LayerId, and TID in the payload header of the FUs, respectively, and with the NAL unit type set equal to the value of the field FuType in the FU header of the FUs, as described in Section 4.3.3.
パケット化プロセスは、次のようにRTPストリームのRTPパケットからNALユニットを抽出します。RTPパケットが単一のNALユニットパケットを搭載すると、RTPパケットのペイロードは、DONLフィールドを除く単一のNALユニットとして抽出されます。RTPパケットが集約パケットを運ぶと、RTPパケットのペイロードからいくつかのNALユニットが抽出されます。この場合、各NALユニットは、セクション4.3.2で説明されているように、NALUサイズフィールドに続く各集約ユニットのペイロードの部分に対応します。RTPパケットがフラグメンテーションユニット（FU）を搭載している場合、断片化されたNALユニットの最初のFU（Sフィールドが1に等しい）からすべてのRTPパケットが最後のFU（Eフィールドが1に等しい）までのすべてのRTPパケットが断片化されています。NALユニットが収集されます。NALユニットは、対応するRTPパケットと同じ順序ですべてのFUペイロードを連結し、NALユニットヘッダーをフィールドF、レイリド、およびTIDをフィールドFの値に等しく等しくすることにより、これらのRTPパケットから抽出されます。セクション4.3.3で説明されているように、FUSのペイロードヘッダーのTID、およびFUSのFUヘッダーのフィールド先物の値に等しく設定されたNALユニットタイプを使用します。
When sprop-max-don-diff is equal to 0, the de-packetization buffer size is zero bytes, and 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.
sprop-max-don-diffが0に等しい場合、パケット化バッファーサイズはゼロバイトであり、単一のRTPストリームで運ばれるNALユニットは、透過順でデコーダーに直接渡されます。これはデコードと同一です注文。
When sprop-max-don-diff is greater than 0, the process described in the remainder of this section applies.
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.
バッファリング状態に関係なく、レシーバーは受信順に入力して脱パケット化バッファーに貯蔵します。RTPパケットで運ばれるNALユニットは、脱パケット化バッファーに個別に保存され、ABSDONの値は各NALユニットに対して計算および保存されます。
Initial buffering lasts until 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.
初期バッファリングは、脱パケット化バッファー内のNALユニットの最大と最小のアブサドン値の差がSPROP-MAX-DON-DIFFの値以上になるまで続きます。
After initial buffering, whenever 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, the following operation is repeatedly applied until this difference is smaller than sprop-max-don-diff:
初期バッファリング後、脱パケット化バッファーのNALユニットの最大と最小のアブサドン値の差がSprop-Max-Don-Diffの値以上である場合、この差まで、次の操作が繰り返し適用されます。sprop-max-don-diffよりも小さい：
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.
アブスドンの最小値を持つパケット化バッファーの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ユニットがバッファーから削除され、アブサドン値の増加の順にデコーダーに渡されます。
This section specifies the optional parameters. A mapping of the parameters with Session Description Protocol (SDP) [RFC8866] is also provided for applications that use SDP.
このセクションでは、オプションのパラメーターを指定します。セッション説明プロトコル（SDP）[RFC8866]を使用したパラメーターのマッピングは、SDPを使用するアプリケーションにも提供されています。
Parameters starting with the string "sprop" for stream properties can be used by a sender to provide a receiver with the properties of the stream that is or will be sent. The media sender (and not the receiver) selects whether, and with what values, "sprop" parameters are being sent. This uncommon characteristic of the "sprop" parameters may not be intuitive in the context of some signaling protocol concepts, especially with offer/answer. Please see Section 7.3.2 for guidance specific to the use of sprop parameters in the offer/answer case.
ストリームプロパティの文字列「SPROP」から始まるパラメーターは、送信者が送信者に送信するか、送信されるストリームのプロパティを提供することができます。メディア送信者（レシーバーではなく）は、「SPROP」パラメーターが送信されているかどうか、およびどの値でどのような値を選択しますか。「SPROP」パラメーターのこの珍しい特性は、特にオファー/回答の場合、一部のシグナル伝達プロトコルの概念のコンテキストでは直感的ではない場合があります。オファー/回答ケースでのSPROPパラメーターの使用に固有のガイダンスについては、セクション7.3.2を参照してください。
The receiver MUST ignore any parameter unspecified in this memo.
受信機は、このメモで不特定のパラメーターを無視する必要があります。
Type name: video
タイプ名：ビデオ
Subtype name: H266
サブタイプ名：H266
Required parameters: N/A
必要なパラメーター：n/a
Optional parameters: profile-id, tier-flag, sub-profile-id, interop-constraints, level-id, sprop-sublayer-id, sprop-ols-id, recv-sublayer-id, recv-ols-id, max-recv-level-id, sprop-dci, sprop-vps, sprop-sps, sprop-pps, sprop-sei, max-lsr, max-fps, sprop-max-don-diff, sprop-depack-buf-bytes, depack-buf-cap (refer to Section 7.2 for definitions).
オプションのパラメーター：Profile-ID、Tier-Flag、Sub-Profile-ID、Interop-Constraints、Level-ID、Sprop-Sublayer-ID、Sprop-Ols-ID、Recv-Sublayer-ID、Recv-Ols-ID、Max-RECV-LEVEL-ID、SPROP-DCI、SPROP-VPS、SPROP-SPS、SPROP-PPS、SPROP-SEI、MAX-LSR、MAX-FPS、SPROP-MAX-DON-DIFF、SPROP-DEPACK-BUFBYTES、depack-buf-cap（定義についてはセクション7.2を参照）。
Encoding considerations: This type is only defined for transfer via RTP [RFC3550].
考慮事項のエンコーディング：このタイプは、RTP [RFC3550]を介して転送するためにのみ定義されます。
Security considerations: See Section 9 of RFC 9328.
セキュリティ上の考慮事項：RFC 9328のセクション9を参照してください。
Interoperability considerations: N/A
相互運用性の考慮事項：n/a
Published specification: Please refer to RFC 9328 and VVC coding specification [VVC].
公開された仕様：RFC 9328およびVVCコーディング仕様[VVC]を参照してください。
Applications that use this media type: Any application that relies on VVC-based video services over RTP
このメディアタイプを使用するアプリケーション：RTPを介したVVCベースのビデオサービスに依存するアプリケーション
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：n/a
Additional information: N/A
追加情報：n/a
Person & email address to contact for further information: Stephan Wenger (stewe@stewe.org)
詳細については、人とメールアドレスをお問い合わせ：Stephan Wenger（stewe@stewe.org）
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: N/A
使用に関する制限：n/a
Author: See Authors' Addresses section of RFC 9328.
著者：RFC 9328の著者のアドレスセクションを参照してください。
Change controller: IETF <avtcore@ietf.org>
profile-id, tier-flag, sub-profile-id, interop-constraints, and level-id: These parameters indicate the profile, the tier, the default level, the sub-profile, and some constraints of the bitstream carried by the RTP stream, or a specific set of the profile, the tier, the default level, the sub-profile, and some constraints the receiver supports.
Profile-ID、ティアフラグ、サブプロファイルID、Interop-Constraints、およびLevel-ID：これらのパラメーターは、プロファイル、ティア、デフォルトレベル、サブプロファイル、およびビットストリームの一部の制約を示しています。RTPストリーム、またはプロファイル、ティア、デフォルトレベル、サブプロファイル、およびレシーバーがサポートするいくつかの制約の特定のセット。
The subset of coding tools that may have been used to generate the bitstream or that the receiver supports, as well as some additional constraints, are indicated collectively by profile-id, sub-profile-id, and interop-constraints.
ビットストリームを生成するために使用されている可能性のあるコーディングツールのサブセット、または受信機のサポート、およびいくつかの追加の制約は、プロファイルID、サブプロファイルID、およびインタープロコンストラリングによって集合的に示されています。
Informative note: There are 128 values of profile-id. The subset of coding tools identified by profile-id can be further constrained with up to 255 instances of sub-profile-id. In addition, 68 bits included in interop-constraints, which can be extended up to 324 bits, provide means to further restrict tools from existing profiles. To be able to support this fine-granular signaling of coding-tool subsets with profile-id, sub-profile-id, and interop-constraints, it would be safe to require symmetric use of these parameters in SDP offer/answer unless recv-ols-id is included in the SDP answer for choosing one of the layers offered.
有益なメモ：プロファイルIDには128の値があります。Profile-IDによって識別されるコーディングツールのサブセットは、サブプロファイルIDの最大255インスタンスでさらに制約できます。さらに、最大324ビットまで拡張できるInterop-Constraintsに含まれる68ビットは、既存のプロファイルからツールをさらに制限する手段を提供します。プロファイルID、サブプロファイルID、およびイントロプロコンストラリントを使用して、このコーディングツールサブセットのこの細粒シグナル伝達をサポートできるようにするには、recv-を除き、SDPオファー/回答でこれらのパラメーターを対称的に使用することを必要とすることは安全です。OLS-IDは、提供されるレイヤーの1つを選択するための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.
ティアはティアフラグで示されています。デフォルトレベルは、レベルIDで示されます。ティアとデフォルトレベルは、構文要素の値の制限または、ビットストリームを生成するときに従うまたは受信機がサポートする構文要素の値の算術の組み合わせを指定します。
In SDP offer/answer, when the SDP answer does not include the recv-ols-id parameter that is less than the sprop-ols-id parameter in the SDP offer, the following applies:
SDPオファー/回答では、SDPの回答にSDPオファーのSPROP-OLS-IDパラメーターよりも少ないRECV-OLS-IDパラメーターが含まれていない場合、次のものが適用されます。
* The tier-flag, profile-id, sub-profile-id, 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.
* Tier-Flag、Profile-ID、Sub-Profile-ID、およびInterop-Constraintsパラメーターは対称的に使用する必要があります。または暗黙的に推測されます。
* 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 higher than level-id in the offer for receiving can be included as max-recv-level-id.
* Revel-IDパラメーターは、答えによって示される最高レベルがオファーのものと等しいか低い限り、変更可能です。受信のオファーのレベルIDよりも高いレベルが高いことは、Max-Recv-Level-IDとして含めることができることに注意してください。
In SDP offer/answer, when the SDP answer does include the recv-ols-id parameter that is less than the sprop-ols-id parameter in the SDP offer, the set of tier-flag, profile-id, sub-profile-id, interop-constraints, and level-id parameters included in the answer MUST be consistent with that for the chosen output layer set 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-OLS-IDパラメーターよりも少ないRECV-OLS-IDパラメーターが含まれている場合、ティアフラグ、プロファイルID、サブプロファイル - のセットが含まれています。ID、Interop-Constraints、およびRevel-IDパラメーターは、SDPオファーに示されているように、選択した出力層セットのID、レベルIDパラメーターと一致する必要があります。答えによって示される最高レベルは、オファーのものと等しいものよりも低いためです。
More specifications of these parameters, including how they relate to syntax elements specified in [VVC], are provided below.
[VVC]で指定された構文要素にどのように関連するかを含む、これらのパラメーターのより多くの仕様を以下に示します。
profile-id: When profile-id is not present, a value of 1 (i.e., the Main 10 profile) MUST be inferred.
Profile-ID：Profile-IDが存在しない場合、1の値（つまり、メイン10プロファイル）を推測する必要があります。
When used to indicate properties of a bitstream, profile-id is derived from the general_profile_idc syntax element that applies to the bitstream in an instance of the profile_tier_level( ) syntax structure.
BitStreamのプロパティを示すために使用される場合、Profile-IDは、Profile_tier_level（）構文構造のインスタンスでビットストリームに適用されるgeneral_profile_idc構文要素から派生します。
VVC bitstreams transported over RTP using the technologies of this memo SHOULD contain only a single profile_tier_level( ) structure in the DCI, unless the sender can assure that a receiver can correctly decode the VVC bitstream, regardless of which profile_tier_level( ) structure contained in the DCI was used for deriving profile-id and other parameters for the SDP offer/answer exchange.
このメモのテクノロジーを使用してRTPを介して輸送されたVVC BitStreamsは、DCIに含まれているプロファイル_Tier_Level（）構造に関係なく、受信者がVVCビットストリームを正しくデコードできることを保証できる場合を除き、DCIにDCIの単一のプロファイル_Tier_Level（）構造のみを含める必要があります。SDPオファー/回答交換のプロファイルIDおよびその他のパラメーターを導き出すために使用されました。
As specified in [VVC], a profile_tier_level( ) syntax structure may be contained in an SPS NAL unit, and one or more profile_tier_level( ) syntax structures may be contained in a VPS NAL unit and in a DCI NAL unit. One of the following three cases applies to the container NAL unit of the profile_tier_level( ) syntax structure containing syntax elements used to derive the values of profile-id, tier-flag, level-id, sub-profile-id, or interop-constraints:
[VVC]で指定されているように、プロファイル_Tier_Level（）構文構造はSPS NALユニットに含まれる場合があり、1つ以上のプロファイル_Tier_Level（）構文構造は、VPS NALユニットとDCI NALユニットに含まれる場合があります。次の3つのケースのいずれかが、プロファイルID、ティアフラグ、レベル-ID、サブプロファイルID、またはインターポストコンストレンズの値を導出するために使用される構文要素を含むプロファイルのコンテナNALユニットに適用されます。：
1. The container NAL unit is an SPS, the bitstream is a single-layer bitstream, and the profile_tier_level( ) syntax structures in all SPSs referenced by the CVSs in the bitstream have the same values respectively for those profile_tier_level( ) syntax elements.
1. コンテナNALユニットはSPS、ビットストリームは単一層のビットストリームであり、BitStreamのCVSSによって参照されるすべてのSPSSのProfile_tier_level（）構文構造は、それらのprofile_tier_level（）構文要素についてそれぞれ同じ値を持っています。
2. The container NAL unit is a VPS, the profile_tier_level( ) syntax structure is the one in the VPS that applies to the OLS corresponding to the bitstream, and the profile_tier_level( ) syntax structures applicable to the OLS corresponding to the bitstream in all VPSs referenced by the CVSs in the bitstream have the same values respectively for those profile_tier_level( ) syntax elements.
2. コンテナNALユニットはVPS、Profile_Tier_Level（）構文構造は、BitStreamに対応するOLSに適用されるVPSの構造、およびProfile_tier_level（）によって参照されるすべてのVPSに対応するOLSに対応するOLSに適用されるOLSに適用される構文構造です。BitStreamのCVSSは、それらのprofile_tier_level（）構文要素に対してそれぞれ同じ値を持っています。
3. The container NAL unit is a DCI NAL unit, and the profile_tier_level( ) syntax structures in all DCI NAL units in the bitstream have the same values respectively for those profile_tier_level( ) syntax elements.
3. コンテナNALユニットはdci nalユニットであり、BitStreamのすべてのdci nalユニットのProfile_tier_level（）構文構造は、それらのprofile_tier_level（）構文要素に対してそれぞれ同じ値を持っています。
[VVC] allows for multiple profile_tier_level( ) structures in a DCI NAL unit, which may contain different values for the syntax elements used to derive the values of profile-id, tier-flag, level-id, sub-profile-id, or interop-constraints in the different entries. However, herein defined is only a single profile-id, tier-flag, level-id, sub-profile-id, or interop-constraints. When signaling these parameters and a DCI NAL unit is present with multiple profile_tier_level( ) structures, these values SHOULD be the same as the first profile_tier_level structure in the DCI, unless the sender has ensured that the receiver can decode the bitstream when a different value is chosen.
[VVC]は、dci nalユニットの複数のprofile_tier_level（）構造を可能にします。これには、プロファイルID、ティアフラグ、レベルID、サブプロファイルID、またはサブプロファイルIDの値を導出するために使用される構文要素の異なる値が含まれる場合があります。さまざまなエントリのイントラポントレイン。ただし、ここでは定義されているのは、単一のプロファイルID、ティアフラグ、レベルID、サブプロファイルID、またはインターポストコンストラリングのみです。これらのパラメーターとdci nalユニットに複数のprofile_tier_level（）構造が存在する場合、これらの値は、レシーバーが別の値が別の値である場合にビットストリームをデコードできることを確認しない限り、DCIの最初のプロファイル_tier_level構造と同じでなければなりません。選ばれた。
tier-flag, level-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、Level-ID：ティアフラグの値は、包括的0〜1の範囲でなければなりません。レベル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.
ビットストリームのプロパティを示すためにティアフラグおよびレベル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.
ティアフラグおよびレベルIDパラメーターが機能交換に使用されている場合、次のものが適用されます。Max-Recv-Level-IDが存在しない場合、レベル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 51 (i.e., level 3.1) MUST be inferred.
ティアフラグが存在しない場合、0の値を推測する必要があります。レベルIDが存在しない場合、51（つまり、レベル3.1）の値を推測する必要があります。
Informative note: The level values currently defined in the VVC specification are in the form of "majorNum.minorNum", and the value of the level-id for each of the levels is equal to majorNum * 16 + minorNum * 3. It is expected that, if any levels are defined in the future, the same convention will be used, but this cannot be guaranteed.
有益なメモ：VVC仕様で現在定義されているレベル値は「Majornum.Minornum」の形式であり、各レベルのレベルIDの値はMajornum * 16 Minornum *に等しくなります。3。、将来、いずれかのレベルが定義されている場合、同じ条約が使用されますが、これを保証することはできません。
When used to indicate properties of a bitstream, the tier-flag and level-id parameters are derived respectively from the syntax element general_tier_flag, and the syntax element general_level_idc or sub_layer_level_idc[j], that apply to the bitstream in an instance of the profile_tier_level( ) syntax structure.
ビットストリームのプロパティを示すために使用される場合、ティアフラグとレベルIDパラメーターは、それぞれSyntax Element general_tier_flag、およびSyntax Element general_level_idcまたはsub_layer_level_idc [j]から導き出されます。）構文構造。
If the tier-flag and level-id are derived from the profile_tier_level( ) syntax structure in a DCI NAL unit, the following applies:
Tier-FlagおよびLevel-IDがDCI NINALユニットのProfile_Tier_Level（）構文構造から派生している場合、次のものが適用されます。
* tier-flag = general_tier_flag
* tier-flag = general_tier_flag
* level-id = general_level_idc
* level-id = general_level_idc
Otherwise, if the tier-flag and level-id are derived from the profile_tier_level( ) syntax structure in an SPS or VPS NAL unit, and the bitstream contains the highest sublayer representation in the OLS corresponding to the bitstream, the following applies:
それ以外の場合、Tier-FlagとLevel-IDがSPSまたはVPS NALユニットのプロファイル_Tier_Level（）構文構造から派生している場合、BitStreamにはBitStreamに対応するOLSの最高のサブレイヤー表現が含まれています。
* tier-flag = general_tier_flag
* tier-flag = general_tier_flag
* level-id = general_level_idc
* level-id = general_level_idc
Otherwise, if the tier-flag and level-id are derived from the profile_tier_level( ) syntax structure in an SPS or VPS NAL unit, and the bitstream does not contain the highest sublayer representation in the OLS corresponding to the bitstream, the following applies, with j being the value of the sprop-sublayer-id parameter:
それ以外の場合、Tier-FlagとLevel-IDがSPSまたはVPS NALユニットのプロファイル_Tier_Level（）構文構造から派生している場合、BitStreamにはBitStreamに対応するOLSの最高のサブレイヤー表現が含まれていない場合、次のものが適用されます。JがSprop-Sublayer-IDパラメーターの値であることを次のようにします。
* tier-flag = general_tier_flag
* tier-flag = general_tier_flag
* level-id = sub_layer_level_idc[j]
* level-id = sub_layer_level_idc [j]
sub-profile-id: The value of the parameter is a comma-separated (',') list of data using base64 encoding (Section 4 of [RFC4648]) representation without "==" padding.
サブプロファイルID：パラメーターの値は、base64エンコーディング（[RFC4648]のセクション4）表現を使用したデータのコンマ分離（ '、'）リストです。
When used to indicate properties of a bitstream, sub-profile-id is derived from each of the ptl_num_sub_profiles general_sub_profile_idc[i] syntax elements that apply to the bitstream in a profile_tier_level( ) syntax structure.
ビットストリームのプロパティを示すために使用される場合、サブプロファイルIDは、ptl_num_sub_profiles general_sub_profile_idc [i]プロファイルのビットストリームに適用される構文要素のそれぞれから派生します。
interop-constraints: A base64 encoding (Section 4 of [RFC4648]) representation of the data that includes the ptl_frame_only_constraint_flag syntax element, the ptl_multilayer_enabled_flag syntax element, and the general_constraints_info( ) syntax structure that apply to the bitstream in an instance of the profile_tier_level( ) syntax structure.
Interop-Constraints：a base64エンコード（[RFC4648]のセクション4）PTL_FRAME_ONLY_CONSTRAINT_FLAG SYNTILAYER_ENABLED_FLAG SYNTAX ELEMENT、およびGENERAL_CONTRAINTS_INFO（）Syntax Structureのgeneral_constraints_infoを含むデータの表現）構文構造。
If the interop-constraints parameter is not present, the following MUST be inferred:
Interop-Constraintsパラメーターが存在しない場合、以下を推測する必要があります。
* ptl_frame_only_constraint_flag = 1
* ptl_frame_only_constraint_flag = 1
* ptl_multilayer_enabled_flag = 0
* ptl_multilayer_enabled_flag = 0
* gci_present_flag in the general_constraints_info( ) syntax structure = 0
* general_constraints_info（）syntax structure = 0のgci_present_flag
Using interop-constraints for capability exchange results in a requirement on any bitstream to be compliant with the interop-constraints.
能力交換のためにインターポストコンストラリントを使用すると、任意のビットストリームがイントラポントレインに準拠する必要があります。
sprop-sublayer-id: This parameter MAY be used to indicate the highest allowed value of TID in the bitstream. When not present, the value of sprop-sublayer-id is inferred to be equal to 6.
SPROP-SUBLAYER-ID：このパラメーターを使用して、ビットストリームでTIDの最高値を示すことができます。存在しない場合、SPROP-Sublayer-IDの値は6に等しいと推測されます。
The value of sprop-sublayer-id MUST be in the range of 0 to 6, inclusive.
SPROP-Sublayer-IDの値は、包括的0〜6の範囲でなければなりません。
sprop-ols-id: This parameter MAY be used to indicate the OLS that the bitstream applies to. When not present, the value of sprop-ols-id is inferred to be equal to TargetOlsIdx, as specified in Section 8.1.1 of [VVC]. If this optional parameter is present, sprop-vps MUST also be present or its content MUST be known a priori at the receiver.
SPROP-OLS-ID：このパラメーターは、ビットストリームが適用するOLSを示すために使用できます。存在しない場合、[VVC]のセクション8.1.1で指定されているように、SPROP-OLS-IDの値はTargetolSidxに等しいと推測されます。このオプションのパラメーターが存在する場合、SPROP-VPも存在する必要があります。または、そのコンテンツが受信機で先験的に既知である必要があります。
The value of sprop-ols-id MUST be in the range of 0 to 256, inclusive.
SPROP-OLS-IDの値は、包括的0〜256の範囲でなければなりません。
Informative note: VVC allows having up to 257 output layer sets indicated in the VPS, as the number of output layer sets minus 2 is indicated with a field of 8 bits.
有益なメモ：VVCは、出力層の数マイナス2が8ビットのフィールドで示されるため、VPSに示される最大257出力層セットを持つことができます。
recv-sublayer-id: This parameter MAY be used to signal a receiver's choice of the offered or declared sublayer representations in sprop-vps and sprop-sps. The value of recv-sublayer-id indicates the TID of the highest sublayer that a receiver supports. When not present, the value of recv-sublayer-id is inferred to be equal to the value of the sprop-sublayer-id parameter in the SDP offer.
RECV-Sublayer-ID：このパラメーターは、SPROP-VPSおよびSPROP-SPSで提供されたまたは宣言されたサブレーヤー表現を受信者が選択することを信号するために使用できます。Recv-Sublayer-IDの値は、受信者がサポートする最高の昇華層のTIDを示しています。存在しない場合、RECV-Sublayer-IDの値は、SDPオファーのSPROP-Sublayer-IDパラメーターの値に等しいと推測されます。
The value of recv-sublayer-id MUST be in the range of 0 to 6, inclusive.
recv-sublayer-idの値は、包括的0〜6の範囲でなければなりません。
recv-ols-id: This parameter MAY be used to signal a receiver's choice of the offered or declared output layer sets in sprop-vps. The value of recv-ols-id indicates the OLS index of the bitstream that a receiver supports. When not present, the value of recv-ols-id is inferred to be equal to the value of the sprop-ols-id parameter inferred from or indicated in the SDP offer. When present, the value of recv-ols-id must be included only when sprop-ols-id was received and must refer to an output layer set in the VPS that includes no layers other than all or a subset of the layers of the OLS referred to by sprop-ols-id. If this optional parameter is present, sprop-vps must have been received or its content must be known a priori at the receiver.
RECV-OLS-ID：このパラメーターを使用して、SPROP-VPSで提供された出力層セットまたは宣言された出力層セットを受信者が選択することを知らせることができます。RECV-OLS-IDの値は、受信者がサポートするビットストリームのOLSインデックスを示します。存在しない場合、RECV-OLS-IDの値は、SDPオファーから推定または示されているSPROP-OLS-IDパラメーターの値に等しいと推測されます。存在する場合、RECV-OLS-IDの値は、SPROP-OLS-IDが受信された場合にのみ含める必要があり、OLSのすべてまたはサブセット以外のレイヤー以外のレイヤーを含むVPSの出力層を参照する必要があります。sprop-ols-idによって言及されています。このオプションのパラメーターが存在する場合、SPROP-VPが受信されている必要があります。または、そのコンテンツが受信機の先験的なものを知っている必要があります。
The value of recv-ols-id MUST be in the range of 0 to 256, inclusive.
recv-ols-idの値は、0〜256の範囲でなければなりません。
max-recv-level-id: This parameter MAY be used to indicate the highest level a receiver supports.
MAX-RECV-LEVEL-ID：このパラメーターは、受信機がサポートする最高レベルを示すために使用できます。
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が存在しない場合、値はレベル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が存在してはなりません。
sprop-dci: This parameter MAY be used to convey a decoding capability information NAL unit of the bitstream for out-of-band transmission. The parameter MAY also be used for capability exchange. The value of the parameter is a base64 encoding (Section 4 of [RFC4648]) representation of the decoding capability information NAL unit, as specified in Section 7.3.2.1 of [VVC].
SPROP-DCI：このパラメーターを使用して、バンド外の伝送のためにビットストリームのデコード機能情報nalユニットを伝達することができます。パラメーターは、機能交換にも使用できます。パラメーターの値は、[VVC]のセクション7.3.2.1で指定されているように、デコード機能情報NALユニットの表現（[RFC4648]のセクション4）の表現です。
sprop-vps: This parameter MAY be used to convey any video parameter set to the 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 substream characteristics (i.e., properties of output layer sets and sublayer representations, as defined in [VVC]). The value of the parameter is a comma-separated (',') list of base64 encoding (Section 4 of [RFC4648]) representations of the video parameter set NAL units, as specified in Section 7.3.2.3 of [VVC].
SPROP-VPS：このパラメーターを使用して、ビデオパラメーターセットのバンド外送信のために、ビットストリームのNALユニットに設定されたビデオパラメーターを伝達することができます。パラメーターは、能力交換やサブストリーム特性（つまり、[VVC]で定義されている出力層セットとサブレイヤー表現のプロパティ）を示すために使用することもできます。パラメーターの値は、[VVC]のセクション7.3.2.3で指定されているように、ビデオパラメーターセットNALユニットのbase64エンコード（[RFC4648]のセクション4）表現のコンマ分離された（ '、'）リストです。
The sprop-vps parameter MAY contain one or more than one video parameter set NAL units. 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 the number of OLSs in vpsA and vpsB are the same and any decoder that conforms to the profile, tier, level, and constraints indicated by the data starting from the syntax element general_profile_idc to the syntax structure general_constraints_info(), inclusive, in the profile_tier_level( ) syntax structure corresponding to any OLS with index olsIdx in vpsA can decode any CVS(s) referencing vpsB when TargetOlsIdx is equal to olsIdx that conforms to the profile, tier, level, and constraints indicated by the data starting from the syntax element general_profile_idc to the syntax structure general_constraints_info(), inclusive, in the profile_tier_level( ) syntax structure corresponding to the OLS with index TargetOlsIdx in vpsB.
SPROP-VPSパラメーターには、1つまたは複数のビデオパラメーターセットNALユニットが含まれている場合があります。ただし、SPROP-VPSパラメーターに含まれる他のすべてのビデオパラメーターセットは、SPROP-VPSパラメーターの最初のビデオパラメーターセットと一致する必要があります。ビデオパラメーターセットVPSBは、VPSAおよびVPSBのOLSの数が同じであり、プロファイル、層、レベル、および制約に適合するデコーダーの数が同じである場合、別のビデオパラメーターセットVPSAと一致すると言われています。構文要素general_profile_idc to the syntax structure general_constraints_info（）、inclusive、forpemore_tier_level（）index olsidxを持つ任意のOLSに対応する構文構造は、VPSBを参照するCVをデコードできます。構文要素general_profile_idcから構文構造general_constraints_info（）までのデータによって示される層、レベル、および制約は、VPSBのIndex Targetolsidxを伴うOLSに対応するOLSに対応する構文構造に包括的で、包括的で包括的である。
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 encoding (Section 4 of [RFC4648]) representations of the sequence parameter set NAL units, as specified in Section 7.3.2.4 of [VVC].
SPROP-SPS：このパラメーターを使用して、シーケンスパラメーターセットのバンド外送信のために、ビットストリームのシーケンスパラメーターセットNAL単位を伝達することができます。パラメーターの値は、[VVC]のセクション7.3.2.4で指定されているように、シーケンスパラメーターセットNAL単位のベース64エンコーディング（[RFC4648]のセクション4）表現のコンマ分離された（ '、'）リストです。
A sequence parameter set spsB is said to be consistent with another sequence parameter set spsA if any decoder that conforms to the profile, tier, level, and constraints indicated by the data starting from the syntax element general_profile_idc to the syntax structure general_constraints_info(), inclusive, in the profile_tier_level( ) syntax structure in spsA can decode any CLVS(s) referencing spsB that conforms to the profile, tier, level, and constraints indicated by the data starting from the syntax element general_profile_idc to the syntax structure general_constraints_info(), inclusive, in the profile_tier_level( ) syntax structure in spsB.
シーケンスパラメーターセットSPSBは、Syntax Element general_profile_idcからSyntax構造の一般_constraints_info（）、インクルーシブなデータから始まるデータによって示されるプロファイル、ティア、レベル、および制約に準拠するデコーダーがある場合、別のシーケンスパラメーターセットSPSAと一致すると言われています。、spsaのプロファイルのプロファイルの構文構造は、Syntax Element general_profile_idcからSyntax構造一般_constraints_info（）、包括的なデータから始まるデータによって示されるプロファイル、層、レベル、および制約に準拠するSPSBを参照する任意のCLVをデコードできます。、spsbのprofile_tier_level（）構文構造で。
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 encoding (Section 4 of [RFC4648]) representations of the picture parameter set NAL units, as specified in Section 7.3.2.5 of [VVC].
SPROP-PPS：このパラメーターを使用して、画像パラメーターセットのバンド外送信のために、ビットストリームの画像パラメーターセットNALユニットを伝達することができます。パラメーターの値は、[VVC]のセクション7.3.2.5で指定されているように、画像パラメーターセットNALユニットの表現（[RFC4648]のセクション4）表現のbase64エンコード（[RFC4648]のセクション4）表現のコンマ分離（ '、'）リストです。
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 [VSEI].
SPROP-SEI：このパラメーターは、ビットストリーム特性を記述する1つ以上のSEIメッセージを伝達するために使用できます。存在する場合、デコーダーは、[VSEI]で指定されているように、SEIメッセージの永続性スコープとは独立して、セッション全体でSEIメッセージで説明されているビットストリーム特性に依存できます。
The value of the parameter is a comma-separated (',') list of base64 encoding (Section 4 of [RFC4648]) representations of SEI NAL units, as specified in [VSEI].
パラメーターの値は、[VSEI]で指定されているように、sei nalユニットの表現（[RFC4648]のセクション4）表現のbase64エンコード（[RFC4648]のセクション4）のコンマ分離された（ '、'）リストです。
| 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:
|
| 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 is likely meaningful, and
| sending it 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.
|
| 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) or the filler payload SEI message (as
| there is no point in just having more bits in SDP).
max-lsr: The max-lsr MAY be used to signal the capabilities of a receiver implementation and MUST NOT be used for any other purpose. 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：MAX-LSRを使用して、受信機の実装の機能を知らせるために使用でき、他の目的に使用してはなりません。Max-LSRの値は、秒単位のLUMAサンプルの最大処理速度を示す整数です。MAX-LSRパラメーターは、受信機が最高レベルで必要とされるよりも高いレートでビデオをデコードできることを示しています。
Informative note: When the OPTIONAL media type parameters are used to signal the properties of a bitstream, and max-lsr is not present, the values of tier-flag, profile-id, sub-profile-id, interop-constraints, and level-id must always be such that the bitstream complies fully with the specified profile, sub-profile, tier, level, and interop-constraints.
有益なメモ：オプションのメディアタイプパラメーターを使用してビットストリームのプロパティを信号し、MAX-LSRが存在しない場合、Tier-Flag、Profile-ID、Sub-Profile-ID、Interop-Constraints、およびレベルの値-idは、BitStreamが指定されたプロファイル、サブプロファイル、ティア、レベル、およびイントラポンストレインに完全に準拠するようなものである必要があります。
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.3 of [VVC] 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が信号を送信すると、受信機は最高レベルの表A.3のMaxlumasR値が最高レベルの[VVC]の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.3 of [VVC] for the highest level.
存在しない場合、MAX-LSRの値は、最高レベルの[VVC]の表A.3に示されているMaxlumasRの値に等しいと推測されます。
The value of max-lsr MUST be in the range of MaxLumaSr to 16 * MaxLumaSr, inclusive, where MaxLumaSr is given in Table A.3 of [VVC] for the highest level.
Max-LSRの値は、Maxlumasrの範囲16 * maxlumasrの範囲でなければなりません。ここで、Maxlumasrは[VVC]の表A.3に最高レベルで示されています。
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, max-lsr.
MAX-FPS：Max-FPSの値は、受信機が効果的に処理できる100秒あたりの画像単位の最大画像レートを示す整数です。MAX-FPSパラメーターを使用して、受信機が最高レベルで暗示され、存在する場合、Max-LSRによって暗示される全体像レートでビデオを効果的に処理できないという制約があることを示すことができます。
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 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-FPSが制約を信号するために使用され、他のパラメーターによって暗示されるものから最大画像レートを下げるという点で、最大LSRと意味的に異なります。
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, max-lsr.
Max-FPSの値は、最高レベルと存在する場合、Max-LSRによって暗示される全体像率以下でなければなりません。
sprop-max-don-diff: If 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.
SPROP-MAX-DON-DIFF：NALユニットの任意のNALユニットがデコード順序で伝送順に続くNALユニットNALUAがない場合（つまり、NALユニットの伝送順序はデコード順序と同じです）、このパラメーターの値は0に等しくなければなりません。
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）値間の最大絶対差を指定します。ここで、NaluaはNALUBに従って順序をデコードし、透過順序でNALUBに先行します。
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-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.
SPROP-DEPACK-BUF-BYTES：このパラメーターは、バイト単位のパケット化バッファーの必要なサイズを指示します。パラメーターの値は、セクション6で指定されているように、脱パケット化バッファーの最大バッファー占有率（バイト単位）以上でなければなりません。
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より大きくなければなりません。。
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: 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 the RTP stream. A receiver is able to handle any RTP stream for which the value of the sprop-depack-buf-bytes parameter is smaller than or equal to this parameter.
DEPACK-BUF-CAP：このパラメーターは、受信機の実装の機能を信号し、RTPストリームで運ばれたNALユニットからのNALユニットデコード順序を再構築できるバイト単位のパケット化バッファースペースの量を示します。レシーバーは、Sprop-Depack-Buf-Bytesパラメーターの値がこのパラメーター以下であるRTPストリームを処理できます。
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は、ネットワークジッターを許可せずに、受信機のみのパケット化バッファーの最大サイズを示します。
The receiver MUST ignore any parameter unspecified in this memo.
受信機は、このメモで不特定のパラメーターを無視する必要があります。
The media type video/H266 string is mapped to fields in the Session Description Protocol (SDP) [RFC8866] as follows:
メディアタイプのビデオ/H266文字列は、次のようにセッション説明プロトコル（SDP）[RFC8866]のフィールドにマッピングされます。
* The media name in the "m=" line of SDP MUST be video.
* SDPの「m =」行のメディア名はビデオでなければなりません。
* The encoding name in the "a=rtpmap" line of SDP MUST be H266 (the media subtype).
* SDPの「a = rtpmap」行のエンコード名は、H266（メディアサブタイプ）でなければなりません。
* The clock rate in the "a=rtpmap" line MUST be 90000.
* 「a = rtpmap」行のクロックレートは90000でなければなりません。
* The OPTIONAL parameters profile-id, tier-flag, sub-profile-id, interop-constraints, level-id, sprop-sublayer-id, sprop-ols-id, recv-sublayer-id, recv-ols-id, max-recv-level-id, max-lsr, max-fps, sprop-max-don-diff, sprop-depack-buf-bytes, and depack-buf-cap, when present, MUST be included in the "a=fmtp" line of SDP. The fmtp line is expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
* オプションのパラメータープロファイルID、Tier-Flag、Sub-Profile-ID、Interop-Constraints、Level-ID、Sprop-Sublayer-ID、Sprop-Ols-ID、Recv-Sublayer-ID、Recv-Ols-ID、Max-recv-level-id、max-lsr、max-fps、sprop-max-don-diff、sprop-depack-buf-bytes、およびdepack-buf-capは、存在する場合は、「a = fmtp」に含める必要があります。「SDPのライン。FMTP行は、パラメーター=値ペアのセミコロン分離リストの形で、メディアタイプの文字列として表されます。
* The OPTIONAL parameters sprop-vps, sprop-sps, sprop-pps, sprop-sei, and sprop-dci, 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, sprop-pps, sprop-sei, or sprop-dci 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, those 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, sprop-pps, sprop-sei, and sprop-dci 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.
* オプションのパラメーターSPROP-VPS、SPROP-SPS、SPROP-PPS、SPROP-SEI、およびSPROP-DCIは、存在する場合は、SDPの「A = FMTP」ラインに含めるか、「FMTP」ソース属性を使用して伝達する必要があります。[RFC5576]のセクション6.3で指定されています。特定のメディア形式（つまり、RTPペイロードタイプ）の場合、SPROP-VPS、SPROP-SPS、SPROP-PPS、SPROP-SEI、またはSPROP-DCIの両方を、SDPの「A = FMTP」ラインに含めて伝えてはなりません「FMTP」ソース属性を使用します。SDPの「a = fmtp」行に含まれる場合、これらのパラメーターは、パラメーター=値ペアのセミコロン分離されたリストの形で、メディア型文字列として表されます。特定のペイロードタイプのSDPの「a = fmtp」ラインで伝達された場合、パラメーターSPROP-VPS、SPROP-SPS、SPROP-PPS、SPROP-SEI、およびSPROP-DCIをペイロードタイプで各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の運搬により、[[]で指定されているように、Topo-Video-Switch-MCUなどのトポロジーのパラメーターセットの帯域外輸送が可能になります。RFC7667]。
A general usage of media representation in SDP is as follows:
SDPでのメディア表現の一般的な使用法は次のとおりです。
m=video 49170 RTP/AVP 98
a=rtpmap:98 H266/90000
a=fmtp:98 profile-id=1;
sprop-vps=<video parameter sets data>;
sprop-sps=<sequence parameter set data>;
sprop-pps=<picture parameter set data>;
A SIP offer/answer exchange wherein both parties are expected to both send and receive could look like the following. Only the media codec-specific parts of the SDP are shown. Some lines are wrapped due to text constraints.
両方の当事者が送信と受信の両方が期待されるSIPオファー/回答交換は、次のように見えることがあります。SDPのメディアコーデック固有の部分のみが表示されます。テキストの制約のためにいくつかの行が包まれています。
Offerer->Answerer:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H266/90000
a=fmtp:98 profile-id=1; level_id=83;
The above represents an offer for symmetric video communication using [VVC] and its payload specification at the main profile and level 5.1 (and as the levels are downgradable, all lower levels). Informally speaking, this offer tells the receiver of the offer that the sender is willing to receive up to 4Kp60 resolution at the maximum bitrates specified in [VVC]. At the same time, if this offer were accepted "as is", the offer can expect that the answerer would be able to receive and properly decode H.266 media up to and including level 5.1.
上記は、[VVC]を使用した対称的なビデオ通信と、メインプロファイルとレベル5.1でのペイロード仕様のオファーを表しています（およびレベルが格下げ可能であり、すべて低いレベル）。非公式に言えば、このオファーは、送信者が[VVC]で指定された最大ビットレートで最大4kp60の解像度を受け取る意思があることをオファーの受信者に伝えています。同時に、このオファーが「現状のまま」受け入れられた場合、この申し出は、レベル5.1を含むH.266メディアを受信して適切にデコードできることをオファーが期待できます。
Answerer->Offerer:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H266/90000
a=fmtp:98 profile-id=1; level_id=67
With this answer to the offer above, the system receiving the offer advises the offerer that it is incapable of handing H.266 at level 5.1 but is capable of decoding 1080p60. As H.266 video codecs must support decoding at all levels below the maximum level they implement, the resulting user experience would likely be that both systems send video at 1080p60. However, nothing prevents an encoder from further downgrading its sending to, for example, 720p30 if it were short of cycles or bandwidth or for other reasons.
上記のオファーに対するこの回答により、オファーを受け取るシステムは、レベル5.1でH.266を渡すことができないが、1080p60をデコードできることを申し出者に助言します。H.266ビデオコーデックは、実装する最大レベル以下のすべてのレベルでのデコードをサポートする必要があるため、結果として生じるユーザーエクスペリエンスは、両方のシステムが1080p60でビデオを送信する可能性が高いでしょう。ただし、サイクルや帯域幅、その他の理由により、エンコーダーが送信をさらに格下げすることを防ぐものはありません。たとえば、720p30などです。
This section describes the negotiation of unicast messages using the offer/answer model as described in [RFC3264] and its updates. The section is split into subsections, covering a) media format configurations not involving non-temporal scalability; b) scalable media format configurations; c) the description of the use of those parameters not involving the media configuration itself but rather the parameters of the payload format design; and d) multicast.
このセクションでは、[RFC3264]とその更新に記載されているオファー/回答モデルを使用したユニキャストメッセージの交渉について説明します。セクションはサブセクションに分割され、a）非同時のスケーラビリティを含むメディア形式の構成をカバーします。b）スケーラブルなメディア形式の構成。c）メディア構成自体ではなく、ペイロード形式の設計のパラメーターを含むこれらのパラメーターの使用の説明。およびd）マルチキャスト。
A non-scalable VVC media configuration is such a configuration where no non-temporal scalability mechanisms are allowed. In [VVC] version 1, it is implied that general_profile_idc indicates one of the following profiles: Main 10, Main 10 Still Picture, Main 10 4:4:4, or Main 10 4:4:4 Still Picture, with general_profile_idc values of 1, 65, 33, and 97, respectively. Note that non-scalable media configurations include temporal scalability inline with VVC's design philosophy and profile structure.
非スケーラブルなVVCメディア構成は、非同時のスケーラビリティメカニズムが許可されていないこのような構成です。[vvc]バージョン1では、一般的な_profile_idcが次のプロファイルのいずれかを示していることが暗示されています。メイン10、メイン10静止画、メイン10 4：4：4、またはメイン10 4：4：4静止画、general_profile_idc値それぞれ1、65、33、および97。非スケーラブルなメディア構成には、VVCの設計哲学とプロファイル構造との時間的スケーラビリティが含まれていることに注意してください。
The following limitations and rules pertaining to the media configuration apply:
メディア構成に関連する以下の制限と規則が適用されます。
* The parameters identifying a media format configuration for VVC are profile-id, tier-flag, sub-profile-id, level-id, and interop-constraints. These media configuration parameters, except level-id, MUST be used symmetrically.
* VVCのメディア形式構成を識別するパラメーターは、Profile-ID、Tier-Flag、Sub-Profile-ID、Level-ID、およびInterop Constraintsです。これらのメディア構成パラメーターは、レベルIDを除く、対称的に使用する必要があります。
The answerer MUST structure its answer according to one of the following three options:
回答者は、次の3つのオプションのいずれかに従って、回答を構成する必要があります。
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. すべての構成パラメーターを維持し、値がメディア形式のオファー（ペイロードタイプ）と同じままであり、レベルIDの値が回答によって示される最高レベルがそれよりも高くない限り、変更可能であることを除いて、申し出によって示されています。
2. include in the answer the recv-sublayer-id parameter, with a value less than the sprop-sublayer-id parameter in the offer, for the media format (payload type), and 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 the level indicated by sprop-sps or sprop-vps in offer for the chosen sublayer representation; or
2. 回答には、メディア形式（ペイロードタイプ）に対して、オファーのSPROP-SUBLAYER-IDパラメーターよりも小さい値を備えたRECV-Sublayer-IDパラメーターを含めます。Media Format（Payload Type）のオファーは、回答で示される最高レベルがSPROP-SPSまたはSPROP-VPSが提供されているレベルよりも高くない限り、レベルIDの値が変更可能であることを除いて、変更可能であることを除きます。選択したサブレイヤー表現。また
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, as described in Section 7.3.2.3 below.
有益なメモ：対称使用の上記の要件は、レベルIDには適用されず、以下のセクション7.3.2.3で説明するように、他のビットストリームまたはRTPストリームプロパティと機能パラメーターには適用されません。
* 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].
* これらの構成の取り扱いと一致を簡素化するには、[RFC3264]で指定されているように、オファーで使用される同じRTPペイロードタイプ番号も回答で使用する必要があります。
* The same RTP payload type number used in the offer for the media subtype H266 MUST be used in the answer when the answer includes recv-sublayer-id. When the answer does not include recv-sublayer-id, the answer MUST NOT contain a payload type number used in the offer for the media subtype H266 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-sublayer-id parameter if a VVC bitstream contains multiple operation points (using temporal scalability and sublayers) and sprop-sps or sprop-vps is included in the offer where information of sublayers are present in the first sequence parameter set or video parameter set contained in sprop-sps or sprop-vps, respectively. If sprop-sps or sprop-vps is provided in an offer, an answerer MAY select a particular operation point indicated in the first sequence parameter set or video parameter set contained in sprop-sps or sprop-vps, respectively. When the answer includes a recv-sublayer-id that is less than a sprop-sublayer-id in the offer, the following applies:
* Media SubType H266のオファーで使用される同じRTPペイロードタイプ番号は、回答にrecv-sublayer-idが含まれている場合、回答で使用する必要があります。回答にrecv-sublayer-idが含まれていない場合、回答には、構成がオファーとまったく同じである場合、または回答の構成が異なる場合を除き、メディアサブタイプH266のオファーで使用されるペイロードタイプ番号を含めてはなりません。レベルIDの異なる価値を持つオファーで。VVC BitStreamに複数の動作ポイント（時間的スケーラビリティとサブレーヤーを使用）を含む場合、回答にはRECV-Sublayer-IDパラメーターが含まれ、SPROP-SPSまたはSPROP-VPSが最初のシーケンスパラメーターに属性の情報が存在するオファーに含まれています。それぞれSPROP-SPSまたはSPROP-VPSに含まれるセットまたはビデオパラメーターセット。SPROP-SPSまたはSPROP-VPSがオファーで提供されている場合、回答者は、それぞれSPROP-SPSまたはSPROP-VPSに含まれる最初のシーケンスパラメーターセットまたはビデオパラメーターセットに示されている特定の操作ポイントを選択できます。答えに、オファーのsprop-sublayer-idよりも少ないrecv-sublayer-idが含まれている場合、以下が適用されます。
1. When the sprop-sps parameter is present, all sequence parameter sets contained in the sprop-sps parameter in the SDP answer and all sequence parameter sets sent in-band for either the offerer-to-answerer direction or the answerer-to-offerer direction MUST be consistent with the first sequence parameter set in the sprop-sps parameter of the offer (see the semantics of sprop-sps in Section 7.1 of this document on one sequence parameter set being consistent with another sequence parameter set).
1. SPROP-SPSパラメーターが存在する場合、すべてのシーケンスパラメーターセットは、SDP回答のSPROP-SPSパラメーターに含まれ、すべてのシーケンスパラメーターセットは、オファーから回答者への方向または回答者からオフファレンの方向のいずれかでバンド内で送信されますオファーのSPROP-SPSパラメーターの最初のシーケンスパラメーターセットと一致する必要があります（別のシーケンスパラメーターセットと一致する1つのシーケンスパラメーターセットのこのドキュメントのセクション7.1のSPROP-SPSのセマンティクスを参照）。
2. When the sprop-vps parameter is present, 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).
2. SPROP-VPSパラメーターが存在する場合、すべてのビデオパラメーターセットは、SDP回答のSPROP-VPSパラメーターに含まれ、すべてのビデオパラメーターセットは、オファーから回答者への方向または回答者からオブフォーの方向のいずれかでバンド内で送信されますオファーのSPROP-VPSパラメーターの最初のビデオパラメーターセットと一致する必要があります（あるビデオパラメーターセットのこのドキュメントのセクション7.1のSPROP-VPSのセマンティクスは、別のビデオパラメーターセットと一致しています）。
3. The bitstream sent in either direction MUST conform to the profile, tier, level, and constraints of the chosen sublayer representation, as indicated by the profile_tier_level( ) syntax structure in the first sequence parameter set in the sprop-sps parameter or by the first profile_tier_level( ) syntax structure in the first video parameter set in the sprop-vps parameter of the offer.
3. いずれかの方向に送信されたビットストリームは、SPROP-SPSパラメーターの最初のシーケンスパラメーターのプロファイル_tier_level（）の構文構造またはfirst profile_tier_levelによって示されるように、選択したサブレイヤー表現のプロファイル、層、レベル、および制約に準拠する必要があります。（）オファーのSPROP-VPSパラメーターに設定された最初のビデオパラメーターの構文構造。
Informative note: When an offerer receives an answer that does not include recv-sublayer-id, it has to compare payload types not declared in the offer based on the media type (i.e., video/ H266) 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 a VVC bitstream.
有益なメモ：オファーがrecv-sublayer-idを含まない回答を受け取った場合、メディアタイプ（つまり、ビデオ/ H266）および上記のメディア構成パラメーターに基づいてオファーで宣言されていないペイロードタイプを比較する必要があります。すでに宣言されているペイロードタイプ。これにより、問題の構成が新規であるかどうか、または回答で異なるペイロードタイプ番号を使用できるため、既に提供されている構成と同等かどうかを判断できます。操作ポイント選択を実行する機能により、受信機はVVCビットストリームの時間的スケーラブルな性質を利用できます。
A scalable VVC media configuration is such a configuration where non-temporal scalability mechanisms are allowed. In [VVC] version 1, it is implied that general_profile_idc indicates one of the following profiles: Multilayer Main 10 and Multilayer Main 10 4:4:4, with general_profile_idc values of 17 and 49, respectively.
スケーラブルなVVCメディア構成は、非同時のスケーラビリティメカニズムが許可されるような構成です。[VVC]バージョン1では、General_Profile_Idcが次のプロファイルのいずれかを示していることが暗示されています。MultiLayerMain 10およびMultiLayer Main 10 4：4：4、それぞれ17および49のgeneral_profile_idc値。
The following limitations and rules pertaining to the media configuration apply. They are listed in an order that would be logical for an implementation to follow:
メディア構成に関連する以下の制限と規則が適用されます。それらは、実装が従うべき論理的な順序でリストされています。
* The parameters identifying a media format configuration for scalable VVC are profile-id, tier-flag, sub-profile-id, level-id, interop-constraints, and sprop-vps. These media configuration parameters, except level-id, MUST be used symmetrically, except as noted below.
* Scalable VVCのメディア形式構成を識別するパラメーターは、プロファイルID、Tier-Flag、Sub-Profile-ID、Level-ID、Interop-Constraints、およびSPROP-VPSです。これらのメディア構成パラメーターは、以下に示すように、レベルIDを除き、対称的に使用する必要があります。
* The answerer MAY include a level-id that MUST be lower than or equal to the level-id indicated in the offer (either expressed by level-id in the offer or implied by the default level, as specified in Section 7.1).
* 応答者には、オファーに示されているレベルID以下であるレベルIDを含めることができます（オファーでレベルIDで表現されるか、セクション7.1で指定されているようにデフォルトレベルで暗示されています）。
* When sprop-ols-id is present in an offer, sprop-vps MUST also be present in the same offer and include at least one valid VPS so to allow the answerer to meaningfully interpret sprop-ols-id and select recv-ols-id (see below).
* SPROP-OLS-IDがオファーに存在する場合、SPROP-VPSも同じオファーに存在し、少なくとも1つの有効なVPSを含める必要があります。（下記参照）。
* The answerer MUST NOT include recv-ols-id unless the offer includes sprop-ols-id. When present, recv-ols-id MUST indicate a supported output layer set in the VPS that includes no layers other than all or a subset of the layers of the OLS referred to by sprop-ols-id. If unable, the answerer MUST remove the media format.
* 応募者にSPROP-OLS-IDが含まれていない限り、応答者にはRecv-Ols-IDを含めてはなりません。存在する場合、RECV-OLS-IDは、SPROP-OLS-IDで言及されているOLSのすべてまたはSUBSET以外のレイヤー以外の層を含まないVPSに設定されたサポートされている出力層を示す必要があります。不可能な場合、回答者はメディア形式を削除する必要があります。
Informative note: If an offerer wants to offer more than one output layer set, it can do so by offering multiple VVC media with different payload types.
有益なメモ：提供者が複数の出力層セットを提供したい場合、異なるペイロードタイプを持つ複数のVVCメディアを提供することでそうすることができます。
* The offerer MAY include sprop-sublayer-id, which indicates the highest allowed value of TID in the bitstream. The answerer MAY include recv-sublayer-id, which can be used to reduce the number of sublayers from the value of sprop-sublayer-id.
* オファーには、BitStreamでのTIDの最高値を示すSprop-Sublayer-IDが含まれる場合があります。応答者には、Recv-Sublayer-IDが含まれている場合があります。これは、SPROP-Sublayer-IDの価値からサブレーヤーの数を減らすために使用できます。
* When the answerer includes recv-ols-id and configuration parameters profile-id, tier-flag, sub-profile-id, level-id, and interop-constraints, it MUST use the configuration parameter values as signaled in the sprop-vps for the operating point with the largest number of sublayers for the chosen output layer set, 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 sprop-vps in offer for the operating point with the largest number of sublayers for the chosen output layer set.
* 回答者にRecv-Ols-IDおよび構成パラメータープロファイルID、ティアフラグ、サブプロファイルID、レベルID、およびInterop-Constraintsが含まれている場合、SPROP-VPSで合図されているように構成パラメーター値を使用する必要があります。選択された出力層セットのサブレーヤーの最大数を持つ動作点は、回答で示される最高レベルがSPROP-VPSで示されるレベルよりも高くない限り、レベルIDの値が変更可能であることを除いて、選択された出力層セットの最大数のサブレーヤーで、操作ポイントを提供します。
The following limitations and rules pertain to the configuration of the payload format buffer management mostly and apply to both scalable and non-scalable VVC.
以下の制限とルールは、主にペイロード形式のバッファー管理の構成に関係しており、スケーラブルと非スケーラブルVVCの両方に適用されます。
* The parameters sprop-max-don-diff and sprop-depack-buf-bytes describe the properties of an RTP stream 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 VVC, the offerer assumes that the answerer will be able to receive media encoded using the configuration being offered.
* パラメーターSPROP-MAX-DON-DIFFおよびSPROP-DEPACK-BUF-BYTESは、オファーまたは応答者がメディア形式の構成のために送信しているRTPストリームのプロパティを説明しています。これは、オファー/回答パラメーターの通常の使用とは異なります。通常、そのようなパラメーターは、オファーまたは応答者が受信できるビットストリームまたはRTPストリームのプロパティを宣言します。VVCを扱うとき、提供者は、応答者が提供されている構成を使用してエンコードされたメディアを受信できると想定しています。
Informative note: The above parameters apply for any RTP stream, 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ストリームへの適用性は、ソースエンドポイントに依存します。ペイロードタイプにバインドされるのではなく、構成に適用されるため、送信中に値を別のペイロードタイプに適用する必要がある場合があります。
* The capability parameter max-lsr MAY be used to declare further capabilities of the offerer or answerer for receiving. It MUST NOT be present when the direction attribute is sendonly.
* 機能パラメーターMAX-LSRを使用して、受け取るために提供者または回答者のさらなる機能を宣言することができます。方向属性がsendonlyである場合、それは存在してはなりません。
* The capability parameter max-fps MAY be used to declare lower capabilities of the offerer or answerer for receiving. It MUST NOT be present when the direction attribute is sendonly.
* 機能パラメーターmax-fpsを使用して、受け取るために提供者または回答者のより低い機能を宣言することができます。方向属性がsendonlyである場合、それは存在してはなりません。
* When an offerer offers an interleaved stream, indicated by the presence of sprop-max-don-diff with a value larger than zero, the offerer MUST include the size of the de-packetization buffer sprop-depack-buf-bytes.
* オファーがゼロより大きな値を持つSprop-Max-Don-Diffの存在によって示されるインターリーブストリームを提供する場合、オファーは脱パケット化バッファーSPROP-DEPACK-BUFバイトのサイズを含める必要があります。
* 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.
* 提供者と応答者が、RTPストリームを受信する際のパケット化バッファリングの機能についてお互いに通知できるようにするために、両当事者はDePack-Buf-Capを含めることをお勧めします。
* The parameters sprop-dci, 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 (DCI, VPS, SPS, or PPS, respectively).
* パラメーターは、存在する場合（SDPの「a = fmtp」行に含まれるか、[fmtp ""ソース属性を使用して伝達される[a = fmtp "ラインに含まれる）sprop-dci、sprop-vps、sprop-sps、またはsprop-ppsに存在する場合、RFC5576]）は、パラメーターセット（DCI、VPS、SPS、またはPPS）の帯域外輸送に使用されます。
* 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 packets 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.
* 応答者は、帯域外のパラメーターセット輸送がオファーから回答者への方向で使用されているかどうかにかかわらず、送信しているビットストリームのパラメーターセットの帯域外または帯域内の輸送を使用する場合があります。回答に含まれるパラメーターセットは、2つの異なるビットストリームのデコードに使用されるため、オファーに含まれるパラメーターセットに依存しません。1つは応答者から提供者へ、もう1つは反対の方向にあります。SDPオファー/回答が落ち着く前にいくつかのRTPパケットが送信された場合、SDPオファー/回答の前に送信されるRTPストリームパーツには、バンド内パラメーターセットを使用する必要があります。
* The following rules apply to transport of parameter sets in the offerer-to-answerer direction.
* 以下のルールは、提供者から回答の方向にあるパラメーターセットの輸送に適用されます。
- An offer MAY include sprop-dci, sprop-vps, sprop-sps, and/or sprop-pps. If none of these parameters are present in the offer, then only in-band transport of parameter sets is used.
- オファーには、SPROP-DCI、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に含まれるパラメーターセットを使用するように準備する必要があります（どちらも含まれています。SDPの「A = FMTP」ラインまたは「FMTP」ソース属性を使用して伝達されるか、たとえば、RTPストリームで運ばれたNALユニットを渡す前に、これらのパラメーターセットNALユニットをビデオデコーダーに渡すことにより、着信ビットストリームをデコードするために伝達されます。それ以外の場合、応答者は、SPROP-VPS、SPROP-SPS、およびSPROP-PPSを無視する必要があります（SDPの「A = FMTP」ラインに含まれるか、「FMTP」ソース属性を使用して伝達します）、および提供者はパラメーターセットを送信する必要があります。バンド。
* The following rules apply to transport of parameter sets in the answerer-to-offerer direction.
* 以下のルールは、回答者の方向にパラメーターセットの輸送に適用されます。
- An answer MAY include sprop-dci, sprop-vps, sprop-sps, and/or sprop-pps. If none of these parameters are present in the answer, then only in-band transport of parameter sets is used.
- 回答には、SPROP-DCI、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」ソース属性を使用して伝達される）を使用する必要があります。たとえば、これらのパラメーターセットNALユニットをビデオデコーダーに渡すことにより、RTPストリームに携帯されているNALユニットを渡すことにより、入ってくるビットストリームが発生します。
* When sprop-dci, 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-dci, 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].
* [RFC5576]のセクション6.3で指定されているように、「FMTP」ソース属性を使用して、SPROP-DCI、SPROP-VPS、SPROP-SPS、および/またはSPROP-PPSが伝達される場合、パラメーターの受信機は含まれるパラメーターセットを保存する必要があります。SPROP-DCIでは、SPROP-VPS、SPROP-SPS、および/またはSPROP-PPSで、「FMTP」ソース属性の一部として与えられたソースに関連付けられます。1つのソースに関連付けられたパラメーターセット（「FMTP」ソース属性の一部として与えられます）は、同じソース（「FMTP」ソース属性の一部として与えられたRTPパケットで伝達されるNALユニットをデコードするためにのみ使用する必要があります。このメカニズムが使用されている場合、[RFC5576]で指定されているように、SSRC衝突検出と解像度を実行する必要があります。
Figure 11 lists the interpretation of all the parameters that MAY be used for the various combinations of offer, answer, and direction attributes.
図11に、オファー、回答、方向の属性のさまざまな組み合わせに使用できるすべてのパラメーターの解釈を示します。
sendonly --+
answer: recvonly, recv-ols-id --+ |
recvonly w/o recv-ols-id --+ | |
answer: sendrecv, recv-ols-id --+ | | |
sendrecv w/o recv-ols-id --+ | | | |
| | | | |
profile-id C D C D P
tier-flag C D C D P
level-id D D D D P
sub-profile-id C D C D P
interop-constraints C D C D P
max-recv-level-id R R R R -
sprop-max-don-diff P P - - P
sprop-depack-buf-bytes P P - - P
depack-buf-cap R R R R -
max-lsr R R R R -
max-fps R R R R -
sprop-dci P P - - P
sprop-sei P P - - P
sprop-vps P P - - P
sprop-sps P P - - P
sprop-pps P P - - P
sprop-sublayer-id P P - - P
recv-sublayer-id O O O O -
sprop-ols-id P P - - P
recv-ols-id X O X O -
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：BitStreamsの送信と受信の構成D：Cと同じチェンジ可能な構成、異なるが一貫した値で答えることができます（これらのパラメーターが一貫しているプロファイル、ティア、およびレベルに関連する6つのパラメーターのセマンティクスを参照）p：送信されるビットストリームのプロパティR：受信機機能o：操作ポイント選択X：存在しないでください - ：存在する場合、無視する必要がある場合は使用できません
Figure 11: Interpretation of Parameters for Various Combinations of Offers, Answers, and Direction Attributes, with and without recv-ols-id.
図11：RECV-OLS-IDの有無にかかわらず、オファー、回答、方向の属性のさまざまな組み合わせのパラメーターの解釈。
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.
受信機の機能を宣言するために使用されるパラメーターは、一般に、ダウングレード可能です。つまり、送信者の可能な動作の上限を表します。したがって、送信者は、これらのパラメーターの低い/低い値または等しい値のみを使用してエンコーダーを設定することを選択できます。
When the answer does not include a recv-ols-id that is less than the sprop-ols-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-OLS-IDよりも少ないRECV-OLS-IDが含まれていない場合、ユニキャスト使用量のレベル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-ols-id in the answer.
送信者の機能が構成パラメーターで宣言されると、これらのパラメーターは、送信者がビットストリームを受信するために許容できる構成を表現します。高い相互運用性レベルを達成するために、複数の代替構成を提供することをお勧めします。単一のペイロードタイプで複数の構成を提供することは不可能です。したがって、複数の構成オファーが作成されると、各オファーにはオファーに関連付けられた独自のRTPペイロードタイプが必要です。ただし、オファーにSPROP-VPSを含めることにより、回答にRECV-OLS-IDを含めることにより、単一のペイロードタイプで1つの構成を使用して複数の操作ポイントを提供することができます。
An implementation SHOULD be able to understand all media type parameters (including all optional media type parameters), even if it doesn't support the functionality related to the parameter. This, in conjunction with proper application logic in the implementation, allows the implementation, after having received an offer, to create an answer by potentially downgrading one or more of the optional parameters to the point where the implementation can cope, leading to higher chances of interoperability beyond the most basic interop points (for which, as described above, no optional parameters are necessary).
実装は、パラメーターに関連する機能をサポートしていなくても、すべてのメディアタイプパラメーター（すべてのオプションのメディアタイプパラメーターを含む）を理解できる必要があります。これは、実装における適切なアプリケーションロジックと組み合わせて、オファーを受け取った後、実装が1つ以上のオプションのパラメーターを対処できるポイントまで潜在的に格下げすることで回答を作成し、より高いチャンスにつながる可能性があります。最も基本的な相互作用ポイントを超えた相互運用性（上記のように、オプションのパラメーターは必要ありません）。
Informative note: In implementations of previous H.26x payload formats, it was occasionally observed that implementations were incapable of parsing most (or all) of the optional parameters. As a result, the offer/answer exchange resulted in a baseline performance (using the default values for the optional parameters) with the resulting suboptimal user experience. However, there are valid reasons to forego the implementation complexity of implementing the parsing of some or all of the optional parameters, for example, when there is predetermined knowledge, not negotiated by an SDP-based offer/answer process, of the capabilities of the involved systems (walled gardens, baseline requirements defined in application standards higher up in the stack, and similar).
有益な注意：以前のH.26Xペイロード形式の実装では、実装がオプションのパラメーターのほとんど（またはすべて）を解析できないことが時々観察されました。その結果、オファー/回答の交換により、結果として得られるユーザーエクスペリエンスでベースラインパフォーマンス（オプションのパラメーターのデフォルト値を使用）が得られました。ただし、たとえば、SDPベースのオファー/回答プロセスによって交渉されず、事前に決められた知識がある場合、オプションのパラメーターの一部またはすべての解析を実装するという実装の複雑さを忘れる正当な理由があります。関係システム（壁に囲まれた庭園、アプリケーション標準で定義されたベースライン要件がスタック内で高く、同様）。
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.
応答者は、追加のメディア形式構成でオファーを拡張する場合があります。ただし、ほとんどの場合、使用を可能にするには、メディア送信者が使用するビットストリームプロパティパラメーターを提供するために、オファーから2回目のオファーが必要です。これには、提供者が送信するだけでなく、このメディア形式の構成を受信できるようにする必要があるという効果もあります。
For bitstreams being delivered over multicast, the following rules apply:
マルチキャストを介して配信されるビットストリームには、次のルールが適用されます。
* The media format configuration is identified by profile-id, tier-flag, sub-profile-id, level-id, and interop-constraints. 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.
* メディア形式の構成は、Profile-ID、Tier-Flag、Sub-Profile-ID、Level-ID、およびInterop-Constraintsによって識別されます。レベルIDを含むこれらのメディア形式の構成パラメーターは、対称的に使用する必要があります。つまり、回答者はすべての構成パラメーターを維持するか、メディア形式（ペイロードタイプ）を完全に削除する必要があります。これは、マルチキャストの提供/回答のレベルIDが変更できないことを意味することに注意してください。
* 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.
* これらの構成の取り扱いと一致を簡素化するには、[RFC3264]で指定されているように、オファーで使用される同じRTPペイロードタイプ番号も回答で使用する必要があります。回答には、構成がオファーと同じでない限り、オファーで使用されるペイロードタイプ番号を含めてはなりません。
* Parameter sets received MUST be associated with the originating source and MUST only be used in decoding the incoming bitstream from the same source.
* 受信したパラメーターセットは、発信元のソースに関連付けられている必要があり、同じソースからの入っているビットストリームのデコードにのみ使用する必要があります。
* The rules for other parameters are the same as above for unicast as long as the three above rules are obeyed.
* 他のパラメーターのルールは、上記の3つのルールが従っている限り、Unicastの上記と同じです。
When VVC over RTP is offered with SDP in a declarative style, as in Real Time Streaming Protocol (RTSP) [RFC7826] or Session Announcement Protocol (SAP) [RFC2974], the following considerations are necessary.
リアルタイムストリーミングプロトコル（RTSP）[RFC7826]またはセッションアナウンスプロトコル（SAP）[RFC2974]のように、RTPを超えるVVCがSDPを宣言スタイルで提供する場合、以下の考慮事項が必要です。
* All parameters capable of indicating both bitstream properties and receiver capabilities are used to indicate only bitstream properties. For example, in this case, the parameters profile-id, tier-id, and level-id declare the values used by the bitstream, not the capabilities for receiving bitstreams. As a result, the following interpretation of the parameters MUST be used:
* ビットストリームプロパティと受信機の両方の機能を示すことができるすべてのパラメーターは、ビットストリームプロパティのみを示すために使用されます。たとえば、この場合、パラメータープロファイルID、Tier-ID、およびレベルIDは、ビットストリームを受信する機能ではなく、ビットストリームで使用される値を宣言します。その結果、パラメーターの次の解釈を使用する必要があります。
- Declaring actual configuration or bitstream properties:
- 実際の構成またはビットストリームプロパティの宣言：
o profile-id
o Profile-id
o tier-flag
o ティアフラグ
o level-id
o レベルID
o interop-constraints
o Interop-Constraints
o sub-profile-id
o サブプロファイルID
o sprop-dci
o sprop-dci
o sprop-vps
o SPROP-VPS
o sprop-sps
o SPROP-SPS
o sprop-pps
o Sprop-pps
o sprop-max-don-diff
o sprop-max-don-diff
o sprop-depack-buf-bytes
o sprop-depack-buf-bytes
o sprop-sublayer-id
o sprop-sublayer-id
o sprop-ols-id
o sprop-ols-id
o sprop-sei
o sprop-sei
- Not usable (when present, they MUST be ignored):
- 使用できません（存在する場合、それらは無視する必要があります）：
o max-lsr
o max-lsr
o max-fps
o 最大fps
o max-recv-level-id
o max-recv-level-id
o depack-buf-cap
o depack-buf-cap
o recv-sublayer-id
o recv-sublayer-id
o recv-ols-id
o recv-ols-id
- 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.
- SDPの受信者は、提供されるパラメーターのすべてのパラメーターと値をサポートするために必要です。それ以外の場合、受信者はセッションに参加するか（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. An 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つのパラメーターの値は異なります。
The following subsections define the use of the Picture Loss Indication (PLI) and Full Intra Request (FIR) feedback messages with [VVC]. The PLI is defined in [RFC4585], and the FIR message is defined in [RFC5104]. In accordance with this memo, unlike [HEVC], a sender MUST NOT send Slice Loss Indication (SLI) or Reference Picture Selection Indication (RPSI), and a receiver SHOULD ignore RPSI and treat a received SLI as a PLI.
次のサブセクションでは、[VVC]を使用した画像損失表示（PLI）および完全なリクエスト（FIR）フィードバックメッセージの使用を定義しています。PLIは[RFC4585]で定義されており、FIRメッセージは[RFC5104]で定義されています。このメモに従って、[HEVC]とは異なり、送信者はスライス損失表示（SLI）または参照画像選択表示（RPSI）を送信してはなりません。受信機はRPSIを無視し、受け取ったSLIをPLIとして扱う必要があります。
As specified in Section 6.3.1 of [RFC4585], 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-IRAP decoder refresh points, picture structures, and so forth), a reaction to the reception of a PLI by a VVC sender SHOULD be to send an IRAP 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, such information can be parameter sets that have been conveyed out of band through mechanisms not defined in this document and that are known to 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 [RFC4585] MUST be observed.
[RFC4585]のセクション6.3.1で指定されているように、メディア送信者によるPLIの受信は、「1つ以上の写真に属する未定義のコード化されたビデオデータの損失」を示しています。ビットストリームのセットアップに関する特定の知識がない（バンド内パラメーターセットの使用や場所、非IRRAPデコーダーリフレッシュポイント、画像構造など）、VVCによるPLIの受信に対する反応がない送信者は、IRAP画像と関連するパラメーターセットを送信する必要があります。潜在的に十分な冗長性があるため、正しい受信を確保する必要があります。ただし、ビットストリーム構造に関する情報が知られている場合があります。たとえば、このような情報は、このドキュメントで定義されていないメカニズムを介してバンドから伝えられ、セッションの期間中は静的にとどまることが知られているパラメーターセットである可能性があります。その場合、PLIの受容の結果、それらを帯域内に送る必要はありません。他の例は、ビットストリーム構造のさまざまな側面に関する先験的な知識に基づいて考案できます。すべての場合において、[RFC4585]のタイミングおよび輻輳制御メカニズムを観察する必要があります。
The purpose of the FIR message is to force an encoder to send an independent decoder refresh point as soon as possible while observing applicable congestion-control-related constraints, such as those set out in [RFC8082].
FIRメッセージの目的は、[RFC8082]に記載されているような、該当する混雑コントロール関連の制約を観察しながら、エンコーダーにできるだけ早く独立したデコーダーリフレッシュポイントを送信するように強制することです。
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 the sender and receiver, established by means outside this document, that parameter sets are exclusively sent out of band.
FIRを受信すると、送信者はIDR画像を送信する必要があります。パラメーターセットが正しく確立されているという先験的な知識がある場合を除き、パラメーターセットも送信する必要があります。その典型的な例は、このドキュメントの外側の手段によって確立された送信者とレシーバーの間の理解です。パラメーターセットはバンドのみから送信されます。
The scope of this section is limited to the payload format itself and to one feature of [VVC] 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.
このセクションの範囲は、ペイロード形式自体と[VVC]の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 seem 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]. 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/SAVP/SAVP/AVPF [RFC3551]などの該当するRTPプロファイルで説明されているセキュリティ考慮事項の対象となります。[RFC3711]、またはRTP/ SAVPF [RFC5124]。ただし、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けていない理由」[RFC7202]が議論するため、機密性などの基本的なセキュリティ目標を満たすために使用されるソリューションを議論または義務付けることは、RTPペイロード形式の責任ではありません。、整合性、および一般的なRTPのソースの信頼性。この責任は、アプリケーションでRTPを使用しているすべての人にあります。彼らは、「RTPセッションを保護するためのオプション」[RFC7201]の利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスを見つけることができます。このセクションの残りの部分では、ペイロード形式自体のセキュリティに影響を与えるプロパティについて説明します。
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. [VVC] 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 but NOT REQUIRED based on the thoughts of [RFC7202].
このペイロード形式で使用されるデータ圧縮はエンドに適用されるため、暗号化は圧縮後に実行する必要があります。不均一なレシーバー末端計算負荷を備えた圧縮技術を使用したデータエンコーディングには、潜在的なサービス拒否脅威が存在します。攻撃者は、デコードするのが複雑で、受信機が過負荷になっているビットストリームに病理学的データグラムを注入できます。[VVC]は、多くの将来のNALユニットのデコードプロセスに影響を与えるNALユニットを含むデータグラムを生成するのは非常に簡単であるため、このような攻撃に対して特に脆弱です。したがって、[RFC7202]の考えに基づいて、データ起源の認証と少なくともRTPパケットのデータ整合性保護の使用が推奨されますが、必要ありません。
Like HEVC [RFC7798], [VVC] 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. [VVC] 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.
HEVC [RFC7798]と同様に、[VVC]には、ユーザーデータ補足拡張情報（SEI）メッセージが含まれています。このSEIメッセージにより、ビデオビットストリームに任意のビットストリングを含めることができます。このようなビットストリングには、JavaScript、マシンコード、その他のアクティブコンテンツが含まれます。[VVC]は、このSEIメッセージの処理を受信システムに残します。ユーザーデータSEIメッセージの有害な副作用を回避するために、デコーダーの実装はそのコンテンツを単純に信頼することはできません。たとえば、デコーダーの実装をWebブラウザーに検出するJavaScriptを転送するのは、悪い実装の実践であるでしょう。ユーザーデータ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. This on-path inclusion of the MANE forgoes end-to-end security guarantees for the end points.
認証、整合性、または機密保護を備えたエンドツーエンドのセキュリティは、完全なパケットを破棄する以外に、たてがみがメディアを認識している操作を実行することを妨げます。機密保護の場合、メディアを認識した方法でパケットを破棄することさえ防止されます。そのような運用を実行するためには、たてがみがセキュリティコンテキストの確立に含まれる信頼できるエンティティである必要があります。たてがみのこのオンパスを含めることは、エンドポイントのエンドツーエンドのセキュリティ保証を放棄します。
Congestion control for RTP SHALL be used in accordance with RTP [RFC3550] and with any applicable RTP profile, e.g., AVP [RFC3551] or AVPF [RFC4585]. 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 are achieved. This condition can be satisfied by implementing congestion-control mechanisms to adapt the transmission rate, by implementing 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]またはAVPF [RFC4585]に従って使用するものとします。Best-Effortサービスが使用されている場合、追加の要件は、このペイロード形式のユーザーがパケットの損失を監視して、パケットの損失率が許容範囲内にあることを確認する必要があることです。同じネットワークパスを横切るTCPフローが同じネットワーク条件を経験すると、合理的なタイムスケールで測定された平均スループットが得られる場合、パケットの損失は許容できると見なされます。この条件は、渋滞制御メカニズムを実装して伝送速度を適応させること、レイヤードマルチキャストセッションにサブスクライブするレイヤー数を実装するか、損失率が容認できないほど高い場合にセッションを離れるように配置することにより、満たすことができます。
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 mechanisms available in [VVC] are temporal scalability and spatial/SNR scalability. A media sender can remove NAL units belonging to higher temporal sublayers (i.e., those NAL units with a high value of TID) or higher spatio-SNR layers until the sending bitrate drops to an acceptable range.
たとえば、量子化パラメーターを適切に調整することにより、リアルタイムエンコードが使用される場合、混雑制御原則に従うために必要なビットレートの適応は簡単に達成できます。ただし、事前にエンコードされたコンテンツが送信されている場合、帯域幅の適応では、事前にコードされたビットストリームをそのような適応性に合わせて調整する必要があります。[VVC]で利用可能な重要なメカニズムは、時間的スケーラビリティと空間/SNRスケーラビリティです。メディア送信者は、送信ビットレートが許容範囲に低下するまで、より高い時間的サブレイヤー（つまり、TIDの値が高い）またはより高いSpatio-SNR層に属するNALユニットを削除できます。
The mechanisms mentioned above generally work within a defined profile and level; 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. MANE can also remove higher temporal scalable layers if the outbound transmission (from the MANE's viewpoint) experiences congestion.
Manesは、以前のパケット損失のためにそのRTPストリームが損傷したときに、RTPストリームから特定の使用不可能なパケットを削除する場合があります。これは、特定の特別なケースでネットワークの負荷を減らすのに役立ちます。たとえば、たてがみが同じスライスに属する先行スライスセグメントが失われた場合、同じNALユニットに属する先行FUSが失われた場合、または依存するスライスセグメントが失われた場合、たてがみはFUSを除去できます。ほとんどのデコーダーに。たてがみは、（たてがみの観点から）アウトバウンド伝送が渋滞を経験した場合、より高い時間スケーラブル層を除去することもできます。
A new media type has been registered with IANA; see Section 7.1.
新しいメディアタイプがIANAに登録されています。セクション7.1を参照してください。
[ISO23090-3] International Organization for Standardization, "Information technology - Coded representation of immersive media - Part 3: Versatile video coding", ISO/ IEC 23090-3:2022, September 2022, <https://www.iso.org/standard/73022.html>.
[ISO23090-3]国際標準化機関、「情報技術 - 没入型メディアのコード化された表現 - パート3：汎用ビデオコーディング」、ISO/IEC 23090-3：2022年9月、<https://www.iso.org/standard/73022.html>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、DOI 10.17487/RFC3264、2002年6月、<https：//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, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487/RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487/RFC3551、2003年7月、<https：//www.rfc-editor。org/info/rfc3551>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、DOI 10.17487/RFC3711、3月2004、<https://www.rfc-editor.org/info/rfc3711>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル"、RFC 4585、doi 10.17487/rfc4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://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, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5104] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバックを備えたRTPオーディオビジュアルプロファイルのコーデック制御メッセージ」、RFC 5104、DOI 10.17487/RFC5104、2月2月2008、<https://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, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5124] OTT、J。およびE. Carrara、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック（RTP/SAVPF）のセキュアーRTPプロファイルを拡張する」、RFC 5124、DOI 10.17487/RFC5124、2008年2月、<HTTPS <<HTTPS：//www.rfc-editor.org/info/rfc5124>。
[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, <https://www.rfc-editor.org/info/rfc5576>.
[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「セッション説明プロトコル（SDP）のソース固有のメディア属性」、RFC 5576、DOI 10.17487/RFC5576、2009年6月、<https：///www.rfc-editor.org/info/rfc5576>。
[RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund, "Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs", RFC 8082, DOI 10.17487/RFC8082, March 2017, <https://www.rfc-editor.org/info/rfc8082>.
[RFC8082] Wenger、S.、Lennox、J.、Burman、B。、およびM. Westerlund、「RTPオーディオ視覚プロファイルのコーデック制御メッセージを層状コーデックを使用したフィードバックを使用して」、RFC 8082、DOI 10.17487/RFC8082、2017年3月、<https://www.rfc-editor.org/info/rfc8082>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/info/rfc8866>.
[RFC8866] Begen、A.、Kyzivat、P.、Perkins、C.、およびM. Handley、「SDP：SESSION説明プロトコル」、RFC 8866、DOI 10.17487/RFC866、2021年1月、<https：//www.rfc8866-editor.org/info/rfc8866>。
[VSEI] ITU-T, "Versatile supplemental enhancement information messages for coded video bitstreams", ITU-T Recommendation H.274, May 2022, <https://www.itu.int/rec/T-REC-H.274>.
[VSEI] ITU-T、「コード化されたビデオビットストリームの汎用補足強化情報メッセージ」、ITU-T推奨H.274、2022年5月、<https://www.itu.int/rec/t-rec-h.274>。
[VVC] ITU-T, "Versatile Video Coding", ITU-T Recommendation H.266, April 2022, <http://www.itu.int/rec/T-REC-H.266>.
[VVC] ITU-T、「Versatileビデオコーディング」、ITU-T推奨H.266、2022年4月、<http://www.itu.int/rec/t-rec-h.266>。
[CABAC] Sole, J., et al., "Transform coefficient coding in HEVC", IEEE Transactions on Circuits and Systems for Video Technology, DOI 10.1109/TCSVT.2012.2223055, December 2012, <https://doi.org/10.1109/TCSVT.2012.2223055>.
[CABAC] Sole、J.、et al。、「HEVCの変換係数コーディング」、ビデオ技術の回路およびシステムに関するIEEEトランザクション、DOI 10.1109/TCSVT.2012.22223055、2012年12月<https://doi.org/10.1109/TCSVT.2012.2223055>。
[HEVC] ITU-T, "High efficiency video coding", ITU-T Recommendation H.265, August 2021, <https://www.itu.int/rec/T-REC-H.265>.
[HEVC] ITU-T、「高効率ビデオコーディング」、ITU-T推奨H.265、2021年8月、<https://www.itu.int/rec/t-rec-h.265>。
[MPEG2S] International Organization for Standardization, "Information technology - Generic coding of moving pictures and associated audio information - Part 1: Systems", ISO/IEC 13818-1:2022, September 2022.
[MPEG2S]国際標準化機関、「情報技術 - 移動写真と関連するオーディオ情報の一般的なコーディング - パート1：システム」、ISO/IEC 13818-1：2022、2022年9月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <https://www.rfc-editor.org/info/rfc2974>.
[RFC2974] Handley、M.、Perkins、C.、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、DOI 10.17487/RFC2974、2000年10月、<https://www.rfc-editor.org/info/RFC2974>。
[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, <https://www.rfc-editor.org/info/rfc6184>.
[RFC6184] Wang、Y.-K.、veven、R.、Kristensen、T.、およびR. Jesup、「H.264ビデオ用のRTPペイロード形式」、RFC 6184、DOI 10.17487/RFC6184、2011年5月、<https <https：//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, <https://www.rfc-editor.org/info/rfc6190>.
[RFC6190] Wenger、S.、Wang、Y.-K.、Schierl、T.、およびA. Eleftheriadis、「スケーラブルなビデオコーディング用のRTPペイロード形式」、RFC 6190、DOI 10.17487/RFC6190、2011年5月、<HTTPS：//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, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。and C. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487/RFC7201、2014年4月、<https://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <https://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けていない理由」、RFC 7202、DOI 10.17487/RFC7202、2014年4月、<https：//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, <https://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、ed。、「リアルタイム輸送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」、RFC 7656、DOI 10.17487/RFC7656、2015年11月、<https://www.rfc-editor.org/info/rfc7656>。
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.
[RFC7667] Westerlund、M。and S. Wenger、「RTP Topologies」、RFC 7667、DOI 10.17487/RFC7667、2015年11月、<https://www.rfc-editor.org/info/rfc767>
[RFC7798] Wang, Y.-K., Sanchez, Y., Schierl, T., Wenger, S., and M. M. Hannuksela, "RTP Payload Format for High Efficiency Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 2016, <https://www.rfc-editor.org/info/rfc7798>.
[RFC7798] Wang、Y.-K.、Sanchez、Y.、Schierl、T.、Wenger、S。、およびM. M. Hannuksela、「高効率ビデオコーディング（HEVC）のRTPペイロード形式」、RFC 7798、DOI 10.17487/RFC7798、2016年3月、<https://www.rfc-editor.org/info/rfc7798>。
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC7826] Schulzrinne、H.、Rao、A.、Lanphier、R.、Westerlund、M。、およびM. Stiemerling、ed。、「リアルタイムストリーミングプロトコルバージョン2.0」、RFC 7826、DOI 10.17487/RFC7826、12月2016、<https://www.rfc-editor.org/info/rfc7826>。
Acknowledgements
謝辞
Dr. Byeongdoo Choi is thanked for the video-codec-related technical discussion and other aspects in this memo. Xin Zhao and Dr. Xiang Li are thanked for their contributions on [VVC] specification descriptive content. Spencer Dawkins is thanked for his valuable review comments that led to great improvements of this memo. Some parts of this specification share text with the RTP payload format for HEVC [RFC7798]. We thank the authors of that specification for their excellent work.
Byeongdoo Choi博士は、このメモのビデオコデック関連の技術的議論とその他の側面に感謝しています。Xin ZhaoとXiang Li博士は、[VVC]仕様記述コンテンツに関する貢献に感謝しています。スペンサー・ドーキンスは、このメモの大幅な改善につながった貴重なレビューコメントに感謝しています。この仕様の一部は、HEVC [RFC7798]のRTPペイロード形式とテキストを共有しています。その仕様の著者に、彼らの優れた作品に感謝します。
Authors' Addresses
著者のアドレス
Shuai Zhao Intel 2200 Mission College Blvd Santa Clara, 95054 United States of America Email: shuai.zhao@ieee.org
Shuai Zhao Intel 2200 Mission College Blvd Santa Clara、95054アメリカ合衆国電子メール：shuai.zhao@ieee.org
Stephan Wenger Tencent 2747 Park Blvd Palo Alto, 94588 United States of America Email: stewe@stewe.org
Stephan Wenger Tencent 2747 Park Blvd Palo Alto、94588アメリカ合衆国電子メール：stewe@stewe.org
Yago Sanchez Fraunhofer HHI Einsteinufer 37 10587 Berlin Germany Email: yago.sanchez@hhi.fraunhofer.de
YAGO SANCHEZ FRAUNHOFER HHI EINSTEINUFER 37 10587 BERLIN GRAY EMAIM：yago.sanchez@hhi.fraunhofer.de
Ye-Kui Wang Bytedance Inc. 8910 University Center Lane San Diego, 92122 United States of America Email: yekui.wang@bytedance.com
Ye-Kui Wang Bytedance Inc. 8910 University Center Lane San Diego、92122アメリカ合衆国電子メール：Yekui.wang@bytedance.com
Miska M. Hannuksela Nokia Technologies Hatanpn valtatie 30 FI-33100 Tampere Finland Email: miska.hannuksela@nokia.com
Miska M. Hannuksela Nokia Technologies Hatanpn Valtatie 30 FI-33100 Tampere Finlandメール：Miska.hannuksela@nokia.com