<?xmlversion="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY rfc3264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"> <!ENTITY rfc3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"> <!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"> ]>version='1.0' encoding='utf-8'?> <rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" version="3" 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" prepTime="2025-03-27T17:04:31" indexInclude="true" scripts="Common,Latin" tocDepth="3"> <link href="https://datatracker.ietf.org/doc/draft-ietf-payload-vp9-16" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc9628" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="RTP Payload Format for VP9">RTP Payload Format for VP9 Video</title> <seriesInfo name="RFC" value="9628" stream="IETF"/> <author fullname="Justin Uberti" initials="J." surname="Uberti"> <organizationabbrev="Google">Google, Inc.</organization>showOnFrontPage="true">OpenAI</organization> <address> <postal><street>747 6th Street South</street> <city>Kirkland</city> <region>WA</region> <code>98033</code> <country>USA</country><street>1455 3rd St</street> <city>San Francisco</city> <region>CA</region> <code>94158</code> <country>United States of America</country> </postal> <email>justin@uberti.name</email> </address> </author> <author fullname="Stefan Holmer" initials="S." surname="Holmer"> <organizationabbrev="Google">Google,abbrev="Google" showOnFrontPage="true">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"> <organizationabbrev="Google">Google,abbrev="Google" showOnFrontPage="true">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"> <organizationabbrev="Google">Google,abbrev="Google" showOnFrontPage="true">Google, Inc.</organization> <address> <postal><street>1585 Charleston Road</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>US</country><street>315 Hudson St.</street> <city>New York</city> <region>NY</region> <code>10013</code> <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,Jitsi" showOnFrontPage="true">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 month="03" year="2025"/> <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<abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1">This specification describes an RTP payload format for the VP9 video codec. The payload format has wideapplicability,applicability as it supports applications from lowbit-ratebitrate peer-to-peerusage,usage to highbit-ratebitrate video conferences. It includes provisions for temporal and spatial scalability.</t> </abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t indent="0" pn="section-boilerplate.1-2"> 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. </t> <t indent="0" pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc9628" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t indent="0" pn="section-boilerplate.2-1"> Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t indent="0" pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions">Conventions</xref></t> </li> <li pn="section-toc.1-1.3"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-media-format-description">Media Format Description</xref></t> </li> <li pn="section-toc.1-1.4"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-payload-format">Payload Format</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2"> <li pn="section-toc.1-1.4.2.1"> <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rtp-header-usage">RTP Header Usage</xref></t> </li> <li pn="section-toc.1-1.4.2.2"> <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-vp9-payload-descriptor">VP9 Payload Descriptor</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2"> <li pn="section-toc.1-1.4.2.2.2.1"> <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-scalability-structure-ss">Scalability Structure (SS)</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.4.2.3"> <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-frame-fragmentation">Frame Fragmentation</xref></t> </li> <li pn="section-toc.1-1.4.2.4"> <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-scalable-encoding-considera">Scalable Encoding Considerations</xref></t> </li> <li pn="section-toc.1-1.4.2.5"> <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-of-a-vp9-rtp-stream">Example of a VP9 RTP Stream</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2"> <li pn="section-toc.1-1.4.2.5.2.1"> <t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derivedContent="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-reference-picture-use-for-s">Reference Picture Use for Scalable Structure</xref></t> </li> </ul> </li> </ul> </li> <li pn="section-toc.1-1.5"> <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-feedback-messages-and-heade">Feedback Messages and Header Extensions</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2"> <li pn="section-toc.1-1.5.2.1"> <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-reference-picture-selection">Reference Picture Selection Indication (RPSI)</xref></t> </li> <li pn="section-toc.1-1.5.2.2"> <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-full-intra-request-fir">Full Intra Request (FIR)</xref></t> </li> <li pn="section-toc.1-1.5.2.3"> <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-layer-refresh-request-lrr">Layer Refresh Request (LRR)</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.6"> <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-payload-format-parameters">Payload Format Parameters</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-parameters">SDP Parameters</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.1.2"> <li pn="section-toc.1-1.6.2.1.2.1"> <t indent="0" pn="section-toc.1-1.6.2.1.2.1.1"><xref derivedContent="6.1.1" format="counter" sectionFormat="of" target="section-6.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-mapping-of-media-subtype-pa">Mapping of Media Subtype Parameters to SDP</xref></t> </li> <li pn="section-toc.1-1.6.2.1.2.2"> <t indent="0" pn="section-toc.1-1.6.2.1.2.2.1"><xref derivedContent="6.1.2" format="counter" sectionFormat="of" target="section-6.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-offer-answer-considerations">Offer/Answer Considerations</xref></t> </li> </ul> </li> </ul> </li> <li pn="section-toc.1-1.7"> <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type-definition">Media Type Definition</xref></t> </li> <li pn="section-toc.1-1.8"> <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.9"> <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-congestion-control">Congestion Control</xref></t> </li> <li pn="section-toc.1-1.10"> <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.11"> <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2"> <li pn="section-toc.1-1.11.2.1"> <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.11.2.2"> <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.12"> <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t> </li> <li pn="section-toc.1-1.13"> <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="intro"title="Introduction"> <t>This specificationnumbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1">This document describes an <xreftarget="RFC3550">RTP</xref>target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP</xref> payload specification applicable to the transmission of video streams encoded using the VP9 video codec <xreftarget="VP9-BITSTREAM"/>.target="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/>. The format described in this document can be used both in peer-to-peer and video conferencing applications.</t><t>The<t indent="0" pn="section-1-2">The VP9 video codec was developed byGoogle,Google and is the successor to its earlier <xreftarget="RFC6386">VP8</xref>target="RFC6386" format="default" sectionFormat="of" derivedContent="RFC6386">VP8</xref> codec. Above the compression improvements and other general enhancementsaboveto VP8, VP9 is also designed in a way that allowsspatially-scalablespatially scalable video encoding.</t> </section> <section anchor="conventions"title="Conventions, Definitions and Acronyms"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-conventions">Conventions</name> <t indent="0" pn="section-2-1"> 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 inBCP 14 <xref target="RFC2119"/>BCP 14 <xreftarget="RFC8174"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="mediaFormatDescription"title="Medianumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-media-format-description">Media FormatDescription"> <t>TheDescription</name> <t indent="0" pn="section-3-1">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<t indent="0" pn="section-3-2">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 ofkey frames.</t> <t>Thesekeyframes.</t> <t indent="0" pn="section-3-3">These features together enable an encoder to implement various forms of coarse-grained scalability, including temporal,spatialspatial, and quality scalability modes, as well as combinations of these, without the need for explicit scalable coding tools.</t><t>Temporal<t indent="0" pn="section-3-4">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<t indent="0" pn="section-3-5">This payload format specification defines how such temporal and spatial scalability layers can be described and communicated.</t><t>Temporal<t indent="0" pn="section-3-6">Temporal and spatial scalability layers are associated with non-negative integer IDs. The lowest layer of either type has an ID of0,zero and is sometimes referred to as the "base" temporal or spatial layer.</t><t>Layers<t indent="0" pn="section-3-7">Layers are designed, andMUST<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<t indent="0" pn="section-3-8">For terminology, this document uses the term "frame" to refer to a single encoded VP9 frame for a particularresolution/quality,resolution and/or quality, and "picture" to refer to all the representations (frames) at a single instant in time.AThus, a picturethusconsists of one or more frames, encoding different spatial layers.</t><t>Within<t indent="0" pn="section-3-9">Within a picture, a frame withspatial layerspatial-layer ID equal toSID,S, whereSID >S > 0, can depend on a frame of the same picture with a lowerspatial layerspatial-layer ID. This "inter-layer" dependency can result in additional coding gain compared to the case where onlytraditional"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, aspatial layer SIDspatial-layer S frame can depend only on the immediately previousspatial layer SID-1spatial-layer S-1 frame, when S>> 0. Additionally, if inter-picture dependency is used, aspatial layer SIDspatial-layer S frame is assumed to only depend on a previously codedspatial layer SIDspatial-layer S frame.</t><t>Given<t indent="0" pn="section-3-10">Given the above simplifications for inter-layer and inter-picture dependencies, a flag (the D bit described below) is used to indicate whether aspatial layerspatial-layer SID frame depends on thespatial layerspatial-layer SID-1 frame. Given the D bit, a receiver only needs to additionally know the inter-picture dependency structure for a givenspatial layerspatial-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 akey framekeyframe withtemporal layera temporal-layer ID equal to0.</t> <t>Inzero.</t> <t indent="0" pn="section-3-11">In flexible mode, each packet can contain up to3three 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 thetemporal layertemporal-layer structure. Since this is signaled in eachpacketpacket, it makes it possible to have very flexibletemporal layer hierarchies,temporal-layer hierarchies and scalabilitystructuresstructures, which are changing dynamically.</t><t>In<t indent="0" pn="section-3-12">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 aPicture Group (PG)."Picture Group" (or "PG"). In this mode, the inter-picture dependencies (the reference indices) of thePicture Group MUSTPG <bcp14>MUST</bcp14> be pre-specified as part of thescalability structureScalability Structure (SS) data. Each packet has an index to refer to one of the described pictures in thePG,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 pn="section-3-13"> <t indent="0" pn="section-3-13.1">Note: A "PictureGroup",Group" or "PG", as used in this document, is not the same thing as the term "Group of Pictures" as it istraditionallycommonly used in video coding,i.e.i.e., to mean anindependently-decoadableindependently decodable run of pictures beginning with akeyframe.)</t> <t>Thekeyframe.</t> </aside> <t indent="0" pn="section-3-14">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> </section> <section anchor="payloadFormat"title="Payload Format"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-payload-format">Payload Format</name> <t indent="0" pn="section-4-1">This section describes how the encoded VP9 bitstream is encapsulated in RTP. To handle networklosseslosses, usage of RTP/AVPF <xreftarget="RFC4585"/>target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/> isRECOMMENDED.<bcp14>RECOMMENDED</bcp14>. All integer fields inthe specificationsthis specification are encoded as unsigned integers in network octet order.</t> <section anchor="RTPHeaderUsage"title="RTPnumbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-rtp-header-usage">RTP HeaderUsage"> <figure anchor="figureRTPHeader"> <preamble>TheUsage</name> <t keepWithNext="true" indent="0" pn="section-4.1-1">The general RTP payload format for VP9 is depictedbelow.</preamble> <artwork><![CDATA[below.</t> <figure anchor="figureRTPHeader" align="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-general-rtp-payload-format-">General RTP Payload Format for VP9</name> <artwork type="" align="left" alt="" pn="section-4.1-2.1"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | VP9 payload descriptor (integer #octets) | : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | + | : VP9 payload : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> <postamble>The</artwork> </figure> <t keepWithPrevious="true" indent="0" pn="section-4.1-3">See <xref target="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Section 4.2"/> for more information on the VP9 payloaddescriptor will be described in <xref target="VP9payloadDescriptor"/>;descriptor; the VP9 payload is described in <xreftarget="VP9-BITSTREAM"/>. OPTIONALtarget="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/>. <bcp14>OPTIONAL</bcp14> RTP paddingMUST NOT<bcp14>MUST NOT</bcp14> be included unless the P bit isset.</postamble> </figure> <t><list style="hanging"> <t hangText="Markerset.</t> <dl newline="false" spacing="normal" indent="3" pn="section-4.1-4"> <dt pn="section-4.1-4.1">Marker bit (M):</dt> <dd pn="section-4.1-4.2">This bit(M):">MUST<bcp14>MUST</bcp14> be set to1one for the final packet of the highestspatial layerspatial-layer frame (the final packet of thepicture), and 0 otherwise.picture); otherwise, it is zero. Unless spatial scalability is in use for this picture, this bit will have the same value as the E bit describedbelow.in <xref target="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Note this bitMUST<bcp14>MUST</bcp14> be set to1one for the targetspatial layerspatial-layer frame if a stream is being rewritten to remove higher spatiallayers.</t> <t hangText="Payloadlayers.</dd> <dt pn="section-4.1-4.3">Payload Type(PT):">In(PT):</dt> <dd pn="section-4.1-4.4">In line with the policy inSection 3 of<xreftarget='RFC3551'/>,target="RFC3551" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3551#section-3" derivedContent="RFC3551"/>, applications using the VP9 RTP payload profileMUST<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 <xreftarget="SDPParameters"/>target="SDPParameters" format="default" sectionFormat="of" derivedContent="Section 6.1"/> for the mechanism to be used with the <xreftarget='RFC8866'>Sessiontarget="RFC8866" format="default" sectionFormat="of" derivedContent="RFC8866">Session Description Protocol(SDP)</xref>.</t> <t hangText="Timestamp:">The <xref target="RFC3550">RTP(SDP)</xref>.</dd> <dt pn="section-4.1-4.5">Timestamp:</dt> <dd pn="section-4.1-4.6">The <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">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 multiplelayerframes, all of the frames of the pictureMUST<bcp14>MUST</bcp14> have the sametimestamp.</t> <t>Iftimestamp.</dd> <dt pn="section-4.1-4.7"/> <dd pn="section-4.1-4.8">If a frame has the VP9 show_frame field set to0zero (i.e., it is meant only to populate a referencebuffer,buffer without beingoutput)output), its timestampMAY<bcp14>MAY</bcp14> alternatively be set to be the same as the subsequent frame with show_frame equal to1.one. (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 picture containing a frame with show_frame==1, however,MUST<bcp14>MUST</bcp14> have a unique timestamp modulo the2^322<sup>32</sup> wrap of thefield.</t> </list></t> <t>Thefield.</dd> </dl> <t indent="0" pn="section-4.1-5">The remaining RTP Fixed Header Fields (V, P, X, CC, sequence number,SSRCSSRC, and CSRC identifiers) are used as specified inSection 5.1 of<xreftarget="RFC3550"/>.</t>target="RFC3550" sectionFormat="of" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-5.1" derivedContent="RFC3550"/>.</t> </section> <section anchor="VP9payloadDescriptor"title="VP9numbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-vp9-payload-descriptor">VP9 PayloadDescriptor"> <figure anchor="figureVP9payloadDescriptor"> <preamble>InDescriptor</name> <t keepWithNext="true" indent="0" pn="section-4.2-1">In flexible mode (with the F bit below set to1),one), the first octets after the RTP header are the VP9 payload descriptor, with the followingstructure.</preamble> <artwork><![CDATA[structure.</t> <figure anchor="figureVP9payloadDescriptor" align="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-flexible-mode-format-for-vp">Flexible Mode Format for VP9 Payload Descriptor</name> <artwork name="" type="" align="left" alt="" pn="section-4.2-2.1"> 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></artwork> </figure><figure anchor="figureVP9payloadDescriptorNonFlexible"> <preamble>In<t keepWithNext="true" indent="0" pn="section-4.2-3">In non-flexible mode (with the F bit below set to0),zero), the first octets after the RTP header are the VP9 payload descriptor, with the followingstructure.</preamble> <artwork><![CDATA[structure.</t> <figure anchor="figureVP9payloadDescriptorNonFlexible" align="left" suppress-title="false" pn="figure-3"> <name slugifiedName="name-non-flexible-mode-format-fo">Non-Flexible Mode Format for VP9 Payload Descriptor</name> <artwork name="" type="" align="left" alt="" pn="section-4.2-4.1"> 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></artwork> </figure><t><list style="hanging"><thangText="I:">Pictureindent="0" pn="section-4.2-5">Except as noted, the following field descriptions apply to the payload descriptor formats in both Figures <xref target="figureVP9payloadDescriptor" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="figureVP9payloadDescriptorNonFlexible" format="counter" sectionFormat="of" derivedContent="3"/>.</t> <dl newline="false" spacing="normal" indent="3" pn="section-4.2-6"> <dt pn="section-4.2-6.1">I:</dt> <dd pn="section-4.2-6.2">Picture ID (PID) present. When set to one, theOPTIONAL<bcp14>OPTIONAL</bcp14> PIDMUST<bcp14>MUST</bcp14> be present after the mandatory first octet and specified as below. Otherwise, PIDMUST 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 to0 (i.e.zero (i.e., non-flexible scalability mode is in use), then this bitMUST<bcp14>MUST</bcp14> be set on everypacket.</t> <t hangText="P:">Inter-picturepacket.</dd> <dt pn="section-4.2-6.3">P:</dt> <dd pn="section-4.2-6.4">Inter-picture predicted frame. When set to zero, 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 lowerspatial layerspatial-layer frame. PSHOULD<bcp14>SHOULD</bcp14> also be set to zero when encoding a layer synchronization frame in response toana <xreftarget='I-D.ietf-avtext-lrr'>LRR</xref>target="RFC9627" format="default" sectionFormat="of" derivedContent="RFC9627">Layer Refresh Request (LRR)</xref> message (see <xreftarget='LRR'/>).target="LRR" format="default" sectionFormat="of" derivedContent="Section 5.3"/>). When P is set to zero, theTIDTemporal-layer ID (TID) field (described below)MUST<bcp14>MUST</bcp14> also be set to0zero (if present). Note that the P bit does not forbid intra-picture, inter-layer prediction from earlier frames of the same picture, ifany.</t> <t hangText="L:">Layerany.</dd> <dt pn="section-4.2-6.5">L:</dt> <dd pn="section-4.2-6.6">Layer indices present. When set to one, 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 to1one (indicating flexible mode), then only one octet is present for the layer indices.OtherwiseOtherwise, if the F bit is set to0zero (indicating non-flexible mode), then two octets are present for the layerindices.</t> <t hangText="F:">Flexibleindices.</dd> <dt pn="section-4.2-6.7">F:</dt> <dd pn="section-4.2-6.8">Flexible mode.FWhen set tooneone, this indicates flexiblemode andmode; if the P bit is also set to one, then the octets following the mandatory first octet, the PID, and layer indices (if present) are as described by"Reference"reference indices" below. ThisMUSTbit <bcp14>MUST</bcp14> only be set to1one if the I bit is also set to one; if the I bit is set to zero, then thisMUSTbit <bcp14>MUST</bcp14> also be set to zero and ignored by receivers. (Flexible mode'sReferencereference indices are defined as offsets from the Picture ID field, so they would have no meaning if I were not set.) The value ofthisthe F bitMUST<bcp14>MUST</bcp14> only change on the first packet of a key picture. Akey picture"key picture" is a picture whose basespatial layerspatial-layer frame is akey frame,keyframe, andwhichthus one which completely resets the encoder state. This packet will have its P bit equal to zero, SID or L bit (described below) equal to zero, and B bit (described below) equal to1.</t> <t hangText="B:">Startone.</dd> <dt pn="section-4.2-6.9">B:</dt> <dd pn="section-4.2-6.10">Start ofa frame. MUSTFrame. This bit <bcp14>MUST</bcp14> be set to1one if the first payload octet of the RTP packet is the beginning of a new VP9frame, and MUST NOTframe; otherwise, it <bcp14>MUST NOT</bcp14> be1 otherwise.one. Note that this frame might not be the first frame of apicture.</t> <t hangText="E:">Endpicture.</dd> <dt pn="section-4.2-6.11">E:</dt> <dd pn="section-4.2-6.12">End ofa frame. MUSTFrame. This bit <bcp14>MUST</bcp14> be set to1one for the final RTP packet of a VP9frame, and 0 otherwise.frame; otherwise, it is zero. 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 bitabove.</t> <t hangText="V:">Scalability structureabove.</dd> <dt pn="section-4.2-6.13">V:</dt> <dd pn="section-4.2-6.14">Scalability Structure (SS) data present. When set to one, theOPTIONAL<bcp14>OPTIONAL</bcp14> SS dataMUST<bcp14>MUST</bcp14> be present in the payload descriptor. Otherwise, the SS dataMUST NOT<bcp14>MUST NOT</bcp14> bepresent.</t> <t hangText="Z:">Notpresent.</dd> <dt pn="section-4.2-6.15">Z:</dt> <dd pn="section-4.2-6.16">Not a reference frame for upper spatial layers. If set to1,one, indicates that frames with higher spatial layers SID+1 and greater of the current and following pictures do not depend on the currentspatial layerspatial-layer SID frame. This enables a decoderwhichthat 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 (seebelow).</t> </list></t> <t>Thebelow).</dd> </dl> <t indent="0" pn="section-4.2-7">The mandatory first octet is followed by the extension data fields that areenabled:<list style="hanging"> <t hangText="M:">Theenabled:</t> <dl newline="false" spacing="normal" indent="3" pn="section-4.2-8"> <dt pn="section-4.2-8.1">M:</dt> <dd pn="section-4.2-8.2">The most significant bit of the first octet is an extension flag. The fieldMUST<bcp14>MUST</bcp14> be present if the I bit is equal to one. If M is set, the PID fieldMUST<bcp14>MUST</bcp14> contain 15 bits; otherwise, itMUST<bcp14>MUST</bcp14> contain 7 bits. See PIDbelow.</t> <t hangText="Picturebelow.</dd> <dt pn="section-4.2-8.3">Picture ID(PID):">Picture(PID):</dt> <dd pn="section-4.2-8.4">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 by1one for each picture it sends.(Note however(Note, however, that because a middlebox can discard pictures where permitted by thescalability structure,SS, Picture IDs as received by a receiver might not be contiguous.) This fieldMUST<bcp14>MUST</bcp14> be present if the I bit is equal to one. If M is set to zero, 7 bits carry the PID;elseelse, if M is set to one, 15 bits carry the PID in network byte order. The sender may choose between a 7- or 15-bit index. The PIDSHOULD<bcp14>SHOULD</bcp14> start on a randomnumber,number andMUST<bcp14>MUST</bcp14> wrap after reaching the maximum ID (0x7f or 0x7fff depending on the index size chosen). The receiverMUST NOT<bcp14>MUST NOT</bcp14> assume that the number of bits in the PIDstaystays the same through the session. If this field transitions from7-bits7 bits to15-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 is0xbf). </t> <t>In0x3f). </dd> <dt pn="section-4.2-8.5"/> <dd pn="section-4.2-8.6">In the non-flexible mode (when the F bit is set to0),zero), this PID is used as an index to thepicture group (PG)PG specified in the SS data below. In this mode, the PID of thekey framekeyframe 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>Allrespectively.</dd> <dt pn="section-4.2-8.7"/> <dd pn="section-4.2-8.8">All frames of the same pictureMUST<bcp14>MUST</bcp14> have the same PIDvalue.</t> <t>Framesvalue.</dd> <dt pn="section-4.2-8.9"/> <dd pn="section-4.2-8.10">Frames (and their corresponding pictures) with the VP9 show_frame field equal to0 MUSTzero <bcp14>MUST</bcp14> have distinct PID values from subsequent pictures with show_frame equal to1.one. Thus, aPicture aspicture (as defined in thisspecificationspecification) is different than a VP9Superframe.</t> <t>Allsuperframe.</dd> <dt pn="section-4.2-8.11"/> <dd pn="section-4.2-8.12">All frames of the same pictureMUST<bcp14>MUST</bcp14> have the same value forshow_frame.</t> <t hangText="Layer indices:">This informationshow_frame.</dd> <dt pn="section-4.2-8.13">Layer indices:</dt> <dd pn="section-4.2-8.14">This field is optional butRECOMMENDED<bcp14>RECOMMENDED</bcp14> whenever encoding with layers. For both flexible and non-flexible modes, one octet is used to specify a layer frame'stemporal layerTemporal-layer ID (TID) andspatial layerSpatial-layer ID (SID) as shown both in Figures <xreftarget="figureVP9payloadDescriptor"/>target="figureVP9payloadDescriptor" format="counter" sectionFormat="of" derivedContent="2"/> and <xreftarget="figureVP9payloadDescriptorNonFlexible"/>.target="figureVP9payloadDescriptorNonFlexible" format="counter" sectionFormat="of" derivedContent="3"/>. 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 currentframe.</t> <t>Inframe.</dd> <dt pn="section-4.2-8.15"/> <dd pn="section-4.2-8.16">In the non-flexible mode (when the F bit is set to0),zero), another octet is used to representtemporal layerthe Temporal Layer 0indexPicture Index (8 bits) (TL0PICIDX), as depicted in <xreftarget="figureVP9payloadDescriptorNonFlexible"/>.target="figureVP9payloadDescriptorNonFlexible" format="default" sectionFormat="of" derivedContent="Figure 3"/>. The TL0PICIDX is present so that all minimally required frames- the(the basetemporal layer frames -temporal-layer frames) can betracked.</t> <t>Thetracked.</dd> <dt pn="section-4.2-8.17"/> <dd pn="section-4.2-8.18"> <t indent="0" pn="section-4.2-8.18.1">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" indent="3" pn="section-4.2-8.18.2"> <dt pn="section-4.2-8.18.2.1">TID:</dt> <dd pn="section-4.2-8.18.2.2">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 TIDMUST<bcp14>MUST</bcp14> match the corresponding TID value of the mapped picture in thePG.</t> <t hangText="U:">SwitchingPG.</dd> <dt pn="section-4.2-8.18.2.3">U:</dt> <dd pn="section-4.2-8.18.2.4">Switching up point.IfWhen this bit is set to1 forone, if the current picturewith temporal layerhas a temporal-layer ID equal toTID,value T, then"switch up" to a higher frame rate is possible assubsequenthigher temporal layerpictures with temporal-layer ID values higher than T will not depend on any picture before the current picture (incodingdecode order) withtemporal layera temporal-layer ID value greater thanTID.</t> <t hangText="SID:">The spatial layerT.</dd> <dt pn="section-4.2-8.18.2.5">SID:</dt> <dd pn="section-4.2-8.18.2.6">The spatial-layer ID of the current frame. Note that frames withspatial layerspatial-layer SID>> 0 may be dependent on decodedspatial layerspatial-layer SID-1 frame within the same picture. Different frames of the same pictureMUST<bcp14>MUST</bcp14> have distinctspatial layerspatial-layer IDs, and frames' spatial layersMUST<bcp14>MUST</bcp14> appear in increasing order within theframe.</t> <t hangText="D:">Inter-layerframe.</dd> <dt pn="section-4.2-8.18.2.7">D:</dt> <dd pn="section-4.2-8.18.2.8">Inter-layer dependency is used.MUSTD <bcp14>MUST</bcp14> be set to one if and only if the currentspatial layerspatial-layer SID frame depends onspatial layerspatial-layer SID-1 frame of the samepicture, otherwise MUSTpicture; otherwise, it <bcp14>MUST</bcp14> be set to zero. For thebase layerbase-layer frame (with SID equal to0), thiszero), the D bitMUST<bcp14>MUST</bcp14> be set tozero.</t> <t hangText="TL0PICIDX:">8 bits temporal layer zero index.zero.</dd> <dt pn="section-4.2-8.18.2.9">TL0PICIDX:</dt> <dd pn="section-4.2-8.18.2.10">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 temporalbase layerbase-layer pictures, i.e., the pictures with a TID set to0.zero. If the TID is larger than0,zero, TL0PICIDX indicates which temporalbase layerbase-layer picture the current picture depends on. TL0PICIDXMUST<bcp14>MUST</bcp14> be incremented by1one when the TID is equal to0.zero. The indexSHOULD<bcp14>SHOULD</bcp14> start on a randomnumber,number andMUST<bcp14>MUST</bcp14> restart at0zero after reaching the maximum number255.</t> </list></t>255.</dd> </dl> </dd> <dt pn="section-4.2-8.19">Reference indices:</dt> <dd pn="section-4.2-8.20"> <thangText="Reference indices:">Whenindent="0" pn="section-4.2-8.20.1">When P and F are both set to one, indicating anon-key framenon-keyframe in flexible mode, then at least one reference indexMUST<bcp14>MUST</bcp14> be specified as below. Additional reference indices(total(a total of up to3three reference indices are allowed) may be specified using the N bit below. When either P or F is set to zero, then no reference index is specified.<list style="hanging"> <t hangText="P_DIFF:">The</t> <dl newline="false" spacing="normal" indent="3" pn="section-4.2-8.20.2"> <dt pn="section-4.2-8.20.2.1">P_DIFF:</dt> <dd pn="section-4.2-8.20.2.2">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 of0zero isinvalid.</t> <t hangText="N:">1invalid.</dd> <dt pn="section-4.2-8.20.2.3">N:</dt> <dd pn="section-4.2-8.20.2.4">1 if there is additional P_DIFF following the currentP_DIFF.</t> </list></t> </list></t>P_DIFF.</dd> </dl> </dd> </dl> <section anchor="VP9payloadDescriptorSS"title="Scalabilitynumbered="true" toc="include" removeInRFC="false" pn="section-4.2.1"> <name slugifiedName="name-scalability-structure-ss">Scalability Structure(SS):"> <t>The scalability structure (SS)(SS)</name> <t indent="0" pn="section-4.2.1-1">The SS data describes the resolution of each frame within a picture as well as the inter-picture dependencies for apicture 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 <xreftarget="figureVP9payloadDescriptor"/>format="counter" target="figureVP9payloadDescriptor" sectionFormat="of" derivedContent="2"/> and <xreftarget="figureVP9payloadDescriptorNonFlexible"/>.</t>target="figureVP9payloadDescriptorNonFlexible" format="counter" sectionFormat="of" derivedContent="3"/>.</t> <figureanchor="figureVP9ScalabilityStructure"> <artwork><![CDATA[anchor="figureVP9ScalabilityStructure" align="left" suppress-title="false" pn="figure-4"> <name slugifiedName="name-vp9-scalability-structure">VP9 Scalability Structure</name> <artwork name="" type="" align="left" alt="" pn="section-4.2.1-2.1"> +-+-+-+-+-+-+-+-+ 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></artwork> </figure><t><list style="hanging"> <t hangText="N_S:">N_S<dl newline="false" spacing="normal" indent="3" pn="section-4.2.1-3"> <dt pn="section-4.2.1-3.1">N_S:</dt> <dd pn="section-4.2.1-3.2">Number of Spatial Layers Minus 1. N_S + 1 indicates the number of spatial layers present in the VP9stream.</t> <t hangText="Y:">Eachstream.</dd> <dt pn="section-4.2.1-3.3">Y:</dt> <dd pn="section-4.2.1-3.4">Each spatial layer's frame resolution is present. When set to one, theOPTIONAL<bcp14>OPTIONAL</bcp14> WIDTH (2 octets) and HEIGHT (2 octets)MUST<bcp14>MUST</bcp14> be present for each layer frame. Otherwise, the resolutionMUST NOT<bcp14>MUST NOT</bcp14> bepresent.</t> <t hangText="G:">PGpresent.</dd> <dt pn="section-4.2.1-3.5">G:</dt> <dd pn="section-4.2.1-3.6">The PG description presentflag.</t> <t hangText="-:">Bitflag.</dd> <dt pn="section-4.2.1-3.7">-:</dt> <dd pn="section-4.2.1-3.8">A bit reserved for future use.MUSTIt <bcp14>MUST</bcp14> be set to zero andMUST<bcp14>MUST</bcp14> be ignored by thereceiver.</t> <t hangText="N_G:">N_Greceiver.</dd> <dt pn="section-4.2.1-3.9">N_G:</dt> <dd pn="section-4.2.1-3.10">N_G indicates the number of pictures in aPicture Group (PG).PG. If N_G is greater than0,zero, 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 than0,zero, then for N_G pictures in the PG, each picture'stemporal layerTemporal-layer ID (TID), switch up point (U), andthe Referencereference indices (P_DIFFs) arespecified.</t> <t>Thespecified.</dd> <dt pn="section-4.2.1-3.11"/> <dd pn="section-4.2.1-3.12">The first picture specified in the PGMUST<bcp14>MUST</bcp14> have a TID set to0.</t> <t>Gzero.</dd> <dt pn="section-4.2.1-3.13"/> <dd pn="section-4.2.1-3.14">G set to0zero or N_G set to0zero 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 thebitstream.</t> <t>Notebitstream.</dd> <dt pn="section-4.2.1-3.15"/> <dd pn="section-4.2.1-3.16">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 eachother andother; this can be described with the use of the D bit described above. The specified dependency structure in the SS dataMUST<bcp14>MUST</bcp14> be for the highest frame ratelayer.</t> </list></t> <t>Inlayer.</dd> <dt pn="section-4.2.1-3.17">R:</dt> <dd pn="section-4.2.1-3.18">The number of P_DIFF fields that are present.</dd> </dl> <t indent="0" pn="section-4.2.1-4">In a scalable stream sent with a fixed pattern, the SS dataSHOULD<bcp14>SHOULD</bcp14> be included in the first packet of every key frame. This is a packet with the P bit equal to zero, SID or L bit equal to zero, and B bit equal to1.one. The SS dataMUST<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 than0).</t>zero).</t> </section> </section> <sectiontitle="Frame Fragmentation"> <t>VP9numbered="true" toc="include" removeInRFC="false" pn="section-4.3"> <name slugifiedName="name-frame-fragmentation">Frame Fragmentation</name> <t indent="0" pn="section-4.3-1">VP9 frames are fragmented intopackets,packets in RTP sequence numberorder,order: beginning with a packet with the B bitset,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> <sectiontitle="Scalable encoding considerations"> <t>Innumbered="true" toc="include" removeInRFC="false" pn="section-4.4"> <name slugifiedName="name-scalable-encoding-considera">Scalable Encoding Considerations</name> <t indent="0" pn="section-4.4-1">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<t indent="0" pn="section-4.4-2">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<t indent="0" pn="section-4.4-3">For spatially scalable streams, this means that "error_resilient_mode" needs to be turned on for the base spatial layer; however, it canhoweverbe 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 onlytemporally-scalabletemporally scalable without spatial scalability, "error_resilient_mode" can additionally be turned off for any picture that immediately follows atemporal layertemporal-layer 0 frame.</t> </section> <sectiontitle="Examplesnumbered="true" toc="include" removeInRFC="false" pn="section-4.5"> <name slugifiedName="name-example-of-a-vp9-rtp-stream">Example of a VP9 RTPStream">Stream</name> <sectiontitle="Reference picture usenumbered="true" toc="include" removeInRFC="false" pn="section-4.5.1"> <name slugifiedName="name-reference-picture-use-for-s">Reference Picture Use forscalable structure"> <t>AsScalable Structure</name> <t indent="0" pn="section-4.5.1-1">As discussed in <xreftarget="mediaFormatDescription"/>,target="mediaFormatDescription" format="default" sectionFormat="of" derivedContent="Section 3"/>, 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> <t>This<table align="center" pn="table-1"> <name slugifiedName="name-example-scalability-structu">Example Scalability Structure</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Temporal</th> <th align="center" colspan="1" rowspan="1">Spatial</th> <th align="center" colspan="1" rowspan="1">References</th> <th align="center" colspan="1" rowspan="1">Updates</th> </tr> </thead> <tbody> <tr> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">0</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">0,1</td> <td align="center" colspan="1" rowspan="1">1</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">1,2</td> <td align="center" colspan="1" rowspan="1">2</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">6</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">1,6</td> <td align="center" colspan="1" rowspan="1">7</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">2,7</td> <td align="center" colspan="1" rowspan="1">-</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">3</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">1,3</td> <td align="center" colspan="1" rowspan="1">4</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">2,4</td> <td align="center" colspan="1" rowspan="1">5</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">3</td> <td align="center" colspan="1" rowspan="1">6</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">4,6</td> <td align="center" colspan="1" rowspan="1">7</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">5,7</td> <td align="center" colspan="1" rowspan="1">-</td> </tr> </tbody> </table> <t indent="0" pn="section-4.5.1-3">This structure is constructed such that the"U"U bit can always be set.</t> </section> </section> </section> <section anchor="Feedback"title="Feedbacknumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-feedback-messages-and-heade">Feedback Messages and HeaderExtensions">Extensions</name> <section anchor="RPSI"title="Referencenumbered="true" toc="include" removeInRFC="false" pn="section-5.1"> <name slugifiedName="name-reference-picture-selection">Reference Picture Selection Indication(RPSI)"> <t>The reference picture selection index(RPSI)</name> <t indent="0" pn="section-5.1-1">The 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 twoways. Eitherways: 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 isperfect -- 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 forpoint to pointpoint-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 <xreftarget="RFC4585"/>)target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>) is simply the(7(7- or15 bit)15-bit) Picture ID of the received frame.</t><t>Note:<aside pn="section-5.1-2"> <t indent="0" pn="section-5.1-2.1">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> </aside> </section> <sectiontitle='Fullanchor="FIR" numbered="true" toc="include" removeInRFC="false" pn="section-5.2"> <name slugifiedName="name-full-intra-request-fir">Full Intra Request(FIR)' anchor="FIR"> <t>The(FIR)</name> <t indent="0" pn="section-5.2-1">The <xreftarget='RFC5104'>Fulltarget="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">Full Intra Request (FIR)</xref> RTCP feedback message allows a receiver to request a full state refresh of an encoded stream.</t><t>Upon<t indent="0" pn="section-5.2-2">Upon receipt ofana FIR request, a VP9 senderMUST<bcp14>MUST</bcp14> send a picture with a keyframe for itsspatial layerspatial-layer 0 layerframe,frame and then send frames without inter-picture prediction (P=0) for anyhigher layerhigher-layer frames.</t> </section> <sectiontitle="Layeranchor="LRR" numbered="true" toc="include" removeInRFC="false" pn="section-5.3"> <name slugifiedName="name-layer-refresh-request-lrr">Layer Refresh Request(LRR)" anchor="LRR"> <t>The(LRR)</name> <t indent="0" pn="section-5.3-1">The <xreftarget="I-D.ietf-avtext-lrr">Layertarget="RFC9627" format="default" sectionFormat="of" derivedContent="RFC9627">Layer Refresh Request (LRR)</xref> allows a receiver to request a single layer of a spatially or temporally encoded stream to berefreshed,refreshed without necessarily affecting the stream's other layers.</t> <figureanchor="figureLRRIndexFormat"> <artwork><![CDATA[anchor="figureLRRIndexFormat" align="left" suppress-title="false" pn="figure-5"> <name slugifiedName="name-lrr-index-format">LRR Index Format</name> <artwork name="" type="" align="left" alt="" pn="section-5.3-2.1"> +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +---------------+---------+-----+ | RES | TID | RES | SID | +---------------+---------+-----+]]></artwork></artwork> </figure><t><xref target="figureLRRIndexFormat"/><t indent="0" pn="section-5.3-3"><xref target="figureLRRIndexFormat" format="default" sectionFormat="of" derivedContent="Figure 5"/> shows the format of an LRR's layer index fields for VP9 streams. The two "RES" fieldsMUST<bcp14>MUST</bcp14> be set to0zero on transmission andingnoredignored on reception. See <xreftarget="VP9payloadDescriptor"/>target="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Section 4.2"/> for details on the TID and SID fields.</t><t>Identification<t indent="0" pn="section-5.3-4">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.ThereforeTherefore, it's recommended for both the flexible and the non-flexible mode that, when switching up points are being encoded in response toaan LRR, those packetsshouldcontain layer indices and the referencefield(s)field or fields so that the decoder ora<xreftarget='RFC7667'>selectivetarget="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667">selective forwarding middleboxes</xref> can make this derivation.</t><t>Example:</t> <t>LRR<t indent="0" pn="section-5.3-5">Example:</t> <t indent="0" pn="section-5.3-6">LRR {1,0}, {2,1} is sent byan MCUa Multipoint Control Unit (MCU) when it is currently relaying {1,0} to a receiverand whichthat wants to upgrade to {2,1}. Inresponseresponse, 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<t indent="0" pn="section-5.3-7">In the non-flexible mode, periodic upgrade frames can be defined by the layer structure of theSS, thusSS; thus, periodic upgrade frames can be automatically identified by thepicturePicture ID.</t> </section> </section> <section anchor="payloadFormatParameters"title="Payloadnumbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-payload-format-parameters">Payload FormatParameters"> <t>ThisParameters</name> <t indent="0" pn="section-6-1">This payload format has three optionalparameters, "max-fr", "max-fs",parameters: max-fr, max-fs, and"profile-id".</t> <t>Theprofile-id.</t> <t indent="0" pn="section-6-2">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 parametersMUST<bcp14>MUST</bcp14> be provided. These parametersMUST NOT<bcp14>MUST NOT</bcp14> be used for any other purpose. A media senderSHOULD 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 <xreftarget='RFC7667'>selectivetarget="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667">selective forwarding middleboxes</xref>, where a media sender does not have media available that fits within areceiversreceiver's max-fs and max-frvalue;values; in such scenarios, a senderMAY<bcp14>MAY</bcp14> exceed the signaled values.)<list style="hanging"> <t hangText="max-fr:">The</t> <dl newline="false" spacing="normal" indent="3" pn="section-6-3"> <dt pn="section-6-3.1">max-fr:</dt> <dd pn="section-6-3.2">The value of max-fr is an integer indicating the maximum frame rate in units of frames per second that the decoder is capable ofdecoding.</t> <t hangText="max-fs:">Thedecoding.</dd> <dt pn="section-6-3.3">max-fs:</dt> <dd pn="section-6-3.4">The value of max-fs is an integer indicating the maximum frame size in units of macroblocks that the decoder is capable ofdecoding.</t> <t>Thedecoding.</dd> <dt pn="section-6-3.5"/> <dd pn="section-6-3.6">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 (97macroblocks).</t> <t hangText="profile-id:">Themacroblocks).</dd> <dt pn="section-6-3.7">profile-id:</dt> <dd pn="section-6-3.8">The value of profile-id is an integer indicating the default codingprofile, theprofile (the subset of coding tools that may have been used to generate the stream or that the receiver supports). <xreftarget="TableOfProfileIds"/>target="TableOfProfileIds" format="default" sectionFormat="of" derivedContent="Table 2"/> lists all of the profiles defined insectionSection 7.2 of <xreftarget="VP9-BITSTREAM"/>target="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/> and the corresponding integer values to beused.</t> <t>Ifused.</dd> <dt pn="section-6-3.9"/> <dd pn="section-6-3.10">If no profile-id is present, Profile 0MUST<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 pn="section-6-3.11"/> <dd pn="section-6-3.12">Informative note: See <xreftarget="TableOfProfiles"/>target="TableOfProfiles" format="default" sectionFormat="of" derivedContent="Table 3"/> for capabilities of coding profiles defined insectionSection 7.2 of <xreftarget="VP9-BITSTREAM"/>.</t> </list></t> <t>Atarget="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/>.</dd> </dl> <t indent="0" pn="section-6-4">A receiverMUST<bcp14>MUST</bcp14> ignore any parameter unspecified in this specification.</t><texttable<table anchor="TableOfProfileIds"title="Table ofalign="center" pn="table-2"> <name slugifiedName="name-correspondence-between-prof">Correspondence between profile-idinteger values representing the VP9 profile correspondingtothe 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> <texttableVP9 Profile Integer</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Profile</th> <th align="center" colspan="1" rowspan="1">profile-id</th> </tr> </thead> <tbody> <tr> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">0</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">1</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">2</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">3</td> <td align="center" colspan="1" rowspan="1">3</td> </tr> </tbody> </table> <table anchor="TableOfProfiles"title="Table of profile capabilities."> <ttcol align="center">Profile</ttcol> <ttcol align="center">Bit Depth</ttcol> <ttcol align="center">SRGB Colorspace</ttcol> <ttcol 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>YUValign="center" pn="table-3"> <name slugifiedName="name-profile-capabilities">Profile Capabilities</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Profile</th> <th align="center" colspan="1" rowspan="1">Bit Depth</th> <th align="center" colspan="1" rowspan="1">SRGB Colorspace</th> <th align="center" colspan="1" rowspan="1">Chroma Subsampling</th> </tr> </thead> <tbody> <tr> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">8</td> <td align="center" colspan="1" rowspan="1">No</td> <td align="center" colspan="1" rowspan="1">YUV 4:2:0</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1">8</td> <td align="center" colspan="1" rowspan="1">Yes</td> <td align="center" colspan="1" rowspan="1">YUV 4:2:2,4:4:0 or4:4:4</c> <c>2</c><c>104:4:4</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1">10 or12</c><c>No</c><c>YUV 4:2:0</c> <c>3</c><c>1012</td> <td align="center" colspan="1" rowspan="1">No</td> <td align="center" colspan="1" rowspan="1">YUV 4:2:0</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">3</td> <td align="center" colspan="1" rowspan="1">10 or12</c><c>Yes</c><c>YUV12</td> <td align="center" colspan="1" rowspan="1">Yes</td> <td align="center" colspan="1" rowspan="1">YUV 4:2:2,4:4:0 or4:4:4</c> </texttable>4:4:4</td> </tr> </tbody> </table> <aside pn="section-6-7"> <t keepWithPrevious="true" indent="0" pn="section-6-7.1">Note: SRGB (often sRGB) = Standard Red-Green-Blue</t> </aside> <section anchor="SDPParameters"title="SDP Parameters">numbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-sdp-parameters">SDP Parameters</name> <sectiontitle="Mappingnumbered="true" toc="include" removeInRFC="false" pn="section-6.1.1"> <name slugifiedName="name-mapping-of-media-subtype-pa">Mapping of Media Subtype Parameters toSDP"> <t>TheSDP</name> <t indent="0" pn="section-6.1.1-1">The media typevideo/VP9video/vp9 string is mapped to fields in the Session Description Protocol (SDP) <xreftarget="RFC8866"/>target="RFC8866" format="default" sectionFormat="of" derivedContent="RFC8866"/> as follows:<list style="symbols"> <t>The</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.1-2"> <li pn="section-6.1.1-2.1">The media name in the "m=" line of SDPMUST<bcp14>MUST</bcp14> bevideo.</t> <t>Thevideo.</li> <li pn="section-6.1.1-2.2">The encoding name in the "a=rtpmap" line of SDPMUST<bcp14>MUST</bcp14> be VP9 (the mediasubtype).</t> <t>Thesubtype).</li> <li pn="section-6.1.1-2.3">The clock rate in the "a=rtpmap" lineMUST<bcp14>MUST</bcp14> be90000.</t> <t>The90000.</li> <li pn="section-6.1.1-2.4">The parameters"max-fr"max-fr and"max-fs" MUSTmax-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 subtypestring,string in the form of asemicolon separatedsemicolon-separated list of parameter=valuepairs.</t> <t>The OPTIONALpairs.</li> <li pn="section-6.1.1-2.5">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 subtypestring,string in the form of a parameter=value pair. When the parameter is not present, a value of 0MUST<bcp14>MUST</bcp14> be inferred forprofile-id.</t> </list></t>profile-id.</li> </ul> <sectiontitle="Example"> <t>Annumbered="true" toc="exclude" removeInRFC="false" pn="section-6.1.1.1"> <name slugifiedName="name-example">Example</name> <t indent="0" pn="section-6.1.1.1-1">An example of media representation in SDP is as follows:</t><figure> <artwork>m=video<sourcecode type="sdp" markers="false" pn="section-6.1.1.1-2">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> <sectiontitle="Offer/Answer Considerations"> <t>Whennumbered="true" toc="include" removeInRFC="false" pn="section-6.1.2"> <name slugifiedName="name-offer-answer-considerations">Offer/Answer Considerations</name> <t indent="0" pn="section-6.1.2-1">When VP9 is offered over RTP using SDP in an Offer/Answer model <xreftarget="RFC3264"/>target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/> for negotiation for unicast usage, the following limitations and rules apply:<list style="symbols"> <t>The</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.2-2"> <li pn="section-6.1.2-2.1">The parameter identifying a media format configuration for VP9 is profile-id. This media format configuration parameterMUST<bcp14>MUST</bcp14> be used symmetrically; that is, the answererMUST<bcp14>MUST</bcp14> either maintain this configuration parameter or remove the media format (payload type) completely if it is notsupported.</t> <t>Thesupported.</li> <li pn="section-6.1.2-2.2">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'scapabilities, and thuscapabilities; thus, their values are set independently of the values in theoffer.</t> <t>Tooffer.</li> <li pn="section-6.1.2-2.3">To simplify the handling and matching of these configurations, the same RTP payload type number used in the offerSHOULD<bcp14>SHOULD</bcp14> also be used in the answer and in a subsequent offer, as specified in <xreftarget="RFC3264"/>.target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>. An answer or subsequent offerMUST 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 parametersMAY<bcp14>MAY</bcp14> be changed in subsequent offers and answers, with the same payload type number, if an endpoint wishes to change its declared receivercapabilities.</t> </list></t>capabilities.</li> </ul> </section> </section> </section> <section anchor="mediaTypeRegistration"title="Medianumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-media-type-definition">Media TypeDefinition"> <t>ThisDefinition</name> <t indent="0" pn="section-7-1">This registrationis done usinguses the template defined in <xreftarget="RFC6838"/>target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/> and following <xreftarget="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" sectionFormat="of" derivedContent="RFC4855"/>. </t> <dl newline="false" spacing="normal" indent="3" pn="section-7-2"> <dt pn="section-7-2.1">Type name:</dt> <dd pn="section-7-2.2">video</dd> <dt pn="section-7-2.3">Subtype name:</dt> <dd pn="section-7-2.4">VP9</dd> <dt pn="section-7-2.5">Required parameters:</dt> <dd pn="section-7-2.6">N/A</dd> <dt pn="section-7-2.7">Optional parameters:</dt> <dd pn="section-7-2.8"> There are three optionalparameters, "max-fr", "max-fs",parameters: max-fr, max-fs, and"profile-id".profile-id. See <xreftarget='payloadFormatParameters' />target="payloadFormatParameters" format="default" sectionFormat="of" derivedContent="Section 6"/> for their definition.</t> <t hangText="Encoding considerations:"><vspace blankLines="0"/></dd> <dt pn="section-7-2.9">Encoding considerations:</dt> <dd pn="section-7-2.10"> This media type is framed in RTP and contains binary data; seeSection 4.8 of <xref target="RFC6838"/>.</t> <t hangText="Security considerations:">See<xreftarget="securityConsiderations"/>target="RFC6838" sectionFormat="of" section="4.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6838#section-4.8" derivedContent="RFC6838"/>.</dd> <dt pn="section-7-2.11">Security considerations:</dt> <dd pn="section-7-2.12"> <t indent="0" pn="section-7-2.12.1">See <xref target="securityConsiderations" format="default" sectionFormat="of" derivedContent="Section 8"/> of RFCxxxx. <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>9628. </t> </dd> <dt pn="section-7-2.13">Interoperability considerations:</dt> <dd pn="section-7-2.14">None</dd> <dt pn="section-7-2.15">Published specification:</dt> <dd pn="section-7-2.16"> <thangText="Published specification:">VP9indent="0" pn="section-7-2.16.1">VP9 bitstream format <xreftarget="VP9-BITSTREAM"/>target="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/> and RFCXXXX. <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 which9628. </t> </dd> <dt pn="section-7-2.17">Applications that use this mediatype:"><vspace blankLines="0"/>type:</dt> <dd pn="section-7-2.18"> Forexample: Videoexample, video over IP, videoconferencing.</t> <t hangText="Fragmentconferencing.</dd> <dt pn="section-7-2.19">Fragment identifierconsiderations:">N/A.</t> <t hangText="Additional information:">None.</t> <t hangText="Personconsiderations:</dt> <dd pn="section-7-2.20">N/A</dd> <dt pn="section-7-2.21">Additional information:</dt> <dd pn="section-7-2.22">None</dd> <dt pn="section-7-2.23">Person & email address to contact for furtherinformation:"><vspace blankLines="0"/> Jonathan Lennox <jonathan.lennox@8x8.com></t> <t hangText="Intended usage:">COMMON</t>information:</dt> <dd pn="section-7-2.24"> <thangText="Restrictionsindent="0" pn="section-7-2.24.1"><contact fullname="Jonathan Lennox"/> <jonathan.lennox@8x8.com></t> </dd> <dt pn="section-7-2.25">Intended usage:</dt> <dd pn="section-7-2.26">COMMON</dd> <dt pn="section-7-2.27">Restrictions onusage:"><vspace blankLines="0"/>usage:</dt> <dd pn="section-7-2.28"> This media type depends on RTPframing, and henceframing; hence, it is only defined for transfer via RTP <xreftarget="RFC3550"/>.</t>target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>.</dd> <dt pn="section-7-2.29">Author:</dt> <dd pn="section-7-2.30"> <thangText="Author:">Jonathan Lennoxindent="0" pn="section-7-2.30.1"><contact fullname="Jonathan Lennox"/> <jonathan.lennox@8x8.com></t><t hangText="Change controller:"><vspace blankLines="0"/></dd> <dt pn="section-7-2.31">Change controller:</dt> <dd pn="section-7-2.32"> IETF AVTCore Working Group delegated from theIESG.</t> </list></t>IETF.</dd> </dl> </section> <section anchor="securityConsiderations"title="Security Considerations"> <t>RTPnumbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-8-1">RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification <xreftarget="RFC3550"/>,target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>, and in any applicable RTP profile such as <xreftarget='RFC3551'>RTP/AVP</xref>, <xref target='RFC4585'>RTP/AVPF</xref>, <xref target='RFC3711'>RTP/SAVP</xref>,target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551">RTP/AVP</xref>, <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">RTP/AVPF</xref>, <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711">RTP/SAVP</xref>, or <xreftarget='RFC5124'>RTP/SAVPF</xref>.target="RFC5124" format="default" sectionFormat="of" derivedContent="RFC5124">RTP/SAVPF</xref>. However, as<xref target='RFC7202'>"Securing"<xref target="RFC7202" format="title" sectionFormat="of" derivedContent="Securing the RTPProtocolFramework: Why RTP Does Not Mandate a Single Media SecuritySolution"</xref>Solution"/>" <xref target="RFC7202" format="default" sectionFormat="of" derivedContent="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,integrityintegrity, and source authenticity for RTP in general. This responsibilitylays onlies with anyone using RTP in an application. They can find guidance on available security mechanisms in<xref target='RFC7201'>Options"<xref target="RFC7201" format="title" sectionFormat="of" derivedContent="Options for Securing RTPSessions</xref>.Sessions"/>" <xref target="RFC7201" format="default" sectionFormat="of" derivedContent="RFC7201"/>. ApplicationsSHOULD<bcp14>SHOULD</bcp14> use one or more appropriate strong securitymechanisms. The rest of this security consideration section discusses the security impacting properties of the payload format itself.</t> <t>Implementationsmechanisms.</t> <t indent="0" pn="section-8-2">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 otherwisemis-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 aretypically(typically) rarer.</t><t>This<t indent="0" pn="section-8-3">This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packetprocessing, and thusprocessing; 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"> <t>Congestionnumbered="true" toc="include" removeInRFC="false" pn="section-9"> <name slugifiedName="name-congestion-control">Congestion Control</name> <t indent="0" pn="section-9-1">Congestion control for RTPSHALL<bcp14>SHALL</bcp14> be used in accordance withRFC 3550<xreftarget="RFC3550"/>,target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>, and with any applicable RTPprofile;profile, e.g.,RFC 3551<xreftarget="RFC3551"/>.target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551"/>. 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 awareMedia-aware network elementsMAY<bcp14>MAY</bcp14> use the information in the VP9 payload descriptor in <xreftarget="VP9payloadDescriptor"/>target="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Section 4.2"/> 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 registernumbered="true" toc="include" removeInRFC="false" pn="section-10"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-10-1">IANA has registered the media typeregistration"video/vp9" as specified in <xreftarget="mediaTypeRegistration"/>.target="mediaTypeRegistration" format="default" sectionFormat="of" derivedContent="Section 7"/>. The media typeishas alsorequested to bebeen added to theIANA registry for"RTP Payload FormatMIME types" <http://www.iana.org/assignments/rtp-parameters>.</t>Media Types" registry of the "Real-Time Transport Protocol (RTP) Parameters" registry group (<eref target="https://www.iana.org/assignments/rtp-parameters" brackets="none"/>) as follows.</t> <dl spacing="compact" indent="3" newline="false" pn="section-10-2"> <dt pn="section-10-2.1">Media Type:</dt> <dd pn="section-10-2.2">video</dd> <dt pn="section-10-2.3">Subtype:</dt> <dd pn="section-10-2.4">VP9</dd> <dt pn="section-10-2.5">Clock Rate (Hz):</dt> <dd pn="section-10-2.6">90000</dd> <dt pn="section-10-2.7">Reference:</dt> <dd pn="section-10-2.8">RFC 9628</dd> </dl> </section><section title="Acknowledgments"> <t>Alex Eleftheriadis, Yuki Ito, Won Kap Jang, Sergio Garcia Murillo, Roi Sasson, Timothy Terriberry, Emircan Uysaler,</middle> <back> <references pn="section-11"> <name slugifiedName="name-references">References</name> <references pn="section-11.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, andThomas Volkert commented onrequests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3264" quoteTitle="true" derivedAnchor="RFC3264"> <front> <title>An Offer/Answer Model with Session Description Protocol (SDP)</title> <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/> <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <date month="June" year="2002"/> <abstract> <t indent="0">This document defines a mechanism by which two entities can make use of thedevelopmentSession Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3264"/> <seriesInfo name="DOI" value="10.17487/RFC3264"/> </reference> <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550"> <front> <title>RTP: A Transport Protocol for Real-Time Applications</title> <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <author fullname="S. Casner" initials="S." surname="Casner"/> <author fullname="R. Frederick" initials="R." surname="Frederick"/> <author fullname="V. Jacobson" initials="V." surname="Jacobson"/> <date month="July" year="2003"/> <abstract> <t indent="0">This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="64"/> <seriesInfo name="RFC" value="3550"/> <seriesInfo name="DOI" value="10.17487/RFC3550"/> </reference> <reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4585" quoteTitle="true" derivedAnchor="RFC4585"> <front> <title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</title> <author fullname="J. Ott" initials="J." surname="Ott"/> <author fullname="S. Wenger" initials="S." surname="Wenger"/> <author fullname="N. Sato" initials="N." surname="Sato"/> <author fullname="C. Burmeister" initials="C." surname="Burmeister"/> <author fullname="J. Rey" initials="J." surname="Rey"/> <date month="July" year="2006"/> <abstract> <t indent="0">Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders andprovidedthus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4585"/> <seriesInfo name="DOI" value="10.17487/RFC4585"/> </reference> <reference anchor="RFC4855" target="https://www.rfc-editor.org/info/rfc4855" quoteTitle="true" derivedAnchor="RFC4855"> <front> <title>Media Type Registration of RTP Payload Formats</title> <author fullname="S. Casner" initials="S." surname="Casner"/> <date month="February" year="2007"/> <abstract> <t indent="0">This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4855"/> <seriesInfo name="DOI" value="10.17487/RFC4855"/> </reference> <reference anchor="RFC5104" target="https://www.rfc-editor.org/info/rfc5104" quoteTitle="true" derivedAnchor="RFC5104"> <front> <title>Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</title> <author fullname="S. Wenger" initials="S." surname="Wenger"/> <author fullname="U. Chandra" initials="U." surname="Chandra"/> <author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <author fullname="B. Burman" initials="B." surname="Burman"/> <date month="February" year="2008"/> <abstract> <t indent="0">This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpfulcommentsprimarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments andfeedback.</t> </section> </middle> <back> <references title='Normative References'>point-to-point calls.</t> <t indent="0">The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5104"/> <seriesInfo name="DOI" value="10.17487/RFC5104"/> </reference> <referenceanchor='VP9-BITSTREAM' target='https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf'>anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838" quoteTitle="true" derivedAnchor="RFC6838"> <front> <title>Media Type Specifications and Registration Procedures</title> <author fullname="N. Freed" initials="N." surname="Freed"/> <author fullname="J. Klensin" initials="J." surname="Klensin"/> <author fullname="T. Hansen" initials="T." surname="Hansen"/> <date month="January" year="2013"/> <abstract> <t indent="0">This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t> </abstract> </front> <seriesInfo name="BCP" value="13"/> <seriesInfo name="RFC" value="6838"/> <seriesInfo name="DOI" value="10.17487/RFC6838"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8866" quoteTitle="true" derivedAnchor="RFC8866"> <front> <title>SDP: Session Description Protocol</title> <author fullname="A. Begen" initials="A." surname="Begen"/> <author fullname="P. Kyzivat" initials="P." surname="Kyzivat"/> <author fullname="C. Perkins" initials="C." surname="Perkins"/> <author fullname="M. Handley" initials="M." surname="Handley"/> <date month="January" year="2021"/> <abstract> <t indent="0">This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.</t> </abstract> </front> <seriesInfo name="RFC" value="8866"/> <seriesInfo name="DOI" value="10.17487/RFC8866"/> </reference> <reference anchor="RFC9627" target="https://www.rfc-editor.org/info/rfc9627" quoteTitle="true" derivedAnchor="RFC9627"> <front> <title>The Layer Refresh Request (LRR) RTCP Feedback Message</title> <author initials="J." surname="Lennox" fullname="Jonathan Lennox"> <organization showOnFrontPage="true">8x8, Inc. / Jitsi</organization> </author> <author initials="D." surname="Hong" fullname="Danny Hong"> <organization showOnFrontPage="true">Google, Inc.</organization> </author> <author initials="J." surname="Uberti" fullname="Justin Uberti"> <organization showOnFrontPage="true">OpenAI</organization> </author> <author initials="S." surname="Holmer" fullname="Stefan Holmer"> <organization showOnFrontPage="true">Google, Inc.</organization> </author> <author initials="M." surname="Flodman" fullname="Magnus Flodman"> <organization showOnFrontPage="true">Google, Inc.</organization> </author> <date month="March" year="2025"/> </front> <seriesInfo name="RFC" value="9627"/> <seriesInfo name="DOI" value="10.17487/RFC9627"/> </reference> <reference anchor="VP9-BITSTREAM" target="https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf" quoteTitle="true" derivedAnchor="VP9-BITSTREAM"> <front> <title>VP9 Bitstream & Decoding Process Specification</title> <authorinitials='A' surname='Grange' fullname='Adrian Grange'> <organization>Google</organization>initials="A" surname="Grange" fullname="Adrian Grange"> <organization showOnFrontPage="true">Google</organization> </author> <authorinitials='P' surname='de Rivaz' fullname='Peterinitials="P" surname="de Rivaz" fullname="Peter deRivaz'> <organization>ArgonRivaz"> <organization showOnFrontPage="true">Argon Design</organization> </author> <authorinitials='J' surname='Hunt' fullname='Jonathan Hunt'> <organization>Argoninitials="J" surname="Hunt" fullname="Jonathan Hunt"> <organization showOnFrontPage="true">Argon Design</organization> </author> <datemonth='March' day='31' year='2016' />month="March" day="31" year="2016"/> <abstract><t><t indent="0"> This document defines the bitstream format and decoding process for the Google VP9 video codec. </t> </abstract> </front> <seriesInfoname='Version' value='0.6' />name="Version" value="0.6"/> </reference>&rfc2119; &rfc8174; &rfc4585; &rfc3550; &rfc8866; &rfc6838; &rfc4855; &rfc5104; &lrr; &rfc3264;</references> <referencestitle='Informative References'> &rfc3551; &rfc5124; &rfc6386; &rfc7201; &rfc7202; &rfc7667; &rfc3711;pn="section-11.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="RFC3551" target="https://www.rfc-editor.org/info/rfc3551" quoteTitle="true" derivedAnchor="RFC3551"> <front> <title>RTP Profile for Audio and Video Conferences with Minimal Control</title> <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <author fullname="S. Casner" initials="S." surname="Casner"/> <date month="July" year="2003"/> <abstract> <t indent="0">This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="65"/> <seriesInfo name="RFC" value="3551"/> <seriesInfo name="DOI" value="10.17487/RFC3551"/> </reference> <reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3711" quoteTitle="true" derivedAnchor="RFC3711"> <front> <title>The Secure Real-time Transport Protocol (SRTP)</title> <author fullname="M. Baugher" initials="M." surname="Baugher"/> <author fullname="D. McGrew" initials="D." surname="McGrew"/> <author fullname="M. Naslund" initials="M." surname="Naslund"/> <author fullname="E. Carrara" initials="E." surname="Carrara"/> <author fullname="K. Norrman" initials="K." surname="Norrman"/> <date month="March" year="2004"/> <abstract> <t indent="0">This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3711"/> <seriesInfo name="DOI" value="10.17487/RFC3711"/> </reference> <reference anchor="RFC5124" target="https://www.rfc-editor.org/info/rfc5124" quoteTitle="true" derivedAnchor="RFC5124"> <front> <title>Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)</title> <author fullname="J. Ott" initials="J." surname="Ott"/> <author fullname="E. Carrara" initials="E." surname="Carrara"/> <date month="February" year="2008"/> <abstract> <t indent="0">An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5124"/> <seriesInfo name="DOI" value="10.17487/RFC5124"/> </reference> <reference anchor="RFC6386" target="https://www.rfc-editor.org/info/rfc6386" quoteTitle="true" derivedAnchor="RFC6386"> <front> <title>VP8 Data Format and Decoding Guide</title> <author fullname="J. Bankoski" initials="J." surname="Bankoski"/> <author fullname="J. Koleszar" initials="J." surname="Koleszar"/> <author fullname="L. Quillio" initials="L." surname="Quillio"/> <author fullname="J. Salonen" initials="J." surname="Salonen"/> <author fullname="P. Wilkins" initials="P." surname="Wilkins"/> <author fullname="Y. Xu" initials="Y." surname="Xu"/> <date month="November" year="2011"/> <abstract> <t indent="0">This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6386"/> <seriesInfo name="DOI" value="10.17487/RFC6386"/> </reference> <reference anchor="RFC7201" target="https://www.rfc-editor.org/info/rfc7201" quoteTitle="true" derivedAnchor="RFC7201"> <front> <title>Options for Securing RTP Sessions</title> <author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <author fullname="C. Perkins" initials="C." surname="Perkins"/> <date month="April" year="2014"/> <abstract> <t indent="0">The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.</t> </abstract> </front> <seriesInfo name="RFC" value="7201"/> <seriesInfo name="DOI" value="10.17487/RFC7201"/> </reference> <reference anchor="RFC7202" target="https://www.rfc-editor.org/info/rfc7202" quoteTitle="true" derivedAnchor="RFC7202"> <front> <title>Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution</title> <author fullname="C. Perkins" initials="C." surname="Perkins"/> <author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <date month="April" year="2014"/> <abstract> <t indent="0">This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.</t> </abstract> </front> <seriesInfo name="RFC" value="7202"/> <seriesInfo name="DOI" value="10.17487/RFC7202"/> </reference> <reference anchor="RFC7667" target="https://www.rfc-editor.org/info/rfc7667" quoteTitle="true" derivedAnchor="RFC7667"> <front> <title>RTP Topologies</title> <author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <author fullname="S. Wenger" initials="S." surname="Wenger"/> <date month="November" year="2015"/> <abstract> <t indent="0">This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.</t> </abstract> </front> <seriesInfo name="RFC" value="7667"/> <seriesInfo name="DOI" value="10.17487/RFC7667"/> </reference> </references> </references> <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgments">Acknowledgments</name> <t indent="0" pn="section-appendix.a-1"><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> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Justin Uberti" initials="J." surname="Uberti"> <organization showOnFrontPage="true">OpenAI</organization> <address> <postal> <street>1455 3rd St</street> <city>San Francisco</city> <region>CA</region> <code>94158</code> <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" showOnFrontPage="true">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" showOnFrontPage="true">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" showOnFrontPage="true">Google, Inc.</organization> <address> <postal> <street>315 Hudson St.</street> <city>New York</city> <region>NY</region> <code>10013</code> <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" showOnFrontPage="true">8x8, Inc. / Jitsi</organization> <address> <postal> <street/> <city>Jersey City</city> <region>NJ</region> <code>07302</code> <country>United States of America</country> </postal> <email>jonathan.lennox@8x8.com</email> </address> </author> </section> </back> </rfc><!-- LocalWords: PictureID DCT Hadamard WHT SSRC CSRC pyld hdr FI VER RPSI --> <!-- LocalWords: stPartitionSize SDP AVPF SRTP IANA PID PICIDX TID -->