Internet Engineering Task Force (IETF) L. Ilola
Request for Comments: 10034 L. Kondrad
Category: Standards Track Nokia Technologies
ISSN: 2070-1721 August 2026
A visual volumetric video-based coding (V3C) ISO/IEC 23090-5 bitstream is composed of V3C units that contain V3C atlas sub-bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This document describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant IETF RFCs for the applicable video codec. The V3C RTP payload format allows for the packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as the fragmentation of a V3C atlas NAL unit into multiple RTP packets. The document also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C-encoded content.
ビジュアル ボリューム ビデオベース コーディング (V3C) ISO/IEC 23090-5 ビットストリームは、V3C アトラス サブビットストリーム、V3C ビデオ サブビットストリーム、および V3C パラメータ セットを含む V3C ユニットで構成されます。このドキュメントでは、V3C アトラス サブビットストリームの RTP ペイロード形式について説明します。V3C ビデオ サブビットストリームの RTP ペイロード形式は、該当するビデオ コーデックに関連する IETF RFC によって定義されます。V3C RTP ペイロード形式では、RTP パケット ペイロード内の 1 つ以上の V3C アトラス ネットワーク アブストラクション レイヤ (NAL) ユニットのパケット化と、V3C アトラス NAL ユニットの複数の RTP パケットへの断片化が可能になります。このドキュメントでは、V3C コンポーネントのサブビットストリームの RTP ストリームをグループ化するメカニズムについても説明し、V3C でエンコードされたコンテンツをストリーミングするための完全なソリューションを提供します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc10034.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10034 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions
3. Definitions and Abbreviations
3.1. Abbreviations
3.2. Definitions
3.2.1. General
3.2.2. Definitions from the V3C Specification
4. Media Format Description
4.1. Overview of the V3C Codec (Informative)
4.2. V3C Parameter Set (Informative)
4.3. V3C Atlas and Video Components (Informative)
4.3.1. General
4.3.2. Atlas NAL Units
4.4. Systems and Transport Interfaces (Informative)
5. V3C Atlas RTP Payload Format
5.1. General
5.2. RTP Header
5.3. RTP Payload Header
5.4. Payload Structures
5.4.1. General
5.4.2. Single NAL Unit Packet
5.4.3. Aggregation Packet
5.4.4. Fragmentation Unit
5.4.5. Example of Fragmentation Unit (Informative)
5.5. Decoding Order Number
6. Packetization and De-Packetization Rules
7. Payload Format Parameters
7.1. Media Type Registration
7.2. Required Parameters Definition
7.3. Definitions of Optional Parameters
7.4. Mapping of Parameters to V3C Syntax
8. Congestion Control Considerations
9. Session Description Protocol
9.1. V3C Format Parameters "v3cfmtp" Attribute
9.2. Mapping of Payload Type Parameters to SDP
9.2.1. For V3C Atlas Components
9.2.2. For V3C Video Components
9.3. Grouping Framework
9.4. Offer and Answer Considerations
9.4.1. Unicast
9.4.2. Multicast
9.5. Declarative SDP Considerations
10. IANA Considerations
10.1. V3C Media Type Registration
10.2. V3C Format Parameters SDP Attribute
10.3. V3C Grouping Type Extension
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Authors' Addresses
Volumetric video, similar to conventional 2D video, when uncompressed, is represented by a large amount of data. It enables the three-dimensional (3D) capture and playback of an object or scene, independent from the original capture position(s) or orientation(s). The visual volumetric video-based coding (V3C) specification [ISO.IEC.23090-5] leverages the compression efficiency of existing 2D video codecs to reduce the amount of data needed for storage and transmission of volumetric video. V3C is a generic mechanism for volumetric video coding, and it can be used by applications targeting volumetric content such as point clouds, Video-based Point Cloud Compression (V-PCC) [ISO.IEC.23090-5], and immersive video with depth (MPEG Immersive Video (MIV)) [ISO.IEC.23090-12].
ボリューム ビデオは、従来の 2D ビデオと同様、非圧縮の場合は大量のデータで表されます。これにより、元のキャプチャ位置や向きに関係なく、オブジェクトやシーンの 3 次元 (3D) キャプチャと再生が可能になります。ビジュアル ボリューム ビデオベース コーディング (V3C) 仕様 [ISO.IEC.23090-5] は、既存の 2D ビデオ コーデックの圧縮効率を利用して、ボリューム ビデオの保存と送信に必要なデータ量を削減します。V3C はボリューム ビデオ コーディングの汎用メカニズムであり、点群、ビデオベースの点群圧縮 (V-PCC) [ISO.IEC.23090-5]、奥行きのあるイマーシブ ビデオ (MPEG イマーシブ ビデオ (MIV)) [ISO.IEC.23090-12] などのボリューム コンテンツをターゲットとするアプリケーションで使用できます。
A V3C encoder converts volumetric frames, i.e., 3D volumetric information, into a collection of 2D frames and associated data known as atlas data. The converted 2D frames are subsequently coded using any video or image codec, e.g., ISO/IEC International Standard 14496-10 (Advanced Video Coding, AVC/H.264) [ISO.IEC.14496-10], ISO/ IEC International Standard 23008-2 (High Efficiency Video Coding, HEVC/H.265) [ISO.IEC.23008-2], or ISO/IEC International Standard 23090-3 (Versatile Video Coding, VVC/H.266) [ISO.IEC.23090-3]. The atlas data is coded with mechanisms specified in [ISO.IEC.23090-5].
V3C エンコーダは、体積フレーム、つまり 3D 体積情報を、2D フレームとアトラス データとして知られる関連データのコレクションに変換します。変換された 2D フレームは、その後、ISO/IEC 国際規格 14496-10 (高度ビデオコーディング、AVC/H.264) [ISO.IEC.14496-10]、ISO/IEC 国際規格 23008-2 (高効率ビデオコーディング、HEVC/H.265) [ISO.IEC.23008-2] などのビデオまたは画像コーデックを使用してコーディングされます。または ISO/IEC 国際標準 23090-3 (多用途ビデオコーディング、VVC/H.266) [ISO.IEC.23090-3]。アトラス データは、[ISO.IEC.23090-5] で指定されたメカニズムでコード化されています。
V3C utilizes a high-level syntax (HLS) design, familiar from conventional 2D video codecs, to represent the associated coded data, i.e., atlas data. The coded atlas data is represented by Network Abstraction Layer (NAL) units. Consequently, the RTP payload format for V3C atlas data described in this document shares design philosophy, security, congestion control, and overall implementation complexity with the other NAL unit-based RTP payload formats such as the ones defined in [RFC6184], [RFC6190], and [RFC7798].
V3C は、従来の 2D ビデオ コーデックでよく知られている高レベル構文 (HLS) 設計を利用して、関連するコード化データ、つまりアトラス データを表現します。コード化されたアトラス データは、ネットワーク アブストラクション レイヤー (NAL) ユニットによって表されます。したがって、この文書で説明されている V3C アトラス データの RTP ペイロード フォーマットは、[RFC6184]、[RFC6190]、および [RFC7798] で定義されているものなど、他の NAL ユニットベースの RTP ペイロード フォーマットと設計哲学、セキュリティ、輻輳制御、および全体的な実装の複雑さを共有しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
All fields defined in this specification related to RTP payload structures SHALL be considered in network order.
RTP ペイロード構造に関連するこの仕様で定義されているすべてのフィールドは、ネットワーク順序で考慮されるものとします (SHALL)。
ACL:
ACL:
atlas coding layer
アトラスコーディング層
AP:
AP:
aggregation packet
集約パケット
AU:
オーストラリア:
aggregation unit
集計単位
CVS:
CVS:
coded V3C sequence
コード化された V3C シーケンス
DON:
ドン：
decoding order number
注文番号をデコードする
DOND:
やめてください:
decoding order number difference
次数の違いをデコードする
DONL:
ドンル:
decoding order number least significant bits
デコード順序番号の最下位ビット
IRAP:
IRAP:
intra random access point
ランダムアクセスポイント内
MTU:
MTU:
maximum transmission unit
最大伝送単位
NAL:
ナル:
network abstraction layer
ネットワーク抽象化層
NALU:
ナル：
NAL unit
NALユニット
RBSP:
RBSP:
raw byte sequence payload
生のバイト シーケンス ペイロード
V3C:
V3C:
visual volumetric video-based coding
ビジュアルボリュームビデオベースのコーディング
VPS:
VPS:
V3C parameter set
V3Cパラメータセット
This document uses the definitions of [ISO.IEC.23090-5]. Section 3.2.2 lists relevant definitions from [ISO.IEC.23090-5] for convenience.
この文書は [ISO.IEC.23090-5] の定義を使用します。セクション 3.2.2 では、便宜上、[ISO.IEC.23090-5] からの関連定義をリストします。
atlas:
アトラス:
Collection of 2D bounding boxes and their associated information placed onto a rectangular frame and corresponding to a volume in 3D space on which volumetric data is rendered.
長方形のフレーム上に配置され、体積データがレンダリングされる 3D 空間のボリュームに対応する 2D 境界ボックスとその関連情報のコレクション。
atlas bitstream:
アトラスビットストリーム:
Sequence of bits that forms the representation of atlas frames and associated data forming one or more coded atlas sequences.
アトラス フレームの表現を形成するビットのシーケンスと、1 つ以上のコード化されたアトラス シーケンスを形成する関連データ。
atlas coding layer NAL unit:
アトラスコーディング層NALユニット：
Collective term for coded atlas tile layer NAL units and the subset of NAL units that have reserved values of nal_unit_type that are classified as being of type class equal to ACL in this document.
コード化されたアトラス タイル層の NAL ユニットと、本書では ACL と等しいタイプ クラスとして分類される nal_unit_type の予約値を持つ NAL ユニットのサブセットの総称。
atlas frame:
アトラスフレーム:
2D rectangular array of atlas samples onto which patches are projected and additional information related to the patches, corresponding to a volumetric frame.
パッチが投影されるアトラス サンプルの 2D 長方形配列と、ボリューム フレームに対応するパッチに関連する追加情報。
attribute:
属性：
Scalar or vector property optionally associated with each point in a volumetric frame such as color, reflectance, surface normal, timestamps, material ID, etc.
色、反射率、表面法線、タイムスタンプ、マテリアル ID など、体積フレーム内の各点にオプションで関連付けられたスカラーまたはベクトルのプロパティ。
coded atlas sequence:
コード化されたアトラス シーケンス:
Sequence of coded atlas access units that consists, in decoding order, of an IRAP-coded atlas access unit, followed by zero or more coded atlas access units that are not IRAP-coded atlas access units, including all subsequent access units up to but not including any subsequent coded atlas access unit that is an IRAP-coded atlas access unit.
デコード順で、IRAP コード化アトラス アクセス ユニットと、それに続く、IRAP コード化アトラス アクセス ユニットではない 0 個以上のコード化アトラス アクセス ユニットから構成されるコード化アトラス アクセス ユニットのシーケンス。IRAP コード化アトラス アクセス ユニットまでの後続のコード化アトラス アクセス ユニットまでのすべてのアクセス ユニットを含みますが、IRAP コード化アトラス アクセス ユニットである後続のコード化アトラス アクセス ユニットは含まれません。
coded atlas access unit:
コード化されたアトラス アクセス ユニット:
Set of atlas NAL units that are associated with each other according to a specified classification rule, are consecutive in decoding order, and contain all atlas NAL units pertaining to one particular output time.
指定された分類ルールに従って相互に関連付けられ、デコード順序で連続し、特定の 1 つの出力時間に関連するすべてのアトラス NAL ユニットを含むアトラス NAL ユニットのセット。
coded V3C sequence:
コード化された V3C シーケンス:
Sequence of V3C atlas and video sub-bitstream(s) identified and separated by appropriate delimiters, required to start with a VPS, included in at least one V3C unit or provided through external means.
適切なデリミタで識別および分離された V3C アトラスおよびビデオ サブビットストリームのシーケンス。VPS で開始する必要があり、少なくとも 1 つの V3C ユニットに含まれるか、外部手段を通じて提供されます。
network abstraction layer unit:
ネットワーク抽象化層ユニット:
Syntax structure containing an indication of the type of data to follow and bytes containing that data in the form of an RBSP.
従うべきデータのタイプの指示と、そのデータを RBSP 形式で含むバイトを含む構文構造。
patch:
パッチ：
Rectangular region within an atlas associated with volumetric information.
体積情報に関連付けられたアトラス内の長方形の領域。
raw byte sequence payload:
生のバイト シーケンス ペイロード:
Syntax structure containing an integer number of bytes that is encapsulated in a NAL unit and that either is 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.
NAL ユニットにカプセル化され、空であるか、構文要素とそれに続く RBSP ストップ ビットと 0 個以上の後続ビットが 0 に等しいデータ ビットの文字列の形式を持つ、整数のバイトを含む構文構造。
tile:
タイル：
Independently decodable rectangular region of an atlas frame.
アトラス フレームの独立してデコード可能な長方形の領域。
V3C atlas sub-bitstream:
V3C アトラス サブビットストリーム:
Extracted sub-bitstream from the V3C bitstream containing a whole or portion of an atlas bitstream.
アトラス ビットストリームの全体または一部を含む、V3C ビットストリームから抽出されたサブビットストリーム。
V3C video sub-bitstream:
V3C ビデオ サブビットストリーム:
Extracted sub-bitstream from the V3C bitstream containing a whole or portion of a video bitstream.
ビデオ ビットストリームの全体または一部を含む、V3C ビットストリームから抽出されたサブビットストリーム。
V3C component:
V3C コンポーネント:
Atlas, occupancy, geometry, or attribute of a particular type that is associated with a V3C volumetric content representation.
V3C ボリューム コンテンツ表現に関連付けられた特定のタイプのアトラス、占有、ジオメトリ、または属性。
V3C parameter set:
V3C パラメータセット:
Syntax structure containing syntax elements that apply to zero or more entire CVSs and may be referred to by syntax elements found in the V3C unit header.
0 個以上の CVS 全体に適用される構文要素を含む構文構造。V3C ユニット ヘッダーにある構文要素によって参照される場合があります。
volumetric frame:
体積フレーム:
Set of 3D points specified by their Cartesian coordinates and zero or more corresponding sets of attributes at a particular time instance.
特定の時間インスタンスにおけるデカルト座標と 0 個以上の対応する属性セットによって指定される 3D 点のセット。
V3C encoding of a volumetric frame is achieved through a conversion of the volumetric frame from its 3D representation into multiple 2D representations and a generation of associated data documenting such conversions and transformations. The associated data, also known as the atlas data, provides information on how to reproject the 2D representations back into the 3D volumetric frame.
体積フレームの V3C エンコードは、体積フレームを 3D 表現から複数の 2D 表現に変換し、そのような変換と変換を文書化する関連データを生成することによって実現されます。アトラス データとも呼ばれる関連データは、2D 表現を 3D 体積フレームに再投影する方法に関する情報を提供します。
2D representations, known as V3C video components, of a volumetric frame are encoded using conventional 2D video codecs. A V3C video component may, for example, include occupancy, geometry, or attribute data. The occupancy data informs a V3C decoder which pixels in other V3C video components contribute to reconstructed 3D representation. The geometry data describes information on the position of the reconstructed voxels while attribute data provides additional properties for the voxels, e.g., color or material information. A voxel is the smallest discrete addressable element in a 3D space, analogous to a pixel in 2D.
V3C ビデオ コンポーネントとして知られるボリューム フレームの 2D 表現は、従来の 2D ビデオ コーデックを使用してエンコードされます。V3C ビデオ コンポーネントには、たとえば、占有、ジオメトリ、または属性データが含まれる場合があります。占有データは、他の V3C ビデオ コンポーネントのどのピクセルが再構築された 3D 表現に寄与するかを V3C デコーダに通知します。ジオメトリ データは再構成されたボクセルの位置に関する情報を記述し、属性データは色や材質情報などのボクセルの追加プロパティを提供します。ボクセルは、2D のピクセルに似た、3D 空間内の最小の個別のアドレス指定可能な要素です。
Atlas data, known as V3C atlas component, provides information to interpret V3C video components and enables the reconstruction from a 2D representation back into a 3D representation of a volumetric frame. Atlas data is composed of a collection of patches. Each patch identifies a region in the V3C video components and provides information necessary to perform the appropriate inverse projection of the indicated region back into a 3D space. The shape of the patch region is determined by a 2D bounding box associated with each patch as well as their coding order. The shape of these patches is also further refined based on occupancy data.
V3C アトラス コンポーネントとして知られるアトラス データは、V3C ビデオ コンポーネントを解釈するための情報を提供し、2D 表現からボリューム フレームの 3D 表現への再構成を可能にします。アトラス データはパッチの集合で構成されます。各パッチは、V3C ビデオ コンポーネント内の領域を識別し、指定された領域を 3D 空間に適切に逆投影するために必要な情報を提供します。パッチ領域の形状は、各パッチに関連付けられた 2D 境界ボックスとそのコーディング順序によって決まります。これらのパッチの形状も占有データに基づいてさらに改良されます。
To enable parallelization, random access, as well as a variety of other functionalities, an atlas frame can be divided into one or more rectangular partitions referred to as tiles. Tiles are not allowed to overlap and should be independently decodable. An atlas frame may contain regions that are not associated with any tile or patch.
並列化、ランダム アクセス、その他のさまざまな機能を有効にするために、アトラス フレームをタイルと呼ばれる 1 つ以上の長方形のパーティションに分割できます。タイルは重複することができず、独立してデコード可能である必要があります。アトラス フレームには、タイルやパッチに関連付けられていない領域が含まれる場合があります。
The binary form of V3C video components, i.e., video bitstream, and V3C atlas components, i.e., atlas bitstream, can be grouped and represented by a single V3C bitstream. The V3C bitstream is composed of a set of V3C units. Each V3C unit has a V3C unit header and a V3C unit payload. The V3C unit header describes the V3C unit type for the payload. The V3C unit payload contains V3C video components, V3C atlas components, or a V3C parameter set. V3C video components, i.e., occupancy, geometry, or attribute components, correspond to video data units (e.g., NAL units defined in [ISO.IEC.23008-2]) that could be decoded by an appropriate video decoder. An example of a V3C bitstream consisting of a V3C parameter set, atlas bitstream, and three video component bitstreams (geometry, occupancy, attribute) is provided in Figure 1.
バイナリ形式の V3C ビデオ コンポーネント (ビデオ ビットストリーム) と V3C アトラス コンポーネント (アトラス ビットストリーム) は、グループ化して 1 つの V3C ビットストリームで表すことができます。V3C ビットストリームは、一連の V3C ユニットで構成されます。各 V3C ユニットには、V3C ユニット ヘッダーと V3C ユニット ペイロードがあります。V3C ユニット ヘッダーは、ペイロードの V3C ユニット タイプを記述します。V3C ユニット ペイロードには、V3C ビデオ コンポーネント、V3C アトラス コンポーネント、または V3C パラメータ セットが含まれます。V3C ビデオ コンポーネント、つまり占有コンポーネント、ジオメトリ コンポーネント、または属性コンポーネントは、適切なビデオ デコーダによってデコードできるビデオ データ ユニット ([ISO.IEC.23008-2] で定義されている NAL ユニットなど) に対応します。V3C パラメータ セット、アトラス ビットストリーム、および 3 つのビデオ コンポーネント ビットストリーム (ジオメトリ、占有、属性) で構成される V3C ビットストリームの例を図 1 に示します。
+-------------------+------------------+-------------------+
| V3C Unit(V3C_VPS) | V3C Unit(V3C_AD) | V3C Unit(V3C_GVD) |
+-------------------+------------------++-----------------++---
| V3C Unit(V3C_OVD) | V3C Unit(V3C_AVD) | V3C Unit(V3C_AD)| ...
+-------------------+-------------------+-----------------+----
Figure 1: Example of a V3C Bitstream
図 1: V3C ビットストリームの例
This document specifies an encapsulation of V3C atlas data. Aspects related to signaling of V3C parameter set, defined in [ISO.IEC.23090-5], are also considered. A V3C parameter set is encapsulated in its own V3C unit, which allows decoupling the transmission of V3C parameter set from the V3C video and atlas components. The V3C parameter set can be transmitted by external means (e.g., as a result of the capability exchange) or through a (reliable or unreliable) control protocol. Section 9 of this document specifies how a V3C parameter set can be signaled using the Session Description Protocol (SDP).
この文書は、V3C アトラス データのカプセル化を指定します。[ISO.IEC.23090-5] で定義されている V3C パラメータセットのシグナリングに関連する側面も考慮されます。V3C パラメータ セットは、独自の V3C ユニットにカプセル化されているため、V3C パラメータ セットの送信を V3C ビデオおよびアトラス コンポーネントから切り離すことができます。V3C パラメータ セットは、外部手段 (たとえば、機能交換の結果) によって、または (信頼できるまたは信頼できない) 制御プロトコルを通じて送信できます。この文書のセクション 9 では、セッション記述プロトコル (SDP) を使用して V3C パラメータ セットを通知する方法を指定します。
Generally, it is useful to signal a V3C parameter set out of band, because it describes what overall resources are needed to decode and reconstruct the associated V3C bitstream. Signaling it dynamically as part of an RTP stream might result in undefined behavior when the receiver does not have the required capabilities to decode the received V3C video component sub-bitstreams or when reconstruction process relies on information that the receiver does not support.
一般に、帯域外の V3C パラメータ セットをシグナリングすると、関連する V3C ビットストリームをデコードして再構築するために必要な全体的なリソースが記述されるため、便利です。RTP ストリームの一部として動的に通知すると、受信した V3C ビデオ コンポーネントのサブビットストリームをデコードするために必要な機能が受信機にない場合、または再構築プロセスが受信機がサポートしていない情報に依存している場合に、未定義の動作が発生する可能性があります。
In the V3C bitstream, the atlas component is identified by vuh_unit_type equal to V3C_AD, or V3C_CAD in the case of common atlas data, in the V3C unit header. The V3C atlas component consists of atlas NAL units that define header and payload pairs; see Section 4.3.2. V3C video components are identified by vuh_unit_type equal to V3C_OVD, V3C_GVD, V3C_AVD, and V3C_PVD. V3C video components can be further differentiated by other values in the V3C unit header such as vuh_attribute_index, vuh_attribute_partition_index, vuh_map_index, and vuh_auxiliary_video_flag. By mapping the V3C parameter set information to vuh_attribute_index, a V3C decoder identifies which attribute a given V3C video component contains, e.g., color.
V3C ビットストリームでは、アトラス コンポーネントは、V3C ユニット ヘッダー内の V3C_AD または共通アトラス データの場合は V3C_CAD に等しい vuh_unit_type によって識別されます。V3C アトラス コンポーネントは、ヘッダーとペイロードのペアを定義するアトラス NAL ユニットで構成されます。セクション 4.3.2 を参照してください。V3C ビデオ コンポーネントは、V3C_OVD、V3C_GVD、V3C_AVD、および V3C_PVD に等しい vuh_unit_type によって識別されます。V3C ビデオ コンポーネントは、vuh_attribute_index、vuh_attribute_partition_index、vuh_map_index、vuh_auxiliary_video_flag などの V3C ユニット ヘッダー内の他の値によってさらに区別できます。V3C パラメータ セット情報を vuh_attribute_index にマッピングすることにより、V3C デコーダは、特定の V3C ビデオ コンポーネントにどの属性 (色など) が含まれているかを識別します。
The information supplied by a V3C unit header should be provided in one form or another to a V3C decoder, e.g., as part of SDP as described in Section 9. The four-byte V3C unit header syntax and semantics are copied below as defined in [ISO.IEC.23090-5], but the syntax is subject to change. Implementations should always refer to the latest specification of [ISO.IEC.23090-5]. The syntax of four-byte V3C unit header is provided here for informative purposes only. The integers in the parentheses, e.g., unsigned int(5), indicate the number of bits used by the syntax element.
V3C ユニットヘッダーによって提供される情報は、セクション 9 で説明されているように、SDP の一部としてなど、何らかの形式で V3C デコーダーに提供される必要があります。4 バイトの V3C ユニットヘッダーの構文とセマンティクスは、[ISO.IEC.23090-5] で定義されているように以下にコピーされますが、構文は変更される可能性があります。実装では常に [ISO.IEC.23090-5] の最新仕様を参照する必要があります。4 バイトの V3C ユニット ヘッダーの構文は、情報提供のみを目的としてここに提供されています。括弧内の整数 (例: unsigned int(5)) は、構文要素で使用されるビット数を示します。
v3c_unit_header( ) {
unsigned int(5) vuh_unit_type;
if( vuh_unit_type == V3C_AVD || vuh_unit_type == V3C_GVD ||
vuh_unit_type == V3C_OVD || vuh_unit_type == V3C_AD ||
vuh_unit_type == V3C_CAD || vuh_unit_type == V3C_PVD ) {
unsigned int(4) vuh_v3c_parameter_set_id;
}
if( vuh_unit_type == V3C_AVD || vuh_unit_type == V3C_GVD ||
vuh_unit_type == V3C_OVD || vuh_unit_type == V3C_AD ||
vuh_unit_type == V3C_PVD ) {
unsigned int(6) vuh_atlas_id;
}
if( vuh_unit_type == V3C_AVD ) {
unsigned int(7) vuh_attribute_index;
unsigned int(5) vuh_attribute_partition_index;
unsigned int(4) vuh_map_index;
unsigned int(1) vuh_auxiliary_video_flag;
}
else if( vuh_unit_type == V3C_GVD ) {
unsigned int(4) vuh_map_index;
unsigned int(1) vuh_auxiliary_video_flag;
bit(12) vuh_reserved_zero_12bits;
}
else if( vuh_unit_type == V3C_OVD || vuh_unit_type == V3C_AD ||
vuh_unit_type == V3C_PVD) {
bit(17) vuh_reserved_zero_17bits;
}
else if( vuh_unit_type == V3C_CAD ) {
bit(23) vuh_reserved_zero_23bits;
}
else {
bit(27) vuh_reserved_zero_27bits;
}
}
vuh_unit_type indicates the V3C unit type for the V3C component as specified in [ISO.IEC.23090-5]. For convenience, the mapping table from vuh_unit_type values to semantics is shown in Table 1.
vuh_unit_type は、[ISO.IEC.23090-5] で指定されている V3C コンポーネントの V3C ユニット タイプを示します。便宜上、vuh_unit_type 値からセマンティクスへのマッピング テーブルを表 1 に示します。
+===============+============+===========+======================+
| vuh_unit_type | Identifier | V3C unit | Description |
| | | type | |
+===============+============+===========+======================+
| 0 | V3C_VPS | V3C | V3C level parameters |
| | | parameter | |
| | | set | |
+---------------+------------+-----------+----------------------+
| 1 | V3C_AD | Atlas | Atlas information |
| | | data | |
+---------------+------------+-----------+----------------------+
| 2 | V3C_OVD | Occupancy | Occupancy |
| | | video | information |
| | | data | |
+---------------+------------+-----------+----------------------+
| 3 | V3C_GVD | Geometry | Geometry information |
| | | video | |
| | | data | |
+---------------+------------+-----------+----------------------+
| 4 | V3C_AVD | Attribute | Attribute |
| | | video | information |
| | | data | |
+---------------+------------+-----------+----------------------+
| 5 | V3C_PVD | Packed | Packing information |
| | | video | |
| | | data | |
+---------------+------------+-----------+----------------------+
| 6 | V3C_CAD | Common | Information that is |
| | | atlas | common for atlases |
| | | data | in a CVS. Specified |
| | | | in ISO/IEC 23090-12. |
+---------------+------------+-----------+----------------------+
| 7...31 | V3C_RSVD | Reserved | - |
+---------------+------------+-----------+----------------------+
Table 1: V3C Unit Type Semantics
表 1: V3C ユニット タイプのセマンティクス
vuh_v3c_parameter_set_id specifies the value of vps_v3c_parameter_set_id for the active V3C VPS.
vuh_v3c_parameter_set_id は、アクティブな V3C VPS の vps_v3c_parameter_set_id の値を指定します。
vuh_atlas_id specifies the ID of the atlas that corresponds to the current V3C unit.
vuh_atlas_id は、現在の V3C ユニットに対応するアトラスの ID を指定します。
vuh_attribute_index indicates the index of the attribute data carried in the Attribute Video Data unit.
vuh_attribute_indexは、属性ビデオデータユニット内で伝送される属性データのインデックスを示す。
vuh_attribute_partition_index indicates the index of the attribute dimension group carried in the attribute video data unit.
vuh_attribute_partition_indexは、属性ビデオデータユニットに含まれる属性次元グループのインデックスを示す。
vuh_map_index, when present, indicates the map index of the current geometry or attribute stream. When not present, the map index of the current geometry or attribute sub-bitstream is derived based on the type of the sub-bitstream.
vuh_map_index が存在する場合、現在のジオメトリまたは属性ストリームのマップ インデックスを示します。存在しない場合、現在のジオメトリまたは属性のサブビットストリームのマップ インデックスは、サブビットストリームのタイプに基づいて導出されます。
vuh_auxiliary_video_flag equal to 1 indicates that the associated geometry or attribute video sub-bitstream contains only RAW and/or enhanced occupancy map (EOM) coded points.
vuh_auxiliary_video_flag が 1 に等しい場合は、関連するジオメトリまたは属性ビデオ サブビットストリームに RAW および/または拡張占有マップ (EOM) コード化ポイントのみが含まれていることを示します。
The atlas NAL unit (nal_unit(NumBytesInNalUnit)) is a byte-aligned syntax structure defined by [ISO.IEC.23090-5] to carry atlas data. The atlas NAL unit always contains a 16-bit NAL unit header (nal_unit_header()), which indicates the type of the NAL unit (nal_unit_type) among other things. The payload of a NAL unit refers to the NAL unit excluding the NAL unit header. The atlas NAL unit syntax and semantics are copied here as defined in [ISO.IEC.23090-5].
アトラス NAL ユニット (nal_unit(NumBytesInNalUnit)) は、アトラス データを伝送するために [ISO.IEC.23090-5] によって定義されたバイト整列構文構造です。アトラス NAL ユニットには常に 16 ビットの NAL ユニット ヘッダー (nal_unit_header()) が含まれており、特に NAL ユニットのタイプ (nal_unit_type) を示します。ＮＡＬユニットのペイロードとは、ＮＡＬユニットヘッダを除いたＮＡＬユニットを指す。アトラス NAL ユニットの構文とセマンティクスは、[ISO.IEC.23090-5] で定義されているようにここにコピーされます。
nal_unit_header(){
bit(1) nal_forbidden_zero_bit;
bit(6) nal_unit_type;
bit(6) nal_layer_id;
bit(3) nal_temporal_id_plus1;
}
nal_unit(NumBytesInNalUnit){
nal_unit_header();
NumBytesInRbsp = 0;
for( i = 2; i < NumBytesInNalUnit; i++ )
bit(8) rbsp_byte[ NumBytesInRbsp++ ];
}
nal_forbidden_zero_bit provides means for indicating errors in NAL units.
nal_forbidden_zero_bit は、NAL ユニットのエラーを示す手段を提供します。
nal_unit_type indicates the type of the RBSP data structure contained in the NAL unit.
nal_unit_typeは、NALユニットに含まれるRBSPデータ構造のタイプを示す。
nal_layer_id indicates the identifier of the layer to which an ACL NAL unit belongs or the identifier of a layer to which a non-ACL NAL unit applies.
nal_layer_idは、ACL NALユニットが属するレイヤの識別子、またはnon-ACL NALユニットが適用されるレイヤの識別子を示す。
nal_temporal_id_plus1 minus 1 indicates a temporal identifier for the NAL unit.
nal_temporal_id_plus1 マイナス 1 は、NAL ユニットの時間識別子を示します。
In addition to releasing specifications on V3C applications [ISO.IEC.23090-5] and [ISO.IEC.23090-12], MPEG conducted further systems-level work on file formats to encapsulate compressed V3C content. The seventh edition of the ISO Base Media File Format (ISOBMFF) specification [ISO.IEC.14496-12] introduces a new media handler 'volv', intended to support volumetric visual media. It also specifies other structures to enable development of derived specifications detailing how various volumetric visual media may be stored in ISOBMFF.
V3C アプリケーション [ISO.IEC.23090-5] および [ISO.IEC.23090-12] の仕様をリリースすることに加えて、MPEG は、圧縮された V3C コンテンツをカプセル化するためのファイル形式に関するさらなるシステムレベルの作業を実施しました。ISO Base Media File Format (ISOBMFF) 仕様 [ISO.IEC.14496-12] の第 7 版では、ボリューム ビジュアル メディアをサポートすることを目的とした新しいメディア ハンドラー 'volv' が導入されています。また、さまざまな体積視覚メディアを ISOBMFF に保存する方法を詳述する派生仕様の開発を可能にする他の構造も指定します。
One of such derived specifications is [ISO.IEC.23090-10], which defines how V3C content can be stored in a file and streamed over DASH [ISO.IEC.23009-1]. To a large extent, ISO/IEC 23090-10 focuses on describing how ISOBMFF boxes and syntax elements may be used to store volumetric media, but in some cases, new boxes and syntax elements are introduced to accommodate the fundamentally different type of new media. While the specification is not directly relevant for defining RTP payload format for V3C atlas data, it is a useful resource that may be considered especially when designing ingestion of encoded V3C content into RTP streaming pipelines.
このような派生仕様の 1 つが [ISO.IEC.23090-10] で、V3C コンテンツをファイルに保存し、DASH 経由でストリーミングする方法を定義しています [ISO.IEC.23009-1]。ISO/IEC 23090-10 は大部分において、ISOBMFF ボックスと構文要素を使用して体積メディアを保存する方法を説明することに重点を置いていますが、場合によっては、根本的に異なるタイプの新しいメディアに対応するために新しいボックスと構文要素が導入されます。この仕様は、V3C アトラス データの RTP ペイロード形式の定義には直接関係しませんが、特にエンコードされた V3C コンテンツの RTP ストリーミング パイプラインへの取り込みを設計する場合に考慮される有用なリソースです。
This section describes details related to V3C atlas RTP payload format definitions. Aspects related to the RTP header, RTP payload header, and general payload structure are considered. RTP payload format(s) for video components is defined in its respective RTP payload format specifications depending on the video codec used.
このセクションでは、V3C アトラス RTP ペイロード形式の定義に関連する詳細について説明します。RTP ヘッダー、RTP ペイロード ヘッダー、および一般的なペイロード構造に関連する側面が考慮されます。ビデオ コンポーネントの RTP ペイロード形式は、使用されるビデオ コーデックに応じて、それぞれの RTP ペイロード形式仕様で定義されます。
The format of the RTP header is specified in [RFC3550] and replicated in Figure 2 for convenience. V3C RTP payload format uses the fields of the RTP header in a manner consistent with [RFC3550]. Unless contextualized below, the meaning of the fields depicted in Figure 2 is the same as in Section 5.1 of [RFC3550].
RTP ヘッダーの形式は [RFC3550] で規定されており、便宜上図 2 に複製されています。V3C RTP ペイロード形式は、[RFC3550] に準拠した方法で RTP ヘッダーのフィールドを使用します。以下で説明しない限り、図 2 に示されているフィールドの意味は、[RFC3550] のセクション 5.1 の意味と同じです。
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
図 2: RTP ヘッダー
Marker bit (M): 1 bit
マーカービット(M)：1ビット
Set for the last packet of the access unit and carried in the current RTP stream. This is in line with the normal use of the M bit in video formats to allow an efficient playout buffer handling.
アクセス ユニットの最後のパケットに設定され、現在の RTP ストリームで伝送されます。これは、効率的な再生バッファ処理を可能にするビデオ フォーマットでの M ビットの通常の使用と一致しています。
Payload Type (PT): 7 bits
ペイロードタイプ(PT): 7ビット
The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here. The assignment of a payload type MUST be performed either through the profile used or in a dynamic way.
この新しいパケット形式に対する RTP ペイロード タイプの割り当ては、このドキュメントの範囲外であるため、ここでは指定しません。ペイロード タイプの割り当ては、使用するプロファイルを通じて、または動的方法で実行しなければなりません (MUST)。
Timestamp: 32 bits
タイムスタンプ: 32ビット
The RTP timestamp is set to the sampling timestamp of the content. A 90 kHz clock rate MUST be used.
RTP タイムスタンプは、コンテンツのサンプリング タイムスタンプに設定されます。90 kHz のクロック レートを使用する必要があります。
If the NAL unit has no timing properties of its own (e.g., parameter set and Supplemental Enhancement Information (SEI) NAL units), the RTP timestamp MUST be set to the RTP timestamp of the coded atlas of the access unit in which the NAL unit (according to Section 8.4.5.3 of [ISO.IEC.23090-5]) is included.
NAL ユニットが独自のタイミング特性 (例: パラメータセットや補足拡張情報 (SEI) NAL ユニット) を持たない場合、RTP タイムスタンプは、([ISO.IEC.23090-5] のセクション 8.4.5.3 に従って) NAL ユニットが含まれるアクセスユニットのコード化されたアトラスの RTP タイムスタンプに設定されなければなりません (MUST)。
Receivers MUST use the RTP timestamp for the display process, even when the bitstream contains atlas frame timing SEI messages as specified in [ISO.IEC.23090-5].
[ISO.IEC.23090-5] で指定されているように、ビットストリームにアトラス フレーム タイミング SEI メッセージが含まれている場合でも、受信機は表示プロセスに RTP タイムスタンプを使用しなければなりません (MUST)。
The remaining RTP header fields are used as specified in [RFC3550].
残りの RTP ヘッダー フィールドは、[RFC3550] の規定に従って使用されます。
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, NUT, NLI, and TID) as the NAL unit header as shown in Section 4.3.2, irrespective of the type of the payload structure. For convenience, the structure of RTP payload header is shown in Figure 3.
RTP パケットのペイロードの最初の 2 バイトは、ペイロード ヘッダーと呼ばれます。ペイロード ヘッダーは、ペイロード構造のタイプに関係なく、セクション 4.3.2 に示す NAL ユニット ヘッダーと同じフィールド (F、NUT、NLI、および TID) で構成されます。便宜上、RTP ペイロード ヘッダーの構造を図 3 に示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| NUT | NLI | TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RTP Payload Header
図 3: RTP ペイロード ヘッダー
F:
F:
The nal_forbidden_zero_bit as specified in [ISO.IEC.23090-5] is equal to 0. A value equal to 1 indicates that the payload may contain errors or syntax violations.
[ISO.IEC.23090-5] で指定されている nal_forbidden_zero_bit は 0 に等しい。値が 1 に等しい場合は、ペイロードにエラーまたは構文違反が含まれている可能性があることを示します。
Media processing elements in the network that are capable of deep packet inspection SHOULD set the F bit to 1 to indicate detected bit errors in the NAL unit(s). A receiver reaction to an RTP payload header in which the F bit is equal to 1 is to discard such RTP packet and to conceal the lost data in the discarded NAL unit(s).
ディープパケットインスペクションが可能なネットワーク内のメディア処理要素は、NAL ユニットで検出されたビットエラーを示すために F ビットを 1 に設定すべきです(SHOULD)。F ビットが 1 に等しい RTP ペイロード ヘッダーに対する受信者の反応は、そのような RTP パケットを破棄し、破棄された NAL ユニットに失われたデータを隠すことです。
NUT:
NUT:
The nal_unit_type as specified in [ISO.IEC.23090-5] defines the type of the RBSP data structure contained in the NAL unit payload. The NUT value could carry other meaning depending on the RTP packet type.
[ISO.IEC.23090-5] で指定されている nal_unit_type は、NAL ユニット ペイロードに含まれる RBSP データ構造のタイプを定義します。NUT 値は、RTP パケット タイプに応じて他の意味を持つ場合があります。
NLI:
NLI:
The nal_layer_id as specified in [ISO.IEC.23090-5] defines the identifier of the layer to which an ACL NAL unit belongs or the identifier of a layer to which a non-ACL NAL unit applies.
[ISO.IEC.23090-5] で指定されている nal_layer_id は、ACL NAL ユニットが属する層の識別子、または非 ACL NAL ユニットが適用される層の識別子を定義します。
TID:
TID:
The nal_temporal_id_plus1 minus 1 as specified in [ISO.IEC.23090-5] defines a temporal identifier for the NAL unit. The value of nal_temporal_id_plus1 MUST NOT be equal to 0.
[ISO.IEC.23090-5] で指定されている nal_temporal_id_plus1 から 1 を引いた値は、NAL ユニットの時間識別子を定義します。nal_temporal_id_plus1 の値は 0 であってはなりません。
Three different types of RTP packet payload structures are specified. A receiver can identify the payload structure by the first two bytes of the RTP packet payload, which co-serves as the RTP payload header. These two bytes are always structured as a NAL unit header. The NAL unit type field indicates which structure is present in the payload.
3 つの異なるタイプの RTP パケット ペイロード構造が指定されています。受信者は、RTP パケット ペイロードの最初の 2 バイトによってペイロード構造を識別できます。これは RTP ペイロード ヘッダーとしても機能します。これら 2 バイトは常に NAL ユニット ヘッダーとして構造化されます。NAL ユニット タイプ フィールドは、ペイロードにどの構造が存在するかを示します。
The three different payload structures are as follows:
3 つの異なるペイロード構造は次のとおりです。
Single NAL Unit Packet:
単一の NAL ユニット パケット:
Contains a single NAL unit in the payload. This payload structure is specified in Section 5.4.2.
ペイロードに単一の NAL ユニットが含まれます。このペイロード構造はセクション 5.4.2 で規定されています。
Aggregation Packet:
集約パケット:
Contains multiple NAL units in a single RTP payload. This payload structure is specified in Section 5.4.3.
単一の RTP ペイロードに複数の NAL ユニットが含まれます。このペイロード構造はセクション 5.4.3 で規定されています。
Fragmentation Unit (FU):
断片化ユニット (FU):
Contains a subset of a single NAL unit. This payload structure is specified in Section 5.4.4.
単一の NAL ユニットのサブセットが含まれます。このペイロード構造はセクション 5.4.4 で規定されています。
NOTE (informative): This document does not limit the size of NAL units encapsulated in NAL unit packets and fragmentation units. [ISO.IEC.23090-5] does not restrict the maximum size of a NAL unit directly, either. Instead, a NAL unit sample stream format may be used, which provides flexibility to signal NAL unit size up to UINT64_MAX bytes.
注 (参考): この文書は、NAL ユニット パケットにカプセル化された NAL ユニットおよびフラグメンテーション ユニットのサイズを制限しません。[ISO.IEC.23090-5] も、NAL ユニットの最大サイズを直接制限しません。代わりに、NAL ユニット サンプル ストリーム フォーマットを使用することもできます。これにより、最大 UINT64_MAX バイトまでの NAL ユニット サイズを柔軟に通知できます。
NOTE (informative): Some of the fields described in the payload structures are conditional and their presence is indicated through the relevant parameters as defined in Section 7.3. These parameters are assumed to be made available prior to sending any RTP packets.
注 (参考): ペイロード構造で説明されているフィールドの一部は条件付きであり、その存在はセクション 7.3 で定義されている関連パラメータを通じて示されます。これらのパラメータは、RTP パケットを送信する前に利用可能になると想定されます。
A single NAL unit packet contains exactly one NAL unit and consists of an RTP payload header and the following conditional fields: 16-bit DONL and 16-bit v3c-tile-id. The rest of the payload data contains the NAL unit payload data (excluding the NAL unit header). A single NAL unit packet MUST only contain atlas NAL units of the types defined in Table 4 of [ISO.IEC.23090-5]. The structure of the single NAL unit packet is shown in Figure 4.
単一の NAL ユニット パケットには、ちょうど 1 つの NAL ユニットが含まれており、RTP ペイロード ヘッダーと次の条件フィールド (16 ビット DONL および 16 ビット v3c-tile-id) で構成されます。ペイロード データの残りの部分には、NAL ユニット ペイロード データが含まれます（NAL ユニット ヘッダーを除く）。単一の NAL ユニット パケットには、[ISO.IEC.23090-5] の表 4 で定義されているタイプのアトラス NAL ユニットのみが含まれなければなりません (MUST)。単一の NAL ユニット パケットの構造を図 4 に示します。
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 payload header | DONL (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| v3c-tile-id (cond) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| NAL unit data |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Single NAL Unit Packet
図 4: 単一の NAL ユニット パケット
The RTP payload header MUST be an exact copy of the NAL unit header of the contained NAL unit.
RTP ペイロード ヘッダーは、含まれる NAL ユニットの NAL ユニット ヘッダーの正確なコピーでなければなりません (MUST)。
A NAL unit stream composed by de-packetizing single NAL unit packets in RTP sequence number order MUST conform to the NAL unit decoding order when DONL is not present.
RTP シーケンス番号の順序で単一の NAL ユニット パケットをデパケット化することによって構成される NAL ユニット ストリームは、DONL が存在しない場合、NAL ユニットのデコード順序に従わなければなりません (MUST)。
The DONL field, when present, specifies the value of the 16-bit decoding order number of the contained NAL unit. The decoding order number indicates the order in which the received NAL units should be reordered to form a bitstream that can be successfully decoded. If sprop-max-don-diff is greater than 0 for any of the RTP streams, the DONL field MUST be present; otherwise, the DONL field MUST NOT be present.
DONL フィールドが存在する場合、DONL フィールドは、含まれる NAL ユニットの 16 ビットのデコード順序番号の値を指定します。デコード順序番号は、正常にデコードできるビットストリームを形成するために、受信した NAL ユニットを並べ替える順序を示します。いずれかの RTP ストリームで sprop-max-don-diff が 0 より大きい場合、DONL フィールドが存在しなければなりません (MUST)。それ以外の場合、DONL フィールドは存在してはなりません。
The v3c-tile-id field, when present, specifies the 16-bit tile identifier for the NAL unit as signaled in the V3C atlas tile header defined in [ISO.IEC.23090-5]. If sprop-v3c-tile-id-pres is equal to 1 and the RTP payload header NUT is in range 0-35 inclusive, the v3c-tile-id field MUST be present. Otherwise, the v3c-tile-id field MUST NOT be present.
v3c-tile-id フィールドが存在する場合、[ISO.IEC.23090-5] で定義されている V3C アトラス タイル ヘッダーで通知される NAL ユニットの 16 ビット タイル識別子を指定します。sprop-v3c-tile-id-pres が 1 に等しく、RTP ペイロード ヘッダー NUT が 0 ～ 35 の範囲内にある場合、v3c-tile-id フィールドが存在しなければなりません (MUST)。それ以外の場合、v3c-tile-id フィールドは存在してはなりません (MUST NOT)。
NOTE (informative): Only values for NAL unit type (NUT) in range 0-35 inclusive are allocated for atlas tile layer data in [ISO.IEC.23090-5].
注 (参考): [ISO.IEC.23090-5] のアトラス タイル レイヤー データには、0 ～ 35 の範囲の NAL ユニット タイプ (NUT) の値のみが割り当てられます。
The presence of the "OPTIONAL RTP padding" is indicated by the padding (P) bit in the RTP header. As defined in [RFC3550], the last octet of the padding contains a count of how many padding octets should be ignored, including itself.
「オプションの RTP パディング」の存在は、RTP ヘッダーのパディング (P) ビットによって示されます。[RFC3550] で定義されているように、パディングの最後のオクテットには、それ自体を含め、無視する必要があるパディング オクテットの数が含まれます。
APs enable the reduction of packetization overhead for small NAL units, such as most of the non-ACL NAL units, which are often only a few octets in size.
AP を使用すると、ほとんどの非 ACL NAL ユニットなど、サイズがわずか数オクテットであることが多い、小さな NAL ユニットのパケット化オーバーヘッドを削減できます。
APs MAY be used to wrap multiple NAL units belonging to the same access unit in a single RTP payload. The first two bytes of an AP MUST contain the RTP payload header. The NAL unit type (NUT) for the NAL unit header contained in the RTP payload header MUST be equal to 56, which falls in the unspecified range of the NAL unit types defined in [ISO.IEC.23090-5]. An AP MAY contain a conditional v3c-tile-id field. An AP MUST contain two or more AUs. The structure of an AP is shown in Figure 5.
AP は、同じアクセス ユニットに属する複数の NAL ユニットを 1 つの RTP ペイロードにラップするために使用できます (MAY)。AP の最初の 2 バイトには、RTP ペイロード ヘッダーが含まれなければなりません (MUST)。RTP ペイロード ヘッダーに含まれる NAL ユニット ヘッダーの NAL ユニット タイプ (NUT) は 56 でなければなりません (MUST)。これは、[ISO.IEC.23090-5] で定義されている NAL ユニット タイプの不特定の範囲に該当します。AP には、条件付きの v3c-tile-id フィールドが含まれてもよい（MAY）。AP には 2 つ以上の AU が含まれなければなりません。AP の構造を図 5 に示します。
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 payload header (NUT=56) | v3c-tile-id (cond) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Two or more aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Aggregation Packet (AP)
図 5: アグリゲーション パケット (AP)
The fields in the payload header are set as follows. The F bit MUST be equal to 0 if the F bit of each aggregated NAL unit is equal to zero; otherwise, it MUST be equal to 1. The NUT field MUST be equal to 56. The value of NLI MUST be equal to the lowest value of NLI of all the aggregated NAL units. The value of TID MUST be the lowest value of TID of all the aggregated NAL units.
ペイロードヘッダーのフィールドは次のように設定されます。集約された各 NAL ユニットの F ビットが 0 に等しい場合、F ビットは 0 に等しくなければなりません (MUST)。それ以外の場合は、1 に等しくなければなりません。NUT フィールドは 56 に等しくなければなりません。NLI の値は、集約されたすべての NAL ユニットの NLI の最小値に等しくなければなりません。TID の値は、集約されたすべての NAL ユニットの TID の最小値でなければなりません。
All ACL NAL units in an aggregation packet have the same TID value since they belong to the same access unit. However, the packet MAY contain non-ACL NAL units for which the TID value in the NAL unit header MAY be different than the TID value of the ACL NAL units in the same AP.
アグリゲーション パケット内のすべての ACL NAL ユニットは、同じアクセス ユニットに属しているため、同じ TID 値を持ちます。ただし、パケットには、NAL ユニット ヘッダーの TID 値が同じ AP 内の ACL NAL ユニットの TID 値と異なる非 ACL NAL ユニットが含まれていてもよい(MAY)。
The v3c-tile-id field, when present, specifies the 16-bit tile identifier for all ACL NAL units in the AP. If sprop-v3c-tile-id-pres is equal to 1, the v3c-tile-id field MUST be present. Otherwise, the v3c-tile-id field MUST NOT be present.
v3c-tile-id フィールドが存在する場合、AP 内のすべての ACL NAL ユニットの 16 ビット タイル識別子を指定します。sprop-v3c-tile-id-pres が 1 に等しい場合、v3c-tile-id フィールドが存在しなければなりません。それ以外の場合、v3c-tile-id フィールドは存在してはなりません (MUST NOT)。
The presence of the "OPTIONAL RTP padding" is indicated by the padding (P) bit in the RTP header. As defined in [RFC3550] the last octet of the padding contains a count of how many padding octets should be ignored, including itself.
「オプションの RTP パディング」の存在は、RTP ヘッダーのパディング (P) ビットによって示されます。[RFC3550] で定義されているように、パディングの最後のオクテットには、それ自体を含め、無視する必要があるパディング オクテットの数が含まれます。
An AP MUST carry at least two AUs and can carry as many AUs as necessary. However, the total amount of data in an AP MUST fit into an IP packet, and the size SHOULD be chosen so that the resulting IP packet is smaller than the local MTU size so to avoid IP layer fragmentation. The structure of the AU depends both on the presence of the decoding order number, the sequence order of the AU in the AP, and the presence of v3c-tile-id field. The structure of an AU is shown in Figure 6.
AP は少なくとも 2 つの AU を伝送する必要があり、必要な数の AU を伝送できます。ただし、AP 内のデータの総量は IP パケットに収まらなければならず、IP 層の断片化を避けるために、結果として得られる IP パケットがローカル MTU サイズより小さくなるようにサイズを選択する必要があります (SHOULD)。AU の構造は、デコード順序番号の存在、AP 内の AU のシーケンス順序、および v3c-tile-id フィールドの存在の両方に依存します。AU の構造を図 6 に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DOND (cond) / DONL (cond) | v3c-tile-id (cond) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| NALU size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Aggregation Unit (AU)
図 6: アグリゲーション ユニット (AU)
If sprop-max-don-diff is greater than 0 for any of the RTP streams, an AU begins with the DOND/DONL field. The first AU in the AP contains DONL field, which specifies the 16-bit value of the decoding order number of the aggregated NAL unit. The variable DON for the aggregated NAL unit is derived as equal to the value of the DONL field. All subsequent AUs in the AP MUST contain an (8-bit) DOND field, which specifies the difference between the decoding order number values of the current aggregated NAL unit and the preceding aggregated NAL unit in the same AP. The variable DON for the aggregated NAL unit is derived as equal to the DON of the preceding aggregated NAL unit in the same AP plus the value of the DOND field plus 1 modulo 65536.
いずれかの RTP ストリームで sprop-max-don-diff が 0 より大きい場合、AU は DOND/DONL フィールドで始まります。AP の最初の AU には、集約された NAL ユニットのデコード順序番号の 16 ビット値を指定する DONL フィールドが含まれています。集約された NAL ユニットの変数 DON は、DONL フィールドの値と等しいものとして導出されます。AP 内の後続のすべての AU には、同じ AP 内の現在の集約 NAL ユニットと前の集約 NAL ユニットのデコード順序番号値の差を指定する (8 ビット) DOND フィールドが含まれなければなりません (MUST)。集約 NAL ユニットの変数 DON は、同じ AP 内の先行する集約 NAL ユニットの DON に DOND フィールドの値を加え、65536 を法とする 1 を加えたものと等しくなるように導出されます。
When sprop-max-don-diff is equal to 0 for all the RTP streams, DOND/ DONL fields MUST NOT be present in an aggregation unit. The aggregation units MUST be stored in the aggregation packet so that the decoding order of the containing NAL units is preserved. This means that the first aggregation unit in the aggregation packet SHOULD contain the NAL unit that SHOULD be decoded first.
すべての RTP ストリームで sprop-max-don-diff が 0 に等しい場合、DOND/DONL フィールドは集約ユニット内に存在してはなりません (MUST NOT)。アグリゲーションユニットは、含まれる NAL ユニットのデコード順序が保存されるように、アグリゲーションパケットに格納されなければなりません (MUST)。これは、集約パケット内の最初の集約ユニットには、最初にデコードされる必要がある NAL ユニットが含まれるべきである (SHOULD) ことを意味します。
If sprop-v3c-tile-id-pres is equal to 2 and the AU NAL unit header type is in range 0-35 inclusive, the 16-bit v3c-tile-id field MUST be present in the aggregation unit after the conditional DOND/DONL field; otherwise, the v3c-tile-id field MUST NOT be present in the aggregation unit.
sprop-v3c-tile-id-pres が 2 に等しく、AU NAL ユニット ヘッダー タイプが 0 ～ 35 の範囲にある場合、16 ビットの v3c-tile-id フィールドが条件付き DOND/DONL フィールドの後の集約ユニットに存在しなければなりません (MUST)。それ以外の場合、v3c-tile-id フィールドは集約ユニットに存在してはなりません (MUST NOT)。
The conditional fields of the aggregation unit are followed by a 16-bit NALU size field, which provides the size of the NAL unit (in bytes) in the aggregation unit. The remainder of the data in the aggregation unit SHOULD contain the NAL unit (including the unmodified NAL unit header).
集約ユニットの条件フィールドの後には、集約ユニット内の NAL ユニットのサイズ (バイト単位) を提供する 16 ビットの NALU サイズ フィールドが続きます。アグリゲーションユニット内の残りのデータには、NAL ユニット（未変更の NAL ユニットヘッダーを含む）が含まれる必要があります（SHOULD）。
FUs are introduced to enable fragmenting a single NAL unit into multiple RTP packets, possibly without co-operation or knowledge of the 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).
FU は、エンコーダの協力や知識がなくても、単一の 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. Aggregation packets MUST NOT be fragmented. FUs MUST NOT be nested; i.e., an FU MUST NOT contain a subset of another FU. The RTP header timestamp of an RTP packet carrying an FU is set to the NALU-time of the fragmented NAL unit.
NAL ユニットがフラグメント化されて FU 内で伝送される場合、それはフラグメント化された NAL ユニットと呼ばれます。集約パケットは断片化してはなりません (MUST NOT)。FU をネストしてはなりません。つまり、FU には別の FU のサブセットが含まれてはなりません (MUST NOT)。FU を搬送する RTP パケットの RTP ヘッダー タイムスタンプは、フラグメント化された NAL ユニットの NALU 時間に設定されます。
An FU consists of an RTP payload header with NUT equal to 57, an 8-bit FU header, a conditional 16-bit DONL field, a conditional 16-bit v3c-tile-id field, and an FU payload. The structure of an FU is illustrated below in Figure 7.
FU は、NUT が 57 に等しい RTP ペイロード ヘッダー、8 ビット FU ヘッダー、条件付き 16 ビット DONL フィールド、条件付き 16 ビット v3c-tile-id フィールド、および FU ペイロードで構成されます。FU の構造を以下の図 7 に示します。
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 payload header (NUT=57) | FU header | DONL (cond) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| DONL (cond) | v3c-tile-id (cond) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Fragmentation Unit
図 7: 断片化ユニット
The fields in the RTP payload header are set as follows. The NUT field MUST be equal to 57. The rest of the fields MUST be equal to the fragmented NAL unit.
RTP ペイロード ヘッダーのフィールドは次のように設定されます。NUT フィールドは 57 に等しくなければなりません。残りのフィールドはフラグメント化された NAL ユニットに等しくなければなりません。
The presence of the "OPTIONAL RTP padding" is indicated by the padding (P) bit in the RTP header. As defined in [RFC3550], the last octet of the padding contains a count of how many padding octets should be ignored, including itself.
「オプションの RTP パディング」の存在は、RTP ヘッダーのパディング (P) ビットによって示されます。[RFC3550] で定義されているように、パディングの最後のオクテットには、それ自体を含め、無視する必要があるパディング オクテットの数が含まれます。
The FU header consists of an S bit, an E bit, and a 6-bit fragmentation unit type (FUT) field. The structure of FU header is illustrated in Figure 8.
FU ヘッダーは、S ビット、E ビット、および 6 ビットのフラグメンテーション ユニット タイプ (FUT) フィールドで構成されます。FU ヘッダーの構造を図 8 に示します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|E| FUT |
+-+-+-----------+
Figure 8: Fragmentation Unit Header
図 8: 断片化ユニットのヘッダー
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.
1 に設定されると、S ビットはフラグメント化された NAL ユニットの開始を示します。つまり、FU ペイロードの最初のバイトは、フラグメント化された NAL ユニットのペイロードの最初のバイトでもあります。FU ペイロードが断片化された NAL ユニット ペイロードの先頭ではない場合、S ビットは 0 に設定しなければなりません (MUST)。
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.
1 に設定されると、E ビットはフラグメント化された NAL ユニットの終わりを示します。つまり、ペイロードの最後のバイトはフラグメント化された NAL ユニットの最後のバイトでもあります。FU ペイロードがフラグメント化された NAL ユニットの最後のフラグメントではない場合、E ビットは 0 に設定しなければなりません (MUST)。
The field FUT MUST be equal to the nal_unit_type of the fragmented NAL unit.
フィールド FUT は、フラグメント化された NAL ユニットの nal_unit_type と等しくなければなりません。
A non-fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the Start bit and End bit MUST NOT both be set to 1 in the same FU header.
非フラグメント化 NAL ユニットを 1 つの FU で送信してはなりません (MUST NOT)。つまり、同じ FU ヘッダー内で開始ビットと終了ビットの両方を 1 に設定してはなりません (MUST NOT)。
The DONL field, when present, specifies the value of the 16-bit decoding order number of the fragmented NAL unit. If sprop-max-don-diff is greater than 0 for any of the RTP streams and the S bit is equal to 1, the DONL field MUST be present in the FU, and the variable DON for the fragmented NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams, or the S bit is equal to 0), the DONL field MUST NOT be present in the FU.
DONL フィールドが存在する場合、フラグメント化された NAL ユニットの 16 ビットのデコード順序番号の値を指定します。いずれかの RTP ストリームで sprop-max-don-diff が 0 より大きく、S ビットが 1 に等しい場合、DONL フィールドが FU に存在しなければならず、フラグメント化された NAL ユニットの変数 DON は DONL フィールドの値と等しいものとして導出されます。それ以外の場合 (すべての RTP ストリームで sprop-max-don-diff が 0 に等しい、または S ビットが 0 に等しい)、DONL フィールドは FU に存在してはなりません (MUST NOT)。
The v3c-tile-id field, when present, specifies the 16-bit tile identifier for the fragmented NAL unit. If sprop-v3c-tile-id-pres is equal to 1, FUT is in range 0-35, and the S bit is equal to 1, the v3c-tile-id field MUST be present after the conditional DONL field. Otherwise, the v3c-tile-id field MUST NOT be present.
v3c-tile-id フィールドが存在する場合、フラグメント化された NAL ユニットの 16 ビット タイル識別子を指定します。sprop-v3c-tile-id-pres が 1 に等しく、FUT が 0 ～ 35 の範囲にあり、S ビットが 1 に等しい場合、v3c-tile-id フィールドは条件付き DONL フィールドの後に存在しなければなりません (MUST)。それ以外の場合、v3c-tile-id フィールドは存在してはなりません (MUST NOT)。
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.
FU ペイロードは、断片化された NAL ユニットのペイロードのフラグメントで構成されているため、S ビットが 1 に等しい FU で始まり、E ビットが 1 に等しい FU で終わる連続する FU の FU ペイロードが連続的に連結される場合、断片化された NAL ユニットのペイロードを再構築できます。
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, NLI, and TID fields of the RTP payload headers of the FUs and the FUT field of the FU header. An FU payload MUST NOT be empty.
フラグメント化された NAL ユニットの NAL ユニット ヘッダーは、そのままでは FU ペイロードに含まれません。むしろ、フラグメント化された NAL ユニットの NAL ユニット ヘッダーの情報は、FU の RTP ペイロード ヘッダーの F、NLI、および TID フィールド、および FU ヘッダーの FUT フィールドで伝えられます。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 ユニットに対応する送信順序で後続のすべての断片化ユニットを破棄すべきです(SHOULD)。
This example illustrates how a fragmentation unit may be used to divide one NAL unit into two RTP packets. Figure 9 depicts the structure of the first packet with the first part of the fragmented NAL unit.
この例は、フラグメンテーション ユニットを使用して 1 つの NAL ユニットを 2 つの RTP パケットに分割する方法を示しています。図 9 は、フラグメント化された 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP payload header (NUT=57) |1|0| FUT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: First Packet of Fragmented NAL Unit
図 9: 断片化された NAL ユニットの最初のパケット
Figure 10 depicts the structure of the second packet with the rest of the fragmented NAL unit.
図 10 は、フラグメント化された NAL ユニットの残りを含む 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP payload header (NUT=57) |0|1| FUT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Second Packet of Fragmented NAL Unit
図 10: 断片化された NAL ユニットの 2 番目のパケット
For each atlas NAL unit, the variable AbsDon is derived, representing the decoding order number that is indicative of the NAL unit decoding order. Let NAL unit n be the n-th NAL unit in transmission order within an RTP stream.
アトラス NAL ユニットごとに、NAL ユニットのデコード順序を示すデコード順序番号を表す変数 AbsDon が導出されます。NAL ユニット n を、RTP ストリーム内の送信順序で n 番目の NAL ユニットとする。
If sprop-max-don-diff is equal to 0 for all the RTP streams carrying the atlas bitstream, AbsDon[n], the value of AbsDon for NAL unit n, is derived as equal to n.
アトラス ビットストリームを伝送するすべての RTP ストリームについて sprop-max-don-diff が 0 に等しい場合、NAL ユニット n の AbsDon の値である AbsDon[n] は、n に等しいものとして導出されます。
Otherwise (sprop-max-don-diff is greater than 0 for any of the RTP streams), AbsDon[n] is derived as follows, where DON[n] is the value of the variable DON for NAL unit n:
それ以外の場合 (どの RTP ストリームでも sprop-max-don-diff が 0 より大きい場合)、AbsDon[n] は次のように導出されます。ここで、DON[n] は NAL ユニット n の変数 DON の値です。
If (n == 0)
AbsDon[n] = DON[0]
Else
If (DON[n] == DON[n-1])
AbsDon[n] = AbsDon[n-1]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] < 32768)
AbsDon[n] = AbsDon[n-1] + DON[n] - DON[n-1]
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] >= 32768)
AbsDon[n] = AbsDon[n-1] + 65536 - DON[n-1] + DON[n]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] >= 32768)
AbsDon[n] = AbsDon[n-1] - (DON[n-1] + 65536 - DON[n])
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] < 32768)
AbsDon[n] = AbsDon[n-1] - (DON[n-1] - DON[n])
For any two NAL units m and n, the following applies:
任意の 2 つの NAL ユニット m および n には、以下が適用されます。
* AbsDon[n] greater than AbsDon[m] indicates that NAL unit n follows NAL unit m in NAL unit decoding order.
* AbsDon[n] が AbsDon[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.
* AbsDon[n] が AbsDon[m] と等しい場合、2 つの NAL ユニットの NAL ユニット復号順序はどちらの順序でも構いません。
* AbsDon[n] less than AbsDon[m] indicates that NAL unit n precedes NAL unit m in decoding order.
* AbDon[and] が AbDon[m] より小さい場合は、NAL ユニット n がデコード順序で NAL ユニット m よりも前であることを示します。
The following packetization rules apply for V3C atlas data:
次のパケット化ルールが V3C アトラス データに適用されます。
* If sprop-max-don-diff is greater than 0 for any of the RTP streams, the transmission order of NAL units carried in the RTP stream MAY be different than the NAL unit decoding order and the NAL unit output order. Otherwise (sprop-max-don-diff is equal to 0 for all the RTP streams), the transmission order of NAL units carried in the RTP stream MUST be the same as the NAL unit decoding order.
* いずれかの RTP ストリームの sprop-max-don-diff が 0 より大きい場合、RTP ストリームで伝送される NAL ユニットの送信順序は、NAL ユニットのデコード順序および NAL ユニットの出力順序と異なっていてもよい(MAY)。それ以外の場合（sprop-max-don-diff がすべての RTP ストリームで 0 に等しい）、RTP ストリームで伝送される NAL ユニットの送信順序は、NAL ユニットのデコード順序と同じでなければなりません（MUST）。
* 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-ACL NAL units such as access unit delimiters, parameter sets, or SEI NAL units are typically small and can often be aggregated with ACL NAL units without violating MTU size constraints.
* 小さなサイズの NAL ユニットは、小さな NAL ユニットの不必要なパケット化オーバーヘッドを避けるために、1 つ以上の他の NAL ユニットと一緒に集約パケットにカプセル化されるべきです(SHOULD)。たとえば、アクセス ユニット デリミタ、パラメータ セット、SEI NAL ユニットなどの非 ACL NAL ユニットは通常小さく、多くの場合、MTU サイズの制約に違反することなく ACL NAL ユニットと集約できます。
* Each non-ACL NAL unit SHOULD, when possible, from an MTU size perspective, be encapsulated in an aggregation packet together with its associated ACL NAL unit, as typically a non-ACL NAL unit would be meaningless without the associated ACL NAL unit being available.
* MTU サイズの観点から、可能であれば、各非 ACL NAL ユニットは、関連する ACL NAL ユニットとともに集約パケット内にカプセル化されるべきです（SHOULD）。これは、一般に、関連する ACL NAL ユニットが利用可能でなければ、非 ACL NAL ユニットは意味がありません。
* For carrying exactly one NAL unit in an RTP packet, a single NAL unit packet (Section 5.4.2) MUST be used.
* RTP パケットでちょうど 1 つの NAL ユニットを伝送するには、単一の NAL ユニット パケット (セクション 5.4.2) を使用しなければなりません (MUST)。
The general concept behind de-packetization is to get the NAL units out of the RTP packets in an RTP stream and all RTP streams the RTP stream depends on, if any, and pass them to the decoder in the NAL unit decoding order.
デパケット化の背後にある一般的な概念は、RTP ストリーム内の RTP パケットと、RTP ストリームが依存するすべての RTP ストリーム (存在する場合) から NAL ユニットを取得し、NAL ユニットのデコード順序でデコーダに渡すことです。
The de-packetization process is implementation dependent. Therefore, the following de-packetization rules SHOULD be taken as an example.
パケット化解除プロセスは実装に依存します。したがって、次のパケット化解除ルールを例として取り上げる必要があります。
* 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 55 inclusive may be passed to the decoder. NAL-unit-like structures with NAL unit type values in the range of 56 to 63 inclusive MUST NOT be passed to the decoder.
* 0 ～ 55 の範囲の NAL ユニット タイプ値を持つ NAL ユニットをデコーダに渡すことができます。56 から 63 までの範囲の NAL ユニット タイプ値を持つ NAL ユニットのような構造をデコーダに渡してはなりません (MUST NOT)。
* When sprop-max-don-diff is equal to 0 for the received RTP stream, the NAL units carried in the RTP stream MAY be directly passed to the decoder in their transmission order, which is identical to their decoding order.
* 受信した RTP ストリームの sprop-max-don-diff が 0 に等しい場合、RTP ストリームで運ばれる NAL ユニットは、デコード順序と同じ送信順序でデコーダに直接渡されてもよい(MAY)。
* When sprop-max-don-diff is greater than 0 for any of the received RTP streams, the received NAL units need to be arranged into decoding order before handing them over to the decoder.
* 受信した RTP ストリームのいずれかで sprop-max-don-diff が 0 より大きい場合、受信した NAL ユニットをデコーダに渡す前にデコード順序に並べる必要があります。
* For further de-packetization examples, the reader is referred to Section 6 of [RFC7798].
* さらなるパケット化解除の例については、[RFC7798] のセクション 6 を参照してください。
Regarding the packetization of V3C video component data, the respective RTP video payload specification(s) define how packetization and de-packetization should be handled.
V3C ビデオ コンポーネント データのパケット化に関しては、それぞれの RTP ビデオ ペイロード仕様で、パケット化とパケット解除がどのように処理されるべきかを定義しています。
This section specifies the optional parameters. A mapping of the parameters into the Session Description Protocol (SDP) [RFC8866] is also provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use SDP.
このセクションでは、オプションのパラメータを指定します。SDP を使用するアプリケーションには、セッション記述プロトコル (SDP) [RFC8866] へのパラメータのマッピングも提供されます。SDP を使用しない制御プロトコルで使用するために、同等のパラメータを別の場所で定義することもできます。
The receiver MUST ignore any parameter unspecified in this section.
受信者は、このセクションで指定されていないパラメータを無視しなければなりません (MUST)。
See Section 10.1 for information related to media type registration.
メディア タイプの登録に関する情報については、セクション 10.1 を参照してください。
sprop-v3c-parameter-set:
sprop-v3c-パラメータセット:
sprop-v3c-parameter-set provides V3C parameter set bytes as defined in [ISO.IEC.23090-5]. The value contains a base64-encoded [RFC4648] representation of the v3c_parameter_set() syntax element.
sprop-v3c-parameter-set は、[ISO.IEC.23090-5] で定義されている V3C パラメータ セット バイトを提供します。値には、v3c_parameter_set() 構文要素の Base64 エンコードされた [RFC4648] 表現が含まれます。
sprop-v3c-unit-header:
sprop-v3c-ユニットヘッダー:
sprop-v3c-unit-header provides bytes corresponding to a V3C unit header as defined in [ISO.IEC.23090-5]. The value contains a base64-encoded [RFC4648] representation of the 4 bytes of V3C unit header. V3C unit header indicates the details of which V3C component the media corresponds to.
sprop-v3c-unit-header は、[ISO.IEC.23090-5] で定義されている V3C ユニット ヘッダーに対応するバイトを提供します。値には、V3C ユニット ヘッダーの 4 バイトの Base64 エンコードされた [RFC4648] 表現が含まれます。V3C ユニット ヘッダーは、メディアがどの V3C コンポーネントに対応するかの詳細を示します。
sprop-v3c-unit-header contains the same information as sprop-v3c-unit-type, sprop-v3c-vps-id, sprop-v3c-atlas-id, sprop-v3c-attr-idx, sprop-v3c-attr-part-idx, sprop-v3c-map-idx, and sprop-v3c-aux-video-flag combined. To avoid the potential of signaling conflicting information, the separate parameters MUST NOT be present when sprop-v3c-unit-header is present.
sprop-v3c-unit-header には、sprop-v3c-unit-type、sprop-v3c-vps-id、sprop-v3c-atlas-id、sprop-v3c-attr-idx、sprop-v3c-attr-part-idx、sprop-v3c-map-idx、および sprop-v3c-aux-video-flag を組み合わせたものと同じ情報が含まれています。競合する情報をシグナリングする可能性を回避するために、sprop-v3c-unit-header が存在する場合は、個別のパラメーターを存在させてはなりません (MUST NOT)。
sprop-v3c-unit-type:
sprop-v3c-unit-type:
sprop-v3c-unit-type provides a V3C unit type value corresponding to vuh_unit_type defined in [ISO.IEC.23090-5], i.e., defines a V3C sub-bitstream type such as geometry, occupancy, atlas data, or attribute.
sprop-v3c-unit-type は、[ISO.IEC.23090-5] で定義されている vuh_unit_type に対応する V3C ユニット タイプ値を提供します。つまり、ジオメトリ、占有、アトラス データ、または属性などの V3C サブビットストリーム タイプを定義します。
When sprop-v3c-unit-header is present, sprop-v3c-unit-type MUST NOT be present. When present, the value of sprop-v3c-unit-type SHALL be in the range of 1 to 31 inclusive.
sprop-v3c-unit-header が存在する場合、sprop-v3c-unit-type は存在してはなりません (MUST NOT)。存在する場合、sprop-v3c-unit-type の値は 1 ～ 31 の範囲内である必要があります (SHALL)。
sprop-v3c-vps-id:
sprop-v3c-vps-id:
sprop-v3c-vps-id provides a value corresponding to active vuh_v3c_parameter_set_id defined in [ISO.IEC.23090-5], i.e., defines the value of the active V3C parameter set id.
sprop-v3c-vps-id は、[ISO.IEC.23090-5] で定義されているアクティブな vuh_v3c_parameter_set_id に対応する値を提供します。つまり、アクティブな V3C パラメータ セット ID の値を定義します。
When sprop-v3c-unit-header is present, sprop-v3c-vps-id MUST NOT be present. When present, the value of sprop-v3c-vps-id SHALL be in the range of 0 to 15 inclusive.
sprop-v3c-unit-header が存在する場合、sprop-v3c-vps-id は存在してはなりません (MUST NOT)。存在する場合、sprop-v3c-vps-id の値は 0 ～ 15 の範囲内であるものとします (SHALL)。
sprop-v3c-atlas-id:
sprop-v3c-atlas-id:
sprop-v3c-atlas-id provides a value corresponding to vuh_atlas_id defined in [ISO.IEC.23090-5]. When a V3C bitstream consists of multiple atlases, this parameter indicates the atlas id for the media component.
sprop-v3c-atlas-id は、[ISO.IEC.23090-5] で定義されている vuh_atlas_id に対応する値を提供します。V3C ビットストリームが複数のアトラスで構成されている場合、このパラメータはメディア コンポーネントのアトラス ID を示します。
When sprop-v3c-unit-header is present, sprop-v3c-atlas-id MUST NOT be present. When present, the value of sprop-v3c-atlas-id SHALL be in the range of 0 to 63 inclusive.
sprop-v3c-unit-header が存在する場合、sprop-v3c-atlas-id は存在してはなりません (MUST NOT)。存在する場合、sprop-v3c-atlas-id の値は 0 ～ 63 の範囲内であるものとします (SHALL)。
sprop-v3c-attr-idx:
sprop-v3c-attr-idx:
sprop-v3c-attr-idx provides a value corresponding to vuh_attribute_index defined in [ISO.IEC.23090-5]. An attribute in V3C determines a feature of a reconstructed volumetric primitive; for example, this could be texture (color), transparency, reflectance, or normal. The attribute index defines which type of attribute the media corresponds to.
sprop-v3c-attr-idx は、[ISO.IEC.23090-5] で定義されている vuh_attribute_index に対応する値を提供します。V3C の属性は、再構築された体積プリミティブの特徴を決定します。たとえば、これはテクスチャ (色)、透明度、反射率、法線などです。属性インデックスは、メディアがどのタイプの属性に対応するかを定義します。
When sprop-v3c-unit-header is present, sprop-v3c-attr-idx MUST NOT be present. When present, the value of sprop-v3c-attr-idx SHALL be in the range of 0 to 127 inclusive.
sprop-v3c-unit-header が存在する場合、sprop-v3c-attr-idx は存在してはなりません。sprop-v3c-attr-idx が存在する場合、その値は 0 ～ 127 の範囲内であるものとします (SHALL)。
sprop-v3c-attr-part-idx:
sprop-v3c-attr-part-idx:
sprop-v3c-attr-part-idx provides a value corresponding to vuh_attribute_partition_index defined in [ISO.IEC.23090-5]. In V3C, an attribute can be partitioned into multiple components. This may for example be useful, when an attribute consists of four dimensions but the video codec only supports coding three channels of data.
sprop-v3c-attr-part-idx は、[ISO.IEC.23090-5] で定義されている vuh_attribute_partition_index に対応する値を提供します。V3C では、属性を複数のコンポーネントに分割できます。これは、たとえば、属性が 4 つの次元で構成されているが、ビデオ コーデックが 3 チャネルのデータのコーディングのみをサポートしている場合に便利です。
When sprop-v3c-unit-header is present, sprop-v3c-attr-part-idx MUST NOT be present. When present, the value of sprop-v3c-attr-part-idx SHALL be in the range of 0 to 31 inclusive.
sprop-v3c-unit-header が存在する場合、sprop-v3c-attr-part-idx は存在してはなりません。存在する場合、sprop-v3c-attr-part-idx の値は 0 ～ 31 の範囲内である必要があります (SHALL)。
sprop-v3c-map-idx:
sprop-v3c-map-idx:
sprop-v3c-map-idx provides a value corresponding to vuh_map_index defined in [ISO.IEC.23090-5]. Maps in V3C allow storing multiple layers of projected volumetric data.
sprop-v3c-map-idx は、[ISO.IEC.23090-5] で定義されている vuh_map_index に対応する値を提供します。V3C のマップでは、投影された体積データの複数のレイヤーを保存できます。
When sprop-v3c-unit-header is present, sprop-v3c-map-idx MUST NOT be present. When present, the value of sprop-v3c-map-idx SHALL be in the range of 0 to 15 inclusive.
sprop-v3c-unit-header が存在する場合、sprop-v3c-map-idx は存在してはなりません (MUST NOT)。存在する場合、sprop-v3c-map-idx の値は 0 ～ 15 の範囲内であるものとします (SHALL)。
sprop-v3c-aux-video-flag:
sprop-v3c-aux-video-flag:
sprop-v3c-aux-video-flag provides a value corresponding to vuh_auxiliary_video_flag defined in [ISO.IEC.23090-5]. Auxiliary video in V3C can be used to pack volumetric data directly in a video frame without projecting it into a 2D plane first.
sprop-v3c-aux-video-flag は、[ISO.IEC.23090-5] で定義されている vuh_auxiliary_video_flag に対応する値を提供します。V3C の補助ビデオを使用すると、最初に 2D 平面に投影することなく、ボリューム データをビデオ フレームに直接パックすることができます。
When sprop-v3c-unit-header is present, sprop-v3c-aux-video-flag MUST NOT be present. When present, the value of sprop-v3c-aux-video-flag SHALL be either 0 or 1.
sprop-v3c-unit-header が存在する場合、sprop-v3c-aux-video-flag は存在してはなりません。sprop-v3c-aux-video-flag が存在する場合、その値は 0 または 1 でなければなりません (SHALL)。
sprop-v3c-tile-id:
sprop-v3c-tile-id:
sprop-v3c-tile-id indicates that the RTP stream contains only portion of the tiles in an atlas. The value of sprop-v3c-tile-id contains a comma-separated (',') list of integer values, which indicate the tile ids that are present in the corresponding RTP stream.
sprop-v3c-tile-id は、RTP ストリームにアトラスのタイルの一部のみが含まれていることを示します。sprop-v3c-tile-id の値には、対応する RTP ストリームに存在するタイル ID を示す整数値のカンマ区切り (',') リストが含まれます。
When sprop-v3c-tile-id is not present, the RTP stream is expected to contain all tiles or only consist of a single tile.
sprop-v3c-tile-id が存在しない場合、RTP ストリームにはすべてのタイルが含まれるか、単一のタイルのみで構成されることが期待されます。
sprop-v3c-tile-id-pres:
sprop-v3c-tile-id-pres:
sprop-v3c-tile-id-pres indicates that the RTP packets contain v3c-tile-id field.
sprop-v3c-tile-id-pres は、RTP パケットに v3c-tile-id フィールドが含まれていることを示します。
When present, the value of sprop-v3c-tile-id-pres SHALL be either 0 or 1. When not present, the default value of sprop-v3c-tile-id-pres is 0.
存在する場合、sprop-v3c-tile-id-pres の値は 0 または 1 でなければなりません。存在しない場合、sprop-v3c-tile-id-pres のデフォルト値は 0 です。
sprop-v3c-atlas-data:
sprop-v3c-atlas-data:
sprop-v3c-atlas-data MAY be used to convey any atlas data NAL units of the V3C atlas sub-bitstream for out-of-band transmission. The value contains a comma-separated (',') list of base64-encoded [RFC4648] representations of the atlas NAL units as specified in [ISO.IEC.23090-5].
sprop-v3c-atlas-data は、帯域外送信用の V3C アトラス サブビットストリームのアトラス データ NAL ユニットを伝達するために使用できます (MAY)。値には、[ISO.IEC.23090-5] で指定されているアトラス NAL ユニットの Base64 エンコードされた [RFC4648] 表現のカンマ区切り (',') リストが含まれます。
When present, the atlas NAL units stored in the sprop-v3c-atlas-data shall be applied for duration of the entire stream until an in-band atlas NAL unit with the same NAL unit type overrides it.
sprop-v3c-atlas-data に保存されているアトラス NAL ユニットが存在する場合、同じ NAL ユニット タイプを持つ帯域内アトラス NAL ユニットがオーバーライドするまで、ストリーム全体の期間適用されます。
sprop-v3c-common-atlas-data:
sprop-v3c-common-atlas-data:
sprop-v3c-common-atlas-data MAY be used to convey common atlas data NAL units of the V3C common atlas sub-bitstream for out-of-band transmission. The value contains a comma-separated (',') list of base64-encoded [RFC4648] representations of the common atlas NAL units (i.e., NAL_CASPS and NAL_CAF_IDR) as specified in [ISO.IEC.23090-5].
sprop-v3c-common-atlas-data は、帯域外送信用の V3C 共通アトラス サブビットストリームの共通アトラス データ NAL ユニットを伝達するために使用できます (MAY)。値には、[ISO.IEC.23090-5] で指定されている共通アトラス NAL ユニット (つまり、NAL_CASPS および NAL_CAF_IDR) の Base64 エンコードされた [RFC4648] 表現のカンマ区切り (',') リストが含まれます。
When present, the common atlas NAL units stored in the sprop-v3c-common-atlas-data shall be applied for duration of the entire stream until an in-band common atlas NAL unit with the same NAL unit type overrides it.
sprop-v3c-common-atlas-data に保存されている共通アトラス NAL ユニットが存在する場合、その NAL ユニットは、同じ NAL ユニット タイプを持つ帯域内共通アトラス NAL ユニットによってオーバーライドされるまで、ストリーム全体の期間適用されます。
sprop-v3c-sei:
sprop-v3c-sei:
sprop-v3c-sei MAY be used to convey SEI NAL units of V3C atlas and common atlas sub-bitstreams for out-of-band transmission. The value is a comma-separated (',') list of base64-encoded [RFC4648] representations of SEI NAL units (i.e., NAL_PREFIX_NSEI and NAL_SUFFIX_NSEI, NAL_PREFIX_ESEI, NAL_SUFFIX_ESEI) as specified in [ISO.IEC.23090-5].
sprop-v3c-sei は、帯域外送信用の V3C アトラスの SEI NAL ユニットおよび共通アトラス サブビットストリームを伝達するために使用できます (MAY)。値は、[ISO.IEC.23090-5] で指定されている SEI NAL ユニット (つまり、NAL_PREFIX_NSEI および NAL_SUFFIX_NSEI、NAL_PREFIX_ESEI、NAL_SUFFIX_ESEI) の Base64 エンコードされた [RFC4648] 表現のコンマ区切り (',') リストです。
When present, the SEI NAL units stored in the sprop-v3c-sei shall be applied for duration of the entire stream until an in-band SEI NAL unit with the same SEI payload type overrides it.
sprop-v3c-sei に格納されている SEI NAL ユニットが存在する場合、その SEI NAL ユニットは、同じ SEI ペイロード タイプを持つ帯域内 SEI NAL ユニットによってオーバーライドされるまで、ストリーム全体の期間適用されます。
v3c-ptl-level-idc:
v3c-ptl-レベル-idc:
v3c-ptl-level-idc provides a value corresponding to ptl_level_idc defined in [ISO.IEC.23090-5]. The value of v3c-ptl-level-idc indicates the level to which the V3C bitstream conforms.
v3c-ptl-level-idc は、[ISO.IEC.23090-5] で定義されている ptl_level_idc に対応する値を提供します。v3c-ptl-level-idc の値は、V3C ビットストリームが準拠するレベルを示します。
When present, the value of v3c-ptl-level-idc SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-level-idc SHALL be in the range of 0 to 255 inclusive.
v3c-ptl-level-idc の値が存在する場合、その値は sprop-v3c-parameter-set 内の対応する値と競合してはなりません。v3c-ptl-level-idc の値は 0 ～ 255 の範囲内である必要があります (SHALL)。
v3c-ptl-tier-flag:
v3c-ptl-tier-flag:
v3c-ptl-tier-flag provides a value corresponding to ptl_tier_flag defined in [ISO.IEC.23090-5]. The value of v3c-ptl-tier-flag indicates the tier context necessary to interpret the value of v3c-ptl-level-idc.
v3c-ptl-tier-flag は、[ISO.IEC.23090-5] で定義されている ptl_tier_flag に対応する値を提供します。v3c-ptl-tier-flag の値は、v3c-ptl-level-idc の値を解釈するために必要な層コンテキストを示します。
When present, the value of v3c-ptl-tier-flag SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-tier-flag SHALL be either 0 or 1.
v3c-ptl-tier-flag が存在する場合、その値は sprop-v3c-parameter-set 内の対応する値と競合してはなりません。v3c-ptl-tier-flag の値は 0 または 1 でなければなりません。
v3c-ptl-codec-idc:
v3c-ptl-コーデック-idc:
v3c-ptl-codec-idc provides a value corresponding to ptl_profile_codec_group_idc defined in [ISO.IEC.23090-5]. The value of v3c-ptl-codec-idc indicates the codec group profile component to which the V3C bitstream conforms.
v3c-ptl-codec-idc は、[ISO.IEC.23090-5] で定義されている ptl_profile_codec_group_idc に対応する値を提供します。v3c-ptl-codec-idc の値は、V3C ビットストリームが準拠するコーデック グループ プロファイル コンポーネントを示します。
When present, the value of v3c-ptl-codec-idc SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-codec-idc SHALL be in the range of 0 to 127 inclusive.
v3c-ptl-codec-idc の値が存在する場合、sprop-v3c-parameter-set の対応する値と競合してはなりません。v3c-ptl-codec-idc の値は 0 ～ 127 の範囲内である必要があります (SHALL)。
v3c-ptl-toolset-idc:
v3c-ptl-ツールセット-idc:
v3c-ptl-toolset-idc provides a value corresponding to ptl_profile_toolset_idc defined in [ISO.IEC.23090-5]. The value of v3c-ptl-toolset-idc indicates the toolset combination profile component to which the V3C bitstream conforms.
v3c-ptl-toolset-idc は、[ISO.IEC.23090-5] で定義されている ptl_profile_toolset_idc に対応する値を提供します。v3c-ptl-toolset-idc の値は、V3C ビットストリームが準拠するツールセット組み合わせプロファイル コンポーネントを示します。
When present, the value of v3c-ptl-toolset-idc SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-toolset-idc SHALL be in the range of 0 to 255 inclusive.
v3c-ptl-toolset-idc の値が存在する場合、sprop-v3c-parameter-set の対応する値と競合してはなりません。v3c-ptl-toolset-idc の値は 0 ～ 255 の範囲内である必要があります (SHALL)。
v3c-ptl-rec-idc:
v3c-ptl-rec-idc:
v3c-ptl-rec-idc provides a value corresponding to ptl_profile_reconstruction_idc as defined in [ISO.IEC.23090-5]. The value of v3c-ptl-rec-idc indicates the reconstruction profile component to which the V3C bitstream is recommended to conform.
v3c-ptl-rec-idc は、[ISO.IEC.23090-5] で定義されている ptl_profile_reconstruction_idc に対応する値を提供します。v3c-ptl-rec-idc の値は、V3C ビットストリームが準拠することが推奨される再構成プロファイル コンポーネントを示します。
When present, the value of v3c-ptl-rec-idc SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-rec-idc SHALL be in the range of 0 to 255 inclusive.
v3c-ptl-rec-idc の値が存在する場合、sprop-v3c-parameter-set の対応する値と競合してはなりません。v3c-ptl-rec-idc の値は 0 ～ 255 の範囲内でなければなりません (SHALL)。
sprop-max-don-diff:
sprop-max-don-diff:
If the transmission order of NAL units in the RTP stream(s) is the same as the decoding and NAL unit output order, this parameter must be equal to 0.
RTP ストリーム内の NAL ユニットの送信順序がデコードおよび NAL ユニットの出力順序と同じである場合、このパラメータは 0 に等しくなければなりません。
Otherwise, if the decoding order of the NAL units of the RTP stream(s) is the same as the NAL unit transmission order but not the same as NAL unit output order, the value of this parameter MUST be equal to 1.
それ以外の場合、RTP ストリームの NAL ユニットのデコード順序が NAL ユニットの送信順序と同じであるが、NAL ユニットの出力順序と同じではない場合、このパラメータの値は 1 に等しくなければなりません (MUST)。
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 に等しいと推定されます。
+============+========+================================+===========+
| Parameter |Required| V3C Syntax Counterpart | ISO/IEC |
| | | | 23090-5 |
| | | | Section |
| | | | Reference |
+============+========+================================+===========+
| sprop-v3c- |YES | v3c_parameter_set() | 8.3.4.1 |
| parameter- | | | |
| set | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | v3c_unit_header() | 8.3.2.2 |
| unit- | | | |
| header | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | vuh_unit_type | 8.4.2.2 |
| unit-type | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | vuh_v3c_parameter_set_id | 8.4.2.2 |
| vps-id | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | vuh_atlas_id | 8.4.2.2 |
| atlas-id | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | vuh_attribute_index | 8.4.2.2 |
| attr-idx | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | vuh_attribute_partition_index | 8.4.2.2 |
| attr-part- | | | |
| idx | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | vuh_map_index | 8.4.2.2 |
| map-idx | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | vuh_auxiliary_video_flag | 8.4.2.2 |
| aux-video- | | | |
| flag | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | - | - |
| tile-id | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | - | - |
| tile-id- | | | |
| pres | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | nal_unit() | 8.3.5.1 |
| atlas-data | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | nal_unit() | 8.3.5.1 |
| common- | | | |
| atlas-data | | | |
+------------+--------+--------------------------------+-----------+
| sprop-v3c- |NO | nal_unit() | 8.3.5.1 |
| sei | | | |
+------------+--------+--------------------------------+-----------+
| v3c-ptl- |NO | ptl_level_idc | 8.4.4.2 |
| level-idc | | | |
+------------+--------+--------------------------------+-----------+
| v3c-ptl- |NO | ptl_tier_flag | 8.4.4.2 |
| tier-flag | | | |
+------------+--------+--------------------------------+-----------+
| v3c-ptl- |NO | ptl_profile_codec_group_idc | 8.4.4.2 |
| codec-idc | | | |
+------------+--------+--------------------------------+-----------+
| v3c-ptl- |NO | ptl_profile_toolset_idc | 8.4.4.2 |
| toolset- | | | |
| idc | | | |
+------------+--------+--------------------------------+-----------+
| v3c-ptl- |NO | ptl_profile_reconstruction_idc | 8.4.4.2 |
| rec-idc | | | |
+------------+--------+--------------------------------+-----------+
| sprop-max- |NO | - | - |
| don-diff | | | |
+------------+--------+--------------------------------+-----------+
Table 2: Mapping of Parameters to V3C Syntax
表 2: V3C 構文へのパラメーターのマッピング
Congestion control for RTP SHALL be used in accordance with RTP [RFC3550] and with any applicable RTP profile, e.g., AVP [RFC3551]. This section only applies for unicast streaming, leaving considerations for multicast streaming out of scope.
RTP の輻輳制御は、RTP [RFC3550] および適用可能な RTP プロファイル (AVP [RFC3551] など) に従って使用されるものとします (SHALL)。このセクションはユニキャスト ストリーミングにのみ適用され、マルチキャスト ストリーミングに関する考慮事項は範囲外となります。
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 that of the RTP flow (see Section 10 of [RFC3550]).
このペイロード形式のユーザーは、パケット損失率が許容範囲内であることを確認するために、パケット損失を監視する必要があります。同じネットワークパスを通過し、同じネットワーク条件を経験している TCP フローが、適切なタイムスケールで測定された、RTP フローの平均スループット以上の平均スループットを達成する場合、パケット損失は許容できると見なされます ([RFC3550] のセクション 10 を参照)。
This condition can be satisfied by implementing congestion-control mechanisms to adapt the transmission rate. A simple bitrate adaptation for congestion control can be achieved when real-time coding is used for V3C video components where quality parameters can be adaptively tuned. Video coding specifications MAY define further adaptation techniques.
この条件は、送信レートを調整する輻輳制御メカニズムを実装することで満たされます。品質パラメータを適応的に調整できる V3C ビデオ コンポーネントにリアルタイム コーディングを使用すると、輻輳制御のための簡単なビットレート適応を実現できます。ビデオコーディング仕様は、さらなる適応技術を定義してもよい(MAY)。
An alternative method is to arrange for a receiver to leave the session if the loss rate is unacceptably high, for example, using a Circuit Breaker [RFC8083] that defines criteria for when one the RTP flow must stop sending RTP Packet Streams.
別の方法は、損失率が許容できないほど高い場合に、受信者がセッションから離脱するように手配することです。たとえば、RTP フローが RTP パケット ストリームの送信をいつ停止する必要があるかの基準を定義するサーキット ブレーカー [RFC8083] を使用します。
As an example, both the sender and the receiver may have their own definition for an acceptable packet loss rate. In such a case, the receiver may decide to quit a stream when it finds the packet loss rate too high. Similarly, the sender may decide to drop a receiver when the reports it receives indicate packet loss rates that are too high from its perspective. These decisions can be made independently by either the receiver or the sender.
一例として、送信者と受信者の両方が、許容可能なパケット損失率について独自の定義を持っている場合があります。このような場合、受信側は、パケット損失率が高すぎると判断すると、ストリームの終了を決定する可能性があります。同様に、送信者は、受信したレポートがその観点から見て高すぎるパケット損失率を示している場合に、受信者をドロップすることを決定する可能性があります。これらの決定は、受信者または送信者のいずれかが独立して行うことができます。
As an example of a bitrate adaptation technique, a sender or a receiver may adapt bitrates of specific sub-streams. The adaptation should be done in a manner that considers the effects on the quality of the experience as a whole, keeping the subjective quality of experience as high as possible. In an implementation this could mean dropping less important sub-streams fully or reducing the bitrates of the most important sub-streams throughout the session.
ビットレート適応技術の一例として、送信者または受信者は特定のサブストリームのビットレートを適応させることができる。適応は、全体としての体験の質への影響を考慮し、主観的な体験の質を可能な限り高く保つ方法で行われるべきです。実装では、これは、重要性の低いサブストリームを完全に削除するか、セッション全体で最も重要なサブストリームのビットレートを下げることを意味します。
A new attribute "v3cfmtp" is defined for carrying V3C format media type parameters in the corresponding fields of SDP [RFC8866]. Grouping framework [RFC5888] is used to indicate which media lines (video and application) in the SDP constitute a V3C representation.
新しい属性「v3cfmtp」は、SDP [RFC8866] の対応するフィールドで V3C フォーマットのメディアタイプパラメータを運ぶために定義されています。グループ化フレームワーク [RFC5888] は、SDP 内のどのメディア ライン (ビデオとアプリケーション) が V3C 表現を構成するかを示すために使用されます。
This document defines a new attribute for SDP, intended to carry V3C-specific media format parameters. Its functionality is similar to "a=fmtp", with the exception that it SHALL be used without the fmt-token and that it can be used also on a session level. The attribute allows V3C-specific media format parameters to be associated with any media line in SDP. The detailed information on the new attribute (a=v3cfmtp) is provided in Section 10.2.
このドキュメントは、V3C 固有のメディア形式パラメータを運ぶことを目的とした SDP の新しい属性を定義します。その機能は「a=fmtp」と似ていますが、fmt トークンなしで使用する必要があることと、セッション レベルでも使用できる点が異なります。この属性により、V3C 固有のメディア フォーマット パラメータを SDP の任意のメディア ラインに関連付けることができます。新しい属性 (a=v3cfmtp) の詳細については、セクション 10.2 を参照してください。
The value of the v3cfmtp attribute is a byte-string, as defined in [RFC8866], which contains at least one V3C-specific media format parameter as a "parameter=value" pair as defined in this document. Multiple semicolon-separated V3C media "parameter=value" pairs can be stored in the byte-string to be conveyed by SDP and given unchanged to the media tool that will use this format. Whitespace in the byte-string is ignored.
v3cfmtp 属性の値は、[RFC8866] で定義されているバイト文字列であり、この文書で定義されている「parameter=value」ペアとして、少なくとも 1 つの V3C 固有のメディア形式パラメータが含まれています。セミコロンで区切られた複数の V3C メディアの「パラメータ=値」ペアをバイト文字列に保存して SDP によって伝達し、この形式を使用するメディア ツールに変更せずに渡すことができます。バイト文字列内の空白は無視されます。
An example of the usage of the new attribute is shown below. The first line describes session-level usage of the attribute, signaling a V3C parameter set. The second line describes a media-level attribute, signaling a V3C unit header and profile tier level flag for the associated media line.
新しい属性の使用例を以下に示します。最初の行は、属性のセッション レベルの使用法を記述し、V3C パラメータ セットを通知します。2 行目はメディア レベルの属性を記述し、関連するメディア ラインの V3C ユニット ヘッダーとプロファイル層レベル フラグを通知します。
a=v3cfmtp:sprop-v3c-parameter-set=AUH/AAAP/zwAAAAAACgIAtEAgQLAIAAUQ
BACWAM5QEDgQCAIAAAAABP8CzwAAAAAAAAAQAAAtAE/wLPAAAAAAAg=;
a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;v3c-ptl-tier-flag=1;
* The media name in the "m=" line of SDP MUST be application.
* SDP の「m=」行のメディア名は application でなければなりません。
* The encoding name in the "a=rtpmap" line of SDP MUST be v3c.
* SDP の「a=rtpmap」行のエンコーディング名は v3c でなければなりません。
* The clock rate in the "a=rtpmap" line MUST be 90000.
* 「a=rtpmap」行のクロックレートは90000でなければなりません。
* The OPTIONAL parameters sprop-v3c-atlas-data, sprop-v3c-common-atlas-data, sprop-v3c-sei, sprop-v3c-tile-id, sprop-v3c-tile-id-pres, when present, MUST be included in the "a=fmtp" line of SDP. This parameter is expressed as a media type string in the form of a semicolon-separated list of parameter=value pairs.
* オプションのパラメータ sprop-v3c-atlas-data、sprop-v3c-common-atlas-data、sprop-v3c-sei、sprop-v3c-tile-id、sprop-v3c-tile-id-pres が存在する場合、SDP の「a=fmtp」行に含める必要があります。このパラメータは、セミコロンで区切られたパラメータ=値のペアのリスト形式のメディア タイプ文字列として表現されます。
* The OPTIONAL parameters sprop-v3c-unit-header, sprop-v3c-unit-type, sprop-v3c-vps-id, sprop-v3c-atlas-id, sprop-v3c-attr-idx, sprop-v3c-attr-part-idx, sprop-v3c-map-idx, sprop-v3c-aux-video-flag, sprop-max-don-diff, sprop-v3c-parameter-set, v3c-ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, v3c-ptl-toolset-idc, and v3c-ptl-rec-idc, when present, MUST be included in the "a=v3cfmtp" line of SDP. This parameter is expressed as a media type string in the form of a semicolon-separated list of parameter=value pairs.
* オプションのパラメータ sprop-v3c-unit-header、sprop-v3c-unit-type、sprop-v3c-vps-id、sprop-v3c-atlas-id、sprop-v3c-attr-idx、sprop-v3c-attr-part-idx、sprop-v3c-map-idx、sprop-v3c-aux-video-flag、sprop-max-don-diff、sprop-v3c-parameter-set、v3c-ptl-level-idc、v3c-ptl-tier-flag、v3c-ptl-codec-idc、v3c-ptl-toolset-idc、および v3c-ptl-rec-idc が存在する場合は、SDP の「a=v3cfmtp」行に含める必要があります。このパラメータは、セミコロンで区切られたパラメータ=値のペアのリスト形式のメディア タイプ文字列として表現されます。
The OPTIONAL parameters, when present in the V3C atlas component media line format parameters attribute, specify values that are valid for the coded V3C sequence until a new value is received in-band. Some OPTIONAL parameters, like sprop-v3c-parameter-set or sprop-v3c-unit-header, can't be carried in-band in the atlas stream and thus may be considered static for the session. The carriage of V3C payload format parameters in "a=fmtp" and "a=v3cfmtp" attributes is separated by logical context, where "a=fmtp" consists of atlas level media format parameters and "a=v3cfmtp" contains V3C level media format parameters.
OPTIONAL パラメータは、V3C アトラス コンポーネントのメディア ライン フォーマット パラメータ属性に存在する場合、新しい値がインバンドで受信されるまで、コード化された V3C シーケンスに対して有効な値を指定します。sprop-v3c-parameter-set や sprop-v3c-unit-header などの一部の OPTIONAL パラメータは、アトラス ストリームの帯域内で伝送できないため、セッションに対して静的であると見なされる場合があります。「a=fmtp」および「a=v3cfmtp」属性の V3C ペイロード形式パラメータの記述は論理コンテキストによって分離されます。「a=fmtp」はアトラス レベルのメディア形式パラメータで構成され、「a=v3cfmtp」には V3C レベルのメディア形式パラメータが含まれます。
An example of media representation corresponding to atlas data component (V3C_AD), where static V3C parameter set and V3C unit header is carried out-of-band in SDP, is as follows:
アトラス データ コンポーネント (V3C_AD) に対応するメディア表現の例は次のとおりです。静的な V3C パラメーター セットと V3C ユニット ヘッダーは SDP の帯域外で実行されます。
m=application 49170 RTP/AVP 98
a=rtpmap:98 v3c/90000
a=fmtp:98 sprop-v3c-tile-id=0,1
a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;v3c-ptl-tier-flag=1;
sprop-v3c-parameter-set=AQD/AAAP/zwAAAAAADwIAQ5BwAAOADjgQAADkA==
* The media name in the "m=" line of SDP MUST be video.
* SDP の「m=」行のメディア名は video でなければなりません。
* The encoding name in the "a=rtpmap" line of SDP can be any video subtype, e.g., H.264, H.265, H.266, etc.
* SDP の「a=rtpmap」行のエンコーディング名には、H.264、H.265、H.266 などの任意のビデオ サブタイプを指定できます。
* The clock rate in the "a=rtpmap" line MUST be 90000.
* 「a=rtpmap」行のクロックレートは90000でなければなりません。
* The OPTIONAL parameters sprop-v3c-unit-header, sprop-v3c-unit-type, sprop-v3c-vps-id, sprop-v3c-atlas-id, sprop-v3c-attr-idx, sprop-v3c-attr-part-idx, sprop-v3c-map-idx, sprop-v3c-aux-video-flag, sprop-max-don-diff, sprop-v3c-parameter-set, sprop-v3c-atlas-data, sprop-v3c-common-atlas-data, sprop-v3c-sei, sprop-v3c-tile-id, sprop-v3c-tile-id-pres, v3c-ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, v3c-ptl-toolset-idc, and v3c-ptl-rec-idc, when present, MUST be included in the "a=v3cfmtp" line of SDP. This parameter is expressed as a media type string in the form of a semicolon-separated list of parameter=value pairs.
* オプションのパラメータ sprop-v3c-unit-header、sprop-v3c-unit-type、sprop-v3c-vps-id、sprop-v3c-atlas-id、sprop-v3c-attr-idx、sprop-v3c-attr-part-idx、sprop-v3c-map-idx、sprop-v3c-aux-video-flag、sprop-max-don-diff、sprop-v3c-parameter-set、sprop-v3c-atlas-data、sprop-v3c-common-atlas-data、sprop-v3c-sei、sprop-v3c-tile-id、sprop-v3c-tile-id-pres、v3c-ptl-level-idc、v3c-ptl-tier-flag、v3c-ptl-codec-idc、v3c-ptl-toolset-idc、および v3c-ptl-rec-idc が存在する場合は、SDP の「a=v3cfmtp」行に含める必要があります。このパラメータは、セミコロンで区切られたパラメータ=値のペアのリスト形式のメディア タイプ文字列として表現されます。
The OPTIONAL parameters, when present in the video media line V3C format parameters ("v3cfmtp") attribute, specify values that are considered static for the session.
OPTIONAL パラメータは、ビデオ メディア ラインの V3C 形式パラメータ (「v3cfmtp」) 属性に存在する場合、セッションに対して静的であるとみなされる値を指定します。
An example of media representation corresponding to occupancy video component (V3C_OVD) in SDP is as follows:
SDP の占有ビデオ コンポーネント (V3C_OVD) に対応するメディア表現の例は次のとおりです。
m=video 49170 RTP/AVP 99
a=rtpmap:99 H265/90000
a=fmtp:99 sprop-max-don-diff=0;
a=v3cfmtp:sprop-v3c-unit-header=EAAAAA==
Below is an example of media representation corresponding to packed video component (V3C_PVD), where the static V3C parameter set, atlas data, and common atlas data are carried out-of-band in SDP. The values are considered static for the session, as they can't be signaled in-band in the video stream.
以下は、パックされたビデオ コンポーネント (V3C_PVD) に対応するメディア表現の例です。ここでは、静的な V3C パラメーター セット、アトラス データ、および共通アトラス データが SDP の帯域外で実行されます。ビデオ ストリームの帯域内で信号を送ることができないため、値はセッションに対して静的であるとみなされます。
m=video 49170 RTP/AVP 99
a=rtpmap:99 H265/90000
a=v3cfmtp:sprop-v3c-unit-header=KAAAAA==;
sprop-v3c-parameter-set=AUH/AAAP/zwAAAAAACgIAtEAgQLAIAAUQBACWAM5Q
EDgQCAIAAAAABP8CzwAAAAAAAAAQAAAtAE/wLPAAAAAAAg=;
sprop-v3c-atlas-data=SAGAFAQBaKjuXgABQEKA,SgHmIA==,LgFoDOAFAABaAA
AAAAA+;
sprop-v3c-common-atlas-data=YAEHgFA=,YgEAMAAAC/B0qcvv/Dbr/pTvb8oq
fhC5JQVS9jn7kAQT/As9EFyrjRBcmxEQe+j5DuGbTT9mZmZAQAAAoA==
Different V3C components MAY be represented by their own respective RTP streams, whose payload formats are defined in the respective specifications. V3C atlas data RTP payload format is defined in this document, whereas the video component RTP payload formats are defined for example in [RFC6184] or [RFC7798]. A grouping tool, as defined in [RFC5888], is extended to indicate which media lines constitute a V3C representation. Further details on the new grouping type provided in Section 10.3.
異なる V3C コンポーネントは、それぞれの仕様でペイロード形式が定義されている、それぞれ独自の RTP ストリームで表すことができます (MAY)。V3C アトラス データの RTP ペイロード形式はこの文書で定義されますが、ビデオ コンポーネントの RTP ペイロード形式はたとえば [RFC6184] または [RFC7798] で定義されます。[RFC5888] で定義されているグループ化ツールは、どのメディア行が V3C 表現を構成するかを示すために拡張されています。新しいグループ化タイプの詳細については、セクション 10.3 を参照してください。
The group attribute with V3C type is provided to allow application to identify "m" lines that belong to the same V3C bitstream. Grouping type V3C MUST be used with the group attribute. The tokens that follow are mapped to 'mid'-values of individual media lines in the SDP.
V3C タイプのグループ属性は、アプリケーションが同じ V3C ビットストリームに属する「m」行を識別できるようにするために提供されます。グループ化タイプ V3C は、group 属性とともに使用する必要があります。後続のトークンは、SDP 内の個々のメディア行の「中間」値にマッピングされます。
a=group:V3C <tokens>
The following example shows an SDP including four media lines: three describing V3C video components (PT:96=occupancy, PT:97=geometry, and PT:98=attribute) and one describing a V3C atlas component (PT:100). All of these media lines are grouped under one V3C group. The V3C parameter set is provided via a session-level V3C media format parameter attribute.
次の例は、4 つのメディア ラインを含む SDP を示しています。3 つは V3C ビデオ コンポーネント (PT:96=占有、PT:97=ジオメトリ、PT:98=属性) を記述し、1 つは V3C アトラス コンポーネント (PT:100) を記述しています。これらのメディア ラインはすべて 1 つの V3C グループにグループ化されます。V3C パラメータ セットは、セッション レベルの V3C メディア フォーマット パラメータ属性を介して提供されます。
...
a=group:V3C 1 2 3 4
a=v3cfmtp:sprop-v3c-parameter-set=AQD/AAAP/zwAAAAAADwIAQ5BwAAOADjgQ
AADkA==
m=video 40000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=EAAAAA==
a=mid:1
m=video 40002 RTP/AVP 97
a=rtpmap:97 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=GAAAAA==
a=mid:2
m=video 40004 RTP/AVP 98
a=rtpmap:98 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=IAAAAA==
a=mid:3
m=application 40008 RTP/AVP 100
a=rtpmap:100 v3c/90000
a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;
a=mid:4
The example below describes how content with two atlases can be signaled as separate streams. The V3C parameter set is carried in a session-level V3C media format parameter attribute and common atlas data are carried as part of the media-level V3C media format parameter attribute corresponding to atlas zero. PT values 96, 97, 98, and 100 correspond to the occupancy, geometry, and attribute video components, as well as the atlas data component, for atlas zero. PT values 101, 102, 103, and 104 correspond to the respective components for atlas one.
以下の例では、2 つのアトラスを含むコンテンツを個別のストリームとして送信する方法を説明します。V3C パラメータ セットはセッション レベルの V3C メディア フォーマット パラメータ属性で伝送され、共通アトラス データはアトラス ゼロに対応するメディア レベルの V3C メディア フォーマット パラメータ属性の一部として伝送されます。PT 値 96、97、98、および 100 は、アトラス ゼロの占有、ジオメトリ、属性ビデオ コンポーネント、およびアトラス データ コンポーネントに対応します。PT 値 101、102、103、および 104 は、アトラス 1 のそれぞれのコンポーネントに対応します。
...
a=group:V3C 1 2 3 4 5 6 7 8
a=v3cfmtp:sprop-v3c-parameter-set=AAUH/AAAP/zwAAABAADwIAWhBwAAOADjg
QAADgAA8CAFoQcAADgA44EAAA6AkAgABRIA=;
m=video 40000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=EAAAAA==
a=mid:1
m=video 40002 RTP/AVP 97
a=rtpmap:97 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=GAAAAA==
a=mid:2
m=video 40004 RTP/AVP 98
a=rtpmap:98 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=IAAAAA==
a=mid:3
m=application 40008 RTP/AVP 100
a=rtpmap:100 v3c/90000
a=fmtp:100
sprop-v3c-common-atlas-data=YAEHgFA=,YgEAMAAAa+96Z5v6VP1D+P7LzRsb
WDJ/yz+ALzMZNfvCg2389Kjd+d6fZyM6QZBfhrDW3K0vaP2Rr8L+gLAq/ny3wAzs9
veiXEjjS67MfH+H4xV/RgW4fkl/YkINe/OsWCOBwPAVLACCf4FnogwYZKIME6oiD9
UCodqjLwCCf4FnogxqBiIMZNwiEBpJIduBUoCCf4FnogwOeSIMCaGiEA9VIdtGwwC
Cf4FnogvB+aILvWIiEBB6IdqobKfmZmZoCmZmefmZmZoCmZmefmZmZoCmZmefmZmZ
oCmZmdA=
a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;
a=mid:4
m=video 40010 RTP/AVP 101
a=rtpmap:101 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=EAIAAA==
a=mid:5
m=video 40012 RTP/AVP 102
a=rtpmap:102 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=GAIAAA==
a=mid:6
m=video 40014 RTP/AVP 103
a=rtpmap:103 H264/90000
a=v3cfmtp:sprop-v3c-unit-header=IAIAAA==
a=mid:7
m=application 40018 RTP/AVP 104
a=rtpmap:104 v3c/90000
a=v3cfmtp:sprop-v3c-unit-header=CAIAAA==
a=mid:8
This section describes the negotiation of unicast streaming using the offer/answer model as described in [RFC3264]. V3C-coded content consists of an atlas bitstream and one or more video coded bitstreams, together known as V3C components. Atlas and video bitstreams are represented as separate media lines in the SDP.
このセクションでは、[RFC3264] で説明されているオファー/アンサー モデルを使用したユニキャスト ストリーミングのネゴシエーションについて説明します。V3C でコード化されたコンテンツは、アトラス ビットストリームと 1 つ以上のビデオ コード化ビットストリームで構成され、これらは合わせて V3C コンポーネントと呼ばれます。アトラスとビデオのビットストリームは、SDP では別個のメディア ラインとして表されます。
During the session negotiation the offerer lists all V3C components available and informs the answerer which media lines SHOULD be consumed together. The answerer CAN select V3C components as suggested by the offerer, or select a subset of the V3C components by setting the port to zero for the undesired media lines in the answer. This allows the answerer to consume a subset of the V3C components in scenarios where it is fully or partially ignorant of the V3C coding scheme.
セッション ネゴシエーション中に、オファー側は利用可能なすべての V3C コンポーネントをリストし、どのメディア ラインを一緒に消費する必要があるかをアンサー側に通知します。回答者は、オファー者の提案に従って V3C コンポーネントを選択することも、回答内の望ましくないメディア行のポートを 0 に設定して V3C コンポーネントのサブセットを選択することもできます。これにより、回答者は、V3C コーディング スキームを完全または部分的に知らないシナリオで、V3C コンポーネントのサブセットを利用できるようになります。
The following limitations and rules pertaining to the V3C atlas component media configuration apply:
V3C アトラス コンポーネントのメディア構成に関連する次の制限とルールが適用されます。
* The parameters identifying the V3C atlas component media configuration is identified by v3c-ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, and v3c-ptl-toolset-idc. These media configuration parameters, except level-id, MUST be used symmetrically.
* V3C アトラス コンポーネントのメディア構成を識別するパラメーターは、v3c-ptl-level-idc、v3c-ptl-tier-flag、v3c-ptl-codec-idc、および v3c-ptl-toolset-idc によって識別されます。これらのメディア設定パラメータは、level-id を除き、対称的に使用しなければなりません (MUST)。
* Send only properties, identified by sprop-prefix, are considered declarative and SHOULD be omitted in the answers.
* sprop-prefix で識別される送信専用プロパティは宣言的とみなされ、回答では省略されるべきです(SHOULD)。
The answerer MUST structure its answer according to one of the following two options:
回答者は、次の 2 つのオプションのいずれかに従って回答を構成しなければなりません。
* 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 v3c-ptl-level-idc is changeable as long as the highest level indicated by the answer is not higher than that indicated by the offer, or
* すべての設定パラメータをメディア形式 (ペイロード タイプ) のオファーと同じ値で維持します。ただし、v3c-ptl-level-idc の値は、回答で示される最高レベルがオファーで示されるレベルより高くない限り変更可能です。または
* reject media line in which one or more of the parameter values are not supported by setting the port to zero in the answer.
* 応答でポートをゼロに設定することで、1 つ以上のパラメーター値がサポートされていないメディア行を拒否します。
The following limitations and rules pertaining to the V3C video component media configuration apply:
V3C ビデオ コンポーネントのメディア構成に関する次の制限とルールが適用されます。
* The parameters identifying a video-coded V3C component media configuration format are according to the respective RTP video payload specification.
* ビデオコード化された V3C コンポーネント メディア構成フォーマットを識別するパラメータは、それぞれの RTP ビデオ ペイロード仕様に従います。
The answerer MUST structure its answer according to one of the following two options:
回答者は、次の 2 つのオプションのいずれかに従って回答を構成しなければなりません。
* maintain all configuration parameters with the values remaining the same as in the offer for the media format (payload type), with the exceptions specified in the respective RTP video payload specification, or
* それぞれの RTP ビデオ ペイロード仕様で指定されている例外を除き、メディア フォーマット (ペイロード タイプ) のオファーと同じ値を維持したすべての構成パラメータを維持する、または
* reject the video coded V3C component media line completely when one or more of the parameter values are not supported by setting the port to zero in the answer.
* 1 つ以上のパラメーター値がサポートされていない場合、応答でポートを 0 に設定することで、ビデオ コード化された V3C コンポーネント メディア ラインを完全に拒否します。
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 ペイロード タイプ番号を応答でも使用する必要があります (SHOULD)。
Below is an example of an offer that only sends V3C content. This example contains video components as three different versions (H.264, H.265, and H.266). Further differences between the alternatives would be signaled as part of the media attribute parameters, as is the practice with regular video streams.
以下は、V3C コンテンツのみを送信するオファーの例です。この例には、3 つの異なるバージョン (H.264、H.265、および H.266) のビデオ コンポーネントが含まれています。通常のビデオ ストリームの場合と同様に、代替案間のさらなる違いは、メディア属性パラメータの一部として通知されます。
...
a=group:v3c 1 2 3 4
a=v3cfmtp:v3c-ptl-level-idc=60;
sprop-v3c-parameter-set=AQD/AAAP/zwAAAAAADwIAQ5BwAAOADjgQAADkA==
m=video 40000 RTP/AVP 96 97 98
a=rtpmap:96 H264/90000
a=rtpmap:97 H265/90000
a=rtpmap:98 H266/90000
a=v3cfmtp:sprop-v3c-unit-type=2;sprop-v3c-vps-id=0;
sprop-v3c-atlas-id=0
a=sendonly
a=mid:1
m=video 40002 RTP/AVP 99 100 101
a=rtpmap:99 H264/90000
a=rtpmap:100 H265/90000
a=rtpmap:101 H266/90000
a=v3cfmtp:sprop-v3c-unit-type=3;sprop-v3c-vps-id=0;
sprop-v3c-atlas-id=0
a=mid:2
a=sendonly
m=video 40004 RTP/AVP 102 103 104
a=rtpmap:102 H264/90000
a=rtpmap:103 H265/90000
a=rtpmap:104 H266/90000
a=v3cfmtp:sprop-v3c-unit-type=4;sprop-v3c-vps-id=0;
sprop-v3c-atlas-id=0
a=mid:3
a=sendonly
m=application 40006 RTP/AVP 105
a=rtpmap:105 v3c/90000
a=v3cfmtp:sprop-v3c-unit-type=1;sprop-v3c-vps-id=0;
sprop-v3c-atlas-id=0;
a=mid:4
a=sendonly
This is an example of an answer that only receives V3C data with the selected versions:
これは、選択したバージョンの V3C データのみを受信する回答の例です。
...
a=group:v3c 1 2 3 4
m=video 50000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=recvonly
a=mid:1
m=video 50002 RTP/AVP 100
a=rtpmap:100 H265/90000
a=recvonly
a=mid:2
m=video 50004 RTP/AVP 104
a=rtpmap:104 H266/90000
a=recvonly
a=mid:3
m=application 50006 RTP/AVP 105
a=rtpmap:105 v3c/90000
a=recvonly
a=mid:4
This is an example of an offer that allows bundling different V3C components into one stream, based on [RFC9143]:
これは、[RFC9143] に基づいて、さまざまな V3C コンポーネントを 1 つのストリームにバンドルできるオファーの例です。
...
a=group:BUNDLE 1 2 3 4
a=group:v3c 1 2 3 4
m=video 40000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=v3cfmtp:sprop-v3c-unit-type=2;sprop-v3c-vps-id=0;
sprop-v3c-atlas-id=0
a=mid:1
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 40002 RTP/AVP 97
a=rtpmap:97 H264/90000
a=v3cfmtp:sprop-v3c-unit-type=3;sprop-v3c-vps-id=0;
sprop-v3c-atlas-id=0;
a=mid:2
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 40004 RTP/AVP 98
a=rtpmap:98 H264/90000
a=v3cfmtp:sprop-v3c-unit-type=4;sprop-v3c-vps-id=0;
sprop-v3c-atlas-id=0
a=mid:3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=application 40006 RTP/AVP 99
a=rtpmap:99 v3c/90000
a=v3cfmtp:sprop-v3c-unit-type=1;sprop-v3c-vps-id=0;
sprop-v3c-atlas-id=0;
sprop-v3c-parameter-set=AQD/AAAP/zwAAAAAADwIAQ5BwAAOADjgQAADkA==
a=mid:4
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
This is an example of an answer that accepts the bundling of different V3C components:
これは、さまざまな V3C コンポーネントのバンドルを受け入れる回答の例です。
a=group:BUNDLE 1 2 3 4
a=group:v3c 1 2 3 4
m=video 50000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=mid:1
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 97
a=rtpmap:97 H264/90000
a=bundle-only
a=mid:2
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 98
a=rtpmap:98 H264/90000
a=bundle-only
a=mid:3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=application 0 RTP/AVP 99
a=rtpmap:99 v3c/90000
a=bundle-only
a=mid:4
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
For bitstreams being delivered over multicast, the following rules apply:
マルチキャスト経由で配信されるビットストリームには、次のルールが適用されます。
* The atlas V3C component media configuration is identified by v3c-ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, and v3c-ptl-toolset-idc. These atlas format configuration parameters MUST be used symmetrically; that is, the answerer MUST either maintain all configuration parameters or reject the media line, including any associated video coded V3C component media lines. This implies that v3c-ptl-level-idc for offer/answer in multicast is not changeable.
* アトラス V3C コンポーネントのメディア構成は、v3c-ptl-level-idc、v3c-ptl-tier-flag、v3c-ptl-codec-idc、および v3c-ptl-toolset-idc によって識別されます。これらのアトラス形式の設定パラメータは対称的に使用する必要があります。つまり、アンサー側は、すべての設定パラメータを維持するか、関連するビデオ コード化された V3C コンポーネント メディア ラインを含むメディア ラインを拒否する必要があります。これは、マルチキャストのオファー/アンサーの v3c-ptl-level-idc が変更できないことを意味します。
* The video-coded V3C component media configuration format is according to the respective RTP video payload specification.
* ビデオコーディングされた V3C コンポーネント メディア構成フォーマットは、それぞれの RTP ビデオ ペイロード仕様に従っています。
* To simplify the handling and matching of these configurations, the same RTP payload type number used in the offer MUST also be used in the answer.
* これらの設定の処理と照合を簡素化するために、オファーで使用されたのと同じ RTP ペイロード タイプ番号を応答でも使用しなければなりません (MUST)。
* Parameter sets received MUST be associated with the originating source and MUST only be used in decoding the incoming bitstream from the same source.
* 受信したパラメータセットは、発信元のソースに関連付けられなければならず、同じソースからの受信ビットストリームをデコードする場合にのみ使用されなければなりません。
When V3C content over RTP is offered with SDP in a declarative style, the parameters capable of indicating both bitstream properties as well as answerer capabilities are used to indicate only bitstream properties. For example, in this case, the parameters v3c-ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, v3c-ptl-toolset-idc, and v3c-ptl-rec-idc declare the values used by the bitstream, not the capabilities for receiving bitstreams.
RTP 上の V3C コンテンツが宣言型スタイルの SDP で提供される場合、ビットストリーム プロパティとアンサー機能の両方を示すことができるパラメータは、ビットストリーム プロパティのみを示すために使用されます。たとえば、この場合、パラメータ v3c-ptl-level-idc、v3c-ptl-tier-flag、v3c-ptl-codec-idc、v3c-ptl-toolset-idc、および v3c-ptl-rec-idc は、ビットストリームを受信する機能ではなく、ビットストリームによって使用される値を宣言します。
An answerer of the SDP is required to support all parameters and values of the parameters provided; otherwise, the answerer MUST reject or not participate in the session. It falls on the creator of the session to use values that are expected to be supported by the receiving application.
SDP のアンサー側は、提供されたすべてのパラメーターとパラメーターの値をサポートする必要があります。それ以外の場合、回答者はセッションを拒否するか、セッションに参加しなければなりません。受信側アプリケーションによってサポートされることが期待される値を使用するかどうかは、セッションの作成者の責任となります。
This document contains three IANA considerations: a new media type, a new SDP attribute, and a new grouping type.
この文書には、新しいメディア タイプ、新しい SDP 属性、新しいグループ化タイプという 3 つの IANA に関する考慮事項が含まれています。
IANA has registered the following media type in the "Media Types" registry.
IANA は、次のメディア タイプを「メディア タイプ」レジストリに登録しています。
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
v3c
v3c
Required parameters:
必須パラメータ:
sprop-v3c-parameter-set
sprop-v3c-パラメータセット
Optional parameters:
オプションのパラメータ:
sprop-v3c-unit-header, sprop-v3c-unit-type, sprop-v3c-vps-id, sprop-v3c-atlas-id, sprop-v3c-attr-idx, sprop-v3c-attr-part-idx, sprop-v3c-map-idx, sprop-v3c-aux-video-flag, sprop-v3c-tile-id, sprop-v3c-tile-id-pres, sprop-v3c-atlas-data, sprop-v3c-common-atlas-data, sprop-v3c-sei, v3c-ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, v3c-ptl-toolset-idc, v3c-ptl-rec-idc, and sprop-max-don-diff.
sprop-v3c-unit-header、sprop-v3c-unit-type、sprop-v3c-vps-id、sprop-v3c-atlas-id、sprop-v3c-attr-idx、sprop-v3c-attr-part-idx、sprop-v3c-map-idx、sprop-v3c-aux-video-flag、sprop-v3c-tile-id、sprop-v3c-tile-id-pres、sprop-v3c-atlas-data、sprop-v3c-common-atlas-data、sprop-v3c-sei、v3c-ptl-level-idc、v3c-ptl-tier-flag、v3c-ptl-codec-idc、v3c-ptl-toolset-idc、v3c-ptl-rec-idc、および sprop-max-don-diff。
Encoding considerations:
エンコーディングに関する考慮事項:
framed
額装された
Security considerations:
セキュリティに関する考慮事項:
See Section 11 of RFC 10034.
RFC 10034 のセクション 11 を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
該当なし
Published specification:
公開された仕様:
RFC 10034
RFC 10034
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Any application that relies on V3C-based media services over RTP.
RTP 経由の V3C ベースのメディア サービスに依存するアプリケーション。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
該当なし
Additional information:
追加情報：
N/A
該当なし
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
Lauri Ilola (lauri.ilola@nokia.com) or Lukasz Kondrad (lukasz.kondrad@nokia.com)
Lauri Ilola (lauri.ilola@nokia.com) または Lukasz Kondrad (lukasz.kondrad@nokia.com)
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
This media type depends on RTP framing and, hence, is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
このメディア タイプは RTP フレーミングに依存するため、RTP [RFC3550] を介した転送に対してのみ定義されています。現時点では、他のフレーミング プロトコル内のトランスポートは定義されていません。
Author:
著者：
See the Authors' Addresses section of RFC 10034.
RFC 10034 の「著者のアドレス」セクションを参照してください。
Change controller:
コントローラーを変更します:
IETF
IETF
IANA has registered the following SDP attribute in the "attribute-name (formerly 'att-field')" registry under the "Session Description Protocol (SDP) Parameters" registry group.
IANA は、「セッション記述プロトコル (SDP) パラメーター」レジストリ グループの「属性名 (以前の「att-field」)」レジストリに次の SDP 属性を登録しました。
Contact name:
連絡先名:
See the Authors' Addresses section of RFC 10034.
RFC 10034 の「著者のアドレス」セクションを参照してください。
Contact email address:
連絡先メールアドレス:
See the Authors' Addresses section of RFC 10034.
RFC 10034 の「著者のアドレス」セクションを参照してください。
Attribute name:
属性名:
v3cfmtp
v3cfmtp
Attribute syntax:
属性の構文:
v3cfmtp-value = byte-string
Notes:
注:
* The V3C format parameters are V3C media type parameters and need to reflect their syntax.
* V3C 形式パラメータは V3C メディア タイプ パラメータであり、その構文を反映する必要があります。
* "byte-string" is as defined in [RFC8866].
* 「バイト文字列」は[RFC8866]で定義されているとおりです。
* ABNF grammar is as defined in [RFC5234].
* ABNF 文法は [RFC5234] で定義されているとおりです。
Attribute semantics:
属性のセマンティクス:
"v3cfmtp-value" is a byte-string, as defined in [RFC8866], that contains at least one V3C-specific media format parameter as a "parameter=value" pair, as defined in this document. Multiple semicolon-separated V3C media "parameter=value" pairs can be stored in the byte-string to be conveyed by SDP and given unchanged to the media tool that will use this format. Whitespace in the byte-string is ignored.
「v3cfmtp-value」は、[RFC8866] で定義されているバイト文字列で、この文書で定義されているように、「parameter=value」ペアとして少なくとも 1 つの V3C 固有のメディア形式パラメータを含みます。セミコロンで区切られた複数の V3C メディアの「パラメータ=値」ペアをバイト文字列に保存して SDP によって伝達し、この形式を使用するメディア ツールに変更せずに渡すことができます。バイト文字列内の空白は無視されます。
Attribute value:
属性値:
v3cfmtp-value
v3cfmtp 値
Usage level:
使用レベル:
session, media
セッション、メディア
Charset dependent:
文字セットに依存:
No
いいえ
Purpose:
目的：
This attribute allows parameters that are specific to a V3C format to be conveyed in a way that SDP does not have to understand them. It allows associating V3C-specific parameters with a session or with any media line. Parameters signaled as part of session-level attributes take effect when conflicting parameters are signaled as media-level attributes.
この属性により、V3C フォーマットに固有のパラメータを、SDP が理解する必要のない方法で伝達できるようになります。これにより、V3C 固有のパラメータをセッションまたは任意のメディア ラインに関連付けることができます。セッション レベルの属性の一部として通知されたパラメータは、競合するパラメータがメディア レベルの属性として通知されたときに有効になります。
O/A procedures:
O/A手順:
The v3cfmtp attribute can be present both in offers and answers.
v3cfmtp 属性は、オファーと回答の両方に存在できます。
Mux Category:
マルチプレクサ カテゴリ:
NORMAL
普通
Reference:
参照：
RFC 10034
RFC 10034
+===========+==========+================+==============+===========+
| Type | SDP Name | Usage Level | Mux Category | Reference |
+===========+==========+================+==============+===========+
| attribute | v3cfmtp | session, media | NORMAL | RFC 10034 |
+-----------+----------+----------------+--------------+-----------+
Table 3: The attribute-name (formerly 'att-field') Registry
表 3: 属性名 (以前の「att-field」) レジストリ
The SDP Group attribute is extended to establish relationships between sub-streams of a V3C representation. IANA has registered the following in the "Semantics for the 'group' SDP Attribute" registry under the "Session Description Protocol (SDP) Parameters" registry group:
SDP グループ属性は、V3C 表現のサブストリーム間の関係を確立するために拡張されています。IANA は、「セッション記述プロトコル (SDP) パラメーター」レジストリ グループの「'グループ' SDP 属性のセマンティクス」レジストリに以下を登録しました。
+==============+=======+==============+===========+
| Semantics | Token | Mux Category | Reference |
+==============+=======+==============+===========+
| V3C grouping | V3C | NORMAL | RFC 10034 |
+--------------+-------+--------------+-----------+
Table 4: The Semantics for the 'group' SDP Attribute Registry
表 4: 「グループ」SDP 属性レジストリのセマンティクス
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 [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lies with anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in [RFC7201].
この仕様で定義されたペイロード形式を使用する RTP パケットは、RTP 仕様 [RFC3550]、および RTP/AVP [RFC3551]、RTP/AVPF [RFC4585]、RTP/SAVP [RFC3711]、または RTP/SAVPF [RFC5124] などの該当する RTP プロファイルで説明されているセキュリティ上の考慮事項の対象となります。しかし、[RFC7202] で説明されているように、RTP 全般の機密性、完全性、ソースの信頼性などの基本的なセキュリティ目標を満たすためにどのようなソリューションが使用されるかを議論したり義務付けたりするのは、RTP ペイロード形式の責任ではありません。この責任は、アプリケーションで RTP を使用するすべての人にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは [RFC7201] で見つけることができます。
This document does not mandate a specific security mechanism. Instead, applications are responsible for selecting mechanisms that follow current best practices for confidentiality, integrity, and source authentication and that reflect the evolving security landscape beyond what is covered in [RFC7201]. For modern best practices, applications can consider the following options:
この文書は、特定のセキュリティ メカニズムを義務付けるものではありません。代わりに、アプリケーションは、機密性、完全性、およびソース認証に関する現在のベスト プラクティスに従い、[RFC7201] でカバーされている内容を超えて進化するセキュリティ状況を反映するメカニズムを選択する責任があります。最新のベスト プラクティスとして、アプリケーションは次のオプションを検討できます。
(D)TLS-based protection:
(D) TLS ベースの保護:
For guidance on using TLS 1.3 and DTLS, applications should refer to [BCP195], which provides up-to-date recommendations.
TLS 1.3 および DTLS の使用に関するガイダンスについては、アプリケーションは最新の推奨事項を提供する [BCP195] を参照する必要があります。
IPsec-based protection:
IPsec ベースの保護:
Relevant and current protocol specifications include [RFC4303] (ESP) and [RFC7296] (IKEv2).
関連する現在のプロトコル仕様には、[RFC4303] (ESP) および [RFC7296] (IKEv2) が含まれます。
The rest of the Security Considerations section discusses the security impacting properties of the payload format itself.
「セキュリティに関する考慮事項」セクションの残りの部分では、ペイロード形式自体のプロパティに影響を与えるセキュリティについて説明します。
A V3C session can consist of multiple sub-streams carried over different RTP streams. Security considerations such as source authentication SHOULD be applied to all its constituent sub-streams. All receivers of V3C data SHOULD exercise source caution and only receive data from senders that they can trust. Furthermore, this RTP payload format supports multiple RTP streams for different components necessary to produce the decoded output; thus, it depends on all RTP streams and signaling components, e.g., SDP and RTCP, being authentic to what the sender intended.
V3C セッションは、異なる RTP ストリーム上で伝送される複数のサブストリームで構成されます。ソース認証などのセキュリティに関する考慮事項は、その構成要素であるすべてのサブストリームに適用されるべきです(SHOULD)。V3C データのすべての受信者は、ソースに注意を払い、信頼できる送信者からのみデータを受信する必要があります。さらに、この RTP ペイロード形式は、デコードされた出力を生成するために必要なさまざまなコンポーネントの複数の RTP ストリームをサポートします。したがって、すべての RTP ストリームとシグナリング コンポーネント (SDP や RTCP など) が送信者の意図したものに対して本物であるかどうかに依存します。
This RTP payload format and its media decoder do not exhibit significant non-uniformity in the receiver-side computational complexity for packet processing and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Furthermore, this payload format contains no active content.
この RTP ペイロード形式とそのメディア デコーダは、パケット処理のための受信側の計算複雑性に大きな不均一性を示さないため、病理学的データの受信によるサービス妨害の脅威を引き起こす可能性は低いです。さらに、このペイロード形式にはアクティブ コンテンツが含まれません。
Components of a system using this media type SHALL NOT construct RTP payloads that contain executable content. The implementer of the RTP payload format SHALL guarantee that the received content is properly de-packetized and fed to a V3C standard compliant decoder. What the receiver does with the decoded bitstream is unspecified.
このメディアタイプを使用するシステムのコンポーネントは、実行可能なコンテンツを含む RTP ペイロードを構築してはなりません (SHALL NOT)。RTP ペイロード形式の実装者は、受信したコンテンツが適切にパケット化解除され、V3C 標準に準拠したデコーダに供給されることを保証するものとします (SHALL)。受信機がデコードされたビットストリームに対して何を行うかは未指定です。
[ISO.IEC.23090-5]
ISO/IEC, "Information technology -- Coded representation
of immersive media -- Part 5: Visual volumetric video-
based coding (V3C) and video-based point cloud compression
(V-PCC)", ISO/IEC 23090-5:2026, 2026,
<https://www.iso.org/standard/91546.html>.
[ISO.IEC.23090-12]
ISO/IEC, "Information technology -- Coded representation
of immersive media -- Part 12: MPEG Immersive video
(MIV)", ISO/IEC 23090-12:2025, 2025,
<https://www.iso.org/standard/87643.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>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, July 2002,
<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>.
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010,
<https://www.rfc-editor.org/info/rfc5888>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>.
[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>.
[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>.
[RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 9143,
DOI 10.17487/RFC9143, February 2022,
<https://www.rfc-editor.org/info/rfc9143>.
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[ISO.IEC.14496-10]
ISO/IEC, "Information technology - Coding of audio-visual
objects - Part 10: Advanced video coding", ISO/
IEC 14496-10:2025, 2025,
<https://www.iso.org/standard/87574.html>.
[ISO.IEC.14496-12]
ISO/IEC, "Information technology - Coding of audio-visual
objects - Part 12: ISO base media file format", ISO/
IEC 14496-12:2026, 2026,
<https://www.iso.org/standard/85596.html>.
[ISO.IEC.23008-2]
ISO/IEC, "Information technology - High efficiency coding
and media delivery in heterogeneous environments - Part 2:
High efficiency video coding", ISO/IEC 23008-2:2025, 2025,
<https://www.iso.org/standard/90502.html>.
[ISO.IEC.23009-1]
ISO/IEC, "Information technology - Dynamic adaptive
streaming over HTTP (DASH) - Part 1: Media presentation
description and segment formats", ISO/IEC 23009-1:2022,
2022, <https://www.iso.org/standard/83314.html>.
[ISO.IEC.23090-3]
ISO/IEC, "Information technology - Coded representation of
immersive media - Part 3: Versatile video coding", ISO/
IEC 23090-3:2024, 2024,
<https://www.iso.org/standard/86516.html>.
[ISO.IEC.23090-10]
ISO/IEC, "Information technology - Coded representation of
immersive media - Part 10: Carriage of visual volumetric
video-based coding data", ISO/IEC 23090-10:2022, 2022,
<https://www.iso.org/standard/78991.html>.
[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>.
[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>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[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>.
Lauri Ilola
Nokia Technologies
Hatanpaeaen valtatie 30
FI-33100 Tampere
Finland
Email: lauri.ilola@nokia.com
Lukasz Kondrad
Nokia Technologies
Werinherstrasse 91
D-81541 Munich
Germany
Email: lukasz.kondrad@nokia.com