doc: Add RFC documents

1 files changed, 3088 insertions, 0 deletions

diff --git a/doc/rfc/rfc9328.txt b/doc/rfc/rfc9328.txt
new file mode 100644
index 0000000..8a530a8
--- /dev/null
+++ b/doc/rfc/rfc9328.txt
@@ -0,0 +1,3088 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           S. Zhao
+Request for Comments: 9328                                         Intel
+Category: Standards Track                                      S. Wenger
+ISSN: 2070-1721                                                  Tencent
+                                                              Y. Sanchez
+                                                          Fraunhofer HHI
+                                                              Y.-K. Wang
+                                                          Bytedance Inc.
+                                                         M. M Hannuksela
+                                                      Nokia Technologies
+                                                           December 2022
+
+
+          RTP Payload Format for Versatile Video Coding (VVC)
+
+Abstract
+
+   This memo describes an RTP payload format for the Versatile Video
+   Coding (VVC) specification, which was published as both ITU-T
+   Recommendation H.266 and ISO/IEC International Standard 23090-3.  VVC
+   was developed by the Joint Video Experts Team (JVET).  The RTP
+   payload format allows for packetization of one or more Network
+   Abstraction Layer (NAL) units in each RTP packet payload, as well as
+   fragmentation of a NAL unit into multiple RTP packets.  The payload
+   format has wide applicability in videoconferencing, Internet video
+   streaming, and high-bitrate entertainment-quality video, among other
+   applications.
+
+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
+   https://www.rfc-editor.org/info/rfc9328.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Overview of the VVC Codec
+       1.1.1.  Coding-Tool Features (Informative)
+       1.1.2.  Systems and Transport Interfaces (Informative)
+       1.1.3.  High-Level Picture Partitioning (Informative)
+       1.1.4.  NAL Unit Header
+     1.2.  Overview of the Payload Format
+   2.  Conventions
+   3.  Definitions and Abbreviations
+     3.1.  Definitions
+       3.1.1.  Definitions from the VVC Specification
+       3.1.2.  Definitions Specific to This Memo
+     3.2.  Abbreviations
+   4.  RTP Payload Format
+     4.1.  RTP Header Usage
+     4.2.  Payload Header Usage
+     4.3.  Payload Structures
+       4.3.1.  Single NAL Unit Packets
+       4.3.2.  Aggregation Packets (APs)
+       4.3.3.  Fragmentation Units
+     4.4.  Decoding Order Number
+   5.  Packetization Rules
+   6.  De-packetization Process
+   7.  Payload Format Parameters
+     7.1.  Media Type Registration
+     7.2.  Optional Parameters Definition
+     7.3.  SDP Parameters
+       7.3.1.  Mapping of Payload Type Parameters to SDP
+       7.3.2.  Usage with SDP Offer/Answer Model
+       7.3.3.  Multicast
+       7.3.4.  Usage in Declarative Session Descriptions
+       7.3.5.  Considerations for Parameter Sets
+   8.  Use with Feedback Messages
+     8.1.  Picture Loss Indication (PLI)
+     8.2.  Full Intra Request (FIR)
+   9.  Security Considerations
+   10. Congestion Control
+   11. IANA Considerations
+   12. References
+     12.1.  Normative References
+     12.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The Versatile Video Coding specification was formally published as
+   both ITU-T Recommendation H.266 [VVC] and ISO/IEC International
+   Standard 23090-3 [ISO23090-3].  VVC is reported to provide
+   significant coding efficiency gains over High Efficiency Video Coding
+   [HEVC], also known as H.265, and other earlier video codecs.
+
+   This memo specifies an RTP payload format for VVC.  It shares its
+   basic design with the NAL-unit-based RTP payload formats of Advanced
+   Video Coding (AVC) [RFC6184], Scalable Video Coding (SVC) [RFC6190],
+   and High Efficiency Video Coding (HEVC) [RFC7798], as well as their
+   respective predecessors.  With respect to design philosophy,
+   security, congestion control, and overall implementation complexity,
+   it has similar properties to those earlier payload format
+   specifications.  This is a conscious choice, as at least [RFC6184] is
+   widely deployed and generally known in the relevant implementer
+   communities.  Certain scalability-related mechanisms known from
+   [RFC6190] were incorporated into this document, as VVC version 1
+   supports temporal, spatial, and signal-to-noise ratio (SNR)
+   scalability.
+
+1.1.  Overview of the VVC Codec
+
+   VVC and HEVC share a similar hybrid video codec design.  In this
+   memo, we provide a very brief overview of those features of VVC that
+   are, in some form, addressed by the payload format specified herein.
+   Implementers have to read, understand, and apply the ITU-T/ISO/IEC
+   specifications pertaining to VVC to arrive at interoperable, well-
+   performing implementations.
+
+   Conceptually, both VVC and HEVC include a Video Coding Layer (VCL),
+   which is often used to refer to the coding-tool features, and a NAL,
+   which is often used to refer to the systems and transport interface
+   aspects of the codecs.
+
+1.1.1.  Coding-Tool Features (Informative)
+
+   Coding-tool features are described below with occasional reference to
+   the coding-tool set of HEVC, which is well known in the community.
+
+   Similar to earlier hybrid-video-coding-based standards, including
+   HEVC, the following basic video coding design is employed by VVC.  A
+   prediction signal is first formed by either intra- or motion-
+   compensated prediction, and the residual (the difference between the
+   original and the prediction) is then coded.  The gains in coding
+   efficiency are achieved by redesigning and improving almost all parts
+   of the codec over earlier designs.  In addition, VVC includes several
+   tools to make the implementation on parallel architectures easier.
+
+   Finally, VVC includes temporal, spatial, and SNR scalability, as well
+   as multiview coding support.
+
+   Coding blocks and transform structure
+      Among major coding-tool differences between HEVC and VVC, one of
+      the important improvements is the more flexible coding tree
+      structure in VVC, i.e., multi-type tree.  In addition to quadtree,
+      binary and ternary trees are also supported, which contributes
+      significant improvement in coding efficiency.  Moreover, the
+      maximum size of a coding tree unit (CTU) is increased from 64x64
+      to 128x128.  To improve the coding efficiency of chroma signal,
+      luma-chroma-separated trees at CTU level may be employed for intra
+      slices.  The square transforms in HEVC are extended to non-square
+      transforms for rectangular blocks resulting from binary and
+      ternary tree splits.  Besides, VVC supports multiple transform
+      sets (MTSs), including DCT-2, DST-7, and DCT-8, as well as the
+      non-separable secondary transform.  The transforms used in VVC can
+      have different sizes with support for larger transform sizes.  For
+      DCT-2, the transform sizes range from 2x2 to 64x64, and for DST-7
+      and DCT-8, the transform sizes range from 4x4 to 32x32.  In
+      addition, VVC also support sub-block transform for both intra- and
+      inter-coded blocks.  For intra-coded blocks, intra sub-
+      partitioning (ISP) may be used to allow sub-block-based intra
+      prediction and transform.  For inter blocks, sub-block transform
+      may be used assuming that only a part of an inter block has non-
+      zero transform coefficients.
+
+   Entropy coding
+      Similar to HEVC, VVC uses a single entropy-coding engine, which is
+      based on context adaptive binary arithmetic coding [CABAC] but
+      with the support of multi-window sizes.  The window sizes can be
+      initialized differently for different context models.  Due to such
+      a design, it has more efficient adaptation speed and better coding
+      efficiency.  A joint chroma residual coding scheme is applied to
+      further exploit the correlation between the residuals of two color
+      components.  In VVC, different residual coding schemes are applied
+      for regular transform coefficients and residual samples generated
+      using transform-skip mode.
+
+   In-loop filtering
+      VVC has more feature support in loop filters than HEVC.  The
+      deblocking filter in VVC is similar to HEVC but operates at a
+      smaller grid.  After deblocking and sample adaptive offset (SAO),
+      an adaptive loop filter (ALF) may be used.  As a Wiener filter,
+      ALF reduces distortion of decoded pictures.  Besides, VVC
+      introduces a new module called luma mapping with chroma scaling to
+      fully utilize the dynamic range of signal so that rate-distortion
+      performance of both Standard Dynamic Range (SDR) and High Dynamic
+      Range (HDR) content is improved.
+
+   Motion prediction and coding
+      Compared to HEVC, VVC introduces several improvements in this
+      area.  First, there is the adaptive motion vector resolution
+      (AMVR), which can save bit cost for motion vectors by adaptively
+      signaling motion vector resolution.  Then, the affine motion
+      compensation is included to capture complicated motion-like
+      zooming and rotation.  Meanwhile, prediction refinement with the
+      optical flow (PROF) with affine mode is further deployed to mimic
+      affine motion at the pixel level.  Thirdly, the decoder-side
+      motion vector refinement (DMVR) is a method to derive the motion
+      vector at the decoder side based on block matching so that fewer
+      bits may be spent on motion vectors.  Bidirectional optical flow
+      (BDOF) is a similar method to PROF.  BDOF adds a sample-wise
+      offset at the 4x4 sub-block level that is derived with equations
+      based on gradients of the prediction samples and a motion
+      difference relative to coding-unit (CU) motion vectors.
+      Furthermore, merge with motion vector difference (MMVD) is a
+      special mode that further signals a limited set of motion vector
+      differences on top of merge mode.  In addition to MMVD, there are
+      another three types of special merge modes, i.e., sub-block merge,
+      triangle, and combined intra/inter prediction (CIIP).  The sub-
+      block merge list includes one candidate of sub-block temporal
+      motion vector prediction (SbTMVP) and up to four candidates of
+      affine motion vectors.  Triangle is based on triangular block
+      motion compensation.  CIIP combines intra and inter predictions
+      with weighting.  Adaptive weighting may be employed with a block-
+      level tool called bi-prediction with CU-based weighting (BCW),
+      which provides more flexibility than in HEVC.
+
+   Intra prediction and intra coding
+      To capture the diversified local image texture directions with
+      finer granularity, VVC supports 65 angular directions instead of
+      33 directions in HEVC.  The intra mode coding is based on a 6-
+      most-probable-modes scheme, and the 6 most probable modes are
+      derived using the neighboring intra prediction directions.  In
+      addition, to deal with the different distributions of intra
+      prediction angles for different block aspect ratios, a wide-angle-
+      intra-prediction (WAIP) scheme is applied in VVC by including
+      intra prediction angles beyond those present in HEVC.  Unlike
+      HEVC, which only allows using the most adjacent line of reference
+      samples for intra prediction, VVC also allows using two further
+      reference lines, known as multi-reference-line (MRL) intra
+      prediction.  The additional reference lines can be only used for
+      the 6 most probable intra prediction modes.  To capture the strong
+      correlation between different color components, in VVC, a cross-
+      component linear mode (CCLM) is utilized, which assumes a linear
+      relationship between the luma sample values and their associated
+      chroma samples.  For intra prediction, VVC also applies a
+      position-dependent prediction combination (PDPC) for refining the
+      prediction samples closer to the intra prediction block boundary.
+      Matrix-based intra prediction (MIP) modes are also used in VVC,
+      which generates an up to 8x8 intra prediction block using a
+      weighted sum of downsampled neighboring reference samples, and the
+      weights are hard-coded constants.
+
+   Other coding-tool features
+      VVC introduces dependent quantization (DQ) to reduce quantization
+      error by state-based switching between two quantizers.
+
+1.1.2.  Systems and Transport Interfaces (Informative)
+
+   VVC inherits the basic systems and transport interface designs from
+   HEVC and AVC.  These include the NAL-unit-based syntax structure, the
+   hierarchical syntax and data unit structure, the supplemental
+   enhancement information (SEI) message mechanism, and the video
+   buffering model based on the hypothetical reference decoder (HRD).
+   The scalability features of VVC are conceptually similar to the
+   scalable extension of HEVC, known as SHVC.  The hierarchical syntax
+   and data unit structure consists of parameter sets at various levels
+   (i.e., decoder, sequence (pertaining to all), sequence (pertaining to
+   a single), and picture), picture-level header parameters, slice-level
+   header parameters, and lower-level parameters.
+
+   A number of key components that influenced the network abstraction
+   layer design of VVC, as well as this memo, are described below
+
+   Decoding capability information
+      The decoding capability information (DCI) includes parameters that
+      stay constant for the lifetime of a VVC bitstream in the duration
+      of a video conference, continuous video stream, and similar, i.e.,
+      any video that is processed by a decoder between setup and
+      teardown.  For streaming, the requirement of constant parameters
+      pertains through splicing.  Such information includes profile,
+      level, and sub-profile information to determine a maximum
+      capability interop point that is guaranteed to never be exceeded,
+      even if splicing of video sequences occurs within a session.  It
+      further includes constraint fields (most of which are flags),
+      which can optionally be set to indicate that the video bitstream
+      will be constrained in the use of certain features, as indicated
+      by the values of those fields.  With this, a bitstream can be
+      labeled as not using certain tools, which allows, among other
+      things, for resource allocation in a decoder implementation.
+
+   Video parameter set
+      The video parameter set (VPS) pertains to one or more coded video
+      sequences (CVSs) of multiple layers covering the same range of
+      access units and includes, among other information, decoding
+      dependency expressed as information for reference-picture-list
+      construction of enhancement layers.  The VPS provides a "big
+      picture" of a scalable sequence, including what types of operation
+      points are provided; the profile, tier, and level of the operation
+      points; and some other high-level properties of the bitstream that
+      can be used as the basis for session negotiation and content
+      selection, etc.  One VPS may be referenced by one or more sequence
+      parameter sets.
+
+   Sequence parameter set
+      The sequence parameter set (SPS) contains syntax elements
+      pertaining to a coded layer video sequence (CLVS), which is a
+      group of pictures belonging to the same layer, starting with a
+      random access point, and followed by pictures that may depend on
+      each other until the next random access point picture.  In MPEG-2,
+      the equivalent of a CVS was a group of pictures (GOP), which
+      normally started with an I frame and was followed by P and B
+      frames.  While more complex in its options of random access
+      points, VVC retains this basic concept.  One remarkable difference
+      of VVC is that a CLVS may start with a Gradual Decoding Refresh
+      (GDR) picture without requiring presence of traditional random
+      access points in the bitstream, such as instantaneous decoding
+      refresh (IDR) or clean random access (CRA) pictures.  In many TV-
+      like applications, a CVS contains a few hundred milliseconds to a
+      few seconds of video.  In video conferencing (without switching
+      Multipoint Control Units (MCUs) involved), a CVS can be as long in
+      duration as the whole session.
+
+   Picture and adaptation parameter set
+      The picture parameter set (PPS) and the adaptation parameter set
+      (APS) carry information pertaining to zero or more pictures and
+      zero or more slices, respectively.  The PPS contains information
+      that is likely to stay constant from picture to picture, at least
+      for pictures for a certain type, whereas the APS contains
+      information, such as adaptive loop filter coefficients, that are
+      likely to change from picture to picture or even within a picture.
+      A single APS is referenced by all slices of the same picture if
+      that APS contains information about luma mapping with chroma
+      scaling (LMCS) or a scaling list.  Different APSs containing ALF
+      parameters can be referenced by slices of the same picture.
+
+   Picture header
+      A picture header (PH) contains information that is common to all
+      slices that belong to the same picture.  Being able to send that
+      information as a separate NAL unit when pictures are split into
+      several slices allows for saving bitrate, compared to repeating
+      the same information in all slices.  However, there might be
+      scenarios where low-bitrate video is transmitted using a single
+      slice per picture.  Having a separate NAL unit to convey that
+      information incurs in an overhead for such scenarios.  For such
+      scenarios, the picture header syntax structure is directly
+      included in the slice header, instead of its own NAL unit.  The
+      mode of the picture header syntax structure being included in its
+      own NAL unit or not can only be switched on/off for an entire CLVS
+      and can only be switched off when, in the entire CLVS, each
+      picture contains only one slice.
+
+   Profile, tier, and level
+      The profile, tier, and level syntax structures in DCI, VPS, and
+      SPS contain profile, tier, and level information for all layers
+      that refer to the DCI, for layers associated with one or more
+      output layer sets specified by the VPS, and for any layer that
+      refers to the SPS, respectively.
+
+   Sub-profiles
+      Within the VVC specification, a sub-profile is a 32-bit number,
+      coded according to ITU-T Recommendation T.35, that does not carry
+      semantics.  It is carried in the profile_tier_level structure and
+      hence is (potentially) present in the DCI, VPS, and SPS.  External
+      registration bodies can register a T.35 codepoint with ITU-T
+      registration authorities and associate with their registration a
+      description of bitstream restrictions beyond the profiles defined
+      by ITU-T and ISO/IEC.  This would allow encoder manufacturers to
+      label the bitstreams generated by their encoder as complying with
+      such sub-profile.  It is expected that upstream standardization
+      organizations (such as Digital Video Broadcasting (DVB) and
+      Advanced Television Systems Committee (ATSC)), as well as walled-
+      garden video services, will take advantage of this labeled system.
+      In contrast to "normal" profiles, it is expected that sub-profiles
+      may indicate encoder choices traditionally left open in the
+      (decoder-centric) video coding specifications, such as GOP
+      structures, minimum/maximum Quantizer Parameter (QP) values, and
+      the mandatory use of certain tools or SEI messages.
+
+   General constraint fields
+      The profile_tier_level structure carries a considerable number of
+      constraint fields (most of which are flags), which an encoder can
+      use to indicate to a decoder that it will not use a certain tool
+      or technology.  They were included in reaction to a perceived
+      market need to label a bitstream as not exercising a certain tool
+      that has become commercially unviable.
+
+   Temporal scalability support
+      VVC includes support of temporal scalability, by the inclusion of
+      the signaling of TemporalId in the NAL unit header, the
+      restriction that pictures of a particular temporal sublayer cannot
+      be used for inter prediction reference by pictures of a lower
+      temporal sublayer, the sub-bitstream extraction process, and the
+      requirement that each sub-bitstream extraction output be a
+      conforming bitstream.  Media-Aware Network Elements (MANEs) can
+      utilize the TemporalId in the NAL unit header for stream
+      adaptation purposes based on temporal scalability.
+
+   Reference picture resampling (RPR)
+      In AVC and HEVC, the spatial resolution of pictures cannot change
+      unless a new sequence using a new SPS starts, with an intra random
+      access point (IRAP) picture.  VVC enables picture resolution
+      change within a sequence at a position without encoding an IRAP
+      picture, which is always intra coded.  This feature is sometimes
+      referred to as reference picture resampling (RPR), as the feature
+      needs resampling of a reference picture used for inter prediction
+      when that reference picture has a different resolution than the
+      current picture being decoded.  RPR allows resolution change
+      without the need of coding an IRAP picture and hence avoids a
+      momentary bit rate spike caused by an IRAP picture in streaming or
+      video conferencing scenarios, e.g., to cope with network condition
+      changes.  RPR can also be used in application scenarios wherein
+      zooming of the entire video region or some region of interest is
+      needed.
+
+   Spatial, SNR, and multiview scalability
+      VVC includes support for spatial, SNR, and multiview scalability.
+      Scalable video coding is widely considered to have technical
+      benefits and enrich services for various video applications.
+      Until recently, however, the functionality has not been included
+      in the first version of specifications of the video codecs.  In
+      VVC, however, all those forms of scalability are supported in the
+      first version of VVC natively through the signaling of the
+      nuh_layer_id in the NAL unit header, the VPS that associates
+      layers with the given nuh_layer_id to each other, reference
+      picture selection, reference picture resampling for spatial
+      scalability, and a number of other mechanisms not relevant for
+      this memo.
+
+      Spatial scalability
+         With the existence of reference picture resampling (RPR), the
+         additional burden for scalability support is just a
+         modification of the high-level syntax (HLS).  The inter-layer
+         prediction is employed in a scalable system to improve the
+         coding efficiency of the enhancement layers.  In addition to
+         the spatial and temporal motion-compensated predictions that
+         are available in a single-layer codec, the inter-layer
+         prediction in VVC uses the possibly resampled video data of the
+         reconstructed reference picture from a reference layer to
+         predict the current enhancement layer.  The resampling process
+         for inter-layer prediction, when used, is performed at the
+         block level, reusing the existing interpolation process for
+         motion compensation in single-layer coding.  It means that no
+         additional resampling process is needed to support spatial
+         scalability.
+
+      SNR scalability
+         SNR scalability is similar to spatial scalability except that
+         the resampling factors are 1:1.  In other words, there is no
+         change in resolution, but there is inter-layer prediction.
+
+      Multiview scalability
+         The first version of VVC also supports multiview scalability,
+         wherein a multi-layer bitstream carries layers representing
+         multiple views, and one or more of the represented views can be
+         output at the same time.
+
+   SEI messages
+      Supplemental enhancement information (SEI) messages are
+      information in the bitstream that do not influence the decoding
+      process as specified in the VVC specification but address issues
+      of representation/rendering of the decoded bitstream, label the
+      bitstream for certain applications, and other, similar tasks.  The
+      overall concept of SEI messages and many of the messages
+      themselves has been inherited from the AVC and HEVC
+      specifications.  Except for the SEI messages that affect the
+      specification of the hypothetical reference decoder (HRD), other
+      SEI messages for use in the VVC environment, which are generally
+      useful also in other video coding technologies, are not included
+      in the main VVC specification but in a companion specification
+      [VSEI].
+
+1.1.3.  High-Level Picture Partitioning (Informative)
+
+   VVC inherited the concept of tiles and wavefront parallel processing
+   (WPP) from HEVC, with some minor to moderate differences.  The basic
+   concept of slices was kept in VVC but designed in an essentially
+   different form.  VVC is the first video coding standard that includes
+   subpictures as a feature, which provides the same functionality as
+   HEVC motion-constrained tile sets (MCTSs) but designed differently to
+   have better coding efficiency and to be friendlier for usage in
+   application systems.  More details of these differences are described
+   below.
+
+   Tiles and WPP
+      Same as in HEVC, a picture can be split into tile rows and tile
+      columns in VVC, in-picture prediction across tile boundaries is
+      disallowed, etc.  However, the syntax for signaling of tile
+      partitioning has been simplified by using a unified syntax design
+      for both the uniform and the non-uniform mode.  In addition,
+      signaling of entry point offsets for tiles in the slice header is
+      optional in VVC, while it is mandatory in HEVC.  The WPP design in
+      VVC has two differences compared to HEVC: i) the CTU row delay is
+      reduced from two CTUs to one CTU, and ii) signaling of entry point
+      offsets for WPP in the slice header is optional in VVC while it is
+      mandatory in HEVC.
+
+   Slices
+      In VVC, the conventional slices based on CTUs (as in HEVC) or
+      macroblocks (as in AVC) have been removed.  The main reasoning
+      behind this architectural change is as follows.  The advances in
+      video coding since 2003 (the publication year of AVC v1) have been
+      such that slice-based error concealment has become practically
+      impossible due to the ever-increasing number and efficiency of in-
+      picture and inter-picture prediction mechanisms.  An error-
+      concealed picture is the decoding result of a transmitted coded
+      picture for which there is some data loss (e.g., loss of some
+      slices) of the coded picture or a reference picture, as at least
+      some part of the coded picture is not error-free (e.g., that
+      reference picture was an error-concealed picture).  For example,
+      when one of the multiple slices of a picture is lost, it may be
+      error-concealed using an interpolation of the neighboring slices.
+      While advanced video coding prediction mechanisms provide
+      significantly higher coding efficiency, they also make it harder
+      for machines to estimate the quality of an error-concealed
+      picture, which was already a hard problem with the use of simpler
+      prediction mechanisms.  Advanced in-picture prediction mechanisms
+      also cause the coding efficiency loss due to splitting a picture
+      into multiple slices to be more significant.  Furthermore, network
+      conditions become significantly better while, at the same time,
+      techniques for dealing with packet losses have become
+      significantly improved.  As a result, very few implementations
+      have recently used slices for maximum-transmission-unit-size
+      matching.  Instead, substantially all applications where low-delay
+      error resilience is required (e.g., video telephony and video
+      conferencing) rely on system/transport-level error resilience
+      (e.g., retransmission or forward error correction) and/or picture-
+      based error resilience tools (e.g., feedback-based error
+      resilience, insertion of IRAPs, scalability with a higher
+      protection level of the base layer, and so on).  Considering all
+      the above, nowadays, it is very rare that a picture that cannot be
+      correctly decoded is passed to the decoder, and when such a rare
+      case occurs, the system can afford to wait for an error-free
+      picture to be decoded and available for display without resulting
+      in frequent and long periods of picture freezing seen by end
+      users.
+
+      Slices in VVC have two modes: rectangular slices and raster-scan
+      slices.  The rectangular slice, as indicated by its name, covers a
+      rectangular region of the picture.  Typically, a rectangular slice
+      consists of several complete tiles.  However, it is also possible
+      that a rectangular slice is a subset of a tile and consists of one
+      or more consecutive, complete CTU rows within a tile.  A raster-
+      scan slice consists of one or more complete tiles in a tile
+      raster-scan order; hence, the region covered by raster-scan slices
+      need not but could have a non-rectangular shape, but it may also
+      happen to have the shape of a rectangle.  The concept of slices in
+      VVC is therefore strongly linked to or based on tiles instead of
+      CTUs (as in HEVC) or macroblocks (as in AVC).
+
+   Subpictures
+      VVC is the first video coding standard that includes the support
+      of subpictures as a feature.  Each subpicture consists of one or
+      more complete rectangular slices that collectively cover a
+      rectangular region of the picture.  A subpicture may be either
+      specified to be extractable (i.e., coded independently of other
+      subpictures of the same picture and of earlier pictures in
+      decoding order) or not extractable.  Regardless of whether a
+      subpicture is extractable or not, the encoder can control whether
+      in-loop filtering (including deblocking, SAO, and ALF) is applied
+      across the subpicture boundaries individually for each subpicture.
+
+      Functionally, subpictures are similar to the motion-constrained
+      tile sets (MCTSs) in HEVC.  They both allow independent coding and
+      extraction of a rectangular subset of a sequence of coded pictures
+      for use cases like viewport-dependent 360-degree video streaming
+      optimization and region of interest (ROI) applications.
+
+      There are several important design differences between subpictures
+      and MCTSs.  First, the subpictures featured in VVC allow motion
+      vectors of a coding block to point outside of the subpicture, even
+      when the subpicture is extractable by applying sample padding at
+      the subpicture boundaries, in this case, similarly as at picture
+      boundaries.  Second, additional changes were introduced for the
+      selection and derivation of motion vectors in the merge mode and
+      in the decoder-side motion vector refinement process of VVC.  This
+      allows higher coding efficiency compared to the non-normative
+      motion constraints applied at the encoder-side for MCTSs.  Third,
+      rewriting of slice headers (SHs) (and PH NAL units, when present)
+      is not needed when extracting one or more extractable subpictures
+      from a sequence of pictures to create a sub-bitstream that is a
+      conforming bitstream.  In sub-bitstream extractions based on HEVC
+      MCTSs, rewriting of SHs is needed.  Note that, in both HEVC MCTSs
+      extraction and VVC subpictures extraction, rewriting of SPSs and
+      PPSs is needed.  However, typically, there are only a few
+      parameter sets in a bitstream, whereas each picture has at least
+      one slice; therefore, rewriting of SHs can be a significant burden
+      for application systems.  Fourth, slices of different subpictures
+      within a picture are allowed to have different NAL unit types.
+      Fifth, VVC specifies HRD and level definitions for subpicture
+      sequences, thus the conformance of the sub-bitstream of each
+      extractable subpicture sequence can be ensured by encoders.
+
+1.1.4.  NAL Unit Header
+
+   VVC maintains the NAL unit concept of HEVC with modifications.  VVC
+   uses a two-byte NAL unit header, as shown in Figure 1.  The payload
+   of a NAL unit refers to the NAL unit excluding the NAL unit header.
+
+                     +---------------+---------------+
+                     |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     |F|Z| LayerID   |  Type   | TID |
+                     +---------------+---------------+
+
+             Figure 1: The Structure of the VVC NAL Unit Header
+
+   The semantics of the fields in the NAL unit header are as specified
+   in VVC and described briefly below for convenience.  In addition to
+   the name and size of each field, the corresponding syntax element
+   name in VVC is also provided.
+
+   F: 1 bit
+      forbidden_zero_bit.  This field is required to be zero in VVC.
+      Note that the inclusion of this bit in the NAL unit header was to
+      enable transport of VVC video over MPEG-2 transport systems
+      (avoidance of start code emulations) [MPEG2S].  In the context of
+      this payload format, the value 1 may be used to indicate a syntax
+      violation, e.g., for a NAL unit resulted from aggregating a number
+      of fragmented units of a NAL unit but missing the last fragment,
+      as described in the last sentence of Section 4.3.3.
+
+   Z: 1 bit
+      nuh_reserved_zero_bit.  This field is required to be zero in VVC,
+      and reserved for future extensions by ITU-T and ISO/IEC.
+      This memo does not overload the "Z" bit for local extensions a)
+      because overloading the "F" bit is sufficient and b) in order to
+      preserve the usefulness of this memo to possible future versions
+      of [VVC].
+
+   LayerId: 6 bits
+      nuh_layer_id.  This field identifies the layer a NAL unit belongs
+      to, wherein a layer may be, e.g., a spatial scalable layer, a
+      quality scalable layer, a layer containing a different view, etc.
+
+   Type: 5 bits
+      nal_unit_type.  This field specifies the NAL unit type, as defined
+      in Table 5 of [VVC].  For a reference of all currently defined NAL
+      unit types and their semantics, please refer to Section 7.4.2.2 in
+      [VVC].
+
+   TID: 3 bits
+      nuh_temporal_id_plus1.  This field specifies the temporal
+      identifier of the NAL unit plus 1.  The value of TemporalId is
+      equal to TID minus 1.  A TID value of 0 is illegal to ensure that
+      there is at least one bit in the NAL unit header equal to 1 in
+      order to enable the consideration of start code emulations in the
+      NAL unit payload data independent of the NAL unit header.
+
+1.2.  Overview of the Payload Format
+
+   This payload format defines the following processes required for
+   transport of VVC coded data over RTP [RFC3550]:
+
+   *  usage of the RTP header with this payload format
+
+   *  packetization of VVC coded NAL units into RTP packets using three
+      types of payload structures: a single NAL unit packet, aggregation
+      packet, and fragment unit
+
+   *  transmission of VVC NAL units of the same bitstream within a
+      single RTP stream
+
+   *  media type parameters to be used with the Session Description
+      Protocol (SDP) [RFC8866]
+
+   *  usage of RTCP feedback messages
+
+2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Definitions and Abbreviations
+
+3.1.  Definitions
+
+   This document uses the terms and definitions of VVC.  Section 3.1.1
+   lists relevant definitions from [VVC] for convenience.  Section 3.1.2
+   provides definitions specific to this memo.  All the used terms and
+   definitions in this memo are verbatim copies from the [VVC]
+   specification.
+
+3.1.1.  Definitions from the VVC Specification
+
+   Access unit (AU):
+      A set of PUs that belong to different layers and contain coded
+      pictures associated with the same time for output from the DPB.
+
+   Adaptation parameter set (APS):
+      A syntax structure containing syntax elements that apply to zero
+      or more slices as determined by zero or more syntax elements found
+      in slice headers.
+
+   Bitstream:
+      A sequence of bits, in the form of a NAL unit stream or a byte
+      stream, that forms the representation of a sequence of AUs forming
+      one or more coded video sequences (CVSs).
+
+   Coded picture:
+      A coded representation of a picture comprising VCL NAL units with
+      a particular value of nuh_layer_id within an AU and containing all
+      CTUs of the picture.
+
+   Clean random access (CRA) PU:
+      A PU in which the coded picture is a CRA picture.
+
+   Clean random access (CRA) picture:
+      An IRAP picture for which each VCL NAL unit has nal_unit_type
+      equal to CRA_NUT.
+
+   Coded video sequence (CVS):
+      A sequence of AUs that consists, in decoding order, of a CVSS AU,
+      followed by zero or more AUs that are not CVSS AUs, including all
+      subsequent AUs up to but not including any subsequent AU that is a
+      CVSS AU.
+
+   Coded video sequence start (CVSS) AU:
+      An AU in which there is a PU for each layer in the CVS and the
+      coded picture in each PU is a CLVSS picture.
+
+   Coded layer video sequence (CLVS):
+      A sequence of PUs with the same value of nuh_layer_id that
+      consists, in decoding order, of a CLVSS PU, followed by zero or
+      more PUs that are not CLVSS PUs, including all subsequent PUs up
+      to but not including any subsequent PU that is a CLVSS PU.
+
+   Coded layer video sequence start (CLVSS) PU:
+      A PU in which the coded picture is a CLVSS picture.
+
+   Coded layer video sequence start (CLVSS) picture:
+      A coded picture that is an IRAP picture with
+      NoOutputBeforeRecoveryFlag equal to 1 or a GDR picture with
+      NoOutputBeforeRecoveryFlag equal to 1.
+
+   Coding Tree Block (CTB):
+      An NxN block of samples for some value of N such that the division
+      of a component into CTBs is a partitioning.
+
+   Coding tree unit (CTU):
+      A CTB of luma samples, two corresponding CTBs of chroma samples of
+      a picture that has three sample arrays, or a CTB of samples of a
+      monochrome picture or a picture that is coded using three separate
+      colour planes and syntax structures used to code the samples.
+
+   Coding Unit (CU):
+      A coding block of luma samples, two corresponding coding blocks of
+      chroma samples of a picture that has three sample arrays in the
+      single tree mode, or a coding block of luma samples of a picture
+      that has three sample arrays in the dual tree mode, or two coding
+      blocks of chroma samples of a picture that has three sample arrays
+      in the dual tree mode, or a coding block of samples of a
+      monochrome picture, and syntax structures used to code the
+      samples.
+
+   Decoding Capability Information (DCI):
+      A syntax structure containing syntax elements that apply to the
+      entire bitstream.
+
+   Decoded picture buffer (DPB):
+      A buffer holding decoded pictures for reference, output
+      reordering, or output delay specified for the hypothetical
+      reference decoder.
+
+   Gradual decoding refresh (GDR) picture:
+      A picture for which each VCL NAL unit has nal_unit_type equal to
+      GDR_NUT.
+
+   Instantaneous decoding refresh (IDR) PU:
+      A PU in which the coded picture is an IDR picture.
+
+   Instantaneous decoding refresh (IDR) picture:
+      An IRAP picture for which each VCL NAL unit has nal_unit_type
+      equal to IDR_W_RADL or IDR_N_LP.
+
+   Intra random access point (IRAP) AU:
+      An AU in which there is a PU for each layer in the CVS and the
+      coded picture in each PU is an IRAP picture.
+
+   Intra random access point (IRAP) PU:
+      A PU in which the coded picture is an IRAP picture.
+
+   Intra random access point (IRAP) picture:
+      A coded picture for which all VCL NAL units have the same value of
+      nal_unit_type in the range of IDR_W_RADL to CRA_NUT, inclusive.
+
+   Layer:
+      A set of VCL NAL units that all have a particular value of
+      nuh_layer_id and the associated non-VCL NAL units.
+
+   Network abstraction layer (NAL) unit:
+      A syntax structure containing an indication of the type of data to
+      follow and bytes containing that data in the form of an RBSP
+      interspersed as necessary with emulation prevention bytes.
+
+   Network abstraction layer (NAL) unit stream:
+      A sequence of NAL units.
+
+   Output Layer Set (OLS):
+      A set of layers for which one or more layers are specified as the
+      output layers.
+
+   Operation point (OP):
+      A temporal subset of an OLS, identified by an OLS index and a
+      highest value of TemporalId.
+
+   Picture Header (PH):
+      A syntax structure containing syntax elements that apply to all
+      slices of a coded picture.
+
+   Picture parameter set (PPS):
+      A syntax structure containing syntax elements that apply to zero
+      or more entire coded pictures as determined by a syntax element
+      found in each slice header.
+
+   Picture unit (PU):
+      A set of NAL units that are associated with each other according
+      to a specified classification rule, are consecutive in decoding
+      order, and contain exactly one coded picture.
+
+   Random access:
+      The act of starting the decoding process for a bitstream at a
+      point other than the beginning of the bitstream.
+
+   Raw Byte Sequence Payload (RBSP):
+      A syntax structure containing an integer number of bytes that is
+      encapsulated in a NAL unit and is either empty or has the form of
+      a string of data bits containing syntax elements followed by an
+      RBSP stop bit and zero or more subsequent bits equal to 0.
+
+   Sequence parameter set (SPS):
+      A syntax structure containing syntax elements that apply to zero
+      or more entire CLVSs as determined by the content of a syntax
+      element found in the PPS referred to by a syntax element found in
+      each picture header.
+
+   Slice:
+      An integer number of complete tiles or an integer number of
+      consecutive complete CTU rows within a tile of a picture that are
+      exclusively contained in a single NAL unit.
+
+   Slice header (SH):
+      A part of a coded slice containing the data elements pertaining to
+      all tiles or CTU rows within a tile represented in the slice.
+
+   Sublayer:
+      A temporal scalable layer of a temporal scalable bitstream
+      consisting of VCL NAL units with a particular value of the
+      TemporalId variable, and the associated non-VCL NAL units.
+
+   Subpicture:
+      A rectangular region of one or more slices within a picture.
+
+   Sublayer representation:
+      A subset of the bitstream consisting of NAL units of a particular
+      sublayer and the lower sublayers.
+
+   Tile:
+      A rectangular region of CTUs within a particular tile column and a
+      particular tile row in a picture.
+
+   Tile column:
+      A rectangular region of CTUs having a height equal to the height
+      of the picture and a width specified by syntax elements in the
+      picture parameter set.
+
+   Tile row:
+      A rectangular region of CTUs having a height specified by syntax
+      elements in the picture parameter set and a width equal to the
+      width of the picture.
+
+   Video coding layer (VCL) NAL unit:
+      A collective term for coded slice NAL units and the subset of NAL
+      units that have reserved values of nal_unit_type that are
+      classified as VCL NAL units in this Specification.
+
+3.1.2.  Definitions Specific to This Memo
+
+   Media-Aware Network Element (MANE):
+      A network element, such as a middlebox, selective forwarding unit,
+      or application-layer gateway that is capable of parsing certain
+      aspects of the RTP payload headers or the RTP payload and reacting
+      to their contents.
+
+         |  Informative note: The concept of a MANE goes beyond normal
+         |  routers or gateways in that a MANE has to be aware of the
+         |  signaling (e.g., to learn about the payload type mappings of
+         |  the media streams), and in that it has to be trusted when
+         |  working with Secure RTP (SRTP).  The advantage of using
+         |  MANEs is that they allow packets to be dropped according to
+         |  the needs of the media coding.  For example, if a MANE has
+         |  to drop packets due to congestion on a certain link, it can
+         |  identify and remove those packets whose elimination produces
+         |  the least adverse effect on the user experience.  After
+         |  dropping packets, MANEs must rewrite RTCP packets to match
+         |  the changes to the RTP stream, as specified in Section 7 of
+         |  [RFC3550].
+
+   NAL unit decoding order:
+      A NAL unit order that conforms to the constraints on NAL unit
+      order given in Section 7.4.2.4 in [VVC], follow the order of NAL
+      units in the bitstream.
+
+   RTP stream (see [RFC7656]):
+      Within the scope of this memo, one RTP stream is utilized to
+      transport a VVC bitstream, which may contain one or more layers,
+      and each layer may contain one or more temporal sublayers.
+
+   Transmission order:
+      The order of packets in ascending RTP sequence number order (in
+      modulo arithmetic).  Within an aggregation packet, the NAL unit
+      transmission order is the same as the order of appearance of NAL
+      units in the packet.
+
+3.2.  Abbreviations
+
+   AU      Access Unit
+
+   AP      Aggregation Packet
+
+   APS     Adaptation Parameter Set
+
+   CTU     Coding Tree Unit
+
+   CVS     Coded Video Sequence
+
+   DPB     Decoded Picture Buffer
+
+   DCI     Decoding Capability Information
+
+   DON     Decoding Order Number
+
+   FIR     Full Intra Request
+
+   FU      Fragmentation Unit
+
+   GDR     Gradual Decoding Refresh
+
+   HRD     Hypothetical Reference Decoder
+
+   IDR     Instantaneous Decoding Refresh
+
+   IRAP    Intra Random Access Point
+
+   MANE    Media-Aware Network Element
+
+   MTU     Maximum Transfer Unit
+
+   NAL     Network Abstraction Layer
+
+   NALU    Network Abstraction Layer Unit
+
+   OLS     Output Layer Set
+
+   PLI     Picture Loss Indication
+
+   PPS     Picture Parameter Set
+
+   RPSI    Reference Picture Selection Indication
+
+   SEI     Supplemental Enhancement Information
+
+   SLI     Slice Loss Indication
+
+   SPS     Sequence Parameter Set
+
+   VCL     Video Coding Layer
+
+   VPS     Video Parameter Set
+
+4.  RTP Payload Format
+
+4.1.  RTP Header Usage
+
+   The format of the RTP header is specified in [RFC3550] (reprinted as
+   Figure 2 for convenience).  This payload format uses the fields of
+   the header in a manner consistent with that specification.
+
+   The RTP payload (and the settings for some RTP header bits) for
+   aggregation packets and fragmentation units are specified in Sections
+   4.3.2 and 4.3.3, respectively.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           timestamp                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                             ....                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 2: RTP Header According to RFC 3550
+
+   The RTP header information to be set according to this RTP payload
+   format is set as follows:
+
+   Marker bit (M): 1 bit
+      Set for the last packet, in transmission order, among each set of
+      packets that contain NAL units of one access unit.  This is in
+      line with the normal use of the M bit in video formats to allow an
+      efficient playout buffer handling.
+
+   Payload Type (PT): 7 bits
+      The assignment of an RTP payload type for this new packet format
+      is outside the scope of this document and will not be specified
+      here.  The assignment of a payload type has to be performed either
+      through the profile used or in a dynamic way.
+
+   Sequence Number (SN): 16 bits
+      Set and used in accordance with [RFC3550].
+
+   Timestamp: 32 bits
+      The RTP timestamp is set to the sampling timestamp of the content.
+      A 90 kHz clock rate MUST be used.  If the NAL unit has no timing
+      properties of its own (e.g., parameter set and SEI NAL units), the
+      RTP timestamp MUST be set to the RTP timestamp of the coded
+      pictures of the access unit in which the NAL unit (according to
+      Section 7.4.2.4 of [VVC]) is included.  Receivers MUST use the RTP
+      timestamp for the display process, even when the bitstream
+      contains picture timing SEI messages or decoding unit information
+      SEI messages, as specified in [VVC].
+
+         |  Informative note: When picture timing SEI messages are
+         |  present, the RTP sender is responsible to ensure that the
+         |  RTP timestamps are consistent with the timing information
+         |  carried in the picture timing SEI messages.
+
+   Synchronization source (SSRC): 32 bits
+      Used to identify the source of the RTP packets.  A single SSRC is
+      used for all parts of a single bitstream.
+
+4.2.  Payload Header Usage
+
+   The first two bytes of the payload of an RTP packet are referred to
+   as the payload header.  The payload header consists of the same
+   fields (F, Z, LayerId, Type, and TID) as the NAL unit header shown in
+   Section 1.1.4, irrespective of the type of the payload structure.
+
+   The TID value indicates (among other things) the relative importance
+   of an RTP packet, for example, because NAL units belonging to higher
+   temporal sublayers are not used for the decoding of lower temporal
+   sublayers.  A lower value of TID indicates a higher importance.  More
+   important NAL units MAY be better protected against transmission
+   losses than less-important NAL units.
+
+4.3.  Payload Structures
+
+   Three different types of RTP packet payload structures are specified.
+   A receiver can identify the type of an RTP packet payload through the
+   Type field in the payload header.
+
+   The three different payload structures are as follows:
+
+   *  Single NAL unit packet: Contains a single NAL unit in the payload,
+      and the NAL unit header of the NAL unit also serves as the payload
+      header.  This payload structure is specified in Section 4.3.1.
+
+   *  Aggregation Packet (AP): Contains more than one NAL unit within
+      one access unit.  This payload structure is specified in
+      Section 4.3.2.
+
+   *  Fragmentation Unit (FU): Contains a subset of a single NAL unit.
+      This payload structure is specified in Section 4.3.3.
+
+4.3.1.  Single NAL Unit Packets
+
+   A single NAL unit packet contains exactly one NAL unit and consists
+   of a payload header, as defined in Table 5 of [VVC] (denoted here as
+   PayloadHdr), following with a conditional 16-bit DONL field (in
+   network byte order), and the NAL unit payload data (the NAL unit
+   excluding its NAL unit header) of the contained NAL unit, as shown in
+   Figure 3.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |           PayloadHdr          |      DONL (conditional)       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     |                  NAL unit payload data                        |
+     |                                                               |
+     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                               :...OPTIONAL RTP padding        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+            Figure 3: The Structure of a Single NAL Unit Packet
+
+   The DONL field, when present, specifies the value of the 16 least
+   significant bits of the decoding order number of the contained NAL
+   unit.  If sprop-max-don-diff (defined in Section 7.2) is greater than
+   0, the DONL field MUST be present, and the variable DON for the
+   contained NAL unit is derived as equal to the value of the DONL
+   field.  Otherwise (sprop-max-don-diff is equal to 0), the DONL field
+   MUST NOT be present.
+
+4.3.2.  Aggregation Packets (APs)
+
+   Aggregation packets (APs) can reduce packetization overhead for small
+   NAL units, such as most of the non-VCL NAL units, which are often
+   only a few octets in size.
+
+   An AP aggregates NAL units of one access unit, and it MUST NOT
+   contain NAL units from more than one AU.  Each NAL unit to be carried
+   in an AP is encapsulated in an aggregation unit.  NAL units
+   aggregated in one AP are included in NAL-unit-decoding order.
+
+   An AP consists of a payload header, as defined in Table 5 of [VVC]
+   (denoted here as PayloadHdr with Type=28), followed by two or more
+   aggregation units, as shown in Figure 4.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    PayloadHdr (Type=28)       |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+    |                                                               |
+    |             two or more aggregation units                     |
+    |                                                               |
+    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                               :...OPTIONAL RTP padding        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 4: The Structure of an Aggregation Packet
+
+   The fields in the payload header of an AP are set as follows.  The F
+   bit MUST be equal to 0 if the F bit of each aggregated NAL unit is
+   equal to zero; otherwise, it MUST be equal to 1.  The Type field MUST
+   be equal to 28.
+
+   The value of LayerId MUST be equal to the lowest value of LayerId of
+   all the aggregated NAL units.  The value of TID MUST be the lowest
+   value of TID of all the aggregated NAL units.
+
+      |  Informative note: All VCL NAL units in an AP have the same TID
+      |  value since they belong to the same access unit.  However, an
+      |  AP may contain non-VCL NAL units for which the TID value in the
+      |  NAL unit header may be different than the TID value of the VCL
+      |  NAL units in the same AP.
+
+      |  Informative note: If a system envisions subpicture-level or
+      |  picture-level modifications, for example, by removing
+      |  subpictures or pictures of a particular layer, a good design
+      |  choice on the sender's side would be to aggregate NAL units
+      |  belonging to only the same subpicture or picture of a
+      |  particular layer.
+
+   An AP MUST carry at least two aggregation units and can carry as many
+   aggregation units as necessary; however, the total amount of data in
+   an AP obviously MUST fit into an IP packet, and the size SHOULD be
+   chosen so that the resulting IP packet is smaller than the MTU size
+   in order to avoid IP layer fragmentation.  An AP MUST NOT contain the
+   FUs specified in Section 4.3.3.  APs MUST NOT be nested, i.e., an AP
+   cannot contain another AP.
+
+   The first aggregation unit in an AP consists of a conditional 16-bit
+   DONL field (in network byte order), followed by 16 bits of unsigned
+   size information (in network byte order) that indicate the size of
+   the NAL unit in bytes (excluding these two octets but including the
+   NAL unit header), followed by the NAL unit itself, including its NAL
+   unit header, as shown in Figure 5.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |               :       DONL (conditional)      |   NALU size   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   NALU size   |                                               |
+    +-+-+-+-+-+-+-+-+         NAL unit                              |
+    |                                                               |
+    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                               :
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 5: The Structure of the First Aggregation Unit in an AP
+
+      |  Informative note: The first octet of Figure 5 (indicated by the
+      |  first colon) belongs to a previous aggregation unit.  It is
+      |  depicted to emphasize that aggregation units are octet aligned
+      |  only.  Similarly, the NAL unit carried in the aggregation unit
+      |  can terminate at the octet boundary.
+
+   The DONL field, when present, specifies the value of the 16 least
+   significant bits of the decoding order number of the aggregated NAL
+   unit.
+
+   If sprop-max-don-diff is greater than 0, the DONL field MUST be
+   present in an aggregation unit that is the first aggregation unit in
+   an AP, and the variable DON for the aggregated NAL unit is derived as
+   equal to the value of the DONL field, and the variable DON for an
+   aggregation unit that is not the first aggregation unit in an AP-
+   aggregated NAL unit is derived as equal to the DON of the preceding
+   aggregated NAL unit in the same AP plus 1 modulo 65536.  Otherwise
+   (sprop-max-don-diff is equal to 0), the DONL field MUST NOT be
+   present in an aggregation unit that is the first aggregation unit in
+   an AP.
+
+   An aggregation unit that is not the first aggregation unit in an AP
+   will be followed immediately by 16 bits of unsigned size information
+   (in network byte order) that indicate the size of the NAL unit in
+   bytes (excluding these two octets but including the NAL unit header),
+   followed by the NAL unit itself, including its NAL unit header, as
+   shown in Figure 6.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |               :       NALU size               |   NAL unit    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
+    |                                                               |
+    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                               :
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+    Figure 6: The Structure of an Aggregation Unit That Is Not the First
+                         Aggregation Unit in an AP
+
+      |  Informative note: The first octet of Figure 6 (indicated by the
+      |  first colon) belongs to a previous aggregation unit.  It is
+      |  depicted to emphasize that aggregation units are octet aligned
+      |  only.  Similarly, the NAL unit carried in the aggregation unit
+      |  can terminate at the octet boundary.
+
+   Figure 7 presents an example of an AP that contains two aggregation
+   units, labeled as 1 and 2 in the figure, without the DONL field being
+   present.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          RTP Header                           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   PayloadHdr (Type=28)        |         NALU 1 Size           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          NALU 1 HDR           |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         NALU 1 Data           |
+    |                   . . .                                       |
+    |                                                               |
+    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |  . . .        | NALU 2 Size                   | NALU 2 HDR    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | NALU 2 HDR    |                                               |
+    +-+-+-+-+-+-+-+-+              NALU 2 Data                      |
+    |                   . . .                                       |
+    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                               :...OPTIONAL RTP padding        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Figure 7: An Example of an AP Packet Containing Two Aggregation
+                        Units without the DONL Field
+
+   Figure 8 presents an example of an AP that contains two aggregation
+   units, labeled as 1 and 2 in the figure, with the DONL field being
+   present.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          RTP Header                           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   PayloadHdr (Type=28)        |        NALU 1 DONL            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          NALU 1 Size          |            NALU 1 HDR         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    |                 NALU 1 Data   . . .                           |
+    |                                                               |
+    +        . . .                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                               :          NALU 2 Size          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          NALU 2 HDR           |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          NALU 2 Data          |
+    |                                                               |
+    |        . . .                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                               :...OPTIONAL RTP padding        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 8: An Example of an AP Containing Two Aggregation Units
+                            with the DONL Field
+
+4.3.3.  Fragmentation Units
+
+   Fragmentation Units (FUs) are introduced to enable fragmenting a
+   single NAL unit into multiple RTP packets, possibly without
+   cooperation or knowledge of the [VVC] encoder.  A fragment of a NAL
+   unit consists of an integer number of consecutive octets of that NAL
+   unit.  Fragments of the same NAL unit MUST be sent in consecutive
+   order with ascending RTP sequence numbers (with no other RTP packets
+   within the same RTP stream being sent between the first and last
+   fragment).
+
+   When a NAL unit is fragmented and conveyed within FUs, it is referred
+   to as a fragmented NAL unit.  APs MUST NOT be fragmented.  FUs MUST
+   NOT be nested, i.e., an FU cannot contain a subset of another FU.
+
+   The RTP timestamp of an RTP packet carrying an FU is set to the NALU-
+   time of the fragmented NAL unit.
+
+   An FU consists of a payload header as defined in Table 5 of [VVC]
+   (denoted here as PayloadHdr with Type=29), an FU header of one octet,
+   a conditional 16-bit DONL field (in network byte order), and an FU
+   payload (as shown in Figure 9).
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   PayloadHdr (Type=29)        |   FU header   | DONL (cond)   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+    |   DONL (cond) |                                               |
+    |-+-+-+-+-+-+-+-+                                               |
+    |                         FU payload                            |
+    |                                                               |
+    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                               :...OPTIONAL RTP padding        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 9: The Structure of an FU
+
+   The fields in the payload header are set as follows.  The Type field
+   MUST be equal to 29.  The fields F, LayerId, and TID MUST be equal to
+   the fields F, LayerId, and TID, respectively, of the fragmented NAL
+   unit.
+
+   The FU header consists of an S bit, an E bit, an R bit, and a 5-bit
+   FuType field, as shown in Figure 10.
+
+                             +---------------+
+                             |0|1|2|3|4|5|6|7|
+                             +-+-+-+-+-+-+-+-+
+                             |S|E|P|  FuType |
+                             +---------------+
+
+                 Figure 10: The Structure of the FU Header
+
+   The semantics of the FU header fields are as follows:
+
+   S: 1 bit
+      When set to 1, the S bit indicates the start of a fragmented NAL
+      unit, i.e., the first byte of the FU payload is also the first
+      byte of the payload of the fragmented NAL unit.  When the FU
+      payload is not the start of the fragmented NAL unit payload, the S
+      bit MUST be set to 0.
+
+   E: 1 bit
+      When set to 1, the E bit indicates the end of a fragmented NAL
+      unit, i.e., the last byte of the payload is also the last byte of
+      the fragmented NAL unit.  When the FU payload is not the last
+      fragment of a fragmented NAL unit, the E bit MUST be set to 0.
+
+   P: 1 bit
+      When set to 1, the P bit indicates the last FU of the last VCL NAL
+      unit of a coded picture, i.e., the last byte of the FU payload is
+      also the last byte of the last VCL NAL unit of the coded picture.
+      When the FU payload is not the last fragment of the last VCL NAL
+      unit of a coded picture, the P bit MUST be set to 0.
+
+   FuType: 5 bits
+      The field FuType MUST be equal to the field Type of the fragmented
+      NAL unit.
+
+   The DONL field, when present, specifies the value of the 16 least
+   significant bits of the decoding order number of the fragmented NAL
+   unit.
+
+   If sprop-max-don-diff is greater than 0, and the S bit is equal to 1,
+   the DONL field MUST be present in the FU, and the variable DON for
+   the fragmented NAL unit is derived as equal to the value of the DONL
+   field.  Otherwise (sprop-max-don-diff is equal to 0, or the S bit is
+   equal to 0), the DONL field MUST NOT be present in the FU.
+
+   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 FU payload consists of fragments of the payload of the fragmented
+   NAL unit so that, if the FU payloads of consecutive FUs, starting
+   with an FU with the S bit equal to 1 and ending with an FU with the E
+   bit equal to 1, are sequentially concatenated, the payload of the
+   fragmented NAL unit can be reconstructed.  The NAL unit header of the
+   fragmented NAL unit is not included as such in the FU payload, but
+   rather the information of the NAL unit header of the fragmented NAL
+   unit is conveyed in the F, LayerId, and TID fields of the FU payload
+   headers of the FUs and the FuType field of the FU header of the FUs.
+   An FU payload MUST NOT be empty.
+
+   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.
+
+   A receiver in an endpoint or in a MANE MAY aggregate the first n-1
+   fragments of a NAL unit to an (incomplete) NAL unit, even if fragment
+   n of that NAL unit is not received.  In this case, the
+   forbidden_zero_bit of the NAL unit MUST be set to 1 to indicate a
+   syntax violation.
+
+4.4.  Decoding Order Number
+
+   For each 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, 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), AbsDon[n] is
+   derived as follows, where DON[n] is the value of the variable DON for
+   NAL unit n:
+
+   *  If n is equal to 0 (i.e., NAL unit n is the very first NAL unit in
+      transmission order), AbsDon[0] is set equal to DON[0].
+
+   *  Otherwise (n is greater than 0), the following applies for
+      derivation of AbsDon[n]:
+
+         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:
+
+   *  When AbsDon[n] is greater than AbsDon[m], this 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.
+
+   *  When AbsDon[n] is less than AbsDon[m], this indicates that NAL
+      unit n precedes NAL unit m in decoding order.
+
+      |  Informative note: When two consecutive NAL units in the NAL
+      |  unit decoding order have different values of AbsDon, the
+      |  absolute difference between the two AbsDon values may be
+      |  greater than or equal to 1.
+
+      |  Informative note: There are multiple reasons to allow for the
+      |  absolute difference of the values of AbsDon for two consecutive
+      |  NAL units in the NAL unit decoding order to be greater than
+      |  one.  An increment by one is not required, as at the time of
+      |  associating values of AbsDon to NAL units, it may not be known
+      |  whether all NAL units are to be delivered to the receiver.  For
+      |  example, a gateway might not forward VCL NAL units of higher
+      |  sublayers or some SEI NAL units when there is congestion in the
+      |  network.  In another example, the first intra-coded picture of
+      |  a pre-encoded clip is transmitted in advance to ensure that it
+      |  is readily available in the receiver, and when transmitting the
+      |  first intra-coded picture, the originator does not exactly know
+      |  how many NAL units will be encoded before the first intra-coded
+      |  picture of the pre-encoded clip follows in decoding order.
+      |  Thus, the values of AbsDon for the NAL units of the first
+      |  intra-coded picture of the pre-encoded clip have to be
+      |  estimated when they are transmitted, and gaps in values of
+      |  AbsDon may occur.
+
+5.  Packetization Rules
+
+   The following packetization rules apply:
+
+   *  If sprop-max-don-diff is greater than 0, the transmission order of
+      NAL units carried in the RTP stream MAY be different than the NAL
+      unit decoding order.  Otherwise (sprop-max-don-diff is equal to
+      0), the transmission order of NAL units carried in the RTP stream
+      MUST be the same as the NAL unit decoding order.
+
+   *  A NAL unit of a small size SHOULD be encapsulated in an
+      aggregation packet together with one or more other NAL units in
+      order to avoid the unnecessary packetization overhead for small
+      NAL units.  For example, non-VCL NAL units, such as access unit
+      delimiters, parameter sets, or SEI NAL units, are typically small
+      and can often be aggregated with VCL NAL units without violating
+      MTU size constraints.
+
+   *  Each non-VCL NAL unit SHOULD, when possible from an MTU size match
+      viewpoint, be encapsulated in an aggregation packet together with
+      its associated VCL NAL unit, as typically a non-VCL NAL unit would
+      be meaningless without the associated VCL NAL unit being
+      available.
+
+   *  For carrying exactly one NAL unit in an RTP packet, a single NAL
+      unit packet MUST be used.
+
+6.  De-packetization Process
+
+   The general concept behind de-packetization is to get the NAL units
+   out of the RTP packets in an RTP stream and pass them to the decoder
+   in the NAL unit decoding order.
+
+   The de-packetization process is implementation dependent.  Therefore,
+   the following description should be seen as an example of a suitable
+   implementation.  Other schemes may be used as well, as long as the
+   output for the same input is the same as the process described below.
+   The output is the same when the set of output NAL units and their
+   order are both identical.  Optimizations relative to the described
+   algorithms are possible.
+
+   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 27,
+   inclusive, may be passed to the decoder.  NAL-unit-like structures
+   with NAL unit type values in the range of 28 to 31, inclusive, MUST
+   NOT be passed to the decoder.
+
+   The receiver includes a receiver buffer, which is used to compensate
+   for transmission delay jitter within individual RTP streams and to
+   reorder NAL units from transmission order to the NAL unit decoding
+   order.  In this section, the receiver operation is described under
+   the assumption that there is no transmission delay jitter within an
+   RTP stream.  To make a difference from a practical receiver buffer
+   that is also used for compensation of transmission delay jitter, the
+   receiver buffer is hereafter called the de-packetization buffer in
+   this section.  Receivers should also prepare for transmission delay
+   jitter, that is, either reserve separate buffers for transmission
+   delay jitter buffering and de-packetization buffering or use a
+   receiver buffer for both transmission delay jitter and de-
+   packetization.  Moreover, receivers should take transmission delay
+   jitter into account in the buffering operation, e.g., by additional
+   initial buffering before starting of decoding and playback.
+
+   The de-packetization process extracts the NAL units from the RTP
+   packets in an RTP stream as follows.  When an RTP packet carries a
+   single NAL unit packet, the payload of the RTP packet is extracted as
+   a single NAL unit, excluding the DONL field, i.e., third and fourth
+   bytes, when sprop-max-don-diff is greater than 0.  When an RTP packet
+   carries an aggregation packet, several NAL units are extracted from
+   the payload of the RTP packet.  In this case, each NAL unit
+   corresponds to the part of the payload of each aggregation unit that
+   follows the NALU size field, as described in Section 4.3.2.  When an
+   RTP packet carries a Fragmentation Unit (FU), all RTP packets from
+   the first FU (with the S field equal to 1) of the fragmented NAL unit
+   up to the last FU (with the E field equal to 1) of the fragmented NAL
+   unit are collected.  The NAL unit is extracted from these RTP packets
+   by concatenating all FU payloads in the same order as the
+   corresponding RTP packets and appending the NAL unit header with the
+   fields F, LayerId, and TID set to equal the values of the fields F,
+   LayerId, and TID in the payload header of the FUs, respectively, and
+   with the NAL unit type set equal to the value of the field FuType in
+   the FU header of the FUs, as described in Section 4.3.3.
+
+   When sprop-max-don-diff is equal to 0, the de-packetization buffer
+   size is zero bytes, and the NAL units carried in the single RTP
+   stream are directly passed to the decoder in their transmission
+   order, which is identical to their decoding order.
+
+   When sprop-max-don-diff is greater than 0, the process described in
+   the remainder of this section applies.
+
+   There are two buffering states in the receiver: initial buffering and
+   buffering while playing.  Initial buffering starts when the reception
+   is initialized.  After initial buffering, decoding and playback are
+   started, and the buffering-while-playing mode is used.
+
+   Regardless of the buffering state, the receiver stores incoming NAL
+   units in reception order into the de-packetization buffer.  NAL units
+   carried in RTP packets are stored in the de-packetization buffer
+   individually, and the value of AbsDon is calculated and stored for
+   each NAL unit.
+
+   Initial buffering lasts until the difference between the greatest and
+   smallest AbsDon values of the NAL units in the de-packetization
+   buffer is greater than or equal to the value of sprop-max-don-diff.
+
+   After initial buffering, whenever the difference between the greatest
+   and smallest AbsDon values of the NAL units in the de-packetization
+   buffer is greater than or equal to the value of sprop-max-don-diff,
+   the following operation is repeatedly applied until this difference
+   is smaller than sprop-max-don-diff:
+
+      The NAL unit in the de-packetization buffer with the smallest
+      value of AbsDon is removed from the de-packetization buffer and
+      passed to the decoder.
+
+   When no more NAL units are flowing into the de-packetization buffer,
+   all NAL units remaining in the de-packetization buffer are removed
+   from the buffer and passed to the decoder in the order of increasing
+   AbsDon values.
+
+7.  Payload Format Parameters
+
+   This section specifies the optional parameters.  A mapping of the
+   parameters with Session Description Protocol (SDP) [RFC8866] is also
+   provided for applications that use SDP.
+
+   Parameters starting with the string "sprop" for stream properties can
+   be used by a sender to provide a receiver with the properties of the
+   stream that is or will be sent.  The media sender (and not the
+   receiver) selects whether, and with what values, "sprop" parameters
+   are being sent.  This uncommon characteristic of the "sprop"
+   parameters may not be intuitive in the context of some signaling
+   protocol concepts, especially with offer/answer.  Please see
+   Section 7.3.2 for guidance specific to the use of sprop parameters in
+   the offer/answer case.
+
+7.1.  Media Type Registration
+
+   The receiver MUST ignore any parameter unspecified in this memo.
+
+   Type name:  video
+
+   Subtype name:  H266
+
+   Required parameters:  N/A
+
+   Optional parameters:  profile-id, tier-flag, sub-profile-id, interop-
+      constraints, level-id, sprop-sublayer-id, sprop-ols-id, recv-
+      sublayer-id, recv-ols-id, max-recv-level-id, sprop-dci, sprop-vps,
+      sprop-sps, sprop-pps, sprop-sei, max-lsr, max-fps, sprop-max-don-
+      diff, sprop-depack-buf-bytes, depack-buf-cap (refer to Section 7.2
+      for definitions).
+
+   Encoding considerations:  This type is only defined for transfer via
+      RTP [RFC3550].
+
+   Security considerations:  See Section 9 of RFC 9328.
+
+   Interoperability considerations:  N/A
+
+   Published specification:  Please refer to RFC 9328 and VVC coding
+      specification [VVC].
+
+   Applications that use this media type:  Any application that relies
+      on VVC-based video services over RTP
+
+   Fragment identifier considerations:  N/A
+
+   Additional information:  N/A
+
+   Person & email address to contact for further information:
+      Stephan Wenger (stewe@stewe.org)
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  N/A
+
+   Author:  See Authors' Addresses section of RFC 9328.
+
+   Change controller:  IETF <avtcore@ietf.org>
+
+7.2.  Optional Parameters Definition
+
+   profile-id, tier-flag, sub-profile-id, interop-constraints, and
+   level-id:
+      These parameters indicate the profile, the tier, the default
+      level, the sub-profile, and some constraints of the bitstream
+      carried by the RTP stream, or a specific set of the profile, the
+      tier, the default level, the sub-profile, and some constraints the
+      receiver supports.
+
+      The subset of coding tools that may have been used to generate the
+      bitstream or that the receiver supports, as well as some
+      additional constraints, are indicated collectively by profile-id,
+      sub-profile-id, and interop-constraints.
+
+         |  Informative note: There are 128 values of profile-id.  The
+         |  subset of coding tools identified by profile-id can be
+         |  further constrained with up to 255 instances of sub-profile-
+         |  id.  In addition, 68 bits included in interop-constraints,
+         |  which can be extended up to 324 bits, provide means to
+         |  further restrict tools from existing profiles.  To be able
+         |  to support this fine-granular signaling of coding-tool
+         |  subsets with profile-id, sub-profile-id, and interop-
+         |  constraints, it would be safe to require symmetric use of
+         |  these parameters in SDP offer/answer unless recv-ols-id is
+         |  included in the SDP answer for choosing one of the layers
+         |  offered.
+
+      The tier is indicated by tier-flag.  The default level is
+      indicated by level-id.  The tier and the default level specify the
+      limits on values of syntax elements or arithmetic combinations of
+      values of syntax elements that are followed when generating the
+      bitstream or that the receiver supports.
+
+      In SDP offer/answer, when the SDP answer does not include the
+      recv-ols-id parameter that is less than the sprop-ols-id parameter
+      in the SDP offer, the following applies:
+
+      *  The tier-flag, profile-id, sub-profile-id, and interop-
+         constraints parameters MUST be used symmetrically, i.e., the
+         value of each of these parameters in the offer MUST be the same
+         as that in the answer, either explicitly signaled or implicitly
+         inferred.
+
+      *  The level-id parameter is changeable as long as the highest
+         level indicated by the answer is either equal to or lower than
+         that in the offer.  Note that the highest level higher than
+         level-id in the offer for receiving can be included as max-
+         recv-level-id.
+
+      In SDP offer/answer, when the SDP answer does include the recv-
+      ols-id parameter that is less than the sprop-ols-id parameter in
+      the SDP offer, the set of tier-flag, profile-id, sub-profile-id,
+      interop-constraints, and level-id parameters included in the
+      answer MUST be consistent with that for the chosen output layer
+      set as indicated in the SDP offer, with the exception that the
+      level-id parameter in the SDP answer is changeable as long as the
+      highest level indicated by the answer is either lower than or
+      equal to that in the offer.
+
+      More specifications of these parameters, including how they relate
+      to syntax elements specified in [VVC], are provided below.
+
+   profile-id:
+      When profile-id is not present, a value of 1 (i.e., the Main 10
+      profile) MUST be inferred.
+
+      When used to indicate properties of a bitstream, profile-id is
+      derived from the general_profile_idc syntax element that applies
+      to the bitstream in an instance of the profile_tier_level( )
+      syntax structure.
+
+      VVC bitstreams transported over RTP using the technologies of this
+      memo SHOULD contain only a single profile_tier_level( ) structure
+      in the DCI, unless the sender can assure that a receiver can
+      correctly decode the VVC bitstream, regardless of which
+      profile_tier_level( ) structure contained in the DCI was used for
+      deriving profile-id and other parameters for the SDP offer/answer
+      exchange.
+
+      As specified in [VVC], a profile_tier_level( ) syntax structure
+      may be contained in an SPS NAL unit, and one or more
+      profile_tier_level( ) syntax structures may be contained in a VPS
+      NAL unit and in a DCI NAL unit.  One of the following three cases
+      applies to the container NAL unit of the profile_tier_level( )
+      syntax structure containing syntax elements used to derive the
+      values of profile-id, tier-flag, level-id, sub-profile-id, or
+      interop-constraints:
+
+      1.  The container NAL unit is an SPS, the bitstream is a single-
+          layer bitstream, and the profile_tier_level( ) syntax
+          structures in all SPSs referenced by the CVSs in the bitstream
+          have the same values respectively for those
+          profile_tier_level( ) syntax elements.
+
+      2.  The container NAL unit is a VPS, the profile_tier_level( )
+          syntax structure is the one in the VPS that applies to the OLS
+          corresponding to the bitstream, and the profile_tier_level( )
+          syntax structures applicable to the OLS corresponding to the
+          bitstream in all VPSs referenced by the CVSs in the bitstream
+          have the same values respectively for those
+          profile_tier_level( ) syntax elements.
+
+      3.  The container NAL unit is a DCI NAL unit, and the
+          profile_tier_level( ) syntax structures in all DCI NAL units
+          in the bitstream have the same values respectively for those
+          profile_tier_level( ) syntax elements.
+
+      [VVC] allows for multiple profile_tier_level( ) structures in a
+      DCI NAL unit, which may contain different values for the syntax
+      elements used to derive the values of profile-id, tier-flag,
+      level-id, sub-profile-id, or interop-constraints in the different
+      entries.  However, herein defined is only a single profile-id,
+      tier-flag, level-id, sub-profile-id, or interop-constraints.  When
+      signaling these parameters and a DCI NAL unit is present with
+      multiple profile_tier_level( ) structures, these values SHOULD be
+      the same as the first profile_tier_level structure in the DCI,
+      unless the sender has ensured that the receiver can decode the
+      bitstream when a different value is chosen.
+
+   tier-flag, level-id:
+      The value of tier-flag MUST be in the range of 0 to 1, inclusive.
+      The value of level-id MUST be in the range of 0 to 255, inclusive.
+
+      If the tier-flag and level-id parameters are used to indicate
+      properties of a bitstream, they indicate the tier and the highest
+      level the bitstream complies with.
+
+      If the tier-flag and level-id parameters are used for capability
+      exchange, the following applies.  If max-recv-level-id is not
+      present, the default level defined by level-id indicates the
+      highest level the codec wishes to support.  Otherwise, max-recv-
+      level-id indicates the highest level the codec supports for
+      receiving.  For either receiving or sending, all levels that are
+      lower than the highest level supported MUST also be supported.
+
+      If no tier-flag is present, a value of 0 MUST be inferred; if no
+      level-id is present, a value of 51 (i.e., level 3.1) MUST be
+      inferred.
+
+         |  Informative note: The level values currently defined in the
+         |  VVC specification are in the form of "majorNum.minorNum",
+         |  and the value of the level-id for each of the levels is
+         |  equal to majorNum * 16 + minorNum * 3.  It is expected that,
+         |  if any levels are defined in the future, the same convention
+         |  will be used, but this cannot be guaranteed.
+
+      When used to indicate properties of a bitstream, the tier-flag and
+      level-id parameters are derived respectively from the syntax
+      element general_tier_flag, and the syntax element
+      general_level_idc or sub_layer_level_idc[j], that apply to the
+      bitstream in an instance of the profile_tier_level( ) syntax
+      structure.
+
+      If the tier-flag and level-id are derived from the
+      profile_tier_level( ) syntax structure in a DCI NAL unit, the
+      following applies:
+
+      *  tier-flag = general_tier_flag
+
+      *  level-id = general_level_idc
+
+      Otherwise, if the tier-flag and level-id are derived from the
+      profile_tier_level( ) syntax structure in an SPS or VPS NAL unit,
+      and the bitstream contains the highest sublayer representation in
+      the OLS corresponding to the bitstream, the following applies:
+
+      *  tier-flag = general_tier_flag
+
+      *  level-id = general_level_idc
+
+      Otherwise, if the tier-flag and level-id are derived from the
+      profile_tier_level( ) syntax structure in an SPS or VPS NAL unit,
+      and the bitstream does not contain the highest sublayer
+      representation in the OLS corresponding to the bitstream, the
+      following applies, with j being the value of the sprop-sublayer-id
+      parameter:
+
+      *  tier-flag = general_tier_flag
+
+      *  level-id = sub_layer_level_idc[j]
+
+   sub-profile-id:
+      The value of the parameter is a comma-separated (',') list of data
+      using base64 encoding (Section 4 of [RFC4648]) representation
+      without "==" padding.
+
+      When used to indicate properties of a bitstream, sub-profile-id is
+      derived from each of the ptl_num_sub_profiles
+      general_sub_profile_idc[i] syntax elements that apply to the
+      bitstream in a profile_tier_level( ) syntax structure.
+
+   interop-constraints:
+      A base64 encoding (Section 4 of [RFC4648]) representation of the
+      data that includes the ptl_frame_only_constraint_flag syntax
+      element, the ptl_multilayer_enabled_flag syntax element, and the
+      general_constraints_info( ) syntax structure that apply to the
+      bitstream in an instance of the profile_tier_level( ) syntax
+      structure.
+
+      If the interop-constraints parameter is not present, the following
+      MUST be inferred:
+
+      *  ptl_frame_only_constraint_flag = 1
+
+      *  ptl_multilayer_enabled_flag = 0
+
+      *  gci_present_flag in the general_constraints_info( ) syntax
+         structure = 0
+
+      Using interop-constraints for capability exchange results in a
+      requirement on any bitstream to be compliant with the interop-
+      constraints.
+
+   sprop-sublayer-id:
+      This parameter MAY be used to indicate the highest allowed value
+      of TID in the bitstream.  When not present, the value of sprop-
+      sublayer-id is inferred to be equal to 6.
+
+      The value of sprop-sublayer-id MUST be in the range of 0 to 6,
+      inclusive.
+
+   sprop-ols-id:
+      This parameter MAY be used to indicate the OLS that the bitstream
+      applies to.  When not present, the value of sprop-ols-id is
+      inferred to be equal to TargetOlsIdx, as specified in
+      Section 8.1.1 of [VVC].  If this optional parameter is present,
+      sprop-vps MUST also be present or its content MUST be known a
+      priori at the receiver.
+
+      The value of sprop-ols-id MUST be in the range of 0 to 256,
+      inclusive.
+
+         |  Informative note: VVC allows having up to 257 output layer
+         |  sets indicated in the VPS, as the number of output layer
+         |  sets minus 2 is indicated with a field of 8 bits.
+
+   recv-sublayer-id:
+      This parameter MAY be used to signal a receiver's choice of the
+      offered or declared sublayer representations in sprop-vps and
+      sprop-sps.  The value of recv-sublayer-id indicates the TID of the
+      highest sublayer that a receiver supports.  When not present, the
+      value of recv-sublayer-id is inferred to be equal to the value of
+      the sprop-sublayer-id parameter in the SDP offer.
+
+      The value of recv-sublayer-id MUST be in the range of 0 to 6,
+      inclusive.
+
+   recv-ols-id:
+      This parameter MAY be used to signal a receiver's choice of the
+      offered or declared output layer sets in sprop-vps.  The value of
+      recv-ols-id indicates the OLS index of the bitstream that a
+      receiver supports.  When not present, the value of recv-ols-id is
+      inferred to be equal to the value of the sprop-ols-id parameter
+      inferred from or indicated in the SDP offer.  When present, the
+      value of recv-ols-id must be included only when sprop-ols-id was
+      received and must refer to an output layer set in the VPS that
+      includes no layers other than all or a subset of the layers of the
+      OLS referred to by sprop-ols-id.  If this optional parameter is
+      present, sprop-vps must have been received or its content must be
+      known a priori at the receiver.
+
+      The value of recv-ols-id MUST be in the range of 0 to 256,
+      inclusive.
+
+   max-recv-level-id:
+      This parameter MAY be used to indicate the highest level a
+      receiver supports.
+
+      The value of max-recv-level-id MUST be in the range of 0 to 255,
+      inclusive.
+
+      When max-recv-level-id is not present, the value is inferred to be
+      equal to level-id.
+
+      max-recv-level-id MUST NOT be present when the highest level the
+      receiver supports is not higher than the default level.
+
+   sprop-dci:
+      This parameter MAY be used to convey a decoding capability
+      information NAL unit of the bitstream for out-of-band
+      transmission.  The parameter MAY also be used for capability
+      exchange.  The value of the parameter is a base64 encoding
+      (Section 4 of [RFC4648]) representation of the decoding capability
+      information NAL unit, as specified in Section 7.3.2.1 of [VVC].
+
+   sprop-vps:
+      This parameter MAY be used to convey any video parameter set to
+      the NAL unit of the bitstream for out-of-band transmission of
+      video parameter sets.  The parameter MAY also be used for
+      capability exchange and to indicate substream characteristics
+      (i.e., properties of output layer sets and sublayer
+      representations, as defined in [VVC]).  The value of the parameter
+      is a comma-separated (',') list of base64 encoding (Section 4 of
+      [RFC4648]) representations of the video parameter set NAL units,
+      as specified in Section 7.3.2.3 of [VVC].
+
+      The sprop-vps parameter MAY contain one or more than one video
+      parameter set NAL units.  However, all other video parameter sets
+      contained in the sprop-vps parameter MUST be consistent with the
+      first video parameter set in the sprop-vps parameter.  A video
+      parameter set vpsB is said to be consistent with another video
+      parameter set vpsA if the number of OLSs in vpsA and vpsB are the
+      same and any decoder that conforms to the profile, tier, level,
+      and constraints indicated by the data starting from the syntax
+      element general_profile_idc to the syntax structure
+      general_constraints_info(), inclusive, in the profile_tier_level(
+      ) syntax structure corresponding to any OLS with index olsIdx in
+      vpsA can decode any CVS(s) referencing vpsB when TargetOlsIdx is
+      equal to olsIdx that conforms to the profile, tier, level, and
+      constraints indicated by the data starting from the syntax element
+      general_profile_idc to the syntax structure
+      general_constraints_info(), inclusive, in the profile_tier_level(
+      ) syntax structure corresponding to the OLS with index
+      TargetOlsIdx in vpsB.
+
+   sprop-sps:
+      This parameter MAY be used to convey sequence parameter set NAL
+      units of the bitstream for out-of-band transmission of sequence
+      parameter sets.  The value of the parameter is a comma-separated
+      (',') list of base64 encoding (Section 4 of [RFC4648])
+      representations of the sequence parameter set NAL units, as
+      specified in Section 7.3.2.4 of [VVC].
+
+      A sequence parameter set spsB is said to be consistent with
+      another sequence parameter set spsA if any decoder that conforms
+      to the profile, tier, level, and constraints indicated by the data
+      starting from the syntax element general_profile_idc to the syntax
+      structure general_constraints_info(), inclusive, in the
+      profile_tier_level( ) syntax structure in spsA can decode any
+      CLVS(s) referencing spsB that conforms to the profile, tier,
+      level, and constraints indicated by the data starting from the
+      syntax element general_profile_idc to the syntax structure
+      general_constraints_info(), inclusive, in the profile_tier_level(
+      ) syntax structure in spsB.
+
+   sprop-pps:
+      This parameter MAY be used to convey picture parameter set NAL
+      units of the bitstream for out-of-band transmission of picture
+      parameter sets.  The value of the parameter is a comma-separated
+      (',') list of base64 encoding (Section 4 of [RFC4648])
+      representations of the picture parameter set NAL units, as
+      specified in Section 7.3.2.5 of [VVC].
+
+   sprop-sei:
+      This parameter MAY be used to convey one or more SEI messages that
+      describe bitstream characteristics.  When present, a decoder can
+      rely on the bitstream characteristics that are described in the
+      SEI messages for the entire duration of the session, independently
+      from the persistence scopes of the SEI messages, as specified in
+      [VSEI].
+
+      The value of the parameter is a comma-separated (',') list of
+      base64 encoding (Section 4 of [RFC4648]) representations of SEI
+      NAL units, as specified in [VSEI].
+
+         |  Informative note: Intentionally, no list of applicable or
+         |  inapplicable SEI messages is specified here.  Conveying
+         |  certain SEI messages in sprop-sei may be sensible in some
+         |  application scenarios and meaningless in others.  However, a
+         |  few examples are described below:
+         |  
+         |  In an environment where the bitstream was created from film-
+         |  based source material, and no splicing is going to occur
+         |  during the lifetime of the session, the film grain
+         |  characteristics SEI message is likely meaningful, and
+         |  sending it in sprop-sei, rather than in the bitstream at
+         |  each entry point, may help with saving bits and allows one
+         |  to configure the renderer only once, avoiding unwanted
+         |  artifacts.
+         |  
+         |  Examples for SEI messages that would be meaningless to be
+         |  conveyed in sprop-sei include the decoded picture hash SEI
+         |  message (it is close to impossible that all decoded pictures
+         |  have the same hashtag) or the filler payload SEI message (as
+         |  there is no point in just having more bits in SDP).
+
+   max-lsr:
+      The max-lsr MAY be used to signal the capabilities of a receiver
+      implementation and MUST NOT be used for any other purpose.  The
+      value of max-lsr is an integer indicating the maximum processing
+      rate in units of luma samples per second.  The max-lsr parameter
+      signals that the receiver is capable of decoding video at a higher
+      rate than is required by the highest level.
+
+         |  Informative note: When the OPTIONAL media type parameters
+         |  are used to signal the properties of a bitstream, and max-
+         |  lsr is not present, the values of tier-flag, profile-id,
+         |  sub-profile-id, interop-constraints, and level-id must
+         |  always be such that the bitstream complies fully with the
+         |  specified profile, sub-profile, tier, level, and interop-
+         |  constraints.
+
+      When max-lsr is signaled, the receiver MUST be able to decode
+      bitstreams that conform to the highest level, with the exception
+      that the MaxLumaSr value in Table A.3 of [VVC] for the highest
+      level is replaced with the value of max-lsr.  Senders MAY use this
+      knowledge to send pictures of a given size at a higher picture
+      rate than is indicated in the highest level.
+
+      When not present, the value of max-lsr is inferred to be equal to
+      the value of MaxLumaSr given in Table A.3 of [VVC] for the highest
+      level.
+
+      The value of max-lsr MUST be in the range of MaxLumaSr to 16 *
+      MaxLumaSr, inclusive, where MaxLumaSr is given in Table A.3 of
+      [VVC] for the highest level.
+
+   max-fps:
+      The value of max-fps is an integer indicating the maximum picture
+      rate in units of pictures per 100 seconds that can be effectively
+      processed by the receiver.  The max-fps parameter MAY be used to
+      signal that the receiver has a constraint in that it is not
+      capable of processing video effectively at the full picture rate
+      that is implied by the highest level and, when present, max-lsr.
+
+      The value of max-fps is not necessarily the picture rate at which
+      the maximum picture size can be sent; it constitutes a constraint
+      on maximum picture rate for all resolutions.
+
+         |  Informative note: The max-fps parameter is semantically
+         |  different from max-lsr in that max-fps is used to signal a
+         |  constraint, lowering the maximum picture rate from what is
+         |  implied by other parameters.
+
+      The encoder MUST use a picture rate equal to or less than this
+      value.  In cases where the max-fps parameter is absent, the
+      encoder is free to choose any picture rate according to the
+      highest level and any signaled optional parameters.
+
+      The value of max-fps MUST be smaller than or equal to the full
+      picture rate that is implied by the highest level and, when
+      present, max-lsr.
+
+   sprop-max-don-diff:
+      If there is no NAL unit naluA that is followed in transmission
+      order by any NAL unit preceding naluA in decoding order (i.e., the
+      transmission order of the NAL units is the same as the decoding
+      order), the value of this parameter MUST be equal to 0.
+
+      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.
+
+   sprop-depack-buf-bytes:
+      This parameter signals the required size of the de-packetization
+      buffer in units of bytes.  The value of the parameter MUST be
+      greater than or equal to the maximum buffer occupancy (in units of
+      bytes) of the de-packetization buffer, as specified in Section 6.
+
+      The value of sprop-depack-buf-bytes MUST be an integer in the
+      range of 0 to 4294967295, inclusive.
+
+      When sprop-max-don-diff is present and greater than 0, this
+      parameter MUST be present and the value MUST be greater than 0.
+      When not present, the value of sprop-depack-buf-bytes is inferred
+      to be equal to 0.
+
+         |  Informative note: The value of sprop-depack-buf-bytes
+         |  indicates the required size of the de-packetization buffer
+         |  only.  When network jitter can occur, an appropriately sized
+         |  jitter buffer has to be available as well.
+
+   depack-buf-cap:
+      This parameter signals the capabilities of a receiver
+      implementation and indicates the amount of de-packetization buffer
+      space in units of bytes that the receiver has available for
+      reconstructing the NAL unit decoding order from NAL units carried
+      in the RTP stream.  A receiver is able to handle any RTP stream
+      for which the value of the sprop-depack-buf-bytes parameter is
+      smaller than or equal to this parameter.
+
+      When not present, the value of depack-buf-cap is inferred to be
+      equal to 4294967295.  The value of depack-buf-cap MUST be an
+      integer in the range of 1 to 4294967295, inclusive.
+
+         |  Informative note: depack-buf-cap indicates the maximum
+         |  possible size of the de-packetization buffer of the receiver
+         |  only, without allowing for network jitter.
+
+7.3.  SDP Parameters
+
+   The receiver MUST ignore any parameter unspecified in this memo.
+
+7.3.1.  Mapping of Payload Type Parameters to SDP
+
+   The media type video/H266 string is mapped to fields in the Session
+   Description Protocol (SDP) [RFC8866] as follows:
+
+   *  The media name in the "m=" line of SDP MUST be video.
+
+   *  The encoding name in the "a=rtpmap" line of SDP MUST be H266 (the
+      media subtype).
+
+   *  The clock rate in the "a=rtpmap" line MUST be 90000.
+
+   *  The OPTIONAL parameters profile-id, tier-flag, sub-profile-id,
+      interop-constraints, level-id, sprop-sublayer-id, sprop-ols-id,
+      recv-sublayer-id, recv-ols-id, max-recv-level-id, max-lsr, max-
+      fps, sprop-max-don-diff, sprop-depack-buf-bytes, and depack-buf-
+      cap, when present, MUST be included in the "a=fmtp" line of SDP.
+      The fmtp line is expressed as a media type string, in the form of
+      a semicolon-separated list of parameter=value pairs.
+
+   *  The OPTIONAL parameters sprop-vps, sprop-sps, sprop-pps, sprop-
+      sei, and sprop-dci, when present, MUST be included in the "a=fmtp"
+      line of SDP or conveyed using the "fmtp" source attribute as
+      specified in Section 6.3 of [RFC5576].  For a particular media
+      format (i.e., RTP payload type), sprop-vps, sprop-sps, sprop-pps,
+      sprop-sei, or sprop-dci MUST NOT be both included in the "a=fmtp"
+      line of SDP and conveyed using the "fmtp" source attribute.  When
+      included in the "a=fmtp" line of SDP, those parameters are
+      expressed as a media type string, in the form of a semicolon-
+      separated list of parameter=value pairs.  When conveyed in the
+      "a=fmtp" line of SDP for a particular payload type, the parameters
+      sprop-vps, sprop-sps, sprop-pps, sprop-sei, and sprop-dci MUST be
+      applied to each SSRC with the payload type.  When conveyed using
+      the "fmtp" source attribute, these parameters are only associated
+      with the given source and payload type as parts of the "fmtp"
+      source attribute.
+
+      |  Informative note: Conveyance of sprop-vps, sprop-sps, and
+      |  sprop-pps using the "fmtp" source attribute allows for out-of-
+      |  band transport of parameter sets in topologies like Topo-Video-
+      |  switch-MCU, as specified in [RFC7667].
+
+   A general usage of media representation in SDP is as follows:
+
+           m=video 49170 RTP/AVP 98
+           a=rtpmap:98 H266/90000
+           a=fmtp:98 profile-id=1;
+             sprop-vps=<video parameter sets data>;
+             sprop-sps=<sequence parameter set data>;
+             sprop-pps=<picture parameter set data>;
+
+   A SIP offer/answer exchange wherein both parties are expected to both
+   send and receive could look like the following.  Only the media
+   codec-specific parts of the SDP are shown.  Some lines are wrapped
+   due to text constraints.
+
+     Offerer->Answerer:
+           m=video 49170 RTP/AVP 98
+           a=rtpmap:98 H266/90000
+           a=fmtp:98 profile-id=1; level_id=83;
+
+   The above represents an offer for symmetric video communication using
+   [VVC] and its payload specification at the main profile and level 5.1
+   (and as the levels are downgradable, all lower levels).  Informally
+   speaking, this offer tells the receiver of the offer that the sender
+   is willing to receive up to 4Kp60 resolution at the maximum bitrates
+   specified in [VVC].  At the same time, if this offer were accepted
+   "as is", the offer can expect that the answerer would be able to
+   receive and properly decode H.266 media up to and including level
+   5.1.
+
+     Answerer->Offerer:
+           m=video 49170 RTP/AVP 98
+           a=rtpmap:98 H266/90000
+           a=fmtp:98 profile-id=1; level_id=67
+
+   With this answer to the offer above, the system receiving the offer
+   advises the offerer that it is incapable of handing H.266 at level
+   5.1 but is capable of decoding 1080p60.  As H.266 video codecs must
+   support decoding at all levels below the maximum level they
+   implement, the resulting user experience would likely be that both
+   systems send video at 1080p60.  However, nothing prevents an encoder
+   from further downgrading its sending to, for example, 720p30 if it
+   were short of cycles or bandwidth or for other reasons.
+
+7.3.2.  Usage with SDP Offer/Answer Model
+
+   This section describes the negotiation of unicast messages using the
+   offer/answer model as described in [RFC3264] and its updates.  The
+   section is split into subsections, covering a) media format
+   configurations not involving non-temporal scalability; b) scalable
+   media format configurations; c) the description of the use of those
+   parameters not involving the media configuration itself but rather
+   the parameters of the payload format design; and d) multicast.
+
+7.3.2.1.  Non-scalable Media Format Configuration
+
+   A non-scalable VVC media configuration is such a configuration where
+   no non-temporal scalability mechanisms are allowed.  In [VVC] version
+   1, it is implied that general_profile_idc indicates one of the
+   following profiles: Main 10, Main 10 Still Picture, Main 10 4:4:4, or
+   Main 10 4:4:4 Still Picture, with general_profile_idc values of 1,
+   65, 33, and 97, respectively.  Note that non-scalable media
+   configurations include temporal scalability inline with VVC's design
+   philosophy and profile structure.
+
+   The following limitations and rules pertaining to the media
+   configuration apply:
+
+   *  The parameters identifying a media format configuration for VVC
+      are profile-id, tier-flag, sub-profile-id, level-id, and interop-
+      constraints.  These media configuration parameters, except level-
+      id, MUST be used symmetrically.
+
+      The answerer MUST structure its answer according to one of the
+      following three options:
+
+      1.  maintain all configuration parameters with the values
+          remaining the same as in the offer for the media format
+          (payload type), with the exception that the value of level-id
+          is changeable as long as the highest level indicated by the
+          answer is not higher than that indicated by the offer;
+
+      2.  include in the answer the recv-sublayer-id parameter, with a
+          value less than the sprop-sublayer-id parameter in the offer,
+          for the media format (payload type), and maintain all
+          configuration parameters with the values remaining the same as
+          in the offer for the media format (payload type), with the
+          exception that the value of level-id is changeable as long as
+          the highest level indicated by the answer is not higher than
+          the level indicated by sprop-sps or sprop-vps in offer for the
+          chosen sublayer representation; or
+
+      3.  remove the media format (payload type) completely (when one or
+          more of the parameter values are not supported).
+
+      |  Informative note: The above requirement for symmetric use does
+      |  not apply for level-id and does not apply for the other
+      |  bitstream or RTP stream properties and capability parameters,
+      |  as described in Section 7.3.2.3 below.
+
+   *  To simplify handling and matching of these configurations, the
+      same RTP payload type number used in the offer SHOULD also be used
+      in the answer, as specified in [RFC3264].
+
+   *  The same RTP payload type number used in the offer for the media
+      subtype H266 MUST be used in the answer when the answer includes
+      recv-sublayer-id.  When the answer does not include recv-sublayer-
+      id, the answer MUST NOT contain a payload type number used in the
+      offer for the media subtype H266 unless the configuration is
+      exactly the same as in the offer or the configuration in the
+      answer only differs from that in the offer with a different value
+      of level-id.  The answer MAY contain the recv-sublayer-id
+      parameter if a VVC bitstream contains multiple operation points
+      (using temporal scalability and sublayers) and sprop-sps or sprop-
+      vps is included in the offer where information of sublayers are
+      present in the first sequence parameter set or video parameter set
+      contained in sprop-sps or sprop-vps, respectively.  If sprop-sps
+      or sprop-vps is provided in an offer, an answerer MAY select a
+      particular operation point indicated in the first sequence
+      parameter set or video parameter set contained in sprop-sps or
+      sprop-vps, respectively.  When the answer includes a recv-
+      sublayer-id that is less than a sprop-sublayer-id in the offer,
+      the following applies:
+
+      1.  When the sprop-sps parameter is present, all sequence
+          parameter sets contained in the sprop-sps parameter in the SDP
+          answer and all sequence parameter sets sent in-band for either
+          the offerer-to-answerer direction or the answerer-to-offerer
+          direction MUST be consistent with the first sequence parameter
+          set in the sprop-sps parameter of the offer (see the semantics
+          of sprop-sps in Section 7.1 of this document on one sequence
+          parameter set being consistent with another sequence parameter
+          set).
+
+      2.  When the sprop-vps parameter is present, all video parameter
+          sets contained in the sprop-vps parameter in the SDP answer
+          and all video parameter sets sent in-band for either the
+          offerer-to-answerer direction or the answerer-to-offerer
+          direction MUST be consistent with the first video parameter
+          set in the sprop-vps parameter of the offer (see the semantics
+          of sprop-vps in Section 7.1 of this document on one video
+          parameter set being consistent with another video parameter
+          set).
+
+      3.  The bitstream sent in either direction MUST conform to the
+          profile, tier, level, and constraints of the chosen sublayer
+          representation, as indicated by the profile_tier_level( )
+          syntax structure in the first sequence parameter set in the
+          sprop-sps parameter or by the first profile_tier_level( )
+          syntax structure in the first video parameter set in the
+          sprop-vps parameter of the offer.
+
+      |  Informative note: When an offerer receives an answer that does
+      |  not include recv-sublayer-id, it has to compare payload types
+      |  not declared in the offer based on the media type (i.e., video/
+      |  H266) and the above media configuration parameters with any
+      |  payload types it has already declared.  This will enable it to
+      |  determine whether the configuration in question is new or if it
+      |  is equivalent to configuration already offered, since a
+      |  different payload type number may be used in the answer.  The
+      |  ability to perform operation point selection enables a receiver
+      |  to utilize the temporal scalable nature of a VVC bitstream.
+
+7.3.2.2.  Scalable Media Format Configuration
+
+   A scalable VVC media configuration is such a configuration where non-
+   temporal scalability mechanisms are allowed.  In [VVC] version 1, it
+   is implied that general_profile_idc indicates one of the following
+   profiles: Multilayer Main 10 and Multilayer Main 10 4:4:4, with
+   general_profile_idc values of 17 and 49, respectively.
+
+   The following limitations and rules pertaining to the media
+   configuration apply.  They are listed in an order that would be
+   logical for an implementation to follow:
+
+   *  The parameters identifying a media format configuration for
+      scalable VVC are profile-id, tier-flag, sub-profile-id, level-id,
+      interop-constraints, and sprop-vps.  These media configuration
+      parameters, except level-id, MUST be used symmetrically, except as
+      noted below.
+
+   *  The answerer MAY include a level-id that MUST be lower than or
+      equal to the level-id indicated in the offer (either expressed by
+      level-id in the offer or implied by the default level, as
+      specified in Section 7.1).
+
+   *  When sprop-ols-id is present in an offer, sprop-vps MUST also be
+      present in the same offer and include at least one valid VPS so to
+      allow the answerer to meaningfully interpret sprop-ols-id and
+      select recv-ols-id (see below).
+
+   *  The answerer MUST NOT include recv-ols-id unless the offer
+      includes sprop-ols-id.  When present, recv-ols-id MUST indicate a
+      supported output layer set in the VPS that includes no layers
+      other than all or a subset of the layers of the OLS referred to by
+      sprop-ols-id.  If unable, the answerer MUST remove the media
+      format.
+
+      |  Informative note: If an offerer wants to offer more than one
+      |  output layer set, it can do so by offering multiple VVC media
+      |  with different payload types.
+
+   *  The offerer MAY include sprop-sublayer-id, which indicates the
+      highest allowed value of TID in the bitstream.  The answerer MAY
+      include recv-sublayer-id, which can be used to reduce the number
+      of sublayers from the value of sprop-sublayer-id.
+
+   *  When the answerer includes recv-ols-id and configuration
+      parameters profile-id, tier-flag, sub-profile-id, level-id, and
+      interop-constraints, it MUST use the configuration parameter
+      values as signaled in the sprop-vps for the operating point with
+      the largest number of sublayers for the chosen output layer set,
+      with the exception that the value of level-id is changeable as
+      long as the highest level indicated by the answer is not higher
+      than the level indicated by sprop-vps in offer for the operating
+      point with the largest number of sublayers for the chosen output
+      layer set.
+
+7.3.2.3.  Payload Format Configuration
+
+   The following limitations and rules pertain to the configuration of
+   the payload format buffer management mostly and apply to both
+   scalable and non-scalable VVC.
+
+   *  The parameters sprop-max-don-diff and sprop-depack-buf-bytes
+      describe the properties of an RTP stream that the offerer or the
+      answerer is sending for the media format configuration.  This
+      differs from the normal usage of the offer/answer parameters;
+      normally, such parameters declare the properties of the bitstream
+      or RTP stream that the offerer or the answerer is able to receive.
+      When dealing with VVC, the offerer assumes that the answerer will
+      be able to receive media encoded using the configuration being
+      offered.
+
+      |  Informative note: The above parameters apply for any RTP
+      |  stream, when present, sent by a declaring entity with the same
+      |  configuration.  In other words, the applicability of the above
+      |  parameters to RTP streams depends on the source endpoint.
+      |  Rather than being bound to the payload type, the values may
+      |  have to be applied to another payload type when being sent, as
+      |  they apply for the configuration.
+
+   *  The capability parameter max-lsr MAY be used to declare further
+      capabilities of the offerer or answerer for receiving.  It MUST
+      NOT be present when the direction attribute is sendonly.
+
+   *  The capability parameter max-fps MAY be used to declare lower
+      capabilities of the offerer or answerer for receiving.  It MUST
+      NOT be present when the direction attribute is sendonly.
+
+   *  When an offerer offers an interleaved stream, indicated by the
+      presence of sprop-max-don-diff with a value larger than zero, the
+      offerer MUST include the size of the de-packetization buffer
+      sprop-depack-buf-bytes.
+
+   *  To enable the offerer and answerer to inform each other about
+      their capabilities for de-packetization buffering in receiving RTP
+      streams, both parties are RECOMMENDED to include depack-buf-cap.
+
+   *  The parameters sprop-dci, sprop-vps, sprop-sps, or sprop-pps, when
+      present (included in the "a=fmtp" line of SDP or conveyed using
+      the "fmtp" source attribute, as specified in Section 6.3 of
+      [RFC5576]), are used for out-of-band transport of the parameter
+      sets (DCI, VPS, SPS, or PPS, respectively).
+
+   *  The answerer MAY use either out-of-band or in-band transport of
+      parameter sets for the bitstream it is sending, regardless of
+      whether out-of-band parameter sets transport has been used in the
+      offerer-to-answerer direction.  Parameter sets included in an
+      answer are independent of those parameter sets included in the
+      offer, as they are used for decoding two different bitstreams; one
+      from the answerer to the offerer and the other in the opposite
+      direction.  In case some RTP packets are sent before the SDP
+      offer/answer settles down, in-band parameter sets MUST be used for
+      those RTP stream parts sent before the SDP offer/answer.
+
+   *  The following rules apply to transport of parameter sets in the
+      offerer-to-answerer direction.
+
+      -  An offer MAY include sprop-dci, sprop-vps, sprop-sps, and/or
+         sprop-pps.  If none of these parameters are present in the
+         offer, then only in-band transport of parameter sets is used.
+
+      -  If the level to use in the offerer-to-answerer direction is
+         equal to the default level in the offer, the answerer MUST be
+         prepared to use the parameter sets included in sprop-vps,
+         sprop-sps, and sprop-pps (either included in the "a=fmtp" line
+         of SDP or conveyed using the "fmtp" source attribute) for
+         decoding the incoming bitstream, e.g., by passing these
+         parameter set NAL units to the video decoder before passing any
+         NAL units carried in the RTP streams.  Otherwise, the answerer
+         MUST ignore sprop-vps, sprop-sps, and sprop-pps (either
+         included in the "a=fmtp" line of SDP or conveyed using the
+         "fmtp" source attribute) and the offerer MUST transmit
+         parameter sets in-band.
+
+   *  The following rules apply to transport of parameter sets in the
+      answerer-to-offerer direction.
+
+      -  An answer MAY include sprop-dci, sprop-vps, sprop-sps, and/or
+         sprop-pps.  If none of these parameters are present in the
+         answer, then only in-band transport of parameter sets is used.
+
+      -  The offerer MUST be prepared to use the parameter sets included
+         in sprop-vps, sprop-sps, and sprop-pps (either included in the
+         "a=fmtp" line of SDP or conveyed using the "fmtp" source
+         attribute) for decoding the incoming bitstream, e.g., by
+         passing these parameter set NAL units to the video decoder
+         before passing any NAL units carried in the RTP streams.
+
+   *  When sprop-dci, sprop-vps, sprop-sps, and/or sprop-pps are
+      conveyed using the "fmtp" source attribute, as specified in
+      Section 6.3 of [RFC5576], the receiver of the parameters MUST
+      store the parameter sets included in sprop-dci, sprop-vps, sprop-
+      sps, and/or sprop-pps and associate them with the source given as
+      part of the "fmtp" source attribute.  Parameter sets associated
+      with one source (given as part of the "fmtp" source attribute)
+      MUST only be used to decode NAL units conveyed in RTP packets from
+      the same source (given as part of the "fmtp" source attribute).
+      When this mechanism is in use, SSRC collision detection and
+      resolution MUST be performed as specified in [RFC5576].
+
+   Figure 11 lists the interpretation of all the parameters that MAY be
+   used for the various combinations of offer, answer, and direction
+   attributes.
+
+                                       sendonly --+
+               answer: recvonly, recv-ols-id --+  |
+                 recvonly w/o recv-ols-id --+  |  |
+         answer: sendrecv, recv-ols-id --+  |  |  |
+           sendrecv w/o recv-ols-id --+  |  |  |  |
+                                      |  |  |  |  |
+   profile-id                         C  D  C  D  P
+   tier-flag                          C  D  C  D  P
+   level-id                           D  D  D  D  P
+   sub-profile-id                     C  D  C  D  P
+   interop-constraints                C  D  C  D  P
+   max-recv-level-id                  R  R  R  R  -
+   sprop-max-don-diff                 P  P  -  -  P
+   sprop-depack-buf-bytes             P  P  -  -  P
+   depack-buf-cap                     R  R  R  R  -
+   max-lsr                            R  R  R  R  -
+   max-fps                            R  R  R  R  -
+   sprop-dci                          P  P  -  -  P
+   sprop-sei                          P  P  -  -  P
+   sprop-vps                          P  P  -  -  P
+   sprop-sps                          P  P  -  -  P
+   sprop-pps                          P  P  -  -  P
+   sprop-sublayer-id                  P  P  -  -  P
+   recv-sublayer-id                   O  O  O  O  -
+   sprop-ols-id                       P  P  -  -  P
+   recv-ols-id                        X  O  X  O  -
+
+   Legend:
+
+    C: configuration for sending and receiving bitstreams
+    D: changeable configuration, same as C, except possible
+       to answer with a different but consistent value (see the
+       semantics of the six parameters related to profile, tier,
+       and level on these parameters being consistent)
+    P: properties of the bitstream to be sent
+    R: receiver capabilities
+    O: operation point selection
+    X: MUST NOT be present
+    -: not usable, when present MUST be ignored
+
+      Figure 11: Interpretation of Parameters for Various Combinations
+       of Offers, Answers, and Direction Attributes, with and without
+                                recv-ols-id.
+
+   Parameters used for declaring receiver capabilities are, in general,
+   downgradable, i.e., they express the upper limit for a sender's
+   possible behavior.  Thus, a sender MAY select to set its encoder
+   using only lower/lesser or equal values of these parameters.
+
+   When the answer does not include a recv-ols-id that is less than the
+   sprop-ols-id in the offer, parameters declaring a configuration point
+   are not changeable, with the exception of the level-id parameter for
+   unicast usage, and these parameters express values a receiver expects
+   to be used and MUST be used verbatim in the answer as in the offer.
+
+   When a sender's capabilities are declared with the configuration
+   parameters, these parameters express a configuration that is
+   acceptable for the sender to receive bitstreams.  In order to achieve
+   high interoperability levels, it is often advisable to offer multiple
+   alternative configurations.  It is impossible to offer multiple
+   configurations in a single payload type.  Thus, when multiple
+   configuration offers are made, each offer requires its own RTP
+   payload type associated with the offer.  However, it is possible to
+   offer multiple operation points using one configuration in a single
+   payload type by including sprop-vps in the offer and recv-ols-id in
+   the answer.
+
+   An implementation SHOULD be able to understand all media type
+   parameters (including all optional media type parameters), even if it
+   doesn't support the functionality related to the parameter.  This, in
+   conjunction with proper application logic in the implementation,
+   allows the implementation, after having received an offer, to create
+   an answer by potentially downgrading one or more of the optional
+   parameters to the point where the implementation can cope, leading to
+   higher chances of interoperability beyond the most basic interop
+   points (for which, as described above, no optional parameters are
+   necessary).
+
+      |  Informative note: In implementations of previous H.26x payload
+      |  formats, it was occasionally observed that implementations were
+      |  incapable of parsing most (or all) of the optional parameters.
+      |  As a result, the offer/answer exchange resulted in a baseline
+      |  performance (using the default values for the optional
+      |  parameters) with the resulting suboptimal user experience.
+      |  However, there are valid reasons to forego the implementation
+      |  complexity of implementing the parsing of some or all of the
+      |  optional parameters, for example, when there is predetermined
+      |  knowledge, not negotiated by an SDP-based offer/answer process,
+      |  of the capabilities of the involved systems (walled gardens,
+      |  baseline requirements defined in application standards higher
+      |  up in the stack, and similar).
+
+   An answerer MAY extend the offer with additional media format
+   configurations.  However, to enable their usage, in most cases, a
+   second offer is required from the offerer to provide the bitstream
+   property parameters that the media sender will use.  This also has
+   the effect that the offerer has to be able to receive this media
+   format configuration, not only to send it.
+
+7.3.3.  Multicast
+
+   For bitstreams being delivered over multicast, the following rules
+   apply:
+
+   *  The media format configuration is identified by profile-id, tier-
+      flag, sub-profile-id, level-id, and interop-constraints.  These
+      media format configuration parameters, including level-id, MUST be
+      used symmetrically; that is, the answerer MUST either maintain all
+      configuration parameters or remove the media format (payload type)
+      completely.  Note that this implies that the level-id for offer/
+      answer in multicast is not changeable.
+
+   *  To simplify the handling and matching of these configurations, the
+      same RTP payload type number used in the offer SHOULD also be used
+      in the answer, as specified in [RFC3264].  An answer MUST NOT
+      contain a payload type number used in the offer unless the
+      configuration is the same as in the offer.
+
+   *  Parameter sets received MUST be associated with the originating
+      source and MUST only be used in decoding the incoming bitstream
+      from the same source.
+
+   *  The rules for other parameters are the same as above for unicast
+      as long as the three above rules are obeyed.
+
+7.3.4.  Usage in Declarative Session Descriptions
+
+   When VVC over RTP is offered with SDP in a declarative style, as in
+   Real Time Streaming Protocol (RTSP) [RFC7826] or Session Announcement
+   Protocol (SAP) [RFC2974], the following considerations are necessary.
+
+   *  All parameters capable of indicating both bitstream properties and
+      receiver capabilities are used to indicate only bitstream
+      properties.  For example, in this case, the parameters profile-id,
+      tier-id, and level-id declare the values used by the bitstream,
+      not the capabilities for receiving bitstreams.  As a result, the
+      following interpretation of the parameters MUST be used:
+
+      -  Declaring actual configuration or bitstream properties:
+
+         o  profile-id
+
+         o  tier-flag
+
+         o  level-id
+
+         o  interop-constraints
+
+         o  sub-profile-id
+
+         o  sprop-dci
+
+         o  sprop-vps
+
+         o  sprop-sps
+
+         o  sprop-pps
+
+         o  sprop-max-don-diff
+
+         o  sprop-depack-buf-bytes
+
+         o  sprop-sublayer-id
+
+         o  sprop-ols-id
+
+         o  sprop-sei
+
+      -  Not usable (when present, they MUST be ignored):
+
+         o  max-lsr
+
+         o  max-fps
+
+         o  max-recv-level-id
+
+         o  depack-buf-cap
+
+         o  recv-sublayer-id
+
+         o  recv-ols-id
+
+      -  A receiver of the SDP is required to support all parameters and
+         values of the parameters provided; otherwise, the receiver MUST
+         reject (RTSP) or not participate in (SAP) the session.  It
+         falls on the creator of the session to use values that are
+         expected to be supported by the receiving application.
+
+7.3.5.  Considerations for Parameter Sets
+
+   When out-of-band transport of parameter sets is used, parameter sets
+   MAY still be additionally transported in-band unless explicitly
+   disallowed by an application, and some of these additional parameter
+   sets may update some of the out-of-band transported parameter sets.
+   An update of a parameter set refers to the sending of a parameter set
+   of the same type using the same parameter set ID but with different
+   values for at least one other parameter of the parameter set.
+
+8.  Use with Feedback Messages
+
+   The following subsections define the use of the Picture Loss
+   Indication (PLI) and Full Intra Request (FIR) feedback messages with
+   [VVC].  The PLI is defined in [RFC4585], and the FIR message is
+   defined in [RFC5104].  In accordance with this memo, unlike [HEVC], a
+   sender MUST NOT send Slice Loss Indication (SLI) or Reference Picture
+   Selection Indication (RPSI), and a receiver SHOULD ignore RPSI and
+   treat a received SLI as a PLI.
+
+8.1.  Picture Loss Indication (PLI)
+
+   As specified in Section 6.3.1 of [RFC4585], the reception of a PLI by
+   a media sender indicates "the loss of an undefined amount of coded
+   video data belonging to one or more pictures".  Without having any
+   specific knowledge of the setup of the bitstream (such as use and
+   location of in-band parameter sets, non-IRAP decoder refresh points,
+   picture structures, and so forth), a reaction to the reception of a
+   PLI by a VVC sender SHOULD be to send an IRAP picture and relevant
+   parameter sets, potentially with sufficient redundancy so to ensure
+   correct reception.  However, sometimes information about the
+   bitstream structure is known.  For example, such information can be
+   parameter sets that have been conveyed out of band through mechanisms
+   not defined in this document and that are known to stay static for
+   the duration of the session.  In that case, it is obviously
+   unnecessary to send them in-band as a result of the reception of a
+   PLI.  Other examples could be devised based on a priori knowledge of
+   different aspects of the bitstream structure.  In all cases, the
+   timing and congestion control mechanisms of [RFC4585] MUST be
+   observed.
+
+8.2.  Full Intra Request (FIR)
+
+   The purpose of the FIR message is to force an encoder to send an
+   independent decoder refresh point as soon as possible while observing
+   applicable congestion-control-related constraints, such as those set
+   out in [RFC8082].
+
+   Upon reception of a FIR, a sender MUST send an IDR picture.
+   Parameter sets MUST also be sent, except when there is a priori
+   knowledge that the parameter sets have been correctly established.  A
+   typical example for that is an understanding between the sender and
+   receiver, established by means outside this document, that parameter
+   sets are exclusively sent out of band.
+
+9.  Security Considerations
+
+   The scope of this section is limited to the payload format itself and
+   to one feature of [VVC] that may pose a particularly serious security
+   risk if implemented naively.  The payload format, in isolation, does
+   not form a complete system.  Implementers are advised to read and
+   understand relevant security-related documents, especially those
+   pertaining to RTP (see the Security Considerations section in
+   [RFC3550]) and the security of the call-control stack chosen (that
+   may make use of the media type registration of this memo).
+   Implementers should also consider known security vulnerabilities of
+   video coding and decoding implementations in general and avoid those.
+
+   Within this RTP payload format, and with the exception of the user
+   data SEI message as described below, no security threats other than
+   those common to RTP payload formats are known.  In other words,
+   neither the various media-plane-based mechanisms nor the signaling
+   part of this memo seem to pose a security risk beyond those common to
+   all RTP-based systems.
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [RFC3550] and in any applicable RTP profile, such as
+   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/
+   SAVPF [RFC5124].  However, as "Securing the RTP Framework: Why RTP
+   Does Not Mandate a Single Media Security Solution" [RFC7202]
+   discusses, it is not an RTP payload format's responsibility to
+   discuss or mandate what solutions are used to meet the basic security
+   goals, like confidentiality, integrity, and source authenticity for
+   RTP in general.  This responsibility lays on anyone using RTP in an
+   application.  They can find guidance on available security mechanisms
+   and important considerations in "Options for Securing RTP Sessions"
+   [RFC7201].  The rest of this section discusses the security impacting
+   properties of the payload format itself.
+
+   Because the data compression used with this payload format is applied
+   end to end, any encryption needs to be performed after compression.
+   A potential denial-of-service threat exists for data encodings using
+   compression techniques that have non-uniform receiver-end
+   computational load.  The attacker can inject pathological datagrams
+   into the bitstream that are complex to decode and that cause the
+   receiver to be overloaded.  [VVC] is particularly vulnerable to such
+   attacks, as it is extremely simple to generate datagrams containing
+   NAL units that affect the decoding process of many future NAL units.
+   Therefore, the usage of data origin authentication and data integrity
+   protection of at least the RTP packet is RECOMMENDED but NOT REQUIRED
+   based on the thoughts of [RFC7202].
+
+   Like HEVC [RFC7798], [VVC] includes a user data Supplemental
+   Enhancement Information (SEI) message.  This SEI message allows
+   inclusion of an arbitrary bitstring into the video bitstream.  Such a
+   bitstring could include JavaScript, machine code, and other active
+   content.  [VVC] leaves the handling of this SEI message to the
+   receiving system.  In order to avoid harmful side effects of the user
+   data SEI message, decoder implementations cannot naively trust its
+   content.  For example, it would be a bad and insecure implementation
+   practice to forward any JavaScript a decoder implementation detects
+   to a web browser.  The safest way to deal with user data SEI messages
+   is to simply discard them, but that can have negative side effects on
+   the quality of experience by the user.
+
+   End-to-end security with authentication, integrity, or
+   confidentiality protection will prevent a MANE from performing media-
+   aware operations other than discarding complete packets.  In the case
+   of confidentiality protection, it will even be prevented from
+   discarding packets in a media-aware way.  To be allowed to perform
+   such operations, a MANE is required to be a trusted entity that is
+   included in the security context establishment.  This on-path
+   inclusion of the MANE forgoes end-to-end security guarantees for the
+   end points.
+
+10.  Congestion Control
+
+   Congestion control for RTP SHALL be used in accordance with RTP
+   [RFC3550] and with any applicable RTP profile, e.g., AVP [RFC3551] or
+   AVPF [RFC4585].  If best-effort service is being used, an additional
+   requirement is that users of this payload format MUST monitor packet
+   loss to ensure that the packet loss rate is within an acceptable
+   range.  Packet loss is considered acceptable if a TCP flow across the
+   same network path and experiencing the same network conditions would
+   achieve an average throughput, measured on a reasonable timescale,
+   that is not less than all RTP streams combined are achieved.  This
+   condition can be satisfied by implementing congestion-control
+   mechanisms to adapt the transmission rate, by implementing the number
+   of layers subscribed for a layered multicast session, or by arranging
+   for a receiver to leave the session if the loss rate is unacceptably
+   high.
+
+   The bitrate adaptation necessary for obeying the congestion control
+   principle is easily achievable when real-time encoding is used, for
+   example, by adequately tuning the quantization parameter.  However,
+   when pre-encoded content is being transmitted, bandwidth adaptation
+   requires the pre-coded bitstream to be tailored for such adaptivity.
+   The key mechanisms available in [VVC] are temporal scalability and
+   spatial/SNR scalability.  A media sender can remove NAL units
+   belonging to higher temporal sublayers (i.e., those NAL units with a
+   high value of TID) or higher spatio-SNR layers until the sending
+   bitrate drops to an acceptable range.
+
+   The mechanisms mentioned above generally work within a defined
+   profile and level; therefore no renegotiation of the channel is
+   required.  Only when non-downgradable parameters (such as profile)
+   are required to be changed does it become necessary to terminate and
+   restart the RTP stream(s).  This may be accomplished by using
+   different RTP payload types.
+
+   MANEs MAY remove certain unusable packets from the RTP stream when
+   that RTP stream was damaged due to previous packet losses.  This can
+   help reduce the network load in certain special cases.  For example,
+   MANEs can remove those FUs where the leading FUs belonging to the
+   same NAL unit have been lost or those dependent slice segments when
+   the leading slice segments belonging to the same slice have been
+   lost, because the trailing FUs or dependent slice segments are
+   meaningless to most decoders.  MANE can also remove higher temporal
+   scalable layers if the outbound transmission (from the MANE's
+   viewpoint) experiences congestion.
+
+11.  IANA Considerations
+
+   A new media type has been registered with IANA; see Section 7.1.
+
+12.  References
+
+12.1.  Normative References
+
+   [ISO23090-3]
+              International Organization for Standardization,
+              "Information technology - Coded representation of
+              immersive media - Part 3: Versatile video coding", ISO/
+              IEC 23090-3:2022, September 2022,
+              <https://www.iso.org/standard/73022.html>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <https://www.rfc-editor.org/info/rfc3264>.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
+              July 2003, <https://www.rfc-editor.org/info/rfc3550>.
+
+   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
+              Video Conferences with Minimal Control", STD 65, RFC 3551,
+              DOI 10.17487/RFC3551, July 2003,
+              <https://www.rfc-editor.org/info/rfc3551>.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, DOI 10.17487/RFC3711, March 2004,
+              <https://www.rfc-editor.org/info/rfc3711>.
+
+   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
+              "Extended RTP Profile for Real-time Transport Control
+              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
+              DOI 10.17487/RFC4585, July 2006,
+              <https://www.rfc-editor.org/info/rfc4585>.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <https://www.rfc-editor.org/info/rfc4648>.
+
+   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
+              "Codec Control Messages in the RTP Audio-Visual Profile
+              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
+              February 2008, <https://www.rfc-editor.org/info/rfc5104>.
+
+   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
+              Real-time Transport Control Protocol (RTCP)-Based Feedback
+              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
+              2008, <https://www.rfc-editor.org/info/rfc5124>.
+
+   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
+              Media Attributes in the Session Description Protocol
+              (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
+              <https://www.rfc-editor.org/info/rfc5576>.
+
+   [RFC8082]  Wenger, S., Lennox, J., Burman, B., and M. Westerlund,
+              "Using Codec Control Messages in the RTP Audio-Visual
+              Profile with Feedback with Layered Codecs", RFC 8082,
+              DOI 10.17487/RFC8082, March 2017,
+              <https://www.rfc-editor.org/info/rfc8082>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8866]  Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
+              Session Description Protocol", RFC 8866,
+              DOI 10.17487/RFC8866, January 2021,
+              <https://www.rfc-editor.org/info/rfc8866>.
+
+   [VSEI]     ITU-T, "Versatile supplemental enhancement information
+              messages for coded video bitstreams", ITU-T
+              Recommendation H.274, May 2022,
+              <https://www.itu.int/rec/T-REC-H.274>.
+
+   [VVC]      ITU-T, "Versatile Video Coding", ITU-T
+              Recommendation H.266, April 2022,
+              <http://www.itu.int/rec/T-REC-H.266>.
+
+12.2.  Informative References
+
+   [CABAC]    Sole, J., et al., "Transform coefficient coding in HEVC",
+              IEEE Transactions on Circuits and Systems for Video
+              Technology, DOI 10.1109/TCSVT.2012.2223055, December 2012,
+              <https://doi.org/10.1109/TCSVT.2012.2223055>.
+
+   [HEVC]     ITU-T, "High efficiency video coding", ITU-T
+              Recommendation H.265, August 2021,
+              <https://www.itu.int/rec/T-REC-H.265>.
+
+   [MPEG2S]   International Organization for Standardization,
+              "Information technology - Generic coding of moving
+              pictures and associated audio information - Part 1:
+              Systems", ISO/IEC 13818-1:2022, September 2022.
+
+   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
+              Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
+              October 2000, <https://www.rfc-editor.org/info/rfc2974>.
+
+   [RFC6184]  Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP
+              Payload Format for H.264 Video", RFC 6184,
+              DOI 10.17487/RFC6184, May 2011,
+              <https://www.rfc-editor.org/info/rfc6184>.
+
+   [RFC6190]  Wenger, S., Wang, Y.-K., Schierl, T., and A.
+              Eleftheriadis, "RTP Payload Format for Scalable Video
+              Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
+              <https://www.rfc-editor.org/info/rfc6190>.
+
+   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
+              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
+              <https://www.rfc-editor.org/info/rfc7201>.
+
+   [RFC7202]  Perkins, C. and M. Westerlund, "Securing the RTP
+              Framework: Why RTP Does Not Mandate a Single Media
+              Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
+              2014, <https://www.rfc-editor.org/info/rfc7202>.
+
+   [RFC7656]  Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
+              B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
+              for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
+              DOI 10.17487/RFC7656, November 2015,
+              <https://www.rfc-editor.org/info/rfc7656>.
+
+   [RFC7667]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
+              DOI 10.17487/RFC7667, November 2015,
+              <https://www.rfc-editor.org/info/rfc7667>.
+
+   [RFC7798]  Wang, Y.-K., Sanchez, Y., Schierl, T., Wenger, S., and M.
+              M. Hannuksela, "RTP Payload Format for High Efficiency
+              Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798,
+              March 2016, <https://www.rfc-editor.org/info/rfc7798>.
+
+   [RFC7826]  Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
+              and M. Stiemerling, Ed., "Real-Time Streaming Protocol
+              Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
+              2016, <https://www.rfc-editor.org/info/rfc7826>.
+
+Acknowledgements
+
+   Dr. Byeongdoo Choi is thanked for the video-codec-related technical
+   discussion and other aspects in this memo.  Xin Zhao and Dr. Xiang Li
+   are thanked for their contributions on [VVC] specification
+   descriptive content.  Spencer Dawkins is thanked for his valuable
+   review comments that led to great improvements of this memo.  Some
+   parts of this specification share text with the RTP payload format
+   for HEVC [RFC7798].  We thank the authors of that specification for
+   their excellent work.
+
+Authors' Addresses
+
+   Shuai Zhao
+   Intel
+   2200 Mission College Blvd
+   Santa Clara,  95054
+   United States of America
+   Email: shuai.zhao@ieee.org
+
+
+   Stephan Wenger
+   Tencent
+   2747 Park Blvd
+   Palo Alto,  94588
+   United States of America
+   Email: stewe@stewe.org
+
+
+   Yago Sanchez
+   Fraunhofer HHI
+   Einsteinufer 37
+   10587 Berlin
+   Germany
+   Email: yago.sanchez@hhi.fraunhofer.de
+
+
+   Ye-Kui Wang
+   Bytedance Inc.
+   8910 University Center Lane
+   San Diego,  92122
+   United States of America
+   Email: yekui.wang@bytedance.com
+
+
+   Miska M. Hannuksela
+   Nokia Technologies
+   Hatanpään valtatie 30
+   FI-33100 Tampere
+   Finland
+   Email: miska.hannuksela@nokia.com