<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
 <!ENTITY rfc3264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"> zwsp   "&#8203;">
 <!ENTITY rfc3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"> nbhy   "&#8209;">
 <!ENTITY rfc3551 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3711 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc3984 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3984.xml">
<!ENTITY rfc4855 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml">
<!ENTITY rfc4585 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc5104 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml">
<!ENTITY rfc5124 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY rfc6386 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6386.xml">
<!ENTITY rfc6838 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml">
<!ENTITY rfc7201 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml">
<!ENTITY rfc7202 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml">
<!ENTITY rfc7667 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml">
<!ENTITY rfc8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY rfc8866 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8866.xml">
<!ENTITY lrr SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtext-lrr.xml"> wj     "&#8288;">
]>

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-payload-vp9-16" ipr="trust200902">
  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes" ?>

  <!-- alphabetize the references -->

  <?rfc comments="no"?>

  <!-- show comments -->

  <?rfc inline="yes" ?>

  <!-- comments are inline -->

  <?rfc toc="yes" ?>

  <!-- generate table of contents --> number="9628" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

  <front>
    <title abbrev="RTP Payload Format for VP9">RTP Payload Format for VP9
    Video</title>
    <seriesInfo name="RFC" value="9628"/>
    <author fullname="Justin Uberti" initials="J." surname="Uberti">
      <organization abbrev="Google">Google, Inc.</organization>
      <address>
        <postal>
          <street>747 6th Street South</street>
          <city>Kirkland</city>
          <region>WA</region>
          <code>98033</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>justin@uberti.name</email>
      </address>
    </author>
    <author fullname="Stefan Holmer" initials="S." surname="Holmer">
      <organization abbrev="Google">Google, Inc.</organization>
      <address>
        <postal>
          <street>Kungsbron 2</street>
          <code>111 22</code>
          <city>Stockholm</city>
          <country>Sweden</country>
        </postal>
        <email>holmer@google.com</email>
      </address>
    </author>
    <author fullname="Magnus Flodman" initials="M." surname="Flodman">
      <organization abbrev="Google">Google, Inc.</organization>
      <address>
        <postal>
          <street>Kungsbron 2</street>
          <code>111 22</code>
          <city>Stockholm</city>
          <country>Sweden</country>
        </postal>
        <email>mflodman@google.com</email>
      </address>
    </author>
    <author fullname="Danny Hong" initials="D." surname="Hong">
      <organization abbrev="Google">Google, Inc.</organization>
      <address>
        <postal>
          <street>1585 Charleston Road</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>

          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>dannyhong@google.com</email>
      </address>
    </author>
    <author fullname="Jonathan Lennox" initials="J." surname="Lennox">
      <organization abbrev="8x8 / Jitsi">8x8, Inc. / Jitsi</organization>
      <address>
        <postal>
          <street/>
          <city>Jersey City</city>
          <region>NJ</region>
          <code>07302</code>

          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>jonathan.lennox@8x8.com</email>
      </address>
    </author>

    <date/>
    <date year="2024" month="August" />
    <area>RAI</area>
    <workgroup>AVTCore Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>
    <keyword>RTP</keyword>
    <keyword>VP9</keyword>
    <keyword>WebM</keyword>
    <abstract>
      <t>This specification describes an RTP payload format for the VP9 video codec.
      The payload format has wide applicability, applicability as it supports applications
      from low bit-rate bitrate peer-to-peer usage, usage to high bit-rate bitrate video
      conferences.  It includes provisions for temporal and spatial scalability.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>

      <t>This specification document describes an <xref target="RFC3550">RTP</xref> target="RFC3550"
      format="default">RTP</xref> payload specification applicable to the
      transmission of video streams encoded using the VP9 video codec <xref
      target="VP9-BITSTREAM"/>.
      target="VP9-BITSTREAM" format="default"/>. The format described in this
      document can be used both in peer-to-peer and video conferencing
      applications.</t>
      <t>The VP9 video codec was developed by Google, Google and is the successor to
      its earlier <xref target="RFC6386">VP8</xref> target="RFC6386" format="default">VP8</xref> codec.
      Above the compression improvements and other general enhancements above to
      VP8, VP9 is also designed in a way that allows spatially-scalable spatially scalable video
      encoding.</t>
    </section>

    <section anchor="conventions"
             title="Conventions, Definitions and Acronyms">
       <t>The numbered="true" toc="default">
      <name>Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
       "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
       RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>

    </section>
    <section anchor="mediaFormatDescription" title="Media numbered="true" toc="default">
      <name>Media Format Description"> Description</name>
      <t>The VP9 codec can maintain up to eight reference frames, of
      which up to three can be referenced by any new frame.</t>
      <t>VP9 also allows a frame to use another frame of a different
      resolution as a reference frame.  (Specifically, a frame may use
      any references whose width and height are between 1/16th that of
      the current frame and twice that of the current frame,
      inclusive.)  This allows internal resolution changes without
      requiring the use of key frames.</t> keyframes.</t>
      <t>These features together enable an encoder to
      implement various forms of coarse-grained scalability,
      including temporal, spatial spatial, and quality scalability modes, as
      well as combinations of these, without the need for explicit
      scalable coding tools.</t>
      <t>Temporal layers define different frame rates of video;
      spatial and quality layers define different and possibly dependent
      representations of a single input frame.  Spatial layers allow
      a frame to be encoded at different resolutions, whereas
      quality layers allow a frame to be encoded at the same
      resolution but at different qualities (and thus (and, thus, with different
      amounts of coding error).  VP9 supports quality layers as
      spatial layers without any resolution changes; hereinafter,
      the term "spatial layer" is used to represent both spatial and
      quality layers.</t>
      <t>This payload format specification defines how such
      temporal and spatial scalability layers can be described and
      communicated.</t>
      <t>Temporal and spatial scalability layers are associated with
	  non-negative integer IDs. The lowest layer of either type has an
	  ID of 0, 0 and is sometimes referred to as the "base" temporal or
	  spatial layer.</t>
      <t>Layers are designed, and MUST <bcp14>MUST</bcp14> be encoded, such that if
      any layer, and all higher layers, are removed from the bitstream
      along either the spatial or temporal dimension, the remaining bitstream is
      still correctly decodable.</t>

      <t>For terminology, this document uses the term "frame" to refer to a
      single encoded VP9 frame for a particular resolution/quality, resolution and/or quality, and
      "picture" to refer to all the representations (frames) at a single
      instant in time.  A  Thus, a picture thus consists of one or more frames,
      encoding different spatial layers.</t>

      <t>Within a picture, a frame with spatial layer
      spatial-layer ID equal to SID, S, where SID > S &gt; 0, can depend on a frame
      of the same picture with a lower spatial layer spatial-layer ID.  This "inter-layer"
      dependency can result in additional coding gain compared to the case
      where only
      traditional "inter-picture" dependency is used, where a frame
      depends on a previously coded frame in time.  For simplicity, this
      payload format assumes that, within a picture and if inter-layer
      dependency is used, a spatial layer SID spatial-layer S frame can depend only on the
      immediately previous spatial layer SID-1 spatial-layer S-1 frame, when S > &gt; 0.
      Additionally, if inter-picture dependency is used, a spatial layer SID spatial-layer S
      frame is assumed to only depend on a previously coded spatial layer SID spatial-layer S
      frame.</t>

      <t>Given the above simplifications for inter-layer and inter-picture
      dependencies, a flag (the D bit described below) is used to indicate
      whether a
      spatial layer spatial-layer SID frame depends on the spatial layer spatial-layer SID-1
      frame.  Given the D bit, a receiver only needs to additionally know the
      inter-picture dependency structure for a given
      spatial layer spatial-layer frame in
      order to determine its decodability.  Two modes of describing the
      inter-picture dependency structure are possible: "flexible mode" and
      "non-flexible mode".  An encoder can only switch between the two on the
      first packet of a key frame keyframe with temporal
      layer a temporal-layer ID equal to 0.</t>
      <t>In flexible mode, each packet can contain up to 3 three reference indices,
      which identify all frames referenced by the frame transmitted in the
      current packet for inter-picture prediction.  This (along with the D
      bit) enables a receiver to identify if a frame is decodable or not and
      helps it understand the temporal layer temporal-layer structure.  Since this is
      signaled in each packet packet, it makes it possible to have very flexible temporal layer
      hierarchies,
      temporal-layer hierarchies and scalability structures structures, which are
      changing dynamically.</t>
      <t>In non-flexible mode, frames are encoded using a fixed, recurring pattern of dependencies;
      the set of pictures that recur in this pattern is known as a Picture Group (PG). "Picture Group" (or "PG").
      In this mode, the inter-picture dependencies (the reference
      indices) of the Picture Group MUST PG <bcp14>MUST</bcp14> be pre-specified as part of the
      scalability structure
      Scalability Structure (SS) data.
      Each
      packet has an index to refer to one of the described pictures
      in the PG, PG from which the pictures referenced by the picture transmitted in the current packet
      for inter-picture prediction can be identified.</t>

	  <t>(Note:

<aside>
      <t>Note: A "Picture Group", Group" or "PG", as used in this document,
	  is not the same thing as the term "Group of Pictures" as
	  it is traditionally commonly used in video coding, i.e. i.e., to mean an
	  independently-decoadable
	  independently decodable run of pictures beginning with a
	  keyframe.)</t>
	  keyframe.</t>
      <t>The SS data can also be used to specify the resolution of each
      spatial layer present in the VP9 stream for both flexible and non-flexible modes.</t> modes.</t></aside>
    </section>
    <section anchor="payloadFormat" title="Payload Format"> numbered="true" toc="default">
      <name>Payload Format</name>

      <t>This section describes how the encoded VP9 bitstream is encapsulated
      in RTP. To handle network losses losses, usage of RTP/AVPF <xref
      target="RFC4585"/> target="RFC4585" format="default"/> is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. All integer fields in the
      specifications this
      specification are encoded as unsigned integers in network octet
      order.</t>
      <section anchor="RTPHeaderUsage" title="RTP numbered="true" toc="default">
        <name>RTP Header Usage">
        <figure anchor="figureRTPHeader">
          <preamble>The Usage</name>
        <t keepWithNext="true">The general RTP payload format for VP9 is depicted
          below.</preamble>

          <artwork><![CDATA[
        below.</t>

        <figure anchor="figureRTPHeader"  title="General RTP Payload Format for VP">
<artwork type="" align="left" alt=""><![CDATA[
   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             |
  |                             ....                              |
  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  |            VP9 payload descriptor (integer #octets)           |
  :                                                               :
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  |                                                               |
  +                                                               |
  :                          VP9 payload                          :
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :    OPTIONAL RTP padding       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

          <postamble>The
        </figure>
        <t keepWithPrevious="true">See <xref target="VP9payloadDescriptor" format="default"/> for more information on the VP9 payload descriptor will be
          described in <xref target="VP9payloadDescriptor"/>; descriptor;
        the VP9 payload is described in <xref target="VP9-BITSTREAM"/>.
			OPTIONAL target="VP9-BITSTREAM"
        format="default"/>.  <bcp14>OPTIONAL</bcp14> RTP padding MUST NOT <bcp14>MUST
        NOT</bcp14> be included unless the P bit is set.</postamble>
        </figure>

        <t><list style="hanging">
            <t hangText="Marker set.</t>

        <dl newline="false" spacing="normal">
          <dt>Marker bit (M):</dt>
          <dd>This bit (M):">MUST <bcp14>MUST</bcp14> be set to 1 for the final packet
            of the highest spatial layer spatial-layer frame (the final packet of the picture),
            and 0 otherwise. picture); otherwise, it <bcp14>MUST</bcp14> be set to 0.  Unless spatial scalability is in use for this picture,
            this bit will have the same value as the E bit described below. in <xref target="VP9payloadDescriptor"/>.  Note this bit
            MUST
            <bcp14>MUST</bcp14> be set to 1 for the target spatial layer spatial-layer frame
            if a stream is being rewritten to remove higher spatial layers.</t>

			<t hangText="Payload layers.</dd>
          <dt>Payload Type (PT):">In (PT):</dt>
          <dd>In line with the policy in Section 3 of <xref target='RFC3551'/>, target="RFC3551"
          sectionFormat="of" section="3" format="default"/>, applications using
          the VP9 RTP payload profile MUST <bcp14>MUST</bcp14> assign a dynamic
          payload type number to be used in each RTP session and provide a
          mechanism to indicate the mapping.  See <xref target="SDPParameters"/> target="SDPParameters"
          format="default"/> for the mechanism to be used with the <xref target='RFC8866'>Session
          target="RFC8866" format="default">Session Description Protocol (SDP)</xref>.</t>

            <t hangText="Timestamp:">The
          (SDP)</xref>.</dd>
          <dt>Timestamp:</dt>
          <dd>The <xref target="RFC3550">RTP target="RFC3550" format="default">RTP timestamp</xref> indicates the time when
            the input frame was sampled, at a clock rate of 90 kHz.  If the
            input picture is encoded with multiple layer multiple-layer frames, all of the
            frames of the picture MUST <bcp14>MUST</bcp14> have the same timestamp.</t>

			<t>If timestamp.</dd>
          <dt/>
          <dd>If a frame has the VP9 show_frame field set to 0 (i.e., it is
          meant only to populate a reference buffer, buffer without being output) output), its
          timestamp MAY <bcp14>MAY</bcp14> alternatively be set to be the same as
          the subsequent frame with show_frame equal to 1.  (This will be
          convenient for playing out pre-encoded content packaged with VP9
          "superframes", which typically bundle show_frame==0 frames with a
          subsequent show_frame==1 frame.)  Every frame with show_frame==1,
          however, MUST <bcp14>MUST</bcp14> have a unique timestamp modulo the 2^32 2<sup>32</sup>
          wrap of the field.</t>

          </list></t> field.</dd>
        </dl>
        <t>The remaining RTP Fixed Header Fields (V, P, X, CC, sequence
        number, SSRC SSRC, and CSRC identifiers) are used as specified in Section 5.1 of <xref
        target="RFC3550"/>.</t>
        target="RFC3550" sectionFormat="of" section="5.1"
        format="default"/>.</t>
      </section>
      <section anchor="VP9payloadDescriptor" title="VP9 numbered="true" toc="default">
        <name>VP9 Payload Descriptor">
        <figure anchor="figureVP9payloadDescriptor">
          <preamble>In Descriptor</name>

<!--[rfced] Section 4.2: It seems the descriptions following Figure 3
     apply to both Figures 2 and 3.  If that is so, might a note of this appear
     somewhere earlier in that section for the ease of the reader?-->

        <t keepWithNext="true">In flexible mode (with the F bit below set to 1), the first octets
          after the RTP header are the VP9 payload descriptor, with the following
          structure.</preamble>

          <artwork><![CDATA[
          structure.</t>
        <figure anchor="figureVP9payloadDescriptor" title="Flexible Mode Format for VP9 Payload Descriptor">
          <artwork name="" type="" align="left" alt=""><![CDATA[
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |I|P|L|F|B|E|V|Z| (REQUIRED)
     +-+-+-+-+-+-+-+-+
I:   |M| PICTURE ID  | (REQUIRED)
     +-+-+-+-+-+-+-+-+
M:   | EXTENDED PID  | (RECOMMENDED)
     +-+-+-+-+-+-+-+-+
L:   | TID |U| SID |D| (Conditionally RECOMMENDED)
     +-+-+-+-+-+-+-+-+                             -\
P,F: | P_DIFF      |N| (Conditionally REQUIRED)    - up to 3 times
     +-+-+-+-+-+-+-+-+                             -/
V:   | SS            |
     | ..            |
     +-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <figure anchor="figureVP9payloadDescriptorNonFlexible">
          <preamble>In
        <t keepWithNext="true">In non-flexible mode (with the F bit below set to 0), the first octets
          after the RTP header are the VP9 payload descriptor, with the following
          structure.</preamble>

          <artwork><![CDATA[
          structure.</t>
        <figure anchor="figureVP9payloadDescriptorNonFlexible" title="Non-flexible Mode Format for VP9 Payload Descriptor">
<artwork name="" type="" align="left" alt=""><![CDATA[
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |I|P|L|F|B|E|V|Z| (REQUIRED)
     +-+-+-+-+-+-+-+-+
I:   |M| PICTURE ID  | (RECOMMENDED)
     +-+-+-+-+-+-+-+-+
M:   | EXTENDED PID  | (RECOMMENDED)
     +-+-+-+-+-+-+-+-+
L:   | TID |U| SID |D| (Conditionally RECOMMENDED)
     +-+-+-+-+-+-+-+-+
     |   TL0PICIDX   | (Conditionally REQUIRED)
     +-+-+-+-+-+-+-+-+
V:   | SS            |
     | ..            |
     +-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t><list style="hanging">
          <t hangText="I:">Picture
        <dl newline="false" spacing="normal">
          <dt>I:</dt>
          <dd>Picture ID (PID) present. When set to one, 1, the
          OPTIONAL
          <bcp14>OPTIONAL</bcp14> PID MUST <bcp14>MUST</bcp14> be present after the
          mandatory first octet and specified as below. Otherwise, PID MUST NOT
          <bcp14>MUST NOT</bcp14> be present.  If the V bit was set in the
          stream's most recent start of a keyframe (i.e. (i.e., the SS field was
          present) and the F bit is set to 0 (i.e. (i.e., non-flexible scalability
          mode is in use), then this bit MUST <bcp14>MUST</bcp14> be set on every packet.</t>

          <t hangText="P:">Inter-picture
          packet.</dd>
          <dt>P:</dt>
          <dd>Inter-picture predicted frame.  When set to zero, 0, the frame does
          not utilize inter-picture prediction.  In this case, up-switching to
          a current spatial layer's frame is possible from a directly lower spatial layer
          spatial-layer frame.  P SHOULD <bcp14>SHOULD</bcp14> also be set to zero 0 when
          encoding a layer synchronization frame in response to an a <xref target='I-D.ietf-avtext-lrr'>LRR</xref> target="RFC9627" format="default">Layer Refresh Request (LRR)</xref>
          message (see <xref target='LRR'/>). target="LRR" format="default"/>).  When P is set
          to zero, 0, the TID field (described below) MUST <bcp14>MUST</bcp14> also be
          set to 0 (if present).  Note that the P bit does not forbid
          intra-picture, inter-layer prediction from earlier frames of the
          same picture, if any.</t>

          <t hangText="L:">Layer any.</dd>
          <dt>L:</dt>

          <dd>Layer indices present.  When set to one, 1, the one or two octets
          following the mandatory first octet and the PID (if present) is as
          described by "Layer indices" below.  If the F bit (described below)
          is set to 1 (indicating flexible mode), then only one octet is
          present for the layer indices. Otherwise Otherwise, if the F bit is set to 0
          (indicating non-flexible mode), then two octets are present for the
          layer indices.</t>

          <t hangText="F:">Flexible indices.</dd>
          <dt>F:</dt>
          <dd>Flexible mode.  F  When set to one 1, this indicates flexible mode and mode; if the
          P bit is also set to one, 1, then the octets following the mandatory
          first octet, the PID, and layer indices (if present) are as
          described by "Reference "reference indices" below.  This MUST bit <bcp14>MUST</bcp14>
          only be set to 1 if the I bit is also set to one; 1; if the I bit is
          set to zero, 0, then this MUST bit <bcp14>MUST</bcp14> also be set to zero 0 and
          ignored by receivers. (Flexible mode's Reference reference indices are defined
          as offsets from the Picture ID field, so they would have no meaning
          if I were not set.)  The value of this the F bit MUST <bcp14>MUST</bcp14>
          only change on the first packet of a key picture.  A key picture "key picture" is
          a picture whose base spatial layer spatial-layer frame is a key frame, keyframe, and
          which thus one which
          completely resets the encoder state.  This packet will have its
          P bit equal to zero, 0, SID or L bit (described below) equal to zero, 0,
          and B bit (described below) equal to 1.</t>

          <t hangText="B:">Start 1.</dd>
          <dt>B:</dt>
          <dd>Start of a frame. MUST This bit <bcp14>MUST</bcp14> be set to 1 if
          the first payload octet of the RTP packet is the beginning of a
          new VP9 frame, and MUST NOT frame; otherwise, it <bcp14>MUST NOT</bcp14> be 1 otherwise. 1. Note that this
          frame might not be the first frame of a picture.</t>

          <t hangText="E:">End picture.</dd>
          <dt>E:</dt>
          <dd>End of a frame.  MUST  This bit <bcp14>MUST</bcp14> be set to 1 for the final
          RTP packet of a VP9 frame, and 0 otherwise. frame; otherwise, it <bcp14>MUST</bcp14> be 0.  This enables a
          decoder to finish decoding the frame, where it otherwise may need to
          wait for the next packet to explicitly know that the frame is complete.
          Note that, if spatial scalability is in use, more frames from the
          same picture may follow; see the description of the B bit above.</t>

          <t hangText="V:">Scalability structure above.</dd>
          <dt>V:</dt>
          <dd>Scalability Structure (SS) data present. When set
          to one, 1, the OPTIONAL <bcp14>OPTIONAL</bcp14> SS data MUST <bcp14>MUST</bcp14> be present in the payload descriptor.
          Otherwise, the SS data MUST NOT <bcp14>MUST NOT</bcp14> be present.</t>

	  <t hangText="Z:">Not present.</dd>
          <dt>Z:</dt>
          <dd>Not a reference frame for upper spatial layers. If set to 1,
          indicates that frames with higher spatial layers SID+1 and greater
          of the current and following pictures do not depend on the current spatial layer
          spatial-layer SID frame.  This enables a decoder which that is targeting a
          higher spatial layer to know that it can safely discard this
          packet's frame without processing it, without having to wait for the "D"
          D bit in the higher-layer frame (see below).</t>
        </list></t> below).</dd>
        </dl>
        <t>The mandatory first octet is followed by the extension data fields that
        are enabled:<list style="hanging">
          <t hangText="M:">The enabled:</t>
        <dl newline="false" spacing="normal">
          <dt>M:</dt>

          <dd>The most significant bit of the first octet is an extension
          flag. The field MUST <bcp14>MUST</bcp14> be present if the I bit is equal
          to one. If M is set, the PID field MUST <bcp14>MUST</bcp14> contain 15
          bits; otherwise, it MUST <bcp14>MUST</bcp14> contain 7 bits. See PID below.</t>

          <t hangText="Picture
          below.</dd>
          <dt>Picture ID (PID):">Picture (PID):</dt>
          <dd>Picture ID represented in 7 or 15 bits, depending on the M
          bit. This is a running index of the pictures, where the sender
          increments the value by 1 for each picture it sends.  (Note however  (Note,
          however, that because a middlebox can discard pictures where
          permitted by the scalability structure, SS, Picture IDs as received by a
          receiver might not be contiguous.)  This field MUST <bcp14>MUST</bcp14>
          be present if the I bit is equal to one. If M is set to zero, 0, 7 bits
          carry the PID; else else, if M is set to one, 1, 15 bits carry the PID in
          network byte order.  The sender may choose between a 7- or 15-bit
          index. The PID SHOULD <bcp14>SHOULD</bcp14> start on a random number, number and MUST
          <bcp14>MUST</bcp14> wrap after reaching the maximum ID (0x7f or
          0x7fff depending on the index size chosen). The receiver
          MUST NOT <bcp14>MUST
          NOT</bcp14> assume that the number of bits in the PID stay stays the same
          through the session.  If this field transitions from 7-bits 7 bits to 15-bits, 15
          bits, the value is zero-extended
          (i.e. (i.e., the value after 0x6e is
          0x006f); if the field transitions from 15 bits to 7 bits, it is
          truncated (i.e. (i.e., the value after 0x1bbe is 0xbf).
          </t>

          <t>In
          </dd>
          <dt/>
          <dd>In the non-flexible mode (when the F bit is set to 0), this PID
          is used as an index to the picture group (PG) PG specified in the SS
          data below.  In this mode, the PID of the key frame keyframe corresponds to
          the first specified frame in the PG.  Then subsequent PIDs are
          mapped to subsequently specified frames in the PG (modulo N_G,
          specified in the SS data below), respectively.</t>

		  <t>All respectively.</dd>
          <dt/>
          <dd>All frames of the same picture MUST <bcp14>MUST</bcp14> have the same
          PID value.</t>

		  <t>Frames value.</dd>
          <dt/>
          <dd>Frames (and their corresponding pictures) with the VP9
          show_frame field equal to 0 MUST <bcp14>MUST</bcp14> have distinct PID
          values from subsequent pictures with show_frame equal to 1.  Thus, a Picture as
          picture (as defined in this specification specification) is different than a VP9 Superframe.</t>

		  <t>All
          superframe.</dd>
          <dt/>
          <dd>All frames of the same picture MUST <bcp14>MUST</bcp14> have the same
          value for show_frame.</t>

          <t hangText="Layer indices:">This information show_frame.</dd>

          <dt>Layer indices:</dt>
          <dd>This field is optional but RECOMMENDED <bcp14>RECOMMENDED</bcp14>
          whenever encoding with layers.  For both flexible and non-flexible
          modes, one octet is used to specify a layer frame's temporal layer temporal-layer
          ID (TID) and spatial layer spatial-layer ID (SID) as shown both in <xref target="figureVP9payloadDescriptor"/>
          target="figureVP9payloadDescriptor" format="default"/> and <xref target="figureVP9payloadDescriptorNonFlexible"/>.
          target="figureVP9payloadDescriptorNonFlexible" format="default"/>.
          Additionally, a bit (U) is used to indicate that the current frame
          is a "switching up point" frame.  Another bit (D) is used to
          indicate whether inter-layer prediction is used for the current frame.</t>

          <t>In
          frame.</dd>
          <dt/>
          <dd>In the non-flexible mode (when the F bit is set to 0), another
          octet is used to represent temporal layer Temporal Layer 0 index Picture Index (8 bits) (TL0PICIDX), as
          depicted in <xref target="figureVP9payloadDescriptorNonFlexible"/>. target="figureVP9payloadDescriptorNonFlexible"
          format="default"/>.  The TL0PICIDX is present so that all minimally
          required frames - the (the base temporal layer frames - temporal-layer frames) can be tracked.</t>
          tracked.</dd>
          <dt/>
          <dd>
            <t>The TID and SID fields indicate the temporal and spatial layers
            and can help middleboxes and endpoints quickly identify which
            layer a packet belongs to.

          <list style="hanging">
            <t hangText="TID:">The temporal layer

            </t>
            <dl newline="false" spacing="normal">
              <dt>TID:</dt>
              <dd>The temporal-layer ID of the current frame.  In the case of
              non-flexible mode, if a PID is mapped to a picture in a specified
              PG, then the value of the TID MUST <bcp14>MUST</bcp14> match the
              corresponding TID value of the mapped picture in the PG.</t>

            <t hangText="U:">Switching PG.</dd>
              <dt>U:</dt>
              <dd>Switching up point.  If this bit is set to 1 for the current
              picture with temporal
            layer a temporal-layer ID equal to TID, value T, then "switch "switching up"
              to a higher frame rate is possible as subsequent higher temporal
            layer
              temporal-layer pictures will not depend on any picture before
              the current picture (in coding order) with temporal layer a temporal-layer ID
              value greater than TID.</t>

            <t hangText="SID:">The spatial layer T.</dd>
              <dt>SID:</dt>
              <dd>The spatial-layer ID of the current frame.  Note that frames
              with spatial layer spatial-layer SID > 0 may be dependent on decoded spatial layer
              spatial-layer SID-1 frame within the same picture.  Different
              frames of the same picture MUST <bcp14>MUST</bcp14> have distinct spatial layer
              spatial-layer IDs, and frames' spatial layers
			MUST
              <bcp14>MUST</bcp14> appear in increasing order within the frame.</t>

            <t hangText="D:">Inter-layer
              frame.</dd>
              <dt>D:</dt>
              <dd>Inter-layer dependency is used.  MUST D <bcp14>MUST</bcp14> be
              set to one 1 if and only if the current spatial layer spatial-layer SID frame
              depends on spatial layer spatial-layer SID-1 frame of the same picture, otherwise MUST picture;
              otherwise, it <bcp14>MUST</bcp14> be set to zero. 0.  For the base layer
              base-layer frame (with SID equal to 0), this the D bit MUST
              <bcp14>MUST</bcp14> be set to zero.</t>

            <t hangText="TL0PICIDX:">8 bits temporal layer zero index. 0.</dd>
              <dt>TL0PICIDX:</dt>
	      <dd>Temporal Layer 0 Picture Index (8 bits). TL0PICIDX is only present
              in the non-flexible mode (F = 0).  This is a running index for
              the temporal
            base layer base-layer pictures, i.e., the pictures with a TID
              set to 0.  If the TID is larger than 0, TL0PICIDX indicates which
              temporal base layer base-layer picture the current picture depends on.
              TL0PICIDX MUST <bcp14>MUST</bcp14> be incremented by 1 when the TID is
              equal to 0.  The index SHOULD <bcp14>SHOULD</bcp14> start on a random number,
              number and MUST <bcp14>MUST</bcp14> restart at 0 after reaching the
              maximum number 255.</t>
          </list></t>

          <t hangText="Reference indices:">When 255.</dd>
            </dl>
          </dd>
          <dt>Reference indices:</dt>
          <dd>
            <t>When P and F are both set to one, 1, indicating a non-key frame non-keyframe in
            flexible mode, then at least one reference index MUST
            <bcp14>MUST</bcp14> be specified as below.  Additional reference
            indices (total (a total of up to
          3 three reference indices are allowed) may be
            specified using the N bit below.  When either P or F is set to zero, 0,
            then no reference index is specified.
          <list style="hanging">
            <t hangText="P_DIFF:">The
            </t>
            <dl newline="false" spacing="normal">
              <dt>P_DIFF:</dt>
	      <dd>The reference index (in 7 bits) specified as the relative
              PID from the current picture.  For example, when P_DIFF=3 on a
              packet containing the picture with PID 112 means that the
              picture refers back to the picture with PID 109. This
              calculation is done modulo the size of the PID field, i.e.,
              either 7 or 15 bits.  A P_DIFF value of 0 is invalid.</t>
            <t hangText="N:">1 invalid.</dd>
              <dt>N:</dt>
              <dd>1 if there is additional P_DIFF following the current P_DIFF.</t>
          </list></t>
        </list></t> P_DIFF.</dd>
            </dl>
          </dd>
        </dl>

	<section anchor="VP9payloadDescriptorSS" title="Scalability numbered="true" toc="default">
          <name>Scalability Structure (SS):"> (SS)</name>
          <t>The scalability structure (SS) SS data describes the resolution of
          each frame within a picture as well as the inter-picture
          dependencies for a picture group (PG). PG.  If the VP9 payload
          descriptor's "V" V bit is set, the SS data is present in the position
          indicated in Figures <xref format="counter" target="figureVP9payloadDescriptor"/> and <xref target="figureVP9payloadDescriptorNonFlexible"/>.</t> target="figureVP9payloadDescriptorNonFlexible" format="counter"/>.</t>

          <figure anchor="figureVP9ScalabilityStructure">
            <artwork><![CDATA[ anchor="figureVP9ScalabilityStructure" title="VP9 Scalability Structure">
<artwork name="" type="" align="left" alt=""><![CDATA[
     +-+-+-+-+-+-+-+-+
V:   | N_S |Y|G|-|-|-|
     +-+-+-+-+-+-+-+-+              -\
Y:   |     WIDTH     | (OPTIONAL)    .
     +               +               .
     |               | (OPTIONAL)    .
     +-+-+-+-+-+-+-+-+               . - N_S + 1 times
     |     HEIGHT    | (OPTIONAL)    .
     +               +               .
     |               | (OPTIONAL)    .
     +-+-+-+-+-+-+-+-+              -/
G:   |      N_G      | (OPTIONAL)
     +-+-+-+-+-+-+-+-+                            -\
N_G: | TID |U| R |-|-| (OPTIONAL)                 .
     +-+-+-+-+-+-+-+-+              -\            . - N_G times
     |    P_DIFF     | (OPTIONAL)    . - R times  .
     +-+-+-+-+-+-+-+-+              -/            -/
]]></artwork>
          </figure>

        <t><list style="hanging">
          <t hangText="N_S:">N_S

<!--[rfced] We note that not all fields that appear in Figure 4 are
     described following it.  Please review and let us know if text
     (or a pointer to where the reader can get more information on
     these fields) should be added.

-->
          <dl newline="false" spacing="normal">
            <dt>N_S:</dt>
            <dd>Number of Spatial Layers Minus 1.  N_S + 1 indicates the number of spatial
          layers present in the VP9 stream.</t>

          <t hangText="Y:">Each stream.</dd>
            <dt>Y:</dt>
            <dd>Each spatial layer's frame resolution is present.
          When set to one, 1, the OPTIONAL <bcp14>OPTIONAL</bcp14> WIDTH (2 octets) and HEIGHT
          (2 octets) MUST <bcp14>MUST</bcp14> be present for each layer frame.  Otherwise, the
          resolution MUST NOT <bcp14>MUST NOT</bcp14> be present.</t>

          <t hangText="G:">PG present.</dd>
            <dt>G:</dt>
            <dd>The PG description present flag.</t>

          <t hangText="-:">Bit flag.</dd>
            <dt>-:</dt>
            <dd>A bit reserved for future use. MUST It <bcp14>MUST</bcp14> be set
            to
          zero 0 and MUST <bcp14>MUST</bcp14> be ignored by the receiver.</t>

          <t hangText="N_G:">N_G receiver.</dd>
            <dt>N_G:</dt>
            <dd>N_G indicates the number of pictures in a
          Picture Group (PG). PG.
            If N_G is greater than 0, then the SS data allows the
            inter-picture dependency structure of the VP9 stream to be
            pre-declared, rather than indicating it on the fly with every
            packet.  If N_G is greater than 0, then for N_G pictures in the
            PG, each picture's temporal layer temporal-layer ID (TID), switch up point (U),
            and the Reference reference indices (P_DIFFs) are specified.</t>

          <t>The specified.</dd>
            <dt/>
            <dd>The first picture specified in the PG MUST <bcp14>MUST</bcp14> have a TID set to 0.</t>

          <t>G 0.</dd>
            <dt/>
            <dd>G set to 0 or N_G set to 0 indicates that either there is only
            one temporal layer (for non-flexible mode) or no fixed
            inter-picture dependency information is present (for flexible
            mode) going forward in the bitstream.</t>

          <t>Note bitstream.</dd>
            <dt/>
            <dd>Note that for a given picture, all frames follow the same
            inter-picture dependency structure.  However, the frame rate of
            each spatial layer can be different from each other and other; this can
            be described with the use of the D bit described above.  The
            specified dependency structure in the SS data MUST <bcp14>MUST</bcp14>
            be for the highest frame rate layer.</t>
        </list></t> layer.</dd>
          </dl>
          <t>In a scalable stream sent with a fixed pattern, the SS data
        SHOULD
          <bcp14>SHOULD</bcp14> be included in the first packet of every key
          frame. This is a packet with the P bit equal to zero, 0, SID or L bit equal
          to zero, 0, and B bit equal to 1.  The SS data MUST <bcp14>MUST</bcp14> only
          be changed on the picture that corresponds to the first picture
          specified in the previous SS data's PG (if the previous SS data's
          N_G was greater than 0).</t>
        </section>
      </section>
      <section title="Frame Fragmentation"> numbered="true" toc="default">
        <name>Frame Fragmentation</name>
        <t>VP9 frames are fragmented into packets, packets in RTP sequence number order,
        order: beginning with a packet with the B bit set, set and ending with a
        packet with the E bit set.  There is no mechanism for finer-grained
        access to parts of a VP9 frame.</t>
      </section>
      <section title="Scalable encoding considerations"> numbered="true" toc="default">
        <name>Scalable Encoding Considerations</name>
        <t>In addition to the use of reference frames, VP9 has several
		additional forms of inter-frame dependencies, largely
		involving probability tables for the entropy and tree
		encoders.  In VP9 syntax, the syntax element
		"error_resilient_mode" resets this additional inter-frame
		data, allowing a frame's syntax to be decoded
		independently.</t>
        <t>Due to the requirements of scalable streams, a VP9 encoder
		producing a scalable stream needs to ensure that a frame does
		not depend on a previous frame (of the same or a previous
		picture) that can legitimately be removed from the stream.
		Thus, a frame that follows a frame that might be removed (in full decode
		order) MUST <bcp14>MUST</bcp14> be encoded with "error_resilient_mode" set to
		true.</t>
        <t>For spatially-scalable spatially scalable streams, this means that
		"error_resilient_mode" needs to be turned on for the base
		spatial layer; however, it can however be turned off for higher spatial
		layers, assuming they are sent with inter-layer dependency
		(i.e.
		(i.e., with the "D" D bit set).  For streams that are only
		temporally-scalable
		temporally scalable without spatial scalability,
		"error_resilient_mode" can additionally be turned off for any
		picture that immediately follows a temporal layer temporal-layer 0 frame.</t>
      </section>
      <section title="Examples numbered="true" toc="default">
        <name>Examples of VP9 RTP Stream"> Stream</name>
        <section title="Reference picture use numbered="true" toc="default">
          <name>Reference Picture Use for scalable structure"> Scalable Structure</name>
          <t>As discussed in <xref target="mediaFormatDescription"/>, target="mediaFormatDescription" format="default"/>, the
			VP9 codec can maintain up to eight reference frames, of
			which up to three can be referenced or updated by any new
			frame.  This section illustrates one way that a scalable
			structure (with three spatial layers and three temporal
			layers) can be constructed using these reference
			frames.</t>

		  <texttable title="Example scalability structure">

			<ttcol align="center">Temporal</ttcol>
			<ttcol align="center">Spatial</ttcol>
			<ttcol align="center">References</ttcol>
			<ttcol align="center">Updates</ttcol>
			<c>0</c><c>0</c><c>0</c><c>0</c>
			<c>0</c><c>1</c><c>0,1</c><c>1</c>
			<c>0</c><c>2</c><c>1,2</c><c>2</c>
			<c>2</c><c>0</c><c>0</c><c>6</c>
			<c>2</c><c>1</c><c>1,6</c><c>7</c>
			<c>2</c><c>2</c><c>2,7</c><c>-</c>
			<c>1</c><c>0</c><c>0</c><c>3</c>
			<c>1</c><c>1</c><c>1,3</c><c>4</c>
			<c>1</c><c>2</c><c>2,4</c><c>5</c>
			<c>2</c><c>0</c><c>3</c><c>6</c>
			<c>2</c><c>1</c><c>4,6</c><c>7</c>
			<c>2</c><c>2</c><c>5,7</c><c>-</c>

		  </texttable>
          <table align="center">
            <name>Example Scalability Structure</name>
            <thead>
              <tr>
                <th align="center">Temporal</th>
                <th align="center">Spatial</th>
                <th align="center">References</th>
                <th align="center">Updates</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">0</td>
                <td align="center">0</td>
                <td align="center">0</td>
                <td align="center">0</td>
              </tr>
              <tr>
                <td align="center">0</td>
                <td align="center">1</td>
                <td align="center">0,1</td>
                <td align="center">1</td>
              </tr>
              <tr>
                <td align="center">0</td>
                <td align="center">2</td>
                <td align="center">1,2</td>
                <td align="center">2</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="center">0</td>
                <td align="center">0</td>
                <td align="center">6</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="center">1</td>
                <td align="center">1,6</td>
                <td align="center">7</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="center">2</td>
                <td align="center">2,7</td>
                <td align="center">-</td>
              </tr>
              <tr>
                <td align="center">1</td>
                <td align="center">0</td>
                <td align="center">0</td>
                <td align="center">3</td>
              </tr>
              <tr>
                <td align="center">1</td>
                <td align="center">1</td>
                <td align="center">1,3</td>
                <td align="center">4</td>
              </tr>
              <tr>
                <td align="center">1</td>
                <td align="center">2</td>
                <td align="center">2,4</td>
                <td align="center">5</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="center">0</td>
                <td align="center">3</td>
                <td align="center">6</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="center">1</td>
                <td align="center">4,6</td>
                <td align="center">7</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="center">2</td>
                <td align="center">5,7</td>
                <td align="center">-</td>
              </tr>
            </tbody>
          </table>
          <t>This structure is constructed such that the "U" U bit can
		  always be set.</t>
        </section>
      </section>
    </section>

    <section anchor="Feedback" title="Feedback numbered="true" toc="default">
      <name>Feedback Messages and Header Extensions"> Extensions</name>
      <section anchor="RPSI" title="Reference numbered="true" toc="default">

        <name>Reference Picture Selection Indication (RPSI)"> (RPSI)</name>
        <t>The reference picture selection index RPSI is a payload-specific
        feedback message defined within the RTCP-based feedback format. The
        RPSI message is generated by a receiver and can be used in two ways.
        Either ways:
        either it can signal a preferred reference picture when a loss has
        been detected by the decoder -- preferably then (preferably a reference that the decoder
        knows is perfect -- or, perfect) or it can be used as positive feedback information
        to acknowledge correct decoding of certain reference pictures. The
        positive feedback method is useful for VP9 used for
        point to point point-to-point
        (unicast) communication. The use of RPSI for VP9 is preferably
        combined with a special update pattern of the codec's two special
        reference frames -- the golden frame and the altref frame -- in which they
        are updated in an alternating leapfrog fashion. When a receiver has
        received and correctly decoded a golden or altref frame, and that
        frame had a Picture ID in the payload descriptor, the receiver can
        acknowledge this simply by sending an RPSI message back to the
        sender. The message body (i.e., the "native RPSI bit string" in <xref target="RFC4585"/>)
        target="RFC4585" format="default"/>) is simply the (7 (7- or 15 bit) 15-bit)
        Picture ID of the received frame.</t>

<aside>
<t>Note: because all frames of the same picture must have the
		same inter-picture reference structure, there is no need for a
		message to specify which frame is being selected.</t> selected.</t></aside>
      </section>
      <section title='Full anchor="FIR" numbered="true" toc="default">
        <name>Full Intra Request (FIR)' anchor="FIR"> (FIR)</name>
        <t>The <xref target='RFC5104'>Full target="RFC5104" format="default">Full Intra Request (FIR)</xref>
		RTCP feedback message allows a receiver to request a full state refresh of an encoded stream.</t>
        <t>Upon receipt of an a FIR request, a VP9 sender MUST <bcp14>MUST</bcp14>
        send a picture with a keyframe for its spatial layer spatial-layer 0 layer
		frame, frame and
        then send frames without inter-picture prediction (P=0) for any higher layer
        higher-layer frames.</t>
      </section>
      <section title="Layer anchor="LRR" numbered="true" toc="default">
        <name>Layer Refresh Request (LRR)" anchor="LRR"> (LRR)</name>
        <t>The <xref target="I-D.ietf-avtext-lrr">Layer target="RFC9627" format="default">Layer Refresh Request
        (LRR)</xref> allows a receiver to request a single layer of a
        spatially or temporally encoded stream to be refreshed, refreshed without
        necessarily affecting the stream's other layers.</t>
        <figure anchor="figureLRRIndexFormat">
          <artwork><![CDATA[ anchor="figureLRRIndexFormat" title="LRR Index Format">
<artwork name="" type="" align="left" alt=""><![CDATA[
            +---------------+---------------+
            |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
            +---------------+---------+-----+
            |   RES   | TID | RES     | SID |
            +---------------+---------+-----+
]]></artwork>
        </figure>
        <t><xref target="figureLRRIndexFormat"/> target="figureLRRIndexFormat" format="default"/> shows the format
		of an LRR's layer index fields for VP9 streams.  The two "RES"
		fields MUST <bcp14>MUST</bcp14> be set to 0 on transmission and ingnored ignored on
		reception.  See <xref target="VP9payloadDescriptor"/> target="VP9payloadDescriptor" format="default"/> for
		details on the TID and SID fields.</t>

<t>Identification of a layer refresh frame can be derived from
		the reference IDs of each frame by backtracking the dependency
		chain until reaching a point where only decodable frames are
		being referenced. Therefore Therefore, it's recommended for both the
		flexible and the non-flexible mode that, when switching up
		points are being encoded in response to a an LRR, those packets should
		contain layer indices and the reference field(s) field or fields so
		that the decoder or a <xref target='RFC7667'>selective target="RFC7667"
		format="default">selective forwarding middleboxes</xref> can
		make this derivation.</t>
        <t>Example:</t>
        <t>LRR {1,0}, {2,1} is sent by an MCU a Multipoint Control
   Unit (MCU) when it is currently
	  relaying {1,0} to a receiver and which that wants to upgrade to
	  {2,1}. In response response, the encoder should encode the next frames
	  in layers {1,1} and {2,1} by only referring to frames in
	  {1,0},
	  {1,0} or {0,0}.</t>
        <t>In the non-flexible mode, periodic upgrade frames can be defined by
        the layer structure of the SS, thus SS; thus, periodic upgrade frames can be
        automatically identified by the picture Picture ID.</t>
      </section>

   </section>

   <section anchor="payloadFormatParameters"
             title="Payload numbered="true" toc="default">

      <name>Payload Format Parameters"> Parameters</name>
      <t>This payload format has three optional parameters, "max-fr", "max-fs", parameters: max-fr,
      max-fs, and "profile-id".</t> profile-id.</t>
      <t>The max-fr and max-fs parameters are used to signal the capabilities
      of a receiver implementation. If the implementation is willing to
      receive media, both parameters MUST <bcp14>MUST</bcp14> be provided. These
      parameters MUST
            NOT <bcp14>MUST NOT</bcp14> be used for any other purpose.  A
      media sender SHOULD NOT <bcp14>SHOULD NOT</bcp14> send media with a frame rate or
      frame size exceeding the max-fr and max-fs values signaled.  (There may
      be scenarios, such as pre-encoded media or <xref target='RFC7667'>selective target="RFC7667"
      format="default">selective forwarding middleboxes</xref>, where a media
      sender does not have media available that fits within a receivers receiver's
      max-fs and max-fr value; values; in such scenarios, a sender MAY <bcp14>MAY</bcp14>
      exceed the signaled values.)
            <list style="hanging">
                <t hangText="max-fr:">The
      </t>
      <dl newline="false" spacing="normal">
        <dt>max-fr:</dt>
        <dd>The value of max-fr is an integer
                indicating the maximum frame rate in units of frames per
                second that the decoder is capable of decoding.</t>

                <t hangText="max-fs:">The decoding.</dd>
        <dt>max-fs:</dt>
        <dd>The value of max-fs is an integer
                indicating the maximum frame size in units of macroblocks that
                the decoder is capable of decoding.</t>

                <t>The decoding.</dd>
		<dt/>

        <dd>The decoder is capable of decoding this frame size as long
                as the width and height of the frame in macroblocks are each less
                than int(sqrt(max-fs * 8)) - 8)); for instance, a max-fs of 1200
                (capable of supporting 640x480 resolution) will support widths
                and heights up to 1552 pixels (97 macroblocks).</t>

                <t hangText="profile-id:">The macroblocks).</dd>
        <dt>profile-id:</dt>
        <dd>The value of profile-id is an integer indicating the default
        coding profile, the profile (the subset of coding tools that may have been used to
        generate the stream or that the receiver supports). <xref target="TableOfProfileIds"/>
        target="TableOfProfileIds" format="default"/> lists all of the
        profiles defined in section Section 7.2 of <xref target="VP9-BITSTREAM"/> target="VP9-BITSTREAM"
        format="default"/> and the corresponding integer values to be used.</t>

		<t>If
        used.</dd>
        <dt/>

        <dd>If no profile-id is present, Profile 0 MUST <bcp14>MUST</bcp14> be inferred.  (The
                profile-id parameter was added relatively late in the development of this
                specification, so some existing implementations may not send it.)
                </t>

		<t>Informative
                </dd>
        <dt/>
        <dd>Informative note: See <xref target="TableOfProfiles"/> target="TableOfProfiles"
        format="default"/> for capabilities of coding profiles defined in section Section 7.2 of
        <xref target="VP9-BITSTREAM"/>.</t>
              </list></t> target="VP9-BITSTREAM" format="default"/>.</dd>
      </dl>
      <t>A receiver MUST <bcp14>MUST</bcp14> ignore any parameter unspecified in this
      specification.</t>

              <texttable

      <table anchor="TableOfProfileIds" title="Table of align="center">
        <name>Correspondence between profile-id
	  integer values representing the VP9 profile corresponding to the set of
	  coding tools supported.">
		<ttcol align="center">Profile</ttcol>
		<ttcol align="center">profile-id</ttcol>
		<c>0</c><c>0</c>
		<c>1</c><c>1</c>
		<c>2</c><c>2</c>
		<c>3</c><c>3</c>
	  </texttable>

	  <texttable VP9 Profile Integer</name>
        <thead>
          <tr>
            <th align="center">Profile</th>
            <th align="center">profile-id</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">0</td>
            <td align="center">0</td>
          </tr>
          <tr>
            <td align="center">1</td>
            <td align="center">1</td>
          </tr>
          <tr>
            <td align="center">2</td>
            <td align="center">2</td>
          </tr>
          <tr>
            <td align="center">3</td>
            <td align="center">3</td>
          </tr>
        </tbody>
      </table>
      <table anchor="TableOfProfiles" title="Table of profile
	  capabilities.">
		<ttcol align="center">Profile</ttcol>
		<ttcol align="center">
        <name>Profile Capabilities</name>
        <thead>
          <tr>
            <th align="center">Profile</th>
            <th align="center">Bit Depth</ttcol>
		<ttcol Depth</th>
            <th align="center">SRGB Colorspace</ttcol>
		<ttcol Colorspace</th>
            <th align="center">Chroma Subsampling</ttcol>
		<c>0</c><c>8</c><c>No</c><c>YUV 4:2:0</c>
		<c>1</c><c>8</c><c>Yes</c><c>YUV Subsampling</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">0</td>
            <td align="center">8</td>
            <td align="center">No</td>
            <td align="center">YUV 4:2:0</td>
          </tr>
          <tr>
            <td align="center">1</td>
            <td align="center">8</td>
            <td align="center">Yes</td>
            <td align="center">YUV 4:2:2,4:4:0 or 4:4:4</c>
		<c>2</c><c>10 4:4:4</td>
          </tr>
          <tr>
            <td align="center">2</td>
            <td align="center">10 or 12</c><c>No</c><c>YUV 4:2:0</c>
		<c>3</c><c>10 12</td>
            <td align="center">No</td>
            <td align="center">YUV 4:2:0</td>
          </tr>
          <tr>
            <td align="center">3</td>
            <td align="center">10 or 12</c><c>Yes</c><c>YUV 12</td>
            <td align="center">Yes</td>
            <td align="center">YUV 4:2:2,4:4:0 or 4:4:4</c>
	  </texttable> 4:4:4</td>
          </tr>
        </tbody>
      </table>
      <aside><t keepWithPrevious="true">Note: SRGB (often sRGB) = Standard Red-Green-Blue</t></aside>

      <section anchor="SDPParameters" title="SDP Parameters"> numbered="true" toc="default">
        <name>SDP Parameters</name>
        <section title="Mapping numbered="true" toc="default">
          <name>Mapping of Media Subtype Parameters to SDP"> SDP</name>

          <t>The media type video/VP9 video/vp9 string is mapped to fields in the
          Session Description Protocol (SDP) <xref target="RFC8866"/> target="RFC8866" format="default"/> as
          follows: <list style="symbols">
              <t>The </t>
          <ul spacing="normal">
            <li>The media name in the "m=" line of SDP MUST <bcp14>MUST</bcp14> be video.</t>

              <t>The video.</li>
            <li>The encoding name in the "a=rtpmap" line of SDP MUST
            <bcp14>MUST</bcp14> be VP9 (the media subtype).</t>

              <t>The subtype).</li>
            <li>The clock rate in the "a=rtpmap" line MUST <bcp14>MUST</bcp14> be 90000.</t>

              <t>The 90000.</li>
            <li>The parameters "max-fr" max-fr and "max-fs" MUST max-fs <bcp14>MUST</bcp14> be included in
              the "a=fmtp" line of SDP if the receiver wishes to declare its receiver
              capabilities. These parameters are expressed as a media subtype
	      string,
	      string in the form of a semicolon separated semicolon-separated list of
	      parameter=value pairs.</t>

              <t>The OPTIONAL pairs.</li>
            <li>The <bcp14>OPTIONAL</bcp14> parameter profile-id, when present, SHOULD <bcp14>SHOULD</bcp14> be
	      included in the "a=fmtp" line of SDP. This parameter is expressed
	      as a media subtype string, string in the form of a parameter=value
	      pair. When the parameter is not present, a value of 0 MUST <bcp14>MUST</bcp14> be
	      inferred for profile-id.</t>
            </list></t> profile-id.</li>
          </ul>
          <section title="Example"> numbered="true" toc="default">
            <name>Example</name>
            <t>An example of media representation in SDP is as follows:</t>

            <figure>
            <artwork>m=video
            <sourcecode type="sdp"><![CDATA[m=video 49170 RTP/AVPF 98
a=rtpmap:98 VP9/90000
a=fmtp:98 max-fr=30;max-fs=3600;profile-id=0
            </artwork>
            </figure>
            ]]></sourcecode>
          </section>
        </section>
        <section title="Offer/Answer Considerations"> numbered="true" toc="default">
          <name>Offer/Answer Considerations</name>
          <t>When VP9 is offered over RTP using SDP in an Offer/Answer model
          <xref target="RFC3264"/> target="RFC3264" format="default"/> for negotiation for unicast usage, the following
          limitations and rules apply: <list style="symbols">
	      <t>The </t>
          <ul spacing="normal">
            <li>The parameter identifying a media format configuration for VP9 is
	      profile-id. This media format configuration parameter MUST <bcp14>MUST</bcp14> be used
	      symmetrically; that is, the answerer MUST <bcp14>MUST</bcp14> either maintain this
	      configuration parameter or remove the media format (payload type)
	      completely if it is not supported.</t>

              <t>The supported.</li>
            <li>The max-fr and max-fs parameters are used declaratively to
              describe receiver capabilities, even in the Offer/Answer model.
              The values in an answer are used to describe the answerer's
              capabilities, and thus
              capabilities; thus, their values are set independently of the
              values in the offer.</t>

              <t>To offer.</li>
            <li>To simplify the handling and matching of these configurations, the
              same RTP payload type number used in the offer SHOULD <bcp14>SHOULD</bcp14> also be used
              in the answer and in a subsequent offer, as specified in <xref
              target="RFC3264"/>. target="RFC3264" format="default"/>. An answer or subsequent offer
	      MUST NOT
	      <bcp14>MUST NOT</bcp14> contain the payload type number used in the offer unless the
	      profile-id value is exactly the same as in the original offer.
              However, max-fr and max-fs parameters MAY <bcp14>MAY</bcp14> be changed in subsequent
              offers and answers, with the same payload type number, if an endpoint
              wishes to change its declared receiver capabilities.</t>
	  </list></t> capabilities.</li>
          </ul>
        </section>
      </section>
    </section>

    <section anchor="mediaTypeRegistration" title="Media numbered="true" toc="default">
      <name>Media Type Definition"> Definition</name>
      <t>This registration is done using uses the template defined in <xref
        target="RFC6838"/> target="RFC6838" format="default"/> and following <xref target="RFC4855"/>. <list
            style="hanging">
            <t hangText="Type name:">video</t>

            <t hangText="Subtype name:">VP9</t>

            <t hangText="Required parameters:">N/A.</t>

            <t hangText="Optional parameters:"><vspace blankLines="0"/> target="RFC4855" format="default"/>. </t>

<!--[rfced] Please note that after AUTH48 concludes, we will
     communicate any changes to the media type template in Section 7
     to IANA for corresponding updates to
     https://www.iana.org/assignments/media-types/video/VP9 to be
     made.-->

      <dl newline="false" spacing="normal">
        <dt>Type name:</dt>
        <dd>video</dd>
        <dt>Subtype name:</dt>
        <dd>VP9</dd>
        <dt>Required parameters:</dt>
        <dd>N/A</dd>
        <dt>Optional parameters:</dt>
        <dd>
            There are three optional parameters, "max-fr", "max-fs", parameters: max-fr, max-fs, and "profile-id". profile-id.
            See <xref target='payloadFormatParameters' /> target="payloadFormatParameters" format="default"/> for their definition.
            </t>

            <t hangText="Encoding considerations:"><vspace blankLines="0"/>
            </dd>
        <dt>Encoding considerations:</dt>
        <dd>
            This media type is framed in RTP and contains binary data; see
            Section 4.8 of
            <xref target="RFC6838"/>.</t>

            <t hangText="Security considerations:">See target="RFC6838" sectionFormat="of" section="4.8"
            format="default"/>.</dd>
        <dt>Security considerations:</dt>
        <dd>
          <t>See <xref
            target="securityConsiderations"/> target="securityConsiderations" format="default"/> of RFC xxxx. <vspace
            blankLines="0"/> [RFC Editor: Upon publication as an RFC, please
            replace "XXXX" with the number assigned to this document and
            remove this note.]</t>

            <t hangText="Interoperability considerations:">None.</t>

            <t hangText="Published specification:">VP9 9628. </t>

        </dd>
        <dt>Interoperability considerations:</dt>
        <dd>None</dd>
        <dt>Published specification:</dt>
        <dd>
          <t>VP9 bitstream format <xref
            target="VP9-BITSTREAM"/> target="VP9-BITSTREAM" format="default"/> and RFC XXXX. <vspace blankLines="0"/> [RFC
            Editor: Upon publication as an RFC, please replace "XXXX" with the
            number assigned to this document and remove this note.] <vspace
            blankLines="0"/></t>

            <t hangText="Applications which 9628. </t>

        </dd>
        <dt>Applications that use this media type:"><vspace
            blankLines="0"/> type:</dt>
        <dd> For example: Video example, video over IP, video
            conferencing.</t>

			<t hangText="Fragment
            conferencing.</dd>
        <dt>Fragment identifier considerations:">N/A.</t>

            <t hangText="Additional information:">None.</t>

            <t
            hangText="Person considerations:</dt>
        <dd>N/A</dd>
        <dt>Additional information:</dt>
        <dd>None</dd>
        <dt>Person &amp; email address to contact for further information:"><vspace
            blankLines="0"/> Jonathan Lennox &lt;jonathan.lennox@8x8.com&gt;</t>

            <t hangText="Intended usage:">COMMON</t>

            <t hangText="Restrictions information:</dt>
        <dd><t><contact fullname="Jonathan Lennox"/> &lt;jonathan.lennox@8x8.com&gt;</t></dd>
        <dt>Intended usage:</dt>
        <dd>COMMON</dd>
        <dt>Restrictions on usage:"><vspace blankLines="0"/> usage:</dt>
        <dd> This media type depends on RTP framing, and hence framing; hence, it is only defined
        for transfer via RTP <xref target="RFC3550"/>.</t>

            <t hangText="Author:">Jonathan Lennox &lt;jonathan.lennox@8x8.com&gt;</t>

            <t hangText="Change controller:"><vspace blankLines="0"/> target="RFC3550" format="default"/>.</dd>
        <dt>Author:</dt>
        <dd><t><contact fullname="Jonathan Lennox"/> &lt;jonathan.lennox@8x8.com&gt;</t></dd>

<!--[rfced] Please review the entry for "Change Controller" in Section
     7.  While we see similar text for the vp8 and vc2 entries, we want to
     confirm that this entry has been reviewed with the following in
     mind from
     https://www.iana.org/help/protocol-registration:

     "The IESG shouldn't be listed as a change controller unless the
     RFC that created the registry (e.g. port numbers, XML namespaces
     and schemas) requires it. The IETF should be named instead."

-->

        <dt>Change controller:</dt>
        <dd> IETF
            AVTCore Working Group delegated from the IESG.</t>
          </list></t> IESG.</dd>
      </dl>
    </section>
    <section anchor="securityConsiderations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>RTP packets using the payload format defined in this specification
      are subject to the security considerations discussed in the RTP
      specification <xref target="RFC3550"/>, target="RFC3550" format="default"/>, and in any
      applicable RTP profile such as <xref target='RFC3551'>RTP/AVP</xref>, target="RFC3551"
      format="default">RTP/AVP</xref>, <xref target='RFC4585'>RTP/AVPF</xref>, target="RFC4585"
      format="default">RTP/AVPF</xref>, <xref target='RFC3711'>RTP/SAVP</xref>, target="RFC3711"
      format="default">RTP/SAVP</xref>, or <xref target='RFC5124'>RTP/SAVPF</xref>. target="RFC5124"
      format="default">RTP/SAVPF</xref>.  However, as "<xref target="RFC7202" format="title"/>" <xref target='RFC7202'>"Securing the RTP Protocol
      Framework: Why RTP Does Not Mandate a Single Media
      Security Solution"</xref> target="RFC7202"
      format="default"></xref> 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 integrity,
      and source authenticity for RTP in general.  This responsibility lays on lies with
      anyone using RTP in an application.  They can find guidance on available
      security mechanisms in "<xref target="RFC7201" format="title"/> <xref target='RFC7201'>Options for Securing
      RTP Sessions</xref>. target="RFC7201" format="default"></xref>.  Applications SHOULD <bcp14>SHOULD</bcp14>
      use one or more appropriate strong security mechanisms.  The rest of this security
      consideration section discusses the security impacting properties of the
      payload format itself.</t> mechanisms.</t>
      <t>Implementations of this RTP payload format need to take appropriate
      security considerations into account.  It is extremely important for the
      decoder to be robust against malicious or malformed payloads and ensure
      that they do not cause the decoder to overrun its allocated memory or
      otherwise mis-behave. misbehave.  An overrun in allocated memory could lead to
      arbitrary code execution by an attacker.  The same applies to the
      encoder, even though problems in encoders are typically (typically) rarer.</t>
      <t>This RTP payload format and its media decoder do not exhibit any
      significant non-uniformity in the receiver-side computational complexity
      for packet
      processing, and thus processing; thus, they are unlikely to pose a denial-of-service
      threat due to the receipt of pathological data. Nor does the RTP payload
      format contain any active content.</t>
    </section>
    <section anchor="congestionControl" title="Congestion Control"> numbered="true" toc="default">
      <name>Congestion Control</name>
      <t>Congestion control for RTP SHALL <bcp14>SHALL</bcp14> be used in accordance
      with RFC 3550 <xref target="RFC3550"/>, target="RFC3550" format="default"/>, and with any
      applicable RTP profile; profile, e.g., RFC
      3551 <xref target="RFC3551"/>. target="RFC3551"
      format="default"/>. The congestion control mechanism can, in a real-time
      encoding scenario, adapt the transmission rate by instructing the
      encoder to encode at a certain target rate. Media aware Media-aware network elements MAY
      <bcp14>MAY</bcp14> use the information in the VP9 payload descriptor in
      <xref target="VP9payloadDescriptor"/> target="VP9payloadDescriptor" format="default"/> to identify
      non-reference frames and discard them in order to reduce network
      congestion. Note that discarding of non-reference frames cannot be done
      if the stream is encrypted (because the non-reference marker is
      encrypted).</t>
    </section>
    <section anchor="IANAConsiderations" title="IANA Considerations">
      <t>The IANA is requested to register numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>IANA has registered the media type registration "video/vp9"
      as specified in <xref
      target="mediaTypeRegistration"/>. target="mediaTypeRegistration" format="default"/>.
      The media type is has also
      requested to
	  be been added to the IANA registry for
      "RTP Payload Format MIME types"
	  &lt;http://www.iana.org/assignments/rtp-parameters&gt;.</t>
    </section>

    <section title="Acknowledgments">
	  <t>Alex Eleftheriadis, Yuki Ito, Won Kap Jang, Sergio Garcia
	  Murillo, Roi Sasson, Timothy Terriberry, Emircan Uysaler, and
	  Thomas Volkert commented on the development Media Types" <eref
      target="https://www.iana.org/assignments/rtp-parameters"
      brackets="angle"/> subregistry of this document and
	  provided helpful comments and feedback.</t> the "Real-Time Transport Protocol (RTP) Paramaeters" registry as follows.</t>

      <dl spacing="compact">
	<dt>Media Type:</dt><dd>video</dd>
	<dt>Subtype:</dt><dd>VP9</dd>
	<dt>Clock Rate (Hz):</dt><dd>90000</dd>
	<dt>Reference:</dt><dd>RFC 9628</dd>
      </dl>

    </section>

  </middle>
  <back>
    <references title='Normative References'>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor='VP9-BITSTREAM' target='https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf'> anchor="VP9-BITSTREAM" target="https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf">
          <front>
            <title>VP9 Bitstream &amp; Decoding Process Specification</title>
            <author initials='A' surname='Grange' fullname='Adrian Grange'> initials="A" surname="Grange" fullname="Adrian Grange">
              <organization>Google</organization>
            </author>
            <author initials='P' surname='de Rivaz' fullname='Peter initials="P" surname="de Rivaz" fullname="Peter de Rivaz'> Rivaz">
              <organization>Argon Design</organization>
            </author>
            <author initials='J' surname='Hunt' fullname='Jonathan Hunt'> initials="J" surname="Hunt" fullname="Jonathan Hunt">
              <organization>Argon Design</organization>
            </author>
            <date month='March' day='31' year='2016' /> month="March" day="31" year="2016"/>
            <abstract>
              <t>
			  This document defines the bitstream format and decoding process for the
			  Google VP9 video codec.
              </t>
            </abstract>
          </front>
          <seriesInfo name='Version' value='0.6' name="Version" value="0.6"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8866.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml"/>

<!-- [I-D.ietf-avtext-lrr] companion document RFC 9627 -->
<reference anchor="RFC9627" target="https://www.rfc-editor.org/info/rfc9627">
   <front>
      <title>The Layer Refresh Request (LRR) RTCP Feedback Message</title>
      <author initials="J." surname="Lennox" fullname="Jonathan Lennox">
         <organization>Vidyo, Inc.</organization>
      </author>
      <author initials="D." surname="Hong" fullname="Danny Hong">
         <organization>Vidyo, Inc.</organization>
      </author>
      <author initials="J." surname="Uberti" fullname="Justin Uberti">
         <organization>Google, Inc.</organization>
      </author>
      <author initials="S." surname="Holmer" fullname="Stefan Holmer">
         <organization>Google, Inc.</organization>
      </author>
      <author initials="M." surname="Flodman" fullname="Magnus Flodman">
         <organization>Google, Inc.</organization>
      </author>
      <date month="August" year="2024" />
   </front>
   <seriesInfo name="RFC" value="9627" />
   <seriesInfo name="DOI" value="10.17487/RFC9627"/>

</reference>

      &rfc2119;

      &rfc8174;

      &rfc4585;

      &rfc3550;

      &rfc8866;

      &rfc6838;

      &rfc4855;

      &rfc5104;

      &lrr;

      &rfc3264;

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6386.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
      </references>

    <references title='Informative References'>

      &rfc3551;

	  &rfc5124;

          &rfc6386;

	  &rfc7201;

	  &rfc7202;

          &rfc7667;

          &rfc3711;
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t><contact fullname="Alex Eleftheriadis"/>, <contact fullname="Yuki
      Ito"/>, <contact fullname="Won Kap Jang"/>, <contact fullname="Sergio
      Garcia"/> <contact fullname="Murillo"/>, <contact fullname="Roi
      Sasson"/>, <contact fullname="Timothy Terriberry"/>, <contact
      fullname="Emircan Uysaler"/>, and <contact fullname="Thomas Volkert"/>
      commented on the development of this document and provided helpful
      feedback.</t>
    </section>
  </back>
</rfc>
<!--  LocalWords:  PictureID DCT Hadamard WHT SSRC CSRC pyld hdr FI VER RPSI
 -->
<!--  LocalWords:  stPartitionSize SDP AVPF SRTP IANA PID PICIDX TID
 -->