Nokia Technologies

Hatanpaeaen valtatie 30 Tampere 33100 Finland lauri.ilola@nokia.com

Nokia Technologies

Werinherstrasse 91 Munich D-81541 Germany lukasz.kondrad@nokia.com

WIT avtcore volumetric video V-PCC MIV point cloud immersive 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.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () 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.

Table of Contents

• .  Introduction
• .  Conventions
• .  Definitions and Abbreviations
  • .  Abbreviations
  • .  Definitions
    • .  General
    • .  Definitions from the V3C Specification
• .  Media Format Description
  • .  Overview of the V3C Codec (Informative)
  • .  V3C Parameter Set (Informative)
  • .  V3C Atlas and Video Components (Informative)
    • .  General
    • .  Atlas NAL Units
  • .  Systems and Transport Interfaces (Informative)
• .  V3C Atlas RTP Payload Format
  • .  General
  • .  RTP Header
  • .  RTP Payload Header
  • .  Payload Structures
    • .  General
    • .  Single NAL Unit Packet
    • .  Aggregation Packet
    • .  Fragmentation Unit
    • .  Example of Fragmentation Unit (Informative)
  • .  Decoding Order Number
• .  Packetization and De-Packetization Rules
• .  Payload Format Parameters
  • .  Media Type Registration
  • .  Required Parameters Definition
  • .  Definitions of Optional Parameters
  • .  Mapping of Parameters to V3C Syntax
• .  Congestion Control Considerations
• .  Session Description Protocol
  • .  V3C Format Parameters "v3cfmtp" Attribute
  • .  Mapping of Payload Type Parameters to SDP
    • .  For V3C Atlas Components
    • .  For V3C Video Components
  • .  Grouping Framework
  • .  Offer and Answer Considerations
    • .  Unicast
    • .  Multicast
  • .  Declarative SDP Considerations
• . IANA Considerations
  • .  V3C Media Type Registration
  • .  V3C Format Parameters SDP Attribute
  • .  V3C Grouping Type Extension
• . Security Considerations
• . References
  • .  Normative References
  • .  Informative References
• Authors' Addresses

Introduction 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 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) , and immersive video with depth (MPEG Immersive Video (MIV)) . 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 International Standard 23008-2 (High Efficiency Video Coding, HEVC/H.265) , or ISO/IEC International Standard 23090-3 (Versatile Video Coding, VVC/H.266) . The atlas data is coded with mechanisms specified in . 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 , , and .

Conventions 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 when, and only when, they appear in all capitals, as shown here. All fields defined in this specification related to RTP payload structures SHALL be considered in network order.

Definitions and Abbreviations

Abbreviations

ACL:

atlas coding layer

AP:

aggregation packet

AU:

aggregation unit

CVS:

coded V3C sequence

DON:

decoding order number

DOND:

decoding order number difference

DONL:

decoding order number least significant bits

IRAP:

intra random access point

MTU:

maximum transmission unit

NAL:

network abstraction layer

NALU:

NAL unit

RBSP:

raw byte sequence payload

V3C:

visual volumetric video-based coding

VPS:

V3C parameter set

Definitions

General This document uses the definitions of . lists relevant definitions from for convenience.

Definitions from the V3C Specification

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.

atlas bitstream:

Sequence of bits that forms the representation of atlas frames and associated data forming one or more coded atlas sequences.

atlas coding layer NAL unit:

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.

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.

attribute:

Scalar or vector property optionally associated with each point in a volumetric frame such as color, reflectance, surface normal, timestamps, material ID, etc.

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.

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.

coded V3C sequence:

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.

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.

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.

tile:

Independently decodable rectangular region of an atlas frame.

V3C atlas sub-bitstream:

Extracted sub-bitstream from the V3C bitstream containing a whole or portion of an atlas bitstream.

V3C video sub-bitstream:

Extracted sub-bitstream from the V3C bitstream containing a whole or portion of a video bitstream.

V3C component:

Atlas, occupancy, geometry, or attribute of a particular type that is associated with a V3C volumetric content representation.

V3C parameter set:

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.

volumetric frame:

Set of 3D points specified by their Cartesian coordinates and zero or more corresponding sets of attributes at a particular time instance.

Media Format Description

Overview of the V3C Codec (Informative) 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. 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. 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. 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. 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 ) 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 .

Example of a V3C Bitstream +-------------------+------------------+-------------------+ | V3C Unit(V3C_VPS) | V3C Unit(V3C_AD) | V3C Unit(V3C_GVD) | +-------------------+------------------++-----------------++--- | V3C Unit(V3C_OVD) | V3C Unit(V3C_AVD) | V3C Unit(V3C_AD)| ... +-------------------+-------------------+-----------------+----

V3C Parameter Set (Informative) This document specifies an encapsulation of V3C atlas data. Aspects related to signaling of V3C parameter set, defined in , 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. of this document specifies how a V3C parameter set can be signaled using the Session Description Protocol (SDP). 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 Atlas and Video Components (Informative)

General 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 . 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. 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 . The four-byte V3C unit header syntax and semantics are copied below as defined in , but the syntax is subject to change. Implementations should always refer to the latest specification of . 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_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 . For convenience, the mapping table from vuh_unit_type values to semantics is shown in . V3C Unit Type Semantics

vuh_unit_type	Identifier	V3C unit type	Description
0	V3C_VPS	V3C parameter set	V3C level parameters
1	V3C_AD	Atlas data	Atlas information
2	V3C_OVD	Occupancy video data	Occupancy information
3	V3C_GVD	Geometry video data	Geometry information
4	V3C_AVD	Attribute video data	Attribute information
5	V3C_PVD	Packed video data	Packing information
6	V3C_CAD	Common atlas data	Information that is common for atlases in a CVS. Specified in ISO/IEC 23090-12.
7...31	V3C_RSVD	Reserved	-

vuh_v3c_parameter_set_id specifies the value of vps_v3c_parameter_set_id for the active V3C VPS. vuh_atlas_id specifies the ID of the atlas that corresponds to the current V3C unit. vuh_attribute_index indicates the index of the attribute data carried in the Attribute Video Data unit. vuh_attribute_partition_index indicates the index of the attribute dimension group carried in the attribute video data unit. 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_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.

Atlas NAL Units The atlas NAL unit (nal_unit(NumBytesInNalUnit)) is a byte-aligned syntax structure defined by 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 . 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_unit_type indicates the type of the RBSP data structure contained in the NAL unit. 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_temporal_id_plus1 minus 1 indicates a temporal identifier for the NAL unit.

Systems and Transport Interfaces (Informative) In addition to releasing specifications on V3C applications and , 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 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. One of such derived specifications is , which defines how V3C content can be stored in a file and streamed over DASH . 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.

V3C Atlas RTP Payload Format

General 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.

RTP Header The format of the RTP header is specified in and replicated in for convenience. V3C RTP payload format uses the fields of the RTP header in a manner consistent with . Unless contextualized below, the meaning of the fields depicted in is the same as in .

RTP Header 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 | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Marker bit (M): 1 bit

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.

Payload Type (PT): 7 bits

The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here. The assignment of a payload type MUST be performed either through the profile used or in a dynamic way.

Timestamp: 32 bits

The RTP timestamp is set to the sampling timestamp of the content. A 90 kHz clock rate MUST be used.

If the NAL unit has no timing properties of its own (e.g., parameter set and 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 ) is included. Receivers MUST use the RTP timestamp for the display process, even when the bitstream contains atlas frame timing SEI messages as specified in . The remaining RTP header fields are used as specified in .

RTP Payload Header 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 , irrespective of the type of the payload structure. For convenience, the structure of RTP payload header is shown in .

RTP Payload Header 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| NUT | NLI | TID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

F:

The nal_forbidden_zero_bit as specified in is equal to 0. A value equal to 1 indicates that the payload may contain errors or syntax violations. 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).

NUT:

The nal_unit_type as specified in 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.

NLI:

The nal_layer_id as specified in 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.

TID:

The nal_temporal_id_plus1 minus 1 as specified in defines a temporal identifier for the NAL unit. The value of nal_temporal_id_plus1 MUST NOT be equal to 0.

Payload Structures

General 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. The three different payload structures are as follows:

Single NAL Unit Packet:

Contains a single NAL unit in the payload. This payload structure is specified in .

Aggregation Packet:

Contains multiple NAL units in a single RTP payload. This payload structure is specified in .

Fragmentation Unit (FU):

Contains a subset of a single NAL unit. This payload structure is specified in .

Single NAL Unit Packet 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 . The structure of the single NAL unit packet is shown in .

Single NAL Unit Packet 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The RTP payload header MUST be an exact copy of the NAL unit header of the contained NAL unit. 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. 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. 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 . 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. The presence of the "OPTIONAL RTP padding" is indicated by the padding (P) bit in the RTP header. As defined in , the last octet of the padding contains a count of how many padding octets should be ignored, including itself.

Aggregation Packet 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. 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 . 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 .

Aggregation Packet (AP) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP payload header (NUT=56) | v3c-tile-id (cond) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Two or more aggregation units | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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. 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. 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. The presence of the "OPTIONAL RTP padding" is indicated by the padding (P) bit in the RTP header. As defined in the last octet of the padding contains a count of how many padding octets should be ignored, including itself. 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 .

Aggregation Unit (AU) 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 | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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. 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. 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. 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).

Fragmentation Unit 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). 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. 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 .

Fragmentation Unit 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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. The presence of the "OPTIONAL RTP padding" is indicated by the padding (P) bit in the RTP header. As defined in , the last octet of the padding contains a count of how many padding octets should be ignored, including itself. 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 .

Fragmentation Unit Header 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|E| FUT | +-+-+-----------+

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. 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. The field FUT MUST be equal to the nal_unit_type of the fragmented NAL unit. 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. 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. 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. The FU payload consists of fragments of the payload of the fragmented NAL unit so that if the FU payloads of consecutive FUs, starting with an FU with the S bit equal to 1 and ending with an FU with the E bit equal to 1, are sequentially concatenated, the payload of the fragmented NAL unit can be reconstructed. The NAL unit header of the fragmented NAL unit is not included as such in the FU payload, but rather the information of the NAL unit header of the fragmented NAL unit is conveyed in the F, 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. 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.

Example of Fragmentation Unit (Informative) This example illustrates how a fragmentation unit may be used to divide one NAL unit into two RTP packets. depicts the structure of the first packet with the first part of the fragmented NAL unit.

First Packet of Fragmented NAL Unit 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 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

depicts the structure of the second packet with the rest of the fragmented NAL unit.

Second Packet of Fragmented NAL Unit 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Decoding Order Number 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. 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. 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: 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:

• AbsDon[n] greater than AbsDon[m] indicates that NAL unit n follows NAL unit m in NAL unit decoding order.
• 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] less than AbsDon[m] indicates that NAL unit n precedes NAL unit m in decoding order.

Packetization and De-Packetization Rules The following packetization rules apply for V3C atlas data:

• 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.
• 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.
• 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.
• For carrying exactly one NAL unit in an RTP packet, a single NAL unit packet () MUST be used.

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. 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.
• 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.
• 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.
• 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.
• For further de-packetization examples, the reader is referred to .

Regarding the packetization of V3C video component data, the respective RTP video payload specification(s) define how packetization and de-packetization should be handled.

Payload Format Parameters This section specifies the optional parameters. A mapping of the parameters into the Session Description Protocol (SDP) is also provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use SDP. The receiver MUST ignore any parameter unspecified in this section.

Media Type Registration See for information related to media type registration.

Required Parameters Definition

sprop-v3c-parameter-set:

sprop-v3c-parameter-set provides V3C parameter set bytes as defined in . The value contains a base64-encoded representation of the v3c_parameter_set() syntax element.

Definitions of Optional Parameters

sprop-v3c-unit-header:

sprop-v3c-unit-header provides bytes corresponding to a V3C unit header as defined in . The value contains a base64-encoded 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 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-type:

sprop-v3c-unit-type provides a V3C unit type value corresponding to vuh_unit_type defined in , i.e., defines a V3C sub-bitstream type such as geometry, occupancy, atlas data, or attribute. 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-vps-id:

sprop-v3c-vps-id provides a value corresponding to active vuh_v3c_parameter_set_id defined in , i.e., defines the value of the active V3C parameter set 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-atlas-id:

sprop-v3c-atlas-id provides a value corresponding to vuh_atlas_id defined in . When a V3C bitstream consists of multiple atlases, this parameter indicates the atlas id for the media component. 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-attr-idx:

sprop-v3c-attr-idx provides a value corresponding to vuh_attribute_index defined in . 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. 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-attr-part-idx:

sprop-v3c-attr-part-idx provides a value corresponding to vuh_attribute_partition_index defined in . 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. 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-map-idx:

sprop-v3c-map-idx provides a value corresponding to vuh_map_index defined in . Maps in V3C allow storing multiple layers of projected volumetric data. 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-aux-video-flag:

sprop-v3c-aux-video-flag provides a value corresponding to vuh_auxiliary_video_flag defined in . Auxiliary video in V3C can be used to pack volumetric data directly in a video frame without projecting it into a 2D plane first. 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-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. 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-pres:

sprop-v3c-tile-id-pres indicates that the RTP packets contain v3c-tile-id field. 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-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 representations of the atlas NAL units as specified in . 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-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 representations of the common atlas NAL units (i.e., NAL_CASPS and NAL_CAF_IDR) as specified in . 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-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 representations of SEI NAL units (i.e., NAL_PREFIX_NSEI and NAL_SUFFIX_NSEI, NAL_PREFIX_ESEI, NAL_SUFFIX_ESEI) as specified in . 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.

v3c-ptl-level-idc:

v3c-ptl-level-idc provides a value corresponding to ptl_level_idc defined in . The value of v3c-ptl-level-idc indicates the level to which the V3C bitstream conforms. 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-tier-flag:

v3c-ptl-tier-flag provides a value corresponding to ptl_tier_flag defined in . The value of v3c-ptl-tier-flag indicates the tier context necessary to interpret the value of 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-codec-idc:

v3c-ptl-codec-idc provides a value corresponding to ptl_profile_codec_group_idc defined in . The value of v3c-ptl-codec-idc indicates the codec group profile component to which the V3C bitstream conforms. 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-toolset-idc:

v3c-ptl-toolset-idc provides a value corresponding to ptl_profile_toolset_idc defined in . The value of v3c-ptl-toolset-idc indicates the toolset combination profile component to which the V3C bitstream conforms. 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-rec-idc:

v3c-ptl-rec-idc provides a value corresponding to ptl_profile_reconstruction_idc as defined in . The value of v3c-ptl-rec-idc indicates the reconstruction profile component to which the V3C bitstream is recommended to conform. 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.

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. 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. 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. The value of sprop-max-don-diff MUST be an integer in the range of 0 to 32767 inclusive. When not present, the value of sprop-max-don-diff is inferred to be equal to 0.

Mapping of Parameters to V3C Syntax Mapping of Parameters to V3C Syntax

Parameter	Required	V3C Syntax Counterpart	ISO/IEC 23090-5 Section Reference
sprop-v3c-parameter-set	YES	v3c_parameter_set()	8.3.4.1
sprop-v3c-unit-header	NO	v3c_unit_header()	8.3.2.2
sprop-v3c-unit-type	NO	vuh_unit_type	8.4.2.2
sprop-v3c-vps-id	NO	vuh_v3c_parameter_set_id	8.4.2.2
sprop-v3c-atlas-id	NO	vuh_atlas_id	8.4.2.2
sprop-v3c-attr-idx	NO	vuh_attribute_index	8.4.2.2
sprop-v3c-attr-part-idx	NO	vuh_attribute_partition_index	8.4.2.2
sprop-v3c-map-idx	NO	vuh_map_index	8.4.2.2
sprop-v3c-aux-video-flag	NO	vuh_auxiliary_video_flag	8.4.2.2
sprop-v3c-tile-id	NO	-	-
sprop-v3c-tile-id-pres	NO	-	-
sprop-v3c-atlas-data	NO	nal_unit()	8.3.5.1
sprop-v3c-common-atlas-data	NO	nal_unit()	8.3.5.1
sprop-v3c-sei	NO	nal_unit()	8.3.5.1
v3c-ptl-level-idc	NO	ptl_level_idc	8.4.4.2
v3c-ptl-tier-flag	NO	ptl_tier_flag	8.4.4.2
v3c-ptl-codec-idc	NO	ptl_profile_codec_group_idc	8.4.4.2
v3c-ptl-toolset-idc	NO	ptl_profile_toolset_idc	8.4.4.2
v3c-ptl-rec-idc	NO	ptl_profile_reconstruction_idc	8.4.4.2
sprop-max-don-diff	NO	-	-

Congestion Control Considerations Congestion control for RTP SHALL be used in accordance with RTP and with any applicable RTP profile, e.g., AVP . This section only applies for unicast streaming, leaving considerations for multicast streaming out of scope. 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 ). 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. 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 that defines criteria for when one the RTP flow must stop sending RTP Packet Streams. 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.

Session Description Protocol A new attribute "v3cfmtp" is defined for carrying V3C format media type parameters in the corresponding fields of SDP . Grouping framework is used to indicate which media lines (video and application) in the SDP constitute a V3C representation.

V3C Format Parameters "v3cfmtp" Attribute 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 . The value of the v3cfmtp attribute is a byte-string, as defined in , 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. 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. a=v3cfmtp:sprop-v3c-parameter-set=AUH/AAAP/zwAAAAAACgIAtEAgQLAIAAUQ BACWAM5QEDgQCAIAAAAABP8CzwAAAAAAAAAQAAAtAE/wLPAAAAAAAg=; a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;v3c-ptl-tier-flag=1;

Mapping of Payload Type Parameters to SDP

For V3C Atlas Components

• The media name in the "m=" line of SDP MUST be application.
• The encoding name in the "a=rtpmap" line of SDP MUST be v3c.
• The clock rate in the "a=rtpmap" line MUST be 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.
• 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.

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. 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: 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==

For V3C Video Components

• The media name in the "m=" line of SDP MUST be 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.
• The clock rate in the "a=rtpmap" line MUST be 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.

The OPTIONAL parameters, when present in the video media line V3C format parameters ("v3cfmtp") attribute, specify values that are considered static for the session. An example of media representation corresponding to occupancy video component (V3C_OVD) in SDP is as follows: 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. 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==

Grouping Framework 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 or . A grouping tool, as defined in , is extended to indicate which media lines constitute a V3C representation. Further details on the new grouping type provided in . 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. 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. ... 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. ... 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

Offer and Answer Considerations

Unicast This section describes the negotiation of unicast streaming using the offer/answer model as described in . 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. 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. The following limitations and rules pertaining to the V3C atlas component media configuration apply:

• 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.
• Send only properties, identified by sprop-prefix, are considered declarative and SHOULD be omitted in the answers.

The answerer MUST structure its answer according to one of the following two options:

• 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
• reject media line in which one or more of the parameter values are not supported by setting the port to zero in the answer.

The following limitations and rules pertaining to the V3C video component media configuration apply:

• The parameters identifying a video-coded V3C component media configuration format are according to the respective RTP video payload specification.

The answerer MUST structure its answer according to one of the following two options:

• 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
• 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.

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 . 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. ... 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: ... 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 : ... 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: 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

Multicast 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.
• The video-coded V3C component media configuration format is according to the respective RTP video payload specification.
• 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.
• Parameter sets received MUST be associated with the originating source and MUST only be used in decoding the incoming bitstream from the same source.

Declarative SDP Considerations 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. 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.

IANA Considerations This document contains three IANA considerations: a new media type, a new SDP attribute, and a new grouping type.

V3C Media Type Registration IANA has registered the following media type in the "Media Types" registry.

Type name:

application

Subtype name:

v3c

Required parameters:

sprop-v3c-parameter-set

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.

Encoding considerations:

framed

Security considerations:

See of RFC 10034.

Interoperability considerations:

N/A

Published specification:

RFC 10034

Applications that use this media type:

Any application that relies on V3C-based media services over RTP.

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)

Intended usage:

COMMON

Restrictions on usage:

This media type depends on RTP framing and, hence, is only defined for transfer via RTP . Transport within other framing protocols is not defined at this time.

Author:

See the Authors' Addresses section of RFC 10034.

Change controller:

IETF

V3C Format Parameters SDP Attribute IANA has registered the following SDP attribute in the "attribute-name (formerly 'att-field')" registry under the "Session Description Protocol (SDP) Parameters" registry group.

Contact name:

See the Authors' Addresses section of RFC 10034.

Contact email address:

See the Authors' Addresses section of RFC 10034.

Attribute name:

v3cfmtp

Attribute syntax:

v3cfmtp-value = byte-string Notes:

• The V3C format parameters are V3C media type parameters and need to reflect their syntax.
• "byte-string" is as defined in .
• ABNF grammar is as defined in .

Attribute semantics:

"v3cfmtp-value" is a byte-string, as defined in , 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.

Attribute value:

v3cfmtp-value

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.

O/A procedures:

The v3cfmtp attribute can be present both in offers and answers.

Mux Category:

NORMAL

Reference:

RFC 10034

The attribute-name (formerly 'att-field') Registry

Type	SDP Name	Usage Level	Mux Category	Reference
attribute	v3cfmtp	session, media	NORMAL	RFC 10034

V3C Grouping Type Extension 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: The Semantics for the 'group' SDP Attribute Registry

Semantics	Token	Mux Category	Reference
V3C grouping	V3C	NORMAL	RFC 10034

Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification and in any applicable RTP profile such as RTP/AVP , RTP/AVPF , RTP/SAVP , or RTP/SAVPF . However, as 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 . 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 . For modern best practices, applications can consider the following options:

(D)TLS-based protection:

For guidance on using TLS 1.3 and DTLS, applications should refer to , which provides up-to-date recommendations.

IPsec-based protection:

Relevant and current protocol specifications include (ESP) and (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. 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. 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.

References Normative References ISO/IEC ISO/IEC In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK] This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. [STANDARDS-TRACK] The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group. This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension. This specification updates RFCs 3264, 5888, and 7941. This specification obsoletes RFC 8843. Informative References This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK] This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK] An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK] This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK] This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK] The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism. This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.

Authors' Addresses Nokia Technologies

Hatanpaeaen valtatie 30 Tampere 33100 Finland lauri.ilola@nokia.com

Nokia Technologies

Werinherstrasse 91 Munich D-81541 Germany lukasz.kondrad@nokia.com