Diff: rfc9628xml2.original.xml

	rfc9628xml2.original.xml	rfc9628.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" docName="draft-ietf-
	<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	payload-vp9-16" number="9628" ipr="trust200902" obsoletes="" updates="" submissi
	ce.RFC.2119.xml">	onType="IETF" category="std" consensus="true" xml:lang="en" symRefs="true" sortR
	<!ENTITY rfc3264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	efs="true" tocInclude="true" prepTime="2025-03-27T17:04:31" indexInclude="true"
	ce.RFC.3264.xml">	scripts="Common,Latin" tocDepth="3">
	<!ENTITY rfc3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	<link href="https://datatracker.ietf.org/doc/draft-ietf-payload-vp9-16" rel="p
	ce.RFC.3550.xml">	rev"/>
	<!ENTITY rfc3551 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	<link href="https://dx.doi.org/10.17487/rfc9628" rel="alternate"/>
	ce.RFC.3551.xml">	<link href="urn:issn:2070-1721" rel="alternate"/>
	<!ENTITY rfc3711 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.3711.xml">
	<!ENTITY rfc3984 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.3984.xml">
	<!ENTITY rfc4855 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4855.xml">
	<!ENTITY rfc4585 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4585.xml">
	<!ENTITY rfc5104 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5104.xml">
	<!ENTITY rfc5124 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5124.xml">
	<!ENTITY rfc6386 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.6386.xml">
	<!ENTITY rfc6838 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.6838.xml">
	<!ENTITY rfc7201 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7201.xml">
	<!ENTITY rfc7202 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7202.xml">
	<!ENTITY rfc7667 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7667.xml">
	<!ENTITY rfc8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8174.xml">
	<!ENTITY rfc8866 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8866.xml">
	<!ENTITY lrr SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.
	I-D.ietf-avtext-lrr.xml">

	]>
	<rfc category="std" 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 -->

	<front>	<front>

	<title abbrev="RTP Payload Format for VP9">RTP Payload Format for VP9	<title abbrev="RTP Payload Format for VP9">RTP Payload Format for VP9 Video<
	Video</title>	/title>
		<seriesInfo name="RFC" value="9628" stream="IETF"/>
	<author fullname="Justin Uberti" initials="J." surname="Uberti">	<author fullname="Justin Uberti" initials="J." surname="Uberti">

	<organization abbrev="Google">Google, Inc.</organization>	<organization showOnFrontPage="true">OpenAI</organization>

	<address>	<address>
	<postal>	<postal>

	<street>747 6th Street South</street>	<street>1455 3rd St</street>
		<city>San Francisco</city>
	<city>Kirkland</city>	<region>CA</region>
		<code>94158</code>
	<region>WA</region>	<country>United States of America</country>

	<code>98033</code>

	<country>USA</country>
	</postal>	</postal>
	<email>justin@uberti.name</email>	<email>justin@uberti.name</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Stefan Holmer" initials="S." surname="Holmer">	<author fullname="Stefan Holmer" initials="S." surname="Holmer">

	<organization abbrev="Google">Google, Inc.</organization>	<organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organiz
	<address>	ation>
		<address>
	<postal>	<postal>
	<street>Kungsbron 2</street>	<street>Kungsbron 2</street>


	<code>111 22</code>	<code>111 22</code>


	<city>Stockholm</city>	<city>Stockholm</city>


	<country>Sweden</country>	<country>Sweden</country>
	</postal>	</postal>

	<email>holmer@google.com</email>	<email>holmer@google.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Magnus Flodman" initials="M." surname="Flodman">	<author fullname="Magnus Flodman" initials="M." surname="Flodman">

	<organization abbrev="Google">Google, Inc.</organization>	<organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organiz ation>
	<address>	<address>
	<postal>	<postal>
	<street>Kungsbron 2</street>	<street>Kungsbron 2</street>


	<code>111 22</code>	<code>111 22</code>


	<city>Stockholm</city>	<city>Stockholm</city>


	<country>Sweden</country>	<country>Sweden</country>
	</postal>	</postal>

	<email>mflodman@google.com</email>	<email>mflodman@google.com</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Danny Hong" initials="D." surname="Hong">
	<author fullname="Danny Hong" initials="D." surname="Hong">	<organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organiz
	<organization abbrev="Google">Google, Inc.</organization>	ation>

	<address>	<address>
	<postal>	<postal>

	<street>1585 Charleston Road</street>	<street>315 Hudson St.</street>
		<city>New York</city>
	<city>Mountain View</city>	<region>NY</region>
		<code>10013</code>
	<region>CA</region>	<country>United States of America</country>

	<code>94043</code>

	<country>US</country>
	</postal>	</postal>


	<email>dannyhong@google.com</email>	<email>dannyhong@google.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Jonathan Lennox" initials="J." surname="Lennox">	<author fullname="Jonathan Lennox" initials="J." surname="Lennox">

	<organization abbrev="8x8 / Jitsi">8x8, Inc. / Jitsi</organization>	<organization abbrev="8x8 / Jitsi" showOnFrontPage="true">8x8, Inc. / Jits
		i</organization>
	<address>	<address>
	<postal>	<postal>
	<street/>	<street/>


	<city>Jersey City</city>	<city>Jersey City</city>


	<region>NJ</region>	<region>NJ</region>


	<code>07302</code>	<code>07302</code>

		<country>United States of America</country>
	<country>US</country>
	</postal>	</postal>


	<email>jonathan.lennox@8x8.com</email>	<email>jonathan.lennox@8x8.com</email>
	</address>	</address>
	</author>	</author>

		<date month="03" year="2025"/>
	<date/>

	<area>RAI</area>	<area>RAI</area>


	<workgroup>AVTCore Working Group</workgroup>	<workgroup>AVTCore Working Group</workgroup>


	<keyword>RFC</keyword>

	<keyword>Request for Comments</keyword>

	<keyword>RTP</keyword>	<keyword>RTP</keyword>


	<keyword>VP9</keyword>	<keyword>VP9</keyword>


	<keyword>WebM</keyword>	<keyword>WebM</keyword>

		<abstract pn="section-abstract">
	<abstract>	<t indent="0" pn="section-abstract-1">This specification describes an RTP
	<t>This specification describes an RTP payload format for the VP9 video co	payload format for the VP9 video codec.
	dec.	The payload format has wide applicability as it supports applications
	The payload format has wide applicability, as it supports applications	from low bitrate peer-to-peer usage to high bitrate video
	from low bit-rate peer-to-peer usage, to high bit-rate video
	conferences. It includes provisions for temporal and spatial scalability. </t>	conferences. It includes provisions for temporal and spatial scalability. </t>
	</abstract>	</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="non
		e"/>.
		</t>
		</section>
		<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
		ude" 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" p
		n="section-toc.1">
		<name slugifiedName="name-table-of-contents">Table of Contents</name>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
		c.1-1">
		<li pn="section-toc.1-1.1">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
		ivedContent="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 der
		ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-conventions">C
		onventions</xref></t>
		</li>
		<li pn="section-toc.1-1.3">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
		ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-media-format-d
		escription">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" form
		at="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-payload-format">Payload Format</xr
		ef></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-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 derived
		Content="" 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 derived
		Content="" format="title" sectionFormat="of" target="name-vp9-payload-descriptor
		">VP9 Payload Descriptor</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-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 derived
		Content="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>. <
		xref derivedContent="" format="title" sectionFormat="of" target="name-scalabilit
		y-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 derived
		Content="" format="title" sectionFormat="of" target="name-frame-fragmentation">F
		rame 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 derived
		Content="" format="title" sectionFormat="of" target="name-scalable-encoding-cons
		idera">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 derived
		Content="" format="title" sectionFormat="of" target="name-example-of-a-vp9-rtp-s
		tream">Example of a VP9 RTP Stream</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-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 derived
		Content="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" form
		at="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-feedback-messages-and-heade">Feedb
		ack Messages and Header Extensions</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-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 derived
		Content="" format="title" sectionFormat="of" target="name-reference-picture-sele
		ction">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 derived
		Content="" 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 derived
		Content="" 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" form
		at="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-payload-format-parameters">Payload
		Format Parameters</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-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 derived
		Content="" format="title" sectionFormat="of" target="name-sdp-parameters">SDP Pa
		rameters</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-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 derived
		Content="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 derived
		Content="6.1.2" format="counter" sectionFormat="of" target="section-6.1.2"/>. <
		xref derivedContent="" format="title" sectionFormat="of" target="name-offer-answ
		er-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" form
		at="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" f
		ormat="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" form
		at="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" f
		ormat="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" form
		at="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-congestion-control">Congestion Con
		trol</xref></t>
		</li>
		<li pn="section-toc.1-1.10">
		<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
		rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
		erations</xref></t>
		</li>
		<li pn="section-toc.1-1.11">
		<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
		rmat="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="sectio
		n-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 deri
		vedContent="" format="title" sectionFormat="of" target="name-normative-reference
		s">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 deri
		vedContent="" format="title" sectionFormat="of" target="name-informative-referen
		ces">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="" form
		at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
		s</xref></t>
		</li>
		<li pn="section-toc.1-1.13">
		<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
		resses</xref></t>
		</li>
		</ul>
		</section>
		</toc>
	</front>	</front>


	<middle>	<middle>

	<section anchor="intro" title="Introduction">	<section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
	<t>This specification describes an <xref target="RFC3550">RTP</xref> paylo	="section-1">
	ad specification applicable to the	<name slugifiedName="name-introduction">Introduction</name>
	transmission of video streams encoded using the VP9 video codec <xref	<t indent="0" pn="section-1-1">This document describes an <xref target="RF
	target="VP9-BITSTREAM"/>. The format described in this document can be use	C3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP</xref> p
	d	ayload specification applicable to the
	both in peer-to-peer and video conferencing applications.</t>	transmission of video streams encoded using the VP9 video codec <xref targ
		et="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITST
	<t>The VP9 video codec was developed by Google, and is the	REAM"/>. The format described in this
	successor to its earlier <xref target="RFC6386">VP8</xref>	document can be used both in peer-to-peer and video conferencing
	codec. Above the compression improvements and other general	applications.</t>
	enhancements above VP8, VP9 is also designed in a way that	<t indent="0" pn="section-1-2">The VP9 video codec was developed by Google
	allows spatially-scalable video encoding.</t>	and is the successor to
		its earlier <xref target="RFC6386" format="default" sectionFormat="of" der
		ivedContent="RFC6386">VP8</xref> codec.
		Above the compression improvements and other general enhancements to
		VP8, VP9 is also designed in a way that allows spatially scalable video
		encoding.</t>
	</section>	</section>

		<section anchor="conventions" numbered="true" toc="include" removeInRFC="fal
	<section anchor="conventions"	se" pn="section-2">
	title="Conventions, Definitions and Acronyms">	<name slugifiedName="name-conventions">Conventions</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",	<t indent="0" pn="section-2-1">
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	interpreted as described in BCP 14 <xref target="RFC2119"/>	", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	<xref target="RFC8174"/> when, and only when,	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	they appear in all capitals, as shown here.</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
		to be interpreted as described in BCP 14 <xref target="RFC2119" format="defa
		ult" sectionFormat="of" derivedContent="RFC2119"/>
		<xref target="RFC8174" format="default" sectionFormat="of" derivedConten
		t="RFC8174"/> when, and only when, they appear in all capitals,
		as shown here.
		</t>
	</section>	</section>

		<section anchor="mediaFormatDescription" numbered="true" toc="include" remov
	<section anchor="mediaFormatDescription" title="Media Format Description">	eInRFC="false" pn="section-3">
	<t>The VP9 codec can maintain up to eight reference frames, of	<name slugifiedName="name-media-format-description">Media Format Descripti
		on</name>
		<t indent="0" pn="section-3-1">The VP9 codec can maintain up to eight refe
		rence frames, of
	which up to three can be referenced by any new frame.</t>	which up to three can be referenced by any new frame.</t>

		<t indent="0" pn="section-3-2">VP9 also allows a frame to use another fram
	<t>VP9 also allows a frame to use another frame of a different	e of a different
	resolution as a reference frame. (Specifically, a frame may use	resolution as a reference frame. (Specifically, a frame may use
	any references whose width and height are between 1/16th that of	any references whose width and height are between 1/16th that of
	the current frame and twice that of the current frame,	the current frame and twice that of the current frame,
	inclusive.) This allows internal resolution changes without	inclusive.) This allows internal resolution changes without

	requiring the use of key frames.</t>	requiring the use of keyframes.</t>
		<t indent="0" pn="section-3-3">These features together enable an encoder t
	<t>These features together enable an encoder to	o
	implement various forms of coarse-grained scalability,	implement various forms of coarse-grained scalability,

	including temporal, spatial and quality scalability modes, as	including temporal, spatial, and quality scalability modes, as
	well as combinations of these, without the need for explicit	well as combinations of these, without the need for explicit
	scalable coding tools.</t>	scalable coding tools.</t>

		<t indent="0" pn="section-3-4">Temporal layers define different frame rate
	<t>Temporal layers define different frame rates of video;	s of video;
	spatial and quality layers define different and possibly dependent	spatial and quality layers define different and possibly dependent
	representations of a single input frame. Spatial layers allow	representations of a single input frame. Spatial layers allow
	a frame to be encoded at different resolutions, whereas	a frame to be encoded at different resolutions, whereas
	quality layers allow a frame to be encoded at the same	quality layers allow a frame to be encoded at the same

	resolution but at different qualities (and thus with different	resolution but at different qualities (and, thus, with different
	amounts of coding error). VP9 supports quality layers as	amounts of coding error). VP9 supports quality layers as
	spatial layers without any resolution changes; hereinafter,	spatial layers without any resolution changes; hereinafter,
	the term "spatial layer" is used to represent both spatial and	the term "spatial layer" is used to represent both spatial and
	quality layers.</t>	quality layers.</t>

		<t indent="0" pn="section-3-5">This payload format specification defines h
	<t>This payload format specification defines how such	ow such
	temporal and spatial scalability layers can be described and	temporal and spatial scalability layers can be described and
	communicated.</t>	communicated.</t>

		<t indent="0" pn="section-3-6">Temporal and spatial scalability layers are
	<t>Temporal and spatial scalability layers are associated with	associated with
	non-negative integer IDs. The lowest layer of either type has an	non-negative integer IDs. The lowest layer of either type has an

	ID of 0, and is sometimes referred to as the "base" temporal or	ID of zero and is sometimes referred to as the "base" temporal or
	spatial layer.</t>	spatial layer.</t>

		<t indent="0" pn="section-3-7">Layers are designed, and <bcp14>MUST</bcp14
	<t>Layers are designed, and MUST be encoded, such that if	> be encoded, such that if
	any layer, and all higher layers, are removed from the bitstream	any layer, and all higher layers, are removed from the bitstream
	along either the spatial or temporal dimension, the remaining bitstream is	along either the spatial or temporal dimension, the remaining bitstream is
	still correctly decodable.</t>	still correctly decodable.</t>

		<t indent="0" pn="section-3-8">For terminology, this document uses the ter
	<t>For terminology, this document uses the term "frame" to refer	m "frame" to refer to a
	to a single encoded VP9 frame for a particular resolution/quality, and	single encoded VP9 frame for a particular resolution and/or quality, and
	"picture" to refer to all the representations (frames) at a single	"picture" to refer to all the representations (frames) at a single

	instant in time. A picture thus consists of one or more frames,	instant in time. Thus, a picture consists of one or more frames,
	encoding different spatial layers.</t>	encoding different spatial layers.</t>

		<t indent="0" pn="section-3-9">Within a picture, a frame with
	<t>Within a picture, a frame with spatial layer ID equal to SID,	spatial-layer ID equal to S, where S > 0, can depend on a frame
	where SID > 0, can depend on a frame of the same picture with a lower spat	of the same picture with a lower spatial-layer ID. This "inter-layer"
	ial layer ID. This	dependency can result in additional coding gain compared to the case
	"inter-layer" dependency can result in additional coding gain	where only "inter-picture" dependency is used, where a frame
	compared to the case where only	depends on a previously coded frame in time. For simplicity, this
	traditional "inter-picture" dependency is used, where a frame depends on p	payload format assumes that, within a picture and if inter-layer
	reviously	dependency is used, a spatial-layer S frame can depend only on the
	coded frame in time. For simplicity, this payload format assumes that,	immediately previous spatial-layer S-1 frame, when S > 0.
	within a picture and if inter-layer dependency is used, a spatial layer SI	Additionally, if inter-picture dependency is used, a spatial-layer S
	D frame	frame is assumed to only depend on a previously coded spatial-layer S
	can depend only on the immediately previous spatial layer SID-1 frame, whe	frame.</t>
	n S > 0. Additionally, if	<t indent="0" pn="section-3-10">Given the above simplifications for inter-
	inter-picture dependency is used, a spatial layer SID frame is assumed to	layer and inter-picture
	only	dependencies, a flag (the D bit described below) is used to indicate
	depend on a previously coded spatial layer SID frame.</t>	whether a spatial-layer SID frame depends on the spatial-layer SID-1
		frame. Given the D bit, a receiver only needs to additionally know the
	<t>Given above simplifications for inter-layer and inter-picture	inter-picture dependency structure for a given spatial-layer frame in
	dependencies, a flag (the D bit described below) is used to indicate wheth	order to determine its decodability. Two modes of describing the
	er a	inter-picture dependency structure are possible: "flexible mode" and
	spatial layer SID frame depends on the spatial layer SID-1 frame. Given t	"non-flexible mode". An encoder can only switch between the two on the
	he D bit, a receiver	first packet of a keyframe with a temporal-layer ID equal to zero.</t>
	only needs to additionally know the inter-picture dependency structure for	<t indent="0" pn="section-3-11">In flexible mode, each packet can contain
	a given	up to three reference indices,
	spatial layer frame in order to determine its decodability. Two modes	which identify all frames referenced by the frame transmitted in the
	of describing the inter-picture dependency structure are possible:	current packet for inter-picture prediction. This (along with the D
	"flexible mode" and "non-flexible mode". An encoder can only switch	bit) enables a receiver to identify if a frame is decodable or not and
	between the two on the first packet of a key frame with temporal	helps it understand the temporal-layer structure. Since this is
	layer ID equal to 0.</t>	signaled in each packet, it makes it possible to have very flexible
		temporal-layer hierarchies and scalability structures, which are
	<t>In flexible mode, each packet can contain up to 3 reference	changing dynamically.</t>
	indices, which identify all frames referenced by the frame	<t indent="0" pn="section-3-12">In non-flexible mode, frames are encoded u
	transmitted in the current packet for inter-picture prediction.	sing a fixed, recurring pattern of dependencies;
	This (along with the D bit) enables a receiver to identify if a frame	the set of pictures that recur in this pattern is known as a "Picture Grou
	is decodable or not and helps it understand the temporal layer	p" (or "PG").
	structure.
	Since this is signaled in
	each packet it makes it possible to have very flexible temporal layer
	hierarchies, and scalability structures which are changing dynamically.</t
	>

	<t>In non-flexible mode, frames are encoded using a fixed, recurring patte
	rn of dependencies;
	the set of pictures that recur in this pattern is known as a Picture Group
	(PG).
	In this mode, the inter-picture dependencies (the reference	In this mode, the inter-picture dependencies (the reference

	indices) of the Picture Group MUST be pre-specified as part of the	indices) of the PG <bcp14>MUST</bcp14> be pre-specified as part of the
	scalability structure (SS) data.	Scalability Structure (SS) data.
	Each	Each
	packet has an index to refer to one of the described pictures	packet has an index to refer to one of the described pictures

	in the PG, from which the pictures referenced by the picture transmitted i n the current packet	in the PG from which the pictures referenced by the picture transmitted in the current packet
	for inter-picture prediction can be identified.</t>	for inter-picture prediction can be identified.</t>

		<aside pn="section-3-13">
	<t>(Note: A "Picture Group", as used in this document,	<t indent="0" pn="section-3-13.1">Note: A "Picture Group" or "PG", as us
		ed in this document,
	is not the same thing as the term "Group of Pictures" as	is not the same thing as the term "Group of Pictures" as

	it is traditionally used in video coding, i.e. to mean an	it is commonly used in video coding, i.e., to mean an
	independently-decoadable run of pictures beginning with a	independently decodable run of pictures beginning with a
	keyframe.)</t>	keyframe.</t>
		</aside>
	<t>The SS data can also be used to specify the resolution of each	<t indent="0" pn="section-3-14">The SS data can also be used to specify th
		e resolution of each
	spatial layer present in the VP9 stream for both flexible and non-flexible modes.</t>	spatial layer present in the VP9 stream for both flexible and non-flexible modes.</t>


	</section>	</section>

		<section anchor="payloadFormat" numbered="true" toc="include" removeInRFC="f
	<section anchor="payloadFormat" title="Payload Format">	alse" pn="section-4">
	<t>This section describes how the encoded VP9 bitstream is encapsulated	<name slugifiedName="name-payload-format">Payload Format</name>
	in RTP. To handle network losses usage of RTP/AVPF <xref	<t indent="0" pn="section-4-1">This section describes how the encoded VP9
	target="RFC4585"/> is RECOMMENDED. All integer fields in the	bitstream is encapsulated
	specifications are encoded as unsigned integers in network octet	in RTP. To handle network losses, usage of RTP/AVPF <xref target="RFC4585"
		format="default" sectionFormat="of" derivedContent="RFC4585"/> is <bcp14>RECOMM
		ENDED</bcp14>. All integer fields in this
		specification are encoded as unsigned integers in network octet
	order.</t>	order.</t>

		<section anchor="RTPHeaderUsage" numbered="true" toc="include" removeInRFC
	<section anchor="RTPHeaderUsage" title="RTP Header Usage">	="false" pn="section-4.1">
	<figure anchor="figureRTPHeader">	<name slugifiedName="name-rtp-header-usage">RTP Header Usage</name>
	<preamble>The general RTP payload format for VP9 is depicted	<t keepWithNext="true" indent="0" pn="section-4.1-1">The general RTP pay
	below.</preamble>	load format for VP9 is depicted
		below.</t>
	<artwork><![CDATA[	<figure anchor="figureRTPHeader" align="left" suppress-title="false" pn=
		"figure-1">
		<name slugifiedName="name-general-rtp-payload-format-">General RTP Pay
		load Format for VP9</name>
		<artwork type="" align="left" alt="" pn="section-4.1-2.1">
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	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 \|	\|V=2\|P\|X\| CC \|M\| PT \| sequence number \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| timestamp \|	\| timestamp \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| synchronization source (SSRC) identifier \|	\| synchronization source (SSRC) identifier \|
	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
	\| contributing source (CSRC) identifiers \|	\| contributing source (CSRC) identifiers \|

	skipping to change at line 322 ¶	skipping to change at line 380 ¶
	\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| : \|	\| : \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	\| \|	\| \|
	+ \|	+ \|
	: VP9 payload :	: VP9 payload :
	\| \|	\| \|
	\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| : OPTIONAL RTP padding \|	\| : OPTIONAL RTP padding \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	]]></artwork>	</artwork>

	<postamble>The VP9 payload descriptor will be
	described in <xref target="VP9payloadDescriptor"/>; the VP9 payload is
	described
	in <xref target="VP9-BITSTREAM"/>.
	OPTIONAL RTP padding MUST NOT be included unless the P bi
	t is set.</postamble>
	</figure>	</figure>

		<t keepWithPrevious="true" indent="0" pn="section-4.1-3">See <xref targe
	<t><list style="hanging">	t="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Sec
	<t hangText="Marker bit (M):">MUST be set to 1 for the final packet	tion 4.2"/> for more information on the VP9 payload descriptor;
	of the highest spatial layer frame (the final packet of the picture)	the VP9 payload is described in <xref target="VP9-BITSTREAM" format="def
	,	ault" sectionFormat="of" derivedContent="VP9-BITSTREAM"/>. <bcp14>OPTIONAL</bcp
	and 0 otherwise. Unless spatial scalability is in use for this pict	14> RTP padding <bcp14>MUST NOT</bcp14> be included unless the P bit is set.</t>
	ure,	<dl newline="false" spacing="normal" indent="3" pn="section-4.1-4">
	this will have the same value as the E bit described below. Note th	<dt pn="section-4.1-4.1">Marker bit (M):</dt>
	is bit	<dd pn="section-4.1-4.2">This bit <bcp14>MUST</bcp14> be set to one fo
	MUST be set to 1 for the target spatial layer frame	r the final packet
	if a stream is being rewritten to remove higher spatial layers.</t>	of the highest spatial-layer frame (the final packet of the picture)
		; otherwise, it is zero. Unless spatial scalability is in use for this picture,
	<t hangText="Payload Type (PT):">In line with the policy	this bit will have the same value as the E bit described in <xref ta
	in Section 3 of <xref target='RFC3551'/>, applications	rget="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="
	using the VP9 RTP payload	Section 4.2"/>. Note this bit
	profile MUST assign a dynamic payload type number to be	<bcp14>MUST</bcp14> be set to one for the target spatial-layer frame
	used in each RTP session and provide a mechanism to	if a stream is being rewritten to remove higher spatial layers.</dd>
	indicate the mapping. See <xref target="SDPParameters"	<dt pn="section-4.1-4.3">Payload Type (PT):</dt>
	/> for the mechanism	<dd pn="section-4.1-4.4">In line with the policy in <xref target="RFC3
	to be used with the <xref target='RFC8866'>Session	551" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-ed
	Description Protocol (SDP)</xref>.</t>	itor.org/rfc/rfc3551#section-3" derivedContent="RFC3551"/>, applications using
		the VP9 RTP payload profile <bcp14>MUST</bcp14> assign a dynamic
	<t hangText="Timestamp:">The <xref target="RFC3550">RTP timestamp</x	payload type number to be used in each RTP session and provide a
	ref> indicates the time when	mechanism to indicate the mapping. See <xref target="SDPParameters" f
		ormat="default" sectionFormat="of" derivedContent="Section 6.1"/> for the mechan
		ism to be used with the <xref target="RFC8866" format="default" sectionFormat="o
		f" derivedContent="RFC8866">Session Description Protocol
		(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" s
		ectionFormat="of" derivedContent="RFC3550">RTP timestamp</xref> indicates the ti
		me when
	the input frame was sampled, at a clock rate of 90 kHz. If the	the input frame was sampled, at a clock rate of 90 kHz. If the

	input picture is encoded with multiple layer frames, all of the	input picture is encoded with multiple frames, all of the
	frames of the picture MUST have the same timestamp.</t>	frames of the picture <bcp14>MUST</bcp14> have the same timestamp.</
		dd>
	<t>If a frame has the VP9 show_frame field set to 0 (i.e.	<dt pn="section-4.1-4.7"/>
	, it is meant only to	<dd pn="section-4.1-4.8">If a frame has the VP9 show_frame field set t
	populate a reference buffer, without being output) its	o zero (i.e., it is
	timestamp MAY alternatively be set	meant only to populate a reference buffer without being output), its
	to be the same as the subsequent frame with show_frame	timestamp <bcp14>MAY</bcp14> alternatively be set to be the same as
	equal to 1. (This will	the subsequent frame with show_frame equal to one. (This will be
	be convenient for playing out pre-encoded content packa	convenient for playing out pre-encoded content packaged with VP9
	ged with VP9 "superframes", which	"superframes", which typically bundle show_frame==0 frames with a
	typically bundle show_frame==0 frames with a subsequent	subsequent show_frame==1 frame.) Every picture containing a frame wit
	show_frame==1 frame.) Every	h show_frame==1,
	frame with show_frame==1, however, MUST have a unique t	however, <bcp14>MUST</bcp14> have a unique timestamp modulo the 2<sup>
	imestamp modulo the 2^32 wrap of	32</sup>
	the field.</t>	wrap of the field.</dd>
		</dl>
	</list></t>	<t indent="0" pn="section-4.1-5">The remaining RTP Fixed Header Fields (
	<t>The remaining RTP Fixed Header Fields (V, P, X, CC,	V, P, X, CC, sequence
	sequence number, SSRC and CSRC identifiers) are used as	number, SSRC, and CSRC identifiers) are used as specified in <xref targe
	specified in Section 5.1 of <xref	t="RFC3550" sectionFormat="of" section="5.1" format="default" derivedLink="https
	target="RFC3550"/>.</t>	://rfc-editor.org/rfc/rfc3550#section-5.1" derivedContent="RFC3550"/>.</t>
	</section>	</section>

		<section anchor="VP9payloadDescriptor" numbered="true" toc="include" remov
	<section anchor="VP9payloadDescriptor" title="VP9 Payload Descriptor">	eInRFC="false" pn="section-4.2">
	<figure anchor="figureVP9payloadDescriptor">	<name slugifiedName="name-vp9-payload-descriptor">VP9 Payload Descriptor
	<preamble>In flexible mode (with the F bit below set to 1), the first	</name>
	octets	<t keepWithNext="true" indent="0" pn="section-4.2-1">In flexible mode (w
		ith the F bit below set to one), the first octets
	after the RTP header are the VP9 payload descriptor, with the followin g	after the RTP header are the VP9 payload descriptor, with the followin g

	structure.</preamble>	structure.</t>
		<figure anchor="figureVP9payloadDescriptor" align="left" suppress-title=
	<artwork><![CDATA[	"false" pn="figure-2">
		<name slugifiedName="name-flexible-mode-format-for-vp">Flexible Mode F
		ormat 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	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|I\|P\|L\|F\|B\|E\|V\|Z\| (REQUIRED)	\|I\|P\|L\|F\|B\|E\|V\|Z\| (REQUIRED)
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	I: \|M\| PICTURE ID \| (REQUIRED)	I: \|M\| PICTURE ID \| (REQUIRED)
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	M: \| EXTENDED PID \| (RECOMMENDED)	M: \| EXTENDED PID \| (RECOMMENDED)
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	L: \| TID \|U\| SID \|D\| (Conditionally RECOMMENDED)	L: \| TID \|U\| SID \|D\| (Conditionally RECOMMENDED)
	+-+-+-+-+-+-+-+-+ -\	+-+-+-+-+-+-+-+-+ -\
	P,F: \| P_DIFF \|N\| (Conditionally REQUIRED) - up to 3 times	P,F: \| P_DIFF \|N\| (Conditionally REQUIRED) - up to 3 times
	+-+-+-+-+-+-+-+-+ -/	+-+-+-+-+-+-+-+-+ -/
	V: \| SS \|	V: \| SS \|
	\| .. \|	\| .. \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+

		</artwork>
	]]></artwork>
	</figure>	</figure>

		<t keepWithNext="true" indent="0" pn="section-4.2-3">In non-flexible mod
	<figure anchor="figureVP9payloadDescriptorNonFlexible">	e (with the F bit below set to zero), the first octets
	<preamble>In non-flexible mode (with the F bit below set to 0), the fi
	rst octets
	after the RTP header are the VP9 payload descriptor, with the followin g	after the RTP header are the VP9 payload descriptor, with the followin g

	structure.</preamble>	structure.</t>
		<figure anchor="figureVP9payloadDescriptorNonFlexible" align="left" supp
	<artwork><![CDATA[	ress-title="false" pn="figure-3">
		<name slugifiedName="name-non-flexible-mode-format-fo">Non-Flexible Mo
		de 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	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|I\|P\|L\|F\|B\|E\|V\|Z\| (REQUIRED)	\|I\|P\|L\|F\|B\|E\|V\|Z\| (REQUIRED)
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	I: \|M\| PICTURE ID \| (RECOMMENDED)	I: \|M\| PICTURE ID \| (RECOMMENDED)
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	M: \| EXTENDED PID \| (RECOMMENDED)	M: \| EXTENDED PID \| (RECOMMENDED)
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	L: \| TID \|U\| SID \|D\| (Conditionally RECOMMENDED)	L: \| TID \|U\| SID \|D\| (Conditionally RECOMMENDED)
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\| TL0PICIDX \| (Conditionally REQUIRED)	\| TL0PICIDX \| (Conditionally REQUIRED)
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	V: \| SS \|	V: \| SS \|
	\| .. \|	\| .. \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+

		</artwork>
	]]></artwork>
	</figure>	</figure>

		<t indent="0" pn="section-4.2-5">Except as noted, the following field de
	<t><list style="hanging">	scriptions apply to the payload descriptor formats in both Figures <xref target=
	<t hangText="I:">Picture ID (PID) present. When set to one, the	"figureVP9payloadDescriptor" format="counter" sectionFormat="of" derivedContent=
	OPTIONAL PID MUST be present after the mandatory first octet and	"2"/> and <xref target="figureVP9payloadDescriptorNonFlexible" format="counter"
	specified as below. Otherwise, PID MUST NOT be present. If the V bit	sectionFormat="of" derivedContent="3"/>.</t>
	was set in the	<dl newline="false" spacing="normal" indent="3" pn="section-4.2-6">
	stream's most recent start of a keyframe (i.e. the SS field was presen	<dt pn="section-4.2-6.1">I:</dt>
	t) and the F bit	<dd pn="section-4.2-6.2">Picture ID (PID) present. When set to one, th
	is set to 0 (i.e. non-flexible scalability mode is in use),	e
	then this bit MUST be set on every packet.</t>	<bcp14>OPTIONAL</bcp14> PID <bcp14>MUST</bcp14> be present after the
		mandatory first octet and specified as below. Otherwise, PID
	<t hangText="P:">Inter-picture predicted frame. When set to zero, the	<bcp14>MUST NOT</bcp14> be present. If the V bit was set in the
	frame does not utilize inter-picture prediction. In this case,	stream's most recent start of a keyframe (i.e., the SS field was
	up-switching to a current spatial layer's frame is possible from direc	present) and the F bit is set to zero (i.e., non-flexible scalability
	tly	mode is in use), then this bit <bcp14>MUST</bcp14> be set on every
	lower spatial layer frame. P SHOULD also be set to zero when	packet.</dd>
	encoding a layer synchronization frame in response to an <xref target=	<dt pn="section-4.2-6.3">P:</dt>
	'I-D.ietf-avtext-lrr'>LRR</xref> message (see <xref target='LRR'/>).	<dd pn="section-4.2-6.4">Inter-picture predicted frame. When set to z
	When P is set to zero, the TID field (described below) MUST also	ero, the frame does
	be set to 0 (if present). Note that the P bit does not	not utilize inter-picture prediction. In this case, up-switching to
	forbid intra-picture, inter-layer prediction from earlier	a current spatial layer's frame is possible from a directly lower
	frames of the same picture, if any.</t>	spatial-layer frame. P <bcp14>SHOULD</bcp14> also be set to zero when
		encoding a layer synchronization frame in response to a <xref target="
	<t hangText="L:">Layer indices present. When set to one,	RFC9627" format="default" sectionFormat="of" derivedContent="RFC9627">Layer Refr
	the one or two octets following the mandatory first octet and the PID	esh Request (LRR)</xref>
	(if present) is as described by "Layer indices" below. If the F bit (	message (see <xref target="LRR" format="default" sectionFormat="of" de
	described below)	rivedContent="Section 5.3"/>). When P is set
	is set to 1 (indicating flexible mode), then only one octet is present	to zero, the Temporal-layer ID (TID) field (described below) <bcp14>MU
	for the	ST</bcp14> also be
	layer indices. Otherwise if the F bit is set to 0 (indicating non-flex	set to zero (if present). Note that the P bit does not forbid
	ible mode),	intra-picture, inter-layer prediction from earlier frames of the
	then two octets are present for the layer indices.</t>	same picture, if any.</dd>
		<dt pn="section-4.2-6.5">L:</dt>
	<t hangText="F:">Flexible mode. F set to one indicates	<dd pn="section-4.2-6.6">Layer indices present. When set to one, the
	flexible mode and if the P bit is also set to one, then the octets fol	one or two octets
	lowing	following the mandatory first octet and the PID (if present) is as
	the mandatory first octet, the PID, and layer indices (if present) are	described by "Layer indices" below. If the F bit (described below)
	as described by "Reference indices" below. This MUST only be set to 1	is set to one (indicating flexible mode), then only one octet is
	if the I	present for the layer indices. Otherwise, if the F bit is set to zero
	bit is also set to one; if the I bit is set to zero, then this MUST al	(indicating non-flexible mode), then two octets are present for the
	so be	layer indices.</dd>
	set to zero and ignored by receivers. (Flexible mode's Reference indic	<dt pn="section-4.2-6.7">F:</dt>
	es are defined as offsets	<dd pn="section-4.2-6.8">Flexible mode. When set to one, this indicat
	from the Picture ID field, so they would have no meaning if I were not	es flexible mode; if the
	set.)	P bit is also set to one, then the octets following the mandatory
	The value of this F	first octet, the PID, and layer indices (if present) are as
	bit MUST only change	described by "reference indices" below. This bit <bcp14>MUST</bcp14>
	on the first packet of a key picture. A key picture is a	only be set to one if the I bit is also set to one; if the I bit is
	picture whose base spatial layer frame is a key frame, and	set to zero, then this bit <bcp14>MUST</bcp14> also be set to zero and
	which thus completely resets the encoder state. This	ignored by receivers. (Flexible mode's reference indices are defined
	packet will have its P bit	as offsets from the Picture ID field, so they would have no meaning
	equal to zero, SID or L bit (described below) equal to zero, and B bit	if I were not set.) The value of the F bit <bcp14>MUST</bcp14>
	(described below)	only change on the first packet of a key picture. A "key picture" is
	equal to 1.</t>	a picture whose base spatial-layer frame is a keyframe, and thus one w
		hich
	<t hangText="B:">Start of a frame. MUST be set to 1 if	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 to one.</dd>
		<dt pn="section-4.2-6.9">B:</dt>
		<dd pn="section-4.2-6.10">Start of Frame. This bit <bcp14>MUST</bcp14>
		be set to one if
	the first payload octet of the RTP packet is the beginning of a	the first payload octet of the RTP packet is the beginning of a

	new VP9 frame, and MUST NOT be 1 otherwise. Note that this	new VP9 frame; otherwise, it <bcp14>MUST NOT</bcp14> be one. Note that
	frame might not be the first frame of a picture.</t>	this
		frame might not be the first frame of a picture.</dd>
	<t hangText="E:">End of a frame. MUST be set to 1 for the final	<dt pn="section-4.2-6.11">E:</dt>
	RTP packet of a VP9 frame, and 0 otherwise. This enables a	<dd pn="section-4.2-6.12">End of Frame. This bit <bcp14>MUST</bcp14>
		be set to one for the final
		RTP packet of a VP9 frame; otherwise, it is zero. This enables a
	decoder to finish decoding the frame, where it otherwise may need to	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 .	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	Note that, if spatial scalability is in use, more frames from the

	same picture may follow; see the description of the B bit above.</t>	same picture may follow; see the description of the B bit above.</dd>
		<dt pn="section-4.2-6.13">V:</dt>
	<t hangText="V:">Scalability structure (SS) data present. When set	<dd pn="section-4.2-6.14">Scalability Structure (SS) data present. Whe
	to one, the OPTIONAL SS data MUST be present in the payload descriptor	n set
	.	to one, the <bcp14>OPTIONAL</bcp14> SS data <bcp14>MUST</bcp14> be pre
	Otherwise, the SS data MUST NOT be present.</t>	sent in the payload descriptor.
		Otherwise, the SS data <bcp14>MUST NOT</bcp14> be present.</dd>
	<t hangText="Z:">Not a reference frame for upper spatial	<dt pn="section-4.2-6.15">Z:</dt>
	layers. If set to 1, indicates that frames with higher	<dd pn="section-4.2-6.16">Not a reference frame for upper spatial laye
	spatial layers SID+1 and greater of the current and following pictures	rs. If set to one,
	do not depend on the current spatial layer SID frame. This	indicates that frames with higher spatial layers SID+1 and greater
	enables a decoder which is targeting a higher spatial layer	of the current and following pictures do not depend on the current
	to know that it can safely discard this packet's frame	spatial-layer SID frame. This enables a decoder that is targeting a
	without processing it, without having to wait for the "D"	higher spatial layer to know that it can safely discard this
	bit in the higher-layer frame (see below).</t>	packet's frame without processing it, without having to wait for the
	</list></t>	D bit in the higher-layer frame (see below).</dd>
		</dl>
	<t>The mandatory first octet is followed by the extension data fields th	<t indent="0" pn="section-4.2-7">The mandatory first octet is followed b
	at	y the extension data fields that
	are enabled:<list style="hanging">	are enabled:</t>
	<t hangText="M:">The most significant bit of the first octet is an	<dl newline="false" spacing="normal" indent="3" pn="section-4.2-8">
	extension flag. The field MUST be present if the I bit is equal to	<dt pn="section-4.2-8.1">M:</dt>
	one. If M is set, the PID field MUST contain 15 bits; otherwise, it MU	<dd pn="section-4.2-8.2">The most significant bit of the first octet i
	ST	s an extension
	contain 7 bits. See PID below.</t>	flag. The field <bcp14>MUST</bcp14> be present if the I bit is equal
		to one. If M is set, the PID field <bcp14>MUST</bcp14> contain 15
	<t hangText="Picture ID (PID):">Picture ID represented in 7 or 15 bits	bits; otherwise, it <bcp14>MUST</bcp14> contain 7 bits. See PID
	,	below.</dd>
	depending on the M bit. This is a running index of the pictures, where	<dt pn="section-4.2-8.3">Picture ID (PID):</dt>
	the	<dd pn="section-4.2-8.4">Picture ID represented in 7 or 15 bits, depen
	sender increments the value by 1 for each picture it sends. (Note how	ding on the M
	ever that	bit. This is a running index of the pictures, where the sender
	because a middlebox can discard pictures where permitted by the scalab	increments the value by one for each picture it sends. (Note,
	ility structure, Picture IDs	however, that because a middlebox can discard pictures where
	as received by a receiver might not be contiguous.) This	permitted by the SS, Picture IDs as received by a
	field MUST be present if the I bit is equal to one. If M is set to zer	receiver might not be contiguous.) This field <bcp14>MUST</bcp14>
	o,	be present if the I bit is equal to one. If M is set to zero, 7 bits
	7 bits carry the PID; else if M is set to one, 15 bits carry	carry the PID; else, if M is set to one, 15 bits carry the PID in
	the PID in network byte order.	network byte order. The sender may choose between a 7- or 15-bit
	The sender may choose between a 7- or 15-bit index. The PID SHOULD sta	index. The PID <bcp14>SHOULD</bcp14> start on a random number and
	rt on a	<bcp14>MUST</bcp14> wrap after reaching the maximum ID (0x7f or
	random number, and MUST wrap after reaching the maximum ID (0x7f or 0x	0x7fff depending on the index size chosen). The receiver <bcp14>MUST N
	7fff depending on	OT</bcp14> assume that the number of bits in the PID stays the same
	the index size chosen). The receiver	through the session. If this field transitions from 7 bits to 15
	MUST NOT assume that the number of bits in PID stay the same through t	bits, the value is zero-extended (i.e., the value after 0x6e is
	he	0x006f); if the field transitions from 15 bits to 7 bits, it is
	session. If this field transitions from 7-bits to 15-bits, the value	truncated (i.e., the value after 0x1bbe is 0x3f).
	is zero-extended	</dd>
	(i.e. the value after 0x6e is 0x006f); if the field transitions from 1	<dt pn="section-4.2-8.5"/>
	5 bits to 7 bits,	<dd pn="section-4.2-8.6">In the non-flexible mode (when the F bit is s
	it is truncated (i.e. the value after 0x1bbe is 0xbf).	et to zero), this PID
	</t>	is used as an index to the PG specified in the SS
		data below. In this mode, the PID of the keyframe corresponds to
	<t>In the non-flexible mode (when the F bit is set to 0), this PID is	the first specified frame in the PG. Then subsequent PIDs are
	used	mapped to subsequently specified frames in the PG (modulo N_G,
	as an index to the picture group (PG) specified in the SS data below.	specified in the SS data below), respectively.</dd>
	In this mode, the	<dt pn="section-4.2-8.7"/>
	PID of the key frame corresponds to the first specified frame in the	<dd pn="section-4.2-8.8">All frames of the same picture <bcp14>MUST</b
	PG. Then subsequent PIDs are mapped to subsequently specified frames	cp14> have the same
	in	PID value.</dd>
	the PG (modulo N_G, specified in the SS data below), respectively.</t>	<dt pn="section-4.2-8.9"/>
		<dd pn="section-4.2-8.10">Frames (and their corresponding pictures) wi
	<t>All frames of the same picture MUST have the same PID value.	th the VP9
	</t>	show_frame field equal to zero <bcp14>MUST</bcp14> have distinct PID
		values from subsequent pictures with show_frame equal to one. Thus, a
	<t>Frames (and their corresponding pictures) with the VP9 show_	picture (as defined in this specification) is different than a VP9
	frame field equal to 0 MUST	superframe.</dd>
	have distinct PID values from subsequent pictures with sh	<dt pn="section-4.2-8.11"/>
	ow_frame equal to 1. Thus,	<dd pn="section-4.2-8.12">All frames of the same picture <bcp14>MUST</
	a Picture as defined in this specification is different t	bcp14> have the same
	han a VP9 Superframe.</t>	value for show_frame.</dd>
		<dt pn="section-4.2-8.13">Layer indices:</dt>
	<t>All frames of the same picture MUST have the same value for	<dd pn="section-4.2-8.14">This field is optional but <bcp14>RECOMMENDE
	show_frame.</t>	D</bcp14>
		whenever encoding with layers. For both flexible and non-flexible
	<t hangText="Layer indices:">This information is optional but RECOMMEN	modes, one octet is used to specify a layer frame's Temporal-layer
	DED	ID (TID) and Spatial-layer ID (SID) as shown both in Figures <xref tar
	whenever encoding with layers. For both flexible and non-flexible mod	get="figureVP9payloadDescriptor" format="counter" sectionFormat="of" derivedCont
	es,	ent="2"/> and <xref target="figureVP9payloadDescriptorNonFlexible" format="count
	one octet is used to specify a layer frame's temporal layer ID (TID) a	er" sectionFormat="of" derivedContent="3"/>.
	nd spatial layer ID (SID)	Additionally, a bit (U) is used to indicate that the current frame
	as shown both in <xref target="figureVP9payloadDescriptor"/> and <xref	is a "switching up point" frame. Another bit (D) is used to
	target="figureVP9payloadDescriptorNonFlexible"/>.	indicate whether inter-layer prediction is used for the current
	Additionally, a bit (U) is used to indicate that the current frame is	frame.</dd>
	a	<dt pn="section-4.2-8.15"/>
	"switching up point" frame. Another bit (D) is used to indicate wheth	<dd pn="section-4.2-8.16">In the non-flexible mode (when the F bit is
	er inter-layer	set to zero), another
	prediction is used for the current frame.</t>	octet is used to represent the Temporal Layer 0 Picture Index (8 bits)
		(TL0PICIDX), as
	<t>In the non-flexible mode (when the F bit is set to 0), another octe	depicted in <xref target="figureVP9payloadDescriptorNonFlexible" forma
	t is used	t="default" sectionFormat="of" derivedContent="Figure 3"/>. The TL0PICIDX is pr
	to represent temporal layer 0 index (TL0PICIDX), as depicted in <xref	esent so that all minimally
	target="figureVP9payloadDescriptorNonFlexible"/>.	required frames (the base temporal-layer frames) can be
	The TL0PICIDX is present so that all minimally required frames - the b	tracked.</dd>
	ase temporal layer frames - can be tracked.</t>	<dt pn="section-4.2-8.17"/>
		<dd pn="section-4.2-8.18">
	<t>The TID and SID fields indicate the temporal and spatial layers and	<t indent="0" pn="section-4.2-8.18.1">The TID and SID fields indicat
	can help middleboxes and	e the temporal and spatial layers
	endpoints quickly identify which layer a packet belongs to.	and can help middleboxes and endpoints quickly identify which
		layer a packet belongs to.
	<list style="hanging">
	<t hangText="TID:">The temporal layer ID of current frame. In the c
	ase of non-flexible mode,
	if PID is mapped to a picture in a specified PG, then
	the value of TID MUST match the corresponding TID value of the mappe
	d picture in the PG.</t>

	<t hangText="U:">Switching up point. If this bit is set to 1 for th
	e current picture with temporal
	layer ID equal to TID, then "switch up" to a higher frame rate is po
	ssible as subsequent higher temporal
	layer pictures will not depend on any picture before the current pic
	ture (in coding order) with temporal layer
	ID greater than TID.</t>

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

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

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

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


	<section anchor="VP9payloadDescriptorSS" title="Scalability Structure (SS)	</t>
	:">	<dl newline="false" spacing="normal" indent="3" pn="section-4.2-8.18
	<t>The scalability structure (SS) data describes the resolution of	.2">
	each frame within a picture as well as the inter-picture dependencies	<dt pn="section-4.2-8.18.2.1">TID:</dt>
	for a picture group (PG). If the VP9 payload descriptor's "V"	<dd pn="section-4.2-8.18.2.2">The temporal-layer ID of the current
	bit is set, the SS data is present in the position indicated in	frame. In the case of
	<xref target="figureVP9payloadDescriptor"/> and <xref target="figureVP9p	non-flexible mode, if a PID is mapped to a picture in a specified
	ayloadDescriptorNonFlexible"/>.</t>	PG, then the value of the TID <bcp14>MUST</bcp14> match the
	<figure anchor="figureVP9ScalabilityStructure">	corresponding TID value of the mapped picture in the PG.</dd>
	<artwork><![CDATA[	<dt pn="section-4.2-8.18.2.3">U:</dt>
		<dd pn="section-4.2-8.18.2.4">Switching up point. When this bit i
		s set to one, if the current picture has a temporal-layer ID equal to value T, t
		hen subsequent pictures with temporal-layer ID values higher than T will not dep
		end on any picture before
		the current picture (in decode order) with a temporal-layer ID
		value greater than T.</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
		with spatial-layer SID > 0 may be dependent on decoded
		spatial-layer SID-1 frame within the same picture. Different
		frames of the same picture <bcp14>MUST</bcp14> have distinct
		spatial-layer IDs, and frames' spatial layers
		<bcp14>MUST</bcp14> appear in increasing order within the
		frame.</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. D <b
		cp14>MUST</bcp14> be
		set to one if and only if the current spatial-layer SID frame
		depends on spatial-layer SID-1 frame of the same picture;
		otherwise, it <bcp14>MUST</bcp14> be set to zero. For the
		base-layer frame (with SID equal to zero), the D bit
		<bcp14>MUST</bcp14> be set to 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 b
		its). TL0PICIDX is only present
		in the non-flexible mode (F = 0). This is a running index for
		the temporal base-layer pictures, i.e., the pictures with a TID
		set to zero. If the TID is larger than zero, TL0PICIDX indicates
		which
		temporal base-layer picture the current picture depends on.
		TL0PICIDX <bcp14>MUST</bcp14> be incremented by one when the TID i
		s
		equal to zero. The index <bcp14>SHOULD</bcp14> start on a random
		number and <bcp14>MUST</bcp14> restart at zero after reaching the
		maximum number 255.</dd>
		</dl>
		</dd>
		<dt pn="section-4.2-8.19">Reference indices:</dt>
		<dd pn="section-4.2-8.20">
		<t indent="0" pn="section-4.2-8.20.1">When P and F are both set to o
		ne, indicating a non-keyframe in
		flexible mode, then at least one reference index
		<bcp14>MUST</bcp14> be specified as below. Additional reference
		indices (a total of up to three reference indices are allowed) may b
		e
		specified using the N bit below. When either P or F is set to zero,
		then no reference index is specified.
		</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) spec
		ified as the relative
		PID from the current picture. For example, when P_DIFF=3 on a
		packet containing the picture with PID 112 means that the
		picture refers back to the picture with PID 109. This
		calculation is done modulo the size of the PID field, i.e.,
		either 7 or 15 bits. A P_DIFF value of zero is invalid.</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 foll
		owing the current P_DIFF.</dd>
		</dl>
		</dd>
		</dl>
		<section anchor="VP9payloadDescriptorSS" numbered="true" toc="include" r
		emoveInRFC="false" pn="section-4.2.1">
		<name slugifiedName="name-scalability-structure-ss">Scalability Struct
		ure (SS)</name>
		<t indent="0" pn="section-4.2.1-1">The SS data describes the resolutio
		n of
		each frame within a picture as well as the inter-picture
		dependencies for a PG. If the VP9 payload
		descriptor's V bit is set, the SS data is present in the position
		indicated in Figures <xref format="counter" target="figureVP9payloadDe
		scriptor" sectionFormat="of" derivedContent="2"/> and <xref target="figureVP9pay
		loadDescriptorNonFlexible" format="counter" sectionFormat="of" derivedContent="3
		"/>.</t>
		<figure anchor="figureVP9ScalabilityStructure" align="left" suppress-t
		itle="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\|-\|-\|-\|	V: \| N_S \|Y\|G\|-\|-\|-\|
	+-+-+-+-+-+-+-+-+ -\	+-+-+-+-+-+-+-+-+ -\
	Y: \| WIDTH \| (OPTIONAL) .	Y: \| WIDTH \| (OPTIONAL) .
	+ + .	+ + .
	\| \| (OPTIONAL) .	\| \| (OPTIONAL) .
	+-+-+-+-+-+-+-+-+ . - N_S + 1 times	+-+-+-+-+-+-+-+-+ . - N_S + 1 times
	\| HEIGHT \| (OPTIONAL) .	\| HEIGHT \| (OPTIONAL) .
	+ + .	+ + .
	\| \| (OPTIONAL) .	\| \| (OPTIONAL) .
	+-+-+-+-+-+-+-+-+ -/	+-+-+-+-+-+-+-+-+ -/
	G: \| N_G \| (OPTIONAL)	G: \| N_G \| (OPTIONAL)
	+-+-+-+-+-+-+-+-+ -\	+-+-+-+-+-+-+-+-+ -\
	N_G: \| TID \|U\| R \|-\|-\| (OPTIONAL) .	N_G: \| TID \|U\| R \|-\|-\| (OPTIONAL) .
	+-+-+-+-+-+-+-+-+ -\ . - N_G times	+-+-+-+-+-+-+-+-+ -\ . - N_G times
	\| P_DIFF \| (OPTIONAL) . - R times .	\| P_DIFF \| (OPTIONAL) . - R times .
	+-+-+-+-+-+-+-+-+ -/ -/	+-+-+-+-+-+-+-+-+ -/ -/

	]]></artwork>	</artwork>
	</figure>	</figure>
		<dl newline="false" spacing="normal" indent="3" pn="section-4.2.1-3">
	<t><list style="hanging">	<dt pn="section-4.2.1-3.1">N_S:</dt>
	<t hangText="N_S:">N_S + 1 indicates the number of spatial	<dd pn="section-4.2.1-3.2">Number of Spatial Layers Minus 1. N_S +
	layers present in the VP9 stream.</t>	1 indicates the number of spatial
		layers present in the VP9 stream.</dd>
	<t hangText="Y:">Each spatial layer's frame resolution present.	<dt pn="section-4.2.1-3.3">Y:</dt>
	When set to one, the OPTIONAL WIDTH (2 octets) and HEIGHT	<dd pn="section-4.2.1-3.4">Each spatial layer's frame resolution is
	(2 octets) MUST be present for each layer frame. Otherwise, the	present.
	resolution MUST NOT be present.</t>	When set to one, the <bcp14>OPTIONAL</bcp14> WIDTH (2 octets) and HEIG
		HT
	<t hangText="G:">PG description present flag.</t>	(2 octets) <bcp14>MUST</bcp14> be present for each layer frame. Other
		wise, the
	<t hangText="-:">Bit reserved for future use. MUST be set to	resolution <bcp14>MUST NOT</bcp14> be present.</dd>
	zero and MUST be ignored by the receiver.</t>	<dt pn="section-4.2.1-3.5">G:</dt>
		<dd pn="section-4.2.1-3.6">The PG description present flag.</dd>
	<t hangText="N_G:">N_G indicates the number of pictures in a	<dt pn="section-4.2.1-3.7">-:</dt>
	Picture Group (PG).	<dd pn="section-4.2.1-3.8">A bit reserved for future use. It <bcp14>
	If N_G is greater than 0, then the SS data allows	MUST</bcp14> be set
	the inter-picture dependency structure of the VP9 stream to	to zero and <bcp14>MUST</bcp14> be ignored by the receiver.</dd>
	be pre-declared, rather than indicating it on the fly with	<dt pn="section-4.2.1-3.9">N_G:</dt>
	every packet. If N_G is greater than 0, then for N_G	<dd pn="section-4.2.1-3.10">N_G indicates the number of pictures in
	pictures in the PG, each picture's temporal layer ID (TID), switch up	a PG.
	point (U),	If N_G is greater than zero, then the SS data allows the
	and the Reference indices (P_DIFFs) are specified.</t>	inter-picture dependency structure of the VP9 stream to be
		pre-declared, rather than indicating it on the fly with every
	<t>The first picture specified in the PG MUST have TID set to 0.</t>	packet. If N_G is greater than zero, then for N_G pictures in the
		PG, each picture's Temporal-layer ID (TID), switch up point (U),
	<t>G set to 0 or N_G set to 0 indicates that either there is only one	and reference indices (P_DIFFs) are specified.</dd>
	temporal	<dt pn="section-4.2.1-3.11"/>
	layer (for non-flexible mode) or no fixed inter-picture dependency inf	<dd pn="section-4.2.1-3.12">The first picture specified in the PG <b
	ormation is present	cp14>MUST</bcp14> have a TID set to zero.</dd>
	(for flexible mode) going forward in the bitstream.</t>	<dt pn="section-4.2.1-3.13"/>
		<dd pn="section-4.2.1-3.14">G set to zero or N_G set to zero indicat
	<t>Note that for a given picture, all frames follow the	es that either there is only
	same inter-picture dependency structure. However, the frame rate	one temporal layer (for non-flexible mode) or no fixed
	of each spatial layer can be different from each other and this can	inter-picture dependency information is present (for flexible
	be described with the use of the D bit described above. The	mode) going forward in the bitstream.</dd>
	specified dependency structure in the SS data MUST be for the highest	<dt pn="section-4.2.1-3.15"/>
	frame rate layer.</t>	<dd pn="section-4.2.1-3.16">Note that for a given picture, all frame
	</list></t>	s follow the same
		inter-picture dependency structure. However, the frame rate of
	<t>In a scalable stream sent with a fixed pattern, the SS data	each spatial layer can be different from each other; this can
	SHOULD be included in the first packet of every key frame. This is a pac	be described with the use of the D bit described above. The
	ket	specified dependency structure in the SS data <bcp14>MUST</bcp14>
	with P bit equal to zero, SID or L bit equal to zero, and B bit equal to	be for the highest frame rate layer.</dd>
	1.	<dt pn="section-4.2.1-3.17">R:</dt>
	The SS data MUST only be changed on the picture that corresponds to the	<dd pn="section-4.2.1-3.18">The number of P_DIFF fields that are pre
	first picture specified in the previous SS data's PG	sent.</dd>
	(if the previous SS data's N_G was greater than 0).</t>	</dl>
		<t indent="0" pn="section-4.2.1-4">In a scalable stream sent with a fi
		xed pattern, the SS data
		<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 equ
		al
		to zero, and B bit equal to one. The SS data <bcp14>MUST</bcp14> only
		be changed on the picture that corresponds to the first picture
		specified in the previous SS data's PG (if the previous SS data's
		N_G was greater than zero).</t>
		</section>
	</section>	</section>

	</section>	<section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
		">
	<section title="Frame Fragmentation">	<name slugifiedName="name-frame-fragmentation">Frame Fragmentation</name
	<t>VP9 frames are fragmented into packets, in RTP sequence	>
	number order, beginning with a	<t indent="0" pn="section-4.3-1">VP9 frames are fragmented into packets
	packet with the B bit set, and ending with a packet with the	in RTP sequence number
	E bit set. There is no mechanism for finer-grained	order: beginning with a packet with the B bit set and ending with a
	access to parts of a VP9 frame.</t>	packet with the E bit set. There is no mechanism for finer-grained
		access to parts of a VP9 frame.</t>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.4
	<section title="Scalable encoding considerations">	">
		<name slugifiedName="name-scalable-encoding-considera">Scalable Encoding
	<t>In addition to the use of reference frames, VP9 has several	Considerations</name>
		<t indent="0" pn="section-4.4-1">In addition to the use of reference fra
		mes, VP9 has several
	additional forms of inter-frame dependencies, largely	additional forms of inter-frame dependencies, largely
	involving probability tables for the entropy and tree	involving probability tables for the entropy and tree
	encoders. In VP9 syntax, the syntax element	encoders. In VP9 syntax, the syntax element
	"error_resilient_mode" resets this additional inter-frame	"error_resilient_mode" resets this additional inter-frame
	data, allowing a frame's syntax to be decoded	data, allowing a frame's syntax to be decoded
	independently.</t>	independently.</t>

		<t indent="0" pn="section-4.4-2">Due to the requirements of scalable str
	<t>Due to the requirements of scalable streams, a VP9 encoder	eams, a VP9 encoder
	producing a scalable stream needs to ensure that a frame does	producing a scalable stream needs to ensure that a frame does
	not depend on a previous frame (of the same or a previous	not depend on a previous frame (of the same or a previous
	picture) that can legitimately be removed from the stream.	picture) that can legitimately be removed from the stream.
	Thus, a frame that follows a frame that might be removed (in full decode	Thus, a frame that follows a frame that might be removed (in full decode

	order) MUST be encoded with "error_resilient_mode" set to	order) <bcp14>MUST</bcp14> be encoded with "error_resilient_mode" set to
	true.</t>	true.</t>

		<t indent="0" pn="section-4.4-3">For spatially scalable streams, this me
	<t>For spatially-scalable streams, this means that	ans that
	"error_resilient_mode" needs to be turned on for the base	"error_resilient_mode" needs to be turned on for the base

	spatial layer; it can however be turned off for higher spatial	spatial layer; however, it can be turned off for higher spatial
	layers, assuming they are sent with inter-layer dependency	layers, assuming they are sent with inter-layer dependency

	(i.e. with the "D" bit set). For streams that are only	(i.e., with the D bit set). For streams that are only
	temporally-scalable without spatial scalability,	temporally scalable without spatial scalability,
	"error_resilient_mode" can additionally be turned off for any	"error_resilient_mode" can additionally be turned off for any

	picture that immediately follows a temporal layer 0 frame.</t>	picture that immediately follows a temporal-layer 0 frame.</t>
		</section>
	</section>	<section numbered="true" toc="include" removeInRFC="false" pn="section-4.5
		">
	<section title="Examples of VP9 RTP Stream">	<name slugifiedName="name-example-of-a-vp9-rtp-stream">Example of a VP9
	<section title="Reference picture use for scalable structure">	RTP Stream</name>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<t>As discussed in <xref target="mediaFormatDescription"/>, the	.5.1">
		<name slugifiedName="name-reference-picture-use-for-s">Reference Pictu
		re Use for Scalable Structure</name>
		<t indent="0" pn="section-4.5.1-1">As discussed in <xref target="media
		FormatDescription" format="default" sectionFormat="of" derivedContent="Section 3
		"/>, the
	VP9 codec can maintain up to eight reference frames, of	VP9 codec can maintain up to eight reference frames, of
	which up to three can be referenced or updated by any new	which up to three can be referenced or updated by any new
	frame. This section illustrates one way that a scalable	frame. This section illustrates one way that a scalable
	structure (with three spatial layers and three temporal	structure (with three spatial layers and three temporal
	layers) can be constructed using these reference	layers) can be constructed using these reference
	frames.</t>	frames.</t>

		<table align="center" pn="table-1">
	<texttable title="Example scalability structure">	<name slugifiedName="name-example-scalability-structu">Example Scala
		bility Structure</name>
	<ttcol align="center">Temporal</ttcol>	<thead>
	<ttcol align="center">Spatial</ttcol>	<tr>
	<ttcol align="center">References</ttcol>	<th align="center" colspan="1" rowspan="1">Temporal</th>
	<ttcol align="center">Updates</ttcol>	<th align="center" colspan="1" rowspan="1">Spatial</th>
	<c>0</c><c>0</c><c>0</c><c>0</c>	<th align="center" colspan="1" rowspan="1">References</th>
	<c>0</c><c>1</c><c>0,1</c><c>1</c>	<th align="center" colspan="1" rowspan="1">Updates</th>
	<c>0</c><c>2</c><c>1,2</c><c>2</c>	</tr>
	<c>2</c><c>0</c><c>0</c><c>6</c>	</thead>
	<c>2</c><c>1</c><c>1,6</c><c>7</c>	<tbody>
	<c>2</c><c>2</c><c>2,7</c><c>-</c>	<tr>
	<c>1</c><c>0</c><c>0</c><c>3</c>	<td align="center" colspan="1" rowspan="1">0</td>
	<c>1</c><c>1</c><c>1,3</c><c>4</c>	<td align="center" colspan="1" rowspan="1">0</td>
	<c>1</c><c>2</c><c>2,4</c><c>5</c>	<td align="center" colspan="1" rowspan="1">0</td>
	<c>2</c><c>0</c><c>3</c><c>6</c>	<td align="center" colspan="1" rowspan="1">0</td>
	<c>2</c><c>1</c><c>4,6</c><c>7</c>	</tr>
	<c>2</c><c>2</c><c>5,7</c><c>-</c>	<tr>
		<td align="center" colspan="1" rowspan="1">0</td>
	</texttable>	<td align="center" colspan="1" rowspan="1">1</td>
		<td align="center" colspan="1" rowspan="1">0,1</td>
	<t>This structure is constructed such that the "U" bit can	<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 bit can
	always be set.</t>	always be set.</t>

		</section>
	</section>	</section>
	</section>
	</section>	</section>

		<section anchor="Feedback" numbered="true" toc="include" removeInRFC="false"
	<section anchor="Feedback" title="Feedback Messages and Header Extensions">	pn="section-5">
	<section anchor="RPSI" title="Reference Picture Selection Indication (RPSI	<name slugifiedName="name-feedback-messages-and-heade">Feedback Messages a
	)">	nd Header Extensions</name>
	<t>The reference picture selection index is a payload-specific	<section anchor="RPSI" numbered="true" toc="include" removeInRFC="false" p
		n="section-5.1">
		<name slugifiedName="name-reference-picture-selection">Reference Picture
		Selection Indication (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	feedback message defined within the RTCP-based feedback format. The

	RPSI message is generated by a receiver and can be used in two ways.	RPSI message is generated by a receiver and can be used in two ways:
	Either it can signal a preferred reference picture when a loss has	either it can signal a preferred reference picture when a loss has
	been detected by the decoder -- preferably then a reference that the	been detected by the decoder (preferably a reference that the decoder
	decoder knows is perfect -- or, it can be used as positive feedback	knows is perfect) or it can be used as positive feedback information
	information to acknowledge correct decoding of certain reference	to acknowledge correct decoding of certain reference pictures. The
	pictures. The positive feedback method is useful for VP9 used for	positive feedback method is useful for VP9 used for point-to-point
	point to point (unicast) communication. The use of RPSI for VP9 is prefe	(unicast) communication. The use of RPSI for VP9 is preferably
	rably combined with a special	combined with a special update pattern of the codec's two special
	update pattern of the codec's two special reference frames -- the	reference frames -- the golden frame and the altref frame -- in which th
	golden frame and the altref frame -- in which they are updated in an	ey
	alternating leapfrog fashion. When a receiver has received and	are updated in an alternating leapfrog fashion. When a receiver has
	correctly decoded a golden or altref frame, and that frame had a	received and correctly decoded a golden or altref frame, and that
	Picture ID in the payload descriptor, the receiver can acknowledge this	frame had a Picture ID in the payload descriptor, the receiver can
	simply by sending an RPSI message back to the sender. The message body	acknowledge this simply by sending an RPSI message back to the
	(i.e., the "native RPSI bit string" in <xref target="RFC4585"/>) is	sender. The message body (i.e., the "native RPSI bit string" in <xref ta
	simply the (7 or 15 bit) Picture ID of the received frame.</t>	rget="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>) i
		s simply the (7- or 15-bit)
	<t>Note: because all frames of the same picture must have the	Picture ID of the received frame.</t>
		<aside pn="section-5.1-2">
		<t indent="0" pn="section-5.1-2.1">Note: because all frames of the sam
		e picture must have the
	same inter-picture reference structure, there is no need for a	same inter-picture reference structure, there is no need for a
	message to specify which frame is being selected.</t>	message to specify which frame is being selected.</t>

		</aside>
	</section>	</section>

		<section anchor="FIR" numbered="true" toc="include" removeInRFC="false" pn
	<section title='Full Intra Request (FIR)' anchor="FIR">	="section-5.2">
		<name slugifiedName="name-full-intra-request-fir">Full Intra Request (FI
	<t>The <xref target='RFC5104'>Full Intra Request (FIR)</xref>	R)</name>
		<t indent="0" pn="section-5.2-1">The <xref target="RFC5104" format="defa
		ult" sectionFormat="of" derivedContent="RFC5104">Full Intra Request (FIR)</xref>
	RTCP feedback message allows a receiver to request a full state r efresh of an encoded stream.</t>	RTCP feedback message allows a receiver to request a full state r efresh of an encoded stream.</t>

		<t indent="0" pn="section-5.2-2">Upon receipt of a FIR request, a VP9 se
	<t>Upon receipt of an FIR request, a VP9 sender MUST send a	nder <bcp14>MUST</bcp14>
	picture with a keyframe for its spatial layer 0 layer	send a picture with a keyframe for its spatial-layer 0 layer frame and
	frame, and then send frames without inter-picture prediction	then send frames without inter-picture prediction (P=0) for any
	(P=0) for any higher layer frames.</t>	higher-layer frames.</t>
		</section>
	</section>	<section anchor="LRR" numbered="true" toc="include" removeInRFC="false" pn
		="section-5.3">
	<section title="Layer Refresh Request (LRR)" anchor="LRR">	<name slugifiedName="name-layer-refresh-request-lrr">Layer Refresh Reque
	<t>The <xref target="I-D.ietf-avtext-lrr">Layer Refresh Request (	st (LRR)</name>
	LRR)</xref>	<t indent="0" pn="section-5.3-1">The <xref target="RFC9627" format="defa
	allows a receiver to request a single layer of a spatially or	ult" sectionFormat="of" derivedContent="RFC9627">Layer Refresh Request
	temporally encoded stream to be refreshed, without necessarily	(LRR)</xref> allows a receiver to request a single layer of a
	affecting the stream's other layers.</t>	spatially or temporally encoded stream to be refreshed without
		necessarily affecting the stream's other layers.</t>
	<figure anchor="figureLRRIndexFormat">	<figure anchor="figureLRRIndexFormat" align="left" suppress-title="false
	<artwork><![CDATA[	" 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\|	\|0\|1\|2\|3\|4\|5\|6\|7\|0\|1\|2\|3\|4\|5\|6\|7\|
	+---------------+---------+-----+	+---------------+---------+-----+
	\| RES \| TID \| RES \| SID \|	\| RES \| TID \| RES \| SID \|
	+---------------+---------+-----+	+---------------+---------+-----+

	]]></artwork>	</artwork>
	</figure>	</figure>
		<t indent="0" pn="section-5.3-3"><xref target="figureLRRIndexFormat" for
	<t><xref target="figureLRRIndexFormat"/> shows the format	mat="default" sectionFormat="of" derivedContent="Figure 5"/> shows the format
	of LRR's layer index fields for VP9 streams. The two "RES"	of an LRR's layer index fields for VP9 streams. The two "RES"
	fields MUST be set to 0 on transmission and ingnored on	fields <bcp14>MUST</bcp14> be set to zero on transmission and ign
	reception. See <xref target="VP9payloadDescriptor"/> for	ored on
		reception. See <xref target="VP9payloadDescriptor" format="defau
		lt" sectionFormat="of" derivedContent="Section 4.2"/> for
	details on the TID and SID fields.</t>	details on the TID and SID fields.</t>

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

	{1,0}, or {0,0}.</t>	{1,0} or {0,0}.</t>
		<t indent="0" pn="section-5.3-7">In the non-flexible mode, periodic upgr
	<t>In the non-flexible mode, periodic upgrade frames can be	ade frames can be defined by
	defined by the layer structure of the SS, thus periodic upgrade	the layer structure of the SS; thus, periodic upgrade frames can be
	frames can be automatically identified by the picture ID.</t>	automatically identified by the Picture ID.</t>
	</section>	</section>

	</section>	</section>

		<section anchor="payloadFormatParameters" numbered="true" toc="include" remo
	<section anchor="payloadFormatParameters"	veInRFC="false" pn="section-6">
	title="Payload Format Parameters">	<name slugifiedName="name-payload-format-parameters">Payload Format Parame
	<t>This payload format has three optional parameters, "max-fr", "max-fs",	ters</name>
	and "profile-id".</t>	<t indent="0" pn="section-6-1">This payload format has three optional para
		meters: max-fr,
	<t>The max-fr and max-fs	max-fs, and profile-id.</t>
	parameters are used to signal the capabilities of a receiver	<t indent="0" pn="section-6-2">The max-fr and max-fs parameters are used t
	implementation. If the implementation is willing to	o signal the capabilities
	receive media, both parameters MUST be provided. These parameters MU	of a receiver implementation. If the implementation is willing to
	ST	receive media, both parameters <bcp14>MUST</bcp14> be provided. These
	NOT be used for any other purpose. A media sender SHOULD NOT send	parameters <bcp14>MUST NOT</bcp14> be used for any other purpose. A
	media with a frame rate or frame size exceeding the max-fr and max-f	media sender <bcp14>SHOULD NOT</bcp14> send media with a frame rate or
	s	frame size exceeding the max-fr and max-fs values signaled. (There may
	values signaled. (There may be scenarios, such as pre-encoded	be scenarios, such as pre-encoded media or <xref target="RFC7667" format="
	media or <xref target='RFC7667'>selective forwarding	default" sectionFormat="of" derivedContent="RFC7667">selective forwarding middle
	middleboxes</xref>, where a media sender does not have media availab	boxes</xref>, where a media
	le	sender does not have media available that fits within a receiver's
	that fits within a receivers max-fs and max-fr value; in such	max-fs and max-fr values; in such scenarios, a sender <bcp14>MAY</bcp14>
	scenarios, a sender MAY exceed the signaled values.)	exceed the signaled values.)
	<list style="hanging">	</t>
	<t hangText="max-fr:">The value of max-fr is an integer	<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	indicating the maximum frame rate in units of frames per

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

	the decoder is capable of decoding.</t>	the decoder is capable of decoding.</dd>
		<dt pn="section-6-3.5"/>
	<t>The decoder is capable of decoding this frame size as long	<dd pn="section-6-3.6">The decoder is capable of decoding this frame siz
	as the width and height of the frame in macroblocks are less	e as long
	than int(sqrt(max-fs * 8)) - for instance, a max-fs of 1200	as the width and height of the frame in macroblocks are each les
		s
		than int(sqrt(max-fs * 8)); for instance, a max-fs of 1200
	(capable of supporting 640x480 resolution) will support widths	(capable of supporting 640x480 resolution) will support widths

	and heights up to 1552 pixels (97 macroblocks).</t>	and heights up to 1552 pixels (97 macroblocks).</dd>
		<dt pn="section-6-3.7">profile-id:</dt>
	<t hangText="profile-id:">The value of profile-id is an integer	<dd pn="section-6-3.8">The value of profile-id is an integer indicating
	indicating the default coding profile, the subset of coding	the default
	tools that may have been used to generate the stream or that the	coding profile (the subset of coding tools that may have been used to
	receiver supports). <xref target="TableOfProfileIds"/> lists all	generate the stream or that the receiver supports). <xref target="TableO
	of the profiles defined in section 7.2 of <xref target="VP9-BITST	fProfileIds" format="default" sectionFormat="of" derivedContent="Table 2"/> list
	REAM"/>	s all of the
	and the corresponding integer values to be used.</t>	profiles defined in Section 7.2 of <xref target="VP9-BITSTREAM" format="
		default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/> and the correspondi
	<t>If no profile-id is present, Profile 0 MUST be inferred. (The	ng integer values to be
		used.</dd>
		<dt pn="section-6-3.9"/>
		<dd pn="section-6-3.10">If no profile-id is present, Profile 0 <bcp14>MU
		ST</bcp14> be inferred. (The
	profile-id parameter was added relatively late in the developmen t of this	profile-id parameter was added relatively late in the developmen t of this
	specification, so some existing implementations may not send it. )	specification, so some existing implementations may not send it. )

	</t>	</dd>
		<dt pn="section-6-3.11"/>
	<t>Informative note: See <xref target="TableOfProfiles"/> for cap	<dd pn="section-6-3.12">Informative note: See <xref target="TableOfProfi
	abilities	les" format="default" sectionFormat="of" derivedContent="Table 3"/> for capabili
	of coding profiles defined in section 7.2 of <xref target="VP9-BI	ties of coding profiles defined in Section 7.2 of
	TSTREAM"/>.</t>	<xref target="VP9-BITSTREAM" format="default" sectionFormat="of" derived
	</list></t>	Content="VP9-BITSTREAM"/>.</dd>
		</dl>
	<t>A receiver MUST ignore any parameter unspecified in this	<t indent="0" pn="section-6-4">A receiver <bcp14>MUST</bcp14> ignore any p
	specification.</t>	arameter unspecified in this
		specification.</t>
	<texttable anchor="TableOfProfileIds" title="Table of profile-id	<table anchor="TableOfProfileIds" align="center" pn="table-2">
	integer values representing the VP9 profile corresponding to the set of	<name slugifiedName="name-correspondence-between-prof">Correspondence be
	coding tools supported.">	tween profile-id to VP9 Profile Integer</name>
	<ttcol align="center">Profile</ttcol>	<thead>
	<ttcol align="center">profile-id</ttcol>	<tr>
	<c>0</c><c>0</c>	<th align="center" colspan="1" rowspan="1">Profile</th>
	<c>1</c><c>1</c>	<th align="center" colspan="1" rowspan="1">profile-id</th>
	<c>2</c><c>2</c>	</tr>
	<c>3</c><c>3</c>	</thead>
	</texttable>	<tbody>
		<tr>
	<texttable anchor="TableOfProfiles" title="Table of profile	<td align="center" colspan="1" rowspan="1">0</td>
	capabilities.">	<td align="center" colspan="1" rowspan="1">0</td>
	<ttcol align="center">Profile</ttcol>	</tr>
	<ttcol align="center">Bit Depth</ttcol>	<tr>
	<ttcol align="center">SRGB Colorspace</ttcol>	<td align="center" colspan="1" rowspan="1">1</td>
	<ttcol align="center">Chroma Subsampling</ttcol>	<td align="center" colspan="1" rowspan="1">1</td>
	<c>0</c><c>8</c><c>No</c><c>YUV 4:2:0</c>	</tr>
	<c>1</c><c>8</c><c>Yes</c><c>YUV 4:2:2,4:4:0 or 4:4:4</c>	<tr>
	<c>2</c><c>10 or 12</c><c>No</c><c>YUV 4:2:0</c>	<td align="center" colspan="1" rowspan="1">2</td>
	<c>3</c><c>10 or 12</c><c>Yes</c><c>YUV 4:2:2,4:4:0 or 4:4:4</c>	<td align="center" colspan="1" rowspan="1">2</td>
	</texttable>	</tr>
		<tr>
	<section anchor="SDPParameters" title="SDP Parameters">	<td align="center" colspan="1" rowspan="1">3</td>
	<section title="Mapping of Media Subtype Parameters to SDP">	<td align="center" colspan="1" rowspan="1">3</td>
	<t>The media type video/VP9 string is mapped to fields in the	</tr>
	Session Description Protocol (SDP) <xref target="RFC8866"/> as	</tbody>
	follows: <list style="symbols">	</table>
	<t>The media name in the "m=" line of SDP MUST be video.</t>	<table anchor="TableOfProfiles" align="center" pn="table-3">
		<name slugifiedName="name-profile-capabilities">Profile Capabilities</na
	<t>The encoding name in the "a=rtpmap" line of SDP MUST be VP9	me>
	(the media subtype).</t>	<thead>
		<tr>
	<t>The clock rate in the "a=rtpmap" line MUST be 90000.</t>	<th align="center" colspan="1" rowspan="1">Profile</th>
		<th align="center" colspan="1" rowspan="1">Bit Depth</th>
	<t>The parameters "max-fr" and "max-fs" MUST be included in	<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 or 4:4:4<
		/td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">2</td>
		<td align="center" colspan="1" rowspan="1">10 or 12</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 or 12</td>
		<td align="center" colspan="1" rowspan="1">Yes</td>
		<td align="center" colspan="1" rowspan="1">YUV 4:2:2,4:4:0 or 4:4:4<
		/td>
		</tr>
		</tbody>
		</table>
		<aside pn="section-6-7">
		<t keepWithPrevious="true" indent="0" pn="section-6-7.1">Note: SRGB (oft
		en sRGB) = Standard Red-Green-Blue</t>
		</aside>
		<section anchor="SDPParameters" numbered="true" toc="include" removeInRFC=
		"false" pn="section-6.1">
		<name slugifiedName="name-sdp-parameters">SDP Parameters</name>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-6
		.1.1">
		<name slugifiedName="name-mapping-of-media-subtype-pa">Mapping of Medi
		a Subtype Parameters to SDP</name>
		<t indent="0" pn="section-6.1.1-1">The media type video/vp9 string is
		mapped to fields in the
		Session Description Protocol (SDP) <xref target="RFC8866" format="defa
		ult" sectionFormat="of" derivedContent="RFC8866"/> as
		follows: </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 SDP <b
		cp14>MUST</bcp14> be video.</li>
		<li pn="section-6.1.1-2.2">The encoding name in the "a=rtpmap" line
		of SDP
		<bcp14>MUST</bcp14> be VP9 (the media subtype).</li>
		<li pn="section-6.1.1-2.3">The clock rate in the "a=rtpmap" line <bc
		p14>MUST</bcp14> be 90000.</li>
		<li pn="section-6.1.1-2.4">The parameters max-fr and max-fs <bcp14>M
		UST</bcp14> be included in
	the "a=fmtp" line of SDP if the receiver wishes to declare its rec eiver	the "a=fmtp" line of SDP if the receiver wishes to declare its rec eiver
	capabilities. These parameters are expressed as a media subtype	capabilities. These parameters are expressed as a media subtype

	string, in the form of a semicolon separated list of	string in the form of a semicolon-separated list of
	parameter=value pairs.</t>	parameter=value pairs.</li>
		<li pn="section-6.1.1-2.5">The <bcp14>OPTIONAL</bcp14> parameter pro
	<t>The OPTIONAL parameter profile-id, when present, SHOULD be	file-id, when present, <bcp14>SHOULD</bcp14> be
	included in the "a=fmtp" line of SDP. This parameter is expressed	included in the "a=fmtp" line of SDP. This parameter is expressed

	as a media subtype string, in the form of a parameter=value	as a media subtype string in the form of a parameter=value
	pair. When the parameter is not present, a value of 0 MUST be	pair. When the parameter is not present, a value of 0 <bcp14>MUST</
	inferred for profile-id.</t>	bcp14> be
	</list></t>	inferred for profile-id.</li>
		</ul>
	<section title="Example">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>An example of media representation in SDP is as follows:</t>	-6.1.1.1">
		<name slugifiedName="name-example">Example</name>
	<figure>	<t indent="0" pn="section-6.1.1.1-1">An example of media representat
	<artwork>m=video 49170 RTP/AVPF 98	ion in SDP is as follows:</t>
		<sourcecode type="sdp" markers="false" pn="section-6.1.1.1-2">m=vide
		o 49170 RTP/AVPF 98
	a=rtpmap:98 VP9/90000	a=rtpmap:98 VP9/90000
	a=fmtp:98 max-fr=30;max-fs=3600;profile-id=0	a=fmtp:98 max-fr=30;max-fs=3600;profile-id=0

	</artwork>	</sourcecode>
	</figure>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-6
	<section title="Offer/Answer Considerations">	.1.2">
	<t>When VP9 is offered over RTP using SDP in an Offer/Answer model	<name slugifiedName="name-offer-answer-considerations">Offer/Answer Co
	<xref target="RFC3264"/> for negotiation for unicast usage, the follow	nsiderations</name>
	ing	<t indent="0" pn="section-6.1.2-1">When VP9 is offered over RTP using
	limitations and rules apply: <list style="symbols">	SDP in an Offer/Answer model
	<t>The parameter identifying a media format configuration for VP9 i	<xref target="RFC3264" format="default" sectionFormat="of" derivedCont
	s	ent="RFC3264"/> for negotiation for unicast usage, the following
	profile-id. This media format configuration parameter MUST be used	limitations and rules apply: </t>
	symmetrically; that is, the answerer MUST either maintain this	<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 parameter <bcp14>MUST</
		bcp14> be used
		symmetrically; that is, the answerer <bcp14>MUST</bcp14> either mai
		ntain this
	configuration parameter or remove the media format (payload type)	configuration parameter or remove the media format (payload type)

	completely if it is not supported.</t>	completely if it is not supported.</li>
		<li pn="section-6.1.2-2.2">The max-fr and max-fs parameters are used
	<t>The max-fr and max-fs parameters are used declaratively to	declaratively to
	describe receiver capabilities, even in the Offer/Answer model.	describe receiver capabilities, even in the Offer/Answer model.
	The values in an answer are used to describe the answerer's	The values in an answer are used to describe the answerer's

	capabilities, and thus their values are set independently of the	capabilities; thus, their values are set independently of the
	values in the offer.</t>	values in the offer.</li>
		<li pn="section-6.1.2-2.3">To simplify the handling and matching of
	<t>To simplify the handling and matching of these configurations,	these configurations, the
	the	same RTP payload type number used in the offer <bcp14>SHOULD</bcp1
	same RTP payload type number used in the offer SHOULD also be used	4> also be used
	in the answer and in a subsequent offer, as specified in <xref	in the answer and in a subsequent offer, as specified in <xref tar
	target="RFC3264"/>. An answer or subsequent offer	get="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>. An
	MUST NOT contain the payload type number used in the offer unless t	answer or subsequent offer
	he	<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.	profile-id value is exactly the same as in the original offer.

	However, max-fr and max-fs parameters MAY be changed in subsequent	However, max-fr and max-fs parameters <bcp14>MAY</bcp14> be change d in subsequent
	offers and answers, with the same payload type number, if an endpo int	offers and answers, with the same payload type number, if an endpo int

	wishes to change its declared receiver capabilities.</t>	wishes to change its declared receiver capabilities.</li>
	</list></t>	</ul>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<section anchor="mediaTypeRegistration" numbered="true" toc="include" remove
	<section anchor="mediaTypeRegistration" title="Media Type Definition">	InRFC="false" pn="section-7">
	<t>This registration is done using the template defined in <xref	<name slugifiedName="name-media-type-definition">Media Type Definition</na
	target="RFC6838"/> and following <xref target="RFC4855"/>. <list	me>
	style="hanging">	<t indent="0" pn="section-7-1">This registration uses the template defined
	<t hangText="Type name:">video</t>	in <xref target="RFC6838" format="default" sectionFormat="of" derivedContent="R
		FC6838"/> and following <xref target="RFC4855" format="default" sectionFormat="o
	<t hangText="Subtype name:">VP9</t>	f" derivedContent="RFC4855"/>. </t>
		<dl newline="false" spacing="normal" indent="3" pn="section-7-2">
	<t hangText="Required parameters:">N/A.</t>	<dt pn="section-7-2.1">Type name:</dt>
		<dd pn="section-7-2.2">video</dd>
	<t hangText="Optional parameters:"><vspace blankLines="0"/>	<dt pn="section-7-2.3">Subtype name:</dt>
	There are three optional parameters, "max-fr", "max-fs", and "profil	<dd pn="section-7-2.4">VP9</dd>
	e-id".	<dt pn="section-7-2.5">Required parameters:</dt>
	See <xref target='payloadFormatParameters' /> for their definition.	<dd pn="section-7-2.6">N/A</dd>
	</t>	<dt pn="section-7-2.7">Optional parameters:</dt>
		<dd pn="section-7-2.8">
	<t hangText="Encoding considerations:"><vspace blankLines="0"/>	There are three optional parameters: max-fr, max-fs, and profile-id.
		See <xref target="payloadFormatParameters" format="default" sectionF
		ormat="of" derivedContent="Section 6"/> for their definition.
		</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; see	This media type is framed in RTP and contains binary data; see

	Section 4.8 of <xref target="RFC6838"/>.</t>	<xref target="RFC6838" sectionFormat="of" section="4.8" format="defa
		ult" derivedLink="https://rfc-editor.org/rfc/rfc6838#section-4.8" derivedContent
	<t hangText="Security considerations:">See <xref	="RFC6838"/>.</dd>
	target="securityConsiderations"/> of RFC xxxx. <vspace	<dt pn="section-7-2.11">Security considerations:</dt>
	blankLines="0"/> [RFC Editor: Upon publication as an RFC, please	<dd pn="section-7-2.12">
	replace "XXXX" with the number assigned to this document and	<t indent="0" pn="section-7-2.12.1">See <xref target="securityConsider
	remove this note.]</t>	ations" format="default" sectionFormat="of" derivedContent="Section 8"/> of RFC
		9628. </t>
	<t hangText="Interoperability considerations:">None.</t>	</dd>
		<dt pn="section-7-2.13">Interoperability considerations:</dt>
	<t hangText="Published specification:">VP9 bitstream format <xref	<dd pn="section-7-2.14">None</dd>
	target="VP9-BITSTREAM"/> and RFC XXXX. <vspace blankLines="0"/> [RFC	<dt pn="section-7-2.15">Published specification:</dt>
	Editor: Upon publication as an RFC, please replace "XXXX" with the	<dd pn="section-7-2.16">
	number assigned to this document and remove this note.] <vspace	<t indent="0" pn="section-7-2.16.1">VP9 bitstream format <xref target=
	blankLines="0"/></t>	"VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREA
		M"/> and RFC 9628. </t>
	<t hangText="Applications which use this media type:"><vspace	</dd>
	blankLines="0"/> For example: Video over IP, video	<dt pn="section-7-2.17">Applications that use this media type:</dt>
	conferencing.</t>	<dd pn="section-7-2.18"> For example, video over IP, video
		conferencing.</dd>
	<t hangText="Fragment identifier considerations:">N/A.</t	<dt pn="section-7-2.19">Fragment identifier considerations:</dt>
	>	<dd pn="section-7-2.20">N/A</dd>
		<dt pn="section-7-2.21">Additional information:</dt>
	<t hangText="Additional information:">None.</t>	<dd pn="section-7-2.22">None</dd>
		<dt pn="section-7-2.23">Person & email address to contact for furthe
	<t	r information:</dt>
	hangText="Person & email address to contact for further informat	<dd pn="section-7-2.24">
	ion:"><vspace	<t indent="0" pn="section-7-2.24.1"><contact fullname="Jonathan Lennox
	blankLines="0"/> Jonathan Lennox <jonathan.lennox@8x8.com></t>	"/> <jonathan.lennox@8x8.com></t>
		</dd>
	<t hangText="Intended usage:">COMMON</t>	<dt pn="section-7-2.25">Intended usage:</dt>
		<dd pn="section-7-2.26">COMMON</dd>
	<t hangText="Restrictions on usage:"><vspace blankLines="0"/> This	<dt pn="section-7-2.27">Restrictions on usage:</dt>
	media type depends on RTP framing, and hence is only defined for	<dd pn="section-7-2.28"> This media type depends on RTP framing; hence,
	transfer via RTP <xref target="RFC3550"/>.</t>	it is only defined
		for transfer via RTP <xref target="RFC3550" format="default" sectionForm
	<t hangText="Author:">Jonathan Lennox <jonathan.lennox@8x8.com&gt	at="of" derivedContent="RFC3550"/>.</dd>
	;</t>	<dt pn="section-7-2.29">Author:</dt>
		<dd pn="section-7-2.30">
	<t hangText="Change controller:"><vspace blankLines="0"/> IETF	<t indent="0" pn="section-7-2.30.1"><contact fullname="Jonathan Lennox
	AVTCore Working Group delegated from the IESG.</t>	"/> <jonathan.lennox@8x8.com></t>
	</list></t>	</dd>
	</section>	<dt pn="section-7-2.31">Change controller:</dt>
		<dd pn="section-7-2.32"> IETF
	<section anchor="securityConsiderations" title="Security Considerations"	AVTCore Working Group delegated from the IETF.</dd>
	>	</dl>
	<t>RTP packets using the payload format defined in this specification	</section>
		<section anchor="securityConsiderations" numbered="true" toc="include" remov
		eInRFC="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 define
		d in this specification
	are subject to the security considerations discussed in the RTP	are subject to the security considerations discussed in the RTP

	specification <xref target="RFC3550"/>, and in any applicable RTP	specification <xref target="RFC3550" format="default" sectionFormat="of" d
	profile such	erivedContent="RFC3550"/>, and in any
	as <xref target='RFC3551'>RTP/AVP</xref>, <xref target='RFC4585'>RTP/AVPF<	applicable RTP profile such as <xref target="RFC3551" format="default" sec
	/xref>,	tionFormat="of" derivedContent="RFC3551">RTP/AVP</xref>, <xref target="RFC4585"
	<xref target='RFC3711'>RTP/SAVP</xref>,	format="default" sectionFormat="of" derivedContent="RFC4585">RTP/AVPF</xref>, <x
	or <xref target='RFC5124'>RTP/SAVPF</xref>.	ref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711
	However, as <xref target='RFC7202'>"Securing the RTP Protocol	">RTP/SAVP</xref>, or <xref target="RFC5124" format="default" sectionFormat="of"
	Framework: Why RTP Does Not Mandate a Single Media	derivedContent="RFC5124">RTP/SAVPF</xref>. However, as "<xref target="RFC7202"
	Security Solution"</xref> discusses, it is not an RTP payload format's res	format="title" sectionFormat="of" derivedContent="Securing the RTP Framework: W
	ponsibility to	hy RTP Does Not Mandate a Single Media Security Solution"/>" <xref target="RFC72
	discuss or mandate what solutions are used to meet the	02" format="default" sectionFormat="of" derivedContent="RFC7202"/> discusses, it
	basic security goals like confidentiality, integrity and source	is not an RTP
	authenticity for RTP in general. This responsibility lays on	payload format's responsibility to discuss or mandate what solutions are
		used to meet the basic security goals like confidentiality, integrity,
		and source authenticity for RTP in general. This responsibility lies with
	anyone using RTP in an application. They can find guidance on available	anyone using RTP in an application. They can find guidance on available

	security mechanisms in <xref target='RFC7201'>Options for Securing	security mechanisms in "<xref target="RFC7201" format="title" sectionForma
	RTP Sessions</xref>. Applications SHOULD use one or more appropriate	t="of" derivedContent="Options for Securing RTP Sessions"/>" <xref target="RFC72
	strong security mechanisms. The rest of this security	01" format="default" sectionFormat="of" derivedContent="RFC7201"/>. Application
	consideration section discusses the security impacting properties of the	s <bcp14>SHOULD</bcp14>
	payload format itself.</t>	use one or more appropriate strong security mechanisms.</t>
		<t indent="0" pn="section-8-2">Implementations of this RTP payload format
	<t>Implementations of this RTP payload format need to take appropriate sec	need to take appropriate
	urity	security considerations into account. It is extremely important for the
	considerations into account. It is extremely important for the decoder to	decoder to be robust against malicious or malformed payloads and ensure
	be	that they do not cause the decoder to overrun its allocated memory or
	robust against malicious or malformed payloads and ensure that they do not	otherwise misbehave. An overrun in allocated memory could lead to
	cause the decoder	arbitrary code execution by an attacker. The same applies to the
	to overrun its allocated memory or otherwise mis-behave. An overrun in al	encoder, even though problems in encoders are (typically) rarer.</t>
	located memory could lead to	<t indent="0" pn="section-8-3">This RTP payload format and its media decod
	arbitrary code execution by an attacker. The same applies to the encoder,	er do not exhibit any
	even	significant non-uniformity in the receiver-side computational complexity
	though problems in encoders are typically rarer.</t>	for packet processing; thus, they are unlikely to pose a denial-of-service
		threat due to the receipt of pathological data. Nor does the RTP payload
	<t>This RTP payload	format contain any active content.</t>
	format and its media decoder do not exhibit any significant
	non-uniformity in the receiver-side computational complexity for packet
	processing, and thus are unlikely to pose a denial-of-service threat due
	to the receipt of pathological data. Nor does the RTP payload format
	contain any active content.</t>
	</section>	</section>

		<section anchor="congestionControl" numbered="true" toc="include" removeInRF
	<section anchor="congestionControl" title="Congestion Control">	C="false" pn="section-9">
	<t>Congestion control for RTP SHALL be used in accordance with RFC 3550	<name slugifiedName="name-congestion-control">Congestion Control</name>
	<xref target="RFC3550"/>, and with any applicable RTP profile; e.g., RFC	<t indent="0" pn="section-9-1">Congestion control for RTP <bcp14>SHALL</bc
	3551 <xref target="RFC3551"/>. The congestion control mechanism can, in	p14> be used in accordance
	a real-time encoding scenario, adapt the transmission rate by	with <xref target="RFC3550" format="default" sectionFormat="of" derivedCon
	instructing the encoder to encode at a certain target rate. Media aware	tent="RFC3550"/>, and with any
	network elements MAY use the information in the VP9 payload descriptor	applicable RTP profile, e.g., <xref target="RFC3551" format="default" sect
	in <xref target="VP9payloadDescriptor"/> to identify non-reference	ionFormat="of" derivedContent="RFC3551"/>. The congestion control mechanism can,
	frames and discard them in order to reduce network congestion. Note that	in a real-time
	discarding of non-reference frames cannot be done if the stream is	encoding scenario, adapt the transmission rate by instructing the
	encrypted (because the non-reference marker is encrypted).</t>	encoder to encode at a certain target rate. Media-aware network elements
		<bcp14>MAY</bcp14> use the information in the VP9 payload descriptor in
		<xref target="VP9payloadDescriptor" format="default" sectionFormat="of" de
		rivedContent="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>

		<section anchor="IANAConsiderations" numbered="true" toc="include" removeInR
	<section anchor="IANAConsiderations" title="IANA Considerations">	FC="false" pn="section-10">
	<t>The IANA is requested to register the media type registration	<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	"video/vp9" as specified in <xref	<t indent="0" pn="section-10-1">IANA has registered the media type "video/
	target="mediaTypeRegistration"/>. The media type is also	vp9"
	requested to	as specified in <xref target="mediaTypeRegistration" format="default" sect
	be added to the IANA registry for "RTP Payload Format MIME types"	ionFormat="of" derivedContent="Section 7"/>.
	<http://www.iana.org/assignments/rtp-parameters>.</t>	The media type has also been added to the
		"RTP Payload Format Media Types" registry of the "Real-Time Transport Prot
		ocol (RTP) Parameters" registry group (<eref target="https://www.iana.org/assign
		ments/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>


	<section title="Acknowledgments">
	<t>Alex Eleftheriadis, Yuki Ito, Won Kap Jang, Sergio Garcia
	Murillo, Roi Sasson, Timothy Terriberry, Emircan Uysaler, and
	Thomas Volkert commented on the development of this document and
	provided helpful comments and feedback.</t>

	</section>

	</middle>	</middle>


	<back>	<back>

	<references title='Normative References'>	<references pn="section-11">
		<name slugifiedName="name-references">References</name>
	<reference anchor='VP9-BITSTREAM' target='https://storage.googleapis.co	<references pn="section-11.1">
	m/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-d	<name slugifiedName="name-normative-references">Normative References</na
	raft.pdf'>	me>
	<front>	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<title>VP9 Bitstream & Decoding Process Specification</titl	119" quoteTitle="true" derivedAnchor="RFC2119">
	e>	<front>
		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	<author initials='A' surname='Grange' fullname='Adrian Grange'>	le>
	<organization>Google</organization>	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	</author>	<date month="March" year="1997"/>
	<author initials='P' surname='de Rivaz' fullname='Peter de Riva	<abstract>
	z'>	<t indent="0">In many standards track documents several words are
	<organization>Argon Design</organization>	used to signify the requirements in the specification. These words are often cap
	</author>	italized. This document defines these words as they should be interpreted in IET
	<author initials='J' surname='Hunt' fullname='Jonathan Hunt'>	F documents. This document specifies an Internet Best Current Practices for the
	<organization>Argon Design</organization>	Internet Community, and requests discussion and suggestions for improvements.</t
	</author>	>
	<date month='March' day='31' year='2016' />	</abstract>
	<abstract>	</front>
	<t>	<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/rfc3
		264" 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 entit
		ies can make use of the Session Description Protocol (SDP) to arrive at a common
		view of a multimedia session between them. In the model, one participant offers
		the other a description of the desired session from their perspective, and the
		other participant answers with the desired session from their perspective. This
		offer/answer model is most useful in unicast sessions where information from bot
		h participants is needed for the complete view of the session. The offer/answer
		model is used by protocols like the Session Initiation Protocol (SIP). [STANDARD
		S-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/rfc3
		550" 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 transpo
		rt protocol. RTP provides end-to-end network transport functions suitable for ap
		plications transmitting real-time data, such as audio, video or simulation data,
		over multicast or unicast network services. RTP does not address resource reser
		vation and does not guarantee quality-of- service for real-time services. The da
		ta transport is augmented by a control protocol (RTCP) to allow monitoring of th
		e 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 supp
		orts the use of RTP-level translators and mixers. Most of the text in this memor
		andum is identical to RFC 1889 which it obsoletes. There are no changes in the p
		acket formats on the wire, only changes to the rules and algorithms governing ho
		w the protocol is used. The biggest change is an enhancement to the scalable tim
		er algorithm for calculating when to send RTCP packets in order to minimize tran
		smission in excess of the intended rate when many participants join a session si
		multaneously. [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/rfc4
		585" 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 de
		gree, resilient against packet losses. Receivers may use the base mechanisms of
		the Real-time Transport Control Protocol (RTCP) to report packet reception stati
		stics 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 imm
		ediate feedback to the senders and thus allows for short-term adaptation and eff
		icient feedback-based repair mechanisms to be implemented. This early feedback p
		rofile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves sca
		lability 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/rfc4
		855" 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 RT
		P 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 a
		n 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/rfc5
		104" quoteTitle="true" derivedAnchor="RFC5104">
		<front>
		<title>Codec Control Messages in the RTP Audio-Visual Profile with F
		eedback (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 mess
		ages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful
		primarily in conversational multimedia scenarios where centralized multipoint fu
		nctionalities are in use. However, some are also usable in smaller multicast env
		ironments and 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 Medi
		a 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>
		<reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6
		838" 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 specificati
		on and registration of media types for use in HTTP, MIME, and other Internet pro
		tocols. 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/rfc8
		174" quoteTitle="true" derivedAnchor="RFC8174">
		<front>
		<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
		tle>
		<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 clari
		fying that only UPPERCASE usage of the key words have the defined special meanin
		gs.</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/rfc8
		866" 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 ses
		sion announcement, session invitation, and other forms of multimedia session ini
		tiation. 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/rfc9
		627" 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</organizati
		on>
		</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-dr
		aft.pdf" quoteTitle="true" derivedAnchor="VP9-BITSTREAM">
		<front>
		<title>VP9 Bitstream & Decoding Process Specification</title>
		<author initials="A" surname="Grange" fullname="Adrian Grange">
		<organization showOnFrontPage="true">Google</organization>
		</author>
		<author initials="P" surname="de Rivaz" fullname="Peter de Rivaz">
		<organization showOnFrontPage="true">Argon Design</organization>
		</author>
		<author initials="J" surname="Hunt" fullname="Jonathan Hunt">
		<organization showOnFrontPage="true">Argon Design</organization>
		</author>
		<date month="March" day="31" year="2016"/>
		<abstract>
		<t indent="0">
	This document defines the bitstream format and decoding process for the	This document defines the bitstream format and decoding process for the
	Google VP9 video codec.	Google VP9 video codec.

	</t>	</t>
	</abstract>	</abstract>
		</front>
	</front>	<seriesInfo name="Version" value="0.6"/>
	<seriesInfo name='Version' value='0.6' />	</reference>
	</reference>	</references>
		<references pn="section-11.2">
	&rfc2119;	<name slugifiedName="name-informative-references">Informative References
		</name>
	&rfc8174;	<reference anchor="RFC3551" target="https://www.rfc-editor.org/info/rfc3
		551" quoteTitle="true" derivedAnchor="RFC3551">
	&rfc4585;	<front>
		<title>RTP Profile for Audio and Video Conferences with Minimal Cont
	&rfc3550;	rol</title>
		<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
	&rfc8866;	"/>
		<author fullname="S. Casner" initials="S." surname="Casner"/>
	&rfc6838;	<date month="July" year="2003"/>
		<abstract>
	&rfc4855;	<t indent="0">This document describes a profile called "RTP/AVP" f
		or the use of the real-time transport protocol (RTP), version 2, and the associa
	&rfc5104;	ted control protocol, RTCP, within audio and video multiparticipant conferences
		with minimal control. It provides interpretations of generic fields within the R
	&lrr;	TP specification suitable for audio and video conferences. In particular, this d
		ocument defines a set of default mappings from payload type numbers to encodings
	&rfc3264;	. This document also describes how audio and video data may be carried within RT
		P. 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 interop
		erable implementations were not found. The additions to RFC 1890 codify existing
		practice in the use of payload formats under this profile and include new paylo
		ad 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/rfc3
		711" 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 Transpo
		rt Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which c
		an 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/rfc5
		124" quoteTitle="true" derivedAnchor="RFC5124">
		<front>
		<title>Extended Secure RTP Profile for Real-time Transport Control P
		rotocol (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 communica
		tions and another profile (AVPF) to provide timely feedback from the receivers t
		o a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifi
		es the combination of both profiles to enable secure RTP communications with fee
		dback. [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/rfc6
		386" 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 dat
		a format, together with a discussion of the decoding procedure for the format. T
		his document is not an Internet Standards Track specification; it is published f
		or 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/rfc7
		201" 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 heterogenei
		ty implies that different security mechanisms are needed to provide services suc
		h as confidentiality, integrity, and source authentication of RTP and RTP Contro
		l Protocol (RTCP) packets suitable for the various environments. The range of so
		lutions 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 appropr
		iate 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/rfc7
		202" 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-tim
		e multimedia sessions. It also explains why the Real-time Transport Protocol (RT
		P) 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 e
		xtensions to ensure that appropriate security mechanisms are mandated and that a
		ny such mechanisms are specified in a manner that conforms with the RTP architec
		ture.</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/rfc7
		667" 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-end
		point topologies used in environments based on the Real-time Transport Protocol
		(RTP). In particular, centralized topologies commonly employed in the video conf
		erencing 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>	</references>

		<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
	<references title='Informative References'>	ndix.a">
		<name slugifiedName="name-acknowledgments">Acknowledgments</name>
	&rfc3551;	<t indent="0" pn="section-appendix.a-1"><contact fullname="Alex Eleftheria
		dis"/>, <contact fullname="Yuki Ito"/>, <contact fullname="Won Kap Jang"/>
	&rfc5124;	, <contact fullname="Sergio Garcia"/> <contact fullname="Murillo"/>, <cont
		act fullname="Roi Sasson"/>, <contact fullname="Timothy Terriberry"/>, <co
	&rfc6386;	ntact fullname="Emircan Uysaler"/>, and <contact fullname="Thomas Volkert"/>
		commented on the development of this document and provided helpful
	&rfc7201;	feedback.</t>
		</section>
	&rfc7202;	<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
		="include" pn="section-appendix.b">
	&rfc7667;	<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
		<author fullname="Justin Uberti" initials="J." surname="Uberti">
	&rfc3711;	<organization showOnFrontPage="true">OpenAI</organization>
		<address>
	</references>	<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.</organ
		ization>
		<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.</organ
		ization>
		<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.</organ
		ization>
		<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. / Ji
		tsi</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>	</back>
	</rfc>	</rfc>

	<!-- LocalWords: PictureID DCT Hadamard WHT SSRC CSRC pyld hdr FI VER RPSI
	-->
	<!-- LocalWords: stPartitionSize SDP AVPF SRTP IANA PID PICIDX TID
	-->

End of changes. 113 change blocks.
	1054 lines changed or deleted	1876 lines changed or added
This html diff was produced by rfcdiff 1.48.